クラウド会計の元帳に消込の紐付けを足すChrome拡張を自作する
前期繰越の1行では、何も分からない
会計ソフトAの月次推移表で3月の金額をクリックすると、その科目の総勘定元帳が開く。開いた先の一番上に「前期繰越」が1行だけある。売掛金なら、およそ55万円。
この55万円の中身が、いつも分からない。前期末に残っているということは、前期に発生して当期にまだ決済されていない取引がそこにいるはずだ。ところが元帳は残高しか見せてくれない。何が回収できていないのかは、自分で仕訳を追って組み立てる。期をまたぐと、これが毎回面倒になる。
会計ソフトBでは、取引に決済を登録すると、発生した債権とそれを消した入金が紐付いて残高が消える。同じ追跡を会計ソフトAの元帳の上でやりたい。会計ソフトBの操作（消込にあたる決済の登録と、そこから枝分かれする「+更新」の振替）は別に整理した記事を書いたところで、欲しい形は自分の中で決まっていた。足りないのは実装だけだった。
消込側だけに書く
計画は朝のセッションで作ってあった。Codexで5往復レビューさせて、判断が要る5点を3択のボタンにして自分で選んだ。決まったのは次の形だ。
- 参照はメモの先頭に書く
- 書くのは消込側の仕訳だけ。発生側には触らない
- 記法は、年度と取引Noと照合用の4文字
- 2025年度は編集ロックを一時的に外して書き戻す
- 拡張は読むだけにする
消込側だけに印を付けると決めたとき、ひとつ引っかかった。消した側にしか印がないなら、発生した側の仕訳を1本ずつ追いかけて「これはどれで消えたのか」を探しに行くことになりはしないか。それとも、相手勘定が売掛金の明細を引っ張ってくれば済む話なのか。聞いてみた。
答えは後者だった。発生1本ごとに探しに行く形にはならず、科目単位で元帳を年度分まとめて読んで、逆引きの索引を1回だけ作る。売掛金の元帳の減らす側の行を全部取れば、それがそのまま消込の一覧になる。発生の本数が増えても、読みに行く回数は増えない。
テスト事業者は使わなかった
Phase 0 から着手させた。書き込みの検証にテスト用の事業者を立てるか迷ったが、自分がいつも見ている実データでやることにした。会計ソフトAは仕訳を全部削除して、連携した取引明細の除外を外せば、実質的に入力前の状態まで戻せる。壊しても戻せるなら、空の事業者より本物の帳簿のほうが検証になる。
確かめたかったことが3つある。売掛金の回収、労働保険料のような未払金と未払費用の支払い、源泉徴収した所得税が納付額と合うか。どれも期をまたぐと追いにくくなる場所で、この機能はそこのために作っている。
Phase 0 では読み取りの実測を全部終えてから、書き込みの実測に入らせた。書く前に復元用の原本を取り、編集フォームの形を確かめている。テストで書いたメモはすべて元に戻し、編集ロックも 2025-12-31 に戻した。本番に残したのは、消込仕訳4本のメモだけだ。
期首残高の内訳が、当たらない
Phase 2 で元帳の画面に表示を差し込ませた。テストは210件とも緑になった。ただし実機の表示だけが確認できていない。拡張のリロードが Chrome DevTools MCP から通らないので、そこは自分でボタンを押した。
押して、売掛金の元帳を開いた。期首残高およそ55万円に対して、内訳がどう見ても合っていない。
原因を調べさせると、2025年度の消込79本が CSV 取込で入っていて、摘要もメモも空だった。推定の当て方は「摘要に書かれた対象期間」と「同額の発生」の2つしかない。摘要が空なら、どちらもほぼ当たらない。結果として2025年の売上576件、金額にして1,400万円強がまるごと未消込に見えていた。バッジそのものと参照先へのリンクは正しく動いていて、壊れていたのは推定だけだった。
未消込に出ている行は、本当に残っているのか
補助科目を1つに絞って見ると、話が早い。決済サービスごとに補助科目を切ってあるので、そのうち1つだけを開いた。
1月11日に13,860円の売上があり、その1週間後に同額の入金がある。帳簿を見れば対応は一目で分かる。それなのに拡張は、売上を未消込、入金を未紐付けと表示していた。
理由は単純だった。入金側のメモに参照が書かれていないからだ。参照が入っているのは、Phase 1 で書き込ませた4本だけだ。拡張は「消えた証拠がないもの」を未消込として出していて、それは「まだ消えていないもの」とは別物だった。拡張が拾いづらいのだと思っていたが、そうではない。推定を前期繰越の内訳にしか使っていなかった、という作りの問題だった。
そこで推定を、当年度の行のバッジにも広げさせた。摘要の対象期間、同額、古い順、の順に当てにいく。推定で消えた行は「済·推定」と出して、メモに参照がある行と区別する。「未紐付け」に残すのは、推定でも当てられなかった行だけにした。
直したのに、数字が1件も減らない
直った版で見てくれと言われて、開いた。未消込157件、未紐付け33件。修正前とまったく同じ数だった。
意図が伝わっていないのではないかと疑った。実際は逆で、修正が画面に届いていなかった。表示中のページには直した後の CSS も判定も入っていない。前にリロードした後でさらに手が入ったので、古い版のまま動いていた。直したコードのほうは実データで検算済みだった。未消込に残るのは9月7日と9月9日の27,280円だけ、というところまで確かめてある。
「直した」と「画面に届いた」は別だ。バッジの数が修正前と1件も変わらないときは、判定を疑う前に、いま動いている版を疑ったほうが早い。
貸方残の科目で破綻していないか
次に預り金の住民税を開いた。そこで気になったのは、推定のロジックが資産科目に寄っていないか、という点だった。売掛金は借方が発生で貸方が消込になる。預り金は逆で、貸方が発生、借方が消込だ。借方残高しか前提にしていないなら、負債科目では発生と消込が入れ替わって破綻するはずだ。
聞いてみたら、貸方を発生、借方を消込として扱う作りに最初からなっていた。実機で預り金と住民税を見ると、8か月分がすべて「済·推定」で、事業主振替8本も1対1で当たっている。破綻していると思って見ていた画面は、例の古い版が動いていた時間帯のものだった。
預り金に「未消込」として残っている行もあったが、これはバグではなく帳簿の実態だという。仮説は外れた。ただ、外れ方を確かめたおかげで、負債側の判定を実機で一度通せた。
書き戻す前に、仕訳を落としておく
2025年度への書き戻しに進む前に、仕訳をダウンロードしてバックアップを取らせた。編集ロックを外して過去年度のメモを書き換える以上、元に戻せる材料は手元に置いておきたい。JSON と CSV は gitignore に入れて、ローカルにだけ残してある。
書き戻しが終わってから編集ロックを戻し、拡張の表示が推定から確定に切り替わったことを確認した。
補助元帳を見ているのに、科目全体の内訳が出る
補助科目のある科目で、もうひとつ気づいた。決済サービス別の補助元帳を開いているのに、内訳を開くと科目全体の期首残高が出てくる。いま見ているのは補助科目1つ分なのだから、出てほしいのは、その補助科目の前期繰越12.7万円のほうだ。売掛金そのものを開いたときに55万円の内訳が出るのは、それはそれで正しい。
補助元帳を開いているときはその補助科目だけ、総勘定元帳では科目全体、と分けて出すように直させた。スクリーンショットで、前期繰越の内訳が4件、合計が補助科目の残高と一致するところまで確認した。
マウスが遅い
昼を回ったころ、PC全体が重くなった。文字入力が遅れて、マウスカーソルまで引きずるように動く。帳簿チェックの拡張のチェックを外しても戻らない。
計測させたが、CPU使用率20%、割り込み0.5%、DPC 0.2%、メモリも切迫していない。ドライバ由来の遅延ならここが跳ねるはずの数値が、どれも低い。原因は分からなかった。
Chrome を終了させたら、その瞬間にマウスが元の速さで動いた。犯人はブラウザの内側にいそうだ。セッションのコンテキストが84%まで来ていたので、引き継ぎのプロンプトだけ出させて、いったんセッションを切った。
重さの原因はどこにいたか
午後に別のセッションを立てて、まず重さの切り分けから始めさせた。
原因は、拡張の content.js が自分の描画で自分を起こし続けるループだった。DOM の変化を見た MutationObserver が要素を描き、その描画がまた MutationObserver を起こす。今日書いた消込の実装ではなく、9月5日に入れた課税形式のバナーが持ち込んだものだった。
修正してテストは219本とも通り、実機でループが消えていることも確認した。計画書の実行項目29件は、これで全部埋まった。両方のリポジトリをコミットして終わりにした。
学び
- 消込の紐付けは、発生側から1本ずつ探すのではなく、元帳の減らす側を全部取って逆引きの索引を作れば済む
- 「消えた証拠がない」は「消えていない」ではない。証拠が無いものを未消込として出すと、CSV取込で摘要が空の帳簿では全滅する
- バッジの数が修正前と1件も変わらないときは、判定より先に「いま動いている版」を疑う
- 過去年度に書き戻す前に、仕訳を落としておく。編集ロックを外して触るなら、戻せる材料が要る
- 動作が重いときの犯人は、今日触ったところにいるとは限らない