UberのCISOが語るAIの内部脅威対策 — EFSとADRを併用する構成

要点

10月13日に公開されたインタビューで、UberのCISO(最高情報セキュリティ責任者)であるPhilip Martin氏が、AIの監視を「モデル向けの内部脅威対策プログラム(insider threat program)」として位置づけました。

• AIにも従業員向けと同じ発想の対策が要る:どの企業も人向けには内部脅威対策を運用しており、データ保持の負担も望まない監視も受け入れている。フロンティアモデルも同じリスクを持つので、同等の仕組みが必要だという主張です
• UberはEnterprise Frontier Safeguards(EFS)の設計にフィードバックを寄せ、それが反映されたと語っています:安全策は有効なまま、Uberのデータは許可なしにAnthropicへ渡らない構成を評価しています
• 自社の検知基盤と二本立てで運用します:Uberがオープンソース化したAI Detection and Response(ADR)が、エージェントの実行環境(ハーネス)からリアルタイムのテレメトリを集めます。Anthropicの分類器の出力も同じ検知環境に取り込めます
• 次の優先課題は2つです:プロンプト入力の時点に近い場所でのリアルタイム検知と介入、そして新しいモデル挙動のパターン把握です

全体のメッセージは、EFSは単体の防御ではなく自社の検知体制に差し込む「データ源」になる、という点にあります。EFSそのものの仕組みと提供条件は、Enterprise Frontier Safeguardsの発表記事で扱っています。

この話は誰の判断を変えるか

AIの監視設計に責任を持つ人にとっては、検知を誰が持つかを決めるときの材料になります。

このインタビューに新機能の発表は含まれていません。語られているのはUberの運用と考え方で、EFSの提供開始時期や条件は変わっていません。EFSは「今秋後半から段階的に」の提供で、広く使えるようになるまでは対象顧客に経過措置が用意されています。

Uberが置いているAIセキュリティの構成

Uberは1日に4,000万件を超える乗車と配達の注文をさばく、世界最大級のリアルタイム市場を運営しています。守る対象は、顧客データと営業上の機密に加えて、現実世界で使うライダー、ドライバー、配達員です。

インタビューによると、同社のセキュリティチームはClaude Codeが登場する前から、脅威モデリングにClaudeを使ってきました。当時はコンテキストを人が手で組み立てていました。いまはClaude Fableがコードや設計文書、チケットの履歴から必要な文脈を自分で集めます。

Martin氏は、フロンティアモデルの最大の違いを「長い時間軸で追加のコンテキストを取り込める力」だと語ります。サービスごとにそのサービスをよく理解したエージェントがつき、エージェント同士が脅威モデルを会話する将来像も描いています。モデルが自分で文脈を集めて動くようになるほど、そのモデル自身の動きを見る仕組みも要ります。Uberの構成は、この問題意識への1つの答えとして読めます。

構成

UberのAIセキュリティ構成の3要素

• LLMゲートウェイ

  Uber社内でAIをどう使うかを制御し、外周(perimeter)をつくります。

• ADR(AI Detection and Response)

  Uberがオープンソース化した製品です。運用中のエージェントハーネスからリアルタイムのテレメトリを集め、その場で対応します。

• Anthropicの安全策(EFS)

  Anthropicの分類器の出力を提供します。Martin氏は、将来EFSがADRのデータ源として流れ込むと見ています。

3つは役割が違います。Martin氏はこれらを合わせて、Uberの全体的なAIセキュリティアーキテクチャと呼んでいます。

EFSの何がUberに合ったのか

Martin氏が挙げた理由は、安全の向きが違う2社が同じ構造を選べたことです。Anthropicが防ぎたいのはフロンティアモデルの悪用で、Uberが守りたいのは顧客データ、営業上の機密、その他の独自情報です。

EFSなら、安全策は動いたまま、データはUberの許可なしにはAnthropicに見えません。安全策が作動した後にどう動くかの判断もUber側に残ります。同氏は、設計の説明を受けた際にフィードバックが反映されており、運用側を運転席に座らせる設計だったと述べています。

この構造はEFSの発表記事にも書かれています。監視用の活動データを顧客のクラウドアカウントに置け、検知されたシグナルは顧客へ直接送られます。Anthropicの従業員による確認は不要です。

