Admin APIでWIFを管理する

Admin APIを使用すると、Workload Identity Federationのリソース、つまり「service account」（サービスアカウント）、「federation issuer」（フェデレーション発行者）、「federation rule」（フェデレーションルール）をプログラムで作成および管理できます。これを使用して、フェデレーション設定を「infrastructure as code」（コードとしてのインフラストラクチャ）で管理し、CIからプロビジョニングし、Claude Consoleでクリック操作を繰り返す代わりに複数の組織間で再現できます。これらのエンドポイントは、Admin APIの他のエンドポイントと同じ/v1/organizationsパスプレフィックスを共有しています。

前提条件

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

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

ant CLIで専用のプロファイルを使用してログインし、org:adminスコープをリクエストします（管理者アクセスを参照）。その後、ベアラートークンをエクスポートします。--profile adminでログインすると、org:adminの認証情報が独自のプロファイル名で保存され、同時にそれがCLIのアクティブなプロファイルになります。また、エクスポートした変数はそのシェル内のすべてのSDKおよびCLI呼び出しに適用されます。そのため、管理作業専用のシェルを使用し、作業が終わったら変数の設定を解除し、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でWorkload identityページ（platform.claude.com/settings/workload-identity-federation）に移動し、Connect workloadを選択して、自動化ワークロード（たとえば、インフラストラクチャリポジトリ内のGitHub Actionsワークフロー）用のフェデレーションルールを1つ作成します。Advanced rule optionsで、ルールのOAuthスコープをorg: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.organization.service_accounts、client.organization.federation.issuers、およびclient.organization.federation.rulesです（CLIではant 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.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.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.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.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がプロバイダーの署名鍵を取得する方法を制御する判別共用体です。

発行者を登録します。この例では、JWKSディスカバリーを使用してGitHub Actionsを登録します。

client = anthropic.Anthropic()

issuer = client.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.organization.federation.issuers.list(limit=20)

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

発行者をアーカイブします。

client = anthropic.Anthropic()

issuer = client.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.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.organization.federation.rules.list(
    issuer_id="fdis_01ABCDEFabcdef0123456789XY"
)

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

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

client = anthropic.Anthropic()

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

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

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

{
  "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リファレンス：サービスアカウントおよびフェデレーションエンドポイントの生成されたリクエストおよびレスポンススキーマ