2026年6月、開発者のあいだで「ループエンジニアリング（Loop Engineering）」という言葉が急に広まりました。
きっかけは、元GoogleでChromeやAI領域の開発者体験を率いていたAddy Osmani氏が6月7日に公開した一本のエッセイです。同じ週に、AnthropicでClaude Codeを率いるBoris Cherny氏が「私の仕事はループを書くこと」と発信し、OpenAIに在籍するPeter Steinberger氏も「エージェントにプロンプトを出すループを設計せよ」と述べました。言葉が同時多発的に重なって、一気に定着したようです。
この記事では、それがどういうものなのか、どんな効果があるのか、そしてどう始めればいいのかを、順番に見ていきたいと思います。
1. どういうものか
ひとことで言うと
Osmani氏の定義が、とても短くて的確でした。
ループエンジニアリングとは、エージェントにプロンプトを与える役割の自分自身を置き換えることである。代わりに、それを実行するシステムを設計する。
これまで私たちは、AIに何かをしてもらうとき、自分で指示を打ち、返ってきたものを見て、また次の指示を打っていました。その「指示を打つ人」の部分を、仕組みに置き換えてしまおう、という考え方です。
職場のたとえで言うなら、毎回口頭で指示を出していた人が、業務の流れそのものを設計する側に回る、という感じでしょうか。誰がいつ動きはじめて、何を参照して、誰が確認して、どうなったら終わりにするか。そこを決めるのが仕事になります。
ループの中では何が起きているのか
「ループ」と言うと難しそうですが、中身は意外と素朴です。ある研究論文は、Claude Codeの中核を「モデルを呼び、ツールを実行し、それを繰り返すだけの単純なループ」と表現しました。
実際の動きは、おおむねこの4つの繰り返しです。
- 動く — AIが次にやることを決めて実行する
- 見る — その結果を受け取る
- 判断する — 続けるか、終えるかを決める
- 検証する — 出来上がったものが要求を満たしているか確かめる
このうち4つ目の「検証」が、あとで出てくる大事なポイントになります。
自動化スクリプトとは何が違うのか
決まった手順を自動で流すだけなら、これまでの自動化と変わりません。違いは、次に何をするかをAI自身が決めている点にあります。
テストが落ちたら原因を調べて直す。直したらもう一度試す。まだ駄目なら別の方法を考える。手順書に書かれていない分岐を、その場で判断しながら進んでいきます。だからこそ、どこで止めるかを人が決めておく必要が出てくるわけです。
2. どんな効果があるのか
手が離れている時間が長くなる
いちばん分かりやすい効果はここです。
Andrew Ng氏は、娘さんのためにタイピング練習アプリをつくったときの話を書いています。コーディングエージェントは、ブラウザを使って自分がつくったものを何度も確認しながら、約1時間、手を借りずに働き続けたそうです。
Ng氏はこうも述べています。「ループを閉じるというこの考え方は昨年末ごろから広がり、エージェントが人の介入なしに長く生産的に働けるようにする決定打になった」。
これまでは、AIが止まるたびに人が様子を見て、次を指示していました。その待ち時間がなくなると、こちらは別の仕事をしていられます。
人の仕事が一段上に移る
これは効果として、いちばん大きいかもしれません。
Ng氏によれば、以前の開発者はAIの品質管理係のような役回りで、時間の多くを「バグを見つけてAIに直させること」に使っていました。AIが自分でテストするようになったことで、その時間が空きます。
空いた時間が向かう先は、どんな機能をつくるか、どんな画面にするか、利用者にどう使ってもらうか、といった判断です。細かい確認作業から、決めごとのほうへ重心が移っていきます。
品質のばらつきが減る
人が都度指示を出していると、指示の内容はどうしても揺れます。今日は細かく伝えたけれど、忙しい日は雑になる、というように。
ループの場合は、参照する資料も、確認する項目も、合格の基準も、あらかじめ仕組みの中に書き込まれています。同じ基準が毎回同じように適用されるので、出来上がるものが安定します。
効果の裏返しも、正直に
ただ、良いことばかりではありません。Osmani氏自身が「ループは生産性とミスの両方を増幅する」と明記しています。
無人で走るループは、無人でミスを重ねるループでもあるということです。速く進むぶん、間違った方向にも速く進んでしまう。この裏返しがあるからこそ、次の「方法」の話が重要になってきます。
3. どうやって始めるか
ループを構成する6つの部品
Osmani氏のエッセイでは、自走するループに必要な部品として6つが挙げられています。
| 部品 | 役割 |
|---|---|
| 自動化トリガー | 決まったタイミングや出来事でループを起動する |
| 並列隔離 | 複数のAIが同じファイルを取り合わないよう作業場を分ける |
| 知識バンドル | プロジェクト固有の手順や決まりごとを渡しておく |
| 外部連携 | 既存の業務ツールやデータにつなぐ |
| 分業設計 | 「つくる役」と「確認する役」を分ける |
| 状態保存 | セッションを越えて経緯や結論を残す |
どれか1つ欠けても、どこかで詰まってしまうそうです。トリガーがなければ、結局は誰かが手で起動することになり、出発点に戻ってしまいます。状態保存がなければ、先週片づけた作業を毎回ゼロからやり直すことになります。
要になるのは「確認する役を分ける」こと
6つの中で、品質を最も左右するのが分業設計だと言われています。
Osmani氏の表現が的を射ていて、**「コードを書いたモデルは、自分の宿題を採点するときに優しすぎる」**というものでした。自分でつくって自分で合格を出すループは、構造的に甘くなります。
そこで、つくる役と確認する役を別々のエージェントに分けます。確認役には別の指示と別の権限を与えて、独立した目で見てもらう。ここを省くと、ループは回っているのに品質が上がらない、という状態になりがちです。
止め方を先に決めておく
始め方と同じくらい、終わり方が大事になります。実務でまず用意したいものが4つ挙げられています。
- 反復回数の上限 — 何回までと区切る
- 予算の上限 — 金額で天井を決める
- 無進展の検出 — しばらく変化がなければ止める
- 異常時の強制終了 — 失敗が続いたら打ち切る
ありがたいことに、これらはコードで明示できます。Claude CodeのSDKには回数や金額の上限を設定する仕組みがあり、「気づいたら走り続けていた」という事故を構造的に防げます。実際、予算を想定より早く使い切ってしまった企業の例も報じられているので、ここは最初に押さえておきたいところです。
一度に無人化しない
いきなり全部を任せるのではなく、段階を踏むやり方が勧められています。
- 第1段階 — AIには調べて報告してもらうだけ。実行はしない
- 第2段階 — 確認役つきで、修正まで任せる
- 第3段階 — 人が見ていない状態での実行を許す
各段階でしばらく運用してみて、想定通りに動くと確認できてから次に進む。遠回りに見えますが、結果的にはこれがいちばん早いと思います。
どの仕事から始めるか
向いている業務を見分ける目安として、3つの観点が挙げられています。
- 繰り返しがあるか — 一度きりの作業を仕組みにしても報われません
- 成果を検証できるか — 合否を判定できないものは、確認役を置けません
- 経済的な価値があるか — かかる費用に見合うか
この3つが揃う仕事から手をつけるのが定石です。逆に、判断基準が曖昧で、正解が人によって変わるような仕事は、ループには向きません。
まとめ
ループエンジニアリングは、「AIに指示を出す人」から「AIが動く仕組みをつくる人」へ、重心が移ったという話です。
効果としては、手が離れる時間が長くなり、人の仕事が細かい確認から判断のほうへ移り、品質のばらつきが減ります。始めるときは、確認役を分けること、止め方を先に決めること、そして段階を踏むこと。この3つを外さなければ、大きな事故にはなりにくいはずです。
言葉自体はまだ生まれたばかりで、技術メディアのADTmagも「若い用語であり、正式な分野というより開発者の略語で終わる可能性もある」と慎重に書き添えています。名前が定着するかどうかは分かりません。
ただ、指しているものは案外シンプルです。速く進むための仕組みと、間違いに早く気づいて止める仕組み。その両方を一緒に設計する、というだけの話なのだと思います。
