5時間の制限に何度も当たった日、作業量ではなく渡し方を変えた
残りが7パーセントになった
財務諸表のQ&Aを28本、1日で書き切るつもりで朝から回していた。執筆者を並列で派遣して本文と図まで書かせ、別のエージェントに独立レビューを当てる。上がってきた指摘を裁定し、登録して描画を確認する。手順そのものは前日に固めてある。
先に尽きるのは、いつも親のほうだった。5時間の利用制限に何度もぶつかった。この日は表示を見たら残りが7%しかない。未着手のぶんは明日でいい。気になったのは、いま書かせている途中のものが消えないかどうかだけだった。聞くと、途中の成果はディスクに残るので再開すれば続けられるという。前日の停止と同じ運用だ。
新しい起動を止めて、台帳に現在の状態と再開手順を書かせた。28本のうち、登録まで終わったのは5本で、16本が未着手だった。止めたあとも、走っている執筆者は次々と上がってきた。制限の直前に届いたものもある。持ち越しになったのは、親のレビュー待ちが5本、書きかけが1本、未着手が16本。書けていないから進まないのではなく、書けたものを受け取りきれずに積み上がっていく形だった。
76パーセントが何に消えたのかを数えさせた
なぜこの作業で76%も使うのか。疑問のまま進めれば、次の枠でも同じところで止まる。別のセッションを開いて、消費の大きかったセッションのログそのものを渡し、中身を数えさせた。走っているほうには触らせない。
数えさせると、まずサブエージェントが容疑から外れた。
- サブエージェント18体の成果物が親に返したのは、全体の1.8%（11kトークン）だけだった
- いちばん食っていたのは、親が自分で回したBash。107回で291k、全体の46%
- 次が、親がサブエージェントへ渡した指示文。155kで24%
この2つで7割になる。書かせることではなく、渡すことと自分で確かめることに消えていた。1.8%を減らそうとして本数を削っていたら、遅くなるだけで何も直らない。
あわせて、親が記事1本あたりに使っている量をおよそ24kと見積もった。推定なので、根拠ごと context-log.csv に残してある。次に同じ話になったときに、記憶で議論しないためだ。
走っているセッションは止めずに直す
直すべき先はわかったが、その改善を効かせたい相手は、いままさに走っているセッションそのものである。走行中に手順書を差し替えれば、書きかけの記事のほうが壊れる。
そこで、改善は次のセッションから効かせることにした。計画書と手順書へ反映させるための引き継ぎプロンプトを、先に出させておく。反映先は、計画書の手順の隣に作る新しい節と、執筆者向けの手順書だ。記事本体と作業ディレクトリには触らせない、という条件も入れた。
長い指示は、渡さずに置いておく
共通の規約を人数ぶん配っていれば、指示文が155kに届くのも不思議ではない。そこで、執筆者に渡すプロンプトを短縮版へ切り替えた。1本あたり約6.2千字。従来よりかなり短い。
やったことは単純で、全員に共通する長い指示をファイルに置き、プロンプトにはそのパスと「特に厳守」の項目だけを書く形にした。エージェントは必要になった時点で自分で読みに行く。
読ませる内容は減っていない。読むコストの置き場所を、親から本人へ移しただけだ。この移動は、渡す相手が増えるほど効く。18体に同じ規約を配れば18回ぶん親が払うが、パスなら1回ぶんで済む。
全文ではなく、骨だけ読む
107回のBashには、上がってきた記事を自分で開いて読む操作も含まれていたはずだ。
レビュー用のスクリプトに --digest を実装させた。抜き出すのは、見出し、リード、各節の主張と要点表、数値例の表、図のテキスト、関連リンク。これで1本10〜12千字になる。本文の言い回しは落ちるが、論点の並びと数値の筋は残る。
落としたものと残したものの線引きは、親の仕事から決めた。親がやっているのは、言い回しの良し悪しを味わうことではない。論点が抜けていないか、数値が合っているか、図が本文と食い違っていないかを見ることだ。だとすれば骨で足りる。
直すところまで任せて、差分だけ見る
その107回には、指摘の反映も入っていただろう。
それまでは、独立レビュアーが出した指摘を親が読み、採否を決め、自分で本文を直していた。指摘の数は少なくない。第1陣の5本では89件が上がり、そのうち84件を採用している。これを親が全部抱えて直せば、それだけで記事1本を読むのと変わらない量になる。
そこで、反映作業そのものを、指摘を出した独立レビュアー自身に渡した。親は diff の変更行だけを見て、裁定にない変更が混ざっていないかを照合する。
任せる範囲を広げたのではない。確認の対象を「成果物」から「変更行」に狭めたのが効いた。読む量は減るのに、見落としたら困るところは全部目を通せる。裁定は相変わらず自分がやっている。この日も執筆者から、数値例の組み立てを指示と変えたという申告が1件上がってきた。記事全体の問いに正対する形になっていたので、そのままでよいと判断した。勝手な書き換えが混ざれば、差分に必ず出る。
終わりを先に決める
最後に、1枠あたり上限12本、使用率70%で締めると決めた。
止まる時刻を後から知るのと、先に決めておくのとでは、手元に残る状態が違う。7%まで削られた日は終わりを決めていなかったので、残量の数字を見ながら、巻き取りの手当てを慌ててやることになった。台帳への書き戻しも、執筆中のエージェントの扱いも、余力があるうちに済ませておけば数分で終わる。
Codexを、一度はやめようとした
途中で、Codexに一部を渡せばこちら側のコンテキストを節約できるのではないか、と考えた。言いながら気が変わった。Codexは細かすぎる。指摘の粒度が自分の求めているところより下にあって、読むほうが疲れる。節約のために使うのはやめておこう、と自分で取り下げた。
それでも、この日の計画書レビューではCodexを使った。3回かけて「通過」まで持っていった。毎日の執筆に混ぜたくないというのと、判断を1回きちんと叩いてもらうというのは、別の話だ。細かすぎるという性質は、計画書に向けたときには長所として働く。
折衷案が否定されたので、確定させなかった
改善のうち1項目で、折衷案を考えていた。レビューで否定された。
押し切って実装することもできた。やらなかった。計画書に「レビューで否定されたら実装を確定しない」という中断条件を書いてあるからだ。条件どおりに手を止め、案Aと案Bを並べて、判断としてこちらに戻させた。
自分で書いた中断条件が、自分の手を止めた。書いたときは形式的なつもりでいたが、実際に止まってみると、止まる仕組みがあるのとないのとでは違う。否定されたのは折衷案であって、案Aでも案Bでもない。中間で妥協した形だけが落ちたのだから、どちらかに倒すしかない。
選んだのは案Aだった。
出てきた引き継ぎを、そのまま受け取らない
案Aを決めたあと、朝に出させた引き継ぎプロンプトをもう一度見た。あれを書いた時点では、この日の修正がまだ入っていなかった。そのまま次のセッションに渡せば、決めたばかりのことが最初から抜ける。反映されているかを確認させた。
反映そのものは実物で確認が取れた。計画書の新しい節も、手順書に足したコンテキスト運用の8項目も、プロンプト生成スクリプトも、更新時刻付きで存在している。ただし、次のセッションで効いてくる食い違いが4点あった。
いちばん厄介だったのは、手順の一部に「読み込んだ内容をそのままエージェントへ渡す」書き方が残っていたことだ。これを残したまま走らせると、パスだけ渡すことにした意味が半分打ち消される。長い指示をファイルへ追い出したのに、渡す直前で親が読んでしまえば、結局は親のコンテキストに乗る。
4点を直させ、修正後の全文を出し直してもらった。改善を決めることと、次の自分に届くことは別の作業だ。届け先の文面を1回読み返さなければ、ここは素通りしていた。
決めたものを、置ける場所に全部置く
案Aの決定は、計画書の§4-6、手順書、プロンプト生成スクリプト build-prompts.mjs に反映させた。HTMLを再生成し、Chromeの前面タブをリロードして、見出しと表が崩れていないことを確認した。台帳の progress.md にも、新しい運用へ切り替えたことを追記した。
決定をやりとりの中にだけ置くと、次のセッションには残らない。プロンプトを生成しているスクリプトまで直して初めて、明日の自分が同じ判断をしなくて済む。この反映を進める実行モデルもOpus 5と指定してある。ここが暗黙のまま切り替わると、あとで原因を探すことになる。
今日の学び
- 上限に当たったとき最初に思いつくのは「量を減らす」だが、消えている先を数えるまでは減らす対象を選べない。この日の成果物は全体の1.8%で、削っても何も変わらない
- 消費の大きいセッションを調べるなら、そのセッション自身にやらせない。別のセッションを開いてログを渡せば、走っている作業を止めずに済む
- 読む量は、任せる範囲を広げなくても減らせる。確認の対象を成果物から変更行へ狭めるだけでいい
- 長い共通指示は渡さずに置いておき、パスだけ渡す。読ませる内容は変えずに、読むコストの置き場所を移せる
- 中断条件は、書いておくと本当に手を止める。書いていなければ、この日は折衷案をそのまま実装していた
- 決定は計画書だけでなく、それを実行するスクリプトと、次の自分へ渡す文面まで下ろす。翌朝に効くのはそちらのほうだ