Headroom体験記 - Tokenomics Meetup #2

Tokenomics Meetup #2 Headroom体験記 ―検証で見えてきた圧縮効果や削減コスト感 株式会社NTTデータグループ 技術革新統括本部 先進エンジニアリング技術部 アーキテクト推進担当（まかせいのう） © 2026 NTT DATA Japan Corporation

自己紹介 石崎 奏（いしざき そう） Sou Ishizaki SNS icon ■経歴 Microsoft Top Partner Engineer (FY23–FY26, Azure) ■プライベート - 全社技術 Q&A 部隊 - 既婚、息子 (13 才 ), 娘 (4 才 ) - 趣味：楽器演奏 ( 主にギター ), 釣り - 好きな音楽： Progressive, Metal, Jazz ( メンバ ～ リー ダー ～ 相 談 役 ～ 卒 業 ～ 相 談 役復 帰 ) - 各種技術支援、提案・設計書アドバイザー - Microsoft アライアンス活動 - 技統本塾 Azure 塾長、社内コミュニティ活動 • • • • • • • • ■得意技 - Microsoft プラットフォーム技術 OS 、 Active Directory 、 DNS 、 NTP 、 Azure - Linux プラットフォーム技術 OS 、 Samba 、 DNS 、 NTP 、 Docker 、 K8s - トラブルシュート © 2026 NTT DATA Japan Corporation Microsoft MVP for Microsoft Azure (2022-) 2 DR EA M TH EATE R Pa in of Sa lva tion Pink Floyd King Crim son Frank Zapp a Biréli Lagrèn e Yn gwie J. M alm steen B’z

まかせ いの う ® とは？ まかせいのう®は、 性能・非機能のいかなる問題も解決するグローバル対応も可能なアーキテクトサービスです。 ナレッジを集約したエキスパート・アーキテクトが、 お客様の性能や非機能に関する問題・課題を解決いたします。 + 200+ 5,000 Professionals 100% Projects 難易度や複雑化が進む近年も 対応した全ての問題を解決 満足度向上施策の継続実施 業界やシステムを問わず 過去十数年間で５,0００超の プロジェクトに対応 200名を超える エキスパート・アーキテクトが あらゆる状況に対応 処理量 100,000 TPS 高SLAへの対応実績 © 2026 NTT DATA Japan Corporation 問題解決率 200+ Projects グローバル案件への対応実績

Tokenomics “最適化” フェーズで Headroom を検証してみた © 2026 NTT DATA Japan Corporation 4 4

Tokenomicsとは？ Tokenを「減らす」活動ではなく、AIコストとValueをつなぎ、利用を持続可能にスケールさせる IMPROVE KNOW DECIDE 01 V ISIBIL ITY 02 O PT IMIZ AT ION 03 V ALUE 可視化 最適化 ビジネス価値 まず、どこでTokenが 使われているかを知る 同じValueを、より効率的な Token消費で実現する WHO Team / User MODEL モデル選択 VALUE 品質 / 生産性 / 売上 WHAT Use Case / Agent INPUT Prompt / Context KPI Cost HOW Model / Token / Cost EFFICIENCY DECIDE 投資 / 最適化判断 「何が起きている？」を データで会話できる状態へ × Tokenを減らすことが目的 Cache / 圧縮 そのToken消費は、 価値につながっているかを見る 「削れるTokenは？」ではなく 「無駄なく届けるには？」 ではなく ✓ Outcome 最終的に見るのは 「Tokenの量」より「Value / Token」 Value / Token を高めながら、AI活用をスケールさせる Tokenomics のゴール © 2026 NTT DATA Japan Corporation 5

