Claude Code を企業導入する前に決めるべきセキュリティ・権限設計と運用ルール

「Claude Code は便利そうだ。ただ、社内のコードを丸ごと扱わせていいのか」

開発チームから導入の相談を受けた情シスやセキュリティ担当が、最初に引っかかるのはたいていここだと思います。AIがファイルを読み、ターミナルでコマンドを実行し、コードを書き換える。挙動を聞くと、便利さより先に「どこまで触れるのか」「何を外に送るのか」が気になります。

公式ドキュメントのベストプラクティスには、デフォルトの挙動について次のように書かれています。

By default, Claude Code requests permission for actions that might modify your system: file writes, Bash commands, MCP tools, etc. This is safe but tedious.

引用：Best practices for Claude Code｜Anthropic

ファイル書き込みもコマンド実行も、デフォルト設定では人間に許可を求めます。そのうえで人間の確認を減らす仕組みとして、以下の3モデルがあります。

• 自動モード：コマンドを別のモデルが審査する
• 権限許可リスト：安全だと分かっているコマンドを許可する
• サンドボックス：OSレベルでファイルとネットワークを隔離する

もう一つ、公式が繰り返し強調しているのが検証です。

Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it. Give Claude something that produces a pass or fail, and the loop closes on its own.

引用：Give Claude a way to verify its work｜Anthropic

放っておくと、Claude は「できたように見える」ところで手を止めます。人間が検証役に回りっぱなしにならないよう、テストやビルドのような合否の出るチェックを渡す。そうすれば、AIが自分でパスするまで直します。

Claude Code は放し飼いのツールではありません。その制御を誰がどのように設計するかは、導入する企業側が決めることになります。デフォルトのまま各自に任せるのか、組織全体へ配る管理設定で縛るのか。許可リストに何を載せ、何を毎回確認させるのか。

ここを決めないままチームへ配ると、「便利だが怖い」の怖い側だけが現実になります。逆に、決めるべきことさえ決めれば、社内コードを扱わせる判断は下せます。

この記事では、その線引きを決めるための材料を整理します。

Claude Code が触れるのは、ざっくり4種類です。ローカルのファイル、Git リポジトリ、ターミナルで走るコマンド、そして外部への通信。読むだけでなく書き換えますし、git commitもgit pushもできます。プロンプトやファイルの中身は、推論のために Anthropic のアクセスポイントへ送られます。ここは、正しく怖がっておくべきところです。

とはいえ、怖がる場所を間違えると導入判断そのものが止まります。よくある誤解と、実務で効くリスクを分けておきます。

まず学習利用です。Anthropic の Team／Enterprise プランでは、送信したコードや会話がモデルの学習に使われません。この一点で「導入したら全てAIに取り込まれる」という不安の多くは消えます。一方、個人向けの Pro／Max は2025年の規約改定で前提が変わり、オプトアウトしない限り、会話が学習に使われる可能性がある扱いになりました。そのため業務利用は必ず Team プランに寄せます。弊社でも個人プランの業務利用は禁止にしました。

そのうえで、開発の品質面で実際に効くリスクは次のあたりです。

• 機密情報の混入。APIキーやパスワード、顧客の実データをうっかりプロンプトやファイルに含めて送ってしまう。学習に使われないとしても、送らないに越したことはありません。
• 誤ったロジックの生成。意図しないデータ変更や削除、集計ロジックの取り違え。動くコードほど気づきにくいものです。
• ライセンス違反。GPLやAGPLのようなコピーレフトのコードが混入すると、社内ツールでもコード全体の公開義務が生じかねません。
• ハルシネーション。存在しないライブラリやメソッドを、それらしく提案してくることがあります。

この4つは、後述する権限設計と運用ルールで潰していきます。ただし、これで安心とはいきません。監査やアカウント管理、外部連携、プロンプトインジェクションといった、組織として別の軸で見るべきリスクが残ります。そちらは後半の「組織ガバナンス」でまとめて扱います。

