私たちが始めたTokenomics実践 - Japan FinOps Community Gathering #2

Japan FinOps Community Gathering #2 私たちが始めたTokenomics実践 ―AI環境の構築と運用、AzureOpenAI Token可視化の実践 株式会社NTTデータグループ 技術革新統括本部 先進エンジニアリング技術部 アーキテクト推進担当（まかせいのう） © 2026 NTT DATA Japan Corporation

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

自己紹介 石崎 奏（いしざき そう） Sou Ishizaki SNS icon ■経歴 Microsoft Top Partner Engineer (FY23–FY26, Azure) ■プライベート - 全社技術 Q&A 部隊 - 既婚、息子 (13 才 ), 娘 (3 才 ) - 趣味：楽器演奏 ( 主にギター ), 釣り - 好きな音楽： 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-) 3 DREAM THEATER Pain of Salvation Pink Floyd King Crimson Frank Zappa Biréli Lagrène Yngwie J. Malmsteen B’z

AIのコスト最適化 × FinOps ＝ Tokenomics FinOps の考え方を参考にできる！ © 2026 NTT DATA Japan Corporation 4 4

FinOps から Tokenomics へ AIコスト構造を見ていると、FinOpsで見てきた「問い」がそのまま現れる 生成AIの利用拡大 Token / Cost が増える 「誰が・何に・いくら・どんな価値？」を考え始める CLOUD FinOps AI クラウドコスト 01 誰が使った？ Account / Team 02 何に使った？ Service / Workload 03 いくら使った？ 04 適切なサービス？ 05 価値は出ている？ TO K EN O M I C S © 2026 NTT DATA Japan Corporation ＝ FinOpsの考え方 Tokenomics 同じ構造 AI / Token コスト 01 誰が使った？ 02 どのユースケース？ Use Case / Agent Usage / Cost 03 何Token / いくら？ Token / Cost Rightsizing 04 適切なモデル？ Model / Context 05 Tokenに見合うValue？ Token Cost Costだけでなく Valueまで見る Value FinOpsの考え方を、AI時代のコスト単位「Token」まで降ろして考える 5 User / Team Value

Tokenomicsとは？ Tokenを「減らす」活動ではなく、AIコストとValueをつなぎ、利用を持続可能にスケールさせる IMPROVE KNOW DECIDE 01 VISIBILITY 02 OPTIMIZATION 03 VALUE 可視化 最適化 ビジネス価値 まず、どこで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 6

Tokenomicsを深掘りする公開記事 NTTデータ DATA INSIGHT｜Tokenomicsを知る2本の記事 01 Tokenomics－忍び寄るAI投資バブル崩壊の危機を乗り越えるには 2026.09.03 トークン消費とAIコストの急増を踏まえ、企業の実例と今日から始める対策を紹介。 02 Tokenomicsで考えるAI時代のコストと価値－生成AIのコスト管理はどう変わるのか？－ 2026.09.24 FinOpsとの関係を整理し、AI固有のコスト・価値の捉え方と実践の始め方を解説。 詳しくは 「NTTDATA INSIGHTS Tokenomics」で検索 © 2026 NTT DATA Japan Corporation 7

• https://www.nttdata.com/jp/ja/trends/data-insight/2026/0903/
• https://www.nttdata.com/jp/ja/trends/data-insight/2026/0924/

私たちが始めたTokenomics実践 Workbookをつくるまでの3ステップと、日次監視の実装 © 2026 NTT DATA Japan Corporation 8 8

基盤構築 トークン爆発 ～ AI基盤を構築した経緯 可視化実装 運用改善・今後 拡大したAI利用が「トークン爆発」を起こし、社内無償利用の予算上限に直面。AIを使い続けるため、自前でのAI基盤を構築した 01 2025年の状況 02 2026年の状況（予算上限） 03 構築したこと AI活用の拡大 ― トークン消費が急増 無償API枠の逼迫と継続手段の検討 Azure APIM ＋ Azure OpenAI の利用基盤 • まかせいのうとして、ChatGPT・Codex・Copilotを中心 にAI利用を積極推進 4月 事務局より「現ペースではFY2026上期中に年 間APIクレジットを使い切る見込み」と連絡 5月 OpenAI API無償利用枠の利用停止の案内。 継続利用の方法を早急に決める必要が発生 APIMの組み込みポリシーで PJ・ユーザー別のトークン上限管理を実現 • OpenAI APIも利用対象・利用量を大きく制限せずに 活用 • 利用拡大と高性能モデルの利用に伴いコストが増加 参考：GPTのトークン単価（入力 / 出力） モデル 入力 出力 GPT-5.6 Sol $4.00 $20.00 GPT-5.6 Terra $2.00 $12.00 GPT-5.6 Luna $0.20 $1.20 想定より早く 利用上限に達する可能性が顕在化 判断 担当内アンケートでCodexを含むAI環境の継 続利用が必要と判断。APIの有償契約を検討し つつ、Enterprise版の利用を推進 • llm-token-limitでPJ／ユーザー／APIキー単位に 上限設定。超過時は429を返却 • Entra ID・Managed Identity・RBACと連携した セキュアな構成 利用枠がトークンで管理され、 新たな組織運用上の課題が発生 • ログ・メトリクスをAzure Monitorへ送信し、利用量を 一元管理 AIを止めずに使い続けるため、「トークンを統制しながら自由に使える」AI基盤へ © 2026 NTT DATA Japan Corporation 9

