蔵書DBを棚卸しして専門書の抜けを洗い出し、簡易デューデリジェンス支援スキルを実装した

デューデリジェンスの本は、うちの蔵書データベースにどこまで入れてあっただろうか。 そう思って Claude Code に DB を当たらせた。 コアになる5冊は、財務側が3冊とビジネス側が2冊で、いずれも1ページ目から最終ページまで入っていた。 途中で止まっている本は1冊もなかった。

そこで終わりのはずだった。 ところが同じ報告の末尾に、後処理のクリーンアップが2冊で効いていない、と書いてあった。

周辺の本まで含めた棚卸し

コア5冊の話をしている間に、周辺の本が気になった。 デューデリジェンスそのものの本でなくても、隣接する分野の実務書は棚に何冊もあるはずだ。

最初に返ってきた数は明らかに少なかった。 検索語が狭かったからである。 M&A、買収、企業価値、バリュエーション、組織再編、事業承継、株式評価、投資ファンド、会社売却、MBO、再生まで語を広げて取り直してもらった。 すると取り込み済み15冊と未取り込み13冊が出てきた。 コア5冊を除いた周辺だけで見ると、取り込み済みが10冊、未取り込みが13冊になる。

蔵書PDFの一覧は、DB側のメタデータ1,333件が実質のマスタになっている。 だから「入っている / 入っていない」は、DBの状態そのものよりも、どんな語で当てにいくかで変わる。 未取り込み13冊は、最初の問い方では1冊も見えていなかった。

消えていた処理済みの印

別の作業をしていて、クリーンアップまで済ませたはずの本にバッジが付いていないのに気づいた。 以前は付いていたのを確認している。

供給元を追わせたら、バッジの実体はDBのカラムではなく、リポジトリの中に置いた処理履歴のファイルだった。 その履歴が .gitignore で丸ごと除外されていて、別のマシンで走らせた処理の記録が手元に届いていなかった。 書籍のデータ本体は無傷で、消えていたのは印だけである。

OCR結果と図版は引き続き除外したまま、履歴だけを追跡対象に戻した。 追跡されたのは4件。 このときは実家にいて、対象のマシンが事務所に置いてあったので、経緯と対応をメモにしてリモートへ押し込んでおいた。

OCRが本文に混ぜた柱

クリーンアップの中身は、ページ上部の柱とページ番号を本文から落とす処理である。 効いていなかった2冊を調べさせたら、柱の表記ゆれが2種類あった。 片方は行頭にページ番号がくっついた形で残っていて、既存の判定を素通りしていた。

削除候補は87種になった。 本文を巻き込んで消すのが一番こわいので、全部確かめてから流した。 本文の誤削除はゼロだった。 更新は76件で、残る3冊はもともとノイズがなく変更0件。 ノイズ42件を抱えていた1冊は0件になった。

途中、全文検索インデックスの再構築が10分でタイムアウトした。 検索自体は生きていた。 そこでインデックスの再構築を本処理から切り離し、残りをバックグラウンドでまとめて流した。

208万字の素材をどこまで削るか

スキルの設計材料として、各書籍の分量を実測してもらった。 コア5冊で148万字。 周辺9冊は、使えると判定したものだけで92万字あり、重複を除いても65万字残る。 素材の総量は208万字と出た。

全部を素材にするのは無理がある。 そこで使い手の側から決め直した。 用語の解説は要らない、手順だけでいい、報告書もスライドではなくHTMLのメモでいい。 この3つを伝えたら、素材は38.5万字まで落ちた。

計画書はいったん作ってから Codex にレビューさせて、致命的な指摘を4件受けて書き直した。 判断を仰ぐ項目はHTMLの決裁フォームに出したのだが、返ってきたコメントのほうが設計を大きく動かした。 財務側とビジネス側を分ける、質問リストとヒアリングのスキルを足す、推移テーブルを必須にする、重心をビジネス側に寄せる。 この4点を反映して計画書を仕上げ、コミットまで済ませた。

抽出した項目数が計画と合わない

設計が固まったので、そのまま実装フェーズに入った。 素材からチェック項目を抜き出す抽出器から手をつけたところ、最初の実行で件数が計画時の実測値と合わなかった。

原因は、行の折り返しをつなぐ処理が暴走して、後続の項目まで飲み込んでいたことだった。 素朴に数え直すと、BS 238、PL 80、CF 26、事業計画 14 で計画時の値と完全に一致した。 凝った前処理のほうが壊れていた。

数が合わない場面は、このあと3回続いた。

1つ目は、1ページに2科目が同居していた箇所である。 通し番号が1から7まで2周していて、片方が丸ごと落ちていた。 他のページも同じ疑いで確かめたら、そちらはOCRが表を分割しただけで通し番号は連続していた。

