財務諸表Q&A 28本を並列サブエージェントで1日に書き切る。自分に残ったのは裁定と照合だった

28本をまとめて片付けると決めた

前の区切りで17本を書き終えて中身を眺めたとき、おおむね良さそうだったので、次は「損益計算書と利益」の28本を一気にやると決めた。そのとき自分で口に出したのは「5時間の制限に引っかかる気がする」の一言だけで、対策は何も決めていない。引き継ぎプロンプトだけ出させて、その日は閉じた。

実際には3回引っかかった。それでも日が終わるまでに28本の執筆が全部終わり、24本を一覧への登録まで持っていった。残り4本のうち3本は、レビューの反映と差分照合まで済んでいて、登録と描画確認だけが残っている。もう1本は独立レビュー待ちである。

本文を書いたのは自分ではない。執筆も独立レビューも general-purpose を model:"opus" で起動して任せた。並列は上限5体。1本あたりの分量は本文6,300〜9,300字、論点6つ、図2〜3枚で、これを28回まわした。では自分は朝から晩まで何をしていたのか。

1本が一覧に並ぶまでに8つの工程がある

8つのうち5つが自分の手元にある。しかも、いちばん時間のかかる執筆だけがエージェント側にある。並列を5体まで上げると、詰まる場所は自分のほうに移る。

指摘を裁く

独立レビューは1本あたり11件から20件の指摘を返してきた。ほとんどは全件採用で、不採用にしたのは数件しかない。

拾ってもらって助かったのは、読者が読み違える書き方をしている箇所だった。値下げを数量で埋めたときの差は、営業利益率ではなく1個あたりの限界利益で決まる。赤字に落ちたあとの目減りの速さも、倍率ではなく限界利益率で決まる。「この行に入るのは所得にかかる税金だけ」と3箇所で言い切っていたが、住民税の均等割は同じ行に入る。「期の途中では計算できない」と書いていたが、仮決算による中間申告がある。どれも指摘されるまで気づかなかった。

不採用にした2件は、記事1本だけを見れば正しい指摘だった。1つは「自作の数値例」という表記を言い換えてはどうか、という提案だ。ただしこの表記は、登録済み9本と図の生成元33本が使っているシリーズ全体の書き方なので、この記事だけ変えるわけにはいかない。レビュアーには訂正を送った。もう1つは別記事へのリンク切れの指摘で、そのリンク先は同じバッチでまさに執筆中だった。

バッチ全体と、すでに登録した分を知っている側でないと裁けない。1本しか見ていないレビュアーには渡せない判断だった。

執筆者のほうから申告が上がってきたこともある。指示した「売上が同じ2社」という数値例を、「売上高が3倍違う2社で、大きいほうの営業利益が小さい」に変えたという報告だった。理由は、同じ組み立てを別の1本がすでに持っているからだという。統合問の「たくさん売れていれば儲かっているの？」に正対する形になるので、そのままでよいと裁定した。

数値と差分を突き合わせる

親レビューでやるのは、機械チェックと数値例の再計算と factcheck への記入の3つである。真ん中がいちばん手間だった。

在庫評価の3方法（先入先出、移動平均、総平均）をそれぞれなぞらせる。48,000円を12か月に配分して当期16,000円、期末の契約負債32,000円になることを確かめる。3期分を通した売上原価の合計8,400万円が、在庫の置き方によらず同じ額に着地することまで追う。税抜方式と税込方式で利益が同じ320万円になることを見る。書いた本人でない側で一度なぞり直さないと、数字の整合はどこかで崩れる。

反映が戻ってきたら、今度は差分を見る。裁定した指摘だけが当たっているか、裁定していない変更が混ざっていないかを確認する。ある1本では HTML 14箇所と図の生成元3行が動いていて、裁定にない変更はなかった。この照合を省くと、レビュアーが「ついでに」直した箇所が誰のレビューも通らないまま公開される。

画面を見る

登録したら dev で描画を確認する。見るのは横のはみ出しと、図のテキストの重なりと、コンソールエラーの3つである。この工程で実際に2件つかまえた。