基盤構築 背景・課題 可視化実装 運用改善・今後 AIが使えるようになった一方で、Azure OpenAIの利用拡大に対し、利用量・クォータを継続的に把握する仕組みが不足していた 背景 課題 01 複数のProduct・User・ModelからAzure OpenAIを利用 01 Product・User・Model単位の利用状況を横断的に把握しづらい 複数のサービス・部門・ユーザーが、さまざまなモデルを利用している 複数の切り口での利用状況を一元的に確認できる手段がない 02 クォータ消化状況や月末超過リスクを日常的に把握しづらい 02 利用量の増加に伴い、トークン消費量の継続的な把握が重要に 各Productのクォータ残量や消化ペースを継続的に確認しづらい 生成AIの本格利用により、利用量が増加し、コスト・クォータ管理の必要性が高まった 03 特定Userの急激な利用増加に気づきにくい 03 APIM側ではProductごとに月間トークンクォータを設定している 一部のユーザーの利用が急増しても、リアルタイムでの検知が難しい APIMで各Productに月間クォータを設定し、利用を制御している 04 運用者が能動的に見に行かなければ変化に気づけない 定期的にポータルやログを確認しないと、利用状況の変化を把握できない 利用構成のイメージ Product Product A （例：社内システム） User Model User A GPT-5 （例：企画部） 現状の運用イメージ 各画面を個別に確認 （Azureポータル、APIM など） Azure OpenAI Product B （例：業務アプリ） User B （例：開発部） GPT-4.1 複数の切り口で集計 （Product / User / Model） Product C （例：分析基盤） User C （例：運用部） GPT-4o mini APIM 運用者 （クォータ制御） ⋮ ⋮ © 2026 NTT DATA Japan Corporation （手動で確認） ⋮ 10 ! 異常や超過リスクに気づきにくい （リアルタイムでの把握が困難） 利用状況を 一目で把握できず、 見に行かないと 分からない状態

今回の取り組み｜4つの課題に対し、2つの仕組みで対応 基盤構築 可視化実装 横断的な利用状況の把握・分析はWorkbook、日常的な利用変化や超過リスクの早期検知はSlack通知 課題 01 Product・User・Model単位の利用状況を 横断的に把握しづらい Azure Workbook 複数の切り口での利用状況を一元的に確認できる手段がない 02 クォータ消化状況や月末超過リスクを日常的 に把握しづらい Product・User・Model単位で利用量・推移・クォータ消化率を可視化し、 任意の期間で分析 詳細分析 主な用途 任意期間の分析 ドリルダウン 各Productのクォータ残量や消化ペースを継続的に確認しづらい 03 特定Userの急激な利用増加に気づきにくい 前営業日の利用量・クォータ・急増Userを判定し、 指定のSlackチャンネルへ日次通知 日次監視 一部のユーザーの利用が急増しても、リアルタイムでの検知が 難しい 04 運用者が能動的に見に行かなければ 変化に気づけない 定期的にポータルやログを確認しないと、利用状況の変化を 把握できない © 2026 NTT DATA Japan Corporation → Logic Apps → Slack 主な用途 日次の自動通知 11 早期検知 運用改善・今後

STEP1 利用データの取得・蓄積構成 基盤構築 可視化実装 運用改善・今後 APIMで取得したトークン利用情報をApplication Insightsに蓄積し、Workbookの分析データとして利用 利用者 / アプリケーション リクエストを転送 APIリクエスト (生成AIの利用) Product / User (社内アプリ・ツールなど) Azure OpenAI / Microsoft Foundry Azure API Management（APIM） APIM Policy（Inbound） Azure OpenAI (生成AIモデル) llm-emit-token-metricでトークン利用量 を計測し、<dimension> で分析軸を付与 <dimension name="product" .../> <dimension name="user" .../> <dimension name="…." .../> ... トークン利用量＋Dimensionを customMetricsとして出力 Application Insights Azure Workbook KQLで参照 (ログ・メトリクス蓄積) customMetrics © 2026 NTT DATA Japan Corporation 12 (可視化・分析)

