Claude Codeで情報漏洩を防ぐ｜入れてよい情報・いけない情報の線引き

「Claude Codeへ秘密の情報を渡さない」。方針としては間違っていません。ただし、この言葉だけを社内の決まりにすると、たいていは2通りの結果に行き着きます。

1つは、誰も利用しなくなる結果です。現実のデータを使えなければ、得られる回答も抽象的な助言に偏り、担当者は期待したほど役立たないと感じます。もう1つは、表に出ない利用が広がる結果です。仕事の実態に合わない規則は、各自の解釈で境界をずらされ、その事実も共有されにくくなります。

そこで欠かせないのが、全面禁止ではなく、入力可能な範囲を具体的に示す境界です。実務では、単純な秘密度よりも、外部へ漏れた後に回復可能かを軸に分類すると判断しやすくなります。

本記事では、データを4色で仕分ける方法、内容を隠して活用する手順、漏洩につながる4経路と個別の防止策、利用端末へ暗号化されず残るデータを順に解説します。さらに、契約形態によるモデル学習への利用や保持日数の違い、社内向けルールを1枚にまとめる要領も紹介します。

モデル改善へのデータ利用、保存期間、端末上に作られるファイル、初期状態の権限、プロンプトインジェクションへの防御については、2026年8月15日現在のClaude Code公式資料（Data usage／Security／.claude directory／Settings）を根拠にしています。期間や数値を他社の記事から引用した箇所はありません。初期設定や仕様は今後変わり得るため、実際の導入時には最新の公式情報を必ず確認してください。分類と運用方法は、弊社（AIスキル）がバックオフィス業務および導入支援で実践しているものです。

「機密は入れない」だけでは、業務が止まる

導入を支援する場面では、以下のような規則を目にすることが少なくありません。

抜けのない規定に見える一方、この文章だけを読んでも、日々の業務で何が許されるかはほぼ判断できません。

営業事務が面談メモをまとめる場合を考えてみましょう。メモには取引先の名称があります。規則に従えば利用不可です。採用担当者が応募者への返信案を作りたい場合も、候補者の氏名は個人情報に該当します。経理が支出表を整えようとしても、一覧には金額が記載されています。それも機密と判断されるかもしれません。

結局、規定を厳密に守れば作業できない状況が生まれます。その後は、役に立たないツールという印象が広がるか、担当者が独自に「この程度なら問題ない」と境界を決めるようになります。

ルールが機能しない理由は「一律だから」

根本的な原因は、リスクの種類が異なる情報を1つの枠へまとめている点にあります。

APIキーが外部へ出れば、直ちに悪用される恐れがあり、キーを交換するまで危険は続きます。対して、1件の取引先名がAI処理を通過した際の影響は、保存先、保存期間、閲覧可能な人によって変わります。性格のまったく違う2つへ同一の決まりを当てはめるのは現実的ではありません。

必要な対処も同じではありません。APIキーは最初からAIの参照対象にしない必要がありますが、会社名なら別の記号へ置換しても業務を進められます。入力禁止以外の方法が成立するかどうかに、大きな差があります。

線を引く基準を変える

このため弊社では、秘密の度合いではなく、問題発生後に元へ戻せるかを判断基準にしています。

• 後から回復できない情報（流出後は失効処理が必要）→ AIへ渡さない
• 代替表現でも目的を果たせる情報（隠しても文脈が成立）→ 置換して利用する
• 利用範囲を絞れば処理可能な情報（特定業務に限って必要）→ 保存場所を分離する
• すでに世間へ公開済みの情報→ そのまま活用する

この4段階に分けることで、現場の担当者自身が迷わず選択できます。その場で判定できない規則は、日常の運用には根付きません。

情報を4色に分ける——基準は「取り返せるか」

日常の実践には、この4区分があれば十分です。細分化しすぎるほど選択に時間がかかるので、意図的に4色だけにし、4つを別々に運用しています。

この区分と社内フォルダを対応づければ、さらに迷いを減らせます。フォルダ単位で「ここは黄」と定義しておけば、1件ずつ判定する必要がなくなるからです。

