AIエージェントの『ループ』はどこで止めるべきか——Anthropicの4分類とVibeCoding現場の境界線

「ループ」とは何か——プロンプトの先にある設計思想

「AIにコードを書いてもらう」という体験は、この1〜2年で様変わりしました。最初は1回の指示に1回の応答が返ってくる、いわば会話のやりとりでした。ところが今のAIコーディングエージェントは、指示を受けたあと自分でファイルを読み、コードを書き、実行し、結果を見て次の一手を決める、という工程を人の介入なしに何度も繰り返せます。この「起動してから停止条件が満たされるまで作業を繰り返す仕組み」を指す言葉として、Anthropicの整理を紹介した@ITの記事は「ループ」という表現を使っています。

正直に言えば、私たちも当初は「ループ」という言葉を単なるバズワードだと捉えていました。ですが実際にClaude CodeやCodexを長時間動かしてみると、印象は変わりました。プロンプトの巧拙よりも、AIエージェントのループ設計、つまり「このループをどう起動し、どこで止めるか」のほうが、成果物の品質を大きく左右することに気づかされたのです。プロンプトエンジニアリングの次に来るのはコンテキストエンジニアリングだと言われていました。ですが実務で本当に重要になったのは、コンテキストの中身以上に、ループそのものの設計でした。

この感覚は私たちだけのものではないようです。海外のAIエンジニアリング関連カンファレンスでも、ループの設計をめぐる議論が活発になっていると耳にしました。ツールの機能一覧を比較する時代から、ツールをどう回すかを比較する時代に移った、というのが私たちの実感です。

Anthropicが示す4種類のループ——ターン・ゴール・タイム・プロアクティブ

Anthropicはループを「どう始まり、どう止まるか」という切り口で4種類に分類しています。ターンベースは人間の指示で始まり、タスク完了か追加入力が必要になった時点で止まります。ゴールベースは目標を渡すと、その達成か最大ターン数への到達で止まります。タイムベースは決まった時間間隔で起動し、条件達成かスケジュール終了で止まります。プロアクティブはイベントをきっかけに人間の指示なしで起動し、目標達成まで動き続けます。

この4分類を読んで私たちが最初に感じたのは、ある一点でした。自律性の度合いが上がるほど「止まる理由」を人間が事前にどれだけ丁寧に定義しているかが問われる、という点です。ターンベースなら、AIが止まらなくても人間がそこにいます。ですがプロアクティブになると、止まる理由が甘ければAIは延々と作業を続けてしまいます。冒頭で紹介した、櫻井が朝まで放置した例はまさにこのタイムベースとプロアクティブの境界にあたるループでした。機能の完成だけを成功条件にしていたため、判断の記録という別の重要な条件が抜け落ちていたのです。

4種類のうち、私たちが顧客の現場で実際に使う頻度が高いのはターンベースとゴールベースの2つです。タイムベースは定期レポートの生成など決まった作業には向きますが、プロアクティブはまだ「任せて良い業務」を選ぶ判断そのものが難しく、慎重な検証を重ねている段階です。

内側ループと外側ループ——エンジニアの仕事はどこに移るのか

もう一つ重要な整理が、内側ループと外側ループ(ハーネス)の区別です。内側ループは、AIが出したコードを実行し、結果を組み込み、ファイルを読み書きし、テストを回すという、1つのタスクの中で回る処理を指します。外側ループはそれを取り囲む枠組みです。どの仕事をいつ渡すか、セッションをどう続行するかを管理する仕組みで、Claude Codeのようなツールもこのエージェントループの仕組みを土台に動いています。

私たちの現場経験では、内側ループの精度はモデルの進化でどんどん上がっていきます。一方で外側ループの設計は、現場ごとに手作りするしかありません。ここは意見が分かれるところですが、私たちは「エンジニアの仕事は内側ループを書くことから、外側ループ、つまりハーネスを設計することへ移っていく」と考えています。どの業務をどのタイミングでAIに渡すか、どこで人が確認するかを決める仕事は、コードを1行も書かなくても高い専門性が要求されるのです。

