イミュータブル台帳とは何か : 監査証跡と、仕訳の削除がバグである理由

イミュータブル台帳（immutable ledger）とは、一度起票された仕訳を決して変更せず、削除もしない台帳のことです。修正を行うには、古い仕訳を相殺または調整する新しい仕訳を追加するため、帳簿の履歴そのものが帳簿の一部となります。

これは単なる技術的な好みではありません。会計記録を過去の現在時点での意見ではなく「証拠」たらしめている本質であり、だからこそ「仕訳データに削除ボタンを追加してほしい」という要望は拒絶されなければならないのです。

編集と削除がすべてを壊す理由

監査証跡（audit trail）こそがプロダクトである。 複式簿記の目的は、すべての残高がそれを生み出した仕訳に分解できることにあります。もし仕訳が密かに改変可能であれば、その分解は何の証明にもなりません。証跡が示すのは、誰かが直近において「そうであってほしい」と決めた結果に過ぎなくなります。

申告済みの数値と帳簿が一致しなくなる。 3月に提出されたVAT申告（VAT return）には、3月の数値が記載されています。6月に3月の請求書を編集してしまうと、あなたの台帳はすでに税務署へ提出済みの書類と一致しなくなります。誰もそれに気づかないまま照合（reconciliation）が行われ、気づいた頃には何ヶ月分もの取引が間に挟まれている状態になります。

不正が不可視化される。 不正の検出は、何かが変更された事実を把握できることに依存しています。仕訳がその場で編集できる環境では、確認すべき変化が何も存在しません。EU全域の税務当局が会計記録の改ざん検知機能（tamper-evident）を義務付けており、複数の国がまさにこの特性に基づいて請求書発行ソフトウェアの認証を行っているのは、まさにそのためです。

分散された状態が乖離する。 顧客に請求書を送り、銀行ファイルにエクスポートし、電子インボイス（e-invoicing）プラットフォームに送信し、パートナー企業向けAPIで読み取られた場合、自社の手元にあるデータを編集しても相手側のデータは1ミリも変わりません。あなたはエラーを修正したのではなく、不整合を作り出したのです。

修正の実際の仕組み

正当な修正はすべて追加によって行われます。

状況	正しいメカニズム
仕訳の誤り	その逆仕訳を起票し、その後に正しい仕訳を起票する
請求金額の誤り	クレジットノート（credit note）を発行し、必要に応じて新しい請求書を発行する
属する期間の誤り	現在のオープンな期間に、修正を行った日付で起票する
見積もりの変更	見積もり（accrual）を逆仕訳し、実績を計上する。詳細は未収収益（accrued revenue）を参照

その結果、記録は一つの物語として読めるようになります。「私たちはこのように考えていた」「このように状況の変化を知った」「したがってこのように修正した」という経緯です。「請求書 S-1041 はどうなりましたか？」と尋ねる監査人に対し、最初からずっとその数値であったかのように装うのではなく、完全な回答を提示できるようになります。

このアプローチのコストは、台帳に誤りが永遠に残ることです。しかしそれこそがポイントです。修正の履歴が一切存在しない企業は、並外れて運が良いか、あるいは帳簿を書き換えているかのどちらかです。

イミュータブル台帳が意味しないこと

• 「何も修正できない」という意味ではない。 いかなる事項も修正可能です。ただし、上書きではなく追加によって修正が行われます。
• ブロックチェーンのことではない。 暗号学的チェーン（cryptographic chaining）は改ざん検知を実現するための一つの実装方法に過ぎません。厳格な制約と監査ログを備えた追記型のリレーショナル台帳であれば、分散合意（distributed consensus）という余分な負担なしに、必要な会計特性を実現できます。
• 監査ログと同じ意味ではない。 監査ログは「誰が何をしたか」を記録するものです。イミュータブル（不変性）とは、会計データそのものが変更されないことを意味します。両方が必要であり、それぞれ異なる問いに答えるものです。
• 下書き（draft）には適用されない。 下書きの請求書は作業中の文書であり、自由に編集できます。不変性が適用されるのは**発行（issue）**の瞬間から、すなわちその文書が外部の誰かにとって実体を持つようになった時点からです。

Nordletにおける強制の仕組み

慣習ではなく、すべて構造的な3つのメカニズムによって強制されます。

起票済みの仕訳は追記型である。 仕訳は一度書き込まれたらそれまでです。起票済みの取引を編集または削除するエンドポイントは存在せず、POST /v1/ledger/journal/transactions/create は書き込み前に検証を実行します。借方と貸方が一致していること、勘定科目が存在し起票可能であること、期間がオープンであることが条件となります。バランスの取れていない台帳は、データベースが表現できない状態です。

期間がロックされる。 POST /v1/ledger/periods/lock により月次が締められ、ロックされた期間に属する日付を持つ取引は拒絶されます。手動入力、請求書、銀行からのインポート、自動認識処理のいずれを経由するものであっても同様です。期間ロックがあるからこそ、提出済みの申告書と帳簿が恒久的に一致するのです。また、ロックの解除自体が監査対象のアクションとなります。ワークフローの詳細については会計期間（accounting period）の記事を参照してください。

すべてが監査される。 状態を変更する操作は、実行者、アクション、エンティティ、およびdiff（差分）とともに監査ログに記録されます。自動処理の場合も、人間がやったかのように偽るのではなく、システムアクターとして記録されます。企業間ミラーリングによって請求書が作成された場合、双方の企業のログにそれが記録されます。

文書も同じルールに従います。売上請求書を発行すると、歯抜けのない連番から番号が割り当てられて起票されます。後から修正するには、編集ではなくクレジットノートを発行する必要があります。元の請求書、クレジットノート、および結果としての残高のすべてが、顧客の履歴に残り続けます。

下書き文書は完全に編集可能なままであり、削除は**論理削除（soft delete）**として処理されます。deletedAt タイムスタンプを付与することでアクティブなクエリからは非表示にしつつ、データ自体は保持されます。

FAQ

イミュータブル台帳とは何ですか？

起票された仕訳を決して変更も削除もしない会計台帳のことです。修正を行うには、逆仕訳や調整仕訳を追加するため、誤りとその修正を含む完全な履歴が記録の一部として残り続けます。

間違った仕訳をそのまま削除してはなぜいけないのですか？

その仕訳がすでに税務申告、顧客に送付された文書、あるいは他システムの記録に反映されている可能性があるためです。削除してしまうと、あなたの帳簿とそれらの記録が密かに不一致を起こすことになります。逆仕訳を行うことで、何が起きたのかの証拠を残したまま数値を正しく修正できます。

イミュータブル台帳にはブロックチェーンが必要ですか？

いいえ。ブロックチェーンは記録の改ざんを検知するための一つの手段に過ぎません。厳格な貸借一致の制約、期間ロック、監査ログを備えた追記型のデータベース設計を採用すれば、分散合意の負担なしに、必要とされる会計上の特性を実現できます。

下書きの請求書は編集できますか？

はい。不変性が適用されるのは、文書が発行され、外部の誰かにとって実体を持つようになった瞬間からです。下書きは作業中の文書であるため、自由に変更や削除が可能です。

締め切られた期間の仕訳を修正するにはどうすればよいですか？

現在のオープンな期間に、修正を行った日付で修正仕訳を起票します。もし締められた期間の報告数値に重大な誤りがあった場合の代替手段として、意図的に期間を再オープンし、修正を行い、再報告と再ロックを行う方法もあります。これは監査対象となるアクションであり、修正再表示（restatement）を行うための誠実なアプローチです。