最適化手法検証テーマの選択 リサーチした24手法を6分類 → 初回PoC候補を比較 → 「入力圧縮」を最初の検証対象に STEP 1 コスト削減の方策を広く洗い出す 入力の削減 指示とツール 候補 変更する部分 メリット／デメリット 今回 指示整理／Chronicle／自動最適化 入力圧縮 (Headroom) モデルに渡す 入力データ ○ユーザーは意識しなくて良い 選定 モデル ルーティング 要求ごとに 使うモデル ○ユーザーは意識しなくて良い ×ルーティングの選択肢が多岐にわ たる 次候補 指示改善 / Chronicle 依頼や固定指示 ×ユーザーでの改善行為が必要 後続 プロンプト キャッシュ 共通入力の 再利用方法 ×入出力トレース・詳細調査が必要 後続 出力制御／推論量／コード化／ル ープ制御 再利用・モデル キャッシュ／小型モデル／ルーテ ィング 運用・契約 初回PoC候補を「変える場所」と検証しやすさで比較 圧縮／取得元の絞り込み／RAG／ 履歴整理 呼出し・生成 実行・提供形態 STEP 2 バッチ／蒸留／提供先比較／自社 運用 推論効率／容量適正化／予算制御 ／ライセンス 前提：冗長なログ・JSONなど、ツール出力が多い従量課金の業務を想定 まずは「どこで費用が発生しているか」に合わせて、候補を 広く持つ © 2026 NTT DATA Japan Corporation 選定理由 大きなユーザー操作なく、入力圧縮の効果を測りやすい → Headroomから検証 6

Headroom アーキテクチャ ― LLM入力を圧縮・キャッシュ最適化するパイプライン アプリからのプロンプト／ツール出力／ログ／ファイルを、入口層 → 6段のパイプライン → LLM Provider → レスポンス処理 の順に流す I NPUT アプリ ユーザー アプリ層 Claude Code HE A DR OO M PIPE LI NE （S tag e 1–6） 入口層 4 圧縮 5 CCR保存 6 送信前 キャッシュ整合 ルーティング 圧縮フェーズ CCR保存 送信前検査 4 entry modes INPUT_RECEIVED INPUT_CACHED INPUT_ROUTED INPUT_COMPRESSE D INPUT_REMEMBERE D PRE_SEND Proxy モード • メッセージを構造化 ブロック（Block） に解析 • タイプ別にトークン 数をカウント SDK モード compress() • 無駄な信号を検出 （大きなJSON・ HTML・Base64 等） Cache Aligner Content Router • 動的コンテンツ（日付 ・UUID・トークン）を 抽出 • コンテンツタイプを 検出 • プレフィックスを安定化 し、プロバイダキャッシュ のヒット率を最適化 • 可変部分をメッセージ 末尾へ移動 MCP モード • 対応するコンプレッ サーを選択 SmartCrusher JSONデータ｜70–95%圧縮 CodeCompressor ASTコード｜署名を保持 JSON Kompress-v2 テキ ストML｜オプション • オリジナルを圧縮し、 ローカルキャッシュに 保存（hashkeyed） • 検索ツール headroom_retri eve を注入 • 圧縮後のメッセー ジ形式を検証 LLM Provider RESPONSE 処理 Anthropic CCRツール呼び出しを検 出？ cache_control • システムメッセージ に検索指示を注 入 90% 節約 • メトリクスを記録 OpenAI • 「詳細が必要なら retrieve(hash) を 呼ぶ」 カスタムコード Text 50% 節約 headroom wrap claude Diff 圧縮戦略は下段参照 ▼ Stage 4 の圧縮戦略 ループは下段 ▼ その まま 返却 ポスト処理 • SQLiteに節約メトリクスを 記録 75% 節約 Log 自動retrieve→会話継続 →最終応答 いいえ CachedContent パターン認識 Wrap モード はい Prefixキャッシュ Google Log/Diff Compressor レスポンス LLM 呼び出し Code headroom_compress prompts / tool outputs / logs / files 3 ルート 入力受信 Cursor LangChain 2 キャッシュ 入口層 headroom proxy Codex 1 受信 L LM 呼び 出し ／ 応答 • フィードバックを更新（将 来の圧縮改善） ※ キャッシュ節約率 CCR（Compress-Cache-Retrieve）ループ ― 圧縮しても情報を失わない仕組み TIME_SERIES CLUSTER TOP_N SMART_SAMPLE 分散スパイクを検出し、変 化点を保持 類似ログをクラスタ化し、各 1–2件を保持 検索結果をスコア順に上 位N件保持 統計サンプリング＋定数抽 出 オリジナル 圧縮 ローカル キャッシュ保存 LLMが retrieve呼出 Stage 5 で hash-keyed 保存 ／ Response 処理で retrieve(hash) により原文を復元 © 2026 NTT DATA Japan Corporation ※ キャッシュ節約率の出典：Cache Optimization | Headroom 7 自動retrieve →会話継続 最終応答

