【AI自律エージェント・第6回】「実行役」と「監視役」。2つのDifyを連携させてミスをゼロにする運用術

「1つのAIに全部やらせる」ことの、本当のコスト

第5回で再試行ループを実装したあなたなら、
こんな経験が一度はあるはずです。

「ループは動いている。スコアも80点を超えた。
でも受け取った成果物を読んでみると、
どこか薄い。何かが足りない気がする。」

それは気のせいではありません。

1つのプロンプトに「書け、調べろ、評価しろ、直せ」を
詰め込みすぎると、AIの集中力は分散します。
結果として、どこかで「まあこれでいいか」という
暗黙の妥協が生まれます。

人間でも同じですよね。
「企画」「実行」「品質チェック」「報告」を
全部一人でやらされたら、
どこかが雑になる。

解決策はシンプルです。

AIにも「役割分担」をさせる。

この記事では、Difyを2つ使って
「実行役」と「監視役」を分業させる
マルチエージェント構成を、
設定画面の操作レベルで実況中継します。

読み終わったら、今日中に着手できます。

📌 この記事はシリーズ第6回です。

第5回（IF条件分岐・再試行ループ）を未読の方は先にご確認ください。

→【第5回】合格するまで終わらせない｜IF条件分岐で作る自己修正ループ完全実装ガイド

この記事を読むとわかること

– シングルエージェントが「品質の天井」にぶつかる構造的な理由
– 実行役Difyと監視役Difyを別々に構築し、API連携でつなぐ手順
– 監視役に「異なるモデル」を使う理由と、モデル選定の考え方
– 「不備を1つ見つけるたびに加点する」監視役プロンプトの設計
– 実装時の落とし穴と回避策

第1章：なぜ「1人のAI」では限界なのか

結論：「作る人」と「チェックする人」が同じ脳では、身内に甘くなる

シングルエージェント構成の本質的な問題は、
実行と評価が同じ思考回路の上で動いていることです。

実行役が「これで十分だ」と判断するような基準を持つAIは、
評価役として機能するときも同じ基準を使います。
盲点は、共有されたままです。

人間の組織に置き換えると、こういうことです。
“`
❌ 機能しない体制：
企画書を書いた担当者が、自分でその企画書を審査する

✅ 機能する体制：
企画書を書いた担当者 ≠ 審査する上司・品質管理部門
“`

AIでも、「書いた知能」と「審査する知能」を分離することで、
初めて客観的な品質保証が機能します。

シングルとマルチの品質差を可視化する

この表の「暗黙の要件」と「盲点の発見」が特に重要です。
これらはプロンプトをどれだけ丁寧に書いても、
シングル構成では原理的に防ぎきれません。

第2章：マルチエージェントの全体設計

2つのDifyが担う役割

実行役（Dify A）：Executor

ミッションは「速く、正確に、指示通りに出力する」ことだけです。
評価も判断も一切しない。創造と実行に全リソースを集中させます。
モデル選定：GPT-4oやClaude Haiku など、高速・低コストのモデルが適しています。

監視役（Dify B）：Supervisor

ミッションは「実行役の出力を、第三者として容赦なく審査する」ことです。
合格・不合格の判定だけでなく、「何が、なぜ問題か」を具体的に報告します。
モデル選定：論理的一貫性に優れたモデル（Claude 3.5 Sonnetなど）が適しています。

💡 モデルを分ける理由

実行役と監視役に同じモデルを使うと、同じ盲点を共有します。

異なるアーキテクチャのモデルを組み合わせることで、

一方が見落とした問題をもう一方が発見できる確率が上がります。

これが「別モデル監視」の最大の価値です。

全体フロー図

“`
【実行役ワークフロー：Dify A】

[開始：テーマ入力]
↓
[実行ノード：コンテンツ生成]
↓
[HTTPリクエストノード]
　　　　│── POST → Dify B APIを呼び出す
↓
[監視役からの返答を受信]
↓
[IF分岐：PASS = true?]
├─ YES → [完了・保存・次工程へ]
└─ NO → [フィードバックを変数にセット → 実行ノードへ戻る]

【監視役ワークフロー：Dify B】

[受信：実行役の出力＋元プロンプト]
↓
[評価ノード：品質審査]
↓
[コードノード：結果をパース]
↓
[レスポンス：SCORE / PASS / FEEDBACK を返す]
“`

2つのワークフローがAPIを介してやりとりします。
実行役は「出力と再試行」に集中し、
監視役は「審査とフィードバック生成」に専念します。

第3章：【実装手順】Dify A（実行役）の構築と公開

💻 前提環境

– Dify（クラウド版 or セルフホスト版）

– 第5回のワークフローが存在すること（評価ノードを分離して使います）

