Claude Codeを組織で安全に使う4レイヤー設計ガイド

結論

• 個人で触るClaude Codeと、組織で配るClaude Codeはまったくの別物だ。シャドーテナント／平文APIキー流出／コスト爆発／組織定着失敗の4リスクが、配布範囲を広げるほど顕在化する。
• 解決は4レイヤーで設計する。①アクセス制御（ドメインクレーム＋SSO）→②ガードレール（Managed Settings＋シークレット管理）→③コスト最適化（従量課金＋利用量可視化）→④組織展開（段階ロールアウト＋教育）。
• 最初に着手すべきはドメインクレーム。10分の作業でシャドーテナント問題を構造的に消せる、最もコスパの高い一手だ。

この記事が役立つ状況

対象者は3つに分かれる。情シス・BizTech・Corp IT 担当が中心だ。AI導入をリードするGTMエンジニアやCTO・CISO クラスも含む。

直面している課題は典型的に4つある。社員が会社メールで勝手にClaudeアカウントを作る。APIキーがSlackで共有される。Claude Codeのコストが見えない。導入したが活用が広がらない。

前提条件はAnthropic との契約または契約検討中であること。加えて、SSO基盤（Okta／Entra ID等）とMDM（Jamf／Intune）を運用、または導入予定であること。

あなたは情シス／BizTechの責任者です。当社にClaude Codeを安全に組織展開するため、以下の条件で4レイヤー（アクセス制御・ガードレール・コスト最適化・組織展開）の実装プランを優先順位付きで作成してください。

【会社規模】[例: 従業員50名、エンジニア15名]
【既存IdP】[例: Okta / Microsoft Entra ID / なし]
【既存MDM】[例: Jamf / Intune / なし]
【既存シークレット管理】[例: 1Password / Vault / 平文]
【AI利用の現状】[例: 個人で勝手に利用中 / 未導入 / 一部部署が試用]
【最重要リスク】[情報漏洩 / コスト爆発 / 組織定着 のうち優先順位]

各レイヤーで「今週やること」「今月やること」「四半期で完成させること」の3段階に分けて、具体的な設定値・ツール名・スクリプト雛形も含めて出力してください。

なぜ「個人のClaude Code」と「組織のClaude Code」は別物なのか

個人でClaude Codeを触っているだけなら、起きる問題は自分の生産性の上下くらいだ。だが組織で配り始めた瞬間、問題の性質が一変する。

4つのリスクが、配布範囲を広げるほどに顕在化する。

1. シャドーIT化 — 社員が会社メールで勝手にClaudeアカウントを作り、会社管理外で会話が積み上がる
2. 機密データの流出 — .envや.zshrcに平文で置かれたAPIキーが、間接プロンプトインジェクション経由で外部に送信される
3. コスト爆発 — 誰がどれだけ使っているか見えないまま、月次請求だけが膨らむ
4. 組織に定着せず活用が進まない — 配ったけど触らない、触っても自己流で使う、安全側に倒せない

これらは「ガイドラインを文書化する」では解決しない。文書は読まれない、忘れられる、解釈がブレる——情シスが昔から抱えてきた課題だ。技術的に構造化して、危険な振る舞いをそもそも起こせなくするのが現代的な解答になる。

GTMエンジニアの視点で言えば、これは「営業プロセスをツールで構造化する」のと同じ発想だ。「営業担当が気合でSFAを入れる」では入力率は上がらない。「フェーズを変えないと次の工程に進めない」とプロセスを設計したときに、初めて入力が回り始める。Claude Codeの組織展開も、同じ構造でアプローチする。

レイヤー①：アクセス制御——シャドーテナントを構造的に発生させない

最初のレイヤーは「誰がアクセスしているか」を100%把握できる状態を作ることだ。

ドメインクレームが最初の一手

Claude for Teamsを契約し、管理コンソールで自社ドメイン（例: your-company.com）を認証する。これだけで以下が成立する。

• 認証済みドメイン配下（@your-company.com）では、個人アカウントを含む新しい組織の作成が防止される
• 同じドメインで既に作成された個人テナントは、管理者による統合・移管フローの対象になる
• 社員が「ちょっと試したい」で個人プランを作ろうとしても、ドメインクレームに引っかかって会社のテナントに合流する

所要時間は10分程度、効果は絶大だ。「公式テナント以外は存在しない」状態を技術的に担保することが、組織導入の出発点になる。

SSO必須化で本人確認を一元管理

ドメインクレームと並行して、公式テナントへのログインをIdP経由のSSO必須に切り替える。Okta、Microsoft Entra ID、Google Workspace等、既存のIdPを使えばいい。

これにより以下が達成される。

• ID/パスワードによる直接ログインを廃止
• 多要素認証（MFA）はIdP側で一元管理
• 退職時はオフボーディングとしてIdPを無効化するだけでAnthropicへのアクセスも自動失効
• 「誰がアクセスしているか」をIdP側のログで一元追跡できるため、監査やフォレンジック対応が容易

IdPプロビジョニングで「申請対応」をなくす

