AIに指示を出し、返ってきた結果を確認して、また次の指示を出す。多くの現場のAI活用は、いまもこの「一往復」の繰り返しです。ところがこの一年ほどで、海外の開発者たちからまったく違う働き方が報告されるようになりました。人がプロンプト（AIへの指示文）を打つのではなく、指示を受けると自分で手順を考えて作業を進めるAI――「AIエージェント」と呼ばれます――に指示を送り続ける「ループ（繰り返しの流れ）」を仕組みとして用意し、人はその外側で入口と検証だけを見る。海外で「ループエンジニアリング」と名づけられたこの考え方は、AIの生産性の物差しを「どれだけ上手に指示するか」から「どれだけ良い流れを設計できるか」へ移しつつあります。
本記事では、この潮流の背景にある事実関係を整理したうえで、ループを安全に業務へ組み込むための設計手順――合格ラインの決め方、結果の確かめ方、止めどき、費用の上限、動かし方の選び方――を、当社が実務で使っている判断基準を交えて解説します。読み終えたときに、自社の業務のどれをループ化できて、何を先に決めるべきかが判断できる状態を目指します。
AIをたくさん使う人には、上手い人と下手な人がいる
AIの使用量の多さは活用度の指標として注目されがちですが、量が多いことと上手に使えていることは別の話です。
前提を一つだけ。AIの使用量は「トークン」という単位で数えられます。使った分だけ料金がかかる、いわばガス代のようなものだと考えてください。海外では、数人のチームが約100体のAIエージェントを常時稼働させ、ひと月に日本円で約2億円分のトークンを消費したという事例が報道され、話題になりました（報道値にもとづく概算であり、費用は本人の自己負担ではなく支援として負担されたと報じられています。また料金プランの選び方次第でコストは桁で変わるという指摘もあります）。注目すべきは金額そのものではなく、その内訳です。人がチャット画面に張り付いて出せる作業量ではまったく届かない数字であり、プログラム修正案の確認、不具合の発見と修正、課題の整理といった仕事が、人の操作を待たずに流れ続ける「生産ラインのような仕組み（パイプライン）」の数字だった、という点です。
一方で、使用量の多さがそのまま成果につながるわけではないことも、研究から分かってきました。AIエージェントにプログラム作成の作業を任せた場合のトークン消費を分析した研究によれば、同じタスクでも実行ごとの消費量は最大で30倍もぶれます。しかも高コストな実行ほど精度が高いわけではなく、精度は中間的なコスト帯でピークを迎えます。高コストな実行の中身を見ると、同じファイルを何度も開き直し、同じ箇所を編集し直す挙動が増えている。つまり「深く考えている」のではなく「迷って同じ場所を行き来している」だけのことが少なくないのです。トークン消費量そのものを生産性の証として誇る風潮は、それ自体を目的にした途端に無駄遣いへ転びます。
では、大量のトークンを上手に使っている人は何が違うのでしょうか。報告されている共通点は、指示の上手さではなく設計の習慣です。自分の仕事の進め方を、AIに渡せる粒度まで言語化している。成功の条件・止まる条件・確かめ方を先に決めてから、AIが動く流れを作っている。そして失敗したときに、その場のプロンプトを言い換えるのではなく、流れ（ループ）そのものを直している。こうして一度仕組みになった仕事は、本人の労働時間に比例しない進捗を、夜間や週末にも生み続けます。
トークン消費の多さは、良い仕組みの「結果」であって「目的」ではない。量を誇るのではなく、消費が成果に変わる流れを設計できているかを問う。
「指示を打つ人」を仕組みに置き換える ― ループという考え方
ここでいうループの設計とは、AIに毎回プロンプトを打つ自分自身を、それを代わりに行う仕組みで置き換える技術のことです。
この考え方を「ループエンジニアリング」という言葉で定式化したのは、Google Chrome チームの Addy Osmani 氏です。氏は「ループエンジニアリングとは、エージェントにプロンプトを打つ『あなた自身』を置き換えること。代わりにそれを行うシステムを設計することだ」と定義しました。同じ時期に、Claude Code（AIにプログラム開発を任せられる代表的なツール）の作者である Boris Cherny 氏も「もう Claude にプロンプトを送っていない。私が持っているのはループだ。プロンプトを送って次に何をするか考えるのは、そのループの方。私の仕事はループを書くことだ」と語っています。別々の場所にいる実務家が、ほぼ同時に同じ結論へ辿り着いたことが、この考え方の説得力を裏づけています。
この転換は、突然現れたものではありません。AIの使いこなしの重心は、段階を踏んで人からシステムへ移ってきました。
| 世代 | 呼び名 | 人間の仕事 | 価値の源泉 |
|---|---|---|---|
| 第1世代 | プロンプトエンジニアリング | 一つの指示を磨く | 指示の質 |
| 第2世代 | コンテキストエンジニアリング | 十分な情報・前提・例を与える | 文脈の質 |
| 第3世代 | ハーネスエンジニアリング | 実行環境と安全柵を整える | 実行環境の質 |
| 第4世代 | ループエンジニアリング | 自律稼働の流れを設計する | サイクルそのもの |
大切なのは、前の世代が消えるわけではないという点です。良い指示も、十分な文脈も、安全な実行環境も、すべてループの部品として内包されます。第3世代の「ハーネス」が「1台の機械を安全に動かすためのレールと柵」だとすれば、ループは「工場全体を自動でスケジューリングする制御盤」にあたります。
人間の立ち位置も変わります。従来のAI活用は、各アクションの前に人が確認・承認する Human-in-the-loop（ループの中の人間）が基本でした。ループの設計では、人はループの外側に立ち、入口の設計・要所の監視・異常時の介入を担う Human-on-the-loop（ループの上の人間）へ移ります。ただし後述するとおり、検証の責任と最終確認まで仕組みに預けてよいわけではありません。この線引きを誤ると、自律化は事故の高速化になります。
ループの設計は、プロンプトの工夫より「簡単」ではない。一つの答えを作ることと、答えを出し続ける機械を作ることは、別の技能である。
ループを構成する6つの部品
自律ループは魔法の一枚岩ではなく、役割の異なる部品の組み合わせでできています。
Osmani 氏の整理によれば、実用に耐えるループは次の6つの部品で構成されます。
| 部品 | 役割 |
|---|---|
| 自動起動（Automations） | 定期・出来事をきっかけにタスクを発見し、人手なしで作業を投入し続ける「心拍」 |
| 作業分離（Worktrees） | 並行するAI同士の衝突を、作業領域の分離で防ぐ「防護壁」 |
| スキル（Skills） | 仕様・手順・過去の決定を恒久ファイルに刻み、毎回の再説明を不要にする「記憶チップ」 |
| 外部接続（Connectors） | タスク管理表・文書やプログラムの保管場所・チャットなど、現実の業務システムへつなぐ「腕」 |
| 副エージェント（Sub-agents） | 作る役と確かめる役を分け、自己採点を防ぐ「牽制機構」 |
| 記憶（Memory） | 進捗や状態を会話の外のファイルに残し続ける「外部記憶」 |
業務の場面に置き換えてみます。たとえば「問い合わせメールの一次分類」をループ化するなら――毎朝9時に未対応の問い合わせを拾い上げて作業を始めるのが自動起動。分類のルールや過去の判断例をまとめたファイルがスキル。問い合わせ管理表を読み書きするつなぎ込みが外部接続。複数のAIを走らせるとき、同じ管理表を同時に触って上書きし合わないよう担当範囲を分けるのが作業分離。分類の結果を別のAIが抜き打ちで検品するのが副エージェント。「どこまで処理したか」を記録し続けるのが記憶です。
この中で、とくに見落とされやすいのが最後の二つです。
まず副エージェント。一体のAIに「自分で作り、自分で合格と判定させる」構成にすると、評価は構造的に甘くなります。作る役（maker）と確かめる役（checker）を分け、さらに確かめる役には別のモデル――AIの銘柄・グレードのことです――と別の指示を与える。同じモデル同士は同じ盲点を共有しやすいため、系統を変えることが牽制として効きます。
次に記憶です。AIの記憶は会話が終われば消えますが、共有の保管場所（リポジトリ）に置かれたファイルは消えません。「モデルは忘れる、リポジトリは忘れない」という言い回しのとおり、進捗ファイルや作業記録といった外部の記録を持たないループは、翌日また最初からやり直すことになります。記録を外に置くことは、後述する「途中で止まっても再開できる」設計の土台でもあります。
合格ラインの決め方と確かめ方 ― 「動きました」を信じない
ループ設計の最初の作業は、道具を選ぶことではなく、目標を「判定できる合格ライン」に変換することです。
当社ではこれを、AIに渡す合格ラインの約束という意味で「目標契約」と呼んでいます。中身は四つで、達成したい状態、対象と対象外の範囲、守るべき制約、そして数字に落とした受け入れ基準です。たとえば開発なら「テスト（プログラムの自動点検）が全件通る」「対象フォルダ以外は変更しない」、経費データの点検を任せるなら「金額の合計が元の伝票と一致する」「未処理が0件になる」のように、数字か真偽で判定できる形に落とします。ここで有効な判定基準が一つあります。この目標を別のAIに渡して、追加の説明なしに達成可否を判定させられるか。判定に主観や補足が必要なら、目標がまだ曖昧だという合図です。そして数字に落ちない目標は、そもそもループで扱わない。無理にループ化せず、人が対話しながら進める仕事として残すのが正しい判断です。
目標が決まったら、次は確かめ方の設計です。原則は一つで、AIの「できました」「動きました」という自己申告を信じないこと。代わりに、テストの結果、実行の記録（ログ）、変更のたびに自動でテストや点検を走らせる仕組み（CIと呼ばれます）の合否といった、誰がいつ実行しても同じ結果になる機械的なチェックを証拠として提出させ、その証拠で判定します。さらに、判定を下す役を作業する役から切り離します。近年のエージェント基盤には、完了判定を作業中のモデルではなく別の新鮮なモデルに委ねる仕組みや、変更を提案する役と評価する役を分ける構成が組み込まれ始めており、これは「やったつもりで止まる」「嘘の完了を返す」というAIエージェントの持病を、役割分担という構造で潰す発明だと言えます。
この一巡を図にすると、次のようになります。合格ラインの約束から始まり、実行、証拠の提出、そして作業役とは別の判定役による判定を経て、合格なら人の最終確認へ、未達なら理由つきで次の一巡へ、判断が必要な異常なら人への引き継ぎ（エスカレーション）へ分岐します。
検証は一回で終わりではありません。繰り返しのたびに軽いチェックを回し、終了の前には全項目のチェックを通す、という二段構えにすると、コストと確実性のバランスが取れます。
確かめる仕組みが信頼性を作り、信頼性が「任せられる量」を増やす。検証できないものをループに載せれば、高速にミスを再生産する装置ができあがる。
「いつ止めるか」と「いくらまで使うか」 ― ループは止め方から設計する
自律ループの安全性は、どう動かすかではなく、どう止まるかで決まります。
まず押さえたいのは、目標と「止まる条件」は別物だということです。目標は「何が成功か」を定め、止まる条件は「いつ試行をやめるか」を定めます。目標達成のチェックだけを止まる理由にすると、達成できないタスクに当たったループは永遠に回り続けます。だから止まる条件は、必ず複数を重ねて設計します。具体的には次の6層です。
- 目標達成チェック（外部の検証で達成を確認したら終わる）
- 繰り返し回数の上限（決めた回数を超えたら止まる）
- 実時間のタイムアウト（決めた時間を超えたら止まる）
- 回復不能なエラーの検知（作業環境の破壊や権限のエラーで止まる）
- 同一動作の繰り返し検知（同じ操作を同じ内容で繰り返し始めたら止まる）
- 人間への引き継ぎ（判断が必要な事態は人に渡して止まる）
当社の実務では、このうち①目標達成チェック・②繰り返し回数の上限・⑥人への引き継ぎの3層を必須とし、これを欠く設計はレビューを通しません。加えて夜間や週末など無人で回すループでは、③実時間タイムアウトを必須に格上げしています。無人の時間帯は、手がかりを見失って迷走するループを誰も見ていないため、「朝まで空回りして終わっていた」という損失を時間の壁で確実に断ち切る必要があるからです。
もう一つの柱が、AIに使わせる費用の上限――トークン予算です。前述のとおり、同じタスクでも消費は最大30倍ぶれます。さらに厄介なことに、AI自身は自分のトークン消費を正確に予測できず、決まって少なめに見積もることが分かっています。つまり「見積もらせて管理する」方式は成立しません。結論として、超過したら強制停止する上限を仕組みとして実装する以外に、確実なコスト管理の方法はないのです。
予算を有効に使う配分にも定石があります。第一に、並行して走らせるAIエージェントは3〜5体までに抑えること。トークンのコストは体数に比例して増える一方、人が確認を追える範囲はそれほど広がらないため、「散漫な5体より集中した3体」が原則です。第二に、場面ごとにAIのグレード（モデル）を使い分けること。設計や実行計画づくりは1回しか走らないので最上位のモデルに任せ、ループ内で何十回も繰り返される実行はタスクに足りる最小のモデルで回し、完了判定は作業役と別のモデルに任せる。設計は1回、実行は何十回と繰り返されるため、設計への投資が全体のコストと成功率を最も効率よく改善します。
見積もりに頼らない。超えたら止まる仕組みを先に置き、その内側で自由に走らせる。
小さく始める ― 動かし方の選び方と最初の一歩
ループ導入のコツは、いきなり大きな仕事を無人化しないことです。動かし方にも仕事の選び方にも、段階があります。
動かし方は、シンプルな順に並べると次のようになります。
| 動かし方 | 向いている場面 |
|---|---|
| 人がその都度動かす | 試作段階・低頻度。まずはここから始める |
| 繰り返し型（完了の定義を満たすまで同じ指示を繰り返させる） | 決めた合格ラインまで自動で粘らせたい |
| 判定役つき（完了かどうかを作業役と別のAIに判定させる） | 「できたつもり」の見逃しを防ぎたい |
| 予約実行（毎朝9時など決まった時刻に自動で始める） | 定型レポートの下書きなど、日次・週次の決まった仕事 |
| 出来事起動（何かが起きたのを合図に自動で動く） | 問い合わせが届いたら仕分ける、プログラムの変更案が出たら点検する等 |
| 司令塔型（複数のAIの分担・順番を管理する基盤に載せる） | 多段の依存関係・複数のAIの編成が必要になったとき |
原則は「最もシンプルな動かし方から始め、必要になったときだけ複雑にする」です。これはAIエージェント設計の古典的な原則でもあります。なお、各ツールの機能名や仕様は時点やバージョンで変わるため、採用時には公式ドキュメントの確認をおすすめします。
最初にループ化する仕事は、小さく・明確で・成否を数字で判定できるものを選びます。開発以外の業務なら、決まった形式の週次レポートの下書き作成、問い合わせメールの一次分類（どの担当に回すかの仕分け）、売上データの入力ミスや抜けの点検。開発の現場なら、自動点検で見つかった不具合の修正、修正のせいで別の場所が壊れていないかの確認、決まった観点での作業記録の巡回点検が定番です。逆に、合格ラインを決めていない大規模な改修や、複数のシステムをまたいで強い権限を行使する処理、好みの問題で合否が決まる仕事は、ループに載せてはいけません。優先順位は「検証できること、自動化できること、広げられること」の順です。あわせて、ループごとに責任者を1人置き、結果とコストの両方をその人が背負う体制にしておくと、コストが誰のものでもなくなる事態を防げます。
運用面では、二つの作法が長期の安定性を分けます。一つ目は、進捗をファイルに書き残しておくことです。進捗ファイルや追記専用の作業記録をAIの会話の外に置き、一定の単位ごとに途中経過を書き出しておく。こうすると途中で失敗しても最初からやり直しにならず、続きから再開できます。二つ目は経験の還元です。AIが間違えたとき、その場の会話で言い直して済ませると、次の機会に同じ間違いが再発します。そうではなく、恒久的なルールファイルに書き足す。成功したパターンは手順書やテンプレートに昇格させ、失敗は禁止ルールやチェック項目に変える。この積み重ねを続けたループとそうでないループは、数ヶ月単位で安定性に大きな差がつきます。
直すのはプロンプトではなく流れ。会話で言い直したことは消えるが、ルールに書いたことは積み上がる。
ループの3つの罠 ― 自律の先でも、責任は人に残る
ループがスムーズに回り始めたときこそ、注意すべき罠があります。厄介なことに、どの罠もうまく回っているように見えるほど深くなります。
第一の罠は検証の死角です。無人で動くループは、無人のままミスを犯します。「完了しました」は自己申告であって証明ではありません。証拠を出さないループは、自信たっぷりに間違い続ける装置になり得ます。対策は本記事で述べてきたとおり、証拠にもとづく検証と判定役の分離を仕組みに組み込むことです。
第二の罠は理解の負債と呼ばれるものです。ループが滑らかに成果を出すほど、人は自分の名前で出している文書やプログラムの中身から疎遠になっていきます。成果物が出てくる速度が上がるのと同じ速度で、作った本人の理解が置き去りになる。開発を急いだツケが後から返ってくる「技術的負債」とは別種の、静かに積み上がる負債です。要所の確認を省かない、生成物の判断理由を説明できる状態を保つ、といった地道な習慣でしか返済できません。
第三の罠がもっとも根深い、認知的降伏です。判断基準を自分で持つことをやめ、ループの出力をすべて受け入れるようになる状態を指します。「AIがそう言うので」が口癖になり始めたら、危険信号です。同じループを使っても、判断力を保ったまま使う人にとっては思考を増幅する道具になり、思考から逃げるために使う人にとっては思考を手放す装置になります。道具は同じでも、結果は正反対になるのです。
だからこそ、人がループの外側に立つ体制（Human-on-the-loop）へ移行しても、人に残る役割ははっきりしています。何をループに載せるかを決める入口の判断、要所の監視と引き継ぎの受け口、そして最終成果への責任です。自律化とは人が仕事から消えることではなく、人の判断を「本当に効く一点」へ集中させることだと捉えるのが、健全な理解だと考えています。
ループは、判断力を持って使えば増幅器になり、判断から逃げるために使えば促進剤になる。分かれ目は道具ではなく、使う側にある。
まとめ ― 流れを設計する側に回る
AIの生産性を分けるのは、指示の上手さよりも、答えが出続ける流れを設計できるかどうかです。
本記事の要点を振り返ります。AIを大量に、かつ上手に使う人は、使用量を目的にせず、仕事をAIに渡せる粒度まで言語化し、成功の条件・止まる条件・確かめ方を先に置いてから回しています。ループは合格ラインの約束（目標契約）に始まり、証拠にもとづく検証と判定役の分離で信頼性を作り、複数の止まる条件と費用の上限で安全を担保します。始めるなら、小さく検証できる仕事から。そして回した経験をルールへ還元し続けることで、ループは数ヶ月をかけて組織の資産になっていきます。
当社は、単発のプロンプト設計にとどまらず、確かめる仕組み・止まる条件・費用の上限まで含めた自律ループの設計と運用整備を、事業の成果から逆算してご支援しています。AIに任せる範囲を本気で広げたいとお考えでしたら、ご相談ください。
参考・引用元
- r.kagaya「どうすれば月2億円分のトークンを燃やせるのか」（Zenn） https://zenn.dev/r_kaga/articles/340fba67527789
- シンウフム「もうプロンプトを書くな──『Loop Engineering』という新しいパラダイムの正体」（Zenn／Acrosstudioテックブログ） https://zenn.dev/acrosstudioblog/articles/38509c0473683a
- 井本賢「もうプロンプトは書かない、ループを書く — Claude Code作者とOpenClaw作者が辿り着いた /goal と /loop」（Zenn） https://zenn.dev/kenimo49/articles/write-loops-not-prompts-goal-loop
- Addy Osmani “Loop Engineering” https://addyosmani.com/blog/loop-engineering/
- “How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks”（arXiv） https://arxiv.org/abs/2604.22750
- Anthropic “Building effective agents” https://www.anthropic.com/engineering/building-effective-agents
※本文は上記の公開情報および当社の運用知見をもとに再構成したものです。引用は日本語での意訳を含みます。報道値にもとづく金額・規模は概算であり、事例は特定の企業・案件・製品の推奨を意図するものではありません。