10-3 Claude Code のセキュリティ｜組織導入の安全設計

このレッスンでわかること

カリキュラムの最後を飾るのは、組織導入でもっとも重要なテーマ——セキュリティです。

「AI に社内データを渡して大丈夫なのか？」。これは、導入を検討するすべての組織で必ず出る質問です。この質問に答えられないまま展開を進めると、現場は不安で使わなくなるか、逆に無防備に何でも渡してしまうか、どちらかに振れます。そして一度インシデントが起きれば、「全面禁止」という最悪の結末を招きかねません。

安全な導入に必要なのは、漠然とした不安でも根拠のない楽観でもなく、具体的なルールと手順です。このレッスンでは、次の5つを身につけます。

• 何を渡してよいか／いけないかを判断する「データ分類」
• 許可（permission）設定の考え方——破壊的操作の確認を残す
• データ取り扱いポリシーで確認すべきポイント（学習利用・保持期間）
• 社内 AI 利用ガイドラインに入れるべき項目チェックリスト
• 誤って機密を送ってしまったときの対応手順

データ分類：何を渡してよいか、線を引く

セキュリティ設計の出発点は、「Claude Code に渡してよいデータと、いけないデータの線引き」です。おすすめは、社内のデータを3段階に分類するシンプルな方法です。

分類	例	Claude Code での扱い
レベル1: 公開情報	公開済みのプレスリリース、自社サイトの文章、公開資料	制限なく扱える
レベル2: 社内情報	社内の業務手順、匿名化済みの集計データ、社内向け資料	契約プランのポリシーを確認のうえ、ルール内で扱う
レベル3: 個人情報・機密	顧客の個人情報、未公開の財務情報、認証情報（パスワード・APIキー）、他社との秘密保持契約に関わる情報	原則渡さない。業務上必要な場合は匿名化・マスキングを必須にする

ポイントは2つあります。

1つは、判断を現場任せにしないこと。「機密っぽいものは避けてね」という曖昧な指示では、人によって判断がバラつきます。上の表のような具体例つきの分類表を配り、「迷ったらレベル3として扱い、推進役に相談する」という逃げ道もセットで用意します。

もう1つは、レベル3でも工夫すれば活用の道があることです。たとえば顧客リストの分析をしたい場合、氏名やメールアドレスを「顧客A」「顧客B」のような記号に置き換えた（匿名化した）データなら、リスクを大きく下げて分析できます。「禁止」で終わらせず、「こうすれば使える」まで示すのが、現場に守られるルールのコツです。

Bad例：

機密情報は AI に入力しないこと。

Good例：

顧客の個人情報・未公開の財務情報・パスワード類は Claude Code に渡さない。 顧客データを分析したい場合は、氏名・連絡先を記号に置換したファイルを作ってから渡す。 判断に迷うデータはレベル3として扱い、#ai-soudan チャンネルで相談する。

permission 設定：破壊的操作の「確認」を残す

Claude Code には、ファイルの編集やコマンドの実行といった操作の前に、ユーザーに許可（permission）を求める仕組みがあります。「この操作を実行していいですか？」という確認です。

使い込んでくると、この確認が面倒になり、確認を省略する設定（自動承認の範囲を広げる設定）を使いたくなります。個人の検証環境ならそれも選択肢ですが、組織利用では「何を自動承認し、何の確認を残すか」を設計することが安全網になります。

考え方の基本は、取り返しがつくかどうかで線を引くことです。

• 自動承認してよい操作（取り返しがつく）：ファイルの読み取り、検索、新規ファイルの作成など。間違っても元のデータは無事です
• 確認を必ず残す操作（取り返しがつかない・影響が外に出る）：ファイルの削除・上書き、外部へのデータ送信、メール送信、システムへの変更操作など

たとえるなら、自動車の運転支援です。直進のアシストは任せても、交差点の右折判断はハンドルを握る人間が行う——破壊的な操作・外部に影響が出る操作の確認は、最後の「人間のハンドル」として残しておきます。