赤：入れない。理由は「取り消せない」から

赤として扱う代表例を挙げます。

• ログインや認証に用いる情報——APIキー、パスワード、アクセストークン、SSH秘密鍵、証明書のファイル
• マイナンバーに当たる個人番号——法律上、厳しい管理が求められ、漏洩時の影響も重い
• カード番号、または銀行口座の本人認証に利用されるデータ
• 契約によって社外持ち出しを禁止された、他社からの預かり情報

共通点は、流出時に失効や再発行を行うほかないことです。会社名なら謝罪と再発防止で対応できる余地がありますが、秘密鍵は交換しなければ安全を取り戻せません。

「入れないつもり」では防げない

注意すべきなのは、赤のデータは本人が意識して入力するより、知らないうちに取り込まれやすいという性質です。

代表的なのが各種設定ファイルです。環境変数を記した .env には、APIキーやパスワードが平文で置かれていることがあります。AIが作業中にそのファイルを開けば、値は対話ログへ取り込まれます。利用者に入力した認識がなくても結果は変わりません。

公式資料にも、ツールが .env を参照した場合やコマンドが認証値を画面へ出した場合、その内容が projects/<project>/<session>.jsonl に記録される旨が示されています。

設定で読めなくする

したがって赤に必要なのは、注意喚起ではなく、仕組みによって参照を禁止することです。Claude Codeでは、指定ファイルへの読み取りを拒む権限ルールを設定できます。弊社では、以下を拒否対象にしています。

• .env と、名前が .env.* に一致するファイル
• ファイル名に credentials が含まれるもの
• token.json をはじめとする認証データ
• *.pem や id_rsa などの秘密鍵関連ファイル

公式資料でも、ローカルでの露出を抑える策の1つとして、権限規則を用いて認証情報へのアクセスを拒否する方法が案内されています。具体的な記述例はClaude Codeの権限設計を実例で｜settings.jsonとhooksの書き方の勘所をご覧ください。

それでも入ってしまったら

万一の際は、1つの優先順位だけ覚えてください。ログを消す前に、漏れた認証情報を使えない状態へ変えます。

キーの交換、パスワードの変更、トークンの取り消しを先に実施します。保存記録を消すのは、その後で問題ありません。先にログだけ削除すると、有効な認証情報が残ったまま安全になったと錯覚する危険があります。

黄：伏せて入れる——伏せ方の実務

黄に該当するのは、顧客や取引先の名称、金額、個人の連絡先など、普段の仕事で頻繁に触れるデータです。これらまで全面禁止にすれば、実務は回りません。

現場で扱いやすいのは、仮の表現に変えて成果物を作り、最後に人が正式な内容へ戻す進め方です。

置き換えの基本形

ポイントは、元データではなく、生成される成果物で匿名化することです。入力前に情報を削りすぎると文脈が欠け、回答品質も下がります。出力時に置換すれば、処理に必要な情報を保ちながら、完成ファイルへの機密の残存を避けられます。

メール、提案資料、公開記事など、成果物が社外へ渡る場合に特に有効です。一方、完成物を社内だけで扱うケースでは、必ずしも隠す必要はありません。そのようなデータは、次の青として管理します。

集計・分析なら、そもそも名前が要らない

もう1つ有効なのが、分析目的と関係のない項目を事前に除く方法です。

商談の傾向を調べるなら、見るべき項目は業種、規模、相談内容、結果であり、会社名ではありません。名称の列を取り除いたデータを用意すれば、置換を指示する必要さえなくなります。

慣れれば準備に要するのは数十秒ほどです。また、分析後に端末へ残るファイル自体の安全性も高められます。

やってはいけない伏せ方

ただし、次に挙げる2つの方法は採用しないでください。

1つ目は、対応一覧を同じ場所へ保存しないことです。匿名化したデータの隣に「A社はどの会社か」を示す表があれば、分離した効果は失われます。

2つ目は、周辺情報から正体がわかる隠し方を避けることです。所在地や従業員12名という規模、歯科医院という業種を組み合わせれば、名称がなくても対象を絞れる場合があります。消すべきなのは固有名だけではなく、個人や組織を特定できる情報の組み合わせです。

