2 時間おきに、Codex がメールの返信案を作成してくれる。
草案のほとんどは良質だ。それでも私は修正を加える。
過去のスレッドや対面での会話で得た判断を追加したり、送信者が誰かを考慮してトーンを和らげたり、まだ果たす準備ができない約束を削除したりする。草案は上手く書かれているが、それでもなお凡庸に感じられることがある。あの凡庸さはよく「AI スロップ」と呼ばれるが、このケースでは問題は知能ではなく、欠落したコンテキストだ。
誰も悪くない。Codex は手元にある情報を基に作業し、私の編集は欠けていたコンテキストを補った。興味深いのは、その編集自体にもコンテキストが含まれている点だ。何を残し、何を変え、何を却下し、何を送信するのに抵抗があったか、その状況で何が重要だったかが明らかになる。
ほとんどの自動化は、そのコンテキストを保持しない。次回の実行も、同じ不完全な状態から始まる。
コンテキストは 2 つのカテゴリーで考えると便利だ。
1 つ目は、作業を始める前に必要なコンテキストだ。履歴、事実、制約、関係性、過去の判断が含まれる。
2 つ目は、作業後に明らかになるコンテキストだ。レビュー中に、人が何を残し、何を変更し、何を却下し、何を送信し、何を未処理のままにしたかである。
これにより、2 つのループが生まれる。インナーループは適切なコンテキストをタスクに取り込み、草案を作成する。アウターループはレビューから学習し、次回の作業実行時にそのコンテキストを利用可能にする。
コンテキストを作業に取り込むインナーループ
メールの場合、インナーループはメッセージに返信が必要かどうかを判断し、関連するコンテキストを見つけ、返信を草案し、その主張をチェックし、レビュー用のドラフトを作成する。
このワークフローは、コードで記述された、またはワークフロービルダーで構築された固定のワークフローで実現できる。メッセージを取得し、ノイズをフィルタリングし、分類し、草案し、結果をチェックする。あるいは、Codex に「毎朝 9 時に、返信が必要なメールの下書きを作成して」といったシンプルなプロンプトを与えるだけで、新しいスレッドを確認し、関連する履歴を復元し、不足している情報を調査し、返信を準備し、不明瞭な点を浮き彫りにする。
どちらのアプローチでも機能する。重要なのは、情報の取得が文章作成の一部であることだ。
返信は、類似のメール、6 ヶ月前の判断、プロジェクトトラッカーの最新ステータス、承認されたソースからの事実に依存する場合がある。Codex はそのコンテキストを収集するか、サブエージェントに特定の質問を調査するよう依頼できる。目的はすべてを取得することではなく、返信を正確かつ具体的にするための最小限の情報セットを見つけることだ。
アクションは元に戻せるようにしておく。下書きを作成し、決して送信しない。編集前に、インナーループは提案された返信、そのソース、そしてプロンプトと文章作成ガイダンスのバージョンを保存する。その記録がなければ、レビューは単なる逸話に過ぎない。記録があれば、レビューは証拠となる。
レビューからコンテキストを回収するアウターループ
アウターループは、私が下書きをレビューした後に開始される。その下書きは、変更されずに送信されたか、編集されて送信されたか、削除されたか、未処理のまま残されたか。
これらの結果は、それぞれ異なる意味を持つ。変更されずに送信された場合は、下書きが機能したことを示唆する。編集して送信された場合は、前後のペアが得られる。削除された下書きは解釈が難しい。的外れだったか、そもそも返信が不要だった可能性がある。未処理の下書きからはほとんどわからない。
送信されたメールに記録されるのは、私が何を受け入れたかだけで、返信が機能したかどうかではない。本当の結果は、その後の返信や作業に現れる可能性がある。それでも、レビューは下書き作成時には利用できなかった証拠を追加する。
下書きと送信バージョンの差分は証拠となる。それは自動的に教訓になるわけではなく、自動的にプロンプトの変更になるべきでもない。
冒頭が短くなっているのは、文章作成上の好みを示しているかもしれない。事実が追加されているのは、インナーループが間違った場所を検索したことを示しているかもしれない。約束が削除されているのは、ワークフローに必要なチェックを示しているかもしれない。段落が書き直されているのは、人間に委ねるべき判断を反映しているかもしれない。
差分は何が変わったかを示すことができる。その意味を理解することが、アウターループの本当の仕事だ。
アウターループがインナーループを改善する
アウターループは、次回のインナーループの実行をより良いものにするために存在する。
Codex の下書きと私が送信したバージョンの間で何が変わったかをレビューし、次に問う。Codex が最初からより良い結果を出せるようにするには、何があれば助けになっただろうか？
答えは、より良い文章作成ガイダンス、別の情報源、新しい検索ステップ、サポートされていない約束のチェック、あるいは私への早期の引き継ぎかもしれない。すべての編集がルールになるわけではない。アウターループはパターンを探し、最小限で有用な変更を提案し、私が何を残すかを決める。
実際には、承認された教訓はシンプルな Markdown ファイルに保存する。アウターループはそのファイルの更新を提案し、内部の自動化は次のメールを下書きする前にそれを読み込む。
これが、レビューがインナーループを改善する仕組みだ。今日私が修正したことは、明日の実行にとって有用なコンテキストとなる。
2 つのループ、2 つのクロック
ループは異なる速度で動作する。インナーループは迅速に、おそらく 2 時間おきに支援する。アウターループは十分な例が集まるのを待ち、1 日の終わり、10 件のレビュー済み下書きの後、または例が少ない場合は週 1 回実行する。
アウターループを頻繁に実行しすぎると、異常なケースから学習してしまうかもしれない。決して実行しなければ、有用な修正は次の下書きと共に消えてしまう。
同じパターンは、デッキ、レポート、ブリーフ、課題トリアージにも当てはまる。どのケースでも、ワークフローが両方の種類のコンテキスト（初回の下書き前にわかっていたことと、レビュー後に明らかになったこと）を活用できれば、作業は改善される。
モデルはすでに能力を備えている。チャンスは、毎回の実行で同じコンテキストを再発見させる必要のないワークフローを構築することにある。
インナーループは適切なコンテキストを作業に取り込む。アウターループは、作業によって明らかになったコンテキストを保持する。
