コーデックス・マキシング（Codex-maxxing）

コーディングエージェントを積極的に活用していたのは、Codex の登場以前からでした。主にコーディングワークに特化したインターフェースを通じて利用しておりました：差分の作成、リポジトリの変更、コードのコミットなどです。そして今年 11 月あたりからは、知識工学的なタスクへの導入も始まりました。Slidev を用いたプレゼンテーションの作成や、音声入力を活用した「メモ取り」のようなエージェントの利用に加え、コーディングエージェントが出力可能な他のアーティファクト（index.html、PDF、スプレッドシート、スライド資料など）を探すようにしていました。最新の Codex アプリケーションへのアップグレードは、そのような広範な利用モードを「自然であるようなもの（native）」と感じさせる最初の試みです。Codex はコーディングタスクにおいては依然として優れているものの、より興味深い変化が生じています。それは、私の作業に「住まい」（すなわち定着場所）を提供してくれる点にあります。

私の行動を変えたのは、「仕事にオペレーティング・ループを与える」ことを学びました。具体的には、持続可能なスレッド（durable thread）、共有メモリ、私のコンピュータ上で動作できるツール、タスクを導き直し再開するための手段、そしてアーティファクトそのものを検証できる表面（surface）です。

持続可能なスレッド（Durable Threads）

私の行動を変えた第一の要因は「コンパクション（compaction）」でした。コンパクションとは、長期にわたるスレッドを圧縮し、過去のすべてのメッセージを完全に保持することなくも継続させ得る仕組みのことです。

現在、私が重視する重要なワークストリームごとにピン留めされたスレッドを維持しています：

• チーフ・オブ・スタッフスレッド
• Agents SDK
• OpenAI CLI
• オープンソース向けの Codex
• ツイッターの監視用スレッド（仅此一项）

これらは単発的な短い会話ではありません。数ヶ月以上にわたってコンパクションをかけながら成長を続けてきた「メガスレッド」です。これらには、歴史、嗜好、そして私が毎回再作成したくない過去の決定など、多くの情報が蓄積されています。

ピン留めされたスレッドへのショートカット

Command-1 から Command-9 の組み合わせで、ピン留めされたスレッドに直接ジャンプすることが可能です。ただし、ここでトレードオフが存在します。長期スレッドにはコストがかかります。後から見返す場合、会話がキャッシュから外れており、新しい短いスレッドよりもコストを掛かる可能性があります。しかし、私が重視するワークストリームにおいては、その連続性の価値は相応のものであり、投資に値します。

音声入力

音声入力を活用することで、Codex に対する私の実際の思考プロセスがより多く取り込まれるようになります。利点は速度ではなく、「編集されていない思考の生きた状態」をエージェントに伝えることにあるのです。Codex には内蔵の音声入力機能がありますが、私は Wispr Flow も併用しています。なぜなら、システム全体で音声認識を設定することで、他のすべてのツールへの文脈投入量も大きく変えるからです。

もしあるタスクを計画している際、「Slack の中に Ben という人物がこれを言っていた気がするけど、正確には覚えていないから調べて」といったように話してもかまいません。この文は入力するには曖昧で面倒ですが、話すことには極めて自然です。トランスクリプトについても同様です。ブログ記事を書く場合、誰かと電話をしたり録音したり、またはスマートフォン上の Granola を通じて対面で話した後にそのトランスクリプトを素材として活用できます。モデルが私の思考の「不器用なバージョン」にアクセスできるか、それとも整ったバージョンのみを与えられるかは、多くの計画の質を大きく変えます。

ガイド制御（Steering）

音声入力は、ガイド制御と組み合わせることでさらに有用になります。ガイド制御とは、Codex が既に作業を行なっている最中に、現在のステップが完了するのを待たずに追加の方向性を加える機能です。これによりツールコール後に次回のメッセージを注入できます。ウェブサイトをレビューしている場合、「これを小さくしてください」「このコピィは間違っていませんか」「これらの二つとの間隔がおかしいですね」「完了したら PR を作成してください」「プレビューデプロイを待ってください」「レビューが必要な Slack の担当者へプレビューリンクを送信してください」といったように、各ステップが終了するまで次の決定を待つ必要はありません。エージェントが作業を行っている間に意図を継続的に追加し、キューが形成された状態で退屈することができます。その後、Heartbeats が私が去った後も PR や Slack スレッドの監視を引き続き行います。仕事の単位はもはや「一つのプロンプトに対する一つの回答」から脱却し、「小型のオペレーティング・ループ」へと変化します。

