Claude Code を会社に導入するには？ 立ちはだかる4つの壁と越え方

AI入門
2026.09.28

はじめに

個人で Claude Code を使って「これは仕事でも使いたい」と感じた方は多いと思います。ところが、会社で使おうとすると急に話が進まなくなります。ライセンスを買う予算の前に、情報セキュリティ部門、情シス、経理、現場のリーダーから、それぞれ違う質問が飛んでくるからです。

この記事では、その質問を 4つの壁 に整理し、壁ごとに「何を決めて、何を設定すればよいか」を順番に説明します。設定例は実際に動かして確かめ、料金や仕様は Anthropic の公式ページで確認しました。

想定している読者は次のような方です。

  • 自社に Claude Code を入れたいが、どこから手を付ければよいか分からない方
  • セキュリティ審査や稟議で何を聞かれるのかを先に知りたい方
  • すでに数人で使っていて、全社に広げる前に設計を見直したい方

まず、4つの壁の全体像を見てください。壁ごとに「聞く人」が違う点に注目すると、誰と話を進めればよいかが分かります。

個人利用では見えなかった4つの壁（セキュリティ、コスト、既存環境、定着）と、それぞれの越え方を順番に示す図

図1：4つの壁と、この記事で扱うアプローチ。壁は上から順に片付けるのではなく、①の審査を進めながら②〜④を並行で準備します

この記事の確認範囲

項目内容
確認日2026年9月28日
公式情報Claude Code ドキュメント、料金ページ、ヘルプセンター、Trust Center、カスタマーストーリー
実機Claude Code 2.1.280、macOS。検証用フォルダとダミーの機密ファイルで確認
実機で確認していないこと管理者設定の端末配布（管理者権限が必要）、管理画面からの配信、Amazon Bedrock 経由、Guardrails、監査ログの出力

料金と仕様は変わります。契約前に、末尾の参考リソースから最新のページを確認してください。

先に知っておきたい：導入した会社では何が起きたか

壁の話に入る前に、越えた先にあるものを確認しておきます。Anthropic の公式カスタマーストーリーに載っている数字を並べました。

会社内容（公式カスタマーストーリーの記載）
Stripe1,370人のエンジニアに展開。Scala から Java への1万行の移行を4日で完了（手作業の見積もりは10人週）
Wiz5万行の Python ライブラリを Go へ約20時間で移行（手作業の見積もりは2〜3カ月）
Satispay決済サービスの Java 8→21 移行を、4週間の見積もりに対し4日未満で完了。全社展開は30日
Rampインシデント調査の時間を最大80%削減
Epic SystemsClaude Code の利用の半分以上が、開発者以外の職種
楽天新機能を市場に出すまでの期間を79%短縮（24営業日→5日）
マネーフォワードエンジニアの80%が日常的に利用。API の実装が2日から5時間に

ここで気づいてほしい点が2つあります。

1つ目は、数字はその会社の環境で出たものだということです。Stripe 自身も、特定の AI ツール単体の効果は切り分けていないと述べています。稟議にそのまま貼るのではなく、「自社でも測る価値がある」という根拠として使うのが安全です。

2つ目は、準備に時間をかけていることです。Stripe は社内向けの配布パッケージの検証に2〜3カ月かけ、全員の端末に設定済みの状態で入れています。成果の裏には、この記事で扱う「壁」を先に片付けた作業があります。

壁1 セキュリティ：「お願い」ではなく「仕組み」で守る

最初の壁はセキュリティです。ここを通らないと、ほかの話は始まりません。審査で聞かれることは、おおむね次の3つに集約されます。

  • 設定を全員に強制できるか
  • 誰が何をしたか追えるか
  • コードはどこへ送られ、どれだけ残るか

「社内ルールを守って使ってください」という通知だけでは、審査は通りません。仕組みで強制できることを示す必要があります。

1-1. 設定の置き場所を知る

Claude Code の設定は5段重ねになっています。同じ項目が複数の場所にあるときは、上の段が勝ちます。

設定の5つの段を優先度順に並べ、最上位の管理者設定に置くものと現場に任せるものを示す図

図2：会社のルールは一番上の「管理者設定」に置きます。現場は自分の設定に許可を追加できますが、管理者設定の禁止は外せません

一番上の管理者設定（managed settings）が、企業導入の土台です。ここに書いた内容は、開発者が自分の設定ファイルや起動時の指定で上書きできません。

管理者設定には、おもに次のものを置きます。

