最近、ハーネス・エンジニアリングの話を書いたばかりなのですが…（笑）次の「〇〇エンジニアリング」が来ていました。→ ループ・エンジニアリング（Loop Engineering）。AI界隈の言葉の消費速度、本当にすごい。ただ、調べてみたらこれが「流行り言葉がまた増えた」で済ませるにはもったいない、面白い概念だったので、今日はこの話です。
ループ・エンジニアリングとは
ひとことで言うと、AIエージェントに毎回指示するのをやめて、エージェントを繰り返し呼び出す「ループ」そのものを設計する、という考え方です。
これまでは、人がプロンプトを書いて、エージェントが動いて、結果を見て、また次のプロンプトを書く——という往復が基本でした。ループ・エンジニアリングでは、この往復ごと仕組みにしてしまいます。いつ起動するか、何を目標に回り続けるか、どうなったら止まるか。人間は個々の指示ではなく、ループの構造と検証に集中するわけです。
どこから出てきた言葉なのか
調べた範囲では、2026年に入ってからの流れのようです。元祖とされるのは、Geoffrey Huntley氏の「Ralphループ」と呼ばれる仕組み。中身は驚くほど素朴で、要するに while true でプロンプトファイルをエージェントに回し続けるだけ。ここから「手でプロンプトを打つ段階はもう越えた」という発言がClaude Codeを率いるBoris Cherny氏らから出て、今年6月にGoogleのAddy Osmani氏がブログで概念を整理し、名前が定着した——というのが大まかな経緯のようです（新しい言葉なので、諸説あります）。
進化の階段の、いちばん外側
この言葉の位置づけは、AIへの指示の進化の延長線上で捉えると分かりやすいです。プロンプト・エンジニアリングは「言い方」を工夫する。コンテキスト・エンジニアリングは「渡すもの」を設計する。ハーネス・エンジニアリングは「環境ごと」設計する。そしてループ・エンジニアリングは、「いつ・どの頻度で・誰が起動するか」まで含めて、自走する仕組みごと設計する。
Osmani氏は「エージェント＝モデル＋ハーネス」と定義したうえで、ループはその一階上の構造だと説明しています。指示の対象が、また一段外側に広がったわけです。私は講義でこの進化を3段のピラミッドで説明してきたのですが、どうやら4段目を書き足す時が来たようです。
ループの部品
ループを構成する部品として挙げられているのは、スケジュールやトリガーで起動する自動起動、並行作業の衝突を避けるワークツリー、プロジェクト固有の知識を外部化しておくスキル、外部ツールと繋ぐコネクタ、役割を分担するサブエージェント、そして状態・記憶の永続化です。
個人的に一番好きだったのは、記憶についてのこの言葉です。「記憶はコンテキストではなくディスクに置く。エージェントは忘れるが、リポジトリは忘れない」。私がプロジェクト開発でAIに引き継ぎメモを書かせているのも、まさにこれでした。名前が付く前から、みんな同じ工夫にたどり着いているんですね。
ただし、「検証はあなたの仕事」
では人間は要らなくなるのかというと、提唱者自身がはっきり否定しています。検証は依然として人間の仕事。理由が面白くて、「コードを書いたモデルは、自分の宿題を採点するには優しすぎる」から。だから、作るエージェントと検証するエージェントを分けて、検証側には別の目を持たせるのが定石になっています。
落とし穴も挙げられています。ループが速く作るほど「存在するコード」と「自分が理解したコード」の差が開いていく理解の負債。自動化が快適なあまり意見を持つのをやめてしまう思考の放棄。予算制御のないトークンコストの暴走。どれも、便利さの影の話です。
同じループでも、結果は正反対になる
一番刺さったのは、Osmani氏の締めの言葉でした。「2人がまったく同じループを作っても、結果は正反対になりうる。一方は深く理解している仕事を速く進めるために使い、もう一方は仕事を理解すること自体を避けるために使う。ループはその違いを知らない。あなたは知っている」。
結局、ここでも手段と目的の話に戻ってくるんですよね。ループは手段で、何のために回すかは人間の側にある。「楽になる」で止まるか、「なぜ楽になったのか」まで考えて楽しくなるか。言葉は次々に増えていきますが、分解してみれば、ピラミッドに新しい階がひとつ増えただけ。問われていることは、昔から変わっていないのだと思います。
参考: Loop Engineeringとは（Qiita） / ループエンジニアリングとは（CodeRabbit Blog）
