Dify=>mastraへの移行

はじめに

初めまして！
皆様どうもこんばんわ、こんにちわ、おはようございます。
エンジニアの榎本です。

最近、Difyで作ったワークフローをmastraへ移行することがあったので、それの進め方について備忘録的に描きたいと思います。

参考になれば大変幸いです。

この記事が参考になる方

• Dify を使っているが、ワークフローが複雑になりすぎて管理がつらい
• GUI ではなく Git でワークフローをバージョン管理したい
• Next.js など既存アプリにワークフローを組み込みたい
• zod などで 型定義された入出力 を設計したい

Difyとは

Dify は LangGenius 社が OSS として公開している LLM アプリ開発プラットフォーム です。
GUI だけでもワークフローを組めるため、PoC や社内ツールのような “とりあえず動くもの” を作る用途にぴったりです。
https://dify.ai/jp

UI で即座に試行錯誤できるため、検証やちょろっとLLMに処理させたいとかがあればDifyはうってつけです。

mastraとは

mastra は、Vercel AI SDK をベースにした TypeScript 製のオープンソース Agent フレームワーク です。
https://mastra.ai/

自社のアプリケーションなどにLLMを組み込んで、agentやワークフローを構築したりするようなAIアプリケーションを作るのはうってつけです。
コードファースト & 型安全 を特徴とし、CI/CD・テスト・監視と親和性が高いのが強みです。

なぜ移行を検討した？

Dify で作ったワークフローが増えるにつれ、次の課題が顕在化しました。

1. 変更履歴の可視化が難しい — GUI での編集内容が Git に残らない
2. ログ追跡が大変 — ネストが深く、実行ログを追いにくい
3. 型がない — Json や Json をstring に変換したもので雑にやり取りしていたため破壊的変更に気付きにくい

開発を進めていく際に、Difyの修正や問題が起きた時にログを追ったりするのが時間がかかるようになっていたため、Mastra への移行 を決めました。

どうやって移行したか

自分の場合、Difyで構築したワークフローを一つ一つ移行していきました。
その時は以下のような手順でやっていました。

・Dify からワークフローのymlファイルをexport
・cline にymlを読み込ませ、以下の指示の元、 mastra のコードを書いていく。

dify/xxxxxx.ymlを読んで、同様のワークフローをmastraで実装してください。

注意点は以下です。
・xxxxxの情報取得するtoolはyyyy_toolを使ってください。
・外部APIを使っている部分に関しては、xxxx_toolを参考に新しいtoolを作成してください。
・作成するworkflow,tool,agentの実装はmastraのmcpのドキュメントを参照して実装して欲しいです。
・inputやoutputはできるだけjsonやjsonをstringに変換したものではなく、zodでobjectを表現してください。
・省略できそうなstepは省略してください

少し補足をしておきます

・作成するworkflow,tool,agentの実装はmastraのmcpのドキュメントを参照して実装して欲しいです。

mastra はドキュメントの MCP server が用意してくれているので、cline にこれを参照しつつコードを書いてくれ！という指示をするとかなり正確にコードを書いてくれます。
https://mastra.ai/ja/docs/getting-started/mcp-docs-server

ドキュメントの MCP serverが用意されているのと、ないのとではかなりコードの品質が変わりそうだなという印象あるので、助かりますね。

・input や output はできるだけ json や json を string に変換したものではなく、 zod でobject を表現してください。

mastra の場合、ワークフローや各 step の入出力は zod schemaで定義します。
これが mastra 移行によるメリットなので、Dify では json やそれっぽい object を渡したりしていましたが(個人差あり)、この辺の入出力の型をきちんと定義できるのは嬉しいですね。

移行によるメリット

メリットはいくつかあります。

1. mastra のドキュメントにアクセスできる MCP serverが用意されている
2. 各ワークフローやその中の詳細な step に型定義ができる
3. コード化によって開発運用に乗せることができる(みんなで開発しやすい、vibe codingもしやすい、Claude Codeとかにも任せれる)
4. test も書くことができる
5. mastra では agent の評価もできる
   よくある話かもしれませんが、LLM の出力は毎回同じ output が出るわけではないので、少し不安定だったりします。
   ですが、アプリケーションに組み込むのであれば一定の品質を担保をしたいものです。
   (本番運用レベルに持っていくなら、AI だから不安定でも仕方ないよねーではあまり済ませたくない。。。)
   そんな時に、mastra を使っていれば、LLMのいろんな評価のtestもかけたりします。
   詳細はドキュメントに書かれていますが、色んな種類の評価できるので、少しずつ導入してみましょう。
   CI にいくつかの評価を組み込んでおけば、コードの変更があったとしても、一定品質を保つことができるでしょう。

※これは全員に当てはまるわけではないですが、今回は Next.js でアプリケーションを作成していたので、Next.js に統合して、mastra の実装ができるのもメリットの一つでした。
(Next.js が動作しているインフラ上でそのまま mastra も動かすことができます)
https://mastra.ai/ja/docs/frameworks/next-js#2-直接統合

最後に

いかがだったでしょうか？
個人的なイメージですが、mastra は結構使いやすいなーという印象です。
特にコードで管理できる点は AI を使った開発とも相性がすごく良いです。
AI アプリケーションを開発をする際はぜひ検討してみてください！