置くもの設定キー役割
絶対に禁止する操作permissions.deny危険なコマンド、機密ファイルの読み取りを止める
確認なしモードの禁止permissions.disableBypassPermissionsModeすべての確認を飛ばす起動方法を使えなくする
監査・検査用のフックhooks実行の前後に自社のスクリプトを挟む
接続してよい外部サービスallowedMcpServers など未承認の接続先を止める
隔離の設定sandboxOS の機能で、読めるファイルと通信先を制限する
共通の環境変数envプロキシ、利用状況の送信先など

さらに、「管理者設定に書いたものだけを有効にする」ための鍵が用意されています。こちらは管理者設定に書いたときだけ効きます。

設定キーtrue にしたときの動き
allowManagedPermissionRulesOnly許可・禁止のルールは管理者設定のものだけ。個人の許可ルールは無視される
allowManagedHooksOnly管理者設定のフックだけが動く。個人やプロジェクトのフックは止まる
allowManagedMcpServersOnly接続の許可リストは管理者設定のものだけを採用する
forceRemoteSettingsRefresh最新の設定を取得できるまで起動しない。取得に失敗したら終了する

気づき：鍵をかけすぎると現場が止まります

allowManagedPermissionRulesOnly を有効にすると、開発者が自分で足した「npm test は確認なしで実行してよい」といった許可も無効になります。日常の作業に必要な許可を管理者設定側に用意しないと、確認の回数が増えて使われなくなります。最初は禁止ルールだけを配り、鍵は必要になってから足すほうが安全です。

1-2. 配り方は2つの質問で決まる

管理者設定を端末に届ける方法は、大きく2つあります。

  • サーバー管理：claude.ai の管理画面に JSON を入力し、Claude Code が起動時に取得する
  • エンドポイント管理：端末の決まった場所にファイルなどを置く

どちらを使うかは、次の図の2つの質問で決まります。

Anthropic に直接つなぐか、端末を管理しているかの2つの質問で、管理者設定の配り方が決まる流れ図

図3：Amazon Bedrock などを経由する場合、管理画面からの配信は使えません。接続経路を先に決める必要があるのはこのためです

サーバー管理は Team プランと Enterprise プランで使えます。設定できるのは Primary Owner と Owner だけです。起動時に取得し、その後は1時間ごとに更新を確認します。

エンドポイント管理でファイルを置く場所は、OS ごとに決まっています。

OS置き場所
macOS/Library/Application Support/ClaudeCode/managed-settings.json
Linux / WSL/etc/claude-code/managed-settings.json
WindowsC:\Program Files\ClaudeCode\managed-settings.json

ファイルのほかに、macOS の構成プロファイル（com.anthropic.claudecode）や Windows のレジストリ（HKLM\SOFTWARE\Policies\ClaudeCode）でも配れます。Jamf や Intune などの MDM（端末をまとめて管理する仕組み）向けのひな形は、公式リポジトリの examples/mdm にあります。

同じ場所に managed-settings.d/ というフォルダーを作ると、設定を複数のファイルに分けて置けます。10-telemetry.json、20-security.json のように番号を付けると、担当部門ごとにファイルを分けて管理できます。

気づき：サーバー管理は「便利な配り方」であって「壁」ではありません

公式ドキュメントは、サーバー管理の設定を「クライアント側の制御であり、セキュリティ上の境界ではない」と説明しています。端末の管理者権限を持つ人は、Claude Code 本体やネットワーク設定に手を入れられるからです。強い保証が必要なら、MDM で管理された端末にエンドポイント管理で配ります。

もう1つ、管理者設定のファイルが JSON として壊れていると、Claude Code は起動を拒否します。配る前に jq . managed-settings.json のようなコマンドで形式を確かめてください。

反映されたかどうかは、開発者の端末で /status を実行すると確認できます。Setting sources の行に、管理者設定の取得元が表示されます。

1-3. 禁止ルールを書いて、実際に試す

ここからは、実際に設定を書いて動きを確かめます。検証用のフォルダーに、ダミーの .env（中身は偽のパスワード）を置きました。

まず禁止ルールです。管理者設定に書く内容と同じものを、検証ではプロジェクトの設定ファイルに書いています。

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

この状態で、Claude Code に「.env を読んで」「curl を実行して」と頼みました。実行時にはどちらのツールも許可しています。

claude -p ".env を Read ツールで読んで中身を教えて。次に curl https://example.com を Bash で実行して" \
  --allowedTools "Read" "Bash(curl *)" \
  --output-format json | jq '.permission_denials'

結果は次のとおりです。許可を与えていても、禁止ルールが勝ちました。

設定ファイルの禁止ルールと、Read と curl の2件が拒否された記録を表示した端末画面

画面1：上が設定した禁止ルール、下が拒否の記録（permission_denials）。保存した実行結果を表示しています

ここまでは期待どおりです。では、禁止ルールをすり抜ける方法はないのでしょうか。3通りの読み方を試しました。

