# Claude APIキーの種類と漏えい時の初動手順

> Claude APIキーは個人・サービスアカウント・ワークスペースの3種類。退職で止まる設計、有効期限、無効化と削除の違いなど、漏えい時の初動手順を中小企業向けに整理します。

- Canonical: https://kuucorp.com/blog/claude-api-key-types-expiration-leak-response-smb/
- Date: 2026-10-18
- Last modified: 2026-10-18
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
退職した開発者が作ったAPIキーが、本番の業務自動化でそのまま使われている。誰のキーか分からず、止めてよいかも判断できない。中小企業のClaude API運用でよく起きる状況です。

キーの作り方を決めておけば、人が抜けたときに自動で止まり、漏えいしても被害の期間を限定できます。本記事では、公式ドキュメントに沿ってキーの種類、有効期限、漏えい時の初動を整理します。キー保管の一般論は[シークレット管理とローテーション](/blog/agent-secret-management-rotation/)も参照してください。

## Claude APIキーにはどんな種類があるか

> Claude APIキーは、個人キー・サービスアカウントキー・ワークスペースキー（レガシー）の3種類です。新規は前2者が推奨されています。

公式ドキュメントによると、作成時にキーの種類を選び、種類ごとに「誰として動くか」と「いつ止まるか」が決まります。

| 種類 | 動作主体 | 止まるタイミング |
|---|---|---|
| 個人キー | 作成した本人 | 本人が組織から外れたとき（アーカイブ） |
| サービスアカウントキー | サービスアカウント | サービスアカウントがアーカイブされたとき |
| ワークスペースキー（レガシー） | 誰でもない（ワークスペース所属） | 期限切れ、無効化・削除、ワークスペースのアーカイブ |

個人キーとサービスアカウントキーは、組織が管理するIDに紐づく「アイデンティティ連動」のキーです。IDが組織から外れればキーも止まるため、人や業務より長く生き残る鍵が生まれません。一方、ワークスペースキーは作成者が退職しても動き続けます。公式は新規連携にアイデンティティ連動キーを優先するよう案内しています。

## 個人キーとサービスアカウントキーはどう使い分けるか

> 自分の開発や試作には個人キー、CIや本番など共有・無人の処理にはサービスアカウントキーを使います。

共有された個人キーは「一人として動く」ため、その人が退職すると業務も止まります。共有・自動化の用途は、組織の管理者がサービスアカウントを作成し、必要なワークスペースに追加したうえで、そのアカウントに紐づくキーを発行します。

キーは可能な限りワークスペース単位に絞ります。ワークスペースを限定したキーはリクエストでワークスペースIDの指定が不要になります。限定しないキーは `anthropic-workspace-id` ヘッダーが必須で、省略すると400エラーになります。

既存のワークスペースキーからの移行手順は、公式が5段階で示しています。種類を決める、サービスアカウントを作る、新キーを作る、配備する、動作確認後に旧キーを削除する、の順です。旧キーの削除を最後にすることで、切り替え中の停止を避けられます。

## 有効期限はどう決めるか

> キー作成時に、3時間・1日・7日・30日のプリセット、任意の期間、またはNeverから有効期限を選びます。後から変更はできません。

公式ドキュメントでは、期限は作成時にのみ設定でき、後で変更できません。組織に最大期限のポリシーがある場合、Neverは選べなくなり、期間も上限までに制限されます。期限切れのキーは401エラーを返し、再有効化はできないため、新しいキーを作成します。

運用の目安は次のとおりです。

1. 検証や一時作業用は、1日〜7日など短い期限にする
2. 本番用は、シークレットマネージャーで自社がローテーションする前提でNeverを選ぶか、30日程度の期限にして定期更新する
3. 管理画面とAdmin APIの `expires_at` で期限を一覧し、切れる前に更新する

期限の事前通知メールは、有効期間が14日以上のキーは期限の7日前、7日以上のキーは1日前に作成者へ届きます。それより短いキーは通知なしで切れます。期限は漏えいした認証情報の寿命を縮めますが、公式も保管の衛生管理の代わりにはならないと明記しています。

## 漏えいを疑ったとき、最初に何をするか

> まず該当キーを無効化または削除します。調査は止めた後に行い、利用状況の確認と新キーへの切り替えが続きます。

公式のベストプラクティスは、漏えいが疑われるキーを直ちに失効させることです。Consoleのキー一覧では、次の2つの操作を使い分けます。

- **Disable（無効化）**: 可逆。Admin APIでは `status: "inactive"` となり、Re-enableで戻せる。原因調査の間、とりあえず止めたいときに使う
- **Delete（削除）**: 不可逆。キーはアーカイブされ、一覧には `status: "archived"` で残る

漏えいが確定したキーは削除し、新しいキーを発行します。公開リポジトリへの混入については、AnthropicがGitHubのシークレットスキャンと連携し、見つかったキーを自動で無効化して利用者へメールで知らせると公式が説明しています。ただし検知の遅れもあり得るため、自動対応に頼らず自分でも失効させます。

初動の後は、次の順で進めます。

1. 影響範囲の確認: Consoleの利用状況とログで、想定外の時間帯・ワークスペースの利用を確認する
2. 経路の特定: ソースコード、設定ファイル、サードパーティツールへの貼り付けを調べる
3. 再発防止: キーを環境変数かシークレットマネージャーに移し、用途別にキーを分ける

用途別にキーを分けておけば、1本止めても他の業務に影響しません。公式は開発・テスト・本番でキーを分けるよう勧めています。

## 規模を問わず、今日やることは何か

> 手持ちのキーを一覧し、レガシーのワークスペースキーとNeverのキーを洗い出して、移行計画を立てます。

Admin APIの一覧エンドポイントは、各キーの `expires_at` と、動作主体を示す `principal` を返します。`principal` が `null` ならワークスペースキーです。この一覧から、持ち主不明のキー、期限なしのキー、複数ワークスペースにまたがるキーを優先して整理します。キーの棚卸しや運用ルールづくりは、[Kuuの導入〜定着支援（AI Ops）](https://kuucorp.com/services/ai-ops/)でも伴走しています。静的キー自体を減らす選択肢として、[Workload Identity Federation](/blog/claude-api-workspace-team-management-wif/)も検討対象です。

## 参考

- [Authentication - Claude Platform Docs](https://platform.claude.com/docs/en/manage-claude/authentication)
- [Admin API - Claude Platform Docs](https://platform.claude.com/docs/en/manage-claude/admin-api)
- [API key best practices - Claude Help Center](https://support.claude.com/en/articles/9767949-api-key-best-practices)

## まとめ

Claude APIキーは、個人・サービスアカウント・ワークスペースの3種類があり、新規はIDに連動する前2者が基本です。期限は作成時にしか決められないため、用途ごとに選びます。漏えいを疑ったら、調査より先に無効化か削除で止めます。キー運用の見直しのご相談は、[Kuu株式会社](https://kuucorp.com/services/ai-ops/)までお問い合わせください。