ChatGPT Sitesはアイデアを公開可能なウェブサイトに変えるが、本当の試練は公開にある

OpenAIは、ChatGPT Sitesによってアイデアを公開可能なウェブサイトに変えられるパブリックベータを開始した。これにより、これまでプロトタイプと実際に稼働するプロダクトを隔てていたデプロイの工程が不要になる。

7月10日に開始されたこの機能では、プロンプトまたは互換性のあるプロジェクトから、ウェブサイト、ウェブアプリ、ゲームをChatGPTで作成し、ホスト、改善、共有できる。OpenAI Developersの投稿では、個人向けの集中アプリなど、同社のチームメンバーが作成したサイトを通じてこの機能を紹介している。

重要な変化は、ChatGPTがウェブサイトを生成できるようになったことではない。AIコーディング製品は、何年も前からその機能を提供してきた。ChatGPT Sitesは現在、生成、ストレージ、アクセス制御、アナリティクス、バージョン管理、本番ホスティングを一つの会話型ワークフローに組み込んでいる。

この組み合わせは、LovableやReplitのようなプロンプトベースのビルダーにプレッシャーを与える一方、Vercelのようなホスティングプラットフォームにも挑戦するものだ。OpenAIは、コードをユーザーに渡して運用作業を別の場所で完了させるだけではなくなった。

しかし、同じ統合によって、より大きな責任がOpenAIの環境に移される。すべてのデプロイは本番デプロイとなり、一般公開には依然として制限があり、クリエイターは自身のサイトと訪問者データについて法的責任を負う。

その結果、これは単なる別のAIウェブサイトジェネレーターよりも明確な提案になっている。OpenAIは、アイデアを説明し、構築し、レビューし、公開し、計測し、維持する場所としてChatGPTを位置付けようとしている。

ChatGPT Sitesは一つの会話でアイデアを公開可能なウェブサイトに変える

ChatGPT Sitesは、ウェブプロジェクトを生成することと、他の人に動作するリンクを提供することの隔たりを埋める。

ユーザーは、ウェブサイトの内容、想定する利用者、必要な動作、参照情報を説明することから始められる。すでにコードを含んでいる互換性のあるローカルプロジェクトから始めることも可能だ。

ChatGPTはプレビューを作成し、会話形式の編集を受け付け、デプロイ用のバージョンを準備する。ユーザーは会話を離れることなく、文章、スタイル、レイアウト、フォーム、リンク、計算、インタラクティブな動作の変更を依頼できる。

このワークフローには、実際上4つの段階がある。説明、レビュー、改善、共有だ。Sitesのドキュメントによると、ウェブサイトについて言及するか、Sitesを明示的に参照することで、このワークフローを呼び出せる。

単純に聞こえるが、最後の段階によって製品カテゴリーが変わる。生成された出力は、一時的なプレビューに表示されるだけではない。ChatGPTはデプロイ可能なバージョンを保存し、OpenAIが管理するホスティングを通じて公開できる。

デプロイごとに本番用URLが発行される。その後、ユーザーは対象となるオーディエンスを選び、承認したバージョンを公開して、そのリンクを配布できる。

OpenAIのローンチ資料は、なぜこれが重要なのかを示している。紹介された個人向けの集中アプリは、静的なデモではなく、小規模なプロダクトだ。これは、インタラクティブなモックアップと一般に利用できるアプリケーションの間で止まってしまいがちなアイデアの典型例である。

Sitesは、より一般的な形式にも対応している。OpenAIは、ランディングページ、プロジェクトダッシュボード、ローンチ管理表、オンボーディングページ、計算ツール、社内ツール、ゲームなどを想定されるユースケースとして挙げている。

これらは、意図的に対象を絞ったプロジェクトだ。OpenAIはSitesを、あらゆるソフトウェアスタック、開発チーム、ホスティングプラットフォームに取って代わる万能な存在として位置付けてはいない。

それでも、対応する基盤は静的ページを超えている。プロジェクトでは、永続的な構造化データ、ファイルストレージ、訪問者認証、既存ドメインとの接続を求めることができる。