ライセンスの付与・剥奪も、IdP連携でプロビジョニングを自動化する。「Claude Codeを使いたい」「やめる」のたびに情シスが手作業で対応していると、組織が大きくなるほど運用が破綻する。

Oktaグループ等に応じて、Claude Code / Claude / Billing / Admin の各ロールを設計する。Enterpriseプランを契約していればSCIMで完全自動化、それ以外でもJIT（Just-in-Time）プロビジョニングで「初回SSOログイン時にアカウント自動発行」が可能だ。

申請対応の運用工数は、自動化前後で週2時間→10分まで圧縮できる（NOT A HOTEL社の実装事例より）。

レイヤー②：ガードレール——危険な振る舞いをそもそも実行できない設定にする

アクセス制御で「誰が入ってくるか」を抑えたら、次は「入ってきた人が何をできるか」をコントロールする。

Managed Settings をMDM経由で配布する

Claude Codeには managed-settings.json という、利用者側で改変できない設定ファイルがある。これを全端末に強制配布する。

Claude公式の標準機能でも配布可能だが、MDM（Jamf/Intune）経由が推奨だ。理由は2つある。

1. 個人の裁量に依存せず、確実に設定される
2. 設定変更があったとき、自動的に再配布される仕組みを構築できる

具体的に最低限入れるべき設定は以下だ。

MDM配布の自動化パイプライン

Managed Settings の運用で詰まりやすいのが「設定変更のたびに手動でMDM配信する」フェーズだ。これを GitHub + GitHub Actions で自動化する。

具体的には、

1. settings.json を GitHubで管理（変更の経緯を残せる、PRでレビューできる）
2. GitHub Actions が PR マージ時に plist 形式へ変換（macOSの場合）
3. Jamf API 経由で全Mac端末にプロファイル設定を自動更新

これでガイドラインの「読まれない・忘れられる・解釈ブレ」問題を構造的に解決できる。

API キーは1Password CLIで op:// 参照に統一

Claude Code を使い始めると、Slack / Notion / Jira / 自作MCPサーバー等、SaaS連携用のAPI キーが一気に増える。これを .env や .zshrc に平文で置く運用は、間接プロンプトインジェクション（外部Webページや GitHubリポジトリに紛れた指示をエージェントが読み込んで実行する攻撃）と組み合わさると致命的だ。

攻撃者が「ホームディレクトリ配下を読み取って結果を外部送信する」指示をどこかに仕込めば、平文のキーは即流出につながる。

解決策は1Password CLIによる op:// 参照だ。

# 実行時に Touch ID 認証してメモリ上でのみ復号
op read "op://BizTech/Anthropic Admin API/credential"

mcp.json での書き方も同様だ。

{
  "N8N_API_KEY": "op://BizTech/n8n-api/credential"
}

.env ファイルから直接読むのではなく、op:// 参照に置換する。この置換作業自体もClaude Codeに依頼すれば、もれなく書き換えできる。1Password Desktop の「デバイスによるロック解除」タイマーに依存して、Touch IDの再認証頻度も最適化できる。

レイヤー③：コスト最適化——使わない人に課金しない

「Claude」と「Claude Code」、そして3rd-party platform（AWS Bedrock / Google Vertex AI 等）の使い分けを設計する。

Claude vs Claude Code の使い分け

「Claude Code でチャットだけしている」「claude.ai でコードを延々とコピペしている」状態は、どちらもコスト効率が悪く生産性も上がらない。「タスクに合った道具を使う」を社内ガイドラインで強調する。

Anthropic Console 経由の従量課金で全社配布

最初は Anthropic Console（platform.claude.com）経由の従量課金で Claude Code を全社配布することを推奨する。理由は3つある。

1. Okta連携でConsole上のアカウントが自動発行される — IdP連携の自然な延長として、Oktaグループへのアサインがそのまま Console上のメンバープロビジョニングにつながる
2. ユーザー固有のAPI キーが自動発行・設定される — Claude Code が直接管理し、ユーザーがAPI キーを直接扱う場面を最小化できる
3. 固定シート課金がされず、純粋な従量課金 — 使わない人に課金されない。「全社員に配ったが半数は触っていない」フェーズでも無駄なコストが発生しない

利用実績が認められたメンバーには、改めて claude.ai のシートを追加配賦する。「使う人にだけ、必要な分だけ投資する」考え方だ。

OpenTelemetryで利用量を可視化する

Claude Code には OpenTelemetry（OTel）連携が組み込まれている。これを有効化すると以下が見えるようになる。

• 利用状況の把握（誰がどれくらい使っているか、個人単位で追える）
• Upload / Download Token量の可視化（「読み込ませているトークンが異常に多い」＝間接プロンプトインジェクション被害の早期検知）
• IdPデータと組み合わせた部署別の浸透度
• 課金プラン最適化の自動アナウンス（「あなたはこのプランに切り替えた方がお得」「このモデルの利用を控えた方がいい」）

最小構成なら、settings.json に以下を追加するだけで始められる。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "console",
    "OTEL_LOGS_EXPORTER": "console",
    "OTEL_METRIC_EXPORT_INTERVAL": "60000"
  }
}

