OpenAI API キーに有効期限を設定できるように — 組織単位で最大有効期間を強制できる
OpenAI が 2026-09-10、プロジェクト API キーの作成時に有効期限を設定できるようにした。加えて、組織およびプロジェクト単位でキーの最大有効期間を強制でき、上限を設定すると新規キーは必ずその範囲内で失効する。公式はキーのローテーションに関する本番運用のベストプラクティスに沿う変更と位置づけている。
ニュース原文を読む ↗要約
OpenAI は 2026-09-10、プロジェクト API キーに有効期限を設定できるようにしました。
変更は2段階です。まず、キーの作成時に有効期限（expiration date）を指定できるようになりました。そして、組織およびプロジェクト単位で「キーの最大有効期間」を強制できます。Platform の設定で上限を決めると、新規に作成されるキーは必ずその上限以内で失効します。
後者が本質です。 有効期限を「設定できる」だけなら、設定するかどうかは個々の開発者次第です。忙しければ設定されません。上限を組織で強制すると、期限なしのキーを作るという選択肢そのものが消えます。
公式は、この変更をキーのローテーションに関する本番運用のベストプラクティスに沿うものと説明しています。
これまで API キーの棚卸しは、「発行台帳を人が管理する」という運用でしか支えられませんでした。退職者が発行したキー、検証目的で作って消し忘れたキー、外部委託先に渡したまま回収していないキー。 こうしたものが残り続ける事故は、仕組みの側に止める手段がない以上、構成上避けられないものでした。今回の変更は、その前提をプラットフォーム側の強制力へ移すものです。
何が変わったか
- プロジェクト API キーの作成時に有効期限を指定できる
- 組織単位・プロジェクト単位でキーの最大有効期間を強制できる
- 上限を設定すると、新規キーは必ずその範囲内で失効する
- 公式はキーのローテーションのベストプラクティスに沿う変更と位置づけている
業務インパクト（一般企業向け）
この更新の価値は、「守るべきルール」を「破れないルール」に変えられる点にあります。
情報セキュリティの社内規程に「API キーは定期的にローテーションすること」と書いてある組織は多いはずです。そして、実際にローテーションされているかを確認する手段がないまま、書いてあるだけになっている組織も多いはずです。監査で聞かれたときに「規程があります」としか答えられない状態は、実質的に管理できていない状態です。
上限を強制する設定を入れると、この状態が変わります。 期限のないキーが作れない以上、ローテーションは「守られているかどうか」ではなく「そういう仕組みである」という話になります。監査に対しても、規程ではなく設定を示せます。
やるべきことは3つです。
- 上限を決める。 90日か180日か。短いほど安全ですが、切り替え作業の頻度も上がります。切り替えを自動化していない環境で30日にすると、月次で人が手を動かすことになり、結局形骸化します。 自動化の水準に合わせて決めるのが現実的です。
- 既存キーを棚卸しする。 この変更で自動的に期限が付くのは新規キーだけです。今動いているキーには期限がありません。上限を設定しただけで安心すると、一番危ないキーが放置されます。 現在有効なキーを一覧し、用途不明のものを止め、必要なものを期限付きで作り直す作業が別途必要です。
- 失効時の影響範囲を先に洗い出す。 キーが切れると、それを使っているバッチや連携が止まります。どのキーがどのシステムで使われているかを把握していない状態で期限を付けると、ある日突然業務が止まります。 期限の前に通知を受け取る仕組みと、切り替え手順を先に用意してください。
順序が重要です。 「上限を設定する」より先に「既存キーの把握」が来ます。逆にすると事故になります。
副業・個人活用視点
個人開発者にとって、これは「消し忘れたキー」の問題への直接的な手当てです。
一人で開発していると、検証用に作ったキーが残り続けます。ローカルの .env に書いたまま忘れ、後でそのリポジトリを別の用途に使い回し、気づいたら公開リポジトリにキーが載っていたという事故は、個人開発でこそ起きやすいものです。期限を付けておけば、少なくとも漏れたキーが永久に有効ではなくなります。
実務的には、用途ごとに期限を変えるのが使いやすい形です。検証用は短く（7日や30日）、本番用は長めに。検証用キーを短期にしておけば、消し忘れても自然に無効化されます。
受託の観点では、これは提案材料になります。
顧客の環境で API を使う案件では、「キーをどう管理するか」は必ず論点になりますが、多くの場合その場では詰められずに流れます。 プラットフォーム側で上限を強制できるという事実は、**「規程ではなく設定で担保します」**という具体的な提案に変えられます。セキュリティ要件の厳しい顧客ほど効きます。
また、委託先にキーを渡す場面でも意味があります。 契約期間に合わせた期限を付けて発行すれば、回収を忘れても契約終了後に自然に無効化されます。 「返してもらう」という人の運用に頼らずに済む、というのが実務上の利点です。個人で外注を使う場合にも同じことが言えます。
なお、既存キーには期限が付かない点は個人でも同じです。設定を入れる前に、いま有効なキーを一度全部見てください。心当たりのないキーが1つも無いと言い切れる人は、そう多くありません。