たとえばある製造業のDX推進担当者は、社内で開発環境を整える難しさについて「知識のギャップがあり、社内で環境を構築するのは難しい」と率直に語っていました。私たちの見立てでは、この種の難しさは今後、コードを書く力よりも、ループを安全に設計し運用する力の不足として表面化していきます。

VibeCoding現場で私たちが実際に回してみたループ

言葉の整理だけでは実感が伝わらないので、私たちが顧客先で実際に試したループの使い分けを紹介します。ある化粧品メーカーの生産計画システムでは、まずターンベースのループで機能を1つずつ作りました。現場担当者がその場で動作確認するというやり方です。次に、テストコードの自動生成と実行だけをゴールベースのループに任せ、「全テストが通過する」を成功条件にしました。ここまでは想定どおりに動きました。

ところが同じプロジェクトで、深夜バッチのエラーログを解析して修正案を作るところまでプロアクティブなループに任せたところ、想定していなかったことが起きました。AIが「エラーの原因らしきもの」を見つけ、先回りで既存の設定ファイルを書き換えてしまったのです。結果的に修正自体は正しかったのですが、誰も指示していない変更が本番環境に近い検証環境に入っていました。翌朝の定例で、現場から鋭い指摘を受けたのは言うまでもありません。この経験から、私たちはプロアクティブなループを本番に近い環境で使う際には運用を切り替えました。変更を提案する段階でいったん止め、人間が承認してから実行するというやり方です。

このシャッター・建材メーカーの生産管理部長がAIによる図面チェックの実演を見て「それできるようになると、もうすごい作業効率が上がります」と期待を語った一方、「検図・工作図の担当者の入れ替わりが激しく、教える時間がないため、作業の指示のみになりがち」と現場の苦労も口にしていたことを、私たちはこの一件のたびに思い出します。ループの自律性を上げれば効率は上がります。ですが教える時間を惜しんだまま止め方の設計を省くと、効率の代わりに別のコストを払うことになるのです。

コストと「ループ税」——止め方を決めないと何が起きるか

ループを止める条件を甘くすると、まず表面化するのはコストの問題です。ループエンジニアリングを解説したAI総合研究所の記事は、ループ化したエージェントが際限なくトークンを消費し続けるリスクを「ループ税」という言葉で表現しています。これは私たちの実感とも一致しています。ゴールベースのループに「テストが全部通るまで」という条件だけを与えると、AIはテストを通すために本質的でない修正を積み重ね続け、気づいたときには当初の見積もりの数倍のコストがかかっていることがあります。

誤解のないように言えば、これはAIの性能が低いから起きる問題ではありません。むしろ性能が高いほど、与えられた目標に対して忠実に手段を尽くそうとします。だからこそ目標設定が粗いと、コストが膨らみやすいのです。私たちが顧客に伝えているのは、ループを始める前に「何をどこまでやったら成功なのか」を人間の言葉で書き出す作業に、コーディング自体より長い時間をかけてもいい、ということです。

これは製造業のVibeCoding 品質管理でも同じ構図が見られます。ある大手化学メーカーのAI推進担当は、AI活用が現場に広がらない理由として「データはある程度揃ってきているが、そのデータを基に人がどう考え、どう動くかを定義・教育するのが難しい」と語っていました。ループの成功条件を定義する作業は、まさにこの「人がどう考え、どう動くか」を言葉にする作業そのものです。ここを省いてループだけ高性能にしても、コストは減りません。

暴走と「認知投降」——AIに判断を丸投げした現場で起きたこと

コストよりも見えにくいリスクが、AI総合研究所の記事が「認知投降」と呼ぶ状態です。ループが十分に賢く見えると、人間はいつの間にか「AIの判断のほうが正しいのだろう」と思い込み、確認する手間を省くようになります。私たちが以前公開したVibeCodingのコードレビュー記事でも触れましたが、AIを実装者としてだけでなく審査者としても使う設計にしないと、この認知投降は避けられません。

