ループエンジニアリングとは？ AIを動かす仕組みを設計する人へ

「プロンプトエンジニアリングは終わった」。最近、そんな言葉を聞くようになりました。

今や、人間がAIへ一つずつ指示するのではなく、AIへ指示を与え、仕事を検証し、次の仕事を決める仕組みそのものを作る。さらに2026年7月には、その先に「グラフエンジニアリング」があるとも言われ始めました。

では、もうプロンプトを書く能力は必要ないのでしょうか。

結論は、むしろ逆です。

プロンプトエンジニアリングが消えるのではありません。人間が毎回プロンプトを入力する方式が減り、プロンプトが仕様書、コンテキスト、AGENTS.md、CLAUDE.md、スキル、評価基準、ハーネス、ループ、グラフの中へ埋め込まれていくのです。

終わりつつあるのは「一発でAIを思いどおりに動かす魔法の呪文探し」です。むしろ重要になるのは、意図・価値観・制約・具体例・失敗例・評価基準・停止条件を、AIとの対話を通じて発見し、再利用できる仕組みに固定する能力です。

本稿では、2026年8月2日時点で確認できる一次資料を中心に、この変化を整理します。

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

現在の意味で「Loop Engineering」という言葉を広く定着させたのは、Addy Osmani氏が2026年6月8日に公開した記事です。

簡単に言えば、ループエンジニアリングとは、人間がエージェントへ毎回プロンプトを書く代わりに、エージェントへプロンプトを与え続ける仕組みそのものを設計することです。

Peter Steinberger氏も、コーディングエージェントへ毎回プロンプトを入力するのではなく、エージェントへプロンプトを与えるループを設計するべきだと発信しました。AnthropicでClaude Codeを率いるBoris Cherny氏も、自分の仕事はClaudeに一つずつ指示することではなく「Claudeを動かすループを書くこと」へ変化したと述べています。

構造にすると、次のようになります。

目標・仕様
   ↓
作業を発見・分解する
   ↓
実行する
   ↓
結果・ログ・差分を観測する
   ↓
テスト・評価・レビューを行う
   ↓
状態・計画・ドキュメントを更新する
   ↓
完了していなければ再実行する ↺

完了・予算超過・異常・高リスク時
   ↓
停止／人間へエスカレーション

式のように表すなら、Loop = Goal + State + Act + Observe + Evaluate + Update + Retry + Stop / Escalateです。

重要なのは、同じプロンプトを無限に繰り返すことではありません。

• 何を達成すべきか
• 現在どこまで進んでいるか
• 次に何をすべきか
• 正しくできたと何で判断するか
• 失敗時に何を変えるか
• どこで諦めるか
• いつ人間を呼ぶか

までを含む、AIのための制御システムを作るのがループエンジニアリングです。Osmani氏は別の論考で、ループを「調査、実装、検証、再実行」の反復として整理しています。モデル自身の「できました」という申告ではなく、テストや独立した評価など、外部の証拠によって完了を判定することが特に重要です。

図1：ループは単なる再実行ではない。状態を引き継ぎ、外部証拠で評価し、停止ゲートまで含めて初めて制御システムになる。

2．新しいのはループそのものではなく、ループを主役にしたこと

AIが「考える→行動する→結果を観測する→次の行動を決める」という循環で動く考え方自体は、新しくありません。

2022年のReAct論文はReasoningとActing、そして環境からの観測を交互に行う方式を扱っていました。Anthropicも2024年には、生成役と評価役が反復する「Evaluator-Optimizer」、中央のLLMが仕事を分解して複数のワーカーへ渡す「Orchestrator-Workers」を代表的なエージェント構成として解説しています。

2025年にはGeoffrey Huntley氏が、Claude CodeをBashのwhileループで繰り返し動かす「Ralph Wiggum Loop」を公開しました。

while :; do
  cat PROMPT.md | claude-code
done

ただし、本当に重要だったのはこの一行ではありません。仕様、作業計画、テスト、Gitの状態、AGENTS.mdなどへ進捗と学習を外部化し、各ループが前回の成果を引き継げるようにしていたことです。Huntley氏自身も、完璧なプロンプトは存在せず、AIの失敗を観察しながらプロンプトや環境を継続的に調整すると説明しています。

したがって、より正確な位置づけは次のとおりです。

ループエンジニアリングは、2026年に突然発明された技術ではない。従来からあったエージェントループを、個人のテクニックから体系的なエンジニアリング対象へ引き上げた言葉である。

