Chainlink CCIP 2.0は、ブロックチェーン間のトークン移動やメッセージ送信に、利用者独自の検証レイヤーを追加できる相互運用プロトコルです。 標準の検証ネットワークだけでなく、発行体やDeFiプロジェクトが指定するCross-Chain Verifier（CCV）を組み合わせ、用途ごとにセキュリティやコンプライアンス要件を設定できます。 一方、独自CCVの運用責任は利用者側にも及ぶため、「検証者を増やせば自動的に安全になる」という仕組みではありません。
ChainlinkがCCIP 2.0を公開
Chainlinkは2026年9月28日、クロスチェーン通信基盤の新版「Cross-Chain Interoperability Protocol 2.0（CCIP 2.0）」を公開しました。CoinDeskは今回の更新について、企業やアプリケーションが独自のセキュリティチェックを追加し、資産移動に対する制御を強められる点を中心に報じています。
CCIPは、異なるブロックチェーン間でトークンや任意のメッセージを送るための基盤です。たとえばEthereum上の資産を別のチェーンで利用する場合、送信元で正しい処理が行われたことを確認し、その結果に基づいて送信先で資産を発行または解放します。
CCIP 2.0では、この確認を担う仕組みとしてCCVが導入されました。標準構成では、ChainlinkのCommittee Verifierがクロスチェーンメッセージを検証します。Chainlinkの発表によると、この標準検証レイヤーは独立した16のノード運営者で構成され、各取引について合意を形成します。
さらに、Lombardのようなトークン発行体、金融機関、DeFiアプリは、標準構成に自社運営または第三者運営のCCVを追加できます。追加されたCCVを含むすべての必須検証が完了するまで、送信先チェーンで処理は実行されません。
CCVで何が変わるのか
CCVは、送信元チェーンで発生したイベントを監視し、必要な確定数を待ったうえでメッセージの正当性を証明する仕組みです。証明結果はメッセージIDに結び付けられ、送信先のコントラクトが実行前に検証します。
重要なのは、追加CCVが標準のCommittee Verifierを置き換えるのではなく、原則として検証条件に加算される点です。送信者、トークンプール、受信コントラクト、通信経路が指定したCCV要件は統合され、必須とされた各CCVの有効な結果がそろわなければ処理は進みません。
Chainlinkの公式ドキュメントには、標準のCommitteeVerifierに加え、CircleのCCTPによる証明を利用するCCTPVerifier、Lombard向けの外部証明、組織独自のCustom CCVといったモデルが示されています。
これにより、銀行なら社内承認を含む検証、ステーブルコイン発行体なら送金制限や許可リスト、DeFiプロトコルなら独立したセキュリティ事業者による再検証といった構成が可能になります。Chainlinkは、AWSやGoogle Cloud向けのCCVスターターキットも用意すると説明しています。
Kelp DAO事件が示した単一検証者のリスク
今回の発表の背景として注目されているのが、2026年4月18日に発生したKelp DAOのrsETHブリッジ事件です。LayerZeroの公式報告によると、攻撃によって116,500 rsETH、当時の評価額で約2億9,200万ドル相当が失われました。
LayerZeroの調査では、攻撃者が関係者へのソーシャルエンジニアリングを起点にクラウド環境へ侵入し、RPCノードが返す情報を改ざんしました。その結果、LayerZero LabsのDVNが偽造されたクロスチェーンメッセージに対して有効な証明を生成したとされています。
被害を拡大させた重要な要因が、対象アプリケーションの「単一検証者」構成です。rsETHの経路ではLayerZero LabsのDVNだけを必須とする設定だったため、その証明が突破されると、偽のメッセージを拒否する独立した第二の検証者が存在しませんでした。
責任の所在については見解が対立しています。LayerZeroは複数DVNによる冗長化を推奨していたと説明する一方、CoinDeskによればKelp側は、LayerZero関係者が構成を確認しながら問題を指摘しなかったと主張しました。その後、Kelp DAOはrsETHのクロスチェーン基盤をChainlink CCIPへ移行する方針を示しています。
この事件から得られる実務的な教訓は、利用するブリッジのブランドだけでなく、実際に何者の証明が何件必要なのかを確認すべきという点です。
旧Risk Management Networkからの変更点
CCIP 2.0を評価する際は、新機能だけでなく従来構成からの変更も把握する必要があります。
過去のCCIPでは、通常のオラクルネットワークとは別にRisk Management Network（RMN）がクロスチェーン処理を監視する設計が強調されていました。しかし、Chainlinkの現行ドキュメントでは、RMNの自動的なオフチェーン検証機能は現在のCCIP展開で稼働していないと説明されています。オンチェーンのRMNコントラクトは、特定機能を緊急停止するための保護手段として残ります。
したがって、追加CCVを設定しない利用者は、標準のCommittee Verifierを中心とする構成に依存します。以前の説明にあった「通常ネットワークと独立RMNによる二重検証」が、そのまま維持されていると理解するのは正確ではありません。
CCIP 2.0では、独立検証を必要とする発行体やアプリケーションがCCVを明示的に追加する方向へ設計思想が移っています。柔軟性は高まりますが、どのCCVを必須にするか、障害時に取引を停止させるか、誰が運用責任を負うかを利用者自身が決める必要があります。
セキュリティ以外の新機能
CCIP 2.0は検証者の追加だけを目的とした更新ではありません。Chainlinkは、確認速度、コンプライアンス、トークンプールの動作を用途に合わせて構成できると説明しています。
まず、送信元チェーンで完全なファイナリティを待つ標準設定に加え、独自の確認ブロック数を指定するFaster-Than-Finality型の転送が用意されています。少額決済では速度を優先し、高額取引では完全確定を待つなど、用途別の設計が可能です。ただし、確定前の取引にはチェーン再編のリスクがあるため、金額制限や隔離処理を含む設計が欠かせません。
次に、Chainlink Automated Compliance Engine（ACE）との連携により、許可リスト、拒否リスト、取引上限、KYC・AML関連のポリシーをクロスチェーン転送へ組み込めます。これは、規制対象資産やRWAを複数チェーンへ展開する発行体にとって重要な機能です。
また、API、SDK、CLIも再設計され、標準転送と高速経路をより統一的に扱えるとされています。Aave、Maple、Re.xyzなどは、CCIP 2.0の高速転送機能を採用するプロジェクトとしてChainlinkの発表に掲載されています。
DeFi事業者が導入前に確認すべきこと
CCIP 2.0を採用するプロジェクトは、まず「標準構成で十分か」「独立CCVを必須にするか」を資産の性質に応じて判断する必要があります。高額なTVLを扱うプロトコルや発行体管理型トークンでは、異なる組織・クラウド・RPCを利用するCCVを組み合わせ、単一障害点を減らす設計が有力です。
ただし、Custom CCVの品質や可用性は運営者の責任です。Chainlinkの公式ドキュメントも、外部CCVのオンチェーンコントラクト、オフチェーンサービス、鍵管理、監視、仕様適合について、Chainlink Labsではなく運営者が責任を負うと明記しています。独自CCVが停止すれば、安全側に倒れる代わりに正規の送金まで滞留する可能性があります。
導入時には、少なくとも次の項目をテストすべきです。
- 各経路で必須となるCCVと合意条件
- CCV、RPC、クラウドの障害時に処理が停止するか
- チェーン再編時の隔離動作と確認深度
- トークンごとの発行上限、流出上限、レート制限
- 管理鍵の権限分離と設定変更時の承認手順
- 不正証明、証明遅延、送信先実行失敗を再現するテスト
- 監視アラートとインシデント時の一時停止手順
Kelp DAO事件が示したように、プロトコルが複数検証者に対応していても、実際の設定が単一検証者なら冗長性は得られません。公開資料の名称ではなく、オンチェーン設定と運用体制を確認することが重要です。
まとめ
Chainlink CCIP 2.0の中心的な変更は、標準のCommittee Verifierに独自または第三者のCCVを追加し、資産やアプリケーションごとに検証条件を設定できるようにしたことです。Kelp DAOのrsETH事件で顕在化した単一検証者のリスクに対し、独立した証明を重ねる選択肢を提供します。
一方、旧RMNの自動オフチェーン検証は現在稼働しておらず、追加CCVの設計・運用は利用者側の判断に委ねられます。CCIP 2.0はセキュリティを無条件に保証する製品ではなく、適切な検証者構成、レート制限、権限管理、障害テストを実装するための基盤と捉えるべきです。
DeFi利用者も、ブリッジを選ぶ際には対応チェーンや手数料だけでなく、必須検証者の数、運営主体の独立性、障害時の停止条件まで確認する必要があります。
