【AI自律エージェント・第5回】合格するまでやり直せ。条件分岐（IF）で実装する「再試行」の自動化

あなたはまだ、AIの「不合格品」を手直ししていませんか？

こんばんは、斎藤です。

AIにブログ記事を書かせた。

でも出てきたのは、どこか薄い、当たり障りのない文章。

「まあ、こんなものか」と諦めて、 自分で30分かけて肉付けしていませんか？

あるいは第4回で導入した「採点ノード」が 「スコア：42点」を叩き出したとき、

結局、自分の手でリライトしていませんか？

それはAIを「道具」として使っている状態です。

まだ「自律エージェント」になっていません。

2026年における本当の自動化とは、こういう意味です。

「AIが自分で採点し、自分でやり直し、 > 合格点を取ってから、初めてあなたに渡してくる」

この記事では、それを実現するDifyの条件分岐（IF）と再試行ループを設定画面の操作レベルで実況中継します。

読み終わったら、そのままDifyを開いて実装できます。

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

まだ第4回（採点ノードの構築）を読んでいない方は

先にそちらをご確認ください。

→【第4回】AIの回答を数値化する「採点者ノード」の作り方

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

– Difyで「IF条件分岐」を設置する具体的な手順

– スコアが基準を下回ったとき、自動でやり直しをかける「ループ配線」の方法

– 無限ループを防ぐ「ガードレール変数」の設定

– 2回目以降の精度を幾何級数的に上げる「自己修正プロンプト」の書き方

第1章：「失敗」を次の成功へのトリガーに変える発想の転換

結論：AIの「一発勝負」は、あなたの時間を消費し続ける

ほとんどの人が、AIを次のように使っています。

“`

指示を出す → AIが出力する → 気に入らなければ自分で直す

“`

このフローの問題点は一つ。

「自分で直す」という工程が、永遠に残り続けることです。

AIを導入しても、最終的には人間の手が入る。

これでは本質的な自動化とは言えません。

なぜ「ループ設計」が必要なのか

人間が仕事をするとき、一発で完璧な成果物を出すことはほぼありません。

書いては読み返し、直しては見直す。

この反復こそが品質を作ります。

AIも同じです。

違うのは、AIは何度やり直しても疲れないし、文句も言わないこと。

「10回書き直せ」と命じても、AIには精神的コストがゼロです。

その特性を活かさない手はありません。

|                              | 人間によるリライト            | ループ設計されたAI   |
|———————–|——————————-|————————|
| 1回の修正コスト      | 20〜60分                          | 30秒〜2分                |
| 精神的消耗              | あり（疲弊、妥協が生じる） | なし                        |
| 深夜・休日の稼働     | 不可                                 | 可                           |
| 修正履歴の管理        | 手動                                 | 自動（変数で管理）   |
| 品質の安定性           | 個人差・体調に左右される   | 基準値以上を保証       |

あなたがすべき仕事は、 「何点を合格とするか」という基準の設計だけです。

あとはAIに任せましょう。

 第2章：【実装手順】DifyでIF条件分岐と再試行ループを組む

💻 前提環境

– Dify（クラウド版 or セルフホスト版、どちらでも可）

– 第4回で構築した「評価ノード」が存在すること

– 評価ノードの出力変数名：`evaluation_score`（数値型）

Step 1：IF条件ノードを評価ノードの直後に設置する

評価ノードの右側に、新しいノードを追加します。

ノードの種類から「IF/ELSE」を選択してください。

設定画面で、以下の条件式を入力します。

“`

{{evaluation_score}} >= 80

“`

これで、フローは2つに分岐します。

– True（80点以上） → 次の工程へ進む（出力・保存など）

– False（79点以下） → 「やり直し」ルートへ

Step 2：Falseルートを「実行ノード」の入力側へ戻す

ここが再試行ループの核心部分です。

FalseルートのノードからドラッグしてAllow、

最初の「実行ノード（コンテンツ生成）」の入力端子に矢印を戻します。

“`

[開始] → [実行ノード] → [評価ノード] → [IF分岐]

↑

| |____________[False]____________|

| [True]

↓

[次の工程]

“`

この配線で、スコアが80点を下回るたびに 自動的に最初からやり直しが始まります。

Step 3：「なぜ落ちたか」を次の試行にフィードバックする

ここで多くの人が見落とす重要なポイントがあります。

ただループさせるだけでは、2回目も同じ失敗をします。 評価ノードには「スコア」だけでなく「改善点テキスト」も
出力させておく必要があります（第4回参照）。
実行ノードのプロンプトを次のように修正してください。
“`
あなたは優秀なコンテンツライターです。
以下の条件でブログ記事を執筆してください。
【テーマ】{{topic}}
{% if retry_count > 0 %}
【前回の評価と改善指示】
前回のスコア：{{evaluation_score}}点
改善すべき点：{{improvement_feedback}}
上記の指摘を必ず反映した上で、より高品質な記事を書いてください。
{% endif %}
“`
`retry_count`（後述）が0のとき（初回）は改善指示が表示されず、
1以上のとき（やり直し時）だけフィードバックが自動で差し込まれます。
これがSelf-Correction（自己修正）の核心です。
2回目以降、AIは「なぜ失敗したか」を知った上で書き直すため、
精度が急速に改善します。

