【2026年版】AIエージェントの暴走を防ぐプロンプト設計10選｜1人SaaS開発の極意

2026年現在、Gemini SparkやClaude Codeといった「勝手に動いてくれる」常駐型のAIエージェントが普及している。1人でSaaS開発をする身として、これらのツールは手放せない存在だ。しかし、便利さと引き換えに「AIが指示を無視して暴走する」「無限ループに陥ってAPIコストが跳ね上がる」といったトラブルも増えている。

結論として、従来の対話型AIと同じ感覚でプロンプトを書いてはいけない。常駐型エージェントには、それ専用の「制御設計」が必要になる。ここでは、開発現場で培った、AIエージェントの暴走を構造的に防ぐためのプロンプト設計術を10個紹介する。これを読めば、AIに振り回される日々から解放されるはずだ。

1. 出力上限と「やらないこと」の明示

AIエージェント、特に常駐型のものは「サービス精神」が旺盛すぎる傾向がある。例えば「最新のニュースを収集して」と指示すると、制約がない限り100件でも200件でも情報を取ってこようとする。これが実行コストの膨張と、質の低下を招く原因だ。

対策はシンプルで、出力の「収集上限数」と「除外条件」を数字で明示する。「最大5件まで」「広告記事は除外する」といった制約をプロンプトの冒頭に置く。LLMは制約がない状態を「最大化すべき」と解釈するため、あえて「枠」をはめることが安定運用の第一歩になる。

2. 自己出力の再帰防止（タグ付け運用）

常駐型エージェントで最も恐ろしいのが「無限ループ」だ。例えば、メールの下書きを作るエージェントが、自分が作った下書きを「新着メール」と勘違いして、さらにその下書きを作るという現象が起きる。これに気づかないと、一晩で数万円のAPI費用が消えることもある。

これを防ぐには、エージェントの成果物に必ず特定のタグ、例えば [auto-generated] といった文字列を付与させるルールを徹底する。そして、入力条件に「このタグが含まれる場合は処理対象から除外する」と明記する。自分の出力が次のトリガーにならないよう、論理的な境界線を引くことが不可欠だ。

3. アクション分類による安全制御（SAFE/CONFIRM/BLOCK）

AIの「タスクを完遂したい」というバイアスは、時にユーザーの意図を超えた操作を引き起こす。勝手にファイルを削除したり、未確認のまま顧客にメールを送ったりするのはその典型だ。プロンプトだけで「慎重にやって」と頼んでも、AIは完了を優先してしまう。

そこで、エージェントが行うアクションを SAFE（即実行可）、CONFIRM（確認必須）、BLOCK（実行禁止） の3段階に分類して定義する。特に決済や外部送信、データの削除などは必ず CONFIRM 以上に設定し、人間の明示的な承認がない限り動けないフローを構築する。プロンプトは「お願い」ではなく「権限管理」だと考えるべきだ。

4. ハートビートによる生存確認とログ出力

常駐エージェントの厄介な点は「黙って失敗する」ことだ。RSSフィードの仕様が変わったり、APIの形式が変わったりしたときに、エラーも出さずに「処理件数0」で動き続けることがある。これを「サイレントな機能不全」と呼ぶ。

対策として、実行のたびに ハートビート（生存報告） をログに残させる指示を入れる。処理時刻、成功件数、スキップした理由などを構造化データとして出力させる。これにより、異常が起きたときにどのステップで止まったのかを即座に把握できる。ログを見る習慣をつけるだけで、システムの腐敗を早期に発見できる。

5. 責務分割パイプライン（Agent Decomposition）

1つの巨大なプロンプトに「収集、分析、要約、投稿」のすべてを詰め込むのは、初心者が最もやりがちな失敗だ。プロンプトが長くなればなるほど、LLMの注意リソースは分散し、指示の遵守率は数学的に低下する。

賢いやり方は、タスクごとにエージェントを分割することだ。収集担当、フィルタリング担当、要約担当というように、小さなプロンプトを持つ複数のエージェントを中間成果物でつなぐ。これを パイプライン設計 と呼ぶ。1つのタスクをシンプルに保つことで、デバッグが容易になり、全体の精度も飛躍的に向上する。

しんたろー：
1人でSaaS開発をしていると、つい1つのAIに全部任せたくなる。しかし、Claude Codeでコードを書いている経験から言うと、機能を小分けにするのが一番の近道だ。複雑なロジックを1つのプロンプトで解決しようとせず、小さな関数の積み重ねのようにAIを使い分けるのがコツだ。

6. TOA（Tape-Oriented Assembly）による命令分離

これは少し上級者向けだが、非常に効果的な手法だ。自然言語による長い指示を減らし、4文字程度の短い記号（パケット）で命令を構成する。例えば s4x9 という文字列に「セキュリティドメイン、コンテキスト4、XSSチェック、優先度9」という意味を持たせる。

LLMには「この記号を解釈して実行しろ」という極小の命令だけを与え、実際の条件分岐やループの制御は外側のプログラム側で管理する。これにより、LLMのコンテキストが汚染されるのを防ぎ、論理的なミスを最小限に抑えることができる。AIを「賢い人間」として扱うのではなく、「高性能なCPU」として扱う発想だ。

7. 制約の密度管理と配置最適化

LLMには「プロンプトの中間にある情報を忘れやすい」という性質がある。これを Lost in the Middle と呼ぶ。制約をダラダラと書き連ねても、真ん中あたりに書いたルールは高確率で無視される。

