会計保証と証拠の設計
借貸一致は出発点です。業務取引が漏れなく正しい勘定へ一度だけ記帳され、Subledger・GL・表示残高・監査まで追跡できることを、複数の証拠で保証します。
境界、transaction、並行制御、脅威、テスト、障害対応をFailure Firstで学ぶ。
先に学ぶ内容 — Prerequisite: 基礎 / 銀行システム学ぶこと — LEARNING GOALS
このページで学ぶこと
- Completeness・Accuracy・Occurrence
- GLとSubledgerのcontrol
- 証拠の独立性と限界
体験27 · ACCOUNTING ASSURANCE（会計保証の限界）
試算表の借方・貸方が一致していれば、記帳はすべて正しいと言えるか確かめよう
まずは予想をひと言。本文を読んだ後、実際の管理画面で会計証拠を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
試算表（Trial Balance）の借方合計と貸方合計が一致していれば、すべての取引が漏れなく正しく記帳されていると証明できるでしょうか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
借方合計と貸方合計は、複式簿記が正しく動いていれば数学的に必ず一致します。それは何を証明していないのでしょうか？
ヒント2を見る
「一致すること」と「漏れがないこと」は同じ主張でしょうか？
もっと詳しく：この問いで使う専門用語
- Completenessは、実在するすべての取引が漏れなく仕訳になったかという主張です。
- Trial Balance（試算表）は、全勘定科目の残高を借方・貸方に振り分けて並べた一覧です。
- Rule conformanceは、各仕訳が投稿時点のAccounting Rule版と一致しているかを比較する検査です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
会計保証では、存在・完全性・正確性・期間・一意性を別々の主張として確かめます。
借貸一致、Trial Balance、Rule conformance、GL↔Subledger照合、Auditは互いの検出限界を補います。
差異を見つけた後の停止・補正・再照合・再発防止までがcontrolです。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Completeness
記録すべき取引が漏れなく記帳されたという主張です。
借貸一致した仕訳だけ見ても、仕訳にならなかった取引は見えません。
business transactionとjournalの差分を照合します。
Control account
Subledger明細の合計を表すGL勘定です。
合計と内訳を独立に比較できます。
TIME_DEPOSITS_PAYABLEとtime_deposits契約元本を対応づけます。
Rule conformance
各仕訳に投稿時点で固定されたAccounting Ruleの版と、実際の勘定・方向・金額を比較する検査です。
左右同額でも誤勘定へ記帳する誤りを見つけ、rule変更後も当時の基準で再検証するためです。
journal_entries.accounting_rule_definition_idからrule_code・versionをたどり、Journal Linesと比較します。
Trial Balance（試算表）
全勘定科目の残高を借方・貸方に振り分けて並べた一覧です。
複式簿記が正しく機能していれば借方合計と貸方合計は数学的に必ず一致するため、崩れがあれば異常の signal になります。
`/admin/accounting/trial-balance`が全科目残高から借方合計・貸方合計・差額を計算して表示します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
会計controlが答える5つの主張
| 主張 | 問い | Minibankで見る証拠 |
|---|---|---|
| Occurrence | 存在する仕訳は実在取引に基づくか | business record・actor・rule reference |
| Completeness | 実在取引がすべて仕訳になったか | 取引↔journalの差分照合 |
| Accuracy | 金額・通貨・勘定が正しいか | Accounting Ruleとjournal lines |
| Cutoff | 正しい時点・期間へ記録されたか | occurred_at・business date・maturity |
| Uniqueness | 同じ取引を二重記帳していないか | idempotency identity・unique constraint |
証拠の鎖
- 01利用者またはoperatorの操作
- 02認可済みbusiness transaction
- 03投稿時にACTIVEなAccounting Rule versionを解決
- 04Journal Entryがrule definition IDを固定参照
- 05balanced Journal Lines
- 06GL balance
- 07Subledger detail
- 08Trial Balance
- 09Reconciliation result
- 10Integrity issue
- 11Audit trail
検査が互いを補う
| 検査 | 検出できる | 単独では検出できない |
|---|---|---|
| 借貸constraint | 片側欠落・不均衡 | 左右同額の誤勘定 |
| Trial Balance | 全体の算術的不均衡 | 取引自体の欠落・重複 |
| Rule conformance | 投稿時rule版と実際の勘定・方向・金額の不一致 | 業務record自体の欠落 |
| GL↔Subledger照合 | 統制勘定と明細合計の差 | 双方へ同じ誤りを二重反映 |
| Audit | actor・時刻・操作経緯 | 金額の会計的正しさ |
差異を見つけた後の設計
- 01差異をimmutableなissueとして記録
- 02影響取引・顧客・金額・期間を特定
- 03追加処理を止めるかseverityで判断
- 04元recordを変更せずreversal・補正eventを承認
- 05再照合して差異解消を確認
- 06root causeをconstraint・test・alertへ戻す
実際のMinibankでは
Accounting Rule Registryは `rule_code・version・status` を持つversion管理済みの正本です。`activate_rule()` は旧ACTIVE版をINACTIVEにして新しい版を有効化しますが、投稿済みJournal Entryの `accounting_rule_definition_id` は変わりません。Journal Explainは現在のruleを推測せず、その仕訳が投稿時に固定した版を表示します。
組戻しでは、反転方法を表す `REVERSAL_STANDARD` と、元仕訳が固定した会計rule版を並べます。Registry、Journal Explain、Time Deposit Transaction Story、Trial Balance、Reconciliation、Integrity、Auditは異なる証拠であり、1つの画面だけを正しさの唯一の証明にしません。これらは法定監査や規制報告そのものではありません。
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
会計保証の5つの主張を読んだところで、実際の管理画面を確認し、自分の言葉で説明してみます。
- 02実際に観察する — OBSERVE
同じ仕組みを、動く画面から観察する
この仕組みは管理者向けの画面で確認できます。管理者ログインがない場合は、この教材内の図・説明・Source Trail（教材の参照元）で代替学習し、次へ進めます。
管理者ログインがない場合：教材の参照元で確認する ↓ - 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず試算表とJournal Explainを計算するservice層を見て、次に仕訳がrule版をどう固定するかをmigrationで見ます。一致することと正しいことの違いを確かめましょう。
教材の参照元を確認する — Source Trail ↓Trial BalanceとJournal Explainを計算するservice層。
src/services/AdminAccountingService.tsMigration（DB定義の変更履歴）。仕訳投稿時にrule版を固定する箇所を確認します。
supabase/migrations/20260828210005_connect_journal_rule_trace.sql - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜ試算表の借方・貸方が一致していても、すべての取引が正しく記帳された証明にはならないのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Completeness」と「Rule conformance」という2つの言葉を使って書いてみましょう。
ヒント2を見る
同じ誤りが借方と貸方の両方に起きたらどうなるか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Completeness、Control account、Rule conformanceの3つを使って、会計保証が複数の証拠を組み合わせる理由を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 一致することと漏れがないことは別の主張だと説明できる
- 個別の仕訳がrule版を固定して保持していると説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1Trial Balance一致で完全性を証明できますか？
できません。取引と仕訳が両方欠落しても借貸は一致するため、業務recordとの照合が必要です。
Q2GLとSubledgerが一致すれば両方正しいですか？
必ずしも正しくありません。同じ誤りを双方へ反映した場合に備え、rule・業務record・auditも確認します。
Q3Rule v2をACTIVEにすると、過去にv1で投稿した仕訳もv2として評価されますか？
されません。各Journal Entryは投稿時のrule definition IDを保持し、v1を永久に参照します。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260828210001_accounting_rule_registry_schema.sqlaccounting.activate_rule()version管理された正本rule - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260828210005_connect_journal_rule_trace.sqlJournal投稿時のrule版固定 - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260828220001_explain_rule_trace.sql組戻しruleと元仕訳ruleの二重trace - 現在の実装 — CURRENT IMPLEMENTATION
src/services/AdminAccountingService.tsTrial Balance・Reconciliation・Story