また、CLAUDE.md にも防御の一文を入れておくと二重の安全網になります。

## してほしくないこと（安全ルール）
- ファイルの削除は、対象の一覧を提示して承認を得てから行う
- 元データのフォルダ（data/）内のファイルは変更しない
- メール送信・外部サービスへの投稿は必ず下書き提示で止める

permission の細かい設定方法はバージョンにより変わることがあるため、実際の設定は公式ドキュメントを確認してください。重要なのは設定の手順より、「確認を残す基準をチームで決めておく」という設計の考え方です。

データ取り扱いポリシーの確認ポイント

「入力したデータは AI の学習に使われるのか？」——これも必ず出る質問です。

Anthropic は、API 経由の入力データをデフォルトではモデルの学習に使わない方針を掲げてきました。また、組織向けの Team / Enterprise プランでは、管理機能とあわせて商用利用を前提としたデータ取り扱いが提供されています。ただし、プランや設定、利用形態によってデータの扱いは異なり、ポリシー自体も更新されることがあります。「Anthropic だから大丈夫」と一括りにせず、自社が契約するプランの規約を確認するのが鉄則です。

確認すべきポイントは次の4つです。

1. 学習利用：入力したデータがモデルの学習・改善に使われるか。オプトアウトの設定が必要か
2. 保持期間：送信したデータがどれくらいの期間、どこに保存されるか
3. 管理機能：組織の管理者がメンバーの利用状況を管理できるか（Team / Enterprise プランで提供。詳細は公式で確認）
4. 自社の契約・法令との整合：顧客との秘密保持契約（NDA）や、個人情報保護法などの法令上、外部サービスへのデータ送信が許される範囲か

4つ目は見落とされがちですが重要です。ツール側のポリシーがどれだけ堅牢でも、「顧客データを第三者に提供しない」という契約を顧客と結んでいれば、自社側の制約として守る必要があります。情報システム部門や法務部門と連携して確認しましょう。

社内 AI 利用ガイドラインのチェックリスト

ここまでの内容を、社内ガイドラインに落とし込みます。最初から分厚い規程を作る必要はありません。A4で1〜2枚、次の項目が入っていれば実用に足ります。

## 社内 AI 利用ガイドライン チェックリスト

### データの取り扱い
- [ ] データ分類表（公開・社内・個人情報/機密の3段階と具体例）
- [ ] レベル3データの扱い（原則禁止、匿名化すれば可、の基準）
- [ ] 迷ったときの相談窓口

### 操作のルール
- [ ] 自動承認してよい操作と、確認を残す操作の基準
- [ ] 共有 CLAUDE.md に入れる安全ルール（削除・外部送信の確認）

### 成果物の扱い
- [ ] 人間が最終確認する原則（レッスン10-2参照）
- [ ] 社外提出物のダブルチェックルール

### 契約・ポリシー
- [ ] 利用するプランとデータ取り扱いポリシーの確認記録
- [ ] 顧客との契約（NDA）・法令との整合の確認

### インシデント対応
- [ ] 誤送信時の報告先と対応手順
- [ ] 「報告しても責めない」原則の明記

### 運用
- [ ] ガイドラインの見直し周期（半年に1回など）
- [ ] 新規利用者への教育（オンボーディング時に説明）

ガイドラインは「作って配る」だけでは読まれません。レッスン10-1のオンボーディング勉強会に組み込み、具体例とセットで説明する場を必ず設けてください。

インシデント対応：誤って機密を送ってしまったら

どれだけルールを整えても、ミスは起きます。重要なのは、起きたときの手順が決まっていて、すぐ報告されることです。誤って機密データ（顧客の個人情報など）を Claude Code に渡してしまった場合の手順例を示します。

