ループエンジニアリングとは？AIエージェントを自走させる設計と実践【2026年版】

---

午前9時、エンジニアがパソコンを開く前に、AIは昨夜のCIエラーを分類し、修正案を作り、別のAIによる確認まで終えていた。

だが、本当に重要なのはAIがコードを書いたことではない。何を調べ、どこまで直し、何を証拠に「完了」と判定し、どの異常で人間を呼び戻すかが設計されていたことである。

プロンプトを一つずつ入力する働き方から、AIが安全に反復できる仕組みを設計する働き方へ。その転換を表す概念が「ループエンジニアリング」である。

ループエンジニアリングとは？プロンプト・ハーネスとの違い

ループエンジニアリングとは、一回ごとの指示ではなく、AIが目標へ向かって動き、検証し、停止する循環そのものを設計する考え方である。

午前9時、AIはすでに働き終えていた

これまでAIコーディングエージェントを使う仕事は、人間とAIのキャッチボールでした。人間が「このエラーを直して」と頼み、回答を読み、「ではテストも追加して」と指示する。テストが落ちれば結果を貼り付け、もう一度修正を求めます。

どれほど高性能なAIを使っても、次の指示を考えて入力する人間が、常に画面の前に必要でした。では、その人間が画面を離れたとき、AIは何を頼りに仕事を続けるのでしょうか。

ところが、冒頭の開発チームでは違います。午前2時にCIが失敗すると、監視システムが異常を検知します。AIがログを読み、既知の失敗か新しい問題かを分類します。修正可能なら隔離された作業環境でコードを変更し、テストを実行します。

その結果を、コードを書いたAIとは別のAIが確認します。基準を満たせばプルリクエストを作成し、判断できなければ証拠とともに人間へ引き継ぎます。

朝、エンジニアが受け取るのは「エラーが出ました」という通知ではありません。「何が起き、何を試し、どのテストに合格し、何が未解決なのか」という、判断可能な状態です。

人間は一つひとつの作業から離れましたが、仕事そのものを手放したわけではありません。 作業の順序、権限、判断基準、停止条件を、人間が先に設計していたのです。

この夜に起きたことを順番にたどると、ループエンジニアリングという新しい概念の輪郭が見えてきます。まずは、従来のAI活用と何が違うのかを確認しましょう。

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

2026年6月8日、ソフトウェアエンジニアのAddy Osmani氏は「Loop Engineering」を公開しました。同氏はループエンジニアリングについて、人間がエージェントへ逐次指示する代わりに、エージェントへ指示を与えるシステムそのものを設計することと説明しています。

そのシステムは、仕事を見つけ、AIへ割り振り、成果を確認し、進捗を記録し、次に行うことを決めます。Osmani氏は、この設計領域をAIエージェントの実行環境である「ハーネス」の一段上に位置づけています。

つまり、ループエンジニアリングとは、AIへ一度だけ答えを作らせる方法ではなく、目標達成まで「実行→検証→記録→次の判断」を反復させる設計です。 プロンプトエンジニアリングが一回の指示を扱い、ハーネスエンジニアリングが一回の実行環境を扱うのに対し、ループエンジニアリングは複数回の実行をどの順番で積み上げ、いつ止めるかを扱います。

ただし、これは「プロンプトエンジニアリングの終わり」ではありません。プロンプトは、ループの内部で引き続き使われます。変わるのは、毎回人間が書くのではなく、状況に応じて仕組みが適切な指示をAIへ渡す点です。

AI活用における4つの設計レイヤー

設計レイヤー	主な設計対象	中心となる問い
プロンプト	1回の指示	AIに何を頼むか
コンテキスト	資料・履歴・制約	AIに何を見せるか
ハーネス	ツール・権限・実行環境	AIをどこで、何を使って動かすか
ループ	反復・検証・停止・再開	いつ動き、何を証拠に続行・停止するか

