Admin APIでWIFを管理する

Admin APIを使用すると、Workload Identity Federationのリソース（サービスアカウント、フェデレーションイシュアー、フェデレーションルール）をプログラムから作成・管理できます。Claude Consoleをクリックして操作する代わりに、フェデレーション設定を「infrastructure as code」（コードとしてのインフラストラクチャ）として保持し、CIからプロビジョニングし、複数の組織にわたって再現するために使用してください。これらのエンドポイントは、Admin APIの他の部分と同じ/v1/organizationsパスプレフィックスを共有します。

前提条件

このページのすべてのリクエストは、org:adminスコープを持つOAuthベアラートークンで認証します。このスコープは、admin、owner、またはprimary ownerロールを持つ組織メンバーにのみ付与され、組織全体へのアクセスを許可します。ワークスペースへのバインディングはすべて無視されます。トークンを取得する方法は2つあり、それぞれ異なる権限を持ちます。自分自身のログインから取得したトークンはユーザーとして動作しますが、フェデレーションされたトークンはサービスアカウントとして動作し、このページのすべての操作を実行できるわけではありません。

インタラクティブ（ターミナル）

専用のプロファイルでant CLIにログインし、org:adminスコープを要求してから（管理者アクセスを参照）、ベアラートークンをエクスポートします。--profile adminでログインすると、org:adminの認証情報が独自のプロファイル名で保存され、同時にそれがCLIのアクティブなプロファイルになります。また、エクスポートした変数はそのシェル内のすべてのSDKおよびCLI呼び出しに適用されます。そのため、管理専用に確保したシェルを使用し、作業が終わったら変数をunsetし、ant profile activate defaultでCLIを元に戻してください。

ant auth login --profile admin --scope "org:admin"
export ANTHROPIC_AUTH_TOKEN=$(ant auth print-credentials --profile admin --access-token)

インタラクティブトークンは有効期間が短いため、リクエストが401を返し始めたら、エクスポートコマンドを再実行してください（トークンは自動的に更新されます）。

SDKとant CLIはANTHROPIC_AUTH_TOKENを自動的に読み取ります。同じシェルではANTHROPIC_API_KEYを未設定のままにしてください。これらのエンドポイントはAPIキーを拒否し、一部のクライアントは両方が設定されている場合にキーを優先するためです。

ワークロード（CIと自動化）

organization_roleがadminであるサービスアカウントをターゲットとする、oauth_scope: org:adminを持つフェデレーションルールを作成します。ルール自体はClaude Consoleで作成する必要があります。ワークロードに組織管理者アクセスを付与することは、人間による意図的な操作であり、自動化が自らブートストラップできるものではありません。次のセクションでは、組織ごとに1回行うこのセットアップについて説明します。

WIFを管理するワークロードをブートストラップする

Consoleで作成したルールが1つあれば、残りのフェデレーション設定をinfrastructure as codeの管理下に置くことができます。信頼できる単一のワークロードにorg:adminスコープを付与し、そのワークロードがこのAPIを通じてフェデレーションイシュアーとすべてのワークスペーススコープのフェデレーションルールを管理できるようにします。

1. 1

   Consoleでorg:adminルールを作成する

   Claude ConsoleでSettings → Workload identityに移動し、Connect workloadを選択して、自動化ワークロード（たとえばインフラストラクチャリポジトリ内のGitHub Actionsワークフロー）用のフェデレーションルールを1つ作成します。Advanced rule optionsで、ルールのOAuthスコープをorg:adminに設定します。するとウィザードは、Admin組織ロールを持つ新しいサービスアカウントを作成します（または、既存のadminサービスアカウントをターゲットとして選択するよう求めます）。

