Codex Sitesとは？Webサイト・アプリを保存・公開する仕組みと使い方
Codex Sitesは、Codexにプロンプトや既存プロジェクトを渡して、Webサイト、Webアプリ、ゲームを保存、公開、確認するためのOpenAIのホスティング機能です。通常の「コードを書いてから別サービスへデプロイする」流れよりも、Codex内で試作、version保存、production URLへの公開、アクセス範囲の確認までを近い距離で進められる点が特徴です。
一方で、Sitesは単なるプレビュー機能ではありません。公式manualでは、Sitesのdeployment URLはproduction deploymentとして扱われると説明されています。つまり、社内確認用のつもりでdeploymentまで進めると、そのURLは公開対象として扱うべき状態になります。
Codex Sitesとは、Codexで作ったサイトや互換性のある既存プロジェクトを、OpenAIがホストするWebサイト・Webアプリとして保存、デプロイ、確認する機能です。安全に使うコツは、まずversionとして保存してレビューし、公開してよい内容、アクセス範囲、secret、保存データの要否を確認してからdeploymentすることです。
本記事のポイント
- Codex Sitesは、Codexで作ったサイトや互換性のある既存プロジェクトを、OpenAIがホストするWebサイト・Webアプリとして保存、公開、確認するための機能です。
- Sitesではversion保存とdeploymentが別物で、deployment URLはproduction扱いです。共有前レビューが必要な場合は、先にversionを保存して確認します。
- 業務で使う前に、Cloudflare Worker互換のビルド、D1/R2の要否、アクセス範囲、hosted secret、公開前レビューの順番を決めることが重要です。
この記事で扱うテーマ
関連キーワード
- Codex Sitesとは
- Codex Sites 使い方
- Codex Sites 保存 公開
- Codex Sites deployment
- Codex Sites version
- Codex Webサイト 公開
- OpenAI Codex Sites
このページで答える質問
- Codex Sitesとは何ですか？
- Codex Sitesのversion保存とdeploymentは何が違いますか？
- Codex SitesはどんなサイトやWebアプリに向いていますか？
- Codex Sitesを業務で使う前に何を確認すべきですか？
Codex Sitesとは何か
Codex Sitesは、OpenAI CodexのSites pluginを使って、プロンプトから作る新規サイトや、対応する既存プロジェクトをホストされたサイトとして扱う機能です。公式manualでは、Sitesは「Websites, web apps, and games hosted by OpenAI」を作成、保存、デプロイ、検査できるものとして説明されています。
使いどころは、別途VercelやNetlifyなどのデプロイ環境を整える前に、Codexにサイトや小さなWebアプリを作らせ、そのままホストされた状態で確認したい場面です。たとえば、社内向けのミニツール、営業資料に添えるインタラクティブなデモ、イベント用の一時的な登録ページ、業務フローを試す小さなアプリなどが候補になります。
ただし、Sitesは「何でもそのまま公開できる魔法の置き場」ではありません。既存プロジェクトを使う場合は、ビルドがCloudflare Worker互換のES module出力を作れるかを確認する必要があります。通常の静的HTMLだけでなく、ランタイム、ストレージ、認証、secretを含む場合は、Sitesの前提に合う設計へ寄せる必要があります。
| 観点 | Codex Sitesで確認すること | 実務での意味 |
|---|---|---|
| 作成対象 | Webサイト、Webアプリ、ゲーム | ランディングページだけでなく、小さな業務アプリの試作にも使える |
| ホスティング | OpenAIがホストするSites project | 別のデプロイワークフローを用意しなくても公開候補を作れる |
| ビルド形状 | Cloudflare Worker互換のES module出力 | 既存プロジェクトは互換性確認が必要 |
| 公開URL | deployment URLはproduction扱い | 共有前レビューとアクセス制御を先に行う |
| 設定ファイル | .openai/hosting.json | ローカルprojectとSites側のprojectやstorage bindingを結びつける |
version保存とdeploymentの違い
Codex Sitesを理解するうえで最も重要なのは、version保存とdeploymentを分けて考えることです。Sitesでは、まずデプロイ可能な成果物をbuildし、source Git commitにひもづいたversionとして保存できます。そのversionを後からdeploymentすると、production URLが発行されます。
レビュー前の成果物をいきなりdeploymentしない運用にすると、本文、画像、データ取り扱い、アクセス権、secretの設定を落ち着いて確認できます。特に顧客情報、社内データ、フォーム、ログイン、アップロードを扱うサイトでは、deployment前にversionを一覧・検査し、意図したversionだけを公開する流れが必要です。
| 段階 | 何が起きるか | 使う場面 |
|---|---|---|
| versionを保存する | build済みの公開候補をsource Git commitと結びつけて保存する | 社内レビュー、差分確認、公開前チェック |
| versionをdeployする | 保存済みversionをproduction deploymentとして公開する | 対象読者に実際にアクセスしてもらう |
| saved versionsを確認する | 過去の公開候補や現在公開したい候補を識別する | 公開候補の取り違え防止、rollback判断 |
この分離は、通常のWeb制作でいう「preview build」と「production deploy」を同じ会話の中で扱うための安全装置です。Codexに「保存だけして、まだデプロイしない」と明示すると、公開前レビューの余地を確保できます。
対応するサイト形状とストレージの選び方
Sitesで作るサイトは、必要な状態管理に応じて形を選びます。コンテンツ中心のWebサイトやLPなら、永続的なアプリケーション状態を持たない形で十分なことが多いです。ユーザーの記録、進捗、ゲームスコアなどを残す場合はD1、画像や書類、音声、動画などのファイルを扱う場合はR2を検討します。
アップロードファイルに検索可能なメタデータが必要な場合は、D1にメタデータ、R2にファイル本体を置く構成が自然です。社内サイトとして現在のworkspaceユーザーの本人性を使うならworkspace-authenticated user identity、外部ユーザー向けのログインが必要ならauthentication-enabledなSites projectを検討します。
| 作りたいもの | Sitesで考える構成 | 判断ポイント |
|---|---|---|
| 記事LP、イベントページ、簡易デモ | 永続状態なし | 表示内容が固定で、ユーザーごとの保存が不要 |
| 入力履歴、進捗、スコアを残すWebアプリ | D1 | 構造化データを永続保存する必要がある |
| 画像、資料、音声、動画アップロード | R2 | ファイルそのものを保存する必要がある |
| ファイルと検索用メタデータを扱う | D1 + R2 | ファイル本体と属性情報を分けて管理したい |
| 社内限定ツール | workspace認証 | workspace内のユーザーだけが使う |
| 外部ユーザーのログインが必要なサービス | 認証付きSites project | public sign-inや外部IDプロバイダーを使う |
一時的なテーマ切り替えや、閉じたバナーの状態のような軽いUI状態にまで永続ストレージを付ける必要はありません。反対に、利用者が「このサイトは覚えてくれる」と期待するデータは、最初から保存先と削除方針を決めておくべきです。
アクセス制御とsecret管理の考え方
SitesでdeploymentしたURLはproduction扱いなので、公開範囲の設定は本文やUIと同じくらい重要です。新しいsiteでは、内容、データ取り扱い、想定読者を確認するまで、ownerとworkspace adminsだけに絞るのが安全です。その後、workspace全体、特定ユーザーやgroupなど、必要な範囲に広げます。
アクセスモードは、owner and admins、workspace、customのように段階を分けて考えます。BtoBの現場では、社内レビュー用、顧客共有用、公開LP用でアクセス範囲が変わります。最初に「誰が見るURLか」を決めずにdeploymentすると、便利な試作がそのまま情報管理上のリスクになります。
APIキーや接続情報などのruntime環境値は、.openai/hosting.jsonへ書かず、Sites panelからhosted environment variablesやsecretsとして設定します。ローカル開発では.envと.env.exampleのkeyをそろえ、secret値そのものはcommitしない運用にします。secretを追加、更新、削除したあとは、承認済みのversionを再deploymentして、実際の公開環境へ反映させます。
業務で使う前のチェックリスト
Codex Sitesは、試作から公開までの距離を縮める機能です。その分、公開前に見るべき項目を明文化しておくと、スピードと安全性を両立しやすくなります。特に、営業資料や社内ツール、顧客向けデモに使う場合は、次の順で確認します。
- 作りたいものがコンテンツ中心か、データ保存を伴うアプリかを分ける。
- 既存プロジェクトを使う場合は、Cloudflare Worker互換のbuild outputを作れるか確認する。
- D1、R2、workspace identity、外部認証の要否を決める。
- Codexにまずversion保存を依頼し、公開前レビュー用の候補として扱う。
- source変更、database migration、アクセス範囲、hosted secretをレビューする。
- 公開してよいversionだけをdeploymentし、production URLとstatusを確認する。
- URL共有後も、アクセス対象が意図どおりか、想定外のデータが表示されていないかを確認する。
この流れは、バイブコーディングで作った小さな業務ツールを社内に持ち込むときにも有効です。作れること自体よりも、誰が使い、何を保存し、どこまで公開するかを先に決める方が、現場に定着しやすくなります。
Codex Sitesが向いているケース、向いていないケース
Codex Sitesが向いているのは、Codexで作った成果物を早く触れる形にし、関係者が同じURLで確認したいケースです。デザイン確認、営業デモ、イベント用の小さなページ、社内業務ツールの初期試作、顧客提案前のクリック可能なプロトタイプには相性があります。
向いていないのは、既に複雑なCI/CD、独自インフラ、細かいnetwork policy、大規模な本番監視、既存認証基盤との深い連携があるサービスを、そのまま置き換えるケースです。その場合は、Sitesを本番基盤の代替ではなく、試作、レビュー、社内デモの高速化手段として使う方が現実的です。
| 向いている | 注意が必要 |
|---|---|
| 新規LPや社内ミニツールを短期間で見せたい | 本格的なCI/CDや監視が既に整っている大規模サービス |
| Codexで作った試作を同じURLでレビューしたい | 既存インフラのnetwork policyに強く依存するシステム |
| D1/R2を使う小さなデータ保存アプリを検証したい | データ分類、削除、監査の設計が未整理の顧客向けアプリ |
| workspace内で使う認証付きツールを試したい | 外部ID連携や権限設計が複雑な商用サービス |
AIエージェントを使ったWeb制作の内製化では、公開手段そのものより、要件整理、権限、ログ、レビューの型が成果を左右します。詳しくは、Webサイト内製をAIエージェントで進めるときのVercel・Xserver比較や、AIエージェントのガバナンス設計も合わせて確認すると、Sitesの位置づけを決めやすくなります。
参考にした公式情報
本記事は、2026年6月3日時点で取得したOpenAIのCodex manualにあるSitesセクションを主な根拠にしています。関連する公式ページとして、Codex Sites、Plugins、Review and ship changesを確認すると、Sites pluginの呼び出し方や公開前レビューの考え方を追いやすくなります。
よくある質問
Codex Sitesとは何ですか？
Codex Sitesとは、Codexで作ったWebサイト、Webアプリ、ゲームをOpenAIがホストするsiteとして保存、デプロイ、確認する機能です。プロンプトから作る新規サイトだけでなく、互換性のある既存プロジェクトも対象になります。
Codex Sitesのdeployment URLはプレビューですか？
いいえ。公式manualでは、Sitesのdeployment URLはproduction deploymentとして扱われます。レビュー前に触れるURLがほしい場合は、Codexにversionを保存させ、公開前候補として確認する運用にします。
Codex SitesはVercelやNetlifyの代わりになりますか？
小さなサイトやWebアプリをCodex内で作り、保存し、公開する用途では便利です。ただし、既に複雑なCI/CD、監視、独自インフラ、既存認証基盤があるサービスをそのまま置き換える前提ではなく、試作やレビューの高速化手段として考える方が安全です。
D1やR2はいつ必要ですか？
ユーザーの記録、進捗、スコアなど構造化データを保存するならD1、画像や資料、音声、動画などのファイルを保存するならR2を検討します。アップロードファイルに検索用メタデータが必要な場合は、D1とR2を組み合わせます。
Codex Sitesを業務で使う前に何を確認すべきですか？
Cloudflare Worker互換のbuild、version保存とdeploymentの分離、アクセス範囲、hosted secret、D1/R2の要否、公開前レビューの担当者を確認します。特に、deployment URLがproduction扱いである点を前提に運用を組むことが大切です。
関連ページと関連記事
- Codexで業務自動化はどこまでできるか？AIエージェント活用の実務設計
- Codex app serverとは？ローカルとリモートをつなぐ仕組みを解説
- Codex goalとは？/goalコマンドの使い方・/planとの違いを解説
- Codex Securityとは？AIコーディングのセキュリティ確認を整理
- バイブコーディング完全ガイド
- AIエージェント ガバナンスとは？権限、監査ログ、承認フローの設計
AIでWeb制作と業務アプリ試作を速く回したい場合
Codex Sitesのような機能を使うと、Webサイトや小さな業務アプリの試作は速くなります。ただし、実務で成果に変えるには、要件整理、データ保存、公開範囲、レビュー、運用後の改善までを一緒に設計する必要があります。ファネルAiでは、AIを使ったWeb制作、業務アプリ試作、AIエージェント運用の設計から実装まで支援できます。
