Claude Admin APIキーを作った人が退職した後の削除と再発行手順

claude.aiのOrganization settingsで作ったAdmin APIキーは、作成者が退職しても止まりません。作成者を組織から削除しても、IdPからデプロビジョニングしても、ロールを下げても、キーは作成時のスコープのまま有効です。退職処理では、メンバーの削除とは別に、その人が作ったキーを削除して作り直す作業が必要になります。

作成者を外してもキーが生き残る理由

Admin APIキーは個人ではなく組織に紐づきます。作成者を組織から外すと、その人自身のアクセスは終わりますが、作ったキーには影響しません。ロールを降格した場合も同じで、各キーは元のスコープのまま有効です。

さらに、claude.aiで作ったキーには有効期限がありません。放っておくと「作った人はもういないのに、メンバー管理やCompliance APIを呼べるキー」が残り続けます。

Consoleのモデル呼び出し用キーは、個人キーとサービスアカウントキーで扱いが違います。個人キーは本人の権限で動くので、組織から外れた時点で止まります。サービスアカウントキーは、サービスアカウントをアーカイブしない限り動き続けます。こちらはメンバー削除後のAPIキーの挙動でも触れています。

退職処理で確認するキーの置き場所

キーは作成した場所の画面から削除します。置き場所は組織の種類で分かれるので、まず自社がどちらを使っているかを確かめます。

Consoleで作るAdminキーは、作成時に有効期限を選べます。期限なしの「Never」も選べますが、組織に最大期限のポリシーがあれば選べません。claude.ai側のキーには期限の選択肢がなく、この違いが退職後に残りやすい差になります。

Consoleのキーが作成者の退職でどうなるかは、Admin keysの一覧で確かめられます。claude.aiのキーと同じ扱いだと決め打ちせず、退職者が作ったキーが一覧に残っていれば、同じ手順で削除します。

削除して作り直す手順

手順は4つです。メンバー側の処理と、キー側の処理を分けて進めます。

順序は「作る、差し替える、消す」です。先に消すと、そのキーに頼っていた連携が止まります。逆に、新しいキーに切り替えた後は、古いキーを残さないことが肝心です。

新しいキーを作るとき、スコープは使う用途に必要な分だけ選びます。たとえばメンバーと招待の読み取りならread:members、メンバーの削除や招待の作成ならwrite:membersです。Compliance APIでチャットなどを読むならread:compliance_user_data、削除するならdelete:compliance_user_dataが要ります。

読み取りと削除の両方を使う運用では、キーを2本に分けます。読み取り用のキーが漏れても、データを削除できないようにするためです。シークレットは表示が1回限りなので、作成時にシークレット管理ツールへ保存します。

メンバーの削除とキーの削除は別作業

退職者をAPIで組織から外す手順は、公式の例にまとまっています。メールアドレスでメンバーを引き、見つかったIDで削除します。

# 1. メールアドレスでメンバーを探す
curl "https://api.anthropic.com/v1/organizations/users?email=departing@example.com" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  -H "anthropic-version: 2023-06-01"
 
# 2. 返ってきた id を指定して削除する
curl -X DELETE "https://api.anthropic.com/v1/organizations/users/{user_id}" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  -H "anthropic-version: 2023-06-01"

この2本のリクエストが終わっても、キーは消えません。削除に使ったキー自身が、退職者の作ったものかもしれません。スクリプトに使うキーの出どころも、一緒に点検の対象です。

SSO環境では、APIで削除できないことがあります。メンバーシップをSCIMプロビジョニングで管理している組織では、APIからの削除は400を返します。この場合は、IdP側でユーザーを外します。IdPで外せば本人のアクセスは終わりますが、先に述べたとおり、作ったキーは残ります。SCIMの同期タイミングはClaude SCIM同期の仕組み、3つの方式の違いはSSO・JIT・SCIMの違いにあります。

owner、membership_admin、primary_ownerのロールを持つメンバーは、APIで変更も削除もできません。管理者ロールだった人の退職は、claude.aiの組織設定で処理します。

SSO連携の組織で、退職処理が400で止まるとき

退職処理のスクリプトが400で止まるのは、IdPが管理している操作をAPIから触ったときです。公式の説明では、次のように分かれます。

読み取り系のリクエストは、どの構成でも通ります。そのため、退職者のメンバー情報を引くところまではスクリプトで進められ、削除だけをIdPで行う分担になります。

ロールの降格をAPIで行っても、退職者が作ったキーは何も変わりません。降格してもキーの権限は下がりません。

退職者のキーがまだ使われているかを見る

削除の前に、そのキーが最近使われているかを確かめたい場合があります。Compliance APIのActivity Feedは、Compliance APIを呼んだ操作をcompliance_api_accessedとして記録します。actor.typeがapi_actorのものについて、actor.api_key_idを見れば、どのキーが呼んだかを特定できます。

Admin APIキーでメンバー、招待、ワークスペース、APIキーを管理した操作は、admin_api_key_actorとして記録され、admin_api_key_idが付きます。公式の説明は組織のadminがAdminキーで管理した操作を指しており、対象はConsoleのAdminキーです。claude.aiのキーを調べるときは、compliance_api_accessedの側で退職者のキーIDを探します。Activity Feedの絞り込み方はCompliance API Activity Feedの使い方にまとめています。

compliance_api_accessedだけに絞って、キーIDで拾うには次のようにします。activity_types[]は繰り返し指定でき、返ってきたJSONのdata配列からjqで絞ります。

curl --fail-with-body -sS -G \
  "https://api.anthropic.com/v1/compliance/activities" \
  --data-urlencode "activity_types[]=compliance_api_accessed" \
  --data-urlencode "limit=100" \
  --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY" \
  --header "anthropic-version: 2023-06-01" \
  | jq '.data[] | select(.actor.type == "api_actor"
      and .actor.api_key_id == "<退職者のキーID>")'

1ページに収まらないときは、レスポンスのhas_moreがtrueの間、last_idをafter_idに渡して古いほうへたどります。出力が空なら、そのキーは取得した範囲で使われていません。

利用がなければ、そのまま削除して問題ありません。利用があれば、連携先が使っているということなので、差し替えを済ませてから削除します。

退職のたびに繰り返さないための運用

棚卸しでは名前が手がかりになります。用途と担当チームを名前に入れ、個人名は入れない運用にしておくと、退職者の作ったキーを探す手間が減ります。

もう一つは、キーの持ち主を個人にしないことです。Compliance Access Keyは、リンクされた全組織のチャットやファイルを読めるので、本番データベースの認証情報と同じ扱いにします。primary ownerについては、Claude Enterprise HIPAA構成の適用前に確認することでも触れています。

Console側で期限を選べるキーは、期限を設ける選択肢があります。期限の通知メールは作成者に届くため、通知先が退職者のままだと見逃されます。期限が近づいたときの連絡先も、作成者の退職時に見直します。

漏洩が疑われるときの無効化は、退職処理とは別の流れです。Claude APIキーの漏洩が疑われるときの無効化手順を参照してください。

まとめ

退職者の後始末は、「メンバーを外す」と「その人が作ったキーを消す」の2つに分かれます。前者はDELETE /v1/organizations/users/{user_id}かIdPで済みますが、後者は画面で行います。claude.aiのキーは期限もないので、削除しない限り残ります。次の退職者が出る前に、現在のKeys一覧に作成者不明のキーがないかを確認しておくと、同じ抜けを避けられます。