年間AI予算が数ヶ月で溶ける！？私たちが始めたTokenomics実践

自組織で取り組んでいるAIコストの可視化や運用、今後の最適化に向けた展望を示した資料です。

Tokenomics Meetup#1
https://tokenomics.connpass.com/event/405331/
にて発表したスライドになります。

Transcript

1. 情 報 種 別 ： 秘密（関係者外秘） 会 社 名 ： NTTデータグループ 情報所有者 ： 技術革新統括本部 先進エンジニアリング技術部 アーキテクト担当 Tokenomics Meetup#1 年間AI予算が数か月で溶ける！？ 私たちが始めたTokenomics実践 ―AI環境の構築と運用、AzureOpenAI Token可視化の実践 株式会社NTTデータグループ 技術革新統括本部 先進エンジニアリング技術部 アーキテクト推進担当（まかせいのう） © 2026 NTT DATA Japan Corporation
2. まかせいのう ® とは？ まかせいのう®は、 性能・非機能のいかなる問題も解決するグローバル対応も可能なアーキテクトサービスです。 ナレッジを集約したエキスパート・アーキテクトが、 お客様の性能や非機能に関する問題・課題を解決いたします。 + 200+ 5,000 Professionals 100% Projects 200名を超える 業界やシステムを問わず エキスパート・アーキテクトが 過去十数年間で５,0００超の あらゆる状況に対応 プロジェクトに対応 処理量 100,000 TPS 高SLAへの対応実績 © 2026 NTT DATA Japan Corporation 問題解決率 難易度や複雑化が進む近年も 対応した全ての問題を解決 満足度向上施策の継続実施 200+ Projects グローバル案件への対応実績
3. 基盤構築 0．本日の共有内容 可視化実装 運用改善・今後 Azure OpenAI＋APIMで利用基盤を構築し、実運用で見えた課題を可視化・日次監視によって改善した取り組みを共有 本日のストーリー AI利用の拡大 構成選定・基盤構築 運用改善 運用で得た学び これから 利用が広がり コストが急増 Azure OpenAI + APIMで 統制可能な基盤を構築 利用量の可視化と 日次監視の自動化 実運用で見えた課題と 改善のポイント Tokenomics・費用対効果・ 費用帰属の検討へ 共有内容 01 基盤構築 AIを安心して使える基盤をどう作ったか 02 可視化実装 03 見えないを見えるに、気づける仕組みへ 運用改善・今後 運用して分かった効果と、次のステップ これまでの経緯と課題 初期運用で見えた課題 運用実績 選択肢の比較と採用理由 上限設計の見直し 改善効果 APIM構成・制御設計 利用量の可視化（Workbook） 今後の課題 キー管理・上限設定 日次監視の自動化（Slack通知） © 2026 NTT DATA Japan Corporation 3
4. 基盤構築 １．これまでの経緯 ～無償利用からEnterprize版利用へ～ 可視化実装 運用改善・今後 ▪FY2025 AI活用の拡大 まかせいのうとして、積極的にChatGPT、Codex、Copilot を中心にAI利用を促進するする方針を打ち出していた。 OpenAI APIについても、利用対象や利用量を大きく制限せずに活用していたが、利用拡大や高性能モデルの利用に伴ってコス トが増加し、想定より早く利用上限に達する可能性が顕在化した。 モデル 入力 キャッシュ入力 出力 主な位置づけ GPT-5.6 Sol $4.00 $0.40 $20.00 高度な業務・分析 GPT-5.6 Terra $2.00 $0.20 $12.00 ★性能/価格バランス GPT-5.6 Luna $0.20 $0.02 $1.20 大量・低コスト処理 GPT-5.5 $5.00 $0.50 $30.00 旧フラッグシップ GPT-5.4 $2.50 $0.25 $15.00 旧汎用モデル GPT-5.4 Mini $0.75 $0.08 $4.50 軽量モデル GPT-5.4 nano $0.20 $0.02 $1.25 定型大量処理 GPT-5.2 $1.75 $0.18 $14.00 旧世代 表１：GPTのトークン単価 GPT-5 Mini $0.25 $2.00 旧軽量モデル ▪FY2026 無償API枠の逼迫と継続手段の検討 GPT-5 nano $0.05 $0.01 $0.40 旧最小モデル • 4月、事務局から、現在の利用ペースではFY2026上期中に年間のAPIクレジットを使い切る見込みとの連絡を受けた。 • 5月には、OpenAI API無償利用枠の利用停止に関する案内が発出され、早急に継続利用の方法を決める必要が生じた。 • 担当内アンケートの結果、Codexを含むAI環境の継続利用が必要と判断し、APIの有償契約の検討を進めつつ、 Enterprise版の利用を推進した。 $0.03 AI利用を継続するためEnterprise版へ移行 しかし、利用枠がトークンで管理されることで、新たな組織運用上の課題が発生 © 2026 NTT DATA Japan Corporation 4
5. 基盤構築 可視化実装 ２．Enterprise版で「トークン消費」が組織課題として顕在化 Enterprise導入から生じた因果 現場 ENTERPRISE版 組織内の AI利用に制限 • 使える人が限られる • トークンのリミットで解析が止まる 01 予算取り トークン消費量を見越して 必要予算を確保する 組織 利用枠 ＝ トークン Enterprise利用により、利用対象と消 費上限が制約に 目指す姿 組織に必要となった管理 AI活用を推進したいのに、 利用制限によってAIが使えない トークン消費を制御しつつ、AIを自由に利用できる環境の構築 利用制限と活用推進を両立する運用基盤へ © 2026 NTT DATA Japan Corporation 5 02 利用量・支出管理 利用量とトークン利用による 支出を継続的に管理する 運用改善・今後
6. 基盤構築 ３．検討対象の選択肢 可視化実装 ▪ 事務局から提示された選択肢 1. OpenAI APIを新規契約 (年間5万ドル以上の利用が必要) ⇒年間5万ドルに達しない場合は、利用していなくても不足分を支払う必要がある。 2. Azure OpenAIを利用 3. AWS bedrockを利用 © 2026 NTT DATA Japan Corporation (新規契約/PJで既存契約があればその中で利用) (新規契約/PJで既存契約があればその中で利用) 6 運用改善・今後
7. 基盤構築 ４．各案の比較 Azure OpenAI 推奨度 △ 単独利用・PoC向き 構築コスト 低い。最短で使える 自作 API Management 低コスト重視 本命 APIM設定・ポリシー設計が必要 △ 制御ロジック実装が必要 ランニングコスト ◦ 低〜中。周辺基盤が少ない △ APIM費用が追加 Functions / Storage中心 llm-token-limitでPJ/ユーザー /APIキー制限 Functionsで自由に実装 利用量制御 △ Project/APIキー単位中心 PJ別停止は自作寄り セキュリティ △ APIキー管理中心 社内IdP連携は別設計 Entra ID/APIM/RBAC/ Managed Identity連携 APIM＋Monitor＋Workbooks 選ぶべき時 AWS AWS標準企業向き △ API Gateway / Lambda / DynamoDB設計が 必要 Lambda / DynamoDB 中心 Lambda/DynamoDBで 実装 IAM/Role/CloudTrail/Priv ateLink App Insights＋Workbooks CloudWatch＋CloudTrail 可視化・監査 管理・運用 運用改善・今後 Entra ID＋Managed Identity ユーザによる制限機能具備と可視化機能の充実がポイント ◦ Usage Dashboard中心 可視化実装 △ Project分割は可能 最新OpenAI機能を 直接使いたい © 2026 NTT DATA Japan Corporation PJ ID＋ユーザーIDをキー化 複数PJ・統制・ 上限停止を重視 Table Storageで柔軟 APIM費用を避け Azureで作りたい 7 DynamoDBで柔軟 AWS基盤・複数モデルを 活用したい
8. ５．構築したアーキテクチャ（Azure API Management） © 2026 NTT DATA Japan Corporation 8 基盤構築 可視化実装 運用改善・今後
9. 基盤構築 ６．キー管理の概要 利用者 / 用途 単純個人利用者 利用者A Subscription Personal - 利用者A 通常個人利用 Product Policy: 個別上限 Maca OpenAI Product 通常利用向け API Policy: 共通上限 可視化実装 運用改善・今後 Backend 認証情報はAPIM内部で保持 API Key を利用者には渡さない Product Policy 1日 100,000 tokens / Subscription 1分 10 requests / Subscription counter-key = product + Subscription.Id APIM API Maca-OpenAI-Instance Maca OpenAI Product PJ-XXX API Policy API全体のToken制限 1日 10,000,000 tokens 1分 500,000 tokens counter-key = api-maca-openai-global Personal - Tomonori 通常個人利用 同一人物で 用途分離 利用者B PJ-XXX - Tomonori PJ作業用途 PJ作業向け Product Policy 1日 1,000,000 tokens / Subscription 1分 50 requests / Subscription counter-key = product + Subscription.Id ユーザ毎、プロダクト毎にキーを発行する ことで何を使っているのかを意識しつつ、 キーが流出しても被害が限定的になる © 2026 NTT DATA Japan Corporation 9 Azure OpenAI aoai-apim-jpedev-002
10. Azure OpenAI トークン利用状況可視化の取り組み © 2026 NTT DATA Japan Corporation 10 1
11. 基盤構築 背景・課題 可視化実装 運用改善・今後 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 （手動で確認） ⋮ 11 ! 異常や超過リスクに気づきにくい （リアルタイムでの把握が困難） 利用状況を 一目で把握できず、 見に行かないと 分からない状態
12. 今回の取り組み｜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 主な用途 日次の自動通知 12 早期検知 運用改善・今後
13. 各仕組みの詳細 Workbookをつくるまでの3ステップと、日次監視の実装 © 2026 NTT DATA Japan Corporation 13 1
14. STEP0 利用データの取得・蓄積構成 基盤構築 可視化実装 運用改善・今後 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 14 (可視化・分析)
15. STEP0 利用データの取得・蓄積構成 基盤構築 可視化実装 運用改善・今後 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 15 (可視化・分析)
16. 基盤構築 STEP1 可視化に向けた分析軸の選定 APIMが既定で利用できるDimensionから、利用実態の把握に有効な5項目を選定 Dimension 実データ例 選定理由・使いどころ Operation ID Create_Response / ... 利用方式を識別 Product ID product-codex-... Product別の利用量・クォータ消化率 User ID usr-... Product内のUser別利用量 Subscription ID 6a6af735... Key単位での切り分け用として保持 API ID aoai-apim-... API単位の識別用として保持 既定で利用可能なDimensionから、まず利用状況の分析に必要な5項目を選定 © 2026 NTT DATA Japan Corporation 16 可視化実装 運用改善・今後
17. STEP2 モデル別分析に向けた分析軸の見直し Product/ユーザ/利用方式別の利用料が 見えるようになりました！ © 2026 NTT DATA Japan Corporation 基盤構築 可視化実装 モデル別の利用料が分からない・・・ 17 運用改善・今後
18. 基盤構築 STEP2 モデル別分析に向けた分析軸の見直し Product/ユーザ/利用方式別の利用料が 見えるようになりました！ 可視化実装 モデル別の利用料が分からない・・・ 項目 見直し前 見直し後（適用済み） 利用単位 API ID（ほぼ固定） Deployment ID（モデル別に集計可能） 利用方式 Operation ID Operation ID（そのまま） Product別 Product ID Product ID（そのまま） ユーザー別 User ID User ID（そのまま） 5 Dimensionの上限内で、分析価値の低いAPI IDをDeployment IDへ変更 © 2026 NTT DATA Japan Corporation 18 運用改善・今後
19. 基盤構築 可視化実装 運用改善・今後 STEP3 Workbookで利用状況を多角的に可視化 Product・User・Model別に、利用量・推移・クォータ状況を一画面で確認 Product別に期間内の使用量を可視化 どのProductがどれだけ利用しているか Product A 日次の推移をProductで色分けして可視化 指定期間内の使用量 • 日別推移 • クォータ消化率 誰の利用が多いか Product別のクォータ消化率を可視化 ユーザ別の期間内の使用量を可視化 モデル別の使用量を可視化 © 2026 NTT DATA Japan Corporation • • Product内のUser別使用量 • 利用集中ユーザの特定 どのモデルが利用されているか 19 • モデル別使用量 • Productごとの利用傾向
20. 基盤構築 可視化実装 運用改善・今後 STEP3 Workbookで利用状況を多角的に可視化 Product・User・Model別に、利用量・推移・クォータ状況を一画面で確認 どのProductがどれだけ利用しているか ✓ ！ 利用状況を可視化できるようになった • 指定期間内の使用量 • 日別推移 • クォータ消化率 ただし、見に行かないと変化にきづけない 誰の利用が多いか • Product内のUser別利用料 • 利用集中ユーザの特定 日々確認すべき変化を自動で判定し、必要な情報だけをSlackへ通知 どのモデルが利用されているか © 2026 NTT DATA Japan Corporation 20 • モデル別利用料 • Productごとの利用傾向
21. 基盤構築 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 21 急増User：直近5営業日平均比 +20%以上 通知先 Slack（指定チャンネルへ通知） 運用改善・今後
22. Token日次Slackレポートの通知内容（例） 基盤構築 全体サマリ • • 今月の累計利用量 前日・当日の利用量と前日比 Product別クォータ • • 各Productの使用量・使用率 月末予測を一覧で表示 アラート・要確認事項 • • 閾値を超えた項目（クォータ超過見込み・急増ユーザー） 該当時はメンションで通知 利用量上位ユーザー • • 前営業日の利用量が多いユーザー Top3 メールアドレス・利用量・主なDeployment 急増ユーザーの詳細 • • 直近5営業日平均と比較して利用量が急増したユーザー 増加率・増加量・主なDeployment 詳細リンク • © 2026 NTT DATA Japan Corporation 22 Workbookへのリンクを記載 可視化実装 運用改善・今後
23. Azure OpenAI 運用時の課題とその解決から見えた次の課題 © 2026 NTT DATA Japan Corporation 23 2
24. 基盤構築 可視化実装 運用上の制約｜組織、グループの二層上限とトークンで管理 制約の構造 運用初期に起きた3つの困りごと AI利用の停止が頻発 01 Input Token でのみ制限可能 金額で制限を掛けられない 割り振れるToken量が少ない 02 組織全体の上限 予算が9月で切れる 03 Group A Group B Group C 二階層の上限を設定する必要がある一方、適正値を判断する材料がなかった © 2026 NTT DATA Japan Corporation 24 運用改善・今後
25. 基盤構築 可視化実装 運用改善・今後 運用上の課題｜トークン上限・トークン総量・用途が不明 01 グループ上限 事前に上限が上げられず、停止後に上限を引き上げる 02 組織全体の上限 利用可能なToken総量が分からない 03 用途別の使用量 用途ごとのToken量が分からずどれだけトークンが必要か不明 © 2026 NTT DATA Japan Corporation 25
26. １.グループ上限の設定｜可視化により事後対応から予防対応へ 可視化前 １億刻みで上限を引き上げ 可視化前 基盤構築 可視化実装 運用改善・今後 上限到達後に利用者から連絡 可視化対応 アラート追加対応 伸び率、過去実績を元に上限の上げ幅を調整 利用率の監視とSlackアラート 可視化後の変化 可視化後の変化 • 月６回の上限変更作業が、月２回までに変更 • 上位者の承認のリードタイムが半減 • 月6回のトークン上限到達による停止が0件へ • 運用者が一人でユーザー影響を出さずに運用が可能に 1か月間全体が停止することなく、AI環境を運用することに成功 © 2026 NTT DATA Japan Corporation 26
27. 2.組織全体の上限設定｜予算からトークン上限の予測が可能に 基盤構築 可視化実装 運用改善・今後 1か月間の利用実績から、上限設定に使う代表値を導出 モデル Token比 In:Out Cost比 In:Out Input単価※ gpt-5.5 84.4 : 1 4.9 : 1 135円 gpt-5.6-sol 170.1 : 1 3.9 : 1 135円 gpt-5.6-terra 140.4 : 1 3.4 : 1 135円 gpt-5.6-luna 124.5 : 1 6.0 : 1 135円 上限設定用 130 : 1 5:1 135円 ※100万トークン当たりの価格 キャッシュヒット率で変動 予算上限から設定すべきトークン利用上限を算出 予算額（円） × 5/6（Inputの額への変換）× 100万/135 (トークン/円）＝ Inputで制限するべきトークン量 まかせいのうの例：200万円 × 5/6 × 100万/135 = 123億トークン © 2026 NTT DATA Japan Corporation 27
28. 基盤構築 2.組織全体の上限設定｜予算からトークン上限の予測が可能に ※ 1か月間の利用実績から、上限設定に使う代表値を導出 モデル 1.グループごとの上限 ✓ In:Out Cost比 | 可視化により事前対応が可能 Input単価※ gpt-5.5 ✓ 4.9 : 1 | 実績値から算出 Token比 In:Out 84.4 : 1 2.組織全体の上限 125円 170.1 : 1 3.9 : 1 125円 gpt-5.6-terra 140.4 : 1 3.4 : 1 125円 gpt-5.6-luna 124.5 : 1 6.0 : 1 125円 上限設定用 可視化結果から、ヒアリング対象を選定 130 :1 5:1 gpt-5.6-sol ！ 可視化実装 3.用途ごとのトークン量 | 未対応 125円 予算上限から設定すべきトークン利用上限を算出 予算額（円） × 5/6（Inputの額への変換）× 100万/135 (トークン/円）＝ Inputで制限するべきトークン量 まかせいのうの例：200万円 × 5/6 × 100万/135 = 123億トークン © 2026 NTT DATA Japan Corporation 28 運用改善・今後
29. 3.用途別の使用量｜利用実態の二極化が判明 基盤構築 可視化実装 運用改善・今後 個別の利用実績を確認した結果上位４人で組織全体の半分のトークン量を消費していることが判明 8月実績のダッシュボード 8月個別利用量のダッシュボード 利用量上位４人を対象にAIの利用用途のヒアリングを実施 © 2026 NTT DATA Japan Corporation 29
30. 3.用途別の使用量｜利用方法は適切かつ今後の利用は増える 01 02 03 基盤構築 モデル選択は適切 利用上位者はいずれも、用途に応じたモデルを選択している 利用範囲は拡大予定 AIを適用する業務を増やすため、トークン利用量は今後も増える見込み 利用者も使用量を意識 ユーザー自身もトークン消費の多さは懸念していた ヒアリングから得られた示唆 利用上位者は適切にAIを活用しているため、リテラシー教育は不要 必要な分だけAIを利用しているため、利用用途からトークン量の見込みを取得することが可能 © 2026 NTT DATA Japan Corporation 30 可視化実装 運用改善・今後
31. 3.用途別の使用量｜用途ごとの大まかなトークン使用量が判明 基盤構築 可視化実装 Aさん 性能試験解析 AP・DBのログを分析し、 被疑箇所を特定する 1,500 万Token / 日 Bさん 設計レビュー 各工程の設計書を確認し、 修正が必要な箇所を指摘する 1,000 万Token / 日 Cさん BOT対応 技術的な問い合わせに対して、 自動で回答する 900 万Token / 日 用途ごとの利用実態が判明したため、最終的なトークン量の概算を実施 © 2026 NTT DATA Japan Corporation 31 運用改善・今後
32. 基盤構築 可視化実装 運用改善・今後 今後の運用課題｜利用拡大時には月294億Tokenが必要 未利用者98人が性能解析を日常利用すると現在の組織上限を大幅に超過 想定利用量 1,500万 Token / 人・日 × 20 × 営業日 98 未利用者 = 294億 Token / 月 現在上限 123億 必要量は現在上限の約2.4倍 次の運用テーマ 01 AI利用の普及 © 2026 NTT DATA Japan Corporation 02 32 Token消費量の削減
33. 今後のTokenomics活動 © 2026 NTT DATA Japan Corporation 33 3
34. 基盤構築 今後のToken最適化への取り組み展望 可視化実装 これからもトークン利用量の増加が見込まれるが、予算には上限がある。 今後トークン利用を効率化していくために下記の2点の導入を見据えて検証中。 トークン圧縮ツール導入 Azure SRE Agentの導入 各種エラーやトークン増加要因の特定を簡易化し、 解析スピードの向上を図る。 © 2026 NTT DATA Japan Corporation 今後の利用量増加による 利用上限抵触を予防するため。 34 運用改善・今後
35. 基盤構築 今後のToken最適化への取り組み展望 可視化実装 これからもトークン利用量の増加が見込まれるが、予算には上限がある。 今後トークン利用を効率化していくために下記の2点の導入を見据えて検証中。 トークン圧縮ツール導入 Azure SRE Agentの導入 各種エラーやトークン増加要因の特定を簡易化し、 解析スピードの向上を図る。 © 2026 NTT DATA Japan Corporation 今後の利用量増加による 利用上限抵触を予防するため。 35 運用改善・今後
36. AI Gateway のログはある。でも分析するのが大変 例えば、こんなことが知りたくなってきます。 • どんなHTTPエラーが多い？ • エラーは誰が発生させている？ • どのモデルで多い？ • 特定ユーザーに突出していない？ ただ、毎回KQLを書いて調べるのは大変。 「これ、AIに調べてもらえばいいのでは？」 © 2026 NTT DATA Japan Corporation 36
37. Azure SRE Agent © 2026 NTT DATA Japan Corporation 37
38. セットアップは意外とシンプル 1. SRE Agent リソースの作成 2. SRE Agent の Managed ID に対して、対象リソースやログ (Log Analytics) への権限を付与 3. 必要に応じてツール設定 4. 質問する！ © 2026 NTT DATA Japan Corporation 38
39. 実際に調査させてみた 4xx系のHTTPエラーはどの程度出ている？ © 2026 NTT DATA Japan Corporation 404エラーが多い原因は？ 39
40. 「見るFinOps」から「聞くFinOps」へ これまでの調査フロー これからの調査フロー ダッシュボードを見る ダッシュボードを見る 気になる数字を見つける 気になる数字を見つける KQLを書く Azure SRE Agent に尋ねる！ ログと合わせて原因を調査する ポイント • • • © 2026 NTT DATA Japan Corporation 40 大量ログの探索を任せられる 深掘り調査を自然言語で繰り返せる 定期実行によりレポーティング化も可能
41. 基盤構築 今後のToken最適化への取り組み展望 可視化実装 これからもトークン利用量の増加が見込まれるが、予算には上限がある。 今後トークン利用を効率化していくために下記の2点の導入を見据えて検証中。 トークン圧縮ツール導入 Azure SRE Agentの導入 各種エラーやトークン増加要因の特定を簡易化し、 解析スピードの向上を図る。 © 2026 NTT DATA Japan Corporation 今後の利用量増加による 利用上限抵触を予防するため。 41 運用改善・今後
42. 基盤構築 Token圧縮ツール導入 入力トークンを圧縮することでトークン消費量を軽減 ツール概要 Headroomを利用予定 AIエージェントがLLMに渡すコンテキストを事前に圧縮するコンテキスト最適化ツール メリット ユーザの技量に依存せずトークン消費が狙える。 コンテキスト長の上限に達しにくくなる。 デメリット 元々無駄の少ないデータでは圧縮効果が限定的。 圧縮処理による追加レイテンシ・計算リソースが発生する。 意図しない圧縮になりやり取りが増える可能性がある。 © 2026 NTT DATA Japan Corporation 42 可視化実装 運用改善・今後
43. 基盤構築 Headroom検証 Headroomをローカルで実行し圧縮率および圧縮処理の時間を検証 対象 テキストベースの技術問い合わせ100件 環境 4 vCPUs, 16 GiB RAM 検証結果 平均入力トークン数：40 平均圧縮後トークン数：34 平均圧縮率：14% 平均処理時間：2.02秒 ※別入力サンプルで検証した結果入力トークンが1400を超えると圧縮時間も10秒を上回るケースも見られた © 2026 NTT DATA Japan Corporation 43 可視化実装 運用改善・今後
45. 参考：各案の比較 ～セキュリティ観点での比較～ © 2026 NTT DATA Japan Corporation 45 基盤構築 可視化実装 運用改善・今後