― AI同士の対話より先に「Environment-Grounded Feedback」を設計する ―
要旨
AIコーディングエージェントから人間による逐次承認を取り除く場合、その代替として単純に別のAIエージェントを配置し、AI同士にレビューや議論をさせればよいとは限らない。
現時点の研究からより強く支持される設計原則は、コード実行、unit test、compiler、type checker、static analyzer、diff、sandbox policyなど、LLMとは独立した外部環境から取得した観測結果を次の推論ループへ入力することである。
すなわち、重要な設計変数は最初から「single-agentかmulti-agentか」ではない。
まず、
LLM内部で生成されたfeedbackなのか、外部世界にgroundされたfeedbackなのか
を区別すべきである。
そのうえで、同一エージェントを再実行するか、reviewer sub-agentを置くか、Claude CodeとCodexのような異なるエージェントを組み合わせるかを選択する、という順序が合理的である。
1. 問題設定
人間承認を減らしたAIコーディングでは、典型的に次の問題が発生する。
Agentがコードを書き、
「正しく修正できた」
「テストできた」
「問題は解決した」
と判断したとしても、その判断自体がLLMによる推論である以上、実際のプログラム状態と一致する保証はない。
ここで単純な解決策として考えられるのが、別のLLMをreviewerとして置く方式である。
例えば、
Coding Agent A
↓
Reviewer Agent B
↓
「問題ありません」
↓
完了
という構成である。
しかし、この構成ではAとBの両方が同じ誤った前提を共有する可能性がある。
したがって、より重要なのはreviewerの「数」ではなく、reviewerが何を根拠として判定しているかである。
2. Self-feedback と External feedback
LLMの修正ループは大きく三種類に分けて考えられる。
2.1 Intrinsic / Self Feedback
Agent
↓
コード生成
↓
Agent自身がレビュー
↓
修正
これはSelf-Refineなどで研究されている方式であり、モデル自身が自分の出力を批評して改善する。自己feedbackによる改善が確認された研究も存在する。
ただし、self-correction研究を体系的にレビューしたKamoi et al.は、promptされたLLM自身が生成するfeedbackだけによる自己修正について、一般的に成功が確立しているとは言えず、一方で信頼できるexternal feedbackを利用できるタスクではself-correctionが機能しやすいと整理している。
2.2 LLM-to-LLM Feedback
Agent A
↓
コード
↓
Agent B
↓
レビューコメント
↓
Agent A
↓
修正
これはsub-agent、critic agent、reviewer agent、multi-agent debateなどに相当する。
この方式そのものが無意味なわけではない。
AgentCoderでは、programmer、test designer、test executorという複数のagentを分業させ、HumanEvalで96.3%、MBPPで91.8%のpass@1を報告している。
しかしAgentCoderで重要なのは、AI同士が会話していることだけではない。
test executorが実際にコードを実行し、その実行結果をprogrammerへ返す構造になっている。つまりmulti-agent architectureの内部にもEnvironment-Grounded Feedbackが組み込まれている。
したがって、この結果だけから「multi-agent conversationがsingle-agentより優れている」と結論することはできない。
2.3 Environment-Grounded Feedback
第三の方式が今回もっとも重要である。
Agent
↓
コード変更
↓
External Verifier
├─ compiler
├─ unit test
├─ integration test
├─ type checker
├─ lint / static analysis
├─ git diff
└─ sandbox / policy checker
↓
観測結果
↓
Agent
↓
retry
ここではfeedbackを作る主体がLLMではない。
「正しいと思います」
ではなく、
pytest:
3 failed, 121 passed
typecheck:
2 errors
git diff:
17 files changed
allowed scope: 4 files
policy:
network write blocked
という観測可能な事実が次のAgent呼び出しへ渡される。
これが今回の中心的な設計原則である。
3. コード生成ではExecution Feedbackが実際に有効である
Chen et al.のSelf-Debuggingでは、
code generation
→ execution
→ execution result
→ feedback message
→ debugging
→ execution
という反復構造が使用されている。
unit testが利用可能なTransCoderとMBPPでは、Self-Debuggingによってbaseline accuracyが最大12ポイント改善された。また、論文ではexecution resultとcode explanationを次のdebugging stepへ返す構造が明示されている。
特にTransCoderでは、同論文内のCodex baseline 80.4%に対し、unit-test feedbackを用いたSelf-Debuggingは91.6%、unit testとcode explanationを組み合わせると92.5%となっている。
つまり、
失敗 → LLMが考え直す
だけではなく、
失敗 → 実行 → 観測 → LLMが考え直す
という構造にすることに意味がある。
4. 現代モデルでも「Execution Error → Retry」は有効
2026年のArimburによる研究では、7種類のモデルについて、生成したコードのexecution errorを再びモデルへ入力して最大5回self-repairさせている。
その結果、HumanEvalでは+4.9〜+17.1 percentage points、MBPP Sanitizedでは+16.0〜+30.0 percentage pointsの改善が報告された。
さらに重要なのは、改善の大部分が最初の2回程度のrepair roundに集中していたことである。
これは実装上、
Agent
↓
Test
↓ FAIL
Retry 1
↓
Test
↓ FAIL
Retry 2
↓
Test
程度までは自動化し、その後も失敗し続ける場合には別の戦略や人間へescalateする、という設計に合理性があることを示唆する。
5. 「別のAIに見せればよい」とはいえない重要な証拠
この点について特に興味深いのが、Park & Choiによる2026年のpreprintである。
研究では長時間動作するautonomous agentについて、agentとtool surfaceを固定したまま、評価器がアクセスできる情報だけを変更する実験を行っている。
Agent自身は54 cycleすべてで「改善した」と判断したが、実際の測定では56%のcycleで改善量がゼロ以下だった。
さらに、artifact全文、diff、過去の判定履歴を読む強いin-band judgeを置いた場合でさえ、実世界では悪化していた変更の44%をacceptし、実際には改善していた変更の38%をrejectした。
一方、containerやnetwork isolationによって実世界の状態を測定するworld-state oracleを使用した場合には、この問題が大きく改善した。
著者らは、成功条件が会話履歴の外部に存在するタスクでは、real-world accessを持つout-of-band evaluationが構造的に必要だと結論している。
これは今回の議論にかなり直接的である。
つまり、
Agent A
↓
Agent B「改善しています」
より、
Agent A
↓
実際の環境
↓
measured result
↓
Agent A
の方が、少なくとも外部世界に正解が存在する問題については強い根拠を持つ。
6. したがって「Agent数」より「Verifierの独立性」が重要
ここから導かれる設計原則は次のようになる。
悪い問い：
Single Agent と Multi Agent、
どちらが優れているか？
ではなく、
より良い問い：
Agentが受け取るfeedbackは
何によってgroundされているか？
である。
同一Agentであっても、
Codex
↓
pytest
↓
failure log
↓
Codex retry
なら十分にexternal feedback loopを構築できる。
逆に、
Claude
↓
Codex
↓
Claude
↓
Codex
と何度会話させても、実行環境を観測しなければ、両者が同じ誤解に収束する可能性を排除できない。
7. ただし、外部ツールなら何でも信用できるわけではない
ここには重要な注意点がある。
Verifier自体が間違っていれば、Agentは間違った方向へ最適化する。
特にAgent自身にテストを書かせ、そのテストだけを正解判定に使う場合には注意が必要である。
Chen et al.による2026年のSWE-bench Verifiedを用いた分析では、agent-generated testを多く書くモデルが必ずしも高い成功率を示すわけではなく、promptによってtest writingを増減させても、多くのケースで最終成功率への影響は小さかった。Agentが作るテストはassertionによる厳密なverificationより、値を表示して観察する用途に偏る傾向も報告されている。
したがって、
Agent
↓
Agent自身が都合のよいtestを書く
↓
そのtestをPASS
↓
成功
だけでは不十分である。
より信頼できる構成は、
既存repository tests
hidden tests
compiler
type checker
static analyzer
schema validator
policy checker
sandbox observation
など、Agentの推論から可能な限り独立したverification sourceを組み合わせることである。
8. diffは「正しさ」ではなく「変更範囲」を検証する
今回使用している
inspect → executable test → diff → retry
という表現についても役割を分ける必要がある。
executable test
主に、
「期待された振る舞いをしているか」
を見る。
compiler / typecheck / lint
主に、
「構文・型・静的制約を満たしているか」
を見る。
diff
主に、
「何を変更したのか」「変更範囲が要求を超えていないか」
を見る。
したがってgit diffが綺麗だからコードが正しい、とはいえない。
しかし、
要求：
src/auth/token.tsだけ変更
実際：
27 files changed
package.json変更
CI設定変更
database migration追加
のようなscope creepを機械的に検出するためには非常に有用である。
つまり、testとdiffは異なるfailure modeを検出している。
9. Sub-AgentやClaude Code ↔ Codexはどこに入るか
ここまで整理すると、sub-agentや異種Agent連携の位置づけも明確になる。
Pattern A：同一Agent + External Verification
Codex
↓
implementation
↓
test / diff / static analysis
↓
Codex
↓
retry
最も単純な構成である。
Agentを増やさなくても成立する。
Pattern B：Main Agent + Reviewer Sub-Agent
Main Agent
↓
implementation
↓
External Verification
↓
Reviewer Sub-Agent
↓
Main Agent retry
Reviewerは、機械的な結果を解釈したり、複数のfailure messageから修正方針を立てたりする役割を持てる。
Pattern C：Claude Code ↔ Codex + External Verification
Claude Code
↓ implementation
Codex
↓ semantic review
pytest / typecheck / diff
↓ objective feedback
Claude Code
↓ retry
あるいは逆でもよい。
この構成では異なるモデルの推論特性を利用できる可能性がある。
ただし、Claude CodeとCodexを組み合わせれば単体より必ず優れる、という直接的な実証結果は現時点では確認できない。
したがってmulti-agent化は二次的なoptimizationとして考えるべきである。
10. 推奨する全体アーキテクチャ
以上から、人間承認を減らすAI coding systemでは次の構造が有力である。
┌──────────────────┐
│ Coding Agent │
└────────┬─────────┘
│
implementation
│
▼
┌───────────────────────────┐
│ External Verification │
│ │
│ compile / typecheck │
│ lint / static analysis │
│ unit / integration tests │
│ hidden tests │
│ git diff / scope check │
│ sandbox / policy check │
└─────────────┬─────────────┘
│
feedback bundle
│
▼
┌──────────────────┐
│ Agent retry │
└────────┬─────────┘
│
必要な場合のみ
▼
┌──────────────────────┐
│ AI Reviewer/Subagent │
└─────────┬────────────┘
│
判断不能・高リスク
▼
┌────────────┐
│ Human │
└────────────┘
この構成では、人間を単純にAI reviewerへ置き換えているのではない。
人間が担っていた検証作業のうち、機械的に判定可能な部分をexternal verifierへ移動している。
ここが重要である。
11. Human-in-the-loopの再定義
この観点から考えると、
「Human approvalを残すか、消すか」
という二択自体が少し粗い。
より適切なのは、
機械的に検証できるものは機械に閉ループさせ、機械的に検証できないものだけ人間へ送る
という考え方である。
例えば、
Machine-verifiable
- buildが通るか
- testが通るか
- type errorがあるか
- API responseが期待値か
- 許可外fileを変更したか
- diffが上限を超えたか
- network accessが発生したか
これらは原則としてHuman approvalを必要としにくい。
一方、
Machine-verificationが難しい
- 要件そのものが曖昧
- UXとして本当に望ましいか
- 大規模architecture変更を許可するか
- production dataを変更してよいか
- irreversible actionを行うか
- business intentを満たしているか
についてはHuman escalationの価値が残る。
12. 本レポートの中心結論
現時点の研究から最も妥当と思われる結論は次の通りである。
人間承認を減らす場合、最初に考えるべき代替手段は「別のAIにレビューさせること」ではない。
まず、
AIの行動結果を外部環境で実行・測定し、その観測結果を次の推論loopへ返す構造
を作るべきである。
すなわち、
Generate
↓
Execute
↓
Observe
↓
Verify
↓
Retry
である。
そのうえで、必要に応じて、
Sub-Agent
AI Reviewer
Claude Code ↔ Codex
Multi-Agent Debate
を追加すればよい。
したがって設計の優先順位は、
External Verification → Retry Loop → AI Review → Human Escalation
と考えるのが有力である。
ただしこれは「AI reviewは不要」という意味ではない。
AI reviewerは、設計品質、仕様解釈、failure原因の仮説生成など、機械的なoracleを作りにくい領域で価値を持つ。
重要なのは、
AIを「正解判定器」として使うのか、それとも「観測結果を解釈して次の行動を考える推論器」として使うのか
を区別することである。
後者の方が、現在のLLMの特性と相性がよい。
13. 今回得られた新しい研究仮説
以上を踏まえると、次の仮説を独立したResearch Questionとして設定できる。
RQ-A
AI coding agentにおいて、人間承認を除去した際の成功率・安全性は、LLM reviewerを追加することより、environment-grounded external verification loopを追加することによって大きく改善するか。
RQ-B
同一Agentによる
execute → feedback → retry
と、異なるAgentによる
Agent A → Agent B → retry
では、どちらが成功率・回復率・token効率に優れるか。
RQ-C
Agent A
→ Agent B review
→ External verification
→ Agent A retry
というhybrid構成は、それぞれ単独の構成を上回るか。
RQ-D
External verifierの独立性は成功率にどの程度影響するか。
例えば、
Agent自身が作成したtest
vs.
既存repository test
vs.
human-written hidden test
vs.
external policy verifier
を比較する。
この問いは特に重要である。
なぜなら、現在の研究からは単に「testをたくさん実行すればよい」のではなく、feedback sourceそのものの信頼性が重要であることが示唆されているためである。
参考文献
-
Kamoi, R., Zhang, Y., Zhang, N., Han, J., & Zhang, R. (2024). When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs. Transactions of the Association for Computational Linguistics, 12, 1417–1440.
Self-correction研究を整理し、prompted LLM自身からのfeedbackとreliable external feedbackを区別した重要なsurvey。 -
Chen, X., Lin, M., Schärli, N., & Zhou, D. (2023). Teaching Large Language Models to Self-Debug.
コード実行結果・unit test結果を次のdebugging loopへ戻すSelf-Debuggingを提案。今回の主張に最も直接的な初期研究の一つ。 -
Arimbur, J. J. (2026). How Many Tries Does It Take? Iterative Self-Repair in LLM Code Generation Across Model Scales and Benchmarks. arXiv preprint.
execution errorを再入力するiterative repairを7モデルで評価し、特に最初の数回のretryの有効性を報告。 -
Park, H., & Choi, B. (2026). When Do Agent Loops Mistake Stagnation for Progress? Self-Evaluation Bias and Externally Grounded Verification in Long-Running Autonomous LLM Agent Loops. arXiv preprint.
in-band AI judgeとworld-state oracleの違いを直接扱っており、本レポートの「grounding」の議論に特に重要。 -
Huang, D., Zhang, J. M., Luck, M., Bu, Q., Qing, Y., & Cui, H. (2023). AgentCoder: Multi-Agent-based Code Generation with Iterative Testing and Optimisation.
programmer、test designer、test executorによるmulti-agent architectureを提案。Multi-agentの有効例であると同時に、その内部にexecution-grounded feedbackが存在する点が重要である。 -
Shinn, N., Cassano, F., Berman, E., Gopinath, A., Narasimhan, K., & Yao, S. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning.
言語feedbackをmemoryとして保持し、次回trialを改善する代表的なreflection architecture。external feedbackとinternally simulated feedbackの双方を扱う。 -
Chen, Z., Sun, Z., Shi, Y., Peng, C., Gu, X., Lo, D., & Jiang, L. (2026). Rethinking the Value of Agent-Generated Tests for LLM-Based Software Engineering Agents. arXiv preprint.
Agent自身によるtest生成を増やしても成功率が単純には上昇しないことを示し、「external verifierなら何でもよい」という解釈に重要な制約を与える。 -
Tyen, G., Mansoor, H., Carbune, V., Chen, P., & Mak, T. (2024). LLMs cannot find reasoning errors, but can correct them given the error location. Findings of ACL 2024.
LLMは誤りの発見自体には苦戦する一方、誤り箇所が与えられると修正能力を発揮しやすいことを示す。外部verificationが「どこが悪いか」を提供する価値を理解するうえで関連する。
最終命題
AIエージェントの自律性を高めるとき、「人間を別のAIで置換する」のではなく、「人間が確認していた事実のうち機械検証可能なものを、信頼できる外部Verifierへ置換する」と考えるべきである。
そして、
Single Agent / Sub-Agent / Claude Code ↔ Codex
という選択は、そのExternal Verification Loopを作った後のarchitecture choiceとして考えるのが妥当である。