OpenAI APIを本番運用するときは、まず『どの業務をどのProjectに閉じ込めるか』を決め、そのうえで人が使う個人キーとシステムが使うService Accountを分けるのが基本です。Projectsは利用者、APIキー、モデル利用、予算アラート、保存されるリソースの境界になります。逆にこの境界が曖昧だと、部門別の原価配賦ができず、不要に強い権限を持つキーが残り、月末にどの処理がコスト超過を起こしたのかも追いにくくなります。先に結論を言うと、Projectは『請求と責任を分けたい単位』で切り、Service Accountは『自動処理だけに使う専用資格情報』として発行し、予算管理は alert だけで終わらせず hard limit の要否まで決めておくのが安全です。
結論: Projectは請求単位、Service Accountは自動処理単位で分ける
OpenAIのHelp Centerでは、Projectの目的を『作業を整理し、アクセス・制限・利用状況を管理するための単位』と説明しています。ProjectごとにAPIキーを発行でき、利用量や予算上限もProject単位で見られます。つまり営業支援ボット、社内検索、検証環境、顧客A向けの受託開発を同じProjectに入れると、誰が何にどれだけ使ったかが混ざります。実務では『1つの承認フローで予算を持つ単位』『同じ障害影響で止めてもよい単位』『同じメンバーにだけ見せたいデータの単位』の3条件で切ると運用しやすくなります。
Projectを分けるべき具体例
例えば、PoCは毎月の上限を低く抑えたい一方で、本番APIは停止コストが大きいため別Projectに分けるべきです。受託案件も顧客別に分けると、費用請求と利用証跡を説明しやすくなります。OpenAIの仕様では、files・threads・assistants などのリソースはProjectに閉じたスコープで管理され、基本的に他Projectへ持ち出せません。あとから分け直すと移行が重くなるので、『社内共通基盤』『案件別本番』『短期検証』の3系統だけでも最初に分離しておく価値があります。Default project は削除できず、メンバーやService Accountの扱いにも制約があるため、恒久運用の本番環境を何でもそこへ寄せる設計は避けた方が無難です。
Service Accountと個人キーは何が違うのか
Service Accountは擬似ユーザーとして扱われ、Projectに閉じた資格情報です。個人キーは担当者の異動や退職、権限変更の影響を受けますが、Service Accountはバッチ、Webhook、バックエンド処理のための固定した主体として管理できます。運用ルールとしては、ローカル検証や運用者の手動作業は個人キー、サーバー常駐処理や夜間ジョブはService Accountに寄せるのが分かりやすい整理です。さらにAPIキー権限は All、Restricted、Read Only を選べるため、管理系APIに触れないワーカーには Restricted を使い、不要なRead/Writeを落としておくと事故面積を縮められます。
予算上限はalertだけでなくhard limitの可否まで決める
OpenAIの最新developer docsでは、spend alert は通知専用、hard spend limit は上限到達後に対象トラフィックを止める制御として明確に分けられています。重要なのは、alertを設定しただけではAPIは止まらない点です。『超過は困るが本番停止はもっと困る』業務なら、まず80%・90%・100%のalertで監視し、夜間無人で暴走してはいけない検証環境だけhard limitを有効化する、という二段構えが現実的です。逆に本番系でhard limitを入れるなら、到達時に429 insufficient_quotaが返ること、停止解除まで更新反映の時間差があることを前提に、代替フローや手動復旧手順まで決めておく必要があります。
429停止を減らすにはrate limitとspend limitを分けて考える
429はすべて同じ意味ではありません。OpenAI docsでは、rate limitは組織単位とProject単位で適用され、モデルごとに上限が異なると説明されています。一方、spend limit由来の429は insufficient_quota で返り、予算または承認済み使用枠が原因です。現場ではこの2種類を混同しやすいため、障害一次対応のRunbookに『429のerror codeを確認する』『Projectの現在利用額とhard limitを照合する』『問題がrate limitならバースト制御、quotaなら上限変更か翌月待ち』を分けて書くべきです。監視ダッシュボードでも、リクエスト失敗率だけでなくエラーコード別の件数を分けると、開発と情シスで会話が噛み合いやすくなります。
最小構成の運用チェックリスト
導入初月は次の順で決めると迷いません。1つ目はProject分割方針です。部門別、顧客別、本番/検証別のどれを請求境界にするか決めます。2つ目は主体の分離です。人が使うキーと自動処理のService Accountを分け、用途名が分かる命名を付けます。3つ目は権限最小化です。全キーにAllを配らず、Restrictedで不要APIを閉じます。4つ目は予算監視です。alertの閾値、通知先、月次レビュー担当を決めます。5つ目は停止戦略です。本番はalert中心、検証はhard limit許容など、停止してよい業務を明文化します。6つ目は障害対応です。429発生時に誰がProject設定を確認し、どこまで増額できるかを事前に決めます。
まとめ: まずは3Project運用から始める
最初から細かく分けすぎると管理コストが増えるので、まずは『共通開発』『本番』『短期検証』の3Projectから始めるのがおすすめです。そのうえで、月次レビューで利用量と請求説明が難しい単位だけを独立させると、運用負荷を抑えながら監査性を上げられます。OpenAI APIはProjectごとにアクセス、利用量、予算、資格情報を整理できる前提があるため、設計の良し悪しはモデル選定より先に効きます。部門展開や顧客向け提供を見据えるなら、最初の数週間でProject境界とService Account方針を決めておく価値は十分あります。
導入設計や予算統制の整理が必要なら、HelloCraftAIが要件整理から運用設計まで伴走します。無料相談はお問い合わせページからどうぞ。
