会計学習ノート全26章の抜本見直しと連結精算表コンテンツの総点検

今日は eurekapu-nuxt4 のコンテンツに2方向からメスを入れた。午前は連結精算表コンテンツの全論点バグチェック、午後はドキュメント作成の専門書から生成したスキルを使って、会計入門レベルの学習ノート全26章を抜本見直しする計画づくり。計画は承認して次セッションに引き継ぎ、そのまま全章の改稿まで走り切った。

午前: 連結精算表の全論点を総点検する

/consolidated-worksheet/ 配下には論点ページが積み上がっている。取得1〜5、売却1〜5、段階取得、持分法、連結除外——数えたら19論点。これだけあると「どこかに仕訳のバグが眠っているのでは」という不安が消えない。そこで Claude Code に全数チェックを頼んだ。観点は4つ。

そもそもバグが入っていないか
適切にテストコードが書かれているか
テストを全てパスしているか
テストが妥当か（パスしていても保証になっていないケースがないか）

構成とテストの所在を把握させてから、ロジックレビューとテスト実行を並列で進めてもらった。結果、テスト6,333件は全てパスしているのに、実バグ3件が出てきた。うち1件は仕訳の貸借不一致。最重要は「売却・税効果あり」の開始仕訳で、税効果なし版の金額が混入して表示額が誤っていた。

テストが全部グリーンなのにバグが3件。つまり「テストがパスしている」と「コンテンツが正しい」は別物だった。テストの保証漏れも同時に見つかったので、修正とあわせてリグレッションテストを123件追加してもらった。配当まわりは設計意図を先に確認させてから前提文を直す、という順序で進めてもらったのが効いて、year1/year2 の5,894件も崩れずに通った。

ついでに全体スイートの失敗4件も「あるべき状態」へ

連結関連を直したついでに全体テストを回すと、4件が落ちていた。blog のID連番テスト、DRAM分類データ、GAAP系の2件。自分の変更起因ではなく既存の失敗だったが、「成功するように直す」のではなく「あるべき状態に直しておいて」と頼んだ。テストを黙らせるのではなく、データとテストのどちらが正しいかを判断して正しい側に寄せる、という意味だ。

原因はそれぞれ別物だった。dramTaxonomy のデータ修正、GAAPデータの既存キー整合、ID連番テストのタイムアウト対策。最終的に全体スイート16,483件・88ファイルが全てグリーンになった。積み残しを確認すると「緊急度の高いものはゼロ、軽微な未対応のみ」との報告。午前はここで区切った。

午後: 学習ノート全26章を見直す計画を立てる

次は学習ノートの番。会計入門レベルの学習ノートが全26章あって、解説の品質は章ごとにバラつきがある。これを、ドキュメント作成の専門書から生成した doc-communication スキルに従って、構造から解説まで一旦抜本的に見直したい。

ただしいきなり書き換えさせない。まず「どういう計画になるか」をマークダウンで出させて、自分が確認してから動かす。計画書は Codex レビューを通したうえで memo/2026-06-10/ に出てきた。診断が面白かった。

26章は個別の品質が高い一方、「章をまたぐ設計」が存在しないことが最大の問題

各章は単体ではよく書けているのに、コース全体の設計図がない。だから章を1本ずつ直す前に、執筆ガイドライン・横断概念マップ・章間参照表を先に確定する計画になっていた。

方針確認: 演習は全問掲載、組み替えは抜本的でいい

計画v1を読んで、3点だけ方針を返した。

公開ステータスはドラフトのまま（管理者のみ閲覧）でいい
演習章は「サンプル＋演習」ではなく全問掲載で自己完結にする
修正の深さは遠慮しなくていい。抜本的に組み替えて構わない。ただし doc-communication スキルにきちんと従うこと

この返答を受けて計画はv2に全面改訂された。最大の変更は、各章を「論点の説明記事」から「1章=1つの問題解決ドキュメント」へ作り替えること。スキルの制作4手順（ストーリー→構成→図表→全体調整）を、章単位の制作プロセスとしてそのまま採用する形になった。Codex の再レビューも通したうえで「OK、いいんじゃないでしょうか」と承認した。

引き継ぎプロンプトを発行して、次セッションで実行

ここでセッションを区切った。26章の改稿は長丁場になるので、計画セッションと実行セッションを分ける。計画書のステータスを「承認済み」に更新させて、次セッションの冒頭に貼る引き継ぎプロンプトを出してもらった。

実行セッションでは、引き継ぎプロンプトを貼っただけで計画書とスキルの読み込みから始まった。流れはこうなった。

Phase 0: 8エージェント並列で全26章を精読、分析成果物4本を memo/ に保存。本文は一切書き換えず、自分のレビュー待ちで停止
Phase 1: パイロット2章（減価償却・決算整理）で例題を4段型に改稿。型拡張とコンポーネント対応も実施。テスト1,836件グリーンを確認してから自分が画面でレビュー
Phase 2: 承認後、バッチ単位で横展開。バッチ内は並列で進めて全27章の改稿完了

途中、演習ページについて追加の指示も出した。既存に /quiz/practice というクイズ練習ページがあり、コンポーネントの出来がいい。演習章をもっとインタラクティブにしたいので、このクイズコンポーネントをコンテンツ側に全部組み込んでほしい、と。ただしBS/PLへの影響表示まではコンテンツ側では不要、という線引きも添えた。Claude Code は既存実装を調べてから演習設計をそちらに合わせ直し、Phase 3（演習120問）の基盤実装に入った。

終業時点で Phase 2 の全27章改稿が完了。全テスト71ファイル・1,829件グリーン。進捗は memo/2026-06-10/ に復帰プロンプト付きで保存させたので、明日はそれを貼れば続きから再開できる。

学び

「テスト全パス」を見ても安心しなくなった。 6,333件グリーンの裏に貸借不一致の実バグが眠っていた。テストの数ではなく「何を保証しているか」を疑う観点を、チェック依頼の文面に最初から入れておいてよかった。

計画→方針確認→実行のセッション分割が効いた。 計画セッションで「全問掲載」「抜本組み替えOK」という2つの判断を済ませてから引き継いだので、実行セッションは承認の「うん、いいですよ」「どんどん進めちゃってください」だけで26章が流れていった。人間の仕事は方針の判断と画面のレビューに絞られて、改稿の手はすべて並列エージェントに任せられた。

専門書はスキル化すると道具になる。 ドキュメント作成の専門書を読んで終わりにせず、スキルに変換しておいたことで「この本の手順に従って26章を組み替えて」という一言が通る。本の内容が制作プロセスそのものとして動き出した。

明日やること

Phase 3 の続き: 演習120問をクイズコンポーネント形式で実装する
改稿済みの章を画面で見て、4段型例題の表示崩れを拾う
連結精算表の軽微な未対応項目（午前のチェックで報告された分）を棚卸しする