ChatGPT Sitesとは？機能や料金、使い方やv0/Boltとの違いを徹底解説

ChatGPT Sites（チャットジーピーティー サイツ）は、OpenAIが2026年6月にプレビュー公開し、7月9日のChatGPT Work発表と同時に位置づけが明確化された、ChatGPT内で対話しながらWebサイト・軽量アプリ・ダッシュボードを生成しホスティングまで完結させる新機能です。

ChatGPT Work・Codexのどちらからも呼び出せ、社内向けの業務アプリを自然言語だけで内製できる点が、Vercel v0・Bolt・Lovable・Replitなど既存のAIアプリビルダーと明確に立ち位置を分けています。

本記事では、ChatGPT Sitesの位置づけ・作れるもの・技術基盤（Sites Runtime、D1、R2、workspace identity）・使い方・料金・制限事項・競合との棲み分け・実務判断まで、2026年7月時点の最新情報で体系的に解説します。

ChatGPT Sitesとは？ChatGPT Workから対話で作れるホスト付きミニアプリ

ChatGPT Sitesは、ChatGPT WorkまたはCodex内で自然言語だけで「動くWebサイト・軽量アプリ・ダッシュボード」を生成し、そのままホスティングまで完結させられる新機能です。

2026年6月にプレビュー公開されたのち、7月9日発表のChatGPT WorkでChat・Work・Codexの3ペインを束ねる新desktop app内の主要出力先の1つとして正式に位置づけられました。

ChatGPT desktop appのピッカーには「Work（For getting work done）」を先頭に、Codex・Scheduled・Sitesが並ぶ（出典：OpenAI）

ChatGPT Work・Codex・Chatの3層の中での位置づけ

2026年7月のChatGPT Work発表以降、OpenAIの生産性ラインは3つのペインに整理されました。ChatGPT Sitesはこの3ペインを横断する「成果物レイヤー」の役割を担います。

• Chat
  質問・会話・ブレインストーミング用のペイン。従来のChatGPT体験の延長。
  
  

• Work
  リサーチ・分析・成果物作成用のペイン。sheets、slides、docs、reports、そしてSitesを仕上げる役割を担う。
  
  

• Codex
  コーディングエージェント用のペイン。リポジトリを読み、ファイルを編集し、コマンドを実行する。既存プロジェクトからSitesにデプロイする経路もここにある。

ここでのポイントは、ChatGPT SitesはWorkとCodexの2方向から起動できる、という点です。

たとえば会話ベースで「経費申請ダッシュボードを作って」と指示すればWorkから、既存のNext.jsプロジェクトを「Sitesで公開して」と指示すればCodexからそれぞれ立ち上がります。

Chatとの直接的な統合はなく、Sitesは「意思決定を支援するChat」ではなく「実物を仕上げるWork/Codex」の側に属する成果物レイヤーです。

ChatGPT Sitesで作れるもの——社内ダッシュボード・軽量Webアプリ・ゲーム

ChatGPT Sitesが得意な生成物は、大きく「情報表示系」「業務ワークフロー系」「体験系」の3方向に分かれます。

以下の表で、公式ヘルプおよびSites showcaseで示された代表的な用途カテゴリを整理しました。

この3方向を象徴するのが、OpenAIがSites showcaseで公開している6事例です。
左サイドバー・中央ワークスペース・右パネルという業務アプリで見慣れた3カラム構成が、いずれの実例でも共通しています。

以下、Sites showcaseの3方向カテゴリ（情報表示系・業務ワークフロー系・体験系）に沿って、代表事例を見ていきます。

情報表示系——Enablement Hub・Pulse Dashboard・Launch Cal

情報表示系は、社内データ・KPI・カレンダーを1画面で可視化する用途です。

D1に設定値やスナップショットを保持する構成が共通しており、外部DB接続なしにそのまま動く手軽さが特徴です。

Enablement Hub——社内トレーニングを6軸で絞り込める知識ライブラリ

Enablement Hubは、検索・フィルタ・ブックマークが効く社内トレーニングライブラリです。D1をバックエンドに、部門別コンテンツを縦横で切り出せる構成になっています。

Sites showcase「Enablement Hub」（出典：OpenAI Developers）

役割・チーム・製品領域・レベル・フォーマット・鮮度の6軸で絞り込める設計になっており、LMSやKnowledge Baseで通常3〜4か月かかる情報アーキテクチャ設計を、プロンプト1本で立ち上げられます。既存LMSの棚卸しが進んでいない現場ほど、まず投げて土台を可視化する使い方に向いています。