青：置き場所を分けて入れる

青は、原文の内容を維持しなければ処理できず、匿名化すると業務目的を果たせない情報です。非公開の仕様、公開前の契約条件、社内規程の全文、給与制度などが含まれます。

この分類では、Claude Codeの作業範囲が起動ディレクトリを基準に決まる仕組みを利用します。

Securityの公式資料では、Claude Codeが書き込めるのは起動場所とその配下に限られ、親側のファイルを変えるには明示的な許可が要ること、Read・Grep・Globによる範囲外の読み取りも承認後に可能になることが説明されています。

言い換えれば、起動するフォルダを選ぶ行為が、そのままAIへ開示する領域の指定になります。

作業用フォルダを分ける

実際の業務では、以下の手順で切り分けます。

• AI作業専用のディレクトリを1つ用意する——Claude Codeは必ずその場所から開始する
• 今回必要な資料だけを専用領域へ複製する——元ファイルは元の場所に残す
• 完了後は完成物を移し、作業領域の中身を片づける

準備が増えるように見えても、AIが現在参照可能な対象をいつでも把握できる点が大きな利点です。全社共有領域で起動すれば、組織全体の資料が視野に入ります。それを防ぐための区画化です。

デスクトップやホームディレクトリで起動しない

不慣れな利用者は、デスクトップやホームディレクトリを起点にしがちです。その場所を起点にすると、個人用ファイルの広い範囲が作業境界へ含まれてしまいます。

公式資料には、ホームディレクトリ直下から開始した場合の補足があります。信頼への同意は現在のセッションに限って有効となり、端末へ永続保存されないので、起動するたびに確認が必要とされています。これを恒久化する設定はなく、プロジェクト配下のディレクトリで利用する方法が推奨されています。

毎回の確認は手間ですが、安全な作業場所を選ぶよう促す仕組み上の警告だと捉え、専用フォルダを準備しましょう。

白：ためらわずに入れてよいもの

4区分の中で説明が省かれやすいのが白です。しかし、許可される情報を示さなければ、利用者はすべて禁止対象だと受け取り、活用を止めてしまいます。

たとえば、以下は白に分類できます。

• 公式サイトや配布資料ですでに公表済みの自社情報
• 誰でも閲覧できる法律、標準、公的組織の公開資料
• 公開されても問題のない社内手順（会議運営や書式に関する決まりなど）
• 個人の識別につながらない一般化された相談（特定場面の文章表現を尋ねる場合など）

社内向けの説明では、禁止対象だけでなく、利用可能な例にも同程度の紙幅を割きましょう。制約だけを並べると、読む側を必要以上に慎重にさせます。

漏れる経路は4つ。塞ぐ手はそれぞれ違う

社内規則の多くは、自分で情報を貼り付ける1番目の経路しか想定していません。実際の出口は4つあり、特に後半の2つである外部送信と端末内保存への備えが不足している組織が目立ちます。

経路1：自分で入力する

文章の貼り付け、ファイルの読み込み、フォルダの指定など、利用者が自ら情報を渡す経路です。4色による判定と作業領域の分離で管理できます。ここまで説明した方法をそのまま適用します。

経路2：道具が勝手に読む

利用者が望んでいないのに、AIが認証ファイルや他案件の文書を参照するパターンです。対処には、権限ルールによる読み取り禁止を使います。

Claude Codeの初期動作も防御に役立ちます。公式説明によると、最初は厳格な読み取り専用権限で動き、編集、テスト、コマンドなどの操作前には明示的な同意を求めます。一方、ls、cat、git status といった内蔵の参照専用コマンドは、確認を挟まずに実行されます。

経路3：外に出す窓口

対策が抜けやすいのが、メール送信、チャット投稿、外部システムへの書き込みといった出口です。AIにこれらの操作手段があると、判断ミスがそのまま社外への情報公開につながります。

弊社では、機能を与えない設計でこの経路を閉じています。AI秘書はメール本文の閲覧と下書き作成だけが可能で、送信権限は取得していません。チャットへの投稿機能も設定で拒否しています。注意力へ依存せず、操作そのものを実行できない構成です。

