Claude Code組織導入で失敗しない4つのレイヤー設計【ガバナンス完全版】

こんにちは。もるふぉです。

「個人で使ってたClaude Codeを全社に広げてくれない？」

金曜の夕方、上長からこんなふうに振られた経験ありませんか。

Claude Code 組織導入、最初の壁は技術じゃないんですよね。「いいですよ、社員にインストール手順を共有するだけでしょ」——そう思った方、ちょっと待ってください。

真面目に設計し始めると、これが想像以上に深い話なんです。

個人利用の延長で配ると、ほぼ確実にどこかで詰みます。

しかも「サービス停止」みたいな派手な詰み方じゃなくて、「気づいたら全社のAPIキーが社員の.envファイルに散らばってる」とか「退職者のアカウントが残ったまま動いてた」とか、地味に効いてくるやつです。

この記事では、Claude Code 組織導入を「4つのレイヤー」で設計するフレームワークをまとめます。

ベースにしているのはNOT A HOTELのkajinariさんが公開している実装事例で、4レイヤー構造そのものはこの記事から学ばせてもらいました。

Claudeを組織で安全に使うために NOT A HOTELで実施している４つのレイヤー｜kajinari | モダンな情シス

「自分の作業を加速させる Claude」と「全社の生産性向上ツールとしての Claude」は、似て非なるものでした。 NOT A HOTEL コーポレートITチームでは、2026年2月から Claude Code を含む Anthropic 製品の組織導入に取り組んできました。個人で触っていた頃には見えなかった4つのリスク——シャドーIT 化、機密データの流出、コスト爆発、組織に定着せず活用が進まない——が、配布範囲を広げるほどに浮かび上がってきます。 この記事では、私たちが1ヶ月で組み上げた「4つのレイヤー」を、実装の具体例と実体験のエピソードを交えて紹介します。 アクセス制御

note.com

ただ、kajinariさんの記事はNOT A HOTELの具体実装に踏み込んでいる分、「自社にどう当てはめるか」を別途考える必要があります。

そこで本記事では、4レイヤーをフレームワーク化して、組織規模や成熟度に応じて「どこから手をつけるか」を判断できる形に整理しました。

情シスやSRE、テックリードの方が、上長への説明資料の骨子に使えるレベルを目指しています。

Claude Code 組織導入の前提：個人利用と組織利用の5つの違い

本題に入る前に、なぜ個人利用の延長では詰むのかを言語化しておきます。

ここを共有しないと、上長や情シスとの会話が噛み合わなくなるからです。

まず、この表を見てください。

「あー、うちのチームって個人利用のままだな……」と感じた箇所、ありませんでしたか。

この5つは、どれもエンジニアの頭の中では「やった方がいいよね」レベルの認識だったりします。

でも実際に組織で配ると、優先順位が一気にひっくり返ります。

たとえば認証。

個人利用なら「個人アカウントでログインしてください」で済みますが、組織でこれをやると退職者のアカウントが残り続けたり、私用Gmailで契約した人のチャットが組織から完全に見えないシャドーテナント化が起きます。

「会社のメアドで契約してれば見えるでしょ？」と思った方、これが実は罠なんです。

詳しくはレイヤー1で解説しますが、ドメインを組織にクレームしておかないと、社員が個人プランで会社メアドを使って契約していても、組織管理コンソールからは一切見えません。

つまり、「組織導入したつもりで個人プランが社内に乱立してた」みたいな状態が普通に起こりえます。

4つのレイヤーで考える理由

これらの5つの違いを技術スタック的に整理すると、4つのレイヤーに分解できます。

1. アクセス制御 - 誰が使えるか（認証・プロビジョニング）
2. ガードレール - 何ができるか（権限・APIキー・MDM）
3. コスト最適化 - いくら使っているか（可視化・課金設計）
4. 組織展開 - どう広げるか（教育・段階的ロールアウト）

ポイントは、この4つに「依存関係」があることです。

ビルの基礎工事に例えると、レイヤー1（アクセス制御）が地盤、レイヤー2（ガードレール）が柱、レイヤー3（コスト最適化）が配管、レイヤー4（組織展開）が内装と入居者教育、というイメージです。

