OpenAI APIキーのガバナンス：作成ルール、所有者、有効期限、無停止ローテーション

OpenAI APIキーに有効期限を付けたい一方で、ルール変更による停止や、次回ローテーションで必要な代替キーを作れない事態は避けたいはずです。本番サービスをサービスアカウントキーにし、個人開発はユーザー所有キーのままにするかも判断が必要です。

この記事では、ワークロードに合わせて所有種別を選び、実際に回せる有効期間を決め、旧キーを重複期間付きで無停止移行する順序を示します。最初に二点だけ押さえてください。新規作成ルールは既存キーを変更せず、組織の制限はプロジェクト設定より優先します。

先に結論：新しい制御は今後作るキーを管理し、既存キーは自動処理しない

9月の更新は、「どの種類の新規キーを発行できるか」と「新規プロジェクトキーを最長どれだけ有効にできるか」という二つの制御です。

日付	OpenAIの更新	チームにとっての意味
2026年9月10日	プロジェクトAPIキーの作成時に有効期限を設定可能。管理者は組織またはプロジェクト単位で最大キー有効期間を強制可能。	新規キーを無期限ではなく期限付きにできる。ただし、短い期限を強制する前に再現可能なローテーション手順が必要。
2026年9月15日	組織とプロジェクトで、新規作成をservice-account keysのみ、user-owned project keysのみ、またはすべて禁止に設定可能。	本番ワークロード、個人開発、凍結プロジェクトに異なる発行ルールを適用できる。
2026年9月15日	組織の制限がプロジェクト設定より優先。	プロジェクトは組織ルールより厳しくできるが、緩めることはできない。
2026年9月15日	既存のAPIキーは新しい作成制限の影響を受けない。	ルールを有効にしても旧キーは失効せず、移行も自動では完了しない。

境界を二つ押さえてください。「新規キー作成を禁止」は「既存キーをすべて失効」と同義ではありません。また、9月10日の最大有効期間は新規作成キーに対する要件として説明されています。既存キーに遡って期限が付くとは、実際のプロジェクトで確認するまで仮定しないでください。

三つを分けて決める：誰が作るか、いつ切れるか、どう安全に廃止するか

この三つは別々に設計してください。Platformの一つのスイッチだけでは、キーのライフサイクル全体を管理できません。

発行ポリシーは、サービスアカウントキー、ユーザー所有のプロジェクトキー、または新規キーなしのどれを許すかを決めます。

期限ポリシーは、新規キーに失効を必須とするか、組織とプロジェクトが許す最大期間を決めます。

ライフサイクル実行は、代替キーを誰が作るか、どこに保存するか、アプリへどう配布するか、何をもって切り替え成功とするか、旧キーをいつ失効させるか、失敗時にどう戻すかを決めます。

最初の二つはOpenAI Platformで制約できます。三つ目はシークレット管理、デプロイ方式、可観測性、担当者、インシデント手順に依存します。最大有効期間だけ設定し、ローテーション担当者や十分な作業時間を用意しなければ、セキュリティ制御が予定された障害になります。

用途で選ぶ：本番はサービスアカウント、個人開発はユーザー所有キー

本番・共有ワークロードにはservice-account key、ローカル・短期作業にはuser-owned project keyを優先し、新規発行の禁止は本当に凍結・廃止するプロジェクトに限ります。

用途	一般に適した種類	理由	主なリスク
本番サービス、共有バックエンド、定期ジョブ、チーム運用のAgent	service-account key	認証情報が特定社員ではなくワークロードに属し、異動や退職による継続性への影響を抑えやすい。	一つのサービスアカウントを多くの無関係なアプリで共有すると影響範囲が広がる。プロジェクトまたはワークロードで分離する。
ローカル開発、短期デバッグ、探索用スクリプト	user-owned project key	所有者と個人責任が明確で、退職処理に本人のキーを含められる。	個人キーが知らないうちに共有本番環境の依存先にならないようにする。
アーカイブ済み、廃止予定、または一時凍結中のプロジェクト	新規作成を禁止	終了・調査中に認証情報の数が増えることを防げる。	早すぎる凍結は、ローテーションや復旧に必要な代替キー作成まで妨げる。

判断に使える質問は、特定の社員がチームを離れても、このアプリは動き続けるべきかです。答えが「はい」なら、本番認証情報をその社員個人のアカウントに依存させない方がよいでしょう。逆に、全開発者へ同じサービスアカウントキーを配ると、操作の帰属が曖昧になり、秘密のコピーも増えます。

キーの種類だけで安全性は決まりません。スコープ、保存、アクセス権、有効期間、ローテーション、失効が実際のリスクを左右します。多数のアプリで共有された長寿命のサービスアカウントキーも、大きな単一障害・漏えい点になり得ます。

組織ポリシーが上限：プロジェクトは厳しくできても緩められない

組織の制限は全プロジェクトの上限になるため、広く適用する前に次回ローテーションを試してください。

たとえば組織でサービスアカウントキーだけを許可した場合、開発プロジェクトが独自設定でユーザー所有キーを再許可することはできません。プロジェクトは組織が許す範囲でさらに厳しくできますが、緩和はできません。

