監査証跡とは？改ざん防止の従来手法とブロックチェーン活用を解説

監査証跡は、業務やシステムの操作を後から検証するための記録です。J-SOXや電子帳簿保存法への対応、IPO準備などの場面で、その管理方法が問われます。

ただし、記録を残すだけでは十分とはいえません。監査で問われるのは、その記録が後から書き換えられていないと示せるかどうかです。本記事では、監査証跡の基本と従来の改ざん防止手法を整理したうえで、ブロックチェーンで何が変わり、どう設計すべきかを開発の現場の視点から解説します。

監査証跡とは ― 業務やシステムの操作を後から検証するための記録

監査証跡とは、業務やシステム上で「いつ・誰が・何を・どのように」行ったかを時系列で記録し、後から第三者が検証できるようにした記録です。内部統制や監査において、業務が規程どおりに行われたことを示す客観的な証拠になります。

定義 ― 「いつ・誰が・何を・どのように」の記録

監査証跡は英語で「オーディットトレイル（Audit Trail）」と呼ばれます。仕訳の登録や修正、システムへのログイン、権限の変更、データの削除など、業務上の重要な操作を時系列に沿って残した記録の総称です。

ポイントは、記録が一連の流れとして追跡できることにあります。ある取引を誰が入力し、誰が承認し、いつ修正したのか。この流れを後からたどることで、業務が規程どおりに行われたかを検証できます。

監査ログ・証憑との違い

混同されやすい言葉に、監査ログと証憑があります。

監査ログは監査証跡を構成する個々のデータ、証憑は取引そのものの証拠です。監査証跡は両者を結びつけ、取引がどのような手続きを経たのかを示します。

記録すべき主な項目

一般的に求められる項目は次のとおりです。

• 操作日時：操作が行われた正確な日時
• 操作者：誰が操作したか（ユーザーIDや権限）
• 操作内容：作成・閲覧・変更・削除・承認などの種類
• 対象データ：どのデータやファイルに対する操作か
• 変更前後の値：何がどのように変わったか
• アクセス元：端末やIPアドレスなど、どこから操作したか

見落とされやすいのが変更前後の値です。「変更があった」ことしか分からない記録では、何が書き換えられたのかを検証できません。

監査証跡が重要とされる理由

監査証跡が重視される理由は、内部統制が機能していることの証明、法令が求める記録保存への対応、不正の抑止と事後調査の3点にあります。いずれも、記録が残っているだけでなく、その記録が改ざんされていないと示せることが前提です。

内部統制と監査への対応（J-SOX）

上場企業には、金融商品取引法に基づく内部統制報告制度、いわゆるJ-SOXへの対応が求められます。財務報告の信頼性を確保する仕組みが機能していることを経営者が評価し、監査人の監査を受ける制度です。

このうちITに関わる統制では、システムへのアクセス管理や変更管理が適切に運用されているかが評価されます。その運用状況を確認する資料の一つが、操作履歴などの監査証跡です。IPOを目指す企業も、上場準備の段階から整備が求められます。

法令・規制への対応と保存期間（電子帳簿保存法など）

電子帳簿保存法では、電子取引のデータを保存する際に「真実性の確保」が求められます。タイムスタンプの付与、訂正・削除の履歴が残るシステムでの保存、事務処理規程の整備といった措置のいずれかで、改ざんされていないことを担保しなければなりません。

保存期間については、法人税法上の帳簿書類は原則7年、青色申告書を提出した事業年度に欠損金額が生じた場合などは10年です。一方、監査証跡やシステムログ全般に一律の保存期間が定められているわけではありません。対象の法令や監査要件、社内規程に応じて期間を決め、システムの保持期間が足りなければ外部へ定期出力する運用が必要です。

不正の抑止とインシデント発生時の原因調査

監査証跡には、不正を未然に防ぐ効果もあります。操作が記録され検証されると分かっていれば、不正の動機そのものが弱まるためです。