1本目は図3でテキストの領域が2箇所重なっていた。生成元の片方のブロックを8px 下げて図を作り直し、重なり0を実測してから完了にした。2本目は図3の行ラベルと注記が5箇所重なった。こちらは行の高さを32から40へ、ピッチを40から48へ、図全体の高さを344から384へ広げて作り直した。

表の横スクロール枠の付け忘れも何本かで出た。ある記事は表8枚のうち7枚が枠なしで、別の記事では4枚が枠なしだった。自分で囲み直した。

途中、頼んでもいないプレビュー描画をレビュアーの1体にやられ、256kを飛ばされたことがあった。以後、手順書に「描画確認は親が行う」と明記した。見るのは自分の目でいい。

止めどきを決める

セッション制限には当日3回当たった。午前に5体がまとめて止まったときはリセットが10:10で、もう一度は11:48に2体が止まってリセットが15:10だった。

止まったときの手順は決めてある。再試行しない。途中成果がディスクに残っていることを確認して、台帳の progress.md に現在の状態と再開手順を書いて止める。前日の16:50に止めたときも同じ形だった。自分でも「未着手はいいんすけど、執筆中のやつがちゃんと残ればいいかな」と言っていた。確かめたいのはそこだけである。

再開は、同じエージェントに SendMessage で続きから頼む。会話の文脈が残っているので、新しく起動し直すより安く済む。10:20 に5体をこの形で再開して、5本ともその日のうちに登録まで終えた。

制限が明けたとき、判断がもう1つあった。途中だった5本はそのセッションで仕上げ、未着手の10本は新しいセッションに引き継ぐ。1つのセッションに全部を抱えさせない。

途中で運用のほうを直した

朝のセッションで、自分のコンテキスト消費が多すぎると感じた。実測は、執筆者が1本あたり中央値でおよそ412k、独立レビューがおよそ200k、反映がおよそ30kだった。親の側は1本あたり約24kで、11本を終えた時点の使用率は43%と推定した。

レビューを Codex に出せば自分のコンテキストを節約できるのではないかとも考えたが、Codex のレビューは細かすぎるので記事には使わないことにした。使ったのは計画書と手順書のほうで、3回見てもらって通した。ただし折衷案の1つは否定されたので、実装を確定せずに案Aと案Bを並べさせ、自分で案Aを選んだ。選んだ案は計画書の該当節と手順書と build-prompts.mjs（1本あたり約6.2千字のプロンプト）に反映させた。

締めようとしたら、まだ3体動いていた

その日を締めるつもりでいたら、サブエージェントがまだ動いているのが見えた。2分前と3分前に始まったものもある。何かと聞いたら、独立レビュアー3体のうち、裁定済みの指摘を記事に当てる第2段階に入った分だという。1本はその場で終わり、17件反映、規約違反0、図の変更なしだった。

残る2体は書き途中だったので、終わらせてから締めることにした。ここで閉じても、裁定した指摘の一覧は作業ディレクトリに残してあるから、次のセッションで当て直せる。ただ、当て直すより待つほうが安い。1本は11件で、裁定外の変更はなく、図も無変更だった。差分を照合してコミットした。最後に、作業ツリーがクリーンで動いているエージェントが無いことを確認して終わった。

分担

書くのはエージェントだと分かってはいたが、1日まわしてみると、自分の手元に残った仕事は5つに絞られていた。指摘を裁くこと。数値例をなぞり直すこと。差分から裁定外の変更を見つけること。画面を見ること。止めどきを決めること。

どれも、「正しいかどうか」ではなく「ここではどうするか」を決める仕事である。記事1本の中だけを見ていては決められない。登録済み9本と図の生成元33本が使っている表記を知らなければ言い換え提案を断れないし、同じバッチで何が書かれている最中かを知らなければリンク切れの指摘を退けられない。

並列を5体に増やしても1日で28本だったのは、エージェントが遅いからではないだろう。この5つが1人ぶんしかないからだと思う。次に「一気にやりましょうか」と言うときは、そこを数えてから言う。