「セキュリティ」タグの記事が6件件あります

GoogleのAgent Payments Protocol (AP2) は、AIエージェントがユーザーに代わって開始する安全で信頼性の高い取引を可能にするために設計された、新しく発表されたオープン標準です。60以上の決済およびテクノロジー組織（主要な決済ネットワーク、銀行、フィンテック企業、Web3企業を含む）との協力により開発されたAP2は、「エージェント型」決済、すなわち自律型エージェント（AIアシスタントやLLMベースのエージェントなど）がユーザーのために実行できる購入や金融取引のための共通言語を確立します。AP2の創設は、根本的な変化によって推進されています。従来、オンライン決済システムは人間が直接「購入」をクリックすることを前提としていましたが、ユーザーの指示に基づいて行動するAIエージェントの台頭がこの前提を打ち破りました。AP2は、AI主導の商取引における承認、信頼性、説明責任といった課題に対処しつつ、既存の決済インフラとの互換性を維持します。本レポートでは、AP2の技術アーキテクチャ、目的とユースケース、AIエージェントおよび決済プロバイダーとの統合、セキュリティとコンプライアンスの考慮事項、既存プロトコルとの比較、Web3/分散型システムへの影響、および業界での採用/ロードマップについて考察します。

技術アーキテクチャ: AP2の仕組み​

AP2の核となるのは、検証可能なデジタルクレデンシャル (VDC) に基づいて構築された暗号学的に安全な取引フレームワークです。VDCは、ユーザーが承認した内容のデジタルな「契約」として機能する、改ざん防止された署名付きデータオブジェクトです。AP2の用語では、これらの契約はマンダートと呼ばれ、各取引の監査可能な証拠の連鎖を形成します。AP2アーキテクチャには、主に3種類のマンダートがあります。

• 意図マンダート (Intent Mandate): 購入に関するユーザーの初期指示または条件を捕捉します。特に*「人間が不在の」シナリオ（ユーザーがオンラインでない状態でエージェントが後で行動する場合）に適用されます。これは、ユーザーがエージェントに与える権限の範囲*を定義します。例えば、「コンサートチケットが200ドル以下になったら、2枚まで購入する」といったものです。このマンダートは、ユーザーによって事前に暗号学的に署名され、特定の制限内での同意の検証可能な証拠として機能します。
• カートマンダート (Cart Mandate): ユーザーが承認した最終的な取引詳細を表し、*「人間が同席する」*シナリオやチェックアウト時に使用されます。これには、正確なアイテムやサービス、その価格、および購入のその他の詳細が含まれます。エージェントが取引を完了する準備ができたとき（例えば、ショッピングカートに商品を詰めた後）、まずマーチャントがカートの内容を暗号学的に署名し（注文詳細と価格を保証）、次にユーザーが（デバイスまたはエージェントインターフェースを介して）署名してカートマンダートを作成します。これにより、表示されたものが支払うものであることが保証され、ユーザーに提示された通りの最終注文が確定されます。
• 決済マンダート (Payment Mandate): AIエージェントが取引に関与していることを決済ネットワーク（カードネットワークや銀行など）に通知するために送信される別のクレデンシャルです。決済マンダートには、承認時にユーザーが同席していたかどうかなどのメタデータが含まれ、リスク管理システムのためのフラグとして機能します。このマンダートは、ユーザーの意図の暗号学的に検証可能な証拠を取得銀行および発行銀行に提供することで、コンテキストを評価し（例えば、エージェントが開始した購入を一般的な不正行為と区別する）、それに応じてコンプライアンスや責任を管理するのに役立ちます。

すべてのマンダートは、関連当事者（ユーザー、マーチャントなど）の鍵によって署名された検証可能なクレデンシャルとして実装され、すべてのエージェント主導の取引に対して否認防止可能な監査証跡を生成します。実際には、AP2は機密情報を保護するためにロールベースのアーキテクチャを使用します。例えば、エージェントは生の決済詳細を一切見ることなく意図マンダートを処理することができ、決済詳細は必要なときにのみ制御された方法で開示され、プライバシーが保護されます。ユーザーの意図 → マーチャントのコミットメント → 決済承認という暗号学的連鎖は、取引がユーザーの真の指示を反映しており、エージェントとマーチャントの両方がその指示を遵守したという、すべての当事者間の信頼を確立します。

取引フロー: AP2がエンドツーエンドでどのように機能するかを説明するために、人間が関与する簡単な購入シナリオを考えてみましょう。

1. ユーザーリクエスト: ユーザーはAIエージェントに特定のアイテムまたはサービスの購入を依頼します（例：「この靴を私のサイズで注文して」）。
2. カートの構築: エージェントはマーチャントのシステムと通信し（標準APIまたはエージェント間の相互作用を使用）、指定されたアイテムのショッピングカートを特定の価格で組み立てます。
3. マーチャントの保証: カートをユーザーに提示する前に、マーチャント側がカートの詳細（アイテム、数量、価格など）を暗号学的に署名します。このステップにより、正確な条件を保証するマーチャント署名付きオファーが作成されます（隠れた変更や価格操作を防ぎます）。
4. ユーザーの承認: エージェントはユーザーに確定されたカートを表示します。ユーザーは購入を確認し、この承認によりユーザー側から2つの暗号学的署名がトリガーされます。1つはカートマンダート（マーチャントのカートをそのまま受け入れるため）に対するもので、もう1つは決済マンダート（選択した決済プロバイダーを通じて決済を承認するため）に対するものです。これらの署名済みマンダートは、それぞれマーチャントと決済ネットワークに共有されます。
5. 実行: カートマンダートと決済マンダートを携えて、マーチャントと決済プロバイダーは取引を安全に実行します。例えば、マーチャントはユーザー承認の証拠とともに決済リクエストを決済ネットワーク（カードネットワーク、銀行など）に送信し、決済ネットワークは決済マンダートを検証できます。その結果、ユーザーの意図と最終的な決済を結びつける暗号学的監査証跡を伴う購入取引が完了します。

このフローは、AP2がAI主導の購入の各ステップにどのように信頼を組み込むかを示しています。マーチャントは、ユーザーがどの価格で何を購入することに同意したかについて暗号学的証拠を持ち、発行者/銀行は、AIエージェントがプロセスを促進したにもかかわらず、ユーザーがその決済を承認したという証拠を持っています。紛争やエラーが発生した場合、署名済みマンダートは明確な証拠として機能し、説明責任の判断に役立ちます（例えば、エージェントが指示から逸脱した場合や、請求がユーザーが承認したものでなかった場合など）。本質的に、AP2のアーキテクチャは、エージェントの行動への信頼ではなく、検証可能なユーザーの意図が取引の基礎であることを保証し、曖昧さを大幅に軽減します。

AP2の目的とユースケース​

なぜAP2が必要なのか: AP2の主な目的は、AIエージェントがユーザーに代わって資金を使うことができるようになったときに生じる、新たな信頼とセキュリティの問題を解決することです。Googleとそのパートナーは、自律型エージェントが関与する場合に、今日の決済インフラでは適切に答えられないいくつかの重要な問題を特定しました。

• 承認: ユーザーが実際にエージェントに特定の購入を行う許可を与えたことをどのように証明するか？（言い換えれば、エージェントがユーザーの十分な同意なしに物を購入していないことを確認する。）
• 信頼性: マーチャントは、エージェントの購入リクエストが本物であり、間違いやAIの幻覚ではなく、ユーザーの真の意図を反映していることをどのように知ることができるか？
• 説明責任: エージェントを介して不正な取引や誤った取引が発生した場合、誰が責任を負うのか？ユーザー、マーチャント、決済プロバイダー、それともAIエージェントの作成者か？

解決策がなければ、これらの不確実性はエージェント主導の商取引に「信頼の危機」を生み出します。AP2の使命は、安全なエージェント取引のための統一プロトコルを確立することで、その解決策を提供することです。標準化されたマンダートと意図の証明を導入することで、AP2は各企業が独自の場当たり的なエージェント決済方法を考案する断片化されたエコシステムを防ぎます。代わりに、準拠するAIエージェントは、共通のルールと検証の下で、準拠するマーチャント/決済プロバイダーと対話できます。この一貫性は、ユーザーとマーチャントの混乱を避けるだけでなく、金融機関が独自のパッチワークのアプローチに対処するのではなく、エージェントが開始する決済のリスクを管理するための明確な方法を提供します。つまり、AP2の目的は、「エージェント経済」が決済エコシステムを破壊することなく成長できるようにする基盤となる信頼レイヤーとなることです。

意図されたユースケース: 上記の問題を解決することで、AP2は、人間が手動でクリックして購入するだけでは不可能な、新しい商取引体験とユースケースへの扉を開きます。AP2がサポートするエージェント対応の商取引の例をいくつか示します。

• よりスマートなショッピング: 顧客はエージェントに「この冬のジャケットを緑色で欲しい。現在の価格より20%までなら喜んで支払う」と指示できます。これらの条件をエンコードした意図マンダートを携えて、エージェントは小売業者のウェブサイトやデータベースを継続的に監視します。ジャケットが緑色で（かつ価格しきい値内で）利用可能になった瞬間、エージェントは安全な署名付き取引で自動的に購入を実行し、そうでなければ見逃されていたであろう販売機会を捉えます。ユーザーの最初の要求から自動チェックアウトまでのすべてのやり取りは、エージェントが承認されたものだけを購入することを保証するAP2マンダートによって管理されます。
• パーソナライズされたオファー: ユーザーはエージェントに、今後の旅行のために特定のマーチャントから特定の製品（例えば、新しい自転車）を探していると伝えます。エージェントは、この関心（意図マンダートの範囲内で）を、旅行日などの関連するコンテキストとともに、マーチャント自身のAIエージェントと共有できます。ユーザーの意図とコンテキストを知っているマーチャントエージェントは、カスタムバンドルや割引で応答できます。例えば、「自転車+ヘルメット+トラベルラックを15%オフで、今後48時間利用可能」といったものです。AP2を使用することで、ユーザーのエージェントはこのカスタマイズされたオファーを安全に受け入れて完了させることができ、単純な問い合わせをマーチャントにとってより価値のある販売に変えることができます。
• 協調タスク: 複雑なタスク（例えば、週末旅行）を計画しているユーザーは、それを完全に委任します。「これらの日付で、合計予算700ドルでフライトとホテルを予約して。」エージェントは、複数のサービスプロバイダーのエージェント（航空会社、ホテル、旅行プラットフォーム）と対話し、予算に合う組み合わせを見つけます。適切なフライトとホテルのパッケージが特定されると、エージェントはAP2を使用して複数の予約を一括で実行します。各予約は暗号学的に署名されます（例えば、航空会社とホテルに別々のカートマンダートを発行し、両方ともユーザーの意図マンダートの下で承認されます）。AP2は、この協調取引のすべての部分が承認されたとおりに行われることを保証し、途中で一部が失敗するリスクなしにチケットと予約が同時に行われるようにすることも可能です。

これらのシナリオは、AP2が意図するユースケースのほんの一部を示しています。より広範には、AP2の柔軟な設計は、従来のeコマースフローとまったく新しい商取引モデルの両方をサポートします。例えば、AP2はサブスクリプションのようなサービス（エージェントが条件が満たされたときに購入することで必需品を補充し続ける）、イベント駆動型購入（トリガーイベントが発生した瞬間にチケットやアイテムを購入する）、グループエージェント交渉（複数のユーザーのエージェントがマンダートをプールしてグループ取引を交渉する）、その他多くの新たなパターンを促進できます。すべての場合において、共通のテーマは、AP2が信頼フレームワーク（明確なユーザー承認と暗号学的監査可能性）を提供し、これらのエージェント主導の取引が安全に行われることを可能にすることです。信頼と検証レイヤーを処理することで、AP2は開発者や企業が決済セキュリティをゼロから再発明することなく、新しいAIコマース体験の革新に集中できるようにします。

エージェント、LLM、および決済プロバイダーとの統合​

AP2は、AIエージェントフレームワークと既存の決済システムの両方とシームレスに統合するように明示的に設計されており、両者の間の橋渡し役を果たします。GoogleはAP2をAgent2Agent (A2A) プロトコルおよびModel Context Protocol (MCP) 標準の拡張機能として位置付けています。言い換えれば、A2Aがエージェントがタスクを通信するための汎用言語を提供し、MCPがAIモデルがコンテキスト/ツールを組み込む方法を標準化するならば、AP2は商取引のためのトランザクションレイヤーをその上に加えます。これらのプロトコルは補完的です。A2Aはエージェント間の通信（例えば、ショッピングエージェントがマーチャントのエージェントと会話できるようにする）を処理し、AP2はそれらの相互作用内でのエージェントからマーチャントへの決済承認を処理します。AP2はオープンで非独占的であるため、フレームワークに依存しないことを意図しています。開発者はGoogle独自のAgent Development Kit (ADK) または任意のAIエージェントライブラリで使用でき、同様にLLMを含むさまざまなAIモデルと連携できます。例えば、LLMベースのエージェントは、自由形式のテキストだけでなく、必要なマンダートペイロードを（AP2仕様に沿って）生成および交換することでAP2を使用できます。構造化されたプロトコルを強制することで、AP2はAIエージェントのハイレベルな意図（LLMの推論から来る可能性のあるもの）を具体的で安全な取引に変換するのに役立ちます。

決済側では、AP2は従来の決済プロバイダーや標準と連携して構築されており、既存システムを置き換えるものではありません。このプロトコルは決済方法に依存しないため、クレジットカード/デビットカードネットワークから銀行振込、デジタルウォレットまで、さまざまな決済レールを資金移動の基盤となる方法としてサポートできます。最初のバージョンでは、AP2はオンライン商取引で最も一般的なカード決済との互換性を重視しています。AP2の決済マンダートは、既存のカード処理フローに組み込まれるように設計されています。AIエージェントが関与しているかどうか、およびユーザーが同席していたかどうかに関する追加データを決済ネットワーク（Visa、Mastercard、Amexなど）および発行銀行に提供することで、既存の不正検出および承認チェックを補完します。本質的に、AP2は決済自体を処理するのではなく、ユーザーの意図の暗号学的証拠で決済リクエストを強化します。これにより、決済プロバイダーはエージェントが開始した取引を適切な注意または速度で処理できます（例えば、発行者は、ユーザーが事前に承認したことを証明する有効なAP2マンダートがある場合、通常とは異なる購入を承認する可能性があります）。特に、Googleとパートナーは、AP2を「プッシュ」決済方法（インドのUPIやブラジルのPIXシステムのようなリアルタイム銀行振込など）やその他の新たなデジタル決済タイプもサポートするように進化させることを計画しています。これは、AP2の統合がカードを超えて拡大し、世界中の現代の決済トレンドと連携することを示しています。

マーチャントや決済処理業者にとって、AP2の統合は、追加のプロトコルメッセージ（マンダート）のサポートと署名の検証を意味します。多くの大規模な決済プラットフォームはすでにAP2の形成に関与しているため、それらがAP2のサポートを構築することが期待できます。例えば、Adyen、Worldpay、Paypal、Stripe（ブログでは明示的に名前が挙げられていませんが、関心がある可能性が高い）などの企業は、AP2をチェックアウトAPIやSDKに組み込み、エージェントが標準化された方法で決済を開始できるようにする可能性があります。AP2はGitHubで公開されたオープン仕様であり、リファレンス実装も提供されているため、決済プロバイダーやテクノロジープラットフォームはすぐに試用を開始できます。Googleはまた、サードパーティのエージェントをリストできるAIエージェントマーケットプレイスについても言及しており、これらのエージェントは取引機能のためにAP2をサポートすることが期待されています。実際には、AIセールスアシスタントや調達エージェントを構築する企業は、このマーケットプレイスにそれをリストすることができ、AP2のおかげで、そのエージェントは購入や注文を確実に実行できます。

最後に、AP2の統合は幅広い業界の支持から恩恵を受けています。主要な金融機関やテクノロジー企業と共同でプロトコルを開発することで、GoogleはAP2が既存の業界ルールとコンプライアンス要件に適合することを保証しました。決済ネットワーク（Mastercard、UnionPayなど）、発行者（American Expressなど）、フィンテック企業（Revolut、Paypalなど）、eコマースプレーヤー（Etsyなど）、さらにはID/セキュリティプロバイダー（Okta、Cloudflareなど）との協力は、AP2が最小限の摩擦で現実世界のシステムに組み込まれるように設計されていることを示唆しています。これらのステークホルダーは、KYC（顧客確認規制）、不正防止、データプライバシーなどの分野で専門知識をもたらし、AP2がこれらのニーズに最初から対処するのに役立っています。要するに、AP2はエージェントフレンドリーで決済プロバイダーフレンドリーに構築されています。既存のAIエージェントプロトコルを拡張して取引を処理し、既存の決済ネットワークの上にレイヤーを重ねてそのインフラを利用しながら、必要な信頼保証を追加します。

セキュリティ、コンプライアンス、および相互運用性の考慮事項​

セキュリティと信頼はAP2設計の核心です。プロトコルが暗号技術（マンダートへのデジタル署名）を使用することで、エージェント型取引におけるすべての重要なアクションが検証可能で追跡可能であることが保証されます。この否認防止は非常に重要です。マンダートが安全な記録として機能するため、ユーザーもマーチャントも、承認され合意された内容を後で否認することはできません。直接的な利点は、不正防止と紛争解決にあります。AP2を使用すると、悪意のある、またはバグのあるエージェントが不正な購入を試みた場合、有効なユーザー署名済みマンダートがないことが明らかになり、取引を拒否または取り消すことができます。逆に、ユーザーが「この購入は承認していない」と主張しても、ユーザーの暗号学的署名付きカートマンダートが存在する場合、マーチャントと発行者は請求を裏付ける強力な証拠を持つことになります。この説明責任の明確さは、決済業界にとって主要なコンプライアンス上の懸念に応えるものです。