Step 1：既存ワークフローから評価ノードを切り離す

第5回で構築したワークフローを開き、
評価ノードとIF分岐ノードを削除します。
（これらの機能は、監視役Dify Bに移管します）

残すのは以下のみです。
“`
[開始] → [実行ノード（コンテンツ生成）] → [出力変数の定義]
“`

Step 2：実行ノードのプロンプトを「実行特化」に書き直す

余計な自己評価の指示を全て取り除き、
生成に集中したシンプルなプロンプトにします。
“`
# 実行役プロンプト（テンプレート）

あなたは優秀なコンテンツライターです。
以下の条件で、指定されたコンテンツを生成してください。

【テーマ】
{{topic}}

【要件】
{{requirements}}

{% if feedback != “” %}
【前回の監視役からの改善指示】
{{feedback}}
※上記の指摘を全て反映した上で再生成してください。
{% endif %}

出力はコンテンツ本文のみ。
前置きや説明文は一切不要です。
“`

初回実行時は`feedback`変数が空なので改善指示は表示されず、
再試行時だけ監視役のフィードバックが自動で差し込まれます。

—

Step 3：HTTPリクエストノードで監視役Dify Bを呼び出す

実行ノードの直後に「HTTPリクエストノード」を追加します。
“`
# HTTPリクエストノードの設定

メソッド：POST
URL：[Dify BのAPIエンドポイントURL]
Headers：
Authorization: Bearer {{DIFY_B_API_KEY}}
Content-Type: application/json

Body（JSON）：
{
“inputs”: {
“executor_output”: “{{output}}”,
“original_requirements”: “{{requirements}}”,
“topic”: “{{topic}}”
},
“response_mode”: “blocking”,
“user”: “dify-a-executor”
}
“`

DifyBのAPIキーとエンドポイントURLは、
Dify Bのワークフロー設定画面の「API」タブから取得できます。

Step 4：Dify AをAPIとして公開する

Dify Aのワークフロー設定から「APIアクセス」を有効にします。
これにより、Dify BからDify Aを呼び出す逆方向の連携も可能になります。

生成されたAPIキーとエンドポイントURLを控えておいてください。
（後のStep 8で使います）

第4章：【実装手順】Dify B（監視役）の構築

Step 5：新規ワークフローを作成する

Difyの管理画面から「新規ワークフロー」を作成します。
名前は `supervisor_v1` など、役割が明確なものにしてください。

入力変数の設定

Step 6：監視役の評価プロンプトを設計する

ここが全実装の中で最も重要な工程です。
“`
# 監視役評価プロンプト

あなたは容赦のない品質管理責任者です。
「不備を1つ発見するごとに報酬が加算される」
という条件のもと、以下の出力を審査してください。

【元の要件】
{{original_requirements}}

【実行役の出力】
{{executor_output}}

—

## 審査項目

### A：要件遵守チェック（各10点満点）
1. 指定文字数の範囲内か
2. 指定フォーマット（見出し、箇条書き等）を守っているか
3. 禁止事項（誇大表現、特定ワードの使用など）が含まれていないか

### B：ビジネス品質チェック（各15点満点）
4. ターゲット読者が読んで具体的な価値を得られるか
5. 主張に根拠・具体例が伴っているか
6. 読者の次の行動（CTA等）が自然に促されているか
7. 法的・倫理的に問題のある表現がないか

—

## 出力形式【厳守】
以下のフォーマット以外の文字を一切出力しないこと。

SCORE:[0〜100の整数のみ]
PASS:[trueまたはfalse ※SCOREが80以上ならtrue]
ISSUES:
– [問題点1：何が・なぜ基準を満たさないか]
– [問題点2：同上、なければ「なし」と記載]
FEEDBACK:
[実行役への具体的な改善指示。
「〜の部分を〜に変更せよ」という形式で記載すること]
“`

「不備を見つけるごとに報酬を与える」という擬似制約が
監視役に批判的視点を持たせる上で効果的です。
これは、「ハロー効果で合格させてしまう」という
LLMの傾向を打ち消すための設計です。

Step 7：コードノードでレスポンスをパースする

評価プロンプトの出力をそのまま使うのは不安定です。
コードノードを挟み、確実に数値と真偽値に変換します。

Step 8：不合格時に実行役Dify Aへフィードバックを返す

Dify Bの末尾に条件分岐を追加します。
“`
[IF分岐]
PASS = true → [正常レスポンスを返す]
PASS = false → [HTTPリクエストノードでDify Aを再呼び出し]
“`

