自己修正ループとは？AIが自分でミスを見つけて直す仕組みをClaude Codeだけで作る方法

自己修正ループとは、AIが成果物を作ったあと、別の評価役が独立した基準で検査し、不合格なら該当箇所だけを直させて、合格条件を満たすまで改善を繰り返す仕組みです。 これを組むと、人間の仕事は「AIの成果物を全件チェックする」ことから「合格基準を設計し、例外だけを判断する」ことに変わります。この記事では、なぜ「見直して」と頼むだけでは品質が上がらないのかという原理から、Claude Codeの標準機能だけで自己修正ループを作る具体的な手順、暴走させないための停止条件までを解説します。

AIに任せた仕事、最後は全部人間が検品していないか

文章を書かせる、競合を調べさせる、資料を作らせる。生成AIは数分で成果物を返してきます。しかしそのあと、「この数字は合っているか」「前の資料と矛盾していないか」と人間が1件ずつ確認し、修正を指示していないでしょうか。

この体制のままAIの処理量だけを増やすと、ボトルネックは作業から確認に移るだけです。AIが100件の仕事を1時間でこなしても、人間が100件を検品するなら、全体の速度は人間の確認速度で頭打ちになります。

答えの方向はシンプルです。AIに「作る役」だけでなく、「ミスを見つける役」と「見つけたミスを直す仕組み」まで持たせます。

この仕組みは思いつきの裏技ではありません。Anthropicはエージェント設計の解説記事「Building effective agents」で、生成役とは別の評価プロセスが成果物を検査し、そのフィードバックで改善を繰り返す構成を「Evaluator-Optimizer(評価者と最適化者)」という代表パターンとして紹介しています。本記事はこのパターンを、Claude Codeの標準機能だけで業務に実装する方法として整理したものです。

なぜ「もう一度見直して」では直らないのか

最も手軽な品質対策は、同じAIに「いまの回答を見直して」と頼むことです。これで改善するケースも確かにあります。しかし、本質的な弱点が残ります。

最初に間違えたAIは、同じ文脈・同じ情報・同じ思い込みのまま見直すため、同じ盲点を高い確率で見逃します。次のようなやり取りが典型です。

AI:   A社の月額料金は9,800円です。
人間: 見直してください。
AI:   見直しました。問題ありません。

このときA社の公式料金ページが12,800円なら、最初の回答も見直し結果も両方とも間違いです。LLMが自分の回答に同意することと、現実に正しいことは別物です。

だから自己修正ループでは、次の2つを徹底します。

1. 生成と評価を分離する — 作った本人ではない検査役が、独立した文脈で成果物を検証する
2. 検査役に外部の根拠を渡す — 元資料・公式ページ・テスト結果など、「AIの記憶」ではないものと照合させる

この2つ目の「外部の根拠」が、次に説明するGround Truthです。

全体像:「作る」「検査する」「仕切る」の3役に分ける

自己修正ループの基本形は、役割の異なる3つのAI(またはAIの動作モード)で構成します。

判定は合格・不合格の2択にしない

Judgeの判定は PASS(合格)/ FAIL(不合格)に加えて、UNVERIFIED(未確認) の3値にします。根拠が見つからず正誤を確認できない項目を、雰囲気で合格にも不合格にもさせないためです。「確認できないものは確認できないと言う」を判定の選択肢として明示的に用意しておくと、AIが無理に断定するのを防げます。

Managerの判断ルールも先に決めておく

ループが迷走する原因の多くは、判定後の動きが曖昧なことです。次のように機械的に決めておきます。

• 重大な誤り(Critical)が1件でもある → 指摘をBuilderへ渡して修正
• 重要項目がUNVERIFIED → 追加調査、それでも埋まらなければ人間へ
• 同じ指摘で2回連続不合格 → ループを止めて人間へ引き継ぐ
• CriticalもMajor(目的を損なう問題)もゼロ → 完了

検査の精度を決める「Ground Truth(正解の根拠)」

自己修正ループの品質を決めるのは、Builderの文章力ではなくJudgeの検査精度です。そしてJudgeの検査精度は、何を根拠に判定させるかでほぼ決まります。