Pulse Dashboard——KPI俯瞰・ドリルダウン・Business Questionsの3層構造

Pulse Dashboardは、指標・トレンド・リネージ情報を並べる経営ダッシュボードです。D1に設定値とキャッシュ済みスナップショットを保持します。

Sites showcase「Pulse Dashboard」（出典：OpenAI Developers）

経営ダッシュボードの定石である「KPI俯瞰＋ドリルダウン＋関連するBusiness Questionsの提示」の3層構造が、Looker StudioやTableauで作り込む工数なしで再現されています。BIツールのライセンス確保・データソース接続・ワイヤーフレーム設計の初期段階を丸ごと省略できるため、経営数字の見える化を試したいがBI人材が薄い組織に向いています。

Launch Cal——リスクシグナル付き月次ローンチカレンダー

Launch Calは、毎月のプロダクトローンチを月次カレンダーで一覧し、リスクシグナル・チェックリスト・関連ソースを紐付ける計画ハブです。

Sites showcase「Launch Cal」（出典：OpenAI Developers）

Jira・Asana・Airtableで組み上げるプロダクトローンチ管理ボードの中核機能を、リスクシグナル（HOLD／HIGH RISK）をカード表面に露出させる設計で凝縮しています。「今月危ういローンチはどれか」を俯瞰視点で一目で判断でき、経営会議前のスクリーニング資料としてそのまま使える密度に仕上がっています。

業務ワークフロー系——Onboarding Hub・Sparkboard・Event Planning Hub

業務ワークフロー系は、手続き・投稿・承認といった業務フローそのものをアプリ化する用途です。構造化データはD1、添付ファイルはR2に保管する構成が共通しています。

Onboarding Hub——入社1週目の資料と手続きを1画面に集約

Onboarding Hubは、入社1週目のチェックリスト・資料・メモ・アップロードドキュメントを1画面に束ねる新人立ち上げ用ハブです。ユーザー状態とメタデータはD1に、アップロード実体はR2に保管する構成になっています。

Sites showcase「Onboarding Hub」（出典：OpenAI Developers）

通常であればSlack・Google Calendar・Notion・Boxに散らばる要素を、1画面で完結できるのが本質です。新人が「次に何をやればいいか」で迷うたびに複数SaaSを行き来する時間を、対話生成の初期設定だけで数十分に圧縮できます。

Sparkboard——アイデア投稿から採用Shipまで一気通貫のワークフロー

Sparkboardは、従業員のアイデア投稿を「認証付き投稿→投票→コメント→ステータス管理→貢献者ランキング」まで一気通貫で扱うワークフローアプリです。

Sites showcase「Sparkboard」（出典：OpenAI Developers）

アイデア投稿から採用・Shipまでの6段階ライフサイクルをステータス管理でそのまま表現しており、IdeaScaleやBrightideaといった社内アイデアマネジメントSaaSの機能骨格が最初から備わっています。貢献者ランキングを常時表示することで投稿インセンティブ設計まで組み込まれており、社内アイデア募集を「立ち上げたが投稿が来ない」状態にしないための実運用上の工夫が効いています。

Event Planning Hub——申請・承認からPolicy readinessまで扱う社内イベント基盤

Event Planning Hubは、イベント申請・承認・テンプレート・マイルストーン・ポリシーチェックまでを扱う社内イベント管理アプリです。

Sites showcase「Event Planning Hub」（出典：OpenAI Developers）

社内イベント運営を「申請→承認→開催→振り返り」のライフサイクルで管理する設計に加え、「Policy readiness（コンプライアンスチェック充足率）」をKPI化している点が特徴です。イベント管理を単なる予定表ではなく法務・情シスと共有する統制対象として扱う思想が明確で、Enterprise用途で導入合意を取りやすい構成になっています。

体験系——プロトタイプ・社内ゲーム・教育ミニアプリ

体験系はSites showcaseの6事例には含まれていませんが、D1（スコアやユーザー進捗）＋R2（アバターや素材）の構成で同じインフラ上に構築できます。

社内アイスブレイク用のクイズゲーム、部門向けミニ研修シミュレーター、新規プロダクトの操作感を確かめるプロトタイプなど、「本番運用ではないが体験共有はしたい」用途と相性が良いです。

