Claude Codeのセキュリティ運用｜法人開発で実践している7つの対策

「設定ファイルをコピペして終わり」では守れない

Claude Codeのセキュリティ設定について検索すると、settings.jsonにコピペするだけの初期設定ガイドがたくさん出てきます。サンドボックスを有効にする、機密フォルダの読み取りを禁止する、外部通信コマンドをブロックする——どれも正しい対策です。

ただ、私はClaude Codeを法人として複数のクライアント案件で使う中で、設定ファイルだけでは防げないリスクに何度か直面しました。

GitGuardianの「State of Secrets Sprawl 2026」レポートによると、AIコーディングツールを使ったコミットの秘密情報漏洩率は3.2%で、GitHub全体の平均1.5%の約2倍です。2025年にはGitHub上に2,865万件もの新しいハードコードされた秘密情報が追加されました（前年比34%増）。AIツールが便利になるほど、漏洩リスクも増えているのが現実です。

この記事では、初期設定の「その先」にある実務レベルのセキュリティ運用を、実際のインシデント経験も含めて7つにまとめました。

1. プロジェクト単位でpermissionsの厳しさを変える

Claude Codeのsettings.jsonには、グローバル設定（~/.claude/settings.json）とプロジェクト設定（.claude/settings.json）の2階層があります。多くの解説記事ではグローバル設定に一律のルールを書く方法を紹介していますが、実務では案件ごとに求められるセキュリティレベルが違います。

私の場合、開発内容の機密性に応じてプロジェクト単位でallow/denyの設定を調整しています。

• 機密性が高い案件（個人情報を扱うシステム開発等）：git pushを含む外部通信系コマンドを全面deny、ファイル読み取りも必要最小限に制限
• 機密性が低い案件（自社サイトの修正等）：開発効率を優先し、テスト実行やlint等を広めにallow

一律に厳しくすると確認ダイアログが増えすぎて「確認疲れ」が起き、中身を見ずにOKを押す癖がつきます。一律に緩くすれば当然リスクが上がります。案件の性質に応じてバランスを取るのが、複数プロジェクトを回す法人としての現実的な運用です。

2. MCP連携は「本当に必要か」で判断する

MCP（Model Context Protocol）は、Claude Codeと外部サービスをつなぐ拡張機能です。データベース操作、CMS投稿、クラウドサービス連携など、できることは非常に多い。私自身もMicroCMSやSupabaseとのMCP連携を業務で活用しています。

ただし、MCPは常にAPI経由で情報のやり取りを許可する機能です。つまり、接続している限り情報漏洩のリスクがゼロにはなりません。

2026年2月にはCheck Point Researchが、プロジェクトの設定ファイルに悪意あるMCP設定を仕込むことでリモートコード実行やAPIキー窃取が可能になる脆弱性（CVE-2025-59536、CVE-2026-21852）を報告しています。いずれも修正済みですが、MCP連携の攻撃面が現実のものであることを示した事例です。

私が実践しているMCPのセキュリティ判断基準は3つです。

• 本当に必要か？ 便利なMCPサーバーはたくさんありますが、「とりあえず入れておこう」は危険。使わないMCPを許可状態にしておくことはセキュリティ的にメリットがありません
• 水際での対策が取れるか？ そのMCPがどんなデータにアクセスできるのかを把握し、permissionsのdenyで補完できるかを確認する
• 使わなくなったら外す。 以前はデザイン系MCPも接続していましたが、別の方法で代替できると判断して外しました。接続数は最小限に保つのが原則です

3. 自動デプロイとの連携に潜む落とし穴

ここからは、私が実際に経験したインシデントの話です。

クライアントのWebサイト制作中、まだ完成前の段階だったので、検索エンジンにインデックスされないようrobots.txtやmetaタグを設定していました。ところがある日、Claude Codeが意図せずindexを許可する状態に設定を変更し、そのままGitHubにプッシュしてしまったのです。

GitHubとVercelを連携していたので、プッシュと同時に自動デプロイが走り、未完成のサイトが本番環境に公開されました。幸い早期に気づいて対処できましたが、privateリポジトリだから安全とは限らないことを痛感した出来事でした。

このインシデント以降、以下の対策を取っています。

• robots.txt、metaタグのnoindex指定、環境設定ファイルなど、公開状態に関わるファイルはpermissionsのdenyで明確に編集制限をかける
• Claude Codeにgit pushまで任せる場合は、デプロイ先のホスティングサービス（Vercel、Netlify等）の自動デプロイ設定を必ず確認する
• 本番環境への影響が大きいファイルの変更は、AIに任せず自分で行う

AIコーディングツールの利便性が上がるほど、「プッシュまでAIに任せる」場面が増えます。しかし、その先にある自動デプロイまで含めた影響範囲を意識しないと、思わぬ事故につながります。

4. Hooksでセキュリティチェックを自動化する

Claude CodeにはHooksという機能があります。特定のアクション（ファイル保存、コミット前など）をトリガーに、あらかじめ定義したスクリプトを自動実行する仕組みです。

