OpenAIのAPIキーに有効期限。API契約の名義で変わる運用費と、確認する3点

AI 開発の見積書には、ほぼ必ず「API 利用料」という行がある。そして、その行の横に誰の名義で API を契約するのかは書かれていないことが多い。

2026 年 9 月、OpenAI の API プラットフォームに、この「名義」の話を無視できなくする変更が 2 つ入った。9 月 10 日にプロジェクト API キーへの有効期限の設定と、組織・プロジェクト単位での最大有効期間の強制。9 月 15 日にAPI キーの発行そのものを統制する設定である。

どちらも管理機能の追加であって、モデルの発表でも値下げでもない。ニュースとしては地味だ。ただ発注側から見ると、「開発会社に渡したキーが、ある日を境に使えなくなる」という状態が設定で作れるようになったという話になる。運用の引き継ぎと、月々の請求先に直接効く。

何が変わったか

OpenAI の公式ドキュメントの変更履歴に載っている内容を、事実のまま整理する。

日付	変更内容
2026年9月10日	プロジェクト API キーの作成時に有効期限を設定できるようになった。管理者は組織またはプロジェクトの単位でキーの最大有効期間を強制できる
2026年9月15日	API キー発行の統制設定が追加された。管理者は「サービスアカウントのキーだけ許可」「利用者個人が持つプロジェクトキーだけ許可」「新規発行を全面禁止」から選べる

補足として押さえておきたい点が 3 つある。

• 組織レベルの制限がプロジェクトの設定に優先する。 プロジェクト側で制限を強めることはできるが、緩めることはできない
• プロジェクトの最大有効期間は、組織の上限を超えて設定できない
• これらは新規発行にだけ効く。すでに発行済みのキーには影響しない

公式ドキュメントの本番運用ガイドでは、キーの作成時に有効期限を設定し、定期的な入れ替えの手順を用意することが推奨されている。入れ替えの手順も明示されていて、期限前に後継のキーを作り、アプリケーション側を更新し、動作を確認してから古いキーを失効させる、という順序になる。

同じ方向の設計は OpenAI に限った話ではない。Anthropic の Claude Console では、API キーは作成したワークスペースに紐づき、ワークスペース間を移すことができない。キーごとに有効期限を持ち、管理 API でその有無を確認できる。ワークスペース単位で支出の上限とモデルごとのレート制限を設定でき、支出が一定額に達した時点でメール通知を出す設定もある。公式のベストプラクティスでは、90 日ごとといった一定周期でのキーの入れ替えが挙げられている。

つまり主要な提供元の双方で、API キーは「発行したら永続的に使えるもの」ではなく「期限と持ち主と上限が付いた貸出物」として扱う前提に寄っている。

なぜ発注側の費用の話になるのか

AI 開発では、API キーは単なる認証情報ではない。請求先そのものである。キーがどのアカウントのどのプロジェクトで発行されたかによって、月々の従量課金がどこに立つかが決まる。

名義の置き方は、実務上おおむね次の 3 通りに分かれる。

型 A：開発会社の名義で契約し、実費を請求してもらう

開発会社が自社のアカウントでキーを発行し、使った分を月額保守費や実費精算として請求する。発注側は API の管理画面を持たない。

• 着手が速い。発注側の情報システム部門を待たなくてよい
• 使用量の内訳が、開発会社の請求書の粒度でしか見えない
• 契約が終わったとき、キーもアカウントも発注側には残らない

型 B：発注側の名義で契約し、キーを開発会社に貸す

発注側が自社アカウントでプロジェクトを作り、そこで発行したキーを開発会社に渡す。請求は発注側に直接立つ。

• 使用量を自分で見られる。支出上限も自分でかけられる
• 今回の変更がそのまま効くのはこの型。期限を付けて貸し、期限で自動的に切れるようにできる
• 発注側にアカウント管理の手間が発生する

型 C：発注側の名義で、サービスアカウントのキーを使う

型 B の変形で、個人に紐づかないサービスアカウントでキーを発行する。9 月 15 日の統制設定で、「サービスアカウントのキーしか作らせない」と組織側で固定できるようになったのはこの型である。

• 担当者の異動・退職でキーの持ち主がいなくなる状態を避けられる
• 本番運用まで進む案件では、最終的にここへ寄せることになる

どの型が正しいという話ではない。 PoC の段階で型 A を選ぶのは合理的だし、本番で型 C に寄せるのも自然だ。問題は、見積書にこの区別が書かれていないまま進み、運用フェーズで初めて表に出ることである。

運用費の考え方そのものは AI開発の運用費・ランニングコストの実態 に、実費を誰が持つかで契約がどう分かれるかは AI運用費は定額保守か従量精算か にまとめている。

止まるのは「引き継ぎ」の場面

有効期限が付いたキーで実際に困るのは、開発中ではない。開発が終わったあとである。よくある 3 つの場面を挙げる。

