原文タイトル：Codex-maxxing
原著者：Jason Liu
翻訳：Peggy

Editor's Note: The AI Agent is evolving from a "code-writing tool" into a new kind of work operating system.

In this article, author Jason Liu (OpenAI Codex team engineer) uses his own experience with Codex as a guide to document how this transformation has taken place: from pinned threads, voice input, shared memory, to browser control, remote operation, Heartbeats auto-loop, and sidebar panels. Codex is no longer just a chat window waiting for a prompt, but is starting to become a space that can host tasks, remember context, generate artifacts, and continuously drive work forward.

What is most noteworthy is not whether Codex can write better code, but how it is changing "how work is organized." In the past, AI usage often remained in a "question-answer" format: users make requests, models provide results, and tasks interrupt at the end of the conversation. However, in this new workflow, threads can exist for a long time, memory can be solidified into files, tasks can be automatically executed regularly, users can intervene, review, and correct at any time, ultimately forming a small operational loop.

This means that the value of the Agent is shifting from "ability" to "continuity." It is not just helping people complete a single task, but establishing connections between different tools, files, browsers, Slack, Gmail, calendars, and local apps, ensuring work continues to progress even after the user leaves. For knowledge workers, this may be a critical step for AI tools to truly enter the daily production process: not replacing an action, but preventing more work from dying after a single prompt.

The following is the original article:

Codex is not just for coding, but taking over workflows

Before Codex appeared, I had been using programming Agents extensively. However, most of the time, I was using them in interfaces designed specifically for programming work: generating diffs, modifying code repositories, delivering code.

Starting around November, I began pushing them into knowledge work scenarios. I used Slidev for presentations, treated the Agent as a note-taker with voice input, and have been looking for other artifacts that can be assisted in generating by programming Agents: an index.html, a PDF, a spreadsheet, a set of slides.

最新の Codex App のアップデートは、私が使った中で初めて、このようなより広義の作業モードを「ネイティブ」に感じさせる本当の製品でした。Codex はまだコードの執筁に長けていますが、より興味深い変化は、私の仕事に「収める」場所を提供し始めたことです。

私の使用習慣を本当に変えたのは、仕事のために実行ループを作る方法を学んだことです：持続可能なスレッド、共有メモリ、私のコンピュータを制御できるツール、いつでも介入してタスクを再開できる方法、そして作業物自体を直接レビューできるインターフェース。

持続可能なスレッド

私の行動を変えた最初の機能は、コンテキストの圧縮です。

今、私はあらゆる重要なワークフローに固定スレッドを設けます：

私の Chief of Staff スレッド

Agents SDK

OpenAI CLI

オープンソースの Codex

Twitter を監視する専用スレッド

これらは短い会話ではありません。これらは数ヶ月分の大きなスレッドを既に圧縮しているものです。彼らは歴史を蓄積し、過去の好みや過去に行った決定を常に覚えており、その情報を毎回語るのは面倒です。

固定スレッドショートカット

Command-1 から Command-9 を使って、固定スレッドに直接移動できます。

もちろん、代償があります。持続的なスレッドは無料ではありません。後で再度それらを開くと、会話はおそらくキャッシュされていないため、新しい短いスレッドを開くよりもコストがかかる可能性があります。しかし、本当に重要なワークフローにとって、連続性は価値があります。

音声入力

音声入力により、Codex が私のよりリアルな思考プロセスを取得できるようになりました。

その利点は速度ではなく、エージェントが編集されていない思考の本質を取得できることにあります。Codex には音声入力が組み込まれていますが、システムレベルの音声認識を使用するために Wispr Flow も使用します。作業を計画している場合、「Slack で Ben という人がこれについて言及していたことを覚えているけど、具体的に何だったかは覚えていない。調べてくれ。」と言うことがあります。この文を打ち込むと、曖昧で迷惑になる可能性がありますが、話すと非常に自然です。

転写テキストも同様です。記事を書きたい場合、誰かに電話して会話を録音したり、Granola アプリを使ってオフラインでの会話を録音したりすることで、転写を出発点として利用することができます。多くの計画がより良くなる理由の一つは、モデルが私の混沌だらけだが真実の考えを取得し、私が磨かれたバージョンだけでなくしているからです。

Steering: 持続的な誘導

音声入力は Steering と組み合わさるとより有用になります。

