回帰テストを関係ない区間まで流していた件と、税額計算Excelモジュールの設計見直し（IBルールの緑文字、表引き、年度の持ち方）

回帰テストは今回直したところだけだったのか

財務諸表教材の6章で、演習の試作を進めていた。 課題の会社の有価証券報告書を EDINET から取らせ、数式エンジンに AVERAGE と MEDIAN を足させて、演習用のブックを組ませた。 エンジンでの検算は式100、書く欄30で、check の合計は作業前も完成も0だった。 解答の区間（Excel の画面再現）もプレビューで1コマずつ撮らせ、ROE を3つの要素に分けた積が ROE に戻るところまで確かめさせた。

数式エンジンと区間の一覧に手を入れたので、仕上げに既存の Excel 動画の回帰テストを裏で回させた。 結果がなかなか返ってこない。 待っているあいだに、ふと聞いてみた。

回帰テストって今回修正したとこだけやってますか？

答えは「いいえ」だった。 流していたのは、Excel 講座の画面再現の全区間を対象にした4本のテストである。 時間がかかっているのはそのためだという。

一番重かったのは関係ないCF精算表だった

全区間の中で一番重いのはどこか、と重ねて聞いた。 たぶん関係ないところに時間を取られている、と思ったからだ。

予想は当たっていた。 重かったのは、CF精算表の21本を全コマで照合する部分である。 動画の全長にわたって1/30秒ごとに計算し、仮の時刻と本人の声の時刻の両方で照合していた。 CI でも1回23分かかるので、CI からは外してある部分だった。

テストを止めさせ、変更が効く区間だけを選ぶ流し方に切り替えたら、数分で終わった。 残っていた vitest のプロセスも、PID を指定して止めさせた。

ただ、それで片付いた気はしなかった。 このセッションで触っていたのは財務諸表のほうで、キャッシュフロー計算書ではない。 ページも分けてある。 それに、前にも同じことを言って分けた気がする。 なぜまた同じ問題が出ているのか、原因を知りたいし改善もしてほしい、と伝えた。

以前分けたときの記録とテストの対象の選び方を調べさせると、原因は2つ重なっていた。 対策として、どの区間を流すかを決めて回帰テストを呼び出す側だけを直させた。 区間を指定せずに直接流すと、12秒で何も照合せずに終わる。 CF精算表の画面の記録（全コマのハッシュ）は変えていない。

コミット、プッシュ、引き継ぎ

続けてコミットとプッシュを頼み、引き継ぎのプロンプトをダウンロードのフォルダにあるテキストファイルへ書き出すよう頼んだ。 書き出しはもう済んでいるかと聞いたら、まだだった。

変更は3つのコミットに分けさせた。 回帰テストの既定の変更と、演習の試作が別々のコミットになっている。 プッシュして origin と一致したのを確かめてから、引き継ぎのプロンプトを書き出させた。 最初に受け取った引き継ぎのファイルとは別の名前で保存させ、元のファイルはそのまま残した。

出力シートの参照セルが黒文字だった

同じセッションの後半は、シミュレーション系の計算モジュールに移った。 個人所得税、住民税、事業税を計算する Excel である。

最初に引っかかったのは文字の色だった。 出力のシートの数字は、他のシートを参照して作っていないか。 参照しているなら、IB ルールに従って数字を緑の文字にしてほしい、と頼んだ。

調べさせると、年の数字のセルは全部、計算のシートを SUMIFS で引く式だった（4冊で93セル）。 これを緑（#008000）に変えさせた。

ところが、直ったのは出力のシートだけだった。 計算のシートにも、他のシートを参照している式がある。 「計算シートも他のシートから参照してる場合は全部緑に」「Excel 作るとき、IB フォーマットのスキル使ってちゃんとルール守って」と伝えて、Excel を出し直させた。 作り直したあとはスキルの判定法で全セルを検査させ、違反0件になった。 画面再現でも、計算のシートが緑になっていることを確かめさせた。

IFで書かれた一行と、2026年しかない制度表

色の件が片付いたところで、計算シートのある式が目に留まった。

=IF(AND(F10>0,F4<6600000),ROUNDDOWN(F4/4000,0)*4000,F4)

イメージと違った。 ここは少なくとも VLOOKUP あたりで書けるはずである。 なぜ IF にしているのか。 テーブルで参照する形だと構造化できない、他の年度に対応できない、という理由なのか。

返ってきたのは「半分はご推察のとおり、残り半分は作りの問題」という答えだった。 この行（12行目「別表第五の収入」）は表を引く行ではなく、端数を切り捨てる行である。 しかも、660万円や4,000円刻みといった制度の数字を式に直接書いていた。 表のほうは、VLOOKUP ではなく INDEX と MATCH で引いていた。

そこで、自分で作った同じ種類のモジュールの Excel と画面を見せて、比べさせた。 自分のモジュールは、その年の制度を前提に置いた1年版である。 作らせたブックは、年の列ごとに制度表の列を選び直す作りになっていた。 けれども、未公表の年はどうせ2026年の表で計算している。 年の列を持っても、得るものはほとんどない。

