プロンプトではなくループを書く：安野貴博が解説する「ループエンジニアリング」

「ヒューマン・イン・ザ・ループ」から「ヒューマン・オン・ザ・ループ」へ

安野はまず「ループ」という言葉を説明する。AIとの作業では、AIが何かを作って出し、人間がそれを見て良し悪しを判断する。悪い部分には「ここはこうしてほしい」と指示を返し、AIが再び作業する。この繰り返しが、螺旋状に回るループになっている。

このループの中に人間がいて、レビューをしたり「これをやってください」と指示を出したりする状態を「ヒューマン・イン・ザ・ループ（HITL）」と呼ぶ。これに対して最近言われているのが「ヒューマン・オン・ザ・ループ」である。ループの中に人間がいるのは効率が悪いのではないか、ここまで賢くなったAIならループの中に人間はいなくてよいのではないか、という発想から出てきた考え方だ。人間はループの外から監督し、方向がずれていれば口を出すが、基本的な作業の中には入らない。

「イン」と「オン」の一語しか違わないが、安野はこの違いが非常に重要だと強調する。

AIとの関わり方の4段階

ヒューマン・イン・ザ・ループからヒューマン・オン・ザ・ループへの移行には段階があるとされる。安野はそれを、プロンプト、コンテキスト、ハーネス、ループの4段階として紹介する。

第1段階：プロンプトエンジニアリング。 AIへの頼み方を工夫する段階である。安野の例では、「あなたは経験豊かなソフトウェアエンジニアです。その立場から見て、下に貼ったコードにどんなバグがあると思うか答えてください」のように聞き方を設計する。これがいちばん手前の段階になる。

第2段階：コンテキストエンジニアリング。 一回ごとの頼み方ではなく、AIが判断するときに見る情報（コンテキスト）の全体を設計する段階である。たとえば仕様書、コーディング規約、関連ファイル、過去のやり取りを毎回きちんとAIに渡す。何をしてほしいかだけでなく、そのために必要な情報をAIに入れ込む。AIが一度に扱える情報量（コンテキストサイズ）には上限がある。安野によれば、現在のFableでは100万トークン、単行本10冊分ほどまでしか見えない。100万トークンはかなり多いが、それでも限られたコンテキストウィンドウにどんな文脈情報を入れるかを考えるのがコンテキストエンジニアリングだという。

第3段階：ハーネスエンジニアリング。 ハーネスとは、AIが安全に、検証を受けながら作業できるようにする足場のことだ。安野はプロンプトとの違いを次のように説明する。「作業の後に必ずテストするコードを書いてください」と頼むのはプロンプトの話である。一方、「テストが通らなければ先に進めない、検品を通らない」という仕組みはお願いではなく、AIが作業する環境側の話になる。AIは時々暴走してデータを消そうとすることもある。そのため、データは消せない、ネット上のこのサイトには接続できる、テストを通さないと次のフェーズに進めない、といった制約を環境として用意しておく。これがハーネスエンジニアリングである。

第4段階：ループエンジニアリング。 第3段階までは、人間が毎回指示を出している。指示の出し方を良くするのがプロンプトエンジニアリング、必要な情報を入れ込むのがコンテキストエンジニアリング、動き出したAIが安全に作業を進められる環境を作るのがハーネスエンジニアリングだった。ループエンジニアリングは、最初にプロンプトを打ってAIを動かし始めるところまでループに組み込む。AIへの指示出しも自動化し、人間は作業ループの外に出る。

ループはハーネスがあって初めて成り立つ

安野は注意点として、AIを自動で動き回らせれば勝手にうまくいくわけではないと述べる。ルールを守って安全に動けるハーネスを作っておかないと、ループで自由に動き回らせたときに危ないことになる。