Steering により、1回のツール呼び出しの後に次のメッセージを注入できます。例えば、ウェブサイトのレビュー中に、次のように言いながら続けることができます：

Make this a bit smaller

This copy doesn't seem right

The spacing between these two elements feels off

Open a PR once done

Wait for the preview deployment

Send the preview link to people who need to review on Slack

I don't need to wait for each step to be completed before deciding what to do next. I can continue to add intent while the Agent is still working, and then leave with a queued list of tasks.

Later, Heartbeats can continue to monitor the PR or Slack thread after I leave. The unit of work is no longer "one prompt, one response," but rather a small operational loop.

Memory

Once threads persist over time, they need a shared memory that does not rely on a single codebase.

The key is not just to store message histories. While a long thread can certainly remember many things, if that useful information is not serialized to a persistent location, it will be trapped within the thread. The significance of a memory system is to transform what a thread has learned into a product that I can inspect, edit, diff against, and reuse.

Most of my long-lived threads start from an Obsidian vault:

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

At the top level, I keep an AGENTS.md directive that includes: when you have more insights about someone, progress on a project, or close a todo loop, update the corresponding page in the vault.

この vault は、エージェントが「居住」する場所であり、個々のプロジェクトとは独立しています。コードリポジトリはコードを保管しますが、vault は私の作業に関連するコンテキスト全体を保管します：人物、意思決定、未解決の問題、日々のメモ、プロジェクトの状態、およびスレッド間で失われやすい理解など。

この vault も GitHub リポジトリとして維持する予定です。これにより、2つの利点が得られます：

クラウドで実行できること；

diff がレビューのためのインターフェースになること。

エージェントが vault を更新する際、私は diff を読んで、どのコンテンツが重要で覚える価値があると考えているかを確認します。このレビュー手順は非常に重要です。私は継続的なスレッドが会話履歴の中でぼやけた「感覚」を静かに蓄積することを望んでいません。それよりも、実際に変更された内容を記述してほしいのです：この人が好むもの、このプロジェクトが待っていること、この決定が下されたこと、このサイクルが完了したこと。

これが私が記憶をファイル形式にしている理由でもあります。ファイルはエージェントに経験を圧縮して、スレッドから独立して存続できる形式にするよう促します。スレッドが消え、圧縮がひどくなり、または続けることが高くつくようになっても、有用な知識はそこに残ります。

この段階に達すると、トップスレッドはもはやチャットウィンドウのようではなく、異なる従業員が同じノートブックを読んでいるように見えます。

Codex には Settings ＞ Personalization ＞ Memories でファーストパーティのメモリ機能もあります。私はこれをローカルなリコールレイヤーと捉えています：安定した好み、繰り返しの作業フロー、プロジェクトの慣行、既知の落とし穴を記録するのに適していますが、リポジトリにコミットされた命令や明示的な vault の代わりにはなりません。Chronicle はここで特に興味深いです。画面のコンテキストを活用して記憶を構築するのに役立ちます。私はこれを真剣に利用したことがなく、ドキュメントには明確に「研究プレビュー機能であり、選択的に参加する必要がある」と記載されています。権限、速度制限、ヒントの挿入、暗号化されていないローカル記憶ファイルなど、様々な制約がありますが、方向性としては私が関心を持っているものに向かっています：仕事は構造化された記憶を残すべきであり、長いチャットログだけでなくなるべきです。

コンピューターとブラウザの使用

スレッドが記憶を持つと一番気になるのは、それがどこにアクセスできるかです。

私自身の理解では、最も有用な区別は次のとおりです：

$browser：私がチェックおよび注釈を付けたいローカルウェブページインタフェース用；

@chrome：ログイン済みブラウザのセッションおよび複数のタブに使用；

@computer：グラフィカルインターフェースでのみ完了できる作業用。

ローカルアプリを反復している場合は、$browser を使用したいと考えています。ログイン済みブラウザセッションで操作する必要がある場合は、@chrome を使用したいと考えています。特定のデスクトップアプリをクリックすることでのみタスクを完了する必要がある場合は、@computer が必要です。

私の仕事用コンピュータでは、Twitter ログインが Safari にあります。@computer にTwitterの読み取りを依頼すると、Safari を使用できなくなります。Agent が複数の認証済みタブを同時に使用し、かつ私が使用中のアプリケーション全体を引き継ぎたくない場合は、@chrome が適しています。

