静岡大学 遠藤研究室

2021年12月21日（火）に遠藤が、静岡大学・中日新聞連携講座2021「いのちとくらしを守るイノベーション」の第4回でオンライン講演しました。要旨は以下の通りです。
１．金融情報システム
金融情報システムは、銀行系と市場系に分かれ、さらに個別金融機関のシステムと金融機関の相互ネットワークのシステムに分類できるが、いずれも複雑で大規模なシステムである。金融情報システムの特異性は、第一に決済システムであること、第二に情報セキュリティの高さを求められること、第三にレガシーシステムの存在、第四に規制産業だということである。金融情報システムでは、IT要因や金融業務要因という外部環境の変化に対して、組織や経営者という内部要因が適合していないという問題構造がある。
２．リスクマネジメント戦略の6観点
そこで、経営者向けにリスクマネジメント戦略の6観点を提言してきた。それは、１）経営トップのコミットメントと支援、２）組織体制とITガバナンス、３）ITリスクマネジメント、４）拡張性一貫性確保、５）要件定義最適化、６）品質重視の仕組構築である。
３．金融情報システムの障害事例4件
金融情報システムの障害事例として4事例を採り上げて分析した。2011年の銀行振込大幅遅延では、未然防止の観点だけでなく障害発生時の対応にも難があった。2012年の一部銘柄取引停止では、二重化の設計を過信して障害発生時の対応が雑になった。2020年の終日株式売買停止では、二重化設計の確認が不十分で、関係者との発生を想定した調整もできていなかった。2021年2月の銀行の障害では、定期性預金の障害が、システムの防衛機能によって全体に波及し、ATMでの通帳・カードの取込みに繋がった。同じ銀行でその後もハード障害、プログラムのミス等を起因に7件の障害が発生した。他の銀行やQRコード決済でも障害は発生しており、各社でシステム障害管理体制の見直しが求められる。
４．システム障害管理体制の実効性向上の留意点
障害発生を皆無にすることは不可能であることを前提として、システム障害管理体制を構築する必要がある。未然防止の観点だけでなく障害発生時の対応準備の観点も重要で、両面に経営の関与が必要になる。
５．障害にどう向き合うか
事業者は、利用者視点で影響が少ない障害は、事後対処でカバーすると割り切り、それを利用者に伝えることも必要ではないか。利用者も障害が発生しないシステムはないことを理解し、代替手段を用意することや、連絡先を最新化しておくことが望まれる。今後DX進展により、元々別々に作られたシステムが連携して動くことで、より便利なサービスが提供される反面、想定しない障害も一定の割合で発生しうることを理解する必要がある。（文責：遠藤正之）

浜松イノベーションチャレンジは、浜松のクラッチ製造の株式会社エフ・シー・シーさん（東証1部上場）主催、株式会社ブリッジさんのサポートでの4か月にわたるワークショップ型の新事業創出プログラムです。参加者は、エフ・シー・シーさんに加え、浜松の上場企業であるユタカ技研さん、ローランドDGさんそして会場FUSE提供の浜松いわた信用金庫さんの社員の若手精鋭で、新事業アイデアを練り上げ、自社の経営陣に向けてプレゼンするものです。
そこに、若い感性を期待され、静岡大学情報学部遠藤研究室の3年生の学生4名が参加させていただきました。12月17日（金）にその最終ピッチ（経営陣向けプレゼン）が行われました（写真）。学生たちも、各社の経営陣の皆様の前で、堂々とプレゼンテーションを行いました。
更に12月22日（水）にアフターフォローセッションが行われ、各社のメンバーと振り返りを行い、4か月の全日程が終了しました。社会人の皆さんの真剣な議論に触れることで、学生たちにとって、得難い大変貴重な体験となりました。

11月26日にみずほ銀行とみずほフィナンシャルグループに対して金融庁からの業務改善命令が発せられました。そこで、改めて、みずほ銀行の障害に関して、システム関連での原因と今後の対応策を、公開情報をベースに纏めてみました。
Ⅰ．原因
第一に、MINORIのアーキテクチャの複雑性、第二に保守運用フェーズでのリソース削減が急であった事、第三にIT現場と経営のコミュニケーションが不十分だったこと、第四にシステム関連の銀行組織、開発会社、運用会社が連携しにくい体制であること、第五に機器の所有を各ベンダーとしたこと。
１）MINORIのアーキテクチャの複雑性
大規模システムでは、マルチベンダーとなることは不可避である。マルチベンダー自体が問題ではない。むしろ勘定系システムの本体部分が、4つの異なる基盤システムで構成されている点が問題である。
それぞれのOSも異なり、データベース管理システムも異なっている。それぞれの専門家はいても、その相違点を十分に理解できる専門家はほぼいないのではないか。基盤を跨る障害に対応するためには、両方の専門家が参画する必要があり、対応スピードがどうしても遅くなってしまう。特に社内にスキルの高い専門家が常駐していれば良いが、そうでないと更に対応スピードは落ちてしまう。第二の原因によるリソース削減で、スキルの高い専門家は常駐していなかったと推測される。
２）保守運用フェーズでのリソース削減が急であった事
大型プロジェクトの場合、リリース直後に障害が発生する。みずほ銀行のシステムリリースは実質的に2019年2月だった。それから約2年たって、システム障害が発生したことに着目すべきである。有識者であるベンダーの人材をそれまでは引き留めていたが、コスト圧縮策の中で、引き留めができなくなり、十分な引継ぎもできず、障害の予兆能力や障害発生後の対応力が低下したと考えられる。
３）IT現場と経営のコミュニケーションが不十分だったこと
経営者とシステムの開発現場のリスク感覚に関する意思疎通ができていなかったことにあるのではないか。現場の状況を経営トップに伝えるのがCIOの一つの役割だが、CIOがシステムの事情に精通していなかったため、経営トップ側の代弁者の機能のみとなり、現場視点の適切な進言を経営トップにすることができなかったのではないか。その結果、２）のように、現場感覚ではリスクが高まるレベルまで人員やベンダーへの支払いを削減してしまったのではないかと考える。
6月のシステム障害調査報告書でも、114ページから116ページにかけて、アンケート調査やホットラインで受け取った意見がまとめてあり、そのことが裏付けられる。
４）システム関連の銀行組織、開発会社、運用会社が連携しにくい体制や伝達方法であること
みずほ内部が、みずほ銀行と開発子会社の二層構造になっている点や、開発会社（みずほリサーチ＆テクノロジーズ）と運用会社（MIDS）の資本関係が異なる点等、組織的に複雑であり、スムーズな連携を阻害している可能性がある。またIT子会社の再編により、保守体制が弱まった可能性がある。一つは、2020年6月に日本IBMの資本を入れた運用会社を設立したことである。もう一つは、2021年2月から3月の4件の障害にもかかわらず、2021年4月に、システム開発を行う子会社だったみずほ情報総研が合併により、みずほリサーチ＆テクノロジーズを設立した点である。
更に、障害発生時の運用会社でのエラーメッセージの検知体制や、運用会社から開発会社への伝達方法が、印刷したうえで電話での口頭の連絡によるなどアナログ的な手法であったことで、大量のエラーが発生した場合の対応が不十分になる素地があった。
５）機器の所有を各ベンダーとしたこと
機器の故障が多い点と、MINORIは35万人月で4000億円台の投資とされているが、投資に機器のコストがほとんど入っていない点とに注目する。機器については、ベンダーの機器を借りている形態で、毎年使用料を払っている形になっているようである。様々なハード機器関連のテスト、障害訓練を自由に行うためには、基本料金以外の追加の費用が発生するため、開発現場ではそのようなテストや訓練を最小限に絞っているのではないか。そのため、機器の故障に際しては、みずほ内部の人間は全く手も足も出ず、ベンダーにお願いする以外方策がないのではないか。しかし２）で説明したように、ベンダーへの保守コストを削減しており、常駐するベンダー担当者のスキルレベルはあまり高くなく、リカバリーに手間取ったのではないか。
Ⅱ．対応策
第１に、システム部門の現場の構造を改善して、ベンダー・開発会社・運用会社・みずほ銀行、みずほFGの一体運営する体制を策定することが望まれる。
特に、みずほ銀行と開発会社の司令塔の一元化、運用会社から開発会社への情報伝達の自動化や改善が喫緊の課題ではないか。
第２に、システム部門のスキルアップと、MINORIのアーキテクチャへの習熟が必要ではないか。MINORIの機能を修得する研修や、障害を想定した、ベンダー、開発会社、運用会社、みずほ銀行、みずほFG、経営まで巻き込んだ訓練の定期的な実施が望まれる。
第３に、経営陣とシステム部門の現場の意思疎通の活性化策を取る必要がある。
CIOが経営陣の代弁者としてだけでなく、IT現場の代弁者として機能するように、するべきである。内部監査部門もこの点を意識した監査を行ってこれを支援することが望ましい。
第４に、アーキテクチャをレビューする組織や体制を強化することが必要ではないか。
複雑なアーキテクチャをこれ以上複雑にしないように、新規開発のアーキテクチャを計画段階でチェックすることが必要である。
第5に、システム部門に過度のプレッシャーをかけないために、経営陣がATMの限定的な停止のような障害（3月3日事案、8月23日事案、9月8日事案）は、今後も十分起こる可能性があることを宣言してしまうことも必要ではないか。

2021年7月21日に遠藤が講師として登壇した研究会がオンライン開催されました。その内容を報告します。
日時：2021年7月２１日（水）19：00～20：40
テーマ：金融情報システムのリスクマネジメント
■要旨
講演者は、金融情報システムに関して、経営者向けにリスクマネジメント戦略の6観点を著書「金融情報システムのリスクマネジメント」で提言している。2020年から2021年にかけて取引所と銀行で大きなシステム障害事例が発生した。これら事例は、詳細な調査報告書が公表されており、講演者が作成した根本原因分析も参考にして、各組織で他山の石として、障害管理体制の実効性を高める見直しを行うことを推奨する。最後に、2021年に調査報告書が公表されたソーシャルレンディングの事故事例についても解説した。

講演者の紹介（司会より）
1983年三菱銀行に入行し、第三次オンライン開発、東京三菱銀行システム統合、三菱東京UFJ銀行システム統合等の超大規模プロジェクトに、主に推進マネジメントの立場で参画し、その後2015年10月より静岡大学に移り、主に、金融情報システム、FinTech、情報システムのマネジメントを専門としている。

Ⅰ．金融情報システム

本日議論する金融情報システムは、「金融機関等コンピュータシステムの安全対策基準・解説書」の定義から、オンラインサービス、決済、顧客データ取扱という3つの要素を含んだ大規模なシステムとする。様々なバリエーションがあり、銀行部門と市場部門のシステムに分かれ、それぞれが更に個社のシステムと相互ネットワークのシステムに分かれる。銀行システムも証券会社システムも多くのサブシステムから構成された複雑で大規模なシステムである。

金融情報システムに係るリスクは2つのタイプに分かれる。第一のタイプは金融情報システム自体が外部から直接評価されるもので、オペレーショナルリスク、ビジネスリスク、戦略リスク、風評リスク、法務・規制リスクがある。この後説明するシステム障害事例で顕在化したのはこのタイプである。第二のタイプは、金融情報システムが経営判断をサポートするタイプのリスクで、市場リスク、信用リスク、流動性リスクがある。最後に説明するソーシャルレンディングで顕在化したのはこの中の信用リスクである。

