[日本語訳]AI Tokenomics：このAI支出で、私たちは何を得たのか

こんにちは、@aymkbyshi です。

普段はDatabricksで、スタートアップのデータ・AI活用を支援しています。

本記事は、Databricks for Startups Blog に掲載された “AI Tokenomics: What Did We Get for All This Spend?” の日本語訳です。
原文: https://blog.databricksforstartups.com/tokenomics-what-did-we-get-for-all-this-spend-3f3c0970d1c7

最初の請求書が届き始めています。

多くのスタートアップが、今まさに初めての本格的な AI 利用料の請求書を受け取り始めています。そして、その金額は当初の想定を超えています。CFO がその明細を見ます。取締役会もその明細を見ます。そして、すべての創業者が恐れ始めている問いが投げかけられます。

「この支出で、私たちは何を得たのか？」

多くのチームにとって、正直な答えは「よく分からない」に近いはずです。

トークンは、いくつものツール、いくつものチームメンバー、いくつものワークフローの中で消費されています。しかし、その全体像を把握している人は誰もいません。

スタートアップは、速く作って速く出すことでここまで来ました。そのスピードは、トークンコストをあまり気にせずに AI 活用の可能性を広げることも可能にしてきました。

しかし、その猶予期間は終わりつつあります。投資家は、AI への支出に対する「成果の証拠」を求め始めています。

この記事では、理論よりも「では何をすればよいのか」に焦点を当てます。

30 秒でできるセルフチェック

まず、次の質問を考えてみてください。

明日、顧客からこう聞かれたとします。

「AI エージェントがサポートチケットに回答したとき、どのデータにアクセスしていましたか？」

この質問に、24 時間以内に正確に答えられますか？

取締役会からこう聞かれたとします。

「AI 機能ごとのコストを出してください」

この情報を、1 つのクエリで出せますか？

金曜の夜に、開発者がエージェントのループを止め忘れたとします。

誰かが手動で確認しなくても、月曜の朝を迎える前に検知できますか？

もし、どれか 1 つでも「何人かに聞いて回らないと分からない」と感じたなら、あなたの AI スタックはすでに手作業のガバナンスで管理できる段階を超えています。

ただし、これは悪いニュースだけではありません。

これらはすべて「設定」の問題であり、同じ考え方で解決できます。

なぜスタートアップが最初に苦しくなるのか

もちろん、大企業にも同じ問題はあります。

ただし、大企業にはプラットフォームチームがあり、CISO がいて、社内向けの AI ガバナンスツールを 6 か月かけて作れるだけの人員があります。

一方で、スタートアップにはその余裕がありません。

特に次の 3 つが、スタートアップにとって大きな負担になります。

把握できていない AI 支出は、そのまま runway を削る

12 人規模の会社に、突然 4 万ドルの LLM 請求が届いたとします。

これは、誰か 1 人の約 2 か月分の給与に相当します。

AI のコストは、単なるクラウド利用料ではありません。スタートアップにとっては、事業を続けられる期間そのものに影響します。

プラットフォームチームがない

社内で管理基盤を作るとしても、その開発は誰かが担当しなければなりません。

そして、その時間は本来進めるはずだったプロダクト開発から差し引かれます。

SOC 2 の質問は、最初のエンタープライズ契約の直前にやってくる

最初の大口顧客が契約しようとしているタイミングで、次のような質問が届きます。

「私たちのデータはどこに送られていますか？」

「監査ログを見せてください」

ここで答えられずに商談が止まると、そのまま失注につながります。

4 つの漏れと、その塞ぎ方

AI 活用でよく起きる失敗には、いくつかの共通パターンがあります。

ここでは、特に多い 4 つの「漏れ」と、それぞれの対策を紹介します。

対策の基本形は、すべて同じです。

すべてのモデル、すべてのエージェント、すべての MCP サーバーの前段に、単一の AI ガバナンスレイヤーを置くことです。

この記事では、その例として Unity AI Gateway を使います。

1. 何にいくら使っているのか分からない

症状

OpenAI から請求書が届く。Anthropic からも請求書が届く。

