具体的にどのようなシステムであれば、訂正又は削除の履歴の確保の要件を満たしているといえるのでしょうか。

良い質問ですね。実は、要件を満たすシステムには大きく分けて2つのタイプがあるんです。

はい。一つ目は「訂正削除の履歴を確保するシステム」、二つ目は「そもそも訂正削除ができないシステム」です。

そうなんです。訂正削除の履歴確保の目的は「変更前のデータを確実に確認できること」ですから、最初から変更できないシステムなら、その目的は自動的に達成されるわけです。

正確です。では、まず一つ目の「履歴を確保するシステム」から詳しく見ていきましょう。

このタイプのシステムは、前回の問33で話した4つの要件を全て満たす必要があります。覚えていますか?

完璧です。では、具体的にどういう動作をするシステムなのか、Y社の実例で説明しましょう。

Y社は大手クラウド事業者の文書管理サービスを使っています。このシステムは電帳法対応を謳っていて、実際に4つの要件を満たしています。

まず、書類をスキャンしてアップロードすると、自動的に「バージョン1.0」として記録されます。この時点で、作成日時、アップロードしたユーザー名、ファイル名などのメタデータが記録されます。

その書類に何か修正があって、修正版をアップロードすると、システムが「これは既存の書類の修正ですか?」と聞いてくるんです。

そうです。「はい」を選ぶと「バージョン2.0」として保存され、「いいえ」を選ぶと新しい「バージョン1.0」として別管理されます。

その通りです。さらに重要なのが、バージョン2.0から次のバージョンを作るとき、必ずバージョン2.0をベースにしなければならないという制約があることです。

正確です。システム側でそれを強制しているんです。これで更新処理の制限の要件を満たします。

Y社のシステムでは、「削除」ボタンを押しても、実際にはデータは消えません。「削除済み」というフラグが立つだけです。

そうです。ただし普通のゴミ箱と違うのは、管理者権限でも物理的な削除ができない仕組みになっていることです。

はい。税務調査対応のため、保存期間中は絶対に消せないようになっています。これで削除と履歴の保持の要件を満たします。

Y社のシステムには「削除済みを含めて検索」というオプションがあります。これにチェックを入れると、削除フラグが立っている書類も検索結果に表示されます。

その通りです。では、Z社で実際にあった複雑なケースを見てみましょう。

Z社は建設業で、取引先から3月1日付の見積書を受け取りました。これをスキャンして「見積書A_v1.0」として保存しました。

ところが翌週、取引先から「材料費が値上がりしたので見積を変更します」と言って、3月8日付の新しい見積書が届いたんです。

ここで担当者が迷ったんです。「これはv2.0にすべきか、別のv1.0にすべきか」と。

答えは「別のv1.0」です。なぜなら、これは改訂版ではなく、全く新しい別の見積書だからです。日付も違いますし、見積番号も違うはずです。

正解です。そして古い「見積書A_v1.0」には削除フラグを立てて、削除済みフォルダに移します。

その通りです。実際にZ社では、半年後に「最初の見積書の内容を確認したい」と言われて、削除済みフォルダから取り出して確認できました。

では次に、AA社の事例を見てみましょう。AA社は少し違うアプローチを取っています。

AA社は「訂正削除ができないシステム」を採用しています。

WORM機能を持つクラウドストレージサービスです。WORMというのは「Write Once Read Many」の略で、一度書き込んだら二度と変更できない仕組みです。

概念は同じですが、クラウド上で実現しています。AA社が使っているのは、Amazon S3のオブジェクトロック機能です。

書類をスキャンしてアップロードすると、その瞬間にデータが「ロック」されます。ロック期間は7年間に設定されています。

そうです。AA社の社長でも、システム管理者でも、クラウド事業者のサポートスタッフでも、誰も変更や削除ができません。

その場合は、正しいファイルを別途アップロードします。間違ったファイルは削除できないので、ファイル名に「誤アップロード」などと付けて管理します。

正確です。このタイプのシステムが要件を満たすには、2つの条件があります。

一つ目は「画像データを全く変更できないこと」。
二つ目は「保存されているデータが読み取り直後のデータであることを証明できること」です。

つまり、スキャンした直後にすぐにクラウドにアップロードされて、途中で誰も改ざんしていないことを証明できる必要があります。

AA社では、スキャナとクラウドストレージが直接連携しています。スキャンボタンを押すと、自動的にクラウドにアップロードされる仕組みです。

その通りです。さらに、アップロード時刻がクラウド側のNTPサーバーと同期した時刻で記録されるので、改ざんの余地がありません。

正確です。では、BB社の事例も見てみましょう。BB社は少し特殊なケースです。

BB社は最初、履歴管理タイプのシステムを使っていたんですが、途中で訂正削除不可タイプのシステムに移行しました。

はい。ここで重要なのが、移行時に「履歴も一緒に移行する」必要があることです。

そうです。例えば、旧システムで「契約書A」がv1.0からv3.0まで3つのバージョンがあったとします。

新システムに移行するとき、v3.0だけ移行してはダメなんです。v1.0、v2.0、v3.0の全てのバージョンを移行する必要があります。

旧システムでの訂正削除の履歴も、保存要件の一部だからです。最新版だけ移行したら、過去の履歴が失われてしまいます。

はい。ただし移行作業が大変でした。移行前に全データの棚卸しをして、各書類のバージョン数を確認して、移行後に全て揃っているか検証しました。

そうですね。システム移行を考えている企業には、この履歴移行の負担も含めて検討するようアドバイスしています。

良い質問ですね。それは会社の規模や運用方針によります。

小規模で書類の修正が少ない会社なら、訂正削除不可タイプがシンプルで良いでしょう。運用も簡単です。

中規模以上で、書類の修正や差し替えが頻繁にある会社です。履歴を辿って確認する機会が多い場合は、履歴管理タイプの方が使いやすいです。

それなら訂正削除不可タイプを提案してみてはどうでしょう。運用がシンプルで、ミスも起きにくいです。

履歴管理タイプなら、BoxやGoogle Workspace、Microsoft 365の電帳法対応プランなどがあります。

Amazon S3のオブジェクトロック、Azure ImmutableStorage、Google Cloud Storageのバケットロックなどです。ただし、これらは技術的な設定が必要なので、導入支援サービスを使うことをお勧めします。

では、まとめましょう。訂正削除履歴の要件を満たすシステムには、大きく2つのタイプがあります。

その通りです。履歴管理タイプは、初版の保存、更新処理の制限、削除と履歴の保持、削除データの検索という4つの要件を満たす必要があります。

完璧です。システム選びの際は、会社の規模や運用方針に合わせて、適切なタイプを選ぶことが重要です。

素晴らしい。CC社には、これらの情報を元に、最適な提案をしてあげてください。必要なら、私も同席しますよ。