行政関係の電子データ消失事故として有名なものに、2019年12月4日に、日本電子計算の自治体向けクラウドで、SSDに障害が発生し、データを消失し、33の自治体の業務に影響を与えたものがあります。また、2022年5月20日には、トラストバンクが、ふるさと納税関連サービスで、こちらも住民申請者からの画像や添付ファイル　17,385件のデータを消失しました。

　日本電子計算の自治体クラウドでは、当初は、その事故原因は、「SSDのファームウェアの不具合」とされました。やがて、バックアップさえも取得できていなかったことが判明しました。そこから以降の真因究明、対策については、一般には知られていません。

トラストバンクの場合も、事故原因は、サーバーの処理負荷軽減対策時の担当者の作業ミスとされ、それにより、バックアップデータを消したとされています。そこから先の真因究明、対策は、公開されていません。

そして今回の新潟県の事故においても、その原因は、「保守作業員のミス」とされています。拡張子大文字⇒小文字変更プログラムが、未承認で導入されたことが事故原因とされました。しかし、今回、それより罪深いのが、実は、「バックアップが三日間しかなく、気づいた時には、もうバックアップがなくなっていた」ということです。

3件に共通するのは、バックアップに弱点があったということです。多くの方が、バックアップという技術を特段に高度ではないと思いがちで、そこに、落とし穴があります。

新潟県の4月21日の発表では、１．事案の概要　の中に、「庁内の起案、決裁等の意思決定手続きの際の添付ファイルが消失したものであり、県民、事業者等に直ちに大きな影響があるものとは想定しておりません。」とあり、さも大した問題でない印象を与えてしまっています。これを受け、各報道機関の報道も大した問題でないというトーンに同調してしまっています。

これは、正しい判断なのでしょうか？検証してみる必要があります。

まず、公文書管理法（公文書等の管理に関する法律）によれば、第四条で、以下のように定めています。「行政機関の職員は、当該行政機関における経緯も含めた意思決定に至る過程並びに当該行政機関の事務及び事業の実績を合理的に跡付け、又は検証することができるよう、処理に係る事案が軽微なものである場合を除き、文書を作成しなければならない。」 また、第五条では、保存が義務付けられています。

さらに、第34条では、「地方公共団体は、この法律の趣旨にのっとり、その保有する文書の適正な管理に関して必要な施策を策定し、及びこれを実施するよう努めなければならない。」としています。

新潟県については、公文書の管理に関する条例となっており、第4条，第5条も踏襲しています。

このように分析してみますと、第四条の義務を負っている行政職員が、決裁という意思決定に至る過程で利用した添付ファイルが消失しても影響がないというような発言はできないことは明確です。

これは、何も、新潟県のケースだけでなく、日本電子計算、自治体クラウドの事故も同様です。

2019年12月の日本計算機の自治体クラウドでのデータ消失事故は、総務省　「地方公共団体における情報セキュリティポリシーに関するガイドラインの改定等に係る検討会」では、「Jip-Base」事案と呼ばれ、有識者が分析しておりますので、要点をご紹介します。尚、この情報については、ASP・SaaS・IOTクラウドコンソーシアム 会長宛てに、2020年５月２２日に発信された通知・通達　総行情第75号「「Jip-Base」事案を踏まえた地方公共団体へのクラウドサービスの提供に係る対応について（要請）」に、記載、添付されております。以下に、引用・抜粋します。

■有識者会議での議論を踏まえた主な論点

論点①：求められるサービスレベルに応じたクラウドサービスの選択
・今回の事案では、重要な業務システムからそうではないシステムまで、同じサービスレベルのクラウドで構築されていた例が散見された。

論点②：クラウドサービス事業者とのSLAを含む適切な契約
・今回の事案では、各自治体の契約事項は大きく差異があり、SLAなど本来必要と思われる事項がなかった。また、事業者から自治体に対してサービスレベル等に関する説明が不足していた。
・今回の事案では、特にバックアップの一部がクラウドサービス事業者側のミスによりできていなかったことが、復旧の長期化の大きな要因になった。

論点③：小規模自治体を中心としたIT人材の不足
・特に、小規模な自治体に適切な契約がなされていない場合が多いなど、ITに知見を有した職員が少なく、各種のガイドライン等を踏まえた適切なクラウドサービスの活用へのハードルが高い状況にあった。
さらに、再発防止策として、以下のような地方自治体助言とクラウドサービス事業者へ要請をしている。

■地方自治体への助言

クラウドサービスは調達者、ベンダー、クラウドサービス事業者が責任を分担するものであり、調達者において適切な使い方をすることが必要との前提の下、地方公共団体に対し、システムに求められる可用性のレベル等を十分に検討の上、下記の事項の確認と契約の見直し、バックアップの実施等を助言する。
①クラウドサービスを利用する重要システムについてバックアップ取得場所（遠隔地、筐体別）
及びバックアップの保証の有無などを確認の上、必要に応じた契約の見直し、バックアップの実施
②要求レベルに応じた適切なクラウドサービスの選択
③必要な条項を盛り込んだ契約及びSLAの締結
✔ 併せて、情報システムの調達等に係るアドバイザー派遣などの各種支援策を周知

■クラウドサービス事業者への要請