承認とプライバシー: AP2は、エージェント主導の取引に対してユーザーからの明示的な承認ステップ（または複数のステップ）を強制し、これは強力な顧客認証のような規制トレンドと一致しています。AP2に組み込まれたユーザーコントロールの原則は、ユーザー（またはユーザーから委任された者）が検証可能な指示を提供しない限り、エージェントが資金を使うことはできないことを意味します。完全に自律的なシナリオでも、ユーザーは意図マンダートを通じてルールを事前に定義します。このアプローチは、特定の取引についてエージェントに委任状を与えるのと似ていますが、デジタル署名され、きめ細かな方法で行われます。プライバシーの観点から、AP2はデータ共有について配慮しています。プロトコルはロールベースのデータアーキテクチャを使用し、機密情報（決済クレデンシャルや個人情報など）が絶対に必要な当事者とのみ共有されるようにします。例えば、エージェントはアイテムと価格情報を含むカートマンダートをマーチャントに送信するかもしれませんが、ユーザーの実際のカード番号は、エージェントやマーチャントではなく、決済処理業者との決済マンダートを通じてのみ共有される可能性があります。これにより、データの不必要な露出が最小限に抑えられ、プライバシー法や決済データ処理に関するPCI DSS規則への準拠が促進されます。

コンプライアンスと標準: AP2は、確立された金融機関からの意見を取り入れて開発されたため、決済における既存のコンプライアンス標準を満たすか、補完するように設計されています。このプロトコルは、通常の決済承認フローを迂回するものではなく、追加の証拠とフラグでそれらを強化します。これは、AP2取引が不正検出システム、3-Dセキュアチェック、または必要な規制チェックを依然として活用できることを意味し、AP2のマンダートは追加の認証要素またはコンテキストキューとして機能します。例えば、銀行は決済マンダートを顧客の取引に対するデジタル署名と同様に扱い、ユーザー同意の要件への準拠を合理化できる可能性があります。さらに、AP2の設計者は、「業界のルールと標準と連携して」作業していることを明示的に述べています。AP2が進化するにつれて、グローバルな金融標準に準拠することを確実にするために、正式な標準化団体（W3C、EMVCo、ISOなど）に持ち込まれる可能性があると推測できます。Googleは、標準化団体を通じてAP2のオープンで協力的な進化へのコミットメントを表明しています。このオープンなプロセスは、規制上の懸念を解消し、以前の決済標準（EMVチップカード、3-Dセキュアなど）が業界全体の協力によって行われたのと同様に、幅広い受け入れを達成するのに役立ちます。

相互運用性: 断片化の回避はAP2の主要な目標です。そのため、このプロトコルは公開されており、誰でも実装または統合できます。Google Cloudサービスに縛られていません。実際、AP2は**オープンソース（Apache-2ライセンス）**であり、仕様とリファレンスコードは公開GitHubリポジトリで入手できます。これにより、複数のベンダーがAP2を採用し、システムを連携させることができるため、相互運用性が促進されます。すでに、相互運用性の原則が強調されています。AP2は既存のオープンプロトコル（A2A、MCP）の拡張であり、非独占的であるため、単一ベンダーソリューションではなく、競争力のある実装エコシステムを育成します。実際には、企業Aが構築したAIエージェントは、両者がAP2に従っていれば、企業Bのマーチャントシステムと取引を開始できます。どちらの側も単一のプラットフォームにロックインされることはありません。

考えられる懸念の1つは、一貫した採用を確保することです。一部の主要なプレーヤーが異なるプロトコルやクローズドなアプローチを選択した場合、断片化が依然として発生する可能性があります。しかし、AP2を支える幅広い連合を考えると、デファクトスタンダードになる態勢が整っているようです。AP2エコシステムに多くのIDおよびセキュリティに特化した企業（例えば、Okta、Cloudflare、Ping Identity）が含まれていることは、相互運用性とセキュリティが共同で対処されていることを示唆しています。これらのパートナーは、AP2をID検証ワークフローや不正防止ツールに統合するのに役立ち、AP2取引がシステム間で信頼できることを保証します。

技術的な観点から見ると、AP2が広く受け入れられている暗号技術（JSON-LDまたはJWTベースの検証可能なクレデンシャル、公開鍵署名など）を使用しているため、既存のセキュリティインフラと互換性があります。組織は既存のPKI（公開鍵インフラ）を使用して、マンダート署名用の鍵を管理できます。AP2は分散型IDシステムとの統合も想定しているようです。Googleは、AP2がエージェント承認のための分散型IDのような分野で革新する機会を生み出すと述べています。これは、将来的にAP2がDID（分散型識別子）標準または分散型識別子検証を活用して、エージェントとユーザーを信頼できる方法で識別できることを意味します。このようなアプローチは、単一のIDプロバイダーに依存しないことで、相互運用性をさらに強化するでしょう。要するに、AP2は暗号技術と明確な説明責任を通じてセキュリティを強調し、設計上コンプライアンスに対応することを目指し、オープン標準の性質と幅広い業界サポートを通じて相互運用性を促進します。

既存プロトコルとの比較​

AP2は、既存の決済およびエージェントフレームワークがカバーしていなかったギャップ、すなわち自律型エージェントが安全かつ標準化された方法で決済を実行できるようにするという問題に対処する、斬新なプロトコルです。エージェント通信プロトコルの観点から見ると、AP2はAgent2Agent (A2A) プロトコルのような先行研究に基づいて構築されています。A2A（2025年初頭にオープンソース化）は、異なるAIエージェントが基盤となるフレームワークに関係なく相互に通信できるようにします。しかし、A2A自体は、エージェントが取引や決済をどのように行うべきかを定義していません。それはタスクの交渉とデータ交換に関するものです。AP2は、会話が購入につながったときに任意のエージェントが使用できるトランザクションレイヤーを追加することで、この状況を拡張します。本質的に、AP2はA2AやMCPと競合するのではなく、補完的であると見なすことができます。A2Aは通信とコラボレーションの側面をカバーし、MCPは外部ツール/APIの使用をカバーし、AP2は決済と商取引をカバーします。これらが一体となって、将来の「エージェント経済」のための標準のスタックを形成します。このモジュラーアプローチは、インターネットプロトコルにいくらか似ています。例えば、データ通信のためのHTTPとセキュリティのためのSSL/TLSのように、ここではA2AがエージェントのHTTPのようなものであり、AP2が商取引のための安全なトランザクションレイヤーであると言えます。

AP2を従来の決済プロトコルおよび標準と比較すると、類似点と相違点の両方があります。従来のオンライン決済（クレジットカード決済、PayPal取引など）は、通常、安全な送信のためのHTTPSなどのプロトコル、カードデータ処理のためのPCI DSSなどの標準、および追加のユーザー認証のための3-Dセキュアなどを含みます。これらはユーザー主導のフロー（ユーザーがクリックし、場合によってはワンタイムコードを入力する）を前提としています。対照的に、AP2は、セキュリティを損なうことなく、第三者（エージェント）がフローに参加する方法を導入します。AP2のマンダートの概念は、OAuthスタイルの委任された権限の拡張として、決済に適用されたものと比較できます。OAuthでは、ユーザーはトークンを介してアプリケーションにアカウントへの限定的なアクセスを許可します。同様にAP2では、ユーザーはマンダートを介して、特定条件下でエージェントに資金を使う権限を付与します。主な違いは、AP2の「トークン」（マンダート）が金融取引のための特定の署名済み指示であり、既存の決済承認よりもきめ細かい点です。

もう1つの比較点は、AP2が既存のeコマースチェックアウトフローとどのように関連するかです。例えば、多くのeコマースサイトは、W3C Payment Request APIやプラットフォーム固有のSDKなどのプロトコルを使用して決済を効率化しています。これらは主に、ブラウザやアプリがユーザーから決済情報を収集する方法を標準化するものであり、AP2は、エージェントがユーザーの意図をマーチャントと決済処理業者に証明する方法を標準化します。AP2が検証可能な意図と否認防止に焦点を当てている点は、より単純な決済APIとは一線を画します。決済ネットワークの上に信頼の追加レイヤーを追加しているのです。AP2は決済ネットワーク（Visa、ACH、ブロックチェーンなど）を置き換えるのではなく、むしろそれらを強化していると言えるでしょう。このプロトコルは、あらゆる種類の決済方法（暗号通貨でさえも）を明示的にサポートしているため、ゼロから新しい決済レールを作成するのではなく、これらのシステムとのエージェントの相互作用を標準化することに重点を置いています。

セキュリティおよび認証プロトコルの分野では、AP2はEMVチップカードのデジタル署名やデジタル契約の公証のようなものと共通の精神を持っています。例えば、EMVチップカード取引は、カードが存在していたことを証明するために暗号グラムを生成します。AP2は、ユーザーのエージェントが承認されていたことを証明する暗号学的証拠を生成します。どちらも不正防止を目的としていますが、AP2の範囲はエージェントとユーザーの関係、およびエージェントとマーチャントのメッセージングであり、これは既存の決済標準では対処されていません。もう1つの新たな比較は、**暗号通貨におけるアカウント抽象化（例：ERC-4337）**です。ユーザーは事前にプログラムされたウォレットアクションを承認できます。暗号通貨ウォレットは、特定の自動取引（スマートコントラクトを介したサブスクリプションの自動支払いなど）を許可するように設定できますが、これらは通常、1つのブロックチェーン環境に限定されます。一方、AP2はクロスプラットフォームであることを目指しています。一部の決済にブロックチェーンを活用できますが（その拡張機能を通じて）、従来の銀行とも連携します。

主流の決済業界には、AP2に直接「競合する」プロトコルはまだありません。AIエージェント決済のためのオープン標準に向けた最初の協調的な取り組みであるように見えます。独自の試みは発生する可能性があり（または個々の企業内で既に進行中である可能性もあります）、しかしAP2の幅広い支持は、その標準となる上で優位性をもたらします。IBMなどがAgent Communication Protocol (ACP) やエージェントの相互運用性のための同様のイニシアチブを持っていることは注目に値しますが、それらはAP2が包括的に行うような決済の側面を含んでいません。むしろ、AP2はこれらの取り組みと統合または活用する可能性があります（例えば、IBMのエージェントフレームワークは、商取引タスクのためにAP2を実装する可能性があります）。

要約すると、AP2はAIと決済の独自の交差点に焦点を当てることで差別化を図っています。古い決済プロトコルが人間ユーザーを前提としていたのに対し、AP2はAI仲介者を前提とし、その結果生じる信頼のギャップを埋めます。既存の決済プロセスと競合するのではなく、それらを拡張し、A2Aのような既存のエージェントプロトコルを補完します。今後、AP2は確立された標準と並行して使用される可能性があります。例えば、AP2カートマンダートは従来の決済ゲートウェイAPI呼び出しと連携して機能したり、AP2決済マンダートは銀行のISO 8583メッセージに添付されたりするかもしれません。AP2のオープンな性質は、代替アプローチが出現した場合でも、コミュニティの協力によってAP2がそれらを吸収または調整できることを意味します。この段階で、AP2はこれまで存在しなかったベースラインを設定しており、AIと決済スタックにおける新しいプロトコルレイヤーを効果的に開拓しています。

Web3と分散型システムへの影響​

当初から、AP2はWeb3および暗号通貨ベースの決済を包含するように設計されてきました。このプロトコルは、将来の商取引が従来の法定通貨チャネルと分散型ブロックチェーンネットワークの両方にまたがることを認識しています。前述のとおり、AP2はクレジットカードや銀行振込からステーブルコインや暗号通貨まで、さまざまな決済タイプをサポートしています。実際、AP2の発表と同時に、Googleは暗号通貨決済に特化した拡張機能であるA2A x402を発表しました。この拡張機能は、Coinbase、Ethereum Foundation、MetaMaskなどの暗号通貨業界のプレーヤーと共同で開発され、「エージェントベースの暗号通貨決済のための本番環境対応ソリューション」です。「x402」という名前は、Webで広く使用されることのなかったHTTP 402「Payment Required」ステータスコードへのオマージュであり、AP2の暗号通貨拡張機能は、オンチェーンで相互に請求または支払いを行いたい分散型エージェントのために、HTTP 402の精神を効果的に復活させます。実際には、x402拡張機能はAP2のマンダートの概念をブロックチェーン取引に適合させます。例えば、エージェントはユーザーからの署名済み意図マンダートを保持し、条件が満たされたらオンチェーン決済（例えば、ステーブルコインの送信）を実行し、そのオンチェーン取引にマンダートの証明を添付できます。これにより、AP2のオフチェーン信頼フレームワークとブロックチェーンのトラストレスな性質が結びつき、オンチェーン決済が*オフチェーンの当事者（ユーザー、マーチャント）*によって承認されたと信頼できるという、両方の世界の利点が得られます。

AP2とWeb3の相乗効果は、協力者のリストに明らかです。暗号通貨取引所（Coinbase）、ブロックチェーン財団（Ethereum Foundation）、暗号通貨ウォレット（MetaMask）、Web3スタートアップ（SuiのMysten Labs、Lightning NetworkのLightsparkなど）がAP2の開発に関与しています。彼らの参加は、AP2が分散型金融と競合するのではなく、補完的であると見なされていることを示唆しています。AIエージェントが暗号通貨決済と対話するための標準的な方法を作成することで、AP2はAI主導のアプリケーションにおける暗号通貨の使用を促進する可能性があります。例えば、AIエージェントはAP2を使用して、ユーザーの好みやマーチャントの受け入れに応じて、クレジットカードでの支払いとステーブルコインでの支払いをシームレスに切り替えることができます。A2A x402拡張機能は、エージェントがオンチェーン手段を通じてサービスを収益化または支払いできるように特別に設計されており、これは将来の分散型マーケットプレイスで非常に重要になる可能性があります。これは、ブロックチェーン上で自律的な経済主体として機能するエージェント（一部ではDACやDAOと呼ばれる概念）が、サービスに必要な支払い（情報のために別のエージェントに少額の手数料を支払うなど）を処理できる可能性を示唆しています。AP2は、そのような取引のための共通言語を提供し、分散型ネットワーク上であっても、エージェントがその行動に対する証明可能なマンダートを持っていることを保証できます。

競争という観点から見ると、純粋な分散型ソリューションがAP2を不要にするのか、あるいはその逆なのか、という疑問が生じるかもしれません。AP2はWeb3ソリューションと階層的なアプローチで共存する可能性が高いです。分散型金融はトラストレスな実行（スマートコントラクトなど）を提供しますが、「AIが人間からこれを行う許可を得たか？」という問題を本質的に解決するわけではありません。AP2は、決済自体がオンチェーンであっても重要な、その人間とAIの信頼のつながりに焦点を当てています。ブロックチェーンプロトコルと競合するのではなく、AP2はそれらをオフチェーンの世界と橋渡しするものと見なすことができます。例えば、スマートコントラクトは、有効なAP2マンダート署名への参照が含まれている場合にのみ特定の取引を受け入れることができ、これはオフチェーンの意図証明とオンチェーンの強制を組み合わせるために実装できます。逆に、暗号通貨ネイティブなエージェントフレームワーク（一部のブロックチェーンプロジェクトは、暗号通貨資金で動作する自律型エージェントを模索しています）がある場合、それらは独自の承認方法を開発するかもしれません。しかし、AP2の幅広い業界サポートは、それらのプロジェクトでさえも一貫性のためにAP2を採用または統合するように誘導する可能性があります。

もう一つの側面は分散型IDとクレデンシャルです。AP2が検証可能なクレデンシャルを使用していることは、Web3のIDへのアプローチ（W3Cによって標準化されたDIDやVCなど）と非常に一致しています。これは、AP2が分散型IDシステムに接続できることを意味します。例えば、ユーザーのDIDを使用してAP2マンダートに署名し、マーチャントはそれをブロックチェーンまたはIDハブに対して検証できます。エージェント承認のための分散型IDの探求に言及されていることは、AP2がWeb3のID革新を活用して、集中型機関にのみ依存するのではなく、分散型でエージェントとユーザーのIDを検証する可能性があることを裏付けています。これは相乗効果のポイントであり、AP2とWeb3の両方が、ユーザーにより多くの制御と行動の暗号学的証明を与えることを目指しています。

潜在的な対立は、大規模な仲介者の役割がない完全に分散化された商取引エコシステムを想定した場合にのみ発生する可能性があります。そのシナリオでは、AP2（Googleとそのパートナーによって最初に推進された）が集中化されすぎているか、従来のプレーヤーによって統治されすぎていると見なされる可能性があります。AP2がオープンソースであり、標準化可能であることを意図しているため、Google独自のプロトコルではないことに注意することが重要です。これは、オープンプロトコルを重視するWeb3コミュニティにとってより受け入れやすいものとなります。AP2が広く採用されれば、エージェント向けのWeb3固有の決済プロトコルの必要性を減らし、それによって取り組みを統一する可能性があります。一方で、一部のブロックチェーンプロジェクトは、特に集中型機関のないトラストレスな環境では、エージェント取引のために純粋なオンチェーン承認メカニズム（マルチシグウォレットやオンチェーンエスクローロジックなど）を好むかもしれません。これらは代替アプローチと見なされるかもしれませんが、オフチェーンシステムと相互作用できない限り、ニッチなままである可能性が高いです。AP2は両方の世界をカバーすることで、AIエージェントが暗号通貨をシームレスに使用できるもう1つの決済方法にするという点で、Web3の採用を実際に加速させるかもしれません。実際、あるパートナーは、「ステーブルコインは、レガシーインフラを持つエージェント型システムの[スケーリングの]課題に対する明白な解決策を提供する」と述べ、暗号通貨がAP2を補完して規模や国境を越えたシナリオを処理できることを強調しました。一方、Coinbaseのエンジニアリングリードは、x402暗号通貨拡張機能をAP2に導入することは「理にかなっていた。エージェントにとって自然な遊び場であり、エージェントが相互に支払いを行うことがAIコミュニティに響くのを見るのはエキサイティングだ」と述べました。これは、AIエージェントが暗号通貨ネットワークを介して取引することが単なる理論的なアイデアではなく、AP2を触媒として期待される結果であるというビジョンを示唆しています。