金融情報システムの特性は4点ある。第１に、決済システムとして広範囲のネットワークに接続しており、可用性や大量即時処理への要求が高いことである。第２に、顧客の財産情報を扱うことから、情報セキュリティの高さを求められることである。第３に、ホスト系のレガシーシステムが存在しており、保守や開発の難易度が高くなっていることである。第４に、規制産業であり当局の監視下に置かれていることである。2011年の調査では、開発の工期、予算、品質の各面で5割以下の満足度となっている。

金融情報システムに関しては、ITや金融業務という外部要因の変化に対して、システム開発の組織や経営者という内部環境が適合しきれていないという、大きな問題構造が浮かび上がってくる。

 

Ⅱ.リスクマネジメント戦略の6観点

金融情報システムの問題構造に対する改善提言として、リスクマネジメント戦略の6観点（CORE-OQ）を提唱している。6観点とは、以下の6点であり、最初の4点が攻めの視点、残りの2点が信頼性実現の視点での観点である

1）経営トップのコミットメントと支援（Commitment）
2）適切な組織体制整備によるITガバナンス強化（「組織体制とITガバナンス」）（Organization）
3）経営ITリスクの適切な評価と対策の構築（「ITリスクマネジメント」）（IT Risk Management）
4）経営戦略に合致した業務拡張性およびシステムの一貫性の確保による二重投資の排除（「拡張性一貫性確保」）（Extensibility）
5）外部関係者の要請とITのケイパビリティの間をつなぐ要件定義最適化（非機能要件を含む）（「要件定義最適化」）（Optimization）
6）品質重視の仕組構築（Quality）　。

観点1の経営トップのコミットメントと支援について3点を示す。第一に経営戦略の優先順位が経営トップとCIO（最高情報責任者）や情報システム部門と共有されていることである。第二に経営トップが開発組織体制の整備や障害対策へ関与することである。第三に経営トップが情報システムに関して組織内外へ発信することである。
観点2の組織体制とITガバナンスについて３点を示す。第一に、情報システム開発に適した全社的組織体制、プロジェクト体制が構築され、障害発生時の連絡体制が委託先も含めて事前に準備されることである。第二にシステム関連の人材育成が計画的になされることである。第三に、ITガバナンスが高められていることである。
観点3のITリスクマネジメントについては、第一に発生可能性のあるリスクを洗い出したうえで、対処の優先順位決めをすることである。第二に適切な対策を立案し実施、管理することである。第三に環境変化に応じて定期的にリスクの優先順位や対策を見直すことである。
観点4の拡張性一貫性確保について3点を示す。第一に業務やシステムの拡張性を確保できるような設計である。第二にシステム全体のグランドデザインの共有である。第三に障害発生時に影響が特定しやすいようにする仕組みを当初から盛り込むことである。
観点5の要件定義最適化について3点を示す。第一に要件実現にあたり現状のシステムを活かして実現することを考えて具体化することである。第二に機能要件だけでなく処理集中時のレスポンスや障害発生時の対応などの潜在的な要件も明確にしていくことである。第三に業務継続計画も策定することである。
観点6の品質重視の仕組構築について3点を示す。第一に設計品質、開発品質、運用品質の3つを意識することである。第二に標準的なルールや手順を制定して属人的な品質のバラツキを極力排することである。第三にレビュー会議実施のルール化や専門的なレビュー組織を作る等で組織全体の品質を高めることである。

Ⅲ．金融情報システムの障害事例

金融情報システムでの障害事例の中で、2011年に発生した銀行の振込大幅遅延、2012年と2020年に発生した取引所の障害、2021年2月3月に発生した銀行のATMカード通帳大量取込他3件の事例について、根本原因分析の手法で掘り下げていく。

【障害事例1：2011年銀行振込大幅遅延】

障害事例1は、2011年の銀行振込大幅遅延である。経緯概要は以下の通りである。東日本大震災の週明けにテレビ局の義援金口座への大量振込が集中し、1口座当たりの処理可能件数を上回り、夜間バッチが異常終了した。復元作業が難航し、翌日のオンライン開局のためバッチ処理を中断して、手作業での処理を行った結果、二重処理や処理漏れなどが連鎖的に発生した。更に翌朝には、携帯電話事業者の義援金口座への大量振込集中で、対外接続系システムでの受け入れ可能なデータ量を上回ったことで、夜間バッチの異常終了が発生し、再度手作業での対応が大量に発生しATMの利用制限やダイレクトチャネルの利用制限につながった。

この障害の根本原因分析が図１である。直接的な原因である義援金口座への振込集中に加え、為替取引の受入の上限値であるリミット値の見直しがされていなかったことも原因となる。また障害が長期化した原因として、日中オンライン処理と夜間バッチ並行実施を想定していなかったことがある。更に携帯電話のチャネルの考慮が不十分であったこと、システム監査での指摘やリスク評価もなされていなかったこと、夜間バッチ遅延発生時のコンティンジェンシープランの整備が不十分だったこと、障害発生後の連絡体制の不備や、全体のマネジメントをする人材が不足していたことが挙げられる。様々な面での不十分な要素があったことが浮かび上がった。更に、リスクマネジメント不十分、組織間の連携不十分、人材育成視点が希薄などの根本原因があることも推定された。

図1　2011年銀行振込大幅遅延の根本原因分析

【障害事例2：2012年の取引所一部銘柄取引停止】

障害事例2は、2012年の取引所一部銘柄取引停止である。経緯は以下の通りである。2月2日未明1時27分に相場情報を配信する情報通信ゲートウェイサーバー8台のうちの1台でハード障害が発生。運用ベンダー担当者が診断レポートを出力し、保守ベンダーと取引所担当に連絡した。保守ベンダー担当は、携帯電話の小さい画面で情報が不十分な状態でレポートを一人で分析し、予備機に処理が引き継がれると誤判断した。取引所担当も自ら確認することなく、売買業務への影響はないと判断し、エスカレーションしなかった。7時過ぎにオペレーター出勤後、予備機へ引き継がれていないことが判明し、それから復旧を図ったが間に合わず、一部銘柄（241銘柄）の午前中売買停止となった。

この障害の根本原因分析が図2である。保守ベンダーが携帯電話の小さい画面でレポートを分析し一人で判断したことと、取引所担当も予備機への切替ができると過信してしまったこと等、障害発生時の対応に難があった。

図２　2012年取引所一部銘柄取引停止の根本原因分析

【障害事例3：2020年10月1日終日株式売買停止】

障害事例3は、2020年10月1日の終日株式売買停止である。経緯は以下である。朝7時4分に共有ディスク装置（NAS）1号機で障害が発生し、別機への自動切替ができず、手動切替も間に合わず、全銘柄の取引停止となった。その後、午後からの売買再開に向け、証券会社、システム提供ベンダーにヒアリングするも、対応可能取引参加者シェアが50%に満たないため、11時過ぎに終日売買停止を決定した。

この障害の根本原因分析が図3である。共有ディスク装置のメモリカードの故障が直接の原因であるが、製造元が自動切替の初期値を変更していたにもかかわらず、納品ベンダーが初期値を従前の値に変更し、確認のためのテストを実施していなかったため、自動切替が作動しなかった。更に手動切替の手順が整備されておらず、手動切替に時間を要したため、9時過ぎに約定情報が配信されてしまい、取引参加者の了解を取らない限り売買再開が困難になった。売買停止後の売買再開に向けた手続きやルールが用意されていなかったことで、対応できる参加者の売買シェアが38%にとどまり、再開できなかった。

図3　2020年10月1日終日株式売買停止の根本原因分析

【障害事例4：銀行の2021年2、3月の障害4件連続】

障害事例4は、銀行の2021年2、3月の障害4件連続の事例である。

１）2月28日

障害事例4の1件目の2月28日（月末の日曜日）の銀行ATMカード通帳大量取込の経緯は以下である。

朝8時24分にe-口座移行に伴う定期性預金のセンター集中記帳が開始され、9時51分に取引共通システムでのシステムエラーの検知を受け、運用会社から開発子会社へ伝達した。それと並行して10時15分には、AＴＭセンターから銀行にAＴＭエラー430件検知の一報メールが発信した。銀行の指示により10時50分にセンター記帳処理は停止されたが、その後も定期性預金取引でのエラーは検知された。一方、ＡＴＭセンターではエラー1000件超となった。11時14分には開発子会社でCＩＦ排他未解除を検知した。同時刻に、運用会社から開発子会社に対して、定期預金通帳記帳取引禁止が自動設定されていることを報告し、開発子会社から銀行へも報告された。銀行からの指示により、12時2分に定期預金の取引サービス禁止機能の作動条件が緩和された。12時37分には開発子会社で自動機サーバの2000件以上のエラーが検知された（定期預金の取引サービス禁止機能の作動条件緩和によることがこの時点では未判明）。12時47分に銀行内で「障害報告メール」（A2ランク懸念）が発信された。13時40分にATM異常多発での本部参集することが副頭取に報告された。14時から開発子会社で取引共通システムのログ調査が開始された。14時20分には開発子会社で取消情報管理テーブルのINDEXファイル容量拡張作業が開始され14時54分に拡張が完了した。14時25分には、全拠点の部店長職員に出勤指示が開始され、14時30分に関係部長会が開催された。17時10分になってログ調査の結果、AＴＭ処理区画の閉塞を認識し、処理区画の再稼働に着手し、18時39分にようやく処理区画復旧が完了した。さらに23時21分にCIFの排他解除が完了した。

2月28日の銀行ATMカード通帳大量取込の根本原因分析は、図4である。

原因としては、ATMセンターの体制が不十分であったこと、取引サービス禁止策の緩和などの不適切な障害対応策、厳格なキャパシティ管理をすべきであった取消情報管理テーブルINDEXのメモリー容量考慮漏れ、ATMエラー時の通帳カード取込仕様、タイムリーな告知が成されなかったこと、システム本体の閉塞機能の影響の把握が不十分、休日のATM障害への対応体制不備、障害発生後の営業店への連絡体制が遅れたこと、システム全体の影響を熟知する人材やマネジメント人材の不足などがある。様々な要素が重なり、障害が発生し、その後の障害検知、対応の遅れに繋がった。

図4　2021年2月28日銀行ATMカード通帳大量取込の根本原因分析

根本原因分析と対応して主な問題点11点を挙げたのが、図5である。（根本原因分析の①、②、…に対応する。）

図5　2021年2月28日事例の主な問題点

２）3月3日

障害事例4の2件目の3月3日のトラブルの経緯は以下である。

19時58分にデータセンタにおけるネットワーク機器内のネットワークカードの故障で通信の瞬断、接続が、3分間続くが、20時01分に解消した。しかしその間にATMでの通帳・カード取り込みが29件発生した。短期間で自動切替されたにも関わらず、ATMの通帳・カード取込仕様が影響を発生させたものである。

３）3月7日

障害事例4の3件目の3月7日のトラブルの経緯は以下である。

