ChatGPT Sitesで何ができる？Webサイト・軽量アプリを作成して公開する方法と注意点【2026年7月】

AIニュース解説

ChatGPTに「こんなWebサイトを作って」と頼み、そのままプレビュー、修正、公開まで進められる新しい機能が「ChatGPT Sites」です。

単なるHTML生成ではなく、OpenAIが用意したホスティング環境上で、Webサイトや軽量なWebアプリ、ダッシュボード、ゲームなどを作成し、URLを発行して共有できます。2026年7月時点ではパブリックベータで、利用可否や上限はプラン、地域、ワークスペース設定によって異なります。

特に注目したいのは、ページを作るだけでなく、データ保存、ファイル保存、サインイン、アクセス制御、独自ドメイン、アクセス解析など、Webアプリ公開に必要な要素まで一体化しつつある点です。一方で、すべてのフレームワークやバックエンド構成を自由に動かせる一般的なクラウド環境ではありません。

ここでは、OpenAIの公式ヘルプと開発者向けドキュメントをもとに、ChatGPT Sitesでできること、実務で使いやすい場面、注意点、従来のWeb開発との使い分けを整理します。

ChatGPT Sitesとは

ChatGPT Sitesは、ChatGPTからホスト型のWebサイトやWebアプリを作成し、編集、公開、共有、管理できる機能です。公式ドキュメントでは、Webサイト、Webアプリ、ゲームなどを、別途デプロイ環境を構築せずに公開できる仕組みとして説明されています。

Web版ではChatGPTのWorkから、デスクトップアプリではWorkまたはCodexからSitesを利用できます。作成時は「Webサイトを作って」と依頼するほか、プロンプト内で「@Sites」を指定して明示的にSitesの作成フローを開始できます。

重要なのは、ChatGPTにコードを書かせるだけではなく、作成した成果物をそのままホストし、公開URLまで発行できる点です。これまで「AIでコード生成→ローカルで確認→GitHubへ保存→VercelやCloudflareなどへデプロイ」と分かれていた作業の一部を、ChatGPT内でまとめて進められます。

ChatGPT Sitesでできること

機能 できること 実務での使いどころ
Webサイト生成 自然言語の指示からページを作成 ランディングページ、説明ページ、社内案内
Webアプリ生成 フォームや操作を含む軽量アプリを作成 申請画面、管理ツール、簡易業務アプリ
プレビュー・修正 生成結果を確認し、会話で修正 レイアウト調整、文言変更、機能追加
ホスティング・公開 Sites上で公開しURLを発行 検証環境、社内共有、公開ページ
アクセス制御 所有者限定、ワークスペース内、公開などを設定 社内ツールや限定公開ページ
永続データ保存 D1による構造化データの保存 進捗、スコア、申請データなど
ファイル保存 R2によるファイル保存 画像、文書、音声、アップロード機能
サインイン Sign in with ChatGPTやワークスペース認証 利用者ごとの表示や保存データ
独自ドメイン 対応環境では所有済みドメインを接続 社外公開サイト、サービス検証
アクセス解析 ユニーク訪問者数やページビューを確認 公開後の利用状況確認

1. プロンプトからWebサイトを作れる

基本的な使い方はシンプルです。作りたいサイトの対象者、目的、必要な機能、使いたい情報を文章で説明すると、ChatGPTがサイトを生成します。

例えば「フリーランスSE向けの案件管理ダッシュボードを作って。案件名、契約期間、進捗、次回確認日を一覧表示し、ステータスで絞り込めるようにして」といった依頼が考えられます。

生成後はプレビューを見ながら、「一覧をカードではなく表にする」「スマートフォンで見やすくする」「入力フォームを追加する」と会話で変更できます。HTMLやCSSを直接修正しなくても、要件を言葉で伝えて改善を続けられるのが大きな特徴です。

2. ランディングページだけでなく軽量アプリも作れる

Sitesは静的な説明ページだけに限定されていません。OpenAIは例として、ダッシュボード、プロジェクトトラッカー、ローンチカレンダー、プロトタイプ、社内ポータル、レポートなどを挙げています。

開発者向けドキュメントでは、Webアプリやゲームも対象として示されています。そのため、単なる「会社紹介ページ」より一歩進んで、入力、検索、絞り込み、状態更新、ユーザーごとの表示といった操作を持つツールも候補になります。