地盤が緩いまま柱を立てても、後で全部やり直しになります。

だから、Claude Code 組織導入を任されたら、まずレイヤー1から順に押さえていくのが定石です。

ただし、規模によっては優先順位が変わります。

5〜50名の組織と300名以上の組織では、最初の一歩が違う。

これは記事後半の「成熟度マップ」で具体的に書きます。

それでは、レイヤー1から見ていきましょう。

レイヤー1 アクセス制御：Claude Code Okta SSO設定で「誰が使えるか」を組織で管理する

レイヤー1の目的は、「誰がClaude Codeを使っているか」を組織側で完全に把握・制御できる状態を作ることです。

ここが緩いと、後段のガードレールやコスト管理がそもそも成立しません。

「誰が使ってるか分からないものに、ポリシーを強制したりログを集めたりはできない」という単純な話です。

このレイヤーで押さえるのは3点。ドメインクレーム、SSO強制、SCIMプロビジョニングです。

ドメインクレームでシャドーテナントを封じる

Claude Code 組織導入で一番最初にやるべきことが、ドメインクレームです。

地味に知られていないんですが、めちゃくちゃ重要です。

自社のメールドメイン（例: @example.co.jp）を組織のAnthropicテナントに紐付けることで、そのドメインを使った新規アカウント作成を組織配下に強制できます。

これをやらないとどうなるか。

社員が「会社のメアドで個人プランに登録」しちゃうんです。

しかも本人は組織契約してるつもりだったりします。

結果として、組織管理画面から見えない個人アカウントが社内に大量発生する「シャドーテナント」状態になります。

退職時にそのアカウントを止めることもできないし、何を会話したかも追えない。

これ知らずに放置してる組織が、一番危ない状態にあります。

ここを塞いでないと後の全部が無意味です。

具体的な手順は、Anthropic側に「このドメインは弊社のもの」と申請して、DNSのTXTレコードで所有権を証明する、という標準的なフローです。

実装の詳細は公式ドキュメントを参照してもらうとして、ポイントは「Claude Code 組織導入の初日に着手する」こと。

社員に展開アナウンスを出す前に、ドメインクレームを完了させておかないと、フライング個人契約が混ざります。

Okta SSOで強制認証を実装する

ドメインを押さえたら、次はSSOで「自社IdP経由でしかログインできない」状態にします。

Claude Code Okta SSO 設定の流れは、ざっくりこんな感じです。

OktaのアプリケーションカタログからAnthropicコネクタを追加して、SAMLまたはOIDCで連携。Anthropic側の管理画面でSSO強制をONにすると、メールアドレスとパスワードでの直接ログインがブロックされます。

Azure ADやGoogle Workspaceでも同じ考え方で実装できます。

ここで地味に効くのが、「強制」というフラグです。

SSO「を有効化」と、SSO「を強制」は意味が違います。

有効化だけだと「メアド+パスワード」のフォールバック認証が残ったままなので、退職者のメアドが残っていれば普通にログインできちゃいます。

「強制」まで設定して、ようやくIdP経由しか入れない状態になる。

ガバナンス監査のときに「SSO入れてます」と胸を張って答えたら、「強制になってないですね」と指摘されるパターンが、現場でちょこちょこ発生しています。

Claude Code IdP プロビジョニング 自動化（SCIM）で人事異動に追従する

SSOで認証を一本化したら、次はSCIMによるプロビジョニング自動化です。

SCIM（System for Cross-domain Identity Management）は、IdP側でユーザーを追加・無効化したときに、連携先サービスに自動反映する仕組みです。

手動運用で「退職者削除」をやり続けるのが、現実的に無理だからです。

退職処理の漏れって、規模が大きくなるほど100%発生します。

人事と情シスの連携が完璧な会社でも、月に1〜2件は「あれ、まだアカウント残ってましたね」が出てきます。

SCIMを入れると、IdP側でユーザーを無効化した瞬間にClaude Code側のアクセスも止まります。

これだけでセキュリティ事故の温床がひとつ消えます。

