多くの開発者は、まずコード用のコーディングエージェントを使います。リポジトリを検査し、差分を作成し、テストを実行し、プルリクエストを開くといった作業です。
これは今でも Codex の中心的な使い方です。しかし、コンピューター上の作業の多くは既にコードを介して行われています。シェルコマンドの実行、Web ページの閲覧、API の呼び出し、ドキュメントのエクスポート、イベントへの応答、自動化のトリガーなどです。これらの操作面が Codex で利用可能になるにつれて、Codex は狭い意味でのコーディングアシスタントというよりも、コンピューター上の作業を実行するためのシステムのように感じられるようになってきました。
Codex アプリ は、その変化を具体的なものにしています。スレッドはコンテキストを保持し、ツールを使用し、アーティファクトを表示し、プロンプト間で継続できます。毎回のやり取りの後にリセットされることはありません。
Codex を最大限に活用するには、これらの機能を組み合わせて使います。
- コンテキストを保持する永続的なスレッド
- ユーザーがループ内にいる間の音声入力、操作誘導、タスクのキューイング
- リポジトリを超えて Codex が動作できるブラウザ、コンピュータ操作、MCP サーバー、コネクタ
- ユーザーが離れている間も作業を継続するスレッド自動化と目標
- コード、ドキュメント、デッキ、その他のアーティファクトを確認できるサイドパネル
永続的なスレッド
永続的なスレッド:
複数のセッションにわたって作業コンテキストを保持する、長時間実行される Codex スレッド。
ピン留めされたスレッドは、永続的なスレッドを手元に置いておく方法の 1 つです。これらは、以下のような繰り返し発生する作業フローに便利です。
- チーフ・オブ・スタッフ用のスレッド
- リリース用のスレッド
- ドキュメントレビュー用のスレッド
- 外部監視専用のスレッド
これらは永続的なワークスペースであり、短いチャットではありません。Codex は時間をかけてそれらを再訪でき、以前の判断、好み、作業コンテキストを保持します。これらは、そうでなければゼロから再構築する必要があるものです。
ピン留めスレッドへのショートカットは、これを実用的にします。Command-1 から Command-9 で、保存されたスレッドに直接ジャンプできます。
音声入力
音声入力が価値を持つのは、思考の粗いバージョンを、洗練された散文に圧縮される前にキャプチャできるからです。
Codex には組み込みの音声入力があります。これは、タイプするのは気まずいが、口にするのは自然な曖昧な出発点に特に適しています。
誰かベンという人が Slack で言っていたと思うんだけど。
詳細は覚えていない。
調べてみて。
検索、コンテキスト収集、報告ができるエージェントにとって、これで十分なことがよくあります。
また、タスクが完全に形成される前の 2 ～ 3 分の思考ダンプにも適しています。
トランスクリプトも同様に機能します。生の会議の文字起こしや口述された計画ノートは、短い要約よりも優れたソース資料を提供することがよくあります。なぜなら、不確実性、強調、未完成の思考の流れを保持するからです。
操作誘導とキューイング
音声は、アクティブなタスクを明示的に制御できると、さらに便利になります。
操作誘導:
現在のステップが完了する前に、実行中の Codex タスクに新しい指示を与えて中断すること。
操作誘導は、エージェントが間違った方向に進んでいて、完了する前に修正が必要な場合に便利です。たとえば、Web サイトのレビュー中に、ユーザーはサイドパネルで画面に注釈を付けながら作業を中断できます。
- これを小さくして
- これら 2 つの要素の間隔がおかしい
- このコピーは間違っている
キューイング:
現在のステップが完了した後に Codex が実行する作業を追加すること。
キューイングは異なります。進行中のタスクを中断しません。次のタスクを列に追加します。ユーザーは次のように言うかもしれません。
作業が終わったら、プレビューリンクを Slack でレビュアーに送って。
操作誘導は、Codex が今何をしているかを変更します。キューイングは、次に何が起こるべきかを変更します。どちらも、作業が展開されている間、ユーザーを作業の近くに留めておきます。
ツールとリーチ
スレッドに継続性が生まれると、次は何に対してアクションを起こせるかという問題になります。Codex はレイヤーを拡張できます。
- $browser — サイドパネルのアプリ内ブラウザで、Codex が Web 画面を検査し、注釈を付けられます。
- @chrome — ログイン済みのブラウザ状態と Chrome ベースのワークフロー用。
- @computer — デスクトップ GUI を通じてのみ存在する作業用。
$browser はサイドパネルのブラウザレビューに適しています。@chrome は、ユーザーの Chrome コンテキストに依存するログイン済みブラウザ作業に適しています。@computer は、デスクトップ GUI を通じてのみ存在するタスクに適しています。
MCP サーバーとコネクタは、同じアイデアをワークフローの残りの部分に拡張します。Slack、Gmail、カレンダー が重要なのは、多くの重要なタスクがコードになる前に、最初はメッセージ、受信箱アイテム、スケジュールの問題として現れるからです。
スキルを使うと、繰り返しのワークフローを再利用可能にできます。ワークフローが有用であることが証明されたら、スキルとしてパッケージ化 して、Codex がルーチンをゼロから再学習することなく再実行できるようにします。
どこからでも作業
Codex モバイルアプリ は、ユーザーがデスクにいなければならないタイミングを変えます。タスクは、ファイル、権限、ローカル設定が既に存在する Mac で開始し、ユーザーがスマートフォンからチェックインしながら続行できます。
これはちょっとした瞬間に重要です。Codex が長いタスクを実行している間にユーザーがデスクを離れ、外部から質問に答え、次のステップを承認し、戻る前にスレッドの方向を変えることができます。ローカル環境はそのまま残り、ユーザーはそれを考慮する必要がありません。
自動化
自動化 は、Codex の作業をスケジュールに従って実行します。日次レポートや定期的なリポジトリチェックなど、定期的なジョブをワークスペースから新たに開始する必要がある場合は、スケジュールされた自動化を使用します。スケジュールがアクティブな会話とその実行コンテキストに戻る必要がある場合は、スレッド自動化を使用します。
スレッド自動化:
同じ Codex スレッドにスケジュールに従って戻る、ハートビート型の定期的な起床呼び出し。
ピン留めされたスレッドは便利ですが、それでもユーザーが戻るのを待ちます。スレッド自動化は、数分ごとまたは数時間ごとに何かをチェックし、条件が満たされるまで続行し、時間の経過とともに頻度を調整できます。
チーフ・オブ・スタッフ用のスレッドは、30 分ごとに実行されるかもしれません。
30 分ごとに Slack と Gmail をチェックして、私の注意を必要とする未回答のメッセージがないか確認してください。
最も重要なものを優先順位付けするのを手伝ってください。
誰かが私に質問をしたら、できるだけ深く調べて、下書きの返信を作成してください。ただし、送信しないでください。
ユーザーが戻ってきたときには、コンテキストを収集するという高コストな部分は多くの場合完了しています。送信するかどうかは依然として人間が決定します。
スレッド自動化は、フィードバックループにも適しています。スレッド自動化は、プルリクエストのコメント、Google ドキュメントのコメント、Slack の返信を監視し、ユーザーが離れている間も周囲の作業を進め続けることができます。
レビュアーが Slack で動画を共有するアニメーションワークフローを考えてみてください。スレッド自動化はスレッドを定期的にチェックし、コメントが届いたら更新バージョンをレンダリングし、同じスレッドでレビュアーをメンションして返信します。1 つの統合機能で最終アップロードを完了できない場合、デスクトップ自動化が GUI を通じてそのステップを完了できます。
このループは、フィードバックのための Slack、レンダリングのためのコードベース、そして最終アップロードのためのデスクトップ自動化にわたります。
目標
目標は、タスクにエージェントが向かって進み続けられる実際のゴールラインがある場合に最も強力です。弱い目標は次のようなものです。
目標:
エージェントが時間をかけて向かって進み続けられるゴールラインを持つ、より長時間実行される Codex タスク。
この Markdown ファイルの計画を実装してください。
より強力な目標には、測定可能な成功基準があります。
たとえば、エンジニアが社内ツールを Python から Rust に移行する場合、新しいディレクトリを設定し、目標を定義し、ゴールラインを明確にします。新しい実装が完了するのは、単体テストに合格したときです。
目標は、継続的な実行と検証機能を組み合わせたものです。ユーザーは成果、停止条件、および Codex が近づいているかどうかを示すシグナルを定義します。
有用な検証機能には以下が含まれます。
- テストスイート
- ベンチマーク
- バグの再現
- 検証マトリックス
- 合格し続けなければならないエンドツーエンドのワークフロー
野心は重要ですが、検証がなければ、それは単なる願望です。
サイドパネル
サイドパネル は、作業を、それを生み出した会話の隣に置いておきます。アーティファクトをエクスポートしてコンテキストを切り替える代わりに、ユーザーはその場でレビューできます。出力はコードかもしれませんが、デッキ、PDF、ブラウザページ、テーブル、または途中で作成されたその他のアーティファクトである可能性もあります。
特に 4 つのジョブをサポートします。
- アーティファクトの検査
- 変更が必要な箇所の注釈付け
- Web 画面の操作
- 変更のレビュー
サイドパネルを使用すると、ユーザーは Markdown、スプレッドシート、データテーブル、ドキュメント、スライドをその場でレビューできます。ループを壊すことなく、アーティファクトを検査、マークアップ、修正できます。
注釈
デッキや PDF は、それを生成したスレッドの隣に開いたままにでき、直接レビューと修正の準備ができています。
Codex でのシート
アプリ内ブラウザ を使用すると、Codex はレンダリングされたページを検査し、制御し、レビュー中の画面に直接注釈に応答できます。ページやアーティファクトへのコメントは、別の引き継ぎになるのではなく、作業ループ内に留まります。
Web は出力と制御面の両方になります。Codex はアーティファクトを構築し、サイドパネルで開き、検査し、デバッグし、同じオブジェクトをその場で改良し続けることができます。
これらの画面は特に効果的です。
- 軽量な静的アーティファクト用の index.html
- UI レビュー用の Storybook
- プログラムによるアニメーション用の Remotion Studio
- プレゼンテーション用のブラウザベースのスライドデッキ
- 分析ワークフロー用のデータアプリ
1 つの index.html ファイルは、サーバーを必要とせずに、耐久性のあるインタラクティブなアーティファクトになります。スレッド自動化は、静的アーティファクトを時間の経過とともに更新して、ユーザーが戻ったときにスレッドに新しいものが待っているようにすることもできます。
共有メモリ
長時間実行されるスレッドは、単一の会話の外部でメモリを共有すると、より便利になります。
共有メモリ:
単一のスレッドの外部に保存された永続的なコンテキスト。将来の作業が明示的でレビュー可能なものから再開できるようにする。
実績のあるパターンの 1 つは、永続的なスレッドを Obsidian ボールトに固定することです。具体的には、検査、編集、移動、長期保存が簡単なプレーンファイルのフォルダです。チームはそのフォルダをクラウドストレージ、Git、Dropbox、Google ドライブ、またはワークフローに合った他の同期レイヤーに保存できます。
ボールトは次のようになります。
vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/
トップレベルでは、AGENTS.md で、Codex が人、プロジェクト、決定、未解決のループについてさらに学習するにつれて、そのワークスペースをどのように更新するかを定義できます。
ボールトの構造を正確にコピーしないでください。永続的なコンテキストをどこに置くか、どのコンテキストを保持するか、いつ変更を生成しないかをエージェントに教えてください。
実用的な AGENTS.md は次のように言うかもしれません。
- ~/vault を永続的な作業メモリとして扱う。
- ノートの乱立よりも正規のノートを優先する。
- TODO、人、プロジェクト、日次サマリー、スクラッチノートを明示的に振り分ける。
- 決定、ブロッカー、所有者、日付、有用なリンクを保持する。
- 意味のある変更がない場合は、ボールトを変更しない。
リポジトリはコードを保持します。ボールトは変化するコンテキストを保持します。関与している人、何が変わったか、何がブロックされているか、何がフォローアップを必要とするか、そしてそうでなければセッション間で消えてしまうものです。
重要なコンテキストは、会話のトランスクリプト内にのみ存在するべきではありません。次のスレッドが再開できる場所に書き留めてください。
Codex には、設定 > パーソナライゼーション > メモリに、ファーストパーティのメモリ機能もあります。これらは、設定、繰り返しのワークフロー、既知の落とし穴に対するローカルなリコールレイヤーを提供します。これらは、明示的な記述コンテキストを置き換えるのではなく、補完します。Chronicle は、Codex が最近の画面コンテキストからメモリを構築するのを支援することで、同じ方向に推し進めます。
コードから外へ
Codex は依然としてコードから始まります。しかし、コードを取り巻く作業の多くが、同じシステムを通じて到達可能になりつつあります。MCP サーバー、ブラウザ画面、デスクトップコントロール、スレッド自動化、レビュー可能なアーティファクトなどです。
これにより、制御モデルが変わります。操作誘導は進行中の作業を中断します。キューイングは次のタスクを並べます。スレッド自動化は、ユーザーが離れている間もスレッドをアクティブに保ちます。目標は、Codex が向かって進み続けられる具体的なゴールラインを追加します。
Codex は現在、作業がリポジトリを離れる場合でも、指示から実行、アーティファクトのレビューまで、ワークフローを運ぶことができます。