この方式は、プロンプトインジェクションなど、利用者が意図しない命令を読み込んだ場合にも有効です。どのような文言に誘導されても、外へ送る機能がなければ送信は成立しません。

経路4：手元に残る

見過ごされやすい最後の経路です。Claude Codeとの対話内容は、利用者の端末へ暗号化されない状態で記録されます。続く章で保存内容を確認します。

手元のPCに残るもの——ここを知らずに「安全」とは言えない

Data usageの公式説明では、セッションを後から再開できるよう、クライアントが対話記録を ~/.claude/projects/ 以下へ平文で保存し、標準では30日間保持すること、cleanupPeriodDays で期間を変えられることが案内されています。

.claude ディレクトリの資料には、さらに、トランスクリプトと操作履歴は保存時に暗号化されず、保護はOSのファイル権限に依存すると記されています。

自動削除の対象になるもの

公式情報によれば、cleanupPeriodDays の設定日数（標準30日、下限1）を超えると、以下が削除対象になります。

• projects/<project>/<session>.jsonl——メッセージ、ツール実行、実行結果を含む対話の完全な記録
• projects/<project>/<session>/tool-results/——容量の大きなツール結果を別保存したデータ
• file-history/<session>/——AIによる変更前のファイルを残した復元用コピー（直近100件のチェックポイント）
• plans/——計画モードが生成したプランのファイル
• paste-cache/・image-cache/——貼り付けた長文や添付画像の実データ
• debug/——デバッグモードで作られるログ

自動削除の対象にならないもの

この違いは必ず把握してください。公式資料には、自動的な整理の範囲に含まれず、手動で消すまで保存されるデータが明記されています。代表が次のファイルです。

この保存仕様を踏まえると、社内規程には少なくとも以下の2項目が必要です。

• 利用端末のストレージ暗号化を必須条件にする（macOSではFileVault、WindowsではBitLocker）
• 端末を紛失した場合や社員が退職する場合の処理手順に、ローカル記録の扱いを含める

減らす手段は公式に用意されている

公式に案内されている軽減策は、次の3種類です。

• cleanupPeriodDays の値を小さくする——ローカルで保存する日数を短縮する。下限は1
• CLAUDE_CODE_SKIP_PROMPT_HISTORY を有効にする——対話ログと入力履歴を最初から書き出さない
• 認証データを含むファイルへのアクセスを権限設定で禁止する

2つ目の履歴を書き出さない設定は効果が大きい反面、中断したセッションを再開できなくなります。翌日に前日の続きを行うような運用ができないため、安全性と使い勝手を比較して決める必要があります。最初の対応としては、業務上必要な範囲へ cleanupPeriodDays を短縮する方法、たとえば7日への変更が取り入れやすいでしょう。

プロジェクト単位で消すコマンド

端末内の状態を案件ごとに削除する公式コマンドもあります。claude project purge を使うと、該当プロジェクトの対話記録、自動メモリ、各セッションのデバッグログ、編集前コピー、history.jsonl 内の関連行、そして ~/.claude.json の関連項目が削除されます。

--dry-run オプションを付ければ、実際には消去せず、対象予定だけを確認できます。機密案件の終了時や退職者端末の回収時に迷わないよう、確認と本実行の2行を手順化しておくと安心です。

ただし公式資料には対象外も示されています。shell-snapshots/ はプロジェクト別の保存領域ではないため消去されず、backups/ に保存された旧設定のコピーへ関連項目が残る場合があります。コピーは最大5件保持され、順次入れ替わります。

契約プランで扱いが変わる——学習利用と保持期間

入力データがモデル学習へ利用されるかは、どの契約プランを使っているかによって結論が異なります。憶測で説明せず、社内文書には公式情報を根拠として記載しましょう。

学習利用

Data usageの公式資料を要約すると、扱いは以下のとおりです。

