TL;DR： loop engineering が最近注目されているが、実質的には三つの名前が同一のものを指しているに過ぎない。コミュニティでは loop、Anthropic 公式では harness と呼ぶ。本当の構造は四段階の委任の階段であり、「まだ自分が見張っている」ターン制から、「課題設定まで手放す」プロアクティブ型まで続く。この仕組みが存在する理由は三つの本質的な問題にあり、中でも最も重要なのは「モデルが自分の出力の品質を判断できない」という点だ。Anthropic 自身の実測データが示している。単一 agent が20分で作るのは何とか動く半完成品に過ぎず、生成と評価を分けた完全なフレームワークが6時間かけて作るものが、本当に使える成果物だ。

「もう Claude に prompt を打つのはやめた。自分が書いているのは、Claude に prompt を打ち続けるループだ。」Claude Code を作った Boris Cherny がSequoia AI Ascent 2026 のインタビューで語ったこの言葉は、切り抜かれて先日約70万回シェアされた。ところが、もう少し深く問いかけると話がこじれる。同じものをコミュニティでは loop と呼び、Anthropic 公式ドキュメントでは harness と呼び、Google の Addy Osmani はあらためてこの概念を命名した。その名が loop engineering だ。三つの名前が同一のものを指しているため、まるで三つの異なる新技術があるように読めてしまう。この記事では用語を整理した上で、この仕組みの本当の構造・それが解決する問題・そして自分が構築したシステムとの関係を、一度に整理していく。

loop engineering とは何か

まず用語を整理しよう。loop（Peter Steinberger・Addy Osmani・swyx というコミュニティのラインが広めた）と harness（Anthropic 公式用語）は、同じものの二つの名前だ。harness とはモデルの外側にある一連の仕組みを指す。prompt、ツール、記憶や引き継ぎファイル、編成の方式——モデルが考える役割を担い、harness がそれを目標に向けて動かし続ける。

一言で言えば：一歩ずつ手動で AI を指示する代わりに、「AI に指示し続けながら目標へ向かって完成まで反復する」システムを自分で書く、ということだ。これはひとつの連続体であり、Anthropic が〈Building Effective Agents〉で分類した両端がある。workflow（ワークフロー）は経路をあらかじめ固定し、予測しやすく安定している。agent（エージェント）は経路をモデルがその場で決定し、柔軟だが、コストが高く、遅く、エラーが連鎖しやすい。シンプルなものから複雑なものへ、五つの構成要素がある。連結、分岐、並列化、サブエージェントへの指示、そして最後が生成と評価だ。公式の原則として、シンプルにできるならシンプルにする——本当に必要なときだけ上に上る。

ループとは何か：一つの目標がシステムに入り、Claude が繰り返し処理を行い、停止条件を満たして初めて完了を出力する

「どれだけ委任したか」を実際に決めるのは、「ループをどう動かすか」という層だ。Claude Code 公式ドキュメント〈Getting started with loops〉はこれを四段階の委任の階段として整理している。違いは「何を手放すか」にある。

ターン制（turn-based）：prompt を一つ渡す。agent が自分でコンテキストを収集し、行動し、結果を検証する。完了していなければもう一周する。完了したと判断するか、処理上限に達した時点で応答する。あなたはまだ一歩ずつ見張っている。

ターン制ループ：あなたが prompt を渡し、Claude がコンテキストを収集・行動・検証し、完了と判断して応答する

ゴール型（/goal）：一歩ずつの指示ではなく、「停止条件」を手放す。agent がタスクを進め、別の独立した評価モデルがあなたの設定した条件を確認する。通過しなければ差し戻してやり直し、条件を満たすか回数上限に達したら終了する。評価するのは別のモデルであり、agent が自分で判断するわけではない。

ゴール型ループ：あなたが停止条件を手放し、評価は独立したモデルが担い、通過しなければ差し戻す