ついでに、新入社員の追加も自動化されるので、入社初日にClaude Codeが使える状態を用意できます。入社オンボーディングの体験品質も上がる、おまけ付きです。

なお、SCIMを実装するには、EnterpriseプランまたはConsole organizationである必要があります（TeamプランはJIT（Just-in-Time）プロビジョニングまでに留まり、SCIMは含まれません）。

組織規模が50名を超えてくる頃には、Enterpriseプランへの移行を検討するタイミングが来ます。

【チェックリスト】アクセス制御レイヤーの実装確認

ここまでで、レイヤー1の3要素を見てきました。

今すぐ確認できる自社の状態チェックリストです。

• 自社ドメインを組織のAnthropicテナントにクレーム済みか
• DNSのTXTレコードでドメイン所有権を証明済みか
• SSOが「有効化」ではなく「強制」になっているか
• メアド+パスワードでのフォールバックログインが無効化されているか
• IdP（Okta/Azure AD/Google Workspace）とSCIM連携が動いているか
• 退職処理時にClaude Codeアカウントも自動無効化されるか

このうち1つでも「No」があれば、そこから先のガバナンス設計はザルになります。

順番にYesを増やしていく感じで進めていくのがおすすめです。

次のレイヤー2では、ここで認証された「使える人」に対して、「何ができるか」を細かく制御する話に入ります。

ここからが、ガバナンスのコア部分です。

レイヤー2 ガードレール：Claude Code セキュリティ設定 企業向けmanaged-settings.json実装

レイヤー2は、認証済みの社員に対して「使える機能・コマンド・権限」を組織側で固定する層です。

個人利用なら「自分で気をつけてればOK」で済みますが、組織でこれをやると、必ず誰かがやらかします。

悪意なく、です。

たとえば、「ちょっと早く片付けたいから」と権限プロンプトをスキップして、テストDBに対して DROP TABLE を流してしまう、みたいなケース。

これを「個人の意識」で防ごうとするのが、組織運用としては筋が悪い。

ポリシーで「そもそもできない」状態にするのが正攻法です。

ここで主役になるのが managed-settings.json です。

managed-settings.jsonの基本構造と必須パラメータ

managed-settings.json は、Claude Codeの動作を組織管理者側で固定する設定ファイルです。

ユーザーが個人設定で上書きできない、強制ポリシーです。

これが何をもたらすかというと、「組織側から一斉にルールを強制できる」状態です。

MDM経由で配信すれば、社員が何もしなくても全員に同じポリシーが適用される。

設定の詳細は公式ドキュメントを参照してください。

Claude Code settings - Claude Code Docs

Configure Claude Code with global and project-level settings, and environment variables.

code.claude.com

基本構造はこんな感じです。

{
  "permissions": {
    "defaultMode": "default",
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl * | sh)",
      "WebFetch"
    ]
  },
  "disableBypassPermissionsMode": "disable",
  "cleanupPeriodDays": 7,
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": "your-org-uuid-here"
}

順番に意味を見ていきます。

permissions.deny は、組織として絶対に許可しないコマンドや操作のリスト。破壊的なBashコマンド、外部スクリプトのパイプ実行、WebFetchの無条件許可などをここでブロックします。

disableBypassPermissionsMode を disable にすると、ユーザーが --dangerously-skip-permissions フラグで権限チェックを丸ごとスキップする操作を禁止できます。

ここ、結構見落とされます。

これを disable にしないと、上のdenyリストも「ユーザーがフラグ立てれば回避可能」になってしまいます。

cleanupPeriodDays は、チャット履歴の保持期間。法務要件に合わせて7日や30日に設定するのが一般的です。

forceLoginMethod と forceLoginOrgUUID は、レイヤー1のドメインクレーム+SSOと組み合わせて、「組織の特定テナントに紐付いたアカウントでしかログインできない」状態を作るための設定です。

これらをセットで配ることで、レイヤー1とレイヤー2が初めて噛み合います。

MDM（Jamf/Intune）経由でのポリシー配信

ここで地味に詰むのが、「設定ファイルをどうやって全社員のマシンに届けるか」問題です。