試した読み方結果
Read ツールで .env を開く止まった
Bash で cat .env止まった（Read の禁止ルールが適用された）
Bash で node -e を使い、プログラムからファイルを開く読めた
禁止ルールだけのときはダミーのパスワードが表示され、サンドボックスを有効にすると EPERM エラーで止まったことを示す端末画面

画面2：上は禁止ルールだけの場合（ダミーの値が読めた）、下はサンドボックスを有効にした場合（OS が拒否）

これは不具合ではなく、公式ドキュメントに書かれている仕様です。Read の禁止ルールが効くのは、Claude Code のファイル用ツールと、cat や head など Bash の中で認識されるファイル操作コマンドです。任意のプログラムがファイルを開く動作までは止めません。Bash(curl *) も同じで、/usr/bin/curl のように書き方を変えたコマンドは対象外です。

1-4. 守りを4層で考える

禁止ルールだけでは足りないと分かったので、守りを層に分けて考えます。

権限ルール、フック、サンドボックス、Guardrails の4つの層と、ダミーの機密ファイルで試した結果を並べた図

図4：4つの層の役割と、実測の結果。文字列の照合に頼る層は、書き方を変えられると見逃します

② フック：実行の前後に自社の処理を挟む

フック（hooks）は、Claude Code が動く決まったタイミングで、自社のスクリプトを自動で実行する仕組みです。企業でよく使うタイミングは次の3つです。

タイミング使いどころ
PreToolUse（実行前）危険な操作を検査して止める
PostToolUse（実行後）実行したコマンドを記録する
UserPromptSubmit（入力時）入力に機密情報の形式が含まれていないか調べる

実行したコマンドを1行ずつ記録するフックを作りました。設定は次のとおりです。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "/usr/local/bin/cc-audit-log.sh" }
        ]
      }
    ]
  }
}

スクリプト本体です。フックには、実行内容が JSON で標準入力に渡されます。

#!/bin/bash
# /usr/local/bin/cc-audit-log.sh
# 実行されたコマンドを JSON Lines 形式で追記する
input=$(cat)
ts=$(date -u +%Y-%m-%dT%H:%M:%SZ)
echo "$input" | jq -c --arg ts "$ts" --arg user "$USER" \
  '{ts:$ts, user:$user, session:.session_id, tool:.tool_name, command:.tool_input.command}' \
  >> /var/log/claude-code/audit.jsonl
exit 0

検証では、記録先を検証用フォルダーの中に変えて動かしました。

監査ログ用のスクリプトと、実行したコマンドが時刻・利用者つきで3行記録された端末画面

画面3：Claude Code が実行した ls や wc が、時刻と利用者名つきで記録されました

実行前に止めるフックも試しました。コマンドの文字列に .env が含まれていたら止める、という単純な検査です。cat .env は止まりましたが、node -e "...readFileSync('.env'...)" は見逃しました。私が書いた照合の条件が、引用符で囲まれた '.env' に合っていなかったためです。

この失敗から分かったことを、フックの注意点としてまとめます。公式ドキュメントにも同じ趣旨の警告があります。

注意点内容
止めるときは終了コード2終了コード1では止まらず、処理が続く
パスの間違いに気づきにくいスクリプトが見つからない、実行権限がない場合、エラーは出るが操作は続行される
時間切れでも止まらない検査が時間内に終わらないと、通常の確認の流れに進む
失敗した操作は記録されない今回の検証でも、拒否された操作は PostToolUse の記録に残らなかった。拒否や失敗を追うには別のタイミング（PermissionDenied、PostToolUseFailure）や、後述の OpenTelemetry を使う
文字列の照合は言い換えに弱い検査の条件を自作すると、今回のように見逃しが出る

③ サンドボックス：OS の機能で閉じる

サンドボックスは、Bash から起動したプログラムごと、読めるファイルと通信先を OS の機能で制限する仕組みです。設定に次の1行を足しました。

{
  "sandbox": { "enabled": true }
}

同じ node -e のコマンドを実行すると、今度は OS が拒否しました（画面2の下段）。禁止ルールに書いた .env と secrets/ が、サンドボックスの読み取り禁止にも反映されていました。

通信先も同じ考え方で制限できます。管理者設定で sandbox.network.allowManagedDomainsOnly を有効にすると、管理者が許可した宛先以外への通信は、確認なしで止まります。「curl を禁止する」より「許可した宛先にしか出られない」のほうが、書き方の違いに左右されません。

④ Guardrails：文章の中身を見る

Guardrails は、モデルに出入りする文章を検査する仕組みです。Amazon Bedrock 経由で Claude Code を使う場合に、Amazon Bedrock Guardrails を組み合わせられます。個人情報やクレジットカード番号のような、文章の中身を検査するのが役割です。

