ループエンジニアリング入門 — 「プロンプトを書く」から「ループを設計する」へ

2026年上半期、AIコーディング界隈でもっとも急速に広まった言葉が「ループエンジニアリング(Loop Engineering)」です。プロンプトエンジニアリング、コンテキストエンジニアリングに続く”第3の波”として、6月の登場からわずか1ヶ月で国内外の技術メディアが一斉に取り上げる状況になっています[5]。

本記事は、公開されている一次発言・解説記事を調査し、定義・構成要素・実務への導入方法・リスクを1本に整理したものです。

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

一行で言えば、「次の一手を出す役を、人間からシステムに移す設計」です。

これまでのAIコーディングは、人間がプロンプトを書き、AIが応答し、人間が結果を見て次のプロンプトを書く——という人間駆動の往復でした。ループエンジニアリングでは、この往復そのものを仕組みにします。つまり、エージェントに指示を出し、結果を検証し、次のタスクを与える「ループ」を設計し、人間はループの設計者・監督者に回ります。

起源 — 「私の仕事はループを書くことだ」

発端は、AnthropicのClaude Code責任者 Boris Cherny 氏の発言です。氏は自分がもはやAIに直接プロンプトを出しておらず、走り続けるループがAIへの指示出しを担っていると述べ、自身の仕事を「ループを書くこと」だと表現しました。

これを受けて、Googleの Addy Osmani 氏が2026年6月のブログ記事でこの働き方を「Loop Engineering」として定式化し、一気に概念が広まりました[1]。国内でも@IT・日経クロステック・Findy Team+などが相次いで解説記事を出しています[3][4]。

プロンプト/コンテキストエンジニアリングとの関係

3つは対立概念ではなく、積み上げの関係にあります。

世代	問い	磨く対象
プロンプトエンジニアリング	どう指示すれば良い出力が返るか	指示の質
コンテキストエンジニアリング	どんな材料を渡せば良い出力が返るか	情報の質
ループエンジニアリング	指示と検証を、誰が・何が回し続けるか	仕組みの質

プロンプトとコンテキストの知見はループの中で生き続けます。変わるのは、それを毎回人間が手で行うのをやめるという点です。

ループの解剖 — 4つのフェーズ

各所の解説を突き合わせると、ループの基本形は次の4フェーズに集約されます[1][6]。

1. 見つける(Find) — 次にやるべき作業を特定する。Issueトラッカー、失敗したCI、TODOコメント、監視アラートなどが「作業のキュー」になる
2. 実行する(Act) — エージェントがコードを書く・直す・ドキュメントを更新する
3. 検証する(Verify) — テスト・型チェック・Lint・ビルド・レビューエージェントで結果を機械的に確かめる
4. 記録する(Record) — 何をやったか、何が残っているかを外部(Markdownファイル、PR、Issue)に書き出し、次の周回に引き継ぐ

このうち心臓部は検証です。ループが暴走せずに収束するかどうかは、「正しく直せたかを機械が判定できるか」——つまりフィードバック信号の質で決まります。テストがないコードベースでループを回すのは、計器のない飛行機で自動操縦を入れるようなものです。

DevOpsの「内側ループ/外側ループ」との接続

ループという発想自体は新しくありません。プラットフォームエンジニアリングの世界では、開発者が個人で回す「内側ループ」(書く→ビルド→テスト→デバッグ)と、組織が回す「外側ループ」(統合→CI/CD→リリース→運用)という整理が以前からあります[7]。

ループエンジニアリングはこの延長線上で理解できます。内側ループの操縦者が人間からエージェントに代わり、人間の仕事は外側——エージェントが安全に速く回れる環境(テスト、型、CI、ガードレール。いわゆるハーネス)の整備に移る、という構図です[2]。

面白いのは、この10年のDevOps・開発者体験(DevEx)への投資が、そのままエージェント時代の資産になることです。「ビルドが速い」「テストが信頼できる」「環境構築が自動」——人間の生産性のために磨いてきたものは、すべてループの回転数を上げる部品になります。

6つの構成要素(Addy Osmaniの整理)

Osmani氏の整理によれば、実運用のループは次の6要素で構成されます[1]。

