プロンプトからシステム設計へ：自律型AIエージェントを動かす「ループエンジニアリング」の台頭
2026年6月22日 21:55
AIコーディングツールの進化に伴い、開発者が手動でプロンプトを入力する時代から、自律型エージェントのワークフローを設計する「ループエンジニアリング」の時代へと移行しつつある。このアプローチは開発効率を劇的に向上させる可能性を秘める一方で、トークンコストの急増という新たな課題も浮き彫りにしている。開発者は、自律ループを安全かつ効果的に運用するために、検証モデルの導入や予算制限などのシステム設計手法を確立する必要がある。
■プロンプトの終焉と「ループエンジニアリング」の誕生
AnthropicでClaude Codeの開発責任者を務めるボリス・チェルニー氏は、プロンプトを書くのをやめたという。ターミナルベースの自律型コーディングツールであるClaude Codeのクリエイターである同氏は、2026年6月のインタビューで、自身の仕事の変化について次のように語った。「私はもうClaudeにプロンプトを投げない。ループを走らせてClaudeにプロンプトを送り、次に何をすべきかを判断させている。私の仕事はループを書くことだ」
この発言は、OpenAIのエンジニアであるピーター・スタインバーガー氏によってもほぼ同時に同調され、さらにGoogleのエンジニアであるアディ・オスマニ氏が広く共有されたエッセイの中で「ループエンジニアリング」と名付けて体系化した。これは、開発者が過去2年近くにわたって構築してきたパラダイムシフトを明確に定義したものである。しかし、このシフトには熱心な支持者たちも慎重に付け加える警告がある。それは、自律エージェントのループにおけるトークンコストは、ほぼすべての開発者の予想を超えるスピードで累積し、検証器のない放置されたループは、高い確信度でバグを量産する機械になりかねないという点だ。
このシフトが起きた理由を理解するには、製品発表には現れない大規模言語モデル（LLM）のアーキテクチャ上の本質を理解する必要がある。LLMは「ステートレス（状態を保持しない）」であり、セッション間で何も記憶しない。今日プロンプトを入力したエージェントは、昨日指示したタスクを覚えていない。プロジェクトのルール、過去の決定、タスク途中の暫定結果など、永続的なコンテキストはすべて、ディスク上のファイルやGitリポジトリ、構造化されたメモリドキュメントなど、モデルの外部に保持しなければならない。この制約はClaude Codeに限らず、すべてのトランスフォーマーベースのモデルに共通する特性である。ループエンジニアリングは、この制約に対するシステム設計側からの回答である。コンテキストを頭の中に保持して手動でプロンプトを再入力する代わりに、外部でコンテキストを保持し、何をプロンプトとして送るかを決定し、エージェントを派遣し、作業が完了したかをチェックする小さなシステムを構築する。これにより、開発のレバレッジは、単一のプロンプトの品質から、プロンプトを生成・検証するシステム全体の設計へと移行する。
■1ターンずつのプロンプト操作が限界を迎えた理由
AIコーディングエージェントが登場してからの最初の2年間、標準的な対話モデルはシンプルだった。プロンプトを書き、コンテキストを追加し、出力を読み、次のプロンプトを書くという、開発者が常にツールを操作し続けるモデルである。しかし、このモデルには限界がある。関数の作成や特定のバグ修正といった単発のタスクであれば十分に機能するが、複数ステップを要し、フィードバックに適応し、エンジニアが他の作業をしている間にバックグラウンドで実行するようなタスクでは、手動によるオーバーヘッドで破綻してしまう。
米メディア「The New Stack」の2026年6月の報道によると、過去18か月における開発者ツールの進化は以下のように整理されている。まず「プロンプトエンジニアリング」から始まり、適切な情報をモデルに届ける「コンテキストエンジニアリング」へと移行した。その後、単一のエージェントが動作する環境を設計する「ハーネスエンジニアリング」へと進み、最終的に、ハーネス自体がタイマーで動作し、ヘルパーを生成して自己フィードバックを行う「ループエンジニアリング」へと行き着いた。ハーネスとループを分ける決定的な技術的違いは、cronジョブが固定されたスクリプトを実行するのに対し、エージェントループはモデルが現在の状態を読み取り、自ら次の行動を決定する点にある。
■エージェントループを構成する6つの要素
自律エージェントループの基礎となるアーキテクチャは、2022年にプリンストン大学とGoogleの研究者らが発表した「ReAct」フレームワークに遡る。ReActは、推論と行動を繰り返すサイクル（モデルが必要なものを考え、行動を起こし、結果を観察し、再び考える）を交互に行う。このサイクルは、標準的なタスクベンチマークにおいて、シングルパス（一括処理）モデルを上回る性能を示すことが実証されており、現代のあらゆるAIコーディングエージェントの基礎となった。Claude CodeやOpenAIのツールも、このパターンを実装している。
Claude Codeにおけるサイクルは次のように動作する。エージェントは、会話履歴と利用可能なツールの定義が含まれたプロンプトを受け取る。現在の状態を評価して次の行動を決定し、それがファイルの読み込み、テストの実行、コードの編集といったツール呼び出しを必要とする場合は、その呼び出しを実行する。結果がコンテキストに返され、再びサイクルが始まる。これは、モデルがタスク完了と判断するまで繰り返される。
アディ・オスマニ氏が2026年6月7日のエッセイ「Loop Engineering」で特定した6つのビルディングブロックは、Claude Codeの現在のコマンドセットとほぼ正確に一致している。
1. 自動化（Automations）：タイマー、Gitイベント、CIシグナルなどによってループを自動的に開始するトリガー。Claude Codeでは「/schedule」や「/loop」コマンドがこれに該当する。
2. ワークツリー（Worktrees）：並行して動作するエージェントが互いの作業を上書きしないようにするための隔離環境。Claude Codeの「--worktree」フラグを使用すると、クリーンアップ機能付きの新しいGitチェックアウトが生成される。
3. スキル（Skills）：プロジェクト固有の知識を固定し、セッションごとに再学習するのを防ぐ保存された指示セット。「SKILL.md」ファイルとして保存され、チーム全体で共有できる。
4. コネクター（Connectors）：Model Context Protocol（MCP）ベースのプラグインで、GitHub、Slack、Linear、外部APIなどの実ツールへのアクセスをループに提供する。
5. サブエージェント（Sub-agents）：「作成者」と「検証者」の分離。コードを書くサブエージェントと、テストを実行してエラーを報告する別のサブエージェントを分けることで、自作自演の評価を防ぐ。
6. メモリ（Memory）：セッションをまたいで永続化される外部状態。Claude Codeが起動時に自動で読み込むプロジェクトレベルの「CLAUDE.md」ファイルが代表例である。エージェントが同じ間違いを繰り返した際、その修正内容をCLAUDE.mdに書き込ませることで、以降のすべてのセッションに修正が反映される。
■「/goal」コマンドと検証モデルの役割
単なるプロンプトの繰り返しと、目標条件付きのループを分ける具体的なメカニズムが、2026年5月11日の週にClaude Codeバージョン2.1.139で追加された「/goal」コマンドである。開発者が「test/auth内のすべてのテストをパスし、linterのエラーをなくす」といった目標を設定すると、Claude Codeはコードを書いたのと同じモデルに完了判定を行わせるのではなく、各ターンの後に完了条件をチェックするためだけに設計された、別の高速なモデルを使用する。つまり、作業を行うエージェントと、その作業が完了したかを評価するエージェントは、異なるモデルインスタンスとなる。
オスマニ氏はこの重要性について、ループを曖昧な目標に向けると、価値あるものを生み出すか、あるいは「低品質なコードを高速で生成する非常に高価な機械」になってしまうかのどちらかだと指摘している。コードを書くジェネレーター（生成モデル）は非常に有能になったが、出力が実際の基準を満たしているかを判断するベリファイアー（検証モデル）の設計が不十分な場合、ループは失敗する。曖昧な成功基準を受け入れてしまう検証器は、エラーを出さずに、次の開発者が解きほぐさなければならないようなコードを自信満々にデプロイしてしまう。
■Dynamic Workflowsがもたらすアーキテクチャの進化
2026年5月28日、Anthropicは「Claude Opus 4.8」の研究プレビューと同時に「Dynamic Workflows（ダイナミックワークフロー）」を発表した。この機能がもたらすアーキテクチャ上の変化は、エージェントの数を増やすことではなく、オーケストレーション（調整）プランをモデルのコンテキストウィンドウから完全に排除した点にある。従来のマルチエージェントパターンでは、サブエージェントがターンごとに呼び出され、すべての中間結果が共有コンテキストウィンドウに蓄積されていた。この蓄積が、長時間の自律タスクにおける最大の制約となっており、数十万行のコードにわたる移行作業などはコンテキストウィンドウに収まりきらなかった。
Dynamic Workflowsでは、Claudeがタスクに応じたJavaScriptのオーケストレーションスクリプトを書き、それをバックグラウンドのランタイムが実行する。ループ、分岐、エージェント数の決定、検証パスなどの制御ロジックは、モデルの作業メモリではなく、スクリプトの変数内に保持される。これにより、各サブエージェントはクリーンで整理されたコンテキストウィンドウを受け取ることができる。公式ドキュメントによると、1回のワークフロー実行で最大1,000のエージェント（同時実行は16）を組み込むことが可能だという。Salesforceの報告によると、従来は231日かかっていた移行作業を、この機能を用いて13日に短縮できたという。
■見過ごされがちな「トークンコスト」の現実
ループエンジニアリングの議論において、広く見過ごされているのがコストの問題である。エージェントループのコストは、通常のプロンプトとは比較にならない。ループ内でのツール呼び出しは、その後のすべての呼び出しにおいてコンテキストとしてモデルに再送信される。ファイルの読み込みを伴うループが20回繰り返される頃には、累積入力は1回あたり5万トークンを超えることがある。Claude Opus 4.8の現在の価格である100万入力トークンあたり5ドル（約810円、1ドル=162円換算）で計算すると、ループ後半の1ステップだけで約0.25ドル（約41円）のコストがかかる。曖昧なタスクに対して200回イテレーションを実行するループでは、コストは80ドル（約1万2,960円）以上に達する。これに対し、適切に範囲を絞ったシングルプロンプトであれば、1ドル（約162円）未満で済む。ある30の開発チームを対象とした分析では、1人の開発者が週末に自律リファクタリングを実行した際、API利用料が4,200ドル（約68万400円）に達した事例が報告されている。
企業における実例もこれを裏付けている。報道によると、Uberは2026年のClaude Code向けAI予算をわずか4か月で使い果たした。エンジニア1人あたりのAPIコストは月額500ドルから2,000ドル（約8万1,000円〜32万4,000円）に達し、4月時点での利用率は95%に達していたという。また、WindowsやMicrosoft 365を管轄するMicrosoftのExperiences and Devices部門は、トークンベースの課金によって年間AI予算が予定より早く枯渇したため、2026年6月にClaude Codeのライセンスの大部分を終了したと報じられている。Anthropic自身が公表している企業向けデータでも、最適化を行う前の段階で、開発者1人あたり平均月額150ドルから250ドル（約2万4,300円〜4万500円）のコストがかかるとしている。
オスマニ氏はエッセイの中で、「まだ初期段階だ。私は懐疑的であり、トークンコストには絶対に注意しなければならない」と慎重な姿勢を示している。同氏や実務家が指摘する主な失敗パターンは、低品質な成果物を自信満々にデプロイしてしまう「脆弱な検証器」、チームの理解を超えるスピードでコードがデプロイされる「理解の負債」、そしてループが出力したものを無批判に受け入れてしまう「認知の放棄」の3点である。適切に設計されたループは優れたエンジニアの生産性を何倍にも高めるが、誤った決定も同じ速度で増幅させてしまう。
こうした状況を受け、Anthropicは2026年6月15日から料金体系を厳格化した。Agent SDK、claude -pスクリプト、GitHub ActionsでのClaude Codeを介した自動ワークロードは、インタラクティブな利用とは別の月額クレジットプール（Proプランは20ドル（約3,240円）、Maxプランは最大200ドル（約3万2,400円））から引き落とされるようになり、クレジットが枯渇すると自動リクエストは停止する仕様となった。
■安全なループを構築するための4つの原則
価値を生み出すループと、請求額を膨らませるだけのループを分けるのは、実行前の4つの設計判断である。
1. 検証可能な成功条件の定義：「バグを直す」ではなく、「/tests/unit/内のすべてのテストが終了コード0でパスし、/src/以外に新しいファイルが作成されないこと」のように定義する。別の評価モデルが機械的にチェックできないタスクは、自律実行に回すべきではない。Claude Codeの/goalコマンドは、各ターンの後に独立した高速モデルでこの完了チェックを実行する。
2. 予算（上限）の設定：「--max-turns」フラグを使用してイテレーション回数を制限する。制限がない場合、曖昧な目標を設定されたループは、APIのハードリミットに達するか、月額クレジットが尽きるまで回り続ける。公式ドキュメントでも、オープンエンドなタスクでは予算設定をデフォルトにすることを推奨している。
3. 作成者と検証者の分離：コードを生成するサブエージェントと、テストやlinter、仕様書に照らして評価するサブエージェントを分ける。コードを書いたモデル自身に検証を行わせると、過剰に成功と判定しがちになる。/goalコマンドの評価モデルはこの分離を自動で行うが、カスタムワークフローでは明示的な設計が必要となる。
4. 並行作業におけるワークツリーの活用：複数のサブエージェントが同じリポジトリを触る場合、隔離環境がなければファイルの衝突が避けられない。Claude Codeの「isolation: worktree」設定は、サブエージェントごとに新しいGitチェックアウトを生成し、実行後に自動でクリーンアップする。これを怠ると、マージコンフリクトだけでなく、実行中にエージェント同士が変更を上書きし合う予測不可能な状態を招く。
■システムエンジニアリングとしてのループ設計
2026年6月7日の議論（スタインバーガー氏の投稿、チェルニー氏の発言、オスマニ氏のエッセイ）を経て、ループエンジニアリングの語彙とプリミティブ（基本要素）は、Claude CodeやOpenAIのツールに標準機能として組み込まれるようになった。かつてはBashスクリプトを書いて維持する必要があった仕組みが、今や製品内部に統合されている。
しかし、変わらない本質は、ループエンジニアリングが「AIのスキル」ではなく「システムエンジニアリングの規律」であるという点だ。モデルのステートレス性という制約は、プロンプトを工夫するだけでは解決しない。永続的な状態は、ファイルやGit、そして「CLAUDE.md」といった外部の仕組みに持たせる必要がある。ループを最も効果的に使いこなすエンジニアとは、プロンプトを上手く書く人ではなく、最も精密な検証器を設計し、具体的な完了条件を設定できる人である。開発におけるレバレッジのあり方は変わったが、その設計という営み自体が簡単になったわけではない。
■注目ポイントQ&A
●Claude Codeにおける /loop と /goal の違いは何ですか？
/loopは定期的なスケジュール（5分ごと、1時間ごとなど）でプロンプトを実行するもので、プルリクエストの仕分けやCI（継続的インテグレーション）の監視といった定常的なタスクに適しています。一方、/goalは指定した完了条件が満たされるまで自律的に処理を繰り返すコマンドです。/goalでは、コードを作成するモデルとは別の高速な検証モデルが毎ターン完了判定を行うため、特定の成果物に向けた自律的な作業に適しています。
●エージェントループのコストが通常のプロンプトより高くなるのは原因は何ですか？
エージェントループでは、ツールを呼び出すたびにコンテキストが蓄積され、その後の呼び出しでモデルに再送信されるためです。例えば、ファイルを読み込むループが20回繰り返されると、1回あたりの入力が5万トークンを超えることがあります。Claude Opus 4.8の料金（100万入力トークンあたり5ドル、約810円）で換算すると、ループ後半の1ステップだけで約0.25ドル（約41円）かかり、200回繰り返すセッションでは80ドル（約1万2,960円）以上のコストが発生することがあります。このため、2026年6月15日の改定により、自動ワークロードは定額サブスクリプションとは別の専用クレジット枠に分離されました。
●/goal における検証モデル（verifier model）とは何ですか？
開発者が設定した完了条件が満たされているかどうかを、各ターンの後にチェックする独立した高速なモデルのことです。コードを生成したモデル自身に検証を行わせると、過剰に「成功した」と判定しがちになるため、アーキテクチャ上、作成と検証の役割を分離することが重要です。検証モデルが不十分な場合、ループはエラーを出さずに低品質なコードを量産してしまいます。
●ループエンジニアリングはClaude Code以外のツールでも使えますか？
はい、使えます。このパターンはOpenAIのツールにおける自動化機能、/goalコマンド（CLIバージョン0.128.0で追加）、ワークツリー、スキルなどの機能にもほぼ同様に当てはまります。ツールの名称は異なりますが、必要とされるシステムアーキテクチャの要件は共通しています。
元記事: Claude Code Loop Engineering: Stop Prompting, Start Designing Autonomous Agent Workflows