[{"data":1,"prerenderedAt":298},["ShallowReactive",2],{"content-/cfws-bug-fixes-and-testing":3,"all-pages-for-dir":296,"og-image-/cfws-bug-fixes-and-testing":297},{"id":4,"title":5,"body":6,"category":275,"description":276,"extension":277,"meta":278,"navigation":279,"path":280,"project_name":281,"published":282,"publishedAt":283,"seo":284,"stem":285,"tags":286,"todo":293,"updatedAt":294,"__hash__":295},"pages/2026-04/2026-04-03/cfws-bug-fixes-and-testing.md","CF精算表のバグ修正とテストコード整備 --- 資本準備金・check行・PL科目名・配列数式の問題を潰した一日",{"type":7,"value":8,"toc":256},"minimark",[9,14,18,22,41,52,56,63,69,72,75,78,88,94,98,101,104,108,115,121,134,138,141,148,152,156,159,162,165,171,200,203,214,217,221,232,238,241,244,247,250,253],[10,11,13],"h1",{"id":12},"cf精算表のバグ修正とテストコード整備","CF精算表のバグ修正とテストコード整備",[15,16,17],"p",{},"CF精算表の自動生成スクリプトを回し始めると、Excelを開くたびに数字がずれている箇所が見つかった。1つ直すと別のセルが壊れる。モグラ叩きを繰り返しながらバグを潰し、最終的にcheck=0の数値検証テストを組んで「もう壊れたら気づける」状態まで持っていった一日の記録。",[19,20,21],"h2",{"id":21},"資本準備金が消えていた",[15,23,24,25,29,30,33,34,37,38,40],{},"BS階層を組み立てる ",[26,27,28],"code",{},"gen_annual_table_core.py"," で、",[26,31,32],{},"資本準備金"," が個別行として出力されていなかった。Excelを開いて純資産の部を見ると、",[26,35,36],{},"資本金"," の下に来るはずの ",[26,39,32],{}," がない。",[15,42,43,44,47,48,51],{},"原因は ",[26,45,46],{},"prune_empty_subtotals"," だった。この関数は値がゼロの小計行を間引く処理だが、資本準備金は小計ではなく末端科目なのに巻き込まれて落ちていた。修正として、",[26,49,50],{},"株主資本合計"," の数式に資本金系の科目を含めるよう書き換えた。",[19,53,55],{"id":54},"check行がcfwsに混入していた","check行がCFWSに混入していた",[15,57,58,59,62],{},"年次推移表には各セクションの末尾に ",[26,60,61],{},"check"," 行がある。BSの借方合計と貸方合計の差額を検証するための行だ。この行がCF精算表のBS科目リストに紛れ込んでいた。CFWSのRow 10に「チェック」という行が表示され、数式が壊れていた。",[15,64,65,68],{},[26,66,67],{},"parse_annual_data"," で年次推移表を読み取るとき、check行をスキップする条件を追加して解決した。",[19,70,71],{"id":71},"中間テーブルの正規化",[15,73,74],{},"借入金・貸付金・資本政策の3つの中間テーブルが、それぞれ別のレイアウトで組まれていた。列の並び順も参照の仕方もバラバラで、新しい勘定科目を追加するたびに3パターンの数式を書く必要があった。",[15,76,77],{},"これを「年度 x 勘定科目 x CF調整列名 -> 金額」の正規化形式に統一した。全テーブルで共通のINDEX/MATCH複合キーパターンを使う。",[79,80,85],"pre",{"className":81,"code":83,"language":84},[82],"language-text","=INDEX(TPL_返済予定表!$L$18:$M$24,\n  MATCH($C6&$C$2, TPL_返済予定表!$K$18:$K$24&TPL_返済予定表!$J$18:$J$24, 0),\n  MATCH(L$3, TPL_返済予定表!$L$17:$M$17, 0))*-1\n","text",[26,86,83],{"__ignoreMap":87},"",[15,89,90,93],{},[26,91,92],{},"$C6&$C$2"," で勘定科目と年度の複合キーを作り、中間テーブルのK列とJ列を結合した配列とMATCHする。この形なら、テーブルが変わっても参照先のシート名と範囲を差し替えるだけで済む。",[95,96,97],"h3",{"id":97},"中間テーブルの参照バグ",[15,99,100],{},"正規化した直後、N列（株式発行の調整列）がTPL_返済予定表を参照してしまうバグを踏んだ。返済予定表には株式発行のデータは存在しない。MATCHが#N/Aを返してセル全体がエラーになっていた。",[15,102,103],{},"テーブルに存在する (勘定科目, CF調整列名) ペアだけに数式を書くようスクリプトを修正した。存在しないペアにはIFERROR(..., 0)ではなく、そもそも数式を入れない方針にした。",[19,105,107],{"id":106},"マーク問題配列数式対応","@マーク問題（配列数式対応）",[15,109,110,111,114],{},"openpyxlが書いたINDEX/MATCHの数式をExcel 365で開くと、MATCHの引数に暗黙的交差演算子 ",[26,112,113],{},"@"," が付加される現象に遭遇した。",[79,116,119],{"className":117,"code":118,"language":84},[82],"MATCH(@$C6&@$C$2, ...)\n",[26,120,118],{"__ignoreMap":87},[15,122,123,125,126,129,130,133],{},[26,124,113],{}," が付くと配列評価が行われず、MATCHが単一セルしか見なくなる。複合キーの結合部分を ",[26,127,128],{},"INDEX(K列&J列,)"," でラップして配列評価を強制した。末尾の空カンマ ",[26,131,132],{},",)"," がポイントで、これによりINDEXが配列を返す式として評価される。",[19,135,137],{"id":136},"pl科目名の不一致","PL科目名の不一致",[15,139,140],{},"年次推移表では「受取利息」と表記されているが、CF精算表の調整辞書は「受取利息及び受取配当金」で検索していた。MATCHが#N/Aを返し、PL由来の調整項目が全滅していた。",[15,142,143,144,147],{},"adjustment dictに ",[26,145,146],{},"pl_name","（年次推移表での科目名）を別フィールドとして保持するよう修正した。CF精算表上の表示名と、年次推移表での検索名を分離することで、表記揺れを吸収できるようになった。",[19,149,151],{"id":150},"check0テストコードの追加","check=0テストコードの追加",[95,153,155],{"id":154},"最初の失敗-構造チェックしか書いていなかった","最初の失敗: 構造チェックしか書いていなかった",[15,157,158],{},"最初に書いたテストコードは「配分先が存在するか」だけを確認する構造チェックだった。数式が入っているかどうかは見るが、数式が正しい値を返すかは検証しない。",[15,160,161],{},"ユーザーから「Excelで数式が組めているのに、なぜテストコードで数値検証できない？」と指摘が飛んできた。確かにそのとおりで、openpyxlは数式の結果を計算しないが、中間テーブルの値はPythonで再計算できる。Excel上の数式と同じロジックをPythonで書けば、期待値は出せる。",[95,163,164],{"id":164},"数値検証版に書き換え",[15,166,167,170],{},[26,168,169],{},"wb.save()"," の直前に以下の4つの検証を実行するテストコードを追加した。",[172,173,174,182,188,194],"ol",{},[175,176,177,181],"li",{},[178,179,180],"strong",{},"BS全年度バランス検証"," --- 各年度の資産合計と負債純資産合計が一致するか",[175,183,184,187],{},[178,185,186],{},"配分漏れチェック"," --- 全調整科目に数式または値が入っているか",[175,189,190,193],{},[178,191,192],{},"PL由来項目の存在チェック"," --- 受取利息、支払利息など必須のPL調整項目が欠落していないか",[175,195,196,199],{},[178,197,198],{},"増減総和チェック"," --- BS増減の合計とCF調整列の合計が一致するか",[95,201,202],{"id":202},"トートロジーバグ",[15,204,205,206,209,210,213],{},"テストコードを回すと全項目check=0になった。一瞬喜んだが、DUAL/EQUITY科目のテストで ",[26,207,208],{},"alloc = h"," と書いていたことに気づいた。",[26,211,212],{},"h"," は中間テーブルから取得した値ではなく、そのセル自身の値だった。つまり「自分自身と自分自身を比較してcheck=0」というトートロジーになっていた。",[15,215,216],{},"実際の中間テーブルの値をPythonで計算し直し、期待値として使うよう修正した。修正後に回すとcheck!=0の科目が2つ出てきて、テストがきちんと機能していることを確認できた。",[19,218,220],{"id":219},"tpl_回収予定表の文字列問題","TPL_回収予定表の文字列問題",[15,222,223,224,227,228,231],{},"スプレッドシートからエクスポートしたデータがopenpyxlで文字列としてコピーされていた。セルの値が ",[26,225,226],{},"\"1000000\""," (文字列) であって ",[26,229,230],{},"1000000"," (数値) ではない。SUMIFSの条件に合致しても集計対象にならず、合計が0のままだった。",[15,233,234,237],{},[26,235,236],{},"copy_sheet"," 関数に自動数値変換を追加した。セルの値が数値に変換可能な文字列であれば、コピー時にfloatへキャストする。",[19,239,240],{"id":240},"短期借入金が配分不能だった",[15,242,243],{},"Codexにスクリプトをレビューさせたところ、「短期借入金がDUAL_ACCOUNTSに定義されているのに、中間テーブルの参照先が長期借入金のテーブルに固定されている」と指摘が返ってきた。短期借入金は返済予定表の別セクションを参照する必要がある。中間テーブルの参照先を科目ごとに切り替えるよう修正した。",[19,245,246],{"id":246},"振り返り",[15,248,249],{},"今日の作業で一番手が止まったのはトートロジーバグの発見だった。テストが全部グリーンになった瞬間は気持ちよかったが、「なぜこんなに簡単に通るのか」と違和感を覚えて式を読み返したら、自分自身との比較だった。テストが通ること自体を疑う習慣がないと、偽の安心を積み上げてしまう。",[15,251,252],{},"もう1つの教訓は、科目名の表記揺れを甘く見ていたこと。「受取利息」と「受取利息及び受取配当金」の違いでMATCHが黙って#N/Aを返す。エラーにならずに0が入るだけなので、目視では気づきにくい。テストコードがなければ、おそらくしばらく気づかなかった。",[15,254,255],{},"check=0テストを入れたことで、今後新しい科目やテーブルを追加したときに壊れたら即座にわかる。モグラ叩きから、壊れたら警報が鳴る状態に移行できた。",{"title":87,"searchDepth":257,"depth":257,"links":258},2,[259,260,261,265,266,267,272,273,274],{"id":21,"depth":257,"text":21},{"id":54,"depth":257,"text":55},{"id":71,"depth":257,"text":71,"children":262},[263],{"id":97,"depth":264,"text":97},3,{"id":106,"depth":257,"text":107},{"id":136,"depth":257,"text":137},{"id":150,"depth":257,"text":151,"children":268},[269,270,271],{"id":154,"depth":264,"text":155},{"id":164,"depth":264,"text":164},{"id":202,"depth":264,"text":202},{"id":219,"depth":257,"text":220},{"id":240,"depth":257,"text":240},{"id":246,"depth":257,"text":246},"dev","CF精算表の年次推移表パーサーとBS階層構築に潜んでいたバグ群を修正し、wb.save()直前に数値検証テストを追加した記録。資本準備金の消失、check行混入、PL科目名不一致、openpyxl配列数式問題など","md",{},true,"/cfws-bug-fixes-and-testing","eurekapu-nuxt4",false,"2026-04-03T00:00:00.000Z",{"title":5,"description":276},"2026-04/2026-04-03/cfws-bug-fixes-and-testing",[287,288,289,290,291,292],"CF精算表","Excel自動化","openpyxl","テストコード","バグ修正","INDEX/MATCH","memo",null,"DJp7-312kOTFN8SFPM7418F0TOSErCXxuX5D2HnrPlo",[],"https://log.eurekapu.com/favicon.svg",1775338204085]