3行まとめ
Students、Codex for Open Source、追加credits、Fast modeは条件と使える場所が違います。
Students offerはCodex用のChatGPT creditsであり、API creditsとして見積もるものではありません。
workspace creditsでは購入者、残高確認者、Fast modeの初期値、停止条件を先に決めます。
金額だけで判断せず、対象条件と運用責任を先に確認すると混乱を減らせます。
- Codexの無料クレジット情報を見るときは、まずStudents、Codex for Open Source、追加credits、Fast modeを分けます。対象者、使える場所、失効、購入可否が違います。
- 2026年6月17日JSTに公式情報を確認した範囲では、Students offerは米国またはカナダの対象学生向けで、ChatGPTアカウントに付くCodex用creditsです。API creditsとして扱うものではありません。
- チームで使うなら、追加購入の前に、workspace creditsの購入者、残高確認者、Fast modeの初期値、上限到達時の停止条件を決めておくほうが安全です。
SNSでCodexのクレジットや無料枠の話題が流れてくると、つい「自分も今すぐ受け取れるのか」「API利用も無料になるのか」と見てしまいます。けれど実務で大事なのは、金額の大きさよりも、対象条件と使える場所です。
この記事では、Xでの反応は需要シグナルとしてだけ扱い、本文の根拠はOpenAI公式のStudents、Codex for Open Source、Pricing、Speed、Help Center、Service Credit Termsに限定します。公式ページは更新され得るため、申請や購入の直前には必ず最新表示を確認してください。
この記事でわかること
日本の学生にそのまま使える話か、地域条件と学生認証を確認します。
Codex for Open Sourceを無料配布ではなく、maintainer向けの申請制度として読みます。
Plus/Proの個人購入とBusiness/Edu/Enterpriseのworkspace creditsを分けます。
速度を買う場面だけ、倍率込みで使うかを判断します。
失効、返金、譲渡、残高確認の責任を購入前に確認します。
この記事は使い方の手順ではなく、公式条件を読むための判断材料に絞っています。
- Students offerが日本の学生にそのまま使える話なのか
- StudentsのcreditsとAPI creditsを分ける理由
- Codex for Open Sourceを無料配布ではなく申請制度として見る理由
- Plus/Proの追加creditsとBusiness/Edu/Enterpriseのworkspace creditsの違い
- Fast modeを常時ONにせず、倍率込みで判断する考え方
- Service Credit Termsで見る失効、返金、譲渡、残高確認
- チーム導入前に決める購入者、承認者、利用上限、停止条件
すでにCodexを使い込んでいて、支出の暴走を止めたい場合は、先にCodexの使いすぎを防ぐ前に決めることを読むと流れがつかみやすいです。この記事は、使い方そのものよりも、公式のクレジット条件を読むための入口に絞ります。
前提知識: creditという言葉を1つにまとめない
無料枠ほど、対象地域、本人確認、アカウント種別、利用期限、API利用可否を先に読みます。
Codexまわりで出てくるcreditは、全部同じ意味ではありません。学生向けのChatGPT credits、OSS maintainer向けの支援制度、利用上限後に追加で買うcredits、Fast modeで消費倍率が変わるcreditsを混ぜてしまうと、導入判断を間違えます。
4種類を別々に見る
まずは、次の4つに分けてください。
| 種類 | 最初に見ること | 誤解しやすい点 |
|---|---|---|
| Students offer | 対象地域、学生認証、ChatGPTアカウント | 学生なら誰でも使える、API creditsになると考えてしまう |
| Codex for Open Source | maintainerか、public projectか、申請理由 | OSSなら自動でもらえる無料枠だと考えてしまう |
| 追加credits | 個人planかworkspaceか、誰が買うか | Plus/Proなら全員同じ条件で買えると考えてしまう |
| Fast mode | 対応モデル、倍率、使う場面 | 速度だけ上がり、予算には効かないと考えてしまう |
2026年6月17日時点の公式Pricingでは、Codexのcredit usageはtoken-based ratesに基づき、input tokens、cached input tokens、output tokensに応じて消費されると説明されています。つまり「1メッセージいくら」と固定して読むより、モデル、入力量、出力量、タスクの重さで変わるものとして扱う必要があります。
無料枠の話ほど対象外条件を先に読む
無料枠や支援制度は、魅力的に見えるほど対象外条件を先に読むべきです。対象地域、本人確認、アカウント種別、利用期限、譲渡可否、API利用可否が合っていなければ、社内説明や個人の予算計画には使えません。
特に日本語圏の読者は、海外向けの学生プログラムをそのまま自分に当てはめないほうが安全です。公式ページに地域条件がある場合、その条件を満たすかを先に確認してください。
結果: Students offerは日本在住なら対象条件を慎重に見る
- 1地域条件
claim時点で米国またはカナダに居住している学生が対象とされています。
- 2在籍条件
米国またはカナダのdegree-granting universityに在籍し、学生認証が必要です。
- 3付与内容
Codexに使うChatGPT creditsであり、API creditsではないと確認します。
- 4期限
付与されたcreditsはgrant dateから12か月で失効します。
- 5代替案
対象外なら、通常plan、追加credits、API billing、チーム契約に切り替えて考えます。
Students offerをAPI検証費用として見積もると、請求や予算説明で混乱しやすくなります。
OpenAIのCodex for Studentsページでは、対象は米国またはカナダのdegree-granting universityに在籍し、claim時点で米国またはカナダに居住している学生と説明されています。成功した学生認証が必要で、1人1回のofferです。
もらえるのはCodex用のChatGPT credits
条件
Students offerで付与されるのは、Codexに使うChatGPT creditsです。公式FAQでは、API creditsではないと説明されています。付与後はChatGPTアカウント側に反映され、Codexで利用できます。
公式FAQでは、offer適用後に2,500 credits、金額換算で100ドル相当が表示されると説明されています。creditsはgrant dateから12か月で失効します。
日本の学生が最初に見るチェックリスト
確認項目
申請前に見る順番は、このくらい具体的で十分です。
| 確認項目 | 見る理由 |
|---|---|
| 米国またはカナダの対象大学に在籍しているか | 公式の地域条件に関わる |
| claim時点で米国またはカナダに居住しているか | 日本在住なら対象外の可能性が高い |
| 学生認証を通せるか | 成功したverificationが必要 |
| ChatGPTアカウントで使う予定か | personal ChatGPT accountでもclaim可能だが、API creditsではない |
| 12か月以内に使う見込みがあるか | 未使用のまま期限を迎える可能性がある |
ここで無理に抜け道を探す必要はありません。対象外なら、Students offerを前提にした予算計画をやめ、通常のincluded usage、追加credits、API key利用、チーム契約のどれで考えるかに切り替えます。
失敗点: API検証費用として見積もってしまう
学生向けcreditsをAPI creditsと混同すると、検証計画が崩れます。たとえば、CI上の自動レビュー、独自CLI、社内bot、MCPサーバー経由の検証にAPI key課金を使う場合、Students offerをそのまま費用源にできるとは限りません。
個人のCodex利用を延ばすcreditなのか、API経由の検証に使えるcreditなのか。この区別をメモに残しておくと、あとで「無料と聞いたのに請求が出た」という混乱を減らせます。
Codex for Open Sourceはmaintainer向けの申請制度として見る
- 1対象project
core maintainerか、広く使われるpublic projectを運営しているかを確認します。
- 2説明する役割
エコシステム上の役割、保守作業、Codexを使うworkflowを説明できる形にします。
- 3benefits
Codex access、Codex Security access、API creditsを別々のbenefitとして見ます。
- 4追加条件
Codex Security accessやAPI creditsは追加審査や追加条件が必要になる場合があります。
- 5権限範囲
所有していない、またはreview権限のないrepositoryやsystemには使いません。
採択や付与内容に依存するため、個人の常用予算として固定的に見積もるのは避けます。
Codex for Open Sourceは、OSSなら誰でも自動でもらえる無料枠ではありません。公式ページでは、open-source maintainersがapplyできる制度として説明されています。
core maintainerか、広く使われるpublic projectか
根拠
公式ページは、core maintainerまたはwidely used public projectを運営しているならapplyするとよい、と案内しています。基準にぴったり合わなくても、エコシステム上の役割を説明できるなら申請できる余地はあります。
実務的には、次を説明できるかで判断します。
| 確認項目 | 申請前に言語化すること |
|---|---|
| maintainer権限 | 自分がそのrepositoryを保守している根拠 |
| public project性 | 利用者、依存関係、配布経路、コミュニティ |
| Codex利用目的 | PR review、maintainer automation、release workflowなど |
| security coverage | Codex Securityが必要な理由と対象repository |
| 権限の正当性 | 自分がreviewやscanを許可されている範囲 |
Program Termsでは、Codex Security accessやAPI creditsはoptionalで、追加審査や追加条件が必要になる場合があるとされています。また、所有していない、またはreview権限のないrepositoryやsystemをscan、probe、test、reviewする用途には使えません。
benefitsを3つに分ける
注意点
Codex for Open Sourceのbenefitsは、1つの無料枠としてまとめないほうが読みやすいです。
| benefit | 見方 |
|---|---|
| six months of ChatGPT Pro with Codex | maintainerの日常的なcoding、triage、review、workflow用 |
| conditional access to Codex Security | deeper security coverageが必要なrepository向けで、case by case |
| API credits through Codex Open Source Fund | PR review、automation、release workflowなどのcore OSS work向け |
この3つは、対象、審査、使い道が違います。「OSS Fundに通れば何でも無料」とは書けません。社内やコミュニティに説明するなら、申請したbenefit、対象repository、使うworkflow、利用者、終了後の運用を別々に残します。
失敗点: OSS支援を個人の常用予算にしてしまう
OSS向けの支援制度を、個人の常用予算として見積もるのは危険です。採択されるか、どのbenefitが付くか、いつまで使えるか、追加条件があるかは、申請と審査に依存します。
OSS maintainerなら、支援制度を「当たれば助かる枠」として見るより、保守作業のどこにCodexを使うとprojectに効くかを先に書くほうが建設的です。PR reviewを早くするのか、release workflowを安定させるのか、security reviewを厚くするのか。目的が曖昧なまま申請しても、運用に残りません。
追加creditsは個人購入とworkspace購入を分ける
購入額だけでなく、誰が承認し、どの作業に使い、どこで止めるかまで含めて決めます。
CodexのPricingとHelp Centerでは、planごとにusage limitsやcredit optionsが異なると説明されています。PlusやProの一部ユーザーは追加creditsでCodex利用を続けられる場合があり、Business、Edu、Enterpriseではflexible pricingのworkspace creditsが関係します。
Plus/Proは自分の作業継続用として見る
個人利用の確認項目
個人のPlus/Proで追加creditsを考えるときは、まずCodex usage pageやlimit bannerを確認します。Help Centerでは、limitに近づいた、または到達した場合に、planで使える選択肢を確認するよう案内されています。
ここで決めることは、単純な購入額ではありません。
| 確認項目 | 判断 |
|---|---|
| 何の作業を続けたいか | 途中のbugfix、review、調査などを分ける |
| いつまでに必要か | 今日中に必要か、resetを待てるか |
| どのモデルで続けるか | 軽いモデルへ切り替える余地があるか |
| どこで止めるか | 追加creditsを何回まで買うか |
| 記録を残すか | 次回の見積もりに使えるか |
個人開発では、勢いで追加購入しやすいです。だからこそ、購入前に「この作業は今止められないのか」「標準速度でよいのか」「小さい依頼に分割できないか」を一度見るだけで、後悔が減ります。
Business/Edu/Enterpriseはworkspace管理の話になる
チーム利用の確認項目
チームや法人では、追加creditsは個人の財布の話ではなく、workspaceの管理問題になります。Business、Edu、Enterpriseでflexible pricingを使う場合、workspace creditsを誰が買い、誰が使い、誰が残高を見るのかを決める必要があります。
最低限、次を決めておきます。
| 項目 | 決めること |
|---|---|
| 購入者 | 管理者、経理、開発責任者のどこに置くか |
| 承認条件 | 何円相当または何credits相当から事前承認にするか |
| 利用範囲 | local messages、cloud tasks、code reviews、API key利用を分けるか |
| 残高確認者 | 週次または月次で誰がusageを見るか |
| 上限到達時 | 追加購入、軽いモデル、作業停止、翌window待ちのどれにするか |
| 監査メモ | 何のproject、何のtask、どの成果に使ったか |
このあたりは、AIコーディングツール料金改定の見方で扱った横断比較ともつながります。Codex単体のcredit条件を読みつつ、最終的にはチーム全体の席数、agent作業量、レビュー工数まで含めて判断します。
token-based creditsはタスクの重さで変わる
上振れと下振れ
Pricingでは、Codex credit usageがinput、cached input、output tokensに応じて計算されると説明されています。rate card上では、2026年6月17日時点で、GPT-5.5、GPT-5.4、GPT-5.4 miniなどのcredits per 1M tokensが示されています。
ここで重要なのは、表の数字を丸暗記することではありません。大きいrepositoryを読ませる、長いログを貼る、何度も再試行する、出力に長い差分や説明を求める、cloud taskやreviewを多用する。こうした条件で消費は上振れします。
逆に、AGENTS.mdを整える、作業範囲を小さくする、不要なMCP serverを切る、ログを要約して渡す、軽いモデルを使う、Fast modeを必要な場面だけにする、といった運用で消費を下げられる場合があります。
Fast modeは急ぎの作業だけ倍率込みで使う
常時ONにすると、あとからcredit消費の理由を説明しにくくなります。
Codex Speedページでは、Fast modeはsupported modelの速度を上げる代わりに、standardより高いrateでcreditsを消費する設定として説明されています。2026年6月17日時点では、GPT-5.5はStandard rateの2.5倍、GPT-5.4は2倍とされています。
常時ONではなく、待ち時間が高い作業に使う
判断基準
Fast modeを入れる価値があるのは、開発者の待ち時間そのものが高い場面です。
| Fast modeを検討する場面 | Standardを基本にする場面 |
|---|---|
| 障害対応中の修正案確認 | 低優先度のdocs修正 |
| release直前の短いreview | 長時間の探索や調査 |
| CI失敗の原因を急いで切り分ける | 大きな再試行ループ |
| 人間が待機しているpair作業 | 夜間に任せる非同期作業 |
Fast modeは、速いから良いというより、時間短縮の価値が倍率を上回るときに使うものです。普段から常時ONにしてしまうと、あとから「なぜcreditが減ったのか」を説明しにくくなります。
CLI、IDE extension、Codex app、API keyの違いを見る
設定メモ
公式Speedページでは、CLIの/fast on、/fast off、/fast statusで設定できること、config.tomlでdefaultを永続化できることが説明されています。Codex IDE extension、Codex CLI、Codex appでChatGPT sign-inしている場合に利用でき、API key利用時はFast mode creditsではなくstandard API pricingになる点も確認が必要です。
チームでは、Fast modeの初期値を明文化しておくと運用しやすくなります。
Fast mode policy example
- default: off
- allowed: production incident, release blocker, time-boxed review
- not allowed by default: long research, broad refactor, overnight automation
- owner: task requester
- evidence: reason, command or surface, expected time savingこのような軽いルールで十分です。禁止したいわけではなく、いつ速さを買うのかを後から説明できる形にします。
Service Credit Termsで失効、返金、譲渡を確認する
法務・契約に近い領域なので、社内では購入者、利用者、残高確認者、月次確認を明確にします。
Service Credit Termsは法律・契約に近い文書なので、この記事では法的助言ではなく、購入前の確認項目として扱います。OpenAIのService Credit Termsは2026年1月1日更新と表示されており、Service Creditの性質、返金、失効、譲渡、残高確認について説明しています。
service creditsは通貨でもwalletでもない
契約上の見方
Termsでは、Service Creditsは法定通貨ではなく、返金や金銭価値への交換ができるものでもなく、指定されたServiceに関連してのみ使われるものとされています。残高はbank account、digital wallet、stored value accountではありません。
この点は、チーム予算で重要です。未使用creditsを「会社の資産として後で自由に移せる」と見るより、指定サービスの利用権に近いものとして扱うほうが安全です。
原則として払い戻し不可、1年で失効、譲渡不可
Termsでは、prepaid Servicesを含むServiceのsalesはfinalで、Service Creditsは法律で必要な場合を除いて払い戻し不可とされています。また、購入または発行から1年で失効すると説明されています。ただし、購入時に別の指定がある場合は、その指定も確認します。
譲渡、販売、贈与、取引も認められていません。team導入では、退職者、部署異動、project終了、未使用残高の扱いを先に決めておくと、後から揉めにくくなります。
残高確認は利用者側の責任として扱う
チームの確認項目
Termsでは、正しいamountが残高に追加または差し引かれているかを確認する責任は利用者側にあるとされています。つまり、購入したら終わりではありません。
小規模チームでも、最低限これだけは決めておきます。
| 項目 | 担当 |
|---|---|
| purchase approval | 開発責任者または管理者 |
| balance check | 週次で1名 |
| usage review | 月次でproject owner |
| incident escalation | 想定外の消費が出たときの連絡先 |
| expiry review | 四半期ごとに未使用残高を見る |
ここを決めないままcreditsを足すと、使い切った後に初めて原因調査が始まります。AIコーディングの費用は、便利だからこそ遅れて見えます。
実務で使うなら、購入前に小さく測る
- 代表タスクを選ぶ
普段の修正、review、調査、長めの作業など4本だけ選びます。
- 条件を固定する
Fast mode、利用surface、渡すログやrepository範囲を記録します。
- 増え方を見る
大きな入力、広い依頼、再試行、長い出力でどれだけ上振れするかを見ます。
- 運用を直す
購入より先に、停止条件、依頼の分割、secretなしの検証を整えます。
pilotの目的は絶対額を当てることではなく、何をすると増えるのかを説明できるようにすることです。
Codexのcreditは、作業の大きさに左右されます。最初から月間予算だけを決めるより、代表タスクを4本だけ走らせて、どこで重くなるかを見たほうが判断しやすいです。
代表タスク4本で見る
| タスク | 見ること |
|---|---|
| 小さなbugfix | local messageでどれくらい往復するか |
| PR review | code reviewや説明出力がどれくらい長くなるか |
| test repair | 失敗ログ、再試行、検証commandで消費が増えるか |
| 長めの調査 | context保持、file探索、要約でどれくらい伸びるか |
この検証では、絶対額の正確さよりも「何をすると増えるのか」を見るのが目的です。大きなログをそのまま貼ると増える。範囲の広い依頼をすると増える。Fast modeを入れると倍率が乗る。こうした上振れ条件がわかれば、購入前の社内説明が現実的になります。
導入しないほうがよいケース
次の状態なら、credits追加より先に運用を整えたほうがよいです。
- 誰が購入してよいか決まっていない
- Fast modeの初期値が決まっていない
- 長時間タスクの停止条件がない
- API key利用とChatGPT sign-in利用を混ぜている
- private repositoryや顧客データを扱う境界が曖昧
- usage pageやworkspace残高を見る担当がいない
- 失敗したtaskを再試行し続ける癖がある
こうした場合は、追加creditsを入れても効果が出にくいです。まずはCodexでGoalを立てる前に決めることやCodexの長い作業を再開する前に決めることで、完了条件と再開条件を整理してください。
セキュリティ・コスト注意
private repository、顧客データ、API key、個人情報、未公開脆弱性を不用意に渡しません。
自分がmaintainし、許可を持ち、説明責任を持てる範囲に限定します。
individualまたはworkspace creditsとして、Codex利用のbudgetを分けて管理します。
API project billingとして、ChatGPT側のcreditsとは別に扱います。
想定より大きい消費は失敗ではなく、次の運用改善の観測対象として扱います。
予算管理はagentを弱くするためではなく、人間が安心して任せられる範囲を作るためのものです。
creditの話は料金だけに見えますが、実務ではセキュリティとセットです。安く長く使えるほど、agentに渡す範囲も広がりがちだからです。
private repositoryとsecretを無料枠で試さない
Students offerやOSS支援の有無に関係なく、private repository、顧客データ、API key、個人情報、未公開脆弱性を不用意に渡してはいけません。検証では、公開可能なsample repository、dummy secret、再現用ログを使います。
OSS programでも、Program Termsは権限のないrepositoryやsystemをscan、probe、test、reviewする用途を認めていません。自分がmaintainしている範囲、自分が許可を持つ範囲、自分が説明責任を持てる範囲に限定します。
API key利用とChatGPT sign-in利用を混ぜない
Codexの使い方には、ChatGPT sign-inで使うsurfaceと、API keyを使うlocal tasksがあります。Pricingでは、API keyでextra local tasksを走らせる場合、standard API ratesで課金されると説明されています。
ここを混ぜると、どのcreditsが減ったのか、どのbudgetから出たのか、誰が承認したのかが曖昧になります。チームでは、少なくとも次のように分けます。
Budget boundary
- ChatGPT sign-in Codex: individual or workspace credits
- API key Codex local tasks: API project billing
- OSS program benefits: approved maintainer workflow only
- Student credits: personal ChatGPT account for Codex, not API credits料金の上振れは失敗ではなく観測対象にする
最初のpilotでcredit消費が想定より大きくなっても、それだけで失敗ではありません。原因を分けられれば、次の運用に活かせます。
| 上振れ原因 | 次に見ること |
|---|---|
| contextが大きすぎる | file範囲を絞る、調査と実装を分ける |
| 出力が長すぎる | report形式、差分形式、要約形式を指定する |
| 再試行が多い | 失敗ログを短く渡す、停止条件を置く |
| Fast modeを使いすぎる | default off、理由記録、対象タスク限定 |
| API key経由が混ざる | billing project、usage dashboard、ownerを分ける |
予算管理は、agentを弱くするためではありません。人間が安心して任せられる範囲を作るためのものです。
失敗点とハマりどころ
地域条件や学生認証を満たさない場合は、別のbudget前提に切り替えます。
Codex for Open Sourceは保守やエコシステムへの貢献を説明する申請制度です。
長い探索や再試行ループでは、credit消費の説明が難しくなります。
購入者、残高確認者、月次review、上限到達時の対応を明記します。
条件を読まないまま予算を組むと、あとから請求と説明の両方で詰まりやすくなります。
このテーマで一番多い失敗は、無料枠の数字だけを見て、条件を読まないことです。
「対象外でも後で何とかなる」と考える
Students offerの地域条件や学生認証を満たしていないのに、あとで通せる前提で予算を組むと崩れます。対象外なら対象外として、通常plan、追加credits、API billing、チーム契約のどれで進めるかに切り替えます。
「OSSならもらえる」と考える
Codex for Open Sourceは、projectの保守やecosystemへの貢献を説明する申請制度です。個人の学習、非公開project、権限のないrepository reviewを前提にしてはいけません。
「Fast modeは速いから常時ON」と考える
Fast modeは、速度を買う設定です。速度が必要な場面では強いですが、長い探索や大きな再試行ループではcredit消費の説明が難しくなります。
「残高は誰かが見ている」と考える
workspace creditsでは、誰かが見ているつもりが一番危ないです。購入者、残高確認者、月次review、上限到達時の対応を明記してください。
実務向けチェックリスト
- 1範囲を決める
代表タスク4本、secretなし、private dataなしで始めます。
- 2速度を決める
Fast mode default offを前提にし、必要な場面だけ理由を残します。
- 3購入を止める
最初のpilotでは追加購入なしにして、消費の増え方を観測します。
- 4残高を見る
usage reviewの担当を置き、誰が何を見たかを残します。
- 5次を決める
運用で下げられる消費と、planやcreditsで補う消費を分けて判断します。
小さく測ってから購入や上位planを考えるほうが、判断の筋が通ります。
最後に、申請や購入前のチェックリストとしてまとめます。
| 読者 | 最初に確認すること | 次の判断 |
|---|---|---|
| 日本在住の学生 | Students offerの地域条件 | 対象外なら通常planや追加creditsで考える |
| 米国/カナダの学生 | 学生認証、2,500 credits、12か月期限 | API creditsではないことを確認する |
| OSS maintainer | core maintainerか、public projectか | PR review、automation、release workflowなど使い道を説明する |
| 個人開発者 | usage page、limit banner、追加credits可否 | resetを待つか、軽いモデルか、追加購入かを決める |
| 小規模チーム | workspace creditsの購入者と残高確認者 | pilot 4タスクで消費傾向を見る |
| 法人導入担当 | flexible pricing、管理者、経理、監査 | securityとbudgetの承認フローを作る |
チーム導入で迷ったら、最初の1週間だけpilotにします。代表タスク4本、Fast mode default off、追加購入なし、secretなし、private dataなし、usage reviewあり。この条件で見てから、購入や上位planを考えるほうが、判断の筋が通ります。
更新履歴
- 2026年6月17日
Codex for Students、Codex for Open Source、Program Terms、Pricing、Speed、Help Center、Service Credit Termsを確認して初版を作成しました。
公式ページは更新され得るため、申請や購入の直前には最新表示を確認します。
- 2026年6月17日: OpenAI公式のCodex for Students、Codex for Open Source、Codex for OSS Program Terms、Codex Pricing、Codex Speed、Help Center、Service Credit Termsを確認し、初版を作成しました。
次に読むなら
更新通知をまとめて受け取りたい場合は、ニュースレターも使えます。AIコーディングツールの料金、権限、MCP、agent運用の変更点を追うときの入口にしてください。
参照した主な情報源
- https://developers.openai.com/community/students
- https://developers.openai.com/community/codex-for-oss
- https://developers.openai.com/codex/codex-for-oss-terms
- https://developers.openai.com/codex/pricing
- https://developers.openai.com/codex/speed
- https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan
- https://openai.com/policies/service-credit-terms