メモリ

スレッドが長期化し始めた段階で、単一のリポジトリ以外の共有メモリが必要となりました。重要な点はそのメッセージ履歴を保存することだけでは不十分です。長期的なスレッドには多くのことを記憶させることができますが、その記憶はスレッドの内部に閉じ込められたままです。有用な部分をどこかに永続的にシリアライズ（系列化）しなかった限りです。メモリシステムの意義は、スレッドが学んだものを「確認でき、編集でき、差分を確認できて、再利用可能なアーティファクト」へと変換することにあります。

私の長期スレッドの多くは、Obsidian のvault で開始されます：

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

トップレベルでは、以下のような指示を含んだ

AGENTS.md

を保持しています。「人々に関する知識が増えたり、プロジェクトに進展を見せたり、未完了のループを閉じるたびに、vault 内の関連ページを更新してください」といった内容です。vault はエージェントが居住する場所であり、特定のプロジェクトとは分離されています。リポジトリはコードを格納しますが、vault は私の仕事を取り巻く動期的な文脈（人々、決定事項、未完了のループ、日々のノート、プロジェクトの状態、そしてスレッド間において失われがちな理解の断片など）を保持します。また、vault を GitHub リポジトリとしても管理しています。これによって得られるのは二つの恩恵です：クラウド上で動作可能であり、かつ差分（diff）をメモリのレビュー表面として利用できます。エージェントが vault を更新する際、私は差分を読み込み、「何について重要だと判断して記憶すべきだったか」を確認できます。このレビューのステップは重要です。常緑性のあるスレッドに静かに「雰囲気（vibes）」のみが会話履歴に蓄積されるのを許したくありません。変化を明確に書き記してもらいたいのです：この人物はこの点を好む、このプロジェクトはそのタスクを待機中、この決定がなされた、このループは閉じられた、など。これこそが、私はメモリを「ファイル」として管理したいと考えている理由です。ファイルは、エージェントに経験をスレッドを超えて生存できる形式へと圧縮することを強制します。スレッドが死滅したり、不適切に圧縮されたり、維持コストが高騰したりしても、有用な知識はそのまま残ります。そのような段階では、ピン留めされたスレッドはもはや「チャット」ではなく、「同じノートブックから読み書きする異なる労働者（ワーカー）」のように感じられます。

Codex にも、設定 > パーソナライゼーション > メモリ からアクセスできるファーストパーティのメモリ機能があります。私はこれを「ローカルな想起層」と捉えています。安定した嗜好、反復的なワークフロー、プロジェクト慣習、既知の落とし穴には有用ですが、チェックインされた指示書や明示的な vault の代替わりにはなりません。特に興味深いのは Chronicle です。これは最近の画面文脈を利用してメモリの構築を手助けできるためです。私はまだ本格的に使用していませんが、ドキュメントには権限、レート制限、プロンプト注入、暗号化されていないローカルメモリファイルなどに関する実際のトレードオフを伴う参加型リサーチプレビューであると明記されています。しかし、方向性の意味は同じです：仕事は単なる長いチャットスクリプトを残すのではなく、構造化されたメモリとして残すべきです。

共有メモリ

共有メモリとは、単一のチャットの外に保持された文脈を指します。例えば、 vault のノートなどで異なるスレッドが再利用可能なコンテンツです。

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

スレッドがメモリを持たせた段階で、次に問われるのは「何に触ることができるか」です。私の脳内では以下のような最も有用な区別があります：

• $browser

  ：検証および注釈付けしたいローカルのウェブ表面の場合

• @chrome

  ：サインイン済みブラウザの状態や複数のタブを扱う場合

• @computer

  ：GUI としての存在しかない仕事の場合

ローカルアプリの反復作業を行なっている場合は

$browser

を、ログイン済みのブラウザセッション内で作業を行う場合は

@chrome

を、タスクを実行するにはデスクトップアプリを通じてクリックする必要しかない場合は

@computer

を使用します。私の仕事用マシンでは Twitter が Safari でログインされています。もし

@computer

でその Twitter を読ませると、Safari が使用中に失われます。一方、エージェントが複数の認証済みタブを並列で使用しつつ、私が利用している全体のアプリアプライバーを取られることもなく機能する場合は、

