Chainlink CCIP 2.0は、ブロックチェーン間の送金やメッセージを検証する仕組みに、利用者独自のチェックを追加できる最新版です。 結論から言えば、標準検証を置き換えるのではなく、銀行・資産発行者・DeFiプロトコルが自ら選んだ検証を重ねる「多層防御」が中心です。 KelpDAOのrsETHブリッジ事件が示した単一検証系の危険を減らす選択肢になりますが、追加した検証器の運用責任までChainlinkが負うわけではありません。
ChainlinkがCCIP 2.0を公開、何が変わったのか
Chainlinkは2026年9月28日、Cross-Chain Interoperability Protocol（CCIP）2.0を公開しました。CCIPは、Ethereumなど異なるブロックチェーンの間でトークンや任意のメッセージを移動させるための相互運用基盤です。送信元チェーンで起きた事実を確認し、宛先チェーンで安全に実行できる形へつなぎます。
最大の変更点は、Cross-Chain Verifier（CCV）という差し替え・追加可能な検証レイヤーです。金融機関、トークン発行者、DeFiプロトコルは、自社運用のCCVや第三者が運用するCCVを標準のCommitteeVerifierに上乗せできます。両方の署名を必須にすれば、一方だけが誤った判定を出しても送金を成立させない構成が可能です。
Chainlinkの公式発表では、InfosysやNethermindなどが顧客向けCCV基盤を開発・運用する事業者として挙げられています。Lombardも、同社のクロスチェーントークンに独自の検証ロジックを組み込む事例として紹介されました。CCVは銀行専用機能ではなく、トークン発行者やDeFi開発者も利用対象です。
KelpDAO事件が突きつけた「1つの検証者」への依存
今回の発表を理解するうえで重要なのが、2026年4月18日に発生したKelpDAOのrsETHブリッジ事件です。LayerZeroの公式調査によると、攻撃で116,500 rsETH、当時約2億9,200万ドル相当が失われました。北朝鮮系の脅威アクターTraderTraitor（UNC4899）に帰属すると、複数の調査会社と研究者が判断しています。
重要なのは、KelpDAOのスマートコントラクトに単純なバグがあった、という事件ではない点です。公式報告では、攻撃者がLayerZero Labsの開発者をソーシャルエンジニアリングで侵害し、内部RPC環境へ移動。監視には正常な応答を返す一方、LayerZero LabsのDVNには改ざんしたRPC応答を返したと説明されています。外部RPCへのサービス妨害も重なり、侵害された内部ノードだけに依存する状況が作られました。
KelpDAO側の構成は、LayerZero LabsのDVNだけを使う1-of-1でした。独立した別のDVNが必須条件に入っていなかったため、唯一の検証経路が誤った証明を出すと、それを止める第二の確認者が存在しませんでした。CCIP 2.0は別製品であり、この事件への直接的な修正ではありません。しかし「複数の独立した検証を必須にする」という設計上の教訓は共通しています。
CCVは標準検証に追加する防御層
CCIP 2.0でも、すべてのメッセージは標準のCommitteeVerifierで検証されます。Chainlinkの公式発表によれば、この委員会は独立した16のノード運営者で構成され、クロスチェーン取引ごとに合意します。追加CCVは、この標準検証の代替ではなく、その上に重ねる防御層です。
たとえばLombardのような資産発行者は、自社トークンの移動に外部の証明を追加できます。CircleのCross-Chain Transfer Protocol（CCTP）を扱うCCTPVerifierも、USDC固有のアテステーションをCCIPの検証条件へ組み込むモデルです。送信者、トークンプール、受信者、レーン設定が要求するCCVは実行時に統合され、必要な検証結果がすべてそろうまで宛先チェーンで実行されません。
この方式の実務上の利点は、全利用者に同じリスク基準を押し付けず、資産ごと・取引ごとに条件を変えられることです。Chainlinkは例として、高額取引だけ追加承認を要求するポリシーを示しています。KYCやAML、取引上限、社内承認フローなどをCCVのポリシーに反映できるため、規制対象のトークン化資産にも応用しやすい設計です。
自社運用と第三者運用、CCV導入の選択肢
CCVは、オンチェーンの検証コントラクトと、イベント監視・署名・証明配信を担うオフチェーン基盤の両方で構成されます。自社で運用する場合、ChainlinkのCCV Starter Kitを既存のKubernetes環境へ導入できます。Amazon Web Services、Google Cloud、Azure、オンプレミスなどで運用でき、クラウド固有の構成は利用者側で管理します。
一方、インフラ運用を内製したくない組織は、InfosysやNethermindなど第三者のCCVを選べます。これは導入負担を下げますが、信頼が不要になるわけではありません。第三者の鍵管理、障害対応、アップグレード方針、監査範囲、再編成への対処を確認し、標準CommitteeVerifierとは独立した障害領域を持つかを評価する必要があります。
公式Starter Kitは、本番環境では独立した障害領域へ複数セルを配置する構成を案内しています。単に同じクラウド、同じRPC、同じ秘密管理へ複数プロセスを置くだけでは、共通障害を分散したことになりません。KelpDAO事件でもRPCが攻撃経路になったため、検証者の数だけでなく、情報源と運用基盤の独立性が重要です。
RMNの役割変更は見落とせない
CCIPの従来説明では、Risk Management Network（RMN）が主要ネットワークとは別にクロスチェーン活動を監視する層として知られていました。しかし現行の公式ドキュメントは、RMNの自動オフチェーン機能が現在のCCIPデプロイでは稼働していないと明記しています。将来、任意の検証層として提供される予定です。
一方、オンチェーンのRMNコントラクトは、チェーン単位またはネットワーク全体の一部機能に対する緊急保護策として残っています。したがって「従来のRMNが今も全送金を独立検証している」と理解するのは正確ではありません。
この変更により、追加設定をしない利用者は標準CommitteeVerifierを中心とする検証モデルを使います。CCVを必須にすれば独立チェックを追加できますが、その可用性や正確性は追加CCVの運営者にも依存します。CCIP 2.0を評価するときは、機能追加だけでなく、標準構成で何が有効なのかを現行ドキュメントで確認する必要があります。
DeFi運営者が導入前に確認すべきこと
UniswapのようなDEX、Aaveのようなレンディング、Lombardのような発行体がクロスチェーン資産を扱う場合、まず保護対象を明確にすべきです。任意メッセージ、ロック・ミント型トークン、外部アテステーション型資産では、失敗時の影響が異なります。CCVを追加すれば安全性が自動的に完成するわけではなく、停止条件と復旧手順も設計対象です。
実務では、少なくとも次を確認したいところです。
- 標準CommitteeVerifierに加え、どのCCVを必須にするのか
- CCV同士でRPC、クラウド、鍵管理、運営主体が十分に分離されているか
- チェーン再編成時の隔離や確定性の扱いが標準検証と同等か
- 追加CCVが停止した場合、取引が止まるのか、迂回できるのか
- 送信者、トークンプール、受信者の設定が矛盾していないか
- 監査ログ、緊急停止、アップグレード権限を誰が管理するか
Chainlinkの責任モデルでは、外部CCVの実装品質、保守、稼働率は運営者側の責任です。仕様不一致や停止は、取引の停滞、実行失敗、トークン供給量の不整合につながる可能性があります。「検証層を増やしたから安全」ではなく、独立性と運用能力を含めて審査することが重要です。
まとめ
CCIP 2.0の中心は、標準CommitteeVerifierを維持しながら、金融機関や資産発行者が独自または第三者のCCVを追加できる点です。Infosys、Nethermind、Lombard、Circle CCTPなど、企業運用や資産固有の検証を組み込む具体像も示されています。
KelpDAO事件は、1-of-1のDVN構成と侵害されたRPC情報源が組み合わさると、スマートコントラクトに欠陥がなくても巨額損失が起こり得ることを示しました。CCVはこの種の単一障害点を減らす有力な手段ですが、外部検証器の品質と可用性は利用者側の評価対象です。
導入を検討するDeFi事業者は、CCVの数だけで判断せず、RPC、クラウド、鍵、運営主体の独立性を確認すべきです。また、現行CCIPではRMNの自動オフチェーン機能が稼働していないため、最新の公式ドキュメントを前提に標準構成と追加防御を設計する必要があります。