情報漏えいや不正アクセスの際にも、監査証跡が原因調査の手がかりになります。どのアカウントが、いつ、どのデータにアクセスしたのかを追えなければ、被害の範囲も再発防止策も特定できません。いずれの目的でも前提になるのは、記録そのものが改ざんされていないと示せることです。

従来の改ざん防止手法とその限界

従来の監査証跡の改ざん防止で代表的なのは、ログを専用の保管場所に隔離し、アクセスできる人を絞り込む「隠して守る」方式です。改変を制限・検証する手法もありますが、いずれも特定の主体への信頼が前提となる点は変わりません。

専用ストレージへの隔離とアクセス権限の制限

最も一般的なのが、ログを業務システムとは別の専用ストレージへ転送し、そこへのアクセス権限を限られた担当者に絞る方法です。利用者がログに触れられない構成にして、操作の痕跡を消されるリスクを抑えます。

ログ管理製品やクラウドの保管サービスも基本は同じ考え方で、多くの企業で実績があります。

追記型（WORM）ストレージ・タイムスタンプの活用

より強固な手法として、追記型（WORM：Write Once Read Many）ストレージがあります。一度書き込んだデータを、保存期間中は変更も削除もできないようにする仕組みです。

タイムスタンプも有効な手段です。第三者機関が付与することで、その時刻にデータが存在し、以降に改ざんされていないことを証明できます。

「隠して守る」方式の限界 ― 管理者権限への依存

このうち、専用ストレージへの隔離とアクセス権限の制限は、ログに近づける人を絞り込むことで守る考え方です。実装の現場では、これを「隠して守る」方式と整理しています。

隠して守る方式は有効ですが、管理者権限を持つ者が記録を変更した場合、外部の監査人や取引先がそれを独立して確かめるのは容易ではありません。WORMストレージやタイムスタンプは管理者による改変を制限・検証できる点で一歩進んだ手法ですが、その保証も保存基盤の提供者や時刻認証事業者への信頼に支えられています。

ブロックチェーンを使うと何が変わるか

ブロックチェーンを使うと、監査証跡の守り方そのものが変わります。データを隠して守るのではなく、複数の場所に複製して保管し、改ざんの有無をハッシュ値で即座に検証するという発想への転換です。

「隠して守る」から「ばらまいて検証する」へ

ブロックチェーンを活用した監査証跡で根本的に変わるのは、データの守り方です。アクセス制御を中心とする従来方式がデータを「隠して守る」発想だったのに対し、ブロックチェーンを使う場合は逆に、データを複数の場所にコピーして「ばらまく」ほうがむしろ望ましいです。

実装の現場では、この変化を「隠して守る時代から、ばらまいて検証する時代への転換」と捉えています。どこに保管されたデータであっても、記録時点のデータと同一かどうかを同じ方法で確かめられるため、保管場所を隠しておく必要性そのものが薄れるからです。

ここでいう「ばらまく」は、機密性の高いログを誰でも見られる状態にする意味ではありません。アクセス制御を保ったまま、社内の複数拠点や外部の保管先に複製を置くことを指します。ブロックチェーンに記録するのはハッシュ値だけで、ログの中身は公開されません。

ハッシュ値による改ざん検知の仕組み

この検証を支えるのがハッシュ値です。ハッシュ値とは、データから一定の計算で求められる固有の文字列で、「データの指紋」にたとえられます。元のデータが1文字でも変われば、まったく異なる値になるのが特徴です。

ログを記録した時点でハッシュ値をブロックチェーンに書き込んでおけば、後から手元のデータのハッシュ値を計算し直し、記録済みの値と照合するだけで改ざんの有無が分かります。データに変更があればすぐに判別できるため、短時間で検証できます。ブロックチェーン上の記録は参加者間で共有・検証されており、後から書き換えることは極めて困難です。

なお、ブロックチェーンが保証するのは記録後の改ざんを検知できることであり、記録した時点のデータが正しいかどうかまでは保証しません。誤った操作記録をそのまま書き込めば、その誤りが書き換えにくい形で残るだけです。

検知はできても復元はできない ― 原本の分散保管が前提

