ID情報に基づく分析で、不正なAIの利用を検出

Ming LuKenny JohnsonAyush Kumar

15分で読了

この記事は以下でも利用可能です EnglishDeutschEspañolEspañol (Latinoamérica)FrançaisItaliano한국어繁體中文简体中文Nederlands.

AIの利用で発生した請求書を見ても、そこに潜む問題を判断することは困難ですが、通常の状態を示す基準を知っておくことで、エージェントの暴走や、特定の社員による利用量の急増に気付くことができます。通常の状態からの変化を検知できれば調査を開始できますが、これまでのところ、それを確認するのは難しい状況にありました。

AIで「誰が」「何をしているのか」を把握することは、現在、多くの組織が直面している主要な課題の1つです。スタンフォード大学のある調査では、59%の組織が、責任あるAIガバナンスを実現する上で最大の障害は「知識不足」であると回答しています。 

これの問題は金銭面だけでなく、セキュリティにもつながる話です。これらの課題を解決するには、すべてのすべてのリクエストに対して確認済みのIDを紐付けること(これにより、利用量の急増が誰によるものかを特定できます)と、そのIDの普段の利用状況といった2つの要素が必要になります。本日、私たちはこの2つの機能の提供を開始します。

Cloudflare Accessと連携したIdentity-aware AI Gatewayがオープンベータ版となり、User InsightsはすべてのAI Gatewayのお客様に追加費用なしで一般提供されています。これらを組み合わせることで、AI Gatewayを通じて既に流れているトラフィックから各ユーザーやエージェントの行動基準を作成し、それから逸脱するものを特定します。

AI Gatewayの役割

AI Gateway は、組織内で利用されるすべてのAI利用を一元管理するための「中央管理基盤」です。すべてのアプリやチームがOpenAI、Anthropic、Google、Workers AIのモデルを直接呼び出すのではなく、要求をまずAI Gatewayに通過させることで、すべてのAI使用について観察、保護、管理を一括して行うことができます。

AI Gatewayは、自社で開発したアプリケーションだけでなく、開発者が普段利用しているコーディングツールにも対応しています。Claude Code、Codex、GitHub Copilotなどの開発ツールもAI Gatewayを経由させることができるため、これらのツールも他のAI利用と同じように、利用状況の可視化やアクセス制御の対象になります。

Identity-aware AI Gateway

AI Gatewayと Cloudflare Accessを連携することで、ゲートウェイの前に バニティドメインを置き、他のアプリケーションと同様にAccessで保護することが可能です。これにより、以下のことが可能になります:

  • OktaやEntraなど、SAML対応の任意のアイデンティティプロバイダーでの認証。Cloudflare APIキーを生成して共有する必要をなくします。
  • 誰がゲートウェイへアクセスできるかを細かく管理できるポリシー設定。
  • URLにアカウントIDやゲートウェイIDを含めず、ai.example.comのようにシンプルなホスト名を使用したリクエストの送信。

Accessによって認証済みのすべてのリクエストにユーザーのID情報が付与されます。AI Gatewayは、確認済みのAccessユーザーIDをcf.user_idというリクエストメタデータに追加します。これにより、実際にリクエストを実行したユーザー単位で、ログ、分析情報、AI利用料金を確認・集計できます。

さらに、利用料金の上限設定と組み合わせることで、このユーザーID情報を予算管理にも活用できます。各リクエストに実際のユーザー情報が含まれるため、ユーザーごとに利用上限を設定できます。例えば、各ユーザーに個別の予算枠を割り当て、上限に達した場合はこれ以上リクエストできないようにブロックしたり、より安価なAIモデルへ自動的に切り替えることもできます。これにより、予想外の高額請求を防ぐことができ、また「誰がどれだけ使ったのか分からない」という共有APIキーの問題も解消できます。

早期導入企業の1社であるFlexportも、まさにこの問題に直面していました。