Uberの話で新しいのは、その上に自社の検知を重ねる運用です。インタビューによれば、Uberは自分たちの視点に加え、Anthropicの分類器の出力を持ち、両方を従来のサイバーセキュリティに近い検知環境へ統合できます。判断の目的は、できるだけ速く、できるだけ確かな根拠で結論を出すことです。

次に防御側が優先すること

Martin氏は優先事項を2つ挙げています。

手順

Uberが挙げた防御側の優先順位

1. 1

   リアルタイムの検知と介入

   プロンプトをハーネスに入力する人に、できるだけ近い位置で働くことを目指します。「それはおそらく望ましくありません」と本人に伝える。あるいは、モデルが次に呼ぶツールや接続先が望ましくないと知らせる、という例です。

2. 2

   新しいパターンの把握

   モデル挙動の傾向を見て、知らなかった挙動を見つけます。多くの場合はLLMの助けを借りて分析し、見つけた挙動への安全策をリアルタイムの基盤に戻します。

2つ目には循環があります。同氏は、制約を加えると新しい挙動が出てくるので、それも見つけてさらに安全策を足す、と説明しています。

EFSの価値は「検知を誰が持つか」の線引きにある

このインタビューの核は、新しい防御技術の紹介ではありません。責任の置き方を、すでに企業が持っている言葉で語り直した点にあります。

Martin氏の主張は、内部脅威対策の対象を人からモデルへ広げる、というものです。

くらべる

内部脅威対策の対象を、人からモデルへ広げる

いま

従業員向けの現行プログラム

データ保持と監視を、負担を承知で受け入れています。人が役割の外で動くことがあるという前提です。

これから

モデル向けに求められるもの

モデルが期待された制約の外で動くよう仕向けられるリスクに対し、同等の能力を用意します。

この枠組みの利点は、社内の合意が取りやすいことです。「AIを監視する」は新しい議論になりますが、「内部脅威対策の対象にエージェントを加える」なら既存の議論の延長に置けます。監視に慎重な組織でも、EFSのようにデータを顧客側に置いたまま回せる形なら、保持と監視の両立という既知の論点として扱えます。

一方で、読む側が割り引くべき点が2つあります。

1つ目は、EFSがADRのデータ源になる話は、Martin氏の見通しであって発表済みの機能ではないことです。インタビューは「そうなると思う」という語り方で、連携の方式や対象モデルの範囲は記載されていません。連携を前提に設計を組むための情報は、まだ公開されていません。

2つ目は、このインタビューがAnthropicの媒体に載った顧客の証言であることです。Uberの運用に固有の前提(ゲートウェイ、独自のOSS、専任のセキュリティ組織)が、そのまま他社に当てはまるとは限りません。ADRの対応環境や導入手順は、このインタビューには載っていません。使うなら公開されているリポジトリの説明で確かめる必要があります。

言い切れることもあります。モデルの出力を見張る側は、ベンダーの分類器だけに任せても、自前のログだけでも足りません。Uberの構成が示すのは、両方を同じ検知環境で突き合わせる設計が現実に運用されている、という事実です。

同時期の動きとのつながり

Anthropicは同じ時期に、顧客事例を通じて安全策の運用面を語る記事を続けて出しています。Blockは数百から数千本のプルリクエストにまたがるコード移行でFable 5を回す運用を語り、安全策はフロンティアの知能を責任をもって展開する要所だと語っています。詳しくはBlockのFable 5によるコード移行の記事にまとめています。

Anthropic側の安全策の全体像、つまりどの層がどう働き警告が何を意味するかはClaudeのセーフガードチームの解説で扱っています。顧客の監視基盤とベンダーの安全策を分けて考えるときの前提になります。

まとめ

Uberの事例から読み取れるのは、EFSの価値がAnthropic側の防御の強さだけでなく、自社の検知環境に差し込めるかどうかで変わるという点です。ADRとの連携はMartin氏の見通しなので、確定した仕様とは分けて、判断と対処を自社に残せるかを軸に見ると比較しやすくなります。個人や小規模チームには直接の変更はありません。

内部脅威対策はもともと、人が悪意だけでなく事情や誤りで役割の外に出ることを前提にした仕組みです。エージェントに任せる仕事が増えるほど、同じ前提で見張る必要が出てきます。Martin氏はAIの導入を事業上の必須事項と位置づけつつ、モデルが高性能になり自律的な作業を担うほどリスクも上がると述べています。