プロトタイプから製品へ。「AI出張手配」がn8nを卒業し、Mastraを選んだ技術的背景

ツール導入前の課題

当初は、検証サイクルを最優先し、ローコードツール n8n で開発していました。しかし、機能拡張に伴いフローが複雑化し、以下の問題に直面しました。

• レビューの崩壊: ワークフローが複数の巨大なJSONとなり、差分が読めずコードレビューが機能しない。
• デバッグ困難: 複雑な分岐により不具合を追跡しづらくなった。
• デグレーション: コード管理の限界とテストがしづらい状態もあり、システムの振る舞いで破壊的変更が起きやすい状態であった。

どのような状態を目指していたか

「検証用プロトタイプ」から、保守可能で堅牢な「製品」へとフェーズを移行させたいと考えていました。 変化の激しい分野であるからこそ、要求や外的要因などの変化に強い状態にすることが最大の関心事でした。 具体的には、ドメインロジックの保護、テストの自動化、そしてチームでの継続的な開発が可能な「エンジニアリング」ができる状態を目指しました。

• Python (LangChain等)
• n8n (既存利用)
• Dify

• 全員がキャッチアップしやすい言語を利用できるか。
• クリーンアーキテクチャ等の設計パターンを適用しやすい構造か。
• 型定義がしっかりしており、エラーを早期に検知できるか。

TypeScriptネイティブである点です。

フロントエンドからバックエンドまでTypeScriptで統一しているため、型定義を「ドキュメント」として扱える点が最大の魅力でした。また、フレームワークの構造がシンプルで、自分たちのアーキテクチャ（クリーンアーキテクチャ）に組み込みやすい点も決め手となりました。

改善したかった課題はどれくらい解決されたか

Gitによるバージョン管理とコードレビューが正常に機能するようになり、チーム開発の健全性が回復しました。また、TypeScriptの型システムにより、変更時の影響範囲が明確になり、デグレーションが大幅に減りました。

どのような成果が得られたか

開発リードタイムが「爆速（だが不安定）」から「安定的かつ計算可能」な状態に変化しました。 また、ロジック部分の単体テストが可能になったことで、安心してリファクタリングや機能追加を行える心理的安全性が確保されました。

導入当時はMastraが進化の途中（v1.0到達前）だったため、破壊的変更（Breaking Changes）への追従に苦労しました。特にメソッド名の変更や、メモリ（会話履歴）のI/O仕様変更などは影響が大きく、都度修正が必要でした。

また、標準機能だけでは非構造データの整合性を保つのが難しく、独自の実装が必要な場面がありました。

フレームワークに完全にロックインされるのではなく、「インフラ層」として扱うなど、適度な距離感を保って設計・実装すると、より保守性の高いアプリケーションと思います。

Mastraや周辺技術の進化（特にRAG連携やメモリ管理の強化）に追従しつつ、「エージェントをどう分割・統合するか」「プロンプトエンジニアリング」といったLLM活用の本質的な改善に注力していきます。

より自律的で精度の高いエージェントへと進化させていく予定です。