2つ目は、サブエージェントからの報告で見つかった。 「このページは実は14項目ある」と言うので自分で確かめたら、3列組みの表の2列目に入った項目を抽出器が丸ごと落としていた。 1ページだけで11項目の取りこぼしで、真の合計は369になった。 PLは80から91へ動いた。

3つ目も報告からで、「13項目ではなく25項目だ」という指摘だった。 これも正しかった。 「沿革」「経営戦略」のような短い項目名が長さのフィルタで落ち、本文が数字で始まる項目も別の条件で落ちていた。 計画書に書いた13項目のほうが間違いだったことになる。

素材の採用量は405,468字、不採用は2,567字で、行き先が決まっていない断片はゼロに揃った。

並列で書かせたリファレンスをどう受け取るか

科目ごとのリファレンスは、1本目だけ並列に出さず、手元で書かせて型を決めた。 表を6つ持つ構成にして、着眼点のマトリクスにあった「事業計画」の列もそのまま組み込んだ。 表が6つとも崩れていないのを自分の目で確かめてから、この型で通すと決めた。

残り13本は、共通仕様書を1本置いたうえで Sonnet 5 のサブエージェント13体に同じ形で書かせた。 並列で走っている間に、成果物として出すHTMLメモの雛形のほうを作った。 損益計算書とキャッシュフロー側の3本も続けて並列に出し、リファレンスは合わせて17本になった。

13本が出揃ってから、件数と構成を機械的に突き合わせる検算ツールを書かせた。 人が読んで確かめる方式では、13本が揃った時点で取りこぼしが出る。 検算には、出典として書かれたページが実在するかの確認も足した。

資料の依頼リストは178項目、うち必須36で仕上がった。 統合元の件数表記に1件ずれがあったので、そちらを実数に直した。

雛形のほうは、描画を見て不具合を1件見つけた。 冒頭のコメントの中に <!-- GUIDE --> と書いたせいでコメントが早く閉じてしまい、説明文がページの先頭に出ていた。

受入試験

リファレンス17本は構成が揃い、工程スキル13本も検算を通った。 最後に、スキルだけを頼りに動くエージェントへ架空企業のデータを渡して、メモを書かせた。 作った本人が使えば動くのは当たり前なので、それでは試験にならない。

メモは19,291字から24,593字まで埋まった。 報告を鵜呑みにせず自分で確かめたら、未記入のまま残っていたのは2件で、どちらも雛形冒頭の使い方コメントの中だった。 案件ファイルに残す性質のものではないので、雛形側の指示を直した。 試験で挙がった指摘のうち、実際の不備だった4件も直した。

成果物は新しいリポジトリ50ファイルにまとまった。 GitHub にプライベートリポジトリを作って押し込んだ。

検算ツール自体の穴

Codex のレビューが並行で返ってきて、検算ツールの穴を2件指摘された。 自分で裏を取ったら2件とも再現した。

偽陽性を潰したあと、中身の照合を足したら欠落を1件検出した。 確かめると、その項目は語順を変えてリファレンス側に存在していた。 自分が足したチェックの誤検出である。

順序に強い照合へ変え、類似度の分布を測ってから閾値を決めた。 中央値は1.00で、0.5を下回るのはOCRで解説文が混ざった1件だけだった。 ところが閾値方式では、単純に1項目抜けているケースを検出できない。 1対1の割り当てに変えたら、仕込んだ欠落を4件中4件とも拾えるようになった。 差し替えを見逃さないよう、弱い対応付けは警告として出す形にした。

検算3本が通ったところで、Codex の指摘と対応を計画書に記録した。 その晩、作ったばかりの資料依頼のスキルを、手元の実データで一度通してみた。

学び

• 「入っているつもり」は、DBの状態ではなく問い方で決まっていた。最初の検索語では未取り込み13冊が1冊も見えなかった
• 数が合わないときは、凝った前処理を疑って素朴に数え直すのが早い。折り返しをつなぐ処理が静かに後続を飲み込んでいた
• 検算ツールも検算の対象になる。Codex に穴を2件指摘され、両方とも再現した
• スキルの試験は、作った本人が使っても意味がない。スキルだけを頼りに動くエージェントに書かせると、雛形の指示の不備まで出てきた
• 処理済みの印が消えたのはデータの事故ではなく、履歴ファイルが同期されていなかっただけだった。印と実体を混同すると原因の探し方を間違える

明日やること

• 未取り込みの13冊から、次に取り込む本を決める
• 事務所のマシンで pull して、処理済みの印が揃うか確かめる
• 検算ツールの誤検出をゼロにする