「プロンプトを書くな。ループを書け」
Peter Steinberger（OpenClaw創設者、現OpenAI）と、Boris Cherny（Anthropic Claude Code責任者）が、独立して同じことを言い始めた。
偶然じゃない。
地球上で最も重要な2つのAIラボのトップエンジニアが、同時に同じパターンに収束している。「流行の話」じゃなくて、AIの使い方そのものが変わるシグナルだと思う。
この記事は、そのシフトを整理したRahul（@sairahul1）のスレッドを元に、僕なりに整理し直したもの。
プロンプト時代に何が起きていたか
2年間、みんなこれをやってきた。
あなた → プロンプト → AI → 出力 → あなたが確認 → 修正 → また入力
気づいてる人は多いと思うけど、「ループしてるのは人間」だった。
AIに一回聞いて、確認して、また聞いて、また確認する。「AIを使ってる」というより「AIと一緒に作業してる」に近い状態。
限界は明確。スケールしない（人間の時間が上限）、品質が人間のレビュー精度に依存する、夜中に動かせない。
Boris Chernyがやっていること
Claude Codeのヘッドが言った言葉をそのまま引用する。
"I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops."
「僕はもうClaudeにプロンプトを送ってない。ループが走っていて、そのループがClaudeに何をすべきか考えさせてる。僕の仕事はループを書くこと」
Peter Steinbergerも同じことをこう言った。
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
ここで止まって読んでほしい。
「指示を改善する」から「指示を出す仕組みを設計する」へ。レイヤーが一段上がった。
ループエンジニアリングとは何か
シンプルに言うと：
「エージェントが自分で発見→計画→実行→検証→修正を繰り返す仕組みを設計すること」
5つのフェーズに分解するとこうなる。
DISCOVER（発見）
↓
PLAN（計画）
↓
EXECUTE（実行）
↓
VERIFY（検証）
↓
ITERATE（修正）
↓
クリアしたら完了 / 失敗したらDISCOVERに戻る
人間はゴールだけ決める。あとはループが回る。
2つのスケール：1人 vs チーム
ループには規模が2つある。
① シングルエージェントループ
1つのエージェントが自分で全サイクルを回す。「自分の下書きを自分で何度も直す人」のイメージ。スコープが小さく、集中した作業向き。
② フリートループ（艦隊型）
オーケストレーターが大きなゴールを持ち、そのゴールをスペシャリストに分解。スペシャリストはさらにサブエージェントに細分化する。
オーケストレーター（ゴール全体を管理）
↓ ↓ ↓
調査担当 開発担当 QA担当
↓ ↓ ↓
Web調査 コード書き+デバッグ テスト+バグ追跡
全エージェントが同じ5ステージのループを回している。チームで一つのプロジェクトを動かすイメージ。
余談なんだけど、これよく「AIが勝手に何でもやってくれる」みたいな文脈で語られるんだよね。
実態は「誰が何を見るかの設計が全部」で、そこは人間がやらないといけない。ループを書ける人が強い理由がここにある。
オープンループとクローズドループ
オープンループ：エージェントに広い裁量を与え、自由に探索させる。
パワフルだけど、トークンを爆速で消費する。無制限APIを持ってるOpenAIのトップエンジニアが「いいよ」と言える世界の話。
クローズドループ：人間が事前にパスを設計する。ゴール明確・ステップ定義・各ステップに評価あり・終了条件あり。エージェントはそのフレームの中で動く。
今すぐ始めるならクローズドループ一択。
品質ゲートなしでオープンに回すと、速くて安くてひどいアウトプットが量産される笑
実際に何を作るか：6つのビルディングブロック
Claude CodeもCodexも、この6つを実装している。（ソースでの評価に基づく。実際の機能可用性は各ツールのドキュメントで確認推奨）これを揃えたらループが走る。
① Automation（自動化）
ループの心拍。スケジュールやトリガーでDISCOVERを開始する。「毎朝テストを走らせて結果を届ける」みたいな仕組み。これがないと「一度実行して終わり」になる。
② Worktrees（ワークツリー）
複数エージェントが並行実行する際のファイル衝突防止。Gitのブランチごとに独立した作業ディレクトリを与える。「2人のエンジニアが同じファイルを同時に書き換える悪夢」を防ぐやつ。
③ Skills（スキルファイル）
VISION.md、ARCHITECTURE.md、RULES.md など、プロジェクト情報を書いたファイル群。毎回プロジェクトの説明をゼロからさせなくて済む。ここが充実してるとループが毎回賢くなる。
④ Plugins / Connectors（連携）
Linear（タスク管理）、Slack（通知）、ステージング環境のAPI……外部ツールとの接続。これがないとループは「ファイルだけ変えて終わり」になる。PRを開いてSlackに通知まで走らせるのがここ。
⑤ Subagents（サブエージェント）
「作る人」と「確認する人」を別エージェントにする。 自分で書いたコードを自分で採点させるのは甘い。別のエージェント（別モデルでもいい）に検証させることでVERIFYが機能する。
⑥ Memory（メモリ）
MarkdownファイルでもLinearボードでも何でもいい。「今回のループで何を試したか、何が通ったか、何が残っているか」を外部に保存する。これがないと毎回ゼロから始まる。ループが長期化するほど重要度が上がる。
実装例を4つ
1.コーディングループ
VISION.md + ARCHITECTURE.md を読む
→ 変更を計画
→ コード編集
→ テスト自動実行
→ 失敗 → エラーを読んで修正 → 再テスト
→ 通過 → 変更内容をサマリー → 完了
2.リサーチループ
リサーチクエスチョンを定義
→ ソース検索
→ 発見をサマリー
→ ソースとクロスチェック
→ 矛盾情報を比較
→ 最終回答を合成
→ 信頼スコアが閾値を超えたら完了
3.コンテンツループ
トピック + ターゲット + ゴールを定義
→ ドラフト作成
→ 批評エージェントがドラフトをレビュー
→ 批評を元にリライト
→ 成功基準でスコアリング
→ スコアを超えたら公開 / 未達なら再リライト
4.営業アウトリーチループ
ICP（理想顧客プロファイル）を定義
→ リードを検索
→ 企業データでエンリッチ
→ 基準でクオリファイ
→ メッセージをパーソナライズ
→ クオリティレビュー
→ 送信 or 人間にエスカレーション
これ、全部同じ骨格。
ゴール → アクション → チェック → 修正 → 完了まで繰り返す。
トークンバーンという現実の壁
ここは正直に書く。
シングルエージェントループ1回（中規模タスクの場合）で、体感としてかなりのトークンを消費する。ソースでは中規模コーディングタスクで5万〜20万トークン程度と報告されているが、タスク規模で大幅に変動する。
フリートループになると消費量は桁違いに跳ね上がる。
ソースではスペシャリスト3体構成で50万〜200万トークン程度の消費が報告されており、体数が増えれば比例して増加する。
これをスケジュール実行（毎朝など）すると、週単位で膨大なトークン消費になる傾向がある。実行頻度とタスク規模次第で大きく変わるが、ソースでは「週に数百万トークン規模」と報告されている。
標準的なAPI価格でこれをやると、まじで月の予算が吹っ飛ぶ。
Peter SteinbergerのポストのリプライにはOpenAIユーザーから「あなたは無制限APIがあるから言えるんですよね」という返信が並んでた。正論だと思う。
これを変えるのがDeepSeekなどの低価格モデル。
DeepSeek V4は100万コンテキストウィンドウと低価格なトークン設定で、ソースでは「最も安価なフロンティアモデルの一つ」と評価されている。
長期ループの経済的ハードルを大幅に下げる可能性がある。「設計できる/できない」の話が「払える/払えない」に移行しつつあって、その変数が消えてきた感じ。
ただしDeepSeekの採用にはデータガバナンス・セキュリティの検討が先。
特にビジネス用途では確認を忘れずに。
プロンプトエンジニアとループエンジニア
プロンプトエンジニア
- 「いい指示を書く」
- 毎回出力を手動確認
- 1回実行して終わり
- 出力の質を高める
ループエンジニア
- 「指示を自動で出す仕組みを書く」
- テストが自動検証
- 繰り返し実行される
- 検証済みアウトプットを生産する
Rahulの言葉を借りると：
「プロンプトエンジニアはAIにアウトプットを求める。ループエンジニアは検証済み結果を生産するシステムを設計する」
2026年で高く評価されるのは「英語のプロンプトが上手い人」じゃなくて、「エージェントがどうやって発見・計画・検証・完了を判断するか、その論理を設計できる人」。
「Go押すだけ」になるな
Rahulが最後に言ってることが一番刺さった。
「同じループを2人が作っても、結果が真逆になることがある。
一方は深く理解した上でレバレッジをかけている。もう一方は理解を避けるためにループを使っている。ループは区別しない。でもあなたには分かる」
「Go押すだけの人」になるか、「設計する人」になるか。
そこが2026年の分岐点。
今日やること
□ Boris Chernyの発言をもう一度読む（「My job is to write loops」）
□ 自分が今やってるAI作業の中に「手動で確認 → また入力」のサイクルがあるか確認する
□ VISION.md / ARCHITECTURE.md / RULES.md の3ファイルを作ってみる（プロジェクト1つから）
□ 「作る人」と「確認する人」を別エージェントに分ける設計を試してみる
□ まずクローズドループから始める（オープンループはその後）
どこから始めるか迷ったら→ VISION.md を書くところから。 これがないとループはゴールを持てない。
Rahulのオリジナルスレッドがめちゃくちゃ充実してるのでおすすめ。
→ Loops: What Every AI Engineer Needs to Know in 2026
ループ設計やってる方いたら、どんな構成にしてるか聞いてみたい。
コメントかDMで教えてください。
