3行まとめ
Business/Enterprise previewとして確認します。
誰が作成、公開、管理できるか分けます。
owner/adminから始めて段階的に広げます。
Sites panelで管理し、repoに入れません。
saved versionと本番公開を分けます。
社内ツール化は、生成能力ではなく運用境界で判断します。
- Codex Sitesは、CodexからWebサイトや軽量アプリを作成、保存、デプロイするpreview機能です。2026年6月11日時点では、ChatGPT BusinessとEnterpriseワークスペース向けに案内されています。
- 社内ツール用途で最初に見るべきなのは、生成能力よりも、RBAC、アクセス範囲、secrets、保存版と本番デプロイの分離、データ保存の扱いです。
- いきなり全社公開するより、owner/admin限定のpilotから始め、レビュー済みのsaved versionだけをデプロイ対象にする運用が現実的です。
Codex Sitesは、AIコーディングエージェントが「コードを書く」だけでなく、チーム内で使えるWeb画面まで作る方向に進んでいることを示すアップデートです。OpenAIの公式発表では、SitesはCodexの中でインタラクティブなWebサイトやアプリを作成し、チームへURL共有できる機能として紹介されています。
ただし、社内ツールとして見るなら「作れそう」だけでは判断できません。誰が有効化できるのか、作られたURLを誰が開けるのか、環境変数やAPIキーをどこに置くのか、保存した候補と本番デプロイをどう分けるのか。ここを曖昧にしたまま使い始めると、preview機能の便利さより先に、公開範囲とデータ管理の事故が起きやすくなります。
この記事では、2026年6月11日にOpenAIの公式ドキュメント、Help Center、release notes、rate cardを確認した範囲で、Codex Sitesを社内ツール用途で試す前の判断軸を整理します。Xやリアルタイム検索での反応は需要のシグナルとして見ましたが、本文の事実確認には使っていません。
この記事でわかること
preview機能は、事実確認と運用ルールをセットで見ます。
- Codex Sitesが、Codex appやpluginの中でどの位置づけにあるか
- ChatGPT BusinessとEnterpriseで、最初に確認すべき管理項目
- RBAC、access mode、workspace内部共有を分ける理由
.openai/hosting.jsonに入れてよい情報と、入れてはいけないsecrets- saved versionとproduction deploymentを分ける運用
- D1、R2、workspace-authenticated user identityを使う前のデータ分類
- preview機能を社内pilotに入れる場合の失敗条件
- 料金と利用量を、月額ではなくcreditsとtoken-based pricingで見る考え方
前提知識として、Codexそのものの導入判断をまだ固めていない場合は、先に<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-agent-selection-codex-claude-code-cursor-copilot-windsurf/">AIコーディングエージェントを比べる前に</a>で、Codex、Claude Code、Cursor、Copilot、Windsurfを比較する軸を確認しておくと読みやすくなります。この記事は、Codexをチームで使う可能性がある前提で、Sitesという新しい配布面に絞ります。
まず結論、社内ツール用途で見るべき5項目
使えるworkspaceか確認します。
管理者とroleの責任を決めます。
URLを誰が開けるか固定します。
APIキーをsourceに残しません。
deploy前にreviewを通します。
便利さより先に、公開と承認の境界を置きます。
合格ラインを先に置く
Codex Sitesを社内ツール用途で試すなら、最初の評価項目は機能一覧ではありません。次の5つを確認できない場合、本番業務の入口に置くのは早いです。
| 確認項目 | 見る理由 | 最初の運用 |
|---|---|---|
| 対象プラン | previewの対象外だと検証用workspaceを作れない | Business/Enterpriseのworkspace条件を確認する |
| 有効化権限 | 誰でも有効化できると管理外のサイトが増える | EnterpriseはRBAC、Businessはworkspace settingsを確認する |
| 公開範囲 | URL共有と社内アクセスの境界を誤ると情報が広がる | owner/admin限定から始める |
| secrets管理 | APIキーや社内システム接続情報がコードに残ると危険 | Sites panelでruntime valuesを管理する |
| デプロイ手順 | 生成されたものがそのままproduction URLになる | save versionとdeployを分ける |
公式ドキュメント上、Sites deployment URLはproduction deploymentとして扱われます。つまり、作成されたURLを「ちょっと見せるだけ」と軽く扱わないほうがよいです。レビュー前の共有、広いworkspace公開、secrets入りの差分を含むデプロイは、すべて同じリスクの線上にあります。
pilotでの初期判断
実務での結論は、次のようになります。
- 個人のメモや一時的なデモなら、Codex Sitesは試す価値があります。
- チームの業務に触れるなら、RBAC、アクセス範囲、データ分類、レビュー手順を決めてからpilotに入れるべきです。
- 顧客データ、契約情報、売上、個人情報、社内APIキーを扱うツールは、previewの段階でいきなり任せないほうが安全です。
Codex Sitesでできることと、まだ決め打ちしないこと
previewでは、短期pilotと長期運用を同じものとして扱いません。
OpenAIの公式発表では、Codex Sitesは、アイデア、分析、計画などをダッシュボード、プランナー、レビュー用ワークスペース、プロジェクトボード、ギャラリー、軽量ツールへ変換する用途として説明されています。開発者ドキュメントでは、CodexがSites pluginを使い、Webサイト、Webアプリ、ゲームを作成、保存、デプロイ、確認できるとされています。
相性がよい用途
社内ツール視点では、特に次の用途が相性よさそうです。
- 施策レビュー用の一時的なダッシュボード
- 問い合わせや作業依頼を一覧化する小さな受付ツール
- プロジェクトの進捗、論点、担当者をまとめる共有画面
- CSVや手元の分析結果を見せるための閲覧専用ビュー
- 社内勉強会や検証ログを見せるインタラクティブな資料
決め打ちしない用途
一方で、ここから先を決め打ちしないほうがよいです。
- 長期運用する基幹システムの置き換え
- 監査要件が強いワークフローの自動化
- 顧客向けの公開サービス
- 複雑な外部API連携を含む業務アプリ
- 社内の権限体系と完全に同期したID管理
理由は単純です。Sitesはpreviewであり、対象プラン、管理画面、利用可能なplugin、料金、地域制限、保存基盤の仕様が変わる可能性があります。軽量な社内ツールを速く作る入口としては魅力がありますが、組織の標準デプロイ基盤として扱うには、まだ運用設計を先に置く必要があります。
BusinessとEnterpriseで最初に確認する場所
使えるかどうかは、plan名だけでなくworkspace設定で決まります。
公式ドキュメントでは、Codex SitesはChatGPT BusinessとEnterpriseワークスペースでpreview提供され、今後ほかのプランにも展開予定とされています。ChatGPT Business release notesでは、BusinessワークスペースでCodex accessがある場合にSitesがpreview提供されると説明されています。
プラン別の確認観点
BusinessとEnterpriseでは、最初に見る場所が少し違います。
Businessで見ること
Businessでは、まずworkspace settingsでSitesの扱い、Permissions & Roles、作成済みsiteの管理場所を確認します。利用できる状態でも、pilot対象者とreviewerを決めずに広げないほうが安全です。
Enterpriseで見ること
Enterpriseでは、RBACで対象roleを絞ることが最初の作業です。全員に開ける前に、Sitesを作る人、保存版を作る人、production deploymentを許可する人を分けます。
| プラン | 最初に見ること | 注意点 |
|---|---|---|
| ChatGPT Business | Workspace settingsのPermissions & Roles、Sitesの管理項目 | 公式情報ではBusinessは有効化済みとして説明されているが、workspace管理者が無効化できる前提で確認する |
| ChatGPT Enterprise | RBAC、Early Accessまたは管理者設定、対象role | メンバー全員へ開けず、pilot roleから始める |
| Plus/Pro/API Key | Feature availabilityとpricing | Sitesが対象外または制限付きである可能性を確認する |
role設計の起点
Enterpriseでは、adminがRBAC controlsから対象roleにSitesを有効化する流れが公式ドキュメントにあります。これは便利な制限ではなく、社内運用の起点です。全員に開ける前に、少なくとも次のroleを分けます。
- Sitesを作成できる人
- saved versionを作れる人
- production deploymentを実行できる人
- workspace_allへ公開範囲を広げられる人
- secretsを追加、更新、削除できる人
Businessでも、利用できるからといって全員が自由に社内ツールを増やしてよいわけではありません。workspace settingsで無効化や管理ができる前提で、最初はチーム単位の小さなpilotにしたほうが、後から整理しやすくなります。
料金面は、<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-tool-pricing-plan-limits-team-enterprise-decision/">AIコーディングツール料金改定の見方</a>でも整理した通り、月額だけでは足りません。Codexのrate cardはcreditsとtoken-based pricingの考え方で更新されているため、Sitesで何度も生成、修正、再デプロイする運用では、作成回数ではなく、モデル利用量とレビュー回数も見ます。
RBACとアクセス範囲は最初から分けて考える
作成直後とレビュー前に使います。
pilot teamやreviewerに限定します。
全体共有前に別レビューを置きます。
社内URLでも、誰でも見られる状態にはしません。
Codex Sitesで混同しやすいのは、作成権限と閲覧権限です。誰がSitesを使えるかと、作られたsiteを誰が見られるかは別の問題です。
作成権限と閲覧権限を分離する
開発者ドキュメントでは、Sitesのaccess modeとして次の考え方が示されています。
| Access mode | 開ける人 | 使いどころ |
|---|---|---|
admins_only | site ownerとworkspace admins | 生成直後、レビュー前、機密度が高い試作 |
workspace_all | workspace内のactive users | 全社や部門全体で使う読み物、軽量ダッシュボード |
custom | 指定したactive usersまたはworkspace groups | pilot、部門限定、レビュー担当だけに見せる場合 |
最初のpilotでは、admins_onlyまたは狭いcustomから始めるのが安全です。特に、社内データや業務判断に関わる画面では、workspace_allを「社内だから安全」と見なさないほうがよいです。workspaceには、正社員、業務委託、外部パートナー、検証用アカウントが混在する場合があります。
workspace_allへ広げる条件
運用ルールは、短くても次のように決めておきます。
Codex Sites pilot rule
1. 新規siteはadmins_onlyで作成する。
2. 共有前に差分、保存データ、secrets、アクセス範囲を確認する。
3. workspace_allへ広げる場合は、site owner以外のレビューを必須にする。
4. 顧客データ、個人情報、契約情報、社内APIキーを含むsiteはpilot対象外にする。
5. 不要になったsiteはownerが削除またはdisableを依頼する。これは大げさな規程ではありません。AIが作った社内ツールは、作成速度が速いぶん、棚卸しされないURLや用途不明の保存データが増えやすいからです。
secretsはリポジトリではなくSites panelで管理する
secretsはsourceではなく、管理面と再デプロイ手順で扱います。
Codex Sitesで最も実務上の事故に近いのは、secrets管理です。
公式ドキュメントでは、Sitesのruntime environment valuesとsecretsはSites panelで追加、更新、削除し、.openai/hosting.jsonには保存しないよう説明されています。.openai/hosting.jsonは、Sites projectとローカルソースの紐づけや、D1、R2などのbinding名を持つ設定ファイルとして扱います。APIキー、DBパスワード、外部サービスのtokenを置く場所ではありません。
置き場所を先に固定する
最低限、次の線引きをします。
| 置き場所 | 入れてよいもの | 入れてはいけないもの |
|---|---|---|
.openai/hosting.json | project_id、D1/R2のbinding名など | APIキー、DB password、OAuth secret、社内URLのcredential |
.env.example | 必要な環境変数名、ダミー値 | 実値、token、秘密情報 |
local .env | ローカル検証用の実値 | Git管理対象にしない |
| Sites panel | hosted runtimeのsecrets | 追加後は承認済みsaved versionを再デプロイする |
review paneで見ること
たとえば、次のような.openai/hosting.jsonは設定の例として読めます。
{
"project_id": "<project-id>",
"d1": "DB",
"r2": null
}ここにGITHUB_TOKENやSALESFORCE_CLIENT_SECRETを足してはいけません。Codexが差分を作ったときは、review paneでsecretsらしい文字列が混ざっていないか見ます。社内運用では、secret scanningやpre-commit hookも併用したいところです。
MCPや外部API連携を組み合わせる場合は、<a href="https://ai-dev.blog.mo-gmo.com/mcp-registry-server-selection-oauth-tool-poisoning-allowlist/">MCP Registryからサーバーを選ぶ前に</a>で扱ったallowlistとOAuthの考え方もそのまま効きます。SitesのUIが便利でも、外部APIに触る瞬間に、権限と監査の設計が必要になります。
保存、デプロイ、レビューを一つの作業にしない
- 1build
Codexにsiteを作らせます。
- 2review
source changesとmigrationを確認します。
- 3save
承認候補としてversionを保存します。
- 4approve
accessとsecretsを見直します。
- 5deploy
選んだversionだけを公開します。
production URLはレビュー後にだけ共有します。
Codex Sitesの重要な概念は、saved versionとdeploymentを分けることです。公式ドキュメントでは、Sites publishingには、deployable siteをbuildしてsource Git commitと関連づける「save a version」と、そのsaved versionを公開する「deploy a version」の2段階があると説明されています。
この分離は、社内ツール運用ではかなり大事です。AIエージェントが作った差分を、人間が確認する前にproduction URLへ出す必要はありません。
saved versionを承認候補にする
実務では、次の流れにします。
- Codexに
@Sitesでsiteを作らせる - build結果と差分を確認する
- 必要ならlocalまたはpreview相当で触る
- saved versionを作る
- reviewerがsource changes、database migrations、runtime values、access modeを見る
- 承認済みsaved versionだけをdeployする
- deployment URLとアクセス範囲を記録する
promptでdeployを止める
プロンプトも、最初から「deployして」と書くより、reviewを挟む形にします。
@Sites Build an internal request dashboard for the operations team.
Use workspace-authenticated user identity.
Keep the first version owner/admin only.
Save a reviewable version, but do not deploy it to a wider audience until I approve the changes.既存プロジェクトをSitesへ載せる場合も同じです。
@Sites Check whether this project can be deployed with Sites.
List any required changes, storage assumptions, build issues, and access settings.
Save a version only after the build succeeds. Do not widen access.日本語で指示してもかまいませんが、save a version、deploy、access mode、runtime secretsのような用語は、公式ドキュメントと揃えると確認しやすくなります。
データ保存と社内データの扱いを先に線引きする
保存できることと、保存してよいことは別です。
公式ドキュメントでは、SitesはCloudflare Worker-compatible outputとしてbuildできるprojectを対象にし、新規projectでは推奨starterから始められると説明されています。また、永続的なstructured dataにはD1、ファイルにはR2、現在のworkspace user identityが必要な社内siteにはworkspace-authenticated user identityという選択肢が示されています。
保存してよいデータを分類する
これは便利ですが、同時にデータ分類の判断を求められます。
| siteの用途 | 保存を許可しやすいデータ | pilotで避けたいデータ |
|---|---|---|
| 作業依頼ボード | 件名、担当者、状態、期限 | 顧客名、契約金額、個人情報 |
| 社内FAQ | 質問、回答、カテゴリ、更新日 | 未公開の人事情報、インシデント詳細 |
| 分析ダッシュボード | 集計済み指標、サンプルデータ | 生ログ、識別子、請求情報 |
| ゲームや研修ツール | スコア、進捗、ニックネーム | 評価情報、実名、部署別の成績 |
特に避けたいのは、「一時的な検証だから」と言いながら、本物の業務データを貼り付けることです。AIエージェントが画面を作ると、目に見える成果が速く出ます。その速度に引っ張られると、データの持ち出し、保存先、削除方法の確認が後回しになります。
初回pilotの制限
最初のpilotでは、次のどれかに限定すると扱いやすいです。
- ダミーデータだけで作る
- 集計済みで個人を特定できないデータだけ使う
- owner/admin限定で、保存期間を短く決める
- 外部APIには接続せず、手入力または静的ファイルで試す
社内でAIコーディングエージェントを使う場合の権限境界は、<a href="https://ai-dev.blog.mo-gmo.com/codex-memories-agents-md-claude-code-mcp-permission-boundaries/">Codex Memoriesをチームで使う前に</a>でも扱いました。Sitesでも同じで、便利な共有機能ほど、どこまで記憶させるか、どこまで読ませるか、どこまで配布するかを先に決めます。
料金と利用量は「作れるか」と別に見る
site完成までのthread数を見ます。
要件変更とUI調整を見込みます。
使うモデルでcredit消費が変わります。
D1/R2の利用有無を分けます。
棚卸しと削除の時間も含めます。
月額だけでなく、creditsと運用時間を合わせて見ます。
Codex Sitesは、単に「生成できるか」だけでなく、「何度作り直すか」で利用量が変わります。社内ツールは、一度で完成しません。フォーム項目を足す、アクセス範囲を変える、保存データを変更する、UIを調整する、レビュー指摘を直す。これらのたびにCodexを使うなら、利用量の見積もりが必要です。
OpenAIのCodex rate cardでは、Codexのcredit usageがAPI token-based ratesに基づく形で説明されています。2026年6月11日時点のrate cardは更新が新しく、モデルやfeatureごとのcredits per million tokensが案内されています。ただし、この記事では具体単価を固定しません。pricingは変わりやすく、Enterprise契約では個別条件もあり得るためです。
生成回数ではなく修正回数を見る
代わりに、社内の試算では次の観点を置きます。
| 観点 | 見ること |
|---|---|
| 作成回数 | 1つのsiteを完成させるまでに何thread、何回修正するか |
| レビュー回数 | review paneで差分確認し、修正依頼する回数 |
| モデル選択 | GPT-5.5など、使うモデルによるcredit消費 |
| storage利用 | D1/R2など永続データやfile storageを使うか |
| 管理コスト | admin、reviewer、削除・棚卸し担当の時間 |
小さく枠を切る
小規模チームなら、最初は「1チーム、1用途、2週間、3siteまで」のように枠を切るのがよいです。使い放題の感覚で社内に広げるより、実際にどれだけ手戻りが起きるか、どのレビューで止まるか、どのデータを入れたくなるかを観察します。
社内ツールとして試すなら、この順番にする
- 用途
一つの業務動線に絞ります。
- データ
使ってよい情報を書き出します。
- role
作成者、reviewer、adminを分けます。
- prompt
deployしない条件も明記します。
- record
URL、owner、削除予定日を残します。
作成速度より、後から追える状態を優先します。
Codex Sitesを試すなら、次の順番が現実的です。
1. 対象用途を一つに絞る
最初から「社内ポータルを作る」ではなく、「問い合わせ一次受付」「リリース判定チェックリスト」「施策レビュー用ダッシュボード」のように、一つの検索意図、一つの業務動線に絞ります。
2. データ分類を先に書く
使ってよいデータ、使わないデータ、保存してよいデータを短く書きます。ここで迷う用途はpilotから外します。
Allowed:
- dummy request records
- aggregated weekly counts
- public product names
Not allowed:
- customer personal data
- contract values
- API keys or service tokens
- internal incident details3. roleを限定する
BusinessでもEnterpriseでも、作成者、reviewer、adminを分けます。少なくとも、本番デプロイとworkspace_all公開は、site ownerだけの判断にしないほうがよいです。
4. @Sitesへの依頼文に制約を書く
Codexに作らせるとき、UI要件だけではなく、アクセス範囲、保存データ、deployしない条件を書きます。
@Sites Create a lightweight internal release checklist.
Use dummy data only.
Do not connect to external APIs.
Keep access owner/admin only.
Save a version for review and explain any storage or migration assumptions.5. review paneで差分を見る
source changes、database migrations、runtime values、build結果、access modeを見ます。見た目がよくても、secrets混入、過剰なstorage、不要な外部通信があれば止めます。
6. deployment URLを記録する
デプロイしたら、URL、owner、目的、access mode、保存データ、削除予定日を記録します。作るより、残すほうがリスクになりやすいです。
使わないほうがよい失敗条件
preview利用の社内承認がありません。
誰が公開できるか決まっていません。
APIキーの置き場所が未定です。
顧客情報や個人情報を初回pilotに入れています。
creditsやレビュー時間を見積もっていません。
止めた理由を残せば、次のpilotの条件になります。
条件が未定なら止める
Codex Sitesは面白い機能ですが、次の条件に当てはまるなら、その用途では使わないほうがよいです。
- preview機能を使う承認が社内で取れていない
- 誰がsiteを作れるか管理できない
- workspace内のユーザー構成を把握していない
workspace_allに出してよい情報か判断できない- APIキーやOAuth secretの管理場所を決めていない
- saved versionとdeploymentの違いを運用に落とせていない
- D1/R2などの保存データを誰が削除するか決まっていない
- 顧客データ、個人情報、契約情報を初回pilotに入れようとしている
- 料金上限、credits、レビュー担当の時間を見積もっていない
特に危ない組み合わせ
特に危ないのは、「社内向けだから大丈夫」と「AIが作ったから速く公開しよう」が同時に起きるケースです。SitesはURL共有までが近いぶん、通常の開発プロセスなら止まる箇所を飛ばしやすくなります。
セキュリティ・コスト注意
軽量ツールでも、公開と保存の責任は軽くなりません。
セキュリティはread-onlyから
セキュリティ面では、read-onlyから始める発想がまだ有効です。最初のsiteでは、外部API接続、書き込み操作、ファイルアップロード、永続DBを避け、静的な閲覧画面またはダミーデータの入力に留めます。書き込みが必要になった時点で、操作ログ、削除方法、owner不在時の対応、secrets rotationを決めます。
コストは運用時間も見る
コスト面では、生成そのものだけでなく、作り直し、レビュー、再デプロイ、不要siteの棚卸しに時間がかかります。Codexの料金はplanとcredits、token-based pricing、feature availabilityに依存します。公式rate cardとworkspace契約条件を確認し、部署単位で上限を置くのが安全です。
法人導入を考える場合は、Sitesだけを切り出して評価するより、Codex app、CLI、MCP、AGENTS.md、permissions、review gateを含めて設計したほうがよいです。必要なら、記事末尾の関連リンクから権限設計や料金比較の記事へ進んでください。AI Dev Lab Japanでは、法人向けAIコーディング導入支援として、RBAC、secrets、MCP、レビューゲート、pilot設計の整理も扱っています。
更新通知や検証ログの差分を追いたい方は、サイトの<a href="https://ai-dev.blog.mo-gmo.com/newsletter/">ニュースレター</a>も使えます。preview機能は変化が速いので、公開時点の判断を固定せず、更新履歴で追う前提にしたほうがよいです。
FAQ
この記事では社内用途に限定します。
使える場合でもroleを限定します。
secretを入れない前提で扱います。
compatible outputか先に確認します。
FAQは、pilot前の確認リストとして使います。
Codex Sitesは社外公開サイトに使えますか
この記事では社内ツール用途に限定して考えています。公式情報ではworkspace内共有やBusiness/Enterprise previewとして説明されているため、顧客向け公開サイトや本番サービスの代替として扱う前に、対象プラン、公開範囲、認証、利用規約、サポート条件を確認してください。
Businessなら全員が使ってよいですか
いいえ。公式情報ではBusinessで有効化済みとして説明されている箇所がありますが、社内運用では作成者、reviewer、admin、公開範囲を分けたほうが安全です。workspace settingsで管理できる前提で、pilot対象者を絞ります。
.openai/hosting.jsonにsecretを入れてもよいですか
入れないでください。公式ドキュメントでは、runtime environment valuesやsecretsはSites panelで管理し、.openai/hosting.jsonには保存しないよう説明されています。.env.exampleにも実値を入れず、必要なkey名だけを置きます。
既存のNext.jsやReactアプリをそのまま載せられますか
既存projectの場合は、Sitesでdeploy可能かCodexに確認させるところから始めます。公式ドキュメントでは、SitesはCloudflare Worker-compatible outputとしてES modulesをbuildできるprojectを対象にする説明があります。build、storage、server API、外部API、環境変数の前提が合わない場合は、修正が必要です。
最初の検証で何を残せばよいですか
最低限、作成日、作成者、用途、access mode、使ったデータ、storageの有無、secretsの有無、saved version、deployment URL、削除予定日を残します。成功した画面だけでなく、止めた理由も残すと、次のpilot判断に使えます。
次に読むなら
参照した主な情報源
- OpenAI: Codex for every role, tool, and workflow
- OpenAI Developers: Sites – Codex
- OpenAI Developers: Codex changelog
- OpenAI Help Center: Using Codex with your ChatGPT plan
- OpenAI Help Center: ChatGPT Business release notes
- OpenAI Developers: Codex pricing
- OpenAI Help Center: Codex rate card
- OpenAI Developers: Codex app
更新履歴
- 2026-06-11
OpenAI公式docs、Help Center、pricing、rate cardを確認しました。
- 次回確認
対象plan、RBAC導線、rate card、access modeの変更を見ます。
この記事は、公開時点の公式情報を基準にしています。
- 2026-06-11: OpenAI公式ドキュメント、Help Center、Codex pricing、rate cardを確認し、Codex SitesのBusiness/Enterprise preview、RBAC、access mode、secrets、saved versionとdeploymentの扱いを整理しました。スポンサー、アフィリエイト、無償提供はありません。