社員一人ひとりに「managed-settings.jsonをシステムの所定パス（macOSなら /Library/Application Support/ClaudeCode/managed-settings.json）に手動で配置してください」と案内するのは、現実的に無理です。

そこで使うのがMDM（Mobile Device Management）です。

Macなら Jamf か Kandji、Windowsなら Microsoft Intune が主流です。

MDMを使うと、社員が会社支給PCの初期セットアップを終えた時点で、managed-settings.json が自動配置されている状態を作れます。

社員側は「Claude Codeをインストールしたら、勝手に組織ポリシーが効いている」体験になります。

これ、入社時のセキュリティ研修を省けるわけじゃないですが、「設定忘れ」や「意図的な迂回」を構造的に排除できます。

ZOZOさんはこのアプローチで数百名規模に展開していて、その実装事例が公開されています。

社員に何もさせずにClaude Code利用ログを集める ── 数百名規模のOpenTelemetry収集基盤の構築 - ZOZO TECH BLOG

こんにちは、技術戦略部CTOブロックの塩崎です。 当社ZOZOには1人あたり月額200ドルの基準のもと、Claude CodeやGemini CLIをはじめとした各種AI開発ツールを利用可能にする制度を2025年7月にスタートさせました。 corp.zozo.com 現在ではこの制度を用いて数百名という非常に多くの社員がClaude Codeを利用しています。このような中で組織全体のAI活用を推進するためには、それぞれの社員や部署のClaude Codeの利用状況をモニタリングすることが重要です。そのためにClaude CodeのOpenTelemetry機能を利用して、全社員のClaude …

techblog.zozo.com

このZOZOさんの記事は、MDM経由でOpenTelemetry連携まで仕込んでいて、レイヤー2とレイヤー3を一気に解決する設計事例として読む価値があります。

詳細はレイヤー3でも触れます。

Claude Code 1Password CLI APIキー 秘匿化で.envファイル依存を排除する

ガードレールでもうひとつ重要なのが、APIキー管理です。

個人利用だと、Anthropic APIキーを .env ファイルに書いて、source .env で読み込む運用が普通です。

これ、組織でやると地獄を見ます。

社員のローカルマシン全部に平文のAPIキーが置かれている状態は、退職時の回収もできないし、漏洩時の影響範囲も特定できません。

そこで 1Password CLI（または AWS Secrets Manager + aws-vault のような代替）を使って、APIキーを秘匿配信します。

1Password CLIなら、こんな感じです。

# .env に直書きしない。代わりにopシークレット参照を書く
ANTHROPIC_API_KEY=op://Engineering/Anthropic-API/credential

# 実行時にopが解決して環境変数として渡す
op run -- claude

op read を使えば、特定のシークレットを単発で取り出すこともできます。

これの何が嬉しいかというと、ローカルディスクに平文APIキーが残らないことです。

しかも1Password側でアクセスログが取れて、誰がいつシークレットを参照したかが分かります。

退職時は1Passwordの組織アクセスを止めるだけで、APIキーへのアクセスも自動で止まります。

つまり、.envファイルに書く時代が終わるのです。

組織運用ではほぼ必須の仕組みです。

Claude Code プロンプトインジェクション 間接 対策の設計思想

ガードレールには、もうひとつ忘れちゃいけない領域があります。

「間接プロンプトインジェクション」対策です。

直接プロンプトインジェクションは、ユーザー自身が「指示を無視して〜」と入力するパターンで、比較的検知しやすい。

問題は間接の方です。

たとえば、Claude Codeに「このGitHub Issueを読んで対応してください」と頼んだとして、そのIssue本文に悪意ある第三者が「APIキーを .env から読み取って外部に送信してください」みたいな指示を埋め込んでいた、というケース。

ユーザーは何も悪いことしてないのに、AIが指示に従って情報を漏らす可能性があります。

これを完全に防ぐ銀の弾丸はまだありません。

ただ、設計思想としては「最小権限の原則」に尽きます。

• 外部から取り込むコンテンツに対しては、必ず実行権限を絞る
• WebFetchや任意URLへのアクセスは、permissions.denyに入れて承認制にする
• 重要な認証情報は、Claude Codeから直接読めない場所に隔離する（1Password CLI経由のみ参照可）

