プロンプトは"書き続けるもの"ではなく"削り続けるもの" ── システムプロンプト肥大化問題と対策

はじめに

AIエージェントの出力、最近なんか微妙になってきた気がしませんか？

Cursor、Claude Code、Clineなど、AIエージェントを日常的に使っていると、カスタムインストラクションやシステムプロンプトを育てていくのが楽しいですよね。「このケースうまくいかないな」→「ルール追加しよう」を繰り返して、気づけばプロンプトが巨大な設定ファイルになっている……なんて経験、ありませんか。

実はこの 「ルールを足し続ける」行為そのものが、AIの出力品質を下げている 可能性があります。

この記事では、システムプロンプトの肥大化がなぜ起きるのか、何が問題なのか、そしてどう対処すればいいのかを整理します。

この記事で分かること

• システムプロンプトが肥大化するメカニズム
• 肥大化がAIの出力品質に与える具体的な悪影響
• 自分のプロンプトが「太りすぎ」かどうかの診断基準
• すぐ実践できる対策から、もう一歩踏み込んだアプローチまで

システムプロンプト肥大化とは

エッジケース追記ループ

肥大化の典型的なパターンはこうです。

1. AIが期待通りに動かないケースが見つかる
2. 「〜の場合は〜すること」というルールを追加する
3. 別のケースが見つかる → またルール追加
4. 以下繰り返し……

雪だるま式にルールが膨らんでいくわけですね。しかも、過去に追加したルールが今も必要かどうかは誰も検証しない。こうして 「誰も全体像を把握できない巨大プロンプト」 が出来上がります。

「AIにプロンプトを改善させる」ループの罠

もう一つ厄介なのが、AIにプロンプト自体を改善させるパターンです。

「このプロンプトを改善して」とLLMに頼むと、LLMは既存の指示を削除することを避ける傾向があります。追記・補足を繰り返すことで、元の意図がどんどん薄まっていく。矛盾する指示が共存したまま膨張していくってことですね。

コード生成の研究でも、反復的にLLMに改善させると5回の反復後に重大な脆弱性が37.6%増加したという報告があります。「AIに任せれば良くなる」とは限らないわけです。

そもそもプロンプトは「命令に従わせるもの」ではなく、行動の確率分布をずらすもの です。「完璧なプロンプトを書けばAIは完璧に動く」というのは誤解で、ハルシネーションの排除や論理的推論の保証はプロンプトだけでは制御できません。この前提を忘れてルールを積み上げ続けると、肥大化の沼にハマりやすくなります。

肥大化すると何が起きるか

矛盾する指示の問題

プロンプトが大きくなると、異なるタイミングで追加された指示同士が矛盾しやすくなります。

矛盾する指示がある場合、モデルはそれらを「平均化」するか「ランダムに選択」します。どちらにしても意図した動作にはなりません。「なんか出力がブレるな」と感じたら、プロンプト内の矛盾を疑ってみるといいですかね。

認知負荷の増大

ルールが多いほどモデルの「認知負荷」が増し、応答が遅くなり、エラーも増えます。

イメージとしてはこんな感じです。

プロンプトの状態	挙動
47のルール、12のエッジケース、23の「never/always」	ロボット的で遅く、エラーが多い
3つの目標、1つの重要ルール	自然で速く、適応的

人間でも「あれもこれも守って」と言われたら動けなくなりますよね。LLMも同じってことです。

コンテキストロット（Context Rot）

コンテキストウィンドウが埋まるほど、モデルのパフォーマンスが低下する現象を コンテキストロット と呼びます。

具体的には：

• 充填率50%未満: 中間部分のトークンが「迷子」になる（"Lost in the Middle" と呼ばれる現象）
• 充填率50%超: 古いトークン、つまり初期の指示が無視されやすくなる

システムプロンプトが巨大だと、それだけでコンテキストウィンドウのかなりの部分を消費します。会話が進むにつれて、肝心のシステムプロンプトの指示が無視される……本末転倒ですよね。

あなたのプロンプト、太りすぎてない？

以下に当てはまるものが多いほど、プロンプトの肥大化が進んでいる可能性があります。

1. プロンプトが500語を超えている
2. 箇条書きが10項目を超えている
3. 「never」「always」を2回以上使っている
4. 自然言語でIF/THENロジックを書いている
5. エージェントの応答が遅くなっている
6. エッジケースを修正するためにルールを追加し続けている
7. エージェントが一部の指示を無視している

特に7番目、「指示を無視する」は認知過負荷の典型的なサインです。ルールを足して解決しようとすると、さらに悪化するという悪循環に陥ります。

対策：プロンプトを痩せさせる

すぐできること

1. 削減リファクタリング

以下の4ステップで、プロンプトをスリムにできます。

Step 1: データを外部に出す

価格、スケジュール、ポリシーなどの「データ」はプロンプトに書かず、APIルックアップや関数に移します。プロンプトには「振る舞い」だけを書くのが理想です。

Step 2: 冗長な指示を削除する

LLMがデフォルトでできることを、わざわざ指示していませんか？

• 「礼儀正しく応答すること」→ LLMはデフォルトで礼儀正しい
• 「フィラー（えー、あー）を処理すること」→ LLMは自然に処理する
• 「不明点は確認質問すること」→ LLMはデフォルトでやる

