プロンプトを事前に詰め込む AI がスケールしない理由

プロンプトエンジニアリングは、1 デプロイメントで機能する戦略です。スケールした瞬間に破綻します。

30 KB のシステムプロンプトで 1 コール約 0.50 ドル。デプロイメント 100 で 50 ドル、1,000 で 500 ドル——ビジネスロジックが動く前の、コンテキスト読み込みだけで。コストカーブではなく、コストの壁です。

コストが膨らむのは症状です。本当の問題は構造にあります。

ルールを追加するたびに、前のルールが使いにくくなります。「返金は 30 日以内」「エンタープライズは優先ルーティング」「JA ロケールでは通貨 X を表示しない」——47 番目のルールは AI を賢くせず、46 番目を曖昧にします。ルールは矛盾し、4 万トークンの中で AI はシグナルを見失います。

さらに根深い問題があります。プロンプトはステートレスです。請求書 1 枚の処理でも、AI はロケールポリシーから返金ルール・オンボーディング手順まで全部読み込みます。このリクエストに関係のないルールに、毎回アテンションを使い続けます。

圧縮で対処するチームがほとんどです——プロンプトを短くし、ルールを要約する。1 デプロイサイクルは乗り越えられます。次の四半期、プロンプトはまた肥大化しています。

断ち切るのは、より賢い圧縮ではありません。「誰がコンテキストを持つか」という前提を変えることです。AI が必要なものだけを取りに行けるなら、システムプロンプトは知識の倉庫ではなく構造の骨格になります。次章では、その転換を可能にするオブジェクトの話をします——型付きオブジェクトが人間と AI の契約になる仕組みを。

前章の結論を一行で言うと、プロンプトにルールを詰め込む方法はスケールで崩壊します。解決策はより賢いプロンプトではなく、別の契約です。

OS iXanagi では、AI がオファーを判断するとき、指示文ではなくスキーマを宣言します。「audience_profile（segment / jobs_to_be_done / pain_points / decision_criteria の 4 フィールド）と company_mission（statement / positioning の 2 フィールド）が必要です」。

この宣言が契約であり、型定義がルールそのものです。

システムは宣言を受け取り、オブジェクトを取得し、要求された形状で返します。AI は「ブランドトーンに沿う」という抽象的な指示を解釈しません。brand_profile.tone_of_voice: "clear and direct" という構造値を受け取り、具体的なフィールドに適用します。

結果として 3 つのことが起きます。

ペイロードが約 80% 縮小します。 800 語のポリシー文書の代わりに 6 フィールドを要求すると、コンテキストウィンドウはシグナルを運びます。トークン予算はポリシーの暗唱ではなく推論に使われます。

推論が決定論的になります。 audience.segment = "DevOps リード" を受け取ったステップは毎回同じ文脈で推論します。プロンプトの末尾で何かが押しつぶされるブレがありません。

監査証跡が読めます。 出力がおかしいとき、600 語のプロンプトをデバッグしません。スキーマ宣言と取得されたオブジェクト値を確認します。ワークフロー実行のたびに、何が取得され、何が返されたかが記録されます。

「50 のルールを覚えておいてください」から「これらの 6 フィールドが必要です」への転換が、AI の推論をスケールで予測可能にします。型定義はルールを記述しません ― 型定義がルールです。

次章では、AI がそのスキーマを静的な設定ではなく実行時に宣言する仕組み ― Tool-use ― を見ます。

AIに「全部を事前に渡す」のをやめたとき、何が変わるか。それがこの章の命題です。

従来の統合では、プロンプトにすべてを詰め込みます。顧客ルール、価格体系、条件——事前に書かれ、AIはそれを読んで実行します。ルールが3ヶ月前のものでも、AIは従います。

Tool-useはこれを逆転させます。AIはタスクとツールセットを受け取り、実行中に「このセグメントの顧客プロファイルをください」とツールを呼びます。結果を読んで判断します。事前の仮定ではなく、自分で調べてから動きます。

worker はあなたが書いたことを実行する。参加者はあなたがまだ書いていないことを調べる。

