Claude Media
Claudeのテナント制限で会社ネットワークから個人アカウントを締め出す
Claudeチュートリアル

Claudeのテナント制限で会社ネットワークから個人アカウントを締め出す

Claudeのテナント制限は、社内プロキシが付けたヘッダーで許可した組織以外のアクセスを遮断します。ヘッダー形式、分割の上限、403と400の読み方、対応プロキシを解説します。

読了目安 約19分

Claudeのテナント制限(Tenant Restrictions)とは

テナント制限は、会社のネットワークからClaudeへ届くリクエストを、許可した組織のアカウントだけに絞る仕組みです。対象はEnterpriseプランのメンバーとConsole組織です。社員が私用のClaudeアカウントで会社のPCからログインしても、ネットワーク層で止められます。

動き方は単純です。会社のネットワークプロキシが、Claude宛てのリクエストにHTTPヘッダーを差し込みます。Anthropic側がそのヘッダーを検証し、許可リストにない組織からのアクセスを遮断します。管理者が設定するのは、ネットワークプロキシ側のルールです。

対応する認証方式は4種類です。

  • claude.aiのWebアクセス
  • デスクトップアプリ経由のアクセス
  • APIキー認証
  • OAuthトークン認証

ブラウザ版とAPIの両方を1つのルールで押さえられる点が、アカウント単位の設定との大きな違いです。

導入の前提条件

導入前に、次の4点がそろっているかを確かめます。

  • 対象プラン: EnterpriseプランのメンバーまたはConsole組織であること
  • TLS検査: プロキシがHTTPSの通信を復号してヘッダーを差し込める構成であること
  • ヘッダー注入の機能: 対応プロキシ製品(後述)か、ヘッダー注入ができる一般的なHTTPSプロキシがあること
  • 取引先の組織UUID: 取引先も許可するなら、先方の管理者から教えてもらうこと。UUIDは先方の組織の画面で確かめられる値です

ヘッダーの形式と書き方

差し込むヘッダーの名前は anthropic-allowed-org-ids です。値は許可する組織UUIDをカンマで区切った文字列で、値どうしの間にスペースは入れません。

anthropic-allowed-org-ids: <org-uuid-1>,<org-uuid-2>

自社の組織だけを許可するなら、UUIDは1つです。取引先の組織も使わせたいときは、そのUUIDをカンマで足します。

組織UUIDの調べ方

Enterpriseの場合、組織IDは2か所で確認できます。

  1. 「Settings」→「Account」を開き、Organization IDを探す
  2. 「Organization settings」→「Organization」を開き、ページ下部のOrganization IDを探す

Console組織は「Settings」→「Organization」にあります。

許可リストが長いときの分割

プロキシ製品によっては、1行のヘッダーに入る長さに上限があります。その場合は、番号付きの続きヘッダーに分けられます。

anthropic-allowed-org-ids: <uuid>,<uuid>;n=3
anthropic-allowed-org-ids1: <uuid>,<uuid>
anthropic-allowed-org-ids2: <uuid>,<uuid>

基本のヘッダーの末尾に ;n=K を付け、ヘッダーの総行数を宣言します。残りのUUIDは anthropic-allowed-org-ids1 から anthropic-allowed-org-ids{K-1} に入れます。上の例は n=3 なので、基本を含めて3本です。

数字

分割ヘッダーの上限

  • ヘッダーの行数

    最大10行

    Kは10以下

  • 組織UUIDの総数

    最大500個

    全行の合計

宣言した行はすべて送ります(n=3なら3本とも必須)

分割するかどうかにかかわらず、プロキシはこれらのヘッダーを毎回上書きする設定にします。無いときだけ追加する設定では、端末側が送ったヘッダーがそのまま通ってしまうためです。

導入手順 — プロキシへのルール追加とテスト

手順は3段階です。

手順