FlexportのスタッフセキュリティエンジニアであるMax Baumgarten氏は、「共有APIキーでは、誰がAIサービスを利用しているのかを把握することがほぼ不可能であり、従業員向けに設定している既存のアクセスルールを適用することも困難です。Cloudflare AccessをAI Gatewayの前段に配置することで、各リクエストに認証済みのIDを付与でき、既存のID管理ポリシーをゲートウェイで利用できるようになります。チームはクライアントごとに個別の認証システムを構築することなく、AIツールを導入できます。」と述べています。

今後、ユーザーのIDプロバイダー上のグループ情報を利用して、利用料金の上限設定や、アクセス可能なAIモデルの制御ができるようになる予定です。例えば、機械学習チームには最新の高性能モデルへのアクセスを許可する一方で、サポートチームには利用料金の上限を設定する、といった制御が可能になります。また、特定プロジェクトに関わるメンバーだけに予算枠を設定することもできます。これらはすべて、すでにIDプロバイダーで管理しているグループ情報と連携して実現できます。

新しく登場したタブ[User Insights]

AI Gateway内に、User Insightsという新しいタブが追加されました。User Insightsには、AI Gatewayを通過する通信を分析した、各アカウントの利用状況や行動パターンが表示されます。それぞれのアカウントの通常の利用状況学習し、そのパターンから外れた利用を特定し、その変化が「不正なAIエージェントによる異常な動作」なのか、「単に作業量が増えたエンジニアによる利用増加」なのかを判断するための情報を提供します。すでにAI Gatewayを通過している通信を利用するため、新たな設定や追加の導入作業は必要ありません。

User Insightsは、コスト管理にも対応しています。例えば、キャッシュヒット率が低いことによる無駄な利用や、必要以上に大きなコンテキストウィンドウの使用など、コスト増加の原因を把握できます。このようなコスト分析を行うツールはすでに数多く存在しますが、「そのアカウントの利用状況が通常の範囲内なのか」を判断する機能はありません。そのため、私たちはコスト管理機能に加えてこのような機能にも重点をおいています。 

すべてのアカウント(ユーザーとAIエージェント)の行動の基準化

人間とエージェントが残した独自の利用パターンを、時間の経過とともに蓄積します。例えば、3時間ごとに問い合わせ内容を要約するエージェントの行動パターンは安定しています。一方、人間のユーザーは、入力するプロンプトの内容や利用する時間帯、難しい課題に長時間取り組むことなどにより、利用パターンが不規則になります。どちらも正常な利用であるため、同じような変化が発生しても、エージェントでは異常の兆候となる一方で、人間では単なる利用のばらつきに過ぎない場合があります。

User Insightsでは、個々のリクエストではなく、セッション単位で利用状況を評価します。単純な固定のしきい値では、このような違いを正しく判断できません。例えば、普段から利用量が多いユーザーが500ドル多く利用したとしても、それは通常の範囲かもしれません。一方で、普段は5ドル程度しか利用しないエージェントが50ドル利用した場合は、利用量が10倍に増えたことになり、重大な異常である可能性があります。しかし、固定のしきい値だけでは、このような変化を見逃してしまうことがあります。User Insightsで各セッションをそのアカウント自身の過去の利用履歴と比較します。具体的には、過去30日間のセッションコストの95パーセンタイル(p95)を基準値として使用し、そのアカウントの普段の利用量を把握し、セッションコストがそのp95値の2倍を超えた場合、異常な利用である可能性が高いと判断します。

以下では、この判定基準をどのように導き出したのかについて説明します。

図1:セッションコストの異常検知

BLOG-3381 2.png

上のグラフの見方 

このグラフは、Cloudflare社内で実際に発生したセッションデータをもとに作成されています。それぞれの点は1つのセッションを表しており、横軸・縦軸ともに対数スケールで表示されています:

  • X軸(Session Cost):セッションで発生した合計コスト(米ドル)
  • Y軸(× User p95):そのセッションのコストが、ユーザー自身の通常利用の基準値(過去30日間のp95)を何倍上回ったか