要約すると、AP2はWeb3に非常に密接に関連しています。暗号通貨決済を第一級市民として組み込み、分散型IDおよびクレデンシャル標準と連携しています。分散型決済プロトコルと真っ向から競合するのではなく、AP2はそれらと相互運用する可能性が高いです。AP2が承認レイヤーを提供し、分散型システムが価値移転を処理します。ステーブルコインやCBDCなどで伝統的な金融と暗号通貨の境界が曖昧になるにつれて、AP2のような統一されたプロトコルは、AIエージェントとあらゆる形態の通貨（集中型か分散型かに関わらず）との間の普遍的なアダプターとして機能する可能性があります。

業界での採用、パートナーシップ、およびロードマップ​

AP2の最大の強みの一つは、この初期段階にもかかわらず、広範な業界の支持を得ていることです。Google Cloudは、AP2に関して「60以上の多様な組織と協力している」と発表しました。これには、主要なクレジットカードネットワーク（例：Mastercard、American Express、JCB、UnionPay）、主要なフィンテックおよび決済処理業者（PayPal、Worldpay、Adyen、Checkout.com、Stripeの競合他社）、eコマースおよびオンラインマーケットプレイス（Etsy、Shopify（Stripeなどのパートナー経由）、Lazada、Zalora）、エンタープライズテクノロジー企業（Salesforce、ServiceNow、Oracle（パートナー経由の可能性あり）、Dell、Red Hat）、IDおよびセキュリティ企業（Okta、Ping Identity、Cloudflare）、コンサルティング会社（Deloitte、Accenture）、そして暗号通貨/Web3組織（Coinbase、Ethereum Foundation、MetaMask、Mysten Labs、Lightspark）などが含まれます。これほど幅広い参加者は、業界の関心と今後の採用の強力な指標です。これらのパートナーの多くは公に支持を表明しています。例えば、Adyenの共同CEOは、エージェント型商取引のための「共通のルールブック」の必要性を強調し、AP2を新しい決済構成要素でマーチャントをサポートするという彼らの使命の自然な延長と見なしています。American ExpressのEVPは、AP2が信頼と説明責任が最重要となる「次世代のデジタル決済」にとって重要であると述べました。Coinbaseのチームは、前述のとおり、AP2への暗号通貨決済の統合に期待を寄せています。この支持の合唱は、業界の多くの人々がAP2をAI主導の決済の有力な標準と見なし、その要件を満たすようにAP2を形成することに熱心であることを示しています。

採用の観点から見ると、AP2は現在、仕様および初期実装段階にあります（2025年9月発表）。完全な技術仕様、ドキュメント、および一部のリファレンス実装（Pythonなどの言語）は、開発者が試用できるようにプロジェクトのGitHubで入手できます。Googleはまた、AP2がエージェント向けの自社製品およびサービスに組み込まれることを示唆しています。注目すべき例は、前述のAIエージェントマーケットプレイスです。これは、サードパーティのAIエージェントをユーザーに提供できるプラットフォームです（おそらくGoogleの生成AIエコシステムの一部）。Googleは、エージェントを構築する多くのパートナーが、「AP2によって可能になる新しい、取引可能な体験」とともにマーケットプレイスでそれらを利用可能にすると述べています。これは、マーケットプレイスが立ち上がるか成長するにつれて、AP2が、Google Cloud Marketplaceからソフトウェアを自律的に購入したり、エージェントがユーザーのために商品/サービスを購入したりするなど、取引を実行する必要があるエージェントの基盤となることを意味します。自律調達（企業に代わってあるエージェントが別のエージェントから購入する）や自動ライセンススケーリングなどの企業ユースケースは、AP2がすぐに促進できる分野として具体的に言及されています。

ロードマップに関しては、AP2のドキュメントとGoogleの発表からいくつかの明確な兆候が示されています。

• 短期: コミュニティの意見を取り入れながら、プロトコルのオープンな開発を継続します。GitHubリポジトリは、実際のテストが行われるにつれて、追加のリファレンス実装と改善で更新されます。AP2をエージェントアプリケーションに統合しやすくするライブラリ/SDKの登場が期待されます。また、パートナー企業によって初期のパイロットプログラムや概念実証が実施される可能性があります。多くの大手決済企業が関与していることを考えると、それらは管理された環境（例えば、少数のユーザーベータ版でのAP2対応チェックアウトオプション）でAP2を試用するかもしれません。
• 標準とガバナンス: Googleは、AP2をオープンガバナンスモデルに移行するコミットメントを表明しており、おそらく標準化団体を通じて行われるでしょう。これは、AP2をLinux Foundation（A2Aプロトコルで行われたように）に提出したり、それを維持するためのコンソーシアムを形成したりすることを意味するかもしれません。Linux Foundation、W3C、さらにはISO/TC68（金融サービス）のような団体も、AP2を正式化する候補となる可能性があります。オープンガバナンスは、AP2が単一企業の管理下になく、中立的で包括的であることを業界に保証するでしょう。
• 機能拡張: 技術的には、ロードマップには、より多くの決済タイプとユースケースへのサポートの拡大が含まれています。仕様に記載されているように、カードの後、焦点は銀行振込や地域のリアルタイム決済スキーム、デジタル通貨などの「プッシュ」決済に移ります。これは、AP2が、カードプルとはフローが少し異なる直接銀行振込や暗号通貨ウォレット送金の場合に、意図/カート/決済マンダートがどのように機能するかを概説することを意味します。A2A x402拡張機能は暗号通貨のためのそのような拡張機能の1つであり、同様に、オープンバンキングAPIやB2B請求シナリオのための拡張機能も登場するかもしれません。
• セキュリティとコンプライアンスの強化: 実際の取引がAP2を通じて流れ始めると、規制当局やセキュリティ研究者からの精査が行われるでしょう。オープンプロセスは、マンダートをさらに堅牢にするために反復される可能性が高いです（例えば、マンダート形式が標準化されていることを確認する、おそらくW3C検証可能なクレデンシャル形式を使用するなど）。IDソリューションとの統合（ユーザーがマンダートに署名するための生体認証の活用、またはマンダートをデジタルIDウォレットにリンクするなど）は、信頼を強化するためのロードマップの一部となる可能性があります。
• エコシステムツール: 新たなエコシステムが生まれる可能性が高いです。すでに、スタートアップ企業はギャップに気づいています。例えば、Vellum.aiの分析では、Autumnというスタートアップが「AIのための請求インフラ」を構築しており、本質的にStripeの上にAIサービスの複雑な価格設定を処理するためのツールを提供していると述べられています。AP2が普及するにつれて、エージェントに特化した決済ゲートウェイ、マンダート管理ダッシュボード、エージェントID検証サービスなどのツールが増えることが期待されます。Googleの関与は、AP2がGoogle Cloud製品にも統合される可能性があることを意味します。DialogflowやVertex AI AgentsツールでのAP2サポートを想像してみてください。これにより、エージェントが取引を処理する（必要なすべての鍵と証明書がGoogle Cloudで管理される）ことがワンクリックで可能になります。

全体として、AP2の軌跡は、他の主要な業界標準を彷彿とさせます。強力なスポンサー（Google）による初期の立ち上げ、幅広い業界連合、オープンソースのリファレンスコード、それに続く反復的な改善と実際の製品への段階的な採用です。AP2がすべてのプレーヤーを「私たちと共にこの未来を築く」よう招待しているという事実は、ロードマップがコラボレーションに関するものであることを強調しています。勢いが続けば、AP2は数年後には、OAuthやOpenID Connectがそれぞれの分野で今日そうであるように、目に見えないが機能を実現する上で不可欠なレイヤーとして普及する可能性があります。

結論​

AP2 (Agents/Agent Payments Protocol) は、AIエージェントが人間と同じくらい信頼性高く安全に取引できる未来に向けた重要な一歩を表しています。技術的には、検証可能なマンダートとクレデンシャルの巧妙なメカニズムを導入し、エージェント主導の取引に信頼を植え付け、ユーザーの意図が明確で強制可能であることを保証します。そのオープンで拡張可能なアーキテクチャにより、急成長するAIエージェントフレームワークと確立された金融インフラの両方と統合できます。承認、信頼性、説明責任という核となる懸念に対処することで、AP2はセキュリティやユーザーコントロールを犠牲にすることなく、AI主導の商取引が繁栄するための基盤を築きます。

AP2の導入は、初期のインターネットプロトコルがウェブを可能にしたように、一部の人々が「エージェント経済」と呼ぶもののための新しい基盤を築くものと見なすことができます。それは、パーソナルショッパーエージェント、自動ディール検索ボット、自律型サプライチェーンエージェントなど、すべてが共通の信頼フレームワークの下で動作する、数え切れないほどの革新への道を開きます。重要なことに、AP2の包括的な設計（クレジットカードから暗号通貨まですべてを包含）は、伝統的な金融とWeb3の交差点に位置し、共通のエージェント仲介プロトコルを通じてこれらの世界を橋渡しする可能性があります。

これまでの業界の反応は非常に好意的で、幅広い連合がAP2が広く採用される標準になる可能性が高いことを示唆しています。AP2の成功は、継続的な協力と実世界でのテストにかかっていますが、それが対処する明確なニーズを考えると、その見通しは明るいです。より広い意味で、AP2はテクノロジーがどのように進化するかを示しています。新しい機能（AIエージェント）が登場し、古い前提を打ち破り、その解決策は、その機能に対応するための新しいオープン標準を開発することでした。今、オープンでセキュリティ第一のプロトコルに投資することで、Googleとそのパートナーは、商取引の次の時代に必要な信頼アーキテクチャを効果的に構築しています。「未来を予測する最善の方法は、それを構築することである」という言葉があるように、AP2はAIエージェントが私たちのためにシームレスに取引を処理する未来への賭けであり、その未来を可能にするために必要な信頼とルールを積極的に構築しています。

情報源:

• Google Cloud Blog – 「新しいAgent Payments Protocol (AP2)でAIコマースを強化」 (2025年9月16日)
• AP2 GitHub ドキュメント – 「Agent Payments Protocol 仕様と概要」
• Vellum AI Blog – 「GoogleのAP2: AIエージェント決済のための新しいプロトコル」 (分析)
• Medium記事 – 「Google Agent Payments Protocol (AP2)」 (Tahirによる要約、2025年9月)
• AP2に関するパートナーのコメント (Google Cloud Blog)
• A2A x402拡張機能 (AP2暗号通貨決済拡張機能) – GitHub README

リスク、監査、コンプライアンスを犠牲にせず、市場スピードで動くカストディと実行スタックを設計する方法。

エグゼクティブサマリー​

カストディと取引はもはや別々の世界で運用できません。今日のデジタル資産市場では、顧客資産を安全に保管するだけでは不十分です。価格がミリ秒単位で変動する中で取引を実行できなければ、リターンを逃すだけでなく、MEV（最大抽出可能価値）やカウンターパーティーの失敗、運用ボトルネックといった回避可能なリスクに顧客をさらすことになります。最新のカストディ・実行スタックは、最先端のセキュリティとハイパフォーマンスエンジニアリングを融合させる必要があります。具体的には、マルチパーティ計算（MPC）やハードウェアセキュリティモジュール（HSM）による署名、ポリシーエンジンとプライベートトランザクションルーティングによるフロントランニング防止、オフチェーン決済を活用したアクティブ/アクティブインフラでベニューリスクを低減し、資本効率を向上させます。コンプライアンスはオプションではなく、Travel Rule のデータフロー、イミュータブルな監査ログ、SOC 2 などのフレームワークにマッピングされたコントロールをトランザクションパイプラインに組み込む必要があります。

「カストディ速度」が今重要な理由​

従来、デジタル資産カストディは「鍵を失わない」ことを最優先にしていました。これは依然として基本ですが、要求は変化しています。現在は ベストエグゼキューション と 市場の健全性 が同等に不可欠です。取引がパブリックメンプールを通過すると、洗練されたアクターが取引を観測し、順序を入れ替えたり「サンドイッチ」したりして利益を抽出します。これは MEV の典型例であり、実行品質に直結します。プライベートトランザクションリレー を活用して機密オーダーフローを公開から隠すことは、リスク軽減の有力手段です。

同時に ベニューリスク も永続的な懸念です。単一取引所に大口残高を集中させると、カウンターパーティーリスクが顕在化します。オフチェーン決済ネットワークは、取引所提供の信用枠を利用しつつ資産を分離・破産回避型カストディに保つことで、この課題を解決します。結果として安全性と資本効率が大幅に向上します。

規制当局もギャップを埋めつつあります。FATF の Travel Rule の施行や IOSCO、金融安定理事会（FSB）などの勧告は、デジタル資産市場を 「同リスク・同ルール」 の枠組みへと押し進めています。つまり、カストディプラットフォームはデータフローと監査可能なコントロールを根本からコンプライアンス対応に設計しなければなりません。

設計目標（「良い」姿）​

ハイパフォーマンスなカストディスタックは、以下のコア原則に基づいて構築されるべきです。

• 予算化可能なレイテンシ：クライアントの意図からネットワークブロードキャストまでの各ミリ秒を測定・管理し、厳格な SLO（サービスレベル目標）で強制する。
• MEV 耐性のある実行：機密オーダーはデフォルトでプライベートチャネルへルーティング。パブリックメンプールへの露出は意図的な選択に留める。
• 鍵素材の確実な保証：プライベートキーは決して境界を越えてはならない。MPC シャード、HSM、TEE（Trusted Execution Environment）いずれであっても同様。鍵ローテーション、クォーラム強制、堅牢なリカバリ手順は必須。
• アクティブ/アクティブの信頼性：障害に耐える設計。RPC ノードとサイナーのマルチリージョン・マルチプロバイダー冗長化を実装し、回路遮断器やキルスイッチでベニュー・ネットワーク障害に自動対応。
• コンプライアンス・バイ・コンストラクション：コンプライアンスは後付けではなく、Travel Rule データ、AML/KYT 検査、イミュータブル監査トレイルを組み込んだアーキテクチャとし、SOC 2 の Trust Services Criteria に直接マッピング。

参考アーキテクチャ​

以下の図は、上記目標を満たすカストディ・実行プラットフォームのハイレベルアーキテクチャを示しています。

• Policy & Risk Engine はすべての指示の中心的ゲートキーパーです。Travel Rule ペイロード、速度制限、アドレスリスクスコア、サイナークォーラム要件などを評価し、鍵素材にアクセスする前に全てをチェックします。
• Signer Orchestrator は資産とポリシーに応じて最適な制御プレーンへ署名リクエストをルーティングします。具体例は以下の通りです
  • MPC（マルチパーティ計算）：閾値署名スキーム（t‑of‑n ECDSA/EdDSA）で信頼を複数のパーティやデバイスに分散。
  • HSM（ハードウェアセキュリティモジュール）：ハードウェアで鍵管理を強制し、決定的なバックアップとローテーションポリシーを提供。
  • TEE（例：AWS Nitro Enclaves）：署名コードを隔離し、測定済みソフトウェアに鍵をバインド。
• Execution Router は最適経路でトランザクションを送信します。情報感度が高い大口注文は プライベートトランザクション送信 を優先し、フロントランニングを回避。必要に応じてパブリック送信にフォールバックし、マルチプロバイダー RPC のフェイルオーバーでネットワーク障害時も高可用性を確保します。
• Observability Layer はシステム状態をリアルタイムで可視化。メンプール・ブロックのサブスクリプション、取引後のリコンシリエーション、そして イミュータブル監査レコード をすべての決定・署名・ブロードキャストに対して記録します。

セキュリティ構成要素（重要性）​

• 閾値署名（MPC）：鍵を分散管理し、単一のマシンや人物が単独で資金を移動できないようにします。最新の MPC プロトコルは高速かつ悪意ある攻撃に耐える署名を実現し、実運用のレイテンシ予算に適合します。
• HSM と FIPS 準拠：HSM は耐タンパーなハードウェアで鍵境界を強制し、FIPS 140‑3 や NIST SP 800‑57 といった標準に基づく監査可能な保証を提供します。
• 証明付き TEE：鍵を測定済みコードにバインドし、KMS と連携して証明されたワークロードのみに鍵素材を解放。承認されたコードだけが署名可能になります。
• MEV 対策のプライベートリレー：プライベートリレーは取引を直接ブロックビルダーやバリデータへ送信し、パブリックメンプールを迂回。フロントランニングやその他の MEV リスクを大幅に低減します。
• オフチェーン決済：資産を分離カストディに保持しつつ、取引所提供の信用枠で取引を実行。カウンターパーティーエクスポージャーを抑制し、決済速度を向上、資本効率を改善します。
• SOC 2 / ISO へのコントロールマッピング：運用コントロールを認知されたフレームワークに文書化・テストすることで、顧客・監査人・パートナーがセキュリティとコンプライアンスを独立検証可能にします。

レイテンシ・プレイブック：ミリ秒の行方​

低レイテンシ実行を実現するには、トランザクションライフサイクルのすべてのステップを最適化します。

• Intent → Policy Decision：ポリシー評価ロジックをメモリ上に常駐させ、KYT やアロウリストデータを短い TTL でキャッシュし、可能ならサイナークォーラムを事前計算。
• Signing：コールドスタートを避けるため、永続的な MPC セッションと HSM キーハンドルを使用。TEE ではエンクレーブを固定し、アテステーション経路を温め、セッションキーを安全に再利用。
• Broadcast：HTTP よりも永続的な WebSocket 接続で RPC ノードに送信。実行サービスをプライマリ RPC プロバイダーのリージョンに同居させ、レイテンシが急上昇した場合は冪等リトライとマルチプロバイダーへのヘッジ送信を実施。
• Confirmation：トランザクションステータスをポーリングせず、ネットワークから直接レシート・イベントをサブスクライブ。これらの状態変化をリアルタイムでリコンシリエーションパイプラインに流し、ユーザーへ即時フィードバックと内部帳簿更新を行う。

各ホップに対して厳格な SLO を設定（例：ポリシーチェック < 20 ms、署名 < 50‑100 ms、ブロードキャスト < 50 ms（通常負荷時））し、p95/p99 が逸脱した際はエラーバジェットと自動フェイルオーバーで対処します。

