残高が違うとき、どの数字から調べるか
表示用の残高、取引の元帳、銀行全体の会計。三つの見方を並べると、食い違いを「直す前に説明する」道筋が見えます。
本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け（非公開GitHub）です。GitHubで閲覧権限がある方だけ開けます。
この記事でわかること
- キャッシュ・元帳・GLが答える問いの違い
- 借方と貸方が一致していても、取引の正しさは別に確かめる
- 不一致の観測、原因調査、承認付きの修復を混同しない
この記事の目次
三つの残高は、三冊の独立した正本ではない
口座画面に素早く出すための数字が cached_balance、誰の勘定がどう動いたかの内訳が元帳、銀行全体を科目ごとにまとめるのが GL です。キャッシュとは捨ててよい適当な数字ではなく、元帳から導ける結果を保存しておくものです。一方、GLは新しい取引をもう一度起こす別帳簿ではなく、元帳の行を会計科目の対応表で集約します。
たとえば顧客ごとの預金勘定は普通預金2100番、SYSTEM_FUNDINGは現金1000番へ対応します。預金は銀行の負債なので貸方−借方、現金は資産なので借方−貸方で自然な残高を表します。どちらにも一律に同じ引き算をすると、正しい数字を異常だと思い込んでしまいます。
この章の問いは、画面と帳簿のどちらを信用するかという二択ではありません。「表示は元帳から説明できるか」「元帳は業務の出来事と一致するか」「その集約が銀行の会計としてつながるか」を順に確かめます。固定コードの設計を読むもので、稼働中の口座を調べた報告ではありません。
1千円のずれは、どの層にあるのか
架空の例として、葵さんの元帳残高が4万2千円、蓮さんが1万8千円で、顧客預金の合計が6万円だとします。ところが葵さんの cached_balance だけが4万3千円なら、口座キャッシュの合計は6万1千円です。GLの普通預金は元帳の集約なので6万円となり、GL残高−補助明細の合計はマイナス1千円になります。
この観測から言えるのは「口座別の表示用残高と元帳集計の間に差がある」ことです。まだ、どの取引が原因か、元帳自体は完全か、過去の移行時点で起きたかは分かりません。「キャッシュだけが間違い」と先に断定するのは一段飛ばしています。業務記録や仕訳のつながりを調べる必要があります。
逆に、葵さんがプラス1千円、蓮さんがマイナス1千円だけずれていたら、キャッシュ合計は6万円のままです。GLと総額が一致しても、各口座の正しさは保証できません。全体の照合と口座別の照合を両方置く理由がここにあります。これは検査の強さの違いであり、どちらか一方が不要という話ではありません。
貸借が合うだけでは、振込先の誤りを見抜けない
1万円の振込を考えます。送金元から1万円を減らし、間違った第三者に1万円を増やしても、借方合計と貸方合計だけは一致します。したがって「仕訳が釣り合う」という検査は必要ですが、それだけでは業務の意味まで正しいことになりません。
追加の照合は、振込記録にある金額・通貨・送金元・送金先と、結び付いた仕訳を比較します。内部振込の仕訳が二行か、送金元への借方と送金先への貸方がそれぞれ振込金額と同じかを確かめます。入出金などの業務記録についても、結び付いた仕訳の合計と業務金額・通貨を比較する検査があります。
さらに、完了済みの振込依頼が本当にその利用者、その送金元、その宛先、その金額の振込へつながっているかを見ます。「依頼は完了なのに結果が別人のもの」という不一致は、口座残高だけの検査では見つかりません。残高、仕訳、業務、依頼という異なる記録を結び直すことで、原因の候補を絞れます。
調査では、数値と一緒に観測の時刻を残す
照合結果には、実行ID、検査の種類、開始・完了時刻、調べた件数、問題件数が必要です。同じ「不一致1件」でも、どの範囲をいつ見たのかが分からなければ、その後の調査と結び付けられません。MiniBank の観測用の読み取りは、検査のまとまりと、問題の種類・対象別の件数、調査案件や修復依頼の状態を返します。
注意すべきなのは、結果が「検査中ずっと世界が止まっていた」という証明ではないことです。実装は、確定済みの文ごとの観測であり、金融記帳は原子的に行われるという観測窓を示しています。別の時刻に取った画面の残高と集計表を雑に比較すると、その間の正当な取引を不一致と見間違うことがあります。
調べるときは、問題の実体IDと種類から、その検査が見た記録へ戻ります。残高差なら口座と元帳、振込と仕訳の差なら振込IDと仕訳ID、依頼の差なら依頼IDと結果IDです。個々の行を見ずに合計だけを合わせるより手間はかかりますが、「何が直ったのか」を説明できる証拠を残せます。
修復は、観測結果とは別の承認付きの行為
現行の通常記帳は、対象口座をロックした後、既存の cached_balance と元帳集計の差を検査します。差があれば LG018 で止めます。新しい入金のついでに古い差を消してしまうと、根本原因が隠れるからです。これは便利さを少し犠牲にして、分からない状態へ取引を重ねない設計です。
管理側には残高修復を提案・確認する別の経路があります。提案時には、観測したキャッシュ残高、元帳残高、理由、提案者を保存します。確認時には別の有効な管理責任者が必要で、版番号や状態、営業日の条件を確かめます。口座をロックして再集計し、提案したときと証拠が変わっていたら、その古い提案では修復できません。
この制御があるからといって、元帳を見ずに「差が出たら修復を押す」と覚えるのは逆です。修復はあくまで原因と正しい値を確認した後の行為です。調査案件の解決も、別人による確認と新しい整合性検査を要求し、同じ問題が残れば閉じられません。本記事は仕組みの説明であり、修復の実行指示ではありません。
実装の読み方：修復前後ではなく、承認条件を見る
以下は読み取り用の擬似コードです。関数の直接呼出しや残高更新は行いません。
提案：口座・二つの観測値・理由を保存
確認：提案者と別の管理責任者か
確認：版番号と状態がまだ同じか
再読：口座をロックして証拠を再確認
変化あり → 古い提案を拒否
解決確認 → 新しい検査でも問題が残らないかGLが一致しても、銀行全体の保証にはならない
普通預金の照合に加えて、定期預金は有効な契約元本、未決済為替は所定の状態にある他行送金、仮受金は未解消明細と、対応するGL科目を比較します。同じ「補助元帳の照合」でも対象の定義が違います。たとえば結果不明の他行送金を勝手に除外すれば、見かけ上の差を小さくしてしまうおそれがあります。
銀行会計の締め検査には、試算表の貸借、貸借対照表、補助明細、未対応の勘定、記帳の整合性など複数の項目があります。検査を通ることと、その世界に起き得るあらゆる誤りがないことは同じではありません。未対応勘定や対象外データがないかも含めて、何を調べた結果なのかを読む必要があります。
この読み物では銀行のデータベースを操作せず、試験も走らせていません。「検査コードが用意されている」という証拠から、「いま稼働中の全残高が一致する」という結論へは進みません。いまの不一致を扱うには、対象環境、対象時刻、権限、当該実行の証拠が別に必要です。
出典と、確認できた範囲
以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。
- GLと補助明細の照合 ↗（非公開GitHub・要権限）
元帳由来のGL、残高の符号、補助明細ごとの比較範囲 - 照合の観測と修復制御 ↗（非公開GitHub・要権限）
業務と仕訳の意味の照合、調査案件と独立確認 - 通常記帳の不一致拒否 ↗（非公開GitHub・要権限）
LG018と修復を通常取引から分ける境界 - 口座別の不変条件 ↗（非公開GitHub・要権限）
総額だけではなく口座別に比較するテストの存在
MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。
つながる読み物
ここまで読んだ記録を、ひとつ。
自分のペースで。あとから取り消すこともできます。