組織設定を変える前に、次の順序で確認します。

1. 全プロジェクトを列挙し、本番、ステージング、開発、テスト、一時利用、アーカイブ、廃止予定に分類する。
2. 現在あるキーの種類だけでなく、各プロジェクトが次回ローテーションで必要とする種類を記録する。
3. 各アクティブワークロードの代替認証情報を特定し、予定する組織ルールで作成可能か確認する。
4. 低リスクのプロジェクトで、作成、配布、検証、失効までをリハーサルする。
5. 通常のローテーションが可能だと実証した後で、組織制限を適用する。

既存キーは動き続けるため、厳しすぎるルールも有効化当日は問題なく見えます。数週間後、キーの期限が近づいたときに必要な代替キーを作れないことで初めて不備が表面化します。現在のリクエストが成功するかだけでなく、次回ローテーションを事前に試してください。

有効期間を一律にしない：実際のローテーション所要時間から決める

最大有効期間は、承認、発行、配布、デプロイ、観測、ロールバックに必要な合計時間より長く設定します。

プロジェクト分類ごとに、少なくとも次を定義します。

項目	答えるべき問い
最大有効期間 N	作成から失効まで新規キーを最長何日・何時間維持できるか。
ローテーション開始余裕 R	期限のどれだけ前に交換作業を始めるか。
主担当と代行担当	誰が責任を持ち、不在時に誰が引き継ぐか。
配布方法	新しいシークレット版を動的に読めるか、再起動・再デプロイが必要か。
検証証拠	どのリクエスト、ログ、エラー、利用量で新キーへの切り替えを証明するか。
ロールバック期間	切り替え後、旧キーをどれだけ残すか。
例外手続き	誰が、どの期間、どの代替統制とともに延長を承認できるか。

Rは作業全体を覆う必要があります。手作業のコピー、時差をまたぐ承認、代行担当なしという環境で極端に短い期限を設定するより、多少長くても自動通知と訓練済みrunbookを持つ方が安定します。

組織の最大値を共通の上限とし、高リスクのプロジェクトはより短い値を設定します。プロジェクトが組織の上限を超えることはできません。本番、個人開発、一時テスト、廃止予定プロジェクトは責任者、影響、復旧速度が違うため、同じ数値に固定する必要はありません。

7ステップの重複ローテーションで停止を避ける

最も安全なのは、新旧キーを短期間だけ並行稼働させ、実トラフィックで切り替えを確認してから旧キーを失効させる方法です。

1. 現在のキーを棚卸しする

プロジェクト、所有種別、ワークロード、アプリ、環境、責任者、保存先、デプロイ方法、作成日、既知の期限、最後に確認した利用状況を記録します。用途や所有者が不明なキーは、いきなり一括失効せず、優先調査対象にします。

OpenAIは2026年8月4日の更新で、Usage/Costsダッシュボード、Usage API、Costs APIがAPIキー単位のフィルタリングとグループ化に対応したと説明しています。この切り口はキーがリクエストを生成しているか判断する材料になります。ただし、月次バッチや災害復旧経路は長期間利用が見えないことがあるため、それだけで削除可能とは判断しません。

2. ポリシーに適合する代替キーを作る

対象プロジェクトで、現在の組織・プロジェクトルールが許す所有種別の新しいキーを作成します。有効期限は適用される上限を超えないようにします。デプロイ当日ではなく、事前に作成可能であることを確認します。

3. 新しいシークレット版として保存する

旧値を直ちに上書きしないでください。制御された移行中は旧版と新版を同時に保持し、「現在の本番」「ローテーション候補」「失効待ち」など明確な状態を付けます。キーをソースコード、コンテナイメージ、チケット本文、ログ、チャットに置かないでください。

4. 段階的にトラフィックを移す

最初は一つのインスタンス、低リスクのジョブ、または少量のトラフィックだけを新キーへ切り替えます。認証、プロジェクト帰属、権限、リクエスト動作を確認してから拡大します。起動時しか環境変数を読まないアプリでは、再起動と容量を計画に含めます。

5. アプリの健全性とキー別利用量を同時に見る

成功リクエスト、認証エラー、レート制限、遅延、業務結果を監視します。同時に、新キーに期待した利用が発生し、旧キーの利用が減っていることを確認します。デプロイが成功表示になっただけでは、実トラフィックが移った証拠になりません。

6. 期限付きのロールバック期間を置く

新キーが安定した後も、事前に定めた期間だけ旧キーを残し、その後失効させます。この期間は遅延worker、複数リージョン、低頻度タスクを覆う必要がありますが、無期限にしてはいけません。二つのキーを恒久的に有効にすると、露出面だけが増えます。

7. 旧キーを失効し、確認して次回を予約する

失効後、旧キーでのリクエストが失敗し、新キーは成功し続けることを確認します。台帳、オンコール手順、責任者、期限、次回ローテーション日を更新します。

旧キーは自動で準拠しない：リスク順に移行する

