プロンプトの書き方が請求書に出る仕組み
Updated September 1, 2026 · first published September 1, 2026
プロンプトは設定ファイルと同じように太ります。誰かが不具合対策の指示を足し、別の誰かが例を足し、三人目がその理由を説明する段落を足す。何も削られません — 削ると誰も再現できないバグが戻るかもしれないからです。半年後、システムプロンプトは 3,000 トークンになり、そのうちどの 200 トークンが効いているのか誰も言えません。
なぜ積み上がるのか
タスクごとに変動する出力と違い、プロンプトのオーバーヘッドは毎リクエスト、同じ量だけ、永久に支払われます。月 1,000 万回の機能で 1,000 トークンの無駄は、月 100 億トークンの純粋な書式代です。
マルチターンではさらに悪化します。システムプロンプトは毎ターン再送されるので、コストはリクエスト数ではなくターン数に比例します。エージェントループでは、1 回のユーザー操作で十数回の呼び出しが走り、同じ肥大した前置きが十数回課金されます。
本当に無駄なもの
丁寧語ではありません。重いのは、同じ規則を三通りに言い換えた重複指示、もう必要のない世代向けに書かれた防御的な定型文、異なるケースを覆わず重複しているだけの例示、そしてモデルではなくファイルを読む人間に向けた説明です。
実務では三つ目が最大です。few-shot はトークン単価が高く、5 件が 2 件で足りるかを見直すチームは多くありません。
予算のあるコードとして扱う
固定プロンプトが平均リクエストに占める割合を測ってください。半分を超えるならスタイルではなくコストの問題です。安定部分を先頭に置けばキャッシュが効き、残りの肥大も安くなります。そのうえでアブレーション — 1 ブロック削って評価を回し、品質が保てれば削除を残す。評価基盤なしの削減は当て推量で、顧客が見つける品質劣化は節約したトークンより高くつきます。
Related
Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →