DifyからMastraへの移行

参考になった

レビュー投稿日の情報になります

株式会社DELTA / ak2-lucky

メンバー / バックエンドエンジニア

最終更新日2025/12/04投稿日2025/12/05

ツールの利用規模	ツールの利用開始時期	事業形態
10名以下	2025年6月	B to B

導入の背景・解決したかった問題

生成AIを組み込んだプロダクトを作成するために、元々Difyを使用していた。

アプリケーション自体はVercel上のNext.jsで動作し、DifyにAPIコールするような作りである。

DifyはGUIだけで即座にワークフローを作成できるため、簡単な検証や小規模なツールなどには向いている。

しかし、アプリケーションの開発が進み、Difyで構築したワークフローが複雑化し、プロダクションとして動かしていくうちに、次の課題が顕在化してきた。

変更履歴の可視化が難しい — GUI での編集内容に誰も気づけない。変更履歴も残らない。
ログ追跡が大変 — Difyではワークフローのネストが深い場合、エラーなどが起きた時に、GUI上で実行ログを追いにくい。(ワークフローを行ったり来たりしないといけない)
型がない — JSON や JSON をString に変換したものでワークフロー間の値の受け渡しをしていたため、実行時までバグが存在するか分かりづらい。
デプロイが手動になる — 自動でデプロイするような機構がなく、環境がいくつかに分かれていると、反映の作業をそれぞれの環境で手動でやる必要がある。

ワークフローをコード化できて、持続的な開発サイクル(フィードバック=>修正=>デプロイ)を素早く回せる状態

上記のコード化によって、以下のようになるはずと考えた。

課題	Mastra導入後
変更履歴の可視化が難しい	コード化し、Git上で管理を行うことによって、誰がどのような変更を行なったかすぐにわかるようになった。
ログ追跡が大変	Sentryなどを導入し、エラー検知やその後の調査が簡単になった。コードベースではどこでエラーになったかが即座にわかる。
型がない	Mastraは各ワークフローやステップ単位で入出力の型を必須とするため、厳密な型定義ができ、堅牢なコードベースを維持できている。
デプロイが手動になる	MastraをNext.jsに組み込み利用できるためデプロイが簡単になった。Vercelを使っていることもあり、デプロイに関してはほぼ困っていない。

上記の元々の課題の解決に加え

一部のLLMの応答の評価テストも導入できた。(MastraのEval機能の活用)

プルリクエスト作成時や任意のマージの前のタイミングで評価のテストを走らせることにより、本番環境でもLLMからの一定程度の品質の応答は担保しうる仕組みを作っている。

DifyからMastraへの移行自体にそこまで大きな壁はなかった。

コーディングエージェントを利用して、小さなワークフローからコード化していった。

MastraはドキュメントのMCP Server を用意してくれているので、そちらをコーディングエージェントが参照する事で、最新のドキュメントに沿ったコード化ができた。

移行時の詳細な方法は記事に書いている。

これから開発サイクルを早く回していくなら、Difyからコードベースでの運用ができるMastraに移行したい！という話を以下のメリットを添えて行なった。

コードベースでの開発運用のしやすさ
コーディングエージェントを使った開発との親和性の高さ(MastraはMCP Server が用意されており、コーディングエージェントが公式ドキュメントを参照した開発ができるので、開発精度が高く、手戻りが少ない)
デプロイなどの容易性(Next.jsを使ったアプリケーションを開発していたので、そこに組み込めるとなると、アプリケーションと同時にデプロイができて、反映が容易になる)