web3（ブロックチェーン）領域の監査と内部統制：実務指針から考えるコンソーシアムチェーンのガバナンス
本記事の位置づけ
前回の記事（web3（ブロックチェーン）領域の監査と内部統制）に対して、予想外に反響があったのでよりマニアックな続編を書いてみようと思います。マニアックとはいっても、この記事は「監査人が何を考えているのか」を少しでもいろいろな人に伝えていくことを目的にしているので、監査に精通された方には今更な内容が多くなっている点、ご容赦ください。
この記事では監査人が監査手続きを検討する際に参照する「実務指針」を読み解くような形で記載しますが、監査人向けの記事にはあえてしないつもりです。
事業者が実務指針を、ガバナンス・内部統制を構築する上で注意が必要な観点が載っているガイドラインのように活用する一助となればよいと思っています。
日本公認会計士協会によると、今回取り上げる保証業務実務指針3701「非パブリック型のブロックチェーンを活用した受託業務に係る内部統制の保証報告書に関する実務指針」は次の目的で起草されたとされています。
本実務指針は、昨今ブロックチェーンを活用したサービスが広まりを見せている中で、ブロックチェーンを活用した受託業務に係る内部統制の保証業務に対する潜在的なニーズが存在すると考えられることから、保証業務実務指針3402「受託業務に係る内部統制の保証報告書に関する実務指針」を基礎として起草したものです。
小難しい表現が並んでいますが、ざっくりと「そのチェーン、信用していいんだっけ？」という観点に監査人がどう向き合うかの参考指針だとイメージすると、何となく趣旨は伝わるんじゃないでしょうか。
指針の本文では、コンソーシアム型ブロックチェーンを想定して作成されていますが、パブリックチェーンを利用している場合にも共通する観点も含まれているので、どちらのタイプを利用している人にも、ある程度参考になるんじゃないかと思っています。
馴染みのない方もいる想定で、保証報告書（SOC１レポート）とは何ぞやというところから書いていますので、そこはすでに知ってるよという方は読み飛ばして後半から読んでいただいて問題ありません。
なお、本記事における「web3」とは、ブロックチェーン技術を利用したビジネス領域をさし、直接民主主義的な社会・組織形態をさすような広義のweb3は対象にしていません。
※この記事に記載の内容はすべて個人の感想であり、所属組織の意見を代表するものではありません。また、本記事に記載の内容を踏まえて内部統制を整備したとしても、会計基準や契約先の監査法人の要求が満たされることを保証しない点、ご了承ください。
「受託業務に係る内部統制の保証報告書」（SOC1レポート）とは
報告書の目的
今回取り上げる保証業務実務指針3701が、保証業務実務指針3402「受託業務に係る内部統制の保証報告書に関する実務指針」を基にしていることからもわかるように、「受託業務にかかる内部統制の報告書」はブロックチェーンに固有なものでは全くありません。
この報告書は、SOC1レポートとも呼ばれ、受託会社が委託会社に対して、受託業務に関する内部統制が適切に整備・運用されていることを証明するために発行し、その内容に監査法人が保証を与えるもので、クラウドサービス事業者や投資信託会社などが発行しています。まとめるとEYのページから引用した以下の図のようになります。
"保証実3402/AT-C320報告書の作成・利用イメージ"より引用
と、ここまで書いてきましたが、受託会社・受託業務・委託会社と少し硬い言葉が並んでしまったので、クラウドサービス（AWS）を例に、登場人物ごとの目線で簡単に説明してみます。
発行者（受託会社）にとっての保証報告書
報告書の発行主体は、サービスを提供しているAWSになります。ご存じの通りAWSは数多の会社に利用されていますので、仮にそのすべての会社から、「財務諸表監査（もしくは外部委託先管理）の一環として、システムの管理状況を監査させてほしい」という問い合わせを受け、個別に対応をしていてはキリがありません。
そんなとき、問い合わせてきたすべての企業に一括で配布できるレポートがあれば便利ですよね。それがSOC1レポートです。一般的に要求される項目（財務諸表監査であれば保証業務実務指針3402に記載の項目など）について、あらかじめAWSが監査を受け監査法人に署名してもらい、その結果を対外的に公表できるレポートにすることで、自社サービスの管理に問題がないことを証明することができます。
利用者（委託会社）にとっての保証報告書
AWSを利用している企業は、委託元の責任として、外部委託先であるAWSのシステム管理体制に対しても責任を持ちます。しかし、AWSに依頼して直接査察をさせてもらうことは現実的ではありません。そこで、AWSが発行しているSOCレポートを確認することで、直接査察をすることなく委託業務（AWSにお願いしている業務。仮想基盤システムの保守など）が問題なく遂行される内部統制が整っていることを確認できます。
特に、SOX対応が必要な場合、内部統制そのものに対する監査が必要になるため、会社自身がSOCレポートを確認して、十分な内部統制が存在することを確かめていることが重要になります。（SOX監査と内部統制の関係については、冒頭で紹介した前回記事参照）
監査人にとっての保証報告書
最後に、少しだけ監査人の目線からも補足します。監査人といっても、ここでは2つ立場があって、１つは「AWSを監査して、SOCレポートにサインする監査人」、もう１つは「AWSを利用している会社を監査して、AWSが管理を担当している部分はSOCレポートの閲覧によって確認する手続をとる監査人」です。前者については通常の監査と同じで、一般的な監査人・被監査人の関係になります。
後者については、「発行者（受託会社）にとっての保証報告書」で記載した内容と重なりますが、直接AWSを監査する手間暇を省略して効率的に監査を行うアイテムになります。言い換えると、受託会社（ここではAWS）が委託会社の監査人（AWSを使ってる企業の監査担当）からの直接の問い合わせに対応をせず、かつSOCレポートを発行していない場合、監査人はAWSが管理する領域について十分な監査証拠を入手できず、結果としてAWS利用企業の監査について、限定的な意見しか出せなくなる可能性があります。
※AWSはSOCレポートを発行していますので、あくまで例えです。AWSのSOCレポートについては、こちらなどをご確認ください。
※厳密には、内部統制の整備状況に関する報告がType１レポート、運用状況に関する報告がType２レポートなので、財務諸表監査上は、通常SOC1Type２レポートが求められます。SOCレポートの種類や詳細については各監査法人のサイトにいろいろ解説が載っています。興味がある方は検索するか、お近くの監査人にお問い合わせください。
保証業務実務指針3701「非パブリック型のブロックチェーンを活用した受託業務に係る内部統制の保証報告書に関する実務指針」
実務指針の対象と想定される背景
前置きが長くなりましたが、ようやく本題に入ります。保証業務実務指針3701は、タイトルにある通り、「非パブリック型」のチェーンを対象にしています。あまりなじみのある表現ではないかと思いますが、パーミッション型と言い換えるとイメージは近いかもしれません。
この実務指針はブロックチェーンを利用したシステムの管理に関する内部統制について、「システムの管理主体が」報告を行う際の保証報告書に関するものですので、パブリックチェーンのような管理主体が存在しないチェーン（"web3的な"チェーンといってもいいかもしれません）は対象に含まれません。言い換えれば、内部統制・ガバナンスを整備しうる管理者を特定できるようなブロックチェーンが対象で、実務指針内では主としてコンソーシアム型を想定しているとありますが、一組織によって管理されるプライベートチェーンにも、この実務指針大部分が当てはまるということになります。
実務指針を見てみると、ここまで書いた内容が適用指針A1に次のように記載されて言います。
A1．本実務指針は、非パブリック型ブロックチェーンのうち、主としてコンソーシアム型ブロックチェーンを活用したサービスを対象とした適用指針を定めているが、プライベート型ブロックチェーンを活用したサービスについても、本実務指針に準拠することができる。プライベート型ブロックチェーンにおいては、通常、受託会社は単独であるため、本実務指針における受託会社の特定に関する事項は考慮する必要はない。（略）
この記述を見て、もう一つ着目したいのが、「プライベート型ブロックチェーンにおいては、通常、受託会社は単独であるため」という部分です。前段でSOCレポートについて説明したのも、この部分を書きたかったからなのですが、この記述は言外に、「コンソーシアム型ブロックチェーンにおいては、通常、受託会社は複数である」ことを主張しています。実際、付録4の図を見てみると、ブロックチェーンが複数社によって運用されているケースが例示されています。
従来の実務指針では、再受託はあっても、一次受けとなる受託会社は単独であり、その会社がSOCレポートを発行することが暗黙の前提でした。しかしながら、コンソーシアム型ブロックチェーンにおいては、システムを共同運用しているケースが一般的であると想定されます。
不特定多数が参加するパブリックチェーンでは、参加者が一定数を超えている場合において、トランザクションを単独ないし一部の組織が不正なトランザクションを実行したり、過去のトランザクションを改ざんすることは容易ではありません。しかしながら、承認機能を持つノードを一部の組織が独占している場合、それら組織が共謀した場合、不正なトランザクションの実行・データの改ざんが現実的になります。こうしたリスクを踏まえると、コンソーシアム型チェーンに関する保証報告書において、単独の受託会社を想定することは現実的ではなくなります。
これを事業者の目線から言い換えると、コンソーシアムの参加者が真に有効なガバナンス・内部統制を構築するには、自社の管轄範囲だけでなく、コンソーシアムに参加している他社の内部統制をも考慮する必要があることを意味していますし、コンソーシアムを運営する上では参加者間の協調が必要であるともいえます。
実際、実務指針では、複数組織の経営者それぞれが保証報告書に署名すること、すなわち内部統制の管理について責任を持つことを要求しています。
A22. 保証実 3402 第 37 項の適用に当たっては、コンソーシアム型ブロックチェーンにおいて、複数の参加者を受託会社として識別する場合、経営者確認書は複数の受託会社から連名、又はそれぞれの受託会社から入手することになる（「付録３ 経営者確認書の記載例」参照）。なお、受託会社として識別しなかった参加者から経営者確認書を入手する必要はない。
コンソーシアム型チェーンにおける「受託会社」
では、コンソーシアム型ブロックチェーンの保証報告書の発行主体となりうる「受託会社」はどのように特定されるのでしょう。参加しているすべての組織が対象になるのでしょうか。実務指針には、受託会社の範囲について次のように記載されています。
A4. コンソーシアム型ブロックチェーンにおいては、複数の会社によって共同でシステムが運営される特性上、コンソーシアムの参加者を垂直的な受託・再受託関係として 識別するのではなく、並列的な関係として識別した方が合理的である場合も想定され る。このような場合においては、参加者全体を受託会社として取り扱うことも考えら れるが、ブロックチェーンを構成するシステムの管理対象・役割等に鑑みて一部の参加者のみを受託会社として取り扱う場合もある。ただし、受託会社は単独とは限らず、 複数の参加者を受託会社として取り扱う場合があることに留意する。
「ブロックチェーンを構成するシステムの管理対象・役割等に鑑みて」受託会社の範囲を決めるとは、どういうことでしょうか。この点を考えるヒントは、実務指針の<<I. 本実務指針の適用範囲>> <<2.背景>>に記載されています。
４. ブロックチェーンにトランザクションデータを記録する際の、データの真正性を担保するためのルールをコンセンサスアルゴリズムという。（中略）プライベート型やコンソーシアム型で利用される代表的なコンセンサスアルゴリズムとして PBFT が挙げられる。そこで、本実務指針におい てはコンセンサスアルゴリズムに PBFT を利用するブロックチェーンを想定している。
５. PBFT に基づくブロックチェーンネットワークに参加するノードには、リーダーノード、承認ノード、非承認ノードの種別がある。発生したトランザクションは、まず リーダーノードに集められ、複数の承認ノードによってその真正性が確かめられた後、 ブロックチェーンの台帳に記録される。更新が完了した台帳は非承認ノードにも共有 されるため、非承認ノードは承認プロセスには参加しないものの台帳を参照することができる。（略）
PoWやPoSのように、機能としてはノードが対象であるアルゴリズムではなく、ノードごとに役割が異なるアルゴリズムであるPBFTを念頭に置いて実務指針が作成されていることがわかります。この点が、「受託会社」の特定のポイントになります。さらに実務指針の続きを見ていくと、次のように記載されています。
A9. 受託会社のシステムが、ブロックチェーンを利用している場合、通常、以下の内容について理解する。（中略）
(2) ブロックチェーンにおける各ノードの役割、どのように取引が承認され記録されるのか及びその合意に至るコンセンサスアルゴリズム
(7) 通常の取引とは異なるブロックチェーン上のデータの操作をする特例処理の有無、またそれを提供する機能の概要及び実行に関するルール
A11. ブロックチェーンのネットワークにおいては、ネットワークに参加する各ノードが互いにデータを持ち合い、当該データが正しいデータか否かについて全体としての合意が形成される。（中略）コンセンサスアルゴリズムの理解には、以下を含む。
・ 承認ノードの管理主体に関する理解
・ 当該ブロックチェーンを維持するために必要なノード構成の理解
・ ファイナリティの条件の理解
・ コンセンサスアルゴリズムの変更に関する内部統制の理解
A12. コンソーシアム型ブロックチェーンの在り方によっては、受託会社は保証報告書の対象となるシステムに関する記述書に含めるノードの範囲を一部に限定することがある。受託会社監査人がノードの対象範囲を理解するに当たって、本実務指針が想定しているノード種別が有している以下のような性質を理解し検討することが重要である。
・ 「リーダーノード」は発生したトランザクションデータを受け取り、承認ノードに転送する機能を有している。ブロックチェーンネットワークにデータを供給する役割を担っており、有効に機能しない場合にブロックチェーンに大きな影響を与えることから、リーダーノードは受託会社のシステムの主要機能としてシステムに関する記述書の対象となることが多い。
・ 「承認ノード」は、リーダーノードから転送されたトランザクションデータを検証・承認する機能及び承認されたデータを保有する機能を有している。コンセンサスアルゴリズムに従ったデータの検証・承認機能はブロックチェーン上のデータの正確性を担保する重要な役割を担っているため、承認ノードは受託会社のシステムの主要機能としてシステムに関する記述書の対象となることが多い。一方、保証報告書を利用する委託会社が承認ノードを所有・管理している場合、当該ノードを管理する主体が委託会社であることから、受託会社は当該ノードをシステムに関する記述書の対象から除外することがある。この場合、受託会社監査人は、受託会社のシステムに関する記述書で特定されている当該ノードに係る委託会社の相補的な内部統制を理解することが適切である。
・ 「非承認ノード」はトランザクションデータを保有する機能を有している。承認ノードとは異なりトランザクションデータの検証・承認は行わず、例えばデータの監視・閲覧といった、主に承認されたデータを利活用する目的で利用されていることから、受託会社は当該ノードをシステムに関する記述書の対象から除外することが多い。一方、非承認ノードは承認されたデータを保有しており、その管理に係る内部統制を評価することが有用であると受託会社が判断した場合、当該ノードをシステムに関する記述書の対象に含めることがある。
たくさん引用してしまいましたが、太字部分をざっくりまとめると、「ブロックチェーンの機能の根幹を担う、データの承認やコンセンサスアルゴリズムの管理に影響力を持つノード」が、通常はSOCレポートの対象になるというような記載になっています。言い換えると、そのようなノードの管理者が、SOCレポート発行における「受託会社」の対象となってくるのではないでしょうか。実際には合同会社などの窓口となる会社を設置してそこから発行することもあると思いますが、本質的には、重要なノードの管理者が内部統制を整備・運用していることがポイントになるといえそうです。
（余談ですが、この考え方はDAOのガバナンスを考えるうえでも適用できるんじゃないかと考えています。DAOのガバナンスについてもまとめてみたいとは思ってるんですが、現状実務指針などの依って立つところがないので悩ましいです。。。）
事業者に求められるガバナンス・内部統制
ここからは、実務指針の<<III 適用指針>>を参考に、コンソーシアムチェーン（およびプライベートチェーン）の運用において求められる内部統制について考えてみましょう。
コンソーシアムへの参加者の管理
複数の組織によって共同運用されるコンソーシアムチェーンにおいては、組織横断的なガバナンスの存在が必要になると考えられます。例えば、5つの組織のうち３つの組織はAML対応をしっかりと実施していて、ほかの２つの組織はほぼノーガードという状況だった場合、コンソーシアム全体でみると、AML対応が不足しているということになってしまいます。共同運用であるが上に、１社でのリスク対応には限界があり、共通の基準に基づく管理が実施されることが望ましいといえます。この点は実務指針に明記はされていませんが、以下の部分が間接的に示唆しているといえるのではないでしょうか。
A9. 受託会社のシステムが、ブロックチェーンを利用している場合、通常、以下の内容 について理解する。（略）
(4) 各ノードの選定、追加、変更及び削除に関するルール
(5) コンソーシアム参加者に要求されるセキュリティ条件等及びその維持に関する 監視の方法
(4)はパーミッション型チェーンにおけるパーミッションの管理に関するルール、(5)は参加者に求める最低限のセキュリティのルールを理解することを監査人に要求しています。裏を返せば、コンソーシアムにはこうした組織横断的なコンソーシアム全体に適用されるルールの存在が期待されているといえるのではないでしょうか。
秘密鍵の管理に係る内部統制
システムの管理に関する内部統制としては、前回記事でも取り上げた、秘密鍵の管理に関する内部統制に言及されています。
A13. 受託会社のシステムにおいては、データの所有や情報の信頼性を担保する上で重要な役割を果たすシステムや関連する内部統制も含めて理解することが適切である。 これには、以下が含まれる。
(1) ウォレットや秘密鍵を担うシステム、及びそれらを保管・管理しているセキュリ ティ体制・仕組み
(2) ブロックチェーンのデータを閲覧又は入手するためのプログラム等の仕組み
まずは、秘密鍵の管理に関する内容から見てみましょう。
A14. （略）特に、秘密鍵の管理においては、ウォ レットと呼ばれる物理又はソフトウェア上で管理がなされていることを考慮する。ま た、秘密鍵間に親子関係がある場合、親アドレスへのアクセス権を保有していれば子アドレスへもアクセス可能であり、鍵の行使に際しても複数の鍵が要求される仕様が存在する点について留意する。 これら仕様を理解することは、受託会社監査人が以下を行う上で役立つ。
・ ウォレット及び鍵の所有者に関する理解
・ ウォレット及び鍵の管理に関する内部統制の理解
A16．保証実 3402 第 20 項は、受託会社監査人が記述書の表示の適正性の評価に含めるべき事項を規定している。特にブロックチェーンを利用しているシステムの場合、当該評価に当たっては以下に留意する。
・ ブロックチェーン上のデータやデジタル資産の所有権は、秘密鍵を利用した署名によってのみ証明可能である場合が存在する。そのため、ブロックチェーン上で利用される秘密鍵の管理方法についても、通常、評価範囲に含めるが、具体的な保管場所については記載しないことがある。
A14では、HDウォレットを念頭にウォレット・秘密鍵の管理の必要性について記載されており、鍵やアドレスの元となるシードが守られていなければオンチェーンで管理される資産が保全されないリスクが考慮されていることがうかがえます。また、A16では、デジタル資産の所有の確認が秘密鍵管理の内部統制に依拠することによってのみ保証できることへの言及があり、やはり秘密鍵管理の内部統制が極めて重要であることを示しています。（この辺りは前回の記事もご参照ください）
では、具体的にどのような内部統制が求められるのでしょうか。監査人が入手すべしとされている監査証拠の例示から読み取ってみましょう。
A18. 受託会社監査人は、通常、ブロックチェーンを構成する秘密鍵の管理ツールとなるウォレット及び鍵の仕組みを理解し、その管理体制を評価する。また、当該評価には、通常、以下事項が含まれる。
(1) 評価対象となるブロックチェーンが採用しているアドレス間の関係性や鍵を利用した署名の方式に適合したウォレット及び鍵の管理体制が敷かれていること、又は、これを担保する内部統制の運用状況の有効性を評価すること
(2) ウォレット及び鍵とブロックチェーン間の仕組みの理解、並びに鍵そのものの管理方法を理解し、監査の目的に適合しているか評価すること
(3) 鍵を利用する上で必要な認証情報が別途管理されている場合、当該情報へのアクセス権についても評価すること
かなり抽象的に記載されていますが、実務指針の序盤（7.,8.）で署名の仕組みとしてシングルシグネチャーとマルチシグナチャーが紹介されていること、ウォレットの類型が示されていることを踏まえると、署名を完了するに至るまでのプロセスに応じたアクセス制限と職務分掌が求められているのではないでしょうか。
(1)にある「管理体制」は、例えば特定の個人が単独で会社の資産を動かせないように、マルチシグを必須にしたり、ハードウェアウォレットのPINコードを知っている人物とウォレットが保管されている金庫のパスワードを知っている人物を分離されるなど、システムの攻勢に応じた職務分掌・アクセス制限を求めているように見えます。
(3)ではSaaSなどの外部アプリを利用した鍵管理を行っている場合やアクセスキーを利用した署名が行われるような場合に、そのアプリケーションのアクセス管理に関するIT全般統制を整備することが要求されているようです。（一般的なIT全般統制の構成要素についてはシステム管理基準追補版や、書店で販売されている書籍が参考になります。）
(2)はかなり監査手続よりの内容ではありますが、あえて事業者側の目線で読み解くと、監査人に対してこうした内容を、リスクベースで説明し納得させられるだけの深い理解が事業者自身に求められているとも言えます。これは、監査人には理解するための最大限の努力をする責任がありますが、内部統制が有効であることの説明責任はどこまで行っても事業者にあるからです。Tech系の企業であればこの辺りは言われずともというところだと思うのですが、大手企業が参入していくに従い、技術への理解の浅い担当者が増えていき、徐々に問題になってくる部分なんじゃないかと思っています。
※蛇足ですが、A16の「秘密鍵の管理方法についても、通常、評価範囲に含めるが、具体的な保管場所については記載しない」という部分は、セキュリティへの配慮から当然といえると同時に、報告書上で会社が具体的な方法に触れずに「秘密鍵管理の内部統制が適切に整備運用されている」と宣言し、監査人が「確かにそのとおりである」と署名するだけで、その内実を明らかにしない状態で市場の信頼を得るスキームであるといえます。言葉を選ばずに言えば、「署名した監査人を信じろ」という形です。「監査」や「保証」という言葉にはそれだけの重みがあるということを、一監査人として常に意識していきたいと改めて思いました。
オンチェーンデータの利用に関する内部統制
あらためてA13を見てみると、監査人に対する要求としてではありますが、オンチェーンデータの閲覧に関する記載があります。
A13. 受託会社のシステムにおいては、データの所有や情報の信頼性を担保する上で重要な役割を果たすシステムや関連する内部統制も含めて理解することが適切である。 これには、以下が含まれる。
(1) ウォレットや秘密鍵を担うシステム、及びそれらを保管・管理しているセキュリ ティ体制・仕組み
(2) ブロックチェーンのデータを閲覧又は入手するためのプログラム等の仕組み
この観点について、内部統制の評価としての具体的な記載はないのですが、監査人が利用する監査証拠の信頼性に関する記述として、次のような記載があります。
A20. 受託会社監査人は、ブロックチェーンから入手したデータを利用する場合、通常、そのファイナリティと各ノード間の同期のタイミングを理解し、利用するデータを評価する。例えば、非承認ノード（監査人が独自のノードを構築している場合を含む。） からデータを入手する場合で、当該データがファイナリティ完了前のものである場合、 当該データは事後的に更新される可能性があることに留意する。
A21. 受託会社監査人は、ブロックチェーンからデータを入手する際に利用するノード、 プログラム等の仕組みを理解し、入手したデータがブロックチェーンに記録されたデータを正確かつ網羅的に反映していることを確かめることが重要である。なお、ブロックチェーン自体にデータアクセス範囲が設定されている可能性について留意する。
これらの項目は、オンチェーンから取得したデータを利用する際の留意事項を示しており、そのままチェーン利用者の内部統制を考慮する際にも当てはめることができます。
例えばオンチェーンの情報を基に、何かビジネス上の判断を行う際、ファイナリティが完了していないデータが判断に重要な影響を与えてしまうと、想定外の損失を被ってしまう懸念があります。また、全量取得したと思っていたデータが一部欠損していていたというような場合にも同様です。
このことから、オンチェーン情報を利用した分析・検証を行うような業務については、利用するデータの信頼性（完全性）をどのように担保するかを意識して手続きをデザインする必要があるといえるのではないでしょうか。
外部委託先の管理
最後に、付録4を見てみましょう。なかなかイカツイ図が載っています。
（保証業務実務指針 3701（2021年4月23日）付録4 例示4より引用）
付録4では、具体的な内部統制についての説明はありませんが、複数会社で共同運営するブロックチェーンにおいて、関連する事業者が極めて多岐にわたることが述べられています。具体例で考えてみましょう。
会社Aが新しくコンソーシアムのメンバーになり、重要な機能を果たすあるノードを持つことになったとしましょう。このとき、ノードがAWSのEC2で構築されており、OS/DBのメンテナンスはSIerXに、コンセンサスアルゴリズムやオンチェーンデータの取得などの機能の管理は、コンソーシアムの立ち上げ人であるweb3企業Yに任せているとします。この時、会社Aにおいてコンソーシアムチェーンの管理に関する内部統制が十全であることを担保するためには、AWS、SIerX、web3企業Yのすべてで関連する内部統制が有効であることが必要になります。なかなかくらくらしてきますね。
そしてさらに、同じ考え方を重要なノードを管理するすべての共同運用会社に適用しなければならないため、管理者が増えれば増えるほど、比例的に関係者が増える可能性があります。
こうした委託関係の広さを十分に理解して、部分だけで評価するのではなく、全体を通じての管理体制を構築することがコンソーシアムに求められていますし、新たにコンソーシアムに参加することを検討する企業が考慮しなければいけない観点であるといえるのではないでしょうか。
終わりに
シンプルに書こうと思ったのにだいぶ長くなってしまいました。文字数が予定の1.5倍くらいになってますが、引用のせいだと思うことにします。
web3の思想として非中央集権が好まれ、自己責任論が前提になっているところがあるように感じていますが、マスアダプションを目指すのであれば、何もわかっていない素人でも安全にサービスを利用できるように、事業者がリスクをコントロールし、消費者を保護する必要があります。大手企業が参入をはじめ、ますますブロックチェーン技術の利活用が進みそうな今だからこそ、あえて一度ブレーキを踏んで、リスク対応にリソースを割くことも重要だと思います。
FTXの破綻を受けて日本の規制対応が見直されていますが、それで満足するのではなく、安心して利用できるブロックチェーンの最先端を走り続けるためにも、事業者自身がイニシアチブをもって、ビジネス拡大とリスク対応を両輪で進めていくことが大切なのではないでしょうか。