1. 保守会社を切り替えるとき。 型 A で作った場合、キーは前の開発会社のアカウントにある。新しい会社に引き継ぐには、別アカウントでキーを取り直し、環境変数を入れ替え、接続確認をやり直すことになる。ここは追加費用として見積もられる工程で、作業自体は小さくても、切り替えの判断が遅れる理由になる。

2. 担当者が異動したとき。 個人に紐づくキーは、その人の権限がなくなった時点で扱いが不安定になる。サービスアカウントへ寄せていれば起きない。9 月 15 日の統制設定は、この状態を組織のルールとして禁止できるようにしたものと読める。

3. 期限が切れたとき。 最大有効期間を組織で強制している場合、後継のキーを用意しないまま期限を迎えると、動いていた機能が突然止まる。止まるのはたいてい平日の朝で、原因の特定に半日かかる。

3 点とも、契約前に 1 行決めておけば発生しない種類の停止である。逆に言えば、決めていなければ確実にいつか起きる。引き継ぎ時の確認項目は AI開発の引き継ぎ。保守移行で確認する12項目 にあるので、そこへ「API キーの名義と有効期限」を足しておきたい。

見積書と契約で確認する 3 点

今回の件で増やすべき確認項目は 3 つだけである。すべて見積書の「API 利用料」の行の周辺で聞ける。

1. 名義はどちらか（型 A / B / C のどれか）

「API の契約は御社名義ですか、弊社名義ですか」と聞く。型 A なら、契約終了時にどう移すかまで続けて聞く。ここで具体的な手順が出てこない会社は、移行を想定していない。

2. キーの有効期限と、切り替えの責任者

期限を設定するのか、するなら何日か、期限前の入れ替えは保守範囲に入っているのか。入っていない場合、期限切れの停止は誰の責任になるのかを決めておく。公式ドキュメントが推奨する手順（後継キーを作る → 更新する → 古い方を失効させる）は数十分の作業だが、担当が決まっていないと誰もやらない。

3. 支出上限と通知は設定されているか

ワークスペース単位・プロジェクト単位の支出上限は、提供元側の機能として用意されている。上限を設定しないまま従量課金で運用するのは、請求が届くまで金額が分からない状態を選んでいることになる。想定外の利用が発生したとき、上限があれば止まるだけで済み、なければ請求になる。

セキュリティ面での設計全般は AIシステムのセキュリティ設計 で扱っている。今回の話は、その中でも費用に直結する部分だと考えてよい。

受け取った見積書の「API 利用料」に内訳がなく、判断がつかない場合は、見積書チェックで相場と共通の指標に当てて確認できる。これから発注する段階であれば、費用診断で分野とフェーズごとの目安を出したうえで、名義の型を先に決めておくと、運用フェーズでのやり直しを避けられる。

まとめ

• 2026年9月10日、OpenAI のプロジェクト API キーに有効期限が設定できるようになり、組織・プロジェクト単位で最大有効期間を強制できるようになった
• 2026年9月15日、キー発行の統制設定が追加され、「サービスアカウントのキーのみ」「利用者個人のプロジェクトキーのみ」「新規発行を禁止」から選べるようになった。組織の設定がプロジェクトに優先し、発行済みのキーには影響しない
• Anthropic 側もキーはワークスペースに紐づいて移動できず、期限・支出上限・レート制限をワークスペース単位で持つ。「期限と持ち主が付いた貸出物」という前提は提供元をまたいで共通になりつつある
• 発注側にとっての論点は機能そのものではなく、API を誰の名義で契約するか。型 A（開発会社名義）・型 B（自社名義で貸与）・型 C（自社名義のサービスアカウント）で、請求先と引き継ぎの難易度が変わる
• 止まるのは開発中ではなく引き継ぎのとき。保守会社の切り替え・担当者の異動・期限切れの 3 場面は、契約前に 1 行決めておけば起きない
• 見積書で聞くのは 3 点。名義はどちらか / 期限の入れ替えは保守範囲か / 支出上限と通知は設定されているか

参考・出典

• OpenAI API Changelog（OpenAI 公式開発者ドキュメント）— 2026年9月15日「API キー発行の統制設定」、2026年9月10日「プロジェクト API キーの有効期限と最大有効期間の強制」の各項目
• OpenAI「Production best practices」API keys 節（OpenAI 公式開発者ドキュメント）— 有効期限の設定と定期的なキー入れ替えの推奨、入れ替え手順、組織レベルの設定がプロジェクトに優先する旨、既存キーは対象外である旨
• Claude Console のワークスペース管理（Anthropic 公式ヘルプセンター）— API キーはワークスペースに紐づき移動できない旨、ワークスペース単位の支出上限・レート制限・支出通知
• Claude API 管理 API リファレンス（Anthropic 公式ドキュメント）— API キーの有効期限（expires_at）とスコープの扱い
• 「API Key Best Practices」（Anthropic 公式ヘルプセンター）— 一定周期でのキー入れ替えの推奨