金融サービスの観点
最終更新日: 2026年9月13日
この文書で扱うこと
- 金融サービスがパブリックチェーンではなくコンソーシアムを選ぶ理由と、その選択で実際に残る価値
- 「全員が同じ台帳を見る」という前提とプライバシー要件が衝突する場面、および解決方法
- 鍵管理、規制、既存インフラとの統合のうち、審査会で実質的な論点になるもの
最初に: ブロックチェーンが適さないケースを除外する
金融サービスのブロックチェーン評価で最も多い問題は、技術が課題に合っていないのに進めてしまうことです。この文書では、まずそこを見極めます。
基礎編で説明したように、ブロックチェーンの本質は「信頼できる仲裁者なしで合意すること」です。その代償として、スループットと複雑さが増します。したがって、次のように考えます。
| 状況 | ブロックチェーンは適切か |
|---|---|
| 単一組織がデータを所有し、管理している | 通常はデータベース／監査ログの代替案から始め、明示的な検証やガバナンス要件を比較する |
| 仲裁者が存在し、全員がその仲裁者を信頼している | いいえ: 仲裁者のデータベースで十分 |
| 改ざんの検出だけが必要 | 通常は不要: ハッシュチェーン、署名付きログ、WORMストレージで対応できる |
| 相互に信頼しない複数の機関が共有状態を更新する | 評価する価値がある |
| 第三者が独立して検証できる必要がある | 評価する価値がある |
| 機関間の照合作業に実際に大きなコストがかかっている | 評価する価値がある |
「改ざん検出だけが必要」というのは、特によくある誤解です。監査証跡や完全性の証明が目的なら、署名付き追記専用ログ、ハッシュチェーン、オブジェクトストレージのWORM（Write Once Read Many）機能を使って実現できます。運用ははるかに簡単です。
Amazon QLDBの事例が参考になります。QLDBは「中央の信頼できる当事者を持つ、暗号学的に検証可能な台帳」を提供し、多くの課題はそれで解決できるという前提に立っていました。サービスは終了しましたが、課題の定義は今も有効です。多くの要件で、完全な分散型コンセンサスは必要ありません。
実務上の推奨:「この課題に仲裁者がいてはならない理由」を1文で書けないなら、まずブロックチェーン以外の選択肢と比較してください。
コンソーシアムを選ぶ理由
金融アプリケーションの中には、参加者、ガバナンス、データ配置を管理するために許可型ネットワークを選ぶものがあります。追加の制御を設けたパブリックネットワークを使うものもあります。ネットワークを選んだだけでKYC／AML、プライバシーなどのコンプライアンスが確立するわけではありません。実際の法域、活動、参加者、データフローを評価してください。
| 制約 | パブリックチェーンでの課題 | コンソーシアムの場合 |
|---|---|---|
| 参加者の特定（KYC／AML） | パブリックアドレスだけでは法的な取引相手を特定できない。アプリケーション制御の要件は活動内容による | 参加者管理は役立つが、それ自体でコンプライアンスが確立するわけではない |
| データ主権と所在地 | 世界中のノードにデータが複製される | 参加機関が管理するノードだけに配置される |
| スループットとレイテンシ | プロトコル固有のスループットと、確率的／経済的ファイナリティ | コンセンサスとワークロード次第。許可制だから高性能とは限らない |
| ガバナンス | プロトコルの変更を管理できない | コンソーシアムが決定する |
| 手数料モデル | ネットワーク手数料に運用／統合コストが加わる | ネットワーク固有の手数料、ガバナンス、インフラコストがある。インフラ費用だけとは限らない |
| エラー対応 | 誤ったトランザクションを取り消せない | ガバナンス手順で対応できる |
取引相手の特定と顧客データの扱いは、活動内容と法域に応じて設計する必要があります。パブリックアドレスが法的な匿名性を自動的に保証するわけではなく、コンソーシアムへの参加が本人確認やデータ所在地の義務を自動的に満たすわけでもありません。適切なコンプライアンス／法務責任者と確認してください。
コンソーシアムを選んでも残るもの
ここは率直に考える必要があります。コンソーシアム化によって、ブロックチェーン本来の価値提案の多くが失われます。
| パブリックチェーンの価値 | コンソーシアムの場合 |
|---|---|
| 検閲耐性 | ✗ 参加者を管理する主体がいる |
| 許可不要の参加 | ✗ 承認が必要 |
| 仲裁者が不要 | △ コンソーシアム運営者が実質的な仲裁者になる |
| 改ざん耐性 | △ 参加者の過半数が結託すれば改ざんできる |
| 独立した検証 | ○ メンバー間では成立する |
| 機関間の照合作業コスト削減 | ○ 残る |
| 共有状態の単一バージョン | ○ 残る |
したがって、コンソーシアムチェーンの実質的な価値は、「機関が同じデータを参照し、照合作業をなくすこと」に絞られます。これは現実の価値ですが、「分散型」や「信頼不要」とは別の説明です。
この区別は審査で重要です。提案書に「分散型で、信頼なしに運用」と書くと、「では誰がメンバーシップを管理するのか」と聞かれます。その答えが「コンソーシアム事務局」なら、説明は成り立ちません。最初から価値を「機関間の照合作業コスト削減」と定義すれば、審査で説明できます。
プライバシー: 最も難しい課題
根本的な緊張関係
ブロックチェーンは「全員が同じ台帳を見て、自分で検証する」ことを前提とします。一方、金融取引では「取引相手ではない第三者に自分の取引を見られてはならない」という要件があります。
この2つは直接衝突します。検証するには閲覧が必要ですが、プライバシーを守るには閲覧できないようにしなければなりません。
解決方法はいくつかありますが、それぞれ異なる代償があります。
アプローチとトレードオフ
| アプローチ | 仕組み | 代償 |
|---|---|---|
| チャネル分離（Fabric） | 取引グループごとに別の台帳を使い、チャネルのメンバーだけがデータを保有する | チャネルごとの運用が複雑。チャネルをまたぐアトミックトランザクションは難しい |
| Private Data Collection（Fabric） | 台帳にはハッシュだけを記録し、実データは許可されたpeerだけが保有する | データ配布とライフサイクルの管理負荷 |
| ゼロ知識証明（ZKP） | 内容を明かさずに命題が真であると証明する | 計算コスト、回路設計の難しさ、検証可能性の審査 |
| オフチェーンストレージ | 機密データをチェーン外に置き、チェーン上にはハッシュ／ポインターだけを置く | オフチェーンストアの可用性と完全性が新たな依存先になる |
| 暗号化ストレージ | 暗号文をチェーンに記録する | 鍵管理がアクセス制御になる。鍵が漏れると過去の記録全体が露出する |
選び方
最も一般的な出発点はチャネル分離です。概念が単純でFabricに標準機能として備わり、「誰が何を見られるか」を明確にできるため、審査で説明しやすくなります。
限界はチャネル間の取引です。A-BチャネルとB-Cチャネルがある場合、AからCへ価値を移す取引をアトミックに処理するのは困難です。業務フローがこの形なら、設計を見直す必要があります。
追記専用／パブリック台帳上の暗号化記録は、履歴コピーに残る場合があります。後から再暗号化しても、それらのコピーは消えません。鍵が侵害されれば、その鍵で暗号化された記録が明らかになる可能性があります。許可型ネットワークのプライベートデータ消去は意味合いが異なるため、すべてのブロックチェーンでデータを消去できないと決めつけず、実際の保持方法と鍵のモデルを検証してください。
ZKPは強力ですが、審査を通すのが難しい技術です。「内容を明かさず真実を証明する」ことを審査担当者に説明する課題と、実装の正しさを保証する課題は別です。方式にtrusted setupが必要なら、その信頼性も問題になります。
消去権との衝突
プライバシー規制の削除要件は、ブロックチェーンの不変性と衝突します。
一般的な対応は「個人データをチェーンに置かない」ことです。識別子やハッシュだけをチェーン上に置き、削除できる個人データはチェーン外に保管します。ただし、元データを知っている人はハッシュを照合できるため（レインボーテーブル攻撃）、ソルトまたは鍵を削除し、実際の復元を不可能に近づける方法（crypto-shredding）も組み合わせます。
要確認
個人情報保護規制（韓国のPIPA、GDPRなど）の削除要件とブロックチェーンの不変性の法的解釈は、法域や事例によって異なります。この文書は法的助言ではありません。
ハッシュや暗号文が個人データに当たるか、crypto-shreddingが削除義務を満たすかは、法務／コンプライアンス部門に確認し、規制当局の解釈にも照らして判断する必要があります。この確認は技術設計より先に行います。
鍵管理: 金融サービスで最も重い検討事項
基礎編では「鍵は権限であり、失えば取り戻せない」と説明しました。これが金融サービスで特に重い課題となる理由を見ていきます。
相反する要件
| 要件 | 相反する要件 |
|---|---|
| トランザクション署名のため鍵をオンラインにする必要がある | 鍵を隔離する必要がある |
| 可用性: 署名が遅れるとサービスが中断する | 複数承認: 1者だけでは署名できない |
| バックアップは必須: 失うと復旧できない | バックアップは漏えい経路になる |
| 監査可能: 誰が何に署名したか | 鍵そのものは露出してはならない |
この矛盾は、金融サービスのブロックチェーン設計で最も難しい部分です。
利用できる仕組み
| 仕組み | 提供するもの | 制約 |
|---|---|---|
| HSM（CloudHSM、オンプレミスHSM） | ハードウェア保護された署名と、構成可能な鍵保護 | 選択したモジュールのアルゴリズム対応、鍵の抽出／ラッピング、バックアップポリシーを確認する |
| AWS KMS | 管理型鍵、IAM統合、CloudTrail監査 | ブロックチェーンが必要とする署名アルゴリズムに対応するか検証する |
| MPC（Multi-Party Computation） | 鍵を分散して保持し、シェアを組み合わせて署名する。完全な鍵はどこにも存在しない | 実装の複雑さ、ベンダー依存 |
| マルチシグ | プロトコルレベルでN-of-Mの署名を要求する | チェーン／コントラクトの対応が必要。トランザクションコストが高い |
| コールド／ホット分離 | 大部分をオフラインに置き、オンラインには少量だけ置く | 運用手順の負荷 |
曲線のサポート: レイヤーによって異なる
鍵管理設計で最もよく見落とされる前提です。「KMSを使う」という計画は、アルゴリズムの対応状況によって破綻します。重要なのは、Ethereumの2つのレイヤーが異なる曲線を使うことです。
| レイヤー | 曲線 | 用途 | AWS KMS／CloudHSM |
|---|---|---|---|
| 実行レイヤー（アカウント、トランザクション） | secp256k1 | トランザクション署名、EOAアカウント | ✅ 対応: KMS key spec ECC_SECG_P256K1、用途はSIGN_VERIFYに限定 |
| コンセンサスレイヤー（バリデーター） | BLS12-381 | ブロック提案とattestation署名 | ❌ 非対応 |
KMSのECC_SECG_P256K1とSIGN_VERIFYは、調整を加えたEthereum ECDSA署名フローをサポートできます。曲線が対応しているだけでは不十分です。digestの扱い、DER形式からチェーン形式への署名変換、low-S／recovery要件、実際のトランザクション形式を検証してください。Bitcoinの署名方式は異なります。secp256k1対応でも、すべてのSchnorr／Taprootフローに対応するとは限りません。実資金を使わずにテストしてください。
課題はコンセンサスレイヤーにあります。BLS12-381はKMSのkey specに含まれず、CloudHSMも対応していません。そのため、バリデーター署名鍵をKMS／HSMに置く設計は機能しません。
AWSが提案する代替策はNitro Enclavesです。Web3Signerのような署名サービスを隔離された実行環境内で動かし、鍵がEnclaveの外に出ないようにします。鍵生成（BLS12-381のEIP-2335形式keystore）にも別の方法が必要です。
設計上の含意: 前述のバリデーター鍵の矛盾（常時オンライン、隔離、二重署名の防止）に加え、もう1つ制約があります。「鍵をHSMで保護する」という標準的な解決策は適用できません。バリデーター運用を評価する場合、これはKMSベース設計から分岐する最初の判断点です。
要確認
上記の対応状況は調査時点のものです。BLS12-381のHSM対応は業界で長く議論されており、今後変わる可能性があります。Ethereum以外のプロトコル（例えばEd25519を使うチェーン）の曲線対応も別途確認してください。
設計前に、KMS key specの一覧を確認し、実際の署名が対象チェーンで有効になることをPoCで必ず検証してください。
バリデーター鍵に固有の問題
PoSバリデーターを運用すると、さらに問題が加わります。
- 署名機会が各slotで発生するため、署名鍵は常時オンラインである必要があります。
- 同一バリデーターの相反する署名はslashの対象になり得ます。調整されていない複数署名者／鍵コピーはリスクを生みます。重複した同一署名が必ずslashされるわけではありません。
- そのため、「高可用性のための冗長化」自体がリスクを作ります。
一般的なデプロイでは、履歴を保持するslashing protectionとfencingを伴う単一のアクティブ署名者、およびフェイルオーバーを使います。active-active／分散署名を行う場合は、共有slashing protectionが実証された設計が必要です。可用性向上だけを目的に、稼働中のバリデーター鍵をコピーして2台目の署名者を起動しないでください。
規制と審査の論点
金融サービスの審査で実際に出てくる質問:
| 論点 | 質問 | 用意する回答 |
|---|---|---|
| 必要性 | 通常のデータベースではなぜだめか | 「この課題に仲裁者がいてはならない理由」を1文で説明する |
| 参加者の管理 | 誰がどのようにメンバーシップを管理するか | ガバナンス構造と参加／離脱の手順 |
| データ所在地 | データはどこに複製されるか | ノードの所在地と地域ごとの管理策 |
| アクセス制御 | 誰が何を見られるか | チャネル／PDC設計、暗号化ポリシー |
| 削除要求 | 個人データ削除にどう対応するか | 個人データをチェーン外に保管する設計 |
| 鍵管理 | 鍵はどこにあり、誰がアクセスできるか | HSM／KMS／MPCの構成と職務分離 |
| 誤りの修正 | 誤ったトランザクションをどう戻すか | ガバナンス手順。技術ではなくプロセスで回答する |
| 可用性 | ノードまたはコンソーシアムの障害時にどうするか | 障害ドメイン、メンバーごとの独立運用 |
| 監査 | 監査人は何をどう確認するか | 監査アクセス方法、ログ |
| アップグレード | 誰がプロトコル変更を決めるか | コンソーシアムのガバナンス |
| 終了計画 | サービス終了時にデータをどうするか | 出口戦略 |
| ベンダー／サービスのロックイン | マネージドサービスが終了したらどうするか | 標準プロトコル、抽象化レイヤー（AMBの資料） |
特に準備不足になりやすい2項目
① 誤りの修正:「取り消せない」は審査上の弱点になる。
ブロックチェーンの強みとされる不変性は、金融業務では問題になることがあります。誤った取引、誤送金、システムエラーは発生し、金融機関にはそれらを修正する義務や手順があります。
答えは技術ではなくプロセスです。標準的な方法は「チェーンをロールバックする」ことではなく、「補償トランザクションを発行する」ことです。元の記録は残し、結果を修正する相殺トランザクションを追加します。会計の反対仕訳と同じ考え方です。審査に備え、手順と承認権限を文書化してください。
② 出口戦略: ほとんど準備されていない。
コンソーシアムが解散した、メンバーが離脱した、システムを停止した場合、データと義務はどうなるでしょうか。金融データには保存義務があるため、「チェーンを止めた」で終わりではありません。
用意するものは、台帳のエクスポート形式、保管責任者、離脱するメンバーのデータの扱い、記録へのアクセス方法です。これらをコンソーシアム契約に明記し、技術設計でも実現できるようにしてください。
既存の金融インフラとの統合
実際には、ブロックチェーンは既存システムを置き換えるのではなく、並行して動作します。統合箇所で実務上の問題が起こります。
| 統合時の問題 | 内容 |
|---|---|
| ファイナリティの不一致 | 既存システムはDBコミットを確定として扱う。チェーンには確認深度が必要 → 境界で状態を管理する |
| アトミック性がない | 既存DBトランザクションとチェーントランザクションを1つのアトミックな単位に結び付けられない |
| スループット差 | 既存システムの方がはるかに高速 → チェーンがボトルネックになる。キューイング／バッチ処理が必要 |
| 可逆性の違い | 既存システムはロールバックできるが、チェーンはできない → 障害シナリオの設計が非対称になる |
| 時刻同期 | ブロック時刻と既存システムの時刻を照合する |
「アトミック性がない」ことが最も実質的な問題です。DB書き込みとチェーントランザクションの送信の間に障害が起きると、不整合になります。分散トランザクションで両者を一体化できないため、上記の補償トランザクション手順と連携するSagaまたはoutboxパターンなどの結果整合性アプローチが必要です。
これはアーキテクチャ上の判断なので、設計の早い段階で扱ってください。後付けすると、本番でデータ整合性の問題が表面化します。
現実的な導入経路
| 段階 | 内容 |
|---|---|
| 1. 課題を検証する | ブロックチェーンが必要か確認する。通常のDB、署名付きログ、WORMなどの代替案と比較する |
| 2. 参加機関を確保する | 想定する参加者と役割を合意する。共有台帳、検証、ガバナンスの利点を単純な代替案と比較し、参加機関数に普遍的な最低数があると決めつけずに正当化する |
| 3. ガバナンスに合意する | 技術導入の前に、メンバーシップ、意思決定、紛争、離脱を決める |
| 4. プライバシーを設計する | チャネル／PDC構成を審査担当者と一緒に設計する |
| 5. 法務／コンプライアンス確認 | 削除要求、データ所在地、監査要件を確認する |
| 6. PoC | 技術検証に加えて、性能と運用負荷を測定する |
| 7. パイロット | 限定した範囲で実際の取引を行う |
| 8. 運用 | ノード運用、監視、証明書更新、ハードフォーク／アップグレード |
この表の要点は、技術の前に段階2と3があることです。技術検証に成功しても、参加機関や合意済みのガバナンスがなければ先に進めません。実際、多くの金融サービスのブロックチェーンプロジェクトがこの段階で止まりました。
まとめ
- まずブロックチェーンが適さないケースを除外する。「この課題に仲裁者がいてはならない理由」を1文で書けないなら、代替案と比較する。改ざん検出だけなら署名付きログやWORMで十分。
- 金融サービスがコンソーシアムを選ぶ決定的な理由は、KYC／AML義務とデータ主権です。スループットとガバナンスは副次的な利点です。
- コンソーシアムを選ぶと、ブロックチェーン本来の価値の多くが失われる。実質的に残るのは「機関間の照合作業コスト削減」であり、そのように価値を定義すれば審査で説明できます。
- 実際のデータモデルに応じてプライバシー対策を選ぶ。過去の暗号文コピーは鍵のローテーション後も残る可能性がある。保持、プライベートデータの消去、法的義務を明示的に確認する。
- 鍵管理では隔離と署名可用性のバランスを取る。PoSバリデーターで調整されていない署名者を使うと、slash対象となる相反メッセージを生成するおそれがある。同一署名の重複が自動的にslash対象になるわけではない。slashing履歴を維持したfencing付きフェイルオーバー、または実証済みの協調型分散署名を使う。
- 審査で準備不足になりやすいのは、誤りの修正（答えは技術ではなく補償トランザクション手順）と出口戦略（保存義務があるため「停止した」で終わらない）の2点。
- 既存インフラとの統合で中心となる課題は、アトミック性がないこと。Saga／outboxなどの結果整合性アプローチを早期に設計へ組み込む。
- 導入経路では、技術より先に参加機関の確保とガバナンスへの合意を行う。
参考資料
- Hyperledger Fabric: プライベートデータ
- Hyperledger Fabric: チャネル
- AWS CloudHSMドキュメント / AWS KMSドキュメント
- AWS KMS key specリファレンス:
ECC_SECG_P256K1を含む - AWS KMSでEthereumアカウントを安全に管理する（AWS Web3 Blog）
- Ethereumバリデーターを実行するAWS Nitro Enclaves（AWS Web3 Blog）: BLS12-381が未対応の場合の代替策
- Amazon Managed Blockchain: サービス終了リスクと緩和策
- ブロックチェーン基礎編: コンセンサスとファイナリティ
- EKS上のブロックチェーンノードの実行: 運用
- EKSセキュリティ / セキュリティ: 一般的なセキュリティ制御