• 個人利用のFree・Pro・Max——将来のモデル改良へデータを提供するか、利用者が設定で選択できる。許可が有効なら、Claude Code経由の内容を含め、これらのアカウントのデータが新モデルの学習に利用される
• 法人利用のTeam・Enterprise・API・第三者プラットフォーム・Claude Gov——商用条件でClaude Codeへ送信されたコードとプロンプトは、生成モデルの訓練へ利用されない。開発パートナープログラムなど、顧客がモデル改良への提供に明示的に同意したケースは例外

企業として一貫した説明と管理を行うなら、法人向けプランを利用する方法が最も明快です。個人プランでは学習利用の設定が各利用者に委ねられ、組織側で統制できません。

保持期間

保存期間についても、同じ公式資料で次のように区別されています。

• Team・Enterprise・APIという商用契約の通常設定——30日
• 個人用プラン——モデル改良を許可した場合は5年、許可しない場合は30日
• ZDR（ゼロデータ保持）——Claude for Enterprise上のClaude Codeで、条件を満たすアカウントが利用できる。Enterpriseへ自動で付属する機能ではなく、対象資格を確認後、アカウントチームが組織ごとに有効化する

見落とされやすい2つの経路

通常の保持期間とは別に、利用者の選択次第で、データがより長期間保存される2つの経路があります。社内教育で忘れずに伝えたい1つの要点です。

1つ目は /feedback の実行です。公式説明では、このコマンドによってソースコードを含み得る対話履歴の複製がAnthropicへ送られ、/bug と /share も同じ仕組みを使います。送信前には、現在のセッションだけ、または同一プロジェクトの直近24時間もしくは7日間から範囲を選択できます。この方法で提供したトランスクリプトの保存期間は5年です。DISABLE_FEEDBACK_COMMAND=1 を設定すれば無効化できます。

2つ目は、セッション品質に関するアンケートです。利用体験を評価した後、トランスクリプトの閲覧を認めるか別途確認される場合があります。そこで同意すると、通常の会話とサブエージェントの対話、端末上にある加工前のセッションログがアップロード対象になります。公式資料によると、既知のAPIキーやトークン形式は送信前に隠されるものの、ソースコード、ファイル本文、そのほかの会話内容は変更されずに送られます。同意して共有した記録の保持は最大6か月です。

どちらも利用者が同意しなければ送信は発生しません。しかし、利用者の操作だけで共有できることも意味します。組織として機能を止める場合は、次の設定を利用できます。

• 品質アンケートの表示を無効化：CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1
• フィードバック用コマンドを無効化：DISABLE_FEEDBACK_COMMAND=1
• 必須でない通信を一括して無効化：CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

公式説明では、ZDRを利用中の組織、製品フィードバックを組織ポリシーで停止した組織、または CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC が有効な環境では、トランスクリプト共有を尋ねる画面そのものが出ません。

テレメトリに中身は含まれるのか

もう1点として、通常の運用テレメトリについて、公式資料は、収集メトリクスへコード、プロンプト、ファイルパスが含まれることはないと説明しています。DISABLE_TELEMETRY=1 で停止も可能です。エラー報告では、既知の秘密情報形式、パス、メールアドレスなどの個人情報が、端末外へ出る前にマスキングされるとされています。

もっとも、これはAnthropicへ送信される標準テレメトリに限った説明です。企業が独自のOpenTelemetry環境へデータを集める場合、プロンプト本文を対象に含めるかは組織側の構成によります。詳しくは情シスのためのClaude Code導入設計で解説しています。

読ませた内容に仕込まれた指示——もう1つの漏れ方

これまでは、利用者がAIへ与える情報を中心に見てきました。もう1つの危険として、読み込み対象そのものに悪意ある命令が埋め込まれている状況も考える必要があります。

これはプロンプトインジェクションと呼ばれます。メール、Webサイト、共有文書などへAI向けの命令文を忍ばせ、内容を読んだAIに予定外の行動を促す攻撃です。たとえば、従来の指示を無視し、指定ファイルを特定の宛先へ送るよう求める文章が、普通の本文に紛れ込んでいます。

公式が用意している対策

Securityの公式資料で示される主な防御機能は、以下のとおりです。