テナント制限を入れる流れ

  1. 1

    許可する組織のUUIDを集める

    自社のUUIDに加え、許可したい取引先があればそのUUIDも集めます。

  2. 2

    プロキシにヘッダー注入のルールを作る

    Claude向けの通信へヘッダーを差し込むルールです。設定項目の並びは製品ごとに異なり、中身は次の形になります。

    Rule: Claude Tenant Restriction
Application: claude.ai, api.anthropic.com, claude.com, anthropic.com
Action: Inject Header
Header Name: anthropic-allowed-org-ids
Header Value: <許可する組織UUIDをカンマ区切りで>
TLS Inspection: Required
  3. 3

    制限をかけたネットワークから疎通を確かめる

    自社組織のAPIキーで通ること、私用アカウントが止まることを順に見ます。

TLS Inspection: Required に注意してください。ヘッダーはHTTPSの通信の中に差し込むため、プロキシが通信を復号できなければ注入できません。TLS検査が入っていないネットワークでは、この機能は成立しません。

注入対象のドメインは、claude.ai、api.anthropic.com、claude.com、anthropic.com の4つです。

デスクトップアプリとclaude.aiは、アプリ用に追加のCDNホスト(assets-proxy.anthropic.com、*.claudeusercontent.com)も使います。claude.ai だけを許可してこれらを遮断すると、エラーではなく白紙のページになります。TLS検査や許可ルールを作るときは、これらのホストも対象に含めます。

疎通テスト

制限をかけたネットワークで、自社組織のAPIキーを使ってリクエストを送ります。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $CLAUDE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-4-6","max_tokens":1024,
       "messages":[{"role":"user","content":"Hello"}]}'

自社の組織が許可リストに入っていれば、通常どおり応答が返ります。次に、私用アカウントのAPIキーやブラウザのログインで同じネットワークから試し、遮断されることまで確認します。

画面にエラーが出たとき — 403と400の見分け方

失敗のしかたは2系統あります。原因が「許可されていない組織」か「プロキシの設定ミス」かで、ステータスが分かれます。

くらべる

403と400はどこが違うか

組織が許可リストにない

403

ヘッダーは正しく届いており、アカウントの組織だけが許可リストに載っていません。直す場所は許可リストのUUIDです。

ヘッダーが壊れている

400

ヘッダーが壊れていれば400になります。直す場所はプロキシのルールです。

403 — 許可リストにない組織

許可リストに載っていない組織のアカウントには、403が返ります。

{
  "type": "error",
  "error": {
    "type": "permission_error",
    "message": "Access restricted by network policy. Contact IT Administrator.",
    "error_code": "tenant_restriction_violation"
  }
}

error_code が tenant_restriction_violation なら、テナント制限が効いた結果です。ユーザーに見えるメッセージは「IT管理者に連絡してください」なので、社員向けの問い合わせ窓口を先に決めておくと、問い合わせが迷子になりません。

400 — ヘッダーの設定ミス

プロキシがヘッダーを誤って送ると、400で失敗します。メッセージは2種類です。

メッセージ意味と直し方
Multiple anthropic-allowed-org-ids headers意味と直し方同じ名前のヘッダーが1つのリクエストに複数ある。追加でなく上書きに変える
Malformed anthropic-allowed-org-ids headers意味と直し方;n=K の値が不正、宣言した行の欠落や余り、UUIDの総数が500超のいずれか

宣言した本数と実際の本数がずれるときは、;n=3 なら3本すべてを毎回送るようにルールを直します。

対応しているプロキシ製品

サポートされているプラットフォームは次のとおりです。括弧内は、設定に使う機能の名前です。

  • Cato Networks(Tenant Restriction policy)
  • Cloudflare Zero Trust / Gateway(HTTPポリシーでカスタムリクエストヘッダーを追加)
  • Netskope(Header Insertion rules)
  • Palo Alto Prisma Access(SaaS App Management)
  • Zscaler ZIA(Cloud App Control policies)
  • ヘッダー注入ができる一般的なHTTPSプロキシ

すでにこれらのSASEやSWGを使っているなら、新しい製品を入れる必要はありません。

