業務データ漏洩対策チェックリスト — Claudeへの共有可否を8項目で判断

業務SaaSのデータをClaudeに渡していいかは、Connectorの機能一覧を見ただけでは判断できません。同じ「読み取りできます」でも、渡した先が誰の権限で何を見られるか、どこで処理されるかまで確認して初めて判断がつきます。以下の8項目は、情シス・法務・現場のどこが確認しても同じ基準で判断できるように整理したものです。1つずつ埋めていけば、担当者が変わっても判断の再現性が保てます。

なぜ機能の有無だけで判断できないか

Connectorsは「Claudeは接続されたサービスから各ユーザーの権限を継承する」という設計です。つまりClaude側の設定がどれだけ厳格でも、接続する本人がソースシステム内で広い閲覧権限を持っていれば、その範囲はそのままClaudeからも見えることになります。機能一覧の「読み取り/書き込み」という表示は、あくまで技術的にできることの上限を示しているだけで、実際に渡っていいデータかどうかは別の話です。

渡す前に確認する8項目

1. 接続先に公式Connectorがあるか、Community・カスタムか

品質と互換性をAnthropicがテスト済みのVerified Connectorか、スクリーニングのみのCommunity Connectorか、自社で追加したカスタムConnectorか。この区分で、信頼できる開発元かどうかの前提が変わります。ただしVerifiedはセキュリティ監査ではなく、権限の広さの保証でもありません。

2. 読み取り専用に絞れるか、書き込みまで必要か

Team・EnterpriseプランならOwnerがConnectorごとに読み取り専用ツールと書き込み/削除ツールを分けて、常に許可・承認が必要・ブロックを設定できます。渡す業務に書き込みが本当に必要かを先に洗い出しておくと、この設定がぶれません。

3. データは誰の権限で見えるものか

権限継承の原則があるため、接続する社員個人が人事・経理などで広い閲覧権限を持っている場合、その範囲がそのままClaudeからアクセス可能になります。個人情報や機密情報が含まれるかどうかは、接続先SaaS側の権限設計を先に棚卸しする必要があります。

4. データはどこで処理されるか

接続されたサービスは自社のインフラと自社の条件でデータを処理し、米国外に置かれている場合もあります。Enterpriseプランの米国のみ推論設定のようにClaude側の推論実行地を制御する設定があっても、接続先のサードパーティサービスが動作する場所までは変更しません。越境移転にあたるかどうかは、接続先SaaS側の契約・仕様を個別に確認する論点です。

日本企業の場合、この論点は個人情報保護法の第三者提供・越境移転に関する社内規程と照らし合わせる必要があります。Claude側の設定を見ただけでは判断がつかないため、接続先SaaSのデータ処理契約(DPA)やプライバシーポリシーを確認する作業を、情シス単独ではなく法務と分担しておくと抜け漏れが減ります。

5. 個人アカウントと組織アカウントが混在しない仕組みか

Enterpriseプランには検証済みドメインConnectorの制限があります。オンにすると、会社ドメインのメールアドレスを使うConnectorへの接続を、組織のClaudeアカウント以外からはブロックできます。ただし逆方向(組織メンバーが私用のGoogleDriveなどに接続すること)は防げず、データ損失防止の代替にもなりません。

6. 後から追跡できる仕組みがあるか

Enterpriseプランでは、Ownerが過去180日分の監査ログをエクスポートできます。ただしチャットやプロジェクトの本文はログの対象外で、記録されるのは識別子までです。より細かい活動やチャット内容まで追う必要がある場合は、Compliance API(公共部門を除くEnterprise・Claude Platform顧客に一般提供、CoworkとClaude Codeはベータ)を使います。

7. データの保持期間とゼロデータ保持(ZDR)の対象か

一部のモデル(Mythosクラスなど「カバーされたモデル」)では、安全性レビューのためにプロンプトと出力が30日間保持されます。Free・Pro・Maxのコンシューマープランはこの変更の対象外で、既存の規約どおりです。Claude ConsoleでZDRワークスペースを設定した組織や、Claude EnterpriseでZDRを使うClaude Codeは対象外になります。接続先SaaS自体の保持期間は別の話なので、両方を分けて確認します。

8. 誰が最終承認するか