新しいルールを有効にしても、旧キーの所有者や期限は変わらないため、専用の移行キューが必要です。

旧キー専用の移行キューを作り、次の順で優先します。

1. コード、チケット、ログ、チャットに現れたことがあるキー。
2. 所有者または用途を特定できないキー。
3. 退職・異動した人が所有するユーザーキー。
4. 複数の本番アプリで共有され、個別に失効しにくいキー。
5. スコープが広い、または影響が大きいキー。
6. 所有者、単一用途、検証済み交換経路が明確なキー。

すべての旧キーを同日に失効させることを成功条件にしないでください。各キーに依存先マップ、承認済み代替、切り替え証拠、失効期限がある状態を目標にします。すぐに移行できない場合は、具体的な阻害要因、責任者、代替統制、例外の終了日を記録します。「レガシーだから」は恒久的な例外理由になりません。

社内ポリシーに最低限必要な11項目

実行できるポリシーには、上限だけでなく、責任者、検証証拠、ロールバック期間、失効条件まで明記します。

ポリシー項目	記録内容
対象範囲	組織、プロジェクト、環境、ワークロード分類
許可する新規種類	サービスアカウントのみ、ユーザー所有のみ、または新規なし
理由	継続性、個人責任、プロジェクト凍結など
最大有効期間	組織上限と、より厳しいプロジェクト上限
開始余裕	期限の何日前に警告・作業チケットを作るか
保存	承認済みシークレット管理とアクセス役割
デプロイ	Canary/段階展開、再起動、ロールバック方法
検証証拠	成功リクエスト、エラー指標、キー別利用、旧キー利用ゼロ
失効条件	新キー安定、低頻度タスク確認済み、戻し期間終了
例外	承認者、理由、代替統制、例外の期限
監査	作成、設定変更、デプロイ、失効、所有者変更

長期的な責任はワークロードまたはチームの役割に割り当てつつ、各ローテーションの実行者も明記します。「プラットフォームチームが担当」だけでは、オンコール経路、期限、エスカレーションがなく運用できません。

制限を有効にする前に次回ローテーションをリハーサルする

以下の全項目に答えられ、低リスクのプロジェクトでリハーサルを終えてから、組織・プロジェクト制限を有効にしてください。

• すべての稼働アプリが具体的なプロジェクトとキーに対応付いている。
• 各プロジェクトが次回ローテーションで必要とする種類が分かっている。
• 組織ルールが重要な代替キー作成を妨げない。
• 本番が一人の個人キーに依存していない。
• シークレットストアがバージョン管理または信頼できるロールバックを提供する。
• 新しい秘密の読み込み方法を、再起動要否を含めて試験済みである。
• APIキー別の利用量・コストを観測でき、低頻度タスクも考慮している。
• 主担当と代行担当がいる。
• 期限警告が作業に十分早く届く。
• 旧キー失効条件が明確で、重複期間を恒久化しない。
• 未解決の旧キーごとに阻害要因、責任者、期限がある。

よくある質問

新しい作成制限で既存アプリはすぐ止まるか

2026年9月15日のOpenAI更新では、既存APIキーは新しい作成制御の影響を受けないとされています。新しく作成できる種類を変えても、稼働中のキーは自動失効しません。ただし次回ローテーションには影響するため、代替キー作成を事前に試してください。

最大有効期間は旧キーにも遡って適用されるか

9月10日の更新は新規キーへの要件として説明されています。旧キーへ自動的に期限が追加されると仮定せず、個別の詳細を確認し、別の移行計画を実施してください。

プロジェクト管理者は組織制限を緩められるか

できません。公式説明では、組織制限がプロジェクト設定より優先します。

組織全体をサービスアカウントキーだけにすべきか

本番サービス、共有バックエンド、定期ジョブ、チーム運用のAgentにはサービスアカウントキーを優先します。ローカル開発や短期検証にはユーザー所有プロジェクトキーを優先します。組織全体をサービスアカウント限定にするのは、ほぼすべてのプロジェクトが前者に該当し、開発プロジェクトにも実用的な代替手段がある場合だけです。

すべての新規キー作成を禁止するのはいつか

アーカイブ済み・廃止予定のプロジェクト、またはセキュリティ調査中の一時凍結が代表例です。ローテーションや復旧のために代替キーが必要でないことを先に確認してください。

旧キーを失効してよいとどう証明するか

ロールアウト状態、新キーでの成功リクエスト、エラー監視、キー別利用量、低頻度タスクの実行、ロールバック期間終了を組み合わせます。短時間トラフィックがないだけでは通常不十分です。

最初にやるべき三つのこと

最初に、各プロジェクトが次回ローテーションで必要とするキー種別を記録し、低リスクのプロジェクトで重複ローテーションを一度完了し、その後に組織・プロジェクト制限を設定してください。

この順序が重要です。先に上限を設定すると、現在のアプリは動き続けても、将来必要な代替キーがポリシーで作れない状態になります。ルールを厳しくする前に、次回ローテーションを完了できることを証明してください。

公式情報源：

• OpenAI API Changelog：2026年9月10日・15日の更新