2026年4月29日時点で、OpenAI Platform APIキーは作成だけなら無料で始められる。しかし、そのキーで公式APIを無料無制限に呼び出せるわけではない。実際にリクエストを通すのは、キーそのものではなく、organization、project、billing、credit、model access、usage limit、rate limit の組み合わせである。
| ルート | アカウントまたはkeyの所有者 | 支払い元 | 安全な用途 | 先に確認すること |
|---|---|---|---|---|
| OpenAI Platform API | 自分のOpenAI organization/project | API billing、credit、prepaid balance | 本番APIと小さな公式テスト | billing、model access、usage limit、rate limit |
| ChatGPTアプリ利用 | 消費者向けアプリのアカウント | Free、Plus、Pro、workspace quota | 手動利用。backend APIではない | アプリplanはAPI請求にならない |
| Trial credit | 対象Platformアカウント | creditを先に消費し、後で有料に移る可能性 | 短い公式テスト | 残高、期限、対象モデル、課金fallback |
| Provider route | 第三者provider | provider credit、plan、またはprovider請求 | 条件が明確な非機密評価 | owner、価格単位、データ条件、limits、support |
| User-pays route | SDK/platformと各end user | 実行時にend userが負担 | ユーザーがsessionや支払いを持ち込む設計 | consent、privacy、abuse control、rate limit |
| 無料open-weight model | host、community、自分のinfra | host、community、または自分 | OpenAI API権利ではなく低リスク実験 | model identity、host limits、context、data policy |
| copied key / generator | 不明または流出した所有者 | 不明。多くは他人のアカウント | 拒否 | key ownership、billing risk、logs、malware、policy risk |
停止ルールは明確だ。keyの所有者、無料後の支払い元、適用されるlimits、promptとoutputのterms、failure supportが見えないルートは、実データや本番コードに接続しない。公式ルートを使うなら、自分のPlatform keyを作り、billingまたはcreditを確認し、低いusage limitを設定し、最小リクエストを1回だけ送ってusageを確認する。
APIキーは認証情報であって、quotaではない
OpenAI Platform APIキーは、特定のorganizationやprojectの中でリクエストを認証するためのsecretである。キーを新しく作っても、独立した無料枠、隠れたbudget、別のmodel accessが生まれるわけではない。project、role、billing、credit、model access、usage limit、rate limitが実際の可否を決める。
そのため、作ったばかりのキーでもエラーになる。secretは正しくても、projectに使えるcreditがない、billingが未設定、modelが許可されていない、spend capに達している、rate limitを踏んでいる、という状態ならリクエストは止まる。key rotationはsecurityのために必要だが、quotaを増やす方法ではない。
実装では OPENAI_API_KEY をserver-sideの環境変数やsecret managerに置く。frontend bundle、公開repo、screenshot、共有notebook、browser extensionには入れない。team環境では、どのprojectがどのkeyを所有し、どのbillingに結びつくかを明記する。
projectごとのroleも重要だ。あるmemberがproject Aでkeyを作れても、project Bのresourceにはアクセスできないことがある。service account keyも権限を絞り、定期的に確認する。localでは動くのにproductionで失敗する場合、まずowning project、role、billing、limitsを確認する。
何が無料で、どこから有料なのか
無料なのはkeyの作成であって、API利用の権利ではない。dashboardでsecretを作ることと、そのsecretでmodelを呼び続けられることは別の問題である。公式の価格はOpenAIのpricing surfaceが持つ。model、input、output、image、audioなどで単位が変わるため、一般的な「公式API無料無制限」という説明は契約として足りない。
Prepaid billingも誤解されやすい。OpenAI Helpは、APIユーザーがusage creditを事前購入する仕組みとしてprepaid billingを説明しており、現在の最小購入額は5米ドルとされている。これは低コストの公式開始点であり、無料無制限の権利ではない。
trial creditやpromotion creditはaccount-specificで、期限や対象modelが変わる。自分のPlatform billing pageで残高、expiry、allowed model、paid fallbackを確認し、日付を残して判断する。古いblogや動画のcredit額を現在の契約として扱わない。
rate limitとusage limitも分ける。rate limitはrequestやtokenの流量を制御し、usage limitは費用を制御する。エラーのownerがbillingなのか、model accessなのか、permissionなのか、rateなのかによって修正は変わる。新しいkeyを作るだけでは、多くの問題は解決しない。
ChatGPTアプリ利用とAPI billingは別のsurface
ChatGPTアプリのFree、Plus、Pro、workspace accessは、手動利用のためのsurfaceである。OpenAI Platform APIは、アプリケーションが認証、請求、logging、retry、failure handlingを行うdeveloper surfaceである。両者は似たmodel名を共有していても、billingとlimitsは同じものではない。
アプリで使えるmodelが、コードから無料で使えることを意味しない。反対に、API creditがあっても、ChatGPTアプリのmessage capやplan機能が変わるわけではない。手動作業ならアプリ、backend integrationならPlatform API、という分け方を最初に固定する。
社内ツールや顧客向け機能では、この分離を設計書にも書くべきだ。どのrouteが人間の操作で、どのrouteがserver callなのか。どこで課金され、どこでusageが記録され、どのerrorを誰が処理するのか。ここを曖昧にしたままkeyだけ配ると、quota、billing、supportがあとで混ざる。
無料に見える代替ルートを分類する
Provider routeは役に立つことがある。trial credit、compatible endpoint、playground、model aliasを提供し、短い評価を早く始められる。ただし、そのrouteではproviderが価格単位、model mapping、logs、data terms、rate limits、failure handling、supportを持つ。これはprovider evaluationであり、OpenAI公式creditではない。
User-pays routeも別物である。end userが自分のsession、account、quota、paymentを持ち込む設計なら、developerの集中請求は下がるかもしれない。しかしユーザーの同意、privacy、abuse control、quota切れ時の表示、support責任が必要になる。全体として無料ではなく、payerが移動しているだけだ。
無料open-weight modelは、低コスト実験やself-hostingのための選択肢である。OpenAI APIと同じcontract、support、model behavior、data handlingを期待するものではない。model identity、context window、host limits、data policyを確認してから使う。
Copied key、generator、無owner wrapperは本番で使わない。1回動くことは、permission、billing ownership、data safety、durability、supportを証明しない。むしろ、他人のcredentialを使っている可能性、prompt leakage、malware、突然のrevoke、請求トラブルを示す警告である。
最小の公式テスト手順
公式routeで最初に行うテストは小さくする。正しいorganizationとprojectを選び、secret keyを作成し、環境変数またはsecret managerに保存し、billingまたはcreditを確認し、project usage limitを低く設定し、有効な低コストmodelに最小promptを送る。
その後、usage pageで想定したprojectに記録されたかを確認する。失敗した場合は、error ownerを読む。billing、quota、model access、permission、rate limitはそれぞれ修正先が異なる。key自体が漏洩していない限り、同じprojectでkeyを作り直しても根本は変わらない。
production前には、server-side secret、budget alertまたはlow cap、quota/billing failureの表示、logging、support pathを用意する。最初のpayloadは非機密にし、data retentionやprivacyの判断を済ませてから実データに進む。
判断ルール
公式docs、直接API behavior、project control、billing visibility、production ownershipが必要ならOpenAI Platform APIを選ぶ。人間が手動で使うだけならChatGPTアプリで足りる。Provider routeはowner、payer、limits、terms、supportがリスクに見合うほど明確なときだけ使う。User-pays routeは、製品が明示的にユーザーの支払いと同意を前提にしているときだけ使う。無料open-weight modelは、低コスト実験のためであって、OpenAI API entitlementの代替名ではない。
Copied keyとgeneratorは拒否する。費用の問題を、security、privacy、billing、reliabilityの問題に変えるだけである。
よくある質問
OpenAI APIキーは無料で作れる？
作成は無料でできる場合がある。しかしAPI利用はbilling、credit、model access、project permission、usage limit、rate limitに左右される。keyは無料無制限の利用権ではない。
ChatGPT PlusやProにはAPI creditが含まれる？
自動では含まれない。ChatGPTアプリ利用とPlatform API billingは別である。アプリplanはbackend API callの支払いにはならない。
Trial creditは誰でも同じ？
同じではない。自分のPlatform billing pageでbalance、expiry、allowed models、paid fallbackを確認する。古いcredit情報を現在の前提にしない。
Providerの無料endpointは公式OpenAI無料API？
違う。Provider routeは別契約であり、price unit、limits、data terms、supportをproviderが持つ。評価には使えても、公式OpenAI creditとは呼ばない。
GitHubの無料keyは安全？
安全ではない。公開keyやgeneratorは、所有権、permission、billing control、data safetyを証明しない。productionや機密promptには使わない。
quota exceeded が出たら何を見る？
project billing、credit、model access、usage limit、rate limitを確認する。同じprojectでkeyを増やしても、多くの場合は同じ制限に当たる。