どの制御から始めるか — 状況別の使い分け

Claudeには、個人アカウントの業務利用を抑える手段がほかにもあります。効く層が違うので、困っている状況から選びます。

状況手段効く層
社員が会社のPCから私用アカウントでログインする手段テナント制限効く層会社ネットワークの通信
会社ドメイン上に個人アカウントが残っている手段ドメインキャプチャ効く層アカウント管理
社外アカウントへ業務データが流れる手段コネクタのドメイン制限効く層コネクタ接続
許可した拠点以外からは使わせたくない手段IPアドレスの許可リスト効く層接続元IP

ドメインキャプチャとコネクタ制限は、効く層がアカウント管理とコネクタ接続で、プロキシのヘッダーとは別の仕組みです。

IPアドレスの許可リストはEnterpriseプラン向けの機能です。CIDR範囲で指定し、設定は自社のAnthropic窓口かサポートに範囲の一覧を伝えて有効にします。範囲に漏れがあると、利用者が締め出されることがあります。

テナント制限が「どの組織のアカウントか」を見るのに対し、IP許可リストは「どこから来た通信か」を見ます。両方を入れる場合の注意が、Claude Codeのブラウザー連携です。連携用のホスト bridge.claudeusercontent.com は、claude.ai や api.anthropic.com と同じプロキシの出口を通すのが公式の案内です。

通せないときは、そのホストに使う出口アドレスを許可リストへ足します。足してよいのは、自組織専用の出口アドレスだけです。共有の出口アドレスを足すと、プロキシ事業者の他の顧客も通ってしまいます。

組み合わせ方はClaudeのドメインキャプチャ一括移行の手順とコネクタを制限し社外アカウントの接続を防ぐ設定が参考になります。個人アカウントの業務利用が社内規程上どう扱われるかは、Claude個人アカウントを会社に無断で仕事に使ってよいかで扱っています。

Claude Codeを使う端末で気をつける点

Claude Codeは、次のホストへの接続を必要とします。

ホスト用途
api.anthropic.com用途APIリクエスト
claude.ai用途claude.aiアカウントの認証
claude.com用途サインイン時にブラウザで開くページ(claude.ai へリダイレクト)
platform.claude.com用途Consoleアカウントの認証。claude.aiアカウントのOAuthトークンの交換・更新にも使う

前の3つは、テナント制限のヘッダー注入対象ドメインと重なります。

CLIをプロキシ経由にする