地方公共団体を対象にクラウドサービスを展開する主な事業者に対し、サービスレベルの適切な開示やガイドラインを踏まえた契約、インシデント発生後の適時適切な状況報告を行うよう要請
そして、「地方公共団体及びクラウドサービス事業者がお互いにシステムの重要度に応じたサービスの選択やバックアップが確実に実施されるよう対話の促進を図る。」ことが必要とまとめている。

2020年5月に、上記の分析と対策の助言・要請がありましたが、これは、今回の事故に役立っていたのでしょうか。本件システムの入札は、2021年3月であり、時期的には、上記の分析と対策を活かすことが可能でした。しかし、3日間のバックアップしか取れていない箇所があったということなので、自治体側も事業者側も結果としては活かせませんでした。

では、記録を保存するという観点からバックアップ以外に問題はなかったのでしょうか？実は、本質的に重要な問題点があったのです。それは、下図②の「『不要な添付ファイルを削除するプログラム』が、既に組み込まれていた。」という点です。このことは、記録を保存するという立場から見ると大きな問題です。

一旦、記録として取り込まれたものは、削除、変更しないのが、記録管理の原則だからです。

このようなロジックは、ファイルサーバーの容量が過大になり、容量削減が必要なときに、利用されている例を見受けますが、保存している記録には、適用すべきではないのです。 　このようなロジックが入っていたことで、拡張子を大文字から小文字に変えたことで、保存された記録を削除してしまったのです。

今回、3件の事故を紹介しましたが、バックアップを無くした割には、いずれも、まだ、運がよかったという状況だと思います。

その理由は３つです。①記録を保存してからまだ日が浅い段階であったので、入力したファイルを集めて再登録が可能であった。あるいは、②他のシステムに元データが残っていたので、これを利用できた。③あまり重要なデータでなかったので、復旧できなくても許された。

ヒヤリハット事故というのをご存知でしょうか。重大事故の前には、その前兆として、「あっ！危ない！」と思うことや、軽傷の事故が起きるという警鐘です。

2023年4月24日の第101回　公文書管理委員会　“１．令和4年度における公文書監察の取組等について”の議論の中でも、新潟県の事故は、「情報システム上の瑕疵による公文書紛失」として取り上げられ、監察上も手を打っていく必要ありとされています。

これまで、バックアップデータの保持期間がクローズアップされた事故は、あまりなかったが、今回は、3日間と極めて短かったために、発見から3日より前のデータは復旧できなくなっています。それでも、今回は、大量のデータが急に消されたために、発覚が早かったとも言えます。

仮にバックアップデータを100日保管していたとしても、毎に、少しずつ削除され、発覚が、削除開始から1年後であったとするならば、1年前から100日前までに消されたデータはバックアップから復旧できません。さらに、登録後、時間が経ってしまっているので、登録した担当者のＰＣ内のデータが消され、特定できなくなり、復旧できなくなります。今のままでは、いずれこのようなデータ復旧が出来ない事故が発生してしまいます。

官民の区別なく、今回の事故を自分事として見直して頂く際の重要事項を以下に上げます。

（１）保管対象データが記録であるか、否かを見極める

　保管する情報は、登録後、変更、削除から保護すべき“記録”であるか、単なる一時的な共有する情報で変更、削除を許してよいものかを判別する。

（２）保管対象データが記録の場合、保管のための要求仕様を文書化する
（保管期間、重要性と可用性に応じたバックアップ方式の選択、変更・削除からの保護等）

要求仕様としては、少なくとも次の事項について仕様化することが必要である。

①保管期間

②重要性と可用性に応じたバックアップ方式の選択

・無くしてはいけない重要な記録であれば、世界標準として、
“3 copies，2 different　media, 1 offssite”
すなわち、原データを含めて3重のデータを、少なくとも2種類の媒体で、そして1個は遠隔地で保管する必要があります。すなわち、バックアップは2重に、そして、異種の媒体で、すくなくとも1個は遠隔地に置かねばなりません。
・可用性については、目標復旧時間で評価しますが、短時間での復旧が必要な場合は、オフサイトもオンラインにする必要があります。

③バックアップデータの保管期間

・できれば、1年前くらいまでは、保有しておきたい。

④変更・削除からの保護

・悪意による変更・削除、意図しない作業ミスや思い違いなどで、一旦、記録したものが変更・削除さ れることから保護することが必要であることを明確にします。

（３）利用しているシステム、サービスに対して、必要な要求仕様を提示できているか、また、保守契約を含め、その要求仕様を満たしているかどうかを確認する。特に、以下は重点的にチェックしましょう。

・記録したデータを自動削除するロジックが入っていないこと
　・極端に短いバックアップ期間の設定がないこと

（４）上記（１）～（３）を判断できる人材、リソースを保有しているか否を確認する。

官も民も今まさに、本格的なデジタル化が避けられない段階に来ています。それだけに、失ってはいけない重要なデータ、記録を如何にして護るかが問われています。しかしながら、そのために利用者側としても必要な人材が、慢性的に不足していることから、これまで、氷山の一角とも言えるデータ消失事故が発生してきています。大事故になる前に、既存システム、既存サービスの点検を行うとともに、対応力のある人材育成が必要となっています。