決めることは「どこで動かすか」「何を渡さないか」「何をどこまで許すか」の3つ。

Claude Code は開発者のローカルマシンで動きます。そのマシンから見えるものは、基本的に Claude からも見えます。

機密性の高いプロジェクトでは、サンドボックスやdevcontainerのような隔離環境の中で動かすことを検討します。ファイルシステムとネットワークの範囲を絞れば、事故が起きたときの被害もそこで止められます。公式のサンドボックス機能を使えば、隔離した中でなら比較的自由に動かせます。

最も効果的なのは、そもそも見せないことです。ここで先にくぎを刺しておきます。「読ませないための除外設定」を、セキュリティ境界として過信しないこと。

.claudeignore のようなファイルで読み込み対象を外す発想は自然ですが、これは 2026年7月時点の Claude Code の公式機能ではありません。似た挙動を第三者製のフックで再現するツールはあるものの、公式に保証された境界ではなく、ignore ルールをすり抜けて機密ファイルを読んでしまう不具合も報告されています。ソフトな除外は「あくまで補助」程度に留め、セキュリティ境界の担保には使わない。

機密を本当に触らせないための確実な手段は2つです。ひとつは、物理的に渡さないこと。認証情報は macOS の Keychain のようなシークレット管理に置き、平文ファイルやログには出さない。実データや秘密鍵は、そもそも Claude を動かすディレクトリやマシンに置かない。もうひとつは、設定で読み込みを拒否すること。~/.claude/settings.json（あるいはチーム共有・管理設定）のpermissions.denyに、読ませたくないパスのReadルールを並べます。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(**/*.pem)",
      "Read(**/credentials*)"
    ]
  }
}

denyはハードブロックで、下位の設定から上書きできません（後述の4層構造）。「渡さない」と「拒否する」の二段構えで担保するほうが、ignore ファイル一つに頼るよりも堅い構成になります。

あわせて、.claude/settings.local.json（個人のローカル設定）は .gitignoreで除外し、チーム共有設定と CLAUDE.md はコミット対象にします。「共有するもの」と「各自のローカルに留めるもの」を最初に切り分けておくと、後から認識の齟齬が生じにくくなります。

ここで効いてくるのが、Claude Code の設定が層構造になっていることです。弊社では4層で運用しています。

1. 管理設定。組織の管理画面から全メンバーへ配ります。セキュリティとコンプライアンスの強制ラインで、ここで禁止したものは下の層で上書きできません。
2. 個人設定（〜/.claude/settings.json）。各メンバーの運用ルール。
3. プロジェクト設定（リポジトリ内の.claude/settings.json）。チームで共有したいルール。
4. ローカル個人設定。リポジトリ単位で各自がカスタマイズする分。

原則として、下の層にある設定ほど優先されます。ただし管理設定の禁止（deny）だけは別格で、下層から上書きできません。組織として絶対に踏ませたくない操作は、この管理設定の denyに置く。ここが企業導入の肝です。

許可の粒度はallow（そのまま実行）、ask（毎回確認）、deny（禁止）の3段階で、評価時はdenyが最優先で適用されます。使い分けを言葉にすると、次のようになります。

denyは、取り返しのつかない操作。rm -rf系の破壊的コマンド、curl ... | shのようなパイプ実行、main / master への force push、データベースのDROP系操作、SSHキーやクラウド認証情報の編集。これらは便利さと引き換えにするものではない、と判断しました。

askは、必要だけれど毎回目視したい操作。ファイルの削除や移動、chmod、sudo、パッケージのインストール、認証ファイルへの書き込み。止めはしませんが、実行前に人間が一度見ます。

allowは、日常的に使う安全なコマンド。ここで大事なのは、Bash(*)のような包括許可を絶対に使わないことです。チームで実際に使うコマンドを1つずつ明示的に列挙します。面倒に見えますが、この面倒さがそのまま安全マージンになります。公式も、承認疲れについてこう書いています。

After the tenth approval you're not really reviewing anymore, you're just clicking through.

