2026年AI必須スキル「ループエンジニアリング」とは — プロンプト時代の終わりと、自律ループ設計への転換

「プロンプトを書くな。ループを書け」——この言葉が、2026年のAI開発者コミュニティを揺るがしている。

Anthropic Claude Code の責任者 Boris Cherny、OpenClaw 創設者（現 OpenAI）Peter Steinberger、そして Google Chrome のエンジニアリングディレクター Addy Osmani が、独立して同じ主張に収束し始めた。最も重要な AI ラボとブラウザベンダーのトップエンジニアが同時に同じパターンへたどり着いている。これは流行ではなく、AI の使い方そのものが変わるシグナルだ。

本稿は、古野光太朗氏（@koutarou_furuno）が Rahul（@sairahul1）のスレッドを元に整理した X Article、および Addy Osmani 「Loop Engineering」をベースにした Acrosstudio テックブログ（シン・ウフム氏）の記事——この2つの解説を統合し、ループエンジニアリングの全体像を一本にまとめたものだ。

AIパラダイムの4世代変遷

ここ数年の AI 活用は、レバレッジが「人間」から「システム」へ着実に移動してきた。

前の世代が消えるわけではない。Prompt も Context も Harness も Loop の部品として中に組み込まれる。料理に例えるなら、火加減のコツが要らなくなったわけではなく、鍋の前に立ち続ける必要がなくなった、というイメージだ。

プロンプト時代に何が起きていたか

2年間、私たちはこうやってきた。人間がプロンプトを書き、AI が出力し、人間が確認して、また入力する。多くの人が気づいているように、ループしているのは人間だった。

「AI を使っている」というより「AI と一緒に作業している」に近い状態。限界は明確だった——スケールしない（人間の時間が上限）、品質が人間のレビュー精度に依存する、夜中に動かせない。

Boris Cherny / Peter Steinberger が言っていること

Claude Code のヘッドが言った言葉をそのまま引用する。

“I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring 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.”

「もうコーディングエージェントにプロンプトを送るべきではない。あなたのエージェントにプロンプトを送るループを設計すべきだ」

「指示を改善する」から「指示を出す仕組みを設計する」へ。レイヤーが一段上がった。

ループエンジニアリングとは何か

シンプルに言うと——

「エージェントが自分で発見 → 計画 → 実行 → 検証 → 修正を繰り返す仕組みを設計すること」

Addy Osmani の定義も同じ方向を向いている。

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

自分がエージェントを叩く側を辞めて、エージェントを叩く役を機械にやらせる、ということ。5つのフェーズに分解するとこうなる。

人間はゴールだけ決める。あとはループが回る。

Harness と Loop の違い

混同されやすいので整理する。

Harness は1台の機械の安全装置、Loop は工場全体の生産管理システム。Harness は Loop の前提であり、Loop が Harness を置き換えるわけではない。

2つのスケール：1人 vs チーム

ループには規模が2つある。

① シングルエージェントループ — 1つのエージェントが自分で全サイクルを回す。「自分の下書きを自分で何度も直す人」のイメージ。スコープが小さく、集中した作業向き。

② フリートループ（艦隊型） — オーケストレーターが大きなゴールを持ち、それをスペシャリストに分解。スペシャリストはさらにサブエージェントに細分化する。全エージェントが同じ5ステージのループを回す。チームで一つのプロジェクトを動かすイメージだ。

なお、これはよく「AI が勝手に何でもやってくれる」という文脈で語られる。実態は「誰が何を見るかの設計が全部」であり、そこは人間がやらなければならない。ループを書ける人が強い理由がここにある。

オープンループとクローズドループ

オープンループ：エージェントに広い裁量を与え、自由に探索させる。パワフルだが、トークンを爆速で消費する。無制限 API を持っている OpenAI のトップエンジニアが「いいよ」と言える世界の話だ。

クローズドループ：人間が事前にパスを設計する。ゴール明確・ステップ定義・各ステップに評価あり・終了条件あり。エージェントはそのフレームの中で動く。

今すぐ始めるならクローズドループ一択。品質ゲートなしでオープンに回すと、速くて安価だが品質の低いアウトプットが量産されるリスクがある。

ループを構成する6つのコアモジュール

Claude Code も Codex も、この6つを実装している（ソースでの評価に基づく。実際の機能可用性は各ツールのドキュメントで確認推奨）。これを揃えたらループが走る。

① Automations（ハートビート）

ループの心拍。スケジュールやイベントで自動起動し、タスクを拾い上げる。毎朝の CI 失敗・積み上がった issue・最近のコミットに混入したバグなどを、人間がチェックしなくてもシステムが triage の受信トレイに書き込んでくれる。これがないと「一度実行して終わり」になる。