STEP1 利用データの取得・蓄積構成 基盤構築 可視化実装 運用改善・今後 APIMで取得したトークン利用情報をApplication Insightsに蓄積し、Workbookの分析データとして利用 利用者 / アプリケーション Azure OpenAI / Microsoft Foundry Azure API Management（APIM） リクエストを転送 APIリクエスト (生成AIの利用) Product / User (社内アプリ・ツールなど) customMetricsに付与するDimensionによって 分析できる切り口が変わる ⇩ どの切り口で利用状況を見たいかに応じて、 設計することが重要 APIM Policy（Inbound） Azure OpenAI (生成AIモデル) llm-emit-token-metricでトークン利用量 を計測し、<dimension> で分析軸を付与 <dimension name="product" .../> <dimension name="user" .../> <dimension name="…." .../> ... トークン利用量＋Dimensionを customMetricsとして出力 Application Insights Azure Workbook KQLで参照 (ログ・メトリクス蓄積) customMetrics © 2026 NTT DATA Japan Corporation 13 (可視化・分析)

基盤構築 STEP2 可視化に向けた分析軸の選定 APIMが既定で利用できるDimensionから、利用実態の把握に有効な5項目を選定 Dimension 実データ例 選定理由・使いどころ Operation ID Create_Response / ... 利用方式を識別 Product ID product-codex-... Product別の利用量・クォータ消化率 User ID usr-... Product内のUser別利用量 Subscription ID 6a6af735... Key単位での切り分け用として保持 Deployment ID gpt-5.5 / … モデル単位の識別用として保持 © 2026 NTT DATA Japan Corporation 14 可視化実装 運用改善・今後

基盤構築 可視化実装 運用改善・今後 STEP3 Workbookで利用状況を多角的に可視化 Product・User・Model別に、利用量・推移・クォータ状況を一画面で確認 Product別に期間内の使用量を可視化 どのProductがどれだけ利用しているか Product A 日次の推移をProductで色分けして可視化 指定期間内の使用量 • 日別推移 • クォータ消化率 誰の利用が多いか Product別のクォータ消化率を可視化 ユーザ別の期間内の使用量を可視化 モデル別の使用量を可視化 © 2026 NTT DATA Japan Corporation • • Product内のUser別使用量 • 利用集中ユーザの特定 どのモデルが利用されているか 15 • モデル別使用量 • Productごとの利用傾向

基盤構築 可視化実装 運用改善・今後 STEP3 Workbookで利用状況を多角的に可視化 Product・User・Model別に、利用量・推移・クォータ状況を一画面で確認 どのProductがどれだけ利用しているか ✓ ！ 利用状況を可視化できるようになった • 指定期間内の使用量 • 日別推移 • クォータ消化率 ただし、見に行かないと変化にきづけない 誰の利用が多いか • Product内のUser別利用料 • 利用集中ユーザの特定 日々確認すべき変化を自動で判定し、必要な情報だけをSlackへ通知 どのモデルが利用されているか © 2026 NTT DATA Japan Corporation 16 • モデル別利用料 • Productごとの利用傾向

基盤構築 Token日次Slackレポート 可視化実装 Logic Appsが利用量・クォータ・User情報を集計し、確認すべき変化だけをSlackへ届ける 処理 内容 通知タイミング 01 利用量を集計 前営業日の総利用量、Product別当月利用量を集計 02 クォータ状況を判定 現在消化率・月末予測消化率を算出 月〜金 09:00 JST 主な閾値 全体利用量：前々営業日比 +20%以上 クォータ消化率：80%以上 月末予測消化率：100%以上 03 Userの変化を検知 User別Top3、直近5営業日平均との差から急増を検知 04 通知情報を整形 User名を解決し、Workbookへの詳細リンクを付けてSlackへ通知 日々の変化を自動で検知し、必要な情報をSlackに送ることで運用の判断材料に © 2026 NTT DATA Japan Corporation 17 急増User：直近5営業日平均比 +20%以上 通知先 Slack（指定チャンネルへ通知） 運用改善・今後

