多くの開発者が初めて Codex を使うとき、たいていはコード作業から始めます。リポジトリを読む、diff を修正する、テストを走らせる、pull request を開く、といった作業です。
これは今でも Codex の中心的なユースケースです。ただ、コンピューター上の多くの仕事は、もともとコードとツールに囲まれています。shell コマンドを実行する、Web ページを閲覧する、API を呼び出す、文書をエクスポートする、メッセージに応答する、自動化を起動する。こうした能力が少しずつ Codex に接続されるにつれて、Codex は狭い意味でのコードアシスタントにとどまらず、コンピューター上の仕事を進めるためのシステムに近づいていきます。
Codex app は、この変化をより具体的なものにします。ひとつの thread はコンテキストを保持し、ツールを呼び出し、成果物を表示し、複数回のプロンプトをまたいで作業を進められます。毎回の会話をゼロから始め直す必要がありません。
Codex をさらに使いこなす鍵は、これらの能力を組み合わせることです。
- Durable threads によって、長期的なコンテキストを保存する
- 音声入力、steering、queuing によって、ユーザーがプロセスを握り続ける
- browser、computer use、MCP servers、connectors によって、Codex をリポジトリの外へ広げる
- thread automations と Goals によって、ユーザーが離れたあともタスクを進める
- サイドバーによって、コード、文書、スライド、Web ページ、その他の成果物をレビューする
- 共有メモリによって、重要なコンテキストを thread の外へ書き出す
Durable threads
Durable threads とは、複数回の会話をまたいで作業コンテキストを保持できる長期 thread のことです。
Pinned threads は実用的な入口です。何度も戻ってくるワークフローに向いています。たとえば次のようなものです。
- Chief of Staff thread
- リリース thread
- 文書レビュー thread
- 外部監視 thread
これらは一時的なチャットではなく、継続して存在する作業空間です。Codex は後から同じ thread に戻り、以前の判断、好み、背景情報を引き継げます。毎回コンテキストをゼロから作り直す必要がなくなります。
ショートカットも使い勝手を高めます。Command-1 から Command-9 で、保存済みの thread に直接移動できます。
音声入力
音声入力の価値は、まだ正式な文章に整理されていない考えを捉えられることにあります。
Codex には音声入力が組み込まれています。話すと自然なのに、文字で打とうとすると妙にぎこちなくなる、曖昧な出発点に特に向いています。
|
|
検索し、コンテキストを整理し、結果を報告できる agent にとっては、これだけで作業を始めるには十分なことがよくあります。
音声は、2、3 分ほど考えを吐き出す用途にも向いています。会議の文字起こし、口頭での計画メモ、未整理の生ログは、しばしば一文の要約より役に立ちます。不確実さ、重点、まだ言い切れていない思考の流れが残るからです。
Steering と queuing
音声と明示的な制御を組み合わせると、さらに有用になります。
Steering とは、Codex のタスク実行中に新しい方向を差し込み、現在のステップが終わる前に軌道修正させることです。
たとえば Web ページをレビューしているとき、ユーザーはサイドバーに注釈を付けながら、現在のタスクに割り込めます。
|
|
Queuing はそれとは異なります。現在のタスクを中断せず、次に行う作業をキューに積みます。
|
|
Steering は、Codex が今まさに何をしているかを変えます。Queuing は、次に何をすべきかを変えます。どちらも、タスクが進行している最中でもユーザーが現場に近い場所にいられるようにします。
ツールと到達範囲
thread に連続性が生まれると、次の問いは「何を操作できるのか」になります。
Codex は層を重ねるように外へ広がれます。
$browser：サイドバー内の Web ページ検査、注釈、review に向いている@chrome：ユーザーの Chrome ログイン状態に依存するブラウザワークフローに向いている@computer：デスクトップ GUI 経由でしか完了できないタスクに向いている
MCP servers と connectors は、同じ考え方をさらに多くのワークフローへ広げます。Slack、Gmail、Calendar は重要です。多くのタスクは、最初からコードとして現れるのではなく、メッセージ、メール、予定に関する問題として現れるからです。
Skills は、繰り返し作業を固定化するのに向いています。ある手順が有用だと分かったら、それを skill としてパッケージ化できます。そうすれば Codex は次回、その手順を学び直す必要がありません。
どこからでも作業を続ける
Codex mobile app は、ユーザーが必ずコンピューターの前に座っていなければならない時間を変えます。
タスクは Mac 上で始められます。ファイル、権限、ローカル環境がそこにあるからです。その後、ユーザーがデスクを離れても、スマートフォンだけで確認、補足、方向修正を続けられます。
これは多くの小さな場面で価値があります。Codex が長いタスクを走らせている間、ユーザーは席を離れられます。確認が必要になれば外出先から返信できます。方向が間違っていれば、すぐに redirect できます。本当にその場に残っているのはローカル環境であって、ユーザー本人ではありません。
自動化
Automations は、Codex の作業をスケジュールに沿って実行できます。
周期的なタスクを特定の workspace から毎回始めるべき場合、たとえば日報や定例のリポジトリチェックなら、scheduled automation を使えます。スケジュール実行が既存の会話に戻り、そのコンテキストを引き継ぐべきなら、thread automation のほうが適しています。
Thread automations は、心拍のような呼び起こしに近いものです。固定されたリズムで同じ Codex thread に戻ります。
Pinned threads はユーザーが能動的に戻る必要があります。一方で thread automation は、数分ごと、あるいは数時間ごとにチェックし、条件を満たすまで継続して動き、時間に応じてリズムを調整できます。
たとえば、Chief of Staff thread を 30 分ごとに実行できます。
|
|
ユーザーが戻ってきたときには、最も時間のかかるコンテキスト収集がすでに終わっていることがよくあります。本当に送信するかどうかは、引き続き人間が決めます。
Thread automations はフィードバックループにも向いています。pull request のコメント、Google Docs のコメント、Slack の返信を定期的に確認し、ユーザーが離れている間も周辺作業を進められます。
たとえばアニメーション制作のワークフローでは、reviewer が Slack で動画フィードバックを送ります。thread automation が定期的に thread を確認し、新しいコメントがあればバージョンを再レンダリングし、同じ Slack thread で reviewer に返信します。何らかの連携が最終アップロードを完了できない場合でも、デスクトップ自動化で GUI から最後の一歩を補えます。
このループは Slack、コードベース、デスクトップアプリをまたぎますが、ユーザーから見ると同じワークフローの中に残っています。
Goals
Goals は、明確な終点があり、agent が継続的に前進させられるタスクに最も向いています。
弱い goal は、たとえば次のようなものです。
|
|
より強い goal には、測定可能な完了基準があります。
たとえば内部ツールを Python から Rust へ移行する場合、まず新しいディレクトリを作り、次に目標を明確にします。新しい実装は、単体テストが通って初めて完了とみなす、という具合です。
Goal の本質は、検証器を伴う継続実行です。ユーザーは結果、停止条件、そして Codex が目標に近づいているかを判断する信号を定義する必要があります。
よくある検証器には次のものがあります。
- テストスイート
- benchmark
- bug reproduction
- validation matrix
- 継続的に通り続ける必要があるエンドツーエンドワークフロー
タスクに野心があっても、検証条件がなければ、それは goal というより願望に近くなります。
サイドバー
サイドバーは、作業成果物をそれを生成した会話の横に置きます。ユーザーはファイルをエクスポートし、コンテキストを切り替え、また戻って問題を説明し直す必要がありません。成果物はコードかもしれませんし、deck、PDF、Web ページ、表、あるいは作業中に生成されたその他の artifact かもしれません。
特に次の 4 種類の作業に向いています。
- artifact を検査する
- 修正が必要な箇所に注釈を付ける
- Web ページ UI を操作する
- 変更をレビューする
Markdown、表、データテーブル、文書、スライドは、サイドバーで直接確認できます。ユーザーは確認、注釈、修正を行えます。その過程を別の引き継ぎに変える必要はありません。
deck や PDF の場合も、それを生成した thread の横に置いたまま、いつでも review と修正を受けられます。
ブラウザも似た作業面です。Codex はレンダリング済みのページを開き、検査し、ユーザーがページ上に付けた注釈に応答し、同じ対象を修正し続けられます。Web ページは出力結果であると同時に、制御面でもあります。
こうした面は、特にサイドバーに置くのに向いています。
index.htmlのような軽量な静的 artifact- Storybook
- Remotion Studio
- ブラウザスライド
- データ分析アプリ
単独の index.html ファイルでも、長期的に存在するインタラクティブ artifact になれます。必ずしもサーバーは必要ありません。Thread automations は静的 artifact を定期的に更新し、ユーザーが戻ったときに新しい結果を見られるようにもできます。
共有メモリ
長期 thread は有用ですが、重要なコンテキストは会話履歴の中だけに置くべきではありません。
Shared memory とは、永続的なコンテキストを thread の外に保存し、未来の作業が明確でレビュー可能な場所から続けられるようにすることです。
安定した方法のひとつは、Durable threads を Obsidian vault に結びつけることです。実際の形はとても単純で構いません。確認、編集、移動、長期保存がしやすい普通のファイル群です。チームなら cloud storage、Git、Dropbox、Google Drive、その他の同期レイヤーに置けます。
vault はたとえば次のようになります。
|
|
トップレベルの AGENTS.md では、Codex がこの作業空間をどう維持すべきかを説明できます。どんな情報を書き残すのか、どこに書くのか、どんなときにノイズを増やさないのか、といったことです。
実用的な AGENTS.md は、たとえば次のように書けます。
|
|
特定の vault 構造をそのまま真似る必要はありません。より重要なのは、agent に教えることです。長期コンテキストをどこに置くべきか、どの情報を残す価値があるか、どんなときにファイルを何度も変更すべきではないか。
リポジトリはコードを置く場所です。Vault は流動的なコンテキストを置く場所です。関係者、何が起きたか、どこで詰まっているか、誰が責任を持つか、次に何をするか、そして書き残さなければ会話の間で失われてしまう細部を保存します。
Codex にはファーストパーティの記憶機能もあり、Settings > Personalization > Memories で設定できます。好み、繰り返しのワークフロー、よくある落とし穴を記録するのに向いています。ただし、明示的な written context の補助として使うほうが適しており、代替にはなりません。Chronicle も同じ方向に進んでいます。直近の画面コンテキストから Codex が記憶を作れるよう支援するものです。
コードの外へ広げる
Codex は今でもコードから始まります。ただし、コードの周囲にあるさらに多くの作業も、今では同じシステムから到達できます。MCP servers、ブラウザ画面、デスクトップ制御、thread automations、レビュー可能な artifact です。
これは Codex の使い方における制御の形を変えます。Steering は進行中の作業に割り込むために使います。Queuing は次の一手を積むために使います。Thread automations はユーザーが離れたあとも thread を動かし続けます。Goals は長期タスクに明確な終点と検証信号を与えます。
これらの能力がつながると、Codex はひとつのワークフローを指示から実行へ、さらに artifact review へ進められます。タスクがコードリポジトリを離れていても、同じシステムの中で完了できます。