ある製造業の現場では、図面の記載ミスを検出するループが高い精度を出し続けたことで、担当者が最終確認を形だけのものにしてしまいました。実際には検出漏れが1件本番に流れてしまった、という出来事もありました。幸い後工程で発見できましたが、これは技術の問題ではありません。運用のどこにも「人間が本気で確認する」というステップが残っていなかったことが原因です。ループが優秀であればあるほど、確認を軽んじたくなる誘惑は強くなります。

ある精密部品メーカーの代表者は、業界横断のプラットフォームについて「現場の人は不良が出ても何が悪いか分からないため問い合わせ先も分からない」という悩みを語っていました。ループに検査業務を任せる際も、これと同じ構造の危うさがあります。AIが「なぜその判断をしたか」を誰も説明できない状態のまま検出精度だけが上がっていくと、いざ検出漏れが起きたときに、誰も原因を追えなくなるのです。私たちがVibeCoding 品質管理で重視しているのは、精度そのものより「判断の理由を後から追えるか」という点です。

安全にループを回すための4つの必須要素

私たちがVibeCoding導入の現場でゲート基準にしているのは、明確なタスク定義、安全な作業環境、機械的な成功テスト、そしてハードストップという4つの要素です。明確なタスク定義とは、ゴールを「テストが通る」のような一言で終わらせず、何をやってはいけないかまで書くことです。安全な作業環境とは、ループが本番データや本番環境に直接触れないよう、検証環境やサンドボックスを用意することを指します。

機械的な成功テストは、単体テスト(UT)やシナリオテストのように、人が毎回見なくても機械的に合否を判定できる仕組みです。私たちは社内システムのAIPLAでも、Vitestによる単体テストとPlaywrightによるシナリオテストを自動化しています。ただし、ユーザーが実際に触って確認する受け入れテストだけは、あえて人間の工程として残しています。VibeCodingでときどき起こる「指示していない項目が勝手に増える」ような事故は、この受け入れテストの段階で止めるようにしています。ハードストップは、回数・時間・コストのいずれかの上限を機械的に決めておくことです。プロアクティブなループほど、この4つを事前に決めていないと安全に回せません。

この4つの要素は、VibeCoding 品質管理の実務でそのままチェックリストとして使えます。私たちが顧客に最初に確認するのは、実は技術的な項目ではありません。「この業務でループが暴走したとき、誰が最初に気づける状態になっているか」という、体制の問いです。技術的な安全対策より先に、この問いに答えられない業務にはプロアクティブなループを入れないという判断をしています。

私たちの見解:AIエージェント ループ 設計はどこから始めるべきか

数多くの現場でAIエージェントのループ設計を試してきた結論を、率直にお伝えします。VibeCodingを初めて導入する企業が、いきなりプロアクティブなループから始めるのは勧めていません。まずはターンベースのループで、人間が毎回結果を見る状態から始めます。AIがどういう手順で作業を進めるのかを、人間側が理解することが先だからです。次に、テストの自動生成や定型的なコードレビューのように、ミスの許容度が高い作業だけをゴールベースのループに任せます。成功条件は、そこから少しずつ厳密にしていきます。

タイムベースやプロアクティブなループは、成功条件とハードストップの設計に十分な自信が持てるようになってから、影響範囲の小さい業務に限定して試すのが現実的です。これは「小さく始めて成功体験を積み重ねる」という私たちの考え方そのもので、ループの自律性を上げる順番にも同じ原則が当てはまります。1日で動くプロトタイプを作れる時代になったからこそ、どこで止めるかを決める設計に時間をかける価値がある、と私たちは考えています。

AIエージェント ループ 設計をBPR(業務プロセス診断)にどう活かすか

ここまで技術的な分類を説明してきましたが、実際にどの業務をどのループに任せるかを決める作業は、コードを書く前の業務整理から始まります。私たちが顧客先に入るとき最初に行うのは、代表の櫻井が自作した業務整理ツール(社内呼称LMBPR)を使い、ヒアリングから業務フロー・改善案・ROIをたたき台として可視化することです。これが記事の冒頭でも触れた無償の業務プロセス診断(BPR)の実体です。