スケジュール型とプロアクティブ型（/schedule）：「トリガー」を手放す。毎回 prompt を渡す必要すらない。システムがクラウド上に常駐し、あるイベントソースを監視する。メインの agent が処理を走らせて検証をパスし、PR を開く。別の agent がレビューして通知する。あなたはマージするかどうかを決めるだけだ。最も自律的な「プロアクティブ型」はここに含まれる。課題を自分で見つけてくるのがその特徴で、あなたが唯一保持するアクションは最後の決断だ。

スケジュール型とプロアクティブ型ループ：あなたがトリガーを手放し、システムがクラウド上で処理を走らせて PR を開き、あなたはマージするかを決める

この仕組みが今になって注目を集めているのは、モデルとフレームワークの二つの歯車が協調して進化しているからだ。METR のタイムホライズンテストによれば、Claude 3.7 Sonnet がタスクの半数を完了できる最長時間は約59分だったが、Opus 4.5 では約4時間49分まで伸びている（METR 公式数値、信頼区間は1時間49分から20時間25分、サンプルはまだ少ない）。モデルが強くなると同時に、フレームワークはシンプルになる。以前はコンテキストを繰り返しリセットしなければ維持できなかった手法を、新しいモデルは訓練だけで解決してしまうことが増えた。フレームワークの複雑さはそれに応じて下がる。この協調進化が、以降のすべての話の背景にある。

これは何の問題を解決するのか

loop engineering を生み出した推進力は、三つの具体的な問題だ。Anthropic のエンジニアリングチームが2026年5月に開催したワークショップ（Ash Prabaker と Andrew Wilson が登壇）では、長時間動作する agent が直面する問題を三種類に分類している。第一に、コンテキストの制約——ウィンドウは有限で、忘れ、劣化する。第二に、計画能力の弱さ——大規模言語モデルは本質的に計画が苦手で、途中で止まって半端な状態のまま残すことが多い。第三、そして最も重要なのは：モデルが自分の出力の品質を安定して判断できず、まだ完成していない機能を完成したと誤認する。

初期の解法では不十分だった。単一モデル・単一セッションで build・check・fix のサイクルを回し続け、履歴を圧縮して自己修正するやり方だ。この手法の致命的な弱点は、まさに三番目の問題にある。自分でスタンプを押して承認し、最終的には壊れた土台を無限に修正し続けるループに陥る。Anthropic がよく引用する原則がここに刺さる。予測可能な失敗の方が、予測不可能な成功より優れている。

新しい解法はどう対症するか。コンテキストの問題には構造化されたファイルによる引き継ぎを使い、モデルの記憶に頼らない。計画の問題には planner agent が曖昧な要件を仕様と複数のスプリントに分解する。そして最も重要な三番目の問題への解法は、生成と評価を二つの独立した agent に分けることだ。それぞれが独立したコンテキストと独立した system prompt を持ち、GAN の敵対的生成から着想を得ている。Ash はあのワークショップでこう直接的に言った。絵を批評することは自分で描くより遥かに簡単だ——だからこそ、生成者に自己批評を求めるより、厳格な独立した評価者を育てる方が現実的なのだ。

この手法を実際に機能させる鍵は、作業開始前のひと手間にある。生成と評価の二つの agent が着手前に「このフェーズが完了するために満たすべき条件」をあらかじめ合意しておく。Anthropic の実測ケースでは、あるフェーズ（level-editor sprint）だけで27項目のテスト可能な条件を詰め、それぞれに明確な閾値が設定された。一項目でも未達なら、そのフェーズは失敗とみなされ、生成側は具体的なフィードバックを受けてやり直す。

📊 一次実測データ

  • 単一 agent で同じ課題（レトロゲーム制作ツールの構築）：20分・9ドル、何とか動く雛形が完成
  • 計画・生成・評価の三役を分けた完全なフレームワーク：6時間・200ドル、本当に使えるアプリ RetroForge が完成
  • 余分にかかった約6倍の時間のほぼすべては「完了の定義を合意すること」と「それを厳格に検証すること」に費やされた。これが成果物が使えるかどうかを分ける