• https://docs.headroomlabs.ai/docs/cache-optimization

Headroom検証の適用モデルケース：技術問い合わせQ&Aへの適用 テキストベースの技術問い合わせサービスのQ&A文書を対象に、AI（Codex）による回答生成の経路へHeadroomを組み込んで検証 Q 質問 （入力） 質問文サンプル AI 回答生成 （Codex） A 回答 （出力） 回答文サンプル Codex ■質問対象の OS : Windows Server 2022 ■質問本文 : ADサーバのドメインに参加していればOSデフォルトの設定 でもADサーバと時刻同期するものと認識していたのですが、 その通り動作しませんでした。環境としましてはAWS上の ADサーバとメンバーサーバとなります。 質問を受けて回答生成を依頼 そこでローカルグループポリシーにて以下の通り設定しました。 質問文のトークンを削減（強度0〜1） ＜中略＞ 回答を簡潔に生成させる指示を付与 ここに組み込み Headroom 入力圧縮 output_shaper 結論から申し上げますと、貴担当にて実施したグループポリ シーの設定を適用することで、時刻同期のソースとして、ド メインコントローラを指定することが可能であると認識してお ります。 また、時刻同期のソースとして、ドメインコントローラを指定 するには、貴担当にて実施したグループポリシーを使用する 方法のほかに、w32tm コマンドを実行する方法、レジスト リを設定する方法もございます。 ＜中略＞ このように設定し、初めてADサーバと同期したのですが、こ の設定で正しいでしょうか。 この設定で問題がないか、不足している点ないかなどの観 点でご教授頂ければ幸いです。 LLM 回答を生成して返却 何卒宜しくお願い致します。 © 2026 NTT DATA Japan Corporation 8 本回答を参考に、ドメイン参加時のクライアントのレジストリ や設定から、上記の状況に該当するか確認する等、本件 の今後の対応をご検討ください。

Headroom検証①：入力の性質で圧縮効果は大きく変わる CPU実行｜技術問い合わせ100件を「質問のみ」と「質問＋回答」で圧縮比較 質問のみ（重要情報が集中） 約10% ファイル別中央値10.0% トークン合計ベース14.4% • • • トークン数（合計） 4,045 → 3,464 平均圧縮時間 2.0秒（1.1〜3.4） バージョン・構成・エラー文・制約条件など、削れない情報が大半 圧縮率0%が11件。冗長表現がほぼ無い＝正常な挙動 質問意図・重要条件は比較的よく保持 質問＋回答やりとり（冗長な文章が多い） 約58% 平均圧縮率57.7% 最大76.8%（#57992） • • トークン数（合計） 81,749 → 34,649 平均圧縮時間 6.8秒（1.5〜20.5） 複数やりとり間の重複、挨拶・定型文、装飾記号、冗長な敬語等が 削減対象 人が読むと文章が断片化し、回答の境界が不明瞭になる場合あり 補足：CPU実行では圧縮自体に数秒の処理時間がかかる 質問のみで平均2.0秒、全文では平均6.8秒 (最大20.5秒)。LLMの応答待ちに上乗せされるため、ユーザー体験への影響が気になるところ。 © 2026 NTT DATA Japan Corporation