この6例に共通するのは、いずれも「外部向けLP」ではなく組織内部の業務ワークフローを丸ごとアプリ化する方向に振れている点です。

Vercel v0はフルスタックアプリ生成にも対応する一方でGit連携＋外部DB接続を前提とする設計です。それに対しChatGPT Sitesが最初から社内ダッシュボード寄りの showcase を並べているのは、ホスティング・データ層・認証をまとめて内包する社内アプリ向けのターゲット用途を明確に示す設計判断だと読めます。

ChatGPT Sitesの技術基盤——Sites Runtime・D1・R2・ワークスペース認証

ChatGPT Sitesが単なる「HTML生成AI」ではなくフルスタックの内製手段として機能する理由は、Sites Runtimeが最初からリレーショナルDB・オブジェクトストレージ・認証を内蔵している点にあります。

Blossom BankのRevenue Forecast plannerは、左サイドで3シナリオ（Base Case / Upside / Conservative）と主要ドライバー（Net interest income・Deposit growth・Credit losses）を切替え、中央にRevenue Forecast推移グラフ、下部にBusiness Line別の予測値表を配置する構成です。

Codex/Sitesの発表で示された架空銀行Blossom BankのRevenue Forecast planner例（出典：OpenAI）

Sitesがこうしたダッシュボード・プランナー系アプリの出力先になり得ることを示すサンプルで、Sites Runtimeが持つD1（構造化データ）とR2（添付ファイル）と認証の組み合わせが、業務プランナーの内製手段として使える幅を象徴しています。

OpenAI公式ヘルプおよびSites developer guideは、Sitesが以下のバインディングを介して動作すると明記しています。

D1・R2・ワークスペース認証の役割

以下の表で、Sites Runtimeが提供する主要バインディングを整理しました。

ここで重要なのは、D1（構造化データ）とR2（ファイル本体）を組み合わせる二段構えが公式ドキュメントで推奨されている、という点です。

たとえば「アバター画像付きの社内投稿アプリ」を作る場合、投稿本文と投稿者IDはD1、アバター画像実体はR2、という分担が公式のプロンプト例「Add player scores and avatar uploads to this game」でそのまま示されています。

さらに社内向けのSitesでは、workspace-authenticated user identityを使えば自前で認証基盤を組む必要がなく、ChatGPTワークスペースのアカウントがそのまま社内SSO相当として動きます。

これは情シスがゼロから認証基盤を立てずに社内アプリを配布できることを意味しており、ノーコード系ツールで「認証だけが最後まで残る問題」だったポイントを構造的に解いています。

hosting.jsonでローカルプロジェクトと結ぶ設計

Sitesはローカルのソースプロジェクトとホスティング先を「.openai/hosting.json」ファイルで紐付ける設計です。既存のNext.jsやReactのプロジェクトを持ち込んで、そのままSitesに公開する経路が想定されています。

Sites developer guideが例示している最小構成は次のとおりです。

{
  "project_id": "<project-id>",
  "d1": "DB",
  "r2": null
}

このファイルにはproject_idと、有効化した各ストレージバインディング名だけが入り、シークレット値は含めません。環境変数・APIキー・秘匿値はhosting.jsonに書かず、Sitesの設定画面から別途登録する運用が推奨されています。

この設計から読み取れるのは、Sitesが「LP生成AI」ではなくCodexで扱うローカルリポジトリと1対1でホスティング先を結びつけるフルスタックのデプロイ層として位置づけられている、という点です。

Codex側でリポジトリを編集し、レビューを通してからSitesに再デプロイする、という開発フローが公式で想定されています。

ChatGPT Sitesの使い方——プロンプト→Save→Deploy→共有→独自ドメイン

ChatGPT Sitesの実行フローは、大きく4段階に整理できます。各段階を丁寧に踏むほど、想定と違うサイトが公開URLで晒される事故を避けやすくなります。

プロンプト設計の4要素（audience・purpose・data・constraints）

最初のステップは、プロンプト設計です。ここで伝えるべきは、対象読者・目的・必要な振る舞い・使わせたい情報の4点です。プロンプトに「website」という語を含めるか、@Sitesと明示することで、SitesがWork/Codexから起動します。

以下は公式Developer guideに掲載された社内アプリ生成プロンプトの原型です。

Build a project request dashboard for my operations team. Let team members
submit requests, see who owns each one, update the status, and filter the list.
Require people to sign in with their workspace account, and keep the request
data saved between visits.