Ground Truthとは、何が正しいかを判断するための、AIの外にある根拠のことです。仕事ごとに次のようなものが使えます。

「このコードは問題なさそうです」というAIの所感より、「テスト24件中24件PASS・lintエラー0件」という機械の出力のほうが強い根拠です。記事なら「AIが正しいと思う」ではなく、原稿の9,800円と公式ページの12,800円を突き合わせて不一致ならFAIL、と判定させます。

検査は3層に分けると安定する

すべてをAIの判断に委ねる必要はありません。実務では次の3層に分けます。

原則は、機械で測れるものをAIに聞かないことです。第1層で落ちるものを第2層に持ち込まない構造にすると、Judgeは意味の検査に集中でき、誤判定が減ります。

「必ず3つ問題を見つけて」と頼まない

Judgeへ渡すプロンプトでありがちな失敗が、「必ず3つ問題を指摘して」という指示です。批判的に読ませる効果はありますが、本当に問題が0件のときにも無理やり3件をひねり出す可能性があります。正しい指示は「問題が0件なら0件と報告する。各基準を独立に検証し、根拠を確認できない項目はUNVERIFIEDとする」です。Judgeの目的は粗探しではなく、基準に照らした正確な判定です。

Claude Codeでの作り方:3段階で無理なく始める

ここからは実装です。使うのはClaude Codeの標準機能だけで、外部の自動化ツールもプログラミングも必要ありません。最初から完成形を組まず、次の3段階で育てます。

Level 1:/goalで「終わりの状態」を宣言する

Claude Codeで /goal コマンドを使うと、セッションに完了条件を設定できます。設定すると、AIは1回の応答で終わらず、各ターンの終了時に別の小型モデル(評価器)が「条件は達成されたか」を判定し、未達ならその理由をAIに返して作業を続けさせます。

/goal drafts/article.md が次の条件をすべて満たすまで改善する。
1. references/フォルダにない数字・日付・会社名を断定していない
2. 確認できない情報は「未確認」と明記している
3. 各章に具体例が1つ以上ある
4. 最大8ターンで未達なら停止し、残った課題を報告する

書き方のコツは1つだけです。「何をしてほしいか」ではなく、どんな状態になれば終わりかを、測れる形で書くことです。

運用上の仕様も押さえておきます(いずれも公式ドキュメント「Keep Claude working toward a goal」に基づく)。ゴールは1セッションに1つで、新しく設定すると置き換わります。引数なしの /goal で進行状況を確認でき、/goal clear で解除できます。条件は最大4,000文字です。また、ゴールを設定してもファイル操作などの権限は変わりません。

そして重要な制約が1つあります。この評価器はツールを使わず、会話に出てきた内容だけで判定します。 つまり「テストが通ったとAIが報告したか」は見えても、評価器自身がファイルを開いたり公式ページを確かめたりはしません。成果物そのものを独立に再検証したい場合は、次のLevel 2が必要です。

Level 2:検査役(Judge)を独立したAIとして立てる

Claude CodeのSubagents(サブエージェント)機能を使うと、.claude/agents/ フォルダにMarkdownファイルを置くだけで、本体とは別の文脈で動く補助AIを定義できます。検査役を独立させるのに最適な仕組みです。

.claude/agents/judge.md
---
name: judge
description: 成果物を独立した視点で検証し、PASS・FAIL・UNVERIFIEDを判定する。成果物は変更しない。
tools: Read, Grep, Glob
---
あなたは検査担当です。成果物を編集してはいけません。
- 評価基準を1つずつ独立に確認する
- 根拠を確認できない項目はUNVERIFIEDとする
- 問題は「場所・内容・根拠・修正指示」のセットで返す
- 問題が0件なら0件と報告する(無理に問題を作らない)

ポイントは tools の行です。検査役には読み取り系のツール(Read・Grep・Glob)だけを許可し、編集権限を与えません。「検査する人は直さない」という役割分担を、口約束ではなく権限のレベルで保証できます。同様に、作成と修正を担うBuilderを編集権限つきで定義すれば、3役が揃います。