単発の会話を調整する仕事から、AIが動き、確かめ、記録し、止まる制御系を設計する仕事への拡張。これが、ループエンジニアリングの本質です。

では、午前2時に検知された一つのエラーは、どのような仕組みを通って午前9時の報告へ変わったのでしょうか。舞台裏には、六つの部品が連動していました。

ループエンジニアリングの仕組み｜6つの構成要素

AIを自走させるには、自動実行、隔離環境、スキル、接続、役割分離、外部記憶を一つの仕組みとして組み合わせる必要がある。

自律的に見えるAIを支える6つの部品

午前2時にCIエラーを見つけただけでは、AIは仕事を終えられません。作業を始めるきっかけ、変更を隔離する場所、プロジェクト固有の手順、現実の業務との接続、別視点からの確認、そして翌朝まで仕事をつなぐ記憶が必要です。

Osmani氏は、実用的なループを支える要素として、5つの部品と外部記憶を挙げています。 この六つは便利機能の寄せ集めではなく、AIが一つの仕事を安全に完走するための連結部品です。

• 自動実行：時刻やイベントをきっかけに、調査・分類・処理を始める
• 隔離環境：複数のAIが同じファイルや本番環境へ干渉しないよう分離する
• スキル：作業手順、設計原則、禁止事項、過去の教訓を外部化する
• コネクター：課題管理、GitHub、Slack、データベースなど実際の業務へ接続する
• サブエージェント：作る役割と確かめる役割を分ける
• 外部記憶：何を試し、何が終わり、次に何をするかを会話の外へ残す

なかでも見落とされやすいのが、外部記憶です。AIの会話履歴だけに進捗を置くと、コンテキストの上限やセッション終了によって、仕事の連続性が失われます。

進捗ファイル、課題管理ボード、データベース、作業ログなどへ状態を残せば、AIが前回の会話を忘れても仕事を再開できます。長く動くループの鍵は、AIの記憶力を信じることではなく、忘れても再開できる状態を作ることです。

冒頭のAIが午前9時まで仕事を引き継げたのも、この外部記憶があったからです。しかし、記録が残っているだけでは、修正が正しいとは限りません。次に必要なのが、作る役割と確かめる役割の分離です。

作るAIと確かめるAIを分ける

ループ設計で特に重要なのが、MakerとCheckerの分離です。自分で書いたコードや文章の誤りを、自分自身では見つけにくいのと同じ原理です。

コードを書いたAIに「正しくできましたか」と尋ねても、自分が採用した前提や見落としを、そのまま引き継ぐ可能性があります。そこで、実装するAIと、仕様・テスト・安全性を確認するAIを分けます。

これは人間の組織と同じです。申請者と承認者、開発者とレビュー担当者、取引実行者と監査担当者を分けるのは、誰かを疑っているからではありません。同じ視点に閉じた判断を避けるためです。

午前2時の修正案を別のAIが確認したのは、このMaker–Checkerの考え方によるものです。ただし、Checkerが「問題ありません」と言うだけでは、まだ不十分です。何をもって正しいとするのか、その証拠が必要になります。

評価基準をどのように設計へ落とし込むかは、AI Evalsとは？生成AIを本番投入する前に必要な評価設計で掘り下げています。

「完了しました」は証拠ではない

午前9時の通知に「修正が完了しました」とだけ書かれていたら、あなたは安心してマージできるでしょうか。AIは、その一文を簡単に生成できます。しかし、コードが動くのか、要件を満たしているのか、副作用がないのかは、その言葉からは分かりません。

ループに必要なのは、完了条件だけではありません。完了を裏づける証拠です。

たとえば「ログイン機能を修正する」という目標なら、認証テストが成功した、型チェックに合格した、既存のアクセス制御に変更がない、変更範囲が指定ファイル内に収まっている、といった機械的に確認できる証拠へ変換します。

Anthropicが2026年7月24日に公開した公式ウェビナーでも、動作するループの要点として、完了の定義、予算、チェックポイント、止まらないループの修正が挙げられています。