設計段階でのリスク＆コンプライアンス​

モダンなカストディスタックは、コンプライアンスをシステムの根幹に据える必要があります。

• Travel Rule オーケストレーション：すべての送金指示で送信者・受取者情報を生成・検証。未知の VASP への送金は自動的にブロックまたは迂回し、暗号化された受領証を監査用に記録。
• アドレスリスク＆アロウリスト：オンチェーン分析と制裁リストをポリシーエンジンに直接組み込み。デフォルトは「拒否」姿勢とし、明示的に許可されたアドレスまたはポリシー例外のみ送金を許可。
• イミュータブル監査：すべてのリクエスト・承認・署名・ブロードキャストをハッシュ化し、追記専用台帳に保存。SIEM へリアルタイムでストリームし、脅威検知と監査証跡の提供を実現。
• コントロールフレームワーク：技術・運用コントロールを SOC 2 の Trust Services Criteria（Security, Availability, Processing Integrity, Confidentiality, Privacy）にマッピングし、継続的なテストと検証プログラムを実装。

オフチェーン決済：安全なベニュー接続​

機関投資家規模のカストディスタックは、取引所へのエクスポージャーを最小化すべきです。オフチェーン決済ネットワーク はその鍵となります。これにより、資産は自社の分離カストディに保持されたまま、取引所の信用枠で取引が可能になります。結果として、破産リスクが抑制され、決済速度が向上し、資本効率が大幅に改善されます。

実装例：MPC、HSM、TEE の組み合わせ​

まとめ​

• カストディと取引は 同時に高速・安全・コンプライアンス対応 が求められる。
• MPC、HSM、TEE を組み合わせたハイブリッド署名基盤で鍵素材の安全性を確保。
• ポリシーエンジンとプライベートリレーで MEV を実質的に排除。
• オフチェーン決済でベニューリスクと資本コストを最小化。
• すべてのデータフローと操作を SOC 2 / ISO にマッピングし、イミュータブル監査ログで証跡を残す。

この設計指針に従うことで、機関投資家や規制当局の期待に応える、高速かつ信頼性の高いデジタル資産カストディスタック を構築できます。

LayerZero v2、Hyperlane、IBC 3.0 のような相互運用性プロトコルは、マルチチェーン DeFi エコシステムの重要なインフラとして台頭しています。それぞれがクロスチェーンメッセージングと共有流動性に対して異なるアプローチを取り、独自のセキュリティモデルを持っています：

• LayerZero v2 – 分散型検証者ネットワーク (DVN) を使用した証明集約モデル
• Hyperlane – マルチシグ検証者委員会を多用するモジュラーフレームワーク
• IBC 3.0 – Cosmos エコシステムにおける信頼最小化リレーヤーを備えたライトクライアントプロトコル

このレポートでは、各プロトコルのセキュリティメカニズムを分析し、ライトクライアント vs マルチシグ vs 証明集約 の長所と短所を比較し、それらが DeFi の構成可能性と流動性に与える影響を検証します。また、現在の実装、脅威モデル、採用レベルをレビューし、これらの設計選択がマルチチェーン DeFi の長期的な存続可能性にどのように影響するかについての見通しで締めくくります。

主要なクロスチェーンプロトコルのセキュリティメカニズム​

LayerZero v2：分散型検証者ネットワーク (DVN) による証明集約​

LayerZero v2 は、モジュラーでアプリケーション設定可能なセキュリティレイヤーを重視するオムニチェーンメッセージングプロトコルです。中心的なアイデアは、アプリケーションが 1 つ以上の独立した分散型検証者ネットワーク (DVN) でメッセージを保護できるようにすることです。これらの DVN は集合的にクロスチェーンメッセージを証明します。LayerZero の証明集約モデルでは、各 DVN は基本的にメッセージを独立して検証できる検証者のセットです (例：ブロック証明や署名のチェック)。アプリケーションは、メッセージを受け入れる前に複数の DVN からの集約された証明を要求することができ、しきい値を持つ「セキュリティスタック」を形成します。

デフォルトでは、LayerZero はいくつかの DVN をすぐに利用できるように提供しています。例えば、LayerZero Labs が運営する 2-of-3 マルチシグ検証を使用する DVN や、Google Cloud が運営する DVN などです。しかし重要なのは、開発者が DVN を自由に組み合わせられることです。例えば、特定の DVN の署名に加えて、他の 5 つのうち任意の 2 つの署名を必要とする 「1 of 3 of 5」 の設定を要求することができます。この柔軟性により、異なる検証方法 (ライトクライアント、zk プルーフ、オラクルなど) を 1 つの集約された証明に組み合わせることが可能です。事実上、LayerZero v2 は v1 のウルトラライトノードモデル (1 つのリレーヤー + 1 つのオラクルに依存) を、DVN をまたいだ X-of-Y-of-N マルチシグ集約へと一般化しています。各チェーン上のアプリケーションの LayerZero エンドポイントコントラクトは、必要な DVN クォーラムがそのメッセージに対して有効な証明を書き込んだ場合にのみ、メッセージを配信します。

セキュリティ特性： LayerZero のアプローチは、要求されたセット内の少なくとも 1 つの DVN が正直である (または 1 つの zk プルーフが有効であるなど) 限り、信頼最小化されています。アプリが 独自の DVN を必須の署名者として実行できるようにすることで、LayerZero はアプリチームの検証者によって承認されない限り、いかなるメッセージも拒否できるようにします。これにより、セキュリティを大幅に強化できます (中央集権化のコストはかかりますが)、アプリの署名なしにクロスチェーンメッセージが実行されることはありません。一方で、開発者はより分散化された DVN クォーラム (例：15 の独立したネットワークのうち 5 つ) を選択して、より強力な信頼分散を実現することもできます。LayerZero はこれを「アプリケーション所有のセキュリティ」と呼んでいます：各アプリは、DVN を設定することで、セキュリティ、コスト、パフォーマンスの間のトレードオフを選択します。すべての DVN の証明は、最終的に不変の LayerZero エンドポイントコントラクトによってオンチェーンで検証され、パーミッションレスなトランスポートレイヤーを維持します。欠点は、セキュリティが選択された DVN の強度に依存することです。設定された DVN が共謀したり侵害されたりすると、不正なクロスチェーンメッセージを承認する可能性があります。したがって、堅牢な DVN を選択するか、より弱いセキュリティのリスクを負うかは、各アプリケーションの責任となります。

Hyperlane：モジュラー ISM を備えたマルチシグ検証者モデル​

Hyperlane は、ターゲットチェーンでメッセージが配信される前に検証を行うオンチェーンのインターチェーンセキュリティモジュール (ISM) を中心とした相互運用性フレームワークです。最も単純な (そしてデフォルトの) 設定では、Hyperlane の ISM はマルチシグネチャ検証者セットを使用します。これは、オフチェーンの検証者からなる委員会がソースチェーンからの証明 (多くの場合、すべての送信メッセージのマークルルート) に署名し、宛先チェーンでしきい値以上の署名が必要とされるものです。言い換えれば、Hyperlane はパーミッション制の検証者クォーラムに依存して、「メッセージ X が確かにチェーン A で発行された」ことを確認します。これは、ブロックチェーンのコンセンサスに似ていますが、ブリッジレベルでのものです。例えば、Wormhole は 19 のガーディアンと 13-of-19 のマルチシグを使用しており、Hyperlane のアプローチも精神的には似ています (ただし、Hyperlane は Wormhole とは異なります)。

重要な特徴は、Hyperlane がプロトコルレベルで単一の固定された検証者セットを持っていないことです。代わりに、誰でも検証者を実行でき、異なるアプリケーションは異なる検証者リストとしきい値を持つ ISM コントラクトをデプロイできます。Hyperlane プロトコルはデフォルトの ISM デプロイメント (チームがブートストラップした検証者セットを含む) を提供しますが、開発者は自由に検証者セットやセキュリティモデルをカスタマイズできます。実際、Hyperlane は複数のタイプの ISM をサポートしており、複数の検証方法を組み合わせる集約 ISM や、メッセージパラメータに基づいて ISM を選択するルーティング ISM などがあります。例えば、アプリは Hyperlane のマルチシグ と 外部ブリッジ (Wormhole や Axelar など) の両方の署名を要求することで、冗長性を通じてより高いセキュリティ基準を達成できます。

セキュリティ特性： Hyperlane のマルチシグモデルの基本的なセキュリティは、検証者の大多数の正直さに由来します。しきい値 (例：8 人中 5 人) の検証者が共謀すれば、不正なメッセージに署名できるため、信頼の前提は約 N-of-M マルチシグ信頼です。Hyperlane はこのリスクに対処するため、EigenLayer リステーキングと統合し、検証者が不正行為に対してスラッシュされる可能性のあるステークされた ETH を預けることを要求する経済的セキュリティモジュール (ESM) を作成しています。この「アクティブ検証サービス (AVS)」は、Hyperlane の検証者が無効なメッセージ (ソースチェーンの履歴に実際には存在しないメッセージ) に署名した場合、誰でも Ethereum 上で証明を提示してその検証者のステークをスラッシュできることを意味します。これにより、不正行為を経済的に抑制することでセキュリティモデルが大幅に強化されます。Hyperlane のクロスチェーンメッセージは、検証者の社会的評判だけでなく、Ethereum の経済的な重みによって保護されるようになります。しかし、トレードオフとして、スラッシングを Ethereum に依存することは、Ethereum のライブネスへの依存を生み出し、不正証明が時間内に提出可能であることを前提とします。ライブネスに関しては、Hyperlane は、しきい値を満たすのに十分な検証者がオンラインでない場合、メッセージ配信が停止する可能性があると警告しています。プロトコルは、柔軟なしきい値設定を許可することでこれを緩和します。例えば、より大きな検証者セットを使用して、時折のダウンタイムがネットワークを停止させないようにします。全体として、Hyperlane のモジュラーマルチシグアプローチは、検証者セットへの信頼を追加するコストと引き換えに、柔軟性とアップグレード可能性 (アプリが独自のセキュリティを選択したり、複数のソースを組み合わせたりできる) を提供します。これは真のライトクライアントよりも弱い信頼モデルですが、最近のイノベーション (リステークされた担保やスラッシングなど) により、多くのチェーンに展開しやすいままで、実際には同等のセキュリティ保証に近づくことができます。

IBC 3.0：信頼最小化リレーヤーを備えたライトクライアント​

Cosmos エコシステムで広く使用されている Inter-Blockchain Communication (IBC) プロトコルは、根本的に異なるアプローチを取ります。新しい検証者セットを導入するのではなく、オンチェーンのライトクライアントを使用してクロスチェーンの状態を検証します。IBC では、各チェーンのペアが接続を確立し、チェーン B はチェーン A のライトクライアントを保持します (逆も同様)。このライトクライアントは、本質的に相手チェーンのコンセンサス (例：検証者セットの署名やブロックハッシュの追跡) の簡略化されたレプリカです。チェーン A がチェーン B にメッセージ (IBC パケット) を送信すると、リレーヤー (オフチェーンのアクター) が証明 (パケットのマークルプルーフと最新のブロックヘッダー) をチェーン B に運びます。その後、チェーン B の IBC モジュールは、オンチェーンのライトクライアントを使用して、その証明がチェーン A のコンセンサスルールのもとで有効であることを検証します。証明が確認されれば (つまり、パケットが A のファイナライズされたブロックにコミットされていれば)、メッセージは受け入れられ、B のターゲットモジュールに配信されます。本質的に、チェーン B は仲介者ではなく、チェーン A のコンセンサスを直接信頼します。これが、IBC がしばしば信頼最小化された相互運用性と呼ばれる理由です。

IBC 3.0 は、このプロトコルの最新の進化 (2025 年頃) を指し、パフォーマンスと機能のアップグレードを導入しています：低遅延のための並列リレーイング、特殊なユースケースのためのカスタムチャネルタイプ、リモート状態を読み取るためのインターチェーンクエリなどです。特筆すべきは、これらのいずれも中心的なライトクライアントのセキュリティモデルを変更するものではなく、速度と機能を強化するものであることです。例えば、並列リレーイングは、複数のリレーヤーが同時にパケットを運ぶことでボトルネックを回避し、セキュリティを犠牲にすることなくライブネスを向上させることを意味します。インターチェーンクエリ (ICQ) は、チェーン A のコントラクトがチェーン B にデータ (証明付き) を要求できるようにし、そのデータは A の B に対するライトクライアントによって検証されます。これにより、IBC の機能はトークン転送を超えて、より一般的なクロスチェーンデータアクセスにまで拡張されますが、依然として検証済みのライトクライアント証明に基づいています。

セキュリティ特性： IBC のセキュリティ保証は、ソースチェーンの完全性と同じくらい強力です。チェーン A が正直な多数派 (または設定されたコンセンサスしきい値) を持ち、チェーン B の A に対するライトクライアントが最新であれば、受け入れられたパケットは 必ず A の有効なブロックから来たものでなければなりません。ブリッジの検証者やオラクルを信頼する必要はありません。唯一の信頼の前提は、2 つのチェーンのネイティブなコンセンサスと、ライトクライアントの信頼期間 (この期間を過ぎると古いヘッダーは失効する) などのいくつかのパラメータです。IBC のリレーヤーは信頼される必要はありません。有効なヘッダーやパケットを偽造することはできず、それらは検証に失敗するからです。最悪の場合、悪意のあるまたはオフラインのリレーヤーはメッセージを検閲または遅延させることができますが、誰でもリレーヤーを実行できるため、少なくとも 1 人の正直なリレーヤーが存在すれば、最終的にライブネスは達成されます。これは非常に強力なセキュリティモデルです：事実上、デフォルトで分散化されパーミッションレスであり、チェーン自体の特性を反映しています。トレードオフはコストと複雑さにあります。別のチェーン上でライトクライアント (特に高スループットのチェーンの) を実行することは、リソースを大量に消費する可能性があります (検証者セットの変更の保存、署名の検証など)。Tendermint/BFT を使用する Cosmos SDK チェーンでは、このコストは管理可能で IBC は非常に効率的ですが、異種のチェーン (Ethereum や Solana など) を統合するには、複雑なクライアント実装や新しい暗号技術が必要です。実際、IBC を介して非 Cosmos チェーンをブリッジングする動きは遅く、Polymer や Composable といったプロジェクトが、IBC を Ethereum などに拡張するためにライトクライアントや zk プルーフに取り組んでいます。IBC 3.0 の改善 (最適化されたライトクライアント、異なる検証方法のサポートなど) は、これらのコストを削減することを目指しています。要約すると、IBC のライトクライアントモデルは、最も強力な信頼保証 (外部の検証者が一切不要) と堅牢なライブネス (複数のリレーヤーが存在する場合) を提供しますが、その代償として実装の複雑性が高く、参加するすべてのチェーンが IBC プロトコルをサポートしなければならないという制約があります。

ライトクライアント、マルチシグ、証明集約の比較​

各セキュリティモデル – ライトクライアント (IBC)、検証者マルチシグ (Hyperlane)、集約証明 (LayerZero) – には、それぞれ明確な長所と短所があります。以下では、主要な側面でこれらを比較します：

セキュリティ保証​

• ライトクライアント (IBC): ソースチェーンのコンセンサスにオンチェーン検証を固定することで、最高のセキュリティを提供します。新たな信頼レイヤーは存在しません。ソースブロックチェーン (例：Cosmos Hub や Ethereum) がブロックを二重生成しないと信頼するなら、それが送信するメッセージも信頼できます。これにより、追加の信頼の前提と攻撃対象領域が最小化されます。しかし、ソースチェーンの検証者セットが破損した場合 (例：Tendermint で >⅓、PoS チェーンで >½ が不正を働く)、ライトクライアントは不正なヘッダーを受け取る可能性があります。実際には、IBC チャネルは通常、経済的に安全なチェーン間で確立され、ライトクライアントはリスクを軽減するためにパラメータ (信頼期間やブロックファイナリティ要件など) を持つことができます。全体として、信頼最小化はライトクライアントモデルの最大の利点です。各メッセージには暗号的な有効性の証明があります。

• マルチシグ検証者 (Hyperlane および同様のブリッジ): セキュリティは、オフチェーンの署名者セットの正直さに依存します。典型的なしきい値 (例：検証者の ⅔) が、各クロスチェーンメッセージまたは状態のチェックポイントに署名する必要があります。利点は、十分な評判の良い、または経済的にステークされた検証者がいれば、これをかなり安全にできることです。例えば、Wormhole の 19 のガーディアンや Hyperlane のデフォルト委員会がシステムを侵害するには、集合的に共謀する必要があります。欠点は、これが新たな信頼の前提を導入することです。ユーザーはチェーンに加えてブリッジの委員会も信頼しなければなりません。これは、いくつかのハッキングで失敗点となっています (例：秘密鍵が盗まれたり、内部関係者が共謀したりした場合)。Hyperlane のリステークされた ETH 担保のような取り組みは、このモデルに経済的セキュリティを追加します。無効なデータに署名した検証者は、Ethereum 上で自動的にスラッシュされます。これにより、マルチシグブリッジはブロックチェーンのセキュリティに近づきます (不正行為を金銭的に罰することで) が、それでもライトクライアントほど信頼最小化されてはいません。要するに、マルチシグは信頼保証において弱いです。少人数のグループの多数派に依存しますが、スラッシングや監査によって信頼性を高めることはできます。

