結論：Claude Codeを法人・チームで安全に使うには、権限設計・データ保持・MCP監査・シークレット管理・監査ログの5つの柱を最初に整備することが不可欠だ。ツールの便利さに引きずられて「とりあえず全許可」で展開すると、後から取り返しのつかないセキュリティインシデントに直結する。
- 要点1：
--dangerously-skip-permissionsを本番・共有環境で使わない。個人の開発PCで検証する場合に限り、リスクを理解したうえで使用する - 要点2：MCPサーバーへの接続は「必要最小限のスコープ」を原則とし、接続先・認証情報・権限範囲を定期的に棚卸しする
- 要点3：APIキー・シークレットをプロンプトや会話履歴に混入させない運用ルールをチーム全員が理解・徹底することが、最も発生頻度の高いリスクを防ぐ
対象読者：情報システム部門・セキュリティ担当者・CTO・開発組織のマネージャー。Claude Codeのチーム展開を検討している、または展開済みで改めてセキュリティ体制を整備したい方。
今日やること：記事末尾の「法人導入セキュリティチェックリスト（25項目）」を印刷またはNotionにコピーし、自チームの現状と照らし合わせる。
「Claude Code、すごく便利なんですが、会社で使うにあたってセキュリティ面が心配で…」
法人向けAI研修や導入支援をしていると、このひとことが最初に出てくるチームが本当に多いんです。気持ちはよくわかります。コーディングエージェントがファイルシステムを操作し、外部サーバー（MCPサーバー）と通信し、コードを自律的に実行する——そういう存在を社内に持ち込む判断には、相応の根拠が必要です。
実際に私が支援した複数の開発組織での展開事例（実案件ベース・匿名化済み）を振り返ると、セキュリティインシデントや「展開後に慌てて設定を見直す」という事態は、ほぼ例外なく「導入前のセキュリティ設計が後回しになっていた」ことが原因でした。逆に言えば、最初にきちんと設計しておけば、あとは安定して使い続けられる。
この記事では、Claude Codeを法人・チームで使う際の「セキュリティ完全チェックリスト」を、実務視点でまとめます。Anthropicの公式ドキュメント（Claude Code Security — Anthropic公式ドキュメント、2026年5月時点）をベースに、実際のチーム展開で詰まりやすいポイントを補足する構成です。
Codex vs Claude Codeの選定検討についてはCodex vs Claude Code比較ガイドも参考にしてください。また、MCPサーバーの実践的な使い方についてはClaude Code MCP実践ガイドに詳しくまとめています。
Claude Codeのセキュリティモデルを正しく理解する
チェックリストに入る前に、Claude Codeがどういう仕組みで動いているかを整理しておくと、各設定項目の意味が分かりやすくなります。
Claude Codeは「AIエージェント」として動作します。つまり、ユーザーの指示を受けてコードを書くだけでなく、ファイルの読み書き・シェルコマンドの実行・外部ツール（MCPサーバー）の呼び出しを自律的に行います。この自律性こそが便利さの源泉であり、同時にセキュリティリスクの源泉でもあります。
Anthropicの設計思想として、Claude Codeは「デフォルトで最小限の権限」を持ち、ユーザーが明示的に拡張することで権限が広がる仕組みになっています（Anthropic Enterprise — Anthropic公式、2026年5月時点）。この設計思想を理解していれば、「どこに何のリスクが潜むか」が見えてきます。
処理フローのセキュリティ接点
法人利用でセキュリティを検討すべき接点は大きく5つあります。
- ローカルファイルシステムへのアクセス：Claude Codeがプロジェクトディレクトリ内のファイルを読み書きします。意図せずシークレット（APIキー等）を含むファイルを読み込んでしまうリスクがあります。
- シェルコマンドの実行：bash / sh / zshを通じてコマンドを実行します。権限設定次第では、想定外のコマンドが実行される可能性があります。
- 外部通信（Anthropic APIへの送信）：会話内容・コードがAnthropicのサーバーに送信されます。エンタープライズ契約の有無によってデータ保持ポリシーが異なります。
- MCPサーバーへの接続：設定したMCPサーバーと通信します。接続先・認証情報の管理が必要です。
- チームメンバー間の設定共有：
.claude/settings.jsonをGitで共有する場合、設定の意図しない共有・上書きが起きます。
権限・パーミッション設計の正しい考え方
法人展開でまず設計すべきは「権限の最小化」です。Claude Codeには複数のパーミッションモードが存在し、その選択が安全性を大きく左右します。
パーミッションモードの種類と用途
Claude Codeには以下のパーミッション設定があります（Anthropic公式ドキュメント、2026年5月時点）。
| モード / 設定 | 概要 | 法人推奨用途 |
|---|---|---|
| デフォルト（確認あり） | ファイル書き込み・コマンド実行前に確認プロンプトが出る | 個人開発・初期導入フェーズ |
--allowedTools 指定 |
使用可能なツールを明示的に列挙（許可リスト方式） | チーム共有設定で推奨 |
--disallowedTools 指定 |
使用禁止ツールを列挙（拒否リスト方式） | 特定ツール禁止時の補助として |
--dangerously-skip-permissions |
全確認プロンプトをスキップして自動実行 | 本番・共有環境での使用禁止 |
重要なのは、--dangerously-skip-permissions を本番環境や共有開発環境で使わないことです。このオプションはCI/CDパイプラインでの自動化テスト等を念頭に設計されており、その名称の通り「危険を承知で使う」フラグです。法人のチーム環境でこれを常用している実装を見かけることがありますが、ファイル削除・シークレット漏洩・意図しないコマンド実行のリスクが格段に上がります。
設定ファイルによる権限管理
.claude/settings.json（プロジェクト共有設定）または ~/.claude/settings.json（ユーザーローカル設定）でツール許可を管理できます。チーム展開では、プロジェクト単位の設定をGitリポジトリで管理し、「このプロジェクトではこの範囲のツールのみ使える」という構成にするのが堅牢です。
// .claude/settings.json（チームで共有する設定例）
{
"permissions": {
"allow": [
"Bash(npm run:*)",
"Bash(git diff:*)",
"Bash(git log:*)",
"Read",
"Edit",
"Write"
],
"deny": [
"Bash(rm -rf:*)",
"Bash(curl:*)",
"Bash(wget:*)"
]
}
}
許可リストはワイルドカード指定が可能です。たとえば Bash(npm run:*) は npm run で始まるコマンドのみを許可します。「とりあえず全部許可して後で絞る」ではなく、「最初に最小限を設定し、必要になったら追加する」 という方向で設計することを強く推奨します。
データ保持・外部送信範囲を正確に把握する
「社内の機密コードがAnthropicに送られているのでは？」という懸念は、法人展開の際に必ずといっていいほど出てくる論点です。正確な情報をもとに判断することが重要です。
何が外部に送られるか
Claude Codeを使う際にAnthropicのサーバーに送信されるデータは、基本的に「会話コンテキスト（プロンプトと応答の内容）」です。これにはあなたが貼り付けたコードスニペット、ファイル内容（Readツールで読み込んだもの）、実行結果などが含まれます。
つまり、「Claude Codeが読んだファイルの内容は、そのままAPIリクエストとしてAnthropicに送信される可能性がある」 と理解しておく必要があります。
プランによるデータ保持ポリシーの違い
Anthropicのデータ保持ポリシーは、利用プランによって異なります（Anthropic Enterprise — 公式、2026年5月時点）。
| プラン | 学習データ利用 | データ保持 | 法人向け推奨 |
|---|---|---|---|
| 無料 / Pro（個人） | モデル改善に使われる可能性あり | 一定期間保持 | 業務利用非推奨 |
| Teams | 原則的に利用しない（オプトアウト） | 保持期間短縮 | 中規模チームに適合 |
| Enterprise | 学習利用なし（ゼロデータ保持オプションあり） | 設定可能（最短ゼロ） | 高機密情報を扱う組織向け |
高機密なソースコード（未公開の特許アルゴリズム・金融系システムの中核ロジック・個人情報を含むコード等）を扱う組織では、Enterpriseプランのゼロデータ保持設定の確認を強く推奨します。最新のポリシーは必ずAnthropic Privacy Policy（公式）で確認してください。
社内秘匿コードの実務的な扱い方
プランに関わらず、以下の実務的な対策を取ることでリスクを下げられます。
# .gitignoreと同様に、Claude Codeに読ませたくないファイルを
# プロジェクトの .claude/settings.json で exclude できます
# 例：シークレット・認証情報を含むファイルをコンテキストから除外
# (Anthropic公式が.claudeignoreのようなファイルレベル除外の
# 正式仕様を提供している場合は最新ドキュメントを参照のこと)
また、コードレビュー・設計相談で使う場合も、機密度の高いファイルは「概要だけ渡してコードは添付しない」「変数名や定数をマスキングした擬似コードで渡す」といった運用上の工夫が有効です。これは技術的制約ではなくチームの運用ルールとして明文化することが大切です。
MCPサーバーの監査：見落とされがちな最大の盲点
法人展開のセキュリティ設計で最も見落とされやすいのが、MCPサーバー（Model Context Protocol Server）の管理です。
MCPはClaude Codeが外部ツール・サービスと連携するためのプロトコルです。たとえばGitHub・Slack・データベース・社内APIなどをMCPサーバーとして接続すると、Claude Codeはそれらを道具として使えるようになります。この拡張性がClaude Codeの強みですが、同時に「誰がどのサーバーに接続しているか」を管理できていないと重大なリスクになります。
MCPサーバーのセキュリティリスク
主なリスクは以下の3つです。
①接続先の信頼性：ユーザーが設定したMCPサーバーが、意図しないデータを外部に送信する可能性があります。特にサードパーティが公開しているMCPサーバーを使う場合、そのサーバーのコードやホスティング環境の信頼性を確認する必要があります。
②認証情報の保存場所：MCPサーバーへの接続には認証情報（APIキー・トークン等）が必要なケースが多く、それが設定ファイルに平文で書かれているケースがあります。
③過剰なスコープ：「とりあえず全権限で接続」している設定。GitHubのMCPであれば「読み取り専用」で十分な用途に「書き込み権限付き」で接続しているケースです。
MCPサーバーの設定確認方法
# MCPサーバーの設定場所を確認する
# グローバル設定（ユーザーレベル）
cat ~/.claude/claude_desktop_config.json
# プロジェクト設定（共有設定）
cat ./.mcp.json
# または
cat ./.claude/mcp.json
// MCPサーバー設定の推奨例（最小権限・認証情報は環境変数）
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
設定例のポイントは2つ。①認証トークンを直書きせず環境変数参照にしていること（${GITHUB_TOKEN}）、②GitHubトークンのスコープを最小限（必要なリポジトリのみ・読み取り専用等）に絞ること。
MCP監査の実施手順
四半期に1回程度、以下の観点でMCP設定を棚卸しすることを推奨します。
#!/bin/bash
# mcp_audit.sh — MCPサーバー設定の簡易監査スクリプト
echo "=== グローバルMCP設定確認 ==="
if [ -f ~/.claude/claude_desktop_config.json ]; then
echo "[存在] ~/.claude/claude_desktop_config.json"
# 認証情報の直書きをチェック（token/secret/password等の文字列）
grep -iE '"(token|secret|password|api_key)"\s*:\s*"[^$]' \
~/.claude/claude_desktop_config.json && \
echo "⚠️ WARNING: 認証情報が直書きされている可能性があります" || \
echo "✅ 認証情報の直書きは検出されませんでした"
else
echo "[なし] グローバルMCP設定ファイルが見つかりません"
fi
echo ""
echo "=== プロジェクトMCP設定確認 ==="
for f in .mcp.json .claude/mcp.json; do
if [ -f "$f" ]; then
echo "[存在] $f"
grep -iE '"(token|secret|password|api_key)"\s*:\s*"[^$]' "$f" && \
echo "⚠️ WARNING: $f に認証情報の直書きの可能性" || \
echo "✅ $f は問題なし"
fi
done
監査ログ・利用状況の可視化
「誰がClaude Codeを使ったか」「何をやったか」を把握できる状態にすることは、インシデント発生時の調査だけでなく、不正利用の抑止力にもなります。
Anthropic ConsoleのTeams/Enterprise管理機能
TeamsおよびEnterpriseプランでは、Anthropic Console（console.anthropic.com）から以下の管理機能が利用できます。
- 利用量ダッシュボード：メンバーごと・プロジェクトごとのAPIトークン消費量
- APIキー管理：発行・失効・スコープ設定
- メンバー管理：招待・削除・ロール設定
- コスト管理：利用上限の設定・アラート
プランや機能は更新される場合があるため、最新情報はAnthropic公式のEnterprise製品ページで確認することを推奨します。
ローカルでの操作ログ
Claude Codeのセッションログはローカルに保存されます（保存先はAnthropicの設定ドキュメントを参照）。社内のセキュリティポリシーによっては、このログを定期的に収集・保管する仕組みを設けることが求められる場合もあります。
# Claude Codeのログ保存場所を確認する（環境依存）
# macOSの場合、~/.claudeディレクトリ配下に保存されることが多い
ls ~/.claude/projects/ 2>/dev/null | head -10
シークレット混入防止：最も発生頻度の高いリスク
100社以上のAI研修・導入支援をしてきた中で、セキュリティ上の実害として最も多く見てきたのが「APIキーやシークレットがClaude Codeのプロンプトや会話履歴に入り込む」パターンです。
混入の典型的な経路
# ❌ よくあるNG：シークレットが含まれたファイルをそのまま読ませる
# Claude Codeに「このファイルを見てデバッグして」と頼む際に
# .env ファイルや config.yaml をまるごと添付してしまうケース
# .envファイルの例（これを読ませてはいけない）
DATABASE_URL=postgresql://user:PASSWORD_HERE@prod-server:5432/mydb
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
STRIPE_SECRET_KEY=sk_live_xxxxxxxxxx
# ✅ 正しいアプローチ：シークレット箇所をマスクして渡す
# デバッグ依頼時はシークレット値を置換する
DATABASE_URL=postgresql://user:***MASKED***@prod-server:5432/mydb
AWS_SECRET_ACCESS_KEY=***MASKED***
STRIPE_SECRET_KEY=***MASKED***
# または、接続設定の構造のみ渡す
# 「DatabaseのURLはこういう形式で、PORT部分だけ変更したい」のように
.gitignoreと同様の除外設定
プロジェクトで .env や認証情報ファイルを使っている場合、Claude Codeがそれらを自動的に読み込まないよう設定できます。また、そもそも .env を誤ってGitにコミットしないための pre-commit フックを導入することも、チームのセキュリティ衛生として有効です。
#!/bin/bash
# pre-commit フック例（.git/hooks/pre-commit に配置）
# シークレットパターンを含むファイルのコミットをブロック
# AWS Secret Access Keyのパターン
if git diff --cached --name-only | xargs grep -l \
'AKIA[0-9A-Z]{16}' 2>/dev/null; then
echo "⛔ AWS Secret Access Key が含まれる可能性があります。コミットを中断します。"
exit 1
fi
# Anthropic APIキーのパターン
if git diff --cached --name-only | xargs grep -l \
'sk-ant-[a-zA-Z0-9\-_]{80,}' 2>/dev/null; then
echo "⛔ Anthropic APIキーが含まれる可能性があります。コミットを中断します。"
exit 1
fi
exit 0
承認フロー：誰がどのリポジトリに何を許可するか
特にGitHub・GitLab等と連携した開発ワークフローでClaude Codeを使う場合、「誰がどのリポジトリに対してどこまでの操作を許可するか」の承認フローを明文化することが重要です。
推奨するアクセス管理の考え方
## チームのClaude Code利用ポリシー（テンプレート）
### 個人開発PCでの利用（制限なし）
- 個人のフィーチャーブランチ内での使用：自由
- ただしシークレット混入防止ルールは常に適用
### 共有開発環境・ステージング環境
- .claude/settings.jsonで許可ツールを明示的に設定
- --dangerously-skip-permissions 使用禁止
- 週次でMCP設定を確認
### 本番環境へのアクセス権限を持つ環境
- Claude CodeからのDB直接接続禁止
- 本番認証情報は読み込ませない
- 実行コマンドは必ず事前レビューを経る
### コードレビュー・PR作成での利用
- 対象ブランチのコードのみを渡す（本番設定ファイルを除外）
- PRタイトル・説明文の生成はOK
- マージ操作はClaude Codeに委任しない
MCPとGitHub連携時の権限設計
# GitHubトークンのスコープを最小限に絞る例
# 必要なスコープのみを選択してPersonal Access Tokenを発行
# コードレビュー支援のみ → read:user, repo（対象リポのみ）
# PR自動作成まで → repo（write）+ read:user
# Issue管理まで → repo + read:user + read:project
# Fine-grained personal access tokenを使えば
# リポジトリ単位・権限種類単位で細かく制御可能（2024年以降の推奨方式）
【要注意】法人展開でよく見る失敗パターン4選
実際の支援現場（実案件ベース・匿名化済み）で繰り返し見てきた失敗パターンを紹介します。
失敗1：全許可設定で展開し後から収拾がつかない
❌ 「まずは試してもらいたいから制限なしで展開した」
→ チームメンバーが本番DB接続設定を読み込ませてデバッグを依頼。接続文字列がAPIログに残る事態が発生。
⭕ 最初から allowedTools で読み取り専用ツールのみ許可。「本番環境接続情報を含むファイルのリストをドキュメント化し、それらは読み込み対象から外す」というルールをオンボーディング資料に明記する。
失敗2：MCPサーバーの認証情報を設定ファイルに直書き
❌ 「チームで共有するために .mcp.json にトークンをハードコードしてGitにプッシュした」
→ パブリックリポジトリへの誤プッシュでトークンが公開状態に。GitHubの自動スキャンで検出された後に失効させたが、露出時間は約30分。
⭕ 認証情報は必ず環境変数参照（${VARIABLE_NAME}）にする。.mcp.json は .gitignore に追加するか、認証情報なしのテンプレートのみをコミットし、実際の値はローカル設定またはシークレット管理サービスで注入する。
失敗3：--dangerously-skip-permissions をチーム標準設定に入れてしまう
❌ 「CI/CDで使っていたオプションをそのまま開発者の設定に横展開した」
→ あるメンバーがリファクタリング作業中に、意図せずプロジェクト外のファイルを削除するコマンドが確認なしで実行された。
⭕ --dangerously-skip-permissions はCI/CDパイプライン専用と明確に区別する。開発者の個人設定・チーム共有設定には含めない。
失敗4：監査ログの仕組みを最後回しにする
❌ 「便利に使っていたら使用量が予算を大幅超過。誰が何にどれだけ使っていたかの把握ができなかった」
→ APIキーが共有されており、個人ごとの使用量が分からない状態。
⭕ 展開初日から「メンバー1人1キー」または「プロジェクト単位キー」の体制を取り、Anthropic Consoleでの利用量監視・上限設定を導入する。コストアラートを月予算の70%・90%で設定しておく。
Anthropic Enterprise設定のポイント
Enterpriseプランを契約している組織向けの追加設定ポイントです（機能・仕様は更新される場合があるため、最新情報はAnthropic公式Enterpriseページを参照してください）。
SSO（シングルサインオン）の設定
EnterpriseプランではSSOが利用可能です。社内のIdP（Okta・Azure AD・Google Workspace等）と連携することで、「退職者のアクセスを一括無効化」「MFA（多要素認証）の強制」が実現できます。これは組織のガバナンス観点から特に重要な設定です。
ゼロデータ保持（ZDR）オプション
金融・医療・官公庁等の高機密データを扱う組織では、ZeroDataRetentionオプションを確認してください。会話データがAnthropicのサーバーに保存されないため、内部情報の取り扱いポリシーに沿ったコンプライアンス対応が可能になります。
APIキーの組織管理
個人アカウントのAPIキーではなく、組織が管理するAPIキーを発行・配布する体制にすることで、メンバーの入退職時のアクセス管理が一元化されます。キーには用途別に適切な名前と有効期限を設定し、定期的なローテーションを実施することを推奨します。
法人導入セキュリティチェックリスト（25項目）
ここまでの内容を、情シスやセキュリティ担当がそのまま使えるチェックリストとしてまとめます。展開前・展開後の定期チェックにご活用ください。
A. 権限・パーミッション設計（6項目）
- □ チーム共有の
.claude/settings.jsonで使用ツールの許可リストを定義している - □
--dangerously-skip-permissionsは個人開発PC・検証環境に限定し、チーム設定には含めていない - □ 本番環境への接続権限を持つサービスアカウントをClaude Codeに使わせていない
- □ 開発者ごとに個別のAPIキーを発行し、共有キーを使用していない
- □ Anthropic Consoleでメンバーのロール（管理者・一般ユーザー等）を適切に設定している
- □ APIキーに使用量の上限（ソフト・ハード）を設定している
B. データ保持・情報管理（5項目）
- □ 利用しているAnthropicプランのデータ保持ポリシーをチームリーダー・情シスが理解している
- □ 社内機密情報（未公開特許・個人情報・金融データ等）の取り扱いルールを文書化している
- □ 機密度の高いファイルをClaude Codeに読み込ませない運用ルールを周知している
- □
.env等のシークレットファイルは.gitignoreに追加し、誤コミットを防止している - □ 高機密データを扱う場合、Enterpriseプランのゼロデータ保持オプションを検討・確認している
C. MCPサーバー管理（5項目）
- □ 接続中のMCPサーバー一覧を文書化し、接続先の信頼性を確認している
- □ MCPサーバーの認証情報は設定ファイルに直書きせず、環境変数参照にしている
- □ MCPサーバーのトークン・キーのスコープを最小限（必要な権限のみ）に絞っている
- □ MCPサーバーの設定ファイル（
.mcp.json等）を.gitignoreまたは暗号化管理している - □ 四半期に1回以上、MCPサーバーの棚卸し（不要サーバーの削除・認証情報のローテーション）を実施している
D. シークレット混入防止（4項目）
- □ APIキー・パスワード・接続文字列をプロンプトに直接貼り付けない運用ルールを周知している
- □
pre-commitフックでシークレットパターンの検出・コミットブロックを導入している - □ 万が一シークレットが混入した場合の対応手順（キー失効→再発行→影響範囲調査）を文書化している
- □ シークレットスキャンツール（GitHub Secret Scanning等）を有効化している
E. 監査ログ・可視化（5項目）
- □ Anthropic Consoleで利用量ダッシュボードを定期確認する担当者・頻度を決めている
- □ 月次のコストアラート（予算70%・90%）を設定している
- □ メンバーの入退職時にAPIキーを適切に失効・移管する手順を定めている
- □ EnterpriseプランのSSO設定（退職者一括無効化・MFA強制）を活用している（Enterprise利用組織）
- □ セキュリティインシデント発生時のエスカレーションフロー（誰に報告→何を調査→どう封じ込める）を文書化している
よくある質問（FAQ）
Q1. Claude Codeで扱ったコードはAnthropicのモデル学習に使われますか？
プランによって異なります。TeamsおよびEnterpriseプランでは、原則としてモデル学習に使用されないよう設定されています（オプトアウト設定）。無料・Proプランでの業務利用は非推奨です。最新の利用規約・プライバシーポリシーはAnthropic公式で必ず確認してください。
Q2. --dangerously-skip-permissions は絶対に使ってはいけないのですか？
「絶対NG」ではなく「場所と目的を選ぶ」が正確です。CI/CDパイプライン内や、完全に隔離されたサンドボックス環境での自動テストには適しています。ただし、本番環境への接続を持つ開発機や、複数人が使う共有環境での常用は避けるべきです。
Q3. 社内のオンプレミス環境でClaude Codeを使えますか？
Claude CodeはAnthropicのAPIを使用するため、インターネット接続が必要です。完全オフライン・オンプレミスでの動作は現時点では提供されていません（2026年5月時点）。クローズドネットワーク要件がある場合はAnthropicのエンタープライズチームへの問い合わせを推奨します。最新状況はAnthropicのEnterprise製品ページを参照してください。
Q4. MCPサーバーを社内で自作・ホストする場合のセキュリティ要件は？
社内MCPサーバーを自作する場合は、①通信の暗号化（HTTPS / TLS）、②認証の実装（APIキー・JWT等）、③ログ記録（誰がいつ何を要求したか）、④入力バリデーション（プロンプトインジェクション対策）の4点が最低限の要件です。MCP仕様の詳細はAnthropicの公式ドキュメントを参照してください。
Q5. Claude Codeのセキュリティ設定を一括で配布する方法は？
チーム共有の .claude/settings.json をGitリポジトリで管理し、オンボーディング手順書に「このファイルをプロジェクトルートに配置する」と明記するのが最もシンプルな方法です。企業規模が大きい場合は、Enterpriseプランの管理機能でポリシーを一元管理できるか確認することを推奨します。
まとめ：今日から始める3つのアクション
- 今日やること：本記事の25項目チェックリストをコピーし、現在の自チームの設定と照らし合わせてみる。赤信号の項目を3つ以内に絞り、次の2週間で対応する優先順位を決める。
- 今週中：MCPサーバーの設定ファイルを開き、認証情報が直書きされていないかを確認する（上記の
mcp_audit.shスクリプトを参考に）。直書きが見つかった場合は環境変数参照に移行する。 - 今月中：チームの「Claude Code利用ポリシー」を1ページで文書化し、オンボーディング資料に組み込む。特に新メンバーへの説明コストを下げることが、長期的な安全運用の鍵になる。
次回予告：次回は「Claude Code × GitHub Actions：CI/CDパイプラインへの安全な組み込み方」を予定しています。MCPサーバーのCI環境設定、シークレット管理のベストプラクティス、自動テスト生成の実装例を詳しく解説します。
参考・出典
- Claude Code Security — Anthropic公式ドキュメント（参照日：2026-05-31）
- Claude Enterprise — Anthropic公式製品ページ（参照日：2026-05-31）
- Privacy Policy — Anthropic（参照日：2026-05-31）