2. 2

   ワークロードのIDトークンを交換する

   SDKのいずれかまたはant CLIを使用するワークロードは、自分自身で交換を実行しません。SDKクライアントを構築するの推論の場合とまったく同じように、フェデレーション環境変数でクライアントをルールに向け、引数なしで構築します。クライアントは最初のリクエスト時にIDトークンを交換し、得られたアクセストークンの有効期限が切れる前にIDトークンを再度読み取って再交換します。

   export ANTHROPIC_FEDERATION_RULE_ID=fdrl_...        # the org:admin rule from step 1
   export ANTHROPIC_ORGANIZATION_ID=00000000-0000-0000-0000-000000000000
   export ANTHROPIC_SERVICE_ACCOUNT_ID=svac_...       # the rule's target service account
   export ANTHROPIC_IDENTITY_TOKEN_FILE=/path/to/jwt  # or ANTHROPIC_IDENTITY_TOKEN
   # ANTHROPIC_WORKSPACE_IDは、ルールがすべてのワークスペースまたは
   # 複数のワークスペースで有効な場合のみ必須です。org:adminエンドポイントはこのバインディングを無視します。
   unset ANTHROPIC_API_KEY ANTHROPIC_AUTH_TOKEN       # both take precedence over federation

   

   ant CLIは同じ変数を読み取るか、--federation-rule、--organization-id、--service-account-id、--identity-token-fileフラグを受け取ります。複数のantコマンドを実行するワークロードでは、フラグや環境変数ではなくフェデレーションプロファイルを使用してください。フラグや変数を使用すると、CLIはプロセスごとにIDトークンを再度交換しますが、jtiクレームを持つIDトークン（GitHub Actionsのトークンが該当します）は1回しか受け付けられないため、2つ目のコマンドは拒否されます。また、ルールがすべてのワークスペースまたは複数のワークスペースで有効になっている場合、交換用のworkspace_idをCLIに渡す唯一の方法もプロファイルです。SDKとは異なり、CLIはANTHROPIC_WORKSPACE_IDや--workspace-idを交換に渡さないためです。すべてのSDKは、同じ設定を明示的なコンストラクタ引数としても受け付けます。言語ごとの例はSDKクライアントを構築するに示されています。完全な一覧と優先順位については、環境変数と認証情報の優先順位を参照してください。

   curlでAPIを呼び出すワークロードは、他のフェデレーションワークロードと同じトークン交換を使用して、JWTを有効期間の短いorg:adminベアラートークンに自分自身で交換し、authorization: Bearerヘッダーで送信します。

3. 3

   APIを通じてイシュアーとワークスペーススコープのルールを管理する

   クライアントを設定したら（curlの場合は、発行されたトークンをANTHROPIC_AUTH_TOKENに設定したら）、ワークロードはこのページのエンドポイントを使用してフェデレーション設定を作成・管理します。

ワークロードが発行したトークンで実行できる操作とできない操作については、権限と制約を参照してください。すでにConnect workloadウィザードでイシュアー、サービスアカウント、またはルールを作成している場合は、再作成するのではなく、以下のエンドポイントで一覧を取得し、infrastructure-as-codeの状態にインポートしてください。

認証

すべてのエンドポイントはhttps://api.anthropic.com/v1/organizations/の下にあります。フェデレーションおよびサービスアカウントのエンドポイントへのすべてのリクエストには、APIバージョンヘッダーとベアラートークンが必要です。

SDKでは、これらのエンドポイントはclient.beta.organization.service_accounts、client.beta.organization.federation.issuers、client.beta.organization.federation.rulesです（CLIではant beta:organization:service-accounts、federation:issuers、federation:rules）。SDKとCLIの例ではデフォルトのクライアントを構築します。このクライアントはANTHROPIC_AUTH_TOKENのベアラートークンを送信するか、自動化されたワークロードではWIFを管理するワークロードをブートストラップするで説明したようにフェデレーション交換を自分自身で実行します。SDKのlistメソッドは必要に応じて後続のページを取得するため、limitはページサイズを設定します。PHPとRubyの例は1ページを読み取ります。

client = anthropic.Anthropic()

service_accounts = client.beta.organization.service_accounts.list()