SE実務で考えると、本番システムをいきなり置き換えるより、業務フローのたたき台やPoC、社内向けの小規模ツール、画面イメージの共有に向いています。要件が曖昧な段階でも画面として形にできるため、利用部門との認識合わせにも使いやすいでしょう。

3. データを保存するWebアプリも作れる

一時的な表示だけでなく、利用者が入力したデータや進捗などを訪問後も保持したい場合、Sitesでは永続ストレージを利用できます。

公式ドキュメントでは、構造化データ向けにD1、画像や文書、音声、動画などのファイル向けにR2が案内されています。例えば、タスクの状態やゲームのスコアはD1、アップロードされた画像はR2、といった使い分けです。

これは、従来ならデータベースやオブジェクトストレージを別途用意する必要があった部分です。Sitesでは必要なデータ保存をプロンプトで伝えることで、ホストされるアプリ側に組み込む形を取れます。

ただし、何でも保存すればよいわけではありません。テーマ設定や閉じたバナーの状態のように、一時的なUI状態に永続ストレージを使う必要はありません。業務データとして後から再利用する情報と、一時表示だけでよい情報を分けて設計した方が管理しやすくなります。

4. 公開範囲を設定できる

新しく作成したSiteは、最初からインターネット全体へ公開されるわけではありません。公式ヘルプでは、新規Siteは所有者とワークスペース管理者に限定され、設定によって公開範囲を変更すると説明されています。

アカウントやワークスペース設定に応じて、所有者と管理者だけ、特定ユーザーやグループ、ワークスペース全体、インターネット上の誰でも、といった共有方法があります。

社内ツールを作る場合、このアクセス制御は重要です。プロトタイプだからといって公開URLをそのまま社外へ出すのではなく、必要最小限の公開範囲から始める方が安全です。

5. Sign in with ChatGPTを組み込める

公開Siteでは、必要に応じて「Sign in with ChatGPT」を追加できます。公開ページ自体はログインなしで閲覧可能にしつつ、サインインした利用者だけに保存機能や個別表示を提供するといった設計ができます。

公式ドキュメントでは、サインイン後の利用者情報としてメールアドレスや、利用可能な場合は氏名をサーバー側で扱える仕組みが説明されています。

実務で利用する場合は、認証できることと、アクセス権限を正しく判定できることを分けて考える必要があります。画面側に表示された名前だけを信用して権限を決めるのではなく、認可処理はサーバー側に置くことが公式にも推奨されています。

6. 独自ドメインを接続できる場合がある

対応している環境では、すでに所有している独自ドメインやサブドメインをSitesに接続できます。Sitesがドメインを取得してくれるわけではなく、利用者側でドメインを所有し、DNSレコードを変更できることが前提です。

例えば、検証中はSitesが発行するURLを使い、社外へ正式に見せる段階で自社ドメインのサブドメインへ切り替える、といった運用が考えられます。

なお、独自ドメインの提供条件はアカウントやワークスペースによって異なり、公式ヘルプではローンチ時点のEnterpriseワークスペースでは利用できないとされています。提供条件は今後変わる可能性があるため、実際に使う前にSitesの設定画面で確認が必要です。

7. 公開後のアクセス解析も確認できる

Sitesには基本的なアクセス解析も用意されています。公式ドキュメントでは、追加の分析SDKを入れなくても、ユニーク訪問者数、ページビュー、それらの時系列推移を確認できるとされています。

ちょっとした社内ツールやPoCでは、「作ったものが実際に使われているか」を知るために十分役立ちます。一方で、本格的なマーケティング分析や細かなコンバージョン計測まで同じ画面でできるとは限りません。必要な分析粒度によっては別の仕組みが必要です。

2026年7月時点の公式ドキュメントでは、SitesのAnalyticsはEnterpriseワークスペース所有のSiteでは利用できないとされています。

8. 既存プロジェクトをSitesへ持ち込める

Sitesは新規生成だけでなく、互換性のある既存プロジェクトを公開する使い方も想定されています。開発者向けドキュメントでは、ローカルプロジェクトをSites向けに準備し、互換性を確認したうえでデプロイする流れが案内されています。

Codex CLIやIDE拡張でローカルのソースを編集・テストし、公開やSitesの管理はChatGPT Webまたはデスクトップアプリから行う、という分担もできます。

すでにコードベースがあるSEにとっては、ゼロからプロンプト生成するだけでなく、「既存アプリの検証用公開先」として考えられる点が実用的です。

9. バージョン保存と公開を分けられる

