ほとんどの AI エンジニアはエージェントの作り方を知っています。
しかし、初回以降で改善されるシステムを構築する方法を知っている人は非常に少ないです。
その差は 6 桁の価値があります。
違いはこれです:
エージェントはワーカーです。
ループがワーカーを改善させます。
現在本番環境で稼働する最も高性能な AI システムは、単一のモデル呼び出しではありません。
それらはループです。
生成 → 評価 → 学習 → 改善。
何度も繰り返します。
出力が実際に良くなるまで。
本番 AI システムで繰り返し登場する 20 のループデザインパターンを紹介します。
保存しておいてください。これらを使って構築することになります。
エージェント vs ループ
旧来の方法:プロンプト → 応答 → 完了。
新しい方法:生成 → 批評 → 書き直し → スコアリング → 再試行 → 記憶 → 改善。
一方は仕事を一度だけ行う工場労働者です。
もう一方は、すべてのミスを研究し、マニュアルを書き直し、毎シフト 3% ずつ良くなる工場労働者です。
現在本番 AI をリリースしているチームは、より良いプロンプトを書いているのではありません。
より良いループを構築しているのです。

カテゴリー 1 — 品質改善ループ (出力がシステムから出る前に品質を良くする)
1. 生成 → 批評 → 書き直し
AI エンジニアリングにおける最も重要なループです。
出力を生成する。批評家がレビューする。生成者がフィードバックに基づいて書き直す。品質基準に達するまで繰り返します。
1 つのモデルではありません。2 つの役割です。1 つのパイプラインです。
1[生成者] → ドラフト2[批評家] → 「パラグラフ 3 が曖昧。エビデンス不足。トーンが合っていない。」3[生成者] → 批評に基づいて書き直し4[批評家] → 「改善された。しかし結論はまだ弱い。」5[生成者] → 最終書き直し
使用場面:ライティング、コードレビュー、レポート、戦略文書、営業メール。
洞察:生成するモデルは、自身の出力を最善に判断できるわけではありません。
独立した批評家は、生成者が毎回見逃すものを発見します。

2. スコアアンドリトライループ
生成する。スコアを付ける。しきい値を下回れば再試行する。
シンプルです。強力です。過小評価されています。
1score = evaluate(output)23while score < threshold:4 output = generate(prompt)5 score = evaluate(output)6 attempts += 17 if attempts > max_retries:8 return best_so_far
品質が測定可能な場合に最適です — 抽出精度、フォーマット準拠、事実正確性、リードスコアリングなど。
生成者は自分が評価されていることを知りません。
評価者は知っています。
その分離こそがパターンです。
3. マルチクリティックループ
1 人の批評家には見落としがあります。
4 人使いましょう。
→ 正確性批評家:事実に基づいて正確ですか?
→ スタイル批評家:明確でよく書かれていますか?
→ 安全性批評家:適切で安全ですか?
→ ドメイン批評家:専門家の基準を満たしていますか?
それぞれが独立して評価します。
最終出力は、すべての基準を満たして初めてシステムから出ます。
使用場面:医療 AI、法律文書レビュー、財務分析、規制コンテンツ。

4. 敵対的批評ループ
批評家の唯一の仕事は、回答を「壊す」ことです。
改善することではありません。壊すことです。
敵対的批評家が問う質問:
→ ここでどの前提が崩れるか? → どのエビデンスが不足しているか? → 懐疑論者は何と言うか? → これは自信満々だが間違っている箇所はどこか?
生成者はそれを防御するか、書き直します。
最良の回答は攻撃を生き残ります。
使用場面:研究統合、投資テーゼレビュー、戦略計画、リスク分析。
5. ジャッジアンサンブルループ
1 人の判定者はノイズの多いスコアを出します。
5 人の判定者がノイズを平均化します。
同じ出力を複数の評価者にかけます。
スコアを集約します。
高いコンセンサスが得られた出力のみが次に進みます。
使用場面:単一モデルの評価が信頼できない場合、リスクが高い場合、エッジケースが重要な場合。

カテゴリー 2 — メモリーループ (発生したことから学び、次回はより賢くなる)
6. リフレクションループ
存在する最も重要な自己改善パターンです。
エージェントが失敗する。エージェントが失敗理由を分析する。エージェントが教訓を保存する。エージェントがその教訓を文脈として再試行する。
各イテレーション:前回より賢くなります。
1試行 1: 失敗2反省: 「X を前提としていたが、X は間違っていた。次回は最初に X を確認する。」3試行 2: 教訓を組み込む → 部分成功4反省: 「改善された。しかし Y を飛ばした。Y のチェックを追加する。」5試行 3: 成功
一度失敗するシステムと、一度だけ失敗するシステムの違いです。