ハーネスに含まれるものとして、安野はいくつかの例を挙げる。一つは、AGENTS.mdやCLAUDE.mdのように「このAIはこう動いてください」というルールを書いたファイル。次にテストである。ソースコードが正しく動いていることを確かめる別のソフトウェアを用意し、それがすべて通れば正常な挙動だと確認できる仕組みだ。さらに、コードの書き方が特定の規則に沿っているかを確かめるリンター、ログや履歴の管理、判断に迷ったときに人間へエスカレーションして指示を仰ぐ仕組みも含まれる。安野によれば、こうした足場がないままループを回すと暴走していくため、ループエンジニアリングにはハーネスエンジニアリングまでできていることが前提になる。

そのうえで安野は、2026年版の「AIを使いこなす」をこう定義する。プロンプトをうまく打つことだけではない。AIが仕事をするための情報をうまく入れ込み、AIが動き回れるハーネスをうまく組み、人間がいちいち「動け」と言わなくてもループが回り始めるようにする。そして人間はループの外に出て、ヒューマン・オン・ザ・ループの立場を取る。

第一線の開発者たちの宣言

安野によると、ループを設計しようという考え方は2026年の初め頃から徐々に現れ、かなり話題になった。安野はその中から二人を紹介する。

一人は、現在OpenAIにいるピーター・バーガー氏（字幕の表記による）である。安野によれば、同氏はXに、コーディングエージェントに直接プロンプトを打つのはやめよう、エージェントにプロンプトを打つループを設計すべきだと投稿した。

もう一人は、AnthropicでClaude Codeを作ったボリス・チェルニー氏だ。安野は余談として、チェルニー氏が日本で味噌を作っていた過去があることで知られ、Claude Mythos（英語の発音では「ミソス」）の登場時に「味噌を作っていたから味噌スを作った」というジョークが流行ったことにも触れている。安野の紹介では、チェルニー氏は、もう直接プロンプトはせず、ループを走らせてそれがClaudeに指示する、自分の仕事はループを書くことだ、と述べている。

安野は、二人とも手で一回ずつ指示する世界から指示する仕組みそのものを設計する方向へ考え方を変えており、人間がループの外に出て監督するヒューマン・オン・ザ・ループを語っている点で共通していると整理する。

アンドリュー・ンによる「速さの違う3つのループ」

では実際のループはどう回るのか。安野はここで、AI研究者として知られるアンドリュー・ン氏が、自分でゼロから製品を作る中で整理した見方を紹介する。ン氏は、ループをよく見ると回る速さの違う3種類のループが入れ子構造になっていると考えている。

1つ目は最も速く回るループで、エージェントがコードを書く部分である。 作りたいソフトウェアの仕様があり、必要ならテスト用データを渡す。するとエージェントは実装し、テストし、直すという作業を数分おきに繰り返していく。安野の紹介では、ン氏は週末に娘のためのタイピング練習アプリを自作した。そのときは、エージェントが作ったものをAIがWebブラウザで確認しながら、1時間ほど人間がまったく口を出さなくても作業を続けられたという。安野はこれを、AI研究の第一人者もこういうことをするのだという心温まるエピソードとして紹介している。

2つ目は、数十分から数時間おきに回る、もう少し遅いループである。 人間が入ってくるのはここだ。安野の説明では、1つ目のループはヒューマン・オン・ザ・ループであり、それを監督するのがこの2つ目のループになる。1時間ほどかけて出てきたものを人間が見て、ここは違うと方向性を修正していく。かつて人間はテストもソースコードもすべて自分で書いていた。AIが自分でテストしてくれるようになった分、人間は数十分から1時間単位で出来上がってくるものを見て、合っているか違っているか、もう少しこうしてほしいかを判断することに集中できるようになった、というのがン氏の見方だ。

3つ目は、外部フィードバックループと呼ばれる最も長いループである。 短ければ数時間、長ければ数週間かかる。一人の開発者が作ったものを他の人に見てもらう段階で、友人に使ってもらう、一部のユーザーに先行公開する、上司に見てもらう、本番でA/Bテストをしてどちらのパターンが良いか比べる、といったことが含まれる。そこで得たものが作り手のビジョンを更新し、それが仕様に落とし込まれて、再び最も速いループに戻っていく。

