エンジニアのAgent Loopを整える技術 ─フィードバックループ is All You Need─
なぜ人間の介入無しに、AIが長時間ぶっ通しで作業が可能なのか？
先日、以下のAnthropicの記事が公開されました。
16のClaude Codeエージェントを並列で2週間動かし続け、10万行規模のRust製Cコンパイラを構築したという内容です。
しかも 人間の介入は一切無し で自律ループによって動作していたとのことでした。
この記事を読んだとき、Agent Teamsの機能に興奮すると同時に 人間の介入は一切無し、の部分に強い興味 を持ちました。しかも2週間も！？えっ、ずっと！？
なぜ、人間の介入が一切無しに、AIが長時間ぶっ通しで作業が可能なのか？
このAnthropicの記事で興味深いのは 「実装はAIが中心だが、テストを含めた評価や環境設定はむしろ人間が入念に設計している」 と書かれていることです。
そして上記のAnthropicの記事と、実際に自分でClaude Codeを長時間動かす中でようやく理解しました。重要な鍵は、Agent Loopの理解とフィードバックループの設計にありました。
Anthropicの記事から抜粋して翻訳：
Claudeエージェントチームでのプログラミングから得た教訓
このスキャフォールディングはClaudeをループで実行しますが、Claudeが進捗を把握できなければ、そのループは役に立ちません。私の努力のほとんどは、Claudeが私なしでも自力で方向を定められるように、Claudeを取り巻く環境（テスト、環境、フィードバック）を設計することに費やされました。
本記事では、なぜAIエージェントに長時間自律的に作業してもらうにはAgent Loopの理解とフィードバックループの設計が重要なのか、そして「エンジニアのAgent Loopを整える技術」について解説します。
本文が長いので、以下は忙しい人のための本記事の大事なところの3行要約とイラスト化したものです
フィードバックループとは何か
まず押さえておきたいのが、フィードバックループという考え方です。
これは 行動した結果を評価しその結果をもとに次の行動を修正する循環構造のこと を指します。
身近な例で言えば、エアコンです。
室温を測定し、設定温度と比較し、差があれば出力を調整する。
この 観測→比較→調整 という循環があるからこそ部屋の温度は安定します。
ソフトウェア開発でも同じです。
コードを書き、テストを実行し、失敗すれば修正する。
このサイクルがあるからこそ品質は向上します。
アジャイル開発におけるフィードバックループ
フィードバックループの分かりやすい例がアジャイル開発です。
アジャイルではいきなり完璧なシステムを作ろうとはしません。
小さく作って、動かして、レビューして、改善するというサイクルを通じて何度もスプリントを回します。
例えばスクラムでは
- スプリント計画を立てる
- 実装する
- レビューする
- レトロスペクティブで振り返る
- 改善して次のスプリントへ進む
というフィードバックループが設計されています。
この構造があるからこそ、仕様変更や不確実性の高いプロジェクトでも前進できます。
エージェントループ(Agent Loop) とは何か
Agent Loopは、AIエージェントが目標達成まで 「推論・ツール利用・結果観測」 のサイクル（思考-行動-観察）を自律的に繰り返すことを言います。AI自ら計画を修正し、外部ツール（検索やコード実行）を活用して、最終的な回答が出るまでこの動作を反復・修正し続けることを指します。
参考：
Agent Loopの基本イメージ
Agent Loopとは、AIエージェントが問題を解決するために、考えて、実行して、結果を受け取り、また考える という一連の行動を繰り返す仕組みです。
参考： ReActの原論文
単に質問に答えるだけのチャットボットとは違い、エージェントは外部ツールを呼び出しながら進めるタスクを自律的に処理します。これはAIが自分で考えながら行動するプロセスの根幹の部分です。
人間の例でいえば、地図を見ながら初めての街を歩くようなものです。目的地に向かう途中で、「あれ？この道違うかも」と考え直して地図を見直し、進むべき道を変更し、また歩き出す。これを繰り返して最終的に目的地にたどり着きます。Agent Loopもこれと同じです。
単なるプロンプト応答と何が違うのか
LLMは私たちが入力した文章に対して言語モデルとしての応答を返します。これは一回だけの「思考→応答」のパターンです。
一方で Agent Loopはこれがループになるところがポイントです。まず LLMが「次に何をすべきか」を考え、場合によってはツールを呼び出し、その結果を基にさらに次の行動を考えます。そしてこれを繰り返しながらタスクを完遂していきます。つまり、思考→行動→評価→再思考を繰り返します。
Agent Loopの構造
Agent Loopは一見複雑ですが、やっていることはシンプルです。ユーザー入力を受け取り、モデルが考え、必要ならツールを実行し、その結果を見てまた考える。このサイクルを繰り返します。
- ユーザー入力の受け取り
- 思考（Reasoning）
- ツール選択と実行
- 結果の反映と再思考
- 終了判定
このループが継続することで、複雑なタスクも分解して進められるようになります。
ループの継続のためのパフォーマンス最適化
プロンプトキャッシュ
ループが継続し、プロンプトが毎回大きくなっていくと、性能低下やコスト増につながります。
そこで プロンプトキャッシュが使われていて、一部のプロンプトが前回と同じ場合は再計算を省く仕組みが導入されています。
ただし、ツールの順序や内容が途中で変わるとキャッシュが効かなくなるので注意が必要です。
コンテキスト圧縮（自動コンパクション）
長いループではコンテキストウィンドウサイズが課題になります。
Claude Code では 自動コンパクションを使って、現在の会話履歴を要約し、不要な部分を縮小してコンテキストを節約します。自動コンパクションが走ると情報が失われるので、重要な情報はログやメモリファイル等に書いて残す必要があります。
Agent Loop設計とは何か
Agent Loop設計とは、AIが自律的に行動し、結果を評価し、改善しながら目標達成に向かう自己循環型の仕組みを、人間側で具体的にフィードバックループを設計したり環境を整えたりすることです。
言い換えれば、フィードバックループの解像度と強度を上げるための施策全部とも言えます。
つまり、AIが以下のような自己改善ループ(フィードバックループ)になるようにプロンプトやエージェントの環境を設計することを言います。
具体的なループ設計例：
- 目標を理解する(ログやgitの履歴から自分の現在地を知ることも含む)
- 調査する
- 計画する
- 行動する(ログに履歴を保存することも含む)
- 結果を評価する
- 改善する(gitにcommitすることも含む)
- 再び目標に照らしてループする
このフィードバックループが、長時間の自律作業を可能にします。
「目標を理解する」とは何を意味するのか
ここで特に重要なのが、最初の「目標を理解する」という工程です。
多くの人がここを軽く見積もりますが、実はこの段階でほぼ勝負が決まります。
目標を理解するとは、単に「何を作るのか」を知ることではありません。(※それも重要ではあります)
達成条件を明確にすることまで含みます。
例えば「Cコンパイラを作る」という目標があったとします。
しかしこれだけでは曖昧です。
・どのC規格に準拠するのか
・どのテストスイートを全通させるのか
・警告は許容するのか
・最適化はどのレベルまで行うのか
・対象プラットフォームは何か
これらが決まっていなければ、「完成」とは何かが定義できません。
AIは「雰囲気」でゴールを判断できません。
達成条件が曖昧だと、AIは途中で迷走しますし、作業途中なのに「こんなもんで、ええでしょう」と勝手に作業を止めてしまうことがよくあります。
私は以前、システムのパフォーマンス改善をClaude Codeに任せたことがあります。
しかし具体的な数値目標を設定していませんでした。
その結果、AIはコードを整理し、リファクタリングしましたが、肝心のレスポンス速度はほとんど変わりませんでした。
そこで私はコンテキストに次のような定義を加えました。
・平均レスポンス時間を300ms以下にする
・p95を500ms以下にする
・CPU使用率を20%削減する
・修正後必ず計測コマンドを叩いて上記を確認し、結果が満たされていなければ再度修正すること
数値で定義した瞬間、AIの動きが変わりました。
ボトルネック調査を行い、計測コードを追加し、仮説を立て、効果測定を繰り返すようになりました。
達成条件の明確化は、いわば「ゴールテープを見える化する」ことです。
ゴールが見えていなければ、全力疾走もできません。
テストで自己修正ループを回す
長時間の自律開発において、最も強力なフィードバック装置は テスト です。
Anthropic の記事でもテストの重要性が書かれています。
極めて高品質なテストを作成する
Claudeは、与えられた問題を自律的に解決します。そのため、タスク検証がほぼ完璧であることが重要です。そうでなければ、Claudeは間違った問題を解決してしまうからです。テストハーネスの改善には、高品質なコンパイラテストスイートを見つけること、オープンソースソフトウェアパッケージの検証機能とビルドスクリプトを作成すること、Claudeが犯している間違いを監視し、その失敗モードを特定するたびに新しいテストを設計することが必要でした。
Agent Loop を「目標 → 行動 → 評価 → 改善」の制御系と捉えるなら、テストは誤差（Error）を定量化するセンサー に相当します。
テストがない状態では、
- 何が正しいのか曖昧
- 改善したかどうか判断不能
- 局所最適に陥る
- AIの勝手な判断による「こんなもんでええでしょう」が発生する
という問題が起きます。
しかしテストがあると、AIは以下の自己修正ループを回せます。
実装 → テスト実行 → 失敗検出 → 原因分析 → 修正 → 再テスト → 収束
これはまさに 自律的フィードバック制御系 です。
Claude Codeでテスト自己修正ループを組み込む方法
重要なのは「テストがすべて通るまでループを止めるな」という明示的な制約を与えることです。
プロンプト例
プロンプトの例
あなたは自律的に動作するソフトウェアエンジニアリングエージェントです。
## 目標
本リポジトリのテストをすべて成功させること。
## 絶対条件
- すべてのテストが成功するまで終了してはいけません。
- テスト失敗時は必ず原因を分析してください。
- 修正後は必ず再度テストを実行してください。
- テストを書き換えて回避することは禁止です。
- 不明な場合はログとソースを読み、仮説を立てて検証してください。
## 各ループで必ず行うこと
1. 現在のコードとテストを確認
2. テストを実行
3. 失敗ケースを特定
4. 失敗原因を推論
5. 修正を実装
6. 再テスト
7. 結果をログに記録しコミット
## 終了条件
- すべてのテストが成功
- ビルドエラーがない
- 未実装（TODO）が存在しない
これらのテストがループ実行前に用意されてはじめて長時間フィードバックループを回すことが可能になります。
また、テスト自体は人間が書いてもいいですし、AIに書かせても構いません(どっちにしろ最終チェックは人間)
また、テストだけでなく、lintや型チェック等の静的解析も整備するとなお良いです。
Anthropicのループ実行例
Anthropicの記事では、以下のような無限ループでClaude Codeを回し続けています。
#!/bin/bash
while true; do
COMMIT=$(git rev-parse --short=6 HEAD)
LOGFILE="agent_logs/agent_${COMMIT}.log"
claude --dangerously-skip-permissions -p "$(cat AGENT_PROMPT.md)" --model claude-opus-X-Y &> "$LOGFILE"
done
このスクリプトがやっていることは非常にシンプルで本質的です。
そして、シェルスクリプトなので、ループが決定論的に確実に実行されます。
- 最新のcommitハッシュを取得
- ログファイル名をcommitごとに決定
- Claude Codeを指定プロンプトで起動
- 結果をログに蓄積
- 終了したらシェルスクリプトのループに再起動されて再度ループ
こうすることで、AIが1つのタスクを終えた瞬間に次の行動を検討し、継続的に作業を進められるようになっています。しかも1ターンごとに再起動されるので会話が長くなってマルチターンでコンテキストが溢れる心配もありません。
またこのループは人間の介入を前提とせず、AI自身が次の行動を決めるというAgent Loop設計の本質を体現しています。
この AGENT_PROMPT.md の中身は公開されていませんが、おそらく目標の達成条件やそれを評価する仕組みやログに何を残して再起動時に現在地と次のやることを知る方法が書かれているのだと思います。
おそらく以下のようなものが書かれているのではないでしょうか
(注：以下は私の勝手な想像です。へっぽこですいません＞＜ たぶん本物はもっとすごいことが書いてあるハズ。。。公開してほしい！！)
AGENT_PROMPT.mdの例 (※勝手な想像です。Agent Teamsは未考慮)
あなたは自律的に動作するソフトウェアエンジニアリングエージェントです。
このリポジトリ内で「Rust製のCコンパイラ」を完成させることが目標です。
## 対象とする C言語規格
本プロジェクトでは以下の規格を対象とします：
- ベース規格：ISO/IEC 9899:1999（C99）
- 必須対応機能：
- 基本的な型（int, char, long, pointer など）
- 制御構文（if, while, for, switch）
- 関数定義と呼び出し
- 再帰呼び出し
...略
## 開発ステップ(※たぶん実際は決定論的ワークフローになってそう。。。)
あなたは各ターンにおいて、以下のステップを順に行います：
1. COMMITとLOGFILEとリポジトリの内容から現在の状態を理解する
2. xxxをして、最も重要な次のアクションを決定する(最終目標を全て達成しているのなら7.へ飛ぶ)
3. 実装する
4. テストする
5. 問題があれば修正する(テストが通るまで3,4,5を繰り返す)
6. コミットする
7. 1ターン終了(※再度このあとシェルスクリプトで再起動される)
## 最終目標
以下を満たす Rust製 Cコンパイラを完成させること：
- C99の定義に従った文法解析
- 正しいコードを生成できる
- すべてのテストケースに合格する
...略
## 各ループで行うこと
各ループ開始時に：
1. 現在の状態を確認する
- READMEを読む
- COMMITとLOGFILEを確認する
- ソースコードを確認する
...略
7. 明確なコミットメッセージでコミットしログを残す：
- 何を実装したか
- なぜそれを行ったか
- xxx
...略
このループ構成では：
- Git commit → 長期記憶
- ログファイル → 思考履歴
- リポジトリ状態 → 世界状態
になっています。
ループするためには、それまでの行動の履歴を覚えておく必要があります。
「さっき何をしたか」「今何を目指しているか」を忘れてしまったら、同じことを繰り返したり、目標を見失ったりします。
なので、ループの最初で、COMMITとLOGFILEとリポジトリの状態を確認して、現在地と目的地を見失わないようにする仕組みが必要なのです。
この仕組みがあるからこそ、数千回を超えるセッションが積み重なり、大規模なプロジェクトでもAIチームが勝手に進み続けたのだと考えます。
そもそもAgent Loopは、Claude Code等のAIツールにすでに内包されているのではないか？
Claude CodeのようなAIエージェントは、内部的にすでに以下のようなループ構造を持っています。
- 状態の読み取り（ファイル・Git・ログ）
- 計画の立案
- コード生成
- 実行
- エラー解析
- 修正
- 再実行
つまり、ユーザ側で何もしなくても、デフォルトで Agent Loopの基本構造は、ツール側にすでに実装されているとも言えます。
なのに、ユーザ側がわざわざ ループ設計をする必要はあるのでしょうか？
不要なケース
- 小規模タスク
- 明確な1ステップ問題
- 人間が逐次レビューする開発
- 短時間で終わる作業
Claude Code は内部的に十分賢く、自然に「観察 → 計画 → 実行 → 修正」を回してくれます。
この場合、明示的なループ設計は冗長です。
必要になるケース
長期タスク
- 例えば、コンパイラ開発
- 大規模リファクタリング
- 大規模プロジェクト
→ 目標が長期的かつ曖昧になる
探索空間が広い場合
Cコンパイラの例では
- どの規格？
- どの順序で実装？
- どこまでやる？
- 最適化はいつ？
ツールの内部ループだけに任せると、探索が発散する可能性があります。
終了条件を明確にしたい場合
AIは結果が「十分良い」と "勝手に" 判断すると止まりやすいです。
しかし人間が求めるのは
- 全テスト合格
- 品質や規格基準準拠
- 明確な目標達成
などの厳密な完了条件です
これを明示しないと、途中で勝手に満足してしまうのです。
大きく分けて二つのループが存在する: 内部ループ vs メタループ
このループ構造は大きく二つに別れます。
- AIエージェントのツールの内部のループ
- AIエージェントのツールの外側のループ(メタループ)
先程も言いましたが、Claude Codeにも内部ループはあります。
今回の Anthropics の記事の bash スクリプトは
while true; do
claude ...略
done
これはツールの外側の「メタループ」です。
内部ループ
- 1回のClaude Code実行内での思考と修正ループ
メタループ
- セッションを超えた長期自己改善
この2つはレイヤーが違います。
なぜ長時間作業にはメタループ設計が必要なのか
短時間のタスクであれば、単発プロンプトでも問題ありません。
しかし数時間、数日、場合によっては数週間回すとなると話は別です。
1. 文脈が揺らぐ
長時間になるほど、AIは局所最適に引っ張られます。
目の前のエラー修正に集中しすぎて、本来の目標や達成条件を忘れてしまうことがあります。
また現在地を見失って迷子になりやすいです。
だからこそ、毎ループで「目標と達成条件とログを照らし合わせて確認する」工程が必要になります。
2. 調査と計画を飛ばすと破綻する
人間でも、調査不足のまま実装を始めると後戻りが増えます。
AIも同じです。
・既存コードを把握する
・依存関係を確認する
・設計方針を明文化する
この工程をループに組み込むだけで破壊的な変更が激減しました。
3. 評価軸がないと迷走する
評価基準や達成条件が曖昧だと、AIは「何が良い状態か」を判断できません。
結果として無駄な変更を繰り返します。
Agent Loop設計は、これらを制御するための枠組みを設計してコンテキストに含めることです。
Human in the Loopを前提にしない
AIエージェントを長時間自律的に動かしたいなら、まず考えなければならないのは
人間が介入しなくても回る構造を設計できているか？
という点です。
多くの開発現場では、無意識のうちに
- エラーが出たら人間が直す
- 方針に迷ったら人間が決める
- コマンド実行やファイル編集には人間の承認が必要
- コードをコミットするためには人間のレビューが必要
- テストが落ちたら人間が調査する
という Human in the Loop（HITL）前提の構造 になっていることが多いです。
Claude Codeを通常実行した場合、コマンド実行やファイル編集の度に承認ダイアログに何度も遭遇すると思います。
短時間タスクなら問題ありません。
しかし、数日〜数週間のAI連続実行では、この前提は破綻します。
よって、Human in the Loopを排除する必要があります。
自律動作のためのフィードバックループ環境整備
Human in the Loop を排除するとは、「人間を排除する」ことではありません。
人間の役割を「事前設計」に移すこと です。
必要なのは以下の整備です
1. 明確な終了条件
- 全テスト成功
- 性能基準達成
- 未実装ゼロ
- エラーゼロ
曖昧なゴールは、必ず人間依存を生みます。
2. 判断基準の明文化
悪い例：
適切に実装せよ
良い例：
RFC仕様の〇〇章に準拠すること
テストケース123〜145をすべて通すこと
p95を500ms未満にすること
AIが迷う余地を減らします。
3. 自動評価の仕組み
- テスト
- Lint
- 型チェック
- カバレッジ
- ベンチマーク
- 静的解析
これらを必ずループ内で実行させます。
4. ログと状態の永続化
- Git commit
- 実行ログ保存
- メトリクス保存
- 進捗サマリ生成
再起動しても「現在地」を見失わない構造にします。
Human in the Loop から Human in the Meta Loop へ
完全自律に必要なのは、「人間をループの中から外に出すこと」 です。
× 人間が毎回修正する
○ 人間がルールを設計する
人間は
- ゴールを定義し
- 評価関数を設計し
- 制約を与え
- 監視だけを行う
これが Human in the Meta Loop という状態です。
ループ設計は入れ子構造になる
フィードバックループ設計は、単一ループではなく、階層化された入れ子構造になります。
- レベル0：現実世界の目標達成
- レベル1：長期的収束を管理
- レベル2：局所最適化を実行
- レベル3：純粋な計算処理
このループの階層構造が、Agent Loop設計の真髄です。
レベル0を達成するために、レベル1のループを設計することです。
そして、レベル0のメタループは、人間が現実世界で回す ということを忘れないでください！
例えば、できたツールをお客さんに使ってもらってフィードバックをもらいまた改善する、というループです。もちろんこの作業を必ずしも人間がすべてやる必要はなく、プロダクトにユーザーからのフィードバック機能を組み込み自動化すること等も、ループを設計することに含まれます。
この他にも、アジャイル開発におけるスプリントをどう回すのか？ などもそうです。
制御理論の視点
Agent Loop は制御理論で言うところの フィードバック制御系 と同型です。
制御理論では以下の要素を持ちます
- 目標値（Setpoint）
- 現在状態（State）
- 誤差（Error）
- 制御入力（Control Action）
- フィードバック（Feedback）
Agent Loop に対応させると
制御理論 Agent構造
---------------- ----------------
目標値 最終ゴール
現在状態 リポジトリ状態
誤差 メトリクスや未達成タスク
制御入力 次の実装
フィードバック テスト結果
つまり、Agentは常に
誤差を最小化する方向へ動く制御装置
として振る舞っています。
戦略ループは 上位制御器（Supervisory Controller） に相当します。
「Agentic Coding とは Reconciliation Loop である」
以前、t-wada さんがこんなことを言っていたことが思い出されます
まとめ
Claude Codeに長時間ぶっ通しで作業してもらうには、
・明確なゴール
・達成条件の定義
・現在地の確認と調査と計画
・行動履歴を残す
・定量評価
・自己修正ループ(フィードバックループ)
・継続実行構造
が必要です。
哲学的に言えば、AIエージェントを使いこなす上で我々が問われているのは
AIは単なる反応装置か？
それとも自己制御系か？
ということでもあります。
Agent Loopを設計するという行為は、
- フィードバック制御を設計し
- 目的関数を定義し
- 自己参照の階層を与える
ということです。
このことを理解しておかないと、AIは目的地まで自律的に長時間行動することはできません。
だからループ設計が重要なのです。
これがAIエージェントを長時間ぶっ通しで作業させるための本質だと考えています。
追記: 円環の理に導かれし者たち
ここだけの話ですが、非常に重要な事実をお伝えします。。。
それは Claude Code自体が、Claude Codeによって 90%以上 開発されている ということです。
しかもその開発プロセスもまた、自己改善ループを前提に設計されています。
さらに驚きなのは、2月5日にOpenAIはGPT-5.3 Codexをリリースしました。
技術ドキュメントには以下が書かれていました。
「GPT-5.3-Codexは、自分自身の作成において重要な役割を果たした初めてのモデル です。Codexチームは初期版を使って、自身の学習のデバッグ、デプロイ管理、テスト結果と評価の診断を行いました。」
Codexも自己改善ループに入ってる！？
これは単なる「AIがコードを書く」という話ではありません。
AIが、自分で実装し、自分でテストし、自分で修正し、自分で改善し
そしてその改善が次の改善を可能にする
という 自己強化的な循環構造 を持っている、ということです。
つまり、私たちが設計しようとしているフィードバックループは、すでにツール自身の内部でも開発プロセスにおいても回っている。
Claude CodeやCodexは、自律的に動作するエージェントでありそのエージェントを改善するエージェントでもあるという 入れ子の自己参照系の上に成り立っています。
これは単なる開発効率の話ではありません。
ただの技術進歩ではなく、社会システム全体に影響する変容が始まったとも言えます。
Claude Codeの自己改善ループが社会構造レイヤーに侵食し始め
ループを設計できるものが、ループを進化させる。
その結果として生まれるのは、より強い内部ループ、より長いメタループ、より安定した自己改善系、です。
そして私たちは今、そのループの外側に立っているのか、それともすでにその一部なのか（？）
Agent Loopを設計するということは、単にAIに仕事をさせることではありません。
外側のメタループも含めて自己改善する構造を設計することです。
Claude Code が Claude Code を改善し続ける世界において重要なのはどこまでAIを自律作業させるかではなく
どのような目的関数とフィードバックを与えるか
なのかもしれません。
世界は、人生は、毎日は、ループで回っています。
問題は、そのループをどの方向へ収束させるか、です。
それを決めるのは、まだ、いまのところは人間です（？）
Discussion