図解

はじめに

AIに仕事を頼んで、違うものが返ってきたとき。たいていの人は、こう打ちます。

「もう一回お願いします」

2回目も少し違う。指示を足して3回目。ようやく合う。この一連の流れを、「AIが回った」と呼んでいる現場が、かなりあります。

でも、回っていたのは人です。

違うと判定したのは人。もう一回と決めたのも人。止めると決めたのも人。AIは、頼まれるたびに1回ずつ答えていただけです。

「もう一回お願いします」は、ループではなく、ただの再試行。

前回の記事で、ハーネスは「AIが一人で回れる足場」だと書きました。この記事は、その足場の上で何が回っているのか、という話です。足場が静止したものだとすれば、ループはその上の運動です。

そして、再試行とループの違いは回数ではありません。違いは2つだけで、その2つが仕組みに書いてあるかどうかで決まります。

この記事で扱うこと

再試行とループは何が違うのか
ループの4要素 — 観測・実行・検証・回復
発散するループ、収束するループ
人が回す輪から、機械が回す輪へ
ハーネスとループ、そして次の層

🔁 再試行とループは、回数では分かれない

まず、再試行の形を正直に描いてみます。

AIに頼む。出てきたものを人が読む。違う。指示を直して、もう一度頼む。出てきたものを人が読む。今度は合っている。終わり。

この輪の中には、人がいます。読むのも人、違うと言うのも人、終わりを決めるのも人です。AIがいるのは「頼む」と「出す」の1区間だけで、輪を一周させているのは人の手です。

ループは、形が違います。

いまの状態を読む。1手だけ進める。出てきたものを機械が判定する。通れば次へ、通らなければ戻してやり直す。決めた条件に達したら止まって、人に渡す。

この図の左は、人が輪の中にいます。右は、人が輪の外にいます。違いは、回っている回数ではなく、人の立ち位置です。

言い換えると、再試行とループを分けるのは次の2つです。

違うと言うのは、誰か。いつ止まるのか。

この2つが、人の頭の中ではなく、コードか設定か手順書に書いてあれば、それはループです。書いてなければ、何回回しても再試行です。

回数を増やしても、人が輪の中にいる限り、それは再試行である。

ここで一つ、誤解を避けておきます。再試行が悪いわけではありません。

何を作るか決まっていない探索の段階では、人が輪の中にいるほうが速い。前回の記事で「野生状態が常に劣るわけではない」と書いたのと、同じ線引きです。

問題は、再試行を「自動化した」と呼んでしまうことです。呼び名が変わった瞬間、人が輪の中にいることが見えなくなります。その人が休んだ日に、輪は止まります。

🧩 ループの4要素 — 観測・実行・検証・回復

では、人が輪の外に出るために、輪の中に何が要るのか。

4つです。観測、実行、検証、回復。

この図の4つが、人が担っていた仕事をそれぞれ引き受けます。どれか一つが欠けると、その穴を埋めるために人が輪の中に戻ります。

一つずつ、Anthropic が長時間エージェント用のハーネスを作ったときの記録と重ねて見ていきます。

観測は、いまどこにいるかを読むことです。

長時間動くエージェントの一番の問題は、新しいセッションが前のセッションの記憶を持たないことでした。Anthropic はこれを、交代制で働くエンジニアにたとえています。

Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.

（交代制で働くエンジニアたちのプロジェクトを想像してほしい。新しいシフトの人は、前のシフトで何があったかを何も覚えていない）

— Effective harnesses for long-running agents

だから、セッションの最初に読むものを用意します。進捗ファイル（claude-progress.txt）と git のログ、そして機能の一覧（feature_list.json）。一覧の各機能には「passes: false」が付いていて、どこまで終わったかが読めます。

観測が無いループは、毎周ゼロから始まります。

実行は、1手だけ進めることです。

同じ記録で、失敗の型として最初に挙がっているのが「一気にやろうとして途中で終わる」でした。複数の機能を同時に始め、コンテキストが尽きて、半端な状態で次のセッションに渡す。次のセッションは、状態の推測から始めることになります。

対策は、1セッション1機能。輪の1周で進む量を、意図的に小さくしています。

検証は、出てきたものが正しいかを、機械が判定することです。

ここで興味深い観察があります。ユニットテストは通っているのに、実際には動かないことが多かった。そこで、ブラウザを操作する道具（Puppeteer の MCP サーバー）を渡し、端から端まで動かして確かめさせました。

Providing Claude with these kinds of testing tools dramatically improved performance, as the agent was able to identify and fix bugs that weren't obvious from the code alone.