for service_account in service_accounts:
    print(f"{service_account.id}: {service_account.name}")

Admin APIキーはこれらのエンドポイントでは受け付けられません。Admin APIページのx-api-keyの例はここには適用されません。

サービスアカウント

サービスアカウント（svac_...）は、フェデレーションされたトークンがその身元として動作する非人間のIDです。organization_roleをdeveloperに設定してください。

サービスアカウントを作成します。

client = anthropic.Anthropic()

service_account = client.beta.organization.service_accounts.create(
    name="inference-worker", organization_role="developer"
)

print(f"id: {service_account.id}")
print(f"name: {service_account.name}")

サービスアカウントの一覧を取得します。

client = anthropic.Anthropic()

service_accounts = client.beta.organization.service_accounts.list(limit=20)

for service_account in service_accounts:
    print(f"{service_account.id}: {service_account.name}")

サービスアカウントをアーカイブします。

client = anthropic.Anthropic()

service_account = client.beta.organization.service_accounts.archive(
    "svac_01ABCDEFabcdef0123456789XY"
)

print(f"id: {service_account.id}")
print(f"archived_at: {service_account.archived_at}")

作成エンドポイントは新しいサービスアカウントを返します。

{
  "id": "svac_...",
  "name": "inference-worker",
  "organization_role": "developer",
  "created_at": "...",
  "type": "service_account",
  "...": "..."
}

単一のサービスアカウントを読み取りまたは更新するには、/v1/organizations/service_accounts/{service_account_id}に対してGETとPOSTを使用します。フェデレーションされたトークンがワークスペース内で動作できるようにするには、サービスアカウントがそのワークスペースのメンバーである必要があります。すべてのサービスアカウントは、組織のデフォルトワークスペースに暗黙的なメンバーシップを持っています。他のワークスペースへの明示的なメンバーシップは、/v1/organizations/service_accounts/{service_account_id}/workspacesに対するGET、POST、DELETEで追加します。DELETEは.../workspaces/{workspace_id}を対象とします。

パラメータの詳細とレスポンススキーマの全体については、サービスアカウントAPIリファレンスを参照してください。

フェデレーションイシュアー

フェデレーションイシュアー（fdis_...）は、OIDC IDプロバイダーを組織に登録します。jwksフィールドは、Anthropicがプロバイダーの署名鍵を取得する方法を制御する判別共用体（discriminated union）です。

イシュアーを登録します。この例では、JWKSディスカバリーを使用してGitHub Actionsを登録します。

client = anthropic.Anthropic()

issuer = client.beta.organization.federation.issuers.create(
    name="github-actions",
    issuer_url="https://token.actions.githubusercontent.com",
    jwks={"type": "discovery"},
)

print(f"id: {issuer.id}")
print(f"name: {issuer.name}")
print(f"issuer_url: {issuer.issuer_url}")

イシュアーの一覧を取得します。

client = anthropic.Anthropic()

issuers = client.beta.organization.federation.issuers.list(limit=20)

for issuer in issuers:
    print(f"{issuer.id}: {issuer.name}")

イシュアーをアーカイブします。

client = anthropic.Anthropic()

issuer = client.beta.organization.federation.issuers.archive(
    "fdis_01ABCDEFabcdef0123456789XY"
)

print(f"id: {issuer.id}")
print(f"archived_at: {issuer.archived_at}")

単一のイシュアーを読み取りまたは更新するには、/v1/organizations/federation_issuers/{issuer_id}に対してGETとPOSTを使用します。OAuthの呼び出し元は、oauth_scopeがworkspace:developerまたはworkspace:inference以外であるルールの基盤となっているイシュアーを更新できません。権限と制約を参照してください。

パラメータの詳細とレスポンススキーマの全体については、フェデレーションイシュアーAPIリファレンスを参照してください。

フェデレーションルール

