エンドカスタマーへの帰属のためのユーザープロファイル

「user profile」（ユーザープロファイル、以下「プロファイル」）は、各APIリクエストがどのエンドカスタマーのためのものかをAnthropicに伝えます。これにより、保留やブロックなどの「safety enforcement action」（安全上の措置）を、組織全体ではなく1つのエンドカスタマーに適用できます。その場合、残りのトラフィックは影響を受けません。

プラットフォームやゲートウェイを運営している場合、またはAPIアクセスを再販している場合、エンドカスタマーのために送信するリクエストは、お客様の組織のリクエストとして届きます。Anthropicは、APIトラフィックに対して自動化された安全分類器を実行しています。リクエストにプロファイルがない場合、1つのエンドカスタマーが組織全体に適用される措置を引き起こす可能性があります。

各エンドカスタマーをPOST /v1/user_profilesで一度登録し、返されるuprof_ IDを保存します。その後、そのエンドカスタマーに代わって行うすべてのリクエストで、そのIDをanthropic-user-profile-idヘッダーで送信します。

プロファイルは課金対象ではなく、料金にも影響しません。

プロファイルを作成する対象を決める

プロファイルが何を表すかは、Claudeをどのように販売しているかによって異なります。つまり、お客様の製品を使用する個人か、お客様がAPIアクセスを再販する相手の企業かです。この2つのケースで、ほとんどのプラットフォームをカバーできます。プロファイルのaccess_typeフィールドは、どちらに該当するかを示します。

プロファイルの内容とAnthropicによる使用方法

プロファイルには、エンドカスタマーについてお客様が送信した情報と、Anthropicが設定するプログラムステータスのみが含まれます。会話の内容は含まれません。Anthropicは、お客様が送信した詳細情報を、リクエストの帰属、不正使用の監視、利用ポリシーの執行のため、および信頼済みアクセスプログラムへの申請とアクセスを可能にするために使用します。Anthropicはこれらの詳細情報を検証しません。

Anthropicはプライバシーポリシーに従ってプロファイルを処理します。

始める前に

プロファイルは、次のいずれかで作成および管理します。

• Claude API上の組織。
• Claude Platform on AWS上の組織。呼び出し元のプリンシパルにはユーザープロファイルのIAMアクションが必要です。
• Azureでホストされているものではなく、AnthropicでホストされているMicrosoft Foundryデプロイメント。Claude APIまたはClaude Platform on AWS上の組織は必要ありません。推論に使用するのと同じベースURLと認証で、Foundryエンドポイントを使用してください。

Amazon BedrockとGoogle Cloudには/v1/user_profilesエンドポイントがありません。推論をそこで実行している場合は、Claude APIまたはClaude Platform on AWS上の組織でプロファイルを作成してください。Amazon Bedrockでは、プロファイルはClaude in Amazon Bedrockでのみ機能します。Amazon BedrockとGoogle Cloudでリクエストを帰属させるを参照してください。

エンドカスタマーのために送信するトラフィックは1つの組織に、お客様自身の内部使用は別の組織に分けてください。プロファイルはワークスペースではなく組織に属するため、1つの組織内でワークスペースを分けるだけでは不十分です。ユーザープロファイルが必要なのは、エンドカスタマーのトラフィック用の組織だけです。Claude API上で別の組織を作成するには、ClaudeヘルプセンターのCreating and managing Workspaces in the Claude Consoleの「How to create a new organization」セクションを参照してください。

例では、APIキーを使用してClaude APIを呼び出しています。Admin APIキーは必要ありません。Claude Platform on AWSでは、そのベースURLと認証を使用してください。

各エンドカスタマーのプロファイルを作成する

Claudeにトラフィックを送信するエンドカスタマーごとに、プロファイルを1つ作成します。顧客のオンボーディングフローで一度だけ作成してください。POST /v1/user_profilesは冪等ではないため、reference_idが既存のものと一致する場合でも、呼び出すたびに新しいプロファイルが作成されます。プロファイルのない既存のエンドカスタマーがいる場合は、このセクションの後半にある既存の顧客ベースの登録に関するガイダンスを参照してください。

次の例では、ゲートウェイを通じてAPIアクセスを購入する企業を登録するため、access_typeをpassthroughに設定しています。applicationプロファイルの場合は、access_typeを省略し、nameとexternal_user_detailsには企業ではなく1人のエンドユーザーについて記述します。2つのアクセスタイプの比較については、プロファイルを作成する対象を決めるを参照してください。

client = anthropic.Anthropic()

profile = client.user_profiles.create(
    name="Acme Analytics, Inc.",
    access_type="passthrough",
    external_user_details={"reference_id": "cust-8f2a1c", "country": "US"},
)

print(profile.id)

レスポンスは新しいプロファイルです。