カードローンシステムのプログラムリリース後の6時8分に、総合口座定期預金の集中記帳でエラーが発生した。7時15分にはエラー原因が判明し、9時22分には影響あるATM、ダイレクトの定期預金サービスを停止した。対応後の13時42分にはサービスは復元された。原因はカードローンの追加開発でのプログラムミスであった。具体的は、貸越明細テーブルの定期預金データへの初期化処理の組込み漏れで、開発子会社テストでも検知できなかったものである。

４）3月12日

障害事例4の4件目の3月12日のトラブルの経緯は以下である。

11日深夜23時39分に、統合ファイル接受基盤に係るディスク装置で故障が発生した。これにより、外為システムも影響が発生するため、要員が参集した。

外為の被仕向処理に関しては、統合ファイル接受基盤が短時間で復旧するという想定のもと、本来復旧前は止めておくべきであった、被仕向の集配処理が定刻の4時に0件で自動実行されてしまった。統合ファイル接受基盤は故障発生後7時間後の6時38分に復旧し、6時57分に3月11日の夜間分のバッチ処理が開始された。8時24分に集配処理の後続処理でエラーが発生した。結果的に12時に事前に準備した手順での復旧ができないことが判明し、マニュアルでのリカバリーに着手することになった。16時15分にマニュアルでの通番情報を銀行の事務企画部に還元するも、リカバリーができず、19時の勘定系システムのオンライン締めに至り、761件について当日中の到着案内が未了となった。

外為の仕向処理については、6時57分の夜間分のバッチ処理開始直後に、異常終了が発生したが、開発子会社の担当が被仕向の対応に注力していたため検知できなかった。11時46分の日付変更処理後も、適切な指示が成されず、13時に外貨決済カットオフタイムが経過し、14時55分には円貨決済カットオフタイムも経過した。15時になってようやく仕向の集配処理が0件で実行されていることに気づき、17時40分に外為データ送信処理が実施され、18時31分にようやくセンター集中記帳処理が完了した。

3月12日の外為送金等遅延の根本原因分析は、図6である。

統合ファイル接受基盤の障害後の自動切替が不調で復旧に時間がかかり、更に外国為替システムの対応での手順ミスがあり、遅延が拡大し、国内他行向仕向外為送金263件の送金処理がカットオフタイムから最大6時間遅延し、外為被仕向送金761件の当日中の到着案内処理が未完了となった。復旧手順の全体統括機能や体制の不足や、復旧に精通した人材配置が不十分だった点や障害シナリオの準備や訓練が不十分だったのではないかと推定される。

図6　2021年3月12日外為送金等遅延の根本原因分析

各障害事例をリスクマネジメント戦略の6観点で何が問題だったかと、金融情報システム自体が外部から直接評価されるタイプのリスクのうち、顕在化したリスクが何であったかを纏めた。

障害事例1では、6観点すべてに問題があった。
障害事例2では、6観点のうち、経営トップのコミットメント、組織体制とガバナンスの観点、ITリスクマネジメント、品質重視の仕組で問題があった。
障害事例3では、組織体制とITガバナンス、ITリスクマネジメント、要件定義最適化の各観点が不十分だった。
障害事例4では、6観点すべてに問題があった。

4件の障害事例からの学びとして、金融情報システムの運用の難易度が高まっていて、各システム別に役割が細分化されている環境下で障害発生の影響見極めが困難になっていることを再認識する必要がある。また証券取引所のような、多組織のネットワークのシステムでは、関係組織の障害対応について、事前に情報収集し、調整しておくことが必要だった。これらの障害事例の報告書と根本原因分析を参考にして、他社でもシステム障害管理体制を見直すことが求められていると考える。

Ⅳ．システム障害管理体制の実効性向上の留意点

ここからシステム障害管理体制の実効性向上の留意点を説明する。
2012年に発表された日本銀行の「システム障害管理体制の実効性向上に向けた留意点」は、2011年の障害を契機として纏めている。障害発生の未然防止や、障害発生時の対応準備、障害管理に対する経営陣の関与のそれぞれに関してポイントを示している。
情報処理推進機構でも、2012年に「情報システム障害の再発防止のための組織的マネジメントの調査ＷＧ報告書」及び『「障害管理の取組みに関する調査」調査報告書』で、「障害管理の取組み」、「障害が防止できなかった時の備え」、「障害管理フレームワーク」に関して、事業者への提言を纏めている。「障害管理フレームワーク」の重要項目として、経営者のガバナンス、管理者のマネジメント、障害管理体制の構築、障害管理活動の有効性を高める方策を示している。

障害事例３（2020年10月1日終日株式売買停止）と障害事例4（銀行の2021年2、3月障害4件連続）に関して、システム障害管理体制の観点で分析した。

まず、障害事例3と障害事例4の4件目（3月12日）の障害に共通するのは、2点ある。第一にバックアップでの自動切替ができなかったことである。第二にハードの障害箇所がシステムのハブとも言える重要な箇所であり、影響が拡大しているということである。

次にシステム障害管理体制の3要素である障害発生時の未然防止、障害発生時の対応準備、障害管理に関する経営陣関与に関して、障害事例3と4に関して分析した。

障害事例3に関しての分析は以下の通りである。障害発生時の未然防止の観点では、ハード障害で不可避な面もあるが、初期値変更の影響確認が不十分であった。障害発生時の対応準備の観点では、証券会社等外部接続者へのコンティンジェンシー計画が不十分という課題があった。障害管理に関する経営陣関与の観点では、終日売買停止の判断は経営として妥当であった。

障害事例4に関しての分析は以下の通りである。障害発生時の未然防止の観点では、2月28日障害では、月末の移行処理を強行した点に難があり、3月7日の障害では、影響確認が不十分なまま、開発・リリースをしていた。障害発生時の対応準備の観点では、コンティンジェンシー計画が不十分で、銀行と運用会社、開発子会社との連携が不十分であった。特に2月28日障害では、他の取引に波及し、混乱や顧客影響が拡大した。障害管理に関する経営陣関与の観点では、障害情報の一元的な共有が行われていない等、経営者の関与が不十分であった。

Ⅴ．ソーシャルレンディング

最後に、2021年4月に調査報告書が出ているソーシャルレンディングについて説明する。ソーシャルレンディングの市場規模は2018年まで拡大していたが、2017年から2018年にかけて最大手のmaneoを含む複数事業者の行政処分があり、ファンド募集を中止した事業者が相次ぎ、募集額は激減した。更に2021年5月には、最大手のSBIソーシャルレンディングでも資金流用の不正融資が発生し、同社は廃業に追い込まれた。

投資家から見たソーシャルレンディングのリスクは、以下の3点と考える。第一に借り手の信用リスク、第二にソーシャルレンディング事業者のガバナンスのリスク、第三にソーシャルレンディング事業者自体の倒産リスクである。ソーシャルレンディング事業者は、多数の借り手と多数の投資家をマッチングするのが理想だが、実態は借り手が少なく、借り手や紹介者の意向を無視できない構造があり、借り手や紹介者寄りの運営になりがちである。

【maneoの事例】
2019年まで最大手として営業していたmaneoの事例を説明する。
2018年7月に提携企業の一つであるグリーンインフラレンディングの不適切な融資で行政処分を受けた。2018年9月、10月には、提携企業の一つであるガイアファンディングのファンドで200百万円の延滞が発生した。更にmaneo自身のファンドでも延滞が発生する事態となった。延滞の大量発生理由には、以下3点と考える。第一に不動産案件の個人向け融資姿勢が引き締められたこと、第二にガバナンス強化の中で、ロールオーバーができなくなったこと、第三に大量のファンド組成の中で、審査不十分な案件が発生したことである。
2019年3月29日にmaneoマーケットは経営改善委員会から「経営改善に向けた提言書」を受領し、瀧本代表取締役が退任するなど、経営体制が見直された。2019年7月以降新規募集が停止となった。

【SBIソーシャルレンディングの事例】
maneoに代わって、最大手となったSBIソーシャルレンディングの事例を説明する。SBIグループの一員として2018年に黒字転換された。
ところが、2021年2月5日に、重大な懸案があるとして、第三者委員会を設置するとの発表がされた。その時点では明らかではなかったが、玄海インベストマネジメントアドバイザーとの協働案件で、実質テクノシステム宛融資の資金使途虚偽という案件だった。2月9日には社長は交代し、4月28日に第三者委員会の調査報告が公表され、虚偽表示や善管注意義務違反が指摘され、145億円の損失が明らかになった。5月24日には、自主的な廃業に追い込まれた。その3日後には、テクノシステムの社長が逮捕された。関東財務局からも業務停止命令が下された。
不正事案の構図は、SBIソーシャルレンディングがSPC特定目的会社に貸付し、そこから、地上権者、発電権利者の支払までは行われたが、建築工事代金の支払資金がテクノシステムから下請け業者に支払われず、借入金返済や損失補填等に流用されたということである。

ソーシャルレンディングの課題として、安定的な借入先の確保ができていないこと、金融機関の融資引締め局面での耐性に難があること、制度がいびつで情報開示に難があること、ガバナンスが不十分な企業があることが挙げられる。これに対し、業界全体での情報開示ルールの策定などが有効ではないかと考えられる。

説明は以上である。ご清聴に感謝する。

【質疑応答】

質問：2021年2月28日の障害に関して、これだけ多数のATMの顧客に適切に案内すること自体が難しかったと考えますが、お考えがあればお知らせ下さい。
回答： ATMで通帳カードが取り込まれかつ電話が繋がらない場合は、後日ご連絡の上、ご本人に通帳やカードは返却する旨の掲示や表示があるだけでも違ったのではないかと考える。

質問：2021年2月28日の障害の報告書では、取引制限緩和が問題視されていますが、障害が発生していた定期預金やCIF排他以外の入出金取引が多数動いていたのではないか。障害発生以外の取引の状況に関して、報告書から読み取れることはあるでしょうか。
回答：取引制限緩和がATMのエラー増加に繋がった事は、報告書以前には着目されていなかったが、報告書で初めて指摘されたものである。障害対象以外の取引については書かれていないので不明だが、閉塞の自動化機能が一種のブラックボックスとなっていたのではないかと考える。

質問：リスクマネジメント戦略の6観点（CORE-OQ）について、６つの中での「重みづけ」や「重要度」のようなものがありますか。
回答：最初の経営トップのコミットメントと支援は重要。重みの差はないが、対応する役員レベルが異なる。CEOレベルでは経営トップのコミットメントと支援と組織体制とITガバナンス、CIOレベルでは6項目全部が必要である。

質問：切替に失敗して大トラブルにつながる事例が多いなかで、切替失敗が発生しないように、開発中や運用中に、どのような監査をすべきでしょうか。体系だった監査手法があるのでしょうか。
回答：体系はおそらくないと考える。ただインパクトの大きい機器に関しては、自動切替ができなかったときに、手動切替の手順を準備しているか等を監査しても良いのではないか。

質問：システム全体を理解する有識者の質と量を維持・承継する方法の一つとして、例えば、システム部門（や、対する業務部門）のキーパーソンについて、人事異動サイクルを長くするという方策は、日本の銀行の人事全体からみて整合しうるものでしょうか（公共部門のシステム開発・運用における課題と通じるものがあると感じ）。
回答：キーパーソンを作るには人事異動サイクルを長くすることが必要だと考える。私が在籍した金融機関でも、専門性が蓄積できるように長期間のサイクルになっており、異動もシステム部門内で行われていた。営業店のような3年程度での異動する人事体系とは別の体系となっていた。