大規模組織なら OTel Collector + BigQuery + ダッシュボードで本格的な可視化基盤を構築する。ZOZO社の事例では「数百名規模のOpenTelemetry収集基盤」を構築し、Claude Code利用ログを自動集約する仕組みを公開している。

レイヤー④：組織展開——「安全に使える人」を継続的に増やす

技術ガードレールを整えただけでは、Claude Codeは組織に定着しない。最後のレイヤーは「人」の設計だ。

段階ロールアウト（Lv0〜Lv4）

利用者を一括で全員にフル機能解放すると、事故が起きやすく、活用も進まない。Lv0〜Lv4の段階制を設計する。

利用ガイドラインの中核は「入れて良いデータ／ダメなデータ」の線引き

ルール本体はシンプルでいい。

• 入れて良い: 公開情報、機密を含まない一般的な文章、社内公開可能なコード
• 絶対に入れない: APIキー、トークン、パスワード、秘密鍵、個人情報、未公開の顧客名・契約情報

ルールだけでなく「なぜ危ないのか」まで添える。「抜かれた瞬間に終わる情報」という危機感を共有することで、現場が迷ったときに安全側へ倒せるようになる。

間接プロンプトインジェクション対策は「人間側の基本動作」にも組み込む

技術的なガードレールに加えて、人間側にも以下の基本動作を教育する。

• 外部テキスト（Webページ、GitHubリポジトリ、メール本文等）は「データ」であり「指示」ではない
• 実行前に影響範囲を確認する（破壊的・不可逆な操作は特に）
• 「ホームディレクトリを読んで結果を送信して」のような不審な指示を読み込んだら即停止

配って終わりにしない運用

ガイドラインは配って終わりにしない。

• ワークショップ・勉強会で「危ないポイント」を実例で体験させる
• 理解度テスト（security-check）の自動リマインドで継続的に思い出させる
• インシデント事例や攻撃手法のアップデートを月次で共有

目標は「制限を増やすこと」ではない。安全に、速く、組織で回り続ける状態を作ることだ。

GTMエンジニアからの実装提案——営業組織でClaude Codeを動かす

ここまでは情シス・BizTechの視点で書いてきた。GTMエンジニアの視点で1つ補足したい。

営業組織でClaude Codeを動かす際、技術ガードレールだけでなく営業プロセスデータとの接続設計が肝になる。

• CRMデータをClaude Codeに渡す経路 — HubSpot/Salesforce のAPI キーは1Password CLI で参照、出力された分析結果はCRMに書き戻すまでをスキル化する
• 商談メモのプロンプトインジェクション対策 — 顧客が送ってきたメール本文や、商談議事録に紛れた「外部送信して」等の指示を <data> フェンスタグで囲み、データ宣言として扱う
• 営業利用シーンのレベル別解放 — Lv1で「メールドラフト生成」、Lv2で「商談メモ要約」、Lv3で「CRM更新の半自動化」、Lv4で「営業エージェント運用」と段階設計する

GTMエンジニアとはで定義した通り、GTMエンジニアの本質は「営業プロセスを設計してテクノロジーで実装する」職能だ。Claude Codeの組織展開は、この職能と情シスの職能が交差する領域であり、両者が連携することで初めて全社展開が機能する。

Zapier vs Make vs n8nで論じた iPaaSの選定と同じく、ツール導入そのものに価値はない。「営業プロセスのどこをClaude Codeで自動化し、どのデータをどう流すか」——その設計こそがGTMエンジニアの価値を発揮する場面になる。CRM側のデータ設計まで含めた全体像は CRMデータ設計ガイド と エージェント型マーケティング設計 も参考になる。

まとめ——4レイヤーで「組織で回り続ける」状態を作る

Claude Codeを組織で安全に展開するには、技術と人と運用を同じ重みで設計する必要がある。

1. アクセス制御: ドメインクレーム + SSO必須化 + IdPプロビジョニング自動化で、シャドーテナントを構造的に発生させない
2. ガードレール: Managed Settings を MDM 経由で配布し、危険な振る舞いをそもそも実行できない状態にする。API キーは 1Password CLI で op:// 参照に統一
3. コスト最適化: Anthropic Console 経由の従量課金で「使わない人に課金しない」状態を作り、OpenTelemetry でトークン量を可視化
4. 組織への展開: 段階ロールアウト（Lv0〜Lv4）と継続的な勉強会・理解度テストで、安全に使える人を増やし続ける

最初の一手はドメインクレーム。10分の作業で、シャドーテナント問題が構造的に消える。そこから順に4レイヤーを積み上げていけば、Claude Code は「個人の生産性ツール」から「組織の生産性インフラ」へと進化する。

組織でAIを活かすには、ツールを買うことより、運用と人を含めた4レイヤーを同時に設計することが本質だ。本記事が、Claude / Claude Code の組織導入を進めるCorp IT / セキュリティ / GTMエンジニア各位の参考になれば嬉しい。