Claude Codeを業務で使うときのデータの扱いと設定。制御を4層で重ねる方法

Claude Codeを業務で使うとき、送信されるのは入力したプロンプトだけではありません。作業中に読み込んだファイルの内容や、実行したコマンドの結果も送信されます。そのため最初に決めるべきなのは「どう設定するか」ではなく、「何を読ませてよいか」です。そのうえで制御をかけますが、1つの設定だけでは足りません。指示ファイル・権限設定・フック・OSレベルの分離という4つの層を重ねて使います。

この記事では、業務利用にあたって何がどこへ送られるのか、4つの層がそれぞれ何を防ぎ何を防げないのか、そして最初に決めるべき5項目を整理します。2026年8月時点の情報です。

何がどこへ送られるのか

Claude Codeはターミナル上で動きますが、判断そのものはクラウド上のモデルが行います。そのため、次のものが提供元へ送信されます。

• 入力したプロンプト
• 作業中に読み込んだファイルの内容
• 実行したコマンドとその結果
• プロジェクトの設定ファイルに書かれた内容

「認証情報のファイルは開いていないから大丈夫」と考えていても、コマンドの実行結果にその内容が含まれていれば送信されます。設定を考える前に、まずこの前提を共有しておく必要があります。

送信されたデータの保持期間と、モデルの学習に使われるかどうかは、契約するプランによって異なります。ここは記事の情報ではなく、提供元の最新の規約で確認してください。プランによっては、組織単位で申請することで処理後すぐに破棄する設定にできる場合もありますが、申請すれば必ず適用されるとは限りません。厳格なデータ管理が求められる業種では、この点を最初に確認することをおすすめします。

クラウド事業者のサービス経由で利用する構成もあります。その場合はデータが各クラウドのインフラ内で処理されるため、自社のクラウド環境内で完結させたい要件がある場合は選択肢になります。

制御は4層で重ねる

Claude Codeの動きを制限する仕組みは4つあります。それぞれ動く場所が違い、防げる範囲も違います。

この4つは代替関係ではありません。上の層で漏れたものを下の層が受け止める構造なので、併用が前提になります。特に重要なのは、権限設定は間接的な実行やサブプロセスには効かないという点です。設定で読み取りを拒否したファイルでも、別のプログラム経由で開かれる経路までは追跡できません。ファイルそのものを守りたい場合は、OSレベルの分離が必要になります。

第1層 プロジェクト固有のルールを書く

プロジェクトのルートに置いた指示ファイルは、起動時に自動的に読み込まれます。ここに書くのは、プロジェクトの目的、使っている技術の構成、ディレクトリの構造、開発時の決まりごとといった「そのプロジェクトに固有で、変わりにくい情報」です。

書かないほうがよいものもあります。認証情報などの機密情報、頻繁に変わる情報、読めば推測できる情報です。前者は送信されるため論外として、後者2つは、記載が増えるほど読み込む量が増え、判断の精度がかえって落ちる方向に働きます。

大きなプロジェクトでは、フロントエンドとバックエンドのように領域を分け、それぞれのディレクトリに個別のルールファイルを置く構成が取れます。その領域のファイルを操作するときだけ該当のルールが読み込まれるため、常時読み込む量を抑えられます。

第2層 実行してよいコマンドを決める

設定ファイルで、ツールの呼び出しを「許可」「実行前に確認」「拒否」の3つに振り分けます。ここで押さえるべきなのは評価の順序です。**拒否 → 確認 → 許可の順で判定され、最初に一致したものが適用されます。**つまり許可のリストに書いてあっても、拒否のリストにも書かれていれば拒否が勝ちます。安全側に倒れる設計になっています。

パターンの書き方には落とし穴が2つあります。

1. 単語の区切り。コマンド名の後ろに何でも一致する記号を隙間なく付けると、意図しない別のコマンドの先頭にも一致してしまいます。似た名前のコマンドがある場合は特に注意が必要です。
2. つないだコマンド。記号でつないで複数のコマンドを並べた場合、全体が1本のコマンドとして扱われるわけではありません。つないだ右側は別のコマンドとして評価されます。

この2点は、設定した本人が「拒否したつもり」になりやすい箇所です。設定後に、拒否したはずの操作を実際に指示してみて、止まることを確認してください。