ブロックチェーンには明確な限界もあります。改ざんされたことは検出できても、オリジナルのデータがなければ元の状態には戻せません。ブロックチェーンに残っているのはハッシュ値であって、ログの中身ではないからです。

だからこそ、原本の複製を複数の場所に保管しておくことが前提になります。どこかのデータが改ざんされても、別の場所にある複製を持ってきて、そのハッシュ値がブロックチェーン上の記録と一致すれば、記録時点と同一の内容だと確認できます。「ばらまいて検証する」とは、検知の仕組みと分散保管をセットで設計することにほかなりません。

オンチェーン／オフチェーンの設計

実務では、監査ログの本体をすべてブロックチェーンに書き込むことはしません。データ本体は低コストな保管先に置き、その要約であるハッシュ値だけを信頼性の高いチェーンに記録する設計が基本です。

すべてのログをオンチェーンに書かない理由 ― コストと機密性

理由は2つあります。1つ目はコストです。パブリックチェーンでは書き込みに手数料がかかるため、大量のログをそのまま記録すると費用が膨らみます。

2つ目は機密性です。監査ログには、取引内容や個人情報、社内の操作履歴など外部に出せない情報が含まれます。パブリックチェーンに書き込んだデータは原則として誰でも参照でき、後から消すこともできないため、中身をそのまま載せる設計は現実的ではありません。

データ本体はオフチェーン、ハッシュ値をオンチェーンに

そこで基本となるのが、データのハッシュ値だけをオンチェーンに記録する設計です。ログ本体は既存のストレージやクラウドなど安価な保管先に置き、そのハッシュ値をイーサリアムのメインチェーンのような信頼性の高い場所に記録します。

ハッシュ値が変われば元のデータが変わったと分かるため、改ざん検知として十分に機能します。実務では、一定期間のハッシュ値を1つに集約して記録し、書き込みの回数と手数料を抑える方法も用いられます。

記録先の選び方 ― パブリック型・パーミッション型とレイヤー2の考え方

ハッシュ値の記録先は、検証する相手に加え、公開範囲、費用、運営主体への依存、必要な処理性能を比較して選びます。外部の監査人や取引先、規制当局にも独立して確認してもらうなら、特定の企業が管理しないパブリック型が適しています。社内やグループ内での検証が目的なら、参加者を限定するパーミッション型も選択肢の一つです。

この設計は、レイヤー2、特にロールアップ型の設計思想にも通じる部分があります。代表的なロールアップは、大量の処理をメインチェーンの外で行い、検証に必要なデータや証明をメインチェーン側へ記録する仕組みです。何を記録するかは方式によって異なりますが、処理の負荷を基盤のチェーンの外へ逃がしつつ、信頼の拠り所を基盤チェーンに置く発想は、監査証跡の設計にも通じます。

関連記事：エンタープライズブロックチェーンとは？企業導入のメリット・事例を徹底解説

既存システムへの後付け導入と進め方

ブロックチェーンを使った監査証跡は、既存システムのログ取得や外部連携が可能であれば、システムを作り替えずに導入できる場合があります。既存のデータ保管はそのままに、ハッシュ値を記録するブロックチェーン層を追加する構成が現実的な選択肢です。

「既存システム＋ブロックチェーン層」という構成

ERPや会計ソフト、業務アプリなどの既存システムを、必ずしもフルリプレイスする必要はありません。要件次第ではあるものの、後付けでシンプルに導入するなら、既存システムのデータ保管先はそのまま使い、ハッシュ値を記録するためのブロックチェーン層を追加する形になります。

具体的には、既存システムのログを取得してハッシュ値を計算し、ブロックチェーンへ記録する仕組みを間に挟む構成です。ただし既存システムによっては、ログの出力機能やAPI連携、検証フローを追加で開発する必要があります。実装の現場でも、「既存システム＋ブロックチェーン層の追加」という構成は現実的に実現できると判断しています。

関連記事：秘密鍵管理にMPCが必要な理由とは？toCサービスのウォレット設計を解説

導入の進め方 ― 対象ログの選定から検証フローの設計まで

導入は、次の順序で進めると手戻りを防げます。