優れたループは、成功したときに止まるだけではありません。失敗したときにも、安全に止まれます。

テストが3回続けて失敗した。予定時間を超えた。費用上限へ達した。権限外の操作が必要になった。要求に複数の解釈が生じた。このような場面で無理に続けず、人間へ戻せることが本番運用では重要です。

つまり、午前9時の報告を信頼できるものにしたのは、AIの流暢な説明ではなく、テスト、差分、ログ、停止記録という証拠でした。

どこで停止し、どの操作を人間の承認へ戻すかは、AIエージェントのGuardrailsとは？Human Review・承認フロー・停止条件の設計実務に判断をつないでいます。

ループエンジニアリングの設計方法｜Loop Contract

完全自律化を競うのではなく、目標、証拠、予算、停止、人間への引き継ぎを先に契約のように定義する設計が重要である。

Arpable式「Loop Contract」

ここまでで、午前2時から午前9時までの仕事を支えた部品は見えてきました。しかし、部品を並べただけではループは動きません。誰が設計しても同じ境界を共有できるよう、仕事の約束を先に書き出す必要があります。

そこでArpableでは、ループを作る前に決めるべき要素を、Loop Contractとして7項目に整理します。これは業界標準ではなく、一次情報と28年間のプロジェクト管理経験をもとにした、Arpable独自の判断フレームです。

午前2時のCIエラーをLoop Contractで分解する

抽象的な定義だけでは使い方が見えにくいため、冒頭のCIエラー対応をそのまま設計表へ落としてみましょう。

午前2時のCIエラーに適用したArpable式 Loop Contract

項目	設計する問い	CIエラー対応の記入例
Goal	何を、どの状態にするか	昨夜のCI失敗を分類し、修正可能ならPRを作成する
Trigger	いつ開始するか	GitHub Actionsが失敗したとき
Scope	何を変更できるか	隔離ブランチだけを変更し、本番環境には触れない
Evidence	何をもって完了とするか	全テスト成功、Lintエラー0、変更ファイル5個以内
Budget	上限をどこに置くか	最大3回、20分、API費用0.50ドル以内
Stop	どの状態で止めるか	証拠がそろった、3回連続失敗、権限外操作が必要
Escalation	誰へ何を渡すか	ログ、差分、未解決事項をSlackで開発チームへ通知する

※上表の回数、時間、費用はLoop Contractの考え方を具体化するための例示です。実際の運用値は、業務の重要度、利用モデル、コスト方針に応じて設定します。

午前9時の報告が信頼できたのは、AIが賢かったからだけではありません。午前2時より前に、人間がこの契約を書いていたからです。

運用サイクルは、Goal → Act → Verify → Record → Decide → Stop / Escalateです。目標に向かって行動し、証拠で確認し、結果を外部へ記録する。その記録を基に、続行、停止、人間への引き継ぎを判断します。

特に重要なのがEvidenceとEscalationです。AIに何をさせるかは、多くの企業が熱心に考えます。しかし、どの証拠があれば信頼できるのか、信頼できない場合に誰が引き取るのかは後回しになりがちです。

証拠と引き継ぎ先が決まっていないループは、自動化された業務ではありません。誰も責任を取れない仕事が、高速で回転しているだけです。

状態管理、中断再開、Human-in-the-Loopを技術としてどう実装するかは、LangGraphとは？LangChain・CrewAI・MAFとの使い分けと本番設計に譲ります。

ここで設計の焦点は、「AIをどこまで自由にするか」から「何が起きるかをどこまで見通せるか」へ移ります。

目標は自律性ではなく予見可能性

28年間、大小さまざまなプロジェクトを動かす中で、私が何度も痛感してきたことがあります。現場を救うのは、単なる能力の高さではなく、次に何が起きるかを見通せる予見可能性です。