グラフ内の2本の破線は基準線で、セッションを以下の4つのカテゴリに分類するためのものです:

  • 右上(★印):ユーザーごとの基準値(2× User p95)と、アカウント全体の上限値(p99)の両方を超える範囲。これは、通常より大幅に利用量が増えている異常な支出と判断され、アラート対象となります。 
  • 左上:ユーザー自身の基準値(2× User p95)は超えているが、アカウント全体のp99には達していない範囲。少額の利用増加による不要なアラートを防ぐため、このケースは異常として扱いません。
  • 右下:セッションコスト自体は高額であるが、そのユーザーにとっては普段からその程度の利用があるため、通常の利用と判断される範囲。このケースもアラートは発生しません。
  • 左下:ユーザーごとの基準値範囲。アカウント全体の基準値のどちらも超えておらず、通常の利用と判断されます。

図2:アカウント全体で見たセッションコストの分布

BLOG-3381 3.png

このヒストグラム(図2)は、組織内で発生したすべてのセッションコストを集計し、アカウント全体における利用上限の基準を示したものです:

  • 一般的な利用状況:大半のセッションコストは10ドル未満で、95パーセンタイル(p95)は20ドルです。
  • アカウント全体のp99(200ドル):組織全体で発生したすべてのセッションのうち、200ドル以上のコストになるセッションはわずか1%しかありません。

では、なぜp99を基準にしたのでしょうか。アカウント全体のp99を「絶対的なコスト上限」とすることで、異常と判断するための適切な基準を設けることができます。これにより、「特定のユーザーだけが普段より多く利用した」というだけでは異常とは判定されず、その利用が組織全体で見ても上位1%に入るほど高額なセッションである場合に初めて、異常である可能性が高いと判断できます。

図3:単一ユーザーのセッション履歴

BLOG-3381 4.png

基準値は固定値ではありません。アカウントの利用傾向が変化すると、それに合わせて過去30日間のp95(緑線)とその2倍のしきい値(オレンジ線)も自動的に更新されます。そのため、アラートは直近の利用状況を反映した基準に基づいて判定されます。また、コストについては最低金額も設定されています。つまり、アラートが発生するには、「統計的に見て通常とは異なる利用」であるだけでなく、「管理者が調査する価値がある程度の金額」であることも条件になります。この最低金額を設けることで、普段ほとんど利用しないユーザーが数セントしか使っていないにもかかわらず、その金額が500倍に増えたようなケースでも、実際の金額がごくわずかであればアラートは発生しません。

不正な利用を検出するための最適な視点 

これまで説明してきた分析を経て、管理者には通常の利用を除外し、それぞれのアカウントが自身の通常パターンから外れた利用だけを表示した画面が提供されます。この画面は、不審な利用を一覧で確認できるフィードとして機能します。

異常な利用状況(組織全体の概要)
異常な利用状況(組織全体の概要)

このような不審な利用の捕捉は、その兆候が「新しいツールを使い始めた」「禁止された操作を行った」といった分かりやすいものではなく、信頼されたアカウントによる、許可済みの実行内容であるため、捕捉することは困難です。例えば、サービスアカウントが突然これまでより高額なセッションを実行し始めたり、あるユーザーの利用量が通常の水準を大きく超え、その状態が数日間続いたりするケースが該当します。

異常な行動(セッション別に分類)
異常な行動(セッション別に分類)

これらはいずれもアクセス制御ポリシーには違反していませんが、そのアカウント本来の利用パターンから大きく外れています。こうした兆候は、資格情報が不正に利用された、あるいはエージェントが想定外の動作を始めたことを示す最初のサインである場合が少なくありません。

ユーザー単位の詳細データ
ユーザー単位の詳細データ