CLIは標準のプロキシ環境変数に従います。SOCKSプロキシには対応していません。プロキシのURLだけは起動時に検証され、解釈できない値(http:// が抜けているなど)だと起動が止まります。

export HTTPS_PROXY=https://proxy.example.com:8080
# プロキシを通さない宛先(スペース区切りもカンマ区切りも可)
export NO_PROXY="localhost,192.168.1.1,example.com,.example.com"

小文字の https_proxy なども使えます。Claude Codeは https_proxy、HTTPS_PROXY、http_proxy、HTTP_PROXY の順で、最初に設定されているものを使います。

バックグラウンドエージェントはsupervisorを共有します。プロキシやCAの変数は、シェルではなく ~/.claude/settings.json か管理設定の env ブロックに置きます。

Claude Desktopがプロバイダーとの接続を管理するセッションでは、これらの変数を管理設定と ~/.claude/settings.json からだけ読みます。リポジトリ内の設定ファイルは無視されます。詳しい設定はClaude Codeのプロキシ設定にまとめてあります。

設定が読み込まれたかを確かめる

プロキシのアドレスや証明書のパスの誤りは、起動時にはほとんど検証されません。後続のリクエストで接続エラーや証明書エラーが出て初めて気づくのが普通です。先に確かめるなら、次の2つの方法があります。

  • 対話セッションで /status を実行し、Proxyの行にプロキシのURLが出ているかを見る。解釈できない値は無効として無視された旨が表示される
  • claude --debug で起動し、デバッグログに追加CA証明書の読み込み行が出ているかを見る。ログの出力先は既定で ~/.claude/debug/ 配下で、--debug-file <path> で変えられる

検査プロキシの証明書を信頼させる

Claude Codeは、同梱のMozilla CA証明書と、OSの証明書ストアの両方を既定で信頼します。ただしOSのストアを読めるのは、tls.getCACertificates を持つ実行環境だけです。ネイティブインストーラー版は常に読めますが、npmで入れた版はNode 22.15以上が必要です。

Node 22.15より古いnpm版では、OSのストアが読まれず、同梱のセットと NODE_EXTRA_CA_CERTS だけが効きます。この場合、社内のルート証明書をファイルで渡します。

# 社内ルート証明書(PEM形式)を追加で信頼させる
export NODE_EXTRA_CA_CERTS=/path/to/corp-root-ca.pem
 
# 信頼元の既定値。bundled が同梱セット、system がOSのストア
export CLAUDE_CODE_CERT_STORE=bundled,system

CLAUDE_CODE_CERT_STORE はカンマ区切りで指定し、既定値は bundled,system です。ネイティブインストーラー版か、Node 22.15以上のnpm版で、社内のルート証明書がOSのストアに入っていれば、追加設定なしで動きます。

Bedrockやゲートウェイ経由のセッション

Bedrock、Google CloudのAgent Platform、Microsoft Foundryのセッションや、Claude appsゲートウェイ経由のセッションもあります。これらのモデル通信と認証は、api.anthropic.com や claude.ai ではなく、プロバイダーかゲートウェイへ向かいます。つまり、注入対象のドメインを通らない通信が増えます。

例外もあります。WebFetchツールのドメイン安全確認は、skipWebFetchPreflight: true を設定しない限り api.anthropic.com を呼びます。ANTHROPIC_BASE_URL でLLMゲートウェイを使っていても、高速モードの利用可否の確認は api.anthropic.com へ向かいます。

この確認はプロキシの設定に従います。ネットワークの遮断が原因なら、プロキシで api.anthropic.com を許可するのが対処です。

テナント制限を設定していない環境への影響

テナント制限を設定していないネットワークには、影響がありません。通常の認証は、管理外のネットワークでもそのまま動きます。既存のAPIキー認証にも変更はありません。

よくあるつまずき

自社の正規アカウントでも止まる

400はヘッダーの形式エラーです。Claude Codeが403や400で止まったときは、CLIの不具合を疑う前に、許可リストの組織UUIDとヘッダーの書き方を見ます。展開前に少数の端末やテスト用ルールで通しておくと、全社展開後の混乱を避けられます。

403が返るのに本来の組織のはず

症状は、403と tenant_restriction_violation です。原因は、組織UUIDが許可リストに入っていないことです。取引先の組織なら、先方の管理者から受け取ったUUIDが正しいかも確認します。区切りのカンマの前後にスペースが入っていないかも見ます。

プロキシを通らない通信にはヘッダーが付かない

ヘッダーを付けるのはプロキシなので、自宅やモバイル回線からの通信がプロキシを通らない構成なら、ヘッダーは付きません。個人アカウントの利用を減らすなら、ドメインキャプチャなど効く層が別の手段と組み合わせる選択肢があります。

TLS検査がなくヘッダーが付かない

ヘッダーはHTTPSの通信の中に差し込むため、プロキシが復号できなければ注入されません。ルールの TLS Inspection を必須にし、対象ドメインを復号の対象に含めます。

まとめ

テナント制限は、アカウントの設定ではなく、会社ネットワークの出口で使えるアカウントを絞る仕組みです。プロキシにヘッダーを1つ足すだけで、ブラウザ・デスクトップ・APIキー・OAuthトークンの4経路をまとめて押さえられます。

導入の前提はTLS検査です。止まったときは、403なら許可リストの組織UUID、400ならプロキシのヘッダー設定と、直す場所が分かれます。

この記事を共有:XはてブLinkedIn

関連する記事

Claude をもっと見る →