OS iXanagiではこれをOfficerモデルと呼びます。AIのOfficerは3つのモードで動きます: 調査（データを取りに行く）、提案（下書きを作る）、エスカレート（ルールが状況に合わないとき人間に委ねる）。

3番目が最も省かれます。「エンタープライズには20%割引を適用」というルールがある。コンプライアンス制限の地域でも、先週ポリシーが変わっていても、workerは適用します。参加者はルールと現実が合わないとき、エスカレートします。

この違いは知性ではなく権限の問題です。Tool-useはAIに「もう少し情報が必要です」と言う権限を与えます。

その権限をどう設計するか——すべてのAIステップを際限のない対話にしないために——キャッシュアーキテクチャが答えを持っています。

Pull 型への移行を検討すると、決まって同じ懸念が来ます。「ステップごとにブランドコンテキストを取りに行ったら、コストが跳ね上がらないか」。

正当な問いです。12 ステップのワークフローが毎回ブランドボイスを引き出せば、単一のシステムプロンプトより大幅に多いトークンを消費します。計算だけ見ればビジネスケースが成立しません。

答えは 3 層キャッシュです。応急処置ではなく、アーキテクチャの核心として設計されています。

Layer 1: run-scope キャッシュ。 1 回のワークフロー実行内では、ツール名とパラメータの組み合わせで呼び出し結果をメモリにキャッシュします。Step 3 が取得したブランドボイスを Step 7 が再要求しても、データベースに届きません。1 ミリ秒以下で解決されます。同じブランド、同じ呼び出し、同じ実行 — 再利用が自動で効きます。

Layer 2: 永続キャッシュ。 複数回の実行をまたいで、キャッシュキーは (tenant_id, brand_key, object_key, attribute, source_version) になります。Haiku（圧縮専用の軽量モデル）がブランド属性を圧縮し、workflow_knowledge_compressions に保存します。実測値: 1,198 トークン → 34、1,953 トークン → 33（平均 97% 削減）。version ハッシュで Knowledge Object の変更を自動検知し、無効化も自動です。

Layer 3: brand-aware Bridge。 Bridge サーバは brand CLAUDE.md をセッション開始時に一度読み込み、30 分 TTL でメモリに保持します。Anthropic の prompt cache が cache_control: ephemeral でシステムプロンプトをマークし、5 分以内の連続呼び出しで 90% 割引が効きます。7 章を並列生成しても全額を払うのは最初の 1 回だけです。

「このコンテキストを覚えておいて」と書く必要はありません。ブランドガイドラインをプロンプトに貼り直す必要もありません。アーキテクチャが透明に処理し、量が増えるほど単価が下がる構造になっています。

このコスト構造の変化が何を可能にするか。それが次章のテーマです。

Push型の限界は、デプロイした瞬間に決まります。

キャンペーン中に「このセグメントは価格よりアーキテクチャ図を重視している」と判明しても、今日のAIにその知識を届ける手段はありません。チケット→開発→QA→次リリース。今動いているAIは、その学びを知らないまま動き続けます。

Pull型は、この天井を取り払います。

AIが知識の空白に当たると、システムはその場でナレッジベースを参照します。チームが空白を埋めれば、次のAI呼び出しは自動的にそれを参照します。コード変更なし、デプロイなし。知識が増えた瞬間、AIの判断が変わります。

これがPush型には作れない、複利の成長ループです。

マーケティングがキャンペーンを動かし、何が効いたか記録します。その学びをナレッジベースに書き込むと、次のAI提案がそれを参照します。精度が上がり、また信号が溜まります。ループが回るたびに、判断が洗練されます。

Push型チームは代わりに、想定シナリオを事前にルール化します。予測できた範囲では機能します。しかし想定外が起きた瞬間—判断が最も必要な場面で—ルールは沈黙します。

Pull型に必要なのは予測力ではなく、観察と記録の習慣です。

OS iXanagiは使うほど強くなります。6か月稼働させたシステムは、6か月分の学習と例外処理を蓄積したナレッジベースを持ちます。チームが経験を積むほど、ツールが賢くなる。Push型が施錠し続けているドアは、そこにあります。