連結会計レッスンの仕訳モーダルを3部構成に拡張：個別→連結あるべき→連結修正の差分検算

連結会計レッスンI-2-1〜I-3-3の6設例で、仕訳モーダルを3部構成に組み替えた。「個別上の処理」「連結上あるべき仕訳」「連結修正仕訳」を縦に並べ、② − ① = ③ の差分を bookRowId 単位で検算する。Codexレビュー（gpt-5.5）で2回方針転換させられた末にデータ駆動方式へ落ち着いた。

何を変えたか

JournalEntryModal.vue を3部構成に分割した。連結修正仕訳の意図は「個別の処理を一旦取り消し、連結ベースの正しい姿に置き換える差分」だが、従来は③だけを表示していたので、学習者が「なぜこの修正が必要か」を頭の中で復元するしかなかった。

3部構成にしたことで、画面が次のように並ぶ。

① 個別上の処理        （点線枠＋ヘッダー）
② 連結上あるべき仕訳  （点線枠＋ヘッダー）
③ 連結修正仕訳       （実線枠＋ヘッダー）

階層インデントは ② を 2em に揃え、視線が「①と②を見比べて、その差分が③」と流れるように整えた。

②−①=③ の検算ロジック

bookRowId 単位で借方・貸方を集計し、②の金額 − ①の金額 が ③の金額 と一致するかをコンポーネント側で検算する。一致しなかった場合はモーダル右上に警告バッジを出す。

ただし NCI按分・未実現損益・連結内ソフト売買のような複雑グループは「個別側の二社合算と連結側の集計が貸借不一致」になるケースがあり、機械的な照合が壊れる。やむを得ず skipReconcileCheck フラグを設例側に持たせ、これらは検算を飛ばす設計に切り替えた。

// 検算スキップ条件
if (group.skipReconcileCheck) return { ok: true, skipped: true }
const diff = sumByBookRow(group.consolidated) - sumByBookRow(group.individual)
return { ok: diff === sumByBookRow(group.modify), skipped: false }

Codexレビューで方針転換した経緯

最初の計画では「③の連結修正仕訳から①の個別仕訳を逆推測する」設計にしていた。Codex（gpt-5.5）に投げたところ即座に致命点を突かれた。

JournalEntry単位で逆推測すると、A社の仕訳とB社の仕訳が混在した片側だけになり、二社の個別処理を再構成できない。データ駆動で個別仕訳をソースに持つべき。

設例ファイルに individualEntries を直接持たせるデータ駆動方式に切り替えた。書く量は増えたが、「期末残高ベース＋差額は現金預金で補完」という設計指針をユーザーから受けて、I-2-1／I-2-2／I-2-3を全面書き直しした。

I-2-2 の借方貸方ミスをユーザー指摘で発見

I-2-2 の cogs-to-sga-reclass（売上原価から販管費への振替）で、借方が費用なのに貸方も「費用」になっている矛盾が残っていた。ユーザーから「貸方は費用じゃなく、実態は現金預金が動いているはず」と指摘されて気づいた。

業務委託サービスで原価が労務費中心という文脈を踏まえ、ラベルを「売上原価（労務費）」に変えたうえで、貸方を現金預金に修正した。仕訳の意味を読み解く前提知識がないと検出できないバグで、Codexも見落としていた。

I-2-3 を I-2-1 構造に統一

I-2-3 は当初、独自の構造で「未達取引」を扱っていたが、I-2-1 と並べて見せたときに学習者の認知負荷が跳ねる。期首棚卸 + 仕入 − 期末棚卸 = 売上原価 の流れに揃え、未達取引4本を ② 連結上あるべき仕訳のセクションに追加した。これで I-2-1／I-2-2／I-2-3 が同じ骨組みで読める。

I-3-1 に減価償却スケジュール表を追加

I-3-1（固定資産の未実現利益消去）では、未実現利益¥400 が10年かけて毎期¥40ずつ実現していく流れをモーダル内に表として埋め込んだ。

年度	期首未実現	当期実現	期末未実現
X1	400	40	360
X2	360	40	320
...	...	...	...
X10	40	40	0

「未実現損益の実現」という用語が業界標準として正しいか不安だったので、Turso DBに登録済みのTAC『連結財務諸表 1』を蔵書検索で引いてp.304を確認した。同書の表記をそのまま採用した。

4Kワイド画面対応

精算表を3カラムレイアウトに組み替えた。max-width を撤廃し、サイドバー1/8、前提条件エリア2/8、精算表本体が残り5/8という比率に調整した。FHDでは従来通り収まり、4Kでは前提条件と精算表が左右に並ぶようになった。

データ構造の変更点

設例ファイルの型定義に追加した主なフィールド：

IndividualModifyColumnDef：個別修正仕訳列の型
fiscalYearLabel：会計期間ラベル（「連結WS_FY20X2-03」など）
skipReconcileCheck：検算スキップフラグ
individualEntries：① 個別上の処理の仕訳配列

fiscalYearLabel を入れたことで、ヘッダーに「連結WS_FY20X2-03」と出るようになり、複数年度を切り替える設例で「いま何期目か」が一目で分かる。

Codex再レビューでの追加指摘

データ駆動に切り替えた更新版を codex exec resume --last で再レビューに回したところ、次の致命点が出た。

ペアリング（借方／貸方を同じ行位置に揃える）が崩れているグループがある
skipReconcileCheck の使いどころを設例ごとにコメントで残すべき

行位置のペアリングは、グループ単位で借方／貸方を揃えるユーティリティを噛ませて解決した。skipReconcileCheck のコメントは設例ファイルに直接書き込んで、後から読んだ自分が「なぜスキップしたか」を即座に思い出せるようにした。

学んだこと

仕訳の片側（連結修正仕訳）から両側（個別＋連結あるべき）を復元するのは無理。データソースを増やす方が結果的に保守しやすい
② − ① = ³ の検算は学習者向けの安心感だけでなく、設例データの整合性チェックとしても効く
Codexは構造的な破綻（逆推測の不可能性）を突くのは得意だが、会計実務的な借方貸方の意味付けは見抜けない。両軸でレビューを回す必要がある
4Kワイド画面では max-width を撤廃してカラム比率で組む方が、画面の余白を活かせる