このプロンプトは、対象読者（operations team）、機能（submit・update・filter）、認証（sign in with workspace account）、永続化（keep data between visits）を1文で押さえています。

Sites Runtimeはこの記述から「D1を使うべき」「workspace-authenticated user identityを使うべき」と判断してストレージ・認証をセットします。

生成物のプレビュー確認

次のステップはプレビュー確認です。プロンプトを送るとChatGPTが非公開プレビューを生成します。ここで確認すべきは、意図した情報が正しく反映されているか、そして意図しない機密情報や外部リンクが混ざっていないか、の2点です。

Sitesは会話コンテキストや添付ファイルを引き込む設計のため、公開したくない情報が生成物に紛れ込む可能性があります。プレビュー段階で必ず目視レビューを入れる運用が現実的です。

Save versionとDeploy versionの2段階公開

続いて公開ステップです。Sitesの公開フローはSaveとDeployが明確に分離されているのが特徴です。

• Save a version
  ChatGPTが「デプロイ可能な候補」としてバージョンをビルドします。ローカルソースプロジェクトの場合、対応するGitコミットとバージョンが紐付きます。この段階では本番URLは動きません。
  
  

• Deploy a version
  保存済みバージョンを本番として公開し、production URLを返します。すべてのデプロイURLが本番URLであり、URLだけで「テスト用」「本番用」を切り替える運用は取れません。

この2段階が示すのは、プレビューでOKと判断してもDeployするまで公開されない、という設計思想です。

以前のバージョンを参照したい場合はChatGPTに「保存済みバージョンを一覧して」と依頼できます。ロールバック運用も、この保存済みバージョンから差し戻す形で行います。

共有範囲の設定と公開先の選択

最後に共有範囲を決めます。Deployしただけではサイトは自動で全世界公開になりません。共有範囲は次の中から選びます。

• 所有者とワークスペース管理者のみ
• 招待した特定のユーザー・グループ
• ワークスペース全員
• リンクを知る全員（インターネット公開）

Enterpriseワークスペースは、パブリック公開がデフォルトで無効化されており、管理者が明示的に有効化しない限り「Anyone on the internet」の選択肢が出ません。

BusinessワークスペースはSitesがデフォルトで有効ですが、公開範囲を狭める判断は所有者側で行う必要があります。

独自ドメイン（カスタムドメイン）の設定

Sitesが提供するデフォルトのSite URLではなく、自社ドメインで運用したい場合はカスタムドメイン設定が使えます。ただし前提として、ドメイン自体はSitesが取得してくれないため、既に所有しているドメインのDNSレコードを操作できる状態が必要です。

設定手順はSites側で「Add domain」を選び、apexドメインまたはサブドメインを入力すると、必要なDNSレコードが表示されます。それを自社のドメインプロバイダーに登録し、Sitesの管理画面でリフレッシュすると反映される、という流れです。

ChatGPT Sitesの対応プランと料金

ChatGPT Sitesは、Free/Goを除く有料プランのパブリックベータとして順次拡大しています。Pro/Pro Lite/Enterprise/Eduが先行し、Plus/Businessは順次ロールアウトされる設計です。

以下の表で、対応プランの現状を整理しました。

この対応表から読み取れるのは、Sites利用は既存プランのplan-specific limits内で含まれる、という点です。

BusinessプランはChat・Work・Sites・Codexすべてを月$25/席（年払時は月$20相当）で使えるため、日本円換算では月3,000〜3,900円台が実効価格になります。

ただし、Sitesの作成数・ストレージ・公開サイトの利用量にはプランごとの上限が設定されている点は、次のPublic Beta Limitsで確認します。

Public Beta Limits——プランごとの利用上限

ChatGPT Sitesはパブリックベータ期間中、プランごとにSitesの作成数・ストレージ・公開サイトの利用量に上限が設けられています。Public Beta Limitsが近づくとChatGPT側から通知が入り、上限到達後は新規Site作成・ストレージ追加・公開維持が制限されます。

既存Siteの編集・管理は上限後も継続できますが、制限は同一アカウント配下のすべてのSites合算で適用される点に注意が必要です。

Enterprise/Eduはワークスペース単位で上限が個別設定される場合があります。

ChatGPT Sitesの制限事項

ChatGPT Sitesがどれだけ便利でも、現時点で扱えないユースケースは明確に決まっています。ここを踏まえずに「Sitesで社内全部やろう」と踏み込むと、Sites Terms違反やコンプライアンス上の事故を招く可能性があります。

