▸ループエンジニアリング
エージェントにプロンプトを与える役割の“自分自身”を置き換え、それを実行するシステムを設計すること。
▸HITLからHOTLへのシフト
人がループの「内側」にいる状態から、人がループの「外側」に立つ状態への変化。
▸ループを設計する力
AIが働き続けられる業務の仕組みを作り、組織の生産性を分ける重要な要素。
こんにちは、ワークスアイディの奥西です。
AIの最新情報についていけない…と感じる方が増えていますよね。私もその一人ではありますが、最近ではAIがすっかり趣味の領域にもなってきています。このコラムでは『最新情報』や『実務で体験した現場の情報』を発信していきますので、ぜひ参考にしていただけると嬉しいです！
本日は『最新情報』の回として、「ループエンジニアリングとは何か？」をご紹介します。
もともとはAIコーディングの現場から出てきた概念ですが、
「プロンプトを書くな、ループを書け」という潮流
2026年6月、AI開発の第一線にいる複数のキーマンから相次いで次のような発言がありました。
こうした動きを概念として整理し、「Loop Engineering（ループエンジニアリング）」という名称で紹介したのが、Addy Osmani氏です。彼はそこで次のように定義しました。
ループエンジニアリングの定義
ループエンジニアリングとは、エージェントにプロンプトを与える役割の“自分自身”を置き換えることである。代わりに、それを実行するシステムを設計する。
同時期に、OpenAIに在籍するPeter Steinberger氏は「エージェントに直接プロンプトを打つな。プロンプトを打つループを設計せよ」と発信。AnthropicでClaude Codeを率いるBoris Cherny氏も「もう直接プロンプトは打たない。ループを走らせていて、私の仕事はループを書くことだ」と語りました。
この数年で私たちが目にしてきた語彙の変遷を並べると、その進化のプロセスがよく分かります。
| 世代 | 概念 | アプローチの対象 |
| 第1世代 | プロンプトエンジニアリング | AIモデルに送る『言葉（指示文）』 |
| 第2世代 | コンテキストエンジニアリング | AIモデルに見せる『情報の組み立て』 |
| 第3世代 | ハーネスエンジニアリング | AIモデル周辺の『環境・制約・ツール』 |
| 第4世代 | ループエンジニアリング | 環境を『自動で回し続ける仕組み』 |
“うまい聞き方”というテクニック論から、“そもそも誰が・いつ・何をAIに投げ、その結果が許容範囲かを誰が決めるのか”という仕組みの設計に軸足が移っています。
もちろん、プロンプトエンジニアリングが不要になるわけではありません。個別の対話にプロンプトは必要であり、そのプロンプトを含む一連の実行構造を設計対象にするのがループエンジニアリングです。
自走するループを構成する『6つの部品』
自走するループを構成する要素として、Osmani氏は以下の6つを挙げています。一見ツールの話に聞こえますが、実は組織の業務設計そのものです。
（1）自動化トリガー
スケジュールやイベントでループを起動する『心臓』。ここが無いと結局手動運用に戻ります。
（2）並列隔離
複数のエージェントが同じ場所を同時に触って壊し合わないよう、作業空間を分ける仕組み。
（3）知識バンドル
『自社プロジェクトの命名規則』『レビュー観点』などの暗黙知を外部ファイル化し、毎回ゼロから再説明させない装備。
（4）外部連携
課題管理ツールやチャット、社内APIとの接続。ここが閉じていると自動化範囲がコード生成だけに縮んでしまいます。
（5）分業設計
生成する役と検証する役を、別のエージェントに分ける仕組み。
（6）状態保存
セッションを跨いで記憶を残す仕組み。
Osmani氏は次のように述べています。
トリガー（起票ルール）、隔離（担当分掌）、知識バンドル（業務マニュアル）、連携（システム間インターフェース）、分業（作成者と検査者の分離）、状態保存（引き継ぎ資料）。
これはまさに、優秀な組織が当たり前にやってきた業務設計そのものですね。今後のAI伴走支援のビジネスプロセスにおいても大変参考になる考え方です。
人はループのどこに関わるのか
ここまで見てきたように、ループエンジニアリングでは、AIエージェントが継続的に業務を実行できるよう、トリガーや知識、外部システムとの連携、分業、状態保存などを設計します。
しかし、実際の業務にこうしたループを組み込む際には、もう一つ重要な設計要素があります。
それは、人がそのループにどのように関与するのか、ということです。
AIが処理を行うたびに人が確認し、次の指示を出すのか。
それとも、一定の範囲はAIに自律的に任せ、人は全体を監督しながら、例外や異常が発生した場合に対応するのか。
ループエンジニアリングでは、AIを「どう動かすか」だけでなく、人をループのどこに置くかも重要な設計対象になります。
そこで重要になるのが、
HITLとHOTLの違いについて
ここが経営層・管理職の方に最も誤解されやすいポイントですので、整理しますね。
HITL（Human-in-the-Loop）
人がループの『内側』にいる状態。
AIが何かを出すたびに人が見て、判断して、次の指示を出す。多くの企業で行われている「ChatGPTに聞いて、結果を見て、また聞き直す」という使い方はこれにあたり、人が一手ごとにボトルネックになりやすいパターンです。
HOTL（Human-on-the-Loop）
人がループの『外側』に立つ状態。
エージェントは［計画→実行→検証→次の判断］を自律的に回し続け、人は完了条件の設計、異常時のエスカレーション対応、最終的なレビューを担います。
ループエンジニアリングが指し示しているのは、この
ただし、誤解のないようお伝えすると、HOTLは“人が関与しなくなること”ではありません。
検証やレビューは、これまで通り人の役割です。自分で作ったものを自分で採点させれば甘い点数がつくのは、人もAIも同じです。
生成役と検証役を分け、機械的に確認できる項目はテストや別エージェントに任せつつ、業務上の妥当性やリスク判断は人が担う必要があります。
なお、HITLとHOTLは排他的ではありません。
管理職の役割で言い換えるなら、『部下の作業を一つひとつ横で見る管理職』から、『業務プロセスと品質基準を設計し、例外だけを裁く管理職』へのシフトというイメージですね。
現場で実際に起きてていること
AI導入の伴走支援を続けてきて、繰り返し目にする現場のリアルが2つあります。
（1）「使い方研修」の翌月、利用率が落ちる
操作や機能説明、プロンプト講座を実施してアンケートの評価が高くても、3か月後には日常利用者が3割を切ってしまう企業があります。
ヒアリングで分かった原因は、AIの使い方ではなく“AIに投げるべき仕事を自分の業務から切り出せないこと”でした。目の前の仕事の
逆に成果が出た部署は、「毎週水曜の午後、この報告書作成に3時間かかっている」という具体的なユースケースを数字で言語化できていました。
ボトルネックさえ特定できれば、AIは驚くほど早く効果を発揮します。
（2）請求書で気づくトークン消費
ループ化・複数動作させたエージェント構成では、通常の一問一答型のチャット利用と比べてトークン消費量が桁違いに増えます。消費量はエージェント数、反復回数、モデル、参照コンテキストで大きく変動します。
2026年には、Uberが最初の4か月で年間のAI予算を使い切り、AIコーディングツールに従業員1人当たりの月額上限を設けたと報じられました。
そこで、少なくとも次の
- 反復回数の上限設定
- 予算の上限設定
- 一定回数進展がない場合の自動停止
- 異常発生時の強制停止
この4点セットを、経営としてガバナンスに組み込むことで抑制できますね。
まとめ
ループエンジニアリングの発祥はAIコーディングですが、本質は
カスタマーサポート、データ処理、監視・アラート対応、定期レポート生成など、あらゆる領域にも転用可能です。
大切なのは、以下を明確に設計することです。
- 何をきっかけに動くのか（トリガー）
- 何をもって完了とするのか（完了条件）
- 誰が、どの基準で検証するのか（品質管理）
- 異常時にどこで止めるのか（エスカレーションと停止条件）
- 次の実行に何を引き継ぐのか（状態保存）
AI活用の主戦場は、個人のスキルから業務プロセスの設計へと移り始めています。
人は目的や品質基準を決め、例外や異常に対応し、最終結果に責任を持つ。
これが、HITLからHOTLへの変化です。
AIに何を聞くかだけでなく、AIが働き続けられる業務の仕組みをどう作るか。
これからのAI活用では、この
ぜひ、皆さまの会社でも『ループエンジニアリング』について議論してみてください。
それでは、本日もGOOD JOB！！
▼こちらもおすすめ
