連結精算表シミュレーターの大幅拡張

2026年2月5日の開発ログ。連結精算表シミュレーターに対して、新コンポーネント追加、データセット拡充、理論値テスト追加、リファクタリング計画見直しと、4つの方向から手を入れた1日だった。5つのコミットで約5,700行の変更（うち追加が約5,600行）。

午前: 教科書OCR読み込みの試み

連結会計教科書のページをJPEGとしてスキャンし、Claude APIで読み込ませて例題データを取り出す作業から始めた。

まず必要だったのはページ番号の対応関係の把握で、JPEGファイルの番号と書籍ページの間にオフセット10のずれがある（JPEG番号 = 書籍ページ + 10）。例題7-1がJPEG 210（p.200）、例題8-1がJPEG 220（p.210）の位置にあることを特定した。

しかし、画像サイズが2,000pxの制限を超えていてAPIエラーになり、このセッションは中断。結果的にデータセットは手入力で作ることになった。

午前〜午後: 5つのコミットによる機能追加

コミット1: 段階取得の試験問題データセット（exam-6-1）

コミット: 42086e6 / 変更: +809行

段階取得（step acquisition）の設例6-1のデータセットを追加した。

• worksheet-data-step-acq-exam-6-1.ts（721行）を新規作成
• CommentaryBlock.vueを拡張し、コメントセクションにテーブルを表示できるようにした
• EquityCalcTable.vueの微修正
• consolidated-worksheet.test.tsにテスト追加

段階取得では、もともと保有していた株式の再評価と、追加取得で生じる差額の処理が必要になる。従来のデータセットは一括取得パターンだけだったので、試験問題の数値をベースに実際の出題形式に沿ったデータを作った。

コミット2: JournalCategoryTable（仕訳カテゴリテーブル）

コミット: 56b1605 / 変更: +49行

仕訳をカテゴリ別に集計するテーブルコンポーネント JournalCategoryTable.vue（45行）を新規作成した。連結修正仕訳が「開始仕訳」「のれん償却」「未実現利益消去」などのカテゴリに分かれるとき、カテゴリごとの金額合計を表形式で確認できる。

コミット3: EquityMovementTable + GoodwillScheduleTable + 4データセット

コミット: 7ab3afe / 変更: +3,724行（今日最大の変更）

ここが今日の作業の中心。2つの新コンポーネントと4つの新データセットを追加した。

EquityMovementTable（株主資本等変動計算書テーブル） — 258行

連結精算表の計算結果から株主資本等変動計算書を組み立てて表示するコンポーネント。表示項目は以下の通り。

• 資本金、資本剰余金、利益剰余金の期首残高 → 期中変動 → 期末残高
• 非支配株主持分の変動
• 連結修正仕訳による調整額

連結精算表で計算した数字が最終的な財務諸表の形で正しく並ぶかどうか、ここで確認できる。精算表の合計が合っていても、変動計算書への組替で間違うケースはありがちだ。

GoodwillScheduleTable（のれん償却スケジュールテーブル） — 121行

のれんの取得額、償却開始時期、償却年数、各期の償却額と残高を一覧で表示する。段階取得のケースでは、「持分法適用時に認識したのれん」と「支配獲得時に認識したのれん」が別々に償却されるので、スケジュール表で全体像を把握できるようにした。

4つの新データセット:

types.tsにも株主資本等変動計算書（EquityMovementTable）とのれんスケジュール（GoodwillScheduleTable）の型定義を追加した。

コミット4: ハイライト機能

コミット: 38d850a / 変更: +79行

EquityCalcTableとEquityMovementTableにハイライト機能を追加した。

• 行や列をクリックすると関連セルがハイライトされる
• types.tsにハイライト状態の型（highlightColumns, highlightRows）を追加
• ページ側の[...slug].vueでハイライト状態を管理

精算表の数字がどの仕訳から来ているのか、視覚的に追跡できるようになった。「この利益剰余金の増減はどの連結修正仕訳に対応するのか」を確認するとき、いちいち手で追いかけなくて済む。

コミット5: 連結除外に伴う利益剰余金減少高

コミット: 32b15d9 / 変更: +32行

exam-9-1とpartial-sale-80-10のデータセットに、支配喪失時の利益剰余金減少高を計算するロジックを追加した。

子会社株式を売却して支配を喪失すると、連結上の利益剰余金が減少する。この金額は株主資本等変動計算書の「連結除外に伴う利益剰余金減少高」として表示される。計算には子会社の利益剰余金のうち親会社持分に帰属する部分と、のれん未償却残高の除去が関わる。

午後: 理論値テストの追加

データセットが19個に増えたところで、横方向の合計整合性やB/Sバランスの検証だけでは足りないと感じ、理論値テストを追加した。

