Claude Media
ClaudeとVantaを連携してAIインベントリを作る — 取り込み範囲と穴
ClaudeClaude連携解説

ClaudeとVantaを連携してAIインベントリを作る — 取り込み範囲と穴

VantaのAI InventoryはClaude Compliance API経由でChat・Claude Code・Coworkの利用を集めます。同期の周期と遡る期間、Enterprise前提、載らない利用経路を確認します。

読了目安 約8分

VantaのAI Inventoryは、Claudeの利用をClaude Compliance APIから自動で集め、AIインベントリに載せる機能です。取り込むのはClaude Chat、Claude Code、Claude Coworkの3つで、同期は既定で4時間ごとに走ります。AI Governanceの一部として早期アクセス(early access)の段階にあります。

監査でAIの利用実態を聞かれたとき、手作業の棚卸しより速く答えられる半面、インベントリに載るのは「Compliance APIが捉えた範囲」だけです。Vantaの連携ページと、Compliance API側の仕様を突き合わせて、何が入り何が抜けるかを確かめます。

Vantaが取り込む対象と同期の仕組み

Vantaの連携ページによると、AI InventoryはCompliance APIから予定された周期でデータを取得します。ページに書かれた条件は次の4点です。

数字

Vantaの取り込み条件

  • 対象プロダクト

    3つ

    Claude Chat / Claude Code / Claude Cowork

  • 同期の周期

    4時間

    既定値

  • Chatの遡り期間

    30日

    チャットとチャット作成イベント

  • Code・Coworkの遡り期間

    7日

    セッション、既定値

Vantaの連携ページの記載

数字の読み方で迷うのは「遡り期間」です。これは各回の同期が過去どこまで読むかの窓で、Claude側の保持期間ではありません。Activity Feedは6年分の組織活動を保持するので、Vantaが毎回読む30日・7日とは別の話になります。

窓が重なる設計でもあります。4時間ごとに過去7日分を読むので、同じセッションが何度も読まれます。取りこぼしを避けるための作りと考えられますが、重複の扱いやバックフィルの有無は、連携ページに記載がありません。連携を数日以上止めた場合に、止めていた間のセッションが戻るかどうかは、Vantaに問い合わせて確かめる項目です。

窓の違いにも意味があります。Chatは30日、Claude CodeとCoworkは7日です。つまり、連携を入れた直後に見えるインベントリは「直近30日のチャット」と「直近7日のセッション」から始まります。過去1年分の利用を監査期間の証跡に出したい場合、このインベントリだけでは足りません。

連携の前に満たす条件

Compliance APIは、Claude Enterpriseの組織とClaude Consoleの一部の組織が使えます。Claude Enterpriseでは、主オーナー(primary owner)がclaude.aiの組織設定のAPIページで有効化します。有効化は親組織から、リンクされたすべての組織へ引き継がれます。

キーは2種類あります。Compliance Access Keyはclaude.aiで作り、すべてのエンドポイントに届きます。Admin APIキーはClaude Consoleで作り、Activity Feedにしか届きません。チャットやセッションの中身を読むには、Compliance Access Keyが要ります。

Vantaの連携ページには、どちらのキーを使うか、どのスコープが要るかの記載がありません。セッションの文字起こしはread:compliance_user_dataのスコープで読みます。Activity Feedはread:compliance_activitiesです。Vanta側の設定画面が求めるスコープに合わせ、必要最小限で作るのが公式の考え方です。読み取りと削除は別のキーに分け、読み取りキーが漏れても削除されない形にします。スコープは作成後に変更できず、変えるときは新しいキーを作って古いキーを消します。

キーの作り方とスコープの選び方はCompliance APIのセットアップに手順があります。APIの全体像はClaude Compliance APIとはにあります。

インベントリに載らない利用経路

ここが、監査対応でいちばん見落としやすい点です。Compliance APIのセッション取得は、ユーザーがClaude Enterpriseのアカウントでサインインしている間に、リクエストがClaude APIへ届いた分を捉える仕組みです。端末には何も入れません。逆に言えば、次の利用はVantaのインベントリにも出てきません。

  • Claude Consoleで作ったAPIキーで認証したClaude Codeのセッション
  • Amazon Bedrock、Google Cloud、Microsoft Foundry経由のClaude Code
  • Claude Codeのクラウドセッション(Claude Code on the web)
  • APIキーで動くClaude APIのワークロード。プロンプトや応答の本文は取得できません
  • 端末の中で完結し、APIに送られない操作

開発チームが社内ルールを知らずにBedrock経由でClaude Codeを使っていれば、インベントリにその利用は現れません。「インベントリに載っていない=使われていない」とは読めない構造です。インベントリの網羅性を監査人に説明するときは、この除外範囲を一緒に示すほうが安全です。