@chrome

の方が適しています。コネクターはそのリーチを私の実際の仕事の領域へ拡張します。私が最も多く使用するのは

$slack

、

$gmail

、

$calendar

で、Slack スレッド、受信トレイ、カレンダーはコード化する以前に多くの仕事が現れる場所だからです。スキル（Skills）は反復的なワークフローの再利用可能化を可能にします。Skill Creator と Skill Installer が良い出発点となります。Skill Installer は、コンポーザーから直接 OpenAI 推奨のスキルを追加できます。Codex ペッツがリリースされた後、私は Hatch Pet スキルのインストールに使いましたが、有用なパターンの一般的なのは次の通りです：一度有用なことをやれば、再度 Codex に教えることなく、それをパッケージ化して繰り返せることが多いのです。

リモートコントロール

リモートコントロールによって、これらの長いループがポータブルになります。Codex はファイル、権限、ローカルセットアップがすでに存在するマシンから継続的に作業を続けながら、私はモバイル端末からチェックインし、見つけたものをレビューしたり、質問に答えたり、次のステップの承認をしたり、方向転換を行ったりできます。OpenAI はこれを「どこからでも Codex と働く方法」と説明していますが、これは Codex が既に長期にわたるタスクを実行している際に、モメンタムを維持したい場合に最も重要です。タスクを開始して退屈し、その後エージェントが意思決定の節目に達した時点ですmartphone からそれをガイドできます。これらが重要な理由は、ピン留めされたスレッド、音声入力、Heartbeats と同じです。仕事が場所が変わっただけで止まる必要はなくなります。スレッドは継続的に進行し、私は次の手掛かりを解除するために必要な注意の程度を保つことができます。

Heartbeats

ピン留めされたスレッドは有用ですが、私が何らかのアクションを起こすのを待っています。Heartbeats がそれを再発させる要素です。Heartbeat とはスレッド固有の自動化です。「数時間ごとにこのスレッドに目配りし続けてください」と指示を与え、スレッド自身がスケジュールを設定できます。スレッドには複数のスケジュールを持ち、ある条件が満たされるまで実行し、時間の経過とともにその頻度を調整することも可能です。

チーフ・オブ・スタッフ（Chief of Staff）

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

• 30 分ごとに Slack と Gmail をチェックして、私の注意が必要な未回答メッセージがないか確認する。
• 私にとって最も重要な優先順位を支援する。
• もし誰かが質問してきたら、可能な限り深く調査し返信草案を作成するが、送信は行わない。

Slack に戻ると、すでに返信のドラフトが待っていることがよくあります。私が送るかどうかを決定するのは私ですが、文脈を集めるという高コストな部分は既に完了しています。

フィードバックの監視

同様のパターンはレビューループでも機能します。Heartbeat は Google Docs のコメント、PR コメント、Slack への返信を監視し、フィードバックが到着するにつれて仕事を進め続けることができます。私の好きな例の一つはアニメーションプロジェクトからのものです。Slack に動画を投稿して Codex を 15 分ごとにチェックしてフィードバックを得るよう依頼し、コメントが届いたら新しいバージョンを再レンダリングしてスレッドに戻りレビュアーにタグ付けするというタスクでした。Slack MCP サーバーはファイルをアップロードできなかったため、エージェントは

@computer

を使って「ファイルを追加」ボタンを押して修正されたリンドを投稿しました。興味深いのは単に 15 分ごとに Slack をチェックした点だけではありません。ループがツール境界を超えていました：Slack でフィードバック、Remotion でレンダリング、

@computer

でアップロードです。ここで Heartbeats、コネクター、コンピュータ利用はもはや個別の機能のように感じられなくなります。それらが一体となって、私がそこにいるなくても続くフィードバックループとなります。

返金手続き

最近、荷物が盗難されました。Amazon に話しかけるのに約 25 分かかるだろうと言われたので、

@computer

を使ってスレッドを作成し、以下のように指示しました：

• 5 分ごとにカスタマーサポートエージェントがこのスレッドに参加していないか確認する。
• もし参加していたら、できる限り返金手続きを支援する。
• 彼らが返信したら、1 分ごとにチェックに切り替えることでより迅速に対応できるようにする。

