OpenAI APIキー管理で何が変わる？3つの作成制御チェックリスト【2026年9月版】
OpenAI APIの運用で2026年9月に見逃せない変更は、APIキーを「誰が作れるか」と「いつ失効させるか」を管理者側で制御しやすくなったことです。9月10日にプロジェクトAPIキーの有効期限と最大寿命の設定、9月15日にAPI Key Governanceが追加され、組織・プロジェクト単位で新規キー作成のルールを決められるようになりました。生成AIを本番運用する企業は、モデル選定だけでなく、キー棚卸し・ローテーション・サービスアカウント化を30日以内に確認するのが安全です。
要点：新規APIキー作成を3パターンで制御できる
今回の中心はAPI Key Governanceです。管理者は新しく作れるAPIキーの種類について、サービスアカウントキーのみ許可、ユーザー所有のプロジェクトキーのみ許可、または新規APIキー作成をすべて無効化、という3つの方向で制御できます。重要なのは、これは「新規作成」に対する制御であり、既存のAPIキーを自動的に削除したり失効させたりする変更ではない点です。
企業運用では、個人ユーザーの長期キーが本番バッチや顧客向けアプリに残ると、退職・異動・権限変更のたびに棚卸しが難しくなります。新規作成をサービスアカウント中心に寄せれば、所有者変更に強く、監査ログやUsageの確認もしやすくなります。一方、検証用プロジェクトではユーザー所有キーを許可し、productionではサービスアカウントのみ、という分け方も現実的です。
仕様表：組織設定とプロジェクト設定の違い
OpenAIの公式説明では、組織レベルの制限がプロジェクト設定より優先されます。つまり、組織で「新規キー作成を禁止」とした場合、プロジェクト側で緩めることはできません。プロジェクト設定は、組織設定をさらに絞る方向には使えますが、組織の方針を上書きして自由化する用途には使えません。全社の最低基準を組織設定で置き、部門や用途別の厳しさをプロジェクト側で追加する、と考えると設計しやすくなります。
比較すると、組織設定は「全社のガードレール」、プロジェクト設定は「用途別の追加制限」です。production、staging、研究開発、顧客別環境を分けている企業では、productionだけ最大キー寿命を短くし、研究開発プロジェクトは短期検証用のユーザーキーを認める、といった段階設計ができます。ただし、プロジェクト上限は組織上限を超えられないため、最初に組織ポリシーを厳しくしすぎると例外運用が増えます。
有効期限：最大キー寿命を決める前に確認する5項目
9月10日の更新では、プロジェクトAPIキー作成時に有効期限を設定でき、管理者は組織またはプロジェクト単位で最大キー寿命を強制できるようになりました。新しく作るキーは、その上限内で期限を持つ必要があります。まずは全キーを一律30日にするより、用途ごとに30日、90日、180日のように分け、更新作業が止まらない範囲で短くするのが現実的です。
確認すべき項目は5つです。1つ目は本番アプリのキー所有者、2つ目はCI/CDやバッチで使うキーの保管場所、3つ目は失効前の通知経路、4つ目はローテーション手順、5つ目は旧キーの無効化確認です。期限だけを短くしても、更新担当者と手順が決まっていなければ障害になります。期限設定は、Secrets Manager、GitHub Actions secrets、Cloudflare Workers secretsなど実際の保管先と一緒に設計してください。
30日導入チェックリスト
まず1週目はAPIキー一覧を出し、キー名、所有者、用途、環境、本番影響、最終利用日を表にします。古いキーほど危険とは限りませんが、利用状況が追跡されていないキーや所有者が不明なキーは優先的に確認します。OpenAIのProduction best practicesでは、環境変数やシークレット管理サービスを使い、コードや公開リポジトリにキーを置かないことも推奨されています。
2週目は新規キー作成ルールを決めます。productionはサービスアカウントキーのみ、stagingはサービスアカウントまたは期限付きユーザーキー、sandboxは短期ユーザーキーも可、というように環境別に書き分けます。3週目は最大キー寿命を設定し、4週目に実際のローテーション訓練を行います。訓練では、交換前後でエラー率、429/503の再試行、利用量ダッシュボードの見え方まで確認すると運用に残しやすくなります。
既存キーはどう扱うべきか
今回のガバナンス制御は既存APIキーには自動適用されません。そのため、既存キーを放置したまま新規キー作成だけを制限すると、見た目だけ整って実態は変わらない状態になります。特に2023年12月20日以前に作成されたキーは、利用状況の追跡がデフォルトで有効ではない場合があるため、Usageで追えるか、キー管理ダッシュボードで追跡を有効にできるかを確認してください。
移行方針は「止める前に置き換える」が基本です。サービスアカウントキーを作成し、アプリケーションのシークレットを差し替え、正常稼働を確認してから旧キーを取り消します。複数サービスで1つのキーを共有している場合は、サービス別に分割してからローテーションします。キー単位でUsageを見られる設計にしておくと、コスト異常や漏えい疑いの切り分けも早くなります。
料金・セキュリティ・監査への影響
APIキー管理はセキュリティだけでなく、費用管理にも直結します。キーが環境やサービスごとに分かれていれば、急な利用増加が「どのプロジェクト・どのサービス・どの担当範囲」で起きたのかを追いやすくなります。逆に共有キーが多いと、月末にUsageを見ても原因特定に時間がかかり、ハードリミットやレート制限の調整も粗くなります。
監査の観点では、作成権限、キー寿命、保管場所、ローテーション履歴、失効確認の5点を残すと説明しやすくなります。社内規程に「個人キーを本番利用しない」「productionキーはサービスアカウントに限定」「最大寿命は原則90日、例外は承認制」のような文言を入れると、OpenAI側の機能変更を社内統制に接続できます。
FAQ：OpenAI APIキー管理でよくある質問
Q. API Key Governanceを有効にすると既存キーは止まりますか？ A. 公式説明では、これらの制御は新規キー作成に適用され、既存APIキーは影響を受けません。既存キーは別途棚卸し、置き換え、失効の計画が必要です。
Q. 最大キー寿命は何日にすべきですか？ A. 一律の正解はありません。本番では90日程度から始め、短期検証や外部委託では30日、長期運用の例外は承認制にするなど、停止リスクと漏えいリスクのバランスで決めるのが現実的です。
Q. サービスアカウントキーだけにすれば十分ですか？ A. 十分ではありません。サービスアカウント化は所有者問題を減らしますが、保管場所、権限範囲、利用量監視、失効手順がなければリスクは残ります。キーの種類、寿命、Usage監視をセットで整える必要があります。
まとめ：3つの作成制御を30日で運用に落とす
OpenAI APIの2026年9月アップデートは、APIキーを作ったあとに慌てて管理する段階から、作る前に統制する段階への移行です。新規キー作成の3パターン制御、最大キー寿命、組織設定の優先順位、既存キーは自動影響なし、という4点を押さえれば、企業のAI活用基盤をかなり整理できます。まずは本番プロジェクトの既存キーを棚卸しし、30日以内にサービスアカウント化とローテーション訓練まで進めるのがおすすめです。
OpenAI APIや生成AI基盤の権限設計、キー棚卸し、社内向け運用ルールづくりをまとめて進めたい場合は、HelloCraftAIにご相談ください。
