Claude企業利用のセキュリティ確認｜導入前に決める5項目

契約・製品側で先に確認する項目

自社ルールを作る前に、利用予定のプランと契約について、入力データの取扱い、保存期間、学習利用の条件、対応リージョン、削除手段、管理者機能、監査機能、外部サービス連携を確認します。同じClaudeでも、利用画面、API、クラウド基盤、個人向け・法人向け契約によって条件が異なる可能性があります。別経路の説明を流用せず、実際に契約するサービスの公式文書を正本にしてください。

セキュリティ認証や提供者の管理策は重要ですが、それだけで自社利用が安全になるわけではありません。自社が投入するデータ、接続するシステム、利用者へ与える権限、出力後の操作によってリスクは変わります。製品側の統制と利用企業側の統制を表に分け、どちらが責任を持つかを明記します。

業務単位でリスクを評価する

「Claudeを導入する」という一括評価では範囲が広すぎます。問い合わせ要約、社内文書検索、営業メール下書き、コード変更など、業務ごとに入力、出力、接続先、利用者、誤りの影響を整理します。同じ機能でも、公開済みFAQを要約する用途と、未公開の顧客相談を扱う用途では必要な統制が異なります。

1. 業務の開始条件と完了条件を書く。
2. 入力データを公開・社内・機密・個人情報へ分類する。
3. Claudeが読める場所と書き込める場所を列挙する。
4. 出力が社外へ届くまでの経路を確認する。
5. 誤り、漏えい、過剰権限が起きた時の最大影響を見積もる。
6. 人間確認、技術制御、ログ、停止手順を割り当てる。

入力禁止情報を具体例まで書く

「機密情報を入れない」だけでは、人によって判断が変わります。顧客氏名、連絡先、契約書原文、未公開財務情報、認証情報、秘密鍵、医療・決済情報、他社から預かった秘密など、自社業務に合わせた具体例を示します。入力可能な場合も、利用目的、最小化、マスキング、保存、削除、アクセス権を定めます。

匿名化は氏名を消すだけでは不十分な場合があります。会社名、部署、日付、希少な属性、自由記述を組み合わせると個人や案件を推測できることがあります。必要な項目だけを残し、再識別できる対応表をClaudeへ送りません。

MCP・外部連携を別リスクとして扱う

Claude単体の利用と、ファイル、GitHub、データベース、CRM、Web、MCPサーバーへ接続する利用は分けて評価します。外部連携を追加すると、読み取り範囲、書き込み権限、外部通信、第三者の保持条件、悪意ある指示の混入経路が増えます。接続先ごとに提供者、認証方式、権限、送信データ、ログ、失効手順を台帳化してください。

最小権限を基本に、読み取り専用から開始し、必要な操作だけを個別に許可します。共有アカウントや長期間有効な資格情報を避け、退職・異動・事故時に速やかに無効化できるようにします。Claude Codeの具体的な権限設計はClaude Code権限設定ガイドも参照してください。

インシデント対応を実行可能にする

停止条件を文書に書くだけでなく、誰が何を止めるかを演習します。誤送信、個人情報入力、意図しないファイル参照、外部連携の過剰権限、費用急増、品質低下を想定し、利用停止、認証情報の失効、ログ保全、影響範囲確認、関係者連絡、再発防止、再開承認の順を決めます。

ログには秘密そのものを重複保存せず、利用者、日時、用途、モデル・機能、参照元、承認結果、外部操作、例外を必要最小限で残します。社内ルール全体の作り方はClaude社内利用ガイドラインで整理しています。

導入判定を残す記録

• 対象業務と対象外業務
• 利用する契約・プラン・接続経路
• 入力可能情報と禁止情報の具体例
• 利用者、管理者、承認者、事故対応責任者
• 外部連携ごとの読み書き権限
• 人間確認が必要な出力と合格条件
• ログ項目、保存期間、閲覧権限
• 停止条件、失効手順、再開承認
• 次回レビュー日と公式情報の確認担当

小さく試す時の合格条件

試行では「便利だった」だけで判断せず、禁止情報の混入ゼロ、重要出力の人間確認率100％、根拠欠落率、誤分類率、例外件数、レビュー時間、停止手順の実行可否を測ります。重大事故につながる失敗が一件でも出た場合は範囲を広げず、入力制限、権限、プロンプト、確認手順のどこで止めるかを見直します。

合格後も一度に全社展開せず、部署、業務、データ範囲を段階的に広げます。新しい外部連携や自動送信を追加する時は、同じ製品の継続利用であっても別のリスク変更として再評価してください。