はじめに

生成 AI ガバナンスの盲点

生成 AI の業務利用にあたって、URL フィルタリングで「どのサービスを許可するか」を統制している組織は多いと思います。
実際、ほとんどの要件はこれでカバーできますが、これだけでは統制できないものが残ります。
どのアカウントで使うか、です。

会社として Claude Enterprise を契約していても、従業員が同じ claude.ai に個人の Free / Pro アカウントでログインしてしまえば、業務データは組織の管理外に出ていきます。個人アカウントは監査ログにも Compliance API にも乗りません。ドメインは同じなので、URL フィルタでは区別できません。

この「同一ドメイン・別アカウント」問題への Anthropic の公式な回答が、テナント制限（Tenant Restrictions）です。

テナント制限とは？

Anthropic のヘルプセンターには、以下のように記載されています。

Tenant Restrictions enable IT administrators on Enterprise plans to enforce network-level access control for Claude. This feature ensures that users on corporate networks can only access approved organizational accounts, preventing unauthorized use of personal accounts.

仕組みはシンプルで、Claude 宛のリクエストに anthropic-allowed-org-ids という HTTP ヘッダーで「許可する組織 ID（UUID）のリスト」を載せると、Anthropic のサーバー側でセッションの所属組織と照合し、リストにない組織からのアクセスを 403 で拒否してくれます。個人アカウントは許可リストに一致しようがないので、必ず拒否側に落ちる、という理屈です。

ただ、このヘッダーを「誰が」注入するかが問題でした。
公式ドキュメントの構成例はプロキシでの注入で、TLS インスペクションが必須です。
つまり、プロキシを通らない経路（リモートワークの自宅回線など）では、制限が静かに効かなくなります。
ZTNA や CASB によって対応も可能ですが、運用の難易度も高くなります。

Chrome 152 の HttpHeaderInjection

そこで登場したのが、Chrome 152（2026年8月25日リリース予定）で追加されるエンタープライズポリシー HttpHeaderInjection です。
Chrome Enterprise のリリースノートには、SaaS のテナント制限の強制を主なユースケースとして、ブラウザのネットワークスタックで直接ヘッダーを注入できると記載されています。

  • SSL インスペクションプロキシが不要
  • 拡張機能による改変・バイパスが不可
  • 管理対象ブラウザであれば、オフィスでも自宅でもホットスポットでも制御が追従

本当にこれだけで個人アカウントを止められるのだろうか。。。

ということで、実際に検証してみました。
※ 現状、検証可能な Claude Enterprise が手元にないため、実証確認できたのは拒否の部分のみです。しかし、論理的には成功する見込みです。

仕組み

登場人物と流れを整理しておきます。

役割 担当
許可リストの宣言 Chrome（HttpHeaderInjection ポリシーがヘッダーを毎リクエストに注入）
アカウントの判定 Anthropic サーバー（セッションの組織 ID とヘッダーを照合）
ブロックの実行 Anthropic サーバー（403 permission_error / tenant_restriction_violation）

ポイントは、ブロックの判定と実行が Anthropic 側で行われることです。
Anthropic 側に設定を登録するわけではないので、ヘッダーの注入をやめれば次のリクエストから即復旧します（ロールバックが容易）。
逆に、ヘッダーが付かない経路では標準の認証がそのまま通ります（フェイルオープン）。制限が効かない方向に倒れるので、業務停止リスクは低い一方、適用範囲の設計が肝になります。

なお、テナント制限は Enterprise プランおよび Console 組織限定の機能です。Team プランでは利用できません。

検証

環境

項目 内容
OS macOS
ブラウザ Google Chrome Beta 152（検証時点で Stable は 151）
管理 Chrome Enterprise Core（Google 管理コンソール）
Claude 個人アカウント（ブロックされる側の検証）

Chrome 152 は検証時点で Stable 直前だったため、Beta チャンネルを使用しました。
Stable リリース（2026年8月25日）以降であれば、通常の Chrome で同じ検証ができます。

1. ブラウザを Chrome Enterprise Core に登録

Google 管理コンソールから登録トークンを生成し、検証機の Chrome をクラウド管理下に置きます。

$ defaults write com.google.Chrome CloudManagementEnrollmentToken -string "YOUR-TOKEN"

Chrome を再起動し、chrome://policy で管理対象になっていることを確認します。

2. Custom Configurations でポリシーを設定

検証時点では、管理コンソールの Users & browsers 設定画面に HttpHeaderInjection の専用 UI がまだありませんでした。
新しいポリシーではよくあることで、こういう場合は Custom Configurations ページから JSON で直接設定できます。

管理コンソール > Chrome browser > Custom Configurations にて、対象 OU を選択し、以下の JSON を設定します。

{
  "HttpHeaderInjection": [
    {
      "patterns": [
        "claude.ai",
        "anthropic.com",
        "claude.com"
      ],
      "headers": [
        {
          "name": "anthropic-allowed-org-ids",
          "value": "550e8400-e29b-41d4-a716-446655440000"
        }
      ]
    }
  ]
}

value には自組織の Organization ID（Enterprise プランの Settings > Account で確認可能）を設定します。
今回はブロック側の検証のため、書式として正しいダミーの UUID を使用しています。
検証の際も、正式のフォーマット (8-4-4-4-12 hex format) である必要があります。