追加した4カテゴリのテスト

1. 連結F/S間の整合性: B/Sの期末残高とS/S（株主資本等変動計算書）の期末残高が一致するか
2. 各金額の妥当性: 投資消去完了後の子会社株式=0、評価差額=0、資本金=親会社の個別資本金
3. 各金額の理論値: NCI（非支配株主持分）>0、のれん>=0、のれんスケジュール整合
4. 単体vs連結: 資産科目（コード100〜299, 540）がマイナスにならないこと

テストではデータセットを自動分類する仕組みを入れた。companyLinkカラムの数と持分比率で「連結子会社」「持分法適用会社」「対象外」を判定し、分類に応じたテストを適用する。

のれんスケジュールテストの試行錯誤

一番手間取ったのがのれんスケジュールとB/Sのれんの整合性テストだった。

初回の実装: スケジュールのperiodLabels.length - 1（最終期間）を「当期」と仮定し、その残高をB/Sと比較。

結果: 例題7-1で失敗。expected 8000 to be 8500。

原因: 例題7-1は段階取得（30%→80%）のケースで、のれんスケジュールに将来3期分の償却予定が含まれていた。精算表の対象期間はX3/03（取得時点）なのに、最終期間のX5/03の残高と比較してしまい、2年分の償却額がずれた。

最終解決策: スケジュールの各期末残高をすべて計算し、B/Sのれんが「いずれかの」期末残高と一致するかを検証する方式に変更した。

const periodRemainingValues = schedule.periodLabels.map((_, periodIdx) =>
  consolidationEntries.reduce((sum, entry) => {
    const amortized = entry.amortizations
      .slice(0, periodIdx + 1)
      .filter((a): a is number => a !== null)
      .reduce((s, a) => s + a, 0)
    return sum + (entry.amount - amortized)
  }, 0)
)
expect(periodRemainingValues).toContain(bsGoodwill)

「当期がどの期間か」を特定する必要がないので、将来のデータセットにも対応できる。ただし「いずれかの残高と一致」は検証として緩い面があり、精算表の対象期間を特定できる情報がデータに追加されたら、特定期間との一致に絞り込むべきだろう。

修正後、全5,877テストがパスした。

午後: リファクタリング計画の見直し

データセットが19個に増え、パターンも出揃ってきたので、リファクタリング計画を更新した。

背景

19ファイル（合計約16,000行）に、同一のヘルパー関数が100%コピペされている。cv, sumCols, linearCols, addFs, negateColsなど12関数、約1,600行の重複。build-worksheet-core.tsに共通化済みのcreateHelpers()とbuildCodeValues()が実装済みだが、どのファイルにも使われていない。

ColumnPipelineConfig適合性の確認

19データセットをGroup A（Year1/Year2）、Group B（連結パターン12件）、Group C（持分法5件）に分類し、それぞれのcodeValues構築がColumnPipelineConfigに適合するか検証した。

17/19が現行のインターフェースで対応可能。残り2件（Year1/Year2）はreclassificationAdjustmentsの拡張が必要だが、Phase 2bで個別対応する方針に。

3フェーズの計画

• Phase 1（低リスク）: createHelpers()の適用。19ファイルのヘルパー定義を2行に集約。約1,200行の削減。
• Phase 2a（中リスク）: buildCodeValues()の適用。Group B + C の17ファイル。
• Phase 2b: Year1/Year2用の拡張。
• Phase 3（高リスク）: ssTableData計算の改善。520直接エントリの制約は受け入れつつ、表示側を改善。

コンポーネント一覧（現時点）

今日の追加で、連結精算表関連のVueコンポーネントは13個になった。

振り返り

今日の成果をまとめると:

• データセット: 15個 → 19個（段階取得・持分法・連結除外の設例を追加）
• コンポーネント: 10個 → 13個（EquityMovementTable、GoodwillScheduleTable、JournalCategoryTable）
• テスト: 理論値テスト4カテゴリを追加し、全5,877テストがパス
• リファクタリング計画: 19ファイル全体の適合性を検証し、Phase 1〜3の具体的な手順を更新

連結会計の教科書を進めるたびにデータセットが増え、データセットが増えるたびにコード重複が目立つようになる。Phase 1のcreateHelpers()適用だけで1,200行減らせるので、次回はここから着手したい。

のれんスケジュールテストの「最終期間=当期」の仮定が崩れた件は、テスト設計の教訓でもある。テスト対象のデータ構造が「当期のみ」なのか「将来期間を含む」のかで前提が変わる。今回は「いずれかの残高と一致」で緩く対応したが、精算表にperiod指定が追加されたら厳密な検証に切り替える。