プロトタイプから製品へ。「AI出張手配」がn8nを卒業し、Mastraを選んだ技術的背景
株式会社TOKIUM / 井上智敬
EM / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
| 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
Agent,Tools,Memory,RAG | 11名〜50名 | 2025年7月 | B to B |
| 利用機能 | Agent,Tools,Memory,RAG |
|---|---|
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2025年7月 |
| 事業形態 | B to B |
アーキテクチャ

アーキテクチャの意図・工夫
クリーンアーキテクチャの徹底と、標準機能の取捨選択を行いました。
Mastraのエージェント定義を「インフラ層」に配置し、ドメインロジック(ビジネスルール)と完全に分離しました。 また、Mastra標準の「Workflow機能」を使用せず、オーケストレーションを自前のTypeScriptコードで実装しました。これにより、パフォーマンスを確保しつつ、独自の決定論的な制御を実現しています。さらに、Mastraのメモリの入出力など、複数のAIエージェントで共通ルールとして持たせるべき機能を「独自SDK」でラップして利用しています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
当初は、検証サイクルを最優先し、ローコードツール n8n で開発していました。しかし、機能拡張に伴いフローが複雑化し、以下の問題に直面しました。
- レビューの崩壊: ワークフローが複数の巨大なJSONとなり、差分が読めずコードレビューが機能しない。
- デバッグ困難: 複雑な分岐により不具合を追跡しづらくなった。
- デグレーション: コード管理の限界とテストがしづらい状態もあり、システムの振る舞いで破壊的変更が起きやすい状態であった。
どのような状態を目指していたか
「検証用プロトタイプ」から、保守可能で堅牢な「製品」へとフェーズを移行させたいと考えていました。 変化の激しい分野であるからこそ、要求や外的要因などの変化に強い状態にすることが最大の関心事でした。 具体的には、ドメインロジックの保護、テストの自動化、そしてチームでの継続的な開発が可能な「エンジニアリング」ができる状態を目指しました。
比較検討したサービス
- Python (LangChain等)
- n8n (既存利用)
- Dify
比較した軸
- 全員がキャッチアップしやすい言語を利用できるか。
- クリーンアーキテクチャ等の設計パターンを適用しやすい構造か。
- 型定義がしっかりしており、エラーを早期に検知できるか。
選定理由
TypeScriptネイティブである点です。
フロントエンドからバックエンドまでTypeScriptで統一しているため、型定義を「ドキュメント」として扱える点が最大の魅力でした。また、フレームワークの構造がシンプルで、自分たちのアーキテクチャ(クリーンアーキテクチャ)に組み込みやすい点も決め手となりました。
導入の成果
改善したかった課題はどれくらい解決されたか
Gitによるバージョン管理とコードレビューが正常に機能するようになり、チーム開発の健全性が回復しました。また、TypeScriptの型システムにより、変更時の影響範囲が明確になり、デグレーションが大幅に減りました。
どのような成果が得られたか
開発リードタイムが「爆速(だが不安定)」から「安定的かつ計算可能」な状態に変化しました。 また、ロジック部分の単体テストが可能になったことで、安心してリファクタリングや機能追加を行える心理的安全性が確保されました。
導入時の苦労・悩み
導入当時はMastraが進化の途中(v1.0到達前)だったため、破壊的変更(Breaking Changes)への追従に苦労しました。特にメソッド名の変更や、メモリ(会話履歴)のI/O仕様変更などは影響が大きく、都度修正が必要でした。
また、標準機能だけでは非構造データの整合性を保つのが難しく、独自の実装が必要な場面がありました。
導入に向けた社内への説明
上長・チームへの説明
「現在のローコード(n8n)のままでは、将来的な保守コストが開発スピードを上回り、製品としての品質維持が不可能になる」と説明しました。
他のAIエージェント開発チームからも、同様の懸念がありました。 チームで議論した結果、「n8n は、検証サイクルを高速に回す役割を十分に果たした。ヒアリングしながら要求を収集する段階は過ぎ、品質を担保した製品として開発していくべきである。」と結論づけました。
その上で「TypeScriptベースのMastraに移行することで、初期コストはかかるが、型安全性とテスト容易性を手に入れ、長期的には開発リードタイムが安定する」と、合意して進めました。
活用方法
社内の経理AIエージェント群の先行事例である「AI出張手配」アプリケーションをはじめ、複数のAIエージェントのバックエンドとして利用しています。
よく使う機能
- Agents (LLMモデルのラッパーとして)
- Tools (外部API連携)
- Memory (会話履歴管理)
- Web Routing(Webサーバ機能 Hono)
ツールの良い点
- TypeScriptネイティブ: 型安全性が高く、開発体験(DX)が良い。組み込みのWebサーバである Hono のパフォーマンスが良い。
- 柔軟性: フレームワークとして主張しすぎず、必要な機能だけを切り出して使いやすい(我々のようにWorkflowを使わない選択もできる)。
- 導入の容易さ: 既存のTypeScriptプロジェクトに違和感なく統合できる。
ツールの課題点
- 進化の速さゆえの変更: (現在はv1.0で安定していると思われるが)APIの変更などが頻繁にあった。
- Workflow機能: 複雑な条件分岐やパフォーマンス面で、まだ改善の余地があると感じた(そのため自前実装を選んだ)。
- メモリ機能: 各AIエージェントを横断した対話をする場合の管理機能が不足している。また、作業メモリ Working Memory はJSONやMarkdownとなるので互換性を意識した開発が必要となる。
ツールを検討されている方へ
フレームワークに完全にロックインされるのではなく、「インフラ層」として扱うなど、適度な距離感を保って設計・実装すると、より保守性の高いアプリケーションと思います。
今後の展望
Mastraや周辺技術の進化(特にRAG連携やメモリ管理の強化)に追従しつつ、「エージェントをどう分割・統合するか」「プロンプトエンジニアリング」といったLLM活用の本質的な改善に注力していきます。
より自律的で精度の高いエージェントへと進化させていく予定です。
株式会社TOKIUM / 井上智敬
EM / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
よく見られているレビュー
株式会社TOKIUM / 井上智敬
EM / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法