{
  "type": "user_profile",
  "id": "uprof_011CZkZCu8hGbp5mYRQgUmz9",
  "name": "Acme Analytics, Inc.",
  "access_type": "passthrough",
  "external_user_details": {
    "reference_id": "cust-8f2a1c",
    "onboarded_at": null,
    "account_status": null,
    "entity_type": null,
    "country": "US",
    "name_hash": null,
    "email_hash": null
  },
  "metadata": {},
  "programs": {
    "cyber": null,
    "efs": null
  },
  "created_at": "2026-03-15T10:00:00Z",
  "updated_at": "2026-03-15T10:00:00Z"
}

idを顧客レコードに保存し、サービスインスタンスが独自にプロファイルを作成するのではなく、そこから読み取るようにしてください。プロファイルの取得、更新、削除はそのidで行います。programsフィールドは読み取り専用で、帰属には使用されません。このフィールドには、Anthropicが運営する各プログラムにおけるエンドカスタマーのステータスが格納されます。値の意味については、プロファイルに適用されるプログラムを参照してください。

組織内のプロファイル数に上限はありませんが、プロファイルの作成にはレート制限があります。既存の顧客ベースを一括で登録する前に、Anthropicのアカウントチームにお問い合わせください。

エンドカスタマーについてAnthropicに伝える内容

すべてのフィールドは任意です。name、metadata、およびexternal_user_details内の次のフィールドを送信できます：entity_type、country、reference_id、onboarded_at、account_status、name_hash、email_hash。各フィールドの型、形式、長さの制限については、プロファイルの作成リファレンスで説明しています。

フィールドを設定する際は、次のルールに従ってください。

• 不明な値： 値がわからない場合は、プレースホルダーを送信するのではなく省略してください。external_user_details内の値は後で置き換えることができますが、クリアすることはできません。
• 企業名： passthroughプロファイルの場合、わかっていれば企業の正式名称をnameで送信してください。
• 国： countryには、お客様の国ではなく、エンドカスタマーの国を送信してください。
• 独自のID： reference_idには、エンドカスタマーに対するお客様独自の安定した識別子を送信してください。一意である必要はありません。
• 共有できない名前とメールアドレス： nameを省略し、代わりにexternal_user_details.name_hashを送信してください。メールアドレスについては、external_user_details.email_hashを送信してください。プロファイルにはアドレス自体のフィールドはありません。
• ハッシュ： ハッシュは、お客様が選択した関数を使用してご自身で計算してください。ハッシュにより、どのプロファイルが名前やメールアドレスを共有しているかがAnthropicにわかります。同じ方法で計算された値のみが一致するため、すべてのプロファイルで同じ関数と、同じ大文字小文字および空白の正規化を使用してください。

各リクエストを帰属させる

エンドカスタマーに代わって行うすべてのリクエストで、プロファイルIDをanthropic-user-profile-idヘッダーで送信してください。SDKとCLIには、このヘッダーを自動的に送信する引数があります：user_profile_id。

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
    user_profile_id="uprof_011CZkZCu8hGbp5mYRQgUmz9",
)

print(message)

このヘッダーは、トークンカウント、Message Batches、およびOpenAI SDK互換のリクエストでも同じように機能します。バッチでは、バッチ内のすべてのリクエストに適用されます。

Claude API、Claude Platform on AWS、およびAnthropicでホストされているMicrosoft Foundryデプロイメントは、すべてのリクエストでIDを確認します。IDの形式が不正な場合、またはリクエストを送信する組織に属していない場合、APIは400 invalid_request_errorを返します。デフォルトでは、これらのプラットフォームは、プロファイルを作成した組織からのリクエストでのみプロファイルIDを受け入れます。つまり、複数の組織（たとえばClaude API上の組織とClaude Platform on AWS上の組織）の下でトラフィックを送信する場合、プロファイルを作成していない組織からのリクエストには同じ400が返されます。

Message Batchesは例外です。バッチの作成時には、IDの形式のみが確認されます。形式が正しいIDがバッチを送信する組織に属していない場合でも、バッチは作成されますが、その中の各リクエストは同じinvalid_request_errorを含むerrored結果で失敗します。

Amazon BedrockとGoogle Cloudでリクエストを帰属させる

どちらのアクセスタイプのプロファイルIDも、Claude in Amazon BedrockおよびGoogle Cloudで機能します。InvokeModelまたはConverseで呼び出す以前のAmazon Bedrock統合では機能しません。Anthropic組織の認証情報は、プロファイルの作成と管理にのみ使用します。推論には引き続き既存のAWSまたはGoogle Cloudの認証情報を使用します。

Claude in Amazon Bedrockでは、IDをリクエストボディのトップレベルに配置します。

{
  "model": "anthropic.claude-opus-5-5",
  "max_tokens": 1024,
  "user_profile_id": "uprof_011CZkZCu8hGbp5mYRQgUmz9",
  "messages": [{ "role": "user", "content": "Hello, Claude" }]
}

