退職した開発者が作ったAPIキーが、本番の業務自動化でそのまま使われている。誰のキーか分からず、止めてよいかも判断できない。中小企業のClaude API運用でよく起きる状況です。
キーの作り方を決めておけば、人が抜けたときに自動で止まり、漏えいしても被害の期間を限定できます。本記事では、公式ドキュメントに沿ってキーの種類、有効期限、漏えい時の初動を整理します。キー保管の一般論はシークレット管理とローテーションも参照してください。
Claude APIキーにはどんな種類があるか
Claude APIキーは、個人キー・サービスアカウントキー・ワークスペースキー（レガシー）の3種類です。新規は前2者が推奨されています。
公式ドキュメントによると、作成時にキーの種類を選び、種類ごとに「誰として動くか」と「いつ止まるか」が決まります。
| 種類 | 動作主体 | 止まるタイミング |
|---|---|---|
| 個人キー | 作成した本人 | 本人が組織から外れたとき（アーカイブ） |
| サービスアカウントキー | サービスアカウント | サービスアカウントがアーカイブされたとき |
| ワークスペースキー（レガシー） | 誰でもない（ワークスペース所属） | 期限切れ、無効化・削除、ワークスペースのアーカイブ |
個人キーとサービスアカウントキーは、組織が管理するIDに紐づく「アイデンティティ連動」のキーです。IDが組織から外れればキーも止まるため、人や業務より長く生き残る鍵が生まれません。一方、ワークスペースキーは作成者が退職しても動き続けます。公式は新規連携にアイデンティティ連動キーを優先するよう案内しています。
個人キーとサービスアカウントキーはどう使い分けるか
自分の開発や試作には個人キー、CIや本番など共有・無人の処理にはサービスアカウントキーを使います。
共有された個人キーは「一人として動く」ため、その人が退職すると業務も止まります。共有・自動化の用途は、組織の管理者がサービスアカウントを作成し、必要なワークスペースに追加したうえで、そのアカウントに紐づくキーを発行します。
キーは可能な限りワークスペース単位に絞ります。ワークスペースを限定したキーはリクエストでワークスペースIDの指定が不要になります。限定しないキーは anthropic-workspace-id ヘッダーが必須で、省略すると400エラーになります。
既存のワークスペースキーからの移行手順は、公式が5段階で示しています。種類を決める、サービスアカウントを作る、新キーを作る、配備する、動作確認後に旧キーを削除する、の順です。旧キーの削除を最後にすることで、切り替え中の停止を避けられます。
有効期限はどう決めるか
キー作成時に、3時間・1日・7日・30日のプリセット、任意の期間、またはNeverから有効期限を選びます。後から変更はできません。
公式ドキュメントでは、期限は作成時にのみ設定でき、後で変更できません。組織に最大期限のポリシーがある場合、Neverは選べなくなり、期間も上限までに制限されます。期限切れのキーは401エラーを返し、再有効化はできないため、新しいキーを作成します。
運用の目安は次のとおりです。
- 検証や一時作業用は、1日〜7日など短い期限にする
- 本番用は、シークレットマネージャーで自社がローテーションする前提でNeverを選ぶか、30日程度の期限にして定期更新する
- 管理画面とAdmin APIの
expires_atで期限を一覧し、切れる前に更新する
期限の事前通知メールは、有効期間が14日以上のキーは期限の7日前、7日以上のキーは1日前に作成者へ届きます。それより短いキーは通知なしで切れます。期限は漏えいした認証情報の寿命を縮めますが、公式も保管の衛生管理の代わりにはならないと明記しています。
漏えいを疑ったとき、最初に何をするか
まず該当キーを無効化または削除します。調査は止めた後に行い、利用状況の確認と新キーへの切り替えが続きます。
公式のベストプラクティスは、漏えいが疑われるキーを直ちに失効させることです。Consoleのキー一覧では、次の2つの操作を使い分けます。
- Disable（無効化）: 可逆。Admin APIでは
status: "inactive"となり、Re-enableで戻せる。原因調査の間、とりあえず止めたいときに使う - Delete（削除）: 不可逆。キーはアーカイブされ、一覧には
status: "archived"で残る
漏えいが確定したキーは削除し、新しいキーを発行します。公開リポジトリへの混入については、AnthropicがGitHubのシークレットスキャンと連携し、見つかったキーを自動で無効化して利用者へメールで知らせると公式が説明しています。ただし検知の遅れもあり得るため、自動対応に頼らず自分でも失効させます。
初動の後は、次の順で進めます。
- 影響範囲の確認: Consoleの利用状況とログで、想定外の時間帯・ワークスペースの利用を確認する
- 経路の特定: ソースコード、設定ファイル、サードパーティツールへの貼り付けを調べる
- 再発防止: キーを環境変数かシークレットマネージャーに移し、用途別にキーを分ける
用途別にキーを分けておけば、1本止めても他の業務に影響しません。公式は開発・テスト・本番でキーを分けるよう勧めています。
規模を問わず、今日やることは何か
手持ちのキーを一覧し、レガシーのワークスペースキーとNeverのキーを洗い出して、移行計画を立てます。
Admin APIの一覧エンドポイントは、各キーの expires_at と、動作主体を示す principal を返します。principal が null ならワークスペースキーです。この一覧から、持ち主不明のキー、期限なしのキー、複数ワークスペースにまたがるキーを優先して整理します。キーの棚卸しや運用ルールづくりは、Kuuの導入〜定着支援（AI Ops）でも伴走しています。静的キー自体を減らす選択肢として、Workload Identity Federationも検討対象です。
参考
- Authentication - Claude Platform Docs
- Admin API - Claude Platform Docs
- API key best practices - Claude Help Center
まとめ
Claude APIキーは、個人・サービスアカウント・ワークスペースの3種類があり、新規はIDに連動する前2者が基本です。期限は作成時にしか決められないため、用途ごとに選びます。漏えいを疑ったら、調査より先に無効化か削除で止めます。キー運用の見直しのご相談は、Kuu株式会社までお問い合わせください。