AI Gateway User Insights：AI利用が「APIキー単位」から「人単位」で見えるようになった

要約

Cloudflare が 2026-08-05、AI Gateway に「User Insights」を追加し、全 AI Gateway 顧客に追加費用なしで一般提供を開始しました。既存のゲートウェイトラフィックの上で動くため、追加のセットアップは不要です。

機能は 2 つの軸を持ちます。1 つは支出の可視化で、組織全体のコスト・リクエスト数・トークン数・利用者数を表示し、個々のユーザー単位までドリルダウンできます。もう 1 つは異常利用の検知で、利用のベースラインを作り、そこから大きく外れたセッションをフラグします。

合わせて発表されたのが、AI Gateway と Cloudflare Access の統合（オープンベータ）です。これにより、AI 利用の追跡単位が匿名の API キーから認証済みのユーザー ID へ変わります。SAML プロバイダ（Okta、Entra）と連携し、個人ごとに直近 30 日の 95 パーセンタイル支出をベースラインとして、その 2 倍を超えたセッションをフラグする、という具体的な閾値が示されています。

この「キーから人へ」という変化が、実務上の要点です。従来、AI ゲートウェイのログはキー単位でした。キーが誰のものかは別途管理表と突き合わせる必要があり、共有キーが使われていれば追跡は事実上不可能です。「先月の請求が跳ねたが、誰が何をしたのか分からない」という状態は、多くの組織で起きています。ID と紐づけば、この突き合わせ作業がなくなります。

その上に、統制の手段が載ります。ユーザー単位の支出上限を設定でき、ID や IdP グループ単位でアクセスやモデル利用を制限できます。「このグループは高価なモデルを使えない」「この人の上限は月◯ドル」といった設定が、AI 利用に対して直接かけられる形です。

異常検知の目的が「犯人探し」ではない点も、公式記事の書き方から読み取れます。想定されているのは、認証情報の漏洩と、暴走したエージェントの早期発見です。エージェントが無限ループで API を叩き続ける事故は、コストとして現れるまで気づきにくく、気づいた時には請求が確定しています。ベースラインからの逸脱を検知する仕組みは、この種の事故に対する早期警報として機能します。

何が変わったか

• AI Gateway に User Insights が追加され、全顧客に追加費用なしで GA（追加セットアップ不要）
• 組織全体のコスト / リクエスト / トークン / 利用者数をダッシュボードで確認できる
• ユーザー単位までドリルダウンして支出内訳を見られる
• 利用のベースラインから外れたセッションを異常としてフラグできる
• Cloudflare Access との統合により、匿名 API キーではなく認証済みユーザー ID 単位で追跡できる（オープンベータ）
• SAML プロバイダ（Okta、Entra）と連携できる
• 異常判定の閾値は「直近 30 日の 95 パーセンタイル支出の 2 倍」
• ユーザー単位の支出上限を設定できる
• ID / IdP グループ単位でアクセスとモデル利用を制限できる

業務インパクト（一般企業向け）

AI の社内利用が広がるほど、情シスに寄せられる質問は「使えるか」から「いくらかかっているか」「誰が使っているか」へ移ります。User Insights は、この 2 つに直接答える機能です。しかも全顧客に無償で GA という提供形態なので、AI Gateway をすでに使っている組織は導入判断が不要で、見るだけです。まずダッシュボードを開いて現状を確認する、というのが最初の行動になります。

コスト管理の観点では、予算配分の議論の質が変わります。これまで部門別の AI 予算は、キーの発行単位や推測に基づいて割り振るしかありませんでした。人単位の実績が出るなら、次期の配分は実データで決められます。あわせてユーザー単位の支出上限が使えるので、「上限を決めて配る」運用が現実的になります。

セキュリティの観点では、認証情報漏洩の検知手段が増えたことになります。AI Gateway のキーが流出した場合、外部からの利用は正規のキーによる正規のリクエストとして通ってしまいます。従来これを見つける手立ては請求額の異常くらいでした。利用パターンのベースラインからの逸脱で検知できるなら、気づくまでの時間が大きく短縮されます。

一方で、運用設計上の注意もあります。人単位の利用実績が見えるということは、個人の業務内容がある程度推測できるということでもあります。労務・法務の観点から、このデータを誰が閲覧でき、何の目的に使うかは明文化しておくべきです。「不正検知のために取得したデータを人事評価に流用する」ような使い方は、制度としても信頼関係としても問題になります。運用開始前に利用目的を定めておくのが順序です。

閾値についても、初期設定のまま運用しないほうがよい場面があります。「30 日の 95 パーセンタイルの 2 倍」は汎用的な設定ですが、業務の性質上、月末や四半期末に利用が集中する組織では正常な変動が検知に引っかかります。数週間の観測でノイズの量を把握してから、アラートの運用ルールを決めるのが実務的です。

副業・個人活用視点

個人開発でも、AI Gateway を挟んでいるならそのまま恩恵があります。追加費用なしで GA という条件なので、自分のプロダクトのコスト内訳を見るだけでも価値があります。「どの機能がトークンを食っているか」がユーザー単位で見えると、価格設計の根拠が作れます。

特に効くのは、AI を組み込んだサービスを従量課金や定額で提供している場合です。ユーザーごとのコストが見えなければ、定額プランの原価がわかりません。ヘビーユーザー 1 人が利益を吹き飛ばす、という構造は AI 組み込みプロダクトでは珍しくありません。User Insights は、この判断に必要な数字を出してくれます。上限設定と組み合わせれば、「プラン内の上限を超えたら制限する」という保護もかけられます。

暴走検知は個人開発でこそ重要です。組織なら誰かが請求に気づきますが、個人開発では月次の請求で初めて事故を知ることになります。無限ループでモデルを呼び続けるバグは、コードレビューで防ぎきれる種類のものではありません。ベースラインからの逸脱で検知できる仕組みが標準で入っているのは、実質的な保険です。

受託案件の観点では、「AI 導入の成果をどう報告するか」という定番の課題に効きます。導入後に聞かれるのは、ほぼ必ずコストと利用実績です。ダッシュボードで人単位の利用状況を出せる構成にしておくと、月次報告の作成コストが下がり、継続契約の材料にもなります。ID 連携（Access 統合）まで組めば提案の厚みが増しますが、こちらはオープンベータなので、本番運用の前提に置く場合は提供条件を確認しておくべきです。