Cloudflare、AI利用の監査と
セキュリティ監査スキルを公開
従業員とAIエージェントをIDで結び付け、誰が何をAIに送ったかを可視化するIdentity-Aware AI Gateway。あわせて、AIエージェントにコード監査をさせるMarkdown指示書とバリデータがMITで公開されました。2026.10.16
Cloudflareは、企業内のAI利用を「誰が・何を」まで可視化するIdentity-Aware AI Gatewayを発表しました（2026年8月5日）。あわせて同社は、AIエージェントにコードのセキュリティ監査をさせるための指示書一式をGitHubで公開しています。統制側の発表と、監査側のオープンソースを分けて整理します。
- 確認済み 公式ブログ・GitHub・一次資料で確認した事実
- 提供元公称 開発元・ベンダー自身の発表。第三者検証は未完了
- 第三者検証 外部の開発者・メディア・実測者が独自に確認したもの
- AIfrontierの見解 編集部の解釈
1. 誰がAIを使っているかを、IDで縛る提供元公称
発表の中心は、アイデンティティ管理製品のCloudflare Accessと、AIトラフィックを中継するAI Gatewayを直結させる仕組みです。これにより、すべてのAIリクエストに、従業員または自動化システムの確認済みIDが紐付きます。誰がモデルに何を送ったのかを特定し、個人やチームごとに利用上限を設定し、リスクのあるコンテンツを自動検出できるとしています。新しいシステムの構築は不要で、従業員への業務上の影響もないとされています。 出典：Cloudflare
背景として同社が挙げているのは、2つの逆向きの圧力です。1つはコスト。1回あたりのAI利用料金は下がっている一方で、従業員や自動化ボットによる利用回数が大幅に増えているため、請求額が想定を超えて膨らむケースが増えています。もう1つはセキュリティで、従業員名、パスワード、機密ファイルといった情報が、気付かないうちに外部のAIサービスへ送信される可能性があります。
従来のツールでも、アカウント全体のAI利用額に上限を設けることはできました。しかし、誰がその費用を発生させたのか、どのようなデータがAIへ送られたのかまでは把握できません。結果として、IT部門は問題が起きた後の対応に追われ、事前の防止が難しくなります。
—— Dane Knecht氏（Cloudflare CTO） 出典：Cloudflare
導入事例として、物流大手Flexportのセキュリティエンジニア、Max Baumgarten氏のコメントが掲載されています。共有APIキーでは誰がAIサービスを利用しているかを把握するのがほぼ不可能で、既存のアクセスルールを適用することも難しい。AccessをAI Gatewayの前段に置くことで、各リクエストに認証済みIDを付与でき、クライアントごとに個別の認証システムを構築せずにAIツールを導入できる、という内容です。
2. User Insights：逸脱の検知と、安いモデルへの誘導提供元公称
同時に提供されるUser Insightsは、ネットワーク上の各個人や自動化システムの通常のAI利用パターンを学習し、そこから逸脱したときにIT部門へ通知します。単純に金額の上限を張るのではなく、その人の基準線からのズレを見る点が特徴です。
もう1つ見落とされやすいのが、過剰な高性能モデル利用の検出です。簡単な処理にも高性能モデルを使っているケースを洗い出し、より低コストで足りるモデルへ切り替えられる箇所を特定します。値下げ競争で単価が下がっても請求額が増える構造に対して、利用回数とモデル選択の両側から手を入れる設計です。
| 機能 | 内容 | 何が変わるか |
|---|---|---|
| IDの紐付け | AccessとAI Gatewayの連携。リクエスト前にユーザー・デバイスの状態を確認し、確認済みIDをログへ記録 | 共有APIキーをやめ、誰が送ったかを特定できる |
| 基準線の学習と逸脱検知 | 各ユーザー・自動化システムの通常パターンを継続的に追跡し、急増時に通知 | 想定外のコスト増を、請求後にではなく発生時に把握する |
| モデル最適化の提案 | 簡単な処理に高性能モデルを使っていないかを検出 | 品質を落とさずに単価を下げる余地が見つかる |
| レート制限とキャッシュ | 利用量制限と、繰り返しリクエストのキャッシュ | 過剰利用による予想外の請求と冗長なコストを抑える |
| 機密情報のフィルタ | 従業員名、パスワードなどの機密情報を外部へ送る前に除去 | 情報漏えいの経路そのものを細くする |
| 一元管理 | AIツール・モデル提供元ごとではなく、すべてのAIリクエストを1点に集約 | IT部門がAI利用全体をリアルタイムで把握できる |
AIfrontierの見解 実務的な価値は、機能の多さよりも「止めずに測る」方向に倒れている点にあります。AI利用を禁止・制限する統制は、現場が抜け道（個人アカウント、私物端末）を作るだけになりがちです。IDで結び付け、基準線から外れたときだけ通知する設計は、統制と利便性のトレードオフを運用で解こうとしています。
3. 監査スキル：Markdownの指示書と2本のバリデータ第三者検証
もう1つが、CloudflareがGitHubで公開したSecurity Audit Skillです。同社が自社の脆弱性ハンティング基盤を作る際の出発点になったもので、MITライセンスで公開されています。中身はコードではなく、Markdown形式の指示書一式です。これをコードエージェントに読み込ませると、単なるコードレビュアーではなく、監査担当者のように動くようになります。 出典：Korben
リポジトリには、攻撃の種類ごとの指示ファイル（メモリ破壊、プロンプトインジェクション、HTTPリクエストの範囲設定、テナント間の分離など）に加えて、レポートの形式を定義したJSONスキーマと、依存関係ゼロで書かれた2つのJavaScriptバリデータが含まれます。
エージェントは偵察から最終レポートまで6つのフェーズを進みます。まずアーキテクチャや信頼境界、エントリーポイントをマッピングし、次に独自のカバレッジ表を作成。それから区画ごとに独立したハンターを送り込み、見つかった手がかりはすべて、ハンティングに一切関与していない検証役へ渡されます。最終的な技術レポートは3種類に分かれます。
| 判定 | 意味 |
|---|---|
| confirmed | 完全なソーストレースと、実際に観測された結果を要求する |
| needs_validation | 何が足りないのかを具体的に指摘する。重大度は一切付けない |
| rejected | これまで却下された内容を記憶し、次のパスで同じ話が蒸し返されるのを防ぐ |
バリデータは証拠の形式を検証する本物のコードです。フィンガープリントは一意でなければならず、テストの経路はエントリーポイントから始まって影響ポイントで終わっている必要があります。そのため、確認済みの発見であっても経路がおかしければ却下されます。
検証役の独立性は指示書の中で「要求」されているだけで、実際にチェックされているわけではありません。Cloudflare社内では自社製のオーケストレーターがこれを担っていますが、一般には公開されていません。 出典：Korben
なぜ、これほど細かく手順を縛るのか。Cloudflareは自社サイトで、エージェントを何のガードレールもなしにコードへぶつけたらどうなるかを説明しています。エージェントはエクスプロイトが動くようにソースコードそのものを書き換えてしまい、そのうえで自分が作り出したバグを堂々と報告してくる。あるいは、exec()が何かを実行することを示すだけのテストを書いて「だからこれは重大な脆弱性だ」と主張してくる。指示書は、まさにこうした挙動を禁じるために作られています。
4. 導入と運用の実際第三者検証
導入にはVercel Labsのskills CLIを使います。監査したいリポジトリの中でエージェントを起動し、セキュリティ監査を依頼すると、スキルが自動的に起動し、モデルがサブエージェントを並列で指揮します。既定の出力先は~/security-audit-skillで、監査対象のリポジトリの外側です。バリデータの実行にNode.jsが必要です。
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit運用上、重要な制約が3つあります。
- サンドボックスがないと動かない。OSレベルで強制されたサンドボックス（ネットワーク遮断、対象は読み取り専用、CPUとメモリに制限）がない状態では、監査対象のコードを実行することを拒否します。サンドボックス自体はリポジトリに含まれないため、Fenceのような分離ツールを自分で用意する必要があります。これがないと、監査の手がかりはきちんと追跡・判定されることなく、
needs_validationで終わります。 - 時間がかかる。Cloudflareの大規模環境では約3万行規模のリポジトリでも3〜4時間で十分な結果が得られるとされていますが、ローカル環境ではもっと時間がかかります。
- 1回のパスでは足りない。Cloudflareは、毎回見つかる脆弱性はだいたい半分程度にとどまると警告しています。複数回実行する必要があります。
プルリクエストの差分を読んでコメントを付ける用途には、AnthropicがClaude Code向けに提供しているセキュリティレビュアーがあります。用途が違うので、両方を併用する形になります。
5. 提供状況と、監査スキルの広がり第三者検証
発表当時の提供形態と、その後の展開を整理します。アイデンティティ対応のAI Gatewayはオープンベータで、User Insightsは全AI Gateway顧客に一般提供されています。User Insights自体は追加料金なしで使えるとされています。 出典：Cloudflareブログ
| 項目 | 現在地 |
|---|---|
| アイデンティティ対応AI Gateway（Access連携） | オープンベータ |
| User Insights | 全AI Gateway顧客に一般提供（追加費用なし） |
| 逸脱の検知方法 | 各ユーザーの通常利用の基準線を学習し、想定外の急増をフラグ（第三者解説では通常の2倍＝2×p95を超えた場合と説明） |
| 公式ドキュメントの変更点（8月5日） | 認証済みユーザー単位の支出上限、ユーザーごとにアクセスできるゲートウェイの制御、ユーザー単位でのログ絞り込み |
つまり「誰がいくら使ったか」を止めるのではなく測って配分する方向の機能が、順に開放されている段階です。IT部門が最初に使うのは、おそらく支出上限とログの絞り込みでしょう。前者は予算の暴走を止め、後者は「あのリクエストは誰か」を後から特定できるようにします。
Cloudflareは別のブログで、このスキルの成り立ちを明かしています。出発点は約450行の指示書で、まず1つのリポジトリに対して走らせ、実際のバグが出てくるまでプロンプトを調整し続けたというものです。公開されているのはその調整済みの版ですが、自社コードに当てる際は同じ調整が必要になると考えるのが自然です。 出典：Cloudflareブログ
公開後の反応も上々で、第三者の集計ではGitHubのスターが2万5,000を超えています。Hacker Newsでも議論が立っており、関心は「脆弱性をどれだけ見つけるか」より「独立した検証役をどう担保するか」に集まっています。ここは指示書が要求するだけで強制していない部分であり、導入する側が自分で設計するしかありません。 出典：explainx
6. 見えてきたことAIfrontierの見解
「誰がAIを使っているかを可視化する」と「AIにコードを監査させる」は、同じ可視性の問題の表裏です。ただし確度は違います。前者は提供元の公称が中心で、第三者による検証はまだ薄い。後者はMITライセンスのコードとして読めるので、実際に動かして確かめられます。
監査スキルを業務に入れるなら、順序が重要です。①サンドボックスを先に用意する、②複数パスを回す前提で工数を見積もる、③レポート形式の検証をCIに組み込む、④検証役の独立性は自分で担保する（指示書任せにしない）。エージェントの監査結果をそのまま信じるのではなく、その結果を検証する仕組みを先に作る。Cloudflare自身が「ガードレールなしでは、エージェントは自分が作ったバグを報告してくる」と書いていることが、この順序の根拠です。
出典
- Cloudflare プレスリリース「企業がAI利用を完全に可視化し、監査・分析できるように」（2026年8月5日） https://www.cloudflare.com/ja-jp/press/press-releases/2026/cloudflare-gives-companies-full-visibility-to-audit-and-analyze-ai-use/
- Cloudflareブログ「ID情報に基づく分析で、不正なAIの利用を検出」 https://blog.cloudflare.com/identity-aware-ai-gateway/
- Cloudflare AI Security（製品ページ） https://www.cloudflare.com/ja-jp/solutions/ai-security/
- Korben「Cloudflareが、AIによるセキュリティ監査スキルを公開」（フランス語記事の日本語訳） https://korben.info/ja/cloudflare-ai-security-audit-skill.html
- Cloudflare Security Audit Skill（GitHub、MITライセンス） https://github.com/cloudflare/security-audit-skill
- Cloudflareブログ「ID情報に基づく分析で、不正なAIの利用を検出」（identity-aware AI Gatewayはオープンベータ、User Insightsは一般提供） https://blog.cloudflare.com/identity-aware-ai-gateway/
- Cloudflare開発者ドキュメント 変更履歴「Identity-aware controls are now available in AI Gateway」（2026年8月5日） https://developers.cloudflare.com/changelog/post/2026-08-05-access-user-id-metadata/
- Cloudflareブログ「Build your own vulnerability harness」（約450行の出発点とプロンプト調整） https://blog.cloudflare.com/build-your-own-vulnerability-harness
- explainx「cloudflare security-audit-skill: 6 phases, 25.6k stars」 https://explainx.ai/blog/cloudflare-security-audit-skill-open-source-agent-vulnerability-hunting-2026