>
>
公開日
2026年6月にプレビュー公開された「ChatGPT Sites」は、ChatGPT（Work / Codex）との対話だけで社内向けのWebサイト・ダッシュボード・軽量アプリを生成し、ホスティングまで完結させる新機能です。7月9日のChatGPT Work発表以降、Business / Enterpriseワークスペースへの展開が本格化しており、現場の従業員が情シスを介さずに「動く社内アプリ」を作って共有できる時代が到来しました。
生産性向上のインパクトは大きい一方、情シスにとっては「野良社内アプリの量産」「意図しない外部公開」「データレジデンシー未対応」という新しい統制課題が同時に発生します。特に注意すべきは、Businessワークスペースでは Sites がデフォルトで有効化されている点です。本記事では、ChatGPT Sitesの機能と技術基盤、管理者向けコントロール、リスクと制限事項、そして情シスが今すぐ取るべきアクションまでを、2026年7月時点の一次情報に基づいて整理します。
本記事のポイント
ChatGPT Sitesは、ChatGPT Work / Codexから自然言語だけで社内サイト・軽量アプリを生成しホスティングまで完結できるパブリックベータ機能（Free / Go除く有料プラン対象、EEA・スイス・英国は対象外）
ホスティング・DB（D1）・ファイルストレージ（R2）・ワークスペース認証を内蔵し、情シスが認証基盤を用意しなくても「社内SSO相当」で配布できる
Businessワークスペースはデフォルト有効。EnterpriseはRBACによる作成・公開権限の制御が可能で、パブリック公開はデフォルト無効
データレジデンシー・インファレンスレジデンシー未対応、PHI / PCI対象データ / 金融取引の実行は利用規約で禁止
情シスの実務は「利用実態の可視化 → ポリシー整備 → 権限設計 → 公開レビュー → 棚卸しとライフサイクル管理」の順で進める
ChatGPT Sitesとは？対話だけで作れる「ホスティング付き社内アプリ」
ChatGPT Sitesは、ChatGPTとの対話を通じてWebサイトや軽量アプリを構築し、そのまま公開・共有できる機能です。OpenAIは2026年6月にプレビューを公開し、7月9日のChatGPT Work発表で、Chat・Work・Codexの3ペイン構成における「成果物レイヤー」の1つとして正式に位置づけました。
従来のAIによるコード生成と決定的に違うのは、生成からホスティング・アクセス制御・データ保存までがChatGPTのワークスペース内で完結する点です。ユーザーは「オペレーションチーム向けのプロジェクト申請ダッシュボードを作って。ワークスペースアカウントでのサインインを必須にして、データは訪問をまたいで保存して」といった指示を出すだけで、認証付き・DB付きの動くアプリを入手できます。
何が作れるのか
OpenAIが公式ショーケースで示している事例は、社内業務アプリに大きく寄っています。
カテゴリ | 具体例 | 想定ユーザー |
|---|---|---|
情報表示系 | KPIダッシュボード、ローンチカレンダー、社内ポータル、ナレッジライブラリ | 経営企画、PMO、営業企画 |
業務ワークフロー系 | プロジェクト申請・承認、アイデア投稿基盤、オンボーディングハブ、イベント管理 | 人事、総務、各事業部門 |
体験系 | プロトタイプ、社内研修用ミニアプリ、教育コンテンツ | 事業企画、PdM、研修担当 |
つまりChatGPT Sitesは、これまでNotion・kintone・Airtable・Retoolなどのノーコードツールや、情シスへの開発依頼で賄っていた「小さな社内アプリ」の領域に、追加契約なし・既存のChatGPTライセンスの範囲内で切り込んでくる機能です。
Codex・ChatGPT Workとの関係
Sitesは単独のプロダクトではなく、ChatGPT WorkとCodexの両方から起動できる出力先です。会話ベースで「ダッシュボードを作って」と指示すればWorkから、既存のNext.js等のローカルプロジェクトを「Sitesで公開して」と指示すればCodexから、それぞれSitesへのデプロイに到達します。なお、旧デスクトップアプリ（ChatGPT Classic）ではSitesは動作しません。
Codex自体の企業統制については、コーディングエージェント全般のガバナンス論点を整理したClaude Code 企業利用の統制ガイドも参考になります。ベンダーは違えど、APIキー管理・実行権限・シャドー利用という論点は共通です。
情シスにとってなぜ重要か：「野良社内アプリ」問題の始まり
ChatGPT Sitesの登場が情シスにとって重要なのは、機能の良し悪し以前に、シャドーITの発生構造が変わるからです。
これまで従業員が勝手に業務ツールを作る場合、無料SaaSへの登録、スプレッドシートのマクロ、個人契約のノーコードツールなど、何らかの「情シスが検知しうる契約・通信の痕跡」がありました。ChatGPT Sitesでは、会社が正式契約したChatGPTのライセンス内で、承認プロセスを経ずに動くアプリが量産され、URLひとつで共有される構造になります。
情シス視点で整理すると、論点は3つです。
可視性の問題：誰が・どんなSiteを作り・誰に共有しているかを、情シスが把握できるか。Sitesはワークスペース内の機能であるため、CASBやSWGによる「未承認SaaSドメインの検知」という従来型シャドーIT対策の網にかかりにくい
データの問題：Siteには会話コンテキストや添付ファイルの内容が反映されうるため、機密情報が生成物に混入したままURL共有される事故が起こりうる
ライフサイクルの問題：作成者の退職・異動後に放置されたSite、業務プロセスに組み込まれたまま管理者不在になったSiteを、誰がいつ棚卸しするか
これは従来のシャドーIT対策の延長線上にある課題です。シャドーITとシャドーAIの構造的な違いと検知手法についてはシャドーAIとは？リスクと2026年最新の検知・対策ガイドで詳しく解説しています。
ChatGPT Sitesの技術基盤：情シスが把握すべき構成要素
Sitesが「HTML生成AI」ではなくフルスタックの内製手段として機能するのは、実行環境（Sites Runtime）に以下の要素が最初から組み込まれているためです。
構成要素 | 役割 | 情シスの確認ポイント |
|---|---|---|
D1 | リレーショナルデータベース。フォーム入力、投稿、ユーザー状態などの構造化データを保存 | どんな業務データがD1に保存されるか。レジデンシー要件との整合 |
R2 | オブジェクトストレージ。アップロードされた画像・文書ファイルの実体を保存 | 添付ファイルとして機密文書が保存されないか |
ワークスペース認証 | ChatGPTワークスペースのアカウントがそのままSiteの認証として機能 | 社内SSO相当として動くため、退職者のワークスペースアカウント削除が実質的なアクセス遮断になる |
外部IdP認証 | 一般公開Siteでのサインイン用 | パブリック公開時の認証設計 |
情シス実務で最も重要なのはワークスペース認証です。従来のノーコードツールでは「認証だけは別途IdP連携が必要」という壁がありましたが、SitesではChatGPTのアカウント管理がそのままアプリの認証基盤になります。裏を返せば、ChatGPTワークスペースのアカウントライフサイクル管理（入退社時のアカウント発行・削除）の品質が、社内アプリ群のアクセス統制の品質に直結するということです。AIサービスの認証・権限管理をどう設計するかという論点は、Claude Enterprise認証管理 完全ガイドで扱ったEnterprise-Managed Authorizationの考え方とも共通します。
公開フローは「Save」と「Deploy」の2段階
Sitesの公開フローは、デプロイ候補としてバージョンを保存する「Save a version」と、本番URLとして公開する「Deploy a version」が分離されています。プレビューで確認しただけでは公開されず、Deployして初めて本番URLが動きます。ロールバックは保存済みバージョンからの差し戻しで行います。
ただし注意点として、デプロイされたURLはすべて本番URLであり、「テスト用URL」「ステージングURL」という概念はありません。検証と本番を分けたい場合は、共有範囲を「所有者と管理者のみ」に絞った状態で検証する運用が現実的です。
ライブデータには直接接続できない
現時点のSitesは、社内の基幹システムやSaaSのライブデータに直接接続できません。定期的に変わる情報を扱う場合は、別途オートメーション（スケジュール実行）で最新情報を収集・整形し、人がレビューしたうえでSiteを更新する設計が公式に案内されています。
この制約は情シスにとってはむしろ好材料です。Sitesが基幹システムへの書き込み経路を持たない以上、当面の統制対象は「Siteに何を載せるか」「誰に共有するか」に絞られます。逆に、今後MCPやコネクタ経由でのデータ接続が拡張された場合はリスクプロファイルが大きく変わるため、アップデートの継続的なウォッチが必要です。AIエージェントと外部データの接点に潜むリスクの全体像はMCP企業導入のセキュリティ完全ガイドを参照してください。
対応プランと提供状況【2026年7月時点】
ChatGPT Sitesは、FreeとGoを除く有料プランを対象としたパブリックベータとして提供されています。
プラン | 提供状況 | 情シスの留意点 |
|---|---|---|
Free / Go | 非対応 | ― |
Plus | 順次ロールアウト | 個人プランのため、会話データの学習利用設定に注意 |
Pro / Pro Lite | 先行提供 | 同上 |
Business | 順次ロールアウト・利用可能になるとデフォルトで有効 | 統制未整備のまま全社員が使える状態になりうる |
Enterprise | 提供中・管理者によるオプトイン制 | RBACで作成・公開権限を制御可能 |
Edu | 提供中 | 教育機関向け |
あわせて押さえるべき提供条件は以下のとおりです。
ローンチ時点でEEA・スイス・英国では利用不可。欧州拠点を持つ企業は、拠点によって利用可否が分かれる
ベータ期間中はプランごとにSite作成数・ストレージ・公開サイトの利用量に上限があり、同一アカウント配下の全Site合算で適用される
Sitesの利用自体は既存プラン料金に含まれ、追加費用は発生しない（ベータ上限の範囲内）
なお、OpenAIのAIモデル自体の選定・コスト設計についてはGPT-5.6（Sol/Terra/Luna）の機能・価格・リスク・導入判断で詳しく解説しています。Sitesの統制はモデル統制とセットで設計するのが効率的です。
管理者向けコントロール：情シスが設定すべき統制ポイント
OpenAIは、Business / Enterprise / Eduのワークスペース管理者向けにSitesの統制機能を提供しています。公式ヘルプの内容を情シス実務の観点で整理します。
1. 有効化と作成権限（RBAC）
Business：Sitesはデフォルトで有効。無効化や制限を行いたい場合は、ワークスペース設定から管理者が明示的に対応する必要がある
Enterprise：ロールベースアクセス制御（RBAC）により、「誰がSiteを作成できるか」「誰が公開できるか」をロールやグループ単位で制御できる
RBAC設計の一般的な考え方はRBACとは？読み方からABACとの違い・情シス向け設計例でも解説していますが、Sitesにおいては「作成権限」と「公開権限」を分離できる点が実務上のポイントです。たとえば「作成は全社員に開放し、ワークスペース外への公開は情シス承認者ロールに限定する」という設計が可能です。
2. 共有範囲とパブリック公開
Siteの共有範囲は次の4段階から選択します。
所有者とワークスペース管理者のみ
招待した特定のユーザー・グループ
ワークスペースの全アクティブメンバー
リンクを知る全員（インターネット公開）
重要なのは、Enterpriseワークスペースではパブリック公開（4）がデフォルトで無効であり、管理者がワークスペース設定で有効化し、かつRBACで公開権限を付与しない限り、メンバーはインターネット公開を選択できないという点です。一方でBusinessでは公開範囲の判断が各Site所有者に委ねられるため、Businessプランを利用中の企業ほど、利用ガイドラインの整備が急務になります。
3. カスタムドメインの制約
Sitesは独自ドメインの割り当てに対応していますが、Enterpriseワークスペースではローンチ時点でカスタムドメインが利用できません。「Enterpriseの統制下で対外的なページを独自ドメイン運用したい」という要件は現時点では成立しないため、対顧客用途は既存のWeb基盤で継続する判断が現実的です。
4. レビュー・削除・通報のプロセス
OpenAIは管理者に対し、Sitesを広く有効化する前に以下を決めておくことを推奨しています。
誰がSiteを作成できるべきか、パブリック公開を許可すべきか
機密情報・第三者コンテンツを含むSiteの公開前レビューを誰が行うか
公開Siteの承認者と削除権限者
不審・悪意ある・権利侵害のSiteを発見した際の報告窓口
また、OpenAI側もSites Termsや利用ポリシー違反のリスクがあると判断したSiteを削除・制限する権限を持ちます。一度削除されたSiteは復元できないため、業務プロセスに組み込むSiteほど、依存度とバックアップ手段を事前に評価しておく必要があります。
リスクと制限事項：導入前に必ず確認すべき5点
1. データレジデンシー・インファレンスレジデンシー未対応
ChatGPT Sitesは、ローンチ時点でデータレジデンシーおよびインファレンスレジデンシーの対象外です。この対象範囲には、デプロイ済みSite・Siteのコード・D1 / R2に保存されたデータ・生成物・ログのすべてが含まれます。
金融庁の監督指針や医療情報システムのガイドライン等で国内保管が求められるデータ、あるいは自社のデータ管理規程で保管場所を限定しているデータは、Sitesに載せない前提でルールを設計してください。
2. 利用規約上の禁止用途
OpenAIのSites Termsは、以下の用途・コンテンツを明確に禁止しています。
保護対象保健情報（PHI）の取り扱い
決済カード情報（PCI対象データ）の取り扱い
金融取引の実行
13歳未満（または適用されるデジタル同意年齢未満）を対象とすること
マルウェア配布、フィッシング、なりすまし
「医療・金融業界だから全面禁止」ではなく、禁止されているのはPHI・PCI対象データ・取引実行そのものです。とはいえ判断が現場任せになると事故につながるため、自社の情報分類（機密区分）とSitesの利用可否のマッピングを、AI利用ガイドラインに明記することを推奨します。
3. 会話データの学習利用はプランで異なる
Business / Enterprise / Edu：デフォルトで、Sitesの作成・編集に関する会話はモデル学習に使用されない
Free / Go / Plus / Pro：「Improve the model for everyone」設定がONの場合、学習利用の対象になりうる
情シスとして特に警戒すべきは、個人契約のPlus / Proアカウントで社内向けSiteを試作するケースです。会社のワークスペース外で業務データが扱われる時点でシャドーAIそのものであり、学習利用リスクも重なります。個人アカウントでの業務利用の検知には、OAuth連携ログやブラウザ拡張による可視化が有効です。具体的な手法は情シスのための生成AI利用状況 可視化ガイドを参照してください。
4. 生成物への機密情報混入
Sitesは会話のコンテキストや添付ファイルの内容を生成物に反映する設計です。つまり、「経営会議資料をアップロードして議論した会話」の流れでSiteを作ると、公開を意図していない数値や固有名詞がSiteに埋め込まれる可能性があります。デプロイ前の目視レビューを必須とする運用ルール、および公開範囲の最小化（デフォルトを「特定メンバーのみ」とする文化づくり）が実務上の防御線になります。
5. プロンプトインジェクション等の攻撃面
現時点のSitesはライブデータ接続を持たないため攻撃面は限定的ですが、AIが生成・ホストするアプリという構造上、モデル側の堅牢性に依存する部分は残ります。OpenAIが攻撃専用AIで自社モデルの耐性を強化している動向と、「モデル頼みの防御は成立しない」という原則については、GPT-Redとは？OpenAIの攻撃専用AIが示すプロンプトインジェクション対策で詳しく解説しています。
情シスが今すぐ取るべき5つのアクション
Sitesの統制は「禁止するか、放置するか」の二択ではありません。適切に統制された内製手段として活用できれば、情シスへの「ちょっとしたツール作って」依頼を減らし、部門のDX内製化を加速する武器になります。以下の順で進めるのが現実的です。
1. 自社ワークスペースでのSites有効状態を確認する
まず、自社のChatGPTプラン（Business / Enterprise）でSitesが有効になっているか、誰が作成・公開できる状態かを確認します。Businessはデフォルト有効のため、「知らないうちに使える状態だった」が最も起こりやすいパターンです。Enterpriseの場合は、オプトインの判断とRBAC設計をセットで行います。
2. AI利用ガイドラインにSitesの条項を追加する
既存の生成AIガイドラインに、以下を追記します。
Siteに載せてよい情報区分（機密区分とのマッピング）
公開範囲の原則（デフォルトは最小共有、ワークスペース外公開は承認制）
個人アカウントでの業務Site作成の禁止
デプロイ前レビューの実施者と手順
不審なSiteの報告窓口
ガイドライン整備の進め方はAI利用ガイドラインの作り方が参考になります。
3. 公開権限を絞り、レビューフローを作る
Enterpriseなら、作成権限は広く・公開権限は狭く、が基本形です。ワークスペース内共有までは現場の裁量に委ね、パブリック公開と部門横断共有には承認を挟む2段構えが、活用と統制のバランスを取りやすい設計です。
4. 作成されたSiteの棚卸しをIT資産管理に組み込む
Sitesで作られた社内アプリは、SaaSアカウントと同様に「作られたら増え続ける」IT資産です。四半期ごとの棚卸しで、放置Site・所有者不在Site・共有範囲が過剰なSiteを洗い出すプロセスを、既存のSaaS棚卸しサイクルに統合してください。ChatGPT自体のアカウント管理・ライセンス管理と一体で運用すれば、退職者アカウントの削除がSiteへのアクセス遮断に直結する構造を活かせます。
5. ChatGPT以外のAIワークスペース製品との比較・使い分けを決める
同種の「AIによる成果物生成」はChatGPT Workだけでなく、Gemini SparkやClaude Coworkなど各社が競って展開しています。全社標準をどれにするか、部門ごとの併用を許容するかは、機能だけでなく管理者統制・データ取り扱い・監査ログの粒度で比較すべきです。選定基準の全体像はChatGPT Work・Gemini Spark・Claude Cowork徹底比較にまとめています。
よくある質問（FAQ）
Q. ChatGPT Sitesは追加料金がかかりますか？
A. かかりません。パブリックベータ期間中は、Free / Goを除く各プランの料金内で、プランごとの利用上限（Site数・ストレージ・公開サイトの利用量）の範囲で利用できます。上限は同一アカウント配下の全Site合算で適用されます。
Q. 社内の基幹システムやSaaSのデータと連携できますか？
A. 現時点では、Siteからライブデータへの直接接続はできません。定期更新が必要な情報は、別途オートメーションで収集・整形し、レビューを経てSiteを更新する運用が公式に案内されています。今後の接続機能拡張はリスクプロファイルを変えるため、継続的な確認が必要です。
Q. Enterpriseワークスペースで従業員が勝手にインターネット公開できてしまいますか？
A. できません。Enterpriseではパブリック公開がデフォルトで無効であり、管理者がワークスペース設定で有効化し、RBACで公開権限を付与したユーザーのみが選択できます。一方Businessでは公開範囲の判断が所有者に委ねられるため、ガイドラインでの統制が必要です。
Q. 従業員が個人のPlusアカウントで社内向けSiteを作っていた場合、何が問題ですか？
A. 会社の管理外で業務データが扱われるシャドーAIに該当します。個人プランでは設定次第で会話データがモデル学習に利用される可能性があり、退職時のアクセス遮断もできません。OAuth連携ログの監視などで検知し、会社ワークスペースへの移行を促してください。
Q. 削除されたSiteは復元できますか？
A. できません。OpenAIがポリシー違反と判断して削除した場合も、復元は不可です（誤削除に対するアピール手続きはあります）。業務プロセスに組み込むSiteは、依存度の評価と代替手段の確保を事前に行ってください。
まとめ：Sitesの統制は「可視化」から始まる
ChatGPT Sitesは、社内の小さな業務アプリを対話1本で内製できる強力な機能であり、適切に統制すれば情シスの開発依頼負荷を減らす味方になります。一方で、Businessでのデフォルト有効化、データレジデンシー未対応、生成物への機密情報混入といったリスクは、放置すれば新しいシャドーITの温床になります。
情シスが最初にやるべきことは、禁止でも全面開放でもなく、自社のAI利用の現在地を可視化することです。
✅ 自社ワークスペースのSites有効状態と作成・公開権限を確認する
✅ AI利用ガイドラインにSitesの利用条件（情報区分・公開範囲・レビュー）を追記する
✅ Enterpriseは「作成は広く、公開は狭く」のRBACを設計する
✅ 作成されたSiteの棚卸しをSaaS棚卸しサイクルに組み込む
✅ 個人アカウントでの業務利用（シャドーAI）を検知する仕組みを持つ
SaaS管理プラットフォーム「マネーフォワード Admina」は、ChatGPTをはじめとするAIサービスのアカウント一元管理、OAuth連携の可視化によるシャドーAI検知、入退社に伴うアカウントライフサイクル管理を支援します。Sitesのようにワークスペース認証がそのまま社内アプリの認証になる時代には、AIサービスのID管理の品質が社内アプリ統制の品質そのものになります。AI利用の可視化・統制にお悩みの方は、ぜひお気軽にご相談ください。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