（こうしたテストの道具を渡したことで、性能は劇的に上がった。コードを読むだけでは分からなかったバグを、エージェント自身が見つけて直せるようになったからだ）

— 同上

前回の記事の「判定が確定的にできるところは、あえてLLMを使わない」は、ここでも効いています。動くか動かないかは、モデルに聞くことではなく、動かして確かめることです。

回復は、失敗したときに戻れる状態を保つことです。

機能を一つ終えるたびに git にコミットする。セッションの終わりは、そのままマージできる状態にして終える。壊したまま次の周に渡さない。

回復が無いループは、一度壊れたら壊れたまま進みます。進んでいるように見えて、戻る場所がありません。

4つを1枚に畳むと、こうなります。

要素	何をするか	無いとどうなるか
観測	進捗ファイル・git log・機能一覧から、いまの状態を読む	毎周ゼロから始まる
実行	1周で1手だけ進める（1セッション1機能）	半端な状態で次の周へ渡る
検証	テスト・ブラウザ操作で、動くかどうかを機械が判定する	それらしいものが通る
回復	機能ごとにコミットし、マージできる状態で終える	壊れたまま進む

ループの質は、1周の速さではなく、4つが揃っているかで決まる。

🧯 発散するループ、収束するループ

4つが揃っていないループは、どこへ行くのか。

ここで、もう一つの記録を見ます。Anthropic の Nicholas Carlini が、16体の Claude を並列に走らせて C コンパイラを作った話です。2週間弱、約2万ドル、10万行。Linux をブートできるところまで行きました。

この記録で一番強く書かれているのは、検証器のことです。

Claude will work autonomously to solve whatever problem I give it. So it's important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem.

（Claude は、与えられた問題を何であれ自律的に解こうとする。だからタスクの検証器はほぼ完璧でなければならない。そうでなければ、Claude は間違った問題を解いてしまう）

— Building a C compiler with parallel Claudes

検証器が弱いループは、止まらずに動き続けます。ただし、向かう先が「正しいもの」ではなく「それらしいもの」になります。

これが発散です。

この図の2本の線は、同じ場所から出ています。分かれるのは、各周の終わりで「違う」と言える判定があるかどうかだけです。

C コンパイラの記録では、人が手を入れたのはテストの設計だけでした。GCC のテスト群で 99% まで通し、その先は SQLite や Redis のような実物でさらに確かめる。検証器を人が作り、輪はエージェントが回す。この分担です。

発散の形は、もう2つあります。

回復が無いループは、壊したまま進みます。同じ記録で、新しい機能を足すと既存の機能が壊れることが頻発した、と書かれています。戻る場所が無ければ、壊れた上に積み上がります。

そして、停止条件が無いループは、止まりません。

Time blindness: Claude can't tell time and, left alone, will happily spend hours running tests instead of making progress.

（時間に対する盲目。Claude は時間が分からない。放っておくと、進捗を出す代わりに何時間でも喜んでテストを回し続ける）

— 同上

この図の4つが、止まる条件の置き場です。時間、回数、費用、そして人に返す場所。どれも、ループの外から与えるものです。輪の中にいるAIは、自分で止まる理由を持っていません。

「直るまで回す」という指示は、一見すると粘り強い設計に見えます。でも、止まる条件を書いていない時点で、設計として発散を選んでいます。

止まる条件が書けないループは、まだ設計が終わっていない。

🧑‍🔧 人が回す輪から、機械が回す輪へ

ここまで読むと、最初から4要素を揃えなければならないように聞こえるかもしれません。そうではありません。

最初は、人が検証器で、人が停止条件です。それで構いません。

大事なのは、その状態から、どう機械の輪に移っていくかです。

この図の階段は、検証が人から機械へ移るたびに、輪の中から人が一人抜けていく様子です。一段ずつで構いません。

今日、自分の目で確かめたことがあるとします。画面を開いて、ボタンを押して、こうなることを見た。

それを、テストとして書き残す。すると明日からは、同じ確認を機械がします。AIが直すたびに自分が画面を開き直す必要がなくなり、壊したかどうかを機械が先に教えてくれます。

これが、人が輪の外に出る一歩目です。検証器は、どこかから持ってくるものではありません。自分の確かめ方を、一つずつ機械に渡していった結果です。

渡す順番にも、型があります。

判定が確定的に決まるものから渡します。型チェック、リント、テスト。白黒がつく場所です。次に、観点を固定したLLMの判定。自由に感想を書かせるのではなく、見る範囲を絞って見せる。人に残るのは、最後まで機械に渡せない判断だけです。