第3層 特定のタイミングで検査を差し込む

フックは、セッションの開始時、プロンプトを送った直後、ツールを実行する前後、応答が終わったときなど、決まったタイミングで任意の処理を走らせる仕組みです。権限設定が「パターンに一致するかどうか」で判定するのに対し、フックは実際に処理を書けるため、より強い制御になります。

たとえばツールの実行前に走らせる設定にしておけば、コマンドの中身を検査して、条件に合う場合は実行そのものを止められます。止められた側は理由を受け取るので、別の手段を検討する動きにつながります。単に止めるだけでなく、次の行動を促す効果があります。

注意点として、フックのスクリプトには実行権限を付けておく必要があります。権限がない場合、フックは起動せず、しかも目立つエラーも出ないまま素通りします。設定したつもりで効いていない状態が最も危険なので、設置後に必ず動作を確認してください。

第4層 読み書きできる範囲そのものを制限する

OSの機構を使って、プロセスが触れる範囲そのものを制限する仕組みがあります。書き込みは作業フォルダの配下と一時領域に限られ、システムの設定ファイルなどには既定で書き込めません。

ここで見落とされやすいのが読み取りです。**書き込みは制限される一方、読み取りは既定でコンピュータ全体が許可されています。**認証情報を書いたファイルや鍵のファイルを守りたい場合は、明示的に読み取りを遮断する指定を追加する必要があります。この指定は、Claude Code本体のツール経由だけでなく、その下で動くプロセスにも及びます。

通信についても、外部との接続を中継する仕組みを通し、許可したドメイン以外への接続を確認または遮断する構成が取れます。ただし、広い範囲のドメインをまとめて許可すると、その配下への送信までは防げません。許可リストはできるだけ狭く保ってください。

設定をどこに置くかで効く範囲が変わる

設定ファイルは、置き場所によって適用される範囲が変わります。会社として守らせたい設定を、個人が変更できる場所に置いてしまうと統制になりません。

優先順位は、組織全体に強制する層が最も高く、次に個人・プロジェクト内、プロジェクト、個人の全プロジェクトの順です。起動時のオプションで指定した内容は個人やプロジェクトの設定より優先されますが、組織全体に強制する層だけは、起動時のオプションでも上書きできません。

チームで運用する場合、本番のデータを壊しかねない操作は、プロジェクト共有の拒否リストに登録しておきます。こうしておけば、メンバーが個人の設定で誤って許可しても遮断されます。この変更はチーム全員の動きに影響するため、変更時のレビューを必須にする運用が有効です。

最初に決める5項目

設定を細かく詰める前に、運用の枠組みを決めます。順序としてはこちらが先です。

1. 業務データを3分類に振り分ける。「AIに渡してよい」「集計した値だけを持ち出す」「渡さない」の3つです。分類ごとの操作手順まで文書化して初めて運用できます。顧客の氏名・住所・電話番号や、認証情報は「渡さない」に入れるのが基本です。
2. **1人1アカウントで運用する。**チームで1つのアカウントを使い回すと、記録を見ても誰の操作か分からず、退職時にそのアカウントだけを止めることもできません。
3. **禁止事項の検出は、記録だけの状態から始める。**いきなり遮断すると、正常な作業まで止まる誤検知が起きます。手を止める仕組みは次第に敬遠され、使われなくなります。最初の2週間は記録だけにして傾向をつかみ、それから遮断に切り替えてください。遮断の対象も、形式が明確なもの（認証情報のような決まった並びのもの）に絞り、社名や人名のように曖昧なものは警告にとどめると運用が安定します。
4. **会社として守らせたい設定を、個人が上書きできない層に置く。**上の表の一番上の層です。ここに置かない限り、設定は個人の判断で外せます。
5. **外部ツールの接続に、申請と承認の手順を決める。**次の節で扱います。

外部ツールを接続するときの確認

Claude Codeは、外部のサービスやデータソースと接続して機能を広げられます。便利な一方、接続先にはプロンプトの内容やコードが渡ります。担当者が検証していない接続先を自由に追加できる状態は、企業ではリスクになります。

承認の手順は次の形が扱いやすくなります。

