1.やりたかったこと
仕事でDifyというノーコードAIツールを使っている。チャットボットとか、社内のFAQ自動応答とか、そういうのをGUIでポチポチ作れるやつだ。
便利なんだけど、ひとつ面倒なことがある。
ワークフローを作るたびに、Difyの管理画面を開いて、ノードをドラッグして、設定を埋めて、接続して……という手作業が発生する。1個2個ならいいけど、10個20個となると正直しんどい。しかもワークフローの「設計書」にあたるDSLファイル（※後述）を手で書くのも、YAML形式の数百行をミスなく書くのはなかなかの苦行だ。
で、思った。
「日本語で『こういうワークフロー作って』と言ったら、あとは全部自動でやってくれないか？」
結論から言うと、できた。この記事はその設定の記録と、やってみて感じた「自動化の勘所」について書く。
2.そもそもDifyって何？という人へ
Difyは、AIアプリケーションをプログラミングなしで作れるプラットフォームだ。たとえば「お客様からの問い合わせメールを読んで、カテゴリ分けして、適切な返答の下書きを作る」みたいな処理を、画面上でブロックを繋いで作れる。
レゴブロックでAIの処理フローを組み立てる、と言えばイメージしやすいかもしれない。
DSL（Domain Specific Language）とは： Difyのワークフローを定義する設計図のようなもの。YAML形式のテキストファイルで、「どんなブロックがあって、どう繋がっていて、各ブロックの設定はこうで……」という情報がすべて記述されている。人間が読めるが、手書きするのはかなり大変。
3.何をどう自動化したのか
3-1.仕組みの全体像
やったことをざっくり言うと、こうだ。
Claude Code（AIアシスタント） → 自然言語の指示を受け取る → DSLを自動生成 → DifyのAPIに投げる → Difyにワークフローが自動登録される
この「DifyのAPIに投げる」部分を担うのが、今回作ったMCPサーバーだ。
MCP（Model Context Protocol）とは： AIアシスタントが外部のツールやサービスと連携するための仕組み。たとえばAIが「ファイルを読みたい」「APIを叩きたい」と思ったとき、MCPサーバーを通じてそれを実行できる。AIの手足を増やすアダプターのようなもの。
API（Application Programming Interface）とは： ソフトウェア同士が会話するための窓口。人間がブラウザで管理画面を操作する代わりに、プログラムが直接「このワークフローを登録して」とリクエストを送れる。
3-2.具体的に何を作ったか
Pythonで約200行のMCPサーバーを書いた。できることは5つ。
- アプリ一覧の取得 — Difyに登録済みのワークフローを一覧で見る
- DSLのエクスポート — 既存ワークフローの設計図をYAML形式で取り出す
- DSLのインポート — YAML形式の設計図を送って新しいワークフローを作る
- アプリ詳細の取得 — 個別のワークフローの設定内容を確認する
- アプリの削除 — 不要になったワークフローを消す
これだけ。シンプルだけど、3番目の「インポート」があるのが肝だ。AIが生成したDSLをそのままDifyに流し込める。
4.設定で一番ハマったところ
4-1.認証トークンの取得
DifyのConsole API（管理画面の裏側で動いているAPI）は、公式ドキュメントには載っていない。いわゆる「内部API」だ。
内部API（非公開API）とは： サービスの管理画面が裏側で使っているAPI。公式にサポートされているわけではないので、アップデートで急に動かなくなる可能性がある。使うなら自己責任。
認証に使うトークン（※一種の合言葉）も、設定画面からコピーできるようなものではなく、ブラウザの開発者ツールから抜き出す必要がある。
手順はこうだ。
- Difyの管理画面にログインする
- ブラウザの開発者ツールを開く（Macなら
Cmd + Option + I） - 「Application」タブの「Local Storage」を見る
console_tokenみたいな名前のキーを探す
ここが一番「これ本当に合ってるのか？」と不安になるポイントだった。実際、最初は設定画面の「API拡張」のページを開いてしまい、全然違う場所だと気づくのに数分かかった。
4-2.セッショントークンの有効期限問題
このトークンはセッションベース、つまり一定時間で失効する。長期運用するなら、ログインAPIから自動取得する仕組みを入れるか、定期的にトークンを更新する運用が必要になる。
今回はまず「動くことの確認」を優先して、手動でトークンを設定する方式にした。本番運用で使うなら、ここは要改善ポイントだ。
5.自動化で生産性はどのくらい変わるのか
5-1.手作業の場合
- Dify管理画面を開く
- 「新規作成」をクリック
- ワークフローモードを選択
- スタートノードを設定
- LLMノードを追加してモデルとプロンプトを設定
- 必要に応じて条件分岐やナレッジ検索ノードを追加
- エンドノードを設定
- 各ノードを接続
- テスト実行
- 公開
シンプルなワークフローでも15〜30分。複雑なものだと1時間以上かかる。
5-2.自動化した場合
「問い合わせメールを受け取って、カテゴリ分類して、日本語で返答を生成するワークフローを作って」
と指示する。30秒〜1分でDifyにワークフローが登録される。
もちろん、生成されたものの確認や微調整は必要だ。でも「ゼロから作る」のと「8割できたものを直す」のでは、かかる時間も精神的な負荷もまるで違う。
5-3数字にすると
手作業自動化シンプルなワークフロー15〜30分1〜2分 + 確認5分複雑なワークフロー1〜2時間3〜5分 + 確認15分月10本作る場合の合計5〜20時間1〜3時間
月に5〜17時間の削減。年間にすると60〜200時間。1人分のエンジニアの1ヶ月分以上の工数に相当する。
6.組織にとって「仕組み化」が重要な理由
ここからは少し抽象的な話になるが、自動化の恩恵は「時間の節約」だけじゃない。
6-1.属人化が減る
ワークフローの作り方を知っている人が休んだら作れない、という状態は組織のリスクだ。自然言語で指示すれば作れる仕組みがあれば、Difyの操作に詳しくない人でもワークフローを作れる。
属人化とは： 特定の人しかできない仕事がある状態。その人が辞めたり休んだりすると業務が止まる。
6-2.品質が安定する
手作業でノードを繋ぐと、人によって設計がバラバラになる。エラーハンドリングを入れ忘れたり、プロンプトの書き方が統一されなかったり。テンプレートベースで自動生成すれば、最低限の品質は担保される。
6-3.試行錯誤のコストが下がる
「このプロンプトで試してみて、ダメだったら別のパターンで」というサイクルが、手作業だと1回30分かかるところが、自動化なら1回2分で回せる。結果として、より良いワークフローにたどり着くまでの時間が劇的に短くなる。
7.注意点は、バージョンには気をつけて！
正直に書いておく。この仕組みにはいくつか課題がある。
内部APIへの依存。 Difyのバージョンが上がったら動かなくなる可能性がある。実際、インポート用のAPIエンドポイント（URLの末尾）が /apps/import なのか /apps/imports なのか、バージョンによって違うらしく、両方試すフォールバック処理を入れた。
トークンの有効期限。 前述のとおり、セッショントークンは時間で失効する。自動更新の仕組みを入れないと、朝出社したら動かなくなっている、ということが起きる。
生成されたDSLの品質。 AIが生成するDSLは、そのまま使えるときもあれば、微妙に間違っているときもある。特にDify固有の記法や、モデルプロバイダーの指定は、Difyのバージョンによって変わることがある。完全放置での運用は現時点ではおすすめしない。
8.まとめ
「自然言語で指示 → DSL自動生成 → Difyに自動登録」のパイプラインは、思ったより簡単に作れた。Pythonで200行、設定ファイルをいくつか書いて、トークンを取得するだけ。
ただ、「簡単に作れる」ことと「安定して運用できる」ことは別の話だ。内部APIへの依存やトークン管理など、本番で使うにはもう少し手を入れる必要がある。
それでも、この仕組みがあるとないとでは、日々の開発速度がまるで違う。ワークフローを「作る」作業から「設計する」作業に集中できるようになる。手を動かす時間が減って、頭を使う時間が増える。
自動化の本質は、たぶんそこにある。
この記事で紹介したMCPサーバーのコードは約200行のPythonスクリプトです。FastMCPフレームワークを使用しています。導入を検討される方は、Difyのバージョンとの互換性を事前に確認してください。
あわせて読みたい
