Codex を最大限活用する：ツール、スレッド、そして自動化（英中対照）

*Codex の最大限活用*

出典：OpenAI Codex 公式ガイド | 英中対照版

Most developers first use coding agents for code: inspect a repository, make a diff, run tests, and open a pull request. That's still the center of gravity for Codex. But much of the work on a computer is already mediated by code: executing shell commands, browsing web pages, calling APIs, exporting documents, responding to events, and triggering automations. As those surfaces become available to Codex, it starts to feel less like a coding assistant in the narrow sense and more like a system for getting computer work done.

ほとんどの開発者は、まずコーディングエージェントをコード作業で使います。リポジトリの確認、差分（Diff）の作成、テスト実行、プルリクエストの作成です。これは今も Codex の中心です。しかし、コンピュータ上の作業の多くはすでにコードで中継されています。たとえばシェルコマンドの実行、ウェブページ閲覧、API 呼び出し、文書のエクスポート、イベントへの応答、オートメーションの実行などです。これらの操作が Codex に開放されるにつれ、Codex はより狭義の「コード専用アシスタント」から、実務処理を前提としたシステムへと変わっていきます。

The Codex app makes that shift concrete. A thread can keep context, use tools, surface artifacts, and continue across prompts instead of resetting after each exchange.

Codex アプリはその変化を具体的な形にします。スレッドはコンテキストを保持し、ツールを利用し、成果物を提示し、やり取りごとにリセットされるのではなく、プロンプトをまたいで継続できます。

Getting more out of Codex means using these capabilities together:

Codex をより強く使うには、これらの機能を組み合わせることが重要です。

• durable threads that preserve context
• voice, steering, and queuing while the user is still in the loop
• browser, computer-use, MCP servers, and connectors that let Codex act beyond a repo
• thread automations and Goals that continue the work while the user is away
• the side panel, where users can review code, documents, decks, and other artifacts

• コンテキストを保持する永続スレッド
• 利用者が参加している間の音声入力、ステアリング、キューイング
• リポジトリの外側でも作業できる、ブラウザ、コンピュータ制御、MCP サーバー、コネクタ
• ユーザー不在時にも作業を継続するスレッド自動化と Goals
• コード、ドキュメント、資料、その他の成果物をレビューできるサイドパネル

第一章、持続スレッド / Durable Threads

Durable threads: Long-running Codex threads that preserve working context across repeated sessions.

>

持久スレッド： 複数セッションをまたいで作業文脈を維持する、長時間実行の Codex スレッド。

Pinned threads are one way to keep durable threads close at hand. They're useful for recurring work streams such as:

ピン留め（固定）スレッドは、持続スレッドをすぐ使える状態で近くに置く方法の一つです。定常的な作業ストリーム、たとえば次のような用途に便利です。

• a Chief of Staff thread
• a release thread
• a documentation review thread
• a thread dedicated to external monitoring

• 参謀（チーフ・オブ・スタッフ）スレッド
• リリーススレッド
• ドキュメントレビュー用スレッド
• 外部モニタリング専用スレッド

These are persistent workspaces, not short chats. Codex can revisit them over time, preserving prior decisions, preferences, and working context that would otherwise need to be rebuilt from scratch.

これらは短いチャットではなく、持続的なワークスペースです。Codex は時間をおいて再訪し、最初から再構築する必要のあった意思決定・嗜好・作業コンテキストを保持したまま引き継ぐことができます。

Pinned-thread shortcuts make this practical. Command-1 through Command-9 jump directly into saved threads.

ピン留めスレッドのショートカットが実用性を高めます。Command-1 から Command-9 で保存済みスレッドに直接移動できます。

第二章、音声入力 / Voice Input

Voice input is valuable because it captures the rough version of a thought before it's compressed into polished prose.

音声入力は、思考が磨かれた文章になる前の、より生々しい思考の状態を捉えられる点で価値があります。

Codex has built-in voice input. It works especially well for vague starting points that are natural to say but awkward to type:

Codex には音声入力機能が標準装備されています。言葉としては自然でも、タイプしようとすると言いにくいあいまいな着想に特に向いています。

I think someone named Ben mentioned this in Slack.

I do not remember the details.

Please go look.

「ベンという名前の人が Slack でこれについて言っていた気がします。」

「詳細は覚えていません。」

「確認してきてください。」

For an agent that can search, gather context, and report back, that's often enough.

検索して文脈を集め、結果を報告できるエージェントなら、それで十分なことが多いです。

It also works well for a two- or three-minute thought dump before the task is fully formed.

タスクがまだ形になっていない段階で、2～3 分ほど思考をしゃべり出しておく用途にも有効です。

Transcripts work the same way. A raw meeting transcript or dictated planning note often provides better source material than a short summary because it preserves uncertainty, emphasis, and unfinished lines of thought.

文字起こしも同様です。会議の生トランスクリプトや口述の計画メモは、短い要約より役立つことがあります。なぜなら、曖昧さ、強調点、未完了の思考の流れが残るためです。

第三章、方向修正とタスクのキューイング / Steering and Queuing

Voice becomes even more useful when paired with explicit control over an active task.

音声は、進行中タスクの明示的な制御と組み合わさるとさらに有効になります。

Steering: Interrupting an in-flight Codex task with new direction before the current step finishes.

方向修正（Steering）： 現在のステップが終わる前に、新しい指示で進行中タスクを中断すること。

Steering is useful when the agent is heading the wrong way and needs a correction before it finishes. During a website review, for example, the user can interrupt the work while annotating the surface in the side panel:

エージェントが誤った方向へ進んでおり、完了前に修正が必要なときに役立つのが方向修正です。たとえばサイトレビュー中、ユーザーはサイドパネルで画面に注釈を付けながら作業を随時中断できます。

make this smaller

the spacing between these two elements feels off

this copy is wrong

「ここをもっと小さく」

「この二つの要素の間隔が不自然」

「このコピーは誤りです」

Queuing: Adding work for Codex to do after the current step completes.

タスクのキューイング（Queuing）： 現在のステップ完了後に次の作業を追加すること。

Queuing is different. It doesn't interrupt the task in progress. It adds the next task to the line. A user might say:

キューイングは性質が異なります。進行中のタスクを中断しません。単に次の作業を列に追加するだけです。ユーザーは次のように指示できます。

Once the work is done, send the preview link to the reviewer in Slack.

「作業が完了したら、プレビューリンクを Slack でレビュアーへ送ってください。」

Steering changes what Codex is doing now. Queuing changes what should happen next. Both keep the user close to the work while it's unfolding.

方向修正は、Codex が今行っている内容を変えます。キューイングは次に何をするかを決めます。どちらも、作業が進んでいる間にユーザーが近くで確認できる状態を保ちます。

第四章、ツール能力と到達範囲 / Tools and Reach

Once a thread has continuity, the next question is what it can act on. Codex can move outward in layers:

スレッドの継続性が確立すると、次の問いは「どこまで実際に手を伸ばせるか」です。Codex は階層的に対象を広げていけます。

• $browser for the in-app browser in the side panel, where Codex can inspect and annotate web surfaces
• @chrome for signed-in browser state and Chrome-based workflows
• @computer for work that only exists through a desktop GUI

• $browser：サイドパネル内蔵ブラウザ。Codex がウェブ画面を調査・注釈できる領域です
• @chrome：Chrome のログイン状態を使うワークフロー向け
• @computer：デスクトップ GUI でしか成立しない作業向け

$browser fits side-panel browser review. @chrome fits signed-in browser work that depends on the user's Chrome context. @computer fits tasks that only exist through a desktop GUI.

$browser はサイドパネルでのブラウザレビュー向け、@chrome はユーザーの Chrome コンテキストに依存するサインイン済みブラウズ作業向け、@computer はデスクトップ GUI でしか存在しないタスク向けです。