Sitesでは「バージョンを保存する」ことと「デプロイする」ことが分かれています。保存は公開候補を作る段階、デプロイはそのバージョンを実際の公開URLへ反映する段階です。

ここは初心者が迷いやすいポイントです。公式ドキュメントでは、SitesのデプロイURLはすべて本番用URLとして扱われます。変更内容を確認したいだけなら、いきなりデプロイせず、まずバージョンを保存してレビューする方が安全です。

業務利用では「修正したら即公開」ではなく、「修正→保存→レビュー→公開」という手順を決めておくと、誤公開を減らせます。

10. 環境変数やシークレットを設定できる

外部APIなどと接続するサイトでは、APIキーやシークレットの扱いが問題になります。Sitesではホスト環境向けの環境変数やシークレットを設定できます。

公式ドキュメントでは、秘密情報をプロンプト、添付ファイル、Site本文に書かず、Sitesの設定画面から管理するよう案内されています。APIキーを「このキーを使って」とチャット本文へ貼り付ける運用は避けるべきです。

SE実務で利用するなら、ローカルの.env、ホスト側の環境変数、ソースコードの役割を分離し、シークレットをGitや公開ページへ混入させない運用が必要です。

ChatGPT Sitesを実務で使うならどんな場面が向いているか

業務画面のプロトタイプ

要件定義中に「一覧と検索と詳細画面が欲しい」と文章で議論するより、動く画面を作って見てもらった方が認識を合わせやすいことがあります。Sitesは、この初期プロトタイプ作成と相性が良い機能です。

小規模な社内ツール

申請一覧、案件管理、進捗確認、簡易集計など、利用者が限定され、機能も比較的単純なツールは候補になります。アクセス制御とデータ保存を組み合わせれば、単なる静的ページより実務的な形にできます。

顧客説明用のデモ

新機能のイメージや、提案中の画面をブラウザで触れる形にする用途も考えられます。URLで共有できるため、ローカル環境の起動手順を相手に説明する必要がありません。

個人向けの小さなWebツール

計算機、チェックリスト、学習ツール、簡易ゲーム、データ整理画面など、1つの目的に絞った小さなWebアプリを短時間で形にする用途にも向いています。

逆に、Sitesだけで完結させにくいケース

Sitesは便利ですが、一般的なクラウド環境の完全な代替ではありません。公式ドキュメントでは、一部のフレームワーク、プライベートネットワーク、データベース、バックグラウンドサービス、ホスティング方式がサポートされない場合があると説明されています。

そのため、複雑な基幹システム、大規模な非同期処理、閉域網との接続、特殊なミドルウェアが必要な構成、厳格なインフラ要件を持つサービスでは、従来のクラウドやPaaSの方が適しています。

「簡単に作れる」ことと「どんなシステムでも載せられる」ことは別です。Sitesは要件を絞ったWeb体験を素早く公開するための選択肢として考えた方が現実的です。

メリット

最大のメリットは、作成から公開までの距離が短いことです。コード生成だけで終わらず、プレビュー、修正、保存、デプロイ、共有までChatGPTを中心に進められます。

  • 自然言語からサイトやアプリを作り始められる
  • ホスティング環境を別途準備しなくても公開できる
  • 修正指示を会話で出せる
  • 永続データやファイル保存にも対応できる
  • アクセス制御やサインインを組み込める
  • 公開後の基本的なアクセス解析を確認できる
  • 既存プロジェクトを持ち込む選択肢もある

特に、インフラ構築そのものが目的ではなく、「業務上必要な小さなツールをまず動かしたい」という場面では効果が出やすいでしょう。

デメリットと注意点

まだパブリックベータ

2026年7月時点でSitesはパブリックベータです。利用上限や対応機能は変更される可能性があり、プランごとの上限値も固定値として公式ドキュメントに一律掲載されているわけではありません。現在の上限はSites画面で確認する必要があります。

プランやアカウントによって表示されない場合がある

OpenAIの最新英語ヘルプでは、SitesはChatGPTワークスペース、Plus、Proアカウント向けのパブリックベータとして案内されています。一方、ロールアウト状況やワークスペース管理者の設定によっては利用できない場合があります。画面にSitesが見当たらないときは、機能が存在しないと判断せず、アカウントへの展開状況や管理者設定を確認した方がよいでしょう。

データレジデンシーには未対応

公式ドキュメントでは、ローンチ時点でSitesはデータレジデンシーや推論レジデンシーに対応していません。デプロイされたSite、コード、D1/R2のデータやファイル、生成物、ログなどが対象です。