Step 4：無限ループを防ぐ「ガードレール」を設定する

⚠️ ここを飛ばすと、ワークフローが永遠に終わらない可能性があります。
Difyの変数設定で、以下の変数を追加してください。
| 変数名 | 型 | 初期値 | 説明 |
|——–|—–|——–|——|
| `retry_count` | Number | 0 | やり直し回数のカウンター |
| `max_retry` | Number | 3 | 最大やり直し回数 |
実行ノードの先頭に「カウンター更新ノード」を追加し、
以下の処理を入れます。
“`
retry_count = retry_count + 1
“`
IF条件ノードに、もう一つ条件を追加します。
“`
{{evaluation_score}} >= 80 OR {{retry_count}} >= {{max_retry}}
“`
これにより、「80点以上取れた場合」か
「3回やり直しても取れなかった場合」のどちらかで、
ループを脱出できます。
3回限界に達した場合は、別途アラートノードを挟み、
「要人間確認フラグ」を立てるとより実践的です。

【落とし穴レポート】実際に設定してみてわかったこと

実装の過程で、次の3つの問題によくぶつかります。
落とし穴①：評価ノードの出力が文字列になっている
`evaluation_score`が数値型ではなく文字列型で出力されると、
`>= 80`という比較が正しく動作しません。
評価ノードのプロンプトで「必ず整数のみで出力すること」と
明示指定してください。
落とし穴②：ループ時に変数が初期化されない
Difyのバージョンによっては、ループ時に前回の
`improvement_feedback`が引き継がれないことがあります。
変数の「スコープ設定」を確認し、
ワークフロー全体で共有されるよう設定してください。
落とし穴③：フィードバックが毎回同じ内容になる
評価プロンプトが固定的すぎると、毎回同じ改善点しか
出力されません。
「前回の出力と今回の出力の差分を踏まえて評価すること」
という一文を評価プロンプトに追加するだけで
フィードバックの質が大きく変わります。

第3章：「品質保証の仕組み」が、長期的な資産になる理由

SEOとコンテンツ品質の関係（2026年版）

Googleは2026年現在、コンテンツ評価の軸として
「その情報が読者の問いに完全に答えているか」を重視しています。
AIが生成したかどうかは問題ではありません。
「読んだ人が満足したか」が全てです。
ループで3回自己修正された記事と、
一発書きで済ませた記事では、
網羅性・具体性・論理の整合性に明確な差が生まれます。
自律エージェントが「合格点を取るまで終わらない」設計で 生み出したコンテンツは、
検索エンジンにとっても「無視できない答え」になります。

あなたの時間が変わる

このループを一度組んでしまえば、
あなたがすることは「テーマを入力する」だけです。
“`
あなたの1日の変化（例）
Before：
– テーマを考える（30分）
– AIに書かせる（5分）
– 出力を読んで修正する（1時間）
– 再修正・校正（30分）
合計：約2時間
After（ループ実装後）：
– テーマを入力する（5分）
– コーヒーを飲む（15分）
– 完成品を受け取って最終確認する（10分）
合計：約30分
“`
浮いた1時間30分で何をするか。
それを考えることこそが、
「AIとの共生」における本当の仕事です。

まとめ｜「合格するまで終わらせない」を仕組みにする

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

1. IF条件ノードで「80点以上か否か」を分岐させる

2. Falseルートを実行ノードに戻すことでループを形成する

3. フィードバック変数を次の試行に差し込み、自己修正を実現する

4. ガードレール（max_retry）で暴走を防ぐ

5. 落とし穴3点（型エラー・変数スコープ・フィードバック固定化）に注意する

今すぐできるアクション

“`
✅ Step 1：Difyを開き、評価ノードの直後にIF/ELSEノードを追加する
✅ Step 2：条件式「{{evaluation_score}} >= 80」を入力する
✅ Step 3：Falseルートの矢印を実行ノードの入力側へ戻す
✅ Step 4：retry_count変数を追加し、max_retry = 3 を設定する
✅ Step 5：実行ノードのプロンプトにフィードバック変数を差し込む
“`
一つひとつは難しくありません。
今日中に Step 2 まで完了させることを目標にしてください。

次回予告：第6回「AIチームを組織する」

シングルエージェントには限界があります。
次回は、「実行役」と「監視役」を分けた2つのDifyを連携させる
マルチエージェント構成を解説します。
– 実行ノードは出力に集中する
– 監視ノードはミスの検出と報告に専念する
– この分業で、ループだけでは防げないエラーをゼロに近づける
構造的にミスを排除する「AIチーム運営」の全手順を
次回は実況中継します。
→ 【第6回】を読む：実行役と監視役。2つのDifyでミスをゼロにする運用術（公開後リンク追加）

この記事がお役に立てたなら、シリーズの他の記事もぜひご覧ください。
第1回から順を追って読むことで、自律エージェントの全体像が掴めます。