10月9日にOpenAIが変更したこと
同日、ChatGPTのアカウントはこの変更を次のように要約しました。「dotはCodexでの作業を開始し、既存のスレッドをフォローアップできるようになりました。ChatGPTの会話、Codexのスレッド、および自動化から情報を引き出すことができます。」
dot自体の利用可能性はまだ限られています。OpenAIのdots概要によると、Pro 100、Pro 200、Pro 500は「欧州経済領域、英国、スイス以外の18歳以上のユーザー向け」、Business Premiumは「世界中で順次展開中」、Enterpriseはワークスペース管理者が有効にするまで「デフォルトでオフ」となっています。
常設のドキュメントと並べて週次ノートを読む価値があります。なぜなら、この2つはdotの適用範囲を異なる表現で説明しているからです。10月10日現在、常設の「Tasks and memory」ページには依然として「コンピュータを接続しても、既存のすべてのChatGPTまたはCodexの会話へのアクセス権が付与されるわけではありません」と記載されています。一方、dotsの概要には「コンピュータを接続すると、dotはそのタスクやファイルを操作できるようになります。すべてのアプリのすべての会話へのアクセス権をdotに与えるわけではありません」とあります。
これらは必ずしも矛盾していません。常設ページはコンピュータの接続によって何が許可されるかについて述べています。週次ノートは、ChatGPTの会話を検索し、Codexのスレッドや自動化を利用するという「機能」について説明しています。安全な解釈としては、dotはより多くの作業領域にわたって情報を検索できるようになり、コンピュータの接続自体がそれを許可するわけではない、ということです。常設ページが書き換えられるまでは、週次ノートを最新の説明として扱い、dotが作業に関連する任意のChatGPTの会話やCodexのスレッドから情報を引き出す可能性がある前提で計画を立ててください。
dotからCodexスレッドへコンテキストが移動する仕組み
3種類のタスク、作業が実行される3つの場所
「Tasks and memory」ページには、dotのコーディング作業が実行される場所が簡単な表で示されています。
- 新規ローカルWorkまたはCodexタスク: 「dotに接続されたコンピュータ上でタスクを作成します。そのコンピュータをオンラインに保ち、ChatGPTアプリを開いたままにしてください。」
- 既存のローカルCodexタスク: 「接続されたコンピュータ上でタスクを継続します。タスクと変更したい内容を特定してください。」
- 新規クラウドコーディングタスク: 「すでにセットアップしたCodexクラウド環境でタスクを作成します。コンピュータはオフラインでも構いません。」
クラウドでの作業は、最初に行うセットアップに依存します。「クラウドコーディング作業の場合は、まずCodexでリポジトリやセットアップ構成を含む環境を作成してください。」まだ作成していない場合は、our guide to Codex cloud environmentsで、環境が各タスクに何を持ち込むかを解説しています。
複数のマシンで作業する場合、1つの詳細が重要になります。「dotの選択されたコンピュータを変更しても、既存のタスクはそのコンピュータに移動しません。」タスクは開始された場所にとどまります。
スレッドが受け取るのは「ブリーフィング」
ドキュメントには、新しいタスクがdotから何を受け取るかが正確に記載されています。「新しいタスクは、その作業のためにdotから指示とコンテキストを受け取ります。タスクは独自の会話を持ち、dotと交わしたすべての会話を自動的に受け取るわけではありません。」
つまり、引き継ぎは「ブリーフィング（概要説明）」です。dotはCodexスレッドに必要なものを決定してタスクに書き込み、スレッドはその内容と、自身の環境が提供するものに基づいて動作します。dotの全履歴からではなく、ブリーフィングから開始されます。
これは合理的な設計です。dotの全履歴が含まれるコーディングスレッドはノイズが多くなり、履歴の一部はプライベートなものです。その代償として、ブリーフィングから漏れた内容は、スレッドが他の場所から見つけられない限り、スレッド内では欠落することになります。
双方がどのメモリを使用するか
ここで3つの製品が交わり、それぞれが独自のメモリについてドキュメント化しています。
概要によると、dotは「会話、関連するChatGPTのメモリ、および好み、決定、進行中の作業に関する自身で保存したノートを活用します」。
コンピュータ上のCodexは異なるストアを使用します。OpenAIのMemoriesページには、「ChatGPTウェブ版はChatGPTメモリを使用しますが、ローカルのCodexクライアントは別のローカルメモリ・ストアとコントロールを使用します」とあります。そのローカルストアは「デフォルトでオフ」であり、Codexのホームディレクトリ配下に存在し、生成された状態（generated state）として説明されています。ローカルメモリを有効にする手順については、turning on Codex's local memoriesで解説しています。
ChatGPT WorkはChatGPT側の境界に位置します。「アカウントとワークスペースで利用可能なメモリ設定を使用し、ローカルのCodexメモリ・ストアやローカルメモリのコントロールは使用しません。」
まとめると、dotがローカルのCodexタスクを開始するとき、3つのメモリが関与します。dotはChatGPTメモリと自身のノートに基づいて動作します。ブリーフィングは、dotが引き渡すことを選択した内容を運びます。ローカルのCodexタスクは、有効にしていればそのマシンのCodexメモリ・ストアを利用できます。クラウドコーディングタスクは、その環境とリポジトリから動作します。ドキュメントでは各ストアが個別に説明されており、引き継ぎ時にそれらの間を行き来するのはブリーフィングです。
Codexメモリに関するOpenAI自身の推奨事項は、ここでは特に重要です。「必要なチームのガイダンスは AGENTS.md またはチェックインされたドキュメントに保管してください。メモリは、常に適用されるべきルールの唯一の情報源としてではなく、役立つ想起レイヤーとして扱ってください。」dotのノートにのみ存在するルールは、dotがそれをブリーフィングに含めるかどうかに依存します。AGENTS.md 内のルールはリポジトリとともに移動するため、その中で動作するすべてのスレッドで利用可能です。ルールが無視されるように思われる場合は、our guide to Codex skipping AGENTS.md rulesで一般的な原因を解説しています。
そして逆方向：dotがCodexから読み取るようになったもの
既存のスレッドと自動化
10月9日の変更は逆方向にも作用します。dotは「既存のスレッドをフォローアップ」し、「既存のCodexスレッドや自動化からのコンテキストを使用」できます。また、常設ドキュメントで既に許可されていた、既存のローカルCodexタスクを継続することも可能です。
自動化（automations）は、製品ラインを最も明確にまたぐ部分です。ChatGPTのスケジュールされたタスクは既存のチャット内で実行できます。OpenAIはその理由を「スケジュールされたタスクは、毎回新しいプロンプトから開始するのではなく、チャットの既存のコンテキストを使用するため」と説明しています。dotは「ChatGPT Workの自動化を読み取り、編集する」ことができるようになったため、その定期的な作業を確認して変更できます。スケジュールされたタスクのコンテキストがそもそもどのように設定されるかについては、scheduled tasks that start over every runで解説しています。
読み取った情報の行き先
OpenAIのdotsプライバシーFAQでは、dotとChatGPTメモリの双方向のリンクについて次のように説明しています。「dotはChatGPTからメモリと最近の会話コンテキストを受け取ることができ、dotとの会話はChatGPTのメモリに蓄積されます。」
これを10月9日の変更と並べて考えてみましょう。dotがCodexスレッドから引き出した詳細は、dotとの会話で現れる可能性があり、dotとの会話はChatGPTメモリに蓄積される可能性があります。また、FAQには、ChatGPTのメモリをオフにすると「その共有が停止」し、「dotがすでに受け取った情報は削除されない」と記載されています。
dot自身のノートにはさらに制限があり、同じFAQに明確に記載されています。「現在、プラグインからdotのコンテキストに入る特定の詳細を含め、個々のdotメモリを表示、削除、または直接変更することはできません。」dotを削除することが、そのコンテキストをクリアするためのドキュメント化された方法であり、dotが作成したものは削除後も残ります。「dotが作成したファイル、Codexスレッド、およびChatGPTの会話は個別に保存されます。dotを削除しても、これらは削除されません。」
権限は依然として個別
Codexへのアクセスは、マシンへのアクセスと同じではありません。コンピュータのページには「dotのローカルコンピュータ権限は、コンピュータをCodexに接続することやWork Syncを有効にすることとは別個のものです。どちらの接続単体でも、dotにアクセス権を与えることはありません」とあります。dotのプロフィールから、個人用コンピュータごとに1台ずつ権限を付与します。
使用制限も別個です。「dotとの会話は、ChatGPTの使用制限にはカウントされません。dotがWorkまたはCodexで開始または管理するタスクは、通常通りそれらの製品の使用制限にカウントされます。」
よくある誤ったアプローチ
Codexスレッドが会話全体を把握していると思い込む。 スレッドが受け取るのはその作業のためのブリーフィングであり、dotの履歴ではありません。
ローカルのCodexメモリがオンになっていると思い込む。 デフォルトではオフであり、特定のマシンに紐づいています。
チームのルールをメモリに保持する。 OpenAIは、常に適用すべきルールについては AGENTS.md またはチェックインされたドキュメントを使用することを推奨しています。
タスクを移動するために、dotの選択されたコンピュータを切り替える。 ドキュメントによると、これによって既存のタスクが移動することはありません。
dotが知っている情報をクリアするためにChatGPTメモリをオフにする。 これにより今後の共有は停止しますが、dotがすでに受け取った情報は残ります。
接続されたコンピュータを完全なアクセス権として扱う。 dotのローカル権限、Codex接続、およびWork Syncは、それぞれ個別の許可設定です。
解決策：境界を越える情報を決定し、双方が読み取れる場所に書き込み、引き継ぎを確認する
ステップ1：すべてのスレッドに必要なルールをCodexが読み取る場所に配置する
dotにコーディング作業を開始させる前に、常に適用すべきルールをリポジトリに移動します。コーディング規約やコマンドについては AGENTS.md、アーキテクチャの決定についてはチェックインされたドキュメントに記載します。クラウドタスクの場合は、Codex環境に必要なリポジトリ、セットアップスクリプト、およびシークレットが含まれていることを確認してください。
これにより、最も重要な事項についてブリーフィングに依存する必要がなくなります。dotは依然としてタスク固有のコンテキストを渡すことができますが、常設のルールは、どのスレッドがリポジトリを開いてもリポジトリとともに提供されます。
ステップ2：作業開始前にdotにブリーフィングの提示を求める
dotにコーディング作業を依頼する際、どのスレッドを使用する予定か、既存のスレッドを継続するのか新しいスレッドを開始するのか、そしてどのようなコンテキストを引き渡すのかを尋ねてください。週次ノートによると、dotはこの判断が向上したとのことですが、確認に必要なのはメッセージ1通分だけです。
作業が既存のスレッドに属する場合は、そのスレッド名を指定します。クリーンな開始が必要な場合は、その旨を伝えてください。ブリーフィングに重視する決定事項が抜けている場合は、スレッドが開始される前に追加します。ローカル作業の場合は、後からdotの選択コンピュータを変更してもタスクは移動しないため、タスクが実行されるマシンも事前に確認してください。
ステップ3：双方に戻ってくる内容を確認する
Codexスレッドが完了したら、dotの「Activity（アクティビティ）」ビューからそれを開き、結果を自分で確認してください。OpenAIのガイダンスには、「実行が完了したこと自体は、要求された結果が達成されたこと、または提供されたことを確認するものではありません」とあります。
次に、逆方向を確認します。dotがChatGPT Workの自動化を編集した場合は、Scheduled（スケジュール済み）で新しいバージョンを確認してください。dotとの会話を通じて入り込み、不要になった詳細がないか、定期的にChatGPTメモリを確認します。MacでComputer Historyを使用している場合は、同じマシン上のメモリに供給されるもう1つの情報源であるため、our guide to what Computer History turns into memoriesを読む価値があります。
MemoryLakeでのセットアップ方法
dot、ChatGPTメモリ、およびCodexのローカルストアは、それぞれ決定事項の一部を保持しており、各インターフェースは独自の情報を読み取ります。どのインターフェースがタスクを開始するかにかかわらず、コーディング作業の背後にある決定事項を自分で管理する1つの場所にまとめたい場合、MemoryLakeは、自分で書き込み、使用するツールに接続できるメモリレイヤーです。
エントリーはあなた自身の言葉で自分で書き込みます。dot、ChatGPTメモリ、Codexのメモリ・ストア、またはその他のベンダーのストアから情報が読み取られたり、書き込まれたり、削除されたりすることはありません。
ステップ1：APIキーを作成する
サインインし、ダッシュボードからキーを生成します。このキーはMemoryLakeワークスペースに属し、OpenAIアカウントとは別個のものです。
ステップ2：最初のメモリをアップロードする
コーディングスレッドが常に必要とする決定事項（アーキテクチャの選択、命名規則、過去の障害からの制約など）から始めます。1つのエントリーにつき1つの決定事項を日付付きで登録することで、新しいエントリーが古いエントリーを明確に置き換えるようにします。
ステップ3：AIとエージェントを接続する
Codexや、使用している他のアシスタントを接続します。これにより、dotからタスクが開始されるか、自分で開いたCodexスレッドから開始されるか、あるいは別のツールから開始されるかにかかわらず、同じ決定事項を利用できるようになります。
実務における変化
第1の違いは、暗黙のギャップが減ることです。常設のルールが AGENTS.md や環境に存在する場合、dotによって開始されたスレッドは、ブリーフィングが短くてもそれらのルールを受け取ることができます。
第2に、スレッドが整理された状態に保たれることです。スレッドに名前を付けるか、dotがどのスレッドを使用するかを尋ねることで、関連する作業が新しいスレッドに分散されることなく、1箇所にまとめられます。
第3に、詳細情報の行き先がより明確になることです。Codexスレッドからの詳細情報がdotとの会話に現れる可能性があり、dotとの会話がChatGPTメモリに蓄積される可能性があることを理解していれば、その経路を念頭に置いてメモリを確認できます。ChatGPT Workでクラウド作業とローカル作業を行き来する場合は、our guide to keeping context between Work cloud and localでその境界について解説しています。
第4に、定期的な作業における想定外の事態が減ることです。dotが自動化を編集できることを知っていれば、計画の変更を依頼した後にScheduled（スケジュール済み）を確認するようになります。
Codexでdotと連携するためのベストプラクティス
ルールを AGENTS.md にコミットする。 リポジトリを開くすべてのスレッドがそれらを読み取ります。
クラウド作業を委任する前にCodex環境をセットアップする。 dotは、すでに作成された環境を使用します。
ブリーフィングと対象スレッドを確認する。 作業開始前に、継続か新規開始かを確認します。
事前にマシンを選択する。 dotの選択されたコンピュータを変更しても、既存のタスクは移動しません。
結果は自分で確認する。 実行が完了したことは、結果が提供された証拠にはなりません。
自動化の変更後はScheduledを確認する。 dotはChatGPT Workの自動化を編集できるようになりました。
ChatGPTメモリを定期的に確認する。 dotとの会話がメモリに蓄積される可能性があります。
結論
2026年10月9日、OpenAIはdotsの機能をCodexに拡張しました。dotはCodexでの作業を開始し、既存のスレッドをフォローアップし、ChatGPTの会話、Codexのスレッド、自動化から情報を引き出し、ChatGPT Workの自動化を編集できるようになりました。
コンテキストは特定の形で移動します。送信時、Codexタスクはdotからブリーフィングを受け取り、その内容に加えて、自身の環境、リポジトリ、および（有効にしている場合は）コンピュータ上のCodexのローカルメモリ・ストアに基づいて動作します。返信時、dotはCodexのスレッドや自動化を読み取ることができ、dotとの会話に現れた内容はChatGPTメモリに蓄積される可能性があります。
常に適用すべきルールはCodexが読み取る場所に配置し、作業開始前にブリーフィングを確認し、双方に戻ってくる内容をレビューしてください。そうすることで、この新しい経路は、各インターフェースが記憶している内容をいつの間にか書き換えてしまうのではなく、あなたの作業を強力にサポートするものとなります。