Okta Blog 第18回そのAPI費用、実は「ツール税」かも～ AIエージェントのトークン消費を90%削る方法

AI エージェントのモデル呼び出しには、使用する可能性のあるすべてのツールのメニューが含まれます。たとえ、そのエージェントが一度も触れないツールであってもです。 これは、エージェントが Google Workspace や Slack に接続している場合でも、数年にわたって数百のツールが追加されてきた社内 MCP（Model Context Protocol）サーバーに接続している場合でも同じです。MCP サーバーが公開するすべてのツールは、スキーマ、名前、説明、パラメータとしてモデルのプロンプトに組み込まれ、それが毎ターンのように発生します。実際にツールを呼び出すかどうかにかかわらず、モデルがそのツールについて推論するためのコストを支払わなければならないのです。 私たちはこれを「ツール税（Tool Tax）」と呼んでいます。これはアクセス拒否やセキュリティインシデントとしては現れないため、ほとんどの AI チームにとって見えにくいものでした。しかし結果として、説明が難しいほどの不自然に高いトークン請求額となって現れるのです。● AI エージェントの能力は、接続先によって決まる MCP サーバーは、企業が AI エージェントをツールやデータに接続するための手段として、今最も急速に普及しているものの1つです。その急成長により、IT 部門内では「すべてをすべてに接続しなければならない」というプレッシャーが生まれました。チームはガバナンスが追いつくよりも早いペースで MCP サーバーをデプロイしており、その結果、セキュリティ上のリスクとコストの問題が同時に表面化しています。 サーバーごとに公開されるツールが増えるほど、実際の作業が始まる前の「ツール選択」のためだけに、AI エージェントの意思決定1回あたりに消費されるトークンが増加します。人気のある単一の MCP サーバーには数千人のアクティブユーザーが存在することもあり、その一人ひとりが毎ターンのようにツール税を支払っています。ツール数の増加とユーザー数の増加という2つの問題が、掛け合わさって膨れ上がっていくのです。 事後に権限のないツール呼び出しを拒否したとしても、消費されたトークンは戻ってきません。それらはモデルが何らかの処理を試みる前、プロンプトの段階ですでに消費されているからです。そして、AI エージェントがアクセス権を持つべきでないツールを一度使用してしまうと、それを取り消す作業自体が一つのプロジェクトになってしまいます。誰かが気づき、調査し、アクセス権を取り消さなければなりません。いずれにせよ、消費されたトークンは戻りません。 処理の上流（アップストリーム）でスコープ（権限範囲）を絞り込めば、最初から取り消すべき問題自体が発生しなくなります。● Okta のフレームワークは「何に接続できるか？」をより具体的に問う 安全なエージェント型エンタープライズを実現するための Okta のフレームワークでは、AI エージェントを運用するすべての組織に対し、次の3つの質問に答えるよう求めています。「エージェントはどこにいるのか？」「エージェントは何に接続できるのか？」「エージェントは何ができるのか？」 こうしたきめ細かいアクセス制御機能（ツール単位での絞り込み）は、先ほどの2つ目の質問を、ほとんどのチームが考え及ばないほど詳細なレベルで追求した結果として実現しました。「何に接続できるか」というのは、AI エージェントがどの MCP サーバーに到達できるかという話にとどまりません。特定のユーザーのために動くエージェントに対し、どの具体的なツールの使用が許可されているか、という点まで踏み込んだものなのです。 最小権限アクセスの原則に基づけば、AI エージェントは明確に権限を与えられていないリソース、データベース、ツールを認識すべきではありません。エンタープライズを保護するために権限のないツールを排除することは、結果としてツール税を減らすことにも繋がります。● 仕組み Okta は、AI エージェントが MCP サーバーに接続する時点でツールリストのスコープを絞り込みます。Okta ダッシュボード内で、管理者は特定のアイデンティティがどのツールを使用する権限を持っているかを設定します。これにより Okta は、サーバーが公開しているすべてのツールではなく、絞り込まれたセットのみを返します。 絞り込まれた短いリストが毎ターンエージェントのプロンプトに挿入されるため、AI エージェントが呼び出しを試みる前から、1ターンあたりのトークン消費量が削減されます。権限のないツールはモデルが見るリストに含まれず、ツール呼び出しが実行される前の実行時（ランタイム）にも、再度スコープチェックが行われます。● 得られる成果 ツールリストを AI エージェントのアイデンティティが実際にアクセスを許可されているものだけに絞り込むことで、モデルに到達する前にカタログの大部分を削減できます。現実的な権限レベルの組み合わせを用いた社内モデリングでは、表示されるツールが 90% 以上削減されたシナリオもありました。プロンプト内でのツール記述に関連するコストである「ツールスキーマコスト」も、ほぼ同等の割合で低下します。（注）● これが「ゲートウェイ」の問題ではなく、「アイデンティティと認可」の問題である理由 ゲートウェイは、データが提供する最も細かい粒度（キー、チーム、グループ単位）で支出の上限を設定します。これは有益な機能であり、ルーティングやレート制限においては、ゲートウェイが担うべき適切な役割です。しかし、事後的に支出上限を設定すると、ゲートウェイの管理者が必然的に「トークン警察」のような役割を担うことになります。誰かが上限を設定し、チームから反発があればそれを正当化し、作業の途中でユーザーが制限に達した際にはその対応をしなければなりません。これはゲートウェイの欠陥ではありません。スコープによる制御ではなく、支出上限しか手段がない場合に起こる当然の帰結なのです。 ゲートウェイは、すでに発生した事象（投入トークン、出力トークン、消費金額）を計測します。意思決定が高コストになった後で被害に上限を設けることはできますが、最初から意思決定が高コストになるのを防ぐことはできません。なぜなら、グループレベルの情報では、特定の1つのエージェント、あるいはその背後にいるユーザーが「実際に何にアクセスする権限を持っているか」までは把握できないからです。 アイデンティティレイヤーならそれが可能です。グループメンバーシップではなく、ユーザー単位および AI エージェント単位の権限（エンタイトルメント）を用いることで、Okta はゲートウェイではアクセスできない解像度でツールリストをフィルタリングします。ゲートウェイは通過したものを計測し、アイデンティティレイヤーは計測対象そのものを小さくするため、監視・規制すべき負担自体が減少するのです。 Software Analyst Cyber Research のプリンシパル・サイバーセキュリティ・インダストリー・アナリストである Paul Webber 氏は次のように語ります。「エージェントのコスト管理は、ビジネスプロセスを妨げることなく、よりきめ細かな制御と精度を提供するアイデンティティガバナンスツールを使用して実現するのが最適です。Okta のアプローチがエレガントなのは、その洞察を持たない個別の計測レイヤーに頼るのではなく、セキュリティを統括するのと同じエンタイトルメントデータを活用しているからです」● より重要な視点 コストは、この問題のほんの一面に過ぎません。使用を許可されていないアイデンティティからツールを取り除くことは、そのアイデンティティが侵害された場合に実行され得る攻撃の選択肢をも奪うことになります。プロンプトをスリムに保つためのスコープ制御が、そのまま被害範囲（ブラストレイディウス）を最小限に抑えることにも繋がるのです。 最小権限の MCP 適用により、モデルが推論すべきトークン量と、残されたツールを使って攻撃者が与え得る被害の両方を減らすことができます。● 次のステップ AI シミュレーターをチェックして、実際の攻撃シナリオの実行、カバー範囲の評価、セキュリティギャップの検出を行い、多様な統制策によってリスクと被害範囲をどのように軽減できるかをご確認ください。（注）手法：本記事の削減数値は、Okta の製品データおよび公開されているベンダー文書のみを使用し、Okta 内部でモデリングした結果に基づいています。顧客データは一切使用されていません。エンタープライズツールのカタログにアクセスできる単一の MCP クライアントをモデル化し、アイデンティティベースのスコープ制御適用前後でモデルから可視化されるツール数を比較しました。ツール削減率は、「1 -（スコープ適用後のツール数 / スコープ適用前のツール数）」として計算されています。スコープ適用後の露出状況を推定するため、Okta MCP サーバーのツールをそれらを有効化する OAuth スコープにマッピングし、代表的なユーザーセグメント（ヘルプデスク参照専用、ヘルプデスクオペレーター、アプリ管理者、ブランド/メール管理者、特権管理者）を定義した上で、月間トラフィックの想定割合で各セグメントを重み付けしました。各ツールはターンごとに名前、説明、パラメータスキーマをプロンプトに提供するため、ツールスキーマのトークンコストはツール数とほぼ線形で推移します。したがって、スキーマコストの削減割合はツール数の削減割合に密接に連動します。絶対的なトークン数および金額は、平均スキーマサイズ、リクエストボリューム、モデルの価格設定に依存し、これらはデプロイ環境ごとに異なるため、本記事では金額ではなく割合として削減率を報告しています。実際の効果は、ご利用のツールカタログ、権限の分布、採用するモデルによって異なります。元の記事を読む