• 証明集約 (LayerZero v2): これは、ある意味で中間的な立場です。アプリケーションがセキュリティスタックにライトクライアント DVN や zk プルーフ DVN を含めるように設定した場合、その保証はそれらのチェックに対して IBC レベル (数学とチェーンのコンセンサス) に近づくことができます。委員会ベースの DVN (LayerZero の 2-of-3 デフォルトや Axelar アダプターなど) を使用する場合、そのマルチシグの信頼の前提を継承します。LayerZero モデルの強みは、複数の検証者を独立して組み合わせられることです。例えば、「zk プルーフが有効である」かつ「Chainlink オラクルがブロックヘッダーは X であると言っている」かつ「我々自身の検証者が署名する」ことを要求することで、攻撃の可能性を劇的に減らすことができます (攻撃者はすべてを一度に破る必要があります)。また、アプリが独自の DVN を必須とすることで、LayerZero は、そのように設定されていれば、アプリの同意なしにメッセージが実行されることはないと保証します。弱みは、開発者が (より安い手数料や速度のために) 緩いセキュリティ設定を選択した場合、セキュリティを損なう可能性があることです。例えば、未知の当事者が運営する単一の DVN を使用することは、単一の検証者を信頼するのと同様です。LayerZero 自体は意見を持たず、これらの選択をアプリ開発者に委ねているため、セキュリティは選択された DVN の質に依存します。要約すると、証明集約は非常に強力なセキュリティ (複数の独立した証明を要求することで、単一のライトクライアントよりも高い) を提供できますが、設定を誤ると弱いセットアップも許容してしまいます。柔軟性があり、アプリは高価値のトランザクションにはセキュリティを強化し (例：複数の大手 DVN を要求)、低価値のトランザクションにはそれを緩和できます。

ライブネスと可用性​

• ライトクライアント (IBC): ライブネスはリレーヤーとライトクライアントが最新の状態を保つことに依存します。良い点は、誰でもリレーヤーを実行できるため、システムが特定のノードセットに依存しないことです。1 つのリレーヤーが停止しても、別のリレーヤーがその仕事を引き継ぐことができます。IBC 3.0 の並列リレーイングは、すべてのパケットを 1 つのパスでシリアル化しないことで、可用性をさらに向上させます。実際には、IBC 接続は非常に信頼性が高いですが、ライブネスが低下するシナリオもあります。例えば、リレーヤーが長期間更新を投稿しないと、ライトクライアントが期限切れになり (例：信頼期間が更新なしに経過した場合)、安全のためにチャネルが閉じられる可能性があります。しかし、そのようなケースはまれであり、アクティブなリレーヤーネットワークによって緩和されます。もう 1 つのライブネスの考慮事項は、IBC パケットがソースチェーンのファイナリティに従うことです。例えば、Tendermint で 1〜2 ブロック (数秒) 待つのが標準です。全体として、IBC は少なくとも 1 つのアクティブリレーヤーが存在する限り高い可用性を提供し、遅延は通常、ファイナライズされたブロックに対して低い (数秒) です。マルチシグのように検証者のクォーラムがオフラインになるという概念はなく、ブロックチェーン自体のコンセンサスファイナリティが主な遅延要因です。

• マルチシグ検証者 (Hyperlane): 検証者セットが小さい場合、ライブネスは弱点になる可能性があります。例えば、ブリッジが 5-of-8 のマルチシグを持ち、4 人の検証者がオフラインまたは到達不能な場合、しきい値を満たせないためクロスチェーンメッセージングは停止します。Hyperlane のドキュメントでは、設定されたしきい値によっては、検証者のダウンタイムがメッセージ配信を停止させる可能性があると指摘しています。これが、稼働時間を向上させるために、より大きな委員会やより低いしきい値 (安全性のトレードオフあり) を選択する理由の一部です。Hyperlane の設計では、必要に応じて新しい検証者をデプロイしたり、ISM を切り替えたりできますが、そのような変更には調整/ガバナンスが必要になる場合があります。マルチシグブリッジが持つ利点は、しきい値の署名が集まれば通常は迅速に確認できることです。マルチシグの証明自体がファイナリティであるため、宛先チェーンでソースチェーンのブロックファイナリティを待つ必要はありません。実際、多くのマルチシグブリッジは数秒以内にメッセージに署名し、リレーします。したがって、一部のチェーンでは遅延がライトクライアントと同等かそれ以下になる可能性があります。ボトルネックは、検証者が遅い、地理的に分散している、または手動のステップが関与する場合です。要約すると、マルチシグモデルはほとんどの場合、高いライブネスと低遅延を実現できますが、ライブネスのリスクが検証者セットに集中しています。あまりにも多くの検証者がクラッシュしたり、彼らの間でネットワーク分断が発生したりすると、ブリッジは事実上ダウンします。

• 証明集約 (LayerZero): ここでのライブネスは、各 DVN とリレーヤーの可用性に依存します。メッセージは、必要な DVN から署名/証明を収集し、その後ターゲットチェーンにリレーされる必要があります。良い点は、DVN が独立して動作することです。(セットのうちの) 1 つの DVN がダウンしていて、それが必須でない場合 (「M of N」の一部に過ぎない場合)、しきい値が満たされる限りメッセージは進行できます。LayerZero のモデルは、一部の DVN の障害を許容するようにクォーラムを設定することを明示的に許可しています。例えば、「2 of 5」の DVN セットは、3 つの DVN がオフラインであってもプロトコルを停止させることなく処理できます。さらに、誰でも最終的なエグゼキューター/リレーヤーの役割を実行できるため、メッセージ配信に単一障害点はありません。プライマリリレーヤーが失敗した場合、ユーザーや他の当事者が証明を持ってコントラクトを呼び出すことができます (これは IBC のパーミッションレスなリレーヤーの概念に類似しています)。したがって、LayerZero v2 は、システムを 1 つの仲介者に縛り付けないことで、検閲耐性とライブネスを目指しています。しかし、必須の DVN がセキュリティスタックの一部である場合 (例えば、アプリが常に独自の DVN の署名を要求する場合)、その DVN はライブネスの依存関係になります。それがオフラインになると、それが復旧するかセキュリティポリシーが変更されるまでメッセージは一時停止します。一般的に、証明集約は堅牢に設定できます (冗長な DVN と任意の当事者によるリレーイングにより)、すべての検証者が一度にダウンする可能性は低いです。トレードオフは、複数の DVN に連絡することが、単一のより高速なマルチシグと比較して、少し多くの遅延を引き起こす可能性があることです (例：複数の署名を待つ)。しかし、それらの DVN は並行して実行でき、多くの DVN (オラクルネットワークやライトクライアントなど) は迅速に応答できます。したがって、LayerZero は高いライブネスと低遅延を達成できますが、正確なパフォーマンスは DVN の設定方法に依存します (一部はソースチェーンで数ブロックの確認を待つかもしれず、それが安全のために遅延を追加する可能性があります)。

コストと複雑性​

• ライトクライアント (IBC): このアプローチは、実装は複雑だが、互換性のあるチェーンで一度設定すれば安価に使用できる傾向があります。複雑さは、各タイプのブロックチェーンに対して正しいライトクライアント実装を作成することにあります。本質的に、チェーン A のコンセンサスルールをチェーン B のスマートコントラクトにエンコードすることになります。同様のコンセンサスを持つ Cosmos SDK チェーンではこれは簡単でしたが、Cosmos を超えて IBC を拡張するには、重いエンジニアリングが必要でした (例：Polkadot の GRANDPA ファイナリティ用のライトクライアントの構築、または zk プルーフを用いた Ethereum ライトクライアントの計画)。これらの実装は些細なものではなく、非常に安全でなければなりません。また、オンチェーンのストレージオーバーヘッドもあります。ライトクライアントは、相手チェーンの最近の検証者セットや状態ルート情報を保存する必要があります。これにより、チェーン上の状態サイズと証明検証コストが増加する可能性があります。結果として、例えば Ethereum メインネット上で直接 IBC を実行する (Cosmos のヘッダーを検証する) ことは、ガス代の観点から高価になります。これが、Polymer のようなプロジェクトがこれらのライトクライアントをメインネット外でホストするために Ethereum ロールアップを作成している理由の 1 つです。Cosmos エコシステム内では、IBC トランザクションは非常に効率的です (多くの場合、ガス代は数セント程度)。これは、ライトクライアントの検証 (ed25519 署名、マークルプルーフ) がプロトコルレベルで十分に最適化されているためです。ユーザーにとって IBC の使用は比較的低コストであり、リレーヤーは宛先チェーンで通常のトランザクション手数料を支払うだけです (ICS-29 ミドルウェアを介して手数料でインセンティブを得ることができます)。要約すると、IBC のコストは開発の複雑さに前倒しされていますが、一度実行されれば、ネイティブで手数料効率の良いトランスポートを提供します。接続されている多くの Cosmos チェーン (100 以上のゾーン) は共通の実装を共有しており、これが標準化によって複雑性を管理するのに役立っています。

• マルチシグブリッジ (Hyperlane/Wormhole/etc.): ここでの実装の複雑さはしばしば低くなります。コアとなるブリッジングコントラクトは、主に保存された公開鍵に対して一連の署名を検証する必要があります。このロジックは、完全なライトクライアントよりも単純です。オフチェーンの検証者ソフトウェアは運用上の複雑さ (チェーンイベントの監視、メッセージのマークルツリーの維持、署名収集の調整など) を導入しますが、これはブリッジ運営者によって管理され、オフチェーンに保たれます。オンチェーンコスト：いくつかの署名 (例えば 2 つまたは 5 つの ECDSA 署名) を検証することはそれほど高価ではありませんが、単一のしきい値署名やハッシュチェックよりも多くのガスを消費することは確かです。一部のブリッジは、集約署名スキーム (例：BLS) を使用して、オンチェーンコストを 1 回の署名検証に削減しています。一般的に、Ethereum や同様のチェーンでのマルチシグ検証は中程度のコストがかかります (各 ECDSA 署名チェックは約 3000 ガス)。ブリッジが 10 の署名を必要とする場合、検証だけで約 3 万ガスかかり、それに加えて新しいマークルルートの保存などがあります。これは通常、クロスチェーン転送が高価値の操作であることを考えると許容範囲ですが、積み重なる可能性があります。開発者/ユーザーの観点から見ると、マルチシグブリッジとの対話は簡単です。デポジットするか、送信関数を呼び出すだけで、残りはオフチェーンで検証者/リレーヤーによって処理され、その後証明が提出されます。アプリ開発者にとっては、ブリッジの API/コントラクトを統合するだけなので、複雑さは最小限です。複雑さの考慮事項の 1 つは、新しいチェーンの追加です。すべての検証者は、メッセージを監視するために各新しいチェーンのノードまたはインデクサーを実行する必要があり、これは調整の頭痛の種になる可能性があります (これは一部のマルチシグ設計で拡張のボトルネックとして指摘されていました)。Hyperlane の答えはパーミッションレスな検証者 (ISM に含まれていれば誰でもチェーンに参加できる) ですが、ISM をデプロイするアプリケーションは依然として最初にそれらのキーを設定する必要があります。全体として、マルチシグモデルは異種のチェーン間でブートストラップするのが容易であり (チェーンごとに特注のライトクライアントは不要)、市場投入までの時間を短縮できますが、オフチェーンでの運用上の複雑さと中程度のオンチェーン検証コストが発生します。

• 証明集約 (LayerZero): ここでの複雑さは、多くの可能な検証方法の調整にあります。LayerZero は標準化されたインターフェース (Endpoint & MessageLib コントラクト) を提供し、DVN が特定の検証 API に準拠することを期待しています。アプリケーションの観点から見ると、LayerZero の使用は非常に簡単です (lzSend を呼び出し、lzReceive コールバックを実装するだけ) が、その裏では多くのことが行われています。各 DVN は独自のオフチェーンインフラを持つ可能性があります (一部の DVN は、Axelar ネットワークや Chainlink オラクルサービスのように、それ自体がミニブリッジです)。プロトコル自体は複雑です。なぜなら、異なる証明タイプを安全に集約する必要があるからです。例えば、ある DVN は EVM ブロック証明を提供し、別の DVN は SNARK を、また別の DVN は署名を提供し、コントラクトはそれぞれを順番に検証しなければなりません。利点は、この複雑さの多くが LayerZero のフレームワークによって抽象化されていることです。コストは、いくつの、そしてどのタイプの証明が必要かに依存します。SNARK の検証は高価になる可能性があります (オンチェーンの zk プルーフ検証は数十万ガスかかることがあります) が、いくつかの署名の検証は安価です。LayerZero は、アプリがメッセージごとにセキュリティにどれだけ支払いたいかを決定できるようにします。また、DVN にその仕事に対して支払うという概念もあります。メッセージペイロードには DVN サービスの手数料が含まれています。例えば、アプリは DVN とエグゼキューターがメッセージを迅速に処理するようにインセンティブを与える手数料を添付できます。これによりコストの側面が加わります。より安全な設定 (多くの DVN や高価な証明を使用) は手数料が高くなりますが、単純な 1-of-1 DVN (単一のリレーヤーのような) は非常に安価ですが、セキュリティは低くなります。アップグレード可能性とガバナンスも複雑さの一部です。アプリはセキュリティスタックを変更できるため、それを行うためのガバナンスプロセスまたは管理者キーが必要です。これはそれ自体が信頼/管理の複雑さのポイントです。要約すると、LayerZero を介した証明集約は非常に柔軟ですが、内部は複雑です。メッセージごとのコストは、効率的な DVN を選択することで最適化できます (例：最適化された超軽量クライアントを使用したり、既存のオラクルネットワークの規模の経済を活用したりする)。多くの開発者は、(デフォルトが提供されている) プラグアンドプレイの性質を魅力的だと感じるでしょう。例えば、簡単にするためにデフォルトの DVN セットを使用するなどです。しかし、それが理解されていない場合、最適でない信頼の前提につながる可能性があります。

アップグレード可能性とガバナンス​

• ライトクライアント (IBC): IBC 接続とクライアントは、参加チェーンのオンチェーンガバナンス提案を通じてアップグレードできます (特に、ライトクライアントが修正を必要とする場合や、ソースチェーンのハードフォークに対応する更新が必要な場合)。IBC プロトコル自体をアップグレードする (例えば IBC 2.0 から 3.0 の機能へ) にも、ソフトウェアの新しいバージョンを採用するためにチェーンのガバナンスが必要です。これは、IBC が意図的なアップグレードパスを持つことを意味します。変更は遅く、コンセンサスが必要ですが、それはセキュリティ第一のアプローチと一致しています。単一のエンティティがスイッチを切り替えることはできず、各チェーンのガバナンスがクライアントやパラメータの変更を承認しなければなりません。良い点は、これにより脆弱性を導入する可能性のある一方的な変更を防げることです。悪い点は、俊敏性が低いことです。例えば、ライトクライアントにバグが見つかった場合、それを修正するには多くのチェーンにわたる協調的なガバナンス投票が必要になるかもしれません (ただし、緊急時の調整メカニズムは存在します)。dApp の観点から見ると、IBC には「アプリレベルのガバナンス」はあまりありません。それはチェーンによって提供されるインフラです。アプリケーションは単に IBC モジュール (トークン転送やインターチェーンアカウントなど) を使用し、チェーンのセキュリティに依存します。したがって、ガバナンスとアップグレードはブロックチェーンレベル (Hub と Zone のガバナンス) で行われます。興味深い新しい IBC の機能として、カスタムチャネルとルーティング (Polymer や Nexus のようなハブなど) があり、これによりアプリを中断することなく基盤となる検証方法を切り替えることができます。しかし、概して IBC は安定しており標準化されています。アップグレードは可能ですが頻繁ではなく、その信頼性に貢献しています。

• マルチシグブリッジ (Hyperlane/Wormhole): これらのシステムには、コントラクトのアップグレード、検証者セットの変更、パラメータの修正を行うための管理者またはガバナンスメカニズムがしばしば存在します。例えば、セットに新しい検証者を追加したり、キーをローテーションしたりするには、ブリッジの所有者のマルチシグや DAO の投票が必要になる場合があります。Hyperlane がパーミッションレスであるということは、どのユーザーもカスタム検証者セットを持つ独自の ISM をデプロイできることを意味しますが、デフォルトを使用する場合、Hyperlane チームまたはコミュニティが更新を管理する可能性が高いです。アップグレード可能性は諸刃の剣です。一方では、アップグレード/改善が容易であり、他方では、中央集権化のリスクになる可能性があります (特権キーがブリッジコントラクトをアップグレードできる場合、そのキーは理論的にブリッジをラグプルする可能性があります)。適切に統治されたプロトコルはこれを制限します (例：アップグレードにタイムロックを設ける、または分散型ガバナンスを使用する)。Hyperlane の哲学はモジュール性です。そのため、アプリは失敗したコンポーネントを ISM を切り替えることで回避することもできます。これにより、開発者は脅威に対応する力を持つことができます (例：ある検証者セットが侵害された疑いがある場合、アプリは迅速に別のセキュリティモデルに切り替えることができます)。ガバナンスのオーバーヘッドは、アプリがセキュリティモデルを決定し、独自の検証者のキーを管理したり、Hyperlane コアプロトコルからの更新に注意を払ったりする必要があることです。要約すると、マルチシグベースのシステムはよりアップグレード可能であり (コントラクトはしばしばアップグレード可能で、委員会は設定可能)、迅速な改善や新しいチェーンの追加に適していますが、ガバナンスプロセスへの信頼が必要です。過去の多くのブリッジの悪用は、侵害されたアップグレードキーや欠陥のあるガバナンスを介して発生しているため、この分野は慎重に扱う必要があります。プラス面として、新しいチェーンのサポートを追加することは、コントラクトをデプロイし、検証者にそのノードを実行させるだけで済む場合があり、根本的なプロトコルの変更は不要です。