あとはメインのAI(Manager役)に、ループの回し方を指示するだけです。

drafts/article.md を自己修正ループで完成させてください。
1. builderで改善する
2. judgeで独立検査する
3. CriticalかMajorの指摘があれば、その指摘だけをbuilderに渡して修正する
4. 問題のない箇所は変更しない
5. 修正後にjudgeで再検査する
6. CriticalとMajorが0件になったら完了
7. 3回修正しても未達なら停止し、残課題を報告する

これで「Builderが作る→Judgeが検査→指摘だけ直す→再検査」のループがClaude Codeの中で回ります。さらに外側に /goal を置けば、ループ全体の完了を別モデルが二重に確認する構成になります。

Level 3:SkillsとHooksで「毎回の手順」に固定する

ループが安定したら、毎回長い指示文を書くのをやめて仕組みに固定します。Claude Codeには置き場所ごとの役割分担があります。

覚え方は「毎回守る常識はCLAUDE.md、手順はSkill、今日の合格ラインは/goal、毎回の閉店点検はStop Hook」です。なお、Stop Hookのプロンプト型評価も/goalの評価器と同じく、実ファイルを自分で開いて確かめるわけではありません。テスト・lintのような確定的な機械検査を第1層に置く原則は、ここでも変わりません。

どこまで任せるか:リスクで3段階に分ける

自己修正ができることと、人間を完全に外してよいことは別問題です。業務をリスクで3段階に分け、人間の関わり方を変えます。

低リスク業務で誤判定の傾向を掴んでから、中リスク業務の「最終確認だけ人間」体制に広げるのが安全な順序です。高リスク操作は、どれだけループが安定しても人間の承認を外しません。AIの実行ループに人間の判断ポイントを組み込むこの考え方は、ヒューマンインザループと呼ばれ、AI活用の設計では標準的な原則です。

暴走させないための5つの停止設計

自己修正ループは、作ること自体は難しくありません。本当に重要なのは、止まるべきときに止まり、失敗を人間へ返せることです。

1. 最大修正回数を必ず決める — 記事や調査なら3回、コードなら10ターンなど。まず少なめに設定し、実績を見て増やします
2. 同じ不合格が2回続いたら止める — 同じ指摘が繰り返される原因は、元資料の不足や条件の矛盾などループの外にあることが多く、回し続けても解決しません
3. 直すのは指摘された箇所だけ — 1箇所の指摘で全文を書き直させると、合格していた箇所が壊れます。「FAILした場所だけ直す、PASSした場所は触らない」を原則にします
4. 人間への引き継ぎ形式を固定する — 何をしようとしたか・現在の成果物・試した修正・残った課題・判断してほしい論点、の定型で報告させれば、人間がゼロから調べ直さずに済みます
5. Judge自身もテストする — 正解の分かっている成果物(正しいもの5件・誤りを仕込んだもの5件)を検査させ、本当の誤りを見つけられるか、正しいものを無理に落としていないかを確認します。Judgeが壊れているとループ全体が壊れます

よくある失敗と対策

まとめ:今日は/goalの1行から始める

自己修正ループの本質は、AIに何度も考えさせることではなく、次の5点を設計することです。

1. 生成と評価を分ける
2. 合格基準を明文化する
3. 検査役にGround Truth(外部の根拠)を持たせる
4. 不合格の箇所だけを修正させる
5. 完了条件と停止条件を先に決める

最初から3役を組む必要はありません。今日の仕事でまず1回、/goal に検証可能な完了条件を書いてみてください。それが安定したら検査役のSubagentを1体作り、判定の精度を人間の目で確かめてから、ループ化・Skill化へ進みます。この順番なら、無理なく「自ら品質を管理するAIの仕事システム」に育てられます。

指示文そのものの組み立て方はプロンプトの書き方で、AIを業務に定着させる際の人材・体制面はFDE(Forward Deployed Engineer)やAI時代に求められるスキルで解説しています。あわせて参考にしてください。