3．プロンプト、コンテキスト、ハーネス、ループ、グラフ

Anthropicはコンテキストエンジニアリングを、プロンプトエンジニアリングの「自然な発展」と明確に位置づけています。単に指示文を工夫するのではなく、システムプロンプト、ツール定義、履歴、外部データ、メモリなど、推論時にモデルへ渡されるトークン全体を最適化する考え方です。

これらは新しい用語が古い用語を一つずつ置き換えているのではありません。Prompt ⊂ Context ⊂ Harness ⊂ Loop ⊂ Graphという単純な包含関係でもありませんが、設計対象が一回の発言から、環境、反復、組織構造へ拡大していると捉えると分かりやすくなります。

ハーネスエンジニアリングとの違い

ハーネスとは、モデルを実務で動かすために周囲へ取り付ける環境全体です。Osmani氏は、モデルをエンジン、ハーネスをその周囲に作る自動車に例えています。ハーネスには、ファイル、ツール、メモリ、権限、サンドボックス、テスト、監視、復旧手段などが含まれます。ループは、その自動車を繰り返し運行し、目的地へ収束させる仕組みです。

• ハーネスエンジニアリング：AIが働く作業場を設計する
• ループエンジニアリング：その作業場で仕事を反復・評価・継続させる
• グラフエンジニアリング：複数の作業場や反復処理を接続し、組織化する

図2：モデルはエンジン、ハーネスは安全に働く環境、ループは反復、グラフは複数の処理を編成する層である。

AGENTS.mdもAIに書かせる時代

OpenAIが2026年2月に公開した社内開発事例では、最初のリポジトリ構造、CI設定、フォーマット規則だけでなく、最初のAGENTS.mdさえCodex自身が作成しました。その後、約5か月で約100万行、約1,500件のプルリクエストに達したと報告されています。

これは一般的な生産性ベンチマークではなく、OpenAI内部の特殊な実験的事例です。それでも、「人間がAGENTS.mdを最初から手作業で完璧に書く必要はない」という見方を裏付けます。Claude Codeも/initを実行するとリポジトリを調査し、ビルド方法、テスト方法、規約などを抽出して、CLAUDE.mdの初稿を自動生成します。

今後の実務は、人間がハーネスを一字一句書くのではなく、AIにリポジトリを調査させ、人間へ質問させ、AI自身にハーネス案を書かせ、人間が意図と境界を承認する形へ進むでしょう。

ただし、AIに書かせれば終わりではない

AIにハーネスを書かせること自体は合理的です。しかし、AIが観測できないものは書けません。OpenAIの事例でも、最初の問題はCodexの能力不足ではなく、環境、ツール、抽象化、内部構造が十分に整っていなかったことでした。

巨大なAGENTS.mdは重要な制約を埋没させ、古い情報を蓄積し、かえって性能を低下させました。そのため、短い「地図」と詳細ドキュメントに分割する方式へ変更されています。計画も一時的な会話ではなく、バージョン管理された第一級の成果物として保存されます。

AIはハーネスを生成できますが、人間はハーネスの意味を所有しなければなりません。

4．グラフエンジニアリングとは何か

「Graph Engineering」が一気に注目された直接的なきっかけは、Peter Steinberger氏が2026年7月18日に投稿した「まだループの話をしているのか、それともグラフへ移ったのか」という短い問いかけです。

この投稿を契機に「Loop Engineering is dead」「次はGraph Engineeringだ」といった発信が急増しました。ただし、Steinberger氏自身は正式な定義やフレームワークを示したわけではありません。Prefectも、この熱狂をほとんど何気ない一言から始まったものとして紹介しています。

現時点での最も実務的な定義は、次のとおりです。

複数のエージェント、ツール、評価器、人間、ループを、ノードとエッジによって接続し、依存関係、分岐、並列実行、合流、権限、状態遷移を設計すること。

ノードはAIエージェントだけではありません。通常のプログラム、テスト、データベース検索、外部API、評価モデル、人間による承認も置けます。エッジには、成功したら次へ、失敗したら戻る、条件Aなら分岐、複数処理を並列起動、全結果が揃ったら合流、リスクが閾値を超えたら人間へ、予算超過なら停止、といった条件を設定します。

[要求分析]
     ↓
[設計レビュー]
  ↙       ↘
[Backend] [Frontend]
  ↘       ↙
   [統合テスト]
     ↙    ↘
 [人間承認] [修正ループ ↺]