• 許可の仕組み——重要度の高い操作を行う前に、利用者の明示的な同意を求める
• 周辺文脈を含む判定——依頼全体を確認し、危険な命令を見つける
• 入力内容の無害化——コマンドへの不正な文字列混入を防止する
• ネットワーク利用コマンドの確認——curl や wget など、Webから取得する命令は初期状態で自動許可されない。完全停止には拒否ルールを用いる
• 処理文脈の切り離し——Web取得を独立したコンテキストウィンドウで処理し、悪意ある文の影響を抑える
• 信頼可否の確認——初めて扱うコードや新規MCPサーバーでは同意を要求する。ただし -p を使う非対話実行では無効になる
• 不審なコマンドの検知——過去に許可済みの形式でも、疑いのある命令は手動承認へ戻す
• 安全側で停止する動作——規則に該当しないコマンドは、標準で人の許可を必要とする

ただし公式資料も、複数の防御で危険性は大幅に下げられるが、すべての攻撃を完全に防げる仕組みは存在しないと注意を促しています。

運用側で足す一段

検知機能だけで100%防御できないことを前提に、運用にも安全策を追加します。弊社では、次の原則を社内規則の最上段に記載しています。

さらに、外部資料を参照した直後に行う送信、削除、設定変更、ソフトウェア導入は、内容を問わず人の確認を必須にすると定めています。

最後に機能するのが、経路3で紹介した外部へ送る機能をそもそも付与しない構成です。文章で気づき、機能構成で実行を防ぎ、権限設定で止める。三層に分けて守れば、1つの対策を突破されても直ちに事故へはつながりません。

社内ルールを1枚に収める

ここまでの内容を、現場が実際に参照できる規則へ変換しましょう。分量が多すぎる規程は読まれないため、要点を1ページへまとめます。

1枚に入れる6項目

この6点に絞れば、A4用紙1枚へ配置できます。詳細な規程を別途整備しても、日常的に担当者が確認するのはこの簡易版です。

禁止と同じ分量で「できること」を書く

重要なので改めて強調します。制限事項だけの資料は、触れないことが最も安全だという印象を与えます。白として自由に使える例や、置換すれば扱える黄の例を、禁止事項と同じ程度掲載しましょう。

ルールをAIにも読ませる

Claude Codeでは、まとめた1枚を CLAUDE.md に記載すると、AIが作業のたびに参照する基本方針として利用できます。人向け資料だけで終わらず、内容をAIの行動にも反映させられます。

もちろん、文章にしただけで常に守られる保証はありません。事故後に戻せない操作は、説明文ではなく技術設定で実行不能にします。役割分担は社内ルールをAIに守らせる｜CLAUDE.mdの書き方と、効かないルールの直し方と権限設計を実例でで詳しく紹介しています。

よくある質問

Q. 顧客名を1回入れてしまいました。どうすればよいですか

慌てて消す前に、順番に状況を確認します。最初に契約プランを特定し、次に会話ログが端末のどこへ保存されたかを調べてください。法人プランなら学習には利用されません。さらに claude project purge でローカル記録を削除すれば、多くのケースでは実務上必要な対応を満たせます。

ただし、社内の事故報告ルールがある場合は必ずそちらを優先します。影響が小さそうだと自己判断して共有を省くほど、後から問題が広がりやすくなります。

Q. APIキーを入れてしまいました

ログ消去を始める前に、該当するキーを失効させます。代替キーを発行して古いものを無効にする対応が先です。保存記録は、その後に削除してください。

Q. ローカルに平文で残るなら、そもそも使わないほうがよいのでは

端末へデータが残ることだけで禁止すると、他の多くの業務ソフトも使えません。メールソフト、チャットツール、端末へ保存した資料も、同様にローカルへ情報を保持します。Claude Codeだけに固有の課題ではありません。

現実的には、ディスク暗号化を必須化し、必要最小限の保存日数へ変更し、紛失時や退職時の処理をあらかじめ手順化します。既存ツールで実施している端末管理へ組み込むことができます。

Q. 伏せ字にすると、AIの回答の質が落ちませんか

入力時点で隠すと品質は下がりやすくなります。一方、成果物を出す段階だけで置換すれば、品質への影響はほとんどありません。実際の文脈をAIに与え、完成文へ書く際に仮名へ変換させる方法が実用的です。

