Claude Code責任者が明言：「もう直接AIにプロンプトを書かない」──Loop Engineeringとは何か？

はじめに

このところ、シリコンバレーで最も話題になっているトピックは：

Loop Engineering、循環工学、略してLEだ。

6月7日、Google Cloud責任者のAddy Osmaniがブログ記事を公開し、熱烈な議論を巻き起こした。

OpenClawの作者であるPeter Steinberger（江湖では「エビ親父」と呼ばれる）はこう述べている：

もはやコーディングエージェントにプロンプトを書くべきではない。ループを設計し、エージェントにプロンプトを書かせるべきだ。

AnthropicのClaude Code責任者Boris Cherny（Claudeの生みの親）もこう語る：

私は今、私はもう直接Claudeにプロンプトを書いていない。ループの仕組みが動いていて、それがClaudeにプロンプトを書き、次に何をすべきかを判断する。私の仕事はループを書くことだ。

発言者が誰かに注目してほしい──一人はClaude Codeの生みの親、もう一人はAIプログラミングツールのベテランだ。二人とも同じことを言っている：

直接AIにプロンプトを書くという行為は、今や時代遅れになりつつある。

これは単なるコンセプトの煽りではない。最前線のエンジニアが日常業務の中で自然に進化させてきたパラダイムだ──十分に使い込めば、手動プロンプトの非効率さに気づき、システムを自走させる方法を模索し始める。

この2年間、私たちはどうコーディングエージェントを使ってきたか

過去2年間、コーディングエージェントに作業させる基本的なやり方はこうだった：

• プロンプトを書き、十分なコンテキストを提供する。
• 内容を入力し、返ってきた結果を読み、次の入力をする。
• エージェントは道具であり、人間がラリーのように一往復ずつ操作する。

この人機卓球モードでは、人間がAIのリアルタイムディスパッチャーを務める。タスクが複雑になれば、人間の忍耐とタイピング速度がシステムのボトルネックになる。

本質的にこれはスケーリングのボトルネックだ：10人のエージェントを監視してリアルタイムでプロンプトを投げるために10人を雇うことはできない。人間の注意力は希少資源であり、それをすべてAIのディスパッチャー役に費やすのは莫大な浪費だ。

パラダイムシフトは明確だ：

• PE（Prompt Engineering）は人間がAIに答えを与える──命令型、AIにどう動くかを一歩一歩指示する
• LE（Loop Engineering）は人間がAIの自動進化エンジンを構築する──宣言型、成功の姿だけを伝え、道筋はAI自身に探させる

この比喩は適当なものではない。命令型から宣言型への移行は、プログラミングパラダイム史上で最も重要な転換の一つだ。SQLが手書きループより効率的なのは賢いからではなく、「どう実行するか」の詳細をエンジンに任せたからだ。LEも同じことをやっている──「どう一歩ずつプロンプトを書くか」という詳細を、Loopシステムに委ねているのだ。

どう話せばより正確になるかを悩むのではなく、このループの法則を設計する：目標と品質基準を定め、残りはシステムに自己博弈的な反復で完遂させる。これからの競争力は「プロンプトが書ける人」ではなく、「最も賢く、最も閉じたシステムのルールを定められる人」にある。

Claude Codeの/loopコマンドが典型例だ。

Loop Engineeringは「自らエージェントにプロンプトを書く」ことを置き換えつつある。核心は：

エージェントに直接プロンプトを書かず、システムを設計してエージェントにプロンプトを書かせることだ。ループとは再帰的な目標である：目標を定義し、AIに反復させ続け、タスクが完了するまで走らせる。

Loop Engineeringの5大コアコンポーネント

Addy Osmaniのブログ記事にはフレームワーク図が示されており、12時の方向から時計回りに見ると：

LEは5つの構成要素で成り立つ：

• Automations 自動化：スケジュールに基づき自動的にトリガー、発見、トリアージを行う。
• Worktrees ワークツリー：並列作業する2つのエージェントが互いに干渉しないようにする。
• Skills スキル：プロジェクト知識を文書化し、エージェントが推測に頼らなくて済むようにする。
• Plugins プラグインとconnectors コネクタ：エージェントを既存ツールに接続する。
• Sub-agents サブエージェント：一つがアイデアを出し、もう一つがチェックする。

さらにmemory（ステート）がある：Markdownファイル、Linearボード、または単一の会話の外部に存在し、「完了事項」と「次のアクション」を保存できるあらゆる場所だ。

これら5つのコアモジュールはClaude CodeとCodexの両方に既に備わっている：

各モジュールの動作ロジック：

定時自動化（Automations）：ループの心拍。スケジュールに基づき自動的にトリガーされ、発見と分類を行う。人の介入は不要。