引用： Configure permissions｜Anthropic

10回目の承認ともなれば、もう中身は見ておらず、ただクリックしているだけ。だからこそ、毎回の確認が必要な操作を適切に絞り込むことが重要です。

承認そのものを別モデルに任せる auto mode という選択肢もあります。ただしこれは、公式が research preview と位置づけている機能で、安全を保証するものではありません。組織で使わせたくなければ、管理設定で無効化できます。過信せず、まずはdenyと許可リストで土台を作るのが順序だと思います。

権限で「できること」を絞ったら、次は「やっていいこと」と「必ずやること」です。技術設定だけでは、生成コードの品質と責任の所在までは決まりません。

弊社のルールはシンプルで、

• 提案されたコードをそのままコピペで採用しない。
• 理解できないコードは採用しない。
• テストなしでマージしない。

当たり前に聞こえますが、AIが生成したコードだと、「動いているから」という理由で流してしまいがちです。なぜそのコードになるのかを説明できる状態で採用する。

弊社はここを判断基準にしています。

人の意志だけに頼ると、忙しい日に事故が起きてしまいます。公式が勧めるのは、Claude 自身に検証手段を渡すことです。

テストスイート、ビルド、リンター。パスするまで Claude 自身に直させる。さらに強く縛るなら、フックで「毎回必ず走らせるチェック」を仕込めます。CLAUDE.md に記載した指示は必ずしも守られるとは限りませんが、フックは決められた条件に従って実行されます。ここは使い分けです。依存ライブラリのライセンスチェックも、この検証に組み込めます。GPLやAGPLを検出したらCIを落とす運用にしておくと、ライセンス違反はマージ前に止まります。

依存ライブラリのライセンスチェックも、この検証に組み込めます。GPLやAGPLを検出したらCIを落とす運用にしておくと、ライセンス違反はマージ前に止まります。

レビュー観点は、AI生成コードでも普通のコードでも土台は同じですが、いくつか項目を追加しています。仕様との整合性、セキュリティ上の問題がないか（入力値検証や認証・認可の漏れ）、テスト済みか、そしてハルシネーションがないかを確認します。存在しないライブラリやメソッドを使っていないかを、レビューの確認項目として明示します。

AI生成コードを含むPull Requestにはラベルを付けて可視化し、本番環境へのPull Requestは2名以上のレビュアー承認を必須にしています。誰がレビューしたかが残ることが、そのまま記録になります。

プロンプトに機密を入れないためのルールも明文化しておきます。個人識別情報は「ユーザーA」「user1@example.com」へ、認証情報は「YOUR_API_KEY」へ、実データはテストデータへ置換してから渡します。

それでも事故は起きるという前提で、対応フローを用意します。機密情報を誤って入力した場合は、セッションを直ちに終了し、セキュリティ担当者と利用管理者へ報告したうえで、該当するキーやトークンをローテーションする。本番データに誤った変更を加えたら即停止し、データオーナーへ報告する。そして、決して隠さないこと。この一文を運用ルールに書いておくだけでも、初動が変わります。

ファイル編集の巻き戻しには/rewind（チェックポイント）が使えます。ただし限界を押さえておく必要があります。/rewindが戻せるのは Claude によるファイル編集で、rmやmvのような Bash コマンドが起こした変更は追跡されず、戻せません。皮肉なことに、いちばん戻したい破壊操作こそ対象外です。だから破壊系は、事後の巻き戻しに期待せず、事前のdenyと git・バックアップで守ります。

ここまでは開発チームの手元の設計でした。情シスが導入・調達時に確認するのは、その外側にある論点です。ここでは網羅性を追求するのではなく、抜けると後で困るものを中心に挙げます。