こういった指示はノイズになるだけなので、削除してOKです。

Step 3: 本当にユニークな要件だけに絞る

残すべきは以下の3つだけです。

• 自分のワークフロー固有の指示
• ブランドボイス（口調・文体）
• 本当に重要なエッジケースのみ

Step 4: テストしながら削除する

1つずつルールを削除して、動作が変わるかテストします。変わらなければそのまま削除。意外と多くのルールが「なくても同じ」だったりします。

2. モジュール化（Instructions as Code）

1つの巨大プロンプトは、1つの巨大な関数と同じです。脆弱で、テスト不可能で、保守不能。

プロンプトもコードと同じように、モジュール化・バージョン管理するのが有効です。

/prompts
  /personas        # ブランドボイス
  /capabilities    # ビジネスロジック
  /constraints     # 出力フォーマット
  /guidelines      # 安全ルール

こうしておけば、変更時の影響範囲が把握しやすくなりますし、再利用もできます。

3. エージェントの分割

1つのスーパーエージェントに全部詰め込むのではなく、役割ごとに分割するアプローチです。

• 受付エージェント（ルーティング専門）
• サポートエージェント（技術的問題専門）
• ドキュメント生成エージェント（文書作成専門）

各エージェントがシンプルで集中した指示を持つので、プロンプトが肥大化しにくくなります。

もう一歩踏み込む

コンテキスト圧縮・要約

長い会話履歴を定期的に要約してコンパクトにする手法です。Claude Code の /compact コマンドがまさにこの考え方の実装例ですね。

研究レベルでは、エージェント自身が自律的にコンテキストを圧縮するアーキテクチャも提案されています。Focus Agent という手法では、精度を維持しながら平均22.7%のトークン削減を達成したとのことです。

RAG（Retrieval-Augmented Generation）

「プロンプトに詰め込む」から「必要なときだけ外部から引っ張る」への発想転換です。

製品情報・ポリシー・FAQなどをプロンプトに書かず、必要なときだけ検索して取得する。動的に取得するので情報の鮮度も保てます。

実装例：Claude Code の MCP Tool Search

Anthropicは2026年1月に MCP Tool Search を Claude Code に導入しました。MCPツールの説明がコンテキストウィンドウの10%を超えると自動起動し、全ツールをプロンプトに入れず、必要なツールだけを動的に検索・ロードします。

7つ以上のMCPサーバーを使うと67,000トークン以上消費していた問題を、最大85%削減できたとのこと。RAGの考え方をツール管理に適用した好例ですね。

参考: Tool search tool - Anthropic公式ドキュメント

ファインチューニング

口調・スタイル・ドメイン固有の応答パターンなど、変わらない振る舞いはプロンプトで毎回指示するより、モデルに学習させるほうが安定します。

研究では、シミュレーションデータでファインチューニングしたモデルのほうが、プロンプトで口調を指定するよりも一貫性が高かったという報告があります。

ただし、コスト・時間がかかるので「プロンプトでは本当に解決できない」と判断してから検討するのが現実的ですかね。

打ち手の全体マップ

最後に、対策の全体像をまとめておきます。

打ち手	難易度	概要
プロンプトの削減・整理	低	定期的に見直し、冗長・矛盾を除去
モジュール化	低〜中	再利用可能なブロックに分割し、必要時だけ注入
エージェント分割	中	役割ごとに分割し、各プロンプトを小さく保つ
コンテキスト圧縮・要約	中	会話履歴を定期的に要約してウィンドウを節約
RAG	中〜高	知識をプロンプト外に出し、必要時に検索取得
ファインチューニング	高	変わらない振る舞いをモデルに焼き込む

まとめ

• システムプロンプトは、エッジケース追記や「AIによる改善」ループで肥大化しやすい
• 肥大化すると、矛盾する指示・認知負荷の増大・コンテキストロットにより出力品質が低下する
• プロンプトは「命令に従わせるもの」ではなく「行動の確率分布をずらすもの」。完璧なプロンプトを書けば完璧に動くわけではない
• まずは削減リファクタリングから。テストしながら1つずつルールを削除してみる
• プロンプトは「書き続けるもの」ではなく 「削り続けるもの」

以上です、プロンプトのダイエット、定期的にやっていきましょう。

参考

• Less is More: Why Over-Prompting Kills Your AI Agent - SignalWire
• Why Your AI Gets Worse Every Time You "Improve" the Prompt - AI Space
• System Prompts as Infrastructure: Instructions Like Code - LLMx
• Context Rot: Why AI Gets Worse the Longer You Chat - Product Talk
• Context Pollution - Adam Holter
• The Prompt Engineering Playbook - Neosage
• Security Degradation in Iterative AI Code Generation - arXiv
• Autonomous Memory Management in LLM Agents (Focus Agent) - arXiv
• Mitigating Prompt Bloat in LLM Tool Selection via RAG - arXiv
• Tool search tool - Anthropic公式ドキュメント
• Fine-tuning on simulated data outperforms prompting for agent tone of voice - arXiv
• Lost in the Middle - Liu et al. (2023)