扱えないコンテンツ・用途（Sites Terms明記）

OpenAI公式のSites Termsでは、以下のコンテンツ・用途を明確に禁止しています。

• 保護対象保健情報（PHI）の取り扱い
• 決済カード情報（PCI対象データ）の取り扱い
• 13歳未満（または適用可能なデジタル同意年齢未満）を対象とする
• 金融取引の実行
• マルウェアの配布
• フィッシング詐欺
• 人物・組織のなりすまし

この禁止事項が示すのは、PHIを扱う医療用途・PCI対象データを扱う決済処理・金融取引の実行・13歳未満（適用可能なデジタル同意年齢未満）を対象とするサイトは現時点で使えない、という点です。

一方で、金融・医療領域そのものが全面禁止というわけではありません。患者PHIを直接扱わない診療情報の閲覧支援ダッシュボード、決済カード情報を保持しない金融データの分析画面、成人向けの投資教育コンテンツなどは、扱うデータ内容・規制・レジデンシー要件次第で使える余地があります。禁止されているのは「PHIそのもの・PCI対象カード情報そのもの・実際の金融取引実行・未成年ターゲティング」の4点に絞られている点を、業務判断の起点にすると整理しやすくなります。

データレジデンシーとインファレンスレジデンシー未対応

ChatGPT Sitesは、ローンチ時点でデータレジデンシーおよびインファレンスレジデンシーに対応していません。この対象範囲にはデプロイ済みSite・Siteコード・D1/R2データ・成果物・ログすべてが含まれます。

日本のデータ主権要件（金融庁監督指針、医療情報ガイドライン等）で「日本国内保管」を要求される業務は、現時点でSitesの対象外です。

Enterpriseワークスペースでの追加制約

Enterpriseの管理者にとって重要なのは、以下の3点です。

• パブリック公開がデフォルトで無効化されている
• カスタムドメインがローンチ時点で利用不可
• Sites自体もroleベースのアクセス制御で管理者がオプトインしない限りメンバーに提供されない

Enterpriseの中央管理を維持したまま社内アプリを配布する用途にはハマりますが、対顧客の公開LPをEnterpriseアカウントで作りたい場合、これらの制約がプレビュー期間中に外れるまで待つ判断が現実的です。

Sites takedownリスク

OpenAIは、Sites TermsまたはUsage Policies違反のリスクがあると判断した場合、Siteを削除または制限する権限を明示しています。誤削除に対しては通知メールのリンクからアピール手続きを踏めますが、一度削除されたSiteは復元不可である点は認識しておく必要があります。

ChatGPT Classic（旧desktop app）ではSitesは動作しません。最新のdesktop appにアップデートするか、Web版から起動する必要があります。

会話データの学習利用（プラン別に扱いが異なる）

Sitesの作成・編集・管理で交わした会話は、プランによってOpenAIの学習利用対象になるかが分かれます。ここは業務データの取り扱い判断に直結するため、必ず契約プランの設定を確認する必要があります。

• ChatGPT Business・Enterprise・Edu
  デフォルトで、ChatGPTとの会話やSites経由でアクセスした情報はモデル学習に使われません。ワークスペース側のデフォルト設定を維持する限り、業務データが学習セットに入ることは想定されていません。
  
  

• ChatGPT Free・Go・Plus・Pro
  「Improve the model for everyone」設定がONの場合、Sitesの作成・設計・編集・情報取得の会話がモデル学習に使われる可能性があります。個人プランで機密情報を含むSitesを作成する場合、この設定の状態を必ず確認するか、意図的にOFFにする運用が現実的です。

個人プランのアカウントで社内向けSitesを試作するときは、設定OFFにするか、機密情報を投入しない範囲でPoCを回す運用が安全です。業務での本格運用は Business/Enterprise/Edu 前提で組むほうが、後々のデータガバナンスを一貫させやすくなります。

ChatGPT Sitesと競合との棲み分け

ChatGPT Sitesの立ち位置を理解する近道は、既存のAIアプリビルダーとの機能・思想の違いを見ることです。

以下の表で、主要5サービスとChatGPT Sitesの棲み分けを整理しました。

この比較から読み取れるのは、「ホスティング＋データ層のバンドル方針」で3系統に分かれる、という点です。

