LLM（大規模言語モデル）を使ったAIエージェントを設計・運用しているエンジニアに向けた話です。GitHubで公開された275,000字を超えるClaude Fable 5.1向けのランタイムプロンプト（実行時にモデルへ渡される指示文）が話題になりました。この件自体の真偽より、そこから見えてくる設計上の落とし穴を整理してみます。
このプロンプトは「Claudeがハッキングされ、秘密の指示が漏洩した」という見出しで広まりました。しかしAnthropic（Claudeの開発元）のサーバーが侵害された証拠や、モデルの重み（学習済みパラメータ）が盗まれた証拠は公開情報として確認されていません。実態は、Pliny the LiberatorというGitHubアカウントが運営する「CL4R1T4S」というリポジトリで、複数のAI製品のシステムプロンプトやジェイルブレイク（安全制約の回避）関連の情報を集めたものの一つとして公開されたものです。Anthropicは別途、公式のFable 5.1システムプロンプトを公開しており、その内容とは規模が大きく異なります。
何が起きているか
注目すべきは、この275,000字のファイルが単一の「よくできたプロンプト」ではないという点です。報告によれば、ウェブ検索の方針、メモリの保存・プライバシー制限、著作権に配慮した応答、コンピュータ操作、インターフェース表示、ツール選択のルーティング、安全性に関する特殊な振る舞いなど、複数のポリシーが1つのファイルに詰め込まれています。初期の分析では、約46個のツールのスキーマ（定義情報）が含まれているとも報告されています。
この数字はAnthropicによって公式に確認されたものではなく、GitHub上の文書が完全かつ常時有効な内容であるかも独立した検証はされていません。とはいえ、この規模感自体が示しているのは、「システムプロンプト」という概念が、もはや一枚の指示文ではなく、アプリケーション全体を束ねる巨大なバンドルになっているという構造の変化です。
なぜこうなるのか（原因の分解）
開発初期のLLMアプリケーションでは、システムプロンプトは次のようにシンプルでした。
You are a helpful assistant. Answer clearly and concisely.一方、現在の本番運用エージェントは、概念的には次のような複数のコンポーネントを実行時に結合しています。
runtime_context = [
base_behaviour_policy,
product_instructions,
user_preferences,
memory_policy,
available_tool_schemas,
search_policy,
retrieved_evidence,
safety_constraints,
conversation_history,
]これはあくまで構造を示す例ですが、アーキテクチャ上の変化を的確に表しています。モデルはユーザーの発言だけに応答しているのではありません。アプリケーション側が組み立てた一時的な環境の中で動作しており、その環境が「何ができるか」「どのツールが使えるか」「何を記憶していいか」「いつ検索すべきか」「表示形式はどうするか」をすべて指示しています。
これらの要素がモデルが読めるテキスト形式にシリアライズ（直列化）されて連結されると、コンテキスト全体が非常に大きくなります。つまり275,000字という規模は、誰かが巨大なプロンプトエンジニアリングを発見したという話ではなく、プロダクトスタック全体が1つのコンテキストに平坦化された結果と見るべきです。
ツール定義もこの肥大化の主要因です。エージェントにツールを使わせるには、関数名を登録するだけでは済みません。そのツールが何をするか、どの引数を受け取るか、いつ呼び出すべきか、どんな結果を返すか、どんな制約があるかをモデルに理解させる必要があります。ツール数が増えるほど、この定義群も線形以上に肥大化していきます。
自分のプロジェクトが該当するか確認する
この構造的な問題は、Claude固有の話ではありません。OpenAIのFunction Calling、LangChainのToolやAgent、社内向けRAG（検索拡張生成）システムなど、ツール呼び出しを組み込んだLLMアプリケーション全般に共通します。以下の観点で自分のプロジェクトを確認してみてください。
- 実行時にモデルへ送信している最終的なプロンプト（システムメッセージ＋ツール定義＋会話履歴の合計）の文字数、あるいはトークン数を計測しているか
- ツール定義（関数のスキーマ）をコードとは別に一元管理し、バージョン管理できているか
- 安全性の制約（何を答えてはいけないか等）が、プロンプトの文言のみに依存し、アプリケーションコード側の検証を持たないか
- メモリ機能やユーザー設定の反映ロジックが、プロンプトへの文字列連結という形で実装されていないか
確認コマンドとしては、LLM APIを呼ぶ直前のペイロード（送信データ）をログ出力し、wc -m や jq '.messages | tostring | length' のような形で文字数・トークン数の推移を追跡する方法が実用的です。急激な増加が見られた場合、どのコンポーネント（ツール定義かRAGの取得結果か会話履歴か）が原因かを分解して特定できます。
対策の手順
プロンプトの肥大化そのものは避けられない側面もありますが、非機能要件の観点で管理可能にする手順は次の通りです。
1. コンテキスト構成要素の分離: システムプロンプトを「基本方針」「ツール定義」「安全制約」「ユーザー個別設定」などのレイヤーに分け、それぞれ別ファイルまたは別モジュールで管理します。1つの巨大な文字列に手書きで追記していく運用は避けます。
2. 安全性・権限制御をアプリケーション層に移す: プロンプトの指示文だけに頼ってアクセス制御や機密情報の扱いを制御するのはリスクが高い設計です。ツール呼び出しの前後にアプリケーションコードでの検証（許可されたツールか、渡された引数が妥当か）を挟み込みます。
3. プロンプトのサイズ・構成の監視をCI/CDに組み込む: プロンプトテンプレートやツール定義を変更した際、合計トークン数がしきい値を超えたら警告を出す仕組みをテストパイプラインに追加します。これはAPIコストとレイテンシ（応答遅延）の両方に直結する非機能要件です。
4. ツール数が増えた際の再設計を検討する: ツールが十数個を超えてくると、モデルが適切なツールを選択する精度が落ちる傾向が指摘されています。ツールのグルーピングやルーティング層（どのツール群を今回の会話で提示するか事前に絞り込む仕組み）の導入を検討してください。
確認すべき情報源
自社のエージェント実装がどの程度この問題に該当するか判断するには、使用しているLLMベンダーの公式ドキュメントで「システムプロンプト」「ツール利用」「Function Calling」に関するページを確認するのが近道です。Anthropicは公式のシステムプロンプトを公開しているため、自社実装と比較して過剰にロジックをプロンプト側へ寄せていないかを見直す材料になります。OpenAIやGoogleのAgent向けドキュメントでも、ツール定義の設計指針やコンテキスト管理のベストプラクティスが公開されています。
まとめ
275,000字のプロンプトが「漏洩事件」かどうかより、そこから見えるアーキテクチャの現実の方が実務的に重要です。
- 現代のAIエージェントの「システムプロンプト」は、単一の指示文ではなくツール定義・安全制約・メモリ方針を束ねたアプリケーションバンドルになっています
- 安全性やアクセス制御をプロンプトの文言だけに依存させる設計は、監査も検証もしづらい技術的負債です
- 実行時ペイロードの文字数・トークン数を計測し、CI/CDでの監視対象に加えることが最初の一歩になります
- ツール数が増えてきたら、ルーティング層の導入やツール定義の分離管理を検討する価値があります
まずは自分のエージェントが送信している実際のペイロードを一度ログに出し、どのコンポーネントが全体のどれだけを占めているか可視化するところから始めてみてください。