MCP servers and connectors extend the same idea into the rest of a workflow. Slack, Gmail, and Calendar matter because many important tasks first appear as messages, inbox items, or scheduling problems before they ever become code.

MCP サーバーとコネクタは、この考え方をワークフロー全体へ拡張します。Slack、Gmail、Calendar が重要なのは、多くの重要タスクが「メッセージ」「受信箱の項目」「日程調整の問題」として現れ、コードになる前に処理の焦点になるからです。

Skills make repeated workflows reusable. Once a workflow proves useful, package it as a skill so Codex can run it again without relearning the routine from scratch.

Skills を使うと、繰り返しのワークフローを再利用できます。価値が確認できたワークフローは、Skill として定義しておけば、Codex は毎回最初から手順を再学習せずに再実行できます。

第五章、どこでも働く / Work from Anywhere

The Codex mobile app changes when the user has to be at the desk. A task can start on a Mac where the files, permissions, and local setup already live, then continue while the user checks in from a phone.

Codex モバイルアプリの登場で、ユーザーが机の前にいることが必須という構図が変わります。タスクは、ファイル・権限・ローカル設定が整っている Mac で開始し、ユーザーがスマートフォンから確認しながら続行することができます。

That matters in small moments. Someone can leave the desk while Codex runs a longer task, answer a question from outside, approve the next step, or redirect the thread before they get back. The local environment stays in place; the user doesn't have to.

こうした「隙間時間」が実運用では効きます。ユーザーは Codex が長時間タスクを実行している間に席を離れ、外出先で質問に回答したり、次のステップを承認したり、戻る前にスレッドを再方向付けしたりできます。ローカル環境はそのまま残り、ユーザー側で都度再構築する必要がありません。

第六章、自動化 / Automations

Automations run Codex work on a schedule. Use a scheduled automation when the recurring job should start fresh from a workspace, such as a daily report or a regular repository check. Use a thread automation when the schedule should return to an active conversation with its running context.

自動化は、スケジュールに基づいて Codex の作業を実行します。毎日のレポート作成や定期的なリポジトリチェックのように、作業を workspace ベースで最初から開始する場合は「スケジュール自動化」を使います。逆に、実行中コンテキストを持つ対話へ戻る必要がある場合は「スレッド自動化」を使います。

Thread automations: Heartbeat-style recurring wake-up calls that return to the same Codex thread on a schedule.

スレッド自動化： スケジュールに従って定期的に起こされ、同一の Codex スレッドへ復帰するハートビート型の繰り返し起動。

Pinned threads are useful, but they still wait for the user to return. A thread automation can check on something every few minutes or every few hours, continue until it meets a condition, and adjust the cadence over time.

ピン留めスレッドは便利ですが、あくまでユーザーが戻るのを待つ必要があります。スレッド自動化なら、数分または数時間ごとに監視し、条件が満たされるまで継続し、時間とともに実行頻度も調整できます。

A Chief of Staff thread might run every 30 minutes:

「Chief of Staff」スレッドは 30 分ごとに実行されることがあります。

Every 30 minutes, check Slack and Gmail for unanswered messages that need my attention.

Help me prioritize what matters most.

If someone asks me a question, research the answer as deeply as you can and draft a reply for me, but do not send it.

「30 分ごとに Slack と Gmail を確認し、私の対応が必要な未返信メッセージを抽出してください。」

「優先度の高いものから順に整理してください。」

「誰かから質問が来たら、できる限り深く調査し、返信草案を作成してください。ただし送信しないでください。」

When the user returns, the expensive part of gathering context is often done. The human still decides what gets sent.

ユーザーが戻る頃には、コンテキスト収集の重い処理はほぼ完了していることが多いです。最終的に何を送るかを決めるのは依然として人です。

Thread automations also fit feedback loops. A thread automation can watch pull request comments, Google Docs comments, or Slack replies and keep the surrounding work moving while the user is away.

