コーディングエージェントの自己修復ループ：検証・停止・人への引き継ぎ
この記事で学べること
- 自己修復ループを構成する、結果の確認、失敗情報の返却、再試行、人への引き継ぎの役割
- テスト合格だけに頼らず、複数の観点から完了条件と停止条件を決める方法
- 情報の機密性と変更の影響に応じた自動化の範囲と、導入前後の確認事項
自己修復に必要な完了条件と停止条件
AIがコードを修正してテストに合格しても、それだけで作業が完了したとは限りません。利用者の意図に合う変更か、許可された範囲を越えていないかも確認する必要があります。
自己修復ループは、AIが変更、検証、失敗原因の特定、修正、再検証を繰り返す仕組みです。あらかじめ決めた完了条件を満たしたら終了し、続行できない条件に達した場合も停止します。
同じ失敗を繰り返している、修正範囲が広がっている、追加の権限が必要になったといった状態を検知して止まれなければ、安全に運用できません。再試行を何回許すかに加え、何をもって完了とするか、どの状態で止めるか、どの判断を人に引き継ぐかを、合わせて決める必要があります。
この記事では、自己修復ループの仕組み、テスト合格と作業完了の違い、自動化できる範囲を整理します。自分の業務で、どこまでAIに任せ、どこから人が確認するかを考えるための判断材料を紹介します。
自己修復ループの仕組みと5つの構成要素
この記事でいう自己修復ループ（self-healing loop）は、コーディングエージェント（コードの変更や検証を行うAI）が、承認された範囲内で修正と検証を繰り返す仕組みです。完了条件または停止条件に達したら終了します。
自律的に進める範囲は、人が先に決めます。その範囲を越える判断や操作が必要になったら、エージェントは作業を止め、人へ引き継ぎます。
ループを構成するのは、次の5つです。
| 要素 | 役割 |
|---|---|
| アクション | コードやコンテンツを変更する |
| 結果を判定する仕組み | 動作テスト、データ形式や文章・コードの構造の確認、仕様との照合、安全性の確認を行う |
| 失敗情報の返却 | 失敗した箇所、期待した値、実際の値、問題の再現手順をAIに返す |
| 再試行の制御 | 修正できる範囲と試行回数を制限し、同じ失敗を繰り返したら止める |
| 人の承認・判断が必要になる条件 | 権限の追加、外部への操作、仕様の解釈など、エージェントだけでは決められない条件を定める |
2023年ごろの自己改善研究を実装に取り入れる際は、生成、自己評価、修正を繰り返す方法が中心でした。2026年時点では、それだけでは不十分です。同じモデルが自分の回答を評価する方法に加えて、実際の実行結果、仕様、エージェントが参照できるテストとは別の確認、人の判断を組み合わせる必要があります。
研究が示す検証の限界
実行結果を使った改善と、その結果の信頼性
2026年8月に公開された研究整理「Self-Evolving Coding Agents」は、過去の作業を基に、AIの実行方法、記憶、手順書、道具などを更新する仕組みを整理しています。改善の主要な材料として挙げているのは、実際に動かして得た結果と、プロジェクト全体の情報です。[1]
同時に、返された結果を信頼できるか、評価問題に合わせすぎていないか、安全に保守できるか、費用を管理できるかを課題として示しています。[1]
テストや評価基準と、人の意図の違い
「The Verification Horizon」は、テストや評価ルーブリック（評価項目と採点基準）は、人の意図そのものではなく、それを測るための代理指標だと整理しています。[2]
検証シグナル（正しさを判断するためのテスト結果や評価結果）には、大規模な作業にも適用できること、人の意図を忠実に測れること、条件が変わっても判定が崩れにくいことの間にトレードオフがあります。すべてを同時に満たすのは難しいということです。[2]
そのため、検証器（結果が条件を満たすか判定する仕組み）を一度用意すれば終わりではありません。生成するAIの能力や、起こりやすい失敗に合わせて、検証器も更新する必要があると結論づけています。[2]
エージェントが参照できるテストだけでは分からない問題
「SpecBench」は、エージェントが参照できる検証用テストと、複数の機能を組み合わせて確認する非公開テストを分けて評価しました。その結果、エージェントが参照できるテストに合格しても、利用者の意図に沿っていない実装が残ることを報告しています。[3]
したがって、自己修復ループの完了条件を「修正中に繰り返し参照したテストに合格したこと」だけにするのは不十分です。
停止条件の記載と、実行時の停止制御
2026年7月には、リポジトリ（プロジェクトのコードや文書の保管場所）に定められたAI貢献ルールを、エージェントが守るか調べた研究も公開されています。対象のエージェントは、ルールを自発的に探すことがほとんどありませんでした。[4]
研究で測定された範囲では、ルールを明示的に知らせたり、検証器からフィードバックを返したりすると、検証や開示に関するルールの遵守は改善しました。一方、禁止された作業を拒否することや、人へ引き継ぐことは、確実には実行されませんでした。[4]
Markdown（見出しや箇条書きを記述できるテキスト形式）の文書に停止条件を書くことと、実行時に必ず停止させることは別の設計課題です。停止条件の文書化に加え、その条件に達したときに作業を止める仕組みが必要です。
失敗履歴を使った手順と検証の改善
失敗履歴を次の改善に使う研究も進んでいます。「Socratic-SWE」は、過去の解決トレース（エージェントが問題を解くまでの操作記録）から、再発しやすい失敗と修復のパターンをSkill（エージェントが参照する手順や知識）として抽出します。さらに、実際に実行して検証した課題を使い、次の学習につなげる閉ループを提案しました。[5]
これは、失敗ログをその場の再試行だけに使うのではなく、ルールや検証器を更新するための候補として残す考え方に対応します。
ここで紹介した資料には、2026年8月8日時点で公開されているプレプリント（査読前の論文）を含みます。個別の数値をそのまま本番品質の保証に使うのではなく、検証設計の論点を確認する一次資料として参照しています。
公式実装に見る複数の検証と人のレビュー
2026年のテック企業の公式記事にも、生成と再試行だけでなく、複数の観点から検証する取り組みが見られます。
OpenAI：修正から再検証・レビュー対応までの仕組み
OpenAIのHarness Engineering（エージェントの作業を支えるツールや検証環境の整備）の事例では、テスト、検証、レビュー、フィードバックへの対応、復旧を、リポジトリの仕組みに組み込んでいます。Codexは、不具合の再現、修正、アプリを操作した再検証、レビューへの対応まで進めています。[6]
ただし、この自律性は、リポジトリ固有の構造やツールの整備への投資に依存します。記事でも、同じ結果をほかの環境で得られるとは限らないと明記しています。[6]
Google：計画・仕様・ルールを含む自動レビュー
GoogleのGemini CLI Conductorは、実装後のAutomated Review（自動レビュー）で、plan.mdとspec.mdへの準拠、ガイドライン、単体・統合テスト、基本的なセキュリティ項目をまとめて確認します。[7]
単体テストは個々の処理の動作を、統合テストは複数の処理を連携させた動作を確認するものです。Conductorは、これらのテストへの合格に加えて、計画やルールに沿っているかも検証対象にしています。[7]
GitHub：PR作成前の自己レビューと安全性の確認
GitHub Copilot coding agentは、PR（変更内容を共有してレビューを受けるための提案）を開く前に自己レビューを行います。さらに、コードスキャン、シークレットスキャン（秘密情報が含まれていないかの検査）、依存関係の脆弱性チェックをワークフロー内で実行し、その後に人へレビューを依頼する流れを公開しています。[8]
3社の実装範囲は異なりますが、共通するのは、エージェント自身の判断だけで完了としないこと、検証結果を次の修正に返すこと、人へ渡す前に複数の検証を通すことです。
形式・動作・目的・安全性・人の判断による5層の検証
ここまでの研究と公式実装が扱う検証対象を基に、自己修復ループの検証を次の5層に整理できます。これは本記事の分類であり、各資料に共通する公式分類ではありません。すべてのタスクに全層を適用するのではなく、変更の影響に応じて必要な層を選びます。
| 層 | 確認すること | 例 |
|---|---|---|
| 1. 形式 | 機械が読み取れる状態か | データ形式、文章やコードの構造、設定項目の確認 |
| 2. 動作 | 想定した入力に対して、期待した出力が得られるか | 単体テスト、統合テスト、リンク確認 |
| 3. 目的との一致 | AIが繰り返し参照したテスト以外の確認でも、利用者の意図を満たすか | 完成条件との照合、回帰テスト、画面確認、変更前後の比較 |
| 4. ルールと安全性 | 実行してよい変更か | 権限、変更範囲、秘密情報、追加する機能、外部送信の確認 |
| 5. 人の判断 | 機械だけでは決められないことが残っていないか | 公開責任、最新情報、実体験との整合、元に戻せない外部操作の判断 |
第3層では、修正を行うエージェントが繰り返し参照してきた検証とは、別の視点を加えます。回帰テストは、変更によって既存の機能が壊れていないかを確認するテストです。
たとえば、単体テストへの合格を目指す修正ループの外側で統合テストを実行する、実装時とは別のレビュー手順で差分（変更前後の違い）を確認する、UI（利用者が操作する画面）の変更を実際のブラウザで確認するといった方法があります。
検証の数を増やすこと自体が目的ではありません。複数の検証で同じ問題を見落とさないよう、異なる観点から確認できる方法を選ぶことが重要です。
作業を終了する条件と、人への引き継ぎ
自己修復ループの停止条件は、完了条件と同時に決めます。この記事では、次のいずれかに達したら停止させます。
- 関連する検証がすべて合格し、差分が承認済みの範囲内に収まった
- 同じ原因の失敗が2回以上続き、修正方針が変わっていない
- 再試行の回数、時間、費用のいずれかの上限に達した
- 修正のたびに差分が広がる、または別の検証に失敗するようになった
- 仕様、最新の外部情報、著者の体験など、機械だけでは判定できない情報が必要になった
- 追加の権限、資格情報（パスワードやAPIキーなどの認証情報）、本番環境へのアクセス、外部への書き込みが必要になった
- 複数の検証結果が矛盾し、どれを優先するか判断が必要になった
最初の条件は、作業が完了した場合の終了です。それ以外は、続行せずに止める条件です。
途中で停止した場合も、ループが失敗したとは限りません。任せられた範囲を越える作業や判断が必要だと検知し、変更差分、合格した検証、残った失敗、次に必要な判断を人へ渡せれば、設計どおりに動いています。
情報の機密性と変更の影響に応じた自動化の範囲
機械的に検証できる作業でも、AIに反復を任せてよいとは限りません。再試行のたびに、情報へのアクセスや変更が繰り返されるためです。
情報の機密性と、変更がほかの環境や利用者に与える影響を基に、自動化の範囲を次のように整理できます。
| 区分 | 例 | 推奨する扱い |
|---|---|---|
| AIだけで反復する候補 | 公開文書、架空のテストデータ、ほかの環境へ影響しない手元での確認 | 変更範囲と再試行回数を制限して実行する |
| 人の承認後に限定して実行 | 機密情報を含まず、元に戻せる組織内コードの変更、承認済み環境での確認 | 人が変更前後と確認手順を確認し、許可した範囲だけ実行する |
| ループの対象外 | 資格情報、顧客データ、アクセス制御、本番データベース、取り消せない外部操作 | AIには機密情報を含まない計画と判断材料を準備させ、実行は人が行う |
ループの途中で追加の情報や権限が必要になった場合は、その時点で停止させます。エージェント自身に権限を広げさせません。
計画の作成と実行を分ける具体的な考え方は、関連記事「/goalと/planの適用条件」でも整理しています。
このサイトでの機械的な修正とAIによる修正
このサイトでは、決まった規則で直せる問題と、文脈を読んで判断する必要がある問題を、同じ修正ループに入れていません。
決まった規則による自動修正と直後の検証
npm run dev:checkには、同じスクリプトを--write（自動修正）と--check（検証）で呼び出す処理があります。
トピックの整合性、内部リンクが指す公開ルート、学習時間の表記などは、まず決まった規則に従って修正します。その直後に、修正対象の問題が残っていないかを確認します。
この処理にはLLM（文章の生成や解釈を行う大規模言語モデル）の判断を使いません。同じ入力なら同じ規則で処理するため、同じ結果を得やすくなります。
文脈の判断が必要な問題と、AIへのフィードバック
決まった規則による機械的な処理では直せない問題は、複数の確認コマンドで検出します。AIは、失敗したファイル、該当する規則、プロジェクト内の根拠を読み、必要な箇所だけを修正して再確認します。
AIに返すエラーメッセージには、単に「失敗した」と書くだけでは不十分です。対象、期待した値、実際の状態、参照すべき規則まで含めることが重要です。
作業を中断するときは、npm run agent:handoffで現在の差分と検証状態を残します。失敗履歴から再発しやすいパターンが見つかった場合は、個別の修正で終わらせず、Skill、ルール、決定論的チェック（同じ入力に対して同じ規則で判定する検査）への反映候補にします。
導入前・試行中・完了時の確認事項
次のチェックリストは、1つの自己修復ループの設計に必要な項目がそろっているかを確認するために使えます。
実行前：変更範囲・成功条件・上限・承認が必要な操作
- 変更対象と対象外を、ファイル、サービス、環境の単位で指定した
- 成功を判定する検証コマンドと、受け入れ条件を決めた
- エージェントが参照できるテストとは別に、回帰テストや仕様の確認を1つ以上用意した
- 再試行の回数、時間、費用の上限を決めた
- 追加権限や外部への書き込みなど、人の承認・判断に引き継ぐ条件を決めた
各試行：失敗原因・修正方針・変更差分・検証結果
- 失敗原因と、どの修正で解消できると考えたかを記録した
- 修正を、失敗原因に関係する最小限の範囲に限定した
- 同じ検証条件で再実行し、結果を保存した
- 差分が拡大していないか、新しい警告が増えていないかを確認した
完了時：検証結果・変更範囲・残るリスク・公開判断
- 機能テストに加え、仕様、既存機能への影響、安全性について、必要な検証を通過した
- 承認済みの変更範囲を越えていない
- 実行した検証、未確認事項、残るリスクを要約した
- 人の判断が必要な変更を、自動で公開・マージ・反映していない
- 再発する失敗を、Skill、ルール、テストの改善に反映するか判断した
まとめ：自己修復ループの完了条件・停止条件と人への引き継ぎ
自己修復ループでは、AIに再試行させる仕組みと合わせて、結果の確認方法、完了条件、停止条件を整え、運用しながら更新する必要があります。AIが繰り返し参照したテストへの合格は必要ですが、それだけでは利用者の意図や安全性まで保証できません。
導入は、毎回同じ規則で判定できる小さな作業から始め、動作、目的との一致、安全上のルール、人の判断へと確認を加えます。AIだけでは完了できない条件を先に決め、停止時に変更前後の差分と検証結果を人へ渡せるようにしておくことが、継続運用に必要です。
本記事は一般的な情報整理であり、法的助言ではありません。実務判断は専門家に確認してください。
参考文献
- Hao Zhou et al., Self-Evolving Coding Agents, arXiv preprint, 2026
- Binghai Wang et al., The Verification Horizon: No Silver Bullet for Coding Agent Rewards, arXiv preprint, 2026
- Bingchen Zhao et al., SpecBench: Measuring Reward Hacking in Long-Horizon Coding Agents, arXiv preprint, 2026
- Wenhao Yang et al., A First Look at Coding Agents’ Compliance with AI Contribution Rules in Open-Source Communities, arXiv preprint, 2026
- Chuan Xiao et al., Socratic-SWE: Self-Evolving Coding Agents via Trace-Derived Agent Skills, arXiv preprint, 2026
- OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026
- Google Developers Blog, Conductor Update: Introducing Automated Reviews, 2026
- GitHub, What’s new with GitHub Copilot coding agent, 2026
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。