並列ワークツリー（Worktrees）：複数のエージェントが干渉せず並列作業できる隔離メカニズム。ワークツリーがなければ、2つのエージェントが同一コードブランチで互いの変更を上書きし合い、ループは制御不能に陥る。

スキルによる知識定着（Skills）：プロジェクト知識を文書化し、エージェントが毎回推測に頼らなくて済むようにする。これは「あなただけが知っている」コンテキストを「エージェントも知っている」構造化入力に変える作業だ。私の見立てでは、5つのコンポーネントの中で最も過小評価されやすいのがこれ──システムの「記憶上限」を決め、ループの品質天井に直結する。

プラグインとコネクタ（Plugins and Connectors）：エージェントを既存ツールチェーン──GitHub、Linear、Slack、データベース──に接続する。ループは実環境の情報を読み取り、結果を環境に書き戻す必要があり、コネクタはこの双方向通路だ。

制作者と検証者を分離したサブエージェント（Sub-agents）：一つのエージェントが提案し、もう一つが検証する──作り手とレビューアーを本来的に分離する。これはループに内蔵された品質ゲートであり、単一エージェントのエラーが誰も気づかぬうちに拡散するのを防ぐ。

Loop Engineering ≠ cronジョブ

待て、見たところLEはただの定期実行タスクではないか？

多くの人の第一反応はそれだが、決定的な違いがある：cronジョブは決定論的だが、LEは適応的だ。

cronジョブは毎回まったく同じ操作を実行する──前回の結果が芳しくなくても戦略を変えない。一方、LEの核心はフィードバックループだ：システムは前回の出力に基づき、次回どう動くかを決める。LLMはコンテキストを読み、結果の良し悪しを理解し、それに応じて調整できる──これは通常のcronジョブにはできない。

まるで開発チームが新機能のフィードバックやユーザーの問題、ワークフローの改善を把握し、イテレーション計画を調整するように。LEはこの「理解→調整→再実行」のループをシステム内に埋め込み、自動で回すものだ。

YCのCEOGarry Tanは警告する：エージェントを「富士康工場」のような反復労働マシンにするな、開発者はエージェントにより多くの仕事を任せるべきだ、と。

だが同時に指摘もある：エージェントにもっと仕事をさせるには、明確な境界を定めなければならない──クリアなコンテキスト、信頼できるツール、監査可能な操作記録、安全な停止条件を提供することだ。

この警告は重要だ。LEは「AIを放任して走らせる」ことではなく、「ルールを設計し、そのルール内でAIを自走させる」ことだ。ルールがよければシステムは走るほど賢くなる；ルールが悪ければシステムは走るほどズレる──そしてあなたが気づくのは数十ラウンド後かもしれない。

LEの既知の3つの問題

① デバッグ難易度が高い

47ラウンドも回ったステートマシンのデバッグは、プロンプト修正の10倍難しい。しかも大半の人は、まともな一発プロンプトすら書けない。

• 最初のセットアップは簡単だが、その後多くの痛みが伴う。修正に手間取る。
• ループ導入を後悔し、他の方案へ移行するのに時間とリソースを費やし、仕方なく継続している人もいる。
• 早期移行を勧める声もあり、時間が経つほど状況は悪化するという。

ここには反直感的なアドバイスがある：LEはプロンプト能力への要求を下げるのではなく、上げるのだ。ループシステムの中で書くそのコアプロンプト──目標定義、受け入れ基準──が曖昧なら、数十倍に増幅されてエラーとして現れる。まず単発プロンプトを確実に書けるようになってから、ループ構築を検討するのが堅実な道だ。

② トークン消費が大きい

LEモードではトークン消費量が多い。Boris ChernyとPeter Steinbergerの裏にある会社はほぼ無制限のトークンを提供できるが、コミュニティの多くはトークン予算に限りがある。

どうするか？

• トークンに余裕がある企業はwhileループを使える
• トークンが逼迫するスタートアップはforループで目標実装ができる

Claude Codeはトークン消費問題に対し様々な制限を設けている：Loopsは最小1分間隔、最長3日間の実行、期限切れで自動停止；Loopsは現在のClaude Codeセッションに紐づき、ターミナルを閉じたりセッションを終了すると停止する；Loop無効化スイッチも提供されている。

視点を変えると：トークン消費が大きいことは、実は自然なフィルターとして機能する。真に価値ある場所──高価値、高反復性、人力処理コストがトークンコストを上回るタスク──にのみLEを使うよう強制するのだ。LEで回すトークンコストが節約できる時間を大きく超えるなら、そのタスクはそもそもLEに向いていない可能性が高い。

③ 長時間タスクの安定性

LEの焦点はエージェントを長時間走らせてもズレさせず、正誤を自己判断させることだ。

Anthropic応用AIチームのエンジニアAshによると、同社の探索方向はより「完全自律」寄りで、目標は人間の判断をハーネスに書き込むことであり、人間のフォールバックを挟むことではない。