もう一つ、輪の大きさの話があります。

1周で進める量は、1周で確かめられる量を超えてはいけません。前回の記事の「レビューの負担は、渡す側の粒度で決まる」は、ループではこう言い換えられます。1周の大きさは、検証器が1周で判定できる大きさで決まる。

30ファイルを一度に変えるループは、どんな検証器を付けても収束しません。確かめられない大きさで回しているからです。

ループを作るとは、自分の確かめ方を、一つずつ機械に渡していくこと。

🗺 ハーネスとループ、そして次の層

最後に、前回の記事との関係を整理します。

ハーネスは足場です。使える道具、触らせない境界、検証器、停止条件。置いてあるもので、それ自体は動きません。

ループは、その足場の上の運動です。観測し、実行し、検証し、回復する。足場に置いてあった検証器と停止条件が、ループの中では「回るたびに働くもの」になります。

この図の下から上へ、足場、その上の輪、複数の輪の配線、と層が重なっています。左が消えたわけではなく、上の層は下の層を前提にしています。

足場が無いまま輪だけ回すと、どうなるか。

検証器が無いので、間違ったものが止まらずに流れていきます。境界が無いので、触ってはいけないところまで変えます。これが、前の章で見た発散の正体です。

逆に、足場を正しく作ってあれば、ループに足りないのは「回し方」だけです。観測と実行と回復を足せば、輪が閉じます。

前回の記事の最後に、こう書きました。ハーネスを正しく作っていれば、グラフの入口には立っている。ループについても、同じことが言えます。

ハーネスを正しく作っていれば、ループの入口には、もう立っている。

そしてその先に、複数の輪をどう繋ぐか、どこで並列にしてどこで合流するか、人の承認をどのノードに置くか、という層があります。グラフと呼ばれています。今回は名前だけにしておきます。

系譜で言えば、プロンプト、コンテキスト、ハーネス、ループ、グラフ。方法論の対象は、外側へ広がり続けています。

📝 まとめ

3つに絞ります。

1つ目。再試行とループの違いは、回数ではありません。違うと言うのは誰か、いつ止まるのか。この2つが仕組みに書いてあるかどうかです。人が輪の中にいる限り、何回回しても再試行です。

2つ目。ループは4要素でできています。観測、実行、検証、回復。検証器が弱いと、それらしい方へ発散します。回復が無いと、壊れたまま進みます。停止条件が無いと、止まりません。

3つ目。ループは一気に作るものではありません。今日、目で確かめたことをテストに残す。その積み重ねで、人が輪の外に出ていきます。検証器とは、自分の確かめ方を機械に渡した結果です。

明日いちばん先に試すことを1つ挙げるなら、これをおすすめします。

いま「自動化した」と呼んでいる仕組みについて、2つに答えてみてください。違うと言うのは、誰ですか。止まる条件は、どこに書いてありますか。

両方の答えが「人」なら、それは再試行です。悪いことではありません。探索の段階なら、それで足ります。

ただし、同じことを繰り返し始めたら、そこが切り替えどきです。まず、今日確かめたことを一つ、テストにしてみてください。

📚 参考

一次資料

Effective harnesses for long-running agents — Anthropic、2025年11月26日。観測・実行・回復の具体（進捗ファイル・機能一覧・1セッション1機能・機能ごとのコミット）はここから
Building a C compiler with parallel Claudes — Anthropic、2026年2月5日。検証器と停止条件の引用はここから

あわせて読む

「AIの出力は必ず人が確認しています」は個人技であって仕組みではない — ハーネスの5要素（ここに 7作目の URL を貼る）
Graph Engineering とは — Loop Engineering の次に来た「エージェントの配線図」 — @y-morimatsu

💡 この記事について
本記事は2026年10月2日時点の整理です。

この記事の内容は、筆者の所属する日本AIセンターの社内教材をもとにしています。特定の顧客やプロジェクトの情報は含みません。

英文の引用はすべて原典と照合しています。日本語訳は筆者によるもので、公式訳ではありません。数字（16体・2週間弱・約2万ドル・10万行・99%）はすべて Anthropic が公開したものです。

「ループエンジニアリング」は、まだ用語として固まりきっていません。同じ言葉が別の意味で使われていることがあります。この記事での定義は、上の4要素と「人が輪の外にいること」です。

エンジニアがAIを活用して次のレベルへ。上流はさらに上へ、下流は上流へ。
そのために何をするかを書いていきます。