ただし、この方法は元の情報が入力可能な分類であることが前提です。赤に該当するデータは、出力を匿名化しても安全にはできません。

Q. どこまでが「個人情報」ですか

ここでは法律上の範囲を新たに定義しません。現在の個人情報保護方針と社内規程で採用している定義に従ってください。Claude Code専用の別定義を作ると運用が分かれます。既存規程へAI利用時の扱いを1行追記する方が統一できます。

Q. ISMSやPマークを取得しています。追加で何をすべきですか

認証組織の監査では、情報資産の区分と、それぞれの取扱方法が対応しているかを確認されます。本記事の4色と、極秘・秘・社外秘・公開など既存の分類を対応づけた表を1つ用意すると説明しやすくなります。

また、学習への利用、保持日数、端末内保存に関する公式記述は、確認日と参照先URLを添えて内部資料へ記録してください。監査時には、判断の根拠となった情報源を示す必要があります。

Q. 私物PCで使っている社員がいます

個人所有の端末には、組織の管理設定を強制配布できず、ストレージ暗号化も保証できません。現実的には、私物端末で黄と青の情報を扱うことを禁止する境界が妥当です。利用範囲は白だけに限定します。

社給端末への導入方法は、会社のPCにClaude Codeを入れる｜Windows／Mac別の手順で確認できます。

まとめ

Claude Codeへ渡す情報について、分類方法、流出経路、ローカルログ、契約プランという4つの側面から境界を整理しました。4面を通じた結論を振り返ります。

• 一律に機密入力を禁じても、実用的な規則にはならない。厳守すれば業務が進まず、非公開の利用を招く可能性がある
• 秘密度より、問題が起きた後に回復できるかで判定する。赤は入力不可、黄は置換、青は領域分離、白はそのまま利用という4区分を使う
• 赤の保護を注意力だけに委ねない。秘密鍵や設定ファイルは権限で参照禁止にし、漏れた場合はログ削除前に失効処理を行う
• 黄は生成物を作る段階で匿名化する。入力から情報を落とすと精度が下がる。分析用途なら不要な氏名列を先に除外する
• 青は開始ディレクトリによって参照範囲を限定する。起点以下が作業領域になるため、デスクトップやホームを起点にしない
• 利用可能な白の範囲も規則へ記載する。禁止例だけでは担当者が必要以上に萎縮する
• 情報の出口は4方向にある。手動入力、自動参照、外部への書き込み、端末内保存をそれぞれ別の方法で防ぐ
• ローカルには暗号化されず記録される。~/.claude/projects/ の標準保存は30日で、cleanupPeriodDays により変更可能。history.jsonl は自動整理の対象ではない（公式資料を2026年8月15日に確認）
• 学習利用と保持条件は契約ごとに異なる。個人プランは本人の選択に左右され、法人プランは初期状態で学習対象外。/feedback 経由の共有内容は5年、アンケート後に提供した記録は最大6か月保存される
• 読み込んだ資料内の命令を実行対象にしない。公式の防御機能も万能ではないため、運用規則、機能構成、権限設定を重ねて守る

境界設定に悩む組織では、規則が過度に厳格または寛容なのではなく、利用者が判断できる形に具体化されていないことが少なくありません。「秘密は入力しない」だけでは、結局、読む人が独自に境界を決めます。最初の1つとして、自社で扱うデータを4色に分類し、各色について3つずつ実例を挙げてください。それだけでも、現場の判断負担をかなり軽減できます。

弊社は、法人向けのClaude Code導入支援と研修を提供しています。社内の情報資産区分と4色分類の対応づけ、権限ルールを用いた読み取り制限、1枚で使える社内ガイドの作成、認証取得企業向け資料の整備まで支援可能です。ここで紹介した方法は、弊社のバックオフィス業務と支援現場で運用している実践内容です。相談と見積りに費用はかかりません。

情報分類の策定から、権限設定による安全確保まで支援します
ご相談・お見積りは費用なしで承ります

無料相談を申し込む →