組織のメンバー追加、ワークスペースの新設、失効間近のAPIキーの棚卸し——これまでは Claude Console の画面操作か、curl を叩くしかありませんでした。2026年8月26日、Anthropic は Admin API を ant CLI と主要7言語の SDK に正式に追加し^[1]、組織管理をアプリケーションコードやCI/CDパイプラインに組み込めるようにしました。本記事では公式ドキュメントを一次情報として、今回のアップデートの中身から実務での使い方までを14章で解説します。

• 0言語
  Python/TS/C#/Go/Java/PHP/Rubyが同じ書き方
• 0コール
  ワークスペース作成に必要な呼び出し数
• 0日
  組織招待が自動失効するまでの固定日数

user@sinyblog:~/article ❯ 01_digest.md90秒ダイジェスト：今回変わった3点

忙しい人向けに、確定情報だけ先に並べます。Anthropic は Claude Platform リリースノートの2026年8月26日付エントリで、Admin API を ant CLI と7言語 SDK に追加したと発表しました^[1]。

1. ant CLIとSDK全7言語が同じAdmin APIを叩けるようになった。Python・TypeScript・C#・Go・Java・PHP・Rubyの各SDKは client.beta.organization 配下に、ant CLIは ant beta:organization 配下に生えている。書き方の思想は共通。
2. 対象は組織情報・メンバー・招待・ワークスペース・APIキー・レート制限・サービスアカウント/WIF連携・暗号鍵管理まで。これまでcurl専用だった操作の大半が型付きコードで書けるようになった。
3. ただし全部ではない。使用量・コストレポートと、Claude Enterprise（claude.ai）のユーザー管理・分析エンドポイントは、引き続きcurl限定のまま残っている^[1]。

user@sinyblog:~/article ❯ 02_release_note.md何が発表されたか（公式リリースノート原文）

まずは一次情報そのものを見ておきます。Claude Platform リリースノートの該当エントリの原文（英語）と、その要旨です。

“The Admin API is now available in the ant CLI and the Python, TypeScript, C#, Go, Java, PHP, and Ruby SDKs under client.beta.organization. They cover organization info, members, invites, workspaces and workspace members, API keys, rate limits, service accounts, workload identity federation issuers and rules, and customer-managed encryption keys. Usage and cost reports and the Claude Enterprise user-management and analytics endpoints remain curl-only. The CLI and SDKs read an Admin API key from ANTHROPIC_API_KEY or an org:admin OAuth token from ANTHROPIC_AUTH_TOKEN.”

Claude Platform release notes, August 26, 2026^[1]

日本語で要約すると次の通りです。Admin API が ant CLI と7言語SDKの client.beta.organization 配下に追加され、組織情報・メンバー・招待・ワークスペース（とそのメンバー）・APIキー・レート制限・サービスアカウント・ワークロードアイデンティティ連携（WIF）の発行者/ルール・顧客管理鍵（CMEK）までをカバーする。一方で使用量/コストレポートと、Claude Enterprise 固有のユーザー管理/分析系エンドポイントは引き続き curl 限定のまま。認証情報は環境変数 ANTHROPIC_API_KEY（Admin APIキー）か ANTHROPIC_AUTH_TOKEN（org:admin スコープのOAuthトークン）から読み込まれます。

user@sinyblog:~/article ❯ 03_what_is.mdAdmin APIとは何か・何を管理できるか

Admin API は、組織のメンバー・ワークスペース・招待・APIキーなどを、Claude Console の画面操作の代わりにプログラムから管理するためのAPIです^[2]。個人アカウントでは使えず、組織を作成していることが前提になります。

公式ドキュメントは主な用途として、オンボーディング/オフボーディングの自動化、ワークスペースアクセスの管理、APIキーの監査の3つを挙げています^[2]。いずれも「毎月Consoleを手でポチポチ確認する」タイプの定型業務で、スクリプト化の効果が出やすい領域です。

user@sinyblog:~/article ❯ 04_roles.md組織のロールと権限

Admin APIで何ができるかは、呼び出す側のメンバーが持つ組織ロールに依存します。公式ドキュメントが定義する5段階です^[2]。

組織のオーナー（owner）とプライマリーオーナー（primary owner）は admin の全権限に加えて admin 自身の管理も行えます。Admin API キーを発行できるのは admin ロールのメンバーのみ、org:admin スコープのOAuthトークンを取得できるのは admin・owner・primary owner の3ロールのみという線引きは、この章の権限表がそのまま反映されています^[2]。

user@sinyblog:~/article ❯ 05_auth.md認証を選ぶ：Admin APIキー vs OAuth

Admin APIは2種類の資格情報のどちらかで叩けます^[2]。用途に応じて選び分けます。