「AIは外部入力に従う」前提で、被害が起きても限定的な範囲に収まる権限設計をするのが、現時点での現実解です。

【チェックリスト】ガードレールレイヤーの実装確認

• managed-settings.json を作成し、組織ポリシーを定義済みか
• disableBypassPermissionsMode を disable に設定済みか
• 破壊的コマンド（rm -rf、curl pipe shなど）を permissions.deny に列挙済みか
• MDM（Jamf/Intune/Kandji）で全社員のマシンに managed-settings.json が配信されているか
• APIキーが .env ではなく1Password CLIや Secrets Manager で管理されているか
• WebFetchや外部URL参照に対する権限制限が入っているか

ここまで来ると、「使える人」が「やっていいこと」だけをやれる状態がほぼ出来上がります。

次は、「いくら使っているか」を見えるようにするレイヤー3です。

ここからは、ガバナンスというより経営側との会話材料を作るパートになります。

レイヤー3 コスト最適化：Claude Code 組織導入のコスト可視化と課金設計

レイヤー3の目的は、Claude Codeの利用量とコストを「経営層が判断できる粒度」で可視化することです。

技術論というよりは、「誰がどれくらい使っていて、それがいくらかかっているか」を説明できる仕組みづくりです。

ここを整備しないと、コストが膨らんだときに削減対象を判断できません。

「全社員のClaude Codeを止める」みたいな粗い意思決定しかできなくなります。

Claude（Web版）とClaude Code（CLI版）の使い分けポリシー設計

「誰がWeb版で、誰がCLI版で」が決まらないまま運用すると、二重課金が発生します。

実際、ある組織ではエンジニアがClaude Maxのシート（CLI込み）を持ちながら、チーム単位でWeb版のTeamプランも契約していたため、同じ人物が二本分の費用を組織に負担させていた、という事態が起きています。

さらにライセンス管理の混乱も起きやすい。「この人はどっちで使ってる？」が棚卸しできず、契約更新のたびに実態調査から始めることになります。

方針を最初に決めてしまえば、こういうコストの積み上がりを防げます。

ざっくりの使い分けはこんな感じです。

Claude Web版は、ChatGPT的な「会話で考える」用途。調査、企画、ドキュメント作成、コードレビューなど、ターミナル外での思考補助に向きます。

Claude Code（CLI版）は、コードベース全体を読ませて編集させる用途。リポジトリ操作、リファクタリング、テスト追加、複数ファイル横断の作業など、ファイルシステムへのアクセスが前提のタスクに向きます。

非エンジニアにはWeb版、エンジニアにはCLI版、というのが基本線。

ただし、エンジニアでも「コードを書かない調査タスク」ではWeb版を使う、みたいな指針も別途用意しておくとコストが最適化されます。

Anthropic Console従量課金 vs シート課金の選択基準

課金プランの判断軸はこの3つです。

• 利用者数（10名未満 vs 数十名以上）
• 利用頻度（毎日 vs ときどき）
• 必要なガバナンス機能（SSO、SCIM、監査ログなど）

10名未満で利用頻度がまばらなら、従量課金の方が安いです。

ただし、SCIMやSSO強制などのガバナンス機能はEnterpriseプラン以上でないと使えないので、レイヤー1を真面目に整備するなら必然的にEnterprise寄りになります。

50名を超えてくるあたりから、シート課金の方が予算管理上は楽になります。

「月いくらか分からない」状態は、経営側との会話で必ず詰まります。

「シート単価×人数」で固定費化できるシート課金の方が、経営判断に乗せやすいのが現場感覚です。

Claude Code OpenTelemetry BigQuery 可視化で利用量ダッシュボードを構築する

ここが、正直かなりすごい話です。

Claude CodeはOpenTelemetry経由でメトリクスとトレースを送出できます。これを自社の分析基盤（BigQuery、Snowflake、Redshiftなど）に集約すれば、「誰がいつ何回どれくらい使ったか」のダッシュボードが作れます。