• 証明集約 (LayerZero): LayerZero は不変のトランスポートレイヤー (エンドポイントコントラクトはアップグレード不可) を謳っていますが、検証モジュール (Message Libraries と DVN アダプター) は追記専用で設定可能です。実際には、これは各チェーンのコア LayerZero コントラクトが固定されたままで (安定したインターフェースを提供)、新しい DVN や検証オプションがコアを変更することなく時間とともに追加できることを意味します。アプリケーション開発者は自身のセキュリティスタックを制御できます。DVN を追加または削除したり、確認ブロックの深さを変更したりできます。これはアプリレベルでのアップグレード可能性の一形態です。例えば、特定の DVN が非推奨になったり、より良い新しい DVN (より高速な zk クライアントなど) が登場したりした場合、アプリチームはそれを設定に統合できます。これにより dApp を将来にわたって保証できます。利点は明らかです。アプリは過去のセキュリティ技術に縛られず、新しい開発に (適切な注意を払って) 適応できます。しかし、これはガバナンスの問題を提起します。アプリ内で誰が DVN セットの変更を決定するのか？ 理想的には、アプリが分散化されている場合、変更はガバナンスを通じて行われるか、不変性を望むならハードコードされるべきです。単一の管理者がセキュリティスタックを変更できる場合、それは信頼のポイントです (悪意のあるアップグレードでセキュリティ要件を低下させる可能性があります)。LayerZero 自身のガイダンスは、そのような変更に対して堅牢なガバナンスを設定するか、必要であれば特定の側面を不変にすることを奨励しています。もう 1 つのガバナンスの側面は手数料管理です。DVN とリレーヤーへの支払いは調整可能であり、インセンティブがずれるとパフォーマンスに影響を与える可能性があります (ただし、デフォルトでは市場の力によって手数料が調整されるはずです)。要約すると、LayerZero のモデルは新しい検証方法の追加に関して非常に拡張性が高くアップグレード可能であり (これは長期的な相互運用性にとって素晴らしいこと)、しかし、それらのアップグレードを責任を持って統治するのは各アプリケーションの責任です。LayerZero のベースコントラクトは、トランスポートレイヤーがラグプルされたり検閲されたりしないように不変であり、メッセージングパイプライン自体がアップグレードを通じて無傷で残るという信頼を呼び起こします。

比較を要約すると、以下の表は主要な違いを強調しています：

DeFi における構成可能性と共有流動性への影響​

クロスチェーンメッセージングは、構成可能性 (異なるチェーン上の DeFi コントラクトが相互作用する能力) のための強力な新しいパターンを解き放ち、共有流動性 (あたかも 1 つの市場であるかのようにチェーン間で資産をプールすること) を可能にします。上記で議論したセキュリティモデルは、プロトコルがどれだけ自信を持ってシームレスにクロスチェーン機能を利用できるかに影響を与えます。以下では、各アプローチがマルチチェーン DeFi をどのようにサポートするかを、実際の例とともに探ります：

• LayerZero を介したオムニチェーン DeFi (Stargate, Radiant, Tapioca): LayerZero の汎用メッセージングと Omnichain Fungible Token (OFT) 標準は、流動性のサイロを打ち破るために設計されています。例えば、Stargate Finance は LayerZero を使用して、ネイティブ資産ブリッジングのための統一された流動性プールを実装しています。各チェーンに断片化されたプールを持つのではなく、すべてのチェーン上の Stargate コントラクトが共通のプールを利用し、LayerZero メッセージがチェーン間のロック/リリースロジックを処理します。これにより、Stargate のブリッジでは月間 8 億ドル以上の取引高が生まれ、 значительная共有流動性が実証されました。LayerZero のセキュリティ (Stargate はおそらく堅牢な DVN セットを使用している) に依存することで、ユーザーはメッセージの信頼性に高い自信を持って資産を転送できます。Radiant Capital も別の例です。これは、ユーザーがあるチェーンで預金し、別のチェーンで借り入れができるクロスチェーンレンディングプロトコルです。LayerZero メッセージを活用して、チェーン間でアカウントの状態を調整し、事実上、複数のネットワークにまたがる 1 つのレンディング市場を作り出しています。同様に、Tapioca (オムニチェーンマネーマーケット) は LayerZero v2 を使用し、メッセージを保護するために独自の DVN を必須の検証者として実行しています。これらの例は、柔軟なセキュリティにより、LayerZero が信用調査、担保移動、清算といった複雑なクロスチェーン操作をサポートできることを示しています。構成可能性は、LayerZero の「OApp」標準 (Omnichain Application) から生まれます。これにより、開発者は同じコントラクトを多くのチェーンにデプロイし、メッセージングを介してそれらを連携させることができます。ユーザーはどのチェーンのインスタンスと対話しても、アプリケーションを 1 つの統一されたシステムとして体験します。セキュリティモデルは微調整が可能です。例えば、大規模な転送や清算にはより多くの DVN 署名を要求し (安全のため)、小規模なアクションはより速く/安価なパスを通過させることができます。この柔軟性により、セキュリティも UX も画一的である必要がなくなります。実際、LayerZero のモデルは共有流動性を大幅に向上させました。これは、数十のプロジェクトがトークンに OFT を採用していることからも明らかです (これにより、トークンは別々のラップされた資産としてではなく、「オムニチェーン」として存在できます)。例えば、ステーブルコインやガバナンストークンは OFT を使用して、すべてのチェーンにわたって単一の総供給量を維持できます。これにより、以前のラップトークンが悩まされていた流動性の断片化や裁定取引の問題を回避できます。全体として、信頼性の高いメッセージングレイヤーを提供し、アプリが信頼モデルを制御できるようにすることで、LayerZero は複数のチェーンを 1 つのエコシステムとして扱う新しいマルチチェーン DeFi 設計を触発しました。トレードオフは、ユーザーとプロジェクトが各オムニチェーンアプリの信頼の前提を理解しなければならないことです (それらは異なる可能性があるため)。しかし、OFT のような標準や広く使用されているデフォルトの DVN は、これをより均一にするのに役立ちます。

• IBC におけるインターチェーンアカウントとサービス (Cosmos DeFi): Cosmos の世界では、IBC はトークン転送を超える豊富なクロスチェーン機能を可能にしました。代表的な機能はインターチェーンアカウント (ICA) で、これによりブロックチェーン (またはチェーン A のユーザー) が、あたかもローカルであるかのようにチェーン B のアカウントを制御できます。これは、トランザクションを運ぶ IBC パケットを介して行われます。例えば、Cosmos Hub は Osmosis 上のインターチェーンアカウントを使用して、ユーザーに代わってトークンをステークまたはスワップできます。これらはすべて Hub から開始されます。具体的な DeFi のユースケースは、Stride のリキッドステーキングプロトコルです。Stride (チェーン) はユーザーから ATOM のようなトークンを受け取り、ICA を使用して、それらの ATOM を Cosmos Hub 上でリモートでステークし、stATOM (リキッドステークされた ATOM) をユーザーに発行します。全体のフローは信頼性がなく、IBC を介して自動化されています。Stride のモジュールは、Hub 上のアカウントを制御し、デリゲートおよびアンデリゲートトランザクションを実行し、確認とタイムアウトが安全性を保証します。これはクロスチェーンの構成可能性を示しています。2 つの主権チェーンが共同のワークフロー (ここでステークし、そこでトークンをミントする) をシームレスに実行します。別の例はOsmosis (DEX チェーン) で、IBC を使用して 95 以上の接続されたチェーンから資産を引き入れています。どのゾーンのユーザーも、IBC を介してトークンを送信することで Osmosis でスワップできます。IBC の高いセキュリティのおかげで、Osmosis などは IBC トークンを本物として自信を持って扱えます (信頼できるカストディアンは不要)。これにより、Osmosis は最大のインターチェーン DEX の 1 つとなり、日々の IBC 転送量は多くのブリッジシステムを上回ると報告されています。さらに、IBC 3.0 のインターチェーンクエリ (ICQ) により、あるチェーンのスマートコントラクトが、信頼最小化された方法で別のチェーンからデータ (価格、金利、ポジションなど) を取得できます。これにより、例えば、複数のゾーンの利回り率を照会し、それに応じて資産を再配分するインターチェーンイールドアグリゲーターが可能になります。これらはすべて IBC メッセージを介して行われます。IBC のライトクライアントモデルが構成可能性に与える主な影響は、信頼と中立性です。チェーンは主権を保ちながら、第三者のブリッジリスクを恐れることなく相互作用できます。Composable Finance や Polymer のようなプロジェクトは、IBC を非 Cosmos エコシステム (Polkadot, Ethereum) に拡張し、これらの機能を利用しようとしています。その結果、どのチェーンも IBC クライアント標準を採用すれば、「ブロックチェーンの普遍的なインターネット」に接続できる未来が訪れるかもしれません。Cosmos の共有流動性はすでに значительнаяです。例えば、Cosmos Hub のネイティブ DEX (Gravity DEX) などは、さまざまなゾーンから流動性をプールするために IBC に依存しています。しかし、これまでの制限は、Cosmos DeFi が主に非同期であることです。あるチェーンで開始し、結果はわずかな遅延 (数秒) を伴って別のチェーンで発生します。これは取引やステーキングのようなものには問題ありませんが、より複雑な同期的な構成可能性 (チェーン間のフラッシュローンなど) は、基本的な遅延のため範囲外です。それでも、IBC によって可能になるクロスチェーン DeFi の範囲は広いです。マルチチェーンイールドファーミング (利回りが最も高い場所に資金を移動)、クロスチェーンガバナンス (あるチェーンがガバナンスパケットを介して別のチェーンでアクションを実行するために投票)、さらにはインターチェーンセキュリティ (コンシューマーチェーンがプロバイダーチェーンの検証者セットを活用する) などです。要約すると、IBC の安全なチャネルは、Cosmos にインターチェーン経済を育みました。プロジェクトが別々のチェーンで専門化しながらも、信頼最小化されたメッセージを通じて流動的に連携できる経済です。共有流動性は、Osmosis への資産の流れや、ゾーン間を自由に移動する Cosmos ネイティブのステーブルコインの台頭などに明らかです。

• ハイブリッドおよびその他のマルチチェーンアプローチ (Hyperlane 以降): Hyperlane のパーミッションレスな接続性のビジョンは、資産をブリッジングするための Warp Routes や、さまざまなエコシステムにまたがるインターチェーン dapps といった概念につながりました。例えば、Warp Route は、Ethereum 上の ERC-20 トークンを Solana プログラムにテレポートさせることを可能にし、その裏では Hyperlane のメッセージレイヤーを使用します。具体的なユーザー向けの実装の 1 つは、Hyperlane の Nexus ブリッジで、Hyperlane のインフラを介して多くのチェーン間で資産を転送するための UI を提供します。モジュラーセキュリティモデルを使用することで、Hyperlane はルートごとにセキュリティを調整できます。小規模な転送は単純で高速なパス (Hyperlane 検証者の署名のみ) を通過するかもしれませんが、大規模な転送は集約された ISM (Hyperlane + Wormhole + Axelar のすべてが証明) を必要とする場合があります。これにより、高価値の流動性移動が複数のブリッジによって保護されることが保証されます。これにより、例えば 1000 万ドルの資産をクロスチェーンで移動する際の信頼性が高まります (それを盗むには複数のネットワークを侵害する必要があります) が、その代償として複雑性/手数料が高くなります。構成可能性の観点から、Hyperlane は彼らが**「コントラクトの相互運用性」と呼ぶものを可能にします。チェーン A のスマートコントラクトは、メッセージが配信されれば、あたかもローカルであるかのようにチェーン B の関数を呼び出すことができます。開発者は Hyperlane SDK を統合して、これらのクロスチェーンコールを簡単にディスパッチします。例としては、一部が Ethereum に、一部が BNB Chain に存在するクロスチェーン DEX アグリゲーターが、Hyperlane メッセージを使用して両者間で裁定取引を行うことが考えられます。Hyperlane は EVM および非 EVM チェーン (CosmWasm や MoveVM 統合の初期作業も含む) をサポートしているため、「あらゆるチェーン、あらゆる VM」を接続することを目指しています。この広範なリーチは、通常は簡単に接続できないエコシステムをブリッジングすることで、共有流動性を増加させることができます。しかし、大規模な DeFi における Hyperlane の実際の採用はまだ成長段階です。ブリッジングにおいて Wormhole や LayerZero のような取引量はまだありませんが、そのパーミッションレスな性質は実験を引きつけています。例えば、一部のプロジェクトは、独自の検証者セットを設定でき、複雑なライトクライアントソリューションを待つ必要がないため、アプリ固有のロールアップを Ethereum に迅速に接続するために Hyperlane を使用しています。リステーキング (EigenLayer) が成長するにつれて、Hyperlane はEthereum グレードのセキュリティをあらゆるロールアップに**比較的低い遅延で提供することで、より多くの採用を見るかもしれません。これにより、新しいマルチチェーンの構成が加速する可能性があります。例えば、Optimism ロールアップと Polygon zk-ロールアップが Hyperlane AVS を介してメッセージを交換し、各メッセージは不正であればスラッシュされる ETH によって裏付けられます。構成可能性への影響は、共有標準を持たないエコシステム (Ethereum と任意の L2 など) でさえ、両サイドが信頼するブリッジコントラクト (経済的に保護されているため) を得られることです。時間とともに、これにより、開発者が構成可能性を「ダイヤルイン」 (どのセキュリティモジュールをどのコールに使用するかを選択) できる、相互接続された DeFi アプリのウェブが生まれるかもしれません。

これらすべての場合において、セキュリティモデルと構成可能性の間の相互作用は明らかです。プロジェクトは、セキュリティが盤石である場合にのみ、大規模な流動性プールをクロスチェーンシステムに委託します。そのため、信頼最小化または経済的に保護された設計への推進力があります。同時に、統合の容易さ (開発者体験) と柔軟性は、チームが複数のチェーンを活用する上でどれだけ創造的になれるかに影響します。LayerZero と Hyperlane は開発者向けのシンプルさ (SDK をインポートし、使い慣れた送受信コールを使用するだけ) に焦点を当てていますが、より低レベルである IBC は、モジュールの理解をより多く必要とし、アプリケーション開発者ではなくチェーン開発者によって扱われるかもしれません。それにもかかわらず、3 つすべてが、ユーザーがどのチェーン上にいるかを知る必要なくマルチチェーン dApps と対話する未来に向かって進んでいます。アプリはどこからでもシームレスに流動性と機能を利用します。例えば、レンディングアプリのユーザーはチェーン A で預金し、借り入れがチェーン B のプールから行われたことにさえ気づかないかもしれません。すべてがクロスチェーンメッセージと適切な検証によってカバーされます。

実装、脅威モデル、および実際の採用状況​

これらのプロトコルが現実世界の状況でどのように機能しているか、つまり現在の実装、既知の脅威ベクトル、および採用レベルを評価することが重要です。

• 本番環境での LayerZero v2: LayerZero v1 (2 つのエンティティ、オラクル+リレーヤーモデル) は大きな採用を獲得し、2024 年半ばまでに 500 億ドル以上の転送量を確保し、1 億 3400 万件以上のクロスチェーンメッセージを処理しました。主に EVM チェーンですが、Aptos のような非 EVM チェーンを含む 60 以上のブロックチェーンと統合されており、Solana の実験的なサポートも視野に入っています。LayerZero v2 は 2024 年初頭にローンチされ、DVN とモジュラーセキュリティを導入しました。すでに、Radiant Capital、SushiXSwap、Stargate、PancakeSwap などの主要プラットフォームが、その柔軟性を活用するために v2 への移行または構築を開始しています。注目すべき統合の 1 つは、Flare Network (データに焦点を当てた Layer1) で、一度に 75 のチェーンと接続するために LayerZero v2 を採用しました。Flare は、セキュリティをカスタマイズできる能力に魅力を感じました。例えば、低価値のメッセージには単一の高速 DVN を使用し、高価値のメッセージには複数の DVN を要求するなどです。これは、本番環境では、アプリケーションが実際に「ミックスアンドマッチ」のセキュリティアプローチをセールスポイントとして使用していることを示しています。セキュリティと監査: LayerZero のコントラクトは不変であり、監査されています (v1 は複数の監査を受け、v2 も同様)。v1 の主な脅威はオラクルとリレーヤーの共謀でした。2 つのオフチェーンパーティが共謀すれば、メッセージを偽造できました。v2 では、その脅威はDVN の共謀に一般化されます。アプリが依存するすべての DVN が 1 つのエンティティによって侵害された場合、偽のメッセージがすり抜ける可能性があります。LayerZero の答えは、アプリ固有の DVN を奨励すること (攻撃者はアプリチームも侵害する必要があるため) と、検証者の多様性 (共謀を困難にするため) です。もう 1 つの潜在的な問題は、設定ミスやアップグレードの悪用です。アプリの所有者が悪意を持って些細なセキュリティスタック (自分たちが制御する 1-of-1 DVN など) に切り替えた場合、セキュリティをバイパスして自身のユーザーを悪用する可能性があります。これはプロトコルのバグというよりはガバナンスのリスクであり、コミュニティはオムニチェーンアプリのセキュリティがどのように設定されているかについて警戒を続ける必要があります (できればマルチシグやコミュニティの承認を要求する)。採用に関しては、LayerZero は現在、DeFi のメッセージングプロトコルの中で最も使用されていると言えるでしょう。**Stargate、Circle の CCTP 統合 (USDC 転送用)、Sushi のクロスチェーンスワップ、**多くの NFT ブリッジ、そして数え切れないほどの OFT トークン (プロジェクトがトークンを複数のチェーンで利用可能にするために LayerZero を選択) のブリッジングを支えています。ネットワーク効果は強力です。より多くのチェーンが LayerZero エンドポイントを統合するにつれて、新しいチェーンが「オムニチェーン」ネットワークに参加しやすくなります。LayerZero Labs 自体が 1 つの DVN を運営しており、コミュニティ (Google Cloud、zk プルーフ用の Polyhedra などのプロバイダーを含む) は 2024 年までに 15 以上の DVN を立ち上げています。現在までに LayerZero のコアプロトコルの大規模な悪用は発生しておらず、これは良い兆候です (ただし、他の技術と同様に、アプリケーションレベルのハッキングやユーザーエラーは発生しています)。トランスポートレイヤーをシンプルに保つ (本質的にメッセージを保存し、証明を要求するだけ) というプロトコルの設計は、オンチェーンの脆弱性を最小限に抑え、ほとんどの複雑さをオフチェーンの DVN に移しています。

