もうプロンプトは書かない時代へ — 「Loop Engineering」とは何か、なぜAIコーディングの主戦場がループ設計に移ったのか
はじめに
2026年6月、AIコーディングの界隈で「もうプロンプトを書くな」という挑発的なフレーズが急速に広まった。きっかけはClaude Code責任者のBoris Chernyの「自分はもうClaudeにプロンプトを出していない。ループを走らせているだけだ」という発言と、それをGoogleのAddy Osmaniがエッセイとして言語化したことだ。単発の指示文を磨く時代は終わり、エージェントが自律的に回り続ける「ループ」そのものを設計するスキルが価値の源泉になりつつある——これが Loop Engineering という考え方だ。本記事では、この潮流がなぜ生まれたのか、ループ駆動のエージェント運用は具体的にどう組み立てるのか、そして見落とされがちな深刻な落とし穴までを、実務エンジニアの視点で整理する。
ニュースの詳細 — 「プロンプト単発」からの脱却宣言
発端は2026年6月8日、開発者Peter Steinbergerが投稿したわずか2文のX投稿だった。「開発者はコーディングエージェントに指示を出すのをやめ、エージェントに指示を出す“ループ”そのものを設計し始めるべきだ」という主張は、瞬く間にコミュニティ全体へ拡散した。これを受けてAddy Osmaniが同月のエッセイで概念を結晶化させ、「Loop Engineering」という呼び名が定着した。
象徴的なのは、Boris Chernyの「もうプロンプトは書いていない、ループを走らせている」という言葉だ。これは単なるレトリックではなく、現場の作業実態の変化を表している。従来は「良いプロンプトを1回書いて1つの答えを得る」ことが目的だったが、いまや「目標を与えると、コードを書き換え→テスト実行→失敗ログを読む→方針修正→再試行、を自動で繰り返すシステム」を組むことが主眼になっている。
across studio blogの記事は、この変化をAI活用の世代進化として整理している。Prompt Engineering（2022〜2024、指示の質）→ Context Engineering（2025、文脈の質）→ Harness Engineering（2026年初頭、実行環境の質）→ そして現在の Loop Engineering（サイクル設計そのものの質）という4段階だ。レバレッジの源泉が「いいプロンプト」から「いいループ設計」へと移動した、という捉え方である。
技術的な背景 — ループを構成する6つのモジュールと5ステップ
Loop Engineeringの本質は「act → observe → reason → repeat（行動→観測→推論→反復）」というサイクルを、停止条件付きで安全に回す仕組みづくりにある。記事ではこれを支える6つのコアモジュールが挙げられている。
- Automations：定期実行やイベント起動で、エージェントがタスクを自動で拾い上げる
- Worktrees：複数エージェントを並行実行するための分離レイヤー（ブランチ単位の隔離）
- Skills：ビルド手順・仕様・既知の罠をまとめたナレッジファイル
- Sub-agents：別モデルによる粗探し・検証専任のエージェント
- Connectors：MCP経由でLinearやGitHub、各種APIと連携
- Memory：markdownやボードなど外部に状態を記録する仕組み
そして実際のループは、次の5ステップの方法論として設計される。(1) 目標契約 — 「P95読み込み時間を◯ms以下」のように完了基準を定量化する。(2) Agent実行 — 複数ツール/インスタンスで並列に作業させる。(3) 証拠駆動フィードバック — テスト結果・ログ・CI出力を必須の入力にする。(4) 停止条件 — 合格・ロールバック・人間への引き渡し・タイムアウトのいずれかで止める。(5) 経験還元 — ルールやSkills、harnessを更新して次サイクルを最適化する。
ここで決定的に重要なのは、ステップ(1)の「目標契約」と(4)の「停止条件」だ。explainx.aiの解説も「良いループは永遠には走らない。予算・ゲート・ログ・エスカレーションポイントを持つことが、本物とおもちゃの差だ」と指摘する。各反復はトークン・ツール呼び出し・CI時間・レビュアーの注意を消費するため、無制限に回るループは“高速な誤生産装置”になりかねない。
エンジニアへの影響 — 何が変わり、何に気をつけるべきか
実務への影響は大きい。向いているのは、CIの赤信号修復、テスト補完、ログ巡回、ドキュメント同期、依存関係更新といった「受け入れ基準を明確に定義でき、証拠（テスト/CI）で合否を機械判定できる」タスクだ。これらは目標契約と停止条件を書きやすく、エンジニアが寝ている間にPRやチケットが進む、という運用が現実になる。
一方で、避けるべき領域もはっきりしている。美的判断を伴うUI作業、複数システムの権限を横断する操作、受け入れ基準のない大規模改修——これらは自動ループに載せると暴走リスクが高い。導入時はまず「CI修復」のような鉄板タスクから始め、品質ゲートとして「証拠の義務化」と「停止条件の明確化」を必ず組み込むのが定石とされる。
ただし、本記事が最も強調するのは3つの“罠”だ。検証の死角：エージェントの「完了しました」は自己申告に過ぎず、証拠がなければ信用できない。Comprehension Debt（理解の負債）：自分が書いていないコードが増え続け、いざデバッグする段になって誰が何を書いたか分からなくなる。Cognitive Surrender（認知的降伏）：「AIがそう言うから」が口癖になり、自分で判断基準を持つことを放棄してしまう。Addy Osmaniの警告が鋭い——「判断力を持ちながら使えば解毒剤、逃げるために使えば促進剤。同じ行動でも結果は正反対だ」。
まとめ
Loop Engineeringは、AI活用のレバレッジが「プロンプトの巧拙」から「ループ設計の巧拙」へ移ったことを示す概念だ。要点は次の通り。第一に、価値の源泉は単発の答えではなく「目標契約・証拠駆動・停止条件」を備えた継続稼働システムの構築にある。第二に、CI修復やテスト補完など証拠で合否判定できるタスクから始めるのが安全だ。第三に、検証の死角・理解の負債・認知的降伏という落とし穴を常に意識する必要がある。「楽になった」のではなく「難しさの場所が動いた」だけ——その薄ら寒さを忘れずに付き合えるかどうかが、これからのエンジニアの差別化要因になりそうだ。