Claude Media
Claudeコネクタの権限設定は監査ログでどこまで追えるか
ClaudeClaude連携解説

Claudeコネクタの権限設定は監査ログでどこまで追えるか

コネクタのアクション制限は読み取り/書き込みを組織全体で縛れますが、Team・Enterpriseで追跡できる範囲がどこまで違うかを、権限設定と監査ログの両面から示します。

読了目安 約7分

コネクタで業務SaaSのデータをClaudeに渡すとき、権限は「Claude側の制限」と「監査ログでの追跡」という別のレイヤーで働きます。Team・Enterpriseプランのオーナーは接続先ごとに読み取り/書き込みを組織全体で縛れますが、その操作が監査ログに個別のイベントとして残るわけではありません。この2つを混同すると、「制限をかけたから記録も残る」と思い込んだまま運用してしまいます。

コネクタのアクション制限はどこまで組織で縛れるか

Team・Enterpriseプランのオーナーは、「Customize」>「Connectors」から接続先ごとの「Tool permissions」を開き、権限を種別ごとに管理できます。権限は読み取り専用のツールと書き込み・削除系のツールに分類され、それぞれ個別に「Always allow(常に許可)」「Needs approval(承認が必要)」「Blocked(ブロック)」のいずれかを選べます。

この制限は組織単位で効きます。オーナーが「Gmailの検索・要約は許可するが送信は禁止」と設定すれば、その組織でコネクタを使う全員に同じ制限がかかります。個々のメンバーが自分だけ設定を緩めることはできません。

公式が挙げる代表的な用途は次の3つです。

  • メールの検索・要約は許可するが、送信は禁止する
  • Google Driveのファイル閲覧は許可するが、作成・編集は禁止する
  • Linearの課題閲覧は許可するが、新規作成やステータス変更は禁止する

設定画面で実際につまずきやすい箇所はClaude Connectorsの権限設定でよくある失敗と対策にまとめています。本記事では「制限の効き方」の仕組みに絞ります。

なぜ権限設計は二重構造になるのか

Claude側でアクションを許可しても、それだけで書き込みが実行できるわけではありません。公式ドキュメントは「アクション制限は接続先システムの権限と並行して働く」と明記しています。Claude側で書き込みを許可していても、実行する本人が接続先のシステム側でその操作権限を持っていなければ、操作自体が失敗します。

つまりClaudeの制限は「上限を狭める」役割しか持ちません。接続先システムが許可していない範囲まで、Claude側の設定で権限を広げることはできない設計です。読み取り専用から始める考え方の背景は業務SaaS連携は読み取り専用アクセスから始める理由で詳しく扱っています。

具体的な例で確認します。Google Driveコネクタで「ドキュメントの編集」をClaude側で「Always allow」に設定したとします。この設定だけでは編集は完了しません。実際に編集を実行するユーザーが、そのGoogle Driveファイルに対して編集権限(閲覧者ではなく編集者)を持っていて初めて、Claude経由の編集が反映されます。逆に言えば、Claude側の制限を「Blocked」にしておけば、ユーザーがGoogle Drive側で編集者権限を持っていても操作自体をそこで止められます。2つのレイヤーはどちらか一方が緩くても、もう一方が締まっていれば操作を止められる関係にあります。

この二重構造を踏まえると、権限設計の順序は次のようになります。

  1. 接続先システム側の権限(誰がどの操作を実行できるか)を先に固める
  2. Claude側のTool permissionsで、その権限のうちどこまでをコネクタ経由の操作に開放するかを決める
  3. 承認が必要な操作は「Needs approval」に置き、実行前に人が確認できる導線を残す

書き込み系ツールが多いMCPサーバーでも同じ発想が要ります。Nomad MCPサーバーでジョブとクラスタ状態を監視させるは、ACLトークン側を先に絞る例です。

「Needs approval」を選んだ操作は、Claudeがその操作を実行しようとする直前に確認画面を出し、実際に操作を行うユーザー本人がその場で許可・却下を選びます。承認するのはオーナーやAdminではなく、コネクタを使っている本人です。オーナーが事前に決められるのは「確認を挟むかどうか」までで、個別の実行判断は現場の利用者に委ねる設計になっています。承認履歴自体は監査ログの event 一覧に専用イベントとして載りません。「いつ・誰が・どの操作を承認したか」を後から追いたい場合は、確認画面が出た時点のスクリーンショットや接続先システム側の実行ログを残す運用が必要です。

監査ログはコネクタの操作を専用イベントとして記録するか

ここが見落とされやすい点です。監査ログはEnterpriseプランの組織のみ利用でき、Organization Owner・Primary Ownerが「Organization settings」>「Data and Privacy」から過去180日分のログをエクスポートできます。エクスポートを実行するとメールにダウンロードリンクが届き、リンクの有効期限は24時間です。

監査ログの1行は created_at(記録時刻)・actor_info(実行者情報)・event(イベント種別)・event_info(イベント固有の詳細)・entity_info(操作対象)・ip_address ・device_id ・user_agent ・client_platform の列で構成されます。記録されるイベント種別には、SSO接続の作成・削除、会話の作成・削除・リネーム、ユーザーのサインイン方式、組織のデータエクスポート開始・完了などが並びます。