Dify Aへの再呼び出しBODY：
“`json
{
“inputs”: {
“topic”: “{{topic}}”,
“requirements”: “{{original_requirements}}”,
“feedback”: “{{feedback}}”
},
“response_mode”: “blocking”,
“user”: “dify-b-supervisor”
}
“`

これで、監視役が不合格を出すたびに
実行役が自動で再試行するループが完成します。

—

第5章：【落とし穴レポート】実装で詰まった3つのポイント

落とし穴①：response_modeをblockingにするとタイムアウトする

監視役の評価プロンプトが複雑なほど、処理に時間がかかります。
`blocking`モードは最大30秒でタイムアウトするため、
`streaming`モードに変更し、完了イベントのみ受け取る設計に切り替えてください。

落とし穴②：異なるモデルでAPIコストが2倍以上になる

実行役と監視役を別モデルにすると、
1サイクルでAPIコールが少なくとも2回発生します。
再試行が3回なら計6回以上。
月間の利用コストを事前にシミュレーションしてから本番稼働させてください。

目安：GPT-4o（実行役）+ Claude 3.5 Sonnet（監視役）の組み合わせで
1,000字程度のコンテンツ1件あたり概算2〜5円前後（2026年現在の料金水準）。

落とし穴③：ループの終了条件を両ワークフローに設定しないと止まらない

第5回で解説した`max_retry`変数は、
Dify AとDify B両方に設定が必要です。
Dify Aにしか設定していない場合、
Dify B起点でのループが暴走することがあります。
“`
# 両ワークフロー共通の終了条件

retry_count >= max_retry（推奨値：3）
→ 強制的にループを脱出し、「要人間確認」フラグを立てる
“`

第6章：マルチエージェント化で「あなたの仕事」が変わる

関わり方の変化

このアーキテクチャが完成したとき、
あなたがシステムに対してやることは1つだけです。
“`
テーマと要件を入力する（5分）
　　　　　↓
AIチームが自律的に動く
　　　　　↓
合格品だけを受け取る（最終確認：10分）
“`

浮いた時間で何をするか。
それを考え、設計することが
「AIとの共生」における、あなた本来の仕事です。

「構造で勝つ」という経営視点

あなたがこのシステムに対してすべき仕事は、
一緒に走ることではなく、適切な役割に適切なAIを配置することです。

「品質基準をどう定義するか」
「監視役のチェック項目をどう設計するか」

この設計の精度を上げるほど、
AIチームのアウトプット品質は自動的に上がります。
これが、労働集約型から構造集約型への移行です。

まとめ｜2つのDifyを連携させることで、品質は「設計」になる

今回の実装を振り返ります。

1. シングルエージェントの限界は「同じ思考回路での自己評価」
2. Dify A（実行役）は生成に集中し、出力をAPIで監視役へ送る
3. Dify B（監視役）は第三者として審査し、フィードバックを返す
4. 異なるモデルを使うことで、盲点を相互にカバーする
5. 落とし穴3点（タイムアウト・コスト・ループ終了条件）に事前対処する

品質は「努力」ではなく「構造」で担保する。
このパラダイムシフトが、あなたの自由時間を作り出します。

今すぐできるアクション

“`
✅ Step 1：既存ワークフロー（Dify A）から評価ノードを削除する
✅ Step 2：新規ワークフロー（Dify B）を作成し、監視役プロンプトを設定する
✅ Step 3：Dify AにHTTPリクエストノードを追加し、Dify BのAPIを呼び出す
✅ Step 4：Dify BのコードノードでSCORE・PASS・FEEDBACKをパースする
✅ Step 5：不合格時にDify BからDify Aへフィードバックを返す配線を完成させる
✅ Step 6：両ワークフローにmax_retry = 3 を設定する
“`

今日は Step 1とStep 2だけ完了させてください。
Dify Bに監視役プロンプトを貼り付けるだけで、
全体像が一気に見えてきます。

次回予告：シリーズ最終回「AIは道具から同僚へ」

第1回から第6回まで、私たちは
タスク分解・自動実行・採点・再試行・チーム化という
5つのレイヤーを積み上げてきました。

最終回では、これら全てを統合した
「24時間自走するエージェントシステムの全体像」を俯瞰します。

そして、その先にある問いに向き合います。

「AIが全てを動かすとき、あなたは何者であるべきか」

→ 【最終回】を読む：AIは「道具」から「同僚」へ。
自律エージェントが描き出す、24時間無人収益化の全貌

シリーズ第1回から読み直すことで、
今回構築したマルチエージェントの全体設計がより深く理解できます。

▼ 関連記事はこちら

【AI自律エージェント・第6回】「実行役」と「監視役」。2つのDifyを連携させてミスをゼロにする運用術

「1つのAIに全部やらせる」ことの、本当のコスト

この記事を読むとわかること