社内で生成AIの利用ルールを書くとき、共有に関する条項はたいてい「共有してよい情報の範囲」の形になります。機密区分、持ち出し禁止のファイル種別、承認が必要な相手。どれも、共有の前に判断を1回置くという設計です。
AIと人が同じドキュメントを編集する形が入ってくると、この設計に穴が開きます。共有の設定が決められるのは「誰がそのページを開けるか」までで、開いた人がその内容をどう扱うかは決められないからです。しかも扱い方を決めているのは相手側の設定であり、こちらからは見えません。
この記事では、OpenAI の公式ヘルプが共有・Memory・学習について実際にどう書いているかを確認し、「共有してよいか」という問いの立て方そのものを置き換えます。管理者が何を設定できるかは、参照したヘルプに一覧がないため扱いません。
30秒で要点
- 共有したページの内容は、相手自身の学習設定と Memory 設定に従うと公式ヘルプが明記している。こちらの設定で相手側を制御することはできない
- 自分の Memory をオフにしていても、相手の Memory が有効なら、ページに書かれた情報を相手側が記憶しうると書かれている
- ファイルの扱いは3通りに分かれる。アップロードは権限を継承し、リンクは権限を運ばず、写した要約は原本を開けない人にも読める
- したがって線引きは「共有してよいか」ではなく、相手の設定がどうであっても困らない内容かで行う
- 社内ルールを「禁止するファイルの一覧」から「相手の設定に依存しない範囲の定義」へ書き換える
共有設定が決めているのは、入口までである
OpenAI はDevDay 2026（ページ上の日付表記は2026年9月29日）で、ChatGPT Space、Pages、Dots を発表しました。同ページは全体で「20件を超える主要発表」としており、確定した件数は示されていません。
公式ヘルプによれば、Space は ChatGPT のファイルとページの置き場であり、Library を置き換えます（Projects はそのまま残ります）。Pages は編集可能なドキュメントで、他のページの中に整理したり、他の人と一緒に作業したりできます。公式は Pages を「人とエージェントの協働のために作られた新しい種類のドキュメント」と説明しています。そして同じヘルプに、本記事の中心になる一文があります。ページを共有すると、相手はそのページの内容にアクセスできるようになり、その内容は相手自身の学習設定と Memory 設定に従う。共有によって、自分のプライベートなチャットや自分の ChatGPT Memory へのアクセスが相手に渡ることはない。各人は自分の ChatGPT で作業する——。
ここに2つの層が同時に書かれています。
表が収まらない場合は、横にスクロールできます
| 層 | 何が決まるか | 誰が決めるか |
|---|---|---|
| 場（ページ）の権限 | 誰が開けるか、閲覧だけか編集もできるか | 共有する側（管理ワークスペースでは管理者の共有制御も適用される） |
| データの扱い | 開いた内容が学習に使われるか、Memory に残るか | 開いた側。共有する側からは見えず、変えられない |
共有の設定は上の層だけを決めます。下の層は、相手のアカウントの設定として存在しています。
「権限を書けば扱いまで決まる」という感覚はどこから来たのか
この2層構造が見えにくいのは、注意不足ではありません。これまでのツールでは、2つの層が事実上一致していたからです。
社内の共有ドライブや Wiki では、フォルダに権限を設定すれば、そのフォルダの中身をどう扱えるかもおおむね決まりました。開ける人の範囲と、情報が流れる範囲が、だいたい同じだったのです。ダウンロード禁止やコピー禁止の設定まで含めれば、場に書いた指示が扱いまで届いているように見えました。
生成AIでは、ここが分かれます。開いた後の処理が各人の環境で起きるからです。相手が自分の ChatGPT でそのページを読み、自分の設定のもとで要約し、自分の Memory の設定に従って記憶する。こちらが場に書いた指示は、その処理には届きません。
もう一段、言い方を変えてみます。宣言と強制は別の層にあります。宣言は、守られることを期待して置くものです。強制は、守らせる仕組みがあって初めて成り立ちます。共有設定は入口に対しては強制として働きますが、開いた後の扱いに対しては宣言にすぎません。「共有していい」という判断は、強制が効く範囲を超えたところまで効くつもりで下されがちです。
自分の設定が守るのは、自分の側だけである
公式ヘルプは、Memory についてもう一段踏み込んで書いています。Memory が有効な場合、ChatGPT はページの執筆や更新を手伝うときに個人的な文脈を使うことがある。その情報がいったんページに書き込まれれば、ページを閲覧できる人はそれを読める。共有する前にページの内容を確認すること——。
そのうえで例が添えられています。ChatGPT が過去の会話から得た情報を使ってプロジェクトのブリーフを書いた場合、その情報はブリーフを読める人に見えるようになり、相手の Memory が有効であれば、自分の Memory がオフでも相手側がその情報を記憶しうる。ただし、元の会話そのものが共有されるわけではない——。
この記述は、設定の効き方の非対称性を示しています。自分の Memory をオフにする操作は、自分の側で起きることを減らします。相手の側で起きることには及びません。「自分は設定を絞っているから大丈夫」は、共有という行為については成り立ちません。
学習についても同じ形です。公式ヘルプは、エージェントがページを使うとき、そのエージェントが読み書きしたページの内容はそのやりとりの一部になりうるとし、個人アカウントについて、そのやりとりを学習に使うかはエージェントを使っている人の設定に従うと書いています。さらに、他の人のエージェントが自分の共有したページを使った場合、適用されるのは相手の学習設定であり、自分の学習設定で相手を制御することはできないとしています。設定の場所は Settings → Data controls → Improve the model for everyone と案内されています。
ビジネス・エンタープライズについては、同じヘルプが「既定では学習しない」と記載しています。ただしこれは学習の層の話で、ページを読める相手が内容を読めるという事実や、相手の Memory に残りうるという点は、学習の可否とは別に残ります。個人プランの利用者と業務でやり取りがある組織では、個人アカウント側の記述を前提に置く必要があります。
ファイルは3通りに分かれる
ファイルの扱いは、操作の見た目が似ているぶん、最も間違いやすい箇所です。公式ヘルプの記述は3つに分かれます。
- ページにアップロードしたファイルは、そのページの権限に従う。ページにアクセスできる人は、そのファイルにもアクセスできる
- 別に保管されたファイルへのリンクを貼っただけでは、読者にそれを開く権限が自動で与えられるわけではない。これは Space に保管されたファイルにも、外部サービスのファイルにも当てはまる。外部サービスのファイルにはそのサービス自身の権限が引き続き適用され、ページを共有してもその権限は変わらない
- そのファイルから写したり要約したりした情報は、ページを閲覧できる人に見えるようになる。原本を開けない人であっても、ページに写された部分は読める
3つめが、ルールの穴になりやすい箇所です。「原本の権限は変わっていない」という事実が正しいぶん、安心材料として使われます。しかし守られているのは原本であって、情報そのものではありません。要約は、権限の壁を越えてページ側に置かれています。
つまり、ファイルを添えるという1つの操作を、権限を継承させる操作（アップロード）と権限を継承させない操作（リンク）として区別し、さらに権限とは無関係に内容が届く経路（写し・要約）を別に数える必要があります。
「共有してよいか」を「相手の設定がどうでも困らないか」に置き換える
ここまでの記述から出てくる線引きは、1文で書けます。
共有の判断は「この内容を共有してよいか」ではなく、「受け取った人の設定が最も緩い状態でも出していい内容か」で行う。
この置き換えが効くのは、見えないものを前提から外せるからです。相手の学習設定も Memory 設定も、こちらからは見えず、変えられません。見えないものを「おそらく絞られているだろう」と仮定した安全策は、安全策として機能しません。確認できない前提に依存しない基準だけが、運用できる基準です。
この基準に立つと、社内ルールの書き方も変わります。
- 変える前：「顧客名を含むファイルはアップロード禁止」のような、禁止対象の一覧
- 変えた後：「相手の設定に依存せず出してよい範囲」の定義 ＋ その範囲を超えるものは共有の手段を問わず置かない
一覧型のルールは、新しい機能が出るたびに追記が必要になります。アップロードを禁止してもリンクが残り、リンクを禁止しても要約が残ります。範囲を定義する形にすれば、どの経路で届くかに関係なく判断できます。
規程を書いても利用が止まらない構造そのものについてはガイドラインを作ってもシャドーAI利用が減らないのはなぜかで、AIにどこまでの判断を任せるかの設計についてはAIに任せる範囲の決め方で扱っています。本記事はそれらとは別に、共有という1回の操作で、こちらの制御が切れる地点を扱っています。
確かなことと、まだ確かではないこと
確かなこと（いずれも2026年10月15日に公式ページで確認、HTTP 200）：共有したページの内容が相手自身の学習設定と Memory 設定に従うこと。プライベートなチャットと自分の Memory へのアクセスは渡らないこと。自分の Memory がオフでも相手の Memory が有効なら相手側が記憶しうること。アップロードしたファイルがページの権限に従い、リンクは権限を運ばず、写した要約は原本を開けない人にも読めること。個人アカウントでは学習の可否がエージェントを使っている人の設定に従うこと。管理ワークスペースでは管理者の共有制御も適用され、ページの作成者・所有者はそのページを削除できること。
まだ確かではないこと：管理者が具体的に何を設定でき、何を止められるのか（参照したヘルプに設定項目の一覧がありません。「管理者の共有制御が適用される」という記述までが確認できた範囲です）。相手の Memory に何がどのように保存されるのかという仕組み（同じく記述がありません）。提供対象のプランや地域（公式ページの表記は確認時点のもので、Space は Pro・Business・Enterprise のデスクトップアプリとWebで全機能、モバイルは検索・閲覧・共有が可能で作成と編集は今後とされています。Dots は Pro と Business Premium で対象地域に提供され、Enterprise・Edu・Healthcare はワークスペース管理者が有効化したときにベータを試せる形で、既定では無効です）。
共有ボタンを押す前の、一問だけの確認
運用に落とすなら、確認は1問で足ります。
この内容は、受け取った人の設定が最も緩い状態でも出していいか。
答えがイエスなら共有します。答えがノーなら、共有の設定をどう絞っても解決しません。 権限を閲覧のみにしても、特定の1人だけにしても、その1人の設定はこちらから見えないままです。ノーのときに取れる手は、共有しないか、内容を変えるかのどちらかです。
この一問の価値は、判断の対象を設定からコンテンツへ移すことにあります。設定を調整している限り、判断は見えない相手側の状態に依存し続けます。コンテンツを基準にすれば、判断は手元で完結します。
1週間、この一問を挟んでみると、どの種類の情報でノーが出るかが分かります。ノーが集まった種類が、そのままルールに書くべき「範囲の外側」になります。禁止リストを先に書くより、この順序のほうが実態に合います。
判断の土台として押さえておくこと
- 共有設定が強制できるのは入口（誰が開けるか）まで。開いた後の扱いは相手の設定に属する
- 自分の Memory や学習設定を絞る操作は、自分の側にしか効かない
- ファイルは3通りに分かれる。アップロードは権限を継承し、リンクは権限を運ばず、写した要約は原本を開けない人にも届く
- 線引きは「共有してよいか」ではなく「相手の設定が最も緩くても出していいか」で行う。見えない前提に依存した安全策は安全策ではない
- 社内ルールは禁止対象の一覧ではなく、相手の設定に依存しない範囲の定義として書く
- 管理者が何を止められるかは公式の記述に一覧がない。「管理者が止めてくれる」を前提に置かない
参考資料・引用元
- OpenAI, "DevDay 2026 Recap"（ページ上の日付表記 2026年9月29日）. https://openai.com/index/devday-2026-recap/ （2026年10月15日確認・HTTP 200）
- OpenAI Help Center, "ChatGPT Space: sharing, data, and controls"（更新表記は相対表示のみ。確認時点で "Updated: 10 days ago"）. https://help.openai.com/en/articles/20001544-chatgpt-space-sharing-data-and-controls （2026年10月15日確認・HTTP 200）