スレッド自動化はフィードバックループにも適しています。スレッド自動化は Pull Request コメント、Google Docs コメント、Slack の返信を監視し、ユーザーが離席している間も周辺作業を前進させます。

Consider an animation workflow where a reviewer shares a video in Slack. A thread automation can check the thread on a schedule, render an updated version when comments arrive, and reply in the same thread tagging the reviewer. If one integration can't complete the final upload, desktop automation can finish the step through the GUI.

たとえば、レビュアーが Slack で動画を共有するアニメーションワークフローを想定してください。スレッド自動化は予定どおりにそのスレッドを確認し、コメント到着時に更新版をレンダリングして、同じスレッド内でレビュアーにメンションして返信できます。もしある連携先で最終アップロードが完了しない場合は、デスクトップ自動化で GUI 操作として仕上げることができます。

The loop spans Slack for feedback, the codebase for rendering, and desktop automation for the final upload.

このループは、フィードバックの起点が Slack、レンダリングがコードベース、最終アップロードがデスクトップ自動化、という三層で構成されます。

第七章、目標設定 / Goals

Goals are most powerful when the task has a real finish line that the agent can keep pushing toward. A weak goal is:

Goal は、エージェントが時間をかけて到達し続けられる明確な“ゴールライン”があるときに最も強力になります。弱い目標は次のようなものです。

Goals: Longer-running Codex tasks with a finish line the agent can keep working toward over time.

Goal： 時間をかけて進められ、エージェントが継続的に取り組み続けることのできる明確な到達点を持つ長期タスク。

Implement the plan in this Markdown file.

>

「この Markdown ファイルの計画を実装してください。」

A stronger goal has a measurable success criterion.

より強い Goal には、測定可能な成功条件があります。

For example, an engineer might migrate an internal tool from Python to Rust by setting up the new directory, defining the goal, and making the finish line explicit: the new implementation isn't done until the unit tests pass.

例えば、あるエンジニアが内部ツールを Python から Rust に移行する場合、新しいディレクトリを用意し、ゴールを定義し、到達点を明確にします。つまり、ユニットテストが通過するまでは新実装は完了とみなさない、という具合です。

A goal combines ongoing execution with a verifier. The user defines the outcome, the stopping condition, and the signal that says whether Codex is getting closer.

Goal では継続実行と検証器を組み合わせます。ユーザーが成果、停止条件、Codex が目標に近づいているかを示すシグナルを定義します。

Useful verifiers include:

有効な検証器には、次のようなものがあります。

• a test suite
• a benchmark
• a bug reproduction
• a validation matrix
• an end-to-end workflow that must keep passing

• テストスイート
• ベンチマーク
• バグ再現
• バリデーションマトリクス
• 常時パスし続ける必要のあるエンドツーエンドワークフロー

Ambition matters, but without verification it's just a wish.

野心は重要ですが、検証がなければただの願望に過ぎません。

第八章、サイドパネル / The Side Panel

The side panel keeps the work beside the conversation that produced it. Instead of exporting an artifact and switching contexts, the user can review it in place. The output might be code, but it might also be a deck, a PDF, a browser page, a table, or another artifact created along the way.

サイドパネルは、作業物をそれを生み出した会話の横に保持します。成果物をエクスポートして文脈を切り替える必要はなく、その場でレビューできます。出力はコードであるだけでなく、スライド、PDF、ブラウザページ、表、あるいは途中で生成された別の成果物であっても構いません。

It supports four jobs especially well:

サイドパネルは特に次の 4 つの用途に向いています。

• Inspect artifacts
• Annotate what needs to change
• Operate web surfaces
• Review changes

• 成果物の確認
• 変更が必要な箇所への注釈
• ウェブ画面の操作
• 変更内容のレビュー

The side panel lets users review Markdown, spreadsheets, data tables, documents, and slides in place. They can inspect, mark up, and revise artifacts without breaking the loop.