サービスアカウント・連携発行者（federation issuer）・連携ルール（federation rule）の3エンドポイントだけは、org:admin OAuthトークンでしか呼べません^[2]。ワークロードアイデンティティ連携（WIF）の設定を触るとき以外は、基本的にAdmin APIキーで事足ります。

user@sinyblog:~/article ❯ 06_ant_cli.mdant CLIから叩く

ターミナルからさっと確認したいだけなら、ant CLIが最短です。org:admin スコープで管理用プロファイルにログインし、発行されたトークンをエクスポートします^[5]。

# 管理用プロファイルでログイン（org:admin スコープ）
ant auth login --profile admin --scope "org:admin"

# 発行されたベアラートークンをエクスポート
export ANTHROPIC_AUTH_TOKEN=$(ant auth print-credentials --profile admin --access-token)

# 組織情報を取得
ant beta:organization retrieve

# ワークスペースを作成
ant beta:organization:workspaces create --name "Production"

# アクティブなAPIキーを確認
ant beta:organization:api-keys list --status active --limit 50

# 作業が終わったらデフォルトプロファイルに戻す
ant profile activate default

インタラクティブログインで発行されるトークンは短命です。リクエストが401を返すようになったら、export の行を再実行してトークンを更新します^[2]。CIなど非対話環境では、ログインの代わりにワークロードアイデンティティ連携でトークンを発行する方式が案内されています。

user@sinyblog:~/article ❯ 07_sdk_parity.md7言語SDKが同じ書き方で動く

今回のアップデートの実務的な価値は、7言語のSDKが同じ設計思想で client.beta.organization を公開している点です^[2]。メンバー一覧を例に、Python・TypeScript・Go を並べてみます。

client = anthropic.Anthropic()  # ANTHROPIC_API_KEY に Admin API キーを設定

users = client.beta.organization.users.list(limit=10)

# limitはページサイズ。イテレータが必要な分だけ自動でページングする
for user in users:
    print(f"{user.id}: {user.email} ({user.role})")

const client = new Anthropic();

const users = await client.beta.organization.users.list({ limit: 10 });

for await (const user of users) {
  console.log(`${user.id}: ${user.email} (${user.role})`);
}

client := anthropic.NewClient()

users := client.Beta.Organization.Users.ListAutoPaging(context.Background(),
    anthropic.BetaOrganizationUserListParams{Limit: anthropic.Int(10)})

for users.Next() {
    user := users.Current()
    fmt.Printf("%s: %s (%s)\n", user.ID, user.Email, user.Role)
}

Python・TypeScript・C#・Go・Javaの一覧系メソッドは、必要なだけ自動でページを取りに行くイテレータを返すため limit は「1回あたりの取得件数」であって「取得総数の上限」ではありません。一方でPHP・Ruby・curlの例は1ページだけを返す作りになっているので、全件を回すなら自前でページングする必要があります^[2]。

user@sinyblog:~/article ❯ 08_workspace.mdワークスペースを1コールで作る

環境やチームごとにAPIキーを分離したいとき、これまではConsole画面で「Settings > Workspaces > Create workspace」と辿って作成していました^[3]。Admin APIならワークスペース作成は文字通り1コールです。

client = anthropic.Anthropic()

workspace = client.beta.organization.workspaces.create(name="Production")

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

組織が持てるワークスペースは既定で最大100（アーカイブ済みは数えない）。開発・ステージング・本番のように環境ごとにワークスペースを分け、それぞれにレート制限や支出上限を設定するのが公式が挙げる典型パターンです^[3]。ただしワークスペース自体の作成・アーカイブと組織メンバーの管理は、組織レベル操作としてAdmin APIキーが必須。ワークスペースAPIキーでは行えません。

user@sinyblog:~/article ❯ 09_expiring_keys.md実践1：失効間近のAPIキーを自動抽出する

APIキーのレスポンスには expires_at（有効期限なしなら null）が必ず含まれます^[2]。今回SDKに追加されたイテレータと組み合わせれば、「今週失効するキー」の抽出はページングを気にせず数行で書けます。

import anthropic
from datetime import datetime, timedelta, timezone

client = anthropic.Anthropic()
soon = datetime.now(timezone.utc) + timedelta(days=7)

expiring = [
    key
    for key in client.beta.organization.api_keys.list(status="active")
    if key.expires_at and key.expires_at <= soon
]

for key in expiring:
    print(f"{key.name}: {key.expires_at.isoformat()} ({key.workspace_id or 'Default'})")

client.beta.organization.api_keys.list() はイテレータなので、for を回すだけで必要な分だけ自動でページを取得します。取得件数が多い組織でも「今週の棚卸し対象を洗い出す」処理を毎朝定期実行に載せるだけで済みます。これは公式ドキュメントが Best practices に挙げる「APIキーの使用状況を監視し、expires_at を監査し、定期的にローテーションする」^[2] をそのままコード化した形です。

