PDFの研修教材を講義ノートにする計画を立て、図と表を別セッションに切り出した

開発eurekapu-nuxt4

PDFの研修教材を講義ノートにする計画を立て、図と表を別セッションに切り出した

税務の公的研修教材が Turso に3年分入っている。 そのうち最新年度分を、サイトの講義ノートにしたかった。 テキストはもう DB にあるのだから、あとは並べるだけだろうと思っていた。

引っかかったのは一点だけだった。 元がPDFなので、読み手が触れる場所がどこにもない。

既存の講義ノートに寄せる

いま公開している講座はミラーカラムレイアウトで作ってある。 新しい講座もその隣に並べたかったので、同じ作りに寄せる前提で実装計画を書かせた。

分野の切り方では迷わなかった。 講本は分野ごとに冊が分かれているので、その章立てをそのまま講座の分野にすればいい。 迷ったのは講座の名前のほうだった。 会計や簿記と一緒にするか、税務だけ独立させるかを口に出しながら決めた。 分けた。

計画書は本文とパイプライン図と判断事項の3点で出させた。 自分に見せる前に Codex のレビューを通させ、4巡目で承認が出た。 途中で1回、接続を拒否されて止まった。

指摘のうち1件は、自分で気づいていなかったものだった。 下書き状態の講座は、デプロイのときにJSONがビルド成果物から削除される。 下書きのまま置く前提で組んでいたので、気づかなければ本番でデータだけが無い状態になっていた。

判断事項は3件に絞って、決裁フォームで答えた。 表示を確かめている途中でローカルのサーバーが落ちたので、立て直させてから見直した。 リスク表の1行目に古い方針が残っていたのも、そこで見つけて直させた。

図の工数が読めないので、順番を入れ替えた

計画が固まったあとで、順番のほうを変えた。

図の作り直しにどれだけかかるか、この時点では見当がつかなかった。 図は8冊で348枚ある(この時点の数え上げで、実作業に入ってからは346枚に落ち着いた)。 全部をSVGに起こすのか、崩れているものだけ直すのか、原図のままで通るものがどれくらいあるのか。 数える手がかりがなかった。

そこで、図だけを先に切り出すことにした。 修正前を原図のPNG、修正後をSVGにして並べる。 8冊ぶんをミラーカラムで一覧できる作業用のギャラリーを、最初に作ることにした。 どの図をどこまで作るかは、並べてみないと決まらない。 その基準を決めること自体を、このフェーズの成果物にした。

法改正のリスクは優先度を下げた。 使うのは最新年度版なので、当面は古くならない。

フェーズは、基盤、図のギャラリー、最小公開、リライト、機能追加の順に組み直した。

実装に入って最初に出た穴

「サブエージェントをうまく使いながら」と添えて実装を始めさせた。

抽出スクリプトと共有モジュールを書かせた。 ビルド側には、節を切る仕組みと、外部リンクに target と rel を自動で付ける処理を入れた。 利用規約を確認させたところ、出典のURLは冊ごとの当該ページを指すのが正しいとわかったので、そこも直させた。 第三者の権利が絡む素材の全冊スキャンは、サブエージェントに委譲して台帳へ反映させた。

レビューは Codex のサブエージェントと code-reviewer の2系統に投げた。 出てきた8件のうち1件が、サニタイザの抜け穴だった。 OCRのテキストをHTMLに流し込む経路なので、ここが抜けているとXSSが通る。 テストは3,218本が通った。

OCR由来の壊れも、目で探すのをやめて機械側へ寄せた。 表の崩れを検出する検査をビルドに足し、本文に紛れ込んだページ見出しの重複は一括で落とさせた。

「第1節と第2節を分けて。全部」

できあがった画面を見て、いったん止めた。 1つのトピックの中に、第1節と第2節が同居していた。 節が別なら、トピックも別で並んでいてほしい。 ここだけの話ではなく、第1章から第8章まで全部そうしてくれ、と伝えた。

原因は、チャンクの切れ目が節の切れ目と合っていないことだった。 節の見出しは本文の中にちゃんとある。 ところがチャンクは節をまたいでいて、前の節の続きから始まるかたまりに次の節の名前が付いていた。 その名前だけを見てトピックを並べていたので、粒度がずれていた。

直し方を変えさせた。 章のテキストを一度つないでから、節見出しで切り直す。 節が中黒で連なっているケースも、分割の対象に含めた。 見出しの照合は、読点が半角カンマになっている箇所で外れていたので、正規化を強くさせた。

入門にあたる1冊は、全10章56節がそれぞれ独立したトピックとして並ぶようになった。 テストは3,225本まで増えて、全部通った。

表は構造化データを正本にする

表のほうは、もっと壊れていた。 数字がカンマのあとで割れて、137, 527 のように空白が入っていた。 行と列の対応も原本と違っていた。

OCRの出力を手で直していく方針は取らなかった。 表を構造化したJSONを正本に置いて、そこからHTMLの表と検算用のExcelとテストの3つを生成する形にした。 合計の合わない表があればビルドを止める。

最初の1つは原本とOCRの両方を突き合わせて作らせ、大きいほうはサブエージェントに委譲した。 Excelまで出させたのは、数式で自分の手でも確かめたかったからだ。

渡し方でつまずいた

ここまでで、セッションが長くなりすぎた。 図の細かい直しは別のセッションでやるつもりだったので、先に進捗をドキュメントにしてもらった。 現状のまとめと、図の作業ガイドと、表の作業ガイドの3本になった。

問題は渡し方だった。 スキルを使えばブラウザ経由で新しいセッションを開けるはずなので、2つとも投げてくれと頼んだ。 これが通らない。 9222 番のポートが開かず、Chrome DevTools からは繋がらなかった。 拡張経由に切り替えたら、今度はタブの状態で既知のエラーが出た。

途中でやめた。 指示もコンテキストも大きいので、渡す仕組みと格闘しているほうが時間を食う。 ターミナルにプロンプトを出してもらって、自分でコピーして貼ればいい。

出てきたのは2本で、図のSVG化と、表の構造化だった。 触るファイルが分かれているので、並行して走らせて大丈夫だという確認も取った。

計画を作りはじめた時点では、作業が3つに割れるとは思っていなかった。 並べるだけで済むと踏んでいたぶんが、図と表の2本になって戻ってきた。

残ったもの

  • どの図をどこまでSVGに起こすかの基準。並べてみないと決まらないので、ギャラリー側の宿題として残した
  • 表は最初の2つが検算付きで出せるところまで。残りの冊はこれから
  • ブラウザ経由で別セッションへ指示を投げる経路。今回は手でコピーして回避したままにしてある