情シスだけで判断せず、機密情報や個人情報を扱う接続は法務・現場の管理者を含めた承認フローに乗せておくと、後から権限を見直すときの経路が明確になります。承認者と設定変更者が同じだと、変更の妥当性を後から検証しにくくなる点には注意が必要です。「誰が接続を許可したか」だけでなく「なぜ許可したか」まで残しておかないと、後任者が同じ接続を見直すときに判断の根拠を追えなくなります。判断理由は承認フロー側のドキュメントで残しておく運用が現実的です。

チェックリストを実務でどう使うか

8項目は毎回すべてをゼロから確認する必要はありません。すでにTeam・Enterpriseプランでアクション制限や検証済みドメイン制限を組織全体に適用済みなら、2番と5番は制度としてクリアしている状態です。個々の接続で改めて確認すべきなのは、3番(そのSaaSで誰がどこまで見えるか)と7番(そのデータがどれくらいの期間残るか)の2つです。ここはSaaSごとに事情が変わるため、チェックリストを都度当てはめる価値があります。

逆に、Free・Pro・Maxで個人が業務SaaSを接続するケースでは、組織側の管理レバーがほとんど働かないため、8項目のうち1〜4番を利用者本人が自覚的に確認する必要があります。とくに機密情報を扱う部署でBYOD的にConnectorを使う場合は、情シスが個人利用の実態を把握しているかどうかで、リスクの見え方が大きく変わります。

判断に迷ったときの相談ルート

8項目のうち1つでも「分からない」がある場合は、接続を保留にして確認してから進めるのが無難です。とくに3番(データの見え方)と4番(処理場所)は接続先SaaS側の仕様に依存するため、情シス単独では確認しきれないことがあります。この2つは法務や、接続先SaaSのベンダー窓口への確認が必要になる場面が多い項目です。

すでにConnectorsの基本的な仕組みを押さえておきたい場合はClaude Connectorsとは、MCP全般のセキュリティ設計はMCPセキュリティガイドにまとまっています。組織導入の手順を横断的に確認したい場合はClaude Code業務導入9ステップチェックリストも合わせて参照できます。相談ルートを一度決めておけば、次に別の部門から似た申請が来たときも同じ経路を使い回せるので、都度ゼロから体制を組み直す必要がなくなります。

よくある質問

Verified Connectorなら個人情報を渡しても問題ありませんか

Verifiedは品質と互換性のレビューを通過した印であり、個人情報の取り扱いを保証するものではありません。渡してよいかどうかは、上記の8項目、とくに3番(データの見え方)と7番(保持期間)を個別に確認して判断します。ラベルの有無で判断を省略しないことが、このチェックリスト全体の前提です。

監査ログを見ればどんなデータが渡ったか分かりますか

Enterpriseプランの監査ログは組織内の操作イベントの識別子までを記録しており、チャットやプロジェクトの本文は対象外です。データの中身まで追いたい場合はCompliance APIの利用を検討します。両者は取得できる粒度が異なるため、目的に応じて使い分けるのが基本です。

この8項目はどのプランでも同じですか

考え方は共通ですが、アクション制限・検証済みドメイン制限・監査ログ・Compliance APIはいずれもTeam以上、もしくはEnterprise限定の機能です。Free・Pro・Maxでは個々のConnectorのツール権限を自分でブロックする以外の管理レバーはありません。

個人情報保護法に違反していないかもこのチェックリストで判定できますか

いいえ。このチェックリストはClaude側の設定と権限構造を確認するためのもので、法令や社内規程への適合を判定するものではありません。要配慮個人情報や機密情報が含まれるかどうかの最終判断は、自社の法務・情報セキュリティ部門が行う前提です。

まとめ

Claudeに業務SaaSのデータを渡していいかは、Connectorの機能表示だけでは判断できず、権限継承・処理場所・追跡可能性・保持期間まで含めた8項目で確認する必要があります。1つでも不明点が残る接続は、保留にしてから進めるほうが後戻りのコストが小さくなります。とくに3番(データの見え方)と4番(処理される場所)は、情シス単独では答えが出ない論点なので、法務や現場の管理者を早い段階で巻き込むのが結果的に近道です。まずは今つながっているConnectorを一覧化し、この8項目に沿って1つずつ埋めていくところから始めてください。