RIPPLE → SHARED INFRASTRUCTURE
Rippleが共同ガバナンスへ移るとは、
誰が、何を決めるようになることか。
共同化の正体は、XRPを配ることでも、XRPLを銀行へ渡すことでもない。金融サービスを動かす4つの決定権を、法的に拘束される共同意思決定へ移すことです。
Rippleが単独で握り得る「4本の鍵」を、別々の統治主体へ再配置する。
ルールブック、参加資格、リスク・緊急対応、本番変更。この4権限を、金融機関が選ぶ取締役会、独立リスク委員会、規制当局の監督、公開された変更手順へ移す。XRPLのプロトコル変更だけは別系統で、バリデータ投票に残ります。
RippleNetは、金融機関委員会による標準化とRulebookを公式に掲げる。XRPLのamendmentはバリデータ投票で決まる。
大規模な市場インフラ化には、標準化だけでなく、所有・取締役会・リスク権限・監督まで法的に分ける必要がある。
最も自然なのは「参加金融機関が持つ上部法人＋規制対象の運営会社＋外部XRPL」という二階建て構造。
今回確認した公式資料では、CLS型への正式な移行計画を確認できない。委員会の構成、議決権、拒否権、緊急権限も公開情報では判然としない。
このあと、①統治対象を3つに分ける → ②移す4権限を特定する → ③組織と手順へ落とす → ④何が出れば実現と判定できるか、の順に一本だけ掘ります。
FIG 00 · THE ANSWER MAP
共同化とは「4本の鍵」を同じ相手へ丸ごと渡すことではない。
取引手続、SLA、データ、責任分界
＋標準化委員会
資格、審査、制裁、競合排除の防止
＋取締役会への上訴
限度額、default、停止、再開、危機権限
＋規制監督
仕様、料金、移行日、互換性、ロールバック
＋参加者通知 / テスト
共同運営体が直接決めるのではない。各サーバーが信頼するバリデータの投票で、80%超の支持が2週間続くと有効化される。共同運営体は「その機能を自社サービスでいつ採用するか」を決める。
ANSWER FIRST
中心疑問への答えを、まず一文で固定する。
Ripple主導から共同ガバナンスへ移るとは、Rippleの会社経営を共同化することではなく、複数社が依存する金融サービスの重要決定権を、共同所有・共同選任・独立統制・規制監督を備えた制度へ移すことです。
ここで重要なのは、「相談相手が増える」では足りないことです。金融機関が資本、信用、顧客取引を載せるなら、ルール変更の前に意見を聞いてもらえるだけでは弱い。誰が議案を出せるのか、誰が投票するのか、何票で可決されるのか、緊急時に誰が止められるのか、決定へ不服を申し立てられるのか——それが定款、Rulebook、会員契約、監督プロトコルに書かれて初めて「権限の共同化」になります。
STOP MIXING SYSTEMS
最初に「3つのガバナンス」を分ける。
同じRipple/XRP周辺に見えても、決める対象と決める人が違います。ここを混ぜると「銀行がXRPLを支配する」「バリデータが金融機関の参加資格を決める」といった、別々の配線を一本に束ねた誤解が生まれます。
FIG 01 · THREE GOVERNANCE LANES
共同化するのは主に真ん中。上と下は別の統治系統。
資本配分、M&A、製品戦略、採用、営業、私有コード。
主な決定者：Rippleの株主・取締役・経営陣参加資格、SLA、リスク、障害、データ、料金、変更日。
ここがCLS型共同化の本体台帳の共通ルール、トランザクション処理、機能有効化。
主な決定者：バリデータ / 各サーバーのUNL会社、交通ルール、道路そのものを分ける話です。道路会社の経営、道路を使う事業者の共通ルール、道路規格の更新は同じ会議で決めません。
会社法上のcorporate governance、契約・会員制のscheme governance、分散ネットワークのprotocol governanceという異なる権限体系です。
共同化すべきなのはBの重要権限です。Cへ命令するのではなく、Cの変更をBが自社サービスへ採用するかを統制します。
WHAT EXISTS NOW
すでに共同の部分と、まだ見えない部分。
公開資料だけで確認できる現在地は、白黒ではありません。RippleNetの標準化は共同、XRPLのプロトコル変更もRipple単独ではない。一方、CLS型の中核である所有構造、取締役会、法的な議決権、独立リスク統制、規制当局との正式な監督枠組みは、RippleNetについて公開確認できません。
RippleNet CommitteeとRulebook
Rippleは、RippleNetを世界の金融機関から成る委員会が民主的に統治し、クロスボーダー取引の標準化を共同で維持すると説明しています。全会員が共通Rulebook、機能標準、SLAへ従うとも明記しています。Rulebookは2017年、RippleNet Advisory Boardとの協働で追加されたと説明されました。[1][2]
XRPLのバリデータ投票
各XRPLサーバーは、どのバリデータを信頼するかを示すUNLを持ち、運営者がその内容を制御します。amendmentは信頼されたバリデータの80%超の支持が2週間続くと有効化されます。[3][4]
委員会の強制力と権利設計
現在の公開ページからは、委員名、選任方法、1社1票か、議決閾値、Rippleの拒否権、会員の提案権、緊急権限、独立した法人・取締役会・監督主体の有無までは読み取れません。これは「存在しない」と断定する材料ではなく、外部から制度的共同性を検証できないという意味です。
つまり、現状の公開像は「みんなで標準を整える」までは見える。
「Ripple一社では重要ルールを変えられない」まで進んでいるかは見えない。
THE FOUR CONTROL RIGHTS
何の権限を共同化するのか。
共同ガバナンスを「関係者と話し合うこと」で止めず、権限の単位へ切ります。必要なのは次の4つです。どれか一つだけ共同でも、他がRippleの裁量なら制度全体はまだ単独主導に近いままです。
RULEBOOK / STANDARDS
ルールブックと標準を変える権限
直感：ゲームの途中で、運営だけが勝手に勝利条件を変えられないようにする。
正確：メッセージ標準、SLA、責任分界、データ要件、手数料、サービス停止条件などの拘束ルールについて、提案権・審議権・議決権・通知義務を定める。
今回の重要点：RippleNet Committeeが現在担うと公表されているのは、主にこの層です。成熟後は「助言」ではなく、Rulebook上の正式な変更権へ接続されている必要があります。
ACCESS / DISCIPLINE
誰を入れ、止め、戻すかを決める権限
直感：競合だから締め出す、売上が大きいから例外扱いする、を防ぐ。
正確：資本、規制、技術、AML、運用能力の参加基準、定期審査、違反時の制裁、停止、退出、上訴をRulebook化する。
今回の重要点：営業判断と市場アクセス判断を分離しないと、Rippleは「インフラ運営者」であると同時に「自社製品の販売者」でもある利益相反を抱えます。
RISK / DEFAULT / EMERGENCY
損失と危機を処理する権限
直感：平時の多数決より、事故の瞬間に誰がブレーキを踏めるかが本当のガバナンス。
正確：リスク許容度、限度額、default手順、流動性不足、インシデント、緊急停止、再開条件、損失配分、危機時の一時権限を定める。
今回の重要点：PFMIは、取締役会がリスク枠組みを定め、危機・緊急時の意思決定責任を明確にし、リスク機能へ独立性と取締役会へのアクセスを与えるよう求めます。[10]
CHANGE / PRODUCTION ADOPTION
技術を本番へ入れる権限
直感：コードを書いた人と、全員の本番を切り替える人を分ける。
正確：Rippleや他ベンダーが変更案を実装しても、影響評価、相互運用テスト、移行日、後方互換性、ロールバック、重大変更の承認を別手順に置く。
今回の重要点：XRPL amendmentが有効になったことと、共同サービスがその機能を本番採用することは別です。プロトコル投票とサービス変更管理を二重化することで、オープン台帳と規制業務を接続できます。
WHO SITS WHERE
誰が、どの席へ座るのか。
「銀行・PB・MM・カストディアン・規制当局で共同運営」と一列に並べるだけでは、責任が消えます。利用者、所有者、取締役、執行者、監督者は役割が違う。全員が全案件へ一票を投じる設計でもありません。
- 01Ripple
- 創設者・技術提供者・運用受託者として残る。議案を作り、コードを書き、日常運用を担える。ただし、重大Rulebook変更、競合の排除、緊急権限の恒久化を単独では決められない位置へ移るのが共同化です。Rippleを追い出すのではなく、不可欠な提供者と最終決定者を分ける。
- 02参加金融機関
- 所有と取締役選任を通じて、制度の方向を決める。CLSでは金融機関株主が上部法人を相互所有し、株式へ投資するSettlement Memberと非株主Memberの両方があります。利用資格と所有権は一致させなくてよい、という実例です。[5][6][7]
- 03PB・MM・カストディアン等
- 専門委員会で実務とリスクの知識を入れる。全社を株主にする必要はありません。流動性、テクノロジー、運用、ユーザーの各委員会で提案・レビュー・実装責任を担い、利益相反のある案件では議決から外す。
- 04独立取締役 / 統制機能
- 会員各社の利益とシステム全体の安全を分ける。大手会員だけで取締役会を埋めると、自社のコスト削減が全体の安全より優先され得ます。PFMIは非執行・独立取締役、明確な委員会責任、利益相反管理を重視します。[10]
- 05規制当局 / 中央銀行
- 日常の商品設計者ではなく、外部の監督者。CLSではFRBが主たる監督者となり、決済通貨の中央銀行と協調監督します。共同ガバナンスは民間だけの仲良し会議ではなく、公的な安全目的と接続されます。[5][8]
- 06XRPLバリデータ / UNL公開者
- 外部プロトコルのルールを担う。共同運営体の子会社に取り込むのではなく、別の牽制軸として残す。運営体がバリデータを持つ場合でも、トークン保有量や会員株式がamendment票へ自動変換されるわけではありません。
ORGANIZATIONAL FORM
どんな組織にするのが最も自然か。
ここからはRippleの公表計画ではなく、公開事実とFMIの先例から組み立てるZVYX仮説です。結論は、「二階建ての法人＋外部プロトコル」。一つの委員会へ全部を詰め込むより、所有、監督、執行、プロトコルを分離した方が責任線を引けます。
FIG 02 · TWO-STOREY GOVERNANCE
参加者が上を持ち、運営会社が下を動かし、XRPLは外に残る。
届出 / 検査 / リスク対話 / 必要なno-objection / 危機時連携
参加金融機関・株主
取締役を選任し、定款上の重要事項へ議決。非株主会員にもRulebook上の相談・上訴権を与える。
共同保有法人 / コンソーシアム
所有、中長期戦略、取締役選任、Rippleを含む株主間の権限バランス。
独立運営会社
会員契約、Rulebook、日常運用、アクセス審査、インシデント対応、ベンダー管理。重要インフラ化するなら規制対象化も候補。
Ripple・他ベンダー
コード、統合、運用サービスを契約で提供。重大変更は運営会社の手順を通す。
XRPL / validators / UNL
amendmentとコンセンサスは外部で決まる。運営会社は対応バージョン、採用日、リスク制御を決める。
DECISION PROCEDURE
どんな手順で共同決定するのか。
権限を誰が持つかだけでなく、「平時」と「緊急時」を分ける必要があります。全変更を長い合議にすると止まり、全緊急判断を運営者へ渡すと単独支配へ戻る。答えは、通常手順と期限付き例外の二本立てです。
FIG 03 · NORMAL / EMERGENCY PATH
通常は合議、緊急時は一時権限。後から必ず戻す。
- 01提案Ripple・会員・委員会
- 02重要度分類通常 / 重大 / reserved matter
- 03影響評価法務・リスク・技術・競争
- 04会員協議文案公開・コメント期間
- 05委員会勧告反対意見も記録
- 06正式議決取締役会 / 特別多数
- 07監督・テスト届出、互換性、移行判定
- 08通知・実施発効日、ロールバック、事後評価
議決ルールは「全部多数決」ではなく、案件の重さで変える。
経営陣へ委任。取締役会が定めた予算・リスク許容度・Rulebookの範囲内で執行する。
委員会の勧告を受け、取締役会の通常多数。会員への事前通知と実装猶予を必須にする。
参加資格の根本変更、損失配分、基幹料金、事業売却、運営者交代などは特別多数または株主承認。Ripple一社にも最大会員一社にも単独拒否権を持たせない。
当事者は審議資料を提出できても議決から外れる。独立取締役・監査が理由と手続を記録する。
THE PLAUSIBLE TRANSITION
現実に移るなら、どの順番か。
いきなりRippleが全権限を手放す必要はありません。むしろ、守るべき利用とリスクがない段階で巨大な共同法人を作ると、会議だけが先に上場します。自然なのは、すでにあるRulebook共同性から、権利を一段ずつ強くする順番です。
標準化を共同で作る
RippleNet Committee、共通Rulebook、機能標準、SLA。
公開資料で確認できる手続上の権利を固定する
提案権、コメント期間、議決閾値、変更通知、上訴、利益相反ルール。
公開情報では詳細不明法人と所有を分ける
参加者保有法人、選任された取締役会、独立運営会社、Rippleとの技術契約。
ZVYXの制度化仮説公的監督へ接続する
重要性に応じた認可・監督、複数当局の協調、危機対応、情報開示。
FMI化する場合の条件最も合理的な将来像は、Rippleが消えることではなく、Rippleの能力を残したまま、Rippleの裁量だけを薄くすることです。
技術の継続性を考えれば、Rippleは長期にわたり重要な提案者・実装者・運用者であり得ます。ただし、その重要性を理由に最終決定権まで永久固定すると、競合金融機関は自社資本を一社の戦略へ預けることになります。共同化は、Rippleの価値を捨てる仕組みではなく、Rippleへの依存を他社が承認可能な形に変える仕組みです。
PROOF / FALSIFICATION
何が出れば「本当に共同化した」と判定できるか。
「member governed」という言葉だけでは判定しません。権限は、広報文ではなく法人文書と変更ログに残ります。今後見るべき証拠は、次の順です。
共同化を強く確認する証拠
- 別法人の設立・所有者金融機関の株主参加、持分上限、Rippleの保有比率
- 定款・取締役選任誰が席を選び、独立取締役を何人置くか
- 公開Rulebookと変更手順提案権、議決閾値、コメント期間、発効通知
- リスク・緊急権限停止、再開、default、損失、CEOの一時権限と期限
- 監督枠組み認可主体、協調監督、定期開示、危機時の連絡線
- XRPLとの責任分界プロトコル変更とサービス採用を誰が決めるか
名目共同にとどまる証拠
- 委員会が助言のみRippleが理由なく勧告を拒否できる
- 契約・料金を単独変更実質的なコメント権や退出猶予がない
- 参加・停止が営業裁量公開基準、上訴、利益相反手続がない
- 緊急権限が無期限事後承認、期限、監督当局への報告がない
- 法人・取締役会が同じRippleの会社判断と市場インフラ判断が分離されない
- “分散化”をUNL数だけで説明サービス側の法的決定権を示さない
RippleNetには、すでに「共同標準」の骨格がある。
しかし、CLS型の「共同権力」まで移った証拠は足りない。
したがって、現時点で最も合理的な表現はこうです。「Ripple主導から共同ガバナンスへ移る可能性」は、ゼロからの空想ではない。すでに存在するCommittee / Rulebookを、所有・取締役会・リスク権限・監督へ拡張する制度化シナリオである。ただし、その正式な移行計画は未確認。
FINAL ANSWER
共同ガバナンスとは、
Rippleの影響力を消すことではない。
単独決定できる範囲を、法的に狭くすること。
金融機関が共同で持つ法人が取締役を選び、独立した運営会社がRulebookに従ってサービスを動かし、リスク委員会が損失と緊急権限を管理し、規制当局が外から監督する。Rippleは創設者・技術提供者・運用者として残るが、重要事項は公開された手続を通さなければ変えられない。
そしてXRPLは、その組織の社内システムにはならない。プロトコル変更はバリデータ側に残り、共同運営体はサービスとしての採用を決める。この二重構造こそ、オープンな台帳と、説明責任を求める金融インフラを同時に成立させる最も自然な形です。
FAQ
ここまでで残りやすい4つの疑問。
共同ガバナンスになるとRippleは運営から外れる？
外れる必要はありません。最も自然なのは、創設者・技術提供者・運用受託者として残りながら、重大Rulebook変更や参加者排除を単独では決められない位置へ移る形です。
金融機関がXRPLプロトコルを共同で支配する？
それは別系統です。XRPLのamendmentは信頼されたバリデータの投票で決まり、80%超の支持が2週間必要です。共同運営体は、その機能を自社サービスへいつ採用するかを決めます。
RippleNet Committeeは、もう共同ガバナンスでは？
標準化とRulebookの層では、すでに共同です。ただし、所有、取締役選任、正式な議決閾値、緊急権限、独立監督まで含む制度的共同性は、公開資料から確認できません。
XRPを多く持つとガバナンス権が増える？
XRPLのamendmentはトークン保有量による投票ではありません。サービス側の権利も、XRP残高ではなく、株式、会員資格、定款、Rulebook、契約によって与えられるべきです。
PRIMARY SOURCES
一次資料・確認日 2026-07-15
- Ripple — RippleNet Committeemember-governed、金融機関委員会、標準化、Rulebook、SLA。
- Ripple — Ripple’s Product Suite is Growing2017年、Advisory Boardとの協働でRulebookを追加した説明。
- XRPL.org — Unique Node List各サーバーのUNLと、信頼するバリデータの選択。
- XRPL.org — Amendments80%超の支持を2週間維持するamendmentプロセス。
- CLS — Corporate governance上部法人、CLS Bank、FRB規制、協調監督。
- CLS — Shareholders世界の主要金融機関による相互所有。
- CLS — Settlement membership株主会員、非株主会員、中央銀行会員、第三者利用。
- CLS — Oversight CommitteeNY連銀が組織・運営する中央銀行の協調監督。
- CLS Bank International Rules — 21 July 2025取締役会のRules変更権、60日レビュー、15日前通知、緊急例外。
- CPMI-IOSCO — Principles for Financial Market Infrastructures明確な責任線、取締役会、独立性、リスク・危機権限、利害関係者。
判定方法：公式ページまたは公式文書で直接確認できた内容を「確認済み」、複数の確認事実から制度上自然に導けるものを「合理的推論」、具体的な将来組織案を「ZVYX仮説」、資料にない権利・予定・数値を「未確認」としました。公開されていないことを、存在しないと断定していません。