ループエンジニアリング Loop Engineering

ループエンジニアリング（Loop Engineering）とは、AIエージェント自身に成果物を判定させてやり直させることで、人が一手ごとに指示を出さなくても目標へ到達させる設計手法である。ここでいうループは「試す→出来栄えを確かめる→直す」という輪を指す。

AIエージェントが自身のミスを自ら直すためには、出来上がりを採点し、合格点に届くまで「何がいけなかったのか」を記すよう設計する。すると、エージェントは自分の失敗を踏まえて次の一手を変えられるようになる。

指示を磨くより、やり直し方を設計する

ループエンジニアリングの要点は、AIへの指示を磨くことではなく、AIが間違えた後の立ち直り方を設計することにある。

プロンプトエンジニアリングは指示文そのものを、コンテキストエンジニアリングはAIに渡す情報の取捨選択を扱う。どちらも1回の応答の質を上げる工夫にあたる。ループエンジニアリングが扱うのは、その1回が外れたときにどう立て直すかである。

何をきっかけに動き出すか、どこで合格と不合格を分けるか、外れたときに何を手がかりにやり直すか。エージェントに1回だけ指示を与えて終わらせるのではなく、これらを設計者があらかじめ決めておく。

あらかじめ決めた通りにしか動かない自動化に対し、ループエンジニアリングは実行結果を評価して次の一手を改善し続ける仕組みを持つ。

語源・提唱者

2026年6月、オープンソースのAIエージェント「OpenClaw」を作ったPeterペーター Steinbergerシュタインベルガーの「エージェントにプロンプトを打つループを設計すべきだ」というXの投稿が元になり、GoogleでエンジニアリングをリードするAddyアディ Osmaniオスマニが、「Loop Engineering」と題した記事で広まった。

人がAIの見張り役から抜けられる

ループを組まずにエージェントを動かすと、人間がチェック、修正しなければならない。さまざまなタスクをAIに任せたとしても、確認する人間の数は増えないので、待ち行列が伸びるだけになる。

検証の輪を組み込むと、この確認作業のうち機械的に判定できる部分をエージェント自身が担う。テストが通るか、リンクが切れていないか、決めた項目が埋まっているか。こうした判定は自動で回り、人間の手元には基準を決める仕事と、機械には判定できない最終判断だけが残る。

4つのループを入れ子に重ねる

AIアプリケーションライブラリを開発するLangChain社は、ループエンジニアリングが扱う輪を抽象度の異なる4つの層に整理している。

• エージェントループ：情報を受け取り、ツールを呼び出し、結果を確認する流れを、1つのタスクが終わるまで繰り返す、もっとも基本となる実行サイクルを指す

• 検証ループ：エージェントの出力を評価基準（ルーブリックという採点表）と照らし合わせて採点し、基準に届かなければ理由を添えてやり直させる層を指す

• イベント駆動ループ：決まったスケジュールや、外部サービスからの自動通知（Webhook）、チャットへの投稿といった出来事をきっかけにエージェントを起動する層を指す

• 改善ループ：本番で実行した記録を分析し、その結果をもとに指示文やツール、採点基準そのものを継続的に手直ししていく層を指す。頂上を探りながら少しずつ登る最適化の手法になぞらえ、山登り型のループとも呼ぶ

内側のエージェントループを、検証ループ・イベント駆動ループ・改善ループが順に包み込むように積み重なる。外側の層を重ねるほどエージェント全体の信頼性は上がるが、応答にかかる時間と実行コストも増える。

まず検証の輪をひとつ足してみる

実務では、いきなり4層すべてを組むのではなく、すでに動いているエージェントの外側に検証の輪をひとつ足すところから始めるとよい。新しく作る工程ではなく、運用中のエージェントに手を入れる工程にあたる。

この設計はエンジニアだけでは決まらない。何をもって合格とするかは、その業務を実際に回している担当者にしか判断できないためである。手を動かすのはエンジニアでも、合格基準の中身は業務側と一緒に決める。

作業の結果として手元に残るのは、採点表そのものである。「何が満たされていれば合格か」を書き出した一覧は、エージェントの判定基準であると同時に、チーム内で品質の合意を取る文書としても使える。

つまずきやすいのは、この採点表が曖昧なまま走り出す場合である。「わかりやすいこと」のような基準ではエージェントは合否を判定できず、やり直しが空回りする。

社内文書の改善を任せる例が分かりやすい。LangChain社は自社ドキュメントを直すエージェントに、この4層をそのまま当てはめている。社内チャットの決まったチャンネルにメッセージが届くと起動し、リポジトリを読んで修正案を書き、リンクが解決するか・自動テストが通るか・依頼された範囲から外れていないかを別のエージェントが採点する。実行記録は後から分析され、指示文や採点基準の手直しに回る。

自動化が進むほど中身が見えなくなる

一方で、ループを重ねるほど、担当者が処理の中身を理解しないまま結果だけを受け取る状態が生まれやすくなる。Osmaniはこれを「理解の負債」と呼び、ループがうまく回るほど負債が速く積み上がると書いている。あわせて、完了の報告を証明と取り違える「検証の負債」、自分で判断を作るのをやめてループの答えを受け入れるようになる「思考の明け渡し」の2つも危険として挙げている。

そのため、支払いやデータベースの操作など、後戻りが難しい判断が絡む場面では、ループの途中に人間の承認を挟む設計にしておく。人間を輪の外に出すという狙いは、人間の判断をすべて取り除くことを意味しない。判断が要る場所を絞り込み、そこに人間を残すこともループの設計に含まれる。

関連用語

• コンテキストエンジニアリング

プロンプトエンジニアリング

ヒューマン・イン・ザ・ループ