7. メモリー更新ループ
タスクのたびに、3 つを保存します:
→ どのような決定が下されたか → 結果はどうだったか → 何を異なる方法で行うか
将来の実行はこの知識を引き継ぎます。
6 ヶ月目のシステムは、1 ヶ月目のシステムと同じではありません。
自身の履歴を 6 ヶ月分読み取っています。
8. エラーライブラリループ
すべての失敗を保存します。
間違った回答。悪い出力。実行失敗。エッジケース。
新しいタスクに取り組む前に:
まずエラーライブラリを検索します。
類似の失敗が存在する場合 → 開始する前から既知の修正を適用します。
システムは同じミスを二度繰り返さなくなります。
本番 AI で最も過小評価されているパターンです。
9. 成功パターンループ
ほとんどのエンジニアは失敗のみを保存します。
成功も保存しましょう。
タスクがうまくいった場合:
→ アプローチを保存する → コンテキストを保存する → 何がうまくいったのかを保存する
類似のタスクに直面したとき、成功パターンを検索します。
間違いからだけでなく、成功からも学びます。
10. メモリー圧縮ループ
メモリーは永遠に増え続けます。
無制限のメモリーは使い物になりません。
N 個のアイテムが蓄積された後:
それらを圧縮します。
多くの具体的な記憶 → 少数の高レベルの抽象化へ。
1圧縮前:2「タスク A で X が原因で失敗」3「タスク B で X が原因で失敗」4「タスク C で X が原因で失敗」56圧縮後:7「パターン:X は失敗を引き起こす。常に最初に X を確認せよ。」
コンテキストは管理可能に保たれます。パターンはアクセス可能に保たれます。システムは高速に保たれます。

カテゴリー 3 — 計画ループ (現実が変化したときに計画を適応させる)
11. 計画 → 実行 → 再計画
AI エージェント設計で最もよくある間違い:
計画を固定されたものとして扱うこと。
計画は現実に触れると破綻します。
パターン:
計画を作成 → ステップを実行 → 結果を観察 → 計画を更新 → 続行
ウォーターフォールではありません。
スパイラルです。
周回するたびにアプローチが洗練されます。
使用場面:環境が変化する場合、タスクに依存関係がある場合、長期的な目標がある場合。

12. 動的ワークフローループ
ほとんどのパイプラインは固定されています。
ステップ 1 → ステップ 2 → ステップ 3。常に。
動的ワークフローは結果に基づいて変化します。
出力 A の場合 → ブランチ X を実行 出力 B の場合 → ブランチ Y を実行 出力 C の場合 → ステップ 5 にスキップ
パイプラインは実行時に自身の形状を決定します。
使用場面:複数ドキュメントのリサーチ、カスタマーサポートのルーティング、アダプティブコンテンツパイプライン。
13. 目標分解ループ
大きな目標が入力されます。
システムはそれをサブゴールに分解します。
各サブゴールはタスクに分解されます。
各タスクはステップに分解されます。
各ユニットが 1 回の呼び出しで実行可能なほど小さくなるまで分解します。
1目標:「包括的な競合分析を書く」2↓3サブゴール 1: 「トップ 5 の競合を特定する」4サブゴール 2: 「各競合の製品を分析する」5サブゴール 3: 「価格モデルを比較する」6サブゴール 4: 「ギャップを特定する」7↓8各サブゴール → タスク → 個別のモデル呼び出し
システムが行動できるまで、ループは分解を続けます。
14. 進捗評価ループ
N ステップごとに:停止して問いかけます。
「私たちは実際に目標に近づいているか?」
はいの場合:現在の戦略を続行。いいえの場合:戦略、ツール、または計画を変更。
システムは自身の進捗を監視します。
盲目的に実行するだけではありません。
使用場面:長時間実行されるリサーチエージェント、複数日にわたる自律タスク、デバッグエージェント。
15. 制約充足ループ
すべての制約が満たされるまで実行を続けます。
1while not all_constraints_satisfied(output):2 output = improve(output, unsatisfied_constraints)34constraints = [5 budget_under_limit,6 quality_above_threshold,7 latency_under_200ms,8 tone_matches_brand,9 no_hallucinations10]
本番システムでは非常に一般的です。
すべてのビジネスルールに合格するまで、出力は完了しません。

カテゴリー 4 — 探索ループ (複数のパスを試して最良の答えを見つける)
16. 分岐探索ループ
1 つのパスにコミットしないでください。
複数を同時に探索します。
1paths = [2 generate(approach="conservative"),3 generate(approach="aggressive"),4 generate(approach="creative")5]67scores = [evaluate(p) for p in paths]8best = paths[scores.index(max(scores))]
結果を比較します。最良のブランチを選択します。残りは破棄します。
使用場面:コンテンツバリエーション、アーキテクチャ決定、複数の仮説のデバッグ、A/B 生成。

