2026年6月3日（日本時間）、OpenAIはイベント「Intelligence at Work」において、Codexの新機能「Sites」を発表しました。これは、Codexで作成したダッシュボードや受付ページといった小規模なWebアプリを、ワークスペース内でシームレスに公開・共有できる機能です。
翌6月3日のAGIラボの共有会では、発表直後のSitesを用いて実際にビルドからデプロイまでを行い、データの保存先についても検証しました。本記事では、Sitesの導入準備から作成手順、共有設定、公開前の確認事項まで詳しく解説します。
要点
Codex Sitesが登場: Codexへの依頼から社内向けWebアプリを作成・公開できる。現在はBusiness / Enterprise向けプレビュー。
公開は2段階: save（バージョンを保存）→ deploy（本番URLに公開）。いきなり全員に公開されることはない。
共有範囲は3種類: admins_only（管理者のみ）／workspace_all（ワークスペース全員）／custom（指定ユーザー）。完全なパブリック公開はできない。
データの保存先を確認する: D1（小さめのDB）／R2（ファイル置き場）／Secrets（APIキー）。公開しても、データが中央のデータベースに集まるとは限らない。
同時に6つの職種別Pluginsも発表: 公式発表記事によると、合計62のアプリと110のスキルを含む。
Codex Sitesを使う前の準備
Sitesを使うには、次の4つがそろっている必要があります。
Business / Enterpriseプラン。開発者向けドキュメントによると、SitesはBusinessとEnterprise向けのプレビュー機能です。Businessは標準で有効、Enterpriseは管理者が有効化する必要があります。他プランへの展開は後日とされており、時期は未定です。
Codexアプリ。Sitesの操作はCodexのアプリ内から行います。
Sitesプラグインの追加。開発者向けドキュメントによると、プラグイン追加後は新しいスレッドを開始する必要があります。古いスレッドのままだとSitesが呼び出せないことがあります。
管理者側の設定。Enterpriseでは管理者がSitesを有効化しているかを先に確認します。有効になっていない場合は管理者に依頼してください。
この記事の手順のうち「保存先の確認」と「共有範囲の確認」は、どのツールでもそのまま応用できます。
基本的な作り方
非常に簡単です。Codexのスレッドで @Sites を付けて、作りたいものを文章で伝えます。
たとえば、次のように伝えてみます。
@Sites イベント受付用の1ページサイトを作ってください。 名前を入力して送信すると、一覧に追加されるだけのシンプルな構成で。
この後は、Codexが作業ディレクトリの確認、スターターの展開、ファイル編集、依存関係のインストール、ビルド、ローカル確認まで進めていきます。
今回の再検証では、16分34秒でローカルURLが起動し、npm run build、npm run lint、HTTP応答の確認まで進みました。
追加で「デプロイしてください」と依頼すると、バージョン保存と公開URLの発行まで進みました。
『共有』からリンクをコピーしてブラウザで開きます。できあがったページは、フォームと一覧だけのシンプルな受付サイトです。名前を送信すると、ページ内の受付一覧に追加されます。
AGIラボ内で試した他のサイトでは、単純なレシピサイト1つに約55分かかり、5時間の使用量を使い切りました。
作業量が多くトークンを多く消費するので、最初は、フォーム1つ、一覧1つ、保存先なし、くらいに絞るのがおすすめです。DB、画像アップロード、複雑な権限は、動く1ページを確認してから足します。
開発者向けドキュメント上の仕組みとしては、公開は save（バージョン保存）と deploy（本番URLへの公開）の2段階です。
ユーザーが毎回細かく指示する必要はありませんが、公開前に止めたいときは「まず確認できるところまで。まだ公開しないでください」と書いておくと安全です。
アクセス権と共有範囲の確認
公開範囲がどうなるかを確認しておきます。現状、アクセス範囲は以下の3種類です。
admins_only：オーナーと管理者のみ。作成直後の確認や、レビュー中に使用します。
workspace_all：ワークスペースの全メンバー。社内全体に共有するツールで使用します。
custom：指定したユーザーのみ。特定チームや特定メンバー向けに使用します。
新規サイトは、レビューが終わるまでオーナーとワークスペース管理者に限定されます。
実際に試してみたところ、やはり完全な一般公開はできませんでした。サイトを閲覧するには、同じワークスペースへのログインが必要です。最初にURLへアクセスすると、以下のように表示されます。
Sitesで指定できる主な要素
依頼文の中で、データの置き場などは指定できます。
ドキュメントによると、構成要素は次のとおりです。
D1: 小さめのデータベース。記録・スコア・進捗など、行と列のデータに使います。
R2: 大きなファイルの置き場。画像・動画・ファイルに使います。
Secrets: APIキーの置き場。外部サービスとの連携キーをコードに直書きしないために使います。
アクセスモード: 公開範囲。admins_only / workspace_all / custom を指定します。
永続的なデータが不要なら、静的なサイトとして作れます。D1もR2も指定しなければ、シンプルな1ページで完結します。
APIキーなどについては、Sitesのパネルで管理され、設定ファイル（.openai/hosting.json）には保存されません。APIキーをプロンプトやコードに直接書かず、「Secretsに置いて名前で呼び出して」と依頼できます。
コミュニティで見えた発見
6月3日の共有会での発見を以下にまとめます：
① 速いときは数分。ただし利用枠の消費に注意：
ランチ共有会では、受付アプリがその場で構築・デプロイまで進む様子を確認できました。一方で、別の検証では「画面を確認しながら細かく調整する」「修正を重ねる」「再デプロイする」といった流れで、短時間に利用枠を大きく消費する場面もありました。
まずは1本を小さく作り、どこまで自動で進むか、どのくらい消費するかを事前に確認しておくのがよさそうです。
② データの保存場所に注意（ブラウザ内保存のケース）：
共有会で実際にリアルタイムで作成した受付アプリのデータ保存先を確認したところ、データはサーバーではなく、利用しているブラウザ内に保存されていました。
ブラウザ内保存の仕組み（IndexedDB）が採用されており、そのPC・そのブラウザにのみ保存される仕様であることが後からわかりました。
複数人でデータを共有するアプリの場合、D1やR2などのストレージ・DBを明示的に指定しないと、外部の保存先が利用されない（ローカル保存になる）ことがあるようです。
③ 独自ドメインはまだ変更できなさそう：検証の範囲では未対応でした。
同時に発表された新規Plugins
Sitesと同時に、職種別のPluginsも発表されました。公式発表記事によると、各Pluginはその職種に関連するアプリ、スキル、指示、ワークフローを束ねたもので、まず6つが提供され、合計62のアプリと110のスキルを含みます。
Data analytics: データ分析。分析質問を、検証済みの回答、ダッシュボード、レポートに落とし込むためのPluginです。
Creative production: クリエイティブ制作。ブリーフや商品画像から、広告案、ムードボード、SNS投稿、掲載用画像などを作るためのPluginです。
Sales: 営業。商談準備、顧客情報の整理、フォローアップ、リスクのある案件レビューなどを進めるためのPluginです。
Product design: プロダクトデザイン。アイデアの探索、ユーザーフローの監査、スクリーンショットからのプロトタイプ化などに使うPluginです。
Public equity investing: 上場株投資。企業分析、決算、ETF/指数調査、投資メモ作成などを支援するPluginです。
Investment banking: 投資銀行。M&A、資本市場、バリュエーション、デューデリジェンス、ピッチ資料づくりなどを支援するPluginです。
公式発表記事によると、今後も職種別Pluginの追加が予定されています。
まとめ
Codex Sitesを使ってみて何より画期的だと感じたのは、Codexへの依頼から画面の構築、ビルド、デプロイ、そして共有までが、すべて一つのスムーズな体験として完結している点です。たった2年前でさえ、社内向けのちょっとしたWebアプリを公開しようと思えば、環境構築やホスティング、認証周りの知識がどうしても欠かせませんでした。それが今や、簡単な受付ページや一覧画面程度なら、やりたいことを言葉で伝えて少し待つだけで、そのまま使えるURLが発行されてしまいます。
普段からCloudflareやGitHub、GASなどの開発ツールに馴染みがない人が、「こんなフォームや一覧が欲しい」と思った時に自力で形にできることにこそ、本当の価値があるように思えます。大がかりな業務システムを置き換えるといった構えた話ではなく、Excelやスプレッドシート、GASを駆使してなんとか回していた「手作りの社内ツール」を、より使い勝手のいいWebアプリへと昇華させるための、もっとも手軽な一歩と言えます。
活用シーンとしてあげられるのは、ワークスペース内で完結するクローズドな用途です。イベントの申し込み、講座のフィードバック、社内レビュー、運営ログの記録、あるいはプロジェクトの簡易的なダッシュボード。
現時点では、不特定多数に見せるための立派なサイトを作るのではなく、チームのメンバーがログインして使う「便利で小さな道具」を作るイメージです。ChatGPTのアカウントとワークスペースの認証がそのまま効くので、セキュリティや共有範囲をあれこれ悩まなくていいのも、この用途には非常にマッチしています。
一方で、独自ドメインでの運用や長期的な保守、データベースの細かな管理、緻密な権限設計などが必要な場合は、これまで通りCloudflareなどを直接叩く方が賢明です。先日のコミュニティ共有会でも、「機能的には本格的なサイトも作れそうだが、ドメイン管理やデータの所有権、将来のメンテナンスまで視野に入れるなら、用途によっては自分たちでインフラを触った方がいい」といった議論がありました。
まずは、1画面だけの小さなツールから試してみるのがおすすめです。出来栄えをチェックして、データの保存先や共有範囲を確認してから公開する。この記事にあるような「項目をまとめて一覧で見る」くらいのダッシュボードなら、練習台としてもちょうどいいサイズ感です。Businessプランを使っているなら、まずは試しに @Sites へリクエストを送ってみるところから始めてみてはいかがでしょうか。
関連アーカイブ
この記事は、2026年6月3日にAGIラボで行われたランチ共有会「Codex新機能 / Codex App講座振り返り」での検証をもとにしています。共有会では、Sitesの実演、D1/R2、保存先、共有範囲、Pluginsの概要などを扱いました。
AGIラボ会員の方は以下のリンクからアーカイブも視聴できます：
AGIラボ昼共有会「Codex新機能 / Codex App講座振り返り」
