Loop Engineering とは？AI Agent 時代のループエンジニアリング完全解説

• 大數軟體
• 2026年8月9日8:57

Prompt Engineering から Loop Engineering へ：エンジニアリングの重心、三度目の移動

2021 年から 2023 年にかけて、業界の関心は Prompt Engineering に集まっていました。一つのプロンプトをいかに巧みに書き、モデルから一発で使える答えを引き出すか、という問いです。2025 年 2 月には Andrej Karpathy が Vibe Coding を提唱し、エンジニアは AI に最初のコードを書かせ、自分は仕上げを担当するという進め方に慣れていきました。この段階における人間と AI の関係は、ベビーシッターと子どもの関係に近いものでした。手を動かすのは AI ですが、人間はそばで一部始終を見張り、いつでも尻ぬぐいできるよう身構えています。そして 2026 年 6 月、Addy Osmani が「Loop Engineering」を発表し、Andrew Ng がこれを話題のキーワードだと評しました。Claude Code や Codex のような agentic coding ツールが日常の道具になるにつれ、Loop Engineering（ループエンジニアリング）は開発者コミュニティに急速に広まっています。ここで一点補足しておくと、この三つは年代ごとに互いを置き換えるものではなく、層として積み上がっていく働き方です。

この移動の背景にある論理は、いたって単純です。モデルが一度コードを生成するコストは下がり続けていますが、Agent にループを何度も回させれば、トークン、ツール呼び出し、人手によるレビューのコストがまとめて膨らみます。希少な資源は「コードを書けること」から「限られた予算の中でループを信頼できる形に設計できること」へと移りました。同じモデルを使っていても、ツール、コンテキスト管理、検証方法、停止条件は最終成果を明確に左右します。モデルの性能とループの設計は、同じ重みを持つ二つの変数だと考えるべきです。

Loop Engineering とは何か

この言葉を提唱した Addy Osmani は、非常に的確な定義を与えています。ループエンジニアリングとは、Agent にプロンプトを出し続けているその人間を外し、代わりにその役割を担うシステムを自分で設計することです。このシステムは、やるべき仕事を見つけ、Agent に割り当て、結果を検証し、進捗を記録し、そして次に何をするかを決めます。実装にあたっては、六つの点をはっきりさせる必要があります。何が起動条件になるのか、目標は何か、どのツールを使ってよいのか、どう検証するのか、いつ止めるのか、状態をどこに保存するのか、です。

これは「AI が一度で正解を出すこと」への期待を、「AI が設計されたループの中で正解に近づき続けること」というエンジニアリングの構造へと置き換える考え方です。

もう少し生活に引きつけた比喩を使うなら、Loop Engineering とは、自分の立ち位置をベビーシッターからコーチへ移すことです。コーチは選手の代わりに走ったりはしません。練習メニューを設計し、合格基準を決め、選手が反復と feedback を通じて自ら強くなる仕組みをつくります。人間は AI の一挙手一投足を見張るのをやめ、代わりに関門の設計が正しいかどうかを見張るようになるのです。

一回きりのプロンプトはコイン投げに似ています。要件をモデルに投げ、使える結果が返ってくることを祈るしかありません。一方ループは、feedback 制御器を組み込んだシステムに似ています。各ラウンドの出力は必ず検証され（テストを走らせる、コンパイルする、仕様と突き合わせる）、その検証結果が次のラウンドの入力として Agent に返ります。モデルが間違えること自体は問題ではありません。重要なのは、その誤りをループが捕捉して修正できるかどうかです。

Andrew Ng の三つの重要なループ

AI 分野の研究者である Andrew Ng（呉恩達）は、0 から 1 のプロダクトをつくるときの三つの重要なループについて語っています。これは正式なフレームワークの名称ではなく、彼自身の実践の整理です。三つは互いにつながりながら、それぞれ異なる速度で回っており、内側から外側への三つの層として理解できます。

