プロンプトを打つ時代から、ループを設計する時代へ

Last updated at 2026-08-27Posted at 2026-08-27

一度の指示で、最後まで仕事を終えてほしい。AIを使い始めた頃、僕はずっとそう考えていました。

質問を打ち、答えを待ち、違えば指示を足す。うまくいかないほどプロンプトは長くなり、例外と禁止事項が増えていく。それでも、少し違う仕事を渡すとまた外れます。正直、僕は指示の書き方が足りないのだと思っていました。

2026年、AIの使い方は一回の応答から、道具を使いながら複数の手順を進む形へ移っています。ただし、重要なのはAIが勝手に動くことではありません。動いた結果を観測し、その結果を次の判断へ戻せることです。

一回のプロンプトでは届かなかった仕事を、なぜループなら前へ進められるのか。そして、何を決めずに回すと危ないのか。この記事では、ループを「実行と観測の往復」として捉え直し、人が設計すべき場所まで一本の線で追います。

一回の応答には、結果が戻ってこない

一回のプロンプトが弱いのは、モデルが賢くないからではありません。行動した後の現実が、次の判断へ戻らないからです。

コードを書く仕事を例にします。実装前には正しそうに見えても、実際に動かすとテストが落ちることがあります。資料なら、文章は整っていても図と主張がずれる。検索なら、最初の結果に必要な情報が含まれていない。

AIへ「うまくできたか自分で考えて」と頼むだけでは、生成と評価が同じ文脈の中で閉じます。間違った前提を持ったまま、よくできたと判断することがあります。

ループでは、実行した結果を次の入力へ戻します。コードを書いたらテストする。失敗したら原因を読む。直して、もう一度テストする。検索したら、答えるのに十分かを確かめる。不足していれば問いを変えて検索し直す。

ループが回るほど、人の仕事は減るのではなく、置き場所が変わります。一手ずつ指示する代わりに、どの結果を見て次を決めるかを先に設計します。

設計するものは三つです。

AIが自信を持っていても、影響が大きい操作は人へ戻す必要があります。反対に、AIが迷っていても、やり直せる下書きなら先へ進められます。

そう感じる方もいると思います。毎回すべてを見るなら、確かに意味は薄いです。

ループは、一回の応答より多くの処理を使います。試す、読む、直すを繰り返すため、時間も費用も増えます。さらに、途中の小さな誤解が次の入力へ混ざると、誤差も輪の中を回ります。

大事なのは、回った回数ではなく、前の状態より進んだかを測ることです。テストの失敗数が減った。根拠が一つ増えた。評価点が基準へ近づいた。変化を観測できなければ、改善と同じ失敗の反復を区別できません。

ループは失敗から戻れる一方、外部への操作を重ねる危険があります。通信が途切れただけなのか、処理自体が失敗したのかを区別できないまま再試行すると、同じメールを二度送り、同じ登録を二度作ることがあります。

決まった順番で足りる仕事は、決め打ちのワークフローにします。状況で次の一手が変わる場所だけ、AIに判断させる。すべてを一人のAIへ渡さず、工程が分けられるなら分ける。

いきなり全社の業務をループへ変える必要はありません。最初は、手順の大半が決まっていて、一箇所だけ判断が必要な仕事が向いています。

定型メールの送信や決まった集計は、ループにしなくても動きます。入力と出力が決まっているなら、通常の自動化のほうが速く、安く、説明しやすい。

最初の設計図は、三段で十分です。

実装へ入る前に、僕なら一枚の紙を五つに分けます。実行すること、外から取得する事実、次の行動を選ぶ基準、終える条件、人へ戻す条件です。各欄を一文で書けない仕事は、まだ範囲が広すぎます。

小さなループを動かしたら、成功件数だけでなく、どこで止まったかを残します。終了条件を満たした、人へ戻した、上限回数へ達した、外部エラーで止まった。同じ停止でも意味が違います。

冒頭の問いに戻ります。一回のプロンプトでは届かなかった仕事を、なぜループなら前へ進められるのか。

行動の結果を観測し、その結果を次の判断へ戻せるからです。ループの本質は、AIが勝手に動くことではありません。外れた後に戻れる構造を持つことです。

僕はこの見方を持ってから、プロンプトを長くする前に、結果がどこへ戻るかを描くようになりました。最初に書くのは指示文ではなく、実行、観測、判断、終了条件、人へ戻す条件です。

同じように小さなループを作っている方がいれば、最初に何を観測点へ置いたか、コメントで知見を交換できるとうれしいです。