PrefectはDirected Agentic Graphを「ノードが仕事やビジネスロジックの単位、エッジが次の呼び出しへ進む経路」と定義しています。従来のDAG型ワークフローとの連続性も明確です。

グラフはループの上位互換なのか

厳密には、上位互換とは言わない方がよいでしょう。数学的には、ループは「循環するエッジを持つグラフ」として表現でき、その意味ではグラフの方が一般的です。

しかし、一つの明確な目標、一つのリポジトリ、一つの評価基準、順番に進めればよい作業に、複雑なグラフは必要ありません。単純なループで十分な仕事へ複数エージェント、共有状態、分岐、合流を持ち込めば、障害点、競合、デバッグコスト、トークン消費、観測負荷が増えます。

グラフエンジニアリングは、ループを捨てる次世代技術ではなく、複数のループや処理を編成する上位のオーケストレーションレイヤーである。

ここでいうグラフは、GraphRAGなどのナレッジグラフとも区別すべきです。

• ナレッジグラフ：AIが何を知るか
• 実行グラフ：AIがどの順序で何をするか
• トレースグラフ：AIが実際に何をしたか
• ガバナンスグラフ：誰がどこで承認するか

現在のブームで中心にあるのは主に実行・制御グラフです。そして実装自体は言葉が流行する前から存在しました。Google ADK 2.0は、エージェント、ツール、関数をグラフ上のノードとして扱う実行エンジンへ移行し、分岐、反復、複数エージェント協調、自動リトライ、Human-in-the-loopの一時停止を備えています。新しいのはグラフそのものより、「Graph Engineering」というラベルが2026年7月に急速に流行したことです。

5．プロンプトは消えず、仕組みの中へ移る

OpenAIは現在も公式ドキュメントでPrompt Engineeringを扱っています。ただし、生産環境のプロンプトを画面上の一時的な文章ではなく、型、コードレビュー、テスト、評価、デプロイ工程を持つアプリケーションコードとして管理する方向へ進めています。

これはプロンプトの消滅ではありません。プロンプトが会話欄からソースコードへ移動し、テスト・バージョン管理されるようになったという動きです。

減っていく可能性が高いのは、「この言い回しなら急に賢くなる」「最初に世界最高の専門家だと書く」「一回の巨大プロンプトですべてを決める」「モデルの癖を利用した呪文集」といった小手先の技法です。

一方、目的と非目的、優先順位、意思決定原則、具体例と反例、評価基準、不確実な点、相談したい点、権限境界、停止条件、完了の証拠を伝える能力は重要になります。

プロンプトエンジニアリングは終わらない。プロンプトの単位が、一回の発言から、仕様・コンテキスト・ハーネス・ループ・グラフへ拡大する。

AIに「相談して、考えて、作ってもらう」

AGENTS.mdを人間が細部まで先に決めるのではなく、まずリポジトリを調べてもらい、必要事項を相談し、ベストプラクティスを考えてもらい、それから作らせる方式は、OpenAIのCodexベストプラクティスとも一致します。

複雑で曖昧な仕事では、先に計画させ、Codexから人間へ質問させ、人間の前提を疑わせ、曖昧なアイデアを具体化させます。例えば、次のようなメタプロンプトが有効です。

このリポジトリに適したエージェント用ハーネスを設計してください。

ただし、すぐにAGENTS.mdを書き始めないでください。
1. コード、CI、テスト、構造、既存文書を調査する
2. 判断できる事実と、判断できない事項を分ける
3. 私に確認すべきことを重要度順に質問する
4. AGENTS.md、skills、hooks、テスト、権限、停止条件を提案する
5. 理由、利点、欠点、維持コストを説明する
6. 承認後にファイルを生成する
7. 実作業でハーネスが機能するか検証する

これは「完璧な命令を書くプロンプトエンジニアリング」ではありません。AIと一緒に仕様を発見するためのプロンプトです。AI時代の優れたプロンプトは、優れた命令書というより、優れた会議設計、壁打ち、1on1、要件定義セッションに近づいていきます。

音声入力型のエージェントエンジニアリング

Andrej Karpathy氏が2025年に「Vibe Coding」という言葉を広めた元の投稿には、SuperWhisperでAIへ話しかけ、ほとんどキーボードに触らないという記述がありました。音声駆動はバイブコーディングの原型に最初から含まれていたと言えます。Vibe Codingは2025年のCollins Dictionary「Word of the Year」にも選ばれました。