これは、未来をすべて正確に当てるという意味ではありません。何が分かっていて、何が分からないのか。どの条件なら続行でき、どこから先は人間の判断が必要なのか。その境界が見えることです。

IBM Researchなどの研究者が、306人の実務家と26分野・20件のケーススタディを調査した研究では、本番稼働するAIエージェントの68％が、人間の介入までに実行するステップを10回以下に抑えていました。70％は既存モデルへのプロンプト設計を中心に構築され、74％は主として人間による評価に依存していました。最大の課題として挙げられたのは、長期にわたり一貫して正しく振る舞う「信頼性」でした。

現場で求められているのは、何十時間も自由に考え続けるAIだけではありません。短いステップ、明確な制約、確認可能な成果、人間へ戻す経路を持つAIです。

午前9時の報告で重要なのも、AIが何回考えたかではありません。どの判断を通り、どの証拠で止まり、どこが未解決かを人間が追えることです。

本番中の足跡をどう残し、判断の逸脱をどう見つけるかは、AIエージェントObservabilityとは？予見可能性を高めるトレース・ログ・失敗監査の設計で扱っています。

人間はループから消えるのではない

ここまで読むと、「人間はループから外れてしまうのか」という疑問が生まれるかもしれません。実際に移動するのは、人間そのものではなく、役割の位置です。

人間が離れるのは、AIのすべての行動に逐一指示を出す内側の実行ループです。一方、人間は外側で、何を任せるか、どの権限を与えるか、どの証拠を信頼するか、どこで止めるか、誰が責任を負うかを決めます。

Osmani氏も2026年7月9日の「Own the Outer Loop」で、AIが調査・実装・検証を反復する内側のループを担い、人間は境界で証拠を確認し、進めるかどうかの判断と説明責任を負うべきだと論じています。

ループエンジニアリングによって変わるのは、人間の存在ではなく役割の重心です。反復作業の比重は下がり、設計、評価、説明責任が前面に出ます。

冒頭のエンジニアも、午前2時に手を動かしてはいません。しかし、午前9時に証拠を読み、マージするか、差し戻すか、設計そのものを直すかを判断します。ここから物語は、仕組みの理解から実際の導入へ進みます。

ループエンジニアリングの実践方法・実装例

最初から完全自律を狙わず、証拠を取りやすく、失敗しても戻せる小さな実装例から始めるべきである。

入門から実践へ｜小さなループを作る5ステップ

ここからは、冒頭のCIエラー対応を「明日から小さく始める」と仮定し、設計から実装までの順序をたどります。完成形を一度に作るのではなく、午前9時の報告に必要な要素を一つずつ足していきます。

繰り返し発生する低リスク業務を一つ選ぶ

最初の対象は、仕事の入口と出口が見えやすいものにします。CIエラーの分類、更新依存関係の調査、定期レポートの下書き、FAQ候補の抽出、古いドキュメントの検出などです。

顧客への自動送信、本番データの削除、金銭処理といった不可逆な業務から始めるべきではありません。

曖昧な完了条件を証拠へ変換する

「品質の高い成果物を作る」では、AIはいつまでも改善を続けられます。「指定した見出しを含む」「一次情報を3件以上確認する」「禁止表現がない」「テストがすべて通る」など、検証可能な条件へ変換します。

外部状態へ必ず記録する

何を調査し、何を変更し、何が未解決なのかを、会話の外へ記録します。次の実行時には、その状態を読み込んで再開させます。成功だけでなく、失敗した方法や判断不能だった項目も残します。

MakerとCheckerを分離する

最初から大規模なマルチエージェントを作る必要はありません。作る役割と確かめる役割の二つに分けるだけでも、自己評価への依存を減らせます。CheckerにはMakerの説明ではなく、仕様、変更差分、テスト結果などの証拠を渡します。

予算、停止、引き継ぎを先に決める

「3回失敗したら停止」「20分を超えたら人間へ戻す」「権限外の操作が必要なら承認を求める」など、失敗時の挙動を先に決めます。