フェデレーションルール（fdrl_...）は、イシュアーをサービスアカウントにバインドします。ルールの一致条件を満たすイシュアーからのJWTは、ルールのターゲットとして動作するトークンを発行できます。作成リクエストのworkspace_idは、作成時にそのワークスペースでルールを有効にします。後から/federation_rules/{rule_id}/workspacesサブリソースを通じてワークスペースを追加できます。作成時にはworkspace_idまたはapplies_to_all_workspaces: trueのいずれかが必須です。

ルールを作成します。この例では、mainブランチからのGitHub Actionsデプロイがサービスアカウントとして動作できるようにします。

client = anthropic.Anthropic()

rule = client.beta.organization.federation.rules.create(
    name="gha-deploy",
    issuer_id="fdis_01ABCDEFabcdef0123456789XY",
    match={
        "subject_prefix": "repo:my-org/my-repo:ref:refs/heads/main",
        "claims": {"repository_owner": "my-org"},
    },
    target={
        "type": "service_account",
        "service_account_id": "svac_01ABCDEFabcdef0123456789XY",
    },
    workspace_id="wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ",
    oauth_scope="workspace:developer",
    token_lifetime_seconds=600,
)

print(f"id: {rule.id}")
print(f"name: {rule.name}")

ルールの一覧を取得します。必要に応じてイシュアーでフィルタリングできます。

client = anthropic.Anthropic()

rules = client.beta.organization.federation.rules.list(
    issuer_id="fdis_01ABCDEFabcdef0123456789XY"
)

for rule in rules:
    print(f"{rule.id}: {rule.name}")

ルールをアーカイブします。

client = anthropic.Anthropic()

rule = client.beta.organization.federation.rules.archive(
    "fdrl_01ABCDEFabcdef0123456789XY"
)

print(f"id: {rule.id}")
print(f"archived_at: {rule.archived_at}")

一覧エンドポイントは、ルールの1ページ分と次のページのカーソルを返します。

{
  "data": [{ "id": "fdrl_...", "name": "gha-deploy", "...": "..." }],
  "next_page": "..."
}

単一のルールを読み取りまたは更新するには、/v1/organizations/federation_rules/{rule_id}に対してGETとPOSTを使用します。ルールがトークンを発行できるワークスペースを管理するには、/v1/organizations/federation_rules/{rule_id}/workspacesに対してGETとPOSTを、/v1/organizations/federation_rules/{rule_id}/workspaces/{workspace_id}に対してDELETEを使用します。

パラメータの詳細とレスポンススキーマの全体については、フェデレーションルールAPIリファレンスを参照してください。

権限と制約

oauth_scope: org:adminを持つルールは、organization_roleがadminであるサービスアカウントをターゲットにする必要があります。リソース名は^[a-z0-9-]+$に一致し、1〜255文字で、リソースタイプごとに組織内で一意である必要があります。フィールドレベルの制約の全体については、バリデーションルールを参照してください。

ページネーションとアーカイブ

サービスアカウント、フェデレーションイシュアー、フェデレーションルールの一覧エンドポイントは、limit（1〜100、デフォルト20）と、前のレスポンスから取得したpageカーソルを受け付けます。レスポンスのnext_pageの値を、次のリクエストのpageクエリパラメータとして渡してください。ルールのワークスペースサブリソースの一覧は、ページネーションなしで全件を返します。アーカイブされたリソースはデフォルトで一覧から非表示になります。含めるにはinclude_archived=trueを渡してください。

アーカイブはソフトデリートであり、冪等です。すでにアーカイブ済みのリソースをアーカイブしても成功します。有効なフェデレーションルールがまだ参照している間は、イシュアーまたはサービスアカウントのアーカイブは400を返します。先にルールをアーカイブしてください。

関連項目

• Workload Identity Federation：概念とConsoleでのセットアップ手順
• WIFリファレンス：環境変数、バリデーションルール、OAuthスコープ、エラーコード
• Admin API：組織管理機能のその他の部分
• Admin APIリファレンス：すべてのAdmin APIエンドポイントについて生成されたリクエストおよびレスポンススキーマ