OpenAI APIキーの有効期限に備える、安全なローテーション設計

OpenAIは2026年9月10日、プロジェクト用のOpenAI APIキーに有効期限を設定できるようにしました。これにより、認証情報のローテーションは、予定を組んで行う本番環境の保守作業になります。無人で動くエージェントにも、担当者、交換作業の時間枠、そしてキーが失効する前の検証手順が必要です。

OpenAI APIキーの有効期限は、自動ローテーションではありません

APIキーは、アプリケーションがOpenAI APIの利用権限を証明するために送る秘密情報です。シークレットマネージャーにキーを保存し、定期実行ワーカーから参照させたまま、問題が起きるまで手を加えない運用も珍しくありません。

OpenAIでは現在、プロジェクトAPIキーの作成時に有効期限を設定できます。管理者は、組織またはプロジェクト単位で、Platform settingsからキーの最長有効期間を設定することもできます。このポリシーがある場合、新しく作成するキーの有効期限は、許可された期間内に収めなければなりません。

それぞれの設定が担う役割は異なります。

ここで重要なのは、上位ルールが優先される点です。プロジェクト側の設定で、組織ポリシーが認める期間よりもキーを長く有効にすることはできません。プロジェクトの設定は、必ず組織側の境界内に収める必要があります。

これは自動ローテーションの仕組みではありません。OpenAIの本番環境向けガイダンスでは、有効期限の前に交換用キーを作成し、アプリケーションを更新して動作を確認した後に、旧キーを失効させるよう案内しています。この引き継ぎ作業のすべては、引き続きチームが担います。

運用面で変わるのは、保守予算です

この機能でトークン料金が変わるわけではありません。変わるのは、プロジェクトキーで認証する定期ジョブごとに発生する作業時間と、中断リスクの計算です。

簡単な計画モデルで考えてみます。以下はOpenAIの制限値ではなく、ワークロードに関する仮定です。

あるプロジェクトでエージェントを15分ごと、つまり1日96回実行するとします。計画的なローテーションには、オペレーターの作業時間が30分かかります。四半期ごとに実施し、人件費を1時間あたり$75と見積もると、ローテーションの費用は1回$37.50、プロジェクトごとに年間$150です。10プロジェクトなら、年間保守費として無視できない$1,500になります。

今度は、キーの失効を見落とし、中断が4時間続いたケースを考えます。この時間帯には16回の定期実行が含まれます。実行できなかったジョブの確認と再実行にそれぞれ10分かかれば、復旧作業は160分、つまり2時間40分です。同じく1時間あたり$75で計算すると、人件費だけで$200になります。顧客対応の遅延、レポートの未配信、売上の損失は、この金額に含まれていません。

これが有効期限を設けることの実務上の影響です。放置された認証情報が有効であり続ける期間は短くなりますが、見えにくかったセキュリティリスクは、繰り返し発生する運用タスクに変わります。そのため、予算に作業時間を組み込み、カレンダー上で担当者を明確にする必要があります。

本当に抑えたいのがAPI利用料の暴走であれば、キーの有効期限は適切な管理策ではありません。その境界については、別記事のAI Agent API予算管理ガイドで解説しています。予算上限も認証情報の期限も処理を止める可能性はありますが、解決する問題が異なるため、復旧計画も分けて考える必要があります。

このローテーション手順が必要なのは誰か

無人のSaaSエージェントを運用する個人創業者

サポート内容の要約、文書処理、データ拡充などのジョブを動かす創業者は、自分自身が担当する場合でも、認証情報の所有者を明確にすべきです。そのキーを使うスケジューラー、デプロイ先、シークレットの登録箇所を記録します。現行キーがまだ使えるうちに交換を始め、新しいシークレットで実際の定期ジョブが完了するところまで確認してください。

得られるのはサービスの継続性です。ローテーションを小規模な計画リリースとして扱えば、「昨日の処理結果が届いていない」という顧客からの連絡で初めて障害に気づく事態を避けられます。

顧客プロジェクトを管理する制作会社の運用責任者

制作会社では、顧客プロジェクトごとにローテーション記録を用意できます。記録するのは、プロジェクト、キーの担当者、稼働中のジョブ、有効期限、交換状況、検証結果です。これにより、必要な工数を数値化できます。また、誰も触れたがらない共有認証情報の中に、忘れられた顧客向け自動処理が埋もれるのも防げます。

得られるのは利益率の保護です。ローテーションの工数を納品計画に含められ、アカウント責任者も、旧シークレットが使えなくなる前に確認すべき顧客ジョブを把握できます。

組織ルールを定めるプラットフォームチーム

バックエンドまたはプラットフォームのチームは、まず組織の最長有効期間を決め、その範囲内で各プロジェクトに上限を設定させるべきです。ワークロードやリスクに応じてプロジェクト側を短くすることはできますが、組織の上限を回避するために、より長い有効期間を設定することはできません。