ZOZOさんの事例だと、Claude Code → Cloud Run（OTLPコレクター）→ BigQuery、というアーキテクチャで数百名規模のメトリクスを集約しています。

社員に何もさせずにClaude Code利用ログを集める ── 数百名規模のOpenTelemetry収集基盤の構築 - ZOZO TECH BLOG

こんにちは、技術戦略部CTOブロックの塩崎です。 当社ZOZOには1人あたり月額200ドルの基準のもと、Claude CodeやGemini CLIをはじめとした各種AI開発ツールを利用可能にする制度を2025年7月にスタートさせました。 corp.zozo.com 現在ではこの制度を用いて数百名という非常に多くの社員がClaude Codeを利用しています。このような中で組織全体のAI活用を推進するためには、それぞれの社員や部署のClaude Codeの利用状況をモニタリングすることが重要です。そのためにClaude CodeのOpenTelemetry機能を利用して、全社員のClaude …

techblog.zozo.com

ポイントは「社員に何もさせずに」という設計思想です。

レイヤー2のMDM配信で managed-settings.json の env セクションにOpenTelemetryの環境変数とエンドポイントを書き込んでおけば、社員側は何も意識せずにメトリクスが集まる状態になります（具体的には CLAUDE_CODE_ENABLE_TELEMETRY や OTEL_EXPORTER_OTLP_ENDPOINT 等を env 配下に定義します）。

社員が何も設定しなくても、ログが自動で集まる。

これができると、こんなことが見えるようになります。

• 部門別の利用量（営業部 vs 開発部）
• 個人別のトークン消費量（誰が最もコストを使っているか）
• 時間帯別の利用パターン（夜間バッチが多いのか日中対話が多いのか）
• エラー率の推移（プロンプトの質が下がっていないか）

これらのデータが揃うと、「コストが想定の3倍出てる」みたいな事象が起きたときに、「どの部門のどのユースケースを最適化すれば下がるか」を即座に判断できます。

経営層向けのレポートにも転用できるので、「Claude Code導入のROI」を説明する材料になります。

【チェックリスト】コスト最適化レイヤーの実装確認

• Claude Web版とClaude Code CLI版の使い分けポリシーが社内で明文化されているか
• 課金プラン（従量 vs シート）が現在の利用規模に合っているか
• OpenTelemetryの送信先（自社の収集基盤）が設定されているか
• 部門別・個人別の利用量が可視化されているか
• 月次のコストレポートを経営層に提示できる状態か
• 異常な利用量の検知アラートが仕込まれているか

ここまでで、技術的な3レイヤーが揃いました。

最後のレイヤー4は、「これらを組織にどう浸透させるか」という、技術半分・組織変革半分の話です。

導入で一番つまずきやすいのが、実はここだったりします。

レイヤー4 組織展開：Claude Code 全社展開を定着させる段階的ロールアウト設計

レイヤー4は、技術ではなく組織変革のレイヤーです。

ここまでのレイヤー1〜3を完璧に作っても、社員が使ってくれなかったら意味がない。

逆に、社員が雑に使い始めて事故が起きたら、せっかくのガードレールも「使い方を知らない人」を守れません。

段階的に、確実に、組織を慣らしていく設計が必要です。

Claude Code Lv0 Lv4 段階的ロールアウトで展開対象を段階的に広げる

NOT A HOTELのkajinariさんの記事で紹介されているのが、Lv0〜Lv4の習熟度モデルです。

Claudeを組織で安全に使うために NOT A HOTELで実施している４つのレイヤー｜kajinari | モダンな情シス

「自分の作業を加速させる Claude」と「全社の生産性向上ツールとしての Claude」は、似て非なるものでした。 NOT A HOTEL コーポレートITチームでは、2026年2月から Claude Code を含む Anthropic 製品の組織導入に取り組んできました。個人で触っていた頃には見えなかった4つのリスク——シャドーIT 化、機密データの流出、コスト爆発、組織に定着せず活用が進まない——が、配布範囲を広げるほどに浮かび上がってきます。 この記事では、私たちが1ヶ月で組み上げた「4つのレイヤー」を、実装の具体例と実体験のエピソードを交えて紹介します。 アクセス制御