17. ツリーサーチループ
分岐探索は 1 レベルの深さです。
ツリーサーチは必要なだけ深く進みます。
最も有望なノードを展開します。最も弱いノードを刈り込みます。解決策が見つかるまで探索を続けます。
1root → [A, B, C]2A → [A1, A2] # A は有望に見えるので展開3B → prune # B は弱いのでここで停止4A1 → [A1a, A1b]5A1a → solution ✓
使用場面:複雑な推論チェーン、マルチステップ計画、コードデバッグ、研究統合。
計算コストは高いですが、単一パスの呼び出しでは見つけられない解決策を見つけます。
18. ディベートループ
2 つのエージェント。1 つのトピック。反対の立場。
エージェント A は回答に賛成論を展開します。エージェント B はそれに反対論を展開します。
各ラウンドで前提に挑戦し、証拠を要求し、弱い論理を暴露します。
最終的な答えは、合意によってではなく、見解の相違を通じて現れます。
敵対的な圧力は、自信過剰な単一エージェントの回答が見逃すものを発見します。
使用場面:投資判断、戦略計画、リスク評価、研究批評。

カテゴリー 5 — システム最適化ループ (ループがループを改善する)
19. プロンプト最適化ループ
ほとんどのエンジニアはプロンプトを一度書いて、二度と触りません。
プロンプト最適化ループはそれを変えます。
システム:
→ テストセットでプロンプトを実行
→ すべての出力をスコアリング
→ プロンプトが失敗する箇所を特定
→ それらの失敗を修正するためにプロンプトを書き直す → 再実行して再スコアリング
プロンプトは自動的に改善されます。
人間が触れることなく。
1current_prompt = "このドキュメントを要約してください。"23for iteration in range(max_iterations):4 outputs = [run(current_prompt, doc) for doc in test_set]5 scores = [evaluate(o) for o in outputs]6 avg_score = mean(scores)78 if avg_score >= target:9 break1011 failures = [o for o, s in zip(outputs, scores) if s < threshold]12 current_prompt = improve_prompt(current_prompt, failures)13 # プロンプトは失敗する箇所に基づいて自身を書き直す
使用場面:本番パイプライン、自動コンテンツシステム、分類タスク。
本番 AI における最良のプロンプトは、人間によって書かれたものではありません。
それらは進化したものです。

20. ワークフロー最適化ループ
ここからが面白くなります。
ループがループを改善します。
システムは自身のパフォーマンスを測定します:
→ レイテンシ:各ステップにかかる時間は?
→ コスト:各呼び出しで使用されるトークン数は?
→ 品質:各段階での出力スコアは?
そして、自身のワークフローを変更します。
遅すぎる? 2 つのステップを並列化。高すぎる? 品質が維持される場所で GPT-4 の呼び出しをより小さなモデルに置き換え。品質が低下している? 最終出力の前に批評家を追加。
1metrics = measure_workflow(outputs, latency, cost)23if metrics.latency > target_latency:4 workflow = parallelize(slow_steps)56if metrics.cost > budget:7 workflow = replace_with_cheaper_model(high_cost_steps)89if metrics.quality < threshold:10 workflow = add_critic_before(final_output_step)
ここから真に自己改善するシステムが始まります。
改善されるのは出力だけではありません。
自身を再設計するシステムです。

20 のパターンすべてに共通するパターン
上記のすべてのループは、1 つの構造を共有しています:
行動 → 観察 → 評価 → 調整
これがすべてのレシピです。
出力は最初の試行で決して最終版ではありません。
出力は出発点です。
ループこそが、出発点を本番に耐えうるものに変えるものです。

全体マップ
カテゴリー 1 — 品質ループ (出力がシステムから出る前に品質を良くする)
→ 1. 生成 → 批評 → 書き直し
→ 2. スコアアンドリトライ
→ 3. マルチクリティック
→ 4. 敵対的批評
→ 5. ジャッジアンサンブル
カテゴリー 2 — メモリーループ (発生したことから学ぶ)
→ 6. リフレクション
→ 7. メモリー更新
→ 8. エラーライブラリ
→ 9. 成功パターン
→ 10. メモリー圧縮
カテゴリー 3 — 計画ループ (現実が変化したときに適応する)
→ 11. 計画 → 実行 → 再計画
→ 12. 動的ワークフロー
→ 13. 目標分解
→ 14. 進捗評価
→ 15. 制約充足
カテゴリー 4 — 探索ループ (複数のパスを試して最良の答えを見つける)
→ 16. 分岐探索
→ 17. ツリーサーチ
→ 18. ディベート
カテゴリー 5 — システム最適化ループ (ループがループを改善する)
→ 19. プロンプト最適化
→ 20. ワークフロー最適化
ほとんどのエンジニアはエージェントが未来だと考えています。
エージェントは単なるワーカーです。
ループこそがワーカーを改善させます。
現在 AI で起こっている最大のシフトは、より良いモデルではありません。
それは、以下からの移行です:
プロンプト → 応答
から
生成 → 評価 → 学習 → 改善
へ
ループ設計を習得したチームは、より良いプロンプトを構築するのではありません。
彼らは、デプロイ後に毎日改善され続けるシステムを構築するでしょう。
誰も触れることなく。
これが役に立ったなら:
→ リポストして、知っているすべての AI エンジニアと共有してください
→ このようなパターンをもっと知りたい方は、@sairahul1 をフォローしてください
→ ブックマークして、1 つのループを選び、今週中に実装してください
私は AI、プロダクト構築、そしてあなたなしで機能するシステムについて書いています。