1. 利用者が、用途・対象・接続先を書いて申請する
2. 次の3点を確認する。提供元と出所（誰が配布しているか。確認できないものは却下）、データの取り扱い（送った内容を学習や再送信に使う規約でないか）、権限の範囲（読み取り専用を基本とし、書き込みや削除は追加で審査）
3. 基準を満たしたものを許可リストに追加し、全端末に配布する
4. 四半期ごとに、使われていない接続先を棚卸しして外す

この申請と承認を、社内のリポジトリとプルリクエストで運用すると、履歴がそのまま記録として残ります。誰がいつ何を申請し、誰が承認したかを後から追えます。

特に注意したいのが提供元の確認です。**見た目が公式らしいだけでは承認しないでください。**公式の配布物に見えるものが、実際には第三者が公開したものだった、という取り違えは起こり得ます。配布元のアカウントやドメインを実際にたどって確認する手順を、審査に含めておくことをおすすめします。

検索されている語から見た関心の変化

当社が調べたところ、Claude Codeに関する検索の内訳には次のような傾向があります。

出典: ラッコキーワードのデータ（2026年8月時点・日本国内）をもとにした当社調査

製品名そのものの検索数は月間301,000件ありますが、直近6か月では28%減少しています。一方で「法人」を伴う検索は12か月で89%増えています。使い方を調べる段階から、会社として使ってよいかを判断する段階へ、関心が移りつつあると見込まれます（根拠: 製品名単体は減少し、法人を伴う語は増加しているため）。

「セキュリティ」を伴う検索の広告競合性は2で、他のキーワードと比べて低い値です。関心はあるが、広告を出している事業者が少ない領域だといえます。

よくある質問

社内のソースコードや顧客データを読み込ませても問題ありませんか

「問題ない」と一律には言えません。何を読み込ませてよいかは、契約プランのデータの扱いと、自社が守るべき規制の両方で決まります。当社では、氏名・住所・電話番号・本文を取り出さずに集計した値だけを得る手順を、実際の業務システムで運用しています。データそのものを渡さずに分析結果だけを得る方法があるため、まずこの形で始めることをおすすめします。

設定さえすれば安全になりますか

なりません。この記事で挙げた4つの層はいずれも限界があり、併用して初めて実用的な水準になります。加えて、外部から読み込んだ内容に指示が紛れ込んで意図しない動作をさせられる攻撃の可能性もあります。ウェブページ、課題管理システムの記載、依存パッケージの説明文など、外から入ってくる内容には注意が必要です。設定に加えて、何を読み込ませるかの運用ルールが要ります。

社内にエンジニアがいなくても設定できますか

できます。ただし、4つの層すべてを最初から設定する必要はありません。まずデータの3分類と1人1アカウントを決め、権限設定で明らかに危険な操作を拒否するところから始めれば、実務上の大部分は押さえられます。フックやOSレベルの分離は、扱うデータの機密度が上がった段階で追加してください。設定作業そのものをClaude Code自身に相談しながら進めることもできます。

まとめ

• Claude Codeは、プロンプトだけでなく**読み込んだファイルの内容とコマンドの実行結果も送信します。**設定より先に「何を読ませてよいか」を決めてください。
• 制御は指示ファイル・権限設定・フック・OSレベルの分離の4層です。権限設定は間接的な実行には効かないため、併用が前提になります。
• 権限設定の評価順序は拒否 → 確認 → 許可です。許可に書いても拒否にあれば拒否が勝ちます。
• **会社として守らせたい設定は、個人が上書きできない層に置いてください。**それ以外の場所に置いた設定は個人の判断で外せます。
• 最初に決めるのは5項目です。データの3分類、1人1アカウント、検出は記録だけの状態から開始、組織で強制する設定の配置、外部ツール接続の申請・承認手順。

自社で進める場合は、まずデータの3分類から着手し、分類ごとの操作手順まで文書化するところを目標にしてください。設定の内容や社内での進め方を相談したい場合は、お問い合わせからご相談いただけます。当社ではAIエージェント導入・構築支援として、データの取り扱いルールの整備から、業務を1つ選んで社員が自分で回せる状態にするまでを支援しています。

会社としての導入の順序は会社としてClaude Codeを導入するときの手順と確認事項、社内ルールの文書化は社内のAI利用規程・ガイドラインの作り方で扱っています。AI導入全体の進め方についてはAI導入の進め方もあわせてご覧ください。