ただし、音声入力を使うこと自体がバイブコーディングではありません。Simon Willison氏はVibe Codingを、単なるAI支援開発ではなく、AIが書いたコードをほとんど確認せず、差分も読まず、結果の雰囲気だけで進める方法として区別しています。

テスト、レビュー、ハーネス、設計相談を伴うなら、厳密には音声駆動のエージェントエンジニアリング、または会話駆動型ハーネスエンジニアリングと表現した方が実態に近いでしょう。ただし、これらは現時点で定着した正式用語ではありません。

図3：音声の価値は速さだけではない。迷い、違和感、例外まで渡し、AIと一緒に仕様を発見できる情報量にある。

理想的な流れは、人間が音声で抽象的な意図や違和感まで話し、AIが誤変換を補正して意図・制約・不明点を構造化し、理解できた内容と未理解の内容を返すことです。人間が修正・補足し、AIがリポジトリを調査し、仕様・ハーネス・評価基準を提案する。人間が境界と優先順位を承認したあと、ループまたはグラフとして実行します。

音声入力の強みは、文章として整える前の曖昧さ、迷い、違和感、感情、例外まで大量に渡せることです。弱みは誤変換と論点の飛躍です。そのため、いきなり実装させず、「私の発言を要約し、決定事項、仮説、未決事項、矛盾、具体例、反例に分けてください」と頼むだけでも、強力なインターフェースになります。

6．『具体と抽象』と、完全には言語化できない人間

細谷功氏の『具体と抽象――世界が変わって見える知性のしくみ』は、2014年11月27日にdZEROから発売されました。著者自身も「思考の最も根本となるのは具体と抽象の往復」と説明しています。同書は、具体的で分かりやすいものばかりが評価され、抽象的思考が軽視される社会に警告を発する内容です。出版社の紹介では、2022年時点で21刷・7万部に達したロングセラーとされています。

そのため、この本の影響でビジネスパーソンが「具体で言うと」と言うようになった、という因果関係は確認できません。むしろ本書は「具体的であることは常に正義」という文化への批判です。

「具体で言うと」「解像度を上げる」「数字で示す」という文化は、KPIやOKR、アジャイル開発の受入条件、コンサルティング的な説明様式、短時間で結論を求める会議、SNSやスライドでの分かりやすさ重視など、複数要因が重なったものと考える方が自然です。ただし、これは特定の起源を確認した事実ではなく推論です。

具体だけを渡すとAIは例に過剰適合し、抽象だけを渡すと正しさを検証できません。必要なのは、抽象から具体へ落とし、具体から抽象へ戻り、失われた意味がないかを確認する往復運動です。

「言葉にすると70％から90％へ情報が削られる」という数値は、この本が科学的に示した数字ではなく、個人的な比喩として扱うべきです。しかし、言語化が情報の圧縮であり、その際にニュアンスが失われるという問題意識は重要です。

人間の頭の中を100％言葉にすることはできません。そこで重要になるのは、すべてを言葉にする能力ではなく、何を言葉にできていて、何をまだ言葉にできていないのかを認識する能力です。

• 方向性は分かるが、最適な構造は分からない
• この例は好きだが、理由をまだ説明できない
• 技術要件は固まっているが、UXの完成像が曖昧
• 正解は分からないが、これは違うという例は示せる
• AとBのどちらを優先するか迷っている
• 言葉にできない違和感が残っているので、質問してほしい

これは曖昧なプロンプトではありません。曖昧さの所在を正確に伝える、高度なプロンプトです。AI時代の言語化能力は、完成した答えを一方的に伝える能力から、未完成の思考を共同探索できる形にする能力へ変化します。

7．現在のAIはどこまで任せられるのか

現在の変化は、単発の回答能力よりも、一つの目的を長時間維持し、失敗から復旧できる時間軸に現れています。

OpenAIが2026年2月に公開した実験では、Codexが空のリポジトリから約25時間連続で動作し、約1,300万トークンを使用して約3万行のコードを生成しました。計画、実装、テスト、失敗修正、ドキュメント更新を反復しています。

ただし、OpenAI自身が本番導入ではなく実験だと明記しています。長時間動いたことと、一般業務で無条件に信頼できることは別です。

2026年のMirrorCode研究では、AIエージェントが外部から観察できる挙動を基に、比較的大きなプログラムを再構築できることが示されました。一方、大規模な一回の試行に19日間、約2,600ドルを要した事例もあり、成功しやすかったのは要件が精密に定義されたタスクでした。