BPRの段階でループ設計の話をするのは早すぎるように見えるかもしれません。ですが、業務の棚卸しをしていく中で「この業務は結果だけ見ればいい」「この業務は途中の判断も全部見たい」という現場の温度差が、ほとんどの場合で見えてきます。この温度差こそが、ターンベースにするか、ゴールベースやタイムベースまで任せてよいかを分ける最初の材料になります。技術検証より先にこの整理をしておくと、後からループの自律性を上げる際の判断が、現場の納得感を伴ったものになります。

たとえば、ある中堅設備工事業の現場では、工事完了報告書の電子化と施工アンケートのデータ化から着手しました。紙の報告書をデータベースに直接取り込む工程は、ミスが起きても後工程で修正しやすいため、私たちは早い段階でゴールベースのループを任せました。一方、同じ現場で検討していた原価配賦のような数字は、一度誤ると経営判断そのものに影響するため、今もターンベースのまま、担当者が毎回結果を確認する運用を続けています。同じ会社の中でも、業務によってどこまでループに任せるかは変わるのです。この見極めこそが、BPRの段階で一番時間をかけるべき作業だと私たちは考えています。

よくある質問

Q. ループエンジニアリングを学ぶには、まず何から始めればいいですか。 A. 新しい概念を学ぶというより、今すでに使っているAIコーディングツールが「どのタイミングで止まっているか」を意識して観察することから始めるのが早道です。ターンベースなのか、内部でゴールベースの繰り返しをしているのかを知るだけで、設計の視点が変わります。

Q. プロアクティブなループは危険なので使わないほうがいいのでしょうか。 A. そうとは言えません。定型的な監視業務やレポート生成のように、影響範囲が小さく失敗しても取り返せる業務であれば、プロアクティブなループのメリットは大きいです。本番環境に近い場所で使う際に、承認ステップを挟むかどうかの設計が重要になります。

Q. ループの設計と従来のCI/CDパイプラインは何が違うのですか。 A. CI/CDは事前に決めた手順を機械的に実行する仕組みですが、ループはAI自身が次にどう動くかを都度判断します。そのため、CI/CDでは想定していなかった「AIが自分の判断で範囲を広げる」リスクへの備えが別に必要です。

Q. 小規模なチームでも4つの必須要素をすべて整えないとループは使えませんか。 A. 最初から全てを整える必要はありません。私たちが小規模なチームに勧めているのは、まずハードストップ(時間かコストの上限)だけを決めてターンベースで始め、慣れてきたら明確なタスク定義と機械的な成功テストを1つずつ追加する順番です。安全な作業環境だけは、規模にかかわらず最初から用意しておくことを勧めています。

まず試すなら

1. 今使っているAIコーディングツールが、ターン・ゴール・タイム・プロアクティブのどのループで動いているかを確認する
2. 現在自動化している(あるいは自動化を検討している)業務について、成功条件とハードストップを人間の言葉で書き出してみる
3. 承認ステップが一つも残っていない業務があれば、まずそこにだけ人間の確認を1つ追加する

この3つは、特別な予算やツールがなくても今日から始められます。逆に言えば、ここができていない状態でループの自律性だけを上げていくのは、私たちの経験ではうまくいきません。

自社の業務のどこにループ設計を入れられるか、あるいはどこにまだ入れるべきではないかを一緒に整理したい場合は、AI-Pathの無償の業務プロセス診断(BPR)をご利用ください。現場のヒアリングから、AIが効く業務とそうでない業務の境界を具体的に見極めます。統制の設計そのものをもう少し深く知りたい場合は、エージェント型AIの業務導入で本当に難しいのは「動かすこと」ではないも併せてご覧ください。

参考リンク

本記事の執筆にあたり以下を参照しました。

AIコーディングの「ループ」4種類を完全入門 Anthropic公式が分かりやすく整理して解説 - @IT

ソフトウェアエンジニアの仕事は「ループを書くこと」になる 内側ループと外側ループ（ハーネス）入門 - @IT

ループエンジニアリングとは？AIエージェントを自律で回す設計手法と6つの構成要素を解説 - AI総合研究所