保存場所や処理地域に厳密な要件がある企業では、導入前に契約条件や社内ルールとの整合を確認する必要があります。

機密情報をそのまま入れない

公開前には、機密情報、秘密値、共有権限のない第三者コンテンツが含まれていないか確認する必要があります。フォームや掲示板など、訪問者が情報を入力できる機能を付ける場合は、収集する情報の範囲も見直してください。

個人情報を集める場合は運営者側の責任がある

Sitesを使えばフォームやサインインを作れますが、個人データを収集する場合、その利用目的や管理方法についての責任までOpenAIに任せられるわけではありません。

OpenAIのヘルプでは、Siteを通じて収集するエンドユーザーデータについて、Site運営者側がデータ管理者として適用されるプライバシー法やデータ保護法へ対応する必要があると説明されています。必要に応じてプライバシーポリシーを用意し、収集項目を必要最小限にすることが求められます。

また、保護対象の医療情報や決済カードデータをSites自身で処理する用途は避ける必要があります。法律や契約に関わる部分は、実際の利用地域や用途によって条件が変わるため、最新の公式情報と必要に応じて専門家への確認が必要です。

ChatGPT Sitesと従来のWeb開発はどう使い分けるか

Sitesの登場で、Web開発がすべて不要になるわけではありません。むしろ「どの段階までSitesで持つか」を決めることが重要です。

企画初期や小規模ツールでは、Sitesで素早く作って利用者の反応を見る方法が合理的です。その後、利用者数が増える、複雑な認証が必要になる、外部システムとの接続が増える、インフラ要件が厳しくなる、といった段階で従来の開発基盤へ移す判断ができます。

フリーランスSEの立場でも、最初から大きな構成を組むより、顧客と完成イメージを共有するためのプロトタイプとしてSitesを使う価値があります。ただし、試作品をそのまま本番システムにするかどうかは、セキュリティ、運用、データ管理、障害時対応まで含めて判断する必要があります。

最初に試すなら、要件を絞った1画面から

初めて使う場合は、いきなり大規模なサービスを作ろうとせず、目的が明確な小さなサイトから始めるのがおすすめです。

例えば、次のような依頼なら必要な機能を整理しやすくなります。

「案件の進捗を確認する社内向けWebサイトを作ってください。案件名、担当者、期限、ステータスを一覧表示し、ステータスで絞り込めるようにしてください。データは訪問後も保存し、公開範囲は最初は自分だけにしてください。スマートフォンでも見やすくしてください。」

このように、対象者、目的、必要なデータ、保存の有無、公開範囲、画面条件まで入れると、単に「管理画面を作って」と依頼するより意図が伝わりやすくなります。

ChatGPT Sitesが向いている人

  • アイデアをすぐ動くWeb画面にしたい人
  • 小規模な業務ツールや社内ダッシュボードを作りたい人
  • 顧客やチームとプロトタイプを共有したいSE
  • デプロイ環境の準備に時間をかけず検証したい人
  • 自然言語で修正を繰り返しながら作りたい人

向いていないケース

  • 複雑なバックエンドや特殊なインフラ構成が必須
  • 閉域網や特定のプライベートネットワーク接続が必要
  • データ保管地域を厳密に固定する必要がある
  • 未対応のフレームワークやホスティング構成へ強く依存している
  • パブリックベータの仕様変更を受け入れにくい本番システム

まとめ

ChatGPT Sitesは、「AIにWebページを書かせる機能」よりも一歩進んだ、作成からホスティング、公開、共有までをChatGPT内でつなぐ仕組みです。

Webサイトや軽量アプリを自然言語から作成し、データ保存、ファイル保存、アクセス制御、サインイン、独自ドメイン、アクセス解析まで組み合わせられるため、プロトタイプや小規模業務ツールにはかなり実用的な選択肢になっています。

一方で、2026年7月時点ではパブリックベータであり、利用上限や提供範囲は変わる可能性があります。さらに、対応できないインフラ構成やデータレジデンシーの制約もあるため、本番利用では従来のWeb開発基盤と比較して判断する必要があります。

まずは機密情報を含まない小さなツールを1つ作り、「生成→保存→レビュー→公開」の流れと、どこまで実務で使えるかを確認するのが現実的です。

参考情報

※機能、提供プラン、利用上限、対応地域は変更される可能性があります。内容は2026年7月28日時点で確認したOpenAI公式情報を基にしています。

コメント