1. ハートビート(自動実行) — スケジュールやイベントをトリガーに、ループを定期的に起動する
2. ワークツリー(並列作業) — Gitワークツリー等で作業空間を分離し、複数のループを衝突なく並列に走らせる
3. スキル(プロジェクト知識) — コーディング規約やドメイン知識を再利用可能な形でエージェントに与える
4. コネクター(ツール連携) — Issueトラッカー・チャット・監視ツールと接続し、「見つける」と「記録する」を自動化する
5. サブエージェント(役割分担) — 実装役・レビュー役・調査役など、専門化したエージェントに分担させる
6. メモリ(状態の外部化) — エージェントは対話を忘れるため、進捗や決定事項をMarkdown等の外部ファイルに記録して引き継ぐ

何に適用されているか

現時点で報告されている適用例は、「繰り返し発生し、完了条件を機械的に判定できるタスク」に集中しています。

• 失敗したCIの自動修復(赤→緑を完了条件にできる)
• 依存パッケージの更新とテスト通過の確認
• Lint・型エラーの一括解消、コード品質の継続改善
• PRの一次レビューとチェックリスト検査
• ドキュメントとコードの乖離検出・更新

逆に、要件が曖昧なもの・完了条件を言語化できないもの(新機能の設計判断など)は、依然として人間駆動の領域です。

リスク — 3つの「人間側の責任」

調査した解説の多くが、効率と同じ分量でリスクを論じています。@ITの解説では、人間側に残る責任として次の3つが挙げられています[1]。

1. 検証責任 — ループの出力を最終的に世に出す判断は人間が担う。自動化されるのは「作業」であって「責任」ではない
2. 理解債務 — AIが書いたコードを誰も理解していない状態が蓄積するリスク。動いているが説明できないシステムは、変更不能な技術的負債になる
3. 認知的降伏 — 「AIがそう言うなら」と検証を省略し始める心理。ループの成功率が高いほど起きやすい

また日経クロステックは推論コストの爆発を指摘しています[3]。ループは放っておけば24時間トークンを消費し続けるため、コスト上限・停止条件の設計はループ設計の一部です。

この3つのリスク構造は、当サイトが医療LLMの安全設計で整理した「自動化バイアス」「Draft-only原則」とほぼ同型です。ループの自律性が上がるほど、人間のレビューゲートの設計が本体になる——ドメインを問わず成り立つ原則だと言えます。

導入ステップ — 小さく始めるための実務ガイド

調査結果と実務感覚を合わせて、導入の順序を5ステップにまとめます。

1. 検証信号を先に固める。テスト・型チェック・Lintが貧弱なら、ループより先にそちらに投資する(これはアーキテクチャテストで境界を守るのと同じ発想で、機械が判定できるルールだけが自動化に耐えます)
2. 1つの定型タスクから始める。おすすめは「CIの赤を直す」か「Lintエラーの解消」。完了条件が明確で、失敗しても被害が小さい
3. 記録を外部化する。ループの各周回が何をしたかをMarkdownやPRに残させ、人間が朝一で監査できるようにする
4. 上限を設ける。1周回あたりのトークン・時間・変更ファイル数に上限を置き、超えたら停止して人間を呼ぶ
5. 人間のゲートを最後に置く。ループの成果物はすべてPR経由にし、マージ権限は人間に残す

まとめ

• ループエンジニアリングは「次の一手を出す役を、人間からシステムに移す」設計手法。2026年6月にBoris Cherny氏の実践をAddy Osmani氏が定式化した
• ループの基本形は「見つける→実行する→検証する→記録する」。品質を決めるのは検証(フィードバック信号)
• DevOpsの内側/外側ループの延長にあり、これまでの開発者体験への投資がそのまま活きる
• 適用に向くのは完了条件を機械判定できる定型タスク。検証責任・理解債務・認知的降伏・コストという人間側の課題は残る
• 導入は「検証信号の整備→小さな定型タスク→記録・上限・人間ゲート」の順で

「プロンプトがうまい人」の時代から、「良いループを設計できる人」の時代へ。その中身は結局、テスト・CI・コードレビューという地道なエンジニアリングの再評価でもあります。