1. 対象ログの選定：会計データの修正や権限変更など、改ざんされた場合の影響が大きいものから選ぶのが基本です。
2. ハッシュ化の単位と頻度の決定：1件ずつ記録するか、一定時間ごとにまとめるかを決めます。頻度を上げるほど検知は早まり、コストは増える関係です。
3. 原本の保管設計：改ざん時に復元できるよう、原本の複製をどこに何か所保管するかを決めます。
4. 検証フローの設計：誰が、いつ、どのようにハッシュ値を照合するのかを決め、監査人が自ら検証できる手順を用意しておくことが重要です。

特に4つ目が抜けると、記録はしていても誰も検証しない状態に陥ります。検証して初めて、監査証跡としての価値が生まれます。

ブロックチェーンを使わなくてよいケース

すべての企業にブロックチェーンが必要なわけではありません。次のような場合は、従来の手法で十分です。

• 社内の監査で完結し、外部に記録の完全性を証明する必要がない場合
• 追記型ストレージや認定タイムスタンプなど、既存の手法で法令や監査の要件を満たせている場合
• 対象のログが少なく、運用で十分に管理できる場合

ブロックチェーンが価値を発揮するのは、管理者を含めて誰も記録を書き換えていないことを、外部に独立した方法で示す必要がある場面です。この要件がなければ、無理に導入する必要はありません。

監査証跡に関するよくある質問

ブロックチェーンを使った監査証跡の費用の見積もり、電子帳簿保存法への対応、機密性の高いログの扱いは、採用する構成に応じた確認が必要です。ここでは、この3点を検討する際のポイントを整理します。

ブロックチェーンで監査証跡を構築する費用の目安は？

費用は、対象ログの量、連携するシステム数、利用するチェーン、検証画面の有無などで大きく変わります。ハッシュ値を記録するだけの構成と、複数システム連携や監査人向けの検証機能まで含む構成とでは開発規模が異なるため、個別の要件整理と見積もりが欠かせません。記録時の手数料は、ハッシュ値をまとめて記録する設計で抑えることが可能です。

関連記事：ブロックチェーン開発の費用・コストを解説

ブロックチェーンに記録すれば、電子帳簿保存法の要件を満たせますか？

ブロックチェーンへの記録だけで要件を満たせるとは限りません。電子取引データの真実性の確保について、電子帳簿保存法が定める措置は、総務大臣が認定する時刻認証業務に係るタイムスタンプの付与、訂正・削除の履歴が残るシステムでの保存、事務処理規程の整備などです。加えて、検索機能の確保といった可視性の要件も満たさなければなりません。これらに該当するかは構成によって異なるため、導入前に税理士や所轄の税務署へ確認してください。

機密性の高いログをブロックチェーンで扱っても問題ありませんか？

ハッシュ値のみを記録する設計であれば、ログの中身がブロックチェーン上に公開されることはありません。ハッシュ値から元のデータを復元することは事実上できないため、取引内容や個人情報を含むログでも扱えます。ただし、推測されやすい短いデータは、ランダムな値を加えてからハッシュ化する工夫が必要です。本体を置くオフチェーン側は、従来どおりアクセス制御や暗号化で保護してください。

まとめ

監査証跡の重要な役割は、操作の流れを後から追跡でき、その記録が改ざんされていないと示せることです。従来の代表的な手法は、専用の保管場所に隔離してアクセスを絞る「隠して守る」方式で、実績はあるものの、管理者や特定の事業者への信頼が前提です。

ブロックチェーンを使えばこの守り方を「ばらまいて検証する」方式へ変えられ、ハッシュ値だけを記録する構成なら、要件次第で既存システムを作り替えずに導入できます。ただし改ざんの検知はできても復元はできないため、原本の分散保管とセットで設計しなければなりません。

まずは改ざん時の影響が大きいログを選び、誰がどう検証するかを決めることから始めてください。XTELAでは、監査証跡へのブロックチェーン活用を、適用可否の判断から設計・開発・既存システムとの連携まで支援しています。お気軽にご相談ください。