昨年、Claude Codeは約20分しか連続稼働できずエラーも多かったものが、ほぼ自己記述により、数日間連続稼働可能へと進化した。

AnthropicエンジニアのAndrewは指摘する：エージェントを数時間〜数日連続稼働させる核心的難点は、コンテキスト、計画、自己判断の3点にある。これを解くためAnthropicは二つのアプローチを取っている：

• モデル自体を強化し、長時間タスク能力をモデル重みに組み込む；
• モデル外部のハーネスを改良する。

初期の長時間稼働エージェントは要件を持続可能なファイルに分解し、新しいコンテキストウィンドウで繰り返しタスクを実行することで、コンテキスト喪失とタスクドリフトを緩和していた。新モデルの能力向上に伴い、Anthropicはハーネスの簡素化を始めた。

• Opus 4.6は計画とツール選択に長け、Sonnet 4.6は低コストでOpusに近い実行能力を提供する。一般的な組み合わせはOpusで計画、Sonnetでコード実行。
• サーバーサイド圧縮と百万級コンテキストウィンドウにより、モデルは単一の長いセッションでより長くコヒーレンスを保てるようになった。

Anthropicが社内実験で試みている最先端のハーネスパターンは、生成器─評価器─計画器構造だ。生成的敵対ネットワーク（GAN）の思想を借りている。

この構造は別途強調しておく価値がある：GANが高品質な画像を生成できるのは、判別器が生成器に「ここがまだ足りない」と伝え続けるからだ。この思想をソフトウェア開発に持ち込めば、一つのエージェントがコードを書き、もう一つがケチをつける──二者が対抗的なプレッシャーを形成し、単一エージェントの反復イテレーションよりはるかに高品質なアウトプットが得られる。これはエンジニアリングテクニックの最適化ではなく、アーキテクチャレベルの思考だ。

私の判断：開発者の役割が再定義されている

Loop Engineeringの最も深い影響はツールにあるのではなく、開発者の仕事内容が構造的に変化している点にある。

これまでは：要件理解 → タスク分解 → コード記述 → デバッグ。

LE以後は：要件理解 → ループルール設計 → 受け入れ基準定義 → システム観察とチューニング。

これは実装層のエンジニアではなく、システムアーキテクトに近い仕事だ。要件を精確なループ目標に翻訳し、合理的な品質基準を設計し、システムがいつズレるかを判断する──これらの能力は「良いプロンプトが書ける」ことより遥かに難しく、遥かに価値が高い。

ゆえにLEは開発者がサボれるツールではなく、開発者の仕事をより抽象度の高いレイヤーへ引き上げるものだ。参入ハードルは下がったのではなく、上がったのだ。

Claude Codeとは？ どう使う？

Claude CodeはAnthropicが提供するAIプログラミングツールで、Copilotのようなコード補完とは異なり、タスクを自律的に分解し、複数ステップを実行するAIエンジニアのような振る舞いをする：ファイルの読み書き、コマンド実行、クロスファイルリファクタリング、自律的デバッグ、そして/loop、/workflows、サブエージェントなどLoop Engineeringに必要なインフラをネイティブサポートしている。

公式サブスクリプション：Claude Proプラン月額20ドル、Maxプラン月額100ドルから。

よくある質問

Q：Loop EngineeringとPrompt Engineeringの核心的違いは？
A：PEは命令型──人間が能動的にAIに指示を書き、AIが実行して結果を返し、人間が再介入する。LEは宣言型──人間が一つのシステムを設計し、システムが自動的にAIにプロンプトを書き、フィードバックを得て、次のラウンドをトリガーする。人間は目標と受け入れ基準を定義するだけ。両者のスキル要件は異なり、進化関係ではなく、方向性の転換だ。

Q：LEに適したタスクのタイプは？
A：3類型に適する：明確な目標があり結果を自動検証できるタスク（テスト実行と失敗修正など）、高反復性だが知的判断を要するタスク（Issueスキャンと分類など）、人力処理コストがトークンコストを大きく上回るタスク。逆に、一回限りの、創造性が強い、結果を定量化しにくいタスクには通常のプロンプトの方が適している。

Q：一般開発者は今すぐLEを使えるか？
A：使えるが、基礎固めを先にすることを勧める。Claude Codeの/loopと/goalコマンドにはLEの基本要素が備わっている。しかしループに乗る前に、まず確実な単発プロンプトが書けることを確認すべきだ──LEはプロンプトの問題を隠蔽するのではなく、増幅するからだ。

Q：LE最大のリスクは？
A：ズレても気づきにくく、修復が困難なこと。数十ラウンド回ってから方向間違いに気づくと、原因特定コストが極めて高くなる。早期に明確な停止条件を設定し、各ラウンドの中間結果を保持し、重要なノードには人間確認ゲートを挟むことを推奨する。