1. 作業を止める：気づいた時点でその会話・作業を中断する
2. すぐに報告する：推進役または情報システム部門に、「何のデータを・いつ・どの環境で」送ったかを報告する。時間が経つほど対応の選択肢が減ります
3. 影響範囲を確認する：データの分類レベル、件数、契約上の報告義務（顧客への通知が必要か）を確認する
4. ベンダー側の対応を確認する：契約プランのポリシーに基づき、送信データの削除依頼が可能かなどを確認する（対応可否はプラン・規約によるため、契約内容を確認のうえ問い合わせます)
5. 再発防止に反映する：原因（分類の誤解、マスキング漏れなど）を特定し、ガイドラインや CLAUDE.md の禁止事項に反映する

このとき、組織の側でもっとも大切な原則があります。正直に報告した人を責めないことです。報告者が叱責される組織では、次のインシデントは隠されます。隠されたインシデントは対応が遅れ、被害が拡大します。「ミスは仕組みで防ぐ。報告は称賛する」——この文化こそが、最強のセキュリティ対策です。

やってみよう

演習1：自分のチームで日常的に扱うデータを10個書き出し、「公開・社内・個人情報/機密」の3レベルに分類してみましょう。判断に迷ったものこそ、ガイドラインに具体例として載せる価値があります。

演習2：自分の業務で Claude Code に任せたい操作を思い浮かべ、「自動承認してよい操作」と「確認を残すべき操作」に仕分けてみましょう。「取り返しがつくか」「影響が外に出るか」が判断基準です。

演習3：上のチェックリストを使って、自分の組織の現状を採点してみましょう。チェックがつかなかった項目から1つ選び、Claude Code に「この項目のたたき台を作って」と頼んで、ガイドラインのドラフトを作ってみてください。

まとめ

• セキュリティ設計の出発点は、データの3段階分類（公開・社内・個人情報/機密）と具体例の提示
• 機密データは「禁止」で終わらせず、匿名化・マスキングによる活用の道も示す
• permission は「取り返しがつかない操作・外部に影響が出る操作」の確認を必ず残す
• データ取り扱いポリシーは「学習利用・保持期間・管理機能・自社契約との整合」の4点を、契約プランごとに必ず確認する
• 社内ガイドラインはA4で1〜2枚から。オンボーディングとセットで浸透させる
• インシデント時は「止める→すぐ報告→影響確認→ベンダー確認→再発防止」。報告者を責めない文化が最強の対策

理解度チェック

Q1. Claude Code に渡すデータの扱いとして、もっとも適切なものはどれでしょう？

1. Anthropic は信頼できる会社なので、どんなデータでも制限なく渡してよい
2. リスクがあるので、社内データはいっさい渡さず公開情報だけで使う
3. データを3段階に分類し、個人情報・機密は原則渡さない。必要な場合は匿名化してから扱う
4. 判断は各メンバーの感覚に任せ、ルールは作らない

解答を見る

正解: 3

「全部OK」も「全部禁止」も実務的ではありません。公開情報・社内情報・個人情報/機密の3段階に分類し、具体例つきの基準を示すのが基本です。機密レベルのデータも、氏名や連絡先を記号に置き換える匿名化を行えば、リスクを下げて活用できる場合があります。判断を現場の感覚任せにしないことが重要です。

Q2. 誤って顧客の個人情報を Claude Code に送ってしまったときの対応として、正しいものはどれでしょう？

1. 学習には使われないはずなので、何もせず作業を続ける
2. 叱責を避けるため、誰にも報告せず会話を閉じて忘れる
3. 作業を止めてすぐに推進役・情シスに報告し、影響範囲と契約上の対応を確認する
4. まず自分だけで1週間ほど様子を見てから、問題がありそうなら報告する

解答を見る

正解: 3

インシデント対応の鉄則は「止める→すぐ報告」です。時間が経つほど、データ削除依頼や顧客への通知といった対応の選択肢が減ります。データの扱いは契約プランのポリシーによって異なるため、自己判断で「大丈夫なはず」と続行するのも危険です。また、報告した人を責めない文化がなければインシデントは隠され、被害が拡大します。