重要な制約は、必ずプロンプトの 先頭 か 末尾 に配置する。また、一度の呼び出しで処理させる制約の数は最小限に絞るのが定石だ。制約を増やせば増やすほど、既存のルールの遵守率も下がるというトレードオフを常に意識しなければならない。

8. 推論と制約遵守のトレードオフ回避

複雑な推論（Chain of Thought）をさせると、LLMの注意リソースは「考えること」に奪われ、結果として「フォーマットを守る」「禁止事項を守る」といった制約への注意力が低下する。

論理的な思考が必要なタスクと、厳格なルール遵守が必要なタスクは、ステップを分けて実行するのがベストだ。まず思考プロセスだけを出力させ、次のステップでその思考結果をもとにルールに従って整形させる。この「思考と出力の分離」が、暴走を防ぐための強力なガードレールになる。

9. フィードバックループの遮断と回数制限

エージェントがエラーに遭遇した際、良かれと思って何度もリトライを繰り返し、無限ループに陥ることがある。これを防ぐには、プロンプト内で「リトライは最大3回まで」「同じエラーが続く場合は処理を中断して報告せよ」と明示的に回数制限を設ける必要がある。

AIは「何とかして解決しよう」と努力するが、その努力がコストの無駄遣いになるケースは多い。あきらめるタイミングをこちらで指定しておくことが、安全な運用のための知恵だ。

10. コンテキストの鮮度管理

常駐型エージェントは、過去の履歴をコンテキストとして持ち続けることが多い。しかし、古い情報が混ざっていると、現在の指示と矛盾が生じて挙動が不安定になる。

定期的にコンテキストをリセットするか、重要な最新情報だけを「現在のコンテキスト」として再定義する指示を入れる。古い前提条件を捨てさせることで、AIの判断を常にクリーンな状態に保つことができる。

AIエージェント対策 比較表

| 対策手法 | コスト削減効果 | 信頼性向上 | 実装難易度 | おすすめ度 |

| :--- | :--- | :--- | :--- | :--- |

| 出力上限の明示 | 高 | 中 | 低 | ★★★★★ |

| 自己出力のタグ付け | 極高 | 高 | 低 | ★★★★★ |

| アクション分類 | 中 | 極高 | 中 | ★★★★☆ |

| 責務分割 | 中 | 高 | 高 | ★★★★☆ |

| TOA（命令分離） | 低 | 極高 | 極高 | ★★☆☆☆ |

しんたろー：
開発しているThreadPostでも、エージェントの暴走対策には一番気を使っている。特にタグ付けによる無限ループ防止は、実装したその日から安心感が全く違った。まずは「上限設定」と「タグ付け」から始めるのが、1人開発を継続させる秘訣だ。

よくある質問（FAQ）

Q1. プロンプトを長く書いているのに指示を守ってくれません。なぜだ？

LLMには「コンテキストの真ん中にある情報を忘れやすい」という性質がある。また、制約の数が増えるほど、一つひとつのルールに対する注意力が分散する。長いプロンプトは逆効果になることが多いため、重要な指示は先頭か末尾に配置し、タスクを分割して一度に処理させる制約の数を減らすのが正解だ。

Q2. 常駐型エージェントが勝手に動き続けてコストが怖いが、どうすればいい？

「やらないこと」と「上限」を明示することが最優先だ。また、自分の出力が次の入力にならないよう、成果物にタグ付けして除外する仕組みを必ず入れるべきだ。さらに、ハートビートをログに出力させることで、意図しないループや異常動作を早期に検知できるようにする。

Q3. LLMの推論能力を最大限活かすにはどうすればいい？

推論と制約遵守は、LLM内部でリソースを奪い合う。複雑な推論をさせる場合は、ルール遵守を厳しく求めすぎないようにし、逆に厳格なフォーマットが重要な場合は、推論を最小限にするのがいい。推論が必要なステップと、ルールに従って出力するステップを分けるのがベストな設計だ。

Q4. TOAのような手法は初心者には難しすぎないか？

TOAは上級者向けだが、「LLMに全てを任せず、フロー制御はプログラム側で持つ」という考え方は誰にとっても重要だ。まずは、LLMには「判断や抽出」だけをさせ、その結果を受けて「次に何をするか」の分岐はPythonなどのコードで書く、という役割分担から始めてみるのがいい。

Q5. エージェントが勝手に外部サービスを操作しないか不安だ。

プロンプトだけで制御しようとせず、必ず「アクション分類」を導入する。特に外部操作を伴うものは CONFIRM 状態にし、ユーザーの承認がないと実行されないフローを設計する。プロンプトはあくまで「お願い」であり、強制力のあるアクセス制御ではないことを前提に、システム側でガードレールを設けるのが鉄則だ。

まとめ

AIエージェントの暴走を防ぐには、プロンプトを「対話」ではなく「システムの仕様書」として捉え直す必要がある。

1. 出力上限を数値で指定する
2. 自己出力タグで無限ループを断つ
3. アクション分類で権限を管理する
4. 責務分割でAIの注意力を集中させる
5. 重要指示は端に配置する

これらの原則を守るだけで、AIエージェントの安定性は劇的に向上する。まずは今日から、自分のプロンプトに「上限設定」と「やらないことリスト」を追加することから始める。

AIは強力なパートナーだが、手綱を握るのは常に人間だ。正しい設計技術を身につけて、1人開発のスピードを加速させる。