自律性は、AIに与える自由の大きさではなく、安全に戻ってこられる範囲の大きさで決めるべきです。

ここまでそろえば、AIは「何となく修正を試すツール」から、「限られた範囲で仕事を完走し、証拠を持って戻るループ」へ変わります。

この小さな実装をPoCから本番運用へどう広げるかは、AIエージェント導入ガイド2026｜PoC・本番移行・ガバナンス設計で導入プロセス全体を整理しています。

Claude Code・Codex・GitHub Copilotなどで実践できるか

ループエンジニアリングは、特定のツールやフレームワークの商品名ではありません。ターミナルや外部ツールを操作できること、状態を保存できること、テストなどで結果を検証できること、停止条件を設定できることが実装の条件です。

ここで、「そのループは何を使って動かすのか」という疑問が出てきます。Claude Code^[5]、OpenAI Codex^[6]、GitHub Copilot^[7]、Cursor^[8]、Google Antigravity^[9]などは、ループを構成する実行基盤の候補です。

ただし、ツールを導入しただけでは、午前9時に信頼できる報告は届きません。Goal、Evidence、Budget、Stop、Escalationを設計して初めて、単発のAIコーディングが制御可能なループへ変わります。

代表的なAI開発ツールとループ実装で注目する機能

ツール	ループ実装で活用できる特徴	注意点
Claude Code	CLIやSDKからコードの検索・編集・テスト・自動化を組み込める	自己評価だけに依存せず、外部テストと承認を置く
OpenAI Codex	複数エージェント、スキル、Automationsを使った反復作業を構成できる	並列化するほどコストとレビュー量も増える
GitHub Copilot	隔離環境でコード変更、テスト、Lint、プルリクエスト作成まで進められる	リポジトリ権限、ネットワーク、Actions利用量を管理する
Cursor	Background Agentsを遠隔・非同期で動かし、状態確認や引き継ぎができる	インターネット接続やデータ保持の条件を確認する
Google Antigravity	Gemini系エージェント、skills.md、agents.md、ワークフローを組み合わせられる	製品機能は更新が速いため、公開時点の公式仕様を確認する
※各機能は公式ドキュメントに基づく2026年8月2日時点の情報です。機能・提供条件は変更される可能性があります。

ローカルLLMでも、ツール実行、外部記憶、検証、停止を別の仕組みで補えば原理上は実装できます。モデルをどこで動かすかよりも、仕事がどの証拠を通って人間へ戻るかが、ループ設計では重要です。

そして、ここで「確認を強くするためにAIを増やせばよい」と考えると、次の落とし穴に入ります。

マルチエージェント化すれば良いとは限らない

一つのAIに調査、実装、評価をすべて任せるより、役割を分けた方が精度を高められる場合があります。しかし、AIの数を増やせば、成果と同時にコスト、調整、レビュー負荷も増えます。

AnthropicのResearchシステムでは、Claude Opus 4をリードエージェント、Claude Sonnet 4をサブエージェントとして使った構成が、同社の内部研究評価で単一のClaude Opus 4を90.2％上回りました。一方、通常のチャットと比べ、エージェントは約4倍、マルチエージェントシステムは約15倍のトークンを使ったと報告されています。^[10]

ただし、これはAnthropicのResearch機能と内部評価における結果です。同社自身も、多くの依存関係を持つ作業は現在のマルチエージェントに適さない場合があり、調査のように独立した探索を並列化できる高価値タスクへ向くと説明しています。

別の視点が必要な場所にだけ、別のAIを配置する。 これが実務的な判断です。午前2時のCI対応でも、実装役と確認役の二つで足りるなら、三つ目、四つ目のAIを増やす理由はありません。

ループは賢く見えるほど安全になるわけではありません。むしろ、静かに回り続けるようになったときこそ、見えない負債が膨らみ始めます。

ループエンジニアリングのコストと3つの失敗パターン