設定は、AWS 側で Guardrail を作ってバージョンを発行し、識別子を Claude Code の設定に書きます。

{
  "env": {
    "ANTHROPIC_CUSTOM_HEADERS": "X-Amzn-Bedrock-GuardrailIdentifier: <YOUR_GUARDRAIL_ID>\nX-Amzn-Bedrock-GuardrailVersion: 1"
  }
}

この層は今回、実機で確認していません。公式ドキュメントの Amazon Bedrock のページに記載されている設定です。

気づき：検査は「記録だけ」から始める

機密情報の検出を入れると、正常な作業まで止めてしまうことがあります。手を止められた開発者は、その仕組みを避けるようになります。最初の1〜2週間は記録だけにして、誤検知の傾向をつかんでから「止める」に切り替えるのが現実的です。止める対象も、カード番号や API キーのように形式がはっきりしたものに絞ります。

1-5. 外部サービスへの接続（MCP）は許可リストで管理する

MCP（Model Context Protocol）は、Claude Code から外部のサービスやデータに接続するための仕組みです。便利な反面、接続先にコードやプロンプトの内容が渡ります。開発者が自由に追加できる状態は、企業ではリスクになります。

管理者設定で、接続してよい相手を許可リストにします。

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example-tracker.com/*" },
    { "serverUrl": "https://mcp.example-chat.com/*" }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://*.untrusted.example/*" }
  ]
}

許可リストの書き方は3種類あります。どれを使うかで、強制力が変わります。

書き方照合するもの強制力
serverUrl接続先の URLあり
serverCommand起動するコマンドと引数（完全一致）あり
serverName利用者が付けた名前なし

気づき：名前での許可は、守りになりません

serverName は利用者が自由に付けられるラベルです。許可された名前を付ければ、別のサーバーでも通ります。公式ドキュメントも、実際に動くサーバーを縛るには serverUrl か serverCommand を使うよう案内しています。

許可リストを増やすときの流れは、次の図のように決めておきます。

MCP サーバーを追加するときの申請、審査、承認、配布、棚卸しの5段階と、審査で見る3点を示す図

図5：審査で見るのは、提供元・データの扱い・権限の3点。提供元をたどれないものは入れません

申請と承認の記録を残す方法として、許可リストを Git リポジトリで管理し、追加の申請をプルリクエストで受ける運用があります。誰がいつ申請し、誰が承認したかが履歴に残るので、そのまま監査の資料になります。

1-6. データはどこへ行き、どれだけ残るか

審査で最も時間がかかるのが、この質問です。Claude Code は、入力したプロンプトだけでなく、作業中に読み込んだファイルの内容やコマンドの実行結果もモデルに送ります。

答えは、どの経路で契約するかで決まります。

Anthropic の直接契約、クラウド事業者経由、Claude Platform on AWS の3つの経路について、データ処理者と保持期間を比べた図

図6：審査で聞かれるのは「誰が処理者か」「何日残るか」「学習に使うか」。経路を選ぶと答えが決まります

項目Team / Enterprise（直接契約）クラウド事業者経由個人向けプラン（参考）
モデルの学習への利用なしなし本人の設定しだい
保持期間標準30日クラウド側の規約に従う学習利用オフで30日、オンで5年
データ処理者Anthropicクラウド事業者Anthropic

保持をゼロにする ZDR（Zero Data Retention）については、誤解しやすい点があります。

  • Enterprise プランに標準で含まれるものではありません。対象は条件を満たすアカウントで、担当チーム経由の申請と審査が必要です
  • 管理画面から自分で有効にすることはできません
  • 有効にすると、クラウド上のセッションや Remote Control など、一部の機能が使えなくなります
  • 一部の最新モデルは30日の保持が必須で、原則として ZDR では使えません

気づき：「ZDR が使えるから大丈夫」を前提にしない

金融や医療のように厳しいデータ管理が求められる場合は、契約の検討に入る前に、ZDR の対象になるかどうかを確認してください。対象外だった場合の代案（クラウド事業者経由）も、同時に検討しておくと手戻りが減ります。

1-7. 誰が何をしたかを追う

記録の取り方は、目的によって使う機能が違います。

知りたいこと使う機能使えるプラン・経路
管理画面で誰が何を変更したか監査ログ（過去180日分を CSV で出力）Enterprise
操作の記録をプログラムで取得したいCompliance APIEnterprise（料金ページの比較表では営業経由の契約）ほか
利用量・費用・受け入れたコード行数利用分析の画面（Team / Enterprise）、Analytics API（Enterprise）直接契約
端末で実行したコマンドフック、OpenTelemetryすべての経路
クラウド経由の API 呼び出しCloudTrail、Cloud Audit Logs など各クラウド事業者

Team プランには監査ログがありません。「誰が、いつ、どの管理操作をしたか」の記録が要件にあるなら、Enterprise かクラウド事業者経由を選ぶことになります。

OpenTelemetry は、利用状況を自社の監視基盤に送るための標準的な仕組みです。どの経路でも使えます。管理者設定の env に書けば、全員の端末に配れます。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel-collector.internal.example.com:4317"
  }
}

プロンプトの本文、応答の本文、コマンドの引数は、初期設定では送られません。記録したい場合は OTEL_LOG_USER_PROMPTS=1 や OTEL_LOG_TOOL_DETAILS=1 を追加します。社員の入力内容を記録することになるので、社内規程や労務の観点での確認を先に済ませてください。

1-8. 審査でよく聞かれる2つ：認証と稼働率

取引先の評価表にそのまま書けるよう、公式の Trust Center（trust.anthropic.com）で確認できる内容をまとめます。

項目状況
SOC 2 Type II取得済み
ISO 27001取得済み
ISO/IEC 42001（AI マネジメントシステム）取得済み
GDPRデータ処理契約（DPA）で対応
HIPAAEnterprise プランで事業提携契約（BAA）を結ぶことで対応。Claude Code を対象にするには ZDR などの追加条件あり

稼働率については、Anthropic との直接契約で公表されている SLA（稼働率の保証）を、今回の調査では確認できませんでした。稼働率の保証が審査の要件になっている場合は、契約時に個別に確認するか、SLA を公表しているクラウド事業者経由（Amazon Bedrock は月間99.9%）を検討します。

SLA の有無にかかわらず、止まったときの備えは決めておきます。

  1. Claude Code が使えないときの作業の進め方を決める
  2. 障害情報（status.claude.com）を監視し、社内のチャットに通知する
  3. 自動化の流れに組み込む場合は、時間切れと失敗時に先へ進む分岐を入れる

壁2 コスト：席料だけで稟議を出さない

2つ目の壁はコストです。ここでの失敗は、だいたい同じ形をしています。席料だけで稟議を通し、あとから審査の工数や研修の費用が出てきて、予算が合わなくなる形です。

2-1. 契約の入り口を選ぶ

契約の形は、上から順に4つの質問で絞れます。

データ処理を自社クラウド内に閉じたいか、監査ログが必要か、人数と SSO の要否、試すだけかの4つの質問で契約を選ぶ流れ図

図7：最初の質問が「データ処理をどこに閉じるか」なのは、経路によって使える管理機能が変わるためです

各プランの内容を表にまとめます。金額は米国向けの表示で、税別です。

項目Max（個人）TeamEnterpriseクラウド事業者経由
料金月100ドル／200ドルStandard 席：月20ドル（年契約）／25ドル（月契約）
Premium 席：月100ドル／125ドル		席あたり月20ドル（年契約）＋使った分を API 単価で使った分だけ
人数1人2〜150人20人〜（営業経由は50人〜）制限なし
Claude Code使える全席で使える使える使える
SSOなしありありクラウド側の権限管理
SCIMなしなしありクラウド側の権限管理
監査ログなしなしありクラウド側のログ
管理画面からの設定配信なしありありなし

SSO は会社のアカウントでログインする仕組み、SCIM は入社・異動・退職に合わせてアカウントを自動で増減する仕組みです。

Team プランの席は、Standard と Premium を混ぜられます。どちらの席でも Claude Code は使え、違いは使える量です。毎日長時間使う人だけ Premium にして、残りは Standard にする組み方ができます。

Enterprise プランは考え方が違います。席料は利用する権利の料金で、使った分は API の単価で別に課金されます。席ごとの利用上限がない代わりに、使った分だけ費用が増えます。

2-2. 総額（TCO）で見積もる

見積もりは、TCO（総保有コスト）で組み立てます。席料に、導入・教育・運用にかかる人件費を足した総額です。

席料、利用料、導入、教育、運用の5つの費用を、請求書に載るものと社内の人件費に分けて示す図

図8：請求書に載るのは上の2つ。下の3つは社内の工数として出ていきます

区分中身性質
① 席料単価 × 人数契約前に計算できる
② 利用料使った分人によって大きく違う。試行で測る
③ 導入セキュリティ審査、環境構築、稟議初年度だけ
④ 教育研修資料、勉強会、問い合わせ対応初年度に集中
⑤ 運用設定の更新、利用状況の確認毎年かかる

席料の計算例です。20人のチームで、よく使う4人を Premium 席、残りを Standard 席にした場合を考えます（Team プラン、年契約）。

席の種類人数単価（月）小計（月）
Standard16人20ドル320ドル
Premium4人100ドル400ドル
合計20人—720ドル（年8,640ドル）

②の利用料については、公式ドキュメントに目安があります。企業での導入全体の平均で、開発者1人あたり1稼働日に約13ドル、月に150〜250ドルです。9割の利用者は1日30ドル未満に収まっています。

これは平均なので、自社の値は小さな試行で測ります。公式ドキュメントも、まず少人数で基準の値を取ってから広げるよう勧めています。

2-3. 効果を自社の数字で示す

稟議では、費用に見合う効果を示す必要があります。冒頭の事例の数字は参考になりますが、他社の環境で出たものです。自社の数字に置き換える手順を決めておきます。

  1. 対象の作業を2〜3個に絞る（例：API の追加、テストの作成、コードレビュー）
  2. 導入前の所要時間を記録する
  3. 試行の期間中、同じ作業の所要時間を記録する
  4. 差に人数と単価を掛けて、月あたりの効果を出す
  5. 図8の総額と並べる

Team プランと Enterprise プランには、利用分析の画面があります。受け入れたコードの行数、提案の受け入れ率、日ごとの利用者数などを確認できます。公式の説明によると、この指標は意図的に控えめに作られています。

2-4. 予算の上振れを仕組みで防ぐ

使った分だけ課金される契約では、上限を決めておかないと予算を超えます。契約の形ごとに、使う仕組みが違います。

契約上限のかけ方
Team追加の利用枠（usage credits）を前払いで購入。組織全体と個人ごとに月の上限を設定
Enterprise組織・グループ・個人ごとに支出の上限を設定
クラウド事業者経由各クラウドの予算機能。利用者ごとの内訳は OpenTelemetry で取る

クラウド事業者経由の場合は、もう1つ注意があります。使うモデルを固定しておかないと、初期設定のモデルが変わったときに単価も変わります。公式ドキュメントは、複数人に展開するときはモデルのバージョンを固定するよう強く勧めています。

開発者側では、/usage コマンドでそのセッションの使用量と費用の目安を確認できます。

壁3 既存環境：社内ネットワークと認証基盤につなぐ

3つ目の壁は、すでにある社内の仕組みとの接続です。個人の環境では何も設定しなくても動いていたものが、社内ネットワークでは動かない、という形で現れます。

3-1. 通信先を許可リストに登録する

Claude Code は、処理のほとんどをクラウド上のモデルに任せています。外への通信が許可されていないと動きません。

社内の端末からの通信がプロキシとファイアウォールを通り、必須の宛先と機能ごとの宛先に分かれて届く流れを示す図

図9：在宅の端末も、VPN でいったん社内に入ってから同じ出口を通ります

登録する宛先を、必須のものと、使う機能に応じて足すものに分けました。通信はすべて HTTPS（443番ポート）です。

宛先用途必要な場面
api.anthropic.comモデルとの通信、Web 取得時の安全性確認常に（クラウド事業者経由でも、Web 取得の確認で使う）
claude.ai、claude.comclaude.ai アカウントでのログイン直接契約
platform.claude.comConsole アカウントの認証、ログイン情報の更新直接契約
downloads.claude.aiインストール、自動更新常に
bedrock-runtime.<リージョン>.amazonaws.comAmazon Bedrock との通信Bedrock 経由
github.com、registry.npmjs.orgプラグインの取得、npm でのインストールプラグインなどを使う場合
mcp-proxy.anthropic.comclaude.ai の MCP コネクタコネクタを使う場合
raw.githubusercontent.com更新履歴の表示任意

全体の一覧は、公式ドキュメントの「Network access requirements」にあります。

気づき：古い資料の宛先一覧をそのまま使わない

利用統計やエラー報告の送信先は、以前の資料と現在の公式の表で変わっています。許可リストは、作業の時点で公式の表を見て作ってください。必須でない通信は、環境変数 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 でまとめて止められます。ただし、この種の「止める」変数は、値に 0 や false を入れても「止める」として働きます。元に戻すときは変数そのものを消します。

3-2. プロキシと証明書の設定を配る

社内のプロキシを通す設定は、環境変数で行います。開発者に1人ずつ入れてもらうより、管理者設定の env でまとめて配るほうが、設定の間違いが減ります。

{
  "env": {
    "HTTPS_PROXY": "http://proxy.internal.example.com:8080",
    "HTTP_PROXY": "http://proxy.internal.example.com:8080",
    "NO_PROXY": "localhost,127.0.0.1,.internal.example.com",
    "NODE_EXTRA_CA_CERTS": "/etc/ssl/certs/internal-ca.pem"
  }
}

それぞれの意味は次のとおりです。

変数意味
HTTPS_PROXY / HTTP_PROXY経由するプロキシのアドレス
NO_PROXYプロキシを通さず直接つなぐ宛先。社内のサービスをここに書く
NODE_EXTRA_CA_CERTS社内の認証局の証明書。通信の中身を検査するプロキシがある場合に必要

つまずきやすい点を3つ挙げます。

  • SOCKS プロキシには対応していません
  • プロキシがユーザー名とパスワードを求める場合、URL に埋め込む方法はありますが、パスワードが端末に残ります。接続元の IP アドレスやクライアント証明書での認証に切り替えられないか、先に相談してください
  • 社内の証明書が OS の証明書ストアに入っていれば、追加の設定なしで動く場合があります（初期設定で、同梱の証明書と OS のストアの両方を信頼します）

サーバー管理でプロキシの設定を配ると、開発者の画面に承認の確認が出ます。通信の経路を変える設定だからです。事前に「この確認が出たら承認してください」と案内しておくと、問い合わせが減ります。

3-3. VPN 越しで遅いとき

Claude Code は、1つの作業の中でモデルと何度もやり取りします。VPN で経路が長くなると、1回ごとの遅れが積み重なります。

対策内容
経路を分けるモデルへの通信だけ VPN を通さず直接出す（スプリットトンネリング）。速くなる代わりに、出口での記録と許可を別に用意する
待ち時間を延ばすAPI_TIMEOUT_MS（初期値は10分）、BASH_DEFAULT_TIMEOUT_MS（初期値は2分）を調整する

記録の要件が厳しい組織は VPN 経由のまま、そうでなければ経路を分ける、という判断になります。

3-4. クラウド事業者経由にするときの引き換え

すでに AWS や Google Cloud を主に使っている会社では、クラウド事業者経由が自然な選択に見えます。権限管理、請求、ログを既存の仕組みに統合できるからです。

ただし、引き換えに使えなくなるものがあります。

使えなくなるもの代わりの手段
管理画面からの設定配信エンドポイント管理（MDM など）で配る
利用分析の画面OpenTelemetry で自社の基盤に送る
クラウド上のセッション、Remote Control など、claude.ai のアカウントが前提の機能なし

Amazon Bedrock で使う場合の設定は、環境変数で切り替えます。

# Amazon Bedrock 経由で Claude Code を使う（モデルのバージョンは固定する）
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1
export ANTHROPIC_DEFAULT_SONNET_MODEL='<固定したいモデルのID>'

図6の経路C「Claude Platform on AWS」は、AWS の認証と請求を使いながら、Anthropic が運用する API を利用する形です。データの処理場所については、Anthropic のドキュメントと AWS のページで記述が異なっていました（2026年9月28日時点）。AWS だけをデータ処理者にしたい場合は Amazon Bedrock を選ぶ、という点は両者で一致しています。

壁4 定着：配っただけでは使われない

最後の壁は定着です。ライセンスを配っても、それだけでは使われません。技術の問題ではないので後回しにされがちですが、投資が回収できるかどうかはここで決まります。

4-1. 3段階で広げる

いきなり全員に配らず、段階を踏みます。大事なのは、次へ進む条件を先に決めておくことです。

PoC、パイロット、全社展開の3段階でやることと、次の段階へ進む条件を示す図

図10：段階ごとに「やること」と「次へ進む条件」を決めます。条件を満たさないまま広げると、問題も一緒に広がります

公式の管理者向けガイドも、まず限られた人数で数週間試し、利用状況と感想を確認してから広げる進め方を勧めています。Satispay の公式事例では、全社展開を30日で終えたと紹介されています。

4-2. 公式の「配布キット」を使う

展開のための文例や手順は、公式ドキュメントに用意されています。一から作る必要はありません。

資料内容
Communications kit導入の告知文、使い方のヒント、よくある質問の文例
Champion kit社内の推進役（チャンピオン）向けの30日間の進め方
Set up Claude Code for your organization管理者が決めることの一覧

告知の前に確認しておくことも、公式に挙げられています。質問用のチャンネルを作る、インストールの手順を事前に試す、データの扱いを説明したページを用意する、最初に試す作業を具体的に決める、最初の48時間に質問へ答える担当を置く、といった項目です。

推進役の負担は、公式の目安で週に40分ほどです。役割は3つで、見つけた使い方を共有する、質問を受ける、次の推進役を増やすことです。セキュリティやデータに関する質問は、推進役がその場で答えず、管理者に回します。

4-3. 開発者が最初の1時間で困らないようにする

定着を左右するのは、最初に触ったときの体験です。次の3つを用意しておきます。

  1. インストールを1手順にする：設定済みの状態で配る。Stripe は全員の端末に事前に入れています
  2. CLAUDE.md を整える：プロジェクトの決まりごとを書いたファイルです。リポジトリに置いておくと、全員が同じ前提で使えます。公式の目安は200行未満です。会社全体の決まりは、管理者設定から配ることもできます
  3. 最初の作業を具体的に示す：「コードベースについて質問する」「小さな不具合を直す」など、失敗しにくいものから始めます

4-4. 使われ続けているかを数字で見る

展開後は、利用状況を毎月確認します。見る項目の例です。

見る項目確認する場所
日ごと・週ごとの利用者数利用分析の画面、OpenTelemetry
1人あたりの費用支出レポート、各クラウドの請求
拒否された操作の件数と内容OpenTelemetry、フックの記録
許可リストへの追加申請の件数申請用のリポジトリ

拒否された操作が多い場合、2つの可能性があります。危険な使い方が多いのか、禁止ルールが厳しすぎて日常の作業を妨げているのかです。後者なら、ルールを見直します。

つまずいたときの確認順

導入の作業でよく起きる問題を、症状から引けるようにまとめます。

症状最初に確認すること対処
起動しない管理者設定のファイルが JSON として正しいかjq . managed-settings.json で形式を確認
管理者設定が効いていない/status の Setting sources の表示置き場所、ファイル名、接続経路（クラウド経由ではサーバー管理は使えない）を確認
社内ネットワークでつながらないプロキシの設定、許可リストclaude --debug で記録を確認。証明書の検査がある場合は社内の証明書を設定
フックが動いていないスクリプトのパスと実行権限初回の実行時に出る通知を確認。止めるときは終了コード2
承認の確認が何度も出るサーバー管理でフックやプロキシを配っているか仕様。事前に案内する
許可していない MCP サーバーが動いている許可リストの書き方が serverName になっていないかserverUrl か serverCommand に変える
費用が想定より多いモデルの指定、利用者ごとの内訳モデルを固定し、上限を設定

導入前チェックリスト

最後に、ここまでの内容を確認項目にまとめます。

壁1 セキュリティ

  • □ 接続経路を決めた（直接契約／クラウド事業者経由）
  • □ データの保持期間と処理者を、審査の担当に説明できる
  • □ 管理者設定の配り方を決めた（サーバー管理／エンドポイント管理）
  • □ 禁止ルールに加えて、サンドボックスの利用を検討した
  • □ 記録の取り方を決めた（監査ログ／フック／OpenTelemetry）
  • □ MCP サーバーの申請と承認の流れを決めた

壁2 コスト

  • □ 総額を5つの区分で見積もった
  • □ 利用料の実測値を、試行で取る計画がある
  • □ 支出の上限を設定した

壁3 既存環境

  • □ 通信先を、公式の最新の表をもとに許可リストへ登録した
  • □ プロキシと証明書の設定を、管理者設定で配る準備をした
  • □ SSO の設定を確認した

壁4 定着

  • □ 段階ごとに、次へ進む条件を決めた
  • □ 推進役と、質問用のチャンネルを用意した
  • □ CLAUDE.md と、最初に試す作業を用意した

まとめ

Claude Code の企業導入で立ちはだかる壁は4つあり、それぞれ相手と越え方が違います。

壁越え方この記事での気づき
セキュリティ仕組みで強制する禁止ルールは書き方の違いに弱い。機密ファイルはサンドボックスで閉じる
コスト総額と実測で語る席料は費用の一部。利用料は試行で測る
既存環境接続経路から決める経路によって使える管理機能が変わる
定着小さく始めて広げる次へ進む条件を先に決める

4つの壁に共通しているのは、最初に接続経路を決めることです。直接契約か、クラウド事業者経由か。この選択で、データの扱い、設定の配り方、記録の取り方、費用の管理方法がすべて決まります。

次の一歩としては、数人での試行を始めながら、セキュリティ審査の担当に図6の内容を持っていくのがお勧めです。審査には時間がかかるので、試行と並行で進めると、結果が出るころに次の段階へ進めます。

参考リソース

Claude Code 公式ドキュメント

料金・契約・信頼性

導入事例（公式カスタマーストーリー）

PR

生成AIを体系的に学びたい方へ

「DMM 生成AI CAMP 学び放題」は、ChatGPTなどの生成AIを学べる月額制のオンライン学習サービスです。仕事への活用に向けて継続的に学びたい方は、公式サイトでコース内容や入会条件をご確認ください。

DMM 生成AI CAMP 学び放題

リンク先は公式サイトです。

AI入門Claude Code企業 × 生成AI活用
Takuyaをフォローする
Takuya