• Agentic Coding Loop（数分ごとに一周）：AI Agent 自身が回す層です。コードを書き、テストを走らせ、結果を見て、仕様を満たすまで修正します。仕様、テスト、権限の境界が十分に明確であれば、この層は人間が逐一介入する必要を大きく減らせます。ただしリスクの高い操作については、承認や停止条件を残すべきです。
• Developer Feedback Loop（十数分から数時間）：エンジニアが回す層です。Agent の成果物をレビューし、方向を修正し、仕様を更新します。エンジニアの役割は「コードを書く人」から「ループを操縦する人」へと変わります。
• External Feedback Loop（数時間から数日、数週間）：現実世界が回す層です。テストユーザー、A/B テスト、リリース後の本番データが、プロダクトの方向そのものを修正します。

この三層は、一軒のレストランの回り方によく似ています。調理場のスタッフが手順書どおりに料理を出し、自分で味を確かめるのが内側の層。料理長がフロアを回って味見をし、レシピを調整するのが中間の層。そして市場での評判や予約の入り方がメニューの方向を決めるのが外側の層です。三つのループの速度差こそが、役割分担の根拠になります。自動で検証できることは最も速い内側のループへ、人間の判断が要ることは中間へ、市場の検証が要ることは外側へ。Loop Engineer の仕事とは、どの事柄をどの層のループに置くのか、そして各層の検証器をどう設計するのかを決めることです。

よくある四つのループパターン

実務の現場では、ループの設計にも再利用できるいくつかの型が生まれています。以下は MindStudio による整理を踏襲したもので、四つのパターンはそれぞれ異なる性質のタスクに向いています。ただし各社のフレームワークで名称は統一されておらず、これは正式な標準ではない点にご注意ください。

1. Retry（リトライループ）：最も単純な形です。失敗したらエラーメッセージを添えてやり直します。コンパイルやフォーマット検証のように、成功の判定基準が明確なタスクに向いています。実装時にはリトライ上限と「進展がなければ止める」条件を必ず設定してください。まったく同じ状態で試行を繰り返すだけでは、予算を焼くだけに終わります。
2. Plan-Execute-Verify（計画、実行、検証）：まず Agent に計画を立てさせ、順に実行し、各ステップで検証します。データパイプラインの構築のように、手順の多い複雑なタスクに向いています。
3. Explore-Narrow（発散、収束）：まず複数の方向を並行して試し、評価の仕組みによって最良の解へ収束させます。アーキテクチャ設計やコピーライティングのように、解の空間が広い問題に向いています。
4. Human-in-the-Loop（人間がループの中に入る）：重要な節目に人間のレビュー関門を置きます。Agent は行き止まりに入り込むこともあれば、制約条件を読み違えることもあり、領域固有の判断を必要とする場面もあります。よいループ設計は、すべてをやり直さずとも、人間が処理を一時停止し、方向を修正し、コンテキストを補えるようにします。これにはシステム側が実行状態を保存できることが前提であり、すべてのツールがこの機能を備えているわけではありません。

具体例を一つ挙げましょう。Agent に月次のソーシャルリスニングレポートを作成させるとします。Retry であれば、必要な章が欠けているときに自動で書き直させます。Plan-Execute-Verify であれば、まず「データ取得 → 話題量の集計 → サマリー執筆 → グラフ生成」の四段階を洗い出し、各段階の完了ごとに成果物の存在と形式を確認します。Explore-Narrow であれば、三つの Agent にそれぞれサマリーを書かせ、評価役のモデルに最良のものを選ばせることができます。そして Human-in-the-Loop であれば、レポートを顧客に送る前にアナリストの承認関門を一つ置きます。一つのフローで複数の型を同時に採用してもかまいません。たとえば、まず計画を立て、各ステップに回数制限つきのリトライを設け、社外に出す前に人手の承認を一段挟む、といった組み合わせです。なお、この組み合わせと先ほどの Andrew Ng の三つのループは別の話です。前者は一つのフローの中の設計手法を、後者はプロダクト開発における三種類の feedback のリズムを指しています。

なぜ日本企業が今 Loop Engineering を理解すべきか

これは開発者界隈の新しい流行語にとどまりません。企業の AI 導入にとって、三つの直接的な意味を持っています。

1. AI ツールを評価するときは、モデルではなくループを見る