午前2時から午前9時まで、通知もなく静かに動き続けるループは、本当に安全なのでしょうか。 人間が手を動かさずに済む仕組みは、裏で何が起きているか分からない仕組みにもなります。

暴走コスト

停止条件が曖昧なループは、同じ調査や修正を何度も繰り返します。予算には金額だけでなく、最大実行時間、最大試行回数、最大変更ファイル数、サブエージェント数も含めます。

理解の負債

AIが短時間で大量のコードや資料を作ると、人間の理解が追いつかなくなります。障害や仕様変更が起きたとき、誰も設計意図を説明できない状態になれば、短期的な速度向上は長期的な保守コストへ変わります。

既存システムでは、重要な仕様がコードだけに存在するとは限りません。過去の障害、顧客との合意、例外対応、現場の暗黙知という「傷跡」に、本当の業務ルールが残っています。

認知的な降伏

AIの結果が頻繁に正しいと、人間は次第に判断すること自体をやめてしまいます。テストが通ったから正しい。Checkerが承認したから安全。過去に問題がなかったから今回も大丈夫。その積み重ねで、人間がAIの結論へ形式的に署名するだけになれば、外側のループは機能していません。

ループの目的は、人間の思考を止めることではありません。機械が代替しにくい判断へ、人間の注意を集中させることです。

だからこそ、すべての業務をループ化すればよいわけではありません。冒頭のCI対応を別の業務へ広げる前に、立ち止まって確認すべき条件があります。

あなたの業務はループ化できるか

次の項目に当てはまる場合は、導入を諦めるのではなく、ループの範囲を小さくする必要があります。

• 成果の良し悪しを説明できない
  → ループを作る前に、評価指標と完了証拠を定義します。
• 正解が状況によって大きく変わる
  → 固定ルールで判断できる工程だけを切り出します。
• 一度の誤操作が重大な損害につながる
  → 完全自動化せず、人間の承認ゲートを置きます。
• 責任者や引き継ぎ先が決まっていない
  → AIの実装より先に、運用責任とエスカレーション経路を決めます。
• 参照すべきデータや禁止事項が整備されていない
  → スキルと外部記憶を整備してから自動実行へ進みます。
• 人間が理解できないほど広い変更を許可する
  → Scopeを狭め、一回の変更量に上限を設けます。

創造的な企画や経営判断でも、調査、論点整理、反対意見の生成、シナリオ比較など、判断を支援する内側の工程だけをループ化できます。

ここまでが、午前2時の障害を安全な午前9時の報告へ変えるための実務設計です。最後に物語から一歩離れ、この新しい概念について一次情報がどこまで語っているかを確認します。

一次情報からどこまで言えるか

概念の有用性は確認できる一方、ループエンジニアリングはまだ成熟した標準手法として確立された段階ではない。

一次情報から確認できること

Addy Osmani氏の記事からは、ループエンジニアリングが、仕事の発見、割り当て、検証、記録、次の判断をシステム化する考えであることを確認できます。また、自動実行、隔離環境、スキル、コネクター、サブエージェント、外部記憶という構成も示されています。

Anthropicの公式ウェビナーは、完了の定義、予算、チェックポイント、停止しないループへの対応を、実装時の要点として挙げています。

本番AIエージェントの実態調査からは、現場で短いステップと人間の介入が重視され、信頼性が依然として最大の課題であることが確認できます。

Arpableの解釈

ループエンジニアリングは、次々と現れる流行語の一つとして消費されるべき概念ではありません。

Arpableでは、AIエージェントの実行を、予見可能な業務プロセスへ変換するための設計思想と位置づけます。

本記事のLoop Contractも、現時点の業界標準ではありません。一次情報で共通して重視される目標、検証、予算、停止、記憶、引き継ぎを、実務で確認しやすい形へ再構成した独自フレームです。