設定後、chrome://policy で Reload policies を実行し、HttpHeaderInjection が Source: Cloud / Status: OK で表示されることを確認します。
このポリシーは dynamic refresh 対応なので、ブラウザの再起動は不要でした。

3. ヘッダー注入の確認

注入されたヘッダーは DevTools に表示されないことがあるため、ヘッダーをエコーしてくれるサービスで確認するのが見やすいです。
patterns に一時的に httpbin.org を追加し、https://httpbin.org/headers にアクセスします。

{
  "headers": {
    "Accept": "text/html,...",
    "Anthropic-Allowed-Org-Ids": "550e8400-e29b-41d4-a716-446655440000",
    "Host": "httpbin.org",
    ...
  }
}

ちゃんと注入されています。
確認が済んだら、httpbin.org は patterns から削除しておきます。本番設定でダミーとはいえヘッダーを第三者サイトに送る理由はないので。

4. 個人アカウントでのブロック確認

いよいよ本題です。個人アカウントで claude.ai にログインしてみます。

結果、チームに参加にリダイレクトされ、チャットは一切利用できませんでした。
「個人アカウントで参加」ボタンを押下しても同様です。

API レベルでは以下の 403 エラーが返っています。

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

正確には「ログイン認証が失敗する」のではなく「認証後のすべてのリクエストがサーバー側で拒否される」挙動ですが、ユーザー体感としては個人アカウントが使えない状態そのものです。

ポリシーを削除して Reload policies すると、即座にアクセスが復旧しました。
ロールバックがワンアクションなのは運用上ありがたいところです。

ハマったポイント

検証中に 2 回ハマったので、供養しておきます。

その 1: フィールド名の誤り

当初、URL パターンのキーを url_patterns と書いていましたが、正しくは patterns でした。
このポリシー、無効なルールはエラーにならず静かに無視される仕様です。chrome://policy 上は設定済みに見えるのに何も起きない、という状態になります。
Chromium ソースのポリシー定義（policy_definitions/Network/HttpHeaderInjection.yaml）にスキーマと example_value が定義されているので、新しいポリシーを扱う際は一次情報にあたるのが確実です。

  • patterns: URL パターンのリスト（URL blocklist filter 形式。claude.ai のような素のホスト名でサブドメインまでマッチ）
  • headers: name / value を持つオブジェクトのリスト
  • 制約: 全ルール合計 500 パターンまで、1 ルール 20 ヘッダーまで、1 ヘッダー 8KB まで

その 2: プレースホルダのまま配布

ヘッダー値を YOUR-ORG-UUID の文字列のまま配布してしまい、注入は成功しているのにブロックされない状態になりました。
UUID として不正な値では Anthropic 側の検証が意図通りに働きません。httpbin でのエコー確認をしていたおかげで、値がそのまま送信されていることに気づけました。
ヘッダーの存在確認だけでなく、値の確認まで含めてエコーテストすることをおすすめします。

運用に向けた考慮事項

検証を通して見えてきた、実運用での設計ポイントです。

  • エラーコードで切り分け可能: 403（tenant_restriction_violation）は意図通りのブロックまたは UUID 誤り、400 はヘッダー書式不正（同名ヘッダーの重複注入など）。ヘルプデスクの一次切り分け表に載せておくと楽です。
  • Custom Configurations は暫定措置: 専用 UI が管理コンソールに実装されたら、JSON 設定からネイティブ設定への移行が必要になります。Runbook に明記しておきましょう。
  • ブラウザ以外の経路: このポリシーが効くのは Chrome 経由のトラフィックのみです。Claude Desktop には MDM ポリシーの forceLoginOrgUUID（サインイン先組織のピン留め）を併用する多層構成が推奨されます。
  • アイデンティティ層が先: ネットワーク制御は多層防御の外側の層です。SSO 強制とドメインキャプチャ（会社メールで個人アカウントを作れなくする）を土台にした上で、本ポリシーを「管理端末上の帯」として重ねるのが正しい順序です。
  • 他の生成 AI は別途統制: テナント制限が効くのは Claude ブランド製品のみです。他サービスの個人利用は Chrome Enterprise Premium の URL フィルタリング（Generative AI カテゴリ）等で併せて統制します。

まとめ

Chrome 152 の HttpHeaderInjection ポリシーを使って、プロキシも TLS インスペクションもなしに、個人 Claude アカウントの利用をブロックできることを確認しました。

従来のプロキシ方式の「社内ネットワークでしか効かない」という弱点を、ブラウザ管理だけで解消できるのは大きな進歩だと感じます。エンドポイントエージェント型の商用製品と同等の「制御が端末に追従する」性質を、Chrome Enterprise Core（無償）の範囲で実現できる点も、提案の幅が広がりそうです。Chrome Enterprise Premium によって、より総合的な統制も可能です。

我々でサポートも可能です。
Chrome Enterprise Premium 導入支援サービス

生成 AI の統制は「ツールを止める」から「承認テナントだけを通す」へ。
シャドー AI 対策でお悩みの方に少しでも役に立てば、これ幸い。

参考

https://support.claude.com/en/articles/13198485-enforce-network-level-access-control-with-tenant-restrictions
https://support.google.com/chrome/a/answer/10314655
https://support.google.com/chrome/a/answer/14749672
https://chromeenterprise.google/policies/
https://chromium.googlesource.com/chromium/src/+/main/components/policy/resources/templates/policy_definitions/Network/HttpHeaderInjection.yaml