同じモデルを載せた二つの製品でも、体験はまったく違うものになり得ます。その差はループにあります。自動検証はあるか。エラーはどう feedback されるか。人間が介入するためのインターフェースは使いやすいか。製品選定にあたっては、モデルのベンチマークスコアを比べるだけでなく、「ループの設計」を評価項目に加えるべきです。

2. 社内プロセスの自動化は「検証できるタスク」から始める

ループは検証器がなければ回りません。帳票の形式は正しいか、数値の合計は整合しているか、書類に必要な項目が含まれているか。こうした判定基準の明確なタスクこそ、まず agentic なループに任せるのに向いています。逆に、経営判断のように基準が曖昧なタスクは、人間をループの中に残すべき領域です。

3. 知識が還流してこそ、次のループはゼロから始めずに済む

各ラウンドのループが生み出す誤り、修正、意思決定の文脈は、いずれも価値ある組織知です。これらが対話ログの中に散らばったままなら、毎回ゼロからのやり直しになります。選別とバージョン管理を経た知識ベースとして蓄積できれば、後続のループは既存の文脈を再利用できます。ここではっきりさせておきたいのは、これによって改善されるのは AI が手に入れられる文脈であって、モデル自体が賢くなるわけではないという点です。選別なしに誤りや古びた決定まで一緒に保存すれば、かえって後の判断を汚染します。これこそが、企業のナレッジマネジメントシステム（RAGi のような企業向け RAG プラットフォーム）が agentic 時代に担う新しい役割です。社員の質問に答えるだけでなく、AI のループが長期的な文脈を取りにいく場所になるのです。また会議や意思決定の文脈の整理（たとえば AIMochi）は、人間が担う層のループにおける判断を記録し、引き継げるものにします。

注意しておきたいのは、ループは自動化すればするほどよい、というものではないことです。金融や公的機関のような規制のある領域で、一件ごとの人手承認が必須かどうかは、具体的な用途、リスクの水準、適用される法規によって変わります。仮に一件ごとの審査義務がない場合でも、責任の分担と監査可能な記録、つまり誰が何を、どの情報に基づいて承認したのかを残す仕組みは通常必要になります。企業環境においてループの基盤が「自動化」と「追跡可能性」を同時に満たさなければならないのは、このためです。各ラウンドの入力、出力、そして人間の意思決定は、コードのバージョン管理と同じように再生できるべきです。この層を欠いたまま agentic な自動化の規模だけを広げれば、ガバナンス上のリスクはそれだけ高まります。

役割別のアクションプラン

• エンジニア：仕事を「自動で検証できるもの」と「人間の判断が要るもの」の二つに分ける練習をしてください。前者はループとして設計して Agent に任せ、後者はレビューに集中する。あなたの価値は、コードを書くことからループを設計し操縦することへ移りつつあります。
• エンジニアリングマネージャー：チームの Definition of Done を見直してください。ループに無人で完了まで走りきってほしいのであれば、成功条件は可能な限り機械が検証できる形で書く必要があります。主観的な判断や高リスクな意思決定が絡む場合は、Definition of Done に人手の承認を一段含めてかまいません。
• 経営の意思決定者：AI 投資の重点は「最強のモデルを買うこと」から「検証でき、feedback が返り、知識が蓄積されるループ基盤を築くこと」へ移りつつあります。まず判定基準の明確なプロセスを棚卸しし、そこから着手してください。

おわりに

Prompt Engineering は AI への話しかけ方を教えてくれました。Loop Engineering が教えてくれるのは、AI との協働の仕方です。モデルの性能が伸び続け、トークンのコストが下がり続けるとき、企業とエンジニアの本当の差別化要因はループの設計に宿ります。検証器は十分に厳密か。人間が介入するタイミングは適切か。知識はシステムへ還っているか。企業にとって「AI を使いこなす」ために必要な能力もまた広がりつつあります。プロンプトを書けるだけでなく、検証を設計し、停止条件を定め、権限を管理し、そして知識を次のループへ還流させられることが求められているのです。

参考資料：Addy Osmani: Loop Engineering、Andrew Ng が語る三つの重要なループ、MindStudio: What Is Loop Engineering?、The Agentic Loop: A Practical Field Guide、Loop Engineering Guide (2026)