AI をカジュアルに使う人と、実際にシステムとして運用する人を分ける、ある特定の瞬間があります。
それは、自分が間違いを発見する側でなくなる瞬間です。
今のほとんどの人にとって、そのループは次のようになっています。Claude に何かを依頼する。出力を読む。何かがおかしいことに気づく。それを指摘する。修正版を得る。それを読む。また別の何かに気づく。また指摘する。毎回、毎タスク、手動で検証レイヤーになっているのです。
自己修正ループは、あなたをその立場から完全に解放します。システムが生成し、実際の基準に照らして自身の成果をチェックし、間違いを発見し、修正し、そして初めて結果を表示します。あなたが出力を見る頃には、明らかな間違いはすでに発見・処理されています。あなたに残されるのは、本当に人間の判断が必要なことへの評価であり、機械の初稿の校正ではありません。
これが完全な構築です。この記事を読み終える頃には、正確なアーキテクチャ、正確なプロンプト、そして重要なものにこれを委ねる前にテストすべき正確な障害モードを手に入れているでしょう。
なぜこれは単に二回聞くのと同じではないのか
最初に思いつくのは、同じ会話の中でモデルに自身の成果をチェックさせることです。「今書いたものを見直して、間違いを修正して。」これには少し効果があります。しかし、真の自己修正ループにはなりません。その理由を理解することが、この後のすべての基礎となります。
モデルが同じコンテキスト内で、間違いを生み出したのと同じ推論を使って自身の出力をレビューすると、真に精査するのではなく、自身の成果を擁護する傾向があります。これは特定のモデルだけの欠陥ではありません。構造的な問題です。もっともらしく聞こえるが間違っている答えを生成した同じパスは、それが間違っていることに気づくのに適した立場にありません。なぜなら、内部から見ると、その答えはまだもっともらしく聞こえるからです。「本当ですか？」と尋ねると、真の再検証よりもむしろ安心させられることが多いのです。
解決策は、より良い質問をすることではありません。アーキテクチャです。真の自己修正ループは、答えを生成する作業とそれを判断する作業を分離し、異なるパス、異なるプロンプト、理想的にはまったく異なる参照枠を用いることで、判断が間違いを生み出したのと同じ盲点に汚染されないようにします。
自己修正ループに必要な三つの役割
機能する自己修正システムは、特定のタスクに関係なく、すべてが三つの明確な役割に還元されます。これらの役割を明確に理解することは、以下に示す特定のプロンプトよりも重要です。なぜなら、これらを理解すれば、具体的な内容を埋めることで、ほぼすべてのタスクに対してループを構築できるからです。
ビルダー。 実際の出力を生成します。コードを書き、コンテンツを起草し、リサーチを行い、タスクを実行します。この役割には最も創造的な自由度と最も少ない制約を与えるべきです。なぜなら、その仕事は完全なものではなく、最初の試みを生成することだからです。
ジャッジ。 何も構築しません。その唯一の仕事は、漠然とした品質感覚ではなく、特定の書面による基準に対してビルダーの出力を評価することです。コードはテストに合格するか。草稿は指示に適合するか。リサーチは実際に求められた質問に答えているか。ジャッジは理想的には、ビルダーが持っていないもの、つまり原本のソース資料、テストスイート、実際の要件文書にアクセスできるべきです。これにより、同じ出力を再読して新たな意見を形成するのではなく、独立したグラウンドトゥルースをチェックできるようになります。
マネージャー。 ジャッジの判定を読み、次に何が起こるかを決定します。具体的なフィードバックを添えてビルダーに戻す。人間にエスカレーションする。タスクを完了としてマークする。ここには停止条件も存在します。これは、何かが実際に自動修正できない場合にループが永遠に実行されるのを防ぐルールです。
三つの役割すべてにわたる重要な設計原則：検証はビルダー自身の推論の外部にあるものを参照する必要があります。テストスイート。原本のソース文書。書面によるチェックリスト。真に異なるフレーミングを持つ第二の AI 呼び出し。「同じモデルに、同じ流れで、もう一度尋ねる」以外のもの。
ハンドオフの構築
自己修正ループにおける実際のエンジニアリング作業は、各役割のための巧妙なプロンプトではありません。それはそれらの間で受け渡されるものの構造であり、これが最初のループを構築するほとんどの人が完全にスキップし、その後なぜシステムが予測不能に動作するのか不思議に思う部分です。
ハンドオフが確実に機能するには、三つの特性が必要です。定義されたフォーマット。受け取る役割が、緩い散文を解析して何が重要かを推測する必要がないように。定義されたトリガー。ビルダー自身がいつ完了したかを決定しないように。そして定義された失敗パス。何かがうまくいかなかった場合に、システムが黙って壊れたり永遠にループしたりするのではなく、指定された次のステップがあるように。
実際には、これはビルダーが単なる会話テキストではなく、構造化されたものを出力する必要があることを意味します。明確な成果物と、それについて不確かな点の明示的な声明。ジャッジは、その構造化された出力を書面による基準に対して評価し、自身の構造化された判定を返します。曖昧な散文の段落ではなく、明確な合格、不合格、または修正必要、と具体的な理由を添えて。マネージャーは、その構造化された判定を読み、生のコンテンツではなく、事前に確立されたルールに基づいて次のアクションを決定します。その場で即興で判断するのではありません。
以下は、執筆、コード、リサーチなど、ほとんどのタスクで機能するテンプレート構造です。
1ビルダー出力フォーマット2成果物: [実際の出力]3確信度: [高 / 中 / 低]4既知の不確実性: [不確かな点があれば明示的に記載]5行った仮定: [指示されずに仮定したこと]67ジャッジ判定フォーマット8判定: [PASS / FAIL / NEEDS REVISION]9チェック基準: [使用した具体的な基準、例: 原本の指示、テストスイート、ソース文書]10特定された問題: [具体的な問題、一般的な印象ではない]11この判定の確信度: [高 / 中 / 低]1213マネージャーアクション14PASS の場合: 完了としてマークし、ユーザーに届ける。15FAIL または NEEDS REVISION の場合: ジャッジの具体的な問題を添付してビルダーに戻す。修正カウンターを増やす。16修正カウンターが [N] を超えた場合: ループを停止し、試行した内容と失敗理由の完全な履歴を添えて人間にエスカレーションする。
これは、カジュアルな往復会話よりも多くの構造に見えます。そして実際にそうです。この upfront のコストが、コンテキストが蓄積されるにつれて予測不能に漂流するのではなく、初回と同じように百回目の実行でも同じように動作するシステムを手に入れるための代償です。
ジャッジには意見ではなく、グラウンドトゥルースが必要
これはシステム全体で最も重要な原則であり、これを間違えると他のすべてが静かに損なわれるため、独立したセクションを設ける価値があります。
ビルダーの出力のみを見て、チェックするための独立した参照がないジャッジは、内部の整合性、つまり出力が首尾一貫して適切にフォーマットされているかどうかしか評価できません。正しさ、つまり出力が実際に求められたものと一致しているか、実際の問題を解決しているかは評価できません。自信過剰で間違った答えは、適切にフォーマットされ内部で一貫していれば、グラウンドトゥルースのないジャッジを毎回すり抜けます。
コーディングタスクの場合、グラウンドトゥルースはテストスイート、コードを実行した実際の出力、リンター結果、ビルドステータスです。「このコードは正しく見えるか」ではなく、「実行時に実際に合格したか」です。
コンテンツタスクの場合、グラウンドトゥルースは原本のソース資料と原本の指示であり、草稿と並べて比較します。「読みやすいか」ではなく、「草稿内のすべての具体的な主張がソース内の実際のものに遡れるか、そして作品が指示のすべての要件を満たしているか」です。
リサーチタスクの場合、グラウンドトゥルースはリサーチの基礎となるはずだった実際の検索結果とソース文書です。「この要約は権威あるように聞こえるか」ではなく、「すべての主張が特定のソースに遡れるか、そして検索されたソースが実際に関連するものだったか」です。
特定のタスクに対するジャッジのグラウンドトゥルースが何であるかを明確にできないなら、まだ自己修正ループはできていません。言い換えループです。ビルダーの自信過剰な間違いが、実際に発見される代わりに、ジャッジによって自信過剰に言い換えられるだけです。
停止条件はオプションではない
自己修正ループが高価で制御不能な混乱になる最も一般的な原因は、明示的でハードな停止条件の欠如です。それがないと、ビルダーとジャッジは無限に循環し、各修正が別の評価を引き起こし、各評価が別の修正を引き起こし、コストが上昇し、請求書が届くまで誰も気づかない可能性があります。
本当の停止条件には三つの要素が必要であり、これらはすべてモデルのその場での判断に任せるのではなく、明示的なロジックとして強制されるべきです。
最大反復回数。修正サイクルのハードな上限。これを超えると、ジャッジがまだ満足していなくても、マネージャーは強制的に人間にエスカレーションする必要があります。
実際に測定可能な品質しきい値。願望ではありません。「十分に良い」というプロンプト内の指示は停止条件ではありません。それは、適切な圧力の下でモデルが無視できる提案だからです。特定の、チェック可能な基準。11 のテストケースすべてが合格する。または草稿が指示の 5 つの要件すべてを満たす。これは、毎回主観的に判断されるのではなく、機械的に検証できるため、停止条件です。
コストまたは時間の上限。タスクがその上限に達した時点で、どのような状態であっても絶対に超えてはならない予算です。これは、最悪のシナリオ、つまり真に解決不可能なタスクが誰かが請求書に気づくまでループし続けることから、特にあなたを守るガードレールです。
停止条件
最大修正回数: 3。3 回目の失敗判定で停止し、完全な修正履歴を添えて人間にエスカレーションする。4 回目のサイクルを自動的に試みない。
品質しきい値: ジャッジのチェックリストのすべての項目が PASS を示す必要がある。「ほぼ合格」や「十分近い」ではダメ。
予算上限: このタスクが [X] トークンまたは [Y] 分を消費した場合、現在の状態に関係なく即座に停止し、完了したものと残っているものを報告する。
これらをマネージャーの実際のロジックに書き込む。モデルが圧力の下で自分自身を説得できる長いプロンプト内のソフトな指示としてではない。
実例：自己修正コンテンツ制作
これを具体的にするために、三つの役割と停止条件が、実際の一般的なタスク、つまりソース文書を完成したコンテンツに変えるために、人間が毎回草稿を校正することなくどのように連携するかを正確に示します。
ビルダーはソース資料と指示を受け取り、草稿を生成します。その出力には草稿自体に加え、明示的な確信度ステートメントと、執筆中に不確かだった点のリスト、つまりソース内に完全には存在しないと確信していなかった特定の数字、直接述べられていないが推測した主張を含みます。
ジャッジは草稿と原本のソースを並べて受け取ります。決して草稿だけではありません。三つの特定の項目をチェックし、それぞれに合格または不合格を付けます。草稿内のすべての事実主張がソース内に実際に存在するものに遡れるか。草稿が指示のすべての特定の要件（長さ、トーン、必須セクション）を満たしているか。核となる議論またはフックが実際に存在し、フィラーで薄められていないか。ジャッジは、三つのチェックのそれぞれについて合格または不合格の構造化された判定を返します。これを一つの全体的なスコアにまとめると、どの次元で失敗したかが隠れてしまうからです。
マネージャーはその構造化された判定を読みます。三つすべてのクリアな合格は、草稿を最終出力キューに送ります。事実確認の次元での失敗は、具体的な未検証の主張を直接フラグ付けして、ビルダーに戻します。「正確性を確認してください」という曖昧な指示ではありません。指示遵守の失敗は、特定の欠落要件を指定して戻します。同じ特定のチェックで三回失敗した後、マネージャーはループを完全に停止し、試行された内容の完全な履歴を添えて人間にエスカレーションします。システムがすでに自力で解決できないことを示している問題を再試行し続けることはありません。
これは小さなシステムです。三つの役割、一つの構造化されたハンドオフフォーマット、一つの明示的な停止条件。また、無人で実行し、その出力を信頼できるシステムです。なぜなら、すべての障害モードに定義されたパスがあり、未定義のものがないからです。
信頼する前にループをテストする
実際に重要なことのために自己修正システムに依存する前に、これらの特定のストレステストを意図的に実行してください。実際の使用で失敗するほとんどのループは、誰かが事前にチェックしていれば、これらのテストのいずれかに即座に失敗していたはずです。
解決不可能なタスクテスト。 意図的にビルダーに、ジャッジの基準を満たせないタスクを与えます。マネージャーは正しく反復回数の上限に達して人間にエスカレーションしますか、それとも成功することが決してないタスクにコストを費やして無限に回転し続けますか。
自信過剰な間違いテスト。 ジャッジに、あなたがすでに微妙に間違っていると知っている出力を与えます。読みやすいが、特定の事実上または論理上の誤りを含むものです。ジャッジは、そのグラウンドトゥルース参照を使って、正しくそれを発見しますか。ジャッジが壊れていると知っているものを合格させた場合、グラウンドトゥルース参照が実際にチェックされていないか、チェックが浅すぎます。
同一モデルの盲点テスト。 ビルダーとジャッジが同じ基盤モデルで実行されている場合、これは直接チェックする価値があります。ジャッジに、そのモデルが特徴的に犯す種類の間違いを正確に含む出力を与えます。ジャッジがそれを通過させた場合、役割間で盲点を共有するループを構築したことになり、それらを分離する目的全体が無効になります。ジャッジの役割には、真に異なるモデル、または少なくとも意味のある異なるプロンプトフレーミングを使用することを検討してください。
コスト暴走テスト。 システムを通る最悪のパスを計算します。最大修正回数、最も高価なモデル呼び出し、最も長い合理的なコンテンツ長。そして、それが実際のドルと実際の時間でいくらになるかを計算します。その数字が実際の請求書に表示された場合に驚くようなものであれば、停止条件はまだ十分に厳しくありません。
実際のものに自己修正ループを委ねる前にこれら四つのテストを実行することで、そうでなければクライアント、上司、または自分の銀行口座の明細書の前で初めて現れるであろう失敗の大部分を発見できます。
優れた設計を静かに壊す一般的な間違い
正しい三役アーキテクチャがあっても、いくつかの特定の実装ミスが完全に異なるドメインにわたって繰り返し現れます。それらを事前に知っていれば、それぞれを苦労して再発見する手間が省けます。
ジャッジに独立した参照なしでビルダーの出力だけを見させる。 これは最も一般的な間違いであり、システムを正しさのチェックから首尾一貫性のチェックへと静かに変えてしまいます。比較するものがないジャッジは、出力が内部的に一貫しているように見えることしか教えてくれません。それが実際に正しいかどうかは決して教えてくれません。
すべての役割に同じモデルを与え、その上に薄い指示の違いだけを重ねる。 ジャッジがビルダーとまったく同じ基盤モデルを実行しており、ただ「批判的であれ」と指示する異なるプロンプトがあるだけの場合、ビルダーが持っているのとまったく同じ盲点を受け継ぐことがよくあります。なぜなら、それは根本的に同じ推論プロセスが異なる帽子をかぶっているだけだからです。予算が許す場合、ジャッジの役割に真に異なるモデルを使用することで、劇的な独立性ではなく、実際の独立性を生み出します。
マネージャーを単なるパススルーとして扱い、以前の試行の実際のメモリを与えない。 この特定のタスクで何がすでに試みられたかを可視化できないマネージャーは、同じ失敗したフィードバックを二度、三度とビルダーに喜んで送り返し、毎回同じ失敗した結果を生成します。なぜなら、システム内でこの正確なアプローチがすでに一度失敗したことを覚えているものがないからです。
みんなが注意深く見ていた一回のデモ実行でシステムがうまく機能したという理由で、四つのストレステストをスキップする。 あなたが注意深く見ているときに正しく動作するシステムと、無人で動作しているときに正しく動作するシステムは、異なる主張です。自己修正ループを構築する本来の目的は、後者だけです。障害モードを意図的にテストしていないなら、実際にどちらの主張があなたのシステムに当てはまるのかを知っているとは言えません。
停止条件をハードなロジックではなく、ソフトな指示として書く。 プロンプト内の「十分に良くなったら止める」は停止条件ではありません。それは提案であり、モデルは適切な圧力の下でそれを無視することができ、最終的には無視します。マネージャーが別のサイクルを許可する前に機械的にチェックするハードな反復カウンターは停止条件です。この二つの違いは、タスクが実際に解決不可能であることが判明した最初の時に非常に重要です。
第二の実例：自己修正コード
同じ骨格は、タスクがコンテンツではなくコードの場合、異なって見えますが、同一のロジックに従います。両方を並べて見ることで、ドメイン間で実際にどれだけ変化が少ないかが明確になります。
ここでのビルダーは、定義されたタスク（バグ修正、機能追加、リファクタリング）に取り組むコーディングエージェントです。その構造化された出力は、コードの差分だけでなく、実際に実行しようとしたコマンド出力、テスト結果、リンター出力、ビルドステータスをハンドオフにバンドルしたものです。コードを生成するが実際に実行しないビルダーは、ビルダーの役割を正しく果たしていません。なぜなら、構文的に可能なコードが自身のテストスイートに失敗する場合、完了していないのに完了しているように見えるため、コードがないよりも悪いからです。
ジャッジは三つの特定の検証可能な項目をチェックします。変更が既存のテストスイートに合格したか（テスト自体が変更されていないことを確認。ビルダーが静かにテストを編集して合格させるのは、特定の驚くほど一般的な失敗であり、直接チェックする価値があります）。静的解析とリンターがクリーンに戻ってきたか。差分が実際に割り当てられたタスクに対処しているか（ビルダーが途中で解決する方が面白いと判断した関連するが異なる問題ではない）。これらのそれぞれが、構造化された判定で独自の明示的な合格または不合格を取得します。
マネージャーは、どの特定のチェックが失敗したかに基づいてルーティングします。テストスイートの失敗は、正確な失敗したテスト出力を直接添付してビルダーに戻します。「テストを修正してください」という一般的な指示ではありません。スコープの不一致（差分が割り当てられたものとは異なる問題を解決した場合）は、ループせずに直ちに人間にエスカレーションします。なぜなら、それはタスクが実際に何であったかについての判断ミスであり、ビルダーが単独で反復して抜け出せる機械的な欠陥ではないからです。
ここでの基礎となる骨格、つまりビルダーが証拠とともに生成・提出し、ジャッジが特定の名前付き基準に対してチェックごとの判定でチェックし、マネージャーがどのチェックが失敗したかに基づいてルーティングする、という構造は、上記のコンテンツ制作の例と同一であることに注意してください。これが、二つの異なるドメインを並べて見ることから得られる実際の教訓です。骨格が正しければ、それを新しい種類のタスクに適用するのは、主にジャッジのための新しい具体的なチェックリストを作成することであり、毎回アーキテクチャ全体をゼロから設計し直すことではありません。
複数の同時ループへのスケーリング
単一の自己修正ループが真に信頼できるようになったら、次の実際の質問は、システムが管理不能になることなく複数のループを同時に実行する方法です。これは、ほとんどの人がこのスケーリングの第二の試みを間違えるまさにそのポイントです。
最初のループが機能した瞬間に、アーキテクチャが技術的にそれをサポートしているという理由だけで、多くのループを同時に立ち上げたくなる誘惑があります。必要以上にそれを抑えてください。追加の同時ループはそれぞれ、停止条件が静かに失敗する可能性のある別の場所、コストが気づかれずに暴走する可能性のある別の場所、ジャッジのグラウンドトゥルース参照が単一のテスト実行ではなく実際のボリュームでのみ現れる微妙な方法で間違っている可能性のある別の場所です。
より安全なスケーリングパスは、各ステップで真の信頼しきい値を持つ逐次拡大です。一つのループを、その出力を注意深くチェックしなくなったほど確実に実行できるようにします。これは、単一の成功したデモ実行ではなく、実際の期間にわたって一貫してあなた自身の手動スポットチェックに合格することを意味します。その場合にのみ、別のタスクのための第二のループを追加します。時間の経過とともに各ループの実際の失敗率を追跡します。たまたま観察した実行で機能したように見えたかどうかだけではありません。
複数のループを同時に実行する場合、すべてのループにわたる共有コストダッシュボードを真剣に検討してください。個別のトラッキングだけではありません。タスクごとの妥当な予算を持つ単一のループは、単独では完全に問題なく見えます。それぞれが予算内にある十のループでも、合計すると真に驚くべき総額になる可能性があり、各ループのトラッキングが単独では問題なく見えたため、誰も集計請求書が届くまで気づきません。
スケーリングの問題を発生する前に防ぐ単一の習慣：すべてのループのすべての停止条件トリガーを記録します。成功した完了だけでなく。最大反復回数に達して人間にエスカレーションするループは、まさにそれがすべきことをしているのです。しかし、特定のループが他のループがほとんどないのに常にその上限に達している場合、その特定のタスクに対するジャッジの基準が誤調整されている、実際に合格するには厳しすぎる、またはまったく間違ったグラウンドトゥルースに対してチェックしているというシグナルです。そのパターンは、成功のみを追跡し、すべてのエスカレーションを孤立した目立たないイベントとして扱い、その特定のループの設計に関するデータポイントとして扱わない場合、見えません。
今週どこから始めるか
最初の試みで完全に一般的な自己修正システムを構築しようとしないでください。すでに定期的に行っている、明確な基準があり、求められれば書き留められるような、一つの特定の、狭く、明確に定義されたタスクを選び、その単一のタスクの周りに三役ループを最初に構築してください。
ビルダーのプロンプトを一行も書く前に、ジャッジのチェックリストを明示的に書き留めてください。チェックする基準が、ビルダーに何を生成させるかを形作るべきであり、その逆ではありません。まだチェックリストを書けないなら、このタスクにとって「正しい」が何を意味するかを、チェックを自動化するのに十分に理解していないということです。そしてそれは、何かを構築する前に発見する価値があります。
実際に重要なことにループを委ねる前に、誰かの前で何かがすでに間違った後ではなく、上記の四つのストレステストを実行してください。最初のバージョンから停止条件を実際のハードなロジックとして追加してください。暴走ループで一度やけどを負った後の後付けとしてではなく。
一つのループが真に信頼でき、無人で実行され、実際の間違いを発見し、停止すべきときにきれいに停止するようになれば、二つ目ははるかに速くなります。プロンプトが直接転送されるからではなく（通常は新しいタスクのために書き直す必要があります）、問題の実際の形状をすでに理解しているからです。構築と判断を分離する。判断にチェックするための実際の何かを与える。停止条件を希望ではなくロジックとして書く。
その形状が全体の訓練です。他のすべては、それを目の前のタスクに適用するだけです。
この記事の背後にあるすべての正確なループテンプレートとビルダー・ジャッジ・マネージャーセットアップについては、@cyrilXBT をフォローしてください。