User Insightsは、利用者の意図を判断したり、自動的にブロックしたりするものではなく、通常の利用パターンから外れた行動を始めた少数のアカウントを管理者に提示し、管理者が「何が起きているのか」を確認できるようにするものです。その結果、本格的なセキュリティ調査が必要になる場合もあります。一方で、単にユーザーへの指導で済むケースもあります(例えば、開発者がコード全体を必要以上にプロンプトに貼り付けてしまうケース)。 

今後の展開は? 

コスト管理からコスト最適化へ

予算を設定した後、次に考えるべきことは、「どうすれば同等の出力品質をより低コストで得ることができるか」です。すべてのリクエストに、最高性能のAIモデルを使う必要はありません。例えば、文章の要約や簡単なコード補完であれば、より低コストなモデルでも、品質をほとんど落とさずに処理できる場合があります。

そこで現在私たちは、AI Gatewayが受信したリクエストの内容を分析し、必要な品質を維持しながら、最も低コストで処理できるモデルへ自動的に振り分ける「タスクベースのスマートルーティング」を開発しています。また、組織全体の利用状況を分析し、より効率的なモデルへ切り替えることで、どこで最もコストを削減できるかも確認できるようになります。タスクベースのスマートルーティングは現在開発中です。機能が成熟し次第、さらに詳しい情報をお知らせします。

AIがどのように利用されているかを把握できるようにします

異常検出では、アカウントが異常行動を示したことを知らせますが、その理由までは示しません。そのため、管理者はログを調査し、何が起きたのかを自ら分析する必要があります。私たちが次に取り組んでいるのは、このギャップを埋めることです。その第一歩として、リクエストがどのような用途なのかを自動で分類する機能を開発しています。

現在開発中のプロンプト分類機能では、リクエストを「コーディング」「文章作成」などのカテゴリに自動分類します。こうしたカテゴリ情報は、これまで多くの分析で欠けていた重要なコンテキストとなります。例えば、急増が、エンジニアが普段行っている「コーディング」カテゴリで発生しても問題視する必要はないかもしれませんが、その人が一度も利用したことのないカテゴリで発生した場合は注意が必要です。分類は、組織にAIの使用量だけでなく、その使用目的も示すことができます。 

さらに、この機能は、多くの組織が抱える「AIは、本来の業務目的に沿って利用されているのか?」といった根本的な疑問にも答えます。業務利用とそれ以外の利用を区別できるようになれば、私的な利用も見えるようになります。外部から見ると、「勤務時間中に副業のためにAIを利用している人」と、「AIモデルを使って社外へデータを持ち出そうとしている人」は、一見すると同じような利用に見えます。この2つを見分けられることは、インサイダーリスクを検知する上で非常に重要です。 

AI Gatewayを経由してAIを利用していれば、新たなリスク検知機能やコスト最適化機能が追加されても、管理者は特別な設定を行うことなく、それらの機能を利用できるようになります。

利用を開始する

User Insightsは本日より、すべてのAI Gatewayユーザーが追加料金なしで利用できるようになりました。すでにAI Gateway経由でAIを利用している場合は、ダッシュボードからこの機能を利用できます。 

まだAI Gatewayを利用していない場合は、ゲートウェイを作成し、カタログに用意されている任意のAIモデルへのリクエストを送信してみてください。 

AI Gatewayを現在オープンベータ中のCloudflare Accessの背後に配置することをお勧めします。利用料金や異常検知の機能はCloudflare Accessがなくても利用できますが、ユーザーのID情報と紐付けることで、匿名のアカウントIDではなく、「誰が利用したのか」を特定できるようになります。まずは、通常時の利用パターン(ベースライン)を把握することから始めることをお勧めします。

皆様が現在どのようにAIを管理しているか、ぜひお聞かせください。Discordで議論に参加するか、担当のアカウントチームまでお気軽にご連絡ください。