コネクタは、この機能を私の実際の作業の他の部分にも拡張しています。最もよく使用するのは $slack、$gmail、および $calendar です。多くの作業は、コードに変換される前に、Slack のスレッド、受信トレイ、およびカレンダーに最初に表示されるためです。

スキルを使用すると、繰り返し作業フローを再利用できます。Skill Creator と Skill Installer は良い出発点です。Skill Installer を使用すると、OpenAI が推奨するスキルをComposerから直接追加できます。Codex pets がリリースされた後、Hatch Pet スキルをインストールしましたが、真の価値はこの一般的なパターンにあります：一度有用なことを成功させると、通常はその作業をパッケージ化し、Codex に再度学習することなく再実行させることができます。

Work Forward

Remote Control

リモートコントロールにより、これらのより長い作業サイクルを携帯可能にします。

Codex は、すでにファイル、アクセス許可、およびローカル環境を持っているマシンで作業を続行し、あなたは進捗状況を確認したり、発見したものをレビューしたり、質問に回答したり、次のステップを承認したり、オフィスデスクに戻らずに方向転換したりすることができます。OpenAI は、これをCodexといつでもどこでも共同作業できる手段と説明しています。

長期間のタスクを実行しているCodexに推進力を保ちたい場合、これが非常に重要です。タスクを開始してから離れることができます。それが意思決定が必要な地点に到達したときに、携帯電話を使用して誘導することができます。

これは、トップスレッド、音声入力、そして Heartbeats が重要な理由と同じです：場所を移動しても作業が停止しません。スレッドは継続して実行でき、私はその次のステップを解除するのに十分な注意を払うだけです。

Heartbeats

トップスレッドは便利ですが、それらはまだ指示を待っています。Heartbeats により、それらは定期的に実行できます。

Heartbeat はスレッドのローカル自動化です。私は言うことができます: 「数時間ごとにこれをチェックしてください。」 すると、そのスレッドは自分自身のスケジュールを設定できます。スレッドには複数のスケジュールがあり、特定の条件が満たされるまで続行したり、時間とともに実行頻度を調整したりできます。

Chief of Staff

私の Chief of Staff スレッドは、30 分ごとに実行されます:

Slack と Gmail を 30 分ごとにチェックし、未読の重要なメッセージを確認します。
何が重要かを判断するのを助けます。
誰かが質問をした場合は、可能な限りその答えを調査し、私のためにドラフトを作成しますが、送信はしません。

Slack に戻ったとき、多くの返信はすでにドラフトにあります。送信する内容をまだ決めることができますが、最も手間のかかるコンテキスト収集は完了しています。

モニタリングフィードバック

同じパターンはレビューサイクルにも適用されます。Heartbeat は Google Docs のコメント、プルリクエストのコメント、または Slack の返信を監視し、フィードバックが現れた場合に作業を継続させます。

私のお気に入りの例の1つは、アニメーションプロジェクトから来ています。 Slack にビデオを投稿し、Codex に15分ごとにスレッドをチェックしてフィードバックがあるかどうかを確認させます。コメントがあれば、新しいバージョンをレンダリングし、そのスレッドに返信し、レビュアーにタグ付けします。 Slack はMCPサーバーではファイルをアップロードできないため、Agent は @computer を使用して「ファイルを追加」ボタンをクリックし、修正されたレンダリングファイルをアップロードします。

面白いのは、それが15分ごとに Slack をチェックすることだけでなく、このサイクルが複数のツール境界を越えている点です： Slack はフィードバックを収集するために使用され、Remotion はレンダリングに、@computer はアップロードに使用されています。 Heartbeats、コネクタ、およびコンピュータ操作が組み合わさると、それらは単独の機能ではなく、私がそこに座っていなくても継続して実行できるフィードバックループに変わります。

返金申請

最近、私はパッケージが盗まれました。Amazon は、リアルタイムのカスタマーサポートとの通話には約25分かかると言われました。そこで、@computer を指定してスレッドを作成し、それに次のように伝えました：

5分ごとにチェックし、サポートスタッフがこの会話に参加したかどうかを確認してください。
参加していれば、返金を取得するために最善を尽くしてください。
相手から返信があったら、1分ごとにチェック間隔を変更し、より速やかに応答できるようにしてください。

シャワーを浴びて出てくると、返金処理が完了していました。

私の多くの Heartbeats はまた、私の Obsidian ボルトを更新し、それを明示的なメモリとして使用します。

目標