METRのTime Horizonもよく引用されますが、これはAIを実際に何時間放置できるかではありません。人間の専門家なら何時間かかる難度のタスクを、一定確率で完了できるかという指標です。16時間を超える推定は信頼性が低く、対象も主に自動評価可能で自己完結した、明確なソフトウェア、機械学習、サイバーセキュリティ課題です。

AIは、境界が明確で、結果を機械的に検証でき、状態を外部へ保存できる仕事については、長時間・多段階の反復を任せられる水準に近づいた。しかし、言語化されていない事業意図、価値判断、組織的利害、責任まで自動的に理解できるわけではない。

能力の境界は「何時間動けるか」より、何を正解として検証できるかで決まります。

ユーザー側の能力は、むしろ重要になる

AnthropicがClaude Codeの実利用を分析したところ、一般的なセッションでは、人間が計画上の意思決定の約70％を担当し、Claudeが実行上の意思決定の約80％を担当していました。

初心者と判断されたユーザーのプロンプトからは平均約5アクション、専門性の高いユーザーのプロンプトからは約12アクションが生じていました。専門性は肩書ではなく、指示をどれだけ的確に設定したか、何を検証させたか、AIの誤りを修正できたかで評価されています。成功率も、ユーザーがタスク固有の専門性を示したセッションほど高くなりました。

AIが一回の指示から実行できる仕事量が増えるほど、最初に与える方向、評価基準、制約の質が、より大きく結果を左右します。間違った方向へ一歩進むAIより、間違った方向へ25時間走り続けるAIの方が危険です。

8．Human-in-the-loopからHuman-on-the-loopへ

全面的にHuman-on-the-loopへ移行すればよいわけではありません。

Anthropicが約99万件の公開APIツール呼び出しを分析した結果では、80％に何らかの安全策があり、73％は何らかの形で人間がループへ関与し、不可逆的と推定された処理は0.8％でした。ただし、Claudeによる分類を含み、Anthropicが実際の処理結果をすべて観測できるわけではないという限界があります。

実務上の正解は、リスクごとの混在です。調査、静的解析、テスト生成はon-the-loop、ローカルのコード変更はon-the-loopと事後レビュー、PR作成は自動化可能、PRマージは条件付き承認。本番デプロイはin-the-loop、データ削除、送金、顧客送信は強いin-the-loopに置きます。緊急時のロールバックは自動化と即時通知の組み合わせも選択肢です。

Human-on-the-loopが成立するには、人間が状況を観測し、異常を理解し、間に合う速度で介入でき、停止権限を持ち、ロールバックでき、責任者が明確でなければなりません。「AIへ任せました。時々見ています」では、監督とは言えません。

図4：AIは内側の実行ループを回せる。人間は外側で、制約、証拠、承認、停止、復旧、最終責任を所有する。

結論：正解を書く人から、正解へ収束する世界を設計する人へ

プロンプトエンジニアリングの時代が終わると言われています。ですが、プロンプトそのものがなくなるわけではありません。

プロンプトは一回の会話から仕様書へ移り、AGENTS.mdやCLAUDE.mdへ移り、ハーネスへ入り、ループやグラフの中へ埋め込まれていきます。

人間の仕事は、AIに一つずつ命令することから、AIが正しい方向へ進み、間違いを検知し、必要なときに止まれる仕組みを作ることへ変わります。

そのとき必要なのは、頭の中のすべてを完璧に言語化する能力ではありません。自分が何を言葉にできていて、何をまだ言葉にできていないのかを知ることです。

抽象的な目的と具体的な例。守るべき思想と機械的に確認できるテスト。良いものの感覚と悪いものの実例。その間をAIと共に何度も往復し、合意した内容を再利用可能な仕組みへ固定する。

これからのエンジニアは、AIに正解を書かせる人ではない。AIが正解へ収束できる世界を設計する人になる。

参考資料

• Addy Osmani, “Loop Engineering”
• Addy Osmani, “Own the Outer Loop”
• Anthropic, “Building effective agents”
• Geoffrey Huntley, “Ralph Wiggum as a software engineer”
• Anthropic, “Effective context engineering for AI agents”
• OpenAI, “ハーネスエンジニアリング”
• Prefect, “Loops vs. graphs”
• Google, “Agent Development Kit 2.0”
• OpenAI, “Prompt engineering”
• OpenAI, “Codex best practices”
• METR, “Time Horizon”
• Anthropic, “Measuring AI agent autonomy in practice”