マイナンバー制度を「アーキテクト」目線から考える（３）
２．住民基本台帳ネットワーク
コンビニ交付サービスでは、利用開始時点で住基カードかマイナンバーカードで本人確認をしています。ふつう、Webで買い物などをするときにはメールアドレスなどをIDとしてパスワードで認証しますが、電子証明書による認証はこれにかわるものです。なぜユーザーIDを発行するなどして、この認証結果に基づいて情報提供ネットワーク経由で証明書を取り寄せる普通のオンライン処理の形にしなかったのでしょうか。
もう10年以上前になりますが、マイナンバー関係のシステム提案に関与していた頃のことです。情報提供ネットワークは構想段階でしたが、既に基本コンセプトは固まっていました。提案チームのミーティングで、情報提供ネットワークがサービス開始されたらコンビニ交付サービスはどうするんだろうということが話題に上ったことがあります。当時すでに稼働を始めていたキオスク端末もありましたが、当然情報提供ネットワークに接続して情報連携するのが妥当だろうというのがメンバー共通の見方だったと思います。根本からプライバシーに関わるデザインが変更される認識でしたので、国の根幹になるシステムなら考え方を合わせるのは当然と漠然と私も考えていました。もっとも、元々コンビニ交付サービスに関する提案の予定もありませんでしたから、この話はそれきりで、私もこのトラブルの話を聞くまでそんな会話をしたことも忘れていました。
今回のトラブルのニュースを聞いて最初に考えたのは、かつて会社でこんなことを話していたなあというそのことです。もしかすると、コンビニ交付サービスは私たちのチームが考えていたように情報提供ネットワークに接続するよう設計変更しなかったのではないかと思ったのです。調べてみると案の定で、当時の設計のままアーキテクチャは変更されず、マイナンバーカードでも認証ができるように改修した程度の変化であることがわかりました。
何らかの制約があって取り残されたのか、積極的に選択した結果なのかどちらなのかは、調べてもわかりませんでした。ほとんどの場合、こうした疑問に政府が公表している文書は回答をくれません。政府の作るシステムには、多くの場合に法的根拠があり、その法的な表現とシステムの表現は整合する必要があります。その法律は、概ね縦割りです。厳しい予算制約もあって、全体としてあるべき設計に一気に到達できるとも限りません。制度を所管する部署や府省をまたがるプロジェクトを進めるだけで非常に調整体力を消費します。多くの人々が意思決定に関わり、それぞれの持ち場で妥協できる範囲を線引きしながら共通の理解を練りあげていく時間のかかる作業が必要です。そうした中で、波紋を起こしそうな表現は角がとられ、いつのまにか主語の不明確な輪郭の失われた文章が作られていきます。仮に情報開示請求をしたところで、本当の政策意図が説明さている文書が出てくる可能性は薄いでしょう。それは様々な調整の結果であり、誰かの考えや意志を説明するものではありません。使用前使用後で何が変わるかを説明して国民理解を求める文書なら山ほどあるのに。まるで、なぜ、と問うことはタブーであるかのように「意志」は封印されるのです。
その結果として、官公庁向けのシステム開発の現場では、なぜそれがそうなっているのかが長年そのシステムを担当している開発者は元より、発注者である官公庁の職員も理由を知らないといったことが起こりがちです。法令やどこかの規則に書かれている条文が制約となっている場合は、理由こそはっきりしていても、それを変えるために元々なぜそのような規則があるのかを調べるのは困難です。しかも、それが法律であったら国会を通さないと変更できませんから、それこそ大臣レクやら政党への説明やらで忙殺されるうえ、政局で国会が荒れれば法案成立は後ろ倒しになるということで、その分システムの完成も後ろ倒しになります。単年度で契約を結んで開発するなかで、これでは仕様提示もできないわけです。政省令や内部の規則の類はそれよりハードルが低くても、手続きが大変なことに変わりはありません。法令の変更が必要で影響範囲が即座には見極められないと言った場合、限られた開発期間では結論が出せないため、本質的であっても影響の大きい機能改修には手を出さないで、そのままそっとしておこうという思考も働きやすくなります。
しかし、アーキテクチャの思想は、こうした細部に宿って初めて意味をもちます。アーキテクチャの思想と反する実装に丹念に手を入れていかなければ、システム全体の真の改革はできません。従来の法律は、もちろんシステムのことを考えて作られてはいませんから、ほとんどの官公庁のシステムは制度縦割りで開発されています。しかし例外も出てきています。まさに、住基ネットやマイナンバー関連のシステムは、法的な整備がシステム構想の立案と同時並行的に進められた先駆けのような例ではないでしょうか。マイナンバー関連の法改正が非常に多くの法律への加筆、修正の山であることに驚く人もいると思いますが、元々縦割りで作られている法制度と既存システムをつなぐのがこの構想のコンセプトですから、手続き上はどうしてもパッチワークの山が必要になり、法体系もシステム構造もスパゲティ化しがちです。しかも、法施行までの期間はしばしば2年がデフォルトとして設定されます。そうした中で、アーキテクチャ上の概念の一貫性を広く確保していくという作業がどれほど難しいものかは外部からはなかなか伺い知れないものがあります。
そこで、少し遠回りをします。いずれにしても、出発点となるのは住基ネットですので、必要な準備として、まず住基ネットについて調べます。住基ネットは多くの訴訟が提起され国民的な議論を巻き起こしたシステムです。この分野に詳しい者であればだれでも知っていることですが、その論争の結果は後のマイナンバー制度の設計に大きく影響しています。住基ネットやそれに関連した最高裁判決についてよくご存じの方は飛ばしてもらってかまいません。
住民基本台帳と住基ネットの役割
住基ネットは、住民個人に全国で固有な番号（住民票コード）を付したうえで、各自治体で管理されている住民基本台帳を全国ネットワークによって相互接続することで、個人情報の連携を容易にすることで事務運営にかかっていた負担を軽減し、住民サービスを向上させることを目的とした仕組みです。住基ネット導入以前は、各自治体に住民の登録簿があって、転出、転入の異動処理によって各々維持する形になっていましたが、住基ネットの導入後でも住民登録の在り方自体に変更はありません。住民記録の維持管理は自治体の仕事です。
転居、結婚、出生、死亡などで住民情報は変化します。個人の範囲でみたらそれほど頻繁にあることではなくとも、サービスを提供する役所の側から見ると結構なボリュームのある事務処理です。総務省の統計や厚労省の人口動態などを見ると、年間の市区町村間の異動者数は530万人、出生者は70万人、死亡者は毎年150万人くらいとなっていますので、異動が転出入で約２倍になることを考えると、日本全国では年にのべ1300万件くらいの台帳に対する追加・更新・削除の処理があることになります。もちろん、転出入については世帯単位での届出になるでしょうから、実際の事務処理件数としてはもっと少ないかもしれませんが、それでも数百万件の処理があることは確実でしょう。
こうした変化を確実に捕捉していくのは案外やっかいな問題です。自治体であれば、それこそ転出入その他の届けによって自然に変化は把握できるわけですが、住民情報が変更されたからといって自動的に他の官公庁が管理している住民情報が変更されるわけではありません。住基ネットができたことで法律が許す範囲で確認のために住民情報を参照することはできても、ネットワークを介した情報連携は行えません。業務上の必要性がないところでの情報収集は元々行えないということを考えると、住民情報のような基礎的な情報でも簡単には事前の連携はできないということなのかもしれません。
しかし、このような情報連携が無い場合、居住実態と整合した住所情報を整備するのには大きなコストがかかります。少し例をあげます。
（１）不達郵便物の管理
住民に対して送付した通知が不達で戻ってくることがあります。不達となったものについては、本人の住所の記録にその旨反映し、後日、本人からの申請等があった際に住所情報を変更するまでは郵送は保留しておく他ありません。では、もしその通知が本人に届くのが遅れたことで何らかの不利益が生じた場合、これは誰の責任なのでしょうか。法律的にいえば、おそらくこれは住所を明らかにしていなかった本人の責任ということにしかならないはずです。
実際の行政事務上では、言ってこないのが悪いと一方的に突き放すのではなく、必要な申請を促す努力は一定程度なされるかもしれませんが、これも住所が不明になってしまうと連絡そのものができないわけで限界があります。電話やメール、SNSが使われている分野はまだまだ限られているのではないでしょうか。
（２）別人として登録した情報の統合（名寄せ処理）
公共サービスの利用登録をシステム化する場合、過去に既に登録されている利用者かどうかをろくに確認しないで運用していると、複数のアカウントが作れてしまう場合があります。そのようなことを防ぐには、四情報だけでは不十分です。たとえば、年度の途中で転居されたことによって、転居先でも登録があるといった場合はアカウントが二重に発行されることもありえます。転出入なら転出側の記録とのマッチングが可能ですから、整合性の維持はできるはずですが、そのような仕組みがないと全国で見ると複数の自治体で登録があるアカウントというのは容易に発生するのです。事業の性質上複数アカウントがあっても問題ないのならそれでもよいのですが、税や社会保障のように公平性の観点や本人利益の観点で複数アカウントの登録が認められない場合、これだとまずいことになります。
多くの公共サービスの利用登録では電話番号や最近ではメールアドレスなども登録するようになってきていると思いますが、これは単に連絡先として用いるだけでなく、同一人物であることを確認するためにも役立てられているはずです。例えば氏名、生年月日、性別が同じで住所が異なるレコードがあった場合、メールアドレスと携帯の番号まで同一であれば同一人物である可能性は高いと言えます。しかし、メールも携帯も家族で共用しているケースはいくらでもありえるので、それだけでは決め手にはなりません。同じ漢字で読みが異なる場合もあります。戸籍には振り仮名がありませんでしたが（最近法改正されてふりがなも登録されることにはなったようです）、住民基本台帳にはあります。名寄せ処理は、こうした各種の情報を基に同一アカウントの記録を統合管理できるようにする処理のことです。少し考えただけでも経験からくるノウハウなしには成立しない処理だというのが分かると思います。誰にでも設計できるというものではありません。
（３）複数の場所に居住している場合の住所登録
Y県のA市とX県のB市に居住し、Z県に別荘を持っているといった人の場合、住民税や社会保障サービスは住民登録のあるA市が担当するとしても、固定資産税はそれぞれの市、課税地でかかります。この場合、住民登録がなくとも郵便で通知するためにいずれか連絡のつく居住地の情報が必要です。複数の土地を所有し、引っ越しが多い人などの場合、どこに通知を出したらよいか判断が必要なこともあるのではないでしょうか。
（４）生死の把握、特定年齢の到達確認
住民票コードは、出生届けがトリガーとなって付番されます。マイナンバーは住民票コードが元になって生成され、符号とともに管理されるようになります。死亡時の住民登録の抹消は死亡届けがトリガーです。これらは、住民として登録されて官公庁の記録の中で個人の存在が確認される基本的なイベントで、ほとんどの場合で適切に申請がなされるものと思います。しかし、出生届や死亡届けは、自治体の中でこそ連携されるかもしれませんが、民間企業は元より、他府省やその他の公共機関に自動的に連携される例は限られています。連携がなければ、家族が機関間の情報連携を肩代わりすべく各所に申請を出すという作業が必要になります（この負担を軽減しようというのが、政府がずっと長い間検討を続けている死亡時ワンストップです）。住基ネットの情報を見ることができない組織では、利用者の申請を待つほかありません。
現在行われている住基ネットを基盤とする代表的な処理として、年金の20歳到達（制度適用）と60（給付開始）歳到達のような特定年齢に到達する住民の抽出処理があります。日本の年金制度では、20歳になって未就労で年金制度に加入していないと国民年金への適用（加入）申請を促す通知が届きます。わざわざ収入がない可能性が高い20歳の国民に支払いを求めるのも妙な話ではありますが、もちろん、国民皆年金の前提として成人している者は国民年金に加入することが義務とされているためです。これは、そのようなレベルの法適用の事務ということになるためか、法律上も住基ネットの情報を使うこととされています。年金給付に関する通知も同様です。
もし住基ネットを使わずにこうした一斉処理を行おうとするなら、結局のところ全国の自治体に届けられた情報を何らかの形で連携しなければなりませんから、物理的に情報を連携する仕組みを構築する必要に迫られたはずです。それはもうほぼ住基ネットです。住基ネットが否定されるならこの連携システムもだめでしょう。結局、1800くらいある各自治体から個々に通知を出してもらうか、すべての自治体から特定年齢到達者のリストをデータとして入手して一斉に通知することになります。住基ネットとの情報連携によって、どれだけ市町村の事務が効率化されたかは自明でしょう。
住所情報の維持に関わる直接のコストということではありませんが、ここで、それが不備であることによって何が起こるのかを少し見ておきます。こうした一斉通知にかかる郵便料金の話です。
令和5年の新成人の人口は、総務省統計局によれば341万人。仮に通知はハガキで出すとしてもこの10月からハガキは85円なので、仮に新成人の全員に対して一斉通知を行うとすると、約290億円が必要ということになります。20歳くらいだと実家を離れて大学のある場所に住んでいるとかいった場合もあるでしょう。この場合、住民票を移していなければ当然ながら通知は実家に届きます。実家のご両親に、「いや、息子は今東京なので、東京に通知を送ってくれ」と言われても、送りなおすことがそれほど容易ではないのは郵便代だけからもすぐに理解できるのではないでしょうか。通知が届くまでやり切る費用や事務負担は相当のものになるはずです。送付されるのがハガキではなくて納付書付きの封書等の場合、用紙代、印刷代、封入・封緘費用、発送費用などに加えて郵送料がかかるわけで、一回の送付でかかる費用は300億円をはるかに超えます。しかも、これに対象の住民からの返信の費用も加わります。働いていれば、社会保険にすでに加入していることもあるでしょうから、現実にはもう少し内輪に収まるかもしれませんが、それでもかなりの金額です。しかも、これだけの数の郵便をきちんと整備されていない住所情報に基づいて送付したら、不達郵便の量はどれだけになることか。住基ネットの利用も当然だと思われませんか。
これが日本年金機構から送られてくる年金定期便になると被保険者全体が対象ですので、約6,800万人が対象になります。メガバンクでも、個人口座数はせいぜいこの１／３くらいです。年金定期便が当初封書で送られていて費用が掛かりすぎるとして圧着ハガキに変更されたのは当然でした。年一回の通知発送をハガキでやっても6,000億円近くかかるわけですから。
つまり、これが公共事業、特に国レベルの事業のコスト感だということです。市町村単位でひとり専任の業務担当者をつけることにしたとします。計算を簡単にするために、仮に一人当たりの人件費が500万円だとしても、日本全国で考えると90億円かかることになります。住民の住所に関する原簿の整備のような基礎的な情報整備くらいできれば自動化を進めたいところです。各府省、地方自治体、個人に対するサービスのある独法などで住民情報くらい共有することができれば、住民はいちいち氏名に住所にと申請書に書かなくても、それこそマイナンバーカードだけですぐにサービスが受けられるようになるはずです。
住民票コードの利用制限
さて、住基ネットの意義についてはもうあまり疑問の余地はないのではありませんか。行政事務をできるだけコスト効率高く実施し、住民にいちいち「書かせない」仕組みを作りたいなら、整備された住所記録を共有するのが効率的であることは理解してもらえるのではないかと思います。住基ネットが実現した転出入処理の効率化などは行政のデジタル化を考える上ではむしろ基本の「キ」であって反対する理由がわからないと私が感じるのもこうしたことが根底にあります。コンピューターを使って事務処理を効率化したいなら、個人単位に割り振られたユニークなコードが必要になるのは至って当然のことです。
しかし、せっかく住基ネットを導入したのに、相変わらず役所で届書や申請書などを書く際にはいわゆる四情報（住所、氏名、生年月日、性別）を書かされることがあります。マイナンバー制度で少し状況は変化してきていますが、これについては後に回し、ここでは住民票コードと住基カードが導入された当時に焦点を当てます。
たとえば、住基ネットを役所の様々な手続きで活用し、場合によっては民間にも開放して、住基カードを提示することで四情報をその都度書かなくても情報連携してもらうことができればずいぶん便利になったはずだとは思われないでしょうか。しかしそうはなりませんでした。そのため、四情報にどうしても依存することになります。それは、個人を特定できるユニークなコードが無い場合、これが本人を特定するために必要最小限の情報だからです。住基カードを持っていないか、利用に制約がある事務の場合、四情報を引っ張ってくる元がありませんから、どうしてもいちいち四情報を記入せざるを得ません。しかも、それがマジョリティだったわけですから、申請書の様式はそこを主体に組み立てざるを得ないということも多分あります。
たとえば、役所の届けなどで、てぶらででかけて、「この間も届けを出したし、その時から住所は変わってないのだからそっちで適当に書いといてよ」といってもそうはいきません。その「この間の届け」は四情報がなければ特定できないからです。氏名、生年月日は基本的には変わりません。性別は近年社会的な側面では相対的なものであることが認識されるようになりましたが、それでも身体的な区別については頻繁に変わることのない基本属性でしょう。ところが、その三つが同じという人が世の中には実在します。したがって、確実な特定のためには、住所を含めた四情報が最低限必要になるのです。
現在、住民票コードを含む住民基本台帳の情報は、社会保障分野で一部、国、自治体以外の機関での利用が認められていますが、限定的です。ユニークな番号があれば情報連携がよりシンプルに行えるようになるのは自明ですが、住民基本台帳の情報の利用については、厳しい法的制約があり、公共機関であってもどの事務でも自由に使えるというようにはなっていません。住民票の発行以外では、選挙人名簿の作成、税や社会保障の特定の事務が対象となっているぐらいです。住民票コードをキーにして独自にデータベースを構築することは公的機関も含めて一切禁じられています。仮に、学校で生徒の住民票コードを集めてデータベースを作成したら、場合によっては刑事罰が科される事件となります。
このような制度設計を考えた場合、住民票コードをトランザクション処理で使うということはまずできないだろうと考えられます。住民記録に関係するとはいえ、コンビニ交付サービスは住基ネットの外での処理には違いありません。住民票コードを用いて情報連携を行う設計が果たしてできるのかどうか疑問です。なぜそのような厳しい制約があるのかについては後に検討するとして、ここではひとまず利用者にひもづく固有のIDとして住民票コードを使うのは難しそうだということを確認しておきたいと思います。
では、住民票コード以外でユニークコードとして使えるものはないのでしょうか。これが無いわけでもないことから、この話はややこしくなります。
まず、住基ネットのような孤立系のネットワーク内で住基カードを用いて情報取得し、利用するユーザーに特別な入力を課さないという基本アーキテクチャから考えると、住基カードに格納されている情報のいずれかを使うほかありません。住基ネットは、そもそも住民基本台帳が見られるという以上の機能は持ちえないのですから、余計なidを登録して使うこと自体に疑問があります。
そうしたシステム環境の中でも、使えるとすれば先に触れたように認証で用いる電子証明書です。電子証明書のレイアウトの中からユニークコードとして使えるものを探すと、電子証明書に対して振られるユニークな番号であるシリアル番号が見つかります。シリアル番号自体には何の意味もありませんが、カードを持参した人が自分で設定した暗証番号を入力することで、「それを持っていること」と「暗証番号」を知っていることで多要素認証が一応成立し、電子証明書のシリアル番号と個人情報がひもづけられることになります。言い換えると、この処理が継続している間に限れば、このシリアル番号はユーザーIDと同等だということです。システム中のトランザクションには個別にトランザクション番号などがふられるかもしれませんが、それに加えてこの証明書のシリアル番号を処理の継続する間維持して各サーバ間で連携させることで、連携処理の間、申請した内容と印刷結果が申請者と紐づいていることを保証することができるわけです。
またこの番号は認証局にはともかくも、コンビニ交付サービス側で保持されるものではありませんから、必要以上の情報流出にはつながりません。そのトランザクションの終了時に破棄すればよいことです。せめてこれを使わなければ最低限のトランザクション管理も実現は難しくなるでしょう。
このコンビニ交付サービスにおいて証明書のシリアル番号によるトランザクション管理が実際に設計されているのかどうかについてはこれまでのところ公開された情報が見つけられていません（※5）。また、複数社ある証明発行サーバの設計が同じなのか異なるのかについてもわかりません。前述のとおり、トラブルの結果から判断する限りでは、富士通社の設計ではそこに何らかの瑕疵があったことは間違いないのですが、そこだけの問題なのか、コンビニ交付サービス全体の設計の問題なのかを判断する材料も今のところみつけられていません。これ以上のことについてはもう当事者に聞く他ないでしょうか。
（※5）本記事にコメントを下さった caminoroad さんの記事を読むと、J-LISの発行する証明書のシリアル番号を使っている旨言及があります。 https://note.com/caminoroad/n/nc67c9d1f7fda （2024年10月24日アクセス）
トランザクションのユーザーid
ここまでの説明で、コンビニ交付サービスが住基ネットの外にあることでそもそも住民票コードは用いることができず、ユーザーIDも発行しないことから、通常のオンラインサービスのように依頼者のidの下で管理されるのではなく、たかだか電子証明書の情報を用いる実装しかできないことは理解してもらったと思います。もちろん、それでもACID属性を満たすオンライン・システムは作れるのかもしれませんが、それがユーザーIDでもアカウントコードでもないことは明白です。このシリアル番号は論理的には、処理中は住民票コードとほぼ同等であってデータベースに保管、管理することには問題があります。また、電子証明書は、有効期限があり書き変わることがありますので、元々これをIDの代わりに永続化して使いまわすことは元々できない相談です。処理終了時に破棄するのが原則でしょう。これは、その都度の処理の中で使うことはできても、情報連携で用いることはできないということを意味します。
つまり、このシステムは電子証明書を示すことで各種証明書を取得してきて印刷するだけのシステムとしての性格そのままに設計されていて、電子証明書によって認証をしたうえで、本人のアカウントコードやユーザーidによってセルフサービスで各種証明書を取得するシステムとしては設計されていないということなのです。
では、この処理の主体、ユーザーは、本当は誰なのでしょうか。誰が、どの権限で住民のデータを取得していることになるのでしょうか。電子証明書のシリアル番号に相当する利用者の権限でアクセス管理がなされていないことは情報の取り違えが生じたことで明白になってしまいました。実は、情報の取り違えが発生したことでもっとも問題として問われなければならないのはこの点なのです。当然すぎるあまり、気づきにくいのですが、住基ネットの構築時にシステム・アーキテクチャの中に住民は登場していません。住民は管理対象の情報であり、記録に過ぎません。システムにアクセスできるのは、住民記録に関係する公的機関の職員に限られます。このことが、コンビニ交付サービスでユーザーidやアカウントコードによるコントロールを難しくしている根本的な原因です。住基ネットはその構造上住民の直接のアクセスを許しません。コンビニ交付サービスで証明書発行サーバ上にわざわざ住民情報を複写してこれを取得する形にしているのはそのためです。
上で、キオスク端末は役所の窓口の代替だと書きました。これは、言葉どおりの意味であると考えると、コンビニ交付サービスのシステム・アーキテクチャの本質が理解できます。役所の窓口で住民票を取得するために申請すれば、役所の職員が住民記録を調べて謄本を作成し、手数料を払うと引き渡してくれます。コンビニ交付サービスは、これを電子的に実現していると思えばよいのです。とはいえ、役所の窓口の代わりはコンビニのキオスク端末です。
機械にはIDはありません。そこに住基カードを照射することで全国の誰の情報でも取得することができるわけですから、権限の設定のしようがありません。これは、広域交付サーバでも、証明発行サーバでも同様です。トランザクションに対して、権限を設定しようにも、そこには一時利用にすぎないシリアル番号しか含まれていないわけです。データベースに対するアクセス権が設定されていないわけですから、処理プロセスが設計どおりに動作しなかった場合、全国の個人情報にこれらのサーバプロセスはアクセス可能になる可能性があります。コンビニ交付サーバの情報取り違えが発生した根本原因はここにあります。通常のデータべース・アプリケーションでは、トランザクションの利用者がアクセスできるデータ範囲に対して許可を与える事前の設定がなされるのが普通です。不特定多数がアクセスする基幹データベースであれば、その利用者をグルーピングして、それぞれのグループに対するアクセス可能範囲をその権限のレベル（参照可能、追加可能、書き換え可能、等々）とともに設定してデータベースを保護するわけです。具体的な方法としては、アプリケーション側で実装したりDBMS側で実装したり、そのシステムの環境によって様々でしょうけども、何のセキュリティ設定もない状況でトランザクションの全面的なアクセスを許可するのは元々かなりスクのある状況である と私には思えます。シリアル番号では、こうした機構を実現することはできません。
次善の策として、シリアル番号とトランザクションIDの組み合わせを持ち歩いて、証明発行サーバでの出力を返却する際にサーバ側と端末側でダブルチェックする実装にしてさえいれば（実際にそのような設計は行われていたのではないかと疑ってはいます、少なくとも他社では）、今回の障害は防げただろうと思います。いろいろと制約がある中で行われた設計でしょうから、担当された技術者の方々には敬意を表したいと思いますが、コンビニ交付サービスのトラブルについては、やはり基本的な設計の中に潜在的にリスクが含まれていて、一部のコンポーネントの動作に不具合が生じたことでこのリスクが現実化したものと解釈するのが妥当であろうと考えざるを得ません。