---
title: Headroom体験記 - Tokenomics Meetup #2
tags:  #finops #tokenomics #azure #headroom  
author: [sou (08thse)](https://www.docswell.com/user/08thse)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/DEYDVV6MEM.jpg?width=480
description: Tokenomics Meetup#2 (https://tokenomics.connpass.com/event/409950/) での登壇資料です。
published: November 12, 26
canonical: https://www.docswell.com/s/08thse/ZE13E1-2026-11-12-202512
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/DEYDVV6MEM.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/VJN6MMZ3J8.jpg)

自己紹介
石崎 奏（いしざき そう）
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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/YE9LNNZP73.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GE8XKK1XJD.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/LEL8ZZQN7R.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4JM6VV1QEW.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/PJRP22LKE9.jpg)

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
→会話継続
最終応答


# Page. 8

![Page Image](https://bcdn.docswell.com/page/PEX3DDW5JX.jpg)

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
本回答を参考に、ドメイン参加時のクライアントのレジストリ
や設定から、上記の状況に該当するか確認する等、本件
の今後の対応をご検討ください。


# Page. 9

![Page Image](https://bcdn.docswell.com/page/3EKYXXVRJD.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/L73955MG75.jpg)

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倍）


# Page. 11

![Page Image](https://bcdn.docswell.com/page/87DGDD6N7G.jpg)

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 弱い
情報への影響


# Page. 12

![Page Image](https://bcdn.docswell.com/page/VJP3XXYNE8.jpg)

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以降
結論
スナップイン作成エラー。サーバマネージャも起動不能。原因と対処を質問
▼
回答に必要な
条件が不足


# Page. 13

![Page Image](https://bcdn.docswell.com/page/2EV4LLGYJQ.jpg)

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件）
「翌週同曜日に上書き」の要件に対し、有効側は日別ファイル＋
世代削除に転換し要件への直接回答がなくなる


# Page. 14

![Page Image](https://bcdn.docswell.com/page/57G1XX8WEL.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/4EQD889QJP.jpg)