② Worktrees（防護壁）

複数のエージェントを並行で走らせるための分離レイヤー。各エージェントが独立した git ブランチを持ち、自分の作業領域で動く。Codex と Claude Code はネイティブで対応しており、「2つのエージェントが同じ行を同時に書き換えてコンフリクト爆発」という事故を防ぐ。

③ Skills（記憶チップ）

VISION.md、ARCHITECTURE.md、RULES.md などプロジェクト情報を刻んだファイル群。ビルド手順や過去の意思決定もここに書く。

# Build Skill
- 依存関係インストール: `pnpm install --frozen-lockfile`
- 型チェック: `pnpm typecheck`
- テスト: `pnpm test --coverage`
- 受け入れ基準: カバレッジ80%以上、tsc エラー0件
- 過去の罠: monorepo 内で `npm` を使うと lockfile が壊れる

ループが起動するたびにこれを読み込むので、毎ラウンド最初からゼロ推論を強いられることはない。ここが充実しているとループが毎回賢くなる。

④ Connectors / Plugins（腕）

MCP（Model Context Protocol）経由で現実世界につなぐ口。Linear（タスク管理）、GitHub、データベース、Staging API、Slack など。ループは「提案」だけしない。PR を作って、チケットを更新して、CI が通ったら自分で Slack にメンションを飛ばすところまでやる。

⑤ Sub-agents（牽制メカニズム）

コードを書くエージェントは、ほぼ確実に自分に高得点をつける。なので「粗探し専門のエージェント」を別に走らせる。

Verifier をあえて別モデルにするのがポイントだ。同じモデルだと、自分の盲点を一緒に見逃す。

⑥ Memory（一番過小評価されている部品）

Addy の記事の中で「これが一番過小評価されている」と明記されているモジュール。Markdown ファイル、Linear のボード、会話の外にあるあらゆる状態記録がこれにあたる。

モデルは忘れる。リポジトリは忘れない。

外部状態がないと、翌日のループはゲームを最初からやり直す羽目になる。Memory をサボると、ループが「毎日同じところで同じ事故を踏むやつ」に化ける。ループが長期化するほど重要度が上がる。

検証可能なループの5ステップ方法論

「で、具体的にどう作るの？」というところ。コアは1行だ。

検証可能なループの中で AI を目標に近づけ、停止条件まで走らせる。

Step 1. 目標契約

まず完了基準を決める。

• 明確な目標と範囲
• 定量化できる受け入れ基準（例: P95 レイテンシ < 1.5秒、エラー率 < 0.1%）
• 制約と境界条件
• 成功したときの成果物の形式

数字に落ちないものはループで扱わない方が無難だ。

Step 2. Agent の実行

タスクを分解して計画を立て、ツールを呼ぶ（コード、検索、コマンド）。必要なら複数インスタンスで並列に処理し、思考と行動の軌跡を記録する。

Step 3. 証拠によるフィードバック

「動きました！」を信じてはいけない。証拠を出させる。

• 自動テスト結果
• 実行ログとエラースタック
• スクリーンショット・画面録画・UI スナップショット
• パフォーマンス指標と監視データ
• CI/CD のステータスと成果物

Step 4. 停止条件

Step 5. 経験の還元

成功体験はルールやテンプレートに、失敗の教訓はネガティブルールやチェックポイントに落とす。Skills を更新し、harness を更新し、ナレッジベースと同期する。1日単位では差が見えないが、3ヶ月で振り返るとかなり違ってくる。

実装例を4つ

これ、全部同じ骨格だ。ゴール → アクション → チェック → 修正 → 完了まで繰り返す。

1. コーディングループ

1. VISION.md + ARCHITECTURE.md を読む
2. 変更を計画する
3. コードを編集する
4. テストを自動実行する
5. 失敗 → エラーを読んで修正 → 再テスト
6. 通過 → 変更内容をサマリー → 完了

2. リサーチループ

1. リサーチクエスチョンを定義する
2. ソースを検索する
3. 発見をサマリーする
4. ソースとクロスチェックする
5. 矛盾情報を比較する
6. 最終回答を合成する
7. 信頼スコアが閾値を超えたら完了

3. コンテンツループ

1. トピック + ターゲット + ゴールを定義する
2. ドラフトを作成する
3. 批評エージェントがドラフトをレビューする
4. 批評を元にリライトする
5. 成功基準でスコアリングする
6. スコアを超えたら公開 / 未達なら再リライト

4. 営業アウトリーチループ