安野は講演中の図に沿って、AIが一気に作業する緑色のループ、そのAIを監督する個人が回す青色のループ、他の人とのやり取りから生まれる紫色のループと呼び分けている。時間軸の違うループが入れ子になった働き方を実際に私たちはしているのではないか、というのがン氏の整理である。安野はこれについて、今起きていることをうまく整理して話す人だと評価している。

なぜ人間はループに残る必要があるのか

安野がン氏の話でもう一つ面白かったと言うのは、なぜ人間がループの中に残らなければならないのかという点だ。

安野の紹介によると、ン氏は、それは人間の「センス」という貴重な資源があるからではないと言う。人間のセンスがなければ良いものにならない、ということではない。人間はユーザーのことや製品が使われる状況について、AIが知らないことを知っているにすぎない。人間はその情報量の差を埋めているだけであり、AIが知らないことを人間が知っている限りにおいて、その知識をシステムに入れる要素が必要になる。だからこの部分は自動化できない。これがン氏の仮説だと安野は説明する。

そのうえで安野は、ループを設計するとは、入れ子になった3つのループのどこにどんな人間を置き、AIをどう回すかという設計の話だとまとめる。すべてをAIに任せきるのでも、すべてを人間がやるのでもなく、その線引きをしっかり考えることがループエンジニアリングの中身だという。

ここまでの整理と「まだ黎明期」という留保

安野は話を二点に整理する。第一に、AIとの関わり方はプロンプトエンジニアリングからコンテキスト、ハーネス、ループへと進み、重心が外へ外へ、より大きな仕事をするためのエンジニアリングへと広がってきている。第二に、多くの人が「プロンプトではなくループを書け」と言い出しているが、よく見るとそれは速度の違う複数のループの設計の問題ではないか、ということだ。

ただし安野は、ループエンジニアリングはまだ黎明期だと留保をつける。さまざまな人が言い始め、やり始めてはいるものの、現場の第一線の人たちが模索している段階であり、今後もいろいろなアップデートがあるだろうという。それでも、この考え方を知っておくことはソフトウェアエンジニアにもそうでない人にも役に立つ、というのが安野の立場である。

非エンジニアの仕事への応用：秘書業務と会議

最後に安野は、ソフトウェア開発以外への応用例を挙げる。

一つ目は、秘書の仕事をAIに任せる場合だ。安野は、秘書業務にもテストに当たるものがあると言う。たとえば、夜7時頃までしか働かず7時以降は帰宅する人や、子育て中で5時以降は仕事ができない人がいるとする。その時間帯に予定調整を入れてしまったら、テストで弾かれるべきである。「この人の5時以降に予定を入れない」というルールで違反を検出するハーネスがあれば、AIが勝手に日程調整をしても、そのAIを信頼できるようになる。そのためには、誰がどの時間に働いているかを記録したデータベース（勤怠情報システムかもしれない）とやり取りしながらルール違反を見つける仕組みを作れるとよい、と安野は述べる。こうしたハーネスやループの発想は、秘書業務だけでなく弁護士や国会議員の仕事にも生きる場面があると安野は考えている。

二つ目は会議である。会議で文字起こしがされていれば、その中で「誰かがこれをやる必要がある」というタスクが生まれることがある。そこで、会議が終わるとAIが自動で立ち上がり、文字起こしから発生したタスクを洗い出す。安野によれば、これはある種のループの仕組みとして実現できる。たとえば「AさんとCさんが3日以内に話し合う必要がある」というタスクが見つかれば、カレンダー操作の仕組みを持つAIが二人のミーティングを調整し、それぞれにカレンダーの招待を送る。AさんとCさんは招待に「出席」をクリックするだけでよい。安野はこれを、人間がワークフローの中に関わっている状態として説明する。

安野は、これはソフトウェアエンジニアの話ではないが、すでにある技術をうまく組み合わせれば実現できるもので、一部の会社ではこのくらいのことはすでに実現されているだろうと述べる。そして、会社の中にAIが働ける環境をいかに作るかが非常に大事になってくる、という見方で話を締めくくっている。