サイドパネルでは、Markdown、スプレッドシート、データテーブル、文書、スライドをその場でレビューできます。作業の流れを止めずに、確認・注釈・修正が可能です。

Annotations

The deck or PDF can stay open beside the thread that produced it, ready for direct review and repair.

スライドや PDF は、それを生成したスレッドの横で開いたままにして、直接レビューと修正が行えます。

Sheets in Codex

The in-app browser lets Codex inspect a rendered page, control it, and respond to annotations directly on the surface under review. Comments on a page or artifact stay inside the working loop instead of becoming a separate handoff.

内蔵ブラウザでは、Codex がレンダリング済みページを確認し、操作し、レビュー対象の画面上で直接注釈に応答できます。ページや成果物へのコメントは作業ループ内に留まり、別の引き継ぎとして分離されません。

The web becomes both output and control surface. Codex can build an artifact, open it in the side panel, inspect it, debug it, and keep refining the same object in place.

ウェブは成果物であると同時に制御面でもあります。Codex は成果物を作成し、サイドパネルで開き、検査し、デバッグし、同じオブジェクトをその場で継続的に改良できます。

These surfaces work especially well:

これらの画面は特に次のような場合に力を発揮します。

• index.html for lightweight static artifacts
• Storybook for UI review
• Remotion Studio for programmatic animation
• browser-based slide decks for presentations
• data apps for analysis workflows

• index.html：軽量な静的成果物
• Storybook：UI レビュー
• Remotion Studio：プログラムによるアニメーション
• ブラウザベースのスライドデッキ：プレゼンテーション
• データアプリ：分析ワークフロー

A single index.html file can become a durable interactive artifact with no server required. Thread automations can also refresh static artifacts over time so a thread has something new waiting when the user returns.

単一の index.html ファイルでも、サーバーなしで持続的なインタラクティブ成果物にできます。スレッド自動化を使えば静的成果物を定期的に更新でき、ユーザーが戻ったときに最新状態を待たせられます。

第九章、共有メモリ / Shared Memory

Long-running threads become more useful when they share memory outside any one conversation.

長時間稼働するスレッドは、会話単位を超えてメモリを共有できると、さらに価値が高まります。

Shared memory: Durable context stored outside a single thread so future work can resume from something explicit and reviewable.

共有メモリ： 単一のスレッド外に保存される持続的コンテキストで、将来の作業が明示的かつレビュー可能な基点から再開できる状態。

One durable pattern is to anchor persistent threads in an Obsidian vault. In practice, that means a folder of plain files that stays straightforward to inspect, edit, move, and keep for a long time. Teams can store that folder in cloud storage, Git, Dropbox, Google Drive, or another sync layer that fits their workflow.

持続的な運用パターンとしては、永続スレッドを Obsidian の保管庫（Vault）に接続する方法があります。実務的には、プレーンファイルのフォルダを長期間にわたって、確認・編集・移動・保管しやすい形で持つということです。チームはこのフォルダをクラウドストレージ、Git、Dropbox、Google Drive、またはワークフローに合う別の同期層に置けます。

A vault might look like this:

Vault の例は次のようになります。

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

At the top level, AGENTS.md can define how Codex should update that workspace as it learns more about people, projects, decisions, and open loops.

トップレベルには AGENTS.md を置き、人物・プロジェクト・意思決定・未完了項目に関する理解が深まるにつれて、Codex がワークスペースをどのように更新すべきかを定義できます。

Don't copy one exact vault structure. Teach the agent where durable context should live, what context to preserve, and when not to create churn.

特定の Vault 構成をそのまま固定して模倣しないでください。持続的コンテキストをどこに置き、何を保持し、いつ不要なノイズを増やしてはいけないかを、エージェントに教えることが重要です。

A practical AGENTS.md might say:

実務的な AGENTS.md は、次のように書けます。

- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.

Repositories hold code. The vault holds rolling context: the people involved, what changed, what's blocked, what needs follow-up, and what would otherwise disappear between sessions.

