Anthropicは2026年7月8日、Claude ConsoleでAPIキーとAdmin APIキーを作成する際に、有効期限を設定できるようにした。

漏えいした認証情報が無期限に利用され続けるリスクを減らせる一方、有効期限を設定しただけでは安全な運用にはならない。期限切れのキーは自動的に使えなくなり、APIは401 authentication_errorを返す。更新手順が整っていない環境では、セキュリティ強化がそのままサービス停止要因になる。

何が変わったか

Claude Consoleで新しいAPIキーを作成するとき、次の有効期限を選択できる。

  • 3時間
  • 1日
  • 7日
  • 30日
  • 任意の期間
  • 無期限

組織管理者が最大有効期間のポリシーを設定している場合、利用者はその上限を超える期間を選べない。無期限も選択できなくなる。

対象は通常のClaude APIキーだけではない。Claude Consoleから作成するAdmin APIキーにも同じ期限設定が適用される。

既存キーは自動変更されない

今回の変更は、新しく作成するキーが対象である。既存のキーへ自動的に期限が付くわけではない。

また、有効期限はキーの作成時に決まり、後から延長または短縮できない。期間を変更したい場合は、新しいキーを作成し、利用先を切り替えた後、古いキーを失効させる必要がある。

この仕様により、キー管理は単なる設定変更ではなく、次の作業を伴う運用になる。

  1. 新しいキーを発行する
  2. シークレット管理基盤へ登録する
  3. アプリケーションまたはCI/CDへ配布する
  4. 新しいキーで疎通確認する
  5. トラフィックを切り替える
  6. 古いキーを失効させる
  7. 監査記録を残す

期限前の通知条件

Anthropicは、キーの有効期間に応じて作成者へメールを送る。

キーの有効期間通知
14日以上期限の7日前
7日以上14日未満期限の1日前
7日未満事前メールなし

短期間のキーは、通知メールを待って交換する運用には向かない。3時間、1日、7日未満の任意期間を利用する場合は、発行と切り替えを自動化する必要がある。

通知先はキーの作成者である。担当者の異動、退職、休暇、メールフィルターなどにより、通知が実運用チームへ届かない可能性がある。メールは補助的な手段と考え、組織側の監視を主にすべきである。

期限切れ後の挙動

期限切れのキーを使ったリクエストは、401 authentication_errorになる。期限切れのキーを再有効化することはできない。

障害監視で401をすべて不正アクセスとして扱っている場合、期限切れと漏えい、不正なキー、設定ミスを区別できない。アプリケーションログには秘密情報を残さず、次の情報を記録するとよい。

  • 利用しているキーの内部識別子
  • 対象環境とサービス名
  • キーの有効期限
  • 最終ローテーション日時
  • 401発生時刻と対象エンドポイント
  • 直前のデプロイまたはシークレット更新履歴

実際のAPIキー文字列をログへ記録してはいけない。

Admin APIで監査できる

Admin APIのキー一覧および個別取得では、expires_atフィールドで有効期限を確認できる。期限を設定していないキーではnullになる。

これにより、組織はメール通知に依存せず、定期的にキー一覧を取得して次の状態を検出できる。

  • 期限まで7日未満のキー
  • 無期限のまま残っているキー
  • 所有者が不明なキー
  • 開発環境で長期間有効なキー
  • 使われていないが失効していないキー
  • 本番サービスに対して短すぎる期限が設定されたキー

誰に影響するか

特に影響が大きいのは次の組織である。

  • Claude APIキーを環境変数へ直接設定している
  • GitHub Actionsや他のCI/CDで長期キーを使っている
  • 複数の本番サービスが同じキーを共有している
  • キー発行者と運用担当者が別である
  • 休日や夜間に期限が切れる可能性がある
  • Admin APIキーを手作業で管理している
  • 有効期限を設定すればローテーション不要だと考えている

推奨する運用設計

1. 環境ごとにキーを分離する

開発、検証、本番で同じキーを共有しない。サービス単位、用途単位で分けることで、ローテーション時の影響範囲と漏えい時の被害を限定できる。

2. シークレット管理基盤を使う

キーをソースコード、設定ファイル、チャット、社内Wikiへ保存しない。AWS Secrets Manager、Google Secret Manager、Azure Key Vault、HashiCorp Vaultなど、利用中の基盤へ保管する。

3. 期限前に重複期間を設ける

旧キーが有効なうちに新しいキーを配布し、疎通確認後に旧キーを失効させる。切り替えと失効を同時に行うと、設定反映の遅延やロールバックで停止する可能性がある。

4. expires_atを監視する

少なくとも1日1回、Admin APIからキー一覧を取得し、期限までの残日数を監視する。本番キーは7日前、3日前、1日前など複数段階で通知するとよい。

5. 401を運用イベントとして分類する

401が増えた場合に、期限切れ、キー削除、誤配布、権限不足を切り分けられるダッシュボードと手順書を用意する。

編集部分析

有効期限付きAPIキーは、漏えいした秘密情報の有効期間を限定する。これは有効な防御だが、短命な認証情報を自動的に発行するワークロードID連携とは異なる。人がConsoleで発行し、アプリケーションへ配布する運用が残る限り、期限切れ障害と配布ミスは発生し得る。

したがって、最初から最短の期限を選ぶことが常に正しいわけではない。手動運用の組織が3時間キーを採用すると、更新作業が追いつかず、かえって共有や回避運用が増える可能性がある。

現実的には、現在のローテーション能力に合う期限から開始し、監視と自動化を整えながら短縮する方が安全である。無期限キーを減らすことと、サービスを停止させないことを同時に達成する必要がある。

実務チェックリスト

  • [ ] 既存キーの所有者と利用先を特定した
  • [ ] 開発、検証、本番のキーを分離した
  • [ ] キーをシークレット管理基盤へ移した
  • [ ] expires_atを台帳または監視へ取り込んだ
  • [ ] 期限前に新旧キーを重複させる手順を作った
  • [ ] 休日・夜間の期限切れを検知できる
  • [ ] 401エラーの切り分け手順を作った
  • [ ] 退職者や異動者が作成したキーを棚卸しした
  • [ ] 無期限キーの利用理由を記録した

一次情報