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