Claude in Amazon Bedrockにリクエストを送信する各AWSアカウント、およびGoogle Cloudでリクエストを送信する各Google Cloudプロジェクトを、プロファイルを作成するAnthropic組織にリンクしてください。

1. その組織の管理者またはオーナーが、portal.anthropic.comのVerification PortalのLinked accountsでリンクを開始します。
2. AWSアカウントまたはGoogle CloudプロジェクトでIAMを管理できる担当者が、ポータルが提供するコマンドを実行します。
3. 管理者またはオーナーがポータルで検証を完了します。

プロファイルに適用されるプログラムは、アカウントがリンクされ、ポータルでLinkedと表示された後にのみ、そのアカウントのリクエストに適用されます。エンドカスタマーがプロファイルを自身の組織にリンクした後は、その組織が承認されているプログラムもこれらのプログラムに含まれます。

Claude in Amazon BedrockとGoogle Cloudは、IDの形式を確認しますが、プロファイルの照会は行いません。形式が不正なIDは400で拒否されます。形式が正しいIDはすべて受け入れられるため、成功したレスポンスはIDがプロファイルと一致することを保証するものではありません。IDのないリクエストは帰属されずに処理され、それが措置を引き起こした場合、その措置は組織全体に適用されます。

企業内の個々のユーザーを識別する

passthroughプロファイルは、リクエストを行う個人ではなく企業を識別します。リクエストが識別可能な1人の個人からのものである場合は、Messagesリクエストのmetadata.user_idフィールドでその個人の識別子も送信してください。これはリクエスト自体のmetadataオブジェクトであり、プロファイルのmetadataフィールドではありません。この識別子は任意であり、Anthropicが1人の個人による不正使用を検出するのに役立ちます。

プロファイルを最新の状態に保つ

エンドカスタマーの詳細情報やアカウントステータスが変更された場合はプロファイルを更新し、アカウントを閉鎖した場合やデータの消去を求められた場合はプロファイルを削除してください。

プロファイルを更新する

POST /v1/user_profiles/{id}は、送信したフィールドのみを変更します。たとえば、企業がブランド名を変更した場合や、アカウントを停止した場合に使用します。

• nameとaccess_typeは、保存されている値を置き換えます。
• external_user_detailsで送信した各フィールドは、保存されている値を置き換えます。値をクリアすることはできません。APIはnullを400で拒否します。
• metadataはキーごとにマージされます。送信したキーは保存されている値を上書きし、空の文字列はキーを削除し、省略したキーはそのまま残ります。

次の例では、アカウントを停止済みとしてマークし、trial_cohortメタデータキーを削除します。

client = anthropic.Anthropic()

profile = client.user_profiles.update(
    "uprof_011CZkZCu8hGbp5mYRQgUmz9",
    external_user_details={"account_status": "suspended"},
    metadata={"trial_cohort": ""},
)

print(profile)

プロファイルを削除する

DELETE /v1/user_profiles/{id}は、プロファイルと、そのプロファイルについてお客様が提供したすべての情報（name、external_user_details、metadataを含む）を完全に削除します。そのプロファイルIDについてAnthropicが保持している信頼と安全に関する記録は削除されません。

エンドカスタマーがアカウントを閉鎖した場合、またはデータの消去を求められた場合は、プロファイルを削除してください。プロファイルを削除する前に、そのエンドカスタマーのリクエストでそのIDを送信するのを停止してください。消去リクエストの後もエンドカスタマーが引き続きお客様のサービスを利用する場合は、新しいプロファイルを作成してそのIDに切り替えてから、古いプロファイルを削除してください。

client = anthropic.Anthropic()

deleted = client.user_profiles.delete("uprof_011CZkZCu8hGbp5mYRQgUmz9")

print(deleted.id)

レスポンスは、"type": "user_profile_deleted"とともにIDを返します。削除でサーバーエラーが返された場合は、再試行してください。再試行で404が返された場合は、最初の削除が完了していることを意味します。

削除後、プロファイルエンドポイントはそのIDに対して404を返します。最大約10分間は、削除されたIDを含む推論リクエストが引き続き成功する場合があります。その後、すべてのリクエストでIDを確認するプラットフォームは、そのリクエストを400で拒否します。Claude in Amazon BedrockとGoogle Cloudはプロファイルを照会しないため、引き続きそのリクエストを受け入れます。

次のステップ

APIリファレンスには、各エンドポイントのフィールド、型、制限が記載されています：プロファイルの作成、プロファイルの取得、プロファイルの更新、プロファイルの一覧表示。

エンドカスタマーがお客様のプラットフォームを通じてClaudeを使用する際に、そのエンドカスタマーのプログラム承認を適用する必要がある場合は、エンドカスタマーにVerification Portalへのリンクを送信するを参照してください。