AIのチャットや文書作成の機能を自社のサービスに組み込み、複数の顧客企業に提供している。APIの契約はAnthropicの組織1つで、どの顧客のリクエストも同じAPIキーで送っている。この構成には、気をつけておきたい弱点があります。
Anthropicは、APIのやり取りに自動の安全チェック（分類器）をかけています。顧客の誰か1社が利用ポリシーに反する使い方をして、制限や停止の対象になったとき、どの顧客のリクエストかが分からなければ、その措置は契約している組織全体にかかり得ます。Anthropicは2026年10月20日、リリースノートで「ユーザープロファイル」を案内し、21日には制限の状態を確認できる項目も加えました。この記事では、公式ドキュメントからこの仕組みを整理し、受託で作ったAIサービスや社内向けのプラットフォームでどう使うかをまとめます。
何のための仕組みか
ドキュメントの冒頭は、目的を次のように説明しています。
User profiles (“profiles”) tell Anthropic which of your end customers each API request is for. A safety enforcement action, such as a restriction or a ban, can then apply to one end customer instead of your whole organization.
Without a profile on the request, one end customer can trigger an enforcement action that applies to your whole organization.
顧客（エンドカスタマー）ごとにプロファイルを1つ作り、そのIDをリクエストに付けて送ると、制限や停止をその顧客だけにかけられるようになります。残りの顧客のリクエストは影響を受けません。プロファイルに料金はかからず、料金体系も変わりません。
ユーザープロファイルは、それまでベータ用のヘッダー（user-profiles-2026-09-04 など）を付けて使う機能でした。Pythonの公式SDKの変更履歴では、10月20日の1.16.0で一般提供（generally available）の扱いになっています。
対象になるのは、プラットフォームやゲートウェイを運営している場合や、APIの利用を再販している場合です。自社の社内利用には付けず、ドキュメントは、顧客向けのリクエストと社内利用を別の組織に分けるよう求めています。プロファイルは組織に属するため、同じ組織の中でワークスペースを分けるだけでは足りません。
誰に1つ作るか
プロファイルの作り方は、Claudeをどう提供しているかで変わります。
| 誰のためのリクエストか | プロファイル | access_type |
|---|---|---|
| 自社のサービスに登録した個人の利用者 | 利用者ごとに1つ（登録時に作る） | application（既定） |
| APIを再販している顧客企業（ゲートウェイなど） | 会社ごとに1つ（社員ごとではない） | passthrough（明示して送る） |
| 自社の社内利用 | 作らない（別の組織に分ける） | なし |
passthrough のプロファイルは会社を表すため、個人を特定できるリクエストでは、Messages APIの metadata.user_id に、その人の識別子を別に入れるよう案内されています。
プロファイルの作成は POST /v1/user_profiles で行い、返ってきた uprof_ で始まるIDを顧客の情報と一緒に保存します。この呼び出しは冪等ではなく、同じ reference_id を送っても毎回新しいプロファイルができます。そのため、顧客の登録処理の中で1回だけ作り、各サーバーは保存したIDを読むよう書かれています。既存の顧客をまとめて登録する前には、Anthropicの担当者に連絡するよう求められています。
毎回のリクエストにIDを付ける
顧客のためのリクエストには、毎回 anthropic-user-profile-id ヘッダーでIDを付けます。SDKには、このヘッダーを付ける引数（Pythonでは user_profile_id）があります。
2026年10月24日に、編集部の検証環境（Python 3.11.17）で、Pythonの anthropic 1.17.0と2.0.0から、ローカルに立てた受信用のサーバーへ user_profile_id="uprof_011TEST" と metadata={"user_id": "emp-42"} を付けて送ったところ、どちらの版も anthropic-user-profile-id: uprof_011TEST ヘッダーと、本文の metadata.user_id を送りました。Anthropicのサーバーには送っていないため、IDの検証の結果は確かめていません。
Python SDKでプロファイルを扱うときは、client.user_profiles を使います。変更履歴によると、後述の制限の状態の項目がSDKの型に加わったのは2.1.0（10月21日）で、10月27日時点の最新は2.3.0です。なお、10月27日にSDKのソースを確かめたところ、2.3.0でもベータ側の client.beta.user_profiles は古いベータのヘッダー（user-profiles-2026-08-18）を自動で付けます。このヘッダーを付けると、制限の状態の項目が応答に含まれません。
ドキュメントによると、Claude APIは毎回IDを確かめ、形式が誤っていたり、別の組織のIDだったりすると400エラーを返します。一方、Message Batchesは作成時に形式しか確かめず、組織が違うIDでもバッチ自体は作られ、中の各リクエストがエラーになります。
Bedrock・Google Cloud・Foundryを使っている場合
推論をAmazon BedrockやGoogle Cloud（Google managed）、Microsoft Foundryで動かしている場合は、扱いが変わります。
- プロファイルの作成はClaude APIかClaude Platform on AWSの組織で行い、IDだけを推論のリクエストに付ける。Bedrockでは、ヘッダーではなく本文の
user_profile_idに入れる - BedrockとGoogle managedは、IDの形式だけを確かめ、プロファイルが実在するかは見ない。成功の応答が返っても、IDが正しいとは限らない
- AWSのアカウントやGoogle Cloudのプロジェクトを、Verification Portal（
portal.anthropic.com）でAnthropicの組織にひも付ける手順がある - 従来のBedrockの呼び出し（
InvokeModel・Converse）では使えない - Microsoft Foundryは、Anthropicがホストするデプロイであれば、Foundryのエンドポイントでプロファイルを作り、ヘッダーで送れる。Azureがホストするデプロイは、ドキュメントの対象に入っていない
- 10月22日に始まったGoogle Cloudの「Anthropic managed」での扱いは、10月27日時点のこのドキュメントには書かれていない
制限されたことを知る
10月21日からは、プロファイルに enforcement_status と enforcement_actions の2つの項目が付きました。enforcement_status は、措置がなければ unrestricted、制限があれば restricted、停止があれば banned になります。措置が続いている間、そのプロファイルのIDを付けたリクエストは、一部またはすべてが拒否されます。
APIリファレンスには、これに加えて、本人確認の審査中を表す pending も値として載っています。ドキュメントは、値が今後増えることがあり、知らない値は restricted として扱うよう求めています。また、古いベータのヘッダー（user-profiles-2026-09-04 以前）を付けたリクエストでは、この2つの項目が応答に含まれず、絞り込みは400エラーになります。
一覧の取得で enforcement_status[]=restricted などを指定すると、措置がかかっている顧客だけを探せます。措置の開始・終了を通知するWebhookもありますが、申し込みが必要なベータです。しかも、10月27日時点のWebhookのドキュメントには、イベントの送信がまだ始まっておらず、登録したエンドポイントには何も届かないと書かれています。それまでは、前回取得した値と比べるよう書かれています。updated_at は必ずしも変わらないためです。なお、Claude Platform on AWSでは、この2つの項目は常に措置なしを示し、Anthropicが措置を理由にリクエストを拒否することもありません。
導入するときの進め方
ここからは編集部の整理です。複数の顧客にClaudeを使った機能を提供している場合は、次の順で検討します。
- 組織を分ける：顧客向けのリクエストと、自社の開発・社内利用が同じ組織にあるなら、まず組織を分けます
- 顧客の登録処理にプロファイルの作成を入れる：作成は1回だけにし、IDを顧客の情報と一緒に保存します。国（
country）には顧客の国を入れ、分からない値は空欄のままにします - APIを呼ぶ共通の部品で、IDを必ず付ける：呼び出しを1か所にまとめておくと、付け忘れを防げます。社内のゲートウェイを使う場合は、そこでヘッダーを付ける設計もできます
- 制限の状態を見る仕組みを作る：Webhookのイベントはまだ届かないため、定期的に一覧を取得し、
restrictedやbannedの顧客を見つけたら、顧客への連絡と、自社のサービス側での利用の停止を判断します
利用ポリシーの最近の改定は、Claudeの利用ポリシー改定 人事AIとチャットボットの確認点で整理しました。社内のAIの呼び出しをまとめるゲートウェイについては社内AIにゲートウェイを1枚挟むかを、APIの呼び出しを観測する方法はClaude APIのOpenTelemetryを参照してください。
確認した範囲
2026年10月24日に、Claude Platformのリリースノートと、ドキュメント「User profiles for end-customer attribution」をplatform.claude.comで直接開いて確認しました（資料調査）。あわせて、編集部の検証環境（Python 3.11.17）で、
anthropic1.17.0と2.0.0がローカルの受信用サーバーへ送るヘッダーと本文を記録しました（実機検証）。公開前の10月27日に、同じ資料と、APIリファレンス、Webhookのドキュメント、Python SDKの変更履歴とPyPIの配布物を確かめ直しました。プロファイルの作成、Anthropicのサーバーでの検証、措置がかかったときの挙動、Webhook、Verification Portal、Bedrock・Google Cloud・Foundry経由の送信は確認していません。
AIを使ったサービスの設計や、顧客ごとの利用管理の作り方は、開発・AI・自動化のご相談からお問い合わせください。
