Fortress Token OptimizerはLLM API送信前の冗長プロンプトを11%前後削る

LLM APIの前段に短いプロンプト圧縮APIを挟み、不要な礼儀語や重複表現を削る。
Diallo WestがDEVに投稿した How I Built an API That Cuts LLM Token Costs by 11-22% は、かなり小さいが実務っぽい削減幅を出していた。

記事中の平均削減は5種類のプロンプトで11%。
「Could you please help me」や「I was wondering if」のような会話の緩衝材が多いほど削れ、すでに密な技術プロンプトでは削減幅が小さい。
派手なモデル差し替えではなく、APIを叩く直前の文字列を詰める話だ。

削れるのは礼儀語と重複した指示

Fortress Token Optimizerは、送信前のプロンプトに対してフレーズ圧縮、重複除去、メタ指示の削除、文の短縮をかける。
DEV記事の例では、18トークンの依頼文が14トークンになり、22%削減されていた。

ベンチは大規模ではない。
ただ、削減幅の出方は直感と合っている。

プロンプト種別	削減率
カバーレター依頼のような会話調	23%
デバッグ依頼	8%
学習リソース依頼	10%
ビジネス分析	4%
プロジェクト計画	12%

この表から見ると、Fortressが強いのは「人間に失礼なく頼むための語」を削る場面だ。
一方で、仕様・制約・評価基準が最初から詰まっているプロンプトでは、削れる余地が薄い。

AI APIでキャラクター設定を入れる記事ではsystem promptに口調、禁止語、JSON出力条件をまとめて入れていた。
あの手のプロンプトは「冗長なお願い」ではなく、出力を縛る設定そのものだ。
同じ圧縮を雑に通すと、キャラの語尾や禁止条件のほうが欠けることがある。

プロンプト圧縮APIはモデル切り替えより地味に効く

近いテーマとして、以前 Compresr Context Gateway を見た。
あちらはClaude CodeやCursorのようなエージェントとLLM APIの間にプロキシを挟み、会話履歴やツール出力を圧縮する。
Fortressはもっと手前の通常プロンプト寄りで、npm SDK、Python SDK、VS Code拡張、Webサイト上のデモを前面に出している。

同じ「トークンを減らす」でも、削っている対象が違う。
Compresrは長いログ、ツール出力、古い会話履歴を相手にする。
Fortressはユーザーが今投げる自然文の依頼を相手にする。
RAGやエージェント履歴のような大きい文脈より、チャットUIや社内ツールの入力欄に近い。

npmでは fortress-optimizer が1.0.1で公開されており、説明文も「LLM API costs by 10-20%」という売り方だった。
PyPIにも同じ1.0.1がある。
Webサイト側は平均10〜20%削減、最適化時間68ms、npm・Copilot・VS Code・Slack・Claude Desktop連携を掲げている。
このあたりはFortress側の表示なので、独立検証済みの性能値としては扱わないほうがいい。

11%削減が効く場所と効かない場所

個人の手打ちプロンプトなら、月額で見ると差は小さい。
DEV記事の試算でも、500 prompts/day規模で月数ドルの削減に留まる。

ただし、トークン単位の課金へ寄っている流れとは噛み合う。
OpenAI Codexがトークン従量制へ移行した話では、メッセージ単位ではタスクサイズのばらつきを吸収できず、トークン単位へ寄った構造を見た。
Claude Opus 4.7のトークナイザ更新では、同じ文字列でもトークン数が1.2〜1.45倍になり、実質的な請求額が膨らむケースを見た。

その流れの中では、11%削減は「すごい節約」ではなく、請求の増減を自分で少し制御する層に見える。
高価なモデルを大量に呼ぶバッチ処理、社内チャットボット、問い合わせ分類、レビュー支援のように、似た入力が大量に流れる場所なら数字が積み上がる。
逆に、1回の生成品質や指示遵守が売上に直結する場所では、11%の入力削減より制約の欠落のほうが高くつく。

コンテキストの伸びが遅くなるほうが地味に大きい

トークンが11%減るということは、マルチターンの会話でコンテキストウィンドウの消費速度も11%遅くなる。
コスト削減とは別に、同じウィンドウ長の中でより多くのやり取りを保持できる。

LLMはコンテキストが長くなるほど古い情報への注意が薄れる。
圧縮でコンテキストの膨張を抑えれば、その劣化が始まるタイミングも後ろにずれる。
チャットボットやエージェントのように長いセッションで使う場面では、月数ドルのコスト削減より、会話後半で指示を忘れにくくなるほうが実感として大きい。

圧縮前後の差分をログに残す

導入するなら、削減率だけでは足りない。
圧縮前プロンプト、圧縮後プロンプト、モデル出力、削減率を並べて保存し、失敗時にどの語が消えたかを追える状態にする。

特に危ないのは、否定、条件、数値、固有名詞、コードブロックだ。
「削っても意味が変わらない語」と「短いが意味を支配している語」は見た目だけでは区別しにくい。
「never」「unless」「only」「JSON」「exactly」のような語が落ちると、トークンは減っても出力は壊れる。

Fortressの記事では「コードブロックや意味のある修飾語は削らない」と説明されている。
それでも、本番ワークロードに入れるなら、最初はconservative設定でA/Bを取るのが自然だ。
プロンプト圧縮は入力の前処理なので、失敗してもモデル側のログだけ見ていると原因が見えない。

AIにpleaseと書く人、AIにキレる人

Fortressが消す「Could you please help me」「I was wondering if」はAPI入力としてはトークンの無駄だ。
ただ、人間がAIにpleaseと書くのはトークン単価を計算した結果ではない。

AIにお礼を言うべきかどうかは定期的に話題になる。
お礼を省けばトークンが減るのは事実で、Fortressのベンチマークが数字で示しているとおりだ。
2024年にはSam AltmanがChatGPTユーザーの「please」で電力消費がかさんでいると冗談を言って話題になった。
でも、人間同士のやり取りで「お疲れ様です」「よろしくお願いします」を省くとメールが攻撃的に見えるのと同じで、会話型UIに用件だけ打ち込むのは人間側に抵抗がある。

こういう定型句は敵意のなさを示すためにあるので、相手がAPIだとわかっていても削りにくい。
Fortressのような圧縮APIが送信前に機械的に削るのは、人間の習慣に手を入れずに済むからちょうどいい。

逆方向の話だが、AIにキレる人もかなりいる。
意図した出力が返ってこないと「さっき言ったよな」「何回同じ間違いをするんだ」と打ち込む。
SNSではChatGPTやClaudeに怒鳴っている報告が日常的に流れていて、怒ったところで出力が改善しないのは本人もわかっているのに、やめられない。

Claude Codeはユーザーの怒りを内部で検知していたという話がある。
システムプロンプトにフラストレーションの検出が組み込まれていて、怒っているユーザーにはトーンを変える。
礼儀語は送信前に機械が削れるが、怒りのほうはモデルが受け取って処理している。