記事のサマリー（TL;DR）
- Claude Code 作者の Boris Cherny が Meta @Scale で「エージェントループはハイプではなく本物」と明言
- コードアーキテクチャ改善・重複抽象化の統合を行うエージェントが常時 PR を出し続ける構成を自社運用
- トークン消費はチャットボットより桁違いに多く、コスト管理が普及の鍵
国内 Claude Code・AI エージェント導入企業が押さえるべきコスト設計の論点
エージェントループは「タスクを指示して完了を待つ」従来のエージェント活用から一歩進み、複数エージェントがバックグラウンドで常時稼働し続ける構成です。Cherny 自身が実際に運用している例では、コードアーキテクチャの継続的改善とコード重複の検出・統合を担う 2 つのエージェントが、人間のコードレビューと同様に PR を提出し続けています。
日本国内でも Claude Code の採用が広がる中、この「ループ型」運用への移行を検討する際にコスト面の試算が不可欠です。チャット型 AI の数倍から数十倍のトークン消費が想定されるため、ループの停止条件・トークン上限・ドリフト監視の仕組みをあらかじめ設計しておく必要があります。kintone や Salesforce の業務システムに接続した MCP 構成でループを回す場合、API コール数の急増が外部サービス側のレート制限にも影響し得るため、接続先ごとのスループット設計も課題になります。
詳細
「ループはハイプではなく本物」——Boris Cherny が Meta @Scale で断言
2025年6月のMeta @Scale カンファレンスで、Claude Code の作者 Boris Cherny は聴衆から「ループは次のハイプサイクルなのか、それとも本物か」という質問を受け、即座に「本物だ」と答えました。
Cherny はその理由をこう説明しています。「2年前、私たちはソースコードを手で書いていた。次にエージェントがコードを書くようになった。そして今、エージェントがエージェントにプロンプトを送ってコードを書かせる段階に移行しつつある。ソースコードからエージェントへの転換と同じくらい大きな一歩だ」。
Cherny 自身が日常業務で回している 2 つのループ
カンファレンス動画の約 32 分地点で、Cherny は自身が実際に動かしているループの具体例を紹介しました。
- コードアーキテクチャの継続改善エージェント：常時コードベースをスキャンし、構造的な改善点を探して PR を提出し続ける
- 重複抽象化の統合エージェント：コード全体に散在する重複実装を検出し、統合案を PR として出し続ける
コードは常に変化し続けるため、これらのエージェントは停止せず無限に稼働します。
「ループ」の技術的背景——再帰ループと Ralph ループ
エージェントループの概念自体は完全に新しくはありません。再帰ループ（関数が自分自身を呼び出し、一定条件で停止する）はコンピュータサイエンスの基礎概念として長く存在してきました。エージェントループが異なるのは、停止条件が明示的なルールではなく、サブエージェント自身が「タスクが完了したかどうか」を判断する非決定論的なロジックである点です。
実用上よく使われる手法として、Ralph ループ（アニメキャラクター Ralph Wiggum にちなむ）があります。これはモデルがこれまでの作業全体を要約し「目標を達成したか」を自問する仕組みで、長時間実行時にモデルが迷走するのを防ぐための「リセット機構」として機能します。
テスト時計算量（test-time compute）との関係
OpenAI の研究者 Noam Brown が今月初めに指摘した通り、「十分な計算量を投入すれば現代のモデルはほぼあらゆる問題を解ける」という知見は、ループの正当性を支える理論的背景になっています。
特にコードベースの改善のようなヒルクライミング型の問題では、モデルが閾値に達するまで小さな改善を積み重ね続けることができます。Cherny の例でいえば、計算リソースが続く限り改善を続けることに上限はありません。
コストの問題——トークン消費に上限がない
エージェントループの最大の課題はコストです。チャットボットのような単純な Q&A と比べ、エージェントループはトークンを桁違いに消費します。さらに「ループを常時稼働させることがポイント」であるため、支出に上限を設けなければ青天井になります。
Anthropic にとってはトークンを売り続けることがビジネスモデルであるため、ループが普及するほど収益につながります。一方、利用企業にとっては、適切な監視体制——トークン支出の上限設定、ドリフト検知、ループの停止条件設計——を整えなければ、コストが想定外に膨らむリスクがあります。
問題の性質とセットアップが適切であれば、コストに見合う成果を得られる可能性は十分にありますが、そのための設計が普及の前提条件となります。