Claude利用をOkta ISPMで洗う — Compliance API連携で見えるIDリスク

Okta Identity Security Posture Management(ISPM)は、Claude Compliance APIとの連携で、Claude EnterpriseとClaude Platformのアカウント状況をOktaの画面に取り込みます。洗い出せるのは、使われていない管理者キー、退職者のアクティブなアカウント、過剰な管理者権限、休眠アカウントの4種類です。発表は2026年5月21日で、提供形態は一部顧客向けのベータとされています。

SAMLとSCIMでClaudeにログインさせる設定は、Claude Okta SSO設定で扱っています。ここで扱うのはその先です。SSOを通した後の「誰がClaudeに入っていて、何の権限を持ち、使われているか」を、ID基盤の側から継続的に点検する話になります。

ISPM連携で何が見えるようになるのか

発表は、Claudeのような生成AIを「侵害されたときの影響が通常のSaaSより大きい対象」と位置づけています。業務データ、コード、ワークフロー、接続先ツールまで広く触れるためです。そのうえで、ISPMとCompliance APIの連携が見つける対象を4つ挙げています。

Anthropic側の連携一覧は、Oktaの説明をもう少し広く書いています。Claudeの利用状況を他のIDプラットフォーム、SaaS、クラウドの信号と突き合わせ、過剰な権限を持つユーザー、休眠アカウント、未使用の管理者キーなどを1つの画面にまとめる、という説明です。突き合わせ(コンテキスト化)こそがISPMの役割で、Claude単体の管理画面では出ない見方が得られます。

Claude側のどのデータがOktaの検出に使われるのか

Compliance APIが返すデータは、製品で違います。Claude Enterpriseではチャットやファイルなどの会話内容に加えて、ユーザーのログイン、管理者操作、設定変更を含むActivity Feedが取れます。Claude Platformで取れるのはActivity Feedで、メンバーやワークスペースの変更、APIキーの作成、アカウント設定といった管理・システムイベントが入ります。Platformではプロンプトやモデル応答の内容は取得できません。

ここで押さえたいのは、Oktaが挙げた4種類の検出はどれも「ID・権限・キー・利用の有無」の話であり、会話内容を必要としない点です。ISPMの目的に、チャット本文は要りません。会話内容を読むDLP系の連携とは、守る対象が違います。

右端の列は、Claude側の公開仕様から対応づけた読み方です。Okta内部でどのエンドポイントを呼ぶかは、発表にも連携一覧にも書かれていません。Compliance APIの構造はClaude Compliance APIとはで、Activity Feedの引き方はActivity Feedの使い方で扱っています。

提供状況と、始める前に必要なこと

発表時点の案内は、一部の顧客に向けたベータで、OktaのISPMとClaude EnterpriseまたはClaude Platformを併用している組織が対象です。始め方は「Oktaの担当者に問い合わせる」とされています。Anthropicの連携一覧にも、OktaについてはセットアップガイドではなくLearn moreのリンクが付くだけです。自分で有効化できるボタンを前提にせず、担当者との調整から入る前提で動くのが現実的です。発表文の末尾には、将来の製品や機能への言及は情報提供のみを目的とし、提供の約束ではなく購入判断の根拠にしないよう求める注記も付いています。

Claude側の準備は決まっています。Claude Enterpriseでは、Compliance APIを有効にできるのは組織のPrimary Ownerだけです。キーは同じ画面から作れます。Primary Ownerはリンクされた全組織を覆うキーを、Ownerは自分の組織に限ったキーを作れます。Adminにはこのページ自体が見えません。親組織にリンクされている場合は、親組織のPrimary Ownerが有効化し、設定がリンクされた全組織に及びます。Claude Platformでは、Anthropicの営業担当に問い合わせる流れです。

連携用のキーを渡す相手は外部のSaaSです。read:compliance_user_dataを持つキーはチャットの中身まで読めるため、ISPMの用途に必要なのはActivity Feed用のスコープだけかを、作成前に確認します。キー作成の手順とスコープの選び方はCompliance APIのセットアップとアクセスキー作成にまとめています。

連携を待たずに、手元で同じ点検をする

ベータを待つあいだも、Activity Feedを直接引けば同種の点検を試せます。たとえばサインインの入口を見るなら、SSO開始のイベントで絞ります。

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --data-urlencode "activity_types[]=sso_login_initiated" \
  --data-urlencode "created_at.gte=2026-09-01T00:00:00Z" \
  --data-urlencode "limit=100" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01"

sso_login_initiatedはサインイン完了前の操作で、actor.typeがunauthenticated_user_actorになり、メールアドレスはunauthenticated_email_addressに入ります。ユーザーとグループの一覧はCompliance APIで組織のユーザーとグループを取得する手順で引けます。そこで得た一覧をIdPのユーザー一覧と突き合わせれば、退職者の残存を手元で確かめられます。IdPとの突き合わせに使える共通の手がかりはメールアドレスです。一方、Activity Feedのイベントとユーザー一覧を結ぶときは、メールの変更に左右されないactor.user_idを使えます。取り込みの設計はCompliance APIのSIEM連携に書いたとおりです。

手元の突き合わせは、点検を一度試すには足ります。ただ毎日回す運用になると、キーの保管、取りこぼしのない窓の進め方、他のIDソースとの名寄せが自前の仕事になります。ISPMのような製品に任せる価値は、この継続運用の側にあります。

「SSOの外から入る」リスクは、Oktaの検出項目には書かれていない

「SSO外ログイン」も洗えると思われがちですが、Oktaの発表が挙げる4項目に、SSOを迂回したログインの検出は入っていません。同じ種類の検出を明記しているのは、別のベンダーの説明です。

「SSOを経由せずに入れるアカウントが残っていないか」が最大の関心なら、Oktaの項目だけで足りる前提では選べません。Claude側でSSOの必須化が効いているかを先に確認するのが筋です。SSO必須化の影響はClaude Okta SSO設定のFAQに、IdPごとの差はClaudeのSSO設定、IdPはOkta・Google Workspace・Entra IDのどれかにあります。

Okta for AI Agentsとの関係

同じ発表は、ISPMとは別の軸としてOkta for AI Agentsにも触れています。AIエージェントを人間のユーザーと同じく独立したIDとして登録し、人間のオーナーを割り当て、中央のポリシーでライフサイクル全体を管理する製品です。接続にはスコープ付きで短命のトークンを使え、アクセスレビューと監査ログ、暴走したエージェントを止めるキルスイッチも備えるとされています。

さらに、Okta Professional Servicesの提供として、Okta MCP Bridgeがあります。Claude CodeのようなクローズドソースのコーディングアシスタントとそのMCPツールを、コードやツールを変えずにIDの境界内へ入れる仕組みです。

ISPMは「すでにあるアカウントの状態を点検する」製品、Okta for AI Agentsは「これから動かすエージェントのIDを管理する」製品、という分担です。前者は今回のCompliance API連携が対象で、後者はClaude Codeなどを自社で動かす側の話になります。

まとめ

ISPM連携の価値は、Claudeを「ID管理の対象のSaaS」に加える点にあります。退職者の残存や休眠アカウントは、SSOとSCIMを整えた後でも残りうる穴で、ライセンス回収にも直結します。

一方で、ベータで担当者経由の提供であること、検出項目にSSO迂回は含まれないことを前提に置く必要があります。選ぶときは、まず自社の関心が「放置されたキーと休眠アカウント」か「SSOの外から入る経路」かを分け、後者ならSilverfortやTwineの説明も見比べる、という順で進められます。