• 本番環境での Hyperlane: Hyperlane (旧 Abacus) は、Ethereum、複数の L2 (Optimism、Arbitrum、zkSync など)、Cosmos-SDK モジュールを介した Osmosis のような Cosmos チェーン、さらには MoveVM チェーンなど、数多くのチェーンで稼働しています (サポート範囲は非常に広いです)。しかし、その採用は、取引量の点で LayerZero や Wormhole のような既存のプロトコルに遅れをとっています。Hyperlane はしばしば**「主権ブリッジ」ソリューションの文脈で言及されます。つまり、プロジェクトは Hyperlane をデプロイして、カスタムセキュリティを持つ独自のブリッジを持つことができます。例えば、一部の appchain チームは、共有ブリッジに依存せずに自分たちのチェーンを Ethereum に接続するために Hyperlane を使用しています。注目すべき開発は、2024 年半ばにローンチされたHyperlane Active Validation Service (AVS)** で、これは Ethereum リステーキングの最初のアプリケーションの 1 つです。検証者 (多くはトップの EigenLayer オペレーター) が ETH をリステークして Hyperlane メッセージを保護し、当初は高速なクロスロールアップメッセージングに焦点を当てています。これは現在、Ethereum L2 ロールアップ間の相互運用性を良好な結果で確保しており、本質的に Ethereum に結びついた経済的セキュリティを備えた、ほぼ瞬時のメッセージパッシング (オプティミスティックロールアップの 7 日間の待機期間よりも速い) を提供しています。脅威モデルに関しては、Hyperlane の元のマルチシグアプローチは、十分な数の検証者のキーが侵害されれば攻撃される可能性があります (他のマルチシグブリッジと同様)。Hyperlane は過去にセキュリティインシデントがありました。2022 年 8 月、初期のテストネットまたはローンチ中に、攻撃者が 1 つのチェーン上の Hyperlane トークンブリッジのデプロイヤーキーをハイジャックし、トークンをミントできたという悪用がありました (約 70 万ドルの損失)。これはマルチシグ自体の失敗ではなく、デプロイメント周りの運用セキュリティの問題であり、アップグレード可能性とキー管理のリスクを浮き彫りにしました。チームは損失を補償し、プロセスを改善しました。これは、ガバナンスキーが脅威モデルの一部であることを強調しています。管理コントロールを保護することは、検証者を保護することと同じくらい重要です。AVS では、脅威モデルは EigenLayer の文脈に移行します。誰かが誤ったスラッシングを引き起こしたり、不正行為にもかかわらずスラッシュを回避できたりすれば問題になりますが、EigenLayer のプロトコルは Ethereum 上でスラッシングロジックを処理しており、これは正しい不正証明の提出を前提とすれば堅牢です。Hyperlane の現在の採用は、ロールアップスペースや一部のアプリ固有のチェーンで増加しています。まだ競合他社のような数十億ドル規模の流れを処理しているわけではありませんが、開発者が完全な制御と簡単な拡張性を求めるニッチを切り開いています。モジュラー ISM 設計は、創造的なセキュリティ設定が見られる可能性を意味します。例えば、DAO は Hyperlane の署名だけでなく、タイムロックや 2 番目のブリッジ署名を管理メッセージに要求するなどです。Hyperlane のパーミッションレスな精神 (誰でも検証者を実行したり、新しいチェーンにデプロイしたりできる) は、長期的には強力であることが証明されるかもしれませんが、エコシステムが成熟する必要があることも意味します (例：デフォルトセットを分散化するために、より多くのサードパーティ検証者が参加するなど。2025 年現在、アクティブな検証者セットが実際にどれだけ分散化されているかは不明です)。全体として、Hyperlane の軌道は、セキュリティの向上 (リステーキングによる) と使いやすさの向上ですが、IBC や LayerZero と同レベルのコミュニティの信頼を得るには、回復力を示し、主要な流動性を引き付ける必要があります。

• 本番環境での IBC 3.0 と Cosmos Interop: IBC は 2021 年から稼働しており、Cosmos 内で非常に実戦テストされています。2025 年までに、115 以上のゾーン (Cosmos Hub、Osmosis、Juno、Cronos、Axelar、Kujira などを含む) を接続し、月間数百万のトランザクションと数十億ドル規模のトークンフローを処理しています。驚くべきことに、プロトコルレベルでの大規模なセキュリティ障害は一度もありません。注目すべき IBC 関連のインシデントが 1 つありました。2022 年 10 月、IBC コード (すべての v2.0 実装に影響) に重大な脆弱性が発見され、攻撃者が多くの IBC 接続チェーンから価値を流出させる可能性がありました。しかし、それは公に開示される前に協調的なアップグレードを通じて秘密裏に修正され、悪用は発生しませんでした。これは、形式的に検証されたプロトコルでさえバグを持つ可能性があるという警鐘でした。それ以来、IBC はさらなる監査と強化を受けています。IBC の脅威モデルは主にチェーンのセキュリティに関するものです。接続されたチェーンの 1 つが敵対的であるか、51% 攻撃を受けた場合、相手のライトクライアントに無効なデータを送ろうとする可能性があります。緩和策には、安全でないチェーンへの接続を停止または閉鎖するためにガバナンスを使用することが含まれます (例えば、Cosmos Hub のガバナンスは、壊れていると検出された特定のチェーンのクライアント更新をオフにすることを投票できます)。また、IBC クライアントはしばしばアンボンディング期間や信頼期間の調整を持っています。例えば、Tendermint ライトクライアントは、アンボンディング期間より古い検証者セットの更新を受け入れません (長距離攻撃を防ぐため)。もう 1 つの考えられる問題はリレーヤーの検閲です。リレーヤーがパケットを配信しない場合、資金がタイムアウトでスタックする可能性がありますが、リレーイングはパーミッションレスでしばしばインセンティブが与えられているため、これは通常一時的なものです。IBC 3.0 のインターチェーンクエリと新機能が展開されるにつれて、クロスチェーン DeX アグリゲーター (例：Skip Protocol が ICQ を使用してチェーン間で価格データを収集) やクロスチェーンガバナンス (例：Cosmos Hub がインターチェーンアカウントを使用してコンシューマーチェーンである Neutron を管理) などでの採用が見られます。Cosmos を超えた採用も物語です。Polymer や Astria (ロールアップのための相互運用ハブ) のようなプロジェクトは、ハブ/スポークモデルを介して事実上 IBC を Ethereum ロールアップに持ち込んでおり、Polkadot のパラチェーンは IBC を使用して Cosmos チェーンと正常に接続しています (例：Composable Finance が構築した Cosmos と Polkadot 間の Centauri ブリッジは、Cosmos 側で GRANDPA ライトクライアントを使用して IBC を内部で使用しています)。Polymer と DataChain によって進行中の IBC-Solidity 実装さえあり、これにより Ethereum スマートコントラクトが IBC パケットを検証できるようになります (ライトクライアントまたは有効性証明を使用)。これらの取り組みが成功すれば、IBC の使用は Cosmos を超えて劇的に広がり、その信頼最小化モデルがそれらのチェーンのより中央集権的なブリッジと直接競合することになるでしょう。共有流動性の観点から、Cosmos の最大の制限は、Ethereum に匹敵するネイティブステーブルコインや深い流動性を持つ DEX がないことでした。それは、Cosmos ネイティブのステーブルコイン (IST、CMST など) の台頭と、USDC のような資産の接続 (Axelar と Gravity ブリッジが USDC をもたらし、現在 Circle は Noble を介して Cosmos でネイティブ USDC をローンチ) によって変化しています。流動性が深まるにつれて、高いセキュリティとシームレスな IBC 転送の組み合わせは、Cosmos をマルチチェーン DeFi 取引の結節点にする可能性があります。実際、Blockchain Capital のレポートは、IBC が 2024 年初頭までにすでに LayerZero や Wormhole よりも多くの取引量を処理していたと指摘していますが、それは主に Cosmos 間のトラフィックの強さによるものです (これは非常に活発なインターチェーン経済を示唆しています)。今後、IBC の主な課題と機会は、そのセキュリティ精神を犠牲にすることなく異種のチェーンに拡大することです。

要約すると、各プロトコルは進化しています：LayerZero は多くのチェーンやアプリケーションと迅速に統合し、柔軟性と開発者の採用を優先し、アプリが自身のセキュリティの一部となることを可能にすることでリスクを軽減しています。Hyperlane はリステーキングとモジュール性で革新し、設定可能なセキュリティで新しいチェーンを接続する最も簡単な方法を目指していますが、まだ信頼と使用を構築中です。IBC はそのドメイン内での信頼性のゴールドスタンダードであり、現在はより高速に (IBC 3.0)、そして Cosmos を超えてそのドメインを拡張することを望んでおり、強力な実績に支えられています。ユーザーとプロジェクトは、それぞれの成熟度とセキュリティインシデントを考慮するのが賢明です。IBC は長年の安定した運用 (と膨大な取引量) を持っていますが、特定のエコシステムに限定されています。LayerZero は急速に使用を集めていますが、カスタムセキュリティ設定の理解が必要です。Hyperlane は実行面では新しいですが、ビジョンは有望で、経済的セキュリティに向けて慎重な一歩を踏み出しています。

結論と展望：マルチチェーンの未来のための相互運用性アーキテクチャ​

マルチチェーン DeFi ランドスケープの長期的な存続可能性と相互運用性は、おそらく3 つすべてのセキュリティモデルが共存し、さらには相互に補完し合うことによって形作られるでしょう。各アプローチには明確な強みがあり、画一的な解決策ではなく、ライトクライアントモデル (IBC) が主要なルート (特に主要チェーン間) で最高の保証を提供し、証明集約システム (LayerZero) がカスタマイズ可能な信頼で普遍的な接続性を提供し、マルチシグモデル (Hyperlane など) がニッチなニーズに応えたり、新しいエコシステムを迅速に立ち上げたりするスタックが見られるかもしれません。

セキュリティ vs 接続性のトレードオフ: IBC のようなライトクライアントは、「ブロックチェーンインターネット」に最も近いものを提供します。これは、TCP/IP に似た中立で標準化されたトランスポートレイヤーです。これらは、相互運用性が新たな弱点を導入しないことを保証し、これは長期的な持続可能性にとって重要です。しかし、これらは標準に関する広範な合意と、チェーンごとの значительнаяなエンジニアリングを必要とし、新しい接続が形成される速度を遅くします。一方、LayerZero と Hyperlane は、即時の接続性と柔軟性を優先し、すべてのチェーンが同じプロトコルを実装するわけではないことを認識しています。たとえそれが一時的にもう少し信頼を受け入れることを意味するとしても、「any to any」を接続することを目指しています。時間とともに、そのギャップは狭まると予想されます。LayerZero はより信頼最小化された DVN を組み込むことができ (IBC 自体も DVN にラップできるかもしれません)、Hyperlane は経済的なメカニズムを使用してネイティブ検証のセキュリティに近づくことができます。実際、Polymer プロジェクトは、IBC と LayerZero は競合相手である必要はなく、階層化できると考えています。例えば、LayerZero は利用可能な場合に IBC ライトクライアントを DVN の 1 つとして使用できます。このような相互作用は、この分野が成熟するにつれて起こりそうです。

構成可能性と統一された流動性: DeFi ユーザーの視点から見ると、最終的な目標は流動性がチェーンに依存しなくなることです。私たちはすでにその一歩を踏み出しています。オムニチェーントークン (OFT) を使えば、自分のトークンバージョンがどのチェーンにあるかを心配する必要はなく、クロスチェーンマネーマーケットを使えば、別のチェーンの担保に対してどのチェーンでも借り入れができます。アーキテクチャの選択は、これらのシステムに対するユーザーの信頼に直接影響します。ブリッジのハッキングが発生した場合 (歴史的に一部のマルチシグブリッジで起こったように)、それは信頼を破壊し、したがって流動性も破壊します。ユーザーはより安全な場所に後退するか、リスクプレミアムを要求します。したがって、一貫してセキュリティを実証するプロトコルが、最大の流動性プールを支えることになります。Cosmos のインターチェーンセキュリティと IBC は 1 つの道を示しました。ゾーン間の複数のオーダーブックと AMM は、転送が信頼性がなく迅速であるため、本質的に 1 つの大きな市場に構成されます。LayerZero の Stargate は別の道を示しました。統一された流動性プールが多くのチェーンの転送に対応できますが、ユーザーは LayerZero のセキュリティの前提 (オラクル+リレーヤーまたは DVN) を信頼する必要がありました。LayerZero v2 が各プールにさらに高いセキュリティを設定できるようにするにつれて (例：すべての転送を検証するために複数の大手検証者ネットワークを使用)、信頼のギャップを縮めています。マルチチェーン DeFi の長期的な存続可能性は、おそらく相互運用性プロトコルが見えなくても信頼できることにかかっています。インターネットユーザーが TCP/IP について考えないように、暗号ユーザーは dApp がどのブリッジやメッセージングシステムを使用しているかを心配する必要はありません。それは、セキュリティモデルが十分に堅牢で、障害が非常にまれであり、これらの相互運用性ネットワーク間に何らかの収束または構成可能性がある場合に起こります。

相互運用性の相互運用性: 数年後には、LayerZero vs Hyperlane vs IBC を別々の領域として話すのではなく、階層化されたシステムとして話すことが考えられます。例えば、Ethereum ロールアップは Polymer を介して Cosmos ハブへの IBC 接続を持つことができ、その Cosmos ハブは LayerZero エンドポイントも持つかもしれません。これにより、メッセージは安全な IBC チャネルを通じてロールアップから LayerZero のネットワークに転送できます。Hyperlane はフォールバックまたは集約として機能することさえできます。アプリは、究極の保証のために IBC 証明と Hyperlane AVS 署名の両方を要求できます。このようなプロトコル間のセキュリティの集約は、最も高度な脅威モデルにさえ対処できる可能性があります (IBC ライトクライアント と 独立したリステークされたマルチシグなどを同時に破壊することははるかに困難です)。もちろん、そのような組み合わせは複雑さとコストを追加するため、高価値のコンテキストに限定されるでしょう。

ガバナンスと分散化: 各モデルは、異なるアクターに異なる権限を与えます。IBC はチェーンのガバナンスの手に、LayerZero はアプリ開発者の手に (そして間接的に、彼らが選択する DVN オペレーターの手に)、Hyperlane はブリッジ検証者とおそらくリステーカーの手に権限を置きます。長期的な相互運用可能なランドスケープは、単一の当事者またはカルテルがクロスチェーントランザクションを支配できないことを保証する必要があります。これは、例えば、1 つのプロトコルがユビキタスになるが、少数のアクターによって制御されている場合のリスクです。それはチョークポイントになる可能性があります (中央集権的なインターネットサービスプロバイダーに類似)。それを軽減する方法は、メッセージングネットワーク自体を分散化すること (より多くのリレーヤー、より多くの DVN、より多くの検証者 – すべてがパーミッションレスで参加できる) と、代替パスを持つことです。この点では、IBC は多くの独立したチームを持つオープンスタンダードであるという利点があり、LayerZero と Hyperlane は両方ともサードパーティの参加を増やす方向に動いています (例：誰でも LayerZero DVN や Hyperlane 検証者を実行できる)。競争とオープンな参加がこれらのサービスを正直に保つ可能性が高いです。L1 のマイナー/検証者がベースレイヤーを分散化させているのと同じように。市場も足で投票します。1 つのソリューションが安全でない、または中央集権的すぎることが証明されれば、開発者は別のソリューションに移行できます (特にブリッジング標準がより相互運用可能になるにつれて)。

結論として、LayerZero v2、Hyperlane、および IBC 3.0 のセキュリティアーキテクチャは、それぞれ異なる哲学を持ちながら、マルチチェーン DeFi のビジョンを現実のものにすることに貢献しています。ライトクライアントは信頼性と中立性を優先し、マルチシグは実用性と統合の容易さを優先し、集約アプローチはカスタマイズと適応性を優先します。未来のマルチチェーン DeFi ランドスケープは、おそらくこれらの組み合わせを使用するでしょう。重要なインフラと高価値の転送は、信頼最小化または経済的に保護された方法で保護され、柔軟なミドルウェアが新しいチェーンやアプリのロングテールに接続します。これらが整備されれば、ユーザーは単一のチェーンを使用するのと同じ信頼と容易さで、統一された流動性とクロスチェーンの構成可能性を享受できるでしょう。前進する道は収束の道です。必ずしもプロトコル自体の収束ではなく、結果の収束です。相互運用性が安全で、シームレスで、標準である世界です。それを達成するには、継続的な厳格なエンジニアリング (悪用を避けるため)、協調的なガバナンス (IBC や普遍的なコントラクトインターフェースのような標準を設定するため)、そしておそらく最も重要なこととして、数学、経済的インセンティブ、インテリジェントな設計の最良の部分を融合させた、セキュリティへの反復的なアプローチが必要です。最終状態は、しばしば引用されるアナロジーを真に満たすかもしれません。インターネット上のネットワークのように相互接続されたブロックチェーン、そして LayerZero、Hyperlane、IBC のようなプロトコルが、DeFi が当面の間乗り続けるオムニチェーンハイウェイを形成するのです。

出典:

• LayerZero v2 アーキテクチャと DVN セキュリティ – LayerZero V2 Deep Dive; Flare x LayerZero V2 announcement
• Hyperlane マルチシグとモジュラー ISM – Hyperlane Docs: Validators; Tiger Research on Hyperlane; Hyperlane restaking (AVS) announcement
• IBC 3.0 ライトクライアントと機能 – IBC Protocol Overview; 3Commas Cosmos 2025 (IBC 3.0)
• 信頼の前提の比較 – Nosleepjohn (Hyperlane) on bridge tradeoffs; IBC vs bridges (Polymer blog)
• DeFi の例 (Stargate, ICA など) – Flare blog on LayerZero (Stargate volume); IBC use cases (Stride liquid staking); LayerZero Medium (OFT and OApp standards); Hyperlane use cases
• 採用と統計 – Flare x LayerZero (cross-chain messages, volume); Range.org on IBC volume; Blockchain Capital on IBC vs bridges; LayerZero blog (15+ DVNs); IBC testimonials (Osmosis, etc.).