• 監査ログ。誰がいつ何を実行したかを追える状態か。上位プランでは、操作ログや管理者向けAPIを通じて、既存のログ基盤へログを連携できます。Pull Requestのレビュー記録とは別に、Claude Code 側のログを確認します。
• SSOとSCIM。組織アカウントに限定するだけでなく、入退社に合わせてアカウントを自動で付与・失効できるか。退職者のアクセスが残る事態を防ぎます。
• データの所在と保持。学習に使われないことと、データがどこで処理され、どの程度の期間保持されるかは別の話です。国内リージョンやゼロ保持のような要件があるなら、契約前に確認します。
• MCPサーバー経由の流出。Claude に外部ツールをつなぐMCPは便利な反面、情報の出口にもなります。接続してよいサーバーを承認制にし、定期的に棚卸しします。
• プロンプトインジェクション。読み込んだファイルやWebページ、Issueの本文にAIへの指示が仕込まれ、意図しない動作を誘うタイプの攻撃です。ハルシネーションより実害が大きいことがあり、外部由来の入力を扱うときほど警戒します。

これらは開発チーム単独では決めきれません。情シス・セキュリティと開発責任者が、一緒に決める領域です。

ここまでを、そのまま導入判断に使える形にまとめます。情シス・セキュリティ担当と開発責任者では、確認すべき観点が少し異なります。

• 学習利用の前提を満たすプラン（Team／ Enterprise）で契約しているか。個人プランの業務利用を禁止しているか
• 認証を組織のSSOに限定し、SCIM等で入退社に応じたアカウント付与・失効ができているか
• 管理設定を全メンバーへ配布し、破壊的コマンド・force push・DB削除・認証情報編集を deny で禁止しているか
• 機密ファイルをpermissions.denyのReadルールで拒否し、実データ・秘密鍵はそもそも作業環境に置かない運用になっているか
• 機密性の高いプロジェクトで、隔離環境（サンドボックス／devcontainer）の利用を定めているか
• 監査ログを取得・保全し、既存のログ基盤で追える状態か
• データの処理場所・保持期間が自社の要件（国内リージョン等）を満たしているか確認したか 
• 接続してよいMCPサーバーを承認制にし、棚卸しの担当を決めたか
• 入力情報のマスキング基準と、機密誤入力時の報告先・ローテーション手順が決まっているか

• 許可リスト（allow/ask/deny）をチームの実作業に合わせて具体化したか。Bash(*)のような包括的な許可を使っていないか
• CLAUDE.md にリポジトリ固有の知識だけを書き、共通ルールを詰め込みすぎていないか
• 生成コードのレビュー観点にハルシネーションチェックを入れたか
• テスト・ビルド・ライセンスチェックを、フックやCIで自動的に回る形にしたか
• AI生成コードのPull Requestを可視化し、本番Pull Requestの承認人数を決めたか
• 破壊系操作は /rewindに頼らず、denyと git・バックアップで守る前提を共有したか
• 「うのみにしない・テストなしでマージしない」を明文化してチームへ共有したか

このリストのうち確認できていない項目は、そのまま導入前に詰めるべき論点になります。全部を一度に完璧にする必要はありません。管理設定のdenyと認証情報の遮断、レビューとテストの担保。この最低ラインを確保できていれば、まずは運用を始められます。

自社だけでゼロから設計するのは、思ったより手間がかかります。許可リストの粒度、管理設定の配布、CLAUDE.md やフックの整備は、実際に手を動かして初めて勘所が分かる部分が多くあります。さらに、さきほどの組織ガバナンス（監査ログ・SSO・データ所在地・MCP・インジェクション対策）は、現状を棚卸しするところから始まります。開発現場の設計は自分たちで決められても、組織全体の現在地を客観的に把握するのは、第三者の目があっても良いかもしれません。

「便利そうだが社内コードを扱わせていいのか」という最初の問いは、決めるべきことを決めれば、答えを出せます。扱う資産を把握し、管理設定で危険な操作を禁じ、機密は渡さずdenyで拒否し、レビューとテストを仕組みで担保する。そのうえで、組織ガバナンスの現在地を確かめる。この設計を、自社の状況に合わせて一緒に組み立てるところから始められます。