Headroom検証②：GPUによる高速化と適用の考え方 100ファイル × 閾値5段階 × 各3回（CPU／GPU） CPUの処理時間懸念 → GPUで大幅改善 CPUでは1件あたり数秒を要していたため、GPUを適用して検証。0.2秒程度に短縮され、大きく改善。圧縮結果はCPU／GPU間で完全一致。 平均 4.28秒 → 0.18秒 4.28秒 0.18秒 1件あたり平均圧縮時間（CPU→GPU） P95 最大 7.96秒 0.32秒 16.07秒 0.52秒 CPU (t3.xlarge) GPU (g4dn.xlarge / T4) GPUは「高速化が必須」な用途にのみ適用か • 数分かかる処理なら、圧縮の数秒（CPU平均4.3秒）は許容範囲かもしれない • 対話型など応答速度が重要な用途に絞ってGPUを使い、費用対効果で選ぶ © 2026 NTT DATA Japan Corporation 約24倍 高速化（累積時間比23.9倍）

Headroom検証③：圧縮強度ごとの圧縮率と削減内容 100件 × 圧縮強度5段階｜圧縮率と、Originalからの差分（どこを削ったか）を比較 前提 圧縮強度（スコア閾値）は 0 ～ 1 で設定。値が大きいほど強く圧縮する ① 圧縮強度別の圧縮率（質問のみ文章） 11% 11% 0.1 0.3 0.5 15% 0.7 0.9 圧縮強度 ※LLM入力トークン（100件合計、Original比） 0.1〜0.5は約11%で横ばい → 0.7で約15% → 0.9で約46%に急増 強度 主な削減・整理の内容 0.1 改行・空行・字下げを整理。一部の挨拶・補足文を削除 本文は概ね維持（67件は空白以外一 致） 0.3 0.1に加え、記号（「:」「>」）や英語の短い語を削除 0.1とほぼ同じ（差分は24件） 0.5 区切り記号を広く削除。製品名・エラー文の一部も短縮 名称・構文が変わる箇所が出始める 0.7 見出しや製品名の語を削除。補足・説明も短縮 OS名や実装条件が欠落する例あり 0.9 見出し・環境説明・質問本文を大幅に削除。断片や数値 が残る 質問全体が消える例あり ※Originalと各強度の圧縮結果の差分を観察して整理 0.9 は非常に圧縮される（約46%）が、質問本文ごと消える例も 圧縮率だけでは良し悪しを判断できない。強く圧縮した分、アウトプット（回答）の品質が落ちていないかの検証が必要 © 2026 NTT DATA Japan Corporation 1 強い ② 各圧縮強度で手を加えていた内容 46% 11% 0 弱い 情報への影響

Headroom検証④：回答が破綻しやすい入力圧縮設定 Originalの回答と比較し最初に品質が破綻した設定値を判定 ① 最初に回答が破綻した設定値 ② 主な事例 （圧縮が強いほど、重要な情報が削除される） 26件 事例① #58195（製品機能 / temp） Original （圧縮なし） SQL Server 2022のmax/min server memoryと実メモリ利用量の仕様確認 ▼ 0.9 「SQL 2022」のみ 878 B → 8 B（99.09%削減） 本文と質問意図 が消える 事例② #51794（トラシュー） 3件 0.1 3件 1件 Original （圧縮なし） 0件 0.3 0.5 0.7 0.9 0.9 最初に破綻した圧縮強度 ※縦軸：チケット数。破綻なし（67件）はグラフから除外 100件中 33件で破綻、うち26件（約8割）は 0.9 で初めて破綻 0.1／0.3 の4件は単発的な破綻で、より強い設定では回答が回復 「OS 2016 OS: server2016」 568 B → 22 B（96.13%削減） Original （圧縮なし） 接続数の履歴を蓄積・保管したい。pg_stat_activityのSQL。簡易な方法を希望 ▼ 保管要件、SQL、簡易な方法の希望を削除 入力が自然言語中心の場合、0.3 / 0.5 の設定で回答品質を維持しつつ十分に圧縮できる。 入力の圧縮率は 0.3 と 0.5 で大きな差はないため、導入時は 0.3 を検討する。 © 2026 NTT DATA Japan Corporation エラー症状と 質問本文が消える 事例③ #51022（製品機能） 0.1以降 結論 スナップイン作成エラー。サーバマネージャも起動不能。原因と対処を質問 ▼ 回答に必要な 条件が不足