暗号を送るとき、あなたのルーティンは何ですか？ 多くの人は、取引履歴から受取人のアドレスをコピーすることです。 結局、0x1A2b...8f9E のような 40 文字の文字列を暗記できる人はいません。 これは誰もが使う便利なショートカットです。

しかし、その便利さが綿密に仕掛けられた罠だったらどうでしょうか？

ブロックチェーンアドレス汚染 と呼ばれる破壊的に効果的な詐欺が、まさにこの習慣を悪用しています。 カーネギーメロン大学の最新研究によると、この脅威は驚異的な規模に達しています。 たった 2 年間で、Ethereum と Binance Smart Chain（BSC）ネットワークだけで、詐欺師は 2.7 億件以上の攻撃試行 を行い、1,700 万人の被害者 を狙い、少なくとも 8,380 万ドル を盗み出しています。

これはニッチな脅威ではなく、現在稼働している最大かつ最も成功した暗号フィッシングスキームの一つです。 仕組みと、資産を守るためにできることをご紹介します。

詐欺の仕組み 🤔​

アドレス汚染は視覚的トリックのゲームです。 攻撃者の戦略はシンプルながら巧妙です。

1. 類似アドレスの生成
   攻撃者は、あなたが頻繁に送金するアドレスを特定し、強力なコンピュータで 先頭と末尾の文字が全く同じ 新しい暗号アドレスを生成します。 多くのウォレットやブロックエクスプローラはアドレスを短縮表示する（例：0x1A2b...8f9E）ため、偽アドレスは一目で本物と見分けがつきません。

2. 取引履歴への「汚染」
   次に、攻撃者はその類似アドレスをあなたのウォレット履歴に入れます。 これは「汚染」トランザクションを送ることで実現します。 方法は以下のいずれかです。

   • ごく小額の送金：偽アドレスから極小額（例：$0.001）を送金し、あなたの最近の取引リストに表示させます。
   • ゼロ価値転送：多くのトークンコントラクトに備わっている機能を悪用し、偽のゼロドル転送を作成します。 これにより、偽アドレスが「あなた」から送られたように見え、信頼性が増します。
   • 偽トークン転送：価値のない偽トークン（例：USDTT）を作成し、過去の実際の取引額に似せた転送を偽アドレスへ行います。

3. ミスを待つ
   罠は完成です。 次に正当な相手に支払う際、取引履歴を確認し、正しいと思われるアドレスをコピーして送金します。 ミスに気付いた時には資金は既に消えており、ブロックチェーンは不可逆的なので銀行に電話しても取り戻すことはできません。

犯罪組織の実態 🕵️‍♂️​

これは単独ハッカーの仕業ではありません。 研究は、これらの攻撃が大規模で組織化された、極めて利益率の高い犯罪集団によって実行されていることを示しています。

標的プロファイル​

攻撃者は小口アカウントに時間を浪費しません。 以下の条件を満たすユーザーを体系的に狙います。

• 資産が豊富：ステーブルコインの残高が多い。
• 取引が活発：頻繁に送金を行う。
• 高額トランザクション：大きな金額を移動させる。

ハードウェアの軍拡競争​

類似アドレスの生成は総当たり計算タスクです。 マッチさせる文字数が増えるほど指数関数的に難易度が上がります。 多くの攻撃者は標準的な CPU で「ほどほどに」偽アドレスを作りますが、最も高度な犯罪集団はさらに一歩進んでいます。

このトップティアの集団は、ターゲットアドレスの 20 文字 まで一致させた偽アドレスを生成しています。 標準的なコンピュータではほぼ不可能であり、研究者は GPU ファーム を使用していると結論付けました。 つまり、高性能ゲームや AI 研究で使われるような大規模な GPU クラスタを投入しているのです。 巨額の投資を行い、被害者から容易に回収しているため、ビジネスとして急成長しています。

資金を守る方法 🛡️​

脅威は高度ですが、防御策はシンプルです。 悪習慣を断ち、注意深いマインドセットを取り入れることが鍵です。

1. 全ユーザーへの必須対策（最重要）

   • アドレス全体を確認する：Confirm をクリックする前に、5 秒余分に時間を取り、アドレス全体を文字ごとに目視で確認してください。 先頭と末尾だけを見るのはやめましょう。
   • アドレス帳を活用する：信頼できるアドレスをウォレットのアドレス帳や連絡先リストに保存し、送金時は必ずこの保存済みリストから選択してください。 動的な取引履歴から選ばないように。
   • テスト送金を行う：大口や重要な支払いの場合、まずごく小額を送金し、受取人が受領したことを確認してから本送金してください。

2. ウォレット開発者への提案

   • ユーザーインターフェースを改善し、デフォルトでアドレスの表示文字数を増やす、または「ごく小額・ゼロ価値の取引しか行っていないアドレスへの送金」時に強力な警告を出す機能を追加してください。

3. 長期的解決策

   • Ethereum Name Service（ENS） のように、人間が読める名前（例：yourname.eth）をアドレスにマッピングできるシステムは、この問題を根本的に解消します。 広範な採用が鍵です。

分散型の世界では、あなたが自分自身の銀行であり、同時に自分自身のセキュリティ責任者でもあります。 アドレス汚染は便利さと不注意を狙う静かな脅威です。 意識的に二重チェックを行うことで、あなたの努力で得た資産が詐欺師の罠にかかることを防げます。

ブロックチェーン技術、特に Ethereum が提供する主な約束のひとつは、ある程度の匿名性です。バリデータと呼ばれる参加者は、暗号的な仮名の背後で活動し、現実世界の身元とそれに伴うセキュリティを保護するとされています。

しかし、ETH Zurich などの研究者が執筆した最近の論文「Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue」では、この前提に致命的な欠陥があることが示されました。彼らは、バリデータの公開識別子と実行マシンの IP アドレスを直接結びつける、シンプルかつ低コストな手法を実証しています。

要するに、Ethereum バリデータは多くの人が考えるほど匿名ではありませんでした。この発見は Ethereum Foundation からバグ賞金を受け取るほどの重要性が認められました。

脆弱性の仕組み：ゴシップの欠陥​

脆弱性を理解するには、まず Ethereum バリデータがどのように通信しているかを簡単に把握する必要があります。ネットワークは 100 万を超えるバリデータで構成され、彼らは常にチェーンの状態に「投票」しています。この投票は アテステーション と呼ばれ、ピアツーピア（$P2P$）ネットワークを通じて全ノードにブロードキャストされます。

バリデータが多数いるため、全員が全投票を全員に送信するとネットワークは瞬時に飽和してしまいます。そこで Ethereum の設計者は賢いスケーリング手法を導入しました。ネットワークは 64 個の独立した通信チャネル、すなわち サブネット に分割されています。

• デフォルトでは、各ノード（バリデータソフトウェアを実行するコンピュータ）は 64 個のサブネットのうち 2 つ のみを購読します。ノードの主な役割は、その 2 つのチャネル上のすべてのメッセージを忠実に中継することです。
• バリデータが投票を行う際、アテステーションはランダムに 64 個のサブネットのいずれかに割り当てられてブロードキャストされます。

ここに脆弱性があります。 たとえば、チャネル 12 と 13 のトラフィック管理を担当しているノードが、突然チャネル 45 のメッセージを送ってきたとします。

これは強力な手がかりです。なぜそのノードが自分の担当外のチャネルのメッセージを処理するのか？ 最も論理的な結論は そのノード自体がメッセージを生成した ということです。つまり、チャネル 45 のアテステーションを作成したバリデータは、まさにそのマシン上で動作していると推測できます。

研究者はこの原理をそのまま利用しました。自前のリスニングノードを設置し、ピアがどのサブネットからアテステーションを送ってくるかを監視したのです。ピアが公式に購読していないサブネットからメッセージを送ったとき、高い確信を持ってそのピアが元のバリデータをホストしていると推測できました。

この手法は驚くほど効果的でした。4 台のノードを 3 日間稼働させるだけで、チームは 161,000 を超えるバリデータ の IP アドレスを特定し、全 Ethereum ネットワークの 15% 以上 を露出させました。

なぜ重要か：匿名性除去のリスク​

バリデータの IP アドレスが公開されることは決して軽視できません。個々のオペレーターだけでなく、Ethereum ネットワーク全体の健全性を脅かす標的型攻撃の入口となります。

1. 標的型攻撃と報酬の盗難
Ethereum は次にブロックを提案するバリデータを数分前に公表します。このバリデータの IP アドレスが分かれば、攻撃者は DDoS 攻撃 を仕掛け、トラフィックで埋め尽くしてオフラインにできます。バリデータが 4 秒間の提案ウィンドウを逃すと、次のバリデータに権利が移ります。もし攻撃者がその次のバリデータであれば、被害者が本来得るべきブロック報酬や取引手数料（MEV）を奪取できます。

2. ネットワークのライブネスと安全性への脅威
資金力のある攻撃者はこの「スナイプ」攻撃を繰り返し、ブロックチェーン全体を遅延させたり停止させたりする ライブネス攻撃 を実行できます。さらに深刻なシナリオでは、取得した情報を用いてネットワーク分断攻撃を仕掛け、チェーン履歴に対する合意が崩れ、安全性攻撃 が成立する恐れがあります。

3. 中央集権的現実の露呈
研究はネットワークの分散性に関する不快な真実も明らかにしました：

• 極端な集中：ある IP アドレスが 19,000 台以上 のバリデータをホストしているケースが発見されました。単一マシンの障害がネットワーク全体に過大な影響を与える可能性があります。
• クラウド依存：特定されたバリデータの 90% が AWS や Hetzner といったクラウドプロバイダー上で稼働しており、個人のホームステーカーではありません。これは重要な集中点です。
• 隠れた依存関係：大手ステーキングプールは独立した運営と主張しますが、研究では競合プールのバリデータが 同一物理マシン 上で動作している事例が見つかり、見えないシステムリスクが潜んでいることが判明しました。

対策：バリデータはどう守るべきか？​

幸いなことに、この匿名性除去手法に対抗する方法はいくつか存在します。研究者は以下の緩和策を提案しています：

• ノイズを増やす：バリデータは 2 つ以上、場合によっては全 64 のサブネットを購読できます。これにより、観測者が中継メッセージと自生成メッセージを区別しにくくなります。
• 複数ノードの活用：オペレーターはバリデータの役割を異なる IP を持つ複数マシンに分散させられます。たとえば、1 台のノードでアテステーションを処理し、別のプライベートノードだけで高価値ブロックの提案を行う、といった構成です。
• プライベートピアリング：バリデータは信頼できる仲間ノードとプライベート接続を確立し、メッセージをリレーさせることで、真の送信元を小さな信頼グループ内に隠すことができます。
• 匿名ブロードキャストプロトコル：Dandelion のように、メッセージをランダムな「ステム」経路で伝搬させてから広範にブロードキャストする手法を導入すれば、送信元特定をさらに困難にできます。

結論​

この研究は、分散システムにおけるパフォーマンスとプライバシーのトレードオフを鮮明に示しています。スケーラビリティを追求した結果、Ethereum の $P2P$ ネットワークは最も重要な参加者の匿名性を犠牲にした設計となっていました。

脆弱性を公にしたことで、研究者は Ethereum コミュニティに対し、問題解決に必要な知識とツールを提供しました。彼らの取り組みは、将来に向けてより堅牢で安全、そして真に分散化されたネットワークを構築するための重要な一歩です。

シリコンバレーのスタートアップでは、Docker Compose はコンテナ化アプリケーションを迅速にデプロイ・管理するための好まれるツールの一つです。しかし、利便性にはしばしばセキュリティリスクが伴います。Site Reliability Engineer（SRE）として、セキュリティ脆弱性が壊滅的な結果を招くことを痛感しています。本記事では、Docker Compose と Ubuntu を組み合わせた実務でまとめたベストなセキュリティ実践を共有し、Docker Compose の便利さを享受しつつシステムの安全性を確保する方法をご紹介します。

I. Ubuntu システムのセキュリティ強化​

コンテナをデプロイする前に、Ubuntu ホスト自体のセキュリティを確保することが重要です。主な手順は以下の通りです。

1. Ubuntu と Docker を定期的にアップデート​

システムと Docker の両方を最新の状態に保ち、既知の脆弱性を修正します。

sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin

2. Docker 管理権限を制限​

Docker の管理権限を厳格にコントロールし、特権昇格攻撃を防止します。

sudo usermod -aG docker deployuser
# 一般ユーザーが簡単に Docker 管理権限を取得できないようにする

3. Ubuntu ファイアウォール (UFW) を設定​

ネットワークアクセスを適切に制限し、不正アクセスを防止します。

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

4. Docker と UFW の連携を適切に設定​

デフォルトでは Docker が iptables を直接操作し、UFW をバイパスします。手動で制御することを推奨します。

Docker 設定ファイルを編集します。

sudo nano /etc/docker/daemon.json

以下の内容を追加します。

{
  "iptables": false,
  "ip-forward": true,
  "userland-proxy": false
}

Docker サービスを再起動します。

sudo systemctl restart docker

Docker Compose でアドレスを明示的にバインドします。

services:
  webapp:
    ports:
      - "127.0.0.1:8080:8080"

II. Docker Compose のセキュリティベストプラクティス​

以下の設定は Docker Compose v2.4 以降を対象としています。Swarm モードと非 Swarm モードの違いに注意してください。

1. コンテナ権限を制限​

デフォルトで root で実行されるコンテナはリスクが高いため、非 root ユーザーに変更します。

services:
  app:
    image: your-app:v1.2.3
    user: "1000:1000" # 非 root ユーザー
    read_only: true # 読み取り専用ファイルシステム
    volumes:
      - /tmp/app:/tmp # 書き込みが必要なディレクトリだけマウント
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

解説

• 読み取り専用ファイルシステムはコンテナ内部での改ざんを防止します。
• マウントするボリュームは必要最小限に留めます。

2. ネットワーク分離とポート管理​

内部ネットワークと外部ネットワークを明確に分離し、機密サービスが外部に露出しないようにします。

networks:
  frontend:
    internal: false
  backend:
    internal: true

services:
  nginx:
    networks: [frontend, backend]
  database:
    networks:
      - backend

• frontend ネットワーク: 公開可。
• backend ネットワーク: 完全に内部限定。

3. シークレット管理の安全化​

機密情報は Compose ファイルに直接記載しないでください。

単一マシンモードの場合:

services:
  webapp:
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    volumes:
      - ./secrets/db_password.txt:/run/secrets/db_password:ro

Swarm モードの場合:

services:
  webapp:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true # Swarm の組み込みシークレット管理を利用

注意

• Docker Swarm のネイティブシークレットは Vault や AWS Secrets Manager など外部ツールを直接利用できません。外部シークレットストレージが必要な場合は、読み取り処理を自前で組み込む必要があります。

4. リソース制限（Compose バージョンに合わせて）​

コンテナがホストリソースを使い果たすのを防ぎます。

単一マシンモード（推奨 v2.4）:

version: "2.4"

services:
  api:
    image: your-image:1.4.0
    mem_limit: 512m
    cpus: 0.5

Swarm モード（v3 以上）:

services:
  api:
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M

注記: 非 Swarm 環境では deploy セクションのリソース制限は 無効 です。Compose ファイルのバージョンに注意してください。

5. コンテナヘルスチェック​

ヘルスチェックを設定し、問題を早期に検知してサービス停止時間を短縮します。

services:
  webapp:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

6. latest タグの使用を避ける​

本番環境で latest タグを使用するとバージョン管理が曖昧になります。明示的にイメージバージョンを指定してください。

services:
  api:
    image: your-image:1.4.0

7. ログ管理の適切化​

コンテナログがディスク容量を圧迫しないように制限します。

services:
  web:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

8. Ubuntu の AppArmor 設定​

Ubuntu ではデフォルトで AppArmor が有効化されています。Docker のプロファイル状態を確認しましょう。

sudo systemctl enable --now apparmor
sudo aa-status

Ubuntu 上の Docker はデフォルトで AppArmor を有効にしますが、同時に SELinux を有効化すると競合するため推奨されません。

9. 継続的なアップデートとセキュリティスキャン​

• イメージ脆弱性スキャン: CI/CD パイプラインに Trivy、Clair、Snyk などを組み込みます。

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image your-image:v1.2.3

• 自動セキュリティアップデート: 既知の脆弱性を修正するため、少なくとも週に一度はイメージをリビルドします。

III. ケーススタディ：Docker Compose 設定ミスから得た教訓​

2019 年 7 月、Capital One は 1 億人以上の顧客情報が流出する大規模なデータ侵害を受けました12。主因は AWS 設定ミスでしたが、同時にコンテナのセキュリティ問題も関与していました。

1. コンテナ権限の問題: 攻撃者は過剰な権限を持つ WAF コンテナの脆弱性を突きました。
2. ネットワーク分離の不備: 侵害されたコンテナから他の AWS リソースへアクセスでき、ネットワーク分離が不十分でした。
3. 機密データの露出: 設定ミスにより大量の顧客データが取得可能になっていました。
4. セキュリティ設定ミスの蓄積: コンテナとクラウドサービスの設定エラーが重なり、重大なインシデントに繋がりました。

この事故により Capital One は数億ドル規模の罰金と長期的な信頼危機に直面しました。権限管理、ネットワーク分離、機密データ保護の重要性を改めて認識させる事例です。

IV. 結論と推奨事項​

Docker Compose と Ubuntu の組み合わせはコンテナアプリケーションを迅速にデプロイする便利な手段ですが、セキュリティはプロセス全体に組み込む必要があります。

• コンテナ権限とネットワーク分離を厳格に管理する
• 機密情報の漏洩を防止する
• 定期的なセキュリティスキャンとアップデートを実施する
• エンタープライズ規模になるほど、Kubernetes など高度なオーケストレーションへ移行し、セキュリティ保証を強化することを推奨します

セキュリティは終わりなき取り組みです。本記事が Docker Compose + Ubuntu 環境の保護に役立つことを願っています。