user@sinyblog:~/article ❯ 10_offboarding.md実践2：退職者対応を自動化する（と落とし穴）

退職・異動時のオフボーディングも、公式が挙げる代表ユースケースの一つです^[2]。まず組織からメンバーを削除します。

client = anthropic.Anthropic()

removed_user = client.beta.organization.users.remove("user_01XyDMpzjS89pFZXqSFUBDr6")
print(f"removed: {removed_user.id}")

# API キーは組織/ワークスペース単位。退職者本人のキーを名前などで特定してから無効化する
api_key = client.beta.organization.api_keys.update(
    "apikey_01Rj2N8SVvo6BePZj99NhmiT",
    status="inactive",
)
print(f"{api_key.name}: {api_key.status}")

つまり退職者対応の完全自動化は「①組織メンバー削除 → ②Claude Codeワークスペースの個人キーは自動失効 → ③それ以外のワークスペースキーは棚卸しリストと突き合わせて個別に無効化」という3段構えになります。①だけで終わらせると通常キーが生き残る点に注意してください。

user@sinyblog:~/article ❯ 11_rate_limits.md組織のレート制限をコードで読む

「今このモデルのRPM上限はいくつか」を毎回Consoleで見に行く代わりに、Rate Limits APIで読み取れます^[4]。ant CLIなら1行です。

ant beta:organization:rate-limits list --model claude-opus-5

レスポンスはモデル群ごとの上限をまとめた形で返ります。公式ドキュメント掲載の例です。

{
  "group_type": "model_group",
  "models": ["claude-opus-5"],
  "limits": [
    { "type": "requests_per_minute", "value": 4000 },
    { "type": "input_tokens_per_minute", "value": 10000000 },
    { "type": "output_tokens_per_minute", "value": 800000 }
  ]
}

ワークスペース側のエンドポイントは「組織値からの上書き分」だけを返す設計です。あるグループがレスポンスに出てこなければ、そのワークスペースは組織全体の制限をそのまま継承しているという意味になります^[4]。用途としては、自社ゲートウェイの起動時に上限を読み込んでハードコードを排除する、Usage and Cost APIの実績値と突き合わせて閾値アラートを飛ばす、といった使い方が案内されています。ただしこのAPIは読み取り専用。上限の変更は引き続きConsoleのRate limitsタブから行います^[4]。

user@sinyblog:~/article ❯ 12_enterprise.mdClaude Enterprise固有の機能

Claude Enterprise（claude.ai）組織は、Admin APIの呼び方が少し異なります。claude.ai側で発行するスコープ付きキー（sk-ant-api01-...）を使い、このページで扱う内容のうちメンバー/招待エンドポイントだけが対象になります^[2]。

代わりにEnterprise限定の機能が開きます。グループとカスタムロールの読み取り、そして支出上限（Spend Limits API）です^[2]。キーは read:members / write:members / read:rbac_groups / write:rbac_groups / read:spend_limits / write:spend_limits などのスコープを組み合わせて発行し、必要な権限だけを与える設計です^[6]。

user@sinyblog:~/article ❯ 13_limits.mdできないこと・注意点（FAQ整理）

公式FAQをもとに、Admin APIで「できると誤解しやすいができないこと」を整理します^[2][3]。

公式が挙げるBest practicesも、そのまま運用チェックリストとして使えます^[2]。

1. ワークスペース名・APIキー名は用途がわかる名前にする
2. 失敗した操作のエラーハンドリングを必ず入れる
3. メンバーのロールと権限を定期的に監査する
4. 使われていないワークスペースと失効済み招待を掃除する
5. APIキーの使用状況を監視し、expires_atを監査し、定期的にローテーションする

user@sinyblog:~/article ❯ 99_summary.mdまとめ

今回のアップデートは、新機能というより「組織管理という地味な運用領域が、他のAPI操作と同じ開発体験に揃った」ことに価値があります。curlで我流のラッパーを書いていたチームほど、恩恵は大きいはずです。

1. ant CLIと7言語SDKがclient.beta.organizationで統一。メンバー・ワークスペース・APIキー・レート制限などを型付きコードで操作できる。
2. 認証は用途で使い分ける。日常はAdmin APIキー、サービスアカウント/WIF連携を触るときだけorg:adminのOAuthトークン。管理用の資格情報は専用シェルに隔離する。
3. 「できない」を先に把握しておく。新規キー発行はConsole限定、ユーザー削除でキーは自動失効しない（Claude Codeワークスペースの個人キーを除く）、レート制限はAPIでは読み取り専用。

まず着手するなら、失効間近のAPIキー抽出（ch09）のような読み取り専用スクリプトから始めるのが安全です。慣れてきたらオンボーディング/オフボーディングの自動化に広げる、という順番がおすすめです。