私はこのHooksを使って、公に公開するもの（記事、提案資料、メール等）をエージェント機能で作成するとき、公開前に強制的にチェックリストと照合する運用をしています。

チェック項目の例：

• クライアントの社名・URL・担当者名が含まれていないか
• 案件の具体的な金額が記載されていないか
• 表記ルール（一人称、敬体等）が守られているか
• .envの内容やAPIキーが出力に含まれていないか

人間が毎回チェックリストを目視確認するのは限界があります。確認すべき項目が多いほど見落としが増える。Hooksで自動化すれば、AIが生成した成果物を別のチェックプロセスが機械的に検証するので、人的ミスを減らせます。

5. アクセス権限はアプリ構造で強制する

Claude Codeのセキュリティとは少し視点が変わりますが、AIを活用したシステム開発におけるセキュリティ設計として、避けて通れないのがアクセス権限の問題です。

介護施設向けのAI記録システムを開発したとき、1つの事業所内で複数の立場の人（事務員・管理者・現場スタッフ）が同じデータベースにアクセスする構成でした。当然、立場によってデータへのアクセス権限を分ける必要があります。入力だけ許可するのか、編集・削除も可能にするのか。

検討の結果、1つのアプリ内でアカウントを分ける方式ではなく、事務員・管理者向けアプリと現場スタッフ向けアプリを完全に分離しました。

1アプリでアカウント認証を分ける案もありましたが、現場のスタッフは介護業務の合間にシステムを操作します。ログインや認証の手間が増えると、結局使われなくなる。実務ではとにかく手間を減らすことが最優先です。アプリ自体を分けることで、認証の手間なく強制的に権限分けができました。

総務省の「令和6年版情報通信白書」でも、情報セキュリティ対策として「アクセス制御・権限管理」の重要性が繰り返し指摘されています。技術的に高度な対策を積み上げるよりも、アプリの構造レベルで権限を分離する方が、現場に無理なく受け入れられるケースは多いです。

6. クライアントへのセキュリティ説明は「リスクから入る」

AIツールを使った開発を提案すると、クライアントから「セキュリティは大丈夫ですか？」と聞かれることがあります。ここで「大丈夫です」と即答するのは最悪の対応です。

私がクライアントにセキュリティを説明するときは、必ず「リスク」から入ります。

1. まずリスクを説明する：AIツールを使うことで、どのようなセキュリティリスクが考えられるかを正直に、網羅的に伝える
2. 次に対策を提示する：そのリスクをどう極限まで低く、あるいはゼロにするかを、専門用語をできるだけ省いて説明する
3. 最後に人的リスクに言及する：技術的に防げる部分とは別に、社員による人為的な情報漏洩のリスクがあることを正直に伝え、クライアント側でもガイドラインの制定を求める

「リスクがあります」と先に伝えることで、クライアントは安心します。逆に「大丈夫です」から入ると、後からリスクが発覚したときに信頼を失います。

7. 技術で防げない部分こそ重要

ここまで6つの対策を紹介しましたが、正直に言うと、思わぬリスクは技術的な設定ではなく人為的な場面で発生することが多いです。

IPAが発表した「情報セキュリティ10大脅威 2026」では、組織向け脅威の第4位に「内部不正による情報漏えい等」、第7位に「不注意による情報漏えい等」がランクインしています。技術的なサイバー攻撃だけでなく、人に起因するインシデントが依然として大きな割合を占めています。

Claude Codeのsettings.jsonをどれだけ完璧に設定しても、以下のような場面には対応できません。

• スタッフがAIとの会話画面をスクリーンショットで外部に共有してしまう
• AIが生成した資料にクライアントの機密情報が含まれていることに気づかず、別の相手に送ってしまう
• 共有PCでClaude Codeのセッションを閉じずに離席する

こうしたリスクに対しては、組織としてのガイドライン制定が必要です。AIツールの利用ルール、情報の取り扱い基準、インシデント発生時の対応フローを整備する。技術的な対策と人的な対策の両輪が揃って、はじめてセキュリティは機能します。

まとめ：設定・運用・人の3層で守る

Claude Codeのセキュリティは、settings.jsonの初期設定がスタート地点に過ぎません。法人として複数の案件を扱う中で見えてきたのは、「設定」「運用」「人」の3つのレイヤーで守る必要があるということです。

• 設定レイヤー：permissions、sandbox、MCP管理。プロジェクト単位で適切に調整する
• 運用レイヤー：自動デプロイの影響範囲を把握する。Hooksで自動チェックを組み込む。使わないMCPは外す
• 人レイヤー：ガイドラインを制定する。クライアントにもリスクを正直に伝え、人に関するルール作りを求める

AIコーディングツールは今後さらに普及します。便利さと引き換えにリスクが増えるのは避けられません。だからこそ、設定をコピペして終わりにせず、自分の業務に合ったセキュリティ運用を設計することが大切です。