Headroom検証⑤：出力圧縮設定機能の有効化による回答品質への影響 Headroomには出力トークンを圧縮する指示等を埋め込む設定が存在。こちらの機能の有効化による回答品質への影響を調査。 ① 出力された回答を比較し影響を確認 5 / 600件 ② 「影響あり」の具体例 技術回答の消失（3件） 設定 致命的な影響あり Original 0 / 100 0.1 3 / 100 0.3 1 / 100 同一チケット・同一入力圧縮設定で 出力圧縮機能の有効／無効の 回答を比較 0.5 0 / 100 0.7 1 / 100 100チケット × 6設定 0.9 0 / 100 判定基準：致命的な欠落・誤結論・要求要件外れのみ「影響あり」 有効化を前向きに検討できる • 影響ありは600件中5件と限定的 • 結論逆転は致命的になり得るため、本番では出力の監視・サンプリング評価を継続 © 2026 NTT DATA Japan Corporation 有効側は「調査結果を提示できない」等の謝罪や問い合わせ文 作成の案内のみになり、技術的な中身が消失 結論の逆転（1件） 無効側「ADスキーマ拡張が必要」→ 有効側「拡張不要」と逆の 結論。他設定の有効側回答とも矛盾 要求要件からの逸脱（1件） 「翌週同曜日に上書き」の要件に対し、有効側は日別ファイル＋ 世代削除に転換し要件への直接回答がなくなる

Headroom検証⑥：入力・出力別のトークン削減とコスト効果 Original と 圧縮強度 0.3 を output_shaper 有無で比較。平均トークンをGPT-6 Sol単価で換算 ① Original と 0.3 の比較（1,000件あたりコスト） 入力 ② 本ケースでのコストは出力側が支配的 出力 合計コスト 圧縮強度 output_ shaper トークン （削減率） 削減額 トークン （削減率） 削減額 /1,000件 削減率 Original 無効 364 ― 2,806 ― $28.79 基準 約97% 有効 364 ― 2,661 (▲5.2%) $1.45 $27.34 ▲5.0% （単価5倍 × 量 約8倍） 無効 324 (▲11.1%) $0.08 2,666 (▲5.0%) $1.39 $27.31 ▲5.1% 有効 324 (▲11.1%) $0.08 2,430 (▲13.4%) $3.76 $24.94 ▲13.4% 0.3 ▲は基準（Original・output_shaper無効）比の削減。単価：GPT-6 Sol 入力$2.00／出力$10.00（1Mトークンあたり） 入力圧縮（0.3）のみの効果 output_shaper 併用 合計 ▲5.1% 合計 ▲13.4% コスト換算では入力トークン部は $0.08／1,000件 に留まる 削減額の大半は出力側（$3.76） 結論 基準時の合計コストに 占める出力の割合 ■ 出力 97.5% ■ 入力 2.5% • 入力圧縮（0.1〜0.7）は入力を11〜15%削るが、コスト換算では $0.1/1,000件程度 • output_shaperは同じ閾値で出力を約3〜9%追加削減 今回は出力トークンの割合が大きい（入力：出力 ≒ 1：8）ワークロードだったため、入力圧縮のコスト効果は限定的 導入時は、実際のワークロードでの入力・出力トークン比率を確認した上で取り組むべき © 2026 NTT DATA Japan Corporation