しかし、それぞれのコストがどの機能、どのチーム、どの顧客に紐づいているのか分からない。

対策

すべてのモデル呼び出しに、ゲートウェイ側で team、user、project のタグを付けます。

さらに、リクエストがモデルに到達する前に、チームごとの予算をチェックできるようにします。

具体的には、AI spend controls を有効化し、system tables に対して SQL アラートを設定します。これにより、週末に暴走したループを、月曜の朝ではなく金曜の夜の時点で検知できます。

たとえば、Serving endpoint に対して、ユーザーごとの rate limit と usage tracking を設定します。

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import (
    AiGatewayConfig, AiGatewayRateLimit, AiGatewayUsageTrackingConfig,
)

w = WorkspaceClient()
w.serving_endpoints.put_ai_gateway(
    name="prod-gpt-4o",
    usage_tracking_config=AiGatewayUsageTrackingConfig(enabled=True),
    rate_limits=[
        AiGatewayRateLimit(calls=60, key="user", renewal_period="minute"),
    ],
)

usage tracking を有効にすると、すべての呼び出しが user tag 付きで system.serving.served_entities に記録されます。

このテーブルに対して SQL アラートを設定すれば、暴走ループが 5 桁の請求になる前に検知できます。

-- 24 時間のローリングウィンドウで、いずれかのユーザーが $500 を超えるトークンを消費したら通知する
SELECT user_id, served_entity_name,
       SUM(input_token_count + output_token_count) AS tokens,
       SUM(usage_cost_usd) AS cost_24h
FROM   system.serving.served_entities
WHERE  event_time > current_timestamp() - INTERVAL 24 HOURS
GROUP  BY user_id, served_entity_name
HAVING cost_24h > 500;

これを 15 分間隔の Databricks SQL Alert に接続します。

そうすれば、問題は月曜朝の Slack インシデントではなく、金曜の夜に検知できるアラートになります。

「もっと注意しよう」は、制御ではありません。

2. エージェントが、新人社員には与えないような権限を持っている

症状

本番環境で動いている多くのエージェントが、それを起動したユーザーよりも広い権限を持っています。

ユーザーが読めないデータを読み、ユーザーが書き込めないシステムに書き込めてしまいます。

もしそのエージェントがプロンプトインジェクションを受けた場合、影響範囲はユーザーの権限ではなく、エージェント自身が持っている権限の範囲になります。

対策

エージェントを 1 つの identity として扱い、on-behalf-of access を強制します。

エージェントからのリクエストには、実行元ユーザーの identity を含めます。権限はゲートウェイでチェックし、すべての呼び出しについて、エージェントとユーザーの両方の identity、そしてアクセスしたリソースをログに残します。

エージェントを社内システムに接続する場合は、Unity Catalog で管理された managed MCP servers を通じて接続します。

これにより、モデル、データ、ツールへのアクセスを、同じ権限モデルの中で管理できます。

ここで見落とされがちなポイントがあります。

人間の従業員には、自然な形で責任が伴います。解雇されるリスク、評判、周囲の目があります。

一方で、エージェントにはそうした責任感はありません。エージェントは、ただタスクを完了しようとします。

もしシステム側が説明責任を担保していないなら、実質的には誰も責任を持っていないのと同じです。

3. ガードレールがモデルごとにバラバラになっている

症状

各 AI プロバイダーは、それぞれ異なるデフォルト設定を提供しています。

その結果、システム全体の安全性は、深夜 2 時に開発者がつないだ、最も弱い endpoint に引きずられてしまいます。

対策

すべてのモデルの前段にある、1 つのレイヤーでガードレールを適用します。

ガードレールには、大きく 2 種類あります。どちらも必要です。

Pre-LLM guardrails

プロンプトがモデルに到達する前に実行されるガードレールです。

たとえば、次のような処理を行います。

• PII の検出・編集
• プロンプトインジェクションの検知
• トピックやキーワードによるフィルタリング
• jailbreak の検知

Post-LLM guardrails

モデルの応答がユーザーに表示される前に実行されるガードレールです。

たとえば、次のような処理を行います。