• Vercel/Git連携＋外部DB型（v0）
  生成コードをGitリポジトリ経由でVercelに即時デプロイし、DBはNeon/Supabase/Vercel Postgres等を接続する構成。自リポジトリ内でコードを完全に保有でき、既存Vercelワークロードに組み込みやすい。
  
  

• Lovable Cloud型（Lovable / Bolt / Replit）
  DB・Auth・Storage・Edge Functionsまでを1プラットフォームに束ねた「AIアプリビルダー内蔵バックエンド」型。認証・データ層をゼロから組む必要がなく、AIプロンプトから完全なアプリまで最短ルートで到達できるのが強み。
  
  

• ChatGPT workspace identity + Sites Runtime型（ChatGPT Sites）
  ChatGPTワークスペースのユーザーIDがそのままアプリの認証に使え、D1+R2がSites Runtime側で確保される構成。社内配布時に別途IdPを設計せずに済むのが最大の特徴。

つまり3系統はどれも「AIで生成する」共通点を持ちながら、コード・認証・データの保有場所がまったく違うレイヤーに分かれているわけです。

対顧客LP・ECはWixとv0が有力、対顧客のフルスタックWebアプリはv0/Bolt/Lovable、汎用フルスタック開発はReplit、そして社内向けの業務アプリ内製はChatGPT Sites、という棲み分けが2026年時点の実効解です。

Claude陣営のArtifacts + Skills + MCPによる生成物出力とは、思想がさらに違います。Claude Artifactsは「対話中に生成した動くコード片を隣のペインでプレビュー」する用途で、ホスティング付き社内アプリの内製までは踏み込みません。

ChatGPT Sitesの実務判断——ケース別の使い分け

ここまでの整理を踏まえ、企業がChatGPT Sitesを実務で使うかを判断する際のケース別推奨を、AI総研の支援現場で見えている実効解として整理します。

社内DXの内製化（もっとも相性が良いゾーン）

情シス・DX推進部門が社内向けダッシュボード・ワークフローアプリを内製したいケースは、社内エージェント基盤と並行して、ChatGPT Sitesがもっとも強みを発揮するゾーンです。

workspace-authenticated user identityで社内SSO相当が自動で使え、D1・R2で永続化データも扱え、しかも既存プランのplan-specific limits内でBusiness/Enterpriseから利用できます。

外部SaaSとの契約交渉・PoC工数を挟まずに、その日のうちに動く社内アプリを配布できる点が、外注や既存ノーコードツールとの決定的な差になります。

対顧客のマーケLP・製品ページは現時点で限定的

対顧客のLP・製品ページを作りたい場合、ChatGPT Sitesは技術的には対応可能ですが、カスタムドメイン制約・Public Beta Limits・Sitesブランドの露出の3点が引っかかります。

Enterprise枠でカスタムドメインが解禁されるまでは、対顧客LP用途はWixやv0など従来の選択肢のほうが安全です。BusinessプランならカスタムドメインをDNS設定で当てられるため、小規模事業者のLPには使える段階に来ています。

PHI・PCI・金融取引の実行は現段階で対象外

PHIを扱う医療用途・PCI対象データを扱う決済処理・金融取引の実行という3種の用途は、Sites Termsで明示禁止されており、現時点で選択肢に入りません。

データレジデンシー未対応と組み合わさると、これらの用途で金融庁監督指針・医療情報ガイドライン下の業務にChatGPT Sitesを使う判断はまだ取れない、というのが妥当な整理です。

一方、金融・医療領域の閲覧・分析・教育用途は、扱うデータ内容・規制要件・レジデンシー要件次第で判断が分かれます。患者PHIを含まない診療サポート情報の可視化、決済カード情報を保持しない金融ダッシュボード、投資教育教材といった用途は、業務の性質と保存データを個別に精査すれば使える余地があります。

禁止3種に該当する処理を「別サービスに切り離し、閲覧・分析部分だけをSitesで組む」設計であれば、SitesベータでもPoCに進める判断は成り立ちます。

プロトタイプ・PoC・要件検証で活かす

事業企画・PdMが「動くもので要件を固めたい」フェーズは、ChatGPT Sitesがハマります。会話1本で叩き台が出て、その場でユーザーテスト・ステークホルダー確認まで回せるからです。

PoC後に本番運用へ移行する段階でBolt/Lovable/Replitなどコードを外に持ち出せるツールに乗り換える、という2段構えの運用も現実的な選択肢になります。

既存ノーコードツールからの置き換え判断

