仕訳チェックボックスで別表四・五(一)が連動するインタラクティブアプリの設計

参考書の解説コンテンツに「触れる別表」を載せたい。仕訳のチェックボックスをON/OFFすると、別表四と別表五(一)のSVGがリアルタイムで数字を組み替える。読者が「この仕訳を入れると別表のどこが動くのか」を自分の手で確かめられるアプリだ。

今日はこの設計をCodex（GPT-5.4）に4回レビューさせながら詰めた。実装は次のセッションに持ち越したが、計画書はほぼ固まった。

テストケース: 法人税の中間納付と期末決算

題材は参考書の「損金経理パターン」。以下の仕訳をチェックボックスにする。

全チェックOFFが「何も仕訳を切っていない状態」、全チェックONが「教科書通りの完成形」。途中のON/OFFの組み合わせで別表の数字が連動して変わる。

計画書を書いてはCodexに投げ、指摘を受けて直す。この反復を4回繰り返した。

最初の計画書では「全チェックOFFなら別表五(一)の繰越損益金は期首と期末が同じ」と書いていた。Codexがすぐ突いてきた。

全チェックOFFでも当期純利益が存在する限り、繰越損益金の期末は当期純利益分だけ増える。洗替え方式なので期首残高に加算される。

P/Lの当期純利益が別表五(一)に流れ込むルートを見落としていた。チェックボックスのON/OFFにかかわらず、繰越損益金の「増③」欄には当期純利益が常に入る。これを計画書に反映した。

参考書のch7.vueに実装済みの損金経理パターンを改めてCodexに読ませた。ここで中間納付の処理が確認できた。

中間分の未納法人税等は別表五(一)で「増③」と「減②」に両建てされる。期首に前期未払分が残っているとき、中間納付でその一部を取り崩す動き。この両建ては直感に反するが、「発生」と「消滅」を両方記録することで期末残高が正しく出る仕組みだ。

計画書に「中間納付チェックON時の別表五(一)の挙動」として、この両建てパターンを明記した。

ここが最大の修正だった。計画書では preTaxProfit = 10,000 を会計と税務の両方で使い回していた。Codexが矛盾を検出した。

ch7の当期利益7,280に法人税等3,170を足すと10,450。preTaxProfitの10,000と合わない。

原因は会計上の税引前利益（10,450）と税務上の課税所得（10,000）を混同していたこと。損金経理した法人税等が損金不算入で加算されるため、両者はずれる。

計画書を修正して2つの変数に分離した。

const accountingPreTaxProfit = 10_450  // P/L上の税引前当期純利益
const taxableIncome = 10_000           // 別表四で算出する課税所得

この分離によって、P/L側の数字（税引前利益 - 法人税等 = 当期純利益）と別表四側の数字（当期利益 + 加算 - 減算 = 所得金額）が両方とも整合するようになった。

最後のレビューで priorJigyozei（前期事業税）の繰越ロジックに指摘が入った。前期末の未払事業税が当期の損金算入額として別表四の減算欄に入るが、このとき別表五(一)の残高も連動して減る。計画書の数式で符号が逆転していた箇所を修正した。

細かい指摘だが、ここを間違えると全チェックON時の期末残高がずれる。最後に全パターンの数値を手計算で検算して、計画書を確定した。

チェックボックスの状態を Ref<boolean> で持ち、computed で別表の全セルを算出する。依存関係は一方向で、仕訳 → P/L → 別表四 → 別表五(一) の順に流れる。

checkbox[] → computeAdjustments() → computeBeppyo4() → computeBeppyo5()

純粋関数で計算ロジックを組み、Vueのリアクティビティに副作用を閉じ込める。テストは純粋関数だけを対象にすれば済む。

別表のSVGはVueテンプレートで直接描画する。<text> 要素に computed の値をバインドすれば、チェックボックスのON/OFFで数字が即座に書き変わる。CSSトランジションで数字の変化にフェードをかけると「動いている」感覚が出る。

計画書は固まった。Codex 4回のレビューで潰した矛盾は、実装段階で踏む地雷を先に踏んだことになる。明日は手を動かす番だ。