Claude Code デスクトップアプリ｜セキュリティ設定の基本｜情報漏洩を防ぐ3原則
Claude Code デスクトップアプリを業務に導入する際、便利さよりも先に詰めるべきはセキュリティ設計。ここが雑だと、導入メリット以上の損失が一度の事故で発生する。
セキュリティの論点は大きく3層。認証情報の取り扱い、アクセス境界の設計、そして事後検知のための監査ログ。この3層を最初から意識して設計すると、後からの手戻りが小さい。
経営者として押さえるべきは、技術の細部ではなく、責任分界点と事故時の対応フロー。ご自身が判断すべき論点を先に切り分けておくと、現場任せにせず設計できる。
最小権限の原則とは：利用者・プロセス・デバイスに対して業務遂行に必要な最小限のアクセス権のみを付与するセキュリティ設計の考え方。権限を広く与えない運用で、情報漏洩や事故発生時の影響範囲を小さく抑えられる基本原則。
セキュリティ設計の3原則
AI ツール導入時に共通して効く設計原則。個別の設定より、原則の理解が事故を防ぐ。
原則1｜最小権限でスタートする
初期セットアップ時は、必要な権限だけを渡す設計に徹する。連携ツールへのアクセスも、作業に必要なフォルダ・リポジトリだけに絞る運用が鉄則。
広めに渡して後から絞る設計は現実的ではない。一度広く渡した権限は、業務が回り始めると「便利だから残しておく」という心理が働いて狭めにくくなる。
皆さんの組織で AI 運用の歴史が浅いなら、権限は後から拡張する前提で狭く始めるほうが健全。拡張の判断が必要になるたびに、経営側で検討する機会も生まれる。
原則2｜機密データは手元に置かない
顧客情報・契約書・財務データなど、漏洩時の影響が大きいデータは Claude に読み込ませない前提で業務を組む。どうしても必要な場合は、個人情報を伏字にしてから渡す。
AI ツールはログが残る設計が多く、一度渡したデータの完全削除は保証されにくい。機密度の高いデータは、原則として AI ツールと切り離した運用環境で処理する。
読者の中には「そんなこと言ってたら何もできない」と感じる方もいるはず。実務では、機密データを匿名化してから Claude に渡す中間処理を組む設計が現実的。
原則3｜事故前提で設計する
完璧なセキュリティは存在しない。事故が起きる前提で、検知・対応・復旧の手順を先に決めておく設計のほうが実用的。
検知の仕組みが無い状態で事故が起きると、発覚まで時間がかかり被害が拡大する。月次で監査ログを確認する運用だけでも、事故検知までの時間は大きく短縮できる。
対応フローは経営者が先に作る。現場任せにすると、事故発覚時に「誰が何を判断するか」で時間を失う。判断フローが明文化されていることが、初動の速さを左右する。
出典: IPA 情報セキュリティ10大脅威 2024（2024）
APIキーと認証情報の管理
認証情報の漏洩は AI ツール導入時の最大リスク。ここを押さえるかどうかで運用の安全性が決まる。
APIキーの保管場所
API キーは設定ファイル本体に直書きせず、環境変数または専用のキーストアから読み込む設計に統一する。設定ファイルが Git にコミットされた際の事故を防げる。
macOS ならキーチェーンアクセス、Windows なら資格情報マネージャーが標準のキーストア。社内で統一したキーストア運用を決めておくと、メンバー展開時にも迷わない。
環境変数運用の場合でも、`.env` ファイルは `.gitignore` に必ず追加する。初期セットアップ段階でこの設定を入れておかないと、後から思い出して追加する運用は失敗しやすい。
キーの権限スコープを絞る
多くの API サービスは、発行するキーに対して権限スコープを指定できる。読み取り専用・特定リポジトリのみ・特定期間のみといった条件を付けられる仕組み。
Claude に渡す API キーは、可能な限りスコープを狭めて発行する。キーが漏洩した際の被害範囲を、設計段階で小さくしておく効果がある。
フルアクセス権限のキーを発行して Claude に渡す運用は、利便性と引き換えにリスクが大きい。最初から分離した運用を組むほうが、後からの調整コストも小さい。
キー更新とローテーション
API キーは定期的にローテーション（更新）する運用が望ましい。3 ヶ月に 1 回の更新サイクルを決めて、カレンダーに定例タスクとして登録する設計が現実的。
ローテーション作業そのものは 10 分程度で終わるが、忘れると漏洩時のリスクが累積する。経営判断として「更新頻度の基準」を先に決めておくと、現場が判断に迷わない。
退職者が出た際は、その人がアクセスできた全てのキーを即座に無効化する手順も必要。この手順は人事フローと連動させて、抜け漏れを防ぐ設計にする。
基本の連携設定の組み方は既存ツールと連携する最小構成で触れているが、連携を増やすたびにキー管理の負荷も増える点は念頭に置く。
アクセス権限とデータ境界
どこまで Claude にアクセスさせるかの境界設計。ここを雑にすると、意図しないデータまで AI に読まれる事故が起きる。
作業フォルダの分離
Claude が読み書きする作業フォルダは、本番データが置かれているフォルダから物理的に分離する。「Claude 連携用」の専用フォルダを作り、そこだけを連携対象にする運用が基本。
本番フォルダを丸ごと連携対象にすると、意図しないファイルの改変リスクが常に存在する。分離運用は手間に感じるが、事故防止の観点では必須の設計。
あなたが経営者として決めるのは、この分離ルールを全社適用にするか、部門別にカスタマイズするか。組織規模が小さいうちは全社統一ルールのほうが運用が楽。
読み取りと書き込みの分離
Claude に読み取り権限だけを渡すパターンと、書き込みも含めて渡すパターンを明確に使い分ける。書き込み権限は、成果物が最終確定するまで人間側で保持する設計が安全。
レビュー→承認→書き込みの 3 段階を守ると、Claude が意図しない変更を本番データに加える事故を防げる。速度は落ちるが、初期段階では落とすべき速度。
慣れてきたら、明らかに低リスクな作業だけ書き込み権限を委譲する設計に移行する。いきなり全権委譲は、事故が起きた際の影響範囲が経営レベルで響く。
データ境界の可視化
Claude がアクセスできる範囲を、図や一覧表で可視化する。設定を頭の中だけで管理すると、3 ヶ月後に自分でも全貌を把握できなくなる現象が高確率で起きる。
可視化は Notion や Google Sheet で十分。連携先・権限範囲・発行日・次回ローテーション日の 4 項目を表にまとめる設計が、最低限の管理水準。
この表は監査時に必ず必要になる。作り始めは面倒だが、運用を 3 ヶ月続けた時点で価値を実感する。皆さんの運用設計の中心に置くべき成果物の一つ。
出典: 内閣サイバーセキュリティセンター セキュリティ・バイ・デザインガイドライン（2023）
ログ監査と事後対応
事故は起きる前提の設計。検知と対応の仕組みを先に作る。
監査ログの取得対象
最低限取得すべきログは「誰が」「いつ」「何にアクセスしたか」の 3 点。Claude の操作履歴と、連携ツール側のアクセスログを突合できる状態に保つ設計。
Claude のログは標準機能で記録されるため、設定の漏れは少ない。一方、連携ツール側のログ保持期間はサービスによって異なるため、3 ヶ月以上の保持設定に明示的に切り替える。
ログが取れていないと、事故発生時の原因究明が不可能になる。事故が起きた時点で初めてログの重要性に気づくのでは遅い。
月次レビューの運用
月に 1 回、1 時間程度のレビュー時間を確保する。ログ全件の精読ではなく、「異常な操作パターンが無いか」のざっくりした確認で十分。
異常パターンの例は 3 つ。深夜時間帯の大量アクセス、普段使わないツールへのアクセス、短時間での連続失敗。いずれも侵入の兆候として定型化されている指標。
レビューは経営者自身が担当するか、情シス担当に権限委譲するかを明確に決める。どちらでも良いが、担当者が曖昧な状態は必ず形骸化する運用リスク要因。
事故発生時の対応フロー
事故を検知した際の対応は、時系列で決めておく。発覚 → キー無効化 → 被害範囲の特定 → 関係者への通知 → 再発防止策の 5 ステップが基本形。
各ステップの「誰が何分以内に」を具体化する。情報漏洩が発覚した場合、発覚から 72 時間以内の当局通知が義務付けられる業界も多い。時間が勝負になる。
このフローは一度作って終わりではなく、年に 1 回は机上訓練で回す。訓練なしのフローは、実事故発生時に役に立たない紙切れになりやすい。
出典: 個人情報保護委員会 個人情報保護法ガイドライン（2024）
よくある質問
Claude に機密データを読ませても問題ないですか
Anthropic の API 規約上、入力データは学習には利用されない方針が示されているが、ログとしては一定期間保持される。顧客個人情報や契約書など、漏洩時の影響が大きいデータは匿名化または伏字処理してから入力する運用を推奨する。社内規程で「AI に渡して良いデータの範囲」を明文化しておくと、現場判断のブレが小さくなる。
APIキーが漏洩したらどうすればいいですか
発覚した時点で即座にキーを無効化し、新しいキーを発行する手順を最優先で実行する。並行して、漏洩期間中にそのキーで行われた操作のログを確認し、不正利用の有無を特定する。影響範囲が個人情報に及ぶ場合は、個人情報保護法に基づく当局報告義務が発生する可能性があるため、法務または顧問弁護士への相談を含めた初動フローを事前に整備しておくと判断が早い。
セキュリティ設定はどのくらいの頻度で見直すべきですか
基本設定は 3 ヶ月に 1 回、組織変更や新規ツール導入のタイミングで臨時レビューという設計が現実的。3 ヶ月サイクルは API キーのローテーションと同期させると、見直し作業の重複を避けられる。年に 1 回は外部の視点で棚卸しする工程も入れると、社内だけで気づかない盲点が検出されやすい。
監査ログは何年保存すべきですか
業界と扱うデータ種別によって異なるが、一般的な業務利用なら 1 年以上の保持が推奨水準。個人情報を扱う場合や金融・医療関連の業界では、法令で 3 〜 7 年の保持が求められるケースがある。保持コストと法令要件のバランスを取り、業種固有の規制を先に確認してから保持期間を決める設計が安全。