すでにNotion・Airtable・Retool・Glide等で社内アプリを運用している組織にとって、ChatGPT Sitesは**「作りたい機能を自然言語で表現する速度」**が最大の乗り換え理由になります。

ただし、既存ツールにあるサードパーティ統合（Slack Bot・外部SaaS連携等）はSitesではまだ薄いため、統合が業務要件の中心にある場合は既存ツールを併用しつつ、要件が単純な部分からSitesに切り出す漸進的な置き換えが安全です。

ChatGPT Sitesの内製アプリと基幹業務のエージェント化を両輪で回すなら

ChatGPT Sitesは社内向けダッシュボード・投稿基盤・イベント管理アプリを対話1本で内製できる強力な選択肢ですが、記事後段で整理したとおりPHI/PCI/金融取引の実行は範囲外、データレジデンシーも未対応で、SAP・勘定奉行クラウド・Dynamics 365といった基幹システムに深く踏み込む業務プロセスはSites Runtimeの守備範囲を超えます。

社内DXを進める企業は、Sitesを「軽量社内アプリ内製の入口」として使いつつ、その隣に「基幹業務のエージェント実行基盤」を別レイヤーで持っておく必要が出てきます。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。
AI総合研究所のAI Agent Hubは、AI-OCR Agent・自動入力Agent・フロー判定Agentなど9種類の業務特化Agentを、SAP Concur・freee会計・Dynamics 365・Salesforce・勘定奉行クラウドといった基幹システムと繋げ、Microsoft Teamsから呼び出せる形でパッケージ化しています。データは100%自社テナント内に保持され、実行ログ・権限管理・セキュリティスキャンが最初から組み込まれた設計のため、Sitesが踏み込めない基幹業務プロセスや規制業種にもAIを届けられます。

AI総合研究所の専任チームが、ChatGPT Sitesなど軽量内製手段と、AI Agent Hubの基幹業務エージェント化を、業務ラインに合わせて使い分ける設計から運用まで伴走支援します。AI Agent HubのLPで、Sitesの範囲を超えた基幹業務プロセスへのAI組み込みの全体像をご確認ください。

基幹業務のエージェント化をSitesと両輪で

Sitesの範囲を超える基幹連携・規制対応

ChatGPT Sitesは社内向け軽量アプリ内製に強力ですが、PHI/PCI/金融取引の実行や基幹システムに深く踏み込む業務プロセスはSites Runtimeの守備範囲外です。AI Agent HubのLPで、SAP・Dynamics 365・勘定奉行クラウド等の基幹システムに接続し、監査ログ付きで動く自社テナント内エージェント基盤の全体像をご確認ください。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

ChatGPT Sitesは、ChatGPT Workから対話1本で社内ダッシュボード・軽量Webアプリを生成し、ホスティングまで完結させる新機能です。

• 位置づけとしてはChat・Work・Codex 3ペインの成果物レイヤーで、Work/Codexの2方向から起動できる
• 生成物はSites showcase 6例が示すとおり社内ダッシュボード・ワークフローアプリ寄り
• 技術基盤はSites Runtime + D1（RDB）+ R2（オブジェクトストレージ）+ workspace-authenticated user identityでフルスタック
• 使い方はプロンプト→Save→Deploy→共有範囲設定の4段階で、独自ドメインも設定可（Enterpriseは現時点で不可）
• 料金はBusiness月$25/席・年払月$20相当。Sites利用は既存プランのplan-specific limits内で含まれる。Free/Goと欧州（EEA・スイス・UK）は現時点で除外
• 制限はPHI/PCI対象データ/金融取引の実行/13歳未満対象/データレジデンシー未対応。PHIを扱う医療用途・PCI対象決済・金融取引実行は現段階で不可（閲覧・分析用途はデータ内容次第で判断）
• v0/Bolt/Lovable/Replit/Wixとは想定用途がほぼ別レイヤー。ChatGPTアカウント縛りが社内アプリ内製で強みになる
• 社内DX内製・PoC・要件検証の3ケースが現時点でもっとも相性が良い

ChatGPT Sitesはプレビュー段階のため仕様の変動余地は残っていますが、社内アプリ内製という主戦場に対しては、既存ノーコードツール・v0・Boltと明確に別方向から切り込む設計になっています。

対顧客LPを作るツールとしてではなく、まず社内DXの内製手段として1つの業務ワークフローで試すのが、2026年時点の妥当な着手点です。