2026年6月末には、トリガー、目標、検証、停止規則、記憶からなる「Loop Specification」を整理したプレプリントも公開されていますが、査読済みの確立した標準ではありません。現時点では、概念整理を補助する研究として慎重に扱うべきです。^[11]

ツール名やコマンド、製品機能は今後も変わります。しかし、Goal、Evidence、Budget、Stop、Escalationという問いは残り続けます。午前2時の障害を扱うツールが別製品へ変わっても、午前9時に人間が確かめるべきものは変わらないからです。

まとめ

AIが内側で仕事を回し、人間が外側で目的・証拠・停止・責任を握ることが、ループ設計の核心である。

午前2時、CIが失敗しました。

そこからAIは、ログを読み、作業範囲を守り、修正を試し、別の視点で確認し、テスト結果と未解決事項を記録しました。午前9時、エンジニアの画面に届いたのは、AIの自信ではなく、判断に使える証拠でした。

この一夜を支えていたのが、自動実行、隔離環境、スキル、接続、Maker–Checker、外部記憶です。そして、それらを一つの仕事へ束ねていたのが、Goal、Evidence、Budget、Stop、Escalationを定めたLoop Contractでした。

AIは内側で仕事を回す。人間は外側で、目的、証拠、停止、責任を握る。

優れたループとは、長く動き続けるループではありません。必要な仕事を終え、証拠を残し、分からないときには立ち止まり、人間へ正しく戻ってこられるループです。

そして翌朝、午前9時。

エンジニアが受け取る通知の中身は、これからも変わり続けるでしょう。それでも変わらないものがあります。

その仕事を裏づける証拠を、人間が確かめられるか。

ループエンジニアリングが私たちに問いかけているのは、AIをどこまで働かせられるかではありません。AIが働く仕組みを、私たちはどこまで責任を持って設計できるかなのです。

専門用語まとめ

ループエンジニアリング

AIが目標に向かって反復作業を行えるよう、開始条件、実行、検証、記録、停止、引き継ぎを設計する考え方。

エージェントハーネス

AIモデルを実務で動かすための、ツール、ファイル、権限、サンドボックス、メモリ、監視などを含む実行環境。

Maker–Checker

成果物を作る役割と、その成果物を独立して確認する役割を分ける設計。

外部状態・外部記憶

会話の外に保存される進捗、試行結果、未解決事項。ファイル、データベース、課題管理システムなどを使う。

エスカレーション

AIが判断できない場合や、権限・予算・安全上の境界へ達した場合に、人間へ仕事を引き継ぐ仕組み。

参考文献 / 出典

次に読むならこの3本

補足Q&A

Q1.
プロンプトエンジニアリングとループエンジニアリングの違いは何ですか？

A1. プロンプトは一回の指示、ループは複数回の実行と検証の循環を設計します。

プロンプトエンジニアリングはAIへ何をどう伝えるかを扱います。ループエンジニアリングは、その指示をいつ渡し、実行結果を何で検証し、次に進むか、停止するかを含む全体の流れを扱います。プロンプトは不要になるのではなく、ループの部品として残ります。

Q2.
ハーネスエンジニアリングとループエンジニアリングの違いは何ですか？

A2. ハーネスは一回の実行を支える足場、ループは実行をどう積み重ね、いつ止めるかの設計です。

ハーネスエンジニアリングは、ツール、権限、サンドボックス、コンテキスト、ログなど、エージェントを動かす環境を整えます。ループエンジニアリングは、その環境を使って反復作業を開始し、検証し、記録し、停止・再開・エスカレーションする流れを設計します。

Q3.
Claude CodeやCodex、GitHub Copilotで実践できますか？

A3. 実践できますが、ツールを導入するだけでは不十分です。

Claude Code、Codex、GitHub Copilot、Cursor、Google Antigravityなどは実装基盤の候補です。どのツールでも、目標、完了証拠、予算、停止条件、外部記憶、人間への引き継ぎを設計する必要があります。

更新履歴