サブエージェント5体に138節を分担させて、自炊した教材の作業用ドラフトを仕上げた

朝いちばんに、図のビフォーアフターを見比べるページを開いた。

自炊した教材の原図と、描き直させた候補のSVGが並んでいる。 1枚ずつ見て、候補のほうでほぼ全部いい、と思った。 原図に戻す理由が見つからない図が続く。 そこで採用をいったん確定させることにした。

気になったのは2件だけだった。 バッジが乗る位置が1件と、区分の並びが1件。 どちらもその場で直させて、コミットの前に未追跡のファイルを確かめさせた。 市販本の原図をgitへ入れてしまわないためだ。 学習ゲートがコミットを止めたので、今日はスキップして通した。

読める形に写しておきたかった本文

図が決まると、次は差し込み先の教材へ足していくフェーズになる。 その手前で、本文のほうへ手を伸ばした。

2冊とも、市販の本をスキャンして起こしたものだ。 公開する予定はない。 そのうえで、作業用のテキストをまるごと作ってくれないか、と頼んだ。 本文をdevに写し、原図があった位置に候補のSVGを差し替えて、そのまま読める状態にする。

レビューを途中でAstraに乗り換えた

計画書はいつもの手順で書かせ、レビューをCodex（gpt-5.6-sol）に投げた。 1周目で指摘が2件返ってきた。 反映して2周目を回し、判断が要る2件を3択の決裁フォームに立てさせた。 ここまでは普段どおりだ。

ちょうどそこへ、ChatGPT側にAstraというモデルが出た。 レビューをそちらでやり直したくなった。

gpt-6-astra はCodex CLIでそのまま疎通した。 設定ファイルの既定モデルにも、いつのまにかなっていた。 ついでに計画レビューの手順書の既定モデルも書き換えさせておいた。

Astraの指摘は、当たる場所が違った。 1周目は、統合された図の採否をどのキーに持たせるかという設計の話だった。 同じ図が本文の複数の位置に出るとき、採否は1つのレコードを共有する。 その採否を終端のキーへ集約して保存する形に、計画の該当節と実装フェーズを書き直した。 2周目は、統合された写しのほうにも採否を持たせると同期のゲートで落ちる、という指摘だった。 これも反映して3周目を回した。

同じ計画書に2つのモデルを当てたので、指摘の傾向を比べたメモを別に残させた。

スクリーンショット1枚で返した4つの注文

実装はPhase T1からT3までの3つに分けてあった。 一通り作らせて、2冊とも、本文が読めて図の位置に候補が出る状態になった。

開いてみると、直したい点が4つ出てきた。 画面を撮って、そのまま渡した。

左のペインは他のコンテンツと同じMillerカラムレイアウトにしたい。 右には目次を入れたい。 矢印の表記が崩れている。 そして、本文を全部、文章として読める形に変換してほしい。

最後の1つが重いのはわかっていた。 OCRから起こしたテキストなので、矢印や記号が地の文に散らばったままになっている。 読み進めると、そのたびに目が引っかかる。 しかも2冊ぶんの全節が対象になる。 サブエージェントをうまく使ってほしい、Sonnetでもいい、と付け足した。

138節を5体に分ける

レイアウトの作り直しはその場で片付けさせて、本文の整形はサブエージェント5体（Sonnet）に投げた。 138節を5体に分担させ、各体には整形したファイルを書いて検査を回すところまでやらせる。 別セッションに渡す案もあったが、この形ならセッションのコンテキストはほとんど増えない。

合格数は担当の報告を足し算するだけにせず、親のセッションでも検査を回させて数えさせた。

最初に返ってきた担当の29節は全件合格だった。 その時点の全体は、1冊目が80節中44節、2冊目が58節中41節で、不合格が1件残っていた。 次の担当の26節も全件通り、残っていた不合格の1件も直っていた。 3体目の27節が通ったところで不合格は0になり、1冊目は68節まで進んだ。 最後は1冊目の80節がすべて通り、2冊目も残り3節が片付いて、138節が全部合格になった。

整えた本文を既定にする変更を11ファイルぶんコミットして、origin/mainへプッシュした。 Cloudflareへのビルドとデプロイはバックグラウンドに回した。 6分か7分かかるので、そのあいだに次の作業へ移った。

ルビが13語で止まった

振り仮名は仕組みを先に実装してから、変換そのものをまた5体に回した。

1周目は5体とも完了した。 変換できたのは合計13語だった。 1冊目が6語、2冊目が7語。

2冊ぶんの全節が対象で、この数はどう見ても少ない。

担当からの報告で理由がわかった。 OCRは、読みを必ずしも漢字の直前には落としていない。 脚注記号やかぎ括弧、番号見出しを挟んだ位置に置いていることがある。 漢字の直後に落ちていることもある。 1周目の検査は漢字の直前しか読みとして認めていなかったので、それ以外は全部こぼれていた。 13語は、担当の腕ではなく、こちらが渡した検査の条件を映した数字だった。 5体に同じ検査を配ったので、その狭さも5体ぶんそのまま効いていた。

検査を広げた。 読みは漢字の前でも後ろでもよい。 あいだに空白、改行、番号、脚注記号、開き括弧が挟まってもよい。 そのぶんのテストを足して、同じ分担で2周目の5体を投入した。 読みが漢字の語の途中に割り込んでいる型だけは、今回も対象外にした。

2周目で報告が返ってきた4体の追加は、3語、3語、0語、0語だった。 広げても大きくは増えなかった。 ある担当の報告では、変換できなかった読みが21件あった。 内訳は、読みと語が離れているものが16件、語の途中に割り込むものが3件、読み自体がOCRで欠けているものが2件だった。 残りは、今回広げた範囲の外にある。 2周でいったん止めてコミットした。

開いたままにしておく必要のなかった欄

Cloudflareのデプロイはルビを回しているあいだに終わり、Workerバンドルの残り容量と本番の反映を確かめさせた。

その少し前に、図の下に付けさせた差し込みメモの欄を撮って渡してあった。 採否を未判断か採用か不採用かで選び、差し込み先の章と節、入れる位置、メモを書く。 そうやって採用台帳へ1図ずつ入れていく欄だ。 統合された図には、同じ図が別の位置にも出るという注記が付く。

画面だけ渡したので、どこを直したいのか聞き返された。 注文は1つだけだった。 クリックで開く形にしてほしい。

理由も一緒に伝えた。 この欄に書いて渡すことは、たぶんそんなに多くない。 直接言うほうが早い。 それなら畳んでおいて、要るときだけ開けばいい。

そこに書き込む頻度を先に見積もっていれば、最初から畳んで作らせていたはずだった。

今日の学び

• サブエージェントに検査まで回させるなら、渡した検査の条件がそのまま人数ぶん効く。13語で止まったのは担当の腕ではなく、こちらの検査が狭かったからだった
• OCRのテキストでは、読みが漢字の直前にあるとは限らない。脚注記号やかぎ括弧、番号見出しを挟んだ位置や、漢字の直後にも落ちる
• 合格数は担当の報告を数えるのではなく、親のセッションでも検査を回させて突き合わせる
• 計画書のレビューはモデルを替えると当たる場所が変わる。同じ計画書に2つ当てて、比べたメモを残しておいた
• 入力欄を足すときは、そこに書き込む頻度を先に見積もる。毎回開いておく必要のない欄は畳んでおく