シャワーから出た頃には返金が完了していました。私の Heartbeats の多くは、明示的なメモリとして Obsidian vault を更新しています。

ゴール

私が今も正しく使いこなす方法を学んでいる新しい機能は「Goals」です。Goals とは Codex が継続的に進められる真のゴールラインを持つ長期タスクです。それに対しては野心を应有のものにすべきです。弱いゴールとは「この Markdown ファイル内の計画を実装する」ことです。強いゴールには、エージェントが継続的に挑戦できる真の成功基準があります。先週、Python Rich ライブラリを Rust へ移行しようとした際、元のプロジェクトには大規模な単体テストスイートが存在したため、「Rich を Rust へ移行させるが、元のライブラリのすべての単体テストに合格しなければならない」といったゴールを設定できました。このテストスイートは実行の真のアローラム（神託）となり、Rust 側版が完了するのは Python ライブラリと同じテストをパスするまでと定義されました。これは AI と長い会話をし Markdown プランを積み上げ、最終的に「これを実装してください」と言うこととは異なります。実行の有効性は、与えられたゴールと検証に依存します。検証なしの野心は単なる願望に過ぎません。

サイドパネル

Codex で最もワクワクするのはサイドパネルです。これはプレビューが発生する場所と思われがちですが、それを過小評価しています。サイドパネルは Codex がチャットアプリであるだけでなく、「作業が行われる場所」へと変化し始めるポイントです。私には以下三つの役割を果たします：アーティファクトの検証、ウェブ表面の操作、変更のレビュー。これらすべてにおいて、エージェントが作用している同じオブジェクトを查看およびコメントできます。

アーティファクトの検証

Markdown、スプレッドシート、CSV、PDF、スライドはすべてそこに存在し得ます。Markdown は注釈付きです。スプレッドシートでは数式が評価されセル編集がサポートされており、私はこれを Codex オープンソース計画の管理に活用しています。CSV は生のテキストではなくテーブルとなります。PDF は直接レンダリングされており、LaTeX の場合は特に有用です。スライドはアプリから離れることなく作成および検証できます。重要なのは単に Codex がアーティファクトを生成できることではなく、ループを断ちながら検証および注釈付けができる点です。

ウェブ表面の操作

アプリ内のブラウザはさらに興味深いです。エージェントはそれを確認でき、

$browser

を通じて JavaScript で制御し、私が閲覧しているもの自体に注釈を残せます。現在これらを日常的に使用するウェブ表面には以下の通りです：

• index.html

  ：軽量な静的アーティファクト用
• Storybook：UI コンポーネントのレビュー用
• Remotion Studio：プログラムによるアニメーション用
• Slidev：プレゼンテーション用
• Streamlit：データアプリ用

最も小さいバージョンが往々にして最適です。モデルに JavaScript と CSS を含めた単一の

index.html

ファイルを生成し、サイドパネルで開いてすぐに操作を開始できます。サーバーは不要です。私は Heartbeats を使用して静的な

index.html

を時間とともに更新する実験も進めています。スレッドに戻った時点で既に新しいアーティファクトが待っているようにします。Thariq は HTML を出力形式として Markdown より優れているという良い投稿があります。その直感は正しいと思います。出力が単なるドキュメントではなく小型のアプリケーションになった時点で、関係性が変わります。より重いものが必要なら Vite アプリを使うこともできますが、その場合はサーバーを稼働させる必要があります。単純な

index.html

ははるかに耐久性があります。アニメーションワークでは Storybook と Remotion Studio を並べて開くことが多いです。「これをバウンスさせて」「これらはもう少し大きくするべき」といった注釈を残し、エージェントは私が閲覧しているブラウザ状態（アニメーションの現在のフレームを含む）を確認できます。プレゼンテーションについては Slidev をよく使います。Codex はスライドを検査し、切り取られたコンテンツを見つけ、スライド間で切り替え、私がレビュー中に注釈に応答できます。将来的には Streamlit や Jupyter などのツールでもさらに有用になると期待しています。異なる人々は異なるアプリ内に住んでいます。Codex はいずれもその場所で迎えることができるようになります。Codex が記憶し、再訪問し、検証し、行動できる場所が越多ほど、私の仕事はプロンプト間の空白で死んでいくことは減ります。それが私が重視する変化です。エージェントが私にとってコードを書くことではなく、私が去った後も多くの仕事が継続的に動いてくれることです。