OpenAIによると、永続的なレコードに使われるリレーショナルデータベースはD1だ。R2は画像、ドキュメント、音声、動画、その他のアップロードファイル向けのオブジェクトストレージを提供する。

クリエイターは「Sign in with ChatGPT」も追加できる。公開サイトはログアウト状態の訪問者にも表示しつつ、認証後にはパーソナライズされた体験を提供できる。

この組み合わせによって、集中アプリの例はより意味のあるものになる。基本的なタイマーは静的に作れるが、セッションの記憶、プロフィール、進捗の保存には永続的な状態とアイデンティティが必要になる。

Sitesは、外部のアナリティクスライブラリを必要とせずにトラフィックも記録する。そのダッシュボードでは、ユニークビジター、ページビュー、時間の経過に伴う変化を確認できる。ただし、ローンチ時点ではEnterpriseが所有するサイトにはこのアナリティクス表示がない。

したがって、今回のニュースはプロンプトからコードを生成する機能を超えている。OpenAIは、アイデアから監視可能な本番サイトに至るまでの複数の独立したサービスを、一つの会話型の経路にまとめた。

デプロイレイヤーこそ、OpenAIが本当に仕掛けた製品上の変化

決定的な特徴は、コード生成の精度向上ではなく、ユーザーのワークフローからデプロイに伴う調整作業を取り除いたことだ。

Sites以前、ChatGPTのユーザーはHTML、Reactコンポーネント、あるいはアプリケーション全体を依頼できた。しかし、それをオンラインで公開するには通常、別のアカウント、リポジトリ、デプロイ設定、ホスティングプロバイダーが必要だった。

クリエイターは、環境変数、ストレージ、認証、アナリティクス、ドメインも接続しなければならなかった。引き継ぎが発生するたびに、設定ミスや作業の放棄につながる可能性が生まれた。

ChatGPT Sitesは、こうした引き継ぎを圧縮する。OpenAIの製品ガイドによると、Codexは構築したのと同じワークスペースからサイトを作成し、デプロイできる。

この違いが、OpenAIが軽量アプリや社内ツールを強調する理由を説明している。こうしたプロジェクトの多くは価値がある一方、専任のエンジニアリングサイクルを組むほどの規模ではない。

プロダクトマネージャーが、ある四半期だけ使うローンチ管理表を必要とすることもある。オペレーションチームが、問い合わせダッシュボードを必要とする場合もある。研究者が、ある調査のためにインタラクティブなプレゼンテーションを作りたいこともある。

こうしたプロジェクトは、スプレッドシート、スライド資料、共有ドキュメント、未完成のプロトタイプの中に置かれがちだ。問題は、ソフトウェアの機能が常に不足していることではない。使えるインターフェースを作り、維持するための負担が問題なのだ。

Sitesは、ホスティングをコーディングエージェントから直接利用できるネイティブなアクションにする。クリエイターは、承認したバージョンのデプロイをChatGPTに依頼し、そのURLを受け取れる。

基盤となるプロセスでは、保存されたバージョンとデプロイを区別している。保存はレビュー可能な候補を作成し、デプロイはその候補を設定されたオーディエンスに公開する。

この分離は重要だ。なぜなら、デプロイされたものはすべて公開状態になるからだ。非公開でレビューしたいユーザーは、まずバージョンを保存し、デプロイを避ける必要がある。

バージョン管理によって、OpenAIはより信頼性のある本番ワークフローも提供できる。ユーザーは保存された候補を確認し、選択したバージョンを公開し、その後プロジェクトに戻って修正できる。

これは、AIが生成したコードブロックを受け取り、次に何をするかを手作業で決める体験とは異なる。エージェントは、作成、修正、設定、ホスティングの間でコンテキストを維持する。

互換性のあるローカルプロジェクトでは、システムがソースコードとホスト先を紐付ける。その関係をホスティング設定ファイルに記録し、保存されたバージョンをGitコミットと関連付ける。

この経路により、開発者は会話型の構築と従来型のソース管理を橋渡しできる。ローカルで編集を続けながら、ChatGPTをデプロイ管理に利用できる。

ただし現時点では、管理操作はウェブ版またはデスクトップ版のChatGPTに限られる。CodexのコマンドラインインターフェースとIDE拡張機能ではプロジェクトを編集できるが、単独のSites管理画面は利用できない。

この制限は、OpenAIの戦略の中心を示している。Sitesは、開発者のターミナルに別のデプロイコマンドを追加するためではなく、ChatGPTのワークスペースを強化するために設計されている。

同じ戦略は、OpenAIが最近強調している「完了した仕事」にも表れている。ChatGPTには、助言、下書き、単独のコードではなく、完成した成果物を作ることがますます期待されている。

実際に稼働するウェブサイトを公開することは、その方向性を試す明確なテストになる。リンクは開かれ、共有され、計測され、元の会話に一切参加していない人々によって評価される可能性がある。

プロンプトビルダーとホスティングプラットフォームは異なる形で圧力を受ける

ChatGPT Sitesは、AIビルダーとデプロイプラットフォームの間に位置するが、どちらのカテゴリーも完全に置き換えるものではない。

Lovable、Replitなどの製品は、自然言語のリクエストを機能するアプリケーションに変えることを自らのアイデンティティの中心に据えてきた。これらのインターフェースは、非開発者が従来型のツールチェーンを組み立てることなく、アイデアから視覚的なプロダクトへ移行できるよう支援する。

Vercel、Netlify、Cloudflareは、別の方向から市場にアプローチしている。ウェブプロジェクト向けに、インフラ、デプロイワークフロー、ドメイン、アナリティクス、ストレージ、本番環境の制御機能を提供している。

OpenAIは現在、両方のグループと重なる位置にいる。Sitesは体験を生成するだけでなく、その体験が動作する環境も運用する。

この重なりは、直ちに流通面でのプレッシャーを生む。ChatGPTはすでに多くのコーディングリクエストの出発点になっているため、ユーザーはアイデアを試す前に別のビルダーを探す必要がなくなる。

この利点は、カジュアルなプロジェクトで特に明確だ。集中アプリ、計算ツール、ポートフォリオ、小規模なダッシュボードを作るユーザーにとっては、インフラの柔軟性よりもスピードの方が重要かもしれない。

ChatGPTは、プロジェクトを生み出した会話を保持できる。同じコンテキストが、見た目の変更、動作の更新、デプロイ設定、後からの修正を導く。

専用AIビルダーにも、差別化の余地は残されている。専門的なビジュアルエディター、より深いデザイン制御、統合コラボレーション、より幅広いテンプレート、アプリケーション作成に完全に特化したワークフローを提供できるからだ。

従来型のホスティングプラットフォームは、要求の厳しいプロダクトに対して、さらに大きな技術的優位性を保っている。成熟したチームには、広範な可観測性、デプロイ自動化、リージョン制御、フレームワーク対応、詳細なインフラ設定が必要になる。

OpenAIもこの境界を認めている。同社のAcademyガイダンスでは、Sitesは対象を絞ったページや軽量アプリに適していると説明し、複雑なプロジェクトについては、より大規模なエンジニアリング作業を推奨している。

一部のフレームワーク、プライベートネットワーク、データベース、バックグラウンドサービス、ホスティングパターンには、引き続き対応していない。互換性はSitesのランタイムと、各アカウントで有効になっている機能に左右される。

Sitesはベータ期間中、利用制限も導入している。制限に達すると、別のサイトの作成、ストレージの追加、高トラフィックのプロジェクトの一般公開継続ができなくなる可能性がある。

こうした制約により、初期段階での競争上の影響は一様ではない。Sitesが最も強い脅威となるのは、インフラの選択肢より利便性が重視される、市場の中でも複雑性が低い領域だ。

より大きな戦略的リスクは、その先にある。OpenAIがランタイムを拡張し、ビジュアル制御を改善し、より多くの統合に対応すれば、軽量なプロジェクトはChatGPTを離れることなく成長できる。

その結果、専用ビルダーやホスティングのダッシュボードに流れる新規ユーザーが減る可能性がある。競合各社は、基本的な公開機能ではなく、制御性、専門性、移植性で勝負する必要に迫られるだろう。

ナレッジワーカーにとって、この変化は成果物の定義も変える。研究やプロジェクトに関する構造化された情報の集合は、別の静的ドキュメントではなく、インタラクティブなインターフェースになり得る。

検索可能なAIワークフローを使うチームは、承認済みの出力をダッシュボードやローンチ管理表に変えられるだろう。サイトは、元のナレッジソースではなく、プレゼンテーション層になる。

この区別は重要だ。なぜなら、生成されたインターフェースの正確さは、基盤となる情報の最新性に左右されるからだ。洗練されたダッシュボードでも、参照元の資料が古くなれば、読者を誤解させる可能性がある。

簡単な公開というストーリーには、厳しい制限が隠れている

ChatGPT Sitesはデプロイの障壁を下げるが、プロダクトの所有責任、セキュリティレビュー、データに関する責任までなくすわけではない。

最初の制約は利用可能性に関するものだ。Sitesはパブリックベータであり、アクセス可否はプラン、地域、提供状況、ワークスペース設定によって異なる。

OpenAIの公開ガイダンスによると、提供開始時点ではFreeおよびGoアカウントでは利用できない。また、EEA、スイス、英国でも利用できない。

Enterpriseの顧客には追加の管理項目がある。管理者は、Sitesを有効にするか、どのロールがプロジェクトを作成できるか、そして公開設定が可能かどうかを決定する。

Enterpriseのワークスペースでは、公開設定はデフォルトで無効になっている。提供開始時点では、カスタムドメインと組み込みの分析ビューもEnterprise所有サイトでは利用できない。

2つ目の制約は、実行環境の範囲に関わる。OpenAIが説明しているのは、任意のインフラではなく、選択された形態のプロジェクトをサポートするホスト環境だ。

既存のアプリケーションが変更なしでデプロイできるとは考えないほうがよい。ChatGPTはまず、そのプロジェクトが互換性のある成果物を生成できるか確認する必要がある。

3つ目の制約は、ライブ情報に関するものだ。OpenAIのAcademy記事によると、現時点でSitesはライブデータソースに直接接続できない。

チームは別の自動化処理を使って更新情報を収集し、更新版を準備することはできる。ただし、その更新内容を誰かが確認し、サイトを再デプロイする必要がある。

このプロセスは、定期的に更新するプロジェクトダッシュボードには適している可能性がある。一方、継続的な同期、バックグラウンドジョブ、時間に敏感な運用データを必要とするアプリケーションには適性が低い。

4つ目の制約は、公開に伴うリスクだ。会話型のワークフローでは、ファイル、フォーム、リンク、生成テキスト、認証の挙動を外部に公開する場合でも、デプロイが単なる最後の小さな操作に感じられてしまうことがある。

OpenAIは、共有する前に訪問者の視点からサイトをテストするようクリエイターに求めている。さらに、対象ユーザーを確認し、機密情報を削除し、個人データを収集する機能を点検しなければならない。

この懸念は理論上のものではない。プロンプトには、会話履歴、アップロードされたファイル、参照資料、生成された成果物、アクセス設定、ホストされたURL、運用メタデータが含まれる可能性がある。

こうしたコンテキストが意図せず公開サイトに到達すれば、統合された公開機能の利便性は負債になる。ユーザーは、どの情報が会話からデプロイ済みの体験へ移されたのかを理解しなければならない。

OpenAIは、プロジェクトの目的を満たす中で最も限定的な対象範囲を選ぶよう勧めている。新しいサイトは、アクセス設定が変更されるまで、当初は所有者とワークスペース管理者に限定される。

利用可能な設定には、指定ユーザー、ワークスペースメンバー、インターネット上の全員などがある。共有権限によって訪問者はサイトを閲覧できるが、編集権限が与えられるわけではない。

OpenAIがサイトをホストできるからといって、同社がそのサイトを審査または承認したことを意味するわけでもない。機能、訪問者が提供するコンテンツ、認証、法令遵守、サポート上の責任は、引き続きクリエイターが負う。

簡単な作成と継続的な責任の間にある隔たりこそが、このプロダクトの中心的なトレードオフだ。Sitesはソフトウェアの公開を身近なものにする一方で、ソフトウェアを運用することに伴う義務は残している。

公開後のサイトにも、責任を負う所有者が必要

OpenAIは実行環境を提供するが、サイトが何を収集し、何を主張し、何を公開するかについては、引き続きクリエイターが責任を負う。

ChatGPT Sitesの規約では、クリエイターが提出したウェブサイトコンテンツについて、既存の所有権を保持すると定めている。同時に、そのコンテンツをホストおよび運用するために必要なライセンスをOpenAIに付与する。

OpenAIは、ウェブサイトがChatGPTによって提供されていることを示す表示を掲載できる。ただし、クリエイターは、OpenAIが自身のサイトを認証、支援、承認したと受け取られる表現をしてはならない。

規約では、訪問者が送信する情報について、クリエイターが責任を負うと定めている。これには、サイトを通じて収集されるテキスト、画像、アップロード資料、ログイン情報、その他の個人データが含まれる。

サイトが個人情報を収集する場合、そのクリエイターはデータ管理者として行動する。したがって、透明性や同意に関する要件を含め、適用されるプライバシー上の義務を満たさなければならない。

Sitesは保護対象保健情報を処理できない。また、決済カード情報を直接処理することもできない。ただし、指定された条件の下で、クリエイターが第三者の決済プロバイダーを実装することは可能だ。

Eコマースには、さらなる責任が伴う。フルフィルメント、返金、カスタマーサポート、税務、外部決済サービスの設定は、クリエイターが管理する。

こうしたルールは、生成されたプロトタイプと実際のサービスの境界を示している。訪問者が情報を送信したり取引を行ったりできるようになった瞬間、そのプロジェクトには運用上および法的な影響が生じる。

認証も同様に精査が必要だ。Sign in with ChatGPTによって、ユーザーの身元を認識する機能は構築しやすくなるが、アプリケーションレベルの認可に取って代わるものではない。

Sitesは、認証済みのメールアドレスとプロフィール情報をサーバーに転送する。OpenAIは、認可に関する判断をサーバー側のコードに残すよう、クリエイターに明示的に伝えている。

つまり、ログインを求めるプロンプトだけでは、完全なセキュリティ設計にはならない。各訪問者がどのレコードにアクセスできるのかをクリエイターが決定し、その境界が守られるかをテストする必要がある。

シークレットには、別途慎重な運用が必要だ。ホスト環境の値は、プロンプト、添付ファイル、プロジェクトコンテンツ、ホスティングマニフェストに記載せず、サイト設定から構成すべきである。

環境値を変更した後は、承認済みの保存バージョンを再デプロイしなければならない。そうしなければ、本番環境では以前の設定が使われ続ける可能性がある。

OpenAIは、安全性またはポリシー上の理由により、サイトを制限または削除することもできる。クリエイターは、自分の作品を非公開にしたり、対象範囲を制限したり、完全に削除したりできる。

削除は取り消せない。直ちに公開状態を解除したいだけであれば、アクセス設定の変更という、より破壊的でない選択肢がある。

こうした点を踏まえると、誰もが思いつきを完成したプロダクトに変えられるという考えは複雑になる。ChatGPT Sitesはデプロイ済みの成果物を生成できるが、その成果物を責任を持って管理する所有者は依然として必要だ。

組織は、サイトごとのリスクに応じたレビュー基準を設ける必要がある。公開用のシンプルな集中タイマーと、従業員情報を含む社内ダッシュボードに同じプロセスを適用する必要はない。

チームは、公開を承認する担当者、生成コードをレビューする担当者、ソースの権利関係を確認する担当者、訪問者データや機能に問題が生じた際に対応する担当者を定めるべきだ。

こうした所有責任がなければ、Sitesはソフトウェアの無秩序な増殖という、よくある問題を拡大させる可能性がある。従業員が便利なツールを素早く作る一方で、管理者はどのツールが稼働中で信頼できるのかを把握できなくなる恐れがある。

ChatGPT Sitesがベータを超えられるかを示す3つのシグナル

次の段階は、利用の広がり、実行環境の拡張、そして会話から作られたソフトウェアの増加を組織が管理できるかどうかにかかっている。

最初のシグナルは、デモを超えた利用実績だ。OpenAIは、ユーザーがデプロイ済みサイトに再訪し、更新し、継続的な利用者に共有していることを示す必要がある。

組み込みの分析機能は、個人クリエイターにとって出発点となる。ユニーク訪問者数やページビューによって、生成された体験が公開告知の注目を失った後も存続しているかを確認できる。

重要なのは、作成されたサイトの数より利用状況だ。放置されたランディングページが大量に存在するなら、持続的なアプリケーションへの需要ではなく、実験への需要があることを示すだろう。

継続的な再デプロイも有用な指標になる。クリエイターが改訂版を保存して公開するなら、Sitesは一度限りの目新しさではなく、継続的なワークフローを支えていることになる。

2つ目のシグナルは、サポート対象となる実行環境の拡張だ。ライブデータへの直接接続、より幅広いフレームワーク互換性、強化されたバックグラウンド処理、追加のインフラ制御が実現すれば、対象市場は広がる。

ただし、それぞれの追加機能はリスクと複雑さも高める。OpenAIは、会話型プロダクトを、設定項目の多い別のクラウドコンソールに変えることなく、機能を拡張しなければならない。

Enterpriseへの対応は、特に重要な指標になる。カスタムドメイン、分析機能、データレジデンシーの選択肢、より強力なガバナンスが整えば、Sitesはビジネス利用においてより説得力を持つ。

提供開始時点で、Sitesにはデータレジデンシーと推論レジデンシーがない。この制限は、デプロイされたコード、保存データ、成果物、ログに適用される。

この隔たりによって、その利便性にかかわらず、Sitesを検討対象にできない規制対象組織も出てくるだろう。地域ごとの制御に対応できれば、OpenAIのビジネス上の主張は強まる。

3つ目のシグナルは、競合の反応だ。プロンプトベースのビルダーは、デザインの深さ、エクスポートの選択肢、コラボレーション、あるいは単一のモデルプロバイダーへの依存からの独立性を強調する可能性がある。

ホスティング企業は、インフラの可搬性を維持しながら、AI生成デプロイを容易にできる。また、より成熟した可観測性、セキュリティ、スケーリング制御を提供することも可能だ。

OpenAIの最大の強みは、引き続きその分布力にある。ユーザーはすでにChatGPTに対して、アイデアの発展、仕様書の作成、アセットの制作、コードの生成を依頼している。

Sitesを使えば、そうした素材がライブな体験になるまで会話を続けられる。この連続性を、個別に分かれた複数のプロダクトで再現するのは難しい。

一方、その統合性こそが弱点でもある。ユーザーは、OpenAIの実行環境の境界、ベータ版としての制限、ガバナンスモデル、ホスティング関係を受け入れなければならない。

ChatGPT Sitesはアイデアを公開可能なウェブサイトへと変えるが、長期的な競争の焦点は公開後に何が起きるかにある。信頼性の高い運用、責任あるデータ処理、継続的な利用が、それらのサイトをプロダクトへ成長させられるかどうかを決める。

現時点では、クリエイターは明確な対象ユーザーを持つ、焦点の定まった低リスクのプロジェクトでSitesを試すべきだ。生成されたすべての挙動を確認し、デプロイ前にバージョンを保存し、外部の訪問者として結果を点検してほしい。

そして、ChatGPTが公開できるかどうかより重要な問いを考えるべきだ。データが変化し、利用者が増え、最初のセキュリティ判断に失敗したとき、このサイトを誰が維持するのか。