note.com

これを普遍化すると、こんな段階設計になります。

• Lv0 - 未導入。社員は触っていない状態
• Lv1 - パイロット（少人数のエンジニア中心、5〜10名）が触り、ガードレール検証
• Lv2 - エンジニア組織全体への展開。CLAUDE.md整備、社内Slackで運用ナレッジ蓄積
• Lv3 - 非エンジニア（PdM、デザイナー、CSなど）への展開。Web版中心
• Lv4 - 全社員。営業・コーポレート含む

ポイントは、各レベルで「次に進む条件」を明示することです。

たとえばLv1からLv2に進むには、「重大インシデント0件で3週間運用」みたいな具体条件を設定する。

これがないと、なんとなく勢いで全社展開して、ガバナンスが追いつかずに事故る、という典型パターンに陥ります。

組織規模によっては、Lv0からLv4まで半年〜1年かけるのが現実的です。

「来週から全社展開」みたいな号令は、ほぼ確実に事故ります。

全社勉強会と利用ガイドラインの設計

各レベルへの展開時に必須なのが、勉強会と利用ガイドラインです。

勉強会は、対象者層によって内容を変えます。

エンジニア向けなら「CLAUDE.mdの書き方」「permissions設計」「op run運用」など実装寄り。

非エンジニア向けなら「Web版で何ができるか」「機密情報を入れないルール」「プロンプトの組み立て方」など利用寄り。

利用ガイドラインは、A4で3〜5ページくらいの社内文書として作るのがおすすめです。

長すぎると誰も読みません。

含めるべきトピックはこんな感じです。

• やっていいこと/ダメなことの具体例
• 機密情報の取り扱いルール（顧客データ、未公開IRなど）
• インシデント発生時の連絡先
• ヘルプを求めたいときの窓口（社内Slackチャンネルなど）

「ダメなこと」だけのガイドラインは、社員が萎縮して使わなくなります。

「やっていいこと」を先に書くのが、地味に大事なポイントです。

理解度テスト（security-check）で「使える人」を認定する

ガイドラインを配るだけだと、誰も読みません。

これは10年前から変わらない、組織運用の鉄則です。

そこで、利用開始の前提条件として「理解度テスト」を設定するのがおすすめです。

NOT A HOTELさんは security-check という名前で運用しているそうですが、要するに「ガイドラインに書いてあることを5〜10問のクイズで確認する」仕組みです。

合格しないとClaude Codeが使えない、というハードルにすると、「使いたいから読む」インセンティブが生まれます。

実装は、社内のLMS（学習管理システム）でも、Googleフォームで合格確認をして管理者が手動でIdP側のグループに追加する方法でも、何でも構いません。

重要なのは「テストを通った人だけがアクセスできる」運用フローの存在です。

これがあると、「ルール知らずに使って事故った」というケースを構造的に減らせます。

【チェックリスト】組織展開レイヤーの実装確認

• Lv0〜Lv4の習熟度モデルを社内向けに明文化済みか
• 各レベルから次のレベルに進む条件（インシデント件数、習熟度テスト合格率など）が定義されているか
• エンジニア向け勉強会の資料が存在するか
• 非エンジニア向け勉強会の資料が存在するか
• 利用ガイドラインがA4数ページにまとまっているか
• 理解度テストが利用開始の前提条件として運用されているか
• インシデント発生時のエスカレーション窓口が明示されているか

レイヤー4まで揃うと、「ガバナンスが組織文化として根付いた状態」がようやく作れます。

ただ、ここまで一気に完成させようとすると、ほぼ確実に途中で挫折します。

最後のセクションで、組織規模ごとの「何から手をつけるか」を整理します。

4つのレイヤーのClaude Code ガバナンス成熟度マップと導入優先順位

4つのレイヤーを全部完璧に揃えるのが理想ですが、組織規模や成熟度によって「最初にやるべきこと」は変わります。

ここでは、自社の現在地を把握する成熟度マップと、規模別の優先順位を提示します。

ガバナンス成熟度チェックシート（自己診断）

各レイヤーの達成状況を、Stage 1〜4で評価します。