質問：エンドユーザのビヘイビアとして休日のATM利用や突発的な振込事例など従来では想定できなかった事象の発生に起因しているのは運用側には厳しい状況とは思いますが、リスクアセスメントを行う際の想定というか発想力を広げる必要があったのではないかと思いますがいかがですか。
回答：その通りと考える。2021年の報告書では、過去に通帳カードの取り込みが発生していたが、その事象を深く分析していなかったことを指摘している。全く起きていない事象を想像することはできないが、起きた事例からの横展開や、そこから想像して対策をすることが必要ではないか。また他社のトラブル事例等も参考になるので、公開された報告書を、そういう視点で一通り見ていただくと良いのではないか。特に2021年の報告書は167ページもの情報量があるので、貴重な資料である。また金融機関では、どうしても外部のベンダーに依存してしまいがちで金融機関内のスキルが高まらない傾向があるが、完全な内製化はできないまでも、重要な点のコントロールを金融機関の人が行うことも必要だという印象である。

質問：今後ますますFinTechサービスが普及されてくる中で、利用者の立場としてFintechサービスを利用する場合、新たなビジネスとしてFinTechサービス事業者と連携する場合について、リスクマネジメント・システム監査の観点から留意する事項等がありますか。
回答：事業者として提携する場合は、API接続のチェックリスト等の記載を参考にしてポイントを押さえて、相互に共有して確認すると良いかと考える。利用者の立場としては、何がリスクなのかをきちんと説明している企業であるかを確認してから利用すると良いのではないか。

質問：2月28日の障害は、「取消情報管理テーブルINDEX」のオーバーフローと関連する自動取消処理の不具合が起因となりましたが、これは構築時から潜んでいたもので、品質を十分管理していた開発プロジェクトでも見逃してしまうような実装上の不具合であり、システム監査が見つけるのは、相当工夫が必要かと思いますが、そのあたりについてはどのようにお考えでしょうか。
回答：2011年の報告書と異なり、2021年の報告書ではシステム監査への期待が書かれていないのが寂しいと考えている。報告書に関しては、実効性ある対策で3点触れていない点があると考える。第一にFG、銀行、開発子会社、運用会社との連携に関しての対策が明示されていないこと。第二に営業店等の現場で自発的に対応している部署もあったが、現場の動きを活用する視点がないこと。第三に監査部門の活用が提言されていないことである。その意味で、監査がシステム部門とは視点を変えて、不具合が発生した際の準備をしているのかを問うだけでも意味があると考える。
以上