• ブランドセーフティのチェック
• センシティブな内容の編集
• スキーマ検証
• 自社のリスクプロファイルに応じたカスタムチェック
  
  コードで設定すると、次のようになります。

from databricks.sdk.service.serving import (
    AiGatewayGuardrails, AiGatewayGuardrailParameters, AiGatewayGuardrailPiiBehavior,
)

guardrails = AiGatewayGuardrails(
    input=AiGatewayGuardrailParameters(
        pii=AiGatewayGuardrailPiiBehavior(behavior="BLOCK"),
        invalid_keywords=["api_key", "secret"],
    ),
    output=AiGatewayGuardrailParameters(
        pii=AiGatewayGuardrailPiiBehavior(behavior="MASK"),
    ),
)

w.serving_endpoints.put_ai_gateway(name="prod-gpt-4o", guardrails=guardrails)

多くのチームがつまずく本当の難所は、検知そのものではありません。

難しいのは、その後の判断です。

ブロックするのか。
編集して処理を続けるのか。
安全な fallback を返すのか。
人間に確認を回すのか。

ゲートウェイを使えば、この判断をルールごとに設定できます。

4. エージェントが何をしているのか見えない

症状

「このエージェントは直近 1 時間で何をしたのか？」

この問いに対して、すぐにクエリを実行したり、信頼できる答えを返したりできない状態です。

対策

すべての呼び出しについて、完全な trace を 1 か所に集約します。

取得すべき情報には、prompt、tool invocations、model、latency、cost、lineage などが含まれます。

MLflow Tracing と gateway logs を組み合わせることで、end-to-end の可視性を確保できます。

多くのスタックでは、これは次のような 1 行の設定から始められます。

import mlflow
mlflow.openai.autolog() # すべての OpenAI 呼び出しを取得
mlflow.anthropic.autolog() # すべての Anthropic 呼び出しを取得
mlflow.langchain.autolog() # ツール呼び出しを含む完全なエージェント trace も取得

Inference logs を使うと、任意の endpoint に対して行われた request と completion を、詳細に把握できます。

これにより、dashboard 上で regression を見つけられるだけではありません。

チームが日々の作業の中で生み出している best practices、chain-of-thought reasoning、再利用可能な AI skills などを発掘することもできます。

今週やるべき 3 つのこと

1. AI estate を棚卸しする

すべての API key、すべての endpoint、すべての agent、すべての developer tool を洗い出します。

Cursor、Claude Code、Copilot の integration も含めて確認してください。

多くのチームは、自分たちが使っている AI 関連の資産を、実際の半分程度しか把握できていません。

2. 1 つの workflow を gateway の後ろに置く

高トラフィックな agent か endpoint を 1 つ選び、Unity AI Gateway の後ろに配置します。

そして、spend tagging、1 つの pre-LLM guardrail、1 つの post-LLM guardrail を有効にします。

目的は、実際の workload に対して、コストの可視性とポリシー強制がどのように変わるのかを体感することです。

3. SOC 2 への回答を今すぐ用意する

Audit log query、access-control story、data-flow diagram を用意しておきます。

顧客から初めて聞かれたときに、慌てて 1 か月かけて対応するのではなく、すぐに答えられる状態にしておくべきです。

Databricks の SOC posture は、有用な参考になります。

おわりに

今後 2 年で勝つスタートアップは、最も多くの AI 機能を出荷する会社ではありません。

勝つのは、自信を持って説明できる AI 機能を出荷する会社です。

その違いを生むのが、ガバナンスです。

そして、ガバナンスを整えるタイミングは今です。

請求書やセキュリティ質問票に追い込まれて慌てる前に、まずは 1 つの endpoint から始めましょう。

実際にどのように動作するかについては、以下の Unity AI Gateway demo を参照してください。そして、1 つの endpoint を選び、そこから始めてみてください。

---

Databricks for Startupsでは、野心的なアイデアに取り組む創業者やエンジニアと密に連携しています。

データ・AI基盤、生成AI活用、AIエージェントの業務実装について相談したい方は、@aymkbyshi までお気軽にDMください。