言いたかったことを、もう少し詰めて伝えた。 この表は2026年しか出していない。 2026年しか出していないのは、将来の変更が読めないからだ。 だとすると、27年、28年の列を作っても、中身は全部同じ数字になる。

その指摘は、そのまま認められた。 さらに、表を「下限」「率」「足す額」「特例の下限」といったブロックに分け、それぞれに年の列を付けたせいで、1つの表が縦に7つほどに割れていた。 公表資料と同じ形の速算表を1枚置けば足りる。

モジュールを作るときの前提として計画書に書かせた

これは今回のモジュールだけの話ではないと思った。 モジュール系、シミュレーション系を作るときの前提である。 このフィードバックを計画書に書いておくよう指示した。

ライフプランの計画書の該当2箇所を直させ、作り直しの範囲が大きかったので、作り直しの計画を別にまとめさせた。 Codex のレビューで出た指摘4点はすべて反映させ、残りの2点も反映させた。 決裁フォームでは判断2点に答え、どちらも推奨案（A）にした。

A1（給与所得）では、式に直書きしていた660万円と4,000円刻みを制度表へ移させた。 根拠は法令の本文（e-Gov）で確かめさせた。 別表第五は4,000円刻みで、最後の行は6,596,000〜6,600,000円である。 作り直したあとも、例題9件の答えは作り直す前と同じ値だった。 Excel の全再計算でも全セルが一致し、IB 書式の検査も通った。

続けて、単体のモジュール4冊から check のまとめのシートを外させた。 check 行は、各シートの中で0になっていれば済む形である。 セッションが膨らんできたので、進捗を計画書2本に書き残してコミットさせ、引き継ぎのプロンプトを書き出させて切り上げた。

決算書の演習を独立したセクションから章の末尾へ

次のセッションでは、前のセッションで書き出させた引き継ぎのプロンプトから、財務諸表教材の続きを再開した。 6章の試作を1〜12章へ広げる作業である。 演習のブックは、12章それぞれの作業前と完成で24冊、それに総合課題の2冊になった。 解答区間9本の台本は、5体のサブエージェント（opus）に章を分けて書かせた。

途中で、6章の解答区間のテストが1件落ちた。 原因は5秒のタイムアウトだった。 全章分の画面の素が増えて JSON が600KBになり、読み込みが遅くなっていた。 このテストには長めの時間制限を付けさせた。 CRLF のせいで置換が当たらず、Edit ツールでやり直させた場面も、このセッションで2回あった。 エンジンに手を入れたので、回帰テストは --changed で流させた。

コミットしたあと（Codex のレビューは critical/high なし）、ページを見て気になった。 決算書の演習が、独立したセクションになっている。 財務諸表の決算書のセクションに入れなかった理由はあったのか。

理由は記録に残っていなかった。 前のセッションが、技術的な都合でそうしただけである。 決算書のページは財務諸表講座用の図の再生の仕組みで動いていて、Excel の画面再現はそのままでは載せられない。

それでも、本当は末尾に入れてほしい。 統合させることにした。 章の解答は、その章の節の末尾に「6-演習 ROE を3つに分ける・解答」のような名前で入った（3、4、5、6、7、10、11、12章）。 独立していたページを開くと、決算書のページへ移るようにした。

未了事項の突き合わせとGoogleタスク

最後に、もともとの計画書と突き合わせて、未了事項を洗い出させた。 計画書の§7と、動画全体の計画書の「まだのこと」に書き込み、進捗を更新して、コミットとプッシュまで済ませた。

中身は翌日に自分でチェックすることにした。 Google タスクに、明日（2026/10/12）の期日で登録させた。 タイトルは「決算書講座の演習: 解答区間10本と配布ブックのチェック（判断3つ）」である。 登録したあとでタスクを読み直させ、タイトル、メモの文面、期日が登録した内容と一致することも確かめた。

別のセッションでは、もう終えてよいかを聞いた。 作業はすべてコミットとプッシュが済んでいて、5体のサブエージェントもすべて終わっている、という返事だった。

学びメモ

• 回帰テストは「指定しなければ何を流すか」が効く。今回は、変更と関係ないCF精算表の21本（CI でも1回23分）に時間を取られていた
• 他のシートを参照するセルの緑は、出力のシートだけ直しても足りない。計算のシートを含めて、IB フォーマットの判定で全セルを検査させる
• 未公表の年に列を並べても、2026年の数字の複製が増えるだけだった。制度表は公表資料と同じ形の1年版を1枚置き、制度の数字は式に直書きせず表へ移す

振り返り

朝のセッションでは、回帰テストの結果をただ待っていた。 聞いてみたら、その時間は、触ってもいないCF精算表の照合に取られていた。 同じ日の次のセッションでは、エンジンを触ったあとの回帰テストを --changed で流させている。

税額計算の Excel も、構図は似ていた。 年の列は年度ごとに制度を選び直すために用意されていたが、中身は同じ数字の繰り返しだった。 作り直しの続きは、引き継ぎのプロンプトに乗せて次のセッションへ回した。 次にモジュールを作らせるときに、計画書に書いた前提が守られるかどうかは、まだ分からない。