1. ICP（理想顧客プロファイル）を定義する
2. リードを検索する
3. 企業データでエンリッチする
4. 基準でクオリファイする
5. メッセージをパーソナライズする
6. クオリティレビューする
7. 送信 or 人間にエスカレーション

ループは Cron ではない

「定期実行なら cron や GitHub Actions でできる」と思うかもしれない。違いは3つに集約される。コンテキスト、ツール、フィードバックだ。

短期サイクルなら Loop、長期で信頼性が要るなら Actions、固定された機械的タスクなら Cron。ざっくりこの感覚で外れない。

トークンバーンという現実の壁

正直に書く。

シングルエージェントループ1回（中規模タスクの場合）で、体感としてかなりのトークンを消費する。ソースでは中規模コーディングタスクで5万〜20万トークン程度と報告されているが、タスク規模で大幅に変動する。

フリートループになると消費量は桁違いに跳ね上がる。ソースではスペシャリスト3体構成で50万〜200万トークン程度の消費が報告されており、体数が増えれば比例して増加する。これをスケジュール実行（毎朝など）すると、週単位で膨大なトークン消費になる傾向がある。

標準的な API 価格でこれをやると、コストが月間予算を大きく超過するリスクがある。Peter Steinberger のポストのリプライには「あなたは無制限 API があるから言えるんですよね」という返信が並んでいた。正論だと思う。

これを変えるのが DeepSeek などの低価格モデルだ。DeepSeek V4 は100万コンテキストウィンドウと低価格なトークン設定で、ソースでは「最も安価なフロンティアモデルの一つ」と評価されている。長期ループの経済的ハードルを大幅に下げる可能性がある。「設計できる/できない」の話が「払える/払えない」に移行しつつあって、その変数が消えてきた感じだ。

ただし DeepSeek の採用にはデータガバナンス・セキュリティの検討が先。特にビジネス用途では確認を忘れずに。

ループの3つの罠

ループには「スムーズに回ること自体が危険」というパラドックスがある。

罠1：検証の死角

ループは無人で動くので、無人のままミスを犯す。「done（完了）」は自己申告であり、証明ではない。証拠が出ないループは実質的に自信過剰な乱数発生機だ。

罠2：Comprehension Debt（理解の負債）

ループがスムーズであるほど、自ら生成させたコードに対して疎遠になりやすい。デリバリーを加速させる一方で、乖離も加速させる。自分で書いていないコードが日々増えていって、ある日デバッガを開いたときに「これ、誰が書いたんだっけ……自分か」となる。技術的負債とは少し違う、新しい種類の負債だ。

罠3：Cognitive Surrender（認知的降伏）

一番怖い罠。ループを走らせ、自分の判断基準を持つことをやめ、それがもたらすすべてを受け入れてしまうこと。「AI がそう言うので…」が口癖になりはじめたら危ない。

Osmani の警告を引用する。

判断力を持ちながらやるなら、ループの設計は解毒剤になる。思考から逃げるために使うなら、それは促進剤になる。同じ行動でも、結果は正反対になる。

レバレッジポイントは移動した

Boris Cherny が言っているのは、仕事が楽になったという話ではない。レバレッジポイントが動いた、という話だ。

Rahul の言葉を借りると——

「プロンプトエンジニアは AI にアウトプットを求める。ループエンジニアは検証済み結果を生産するシステムを設計する」

2026年で高く評価されるのは「英語のプロンプトが上手い人」じゃなくて、「エージェントがどうやって発見・計画・検証・完了を判断するか、その論理を設計できる人」だ。

ループエンジニアリングはプロンプトエンジニアリングより難しい。1つの答えを作るのと、答えを出し続ける機械を作るのは、まったく別の技能だからだ。それでも、難しい代わりに効く。

「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（@sairahul1）「Loops: What Every AI Engineer Needs to Know in 2026」
• 古野光太朗（@koutarou_furuno）による X Article「2026年AI必須スキル：『loop設計』とは—プロンプト時代の終わり」
• Addy Osmani 「Loop Engineering」— addyosmani.com, 2026.06.07
• Acrosstudio テックブログ（シン・ウフム）「もうプロンプトを書くな──『Loop Engineering』という新しいパラダイムの正体」— zenn.dev
• Boris Cherny（Claude Code 責任者）— Acquired Podcast 出演, 2026

関連記事

• ループエンジニアリング14ステップ — 4条件テストと失敗パターン — 「そのループは作るべきか」の判断基準、撤退ライン（cost per accepted change）、無人ループのセキュリティリスク
• プロンプトからループへ — Boris Cherny / Peter Steinberger の発言を軸にした概観