8月20日のみずほ銀行トラブルに関して、複数のメディアで採り上げていただきました。
https://www.inf.shizuoka.ac.jp/news/detail.html?CN=154610
１．2021年8月20日(金)NHKニュースウォッチ9（21時15分頃からコメントの録画が放映）
２．2021年8月20日(金)朝日新聞デジタル「5度目の障害、システム専門家が指摘する「スキル不足」」
https://www.asahi.com/articles/ASP8N774GP8NULFA027.html
３．2021年8月21日(土)朝日新聞朝刊3面「みずほ再発防止の矢先」本文内コメント
「故障発生後、最悪のケースも含めて動いていれば、もっと早く対応できたかもしれない。リスクとなる部分の回復が、システムベンダー依存になっている可能性もあり、その解消が今回の教訓ではないか」等
４．2021年8月21日(土)静岡新聞朝刊6面「弱いリカバリー力」
（共同通信社、静岡新聞社掲載許可済、神戸新聞、西日本新聞にも掲載）
なお、みずほ銀行トラブルに関しては、これまでも、採り上げていただいています。
(2021年3月5日朝日新聞掲載記事）
https://www.inf.shizuoka.ac.jp/news/detail.html?CN=154535
(2021年3月16日静岡新聞掲載記事）
https://www.inf.shizuoka.ac.jp/news/detail.html?CN=154544
(2021年6月16日朝日新聞掲載記事）
https://www.inf.shizuoka.ac.jp/news/detail.html?CN=154595

遠藤が副主査として開催した研究会がオンライン開催されました。
銀行APIの動向に関する大変興味深い内容ですのでレポートを纏めました。
日時：2020年8月3日（水）18：30～20：20
テーマ：電子決済等代行事業者協会の取組みとFinTechの最新動向
講師：吉本憲文氏（電子決済等代行事業者協会理事）
出席者：85名

■要旨
日本で2018年の銀行法改正により、電子決済等代行業が法律に追加され、2020年には、銀行との接続の契約を結ぶことが義務付けられるなど、API開放が本格化した。銀行API（Application　Programing　Interface）の具体的事例や、4月に発表された公正取引委員会の報告を中心に、業界の動向とAPIの普及に向けた課題を説明いただいた。最後に、これからのFinTech全般に関する予想についてお話しいただいた。

０．講演者の紹介（司会より）

吉本憲文氏は、Yahoo! JAPAN、野村総合研究所などを経て、2015年から住信SBIネット銀行で、FinTech事業企画部長として、API開放に取り組まれ、家計簿アプリ、クラウド会計等への接続を率先して行った。特に2016年12月には、更新系銀行APIの開放を、金融界の先頭を切って行った。そのかたわら、経済産業省のFin Tech研究会や、全国銀行協会の『オープンAPIのあり方に関する検討会』等のメンバーも歴任され、2017年からは電子決済等代行事業者協会の理事として、日本における銀行API活用の推進を図っている、日本の銀行APIの第一人者である。

１．電子決済等代行業

１－１．電子決済等代行業

電子決済等代行業は、2018年銀行法改正で新たに可能となった「業」であり、登録業務である。登録業務とは、参入規制の「許可、免許または承認」「認可」、「登録」、「届出」の4段階の下から2番目である。一定の審査を受けて登録して、初めてこの業を営むことができるものである。電子決済等代行業は、マネーフォワードやfreee等の家計簿ソフトやクラウド会計ソフトのように、銀行APIを活用するいわゆるFinTech企業がなる業というイメージだが、実際の法律の対象範囲はもう少し広い。金融庁のHPの電子決済等代行業者一覧で業者の名前や法人番号を見ることができる。家計簿ソフトやクラウド会計の企業以外にも、証券会社やITの大手企業や銀行などが含まれている。

電子決済等代行業者には、1号事業者（更新系）と2号事業者（参照系）がある（表1）。

表1　電子決済等代行業者の種類と対象例

種類	対象例
1号事業者（更新系）	・更新系（振込）APIを用いて、利用者の振込指示を銀行に伝達する事業者 ・Pay‐easyサービス（情報リンク方式）を提供する事業者　　等
2号事業者（参照系）	・個人資産管理（Personal Financial　Management）サービス事業者 ・クラウド会計サービス事業者　　等

また、電子決済等代行業は、①顧客の委託を受けて、②顧客の口座に対して、③電子的に指示を出す、以上3つの要件を満たす業務を行うものである。電子決済等代行業に該当しない例と対比したのが表2である。

ただし、銀行法施行規則第1条の3の3で、定期的な口座振替サービス、公金の支払い、自己債権の回収、インターネットモール等は、適用除外と定められている。

表2　電子決済等代行業の3要件

	電子決済等代行業の3要件	電子決済等代行業に該当しない例
１	顧客の委託を受けて	銀行の委託を受けている
２	顧客の口座に対して	顧客の属性に対して指示を出す（住所変更等）
３	電子的に指示を出す	磁気テープに記録して手渡し

1－2．スクリーンスクレイピングと問題点

APIの背景となった重要な要素技術として、スクリーンスクレイピングがある。マネーフォワードやfreeeがAPI接続以前に主力として扱っていた技術で、今でもこの技術を使って接続していることもある。図1で言えば、ユーザーは、インターネットバンキングにログインIDやパスワードを直接入力するのではなく、クラウド会計ソフトに預け、クラウド会計ソフトがユーザーに成り代わる形でログインし、そこに表示されている残高情報や入出金情報をシステム的にキャプチャーして表示するものである。

図１　スクリーンスクレイピング

このスクリーンスクレイピングの歴史は古く、検索エンジンの概念にも用いられる技術であるが、金融情報でこれを利用すると情報セキュリティ上問題になるポイントから3点を説明する。

第一にアクセス元（IPアドレス等）情報の重複である。例えば銀行に複数の顧客から情報の照会が同じアドレスから入る形になり、詐欺集団がログイン情報を収集してアクセスしているのと同じにしか見えない形になる。銀行としては、犯罪集団を見抜きにくくなるという問題である。

第二にクローラー負荷問題がある。通常、銀行の顧客は、毎日複数回も銀行口座の情報を見るようなことはしないが、スクリーンスクレイピング技術を使っている会社は、銀行の口座の異動を高頻度でアクセスすることになり、インターネットバンキングを提供する銀行としては、顧客がアクセスしていた時以上に高負荷のアクセスに耐える設計をしなければならなくなるという課題が出る。

第三に、ハッキングに狙われるという課題がある。多数の顧客がログインIDやパスワードを預けているので、ハッキングに成功すれば、大量のアカウント情報を入手することが可能になるという課題である。

１－3．オープンAPI 制度化の時系列

概観すると、欧州では2015年から検討が始まり、2016年に制度化して、2018年に施行された。日本はやや遅れて、2016年に検討が開始され、2017年に制度化され、2018年に電子決済等代行業という形で施行された。

EUでは2015年12月にEU第二次決済サービス指令（PSD2）が公布された。英国でも2016年2月にOpen　Banking　Standardが公表され、法制度化の検討がキックオフされた。

EUのPSD２は、更新系を扱う決済指図伝達サービス提供者（PISP：Payment　Initiation　Service　Provider）と、参照系を扱う口座情報サービス提供者（AISP：Account　Information　Service　Provider）に対し、一定のルールを守ることが提唱された。法制度も日本の銀行法と違って、銀行側は、これらの事業者からの接続を拒否することはできないというかなり強めの法律となっている。

日本では、実際の事例が先行した。2016年3月に、住信SBIネット銀行が日本で最初にAPI開放を行った。翌4月には地方銀行の事例が続いた。2015年12月の金融審議会の決済高度化ワーキンググループの報告書や2016年6月の日本再興戦略2016でAPI公開の検討が指示された。これらを受けて、2016年10月に全銀協に銀行界、IT事業者、FinTech企業、学者、弁護士、消費者団体、金融庁等の関係者をメンバーとする「オープンAPIのあり方に関する検討会」が設置され、吉本氏も検討会メンバーとなった。この時点では立法化を視野に入れたわけではなく、APIはどうあるべきかを検討するものであった。

2016年12月の金融審議会の金融制度ワーキンググループの報告書では、「電子決済等代行業者（フィンテック企業）」の登録制導入、情報管理、業務管理体制の整備と金融機関側のオープンAPI の整備、顧客に損失が発生した場合の、責任分担ルールの策定などの法整備が打ち出された。2017年の3月に、更新系と参照系で3つの要件を定義した銀行法の改正法案が提出された。

「オープンAPIのあり方に関する検討会」でもオープンAPIのあり方の検討から、法制度整備への対応の検討に軌道修正され、法案が成立したのを受けて7月に報告書を取りまとめた。法案の審議と並行しての報告書の取りまとめには、苦労があった。

法はシンプルであるが、実際の事業者への適用については、政省令で定めていくので、246件に及ぶパブリックコメントが寄せられた。その中では、電子決済等代行業者が必ずしもAPIを使用する事業者に限られないという回答もあった。また参照系CMSや収納代行業者も該当するなどの回答がなされ、当該事業者を震え上がらせた。結果として電子決済等代行業は、APIを主軸としながらも、かなり幅広いユースケースを持つ法律として定められたといえる。

2．そもそもAPIとは

2－１．API

ユーザーデータを管理するリソースサーバーに対して、クライアントアプリがユーザーデータを要求する時の、ユーザーのデータをやり取りする口が「API」である（図2）。

人が使うためのインターフェースすなわちユーザーインターフェース（UI）に対して、APIは、プログラムが使うためのインターフェースである。

図２　API

出典：川崎貴彦「一番分かりやすいOAuthの説明」https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be

2-2．「良いAPI」と「イケてないAPI」

「良いUI」と「イケてないUI」があるのと同じように、APIにも「良いAPI」と「イケてないAPI」がある。具体的なAPIの例として残高照会の場合を示す（図3）。この事例は、世界標準的な考え方で実装されていて、残高の値を返すだけでなく、日付や時点、通貨単位、前日残高、前月残高の情報なども返ってくる優れたものである。

図3　具体的なAPI　残高照会

出典：GMOあおぞらネット銀行のAPI仕様書
https://gmo-aozora.com/business/service/pdf/api-spec-indivisual.pdf

残高照会のUIの場合は、各社独自の画面表示をしており、残高の表示位置や基準日、名称などは様々である。スクリーンスクレイピングの技術では、各社ごとのログイン後の画面のどこに必要な情報が表示されているかを人力で登録し、機械的に巡回取得している。

次に、残念なAPIの例（架空のもの）を示す（図４）。

第一に呼び出しの仕様が「Zandaka」とローマ字表記である。
第二にいつの時点の情報がわからないので、データ取得時点をクライアントで記録するしかない。ただし、リソースサーバー側の障害や遅延などしている可能性が排除しきれず、正しい値が出ているのか検証不能であり、障害連絡が来たら遡ってデータ修正が必要になる。
第三に通貨単位が、ユニバーサルな通貨コード（JPYなど）ではなく、独自のテーブルを用いている。マッピングテーブル（０１＝JPYなど）を事前に受領したうえで、クライアント側で都度変換しないと、理解できないものになっている。

図４　残念なAPI　残高照会

2-3．IB（インターネットバンキング）接続型の課題

例えばマネーフォワードのような会社は、国内の140行程度のすべての銀行と接続をするニーズを満たさなければいけないので、相当大変であることが想像できる。

このようなことが発生する理由の一つは、API基盤の作り方に起因している。日本の銀行は、勘定系直結型とIB（インターネットバンキング）接続型のどちらかのパターンで、API基盤を構成しているが、IBシステム接続型で問題になることがある。

IB接続型の場合、IBに依存することになる。IBのシステムは、画面表示で最適な情報のみを表示するが、それをそのままAPIにすると、必要なデータが渡されなかったり、画面制御のための情報など、APIでは必要のない情報が渡されたりすることになる。例えば入出金明細照会の場合、画面上で1ページに表示できない場合、「次へ」といったボタンで、続きの明細を出す仕様にすることがある。APIがそのままの仕様で作られると、クライアントアプリが何度も繰り返して情報を取る必要がある。またクライアント側で、必要としない情報を削除の上、合算するなどのコントロールを行う必要が生じることもある。参照系であればまだ良いが、リアルタイムの更新系のAPIでは、このような仕様は、時間切れ等の課題となる。

３．直近の電子決済等代行業界の状況

3-1．現在の状況

金融機関と電子決済等代行業者とのAPI接続が進んでおり、スクレイピングで接続している業者が、API接続に切り替えるタイムリミットが2020年5月末であった。コロナの影響で、基本的な合意をしていれば、9月末までの猶予が追加的に認められている。ただ多くは、5月末に金融機関との間に契約を締結し、API接続に切り替えている状況である。

3-2．公正取引委員会の報告書（4月21日）

契約期限が5月末に迫る中で、4月21日に公正取引委員会が、「フィンテックを活用した金融サービスの向上に向けた競争政策上の課題について」という報告書を公表した。この報告書の背景は2点ある。

第一に、家計簿サービス等を営む事業者と銀行とのAPI接続等の契約の進展が芳しくないという情報があったことから、何が問題なのかを明らかにするものである。
第二に、PayPay等コード決済事業者の台頭を背景に、キャッシュレスの進展等、利用者の決済のあり方が変容しつつあることから、現状に問題ないのかを確認する意味合いがある。

これら2点に関して、銀行のデータ参照・送金等にかかるコスト等がその進展の妨げになっていないかを調査報告したものである。

公正取引委員会の報告書は、以下の4つの文書からなる。

１．フィンテックを活用した金融サービスの向上に向けた競争政策上の課題についてhttps://www.jftc.go.jp/houdou/pressrelease/2020/apr/chouseika/200421_honbun.pdf ２．報告書概要 https://www.jftc.go.jp/houdou/pressrelease/2020/apr/chouseika/200421_gaiyou.pdf ３．家計簿サービス等に関する実態調査報告書https://www.jftc.go.jp/houdou/pressrelease/2020/apr/chouseika/200421_houkokusyo_1.pdf ４．QRコード決済を用いたキャッシュレス決済に関する実態報告書https://www.jftc.go.jp/houdou/pressrelease/2020/apr/chouseika/200421_houkokusyo_2.pdf

全体を把握するには２．の報告書概要を読むのが良いが、詳細を知るには、３．４．の調査報告書本文を読み込むのも良い。報告書の本文の構成は、前半に調査の概要、最後に競争政策上及び独禁法上の考え方が記載されている。業界事情に詳しい人は、最後のところだけを読むのでも内容を理解できる。業界内がどうなっていたのかを知りたい人は前半を読むと、実態を知ることができる。

報告書概要の家計簿サービス等に関する実態調査では、以下を報告書にまとめている。

①の銀行と電子決済等代行業者の関係（図5の中央部）では、銀行から電子決済等代行業者に口座情報提供がある一方で、業者からは接続料等支払がされる利害関係を示している。
②の銀行とシステムベンダーの関係（図5の上部）では、銀行はシステムベンダーに初期費用やランニングコストを払う代わりに、システムベンダーにAPI接続基盤の整備や運用をしてもらうという利害関係を示している。

図5　家計簿サービス等に係わる取引構造

そして①銀行と電子決済等代行業者（以下電代業者）の関係、②銀行とシステムベンダーの関係のそれぞれで、競争政策上の考え方と独占禁止法上の考え方を示している。銀行宛の指摘が7点、システムベンダー宛の指摘が2点ある。

（銀行宛） 1．電代業者向けの接続の確保に向けた更なる方策の検討 2．API接続で取得可能な情報範囲の拡大 3．電代業者向けの契約における不当な見直し 4．競争者の市場排除を目的とした、電代業者向けの取引拒否や情報制限 5．一部の電代業者に対してのみ差別的な取り扱い 6．複数のシステムベンダーから見積もりを取るなど、システム調達の方法に十分な競争性が確保されること 7．人材の育成等によるシステムに対する知見や専門性の確保を図ること （ベンダー宛て） 8．既存ベンダーが、合理的な理由なく仕様公開を拒むなどして、他社ベンダーから受託することを不当に妨害すること 9．既に提供している勘定系システムやIBシステムの提供の停止を示唆することにより、自社とのAPI接続基盤の取引を強要し、不当に、銀行が他社ベンダーに委託できないようにする

3-3．公正取引委員会報告書のキャッシュレス決済編（参考）

以下の通り独占禁止法上ないし競争政策上の指摘が9点ある。

（銀行宛） １．コード決済事業者とのチャージ等取引を拒絶することやチャージ等取引に係る手数料を事実上拒絶と同視し得る程度まで引き上げること ２．①銀行自らが提供するコード決済サービスの加盟店開拓を行わせること、 ②キャンペーン費用の負担を要請すること、 ③ノンバンクのコード決済事業者の保有するデータを提供させることなどにより、相手方に正常な商慣習に照らして不当に不利益を与えること （NTTデータ宛） 3．CAFISの利用料金が固定的であることは、銀行口座からのチャージ等に係る費用を高止まりさせることにもつながるおそれ （銀行宛） 4．各銀行は、決済インフラへの競争圧力を高めるため、更新系APIの利用を簡便に行える環境の整備を検討 5．資金移動業者のアカウントへの賃金支払の解禁が行われた場合には、銀行とノンバンクのコード決済事業者間のコード決済における競争条件のイコールフッティングの確保に好ましい影響が生じる （全銀協宛） 6．銀行間手数料の必要性を含めた検討を行った上、設定水準、設定根拠に関する説明責任を十分果たすことにより、事務コストを大きく上回る銀行間手数料の水準が維持されている現状の是正に向けて取り組むべき （全銀ネット宛） ７．全銀ネットは、エンドユーザーのニーズを反映できるようガバナンス体制を強化することが望ましい 8．全銀ネットは、全銀システムを利用した取引コストの透明性を確保することが望ましい 9．全銀ネットは、全銀システムへの接続に求められる条件を整理し、条件を満たす資金移動業者に対しては、アクセス開放を検討することが望ましい

４．これからのFinTech予想

4-1．キャッシュレスの未来

消費税増税還元施策は、6月末で終了したが、マイナポイントの還元施策や、公正取引委員会の報告書、コロナ禍の影響でECサイトの利用や店頭でのキャッシュレス支払が進展している。

キャッシュレスがらみでは、冷蔵庫にセンサーとAIがついていて、「たまご」の利用スピードを把握して、無くなる直前に適量をAPIで発注する世界が来る可能性がある。APIは本質的に、このように自分の認識していないところで自動的につないでいくことに相性が良い。

キャッシュレスは過程に過ぎず、ペイメントレスの兆候ではないかと考える。なぜなら「移動したい」「モノが欲しい」「コトが体験したい」わけであって、「お金を払いたい」わけでは無いからである。組み合わせによるAPI活用が新たなユーザー体験の創出につながると予想する。その際、IOTで機器が判断して取引を行うAPI×IOT決済の世界では、手数料体系も高速トランザクションの世界に対応した新たな体系が必要となる。

4-2．銀行や決済周りで起きること（予想付）

①全銀ネットに銀行以外が接続できるようになる。
例えば○○Payから証券会社に振り込めるとか、クレジットカード支払いを○○Payで行えるなど。
②○○Payで給与を受けとれるようになり、海外から来た労働者も給与を受け取りやすくなる。
③全銀送金手数料の大幅値下げにより、100円未満の少額チップの送金や、オンラインスポーツ観戦に対する投げ銭やアイドルの応援ができる。

4-3．金融サービス仲介法制

2020年国会にて金融関連で2つの法改正が成立した。金融サービス仲介法制と資金移動業の三類型化である。金融サービス仲介業は、銀行のみならず、証券や保険にまたがった仲介業を創設するものである。具体的な提案イメージは以下のようなものがある。

①家計簿ソフトで連携している銀行が取り扱う住宅ローンの金利を表示して並べて提案する。
②住宅ローンを提案したお客さまに、その後の資産運用を提案する（銀行を紹介した後、証券を紹介する）。
③オークションやフリーマーケットの売上から直接株式が買える。
④スーパーアプリで旅行を予約すると旅行保険が提案される。

金融サービス仲介は、既存の業者が存在している領域に法律を設置するというアプローチではなく、誰がプレーヤーとして出現するかは未知数である。法施行は2021年秋ごろと言われており、現在自主規制団体設立に向けた議論が始まったばかりである。

4-4．その先の規制改革領域

規制改革推進会議の投資等ワーキンググループで議論されている証券業や資産運用業ではないかと考えている。米国でできて日本ではできないこととして、以下がある。

①未公開企業の資金調達に関する証券会社による募集行為…ユニコーン企業を生む出すために、有効ではないか。
②特定の株式と交換できる、コンビニプリペイドカードの販売
③デビットカードで決済すると、ポイントの代わりに、買い物した会社の端数株式が貰える。

4-5おわりに

諸外国の動向も踏まえて、電子決済等代行業という業が誕生したが、APIを用いた真のサービス活用はまさにこれからである。関連する法制度改革は現在も進行中である。海外事例を少し見るだけでも、日本でも法制度をちょっと改正すればできるような面白いサービスはたくさんある。

日本でもこれから面白いサービスがたくさん誕生するのではないかということで、楽しい「FinTech　JAPAN」みたいなことが、今後も起きていくと考えていただければ、私の今日お伝えしたかったことが伝わったと思う。ご清聴に感謝する。

【質疑】
質問：簡単に言うと電子決済等代行業者と資金決済業者の違いはなんでしょうか。

回答：電子決済等代行業者は、銀行との関わりが必須で指図をする立場だが、資金決済業者は顧客からの資金を預かり、送金や決済を行うものである。

質問：ポイント業者から銀行口座に逆チャージする場合に、何か法的問題はありますか。

回答：ポイントは、金融機関が発行したもの等でない限り、基本的に口座に現金換金することはできません。

質問：金融機関ごとにAPIの仕様は異なるのでしょうか。仕様を統合する動きはないのでしょうか。XMLのメタデータ付き変換には対応していますか。全銀EDI（ZEDI）とも関係しますか。

回答：銀行ごとに画面が異なるように仕様は異なっている。全銀のAPIの報告書で、最低限の標準化の議論はあるが、細部まで統一すると、ハッキングされやすくなるということなどもあり、一定程度自由度を持たせている。銀行APIの仕様としては、最も軽量化を図れるJSON APIを採用した。XMLでは高頻度のトランザクションが発生する際に、ボリュームが増えてボトルネックになる可能性があるためである。全銀EDI（ZEDI）については、直接APIとは関係ない。

質問：現金での支払いを拒否することを禁じる法律についてどう考えるか。

回答：災害時等を考えると、法定通貨はどこでも使えることが必要である。特に日本のような人口規模の場合、現金受入れを許容することが必要と考える。

質問：電子決済代行事業者間の競争については、どのような策を法で取られているのでしょうか。

回答：電子決済等代行業者間については、法での規定はなく、自由競争下にある。電子決済等代行業者としての顧客保護等の観点で一律の指導が入っている状況である。

質問：決済等代行業というと、BtoBのビジネスで、売掛金の取立てに発展することになるのか、電子手形の延長になる可能性はありますか。

回答：電子決済等代行業者としては、例としてマネーフォワードを出したので、BtoCのイメージが強かったかもしれないが、BtoBでも3条件を満たせば対象になる。キャッシュマネジメントサービス（CMS）として、大手企業のグループ間のサプライチェーンを担っているような会社も、資金決済を担っていれば対象となる。売掛金の回収や指示を電子的に行えば、電代業にあたるという整理になる。電子手形については、3条件に当てはまれば電代業になるし、違う観点であれば関係ないということになる。

質問：銀行と一口で言ってもメガバンクと地銀クラスではIT部門の体制も大きく違うので、規模に応じた解釈をするのでしょうか。

回答：一律に適用というものではなく、ご指摘の通り、規模に応じた解釈をすると考えられる。

質問：全銀ネットはトランザクションの金額によらず、同一のセキュリティレベルを担保し、これが高コストの原因の一つと思うのですが、例えば3万円以下のトランザクション専用のネットは考えられないでしょうか。

回答：少額決済について、「全銀LITE」検討の議論が既になされている。

質問：金融サービス法案の原文や審議状況はどこで確認できますか。

回答：金融審議会のサブグループである「決済法制及び金融サービス仲介法制に関するワーキンググループ」で議論された。

質問：日本における電子決済等代行業の普及促進に係る阻害要因とその対応策は何か

回答：様々な要因が複雑に絡み合っているのだと思う。銀行がAPI開放したくないとか、仕様が今一つであるということで、銀行がやり玉にされているようなところもあるし、インフラを提供する会社がコストの高いものを銀行に提供しているため、あまり使われていないという流れもある。家計簿ソフトや会計ソフトが諸手を挙げて素晴らしいという状況でない点もあり、電子決済等代行業者側の努力も必要かと思われる。これらが少しずつでも進歩して、いい方のスパイラルに入っていけばよいと、電子決済等代行事業者協会の理事として考えている。

質問：米国でのAPIの状況はどこで見れば良いですか。

回答：米国は日本より進んでいない。国を挙げてAPI化を図ろうとはしていないので、お示しできるものはない。

質問：システム監査の目線で言うと、不適切な契約などは検証できそうですが、「契約しない」というのは、検証が難しいと思いました。

回答：銀行には連携及び協働に係る方針の公表義務があり、そこに連絡先窓口も公表されている。例えばこちらへの問い合わせの総数を分母に、業務監査に関しては、問合わせが来ているのに放置していることを、監査できるかもしれない。

質問：小規模な電子決済代行業者にとっては、銀行のセキュリティ等の要件のハードルが高くて、対応しきれないということが発生する可能性はないか。

回答：銀行が電子決済等代行業者と契約を締結する際に用いる、FISCのチェックリストがある。この基準に逸脱していないかどうかを確認することで対応できると思われる。

質問：今の議論の関連で、電子代行業者の事業継続に係る主なリスク事項と監査に期待することは何かありますか。

回答：今までは、万一サービスが無くなっても、不便にはなるが、大きな混乱は生じないという整理だった。しかし今後は電子決済等代行業者の事業継続性をサポートすることありうるのではないかと考える。

質問：APIからのDDOS攻撃への対策を考える必要はないか。

回答：銀行APIの機能は、「認証認可の画面」「APIそのもの」の２つに分けられるが、画面についてはそもそも銀行のインターネットバンキング自体で対策が打たれている。APIそのものについては、接続先である電子決済等代行事業者にアクセス元が限定されているので、APIがまとめて打撃を受ける可能性としては小さいのではないか。
（文責遠藤正之）

7月、新たに3年生4名が研究室に配属されました。
今期は、研究室の会合もZoomオンラインで行っていますが、
この日だけは感染防止策を徹底しつつ、リアルでの歓迎会を行いました。
オンラインではわからなかったのですが、高身長の学生が多いという気づきも。
【感染防止策】
１．座席を一つ置きで、向かい合わない形で、ソーシャルディスタンスを確保。
２．個別で蓋付の食事（うな重）とする。効果として、食べることに集中でき、必然的に会話は食後となりました。

遠藤が副主査として開催した研究会が、法政大学市ヶ谷新一口坂校舎で開催されました。
（遠藤以外に修士学生1名も参加）
カンボジアの事例から日本のキャッシュレスへの提言まで、すばらしい講演内容でした。

日時：2020年2月19日（水）18：30～20：20
テーマ：カンボジア国立銀行デジタル通貨「バコン」とブロックチェーンの最前線
講師：宮沢和正氏（ソラミツ株式会社特別顧問、3/1より代表取締役社長）
出席者：27名
■講演要旨
カンボジア国立銀行と日本のソラミツ株式会社が共同開発した世界初の中銀デジタル通貨「バコン」（Bakong）は、2020年3月末から正式運用が開始される。「バコン」は、日本発ブロックチェーン「Hyperledger Iroha」を活用したトークン型のデジタル通貨で、国家全体の決済アーキテクチャの大幅な簡素化・低コスト化を実現している。日本も国際的な競争に乗り遅れないように、日本銀行メンバーに加えて決済や技術の専門家チームを組成して、中央銀行デジタル通貨に関して、具体的な実施計画を検討すべきである。

【講演内容】
１．講演者と所属企業の紹介
宮沢氏は、カンボジア中央銀行プロジェクトの総責任者で、その前はソニーで交通カードSUICAの開発,楽天でEdy創業を行うなど、電子マネー関連での経歴が長い。
ソラミツ株式会社はブロックチェーン技術で社会課題を解決するミッションの企業。設立は、4年前の2016年2月で日本、スイス、ロシア、カンボジア等6か国に子会社があり、従業員数約60人。実績としては、中央銀行、証券取引所、金融機関等との取引が中心。ブロックチェーン開発に加え、インターオペラビリティ開発を行っている。

２．カンボジア中銀デジタル通貨
2.1導入の経緯
カンボジアは、銀行口座の開設率が22%と低い一方で、スマホ普及率は150%と高く、2台持つケースも多い。最近Wingというモバイル送金を行う決済事業者が、全国で4000店舗以上店を作り、スマホによる送金が拡大してきた。農村部の金融包摂を促進するということと、決済事業者の管理を行うという、２つの課題に対し、中央銀行がネットワークを整備したうえで、決済事業者を含む金融機関が参加する決済の仕組みを作ることとした。

このネットワークやシステムの構築には、ブロックチェーンの改ざんできない、二重支払いができないという特徴が必要であるとして、共同開発するブロックチェーン技術企業の選定が行われた。ソラミツ株式会社には、2017年1月に問合せがあり、他2社との競争入札で選定され、2017年4月から共同開発を開始した。2019年7月に本番システムの開発が完了し、テスト運用として、大手のアクレダを含む11銀行が参加し、7千人が送金や店舗での支払いに活用している。2020年3月末に正式運用を開始し、全銀行120行に広げる。

2.2カンボジア中銀デジタル通貨の特徴
①データ自体が現金と同等の価値を持ち、転々流通可能なトークン型のデジタル通貨。「バコン」はデジタル財布の名称で、通貨単位はカンボジアリエルとUSドル。
②入手方法は、カンボジアの携帯電話番号を保有している人は、誰でもアプリをダウンロードして民間銀行か決済事業者を選択して登録し、現金または預金と交換して入金できる。現在は現金入金が中心。Wingや銀行に行って現金を入金している。取引は瞬時で信用リスクはなく、個人間・企業間・銀行間の直接送金、店舗や請求書のQRコードでの支払いが可能で、日本のようにコンビニに行く必要はない。
③利用方法は、送金先の銀行口座番号を知る必要がなく、相手の携帯電話番号宛に直接送金したり、対面でQRコードをスキャンしたりすることで決済や送金を行う。送金手数料や加盟店手数料は無料である。決済手数料も無料である。ただし銀行やWingは現金と交換するときに、若干の手数料を取っている。
④匿名性とマネロン対策については、銀行口座は必須でないため、本人確認未済でも使えるが、その場合、1日250ドル＋250ドル相当のリエルが上限である。本人確認して銀行口座と紐づけると1日2500ドル以上の取引が可能となる。口座開設率を上げるのが一つの狙い。
⑤ユーザーが端末を紛失した場合でも、本人確認による鍵の付替えができる。ビットコインは鍵を紛失すると使えなくなるが、実用化のため、付替え機能を開発した。
⑥間接発行であり、カンボジア国立銀行にとっては、所有者は匿名。民間銀行が本人確認によりKYCが行われる。
⑦ソラミツが開発したブロックチェーン「Hyperledger Iroha」を活用し、カンボジア国民1600万人に提供する強固なセキュリティと十分な処理能力を実現。
⑧少額のリテール決済から高額のホールセール、銀行間取引まですべて一貫して一つのブロックチェーン化している。国家全体の決済アーキテクチャの簡素化、低コスト化を実現している。日銀ネットのRTGS（Real-Time Gross Settlement即時グロス決済）の100分の1程度の費用で実現できている。
⑨2017年に銀行APIが全銀行で義務化された。中央銀行がHUB化しており、１ヶ所つなぐと全銀行に繋ぐことができる。Edyを銀行に繋ぐときは１行あたり30百万円くらいかかった。100行と接続するためには30億円かかることになるが、今回は0円でできた。また、他の決済手段を禁止し、通貨や決済を乱立させないようにしている。「バコン」共通APIを各銀行に開放し、各銀行は独自サービスを追加している。
⑩海外とのクロスボーダー送金・決済も開発中。具体的な対象国はタイとマレーシア。

2.3カンボジア中銀デジタル通貨導入の目的
①金融包摂、金融政策力の維持、銀行口座開設率の向上
銀行支店がない農村地域でも本人確認不要で「バコン」サービスが開始できる。
②自国通貨の強化、電子商取引、クロスボーダー決済
現在、ドル取引が7割だが、テスト運用段階での「バコン」での決済は4割がドルでリエルが6割となっており、自国通貨の強化に繋がる。またクレジットカードを持っていない国民が多いので、電子商取引の決済手段ともなる。Wingの4000店舗で「バコン」を利用できるようにして、加盟店もそのまま利用できるようにする。中国のデジタル人民元もアリペイやウィーチャットペイ、銀聯で利用できるようにするという同様の戦略を取ると聞いている。
③最先端システム、国家全体の決済アーキテクチャ簡素化・低コスト化
リテール決済からホールセール決済（RTGS）を同一のシステムで処理可能。決済手段乱立の解消、現金流通コストの削減。銀行API（ISO-20022）で従来のコアバンキングシステムと連結。現在はブロックチェーンのノードは中央銀行が持っているが、将来的には一般銀行にも開放するかもしれないとのことである。

2.4アプリケーションの特徴
ユーザー・加盟店向けアプリケーションは、スマートフォンアプリで、ドル・リエルが使い分けれる。金融機関管理者向けアプリケーションでは、高額取引はマルチシグニチャーが必要である。金融機関ではモニタリングにより、疑わしい取引の停止も可能。

３．中銀デジタル通貨の分類、日本のキャッシュレス決済との相違点
3.1カンボジア中央銀行の発行するデジタル通貨
目的は信用リスクのない支払手段の提供、金融包摂の推進、金融政策力の維持であり、現金と同じ流通形態を取り、徐々に現金を代替するため、通貨発行量に影響がない。
・銀行券の代替かつ銀行間の大口決済でも利用
・匿名の場合、利用限度額あり、本人確認すると利用限度額拡大という二面性。
・価値保存はトークン型（⇔口座型）
・利用者への発行は民間銀行が発行する間接発行形態（⇔中央銀行直接発行）
・発行量のコントロールは、紙幣を裏付けとして制限を設ける
・付利なし
・データ活用は民間銀行が活用するが、政府は活用しない。

3.2中銀デジタル通貨と現金・電子マネーとの比較
デジタル人民元がよく似ているが、人口14億人が対象のため、ブロックチェーンは一部での利用で、それ以外は中央集権的な仕組みと聞いている。2020年にテスト開始の方向。二層形式の間接発行である点は同じ。
LIBRAも似ているが、一番大きな違いは中央銀行が発行することと、価値裏付けが法定通貨か通貨バスケットであるかという点である。LIBRAは様々な課題があり、解決しないと発行できないとして世界中で議論がされている。

	デジタル人民元(中国）	Bakong（カンボジア）	Eクローナ（スウェーデン）	現金	電子マネー	LIBRA
発行者	中央銀行	中央銀行	中央銀行	中央銀行	企業	LIBRA財団
形式	二層形式 間接発行	二層形式 間接発行	直接発行と間接発行を検討	銀行経由の直接発行	直接発行	二層形式 間接発行
価値保存	トークン型	トークン型	口座型	現物保有	口座型	トークン型
技術	ブロックチェーンを権利確認と照合で使用	ブロックチェーン	ブロックチェーン以外のデジタル技術	紙印刷	RDB等	ブロックチェーン
価値裏付け	法定通貨	法定通貨	法定通貨	法定通貨	供託金等	通貨バスケット
匿名性・追跡可能性	匿名性有、追跡可能	匿名性有、追跡可能	匿名性有、追跡可能	匿名性有、追跡不可能	匿名性有、追跡可能	匿名性有、追跡可能
利用状況	2020年にテスト開始見込	2020年１Q運用開始	運用開始準備中	流通中	流通中	運用開始に向けた課題あり

トークン型のデジタル通貨は、データ自体に現金と同等の価値があり、ファイナリティがある。銀行間・企業間・個人間での直接取引が可能である。
口座型の場合、企業間での支払いの場合、企業Bが月末締め翌月払いのような形で送金をして、企業Aは着金確認をする。ネット決済で様々な取引が混在しており、着金まで引当てをするということを、大体の企業は行うなど、多くの工数がかかる。
これがトークン型の場合、トークンは現金と同じなので、その場で払って完了する。すべての支払いがグロス決済（RTGS）できるので、資金清算の振込や着金確認が不要になる。企業間の取引に銀行不要となる。銀行の決済業務が縮小していく。
ブロックチェーンにはスマートコントラクトの機能を付けることができるので、税金支払や賃貸等の契約に連動した定期的な支払が可能である。会計処理が透明化され、監査に使うということもできる。決済や支払が根本から変わってくる。

3.3日本のキャッシュレス決済との相違点
日本のキャッシュレス決済は高コストで、加盟店にも負担が生じる。
①決済間の相互互換性がないため。複数の決済手段を受け入れるための投資がかかる。
②加盟店への振込に約1カ月かかるなど流動性が低い。小規模店では利用金額が少ないことから、振込手数料の負担のため、3か月まとめて入金するようなこともあり、その間の資金負担が生じてしまっている。
トークン型になれば、加盟店では資金の流動性が高くなり、システム投資も低減できる。シンプルな仕組みとするか、既存システムに相互運用性をつけるという形にするか判断の岐路に立っている。日本では、金融機関、クレジットカード会社、新しい決済事業者の関係がミッシングリンク（連続性が欠けた部分）で、n:nになっているが、ここにHUB機能を作るべきではないかと提言している。決済事業者が金融機関に接続するため、各社重複投資をしており、接続機能を提供する企業だけが儲かっている。カンボジアでは、中央銀行がHUB機能を作って、XMLでつながっていて、口座の送金手数料が無料となっている。カンボジアの中央銀行からすると、お札を発行し輸送管理し、ATM網を維持するコストが低減できるので、「バコン」の仕組みは無料で提供できる。
ConsenSysが2020年の1月にCBDC（中銀デジタル通貨）を提案するホワイトペーパーを出しているが、3年前に設計した「バコン」の仕組みとほとんど同じである。唯一異なる巻き戻し機能のところは、中央銀行が万能になって何でもできてしまい、国民から信頼されないのではないかということであえてつけないこととした。
ブロックチェーンを使う必然性は、システム管理者でも頭取でも政府でも、何人たりともデータを変えることができないことを技術で担保することで、カンボジア国民の信頼を得ることができると考えたことによる。

４．地域通貨・スーパーシティ構想への活用
4.1　地域通貨の取り組み
ソラミツは、会津若松で、地域通貨の実証実験を行っている。将来的に中銀デジタル通貨とも相互運用可能な地域デジタル通貨として設計しており、自治体共通プラットフォームの実現を目指している。会津若松は、5月から本番稼働を考えているが、「バコン」の仕組みを、カスタマイズしたので、４ヶ月くらいで開発できた。他の地域でもすぐにカスタマイズ可能である。地域通貨は、決済手段だけではなく、善意の流通、エコ活動推進、中小企業の資金調達にも活用の可能性があると考えている。

５．日本における提言
5.1日本のデジタル通貨検討をめぐる動き
自民党の金融調査会のデジタルマネー推進ＰＴで、カンボジア中銀デジタル通貨「バコン」と日本における提言に関して、2019年11月26日と2020年2月7日の2回議論した。それを受けて、自民党（1月15日）、MUFG（1月28日）、JPモルガンが、カンボジア中銀を視察している。

5.2日本における提言（11月26日）
①デジタル通貨（ホールセール・リテール）の決済及び技術エキスパートチームを結成し、制度面、技術面、運用面などの具体的検討と実証実験を実施すべきである。現在は日本銀行のメンバーだけでなく、実務経験者や最先端の技術を持っている人も入れるべきである。
②ホールセール向けデジタル通貨を、早期に導入し、乱立する決済手段を纏める役目を果たすべきである。税金支払いや現在のキャッシュレス手段である電子マネーやスマホ決済（SuicaやPayPay）へのチャージを可能にすることを提案した。
③民間金融機関と共創で、「リテール向けデジタル通貨」をモデル地区から導入して、地方創生に活用しながら、検証、技術開発、相互接続を実施することを提案した。
④政府が標準化、法制度、枠組み整備を実施するよう提案した。
中銀デジタル通貨の優位性と課題については、以下を示した。ただし、停電等を考えると現金がゼロにはならないと考えている。

	優位性	課題
日本国	・通貨主権・金融政策の有効性向上 ・決済手段の相互運用性を確立し乱立を解消 ・民間決済事業者倒産によるリスク低減 ・クロスボーダー決済、インバウンド対応	・停電に対する対応 ・国民全体のITリテラシー向上が必要 ・プライバシー・セキュリティ対策
銀行 金融機関 決済事業者	・現金流通・管理コスト削減、利便性向上 ・資金移動・決済システムコスト低減 ・データ活用ビジネス ・金融ワンストップサービス	・金融機関の信用不安の場合には、取付騒ぎ対策が必要 ・銀行の信用創造力の低下防止
個人 企業 自治体	・乱立した決済手段の一元管理 ・送金・決済の利便性・即時性・手数料削減 ・転々流通による流動性拡大 ・スマートコントラクトによる自動化・透明化	・停電に対する対応 ・プライバシー・セキュリティ対策

日本のデジタル通貨の発行形態としては、「二層構造」の間接発行で本人確認やウォレット管理は仲介機関（銀行・信用金庫、証券会社等、前払式支払手段、資金移動業者）が実施する形態で、現在のキャッシュレス手段と共存し、現金と同様の価値と利便性を持たせて流通することを提案した。最初は銀行からということが常道かと考えている。
カンボジアは1600万人だからできたが、日本は1億３千万人でできるのかという疑問に対しては、ブロックチェーンを二層構造で連結するよう、インターレジャーやアトミックスワップという技術を活用すれば、理論的には数億人から数十億人のスケーラビリティが可能と説明している。ただ実証はされていないので、実証実験を提言している。

5.3今後の検討課題
今後の検討課題としては、以下が挙げられる。
①金融政策への影響…現金（M0）だけでなく、預金とか定期預金に広げる場合、金融政策への影響がどうなるかという点。
②仲介機関の対象範囲や機能…資金移動業者を含めるか、含める場合どのような管理を行うか。
③金融機関などへの影響…金融機関の業務スタイルがどのように変化するか。定期預金について一定期間ウォレットからの引き出しを停止し、その預金を見合いに貸出として信用創造を行うことで新たなビジネスができるかもしれない。
④AML／KYCへの対応…本人確認の精度向上や、テロ資金等のマネロンの疑義がある場合の組戻し等のルールの整備が必要。
⑤個人取引情報の保護…アクセス制限の設定をどうするか。
⑥法制度整備…ファイナリティの定義や、第三者対抗要件等の手当。仲介機関を跨いで価値が移動する場合の仕組みが必要になる。カンボジアでは、デジタル通貨と現金のバランスが崩れた場合、手作業で行っているが、今後自動化やルールを作る検討が必要になる。

5.4日本における中銀デジタル通貨検討の今後の進め方
現状のキャッシュレスの状況は課題があるので、改善できないかと考えている。他方、金融政策等の課題があり、簡単ではないので、早く実証実験等を開始し、課題の洗い上げをする必要がある。国際的な競争に乗り遅れないために、早く専門家チームを組成し、具体的な実施計画の工程表を作ることを、政府にお願いした。

６．Hyperledger Irohaについて
6.1 Hyperledger Irohaの特徴
Linuxと同じように、オープンソースで世界標準になることを目指し、Linuxが制定したHyperledgerプロジェクトに応募し、2016年10月には、全世界260社の中から、投票でIBM、Intelに続いて3社目としてソラミツが選ばれた。2019年5月には、バージョンアップしたものが、Linuxから商用バージョンとして認定された。
オープンソースなので無償。セキュリティ監査をKPMG、トーマツにやってもらっている。日本のブロックチェーンを開発している企業はいくつかあるが、オープンソースは、ソラミツのみ。一般的なブロックチェーンの課題をすべて解決した。具体的には下記。

ブロックチェーンの課題	Hyperledger Iroha
①開発・導入・品質確保が困難	開発導入容易性は、他のブロックチェーン比ダントツ JAVAやPythonが書ければ開発できるレベル カンボジアのエンジニアでも開発可能で生産性も高い
②処理能力低い、ファイナリティなし	高速大量処理で、ファイナリティもある。 Hyperledger FabricやCorda 等と比較しても、処理スピードは速い
③プライバシーが無く、鍵紛失で利用不可	必要な人にしか情報を見せない 鍵をなくしても再発行できる
④単一障害点、ビザンチン将軍問題	BFT・単一障害点なし 高い信頼性と安全性実現
⑤必要リソース大、モバイルSKD（ Software Development Kit）不十分	B2Cマーケット向け Webモバイル対応(SKDも豊富)

６．２カンボジア中銀との共同開発での機能拡充

①開発・導入・品質確保の容易性…あらかじめ定義されたコマンドを用意した。例えば送金であればTransferAssetというコマンドを使えば一行でできる。二重送金がないか等のチェックをすべてした上で送金することができるコマンドである。AddAssetQuantityというコマンドでは、通貨の発行を追加することができるが、中央銀行の権限者に限定し、マルチシグニチャーで権限者が例えば3人集まらないと実施できないように設定ができる。
②プライバシー…Role Based　Access Control　モデルにより容易に対応できる。銀行ごとにドメインを分けた上で、役割（Role）や権限（permission）を設定する。カンボジア中銀からは、各銀行は自行の取引は見れても良いが他行の取引は見れてはいけない。中央銀行はすべての銀行の取引を見ることができるといったニーズが出た。これら権限のニーズを簡単に設定できるブロックチェーンはあまりないが、Irohaでは簡単に役割別のアクセスコントロールとして設定できる。
③消費者保護機能…携帯紛失時には、鍵再発行する必要があるが、反面誰でもが再発行できてはいけないので、自分の鍵の再発行権のみを管理者（口座の銀行）にGrant（譲渡）できるとした。管理者が本人確認の上で、古い鍵を消して、新しい鍵を設定することとした。
④ガバナンス…コンソーシアム型なのでもともと優れているが、（反面生じる）権限集中の懸念についても、配慮している。中央銀行が勝手に何でもできるようにしてはいけないということで、三権分立の仕組みをブロックチェーンに取り込むようにした。いわば「憲法」を最初の「Genesis Block」に記載することで、「憲法」を変えることができない仕組みをブロックチェーンの中に凝縮して取り込んだ。

Hyperledger Irohaは何億円も投資しているが、オープンソースで無償利用できるので、ソラミツの収益モデルとしては、Redhatモデルで、周辺の開発ツールやアプリケーションを有償で提供している。全体をUNKAI/雲海と呼んでいる。開発パートナーとして7社、ユースケースパートナーとして43社と連携し、Hyperledger Irohaオープンコミュニティメンバーが全世界で300名以上いる。

７．インターオペラビリティの取組み
①Two-way Pegサイドチェーン…ビットコインやEthereumをHyperledger Irohaに接続することで、セキュリティや処理能力を高める技術。
②Polkadot Runtime Environment…ソラミツとW3F（Web3.0Technologies　Foundation）とで、インターネットのTCPIPがネットワークをつなぐように世界中のブロックチェーンをつなぐものの開発を開始している。
③ISO/TC30７ブロックチェーン国際標準化でインターオペラビリティを審議しているが、日本代表委員として参画している。
以上のように、様々なブロックチェーンを相互接続することで世界を覆うTrusted　Internetを実現すべく、デファクト、デジュリーの両面から活動している。

８．質疑応答
Q：停電やネットワークが繋がらなくなった場合に関しての議論はあったか。
A:二重化三重化の仕組みを入れているが、完全にストップした場合に備え、現金で決済できるように準備している。

Q:KYCに関しては、銀行口座を作成することで確認するのか。銀行口座を増やすのが目的なのか。
A:カンボジア中銀としては、現状保有率22%の銀行口座を増やすのが目的であるが、農村部まで支店を作るのは難しいので民間の決済事業者とも提携するが、仮に仲介機関が倒産してもデジタル通貨は中央銀行が保証しており、倒産隔離されるので、それも今回の趣旨である。

Q:紙幣を裏付けにする意味は。
A:インフレを回避するために、市中の紙幣を回収して発行することとしている。

Q:本人確認がない場合の上限250ドルの理由は何か。
A:背景は教えてもらっていない。マネロンの関係と日々の支払いはできるレベルかと。

Q:データの利活用で民間企業は何を活用するのか。
A:一つの例として、リネットとソラミツがジョイントベンチャーの会社を作ったが、リネットはマイクロファイナンスの会社であり、利用者の許諾が前提となるが、決済情報とファイナンスの情報から、信用スコアリングを行うことを計画している。

Q:データはどこに蓄積されるのか。
A:民間金融機関に蓄積される。

Q:デジタル通貨で資金供与に関しての変更はあるか。
A:デジタル通貨自体では信用創造はできないので、デジタル通貨を預金してそれを元に信用創造することが基本である。デジタル通貨自体での信用創造にも方法が考えられるが、今後の動向を見ていく必要がある。

Q:Libraのような世界通貨の可能性や中央銀行の決済はどう変わっていくと考えているか。
A:非常に大きなテーマである。Libraについては、各国からみて通貨主権を脅かす存在として反対されるので、容易には発行できないと思われる。ただLibraがきっかけになって、各国でデジタル通貨の議論が起こった点は、人類にとっては進歩である。開発途上国では、BISの調査では、3割くらいが数年以内にデジタル通貨を採用するとしており、開発途上国の方が実現は早い。ソラミツも50か国程度の中央銀行に売り込んでおり、小さい国や現金の輸送コストが高い島国などで需要がある。

Q:他国通貨であるUSDをデジタル通貨化してしまっている点が驚きだが、アメリカは許可しているのか。アメリカから何か言われていないのか。
A:カンボジア中銀は、あくまでモバイル決済手段と言っている。単なる決済手段であるとしているので、何も言われていないものと思われる。

Q:デジタル人民元はオフラインで決済可能との話があるが、「バコン」はどうか。
A:「バコン」ではできない。人民元については、諸説あるが、オフラインでは二重払いが発生しうるので、やらないのではないかとの意見がある。

Q:日本の地域金融機関は、支店を減らしていく方向かと考えるが、その際、デジタル通貨導入は、代わりになりうるのか。
A:デジタル通貨になると、運営コストはセーブできる可能性がある。決済では儲かっておらず、むしろATMの費用が削減できるなら、決済は無くなっても影響がないと言う金融機関関係者もいる。

Q:カンボジアのように、中央が強いところと比較して、日本では難しいかもしれないが、地域での通貨の方が、実現可能性があるのではないか。
A:日銀へラブコールを送っているが、なかなか難しいので、二面作戦で、地域で作り、その場合は、将来的につながる仕組みを最初から設計しておけば良いと考えている。地銀も、預金量は減らしたくないという点で危機感を持っている。例えば電子マネーで給料を受け取れるという制度改訂に対して、心配しているようである。

Q:ブロックチェーン同士を繋げて、より大きな国でも対応できるという説明があったが、一か所で遅延が生じると、他のブロックチェーンにも影響するのではないか。
A:シャーディングという技術の実証実験は既に行われている。ただ大規模なケースは行われておらず、今後実証実験が必要だと考える。ブロックチェーンでもクレジットカードと同様に、残高を確認してオーソリが先に行われ、台帳記入は後で行われるのと同じと考えれば、残高引落としさえできれば、理論的には大丈夫ではないかとも考えるが、検証は必要である。

Q:障害が発生したとき、送金先の銀行のシステムの方で障害が発生して、取引が完結しなかった場合、戻しが必要ではないか。
A:「バコン」の場合、銀行口座に確実に入金されたという確認が取れるまでは、ホールドするので大丈夫である。

Q:安全保障上、オープンソースで問題ないのか。
A:Irohaはオープンソースだが、「バコン」システムは、有料で開発しているので開示していない。ソラミツは、知財の権利は持っていて、似たようなシステムを他国で構築することができる。ただそのままコピーすることはできない。

カンボジアは良く決断したと考えている。壮大な社会実験に踏み込んだ勇気があり、それに関与できたことは大変名誉なことである。ただ本当にうまくいくかはこれからであり、どのような課題が出るかもわからないが、楽しみでもある。タイの中央銀行とも良く話をするが、カンボジアでうまくいけばやりたいと言っている。その場合、人口は約5倍なので、二層構造が必要になるかもしれない。他にも興味を持っている国は多くある。

（文責遠藤正之）