得られるのは一貫したガバナンスです。有効期間のルールを公開するときは、同じチームが交換手順も同時に示す必要があります。引き継ぎ方法のない期限は、発生日だけが決まっている将来のインシデントにすぎません。

古い認証情報を整理するセキュリティ管理者

セキュリティ管理者は、新規キーのポリシーと既存キーの棚卸しを別々の作業として扱うべきです。新しく作るキーには最長有効期間を適用し、それとは別に既存のプロジェクト認証情報を洗い出して担当者を割り当てます。公開情報の対象範囲には、古いキーが自動的に期限切れになるという保証はありません。

得られるのは、実態に即した導入です。将来に向けたポリシーを過去分の整理まで完了したものと取り違えることなく、新しい認証情報からすぐに改善できます。

APIキーを無停止でローテーションする手順

実際に操作する画面は、利用するホスティング環境やシークレットマネージャーによって異なります。しかし、安全に進める順序は共通です。

1. 1

   ポリシーと担当者を確認する

   交換用キーを作る前に、組織とプロジェクトの最長有効期間を確認します。現行キーが属するプロジェクト、そのキーを使うすべてのジョブ、責任者、交換作業の開始時点を記録してください。

2. 2

   余裕を持って交換用キーを作る

   旧キーがまだ有効なうちに、新しいプロジェクトAPIキーを作成します。適用中のポリシーに沿った有効期限を設定してください。ソースコードや公開リポジトリには保存しません。

3. 3

   シークレットストア経由で段階的に反映する

   アプリケーションが現在利用している環境変数またはシークレット管理パスに、交換用キーを新しいバージョンとして保存します。まずは管理下にあるワーカーまたはテスト経路に限定して更新してください。テスト環境と本番環境をより厳密に分離したい場合、OpenAIではステージング用と本番用に別々のプロジェクトを利用することもできます。

4. 4

   デプロイ済みジョブを検証する

   実際の認証経路を通してアプリケーションを実行します。リクエスト結果、ジョブの出力、キュー、ワーカーのログを確認してください。キーのトラッキングを有効にすると、OpenAIのUsageページも追加の判断材料になりますが、ダッシュボードの表示だけでは業務上の結果を確認したことにはなりません。

5. 5

   全体へ反映してから旧キーを廃止する

   旧認証情報を使っていたすべてのデプロイ先、スケジューラー、CIシークレット、長時間稼働するワーカーを更新します。それらのジョブすべてで新しいキーが機能することを確認してください。検証が完了してから旧キーを失効させます。

有効期限を設定しても、運用側に残る課題

OpenAIの公開情報には、全ユーザー共通のデフォルト有効期間も、一律の最長期間も記載されていません。また、猶予期間、自動交換の仕組み、有効期限通知のスケジュールについても説明されていません。ポリシーを決めるのは各アカウントの設定であり、リマインドと展開作業は、その周囲に構築する運用で補う必要があります。

この設定だけでは、シークレットがどこへコピーされたかも把握できません。開発者がキーをCIシステム、サーバーレス環境、ローカルマシン、バックアップスクリプトに貼り付けたとしても、設定側では検知できないのです。多くのチームが最も過小評価しやすいのは、この棚卸し作業です。

もう一つの難所は検証です。テストリクエストの成功で分かるのは、交換用キーが有効だということだけです。すべての定期実行ワーカーに反映された証明にはなりません。だからこそ、ローテーション記録にはジョブ一覧が必要であり、その一覧を確認し終えるまで旧キーを有効にしておく必要があります。

今週着手すべきこと

定期実行エージェント、バッチワーカー、顧客向け自動処理、バックエンドサービスのいずれかがプロジェクトAPIキーを使っており、組織で最長有効期間を適用する予定なら、今から動くべきです。最初の期限が発生する前に、ローテーションの工数を運用予算へ組み込んでください。

最長有効期間が有効になっておらず、現在のプロジェクトキーにも有効期限がなければ、全面導入は待つことができます。それでも、認証情報と担当者の棚卸しは今のうちに始めてください。新しい管理機能によって今後の方向性は明確になっており、OpenAIもすでに定期的なローテーションを推奨しています。

既存キーが過去へさかのぼって失効するとは説明されていないため、古いデプロイすべてに突然9月の期限が生じたと主張する根拠はありません。ただし、放置してよいという意味でもありません。新しいポリシーが過去の認証情報まで整理してくれると期待せず、既存キーは別枠で調査すべきです。

月曜日になったら、本番プロジェクトをひとつ選びます。認証情報の担当者を決め、現行キーが使えるうちに交換用キーを段階導入し、新しいキーですべてのデプロイ済みジョブを確認してから、旧キーを廃止してください。この一連の引き継ぎが、ローテーション計画です。

このような運用のポイントを分かりやすく知りたい方は、ニュースレターにご登録ください。