プロンプトを打つのを、やめてみた。AIエージェントを“回す”ループエンジニアリングを、現場から翻訳する
「AIをどう使うか」と聞かれると、少し前まではプロンプトの話をしていた。
どう質問すれば、いい答えが返ってくるか。けれど最近、その前提そのものが古くなりつつある。
数億トラフィックのシステムを設計し、この2年はLLMを業務に組み込んできた立場から、
いま静かに広がっている「ループエンジニアリング」を、明日提案できる言葉に翻訳してみたい。
「AIを使う」の景色が、いつのまにか変わっていた
このところ、note でも「AIが“同僚”として出社する」「AIエージェントを経営にどう組み込むか」といった言葉をよく見かけるようになった。世の中の関心は、はっきりと上がっている。
ただ、多くの人が思い浮かべる「AIの使い方」は、いまもだいたいこの形だ。
人が画面に向かって、プロンプトを打つ
AIが答えを返す
その答えを見て、人が次の指示を考える
また打つ
悪くはない。むしろ、ここまで来られただけでも大きい。けれど、この形には一つの天井がある。ループを回しているのが、ずっと人間なのだ。AIがどれだけ賢くなっても、起動して、受け取って、次を考えるのは人。人が席を立てば、AIも止まる。
ここから先に進む鍵は、たぶん「もっと上手なプロンプト」ではない。そのループを、人の手から仕組みの側へ渡せるか——そこに移りつつある。
自分が現場でやってきたこと
抽象的に語ると、どうしても空々しくなる。だから、自分が実際に手を動かしてきたことを先に書いておきたい。
2022年の11月、ChatGPTが世に出た直後のことだ。当時は「APIを使わないと入力内容が学習に使われてしまう」という懸念から、社内利用に二の足を踏む会社が多かった。私はそこで、社内稟議を通してAPIキー経由のChatGPT環境を構築し、全社で安全に使える形に整えた。技術そのものよりも先に、社内の合意と運用ルールを設計した、という話だ。
そこから先は、もう“チャット”ではなくなっていった。
LLMを使った総合業務支援ツールを、Webとデスクトップ（Electron）の両方で設計・開発した
RAGを応用した自然言語の社内検索を、技術調査から社内提案、要件定義、開発まで一貫して担当した。社内に蓄積された大量のデータをベクトル化し、普段の言葉で探せる仕組みだ
AIエージェントやMCPの開発にも踏み込んだ。AIが単発で答えるのではなく、ツールを呼び、手順を踏んで業務を進める仕組みである
いま振り返ると、これらは少しずつ同じ方向を向いていた。「人がAIに聞く」から、「仕組みがAIを動かす」へ。当時はまだ言葉がなかったけれど、やっていたのはたぶん、この記事で書く話の助走だった。
ループエンジニアリングとは何か
最近、似たような言葉をいくつも見かけるようになった。Flow Engineering、Agentic Workflow、AIハーネス。呼び方は乱立しているが、私がいま一番しっくり来ているのは「ループエンジニアリング（Loop Engineering）」だ。Googleのエンジニア Addy Osmani が2026年6月に名前を与えたことで、一気に広まった。
あえてひと言に翻訳すると、こうなる。
エージェントに毎回プロンプトを打つのをやめて、エージェントを繰り返し呼び出す「ループ」そのものを設計する側に回ること。
ループの中身は、驚くほどシンプルだ。
実行する（act） — タスクをやってみる
結果を観察する（observe） — うまくいったか、自分で確かめる
次を判断する（decide） — 直すのか、次へ進むのか決める
繰り返す（repeat） — ゴール条件を満たすまで、自分で回し続ける
これまでのプロンプトエンジニアリングは、人間が上手な質問を一度投げて、良い答えを一度もらう世界だった。ループエンジニアリングは、その「もらった後」を人ではなく仕組みに引き受けさせる。目的を一度だけ定義すれば、あとはゴールにたどり着くまで自走する——そういう設計だ。
難しく考える必要はないと思う。優秀な新人に、毎回ひとつずつ指示を出すのをやめて、「この状態になるまで自分で回して、詰まったら呼んで」と任せる。ループエンジニアリングのイメージは、たぶんそれにいちばん近い。
ある一日の流れ ── 人は決める、AIは回す
いちばん有名な実例は、OpenAIのCodexチームなどが日常的に回している「毎朝のトリアージ＆PR自動化」だ。これを、人とAIの一日の動きとして並べてみると、分業の形がはっきりする。
日中、人間がやるのは「決めること」だ。 会議や打ち合わせの中で、今日やるべき要望・バグ報告・優先順位を固め、課題（Issue）として登録しておく。ここまでが人の仕事。あとは退社してかまわない。
夜のあいだ、AIがループを回す。 スケジュールで自動起動し、登録された課題と現状（テストの失敗やコミット）を読む。直すべきことを台帳（State file）に整理し、課題ごとに隔離された作業場で「書くエージェント」が修正を当て、「確認するエージェント」がテストや基準に照らしてレビューする。書いた本人は自分の仕事に甘いから、採点役を別に立てる——これが品質の肝になる。仕上がったらコネクター経由でPRを作る。
翌朝、人間は「判断」に戻る。 できあがったPRをレビューして、良ければマージ。気になれば差し戻す。そしてまた日中、次の課題を登録する。
この絵で大事なのは、人間が消えないことだ。人は「何をやるか」を決め、「できたものを通すか」を判断する。その間の「回す」だけを、仕組みに渡している。夜のあいだ働いてくれる優秀なチームに、朝、成果をレビューしに行く——そういう働き方に近い。
ループを支える、6つの部品
ループは「回す」と言うだけなら簡単だが、実際に自走させるにはいくつかの部品が要る。提唱されている構成要素は、おおむね次の6つだ。これを業務の言葉に翻訳しておく。
自動実行（Automations） … イベントや時刻をきっかけに、ループを人の手を借りずに起動する
ワークツリー（Worktrees） … 失敗しても本番を壊さない、隔離された作業場を用意する
スキル（Skills） … 繰り返す手順を、使い回せる「型」として持たせる
コネクター（Plugins / Connectors） … 社内ツールや外部サービスに手を伸ばせるようにする
サブエージェント（Sub-agents） … 役割を分け、調べる係・書く係・確認する係に分担させる
メモリ（Memory） … 一周ごとの文脈や学びを、次の周回へ持ち越す
並べてみて気づくのは、これが特別な未来の話ではない、ということだ。隔離された作業場、再利用できる手順、役割分担、記憶の引き継ぎ——どれも、人間のチームが当たり前にやってきたことを、AIエージェントに持たせ直しているだけなのである。
チャットの往復から、卒業する
「プロンプトを打つ」働き方と「ループを回す」働き方を、業務の目線で並べてみると、輪郭がはっきりしてくる。
注目したいのは、いちばん下の行だ。ループを仕組み側に渡すと、人間の仕事は「自分で全部回す」から「AIが回した結果をレビューし、判断する」へと移っていく。
これは脅威というより、立ち位置の話だと考えている。先にこのループを設計できる人は、社内で「AIを分かっている人」になる。逆に出遅れると、「AIに仕事を奪われる側」として語られることになる。同じ技術をめぐって、上に立つのか下に置かれるのか。その分岐点が、いま来ている気がする。
ちなみにこの文章も、私はスマホからAIに指示を出しながら構成を整えている。「人がパソコンの前に座って起動する」という前提すら、すでに少し揺らいでいる。
明日、社内で提案できる形に落とす
「では、何を提案すればいいのか」にも触れておきたい。いきなり全自動の基盤をつくる必要はない。人が回しているループを一つ選び、それを仕組み側に半歩だけ渡す。そこから始めれば十分だと思う。
ひとつ目に、人が毎回回している定型業務を一つ選ぶ。
「AIに聞いて、結果を見て、また指示して」を人間が繰り返している業務を探す。問い合わせの一次対応、レポートの定時生成、記事のリライト。どれでもかまわない。
ふたつ目に、ゴール条件をひとつ決める。
「この状態になったら完了」を言葉にする。これが、ループを止める基準になる。ここが曖昧だと、いつまでも回り続けてしまう。
みっつ目に、一周だけ自動で回してみる。
イベントが起きたらAIが実行・観察・判断し、結果を人間がレビューする。まず一業務だけ。小さく作って、レビューは人が握っておく。ここがリスク管理の要になる。
よっつ目に、レビュー結果をメモリに残して、精度を上げる。
回して、直して、また回す。ループエンジニアリングそのものを、導入のプロセスにも当てはめていく、ということだ。
この順番で提案すると、経営層にも届きやすい。「全部AIに任せる」ではなく、「人がゴール判定とレビューを握ったまま、回す作業だけを仕組みに渡す」。投資判断として通しやすいのは、後者のほうだ。私が社内のChatGPT環境を通したときも、技術の派手さではなく、安全に・小さく・運用できる形に落として合意を取った。
おわりに
AIの使い方は、「上手なプロンプトを打つ」で止めた瞬間に、ループを回す担当が人間のまま固定されてしまう。
次に来るのはループエンジニアリング——act → observe → decide → repeat を仕組みに回させ、人はゴール判定とレビューに集中する世界だと考えている。そして、それを「明日提案できる形」に翻訳できる人が、これからの現場では強い。
私はこれからも、実際に組んできた経験をもとに、こうした「上流の翻訳」を書いていくつもりだ。よければ、また読みに来てもらえると嬉しい。
