なぜクラウドタスクはローカルのコンテキストなしで開始されるのか
まず、環境とは何かから始めましょう。「クラウド環境とは、タスクが使用する再利用可能なセットアップ（リポジトリ、依存関係、ツール、アクセス設定など）のことです。」Codexはリポジトリを検査し、必要なものをインストールし、あなたと一緒にセットアップをテストした上で、あなたがそれを公開します。「新しい各タスクは、公開された環境から独自の隔離されたワークスペースを取得します。」
OpenAIの環境概要では、その境界線が2つの文で明確に示されています。「クラウドタスクは、そのクラウド環境で利用可能なファイルとサービスを使用します。コンピュータのローカルファイル、実行中のプロセス、ブラウザのサインイン、VPNアクセスは、自動的には転送されません。」
では、ローカルのCodexがコンテキストをどこに保持しているかを見てみましょう。
指示（Instructions）。「Codexは作業を行う前にAGENTS.mdファイルを読み込みます。」これはチェーンを構築します。まず、デフォルトで~/.codexとなるCodexホームディレクトリ内のグローバルファイル、次にプロジェクトのルートから作業ディレクトリまでのファイルです。リポジトリのファイルはチェックアウトの一部ですが、グローバルファイルはあなたのマシン上に存在します。
スキル（Skills）。 Codexは、リポジトリ、ユーザー、管理者、システムの場所からスキルを読み込みます。リポジトリのスキルはリポジトリ内の.agents/skillsにあります。ユーザースキルは$HOME/.agents/skillsにあります。クラウド環境のページでは、タスクがどのスキルを参照できるかが具体的に説明されています。「リポジトリに保存されているスキルはクラウドタスクで利用可能です。ローカルコンピュータからの個人スキルはクラウド環境に同期されません。」
メモリ（Memories）。「ChatGPTのウェブ版はChatGPTのメモリを使用しますが、ローカルのCodexクライアントは別のローカルメモリ保存先とコントロールを使用します。」その保存先はディスク上にあります。「CodexはメモリをCodexホームディレクトリの下に保存します。」ローカルでの動作については、Codexのローカルメモリを有効にするで解説しています。
これらを総合すると、クラウドタスクはリポジトリにコミットされたものと、環境で設定したものだけを確実に取得します。ホームフォルダ内のガイダンス、個人のスキル、そしてローカルメモリが取り込んだものはすべて、あなたのコンピュータに紐づいています。
さらに2つの詳細が、タスクが記憶する内容を左右します。「各クラウドタスクは独自の作業ファイルを持ちます。タスク内でのファイル変更は、再利用可能な環境を更新しません。」また、保存された状態には寿命があります。「デフォルトでは、タスクの保存されたVM状態は、最後にターンを開始するかタスクを再開してから最大7日間回復可能です。」
これは珍しいことではありません。Claude Codeのクラウドセッションも同様の境界線を引いています。これについては、ローカルのセットアップがClaude Codeのクラウド環境に残すもので説明されています。クラウドエージェントは、設計上、共有されているものから開始されます。
代わりに人々が試みること
最初のクラウドタスクを実行し、不具合を修正する。 これは最終的には機能しますが、各修正は1つのタスクの作業ファイル内に留まります。タスク内のファイル変更は環境を更新しないため、次のタスクは同じ場所から開始されます。
Codexのメモリに依存する。 メモリはローカルでは便利ですが、OpenAI自身のガイダンスはその役割について明確に述べています。「必要なチームのガイダンスはAGENTS.mdまたはチェックインされたドキュメントに保管してください。メモリは、常に適用されなければならないルールの唯一のソースとしてではなく、役立つ想起レイヤーとして扱ってください。」
重要なルールをグローバルのAGENTS.mdに保持する。 ホームフォルダのファイルは、個人の作業合意を置くには適した場所です。チーム全体が依存するルールはリポジトリに属し、ローカルかクラウドかを問わず、すべてのタスクがそれを読み取れるようにすべきです。
すべてをセットアップの会話に詰め込む。 環境は、プロジェクトの準備と実行方法を保持するインストールスクリプトと開始スキルを記録します。これらは、アーキテクチャの決定やコーディング規約を置く場所としては不適切です。
レガシーなクラウドセットアップが引き継がれると仮定する。 OpenAIは「Codex Cloud（レガシー）は引き続きCode Review、Linear、GitHubの連携をサポートする」としつつ、非推奨にする計画であることを指摘しています。新しいCodex Cloudの環境は個別に作成されます。
解決策：プロジェクトのコンテキストをリポジトリと環境に配置し、タスクで確認する
ステップ 1：ローカルのCodexセットアップが各タスクに提供しているものを棚卸しする
環境を作成する前に、ローカルタスクが何に依存しているかをリストアップします。その大部分は以下の4つの場所にあります。
~/.codexにあるグローバルなAGENTS.md。これを読み、各行を個人用（自分の好みの働き方）かプロジェクト用（このコードベースの仕組み）に分類します。
$HOME/.agents/skillsにある個人のスキル。このプロジェクトで使用しているものを書き留めます。
ローカルのメモリ。Codexはこれらを~/.codex/memories/の下にファイルとして保存しており、OpenAIはこれらを生成された状態として扱うことを推奨しています。これらを読み取ることで、Codexが何に依存してきたかを確認し、ファイルに記録されなかったプロジェクトの事実を見つけ出すことができます。
あなた自身の習慣。タスクを開始するときに通常送信する最初のメッセージについて考えてみてください。どのコマンドを実行するか、どのフォルダを避けるか、どのサービスを最初に起動するか。これらもコンテキストです。
出力されるのは、現在あなたのマシン上にのみ存在するプロジェクトコンテキストの短いリストです。もしCodexが、読み込んでいると思っていたリポジトリファイルを無視している場合、CodexがAGENTS.mdのルールをスキップする理由に一般的な原因が記載されています。
ステップ 2：プロジェクトのコンテキストをリポジトリに、セットアップを環境に移動する
次に、各アイテムに共有の場所を提供します。
プロジェクトの規約は、リポジトリのAGENTS.mdに記述します。Codexはルートから順にファイルを連結するため、リポジトリ全体のルールはルートに、特定の領域のルールはネストされたフォルダに配置します。個人の好みはグローバルファイルに保持してください。それらはプロジェクトではなく、あなたに関するものです。
プロジェクトのスキルは、リポジトリ内の.agents/skillsに配置します。このプロジェクトで使用するスキルがホームフォルダにある場合は、クラウドタスクやチームメイトが利用できるようにリポジトリにコピーします。以前にカスタムプロンプトを使用していた場合は、Codexのカスタムプロンプトをスキルに変換するでその移行方法を説明しています。
ローカルメモリからの永続的なプロジェクトの事実は、チェックインされたドキュメントに移動します。それらを理由付きの平易な記述として書き、すべてのタスクで必要な場合はAGENTS.mdからリンクします。
その後、環境を作成します。ウェブまたはデスクトップアプリで「Work in」から「Cloud」、「Create environment」の順に選択し、リポジトリを選択します。Codexにそれらを検査させ、セットアップを準備させます。会話を利用して、ステップ1で確認した習慣（起動するサービス、固定するバージョンなど）を伝えます。Codexはこれをインストールスクリプトと開始スキルに記録します。後者は「サービスを開始し、準備ができているか確認するための指示」です。
アクセス権を適切に処理します。プログラムが直接読み取る値には環境変数を、特定のHTTPSサービスに送信される資格情報にはネットワークシークレットを、各個人が提供する値にはPersonal vault（個人用ボルト）を使用します。共有環境について、OpenAIは環境を共有すると要件も引き継がれると指摘しています。「環境を共有すると、これらの要件が共有されますが、個人の資格情報は共有されません。」
タスクがアクセスできる範囲を決定します。ワークフローにパッケージレジストリや内部APIが必要な場合は、環境のインターネットアクセス設定でそれらを追加し、セットアップ中にテストします。OpenAIは、覚えておくべき制限事項を指摘しています。「宛先を許可しても、そのサービスでの資格情報の提供や権限の付与は行われません。」リポジトリや接続されたアプリについても同様です。「リポジトリへのアクセスと個人の接続は、タスクを実行するアカウントに依存します。」共有環境を使用する同僚は、あなたのアクセス権ではなく、彼ら自身のアクセス権で作業することになります。
セットアップレポートを確認し、公開します。保存と公開の違いに注意してください。「保存すると設定が格納され、一部の設定はアクティブなセットアップに即座に適用されます。公開すると、新しいタスク用に準備されたファイルシステムがキャプチャされます。」
ステップ 3：タスクを開始し、何がロードされたかを確認する
公開された環境から新しいタスクを開始し、実際の作業を与える前にいくつかの直接的な質問を投げかけます。ロードされた指示ソースをリストアップするよう求めます。どのスキルが利用可能か尋ねます。プロジェクトのテストコマンドを実行させます。OpenAI自身のAGENTS.mdドキュメントでも、ローカルで同様のチェックを行い、Codexにロードされた指示ソースをリストアップさせています。
回答をステップ1のリストと比較します。足りないものは、まだあなたのマシン上にあります。
その後、実際のタスクに環境を使用し、繰り返される修正がないか監視します。クラウドタスクに同じことを何度も指示していることに気づいた場合、その事実はフォローアップメッセージではなく、リポジトリまたは環境に属するべきです。
最後に、成果を保護します。「重要な作業をコミットするか、必要な出力を保存してください。保存された状態はソース管理の代わりにはなりません。」タスクの状態は限られた期間のみ回復可能ですが、コミットは永続的です。
MemoryLakeでのセットアップ
この解決策により、規約はリポジトリに、セットアップは環境に配置されます。しかし、そのどちらにも当てはまらないコンテキストもあります。なぜそのようなアーキテクチャになっているのか、複数のリポジトリにまたがって下された決定、そしてタスクがCodex Cloud、ローカルセッション、あるいはまったく別のエージェントで実行されるかに関わらず適用される教訓などです。MemoryLakeは、特定のマシンや環境の外側に、そのレイヤーを保持するための場所です。
エントリーはあなた自身の言葉で、あなた自身が記述します。Codexのメモリ、クラウド環境、リポジトリ、あるいはベンダーの保存先から何かが読み取られたり、書き込まれたり、削除されたりすることはありません。
ステップ 1：APIキーを作成する
サインインし、ダッシュボードからキーを生成します。環境が資格情報を想定する方法で保存し、リポジトリに入らないようにします。
ステップ 2：最初のメモリをアップロードする
ステップ1で確認した、ルールではなく「理由」に関するプロジェクトの事実から始めます。なぜサービスが分割されたのか、どのアプローチが断念されたのか、依存関係の制約が何を保護しているのかなどです。1つのエントリーにつき1つの決定を、日付付きで記述します。
ステップ 3：AIとエージェントを接続する
Codexや、チームが使用する他のエージェントを接続します。これにより、タスクがローカルで実行されるかクラウドで実行されるかに関わらず、同じ背景情報が利用可能になります。
これにより実際に何が変わるか
第1の違いは、クラウドタスクがローカルタスクと同じように動作することです。必要なガイダンスがコミットされているため、すべてのタスクの最初のメッセージはセットアップではなく、作業そのものに関するものにできます。
第2の違いは、チームメイトが同じスタートラインに立てることです。共有環境に加えて、リポジトリレベルの指示とスキルがあることで、同僚のタスクはあなたのタスクとまったく同じ場所から開始されます。
第3の違いは、ローカルメモリが再び「便利な補助機能」に戻ることです。常に適用されるべきルールはファイルに存在するため、ローカルメモリはあなた自身のセッションをよりスムーズにするためだけに機能します。より広範な問題については、Codexがプロジェクトのコンテキストを忘れる理由を参照してください。
第4の違いは、異なる環境間を移動してもコンテキストが失われなくなることです。ChatGPT Work、ローカルのCodex、Codex Cloudはそれぞれ異なる場所で実行されます。このパターンについては、ChatGPT Workのクラウドとローカルの間でコンテキストを維持するで説明されています。コンテキストが共有ファイルと共有メモリレイヤーに存在する場合、どの環境を使用するかはそれほど重要ではなくなります。
Codexクラウド環境のベストプラクティス
チームのルールをリポジトリのAGENTS.mdにコミットする。 グローバルファイルは個人の好みのために残しておきます。
プロジェクトのスキルを.agents/skillsに移動する。 個人のスキルはコンピュータ上に残します。
ローカルメモリをドキュメントに変換する。 永続的な事実はファイルに属します。
環境内で起動処理を記述する。 Codexにインストールスクリプトと開始スキルとして記録させます。
各シークレットに適切な場所を使用する。 環境変数、ネットワークシークレット、またはPersonal vault。
セットアップ変更後は再公開する。 その後、新しいタスクを開始して使用します。
短いタスクで新しい環境を毎回チェックする。 実際の作業を与える前に、何がロードされたか尋ねます。エージェントがツール間で実際にロードするものについては、コーディングエージェントが実際に読み取るものを参照してください。
結論
Codexのクラウド環境を使用すると、共有された再利用可能なセットアップからリモートでタスクを簡単に実行できます。タスクが開始時に持つものは、環境とリポジトリが提供するものだけです。グローバルなAGENTS.md、個人のスキル、ローカルメモリはあなたのマシンに紐づいており、OpenAIは個人のスキルは同期されず、ローカルファイルは転送されないと明言しています。
したがって、プロジェクトのコンテキストをタスクが読み取れる場所に移動しましょう。規約はリポジトリのAGENTS.mdに、スキルは.agents/skillsに、永続的な事実はチェックインされたドキュメントに、セットアップは環境に配置します。そして、タスクに何がロードされたかを尋ねることで、新しい各環境をチェックします。
プロジェクトの背後にある理由を、すべてのエージェントがアクセスできるレイヤーに保持すれば、クラウドはタスクがあなたよりも少ない情報で開始される場所ではなくなります。