Anthropic 自身もひとつの注意を残している。モデルが強くなり、フレームワークがシンプルになっていくのは協調進化だが、フレームワークという層が消えるわけではない。彼らの言葉を借りれば「面白い harness の組み合わせはモデルが強くなるほど減るのではなく、場所を変えるだけだ」——古いものがモデルに吸収され、新しい能力がまた新しい組み合わせの空間を開く。この言葉をどう活用するかは、自分のタスクが今どのフェーズにあるかによる。モデルがまだ対応できない部分には、フレームワークが引き続き必要だ。

これは自分の翻訳システムとどう関係するか

Anthropic が〈Building Effective Agents〉で生成と評価という構成要素の例として挙げているのは、まさに文学翻訳だ。翻訳には細かなニュアンスが多く、一回目のモデルがすべて拾えるとは限らないが、独立した評価モデルなら有益な批評を返せる、と説明している。これはちょうど数ヶ月前に自分が作り始めた会議翻訳品質エンジニアリングシステム、TQEF と重なる。複数経路の音声認識が異なるエンジンに接続し、モデルが翻訳し、後処理を経て段落ごとの訳文を出力する——これが生成側だ。評価器が五つの次元を持つルーブリックで各段落を採点する。術語・流暢さ・文脈・フォーマット・致命的エラー。通過しなければやり直す——これが評価側だ。五つのソースが合流し、スケジュール常駐でコーパスを蓄積するのが、全体を支える基盤設備だ。

この公式フレームワークを読んでから作り始めたわけではない。自分で一周ずつ壁に当たりながら、同じ構造に辿り着いた。ただ、公式の示範よりもう一歩先まで考えていた。評価器の prompt を調整するだけでなく、評価器自体が正確かを検証するフェーズ（Stage B）を設けるべきだと。別の指標と交差比較し、専門家の採点で校正し、同一データセットを繰り返し処理したときの安定性を確認する、そういうフェーズだ。だが実はこのフェーズ、まだきちんと終わらせていない。他の優先事項の後ろに控えたまま、正直に言えば未完のままの課題だ。これはまさに前述の原則への応答だ。ループは生成と評価を分ける手助けをしてくれるが、「翻訳の一文が合格とはどういう状態か」を先に自分が言語化しなければ何も始まらないし、その物差し自体が正確かどうかも、自分で検証するしかない。

この道を一度辿って、いくつかの日常の作業原則を導き出した。手作りの構成要素には「なぜ存在するか」を一文書いておく。モデルのアップグレード時は足し算より引き算を先にする。力を注ぐべきは評価器と評価基準だ——モデルが変わっても消えない。ループを積み重ねることへの投資はやがてモデルに吸収される。ひとつの不合格を単体で修正するのでなく、それをシステムに組み込んで以降のすべての処理に活かす。token の制御も層を選ぶ。/goal の評価器には安価なモデルで十分だ。停止条件を明確に書けば、確実性の高いステップはスクリプトに任せられる。毎回ゼロから考えなくていい。

loop engineering はあなたが「どう動かすか」を手放す手助けをする。コンテキストをどう収集し、どう行動し、どう検証するか——これらは自動化できる。自動化できないのは、「正しく動いたとはどういうことか」を定義すること自体だ。その基準は、誰かが先に言語化しなければならない。

この記事ではフレームワーク自体の整理に留めた。自分がこの数ヶ月で同じ構造にどう独力で辿り着き、翻訳システムのどこで躓いたか、それは次回に詳しく話す。

参考資料

Anthropic／Claude Code 公式一次資料

その他の一次資料

  • Boris Cherny（Claude Code 責任者），Sequoia AI Ascent 2026 インタビュー：冒頭の引用の出典となったインタビューそのもの。この一言は後に切り抜かれ広く拡散したが、本記事は二次的な転載版ではなくインタビュー本体を引用している
  • Addy Osmani，Loop Engineering：この概念を正式に命名した原著記事