私はまた、最新の機能である Goals をよりよく使用する方法を学んでいます。

それには、より野心的な目標を設定する必要があります。弱い目標は、「この Markdown ファイルの計画を実行する」です。一方、強力な目標には本物の成功基準があり、エージェントがそれに向かって持続的に進んでいけるようになっています。

先週、Python Rich ライブラリを Rust に移行しようとしました。元のプロジェクト自体には大規模な単体テストセットがあったため、次のような目標を設定しました：Rich を Rust に移行させるが、元の Python ライブラリのすべての単体テストに合格する必要があります。

このテストセットは、実行プロセスに本当の判断基準を提供しています：Rust バージョンは、Python 元ライブラリと同じテストを通過することでのみ完了と見なされます。

これは AI との長期間の対話を行い、Markdown プランを蓄積し、最終的に「それを実現する」と言うのとは異なります。実行効果の上限は、目標と検証方法にかかっており、検証のない野心は単なる願望に過ぎません。

AI が本当にワークフローに参入する

サイドパネル

Codex で最もワクワクしている機能は、サイドパネルです。

人々はこれを、起こっていることのプレビューとして簡単に捉えがちです。しかし、この理解はその価値を過小評価しています。サイドパネルは Codex がもはや単なるチャットアプリでなく、作業が行われる場所になり始めていることを示しています。

私にとって、それは3つのことを担当しています：製品のチェック、ウェブインターフェースの操作、変更のレビュー。これらのすべての場合において、私はエージェントが操作している同じオブジェクトを見ることができ、コメントすることができます。

検査対象

Markdown、スプレッドシート、CSV、PDF、およびスライドをここに配置できます。

Markdown にはコメントを追加できます。スプレッドシートには数式のレンダリングが可能で、セルの編集もサポートされています。Codex オープンソースプロジェクトの管理に使用します。CSV は元のテキストではなく表として表示されます。PDF は直接レンダリングされ、特に LaTeX には便利です。スライドも作成し、アプリを離れることなくレビューできます。

重要なのは Codex がこれらの対象を生成できるだけでなく、私がループを中断することなくそれらを検査および注釈できることです。

ウェブインターフェースの操作

アプリ内ブラウザはより面白いです。Agent はそれを見ることができ、$browser を介して JavaScript を使用して制御でき、私は自分が表示しているコンテンツに直接注釈を残すことができます。

私が現在この方法で頻繁に使用しているいくつかのウェブインターフェースがあります：

index.html、軽量静的な対象に使用；

Storybook、UI コンポーネントのレビューに使用；

Remotion Studio、プログラム化されたアニメーションに使用；

Slidev、プレゼンテーションに使用；

Streamlit、データアプリケーションに使用。

最小バージョンがしばしば最良です。モデルに JavaScript と CSS を含む単一ファイル index.html を作成させ、それをサイドパネルで開き、すぐに対話を開始できます。サーバーは不要です。私は常に時間とともに変化する静的 index.html を Heartbeats で試み、スレッドに戻るたびに新鮮な対象が待っているようにしています。

Thariq には、Markdown よりも出力形式として HTML を好む理由について素晴らしい記事があります。この直感は正しいと思います。出力が文書ではなく小さなアプリケーションになると、人と対象の間の関係が変わります。

より重いものが必要な場合は、Vite アプリケーションを使用することもできますが、その場合はサーバーを維持する必要があります。純粋な index.html の方がはるかに持続します。

アニメーションを行う際、私はしばしば Storybook と Remotion Studio を並行して開いています。Agent が私が見ている同じブラウザー状態をチェックでき、アニメーション内の現在のフレームを含むコメントを残すことができます。

プレゼンテーションを作成する際、私はよく Slidev を使用します。Codex はスライドをチェックし、切り捨てられたコンテンツを見つけ、ページ間を切り替え、私がレビューする際にアノテーションに応答します。

また、将来は Streamlit や Jupyter などのツールでもこのような方法がより便利になることを期待しています。異なる人々は本来、異なるアプリケーションで生活しています。Codex は彼らがいる場所にますます入り込んでいます。

場所が記憶、再訪、チェック、アクションを取ることができるようになればなるほど、私の仕事は一度のプロンプトごとに終わることが少なくなります。これこそが私が本当に心配している変化です：エージェントにコードを書かせるのではなく、私が去った後もさらに多くの作業が進行することです。

[Original Article]

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia