結論：人の作業はpersonal、無人処理はservice accountで分ける
Claude APIの認証は、担当者本人として動く検証にはpersonal key、バッチや本番連携にはservice account keyを基本候補とし、対象workspaceと必要権限を最小化します。Anthropicは2026年8月27日、Claude Consoleでpersonal keysとservice account keysを作成できるようにしたと公式releaseで案内しました。従来のworkspace API keysもlegacy optionとして対応が続きますが、新規設計では「誰として動くか」を先に決めると棚卸ししやすくなります。
読者の具体的な困りごとは、開発者の個人キーを共有サーバーへ置いたまま担当変更を迎え、停止影響と利用者を追えなくなることです。読了後には、利用場面ごとにpersonal、service account、workspaceのどれを採用するか判断できます。次の行動は、現在のキー台帳へ主体、workspace、用途、owner、失効条件を追記することです。
公式情報ではpersonal keyは作成者本人、service account keyはservice accountと同じ権限で動き、関連するaccountがorganizationから削除されると動作を停止します。キーは特定workspaceへscopeするか、主体がアクセスできる全workspaceとadmin endpointで使う設定が候補です。これは自動的に全権限を与える意味ではありません。発行画面、role、endpointの組み合わせを検証し、秘密値は一度も記事やticketへ貼り付けません。
3種類を権限・失効・用途・監査で比較する
personal keyは「人に帰属する」ため、短期の開発、個人の検証、本人の操作責任が明確な作業に向きます。退職・異動・organization削除に伴う停止を期待できますが、個人キーをCIへ置くと担当者の権限変更が本番障害へ直結します。共有は禁止し、検証環境でも有効期限、保存先、利用workspaceを記録します。
service account keyは「処理に帰属する」ため、CI、定期バッチ、社内アプリ、監視連携に向きます。人の退職と処理の継続を分離できますが、service accountを過大権限にすると複数処理へ被害が広がります。業務またはアプリ単位でaccountを分け、ownerは必ず人またはteamとして登録します。service accountそのものの削除、key rotation、secret managerの更新を一つの手順にします。
workspace API keyは既存連携との互換性を保つ選択肢です。すぐに全廃する必要はありませんが、誰の責任で発行され、どの処理が使うか曖昧なまま増やさないことが重要です。新しいkeyへ移す場合も、旧keyを先に削除せず、並行稼働、traffic確認、rollback、失効の順で行います。料金はキー種別ではなく、利用model、token、機能、契約条件で決まるため、keyの変更を値下げとして説明しません。
- 主体：人の判断で動くか、無人の処理として動くか。
- 範囲：単一workspaceで足りるか、複数workspaceまたはadmin endpointが必要か。
- 失効：account削除、担当変更、秘密漏えいのどれで止めるか。
- 監査：利用量と変更履歴を一つのownerへ結び付けられるか。
安全に切り替える7手順
- Claude Console、利用SDK、API gatewayにある全キーを台帳化します。
- 各キーについて主体、処理名、workspace、endpoint、保存先を特定します。
- 人の検証、無人処理、既存互換の3区分へ分類します。
- personalまたはservice accountを必要最小roleで用意し、workspace scopeを限定します。
- secret managerへ保存し、application logへ値が出ないことを確認します。
- 旧新キーを短時間だけ並行させ、成功率、workspace ID、usageを照合します。
- rollback期限後に旧キーを失効し、台帳とincident手順を更新します。
切替testでは通常requestだけでなく、権限外workspace、無効endpoint、rate limit、account削除後、secret rotation失敗を確認します。Claude APIのresponseに返るanthropic-workspace-idも利用し、想定したworkspaceへ解決されたかを監視できます。値を業務dataと結び付けすぎず、認証情報そのものはlogへ出しません。
admin endpointを使う処理は通常の生成requestとkeyを共用しません。memberやworkspaceを変更する権限は影響が大きいため、別service account、別secret、承認付きdeploymentへ分けます。利用者のlocal環境へadmin keyを配布せず、申請経路を用意します。緊急停止時にはkeyだけでなく、service account、workspace role、gatewayの全経路を確認します。
公開前・導入前チェックリスト
- 発行主体を記録した
- personとserviceを共用しない
- workspace scopeを限定した
- admin権限を別管理した
- secret managerへ保存した
- source codeへ埋め込まない
- logへ秘密値を出さない
- ownerと代替ownerがいる
- rotation日を決めた
- account削除時をtestした
- 旧keyの失効日がある
- 料金表を別途確認した
- workspace IDを照合した
- incident停止手順がある
HOLD条件は、発行主体が不明、複数人がpersonal keyを共有、admin権限の必要性を説明できない、secretの保存先が平文、旧keyの利用処理を特定できない場合です。キー種別を選ぶだけではdata retention、model availability、rate limit、請求上限は変わりません。契約と料金はAnthropic公式pricing、認証条件は公式文書で公開直前に再確認します。
よくある質問と次の行動
開発者のpersonal keyをCIで使ってもよいですか？
短期test以外ではservice accountへ分けます。担当変更と本番継続を切り離せます。
workspace API keyは直ちに交換が必要ですか？
公式には引き続き対応するlegacy optionです。riskと依存を棚卸しし、段階移行します。
service accountなら安全ですか？
自動的に安全にはなりません。最小権限、scope、保管、rotation、監査が必要です。
一次情報はClaude Platform release notesとAPI keys公式文書です。関連するEnterprise Admin APIの権限管理、個人情報を扱う確認項目、コスト管理も確認してください。Miraigentの無料診断では、現在のキー境界と移行順を60秒で整理します。