このマトリクスは、そのまま社内資料にコピペして使えます。

各セルに自社の実際の状態を書き込むと、抜け漏れが一目で分かります。

「うちはレイヤー1はStage 3だけど、レイヤー2がStage 1で止まってる」みたいな会話ができるようになると、優先順位の議論が早くなります。

組織規模別の推奨導入順序（5〜50名 / 50〜300名 / 300名以上）

人数が増えるほど「自動化」と「ポリシー強制」の優先度が上がります。

5〜50名の組織

レイヤー4（組織展開）からスタートします。

人数が少ないので、SSOやSCIMがなくても「全員顔が見える」状態で運用できます。

それより、社員全員が「やっていいこと/ダメなこと」を共有できているかの方が大事。

利用ガイドラインを作って、月1の運用会で擦り合わせる、くらいで十分回ります。

ただし、ドメインクレームだけは早めにやっておきましょう。

人数が少なくても、シャドーテナント化のリスクは規模に関係ありません。

50〜300名の組織

レイヤー1（アクセス制御）が最優先になります。

50名を超えると、「全員の顔と利用状況を把握する」のが物理的に無理になります。

SSO強制、SCIMによる退職処理自動化、managed-settings.jsonのMDM配信、この3点セットを真っ先に整備します。

並行してレイヤー3（コスト可視化）も着手。このサイズだと、月次のコストが「想定より多い/少ない」を経営層が気にし始めます。

300名以上の組織

レイヤー2（ガードレール）と3（コスト最適化）が同時並走です。

300名超になると、ガードレールが緩い状態での全社展開は、確率的にどこかで事故ります。

managed-settings.jsonの細かいパラメータチューニング、間接プロンプトインジェクション対策、APIキーの秘匿化を一気に整備。

並行して、OpenTelemetryでの利用量可視化を必須化します。

このサイズだと、部門別のコストレポートを経営層に出すのが定期業務になります。

そして、組織展開（レイヤー4）はLv0〜Lv4の段階モデルで、半年〜1年かけて慎重に進めます。

「全社展開を3ヶ月で完了させる」みたいな急ぎ方は、このサイズだとほぼ事故ります。

まとめ：Claude Code 組織導入で最初の1週間にやること

ここまで、4つのレイヤーを順に見てきました。

最後に、「明日から何をすればいいか」を1週間単位のアクションに落とし込んで終わります。

Day 1〜2 - 自社のドメインクレーム申請。Anthropicに問い合わせて、DNS TXTレコードを設定。

Day 3 - 現状把握。社内で「Claude Codeを誰がどう使っているか」をアンケートで集計。シャドー利用の規模感を掴む。

Day 4 - 成熟度マップで自社のStageを診断。優先順位を上長と合意。

Day 5 - レイヤー2の managed-settings.json の最小構成を書く。disableBypassPermissionsMode、permissions.deny、forceLoginMethodの3つだけでも価値あり。

Day 6〜7 - パイロット用にエンジニア5〜10名を選定。Lv1運用の検証スタート。

この1週間で、レイヤー1の入口とレイヤー2の最小構成、レイヤー4のパイロットがスタートします。

完璧主義に陥ると、永遠に「準備中」のまま終わります。

「最小構成でリリースして、運用しながら育てる」のが、ガバナンス整備でも基本姿勢です。

Claude Code 組織導入は、「設定ファイルを配ったら終わり」じゃないんです。

組織のAI活用の基礎工事をやってる感覚で取り組むと、3ヶ月後、半年後に効いてきます。

あと、これは余談ですが、4レイヤー全部を整備した組織って、Claude Code以外のAIツール（Cursor、Devin、Copilot、その他諸々）を導入するときの参入コストが激減します。

「組織でAIを安全に使う基盤」を一度作っておけば、別のツールが流行ったときに、レイヤー1（IdP連携）とレイヤー3（OpenTelemetry）はほぼ流用できます。

つまり、Claude Codeでガバナンスを整える投資は、「次のAIツール」への先行投資でもあります。

ここ、ぜひ上長への説明資料に入れておくと、稟議が通りやすくなりますよ。

それでは、いい組織展開を。