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

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

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

読了目安 約16分

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: 取引先も許可するなら、先方の管理者から教えてもらう必要があること。自社側で調べる手段はありません

ヘッダーの形式と書き方

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

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

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

想定ヘッダーの値
自社の組織だけヘッダーの値自社の組織UUID
自社と取引先の組織ヘッダーの値組織UUIDを2つ、カンマ区切り

組織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. 許可する組織のUUIDを集める
  2. プロキシに、Claude向けの通信へヘッダーを注入するルールを作る
  3. 制限をかけたネットワークから疎通を確かめる

ルールの中身は、例えば次のような形です(設定項目の並びは製品ごとに異なります)。

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

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

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

疎通テスト

制限をかけたネットワークで、自社組織の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キーやブラウザのログインで同じネットワークから試し、遮断されることまで確認します。

エラー応答の読み方

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

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超のいずれか

400は組織の許可・不許可とは無関係に出ます。自社の正規アカウントでも、ヘッダーが壊れていれば止まります。

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

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

  • 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には、個人アカウントの業務利用を抑える手段がほかにもあります。効く層が違うので、目的で使い分けます。

手段効く層止めるもの
テナント制限効く層会社ネットワークの通信止めるもの許可外の組織へのアクセスそのもの
ドメインキャプチャ効く層アカウント管理止めるもの会社ドメインのメールで作られた個人アカウントの組織への取り込み
コネクタのドメイン制限効く層コネクタ接続止めるもの社外アカウントへの業務データ連携
IPアドレスの許可リスト効く層接続元IP止めるもの許可した送信元以外からの利用

テナント制限が扱うのは、プロキシを通る通信だけです。逆に、ドメインキャプチャやコネクタ制限は、ネットワークを問わずアカウントやデータ連携に効きます。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の設定はClaude Codeのプロキシ設定にまとめてあります。

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

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のストアに入っていれば、追加設定なしで動きます。

影響が出ないケース

テナント制限を設定していないネットワークには、影響がありません。通常の認証は、管理外のネットワークでもそのまま動きます。既存のAPIキー認証にも変更はありません。段階的に広げても、既存の利用が一斉に止まる構造ではないということです。

よくあるつまずき

宣言した行数と実際の本数がずれて400になる

症状は、;n=3 のように宣言したのに、400の「Malformed anthropic-allowed-org-ids headers」が返ることです。原因は、続きヘッダーが宣言より少ない(または多い)、もしくは ;n=K の値が不正なことです。UUIDの総数が500を超えても同じエラーになります。宣言した本数ぶんのヘッダーを全部送るようにルールを直します。

ヘッダーが二重に付いて400になる

症状は、400の「Multiple anthropic-allowed-org-ids headers」です。原因は、プロキシが既存のヘッダーの有無を見て追加する設定になっていて、同じ名前のヘッダーが1つのリクエストに複数付くことです。毎回上書きする設定に変えます。

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

400は組織の許可・不許可と関係なく出ます。ヘッダーが壊れていれば、許可リストに入っている自社アカウントでも止まります。Claude Codeが403や400で止まったときは、CLIの不具合を疑う前に、許可リストの組織UUIDとヘッダーの書き方を見ます。展開前に少数の端末やテスト用ルールで通せば、全社展開後の混乱を避けられます。

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

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

自宅やモバイル回線では制限が効かない

社外の回線に出た端末は、プロキシを通らないので、ヘッダーが付かず対象外です。ネットワーク層の制御だけで個人アカウントを完全には防げません。ドメインキャプチャなど、ネットワークを問わない手段と組み合わせる必要があります。

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

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

まとめ

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

注意点は3つに絞れます。TLS検査が前提であること、ヘッダーは毎回上書きすること、自宅やモバイル回線には効かないことです。個人アカウントの利用を減らすなら、ドメインキャプチャでアカウントを組織に取り込みつつ、テナント制限でネットワーク越しの経路を塞ぐ組み合わせが現実的です。

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

関連する記事

Claude をもっと見る →