Token日次Slackレポートの通知内容（例） 基盤構築 全体サマリ • • 今月の累計利用量 前日・当日の利用量と前日比 Product別クォータ • • 各Productの使用量・使用率 月末予測を一覧で表示 アラート・要確認事項 • • 閾値を超えた項目（クォータ超過見込み・急増ユーザー） 該当時はメンションで通知 利用量上位ユーザー • • 前営業日の利用量が多いユーザー Top3 メールアドレス・利用量・主なDeployment 急増ユーザーの詳細 • • 直近5営業日平均と比較して利用量が急増したユーザー 増加率・増加量・主なDeployment 詳細リンク • © 2026 NTT DATA Japan Corporation 18 Workbookへのリンクを記載 可視化実装 運用改善・今後

基盤構築 今後のToken最適化への取り組み展望 これからもトークン利用量の増加が見込まれるが、予算には上限がある。 今後トークン利用を効率化していくためにトークン圧縮ツール導入を見据えて検証中。 © 2026 NTT DATA Japan Corporation 19 可視化実装 運用改善・今後

基盤構築 Token圧縮ツール導入 入力トークンを圧縮することでトークン消費量を軽減 ツール概要 Headroomを利用予定 AIエージェントがLLMに渡すコンテキストを事前に圧縮するコンテキスト最適化ツール メリット ユーザの技量に依存せずトークン消費が狙える。 コンテキスト長の上限に達しにくくなる。 デメリット 元々無駄の少ないデータでは圧縮効果が限定的。 圧縮処理による追加レイテンシ・計算リソースが発生する。 意図しない圧縮になりやり取りが増える可能性がある。 © 2026 NTT DATA Japan Corporation 20 可視化実装 運用改善・今後

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

基盤構築 Headroom検証②：GPUによる高速化／圧縮効果検証 可視化実装 運用改善・今後 Headroom SDK、101ファイル × 閾値5段階 × 各3回（CPU／GPU 各1,515レコード） ① CPUの処理時間懸念 → GPUで大幅改善 4.28秒 → 0.18秒 ② しきい値別の圧縮効果（質問のみ文章） 約24倍 45.7% 高速化（累積時間比23.9倍） 1件あたり平均圧縮時間（CPU→GPU） 11.0% 11.2% 0.1 0.3 11.7% 14.7% 4.28秒 平均 0.18秒 7.96秒 P95 0.5 0.7 0.9 スコア閾値 0.32秒 ※質問のみ：検証のLLM入力トークン（101件合計、Original比） 16.07秒 最大 0.52秒 CPU (t3.xlarge) GPU (g4dn.xlarge / T4) 懸念だった「数秒の待ち」は0.2秒程度に短縮。圧縮結果はCPU／GPU間・3回反復 でハッシュ完全一致（再現性あり） © 2026 NTT DATA Japan Corporation 閾値0.9（最大）で質問の圧縮率45.7% 0.1〜0.7は11〜15%に留まり0.9で急増（36,805→19,988） 回答品質の担保は今後確認が必要 圧縮率だけでは情報保持の品質は評価できない。通常回答と Headroom経由の回答を比較する等、品質測定を検討する。 2

最適化事例 - GitHub Copilot コスト最適化施策 ― 全体像 課金が「利用回数」から「トークン量（AI Credit）」ベースへ変わり、コストが大幅増に。 「ツール」と「使い方」の2方向から対策し、教育と仕組みでプロジェクト全体に展開した 施策1 生成AIツールのリファクタリング 施策2 AI利用運用の改善 成果 対象：AIツール内部の無駄な処理 対象：ユーザーのモデル選択・使い方 AIツール 1コマンドあたり 1 2 3 4 入力トークンの削減 共通指示ファイルを整理し、毎回の送信量を削減 1 軽量モデルの活用 通常作業は軽量モデルが原則（最大の効果） ▲35% 819 → 524 AI Credit コンテキストサイズの最適化 出力品質をほぼ落とさずに削減 1Mへ拡張し、高コストな要約処理を回避 2 アウトプットの最適化 タスクごとにセッション分割 履歴の蓄積による入力増・要約発生を防止 単価最高の出力を「必要十分」に絞る キャッシュの有効活用 3 サブエージェント並列化でキャッシュを維持 プロジェクト全体の利用料金 画像仕様への対策 画像上限超過によるキャッシュ無効化を回避 ▲60%以上 ピーク時比 ツール改善・ルール整備・教育の総合効果 施策3 プロジェクト への展開 勉強会 個別指導・相談 仕組み化 AI Credit・プロンプト・ルール ヘビーユーザーへフィードバック リアルタイム警告ツール © 2026 NTT DATA Japan Corporation 23