なぜコンテキストは異なる場所に保存されるのか
1つのアプリ、2つの実行環境
Cloud Workは「サポートされているWeb、モバイル、デスクトップの環境で利用可能」であり、「OpenAIが管理するインフラストラクチャ上の隔離された環境でCodexハーネスを実行」します。その会話は「これらの環境間で同期」でき、「サポートされているタスクは、ユーザーが会話から離れている間も継続」できます。
Local Workは「ユーザーのデバイス上のChatGPTデスクトップアプリを介してタスクを実行」します。そのメリットは、行う必要のない作業という観点から説明されています。「Web上のWorkとは異なり、ローカルのWorkは、ファイルをクラウドの会話にアップロードすることなく、コンピューター上に残っているリソースを操作できます。」
両者の境界は一方向において厳格です。「クラウドタスクは、そのデバイスからローカルファイル、デスクトップアプリケーション、ブラウザセッション、またはプライベートネットワークへのアクセスを継承しません。」また、ホストされたブラウザがユーザーのブラウザから何かを継承することもありません。「ユーザーのローカルブラウザプロファイル、開いているタブ、既存のサインイン、保存されたパスワード、パスワードマネージャー、または閲覧履歴を継承しません。」
プライバシーについて思い込みをする前に、1つ明確にしておくべきことがあります。それは「ローカル」は「オフライン」を意味しないということです。「ローカルファイルはデバイス上に残すことができますが、タスクを完了するために、関連するファイルの抜粋、プロンプト、スクリーンショット、ブラウザのコンテンツ、またはツールの結果がOpenAIサービスに送信される場合があります。ローカル実行は、オフラインまたはデバイス上のみでのモデル推論を意味するものではありません。」
保持期間はワークスペース単位ではなく、データカテゴリ単位
クラウドセキュリティのページには保持動作が表として記載されており、この表こそが重要なポイントです。Workの会話はワークスペースの会話保持設定に従い、削除されたチャットは「通常30日以内に完全に削除されるようスケジュール」されます。ライブラリ（Library）に保存されたファイルはライブラリのルールに従い、「会話を削除しても、ライブラリに保存されたファイルは削除されません。」プロジェクトファイルは「削除されるかプロジェクトが削除されるまで、そのプロジェクトに関連付けられたまま」になります。ライブラリ以外の「一時的なアップロードは、別の適用可能な保持設定が適用されない限り、48時間後に期限切れになる可能性があります。」コンプライアンスログプラットフォーム（Compliance Logs Platform）の記録は「30日間利用可能」です。
特に次の2つの項目は、注意深く読む必要があります。
ホストされた実行状態とスナップショットは「会話やファイルとは異なるライフサイクルに従い」、その項目の最後には人々を驚かせる一文があります。「タスクを終了したりチャットを削除したりしても、関連するすべてのアーティファクトがすぐに消去されるわけではありません。」
そして、保存されたメモリ（有効な場合）は「個別のメモリコントロールに従います。会話を削除しても、既存の保存されたメモリが必ずしも削除されるわけではありません。」
OpenAIは次のような結論を提示しています。「会話の削除、ライブラリファイルの削除、保存されたメモリの削除、アプリの切断、ホストされたブラウザデータのクリアは、それぞれ個別の操作です。1つの操作ですべてのコピーが削除されると思い込まず、関連するストレージの場所を確認してください。」
これは良くも悪くも作用するため、単なるセキュリティレビューではなく、コンテキストの維持に関するガイドで取り上げるべき内容です。チャットを削除してもメモリが削除されるとは限らないのであれば、チャットを削除してもメモリが保護されるわけでもありません。それぞれのストレージについて、個別に考える必要があります。
ローカルの記録は個別に管理され、ドキュメントでも2回言及されている
ローカルに関するページは、一般的な形式の同じ警告から始まります。「ローカルファイル、タスクコンテキスト、ブラウザデータ、接続されたシステムの記録、および監査イベントは、異なる保存および保持ルールに従う場合があります。」
そして、会話の記録について、より具体的に再び言及しています。ローカルの会話記録について確認すべきことは、「デスクトップ体験がローカル記録をどのように保存、削除、バックアップ、または共有するかです。ホストされた会話の保持設定が、すべてのローカルアーティテャクトに適用されると思い込まないでください。」
さらに3回目として、独立した指示が記載されています。「ホストされた会話、一時的なアップロード、またはコンプライアンスログの保持期間を、特定のデータカテゴリに適用されることを確認せずに、ローカル記録に適用しないでください。」
ベンダーが1つのページで警告を3回も繰り返すのは、その間違いが非常に一般的だからです。ここでの間違いは、ワークスペースの保持設定が「すべて」に適用されると信じてしまうことです。それはあくまで「ホストされた会話」に関する設定に過ぎません。
また、Local Workにはクラウドモデルには存在しないカテゴリもあります。VoiceやAppshotsは「マイク入力、最前面ウィンドウのスクリーンショット、アクセス可能なアプリケーションテキスト、ローカルセッションストレージ、およびタスクコンテキストとして送信されたコンテンツ」をカバーしています。監査の対象範囲も異なります。「OpenAIは、拡張機能を介して実行されたChromeのアクションについて、個別の完全な記録を保存しません。」
ベンダーがトレードオフを明言している
どちらのドキュメントにおいても最も有用な一文は、保持期間が単なるセキュリティの調整つまみであるかのように装うのをやめた、次の一文です。
「適切な会話および実行コンテキストを保持することは、Workが中断されたタスクを再開し、前のステップを参照し、より一貫した結果を生成するのに役立ちます。保持期間を短くしたり削除したりすると、その継続性が低下する可能性があるため、セキュリティ要件とワークフローの有用性のバランスをとる設定を選択してください。」
これは、現実の対立を率直に表した言葉です。継続性は、保持期間と引き換えに得られるものです。つまり、セキュリティチームが（正当な理由から正しく）保持期間を短縮するたびに、アシスタントは中断したところから再開するのが少しずつ苦手になります。そして、その性能低下が3週間前のポリシー変更によるものであるとは、誰も気づかないのです。
解決策は、保持期間を長くするように主張することではありません。永続的なコンテキストを維持するための唯一の手段を、保持設定に頼るのをやめることです。
よくある試みとその限界
ワークスペースの保持設定がすべてをカバーしていると思い込む。 実際には、ホストされた会話のみをカバーしています。ライブラリファイル、プロジェクトファイル、保存されたメモリ、実行スナップショット、ブラウザデータ、コンプライアンス記録には、それぞれ独自の動作があります。
整理のためにチャットを削除する。 合理的ではありますが、どちらの方向に対しても不完全です。保存されたメモリが必ずしも削除されるわけではなく、また保存されたメモリが保護されるわけでもありません。
すべての新しいタスクに同じ背景情報を貼り付ける。 誰もが思いつく回避策です。機能はしますが、すべてのセッションの最初の2分間が無駄になり、内容が陳腐化していきます。10月に貼り付けている内容は、6月に書いた古いバージョンのままになりがちです。
1つの長い会話ですべてを済ませようとする。 別の理由で脆弱です。会話は、自分が管理できない保持設定によって管理されているカテゴリの1つだからです。
プロジェクトを永続的なストレージとして使用する。 プロジェクトファイルは「削除されるかプロジェクトが削除されるまで、そのプロジェクトに関連付けられたまま」になるため、より良い方法です。しかし、依然としてプロジェクトの範囲内に限定されます。これが、ChatGPTのプロジェクトがメモリを共有しない理由で説明されているポイントです。
Workは単にコンテキストを失うものだと諦める。 実際には失っていません。そう決めつけると、実際の仕組みが見えなくなります。Workにはコンテキストを適切に保持する場所がいくつかあります。ただ、それぞれ異なるルールで保持されているだけであり、チームの知識を保存する唯一の永続的な場所として設計されたものは1つもありません。これは、ChatGPTがセッション間でコンテキストを失う理由で説明されている、より一般的な状況と同じです。
解決策：保持設定の影響を受けない永続的な情報を切り分け、別の場所に保管する
コンテキストを2つの山に分類してください。1つは「一時的な情報」です。現在のタスク、このファイル、このスレッドなどが該当します。これらはワークスペースのポリシーに従って、適切な場所に置かれ、期限切れになるべきです。
もう1つは「永続的な情報」です。チームの執筆スタイル、成果物に含めるべき内容、承認されたベンダー、前四半期のアプローチが失敗した原因となった制約などがこれに当たります。この情報は、会話の保持期間や48時間の一時アップロード期限、あるいはどの実行環境でタスクが実行されたかといったことに左右されるべきではありません。
MemoryLake は、この2つ目の情報を保管する場所です。これは、APIを介してアシスタントが読み取る、ユーザー自身が所有するメモリレイヤーです。継承された複数のライフサイクルではなく、ユーザー自身がコントロールする単一のライフサイクルを持ちます。手順は以下の3ステップです。
ステップ 1: APIキーを作成する
サインインし、ワークスペースの設定からAPIキーを作成します。これは実行環境の属性ではなく、ユーザー自身に紐づくものであるため、タスクがクラウドで実行されてもローカルマシンで実行されても、同じように動作します。
ステップ 2: 最初のメモリをアップロードする
永続的な情報をロードします。チームのトーン＆マナーやフォーマット基準、繰り返し作成する成果物の「完了の定義」、承認済みの情報源と除外された情報源、繰り返し発生する制約（対象読者、コンプライアンス基準、クライアント向け文書に決して記載してはならない2つの事項など）です。ファイルはそのままアップロードでき、マルチモーダルファイルも処理されるため、ブランドのプレゼン資料や命名規則のスプレッドシートなどを直接取り込むことができます。
ステップ 3: AIとエージェントを接続する
チームが使用している他のツールと並行して、ChatGPTを接続します。これ以降、永続レイヤーは1つの場所から読み取られるようになり、どの環境や実行環境でタスクが開始されたかは関係なくなります。
ここで、3つの制限事項を明確にしておきます。第一に、MemoryLakeはChatGPT Work内部の保持動作を変更しません。会話、スナップショット、ライブラリファイル、保存されたメモリはすべて独自のライフサイクルを維持します。MemoryLakeは永続的な情報を保管する場所であり、既存のライフサイクルを変更するものではありません。第二に、ChatGPTに保存されたメモリを読み取ったり削除したりすることはできません。これらはOpenAI独自のメモリコントロールを通じて管理されます。第三に、これは監査やコンプライアンスのツールではありません。ワークスペースの記録、接続されたシステムのログ、およびコンプライアンスログプラットフォーム（Compliance Logs Platform）が、引き続き公式の記録システムとなります。
導入によって実際に変わること
最も直接的な変化は、保持期間が短縮されても出力の品質が低下しなくなることです。保持期間の設定は、アシスタントがどれだけの知識を持っているかという暗黙の決定ではなく、「一時的なデータをどれだけの期間保持するか」という本来あるべき決定へと変わります。
2つ目の変化は、クラウドかローカルかという選択が、コンテキストの有無ではなく、運用上の選択肢になることです。現状では、ファイルがデバイスから出ないように「ローカル」を選択すると、永続的なコンテキストもクラウドとは異なるストレージに保存されることになります。永続的な情報を外部化することで、それぞれのメリットに基づいて実行環境を選択できるようになります。マシン上に残すべきリソースがある場合はローカルを、離席中も継続すべき作業にはクラウドを選択できます。
3つ目の変化は、プラットフォーム自体が提供していない種類の監査可能性が得られることです。OpenAIは、対象範囲が異なることを率早に認めています。「すべてのシェルコマンド、ブラウザの操作、アプリの呼び出し、ファイル操作、または承認が、顧客に表示されるコンプライアンスエクスポートに表示されると思い込まないでください。」また、エンドポイントの監視では「ホストされた実行環境内のアクションを検査することはできません。」これらは、実行テレメトリにおける合理的な制限です。しかし、アシスタントが「何をしたか」を知ることと、アシスタントに「何を伝えたか」を知ることは別問題であり、伝えた内容が確認可能な1つの場所に保管されていれば、その疑問に答えることができます。AIアシスタントが記憶している内容の監査では、その監査の実行方法について説明しています。
クラウドとローカルのWorkを併用するためのベストプラクティス
どの環境でタスクが実行されたかを把握する。 デスクトップアプリからクラウドタスクを開いても、それがローカルになるわけではありません。特定の作業においてこれが重要な場合は、クリックした場所から推測するのではなく、実際に確認してください。
各ストレージに個別の削除操作があるものとして扱う。 会話、ライブラリファイル、プロジェクトファイル、保存されたメモリ、ホストされたブラウザデータ、実行スナップショットの削除は、それぞれ異なる効果を持つ個別の操作です。
境界を越えて保持期間の前提を持ち込まない。 ローカルのドキュメントでは3回にわたり、ホストされた会話、一時的なアップロード、またはコンプライアンスログの保持期間を、適用されることを確認せずにローカル記録に適用しないよう求めています。
保存したいものは意図的にライブラリを使用する。 接続されたアプリから取得したコンテンツは「自動的にライブラリファイルとして保存されるわけではありません。」また、一度どこかに保存されると、「そのコピーは保存先のルールに従います。」
一時的なアップロードをアーカイブ代わりにしない。 Enterpriseプランの場合、ライブラリ以外の一時的なアップロードは「別の適用可能な保持設定が適用されない限り、48時間後に期限切れになる可能性があります。」
管理者設定の区分を確認し、それに合わせて設計する。 個別のコントロールが存在する場合、クラウドとローカルのWorkは異なる権限として管理されます。一部のワークスペースでは「ローカルのWorkがCodex Localとコントロールを共有できる」場合があります。一方を無効にしても他方に影響を与えないと思い込む前に、これを知おく価値があります。
セキュリティ体制と継続性体制を切り離して考える。 関連する保護機能はすでに明記されています。Business、Enterprise、Eduのワークスペースデータは「送信中および保管時に暗号化され、デフォルトでOpenAIモデルのトレーニングには使用されません。」これを超えて保持期間を短縮することは、わずかな安全性の向上と引き換えに、実質的な継続性の喪失を招きます。永続レイヤーを外部に置くことで、その両方を手に入れることができます。これについては、AIメモリのセキュリティに関する考え方で詳しく説明しています。
結論
ChatGPT Workは、2つの実行環境と約12のストレージで構成されており、それぞれが独自のライフサイクルを持っています。OpenAIはこれらすべてを正確にドキュメント化しています。問題はプラットフォームにあるのではなく、ワークスペースの保持設定がすべてに適用されると思い込み、保持期間の長さによって継続性を維持しようとすることにあります。
コンテキストを整理しましょう。一時的な情報は、すでに存在する場所で期限切れになるようにします。そして、チームが蓄積してきた基準、定義、制約、不採用となったアプローチなどの永続的な情報は、自分がコントロールできる単一のライフサイクルを持つ場所に保管してください。そうすれば、クラウドかローカルかという選択は、タスクをどこで実行すべきかという問題になり、アシスタントがどれだけのことを覚えているかという問題ではなくなります。