公式ドキュメントが公開しているイベント種別の一覧に、コネクタの読み取り・書き込み操作を指す専用のイベント名は含まれていません。 entity_info が扱う対象の種類はaccount(ユーザーアカウント)・invite(招待)・chat_project(プロジェクト)・chat_project_document(プロジェクト内のドキュメント)・chat_conversation(会話)・file(アップロードファイル)・sso_connection(SSO接続)の7種類で、いずれもClaude本体の操作対象です。会話の作成・削除・リネームやファイルのアップロードは個別イベントとして記録されます。ただし「どのコネクタでどの書き込みが実行されたか」を監査ログの1行から特定する経路は、公開情報の範囲では確認できませんでした。Tool permissionsによる制限自体は組織全体に効きますが、その効き目を監査ログ単体で事後検証できるとは限らない、という前提で運用設計を組む必要があります。

Enterprise組織の監査ログの全体像(エクスポート手順・保持期間・列構成)はClaude監査ログの見方 — Enterprise組織の変更履歴を追跡するにまとめています。

Compliance APIとエクスポート機能はどう使い分けるか

監査ログには2つの取得経路があります。1つは前述の「Export logs」ボタンによる180日分の一括エクスポート、もう1つはCompliance API経由のプログラム的な取得です。Compliance APIはEnterpriseプラン組織(Public Sector組織を除く)とClaude Platformの顧客が対象で、Claude・Cowork・Claude Code(CLI経由)の活動を継続的に監視する用途に向きます(Compliance API Activity Feedの使い方も参照)。

Compliance APIを有効化できるのはPrimary Ownerのみです。「Organization settings」>「API」からアクセスキーを作成でき、Primary Ownerは連結された全組織を横断するキーを、Ownerは自組織に限定したキーを作成できます。Adminロールにはこのページ自体が表示されません。

顧客管理鍵(CMEK)を使う組織では「Export logs」ボタンによるエクスポートが使えない点にも注意が必要です。この場合、監査ログの継続取得はCompliance API経由に一本化されます。

Compliance APIが取得対象とする範囲にも線引きがあります。カバー対象はClaude・Cowork(Claude・Claude Desktop・Claude Mobile経由)・Claude Code(CLI・Claude Desktop経由)で、Microsoft 365アドイン(Excel・Word・PowerPoint・Outlook)とClaude Scienceはベータでの対応です。一方、Claude CodeのWeb版、Claude Platform経由のClaude Code、他のMicrosoft 365アプリ、Amazon BedrockやGoogle Vertex AI上のセッションはカバー対象外です。コネクタ経由の操作が接続先ごとにどの実行環境を通るか(Claude本体か、Claude Codeのどの経路か)によって、Compliance APIで拾える範囲も変わる点は設計時に確認しておく必要があります。

プラン別に何が使えるか

機能TeamEnterprise
コネクタのアクション制限(Tool permissions)Team◯Enterprise◯
監査ログのExport logsボタン(180日分)Team×Enterprise◯(CMEK利用時は不可)
Compliance APITeam×Enterprise◯(Public Sector除く)

Teamプランでもアクション制限までは組めますが、その効果を組織として事後検証する手段(監査ログ・Compliance API)はEnterprise以上に限られます。業務データを扱うコネクタをTeamプランで運用する組織は、制限の設定を過信せず、接続先システム側のログを一次情報として残す運用を並行させる必要があります。具体的には、Google Workspaceの管理コンソール監査ログやSlackのアクセスログ、Linearのアクティビティ履歴のように、接続先システム自体が備えている操作ログを一次情報として扱う形です。Claude側のTool permissionsで「送信は禁止」と設定していても、その禁止が実際に効いたかどうかをTeamプランのClaude側だけから確認する手段はありません。「誰が・いつ・何を実行したか」を知りたい操作については、接続先システムのログ保持期間とエクスポート手順を先に確認しておく必要があります。

よくある質問

読み取り専用に設定すれば監査ログを見なくても安全ですか

いいえ。読み取り専用への制限は「書き込みを実行できないようにする」対策であり、「何を読み取ったか」を記録する仕組みではありません。閲覧履歴の可視化が必要な場合は、接続先システム側のアクセスログと組み合わせる必要があります。

まとめ

コネクタの権限設定は、実行できる操作の上限を狭める装置であって、実行の可否を最終的に決めるのは接続先システム側です。Claude側で「Always allow」にしていても、接続先のユーザー権限が伴わなければ操作は失敗し、逆にClaude側を「Blocked」にすれば接続先の権限がどれだけ広くても操作はそこで止まります。この上限を狭める効き目を事後に検証できるのは、Enterpriseプランの監査ログとCompliance APIに限られます。監査ログのentity_infoが扱う対象はアカウント・招待・プロジェクト・会話・ファイル・SSO接続の7種類にとどまります。「どのコネクタでどの読み取り・書き込みが実行されたか」を1行で特定できる専用イベントは、公開されているイベント種別の一覧に見当たりません。Teamプランで運用する場合は、この検証の空白を接続先システム側のログで埋める前提を持つ必要があります。

業務データの共有可否をチェックリストで判断する切り口は業務データ漏洩対策チェックリスト — Claudeへの共有可否を8項目で判断にまとめています。

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

関連する記事

Claude をもっと見る →