リポジトリはコードを保持します。Vault は、関係者、変更内容、ブロッカー、フォローアップ項目、セッション間で消えやすい情報といった継続的文脈を保持します。

Important context shouldn't live only inside a conversation transcript. Write it down somewhere the next thread can pick back up.

重要な文脈は会話ログの中だけに置いておくべきではありません。次のスレッドが引き継げる場所に必ず記録してください。

Codex also has first-party memory features in Settings > Personalization > Memories. They provide a local recall layer for preferences, recurring workflows, and known pitfalls. They complement explicit written context rather than replacing it. Chronicle pushes in the same direction by helping Codex build memory from recent screen context.

Codex には「設定 > パーソナライゼーション > メモリ」に一次機能としてのメモリ機能があります。これは、好みや反復ワークフロー、既知の落とし穴に対するローカルな記憶層を提供し、明示的な文書コンテキストを置き換えるのではなく補完します。Chronicle も同様に、直近の画面コンテキストから Codex の記憶形成を支援します。

第十章、コードから外へ / From Code Outward

Codex still starts from code. But more of the work around code is now reachable through the same system: MCP servers, browser surfaces, desktop controls, thread automations, and reviewable artifacts.

Codex の出発点は依然としてコードです。しかし、コード周辺の作業の範囲は今や同一システムで到達可能になっています。たとえば MCP サーバー、ブラウザ画面、デスクトップ操作、スレッド自動化、レビュー可能な成果物です。

That changes the control model. Steering interrupts the work in progress. Queuing lines up the next task. Thread automations keep a thread active when the user steps away. Goals add a concrete finish line that Codex can keep working toward.

これにより制御モデル自体が変わります。ステアリングは進行中タスクの方針を即時修正し、キューイングは次の作業を順序立て、スレッド自動化はユーザー離席時にもスレッドをアクティブに保ち、Goals は Codex が引き続き前進できる具体的なゴールラインを追加します。

Codex can now carry a workflow from instruction to execution to artifact review, even when the work leaves the repo.

Codex は、作業がリポジトリ外に拡張してしまっていても、指示から実行、成果物レビューまでを一連で担えるようになりました。

*本記事は OpenAI Codex 公式ガイドを基にしています。英中対照版は Lamjin が翻訳・編集しました。*

国内で Codex の登録と認証を安定して利用したい場合は、《giffgaff 英国実在番号利用ガイド》をご参照ください。OpenRouter の無料モデルを Codex の代替実験基盤として使う場合は、《OpenRouter 無料モデル推奨》をご覧ください。

よくある質問

Codex と Claude Code の違いは？

Codex は OpenAI のコーディングエージェント製品で、Claude Code は Anthropic の対応ツールです。両者は設計思想が近く（実環境でタスクを実行するエージェント）ですが、エコシステムと統合方法は異なります。Codex は GitHub 統合とクラウド実行を重視し、Claude Code はローカル CLI ワークフロー寄りです。

Codex の「持続スレッド」とは？

持続スレッドは、複数回のプロンプト交換の間でコンテキストを保持し、毎回リセットされない状態を意味します。多段階で進める複雑なタスク向けです。タスクキューイングやスレッド自動化と組み合わせることで、ユーザーが離席中でも後続作業を継続できます。

Codex の Automations（自動化タスク）はどのように動作しますか？

Automations は、ユーザーがオンラインでないときでもタスクを継続実行します（定期的なリポジトリチェックやイベント対応、テスト実行など）。これは、Codex をバックグラウンドワーカーとして機能させるイメージです。Goals は、毎回手動で起動を待つのではなく、具体的な目標へ継続的に進めるモードです。

Codex はどの外部ツールに接続できますか？

Codex は現在、ブラウザ、MCP サーバー、各種コネクタ（Connectors）をサポートし、外部 API 呼び出し、ドキュメントの読み書き、Shell 実行、コードベース外のシステム操作を行えます。

参照元

• Getting the Most Out of Codex（原文ツイート）