Loops が Prompts に取って代わる：ループエンジニアリングが AI Agent の使い方を変える

Wed, 10 Jun 2026 13:13:28 +0800

「Loops が Prompts に取って代わる」とは、より正確には、AI Agent の使い方が「よいプロンプトを 1 つ書く」ことから「フィードバックシステムを設計する」ことへ移っているという意味です。

これまでは Prompt が中心でした。タスクをどう説明するか、出力をどう制限するか、モデルに一度でよりよい答えを返させるにはどうするか。短いタスクでは今でも有効ですが、長期的で検証可能な複数ステップのタスクでは、単発のプロンプトは途中で止まりがちです。

Loop の考え方は違います。モデルに一度で最終結果を出させるのではなく、モデルを継続的に動く循環の中に置きます。生成、実行、検証、フィードバック、再生成です。人間の役割も「プロンプトを打つ人」から「ルール、状態、境界を設計する人」へ変わります。

Prompt と Loop の主な違い

観点	従来の Prompt	現代的な Loop
作業モード	一問一答で、通常はコールドスタート	継続的なコンテキスト、バックグラウンド実行、自動反復
人間の役割	プロンプトエンジニア。意図を明確に書く	システムアーキテクトまたは Meta-Prompt エンジニア。ルールを書く
フィードバック	結果が悪ければ Prompt を書き直す	テスト、検証、再試行、修正の閉ループを内蔵
主な利点	始めやすく、短期タスクに強い	複雑な長期タスクに向き、途中終了を減らせる
主なリスク	結果が不安定で、人手の追加入力が必要	コスト、状態管理、暴走リスクが高い

Prompt は 1 回のリクエストに近く、Loop は 1 つのシステムに近いものです。前者は Q&A、要約、リライト、小さなコード片に向いています。後者はコード修正、自動運用、在庫確認、データ処理、継続監視に向いています。

典型的な Loop の流れ

現代的な Agent の Loop は、通常 4 つのステップに分けられます。

第 1 ステップは指示入力です。ユーザーが自然言語で Agent に大きな目標を与えます。たとえば「倉庫在庫を確認し、しきい値を下回ったら自動で補充する」や「このリポジトリでテストが失敗する原因を修正する」といったものです。

第 2 ステップは生成と実行です。Agent は現在の目標から最初の行動を決めます。ファイルを読む、API を呼ぶ、コマンドを実行する、コードを修正する、計画を書く、といった行動です。

第 3 ステップは検証とフィードバックです。システムが自動で結果を確認します。テストを実行する、コンパイルエラーを見る、ログを読む、在庫状態を比較する、API レスポンスが期待どおりか確認する、などです。

第 4 ステップは意思決定と反復です。検証に通れば次へ進みます。失敗すれば、システムがエラー情報を取り出し、コンテキストまたは Prompt を調整し、Agent に自己修正させて再実行します。

簡略化すると次のようになります。

1
2
3

目標入力 -> 行動を生成 -> タスクを実行 -> 結果を検証 -> 次の一手を決める
                ^                              |
                |---------- フィードバック -----|

Loop の価値は、「結果を見る、エラーを探す、もう一度試す」という作業を自動化できることです。人間が毎回エラーをコピーし、プロンプトを書き直し、リクエストを再送する必要がなくなります。

Agent に Loop が必要な理由

AI Agent と通常のチャットの最大の違いは、Agent がテキストを生成するだけではない点です。ツールを呼び出し、状態を読み、実際に行動します。ツール呼び出しと現実の環境が入ると、単発の Prompt だけで全分岐をカバーするのは難しくなります。

たとえば、プロジェクトのテスト失敗を直す場合、モデルは最初に 1 つのエラーだけを見るかもしれません。修正後にはテストを再実行する必要があります。テストが通れば、フォーマットの問題がないか確認します。さらに境界ケースも確認するかもしれません。この流れは自然に Loop になります。

在庫の自動補充も同じです。Agent は「補充をおすすめします」と答えるだけでは不十分です。在庫を読み、しきい値を判断し、仕入れ先を確認し、注文を作成し、確認を待ち、失敗時にはロールバックまたはアラートを出す必要があります。重要なのは美しい 1 文のプロンプトではなく、プロセスと制約です。

実運用前に注意すべき 3 つの問題

Loop は強力ですが、複雑さは Prompt からシステム設計へ移ります。

1 つ目は Token コストです。各反復で入力、コンテキスト、出力 Token が消費されます。短い間隔で長時間動き、多くのツールを使う Loop は、コストが急増しやすくなります。本番環境では通常、予算上限、反復回数制限、キャッシュ戦略、タスク分割が必要です。

2 つ目は状態の複雑さです。複数ステップの状態機械をデバッグするのは、単発の Prompt を調整するよりずっと難しいです。Agent がどの段階にいるのか、何を読んだのか、なぜその行動を選んだのか、失敗後にどこへ戻るべきかを把握する必要があります。

3 つ目は暴走リスクです。明確な停止条件、拒否ルール、権限境界がなければ、Agent は無限ループに入り、無用なコードを生成し続けたり、ツールを何度も呼び出したり、間違った方向へ進み続けたりする可能性があります。

基本的な Loop に必要なルール

Loop を信頼できるものにするには、少なくともいくつかのルールが必要です。

目標ルール：何をもってタスク完了とするかを定義します。できればテスト、状態チェック、または人間の確認で検証できる形にします。

行動ルール：Agent が呼び出せるツール、変更できるファイル、アクセスできるデータを制限します。

フィードバックルール：失敗時にエラーをどう抽出するか、コンテキストをどう短くするか、再試行するか別戦略に変えるかを定義します。

停止ルール：最大反復回数、最大コスト、最大実行時間、人間に引き渡すべき条件を設定します。

監査ルール：各ラウンドの入力、行動、結果、判断を記録し、後から再現・調査できるようにします。

これらのルールは、「丁寧にタスクを完了してください」と書くより重要です。Loop エンジニアリングの中心は、モデルをより従順にすることではありません。モデルを制約し、結果を観察し、エラーが出たときに明確な処理経路を持つシステムを作ることです。

Prompt Engineering から Loop Engineering へ

Prompt Engineering は消えません。Loop システムの 1 つの部品になります。目標、制約、出力形式を明確に書く必要は今後もありますが、長期タスクの成否を決めるのは、検証、状態、再試行、停止条件です。

次のように考えるとわかりやすいです。

Prompt はモデルに「このラウンドでどう考えるか」を伝える。
Tool はモデルに「何ができるか」を与える。
State は「今どこまで進んだか」を記録する。
Test は「結果が信頼できるか」を判断する。
Stop Hook は「いつ必ず止めるか」を決める。

これらが組み合わさると、AI Agent は一度きりの回答生成器ではなく、継続的に動く自動化システムになります。

まとめ

「Loops が Prompts に取って代わる」とは、プロンプトが不要になるという意味ではありません。AI Agent の中心が、単発の表現力から継続的なフィードバック能力へ移っているということです。

短いタスクには今でも Prompt が向いています。複雑で、長期的で、検証が必要なタスクには Loop のほうが向いています。本当の変化は、人間が完璧な一文を書く人ではなく、実行でき、検証でき、停止でき、復旧できるフィードバックループを設計する人になることです。

ループエンジニアリング on KnightLiブログ