もう一つ、プロダクトの名前の対応にも注意が要ります。Compliance API自体はClaude Science、Claude for Microsoft 365、Claude in Chromeのセッションも扱います。Claude ScienceとClaude in Chromeは、セッション取得がベータの扱いです。一方、Vantaの連携ページが対応プロダクトに挙げるのはChat、Claude Code、Coworkの3つだけです。APIが返せる範囲と、Vantaが取り込む範囲は一致しません。

除外範囲の詳しい一覧はCompliance APIのFAQに、セッション取得の仕様はセッションの文字起こしを取得する手順にあります。

中身は見られるのか

Vantaの連携ページは、取り込む対象を「データ」と書いていますが、プロンプトや応答の本文を保存するとは書いていません。インベントリの目的は、どのツールがどれだけ使われているかの台帳です。

押さえておくべき一般仕様は、Activity Feedが「誰がいつ何をしたか」を記録するだけで、プロンプトや応答のテキストを含まないことです。本文はチャットやメッセージのエンドポイントで、別のスコープで取りに行きます。Vantaがそこまで読むのか、Activity Feedの範囲にとどまるのかは、連携ページから判断できません。

ユーザーが削除したチャットも、一覧には残ります。deleted_atが入り、中身は返りません。インベントリ上は「使われた形跡」として残り、内容の確認はできない、という見え方になります。

同じCompliance APIを読む他のツールとの役割分担

Compliance APIの出口は、Vantaだけではありません。公開されている連携先を並べると、同じ入口から別の目的の出力が出ているのが分かります。

連携先主な目的前提として書かれていること
Vanta AI Inventory主な目的AIの利用を台帳化し、統制と突き合わせる前提として書かれていること早期アクセス
Datadog主な目的監査ログの監視とSIEM用途前提として書かれていることEnterpriseプラン、Compliance API有効化
Cloudflare CASB主な目的DLPに違反する公開プロジェクトやチャット内容の検出前提として書かれていることCompliance API連携
Netskope AI Command Center主な目的AI資産と設定の可視化、DLP違反の把握前提として書かれていることプレビュー、Compliance Access Key

Datadogの連携は、Admin APIキー(read:compliance_activities)かCompliance Access Keyのどちらかを使う前提です。ログを流し込んでSIEMの検知ルールで見る使い方で、台帳を作るVantaとは出口が違います。CloudflareのCASBは、公開設定のプロジェクトや、DLPポリシーに違反するチャット・ファイル・成果物の検出が中心です。NetskopeのAI Command Centerは、Compliance Access Keyで接続する形で、記載上はプレビュー扱いです。

監査対応の観点では、Vantaは「誰がどのAIをどれだけ使っているか」の説明に向き、違反の検知や調査はSIEMやCASB側が担う、という分担になります。Vantaに入れたからといって、検知まで任せられるわけではありません。SIEMへの流し込み方はCompliance APIのSIEM連携で解説しています。

監査に使う前に確かめる5点

早期アクセスの機能を、監査の証跡にそのまま乗せるのは避けたいところです。確認の順番を並べます。

  1. Claude Enterpriseのテナントで、Compliance APIが有効か。無効の間は活動が記録されず、あとから戻せません
  2. 連携に渡したキーの種類とスコープが、取り込みたい範囲に足りているか
  3. BedrockやConsoleキー経由のClaude Code利用が、組織内にないか。ある場合は別の経路で台帳に足す必要があります
  4. 連携を止めた期間と、Vantaの窓(Chat 30日、Code・Cowork 7日)の関係
  5. 早期アクセスの仕様が、監査期間中に変わらないか

2点目は、Compliance APIを直接叩いて確かめられます。Activity Feedの最新1件を取るだけの呼び出しです。キーが有効で、read:compliance_activitiesが付いていれば成功します。

curl --fail-with-body -sS \
  "https://api.anthropic.com/v1/compliance/activities?limit=1" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

応答のdataにActivityが1件返れば、キーとスコープは通っています。例えばtypeがclaude_chat_createdのように返ります(公式の応答例に沿った形です)。403なら、スコープが足りないか、Admin APIキーで内容系のエンドポイントを叩いています。

文書化との使い分け

ISMSやSOC 2の審査では、AIの利用ルールの文書と、実際の利用状況の証跡の両方が求められます。ルールの文書をClaudeで下書きする手順はISMSの適用宣言書をClaudeで下書きするにまとめています。VantaのAI Inventoryは、その文書に対する「実態」の側を担います。文書は下書きの段階でClaudeを使えますが、利用実態の台帳は、Claudeに書かせるのでなく、Compliance APIの記録を元に作るものです。

まとめ

VantaのAI Inventoryは、Compliance APIを4時間ごとに読み、直近30日のチャットと直近7日のセッションをインベントリに入れます。入口がCompliance APIである以上、Enterpriseの外の利用や、Consoleキー・Bedrock経由のClaude Codeは載りません。連携を入れる前に、自社のClaude Codeがどの経路で認証されているかを洗い出すと、インベントリの穴の大きさが分かります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude をもっと見る →