はじめに

ブロックチェーンは国境を越えた取引やボーダーレスなネットワーク構築を可能にし、近年、実世界資産（RWA：Real World Asset）の領域にも応用されつつあります。しかしRWAでは、とりわけモビリティにおいては、制度や商習慣といったローカルな境界が存在し、それらを無視することはできません。モビリティは単なるモノではなく、登録・保険・税・整備・監査など、複数主体の関係性と手続きの上に成立する社会システム的存在だからです。

私たちは昨年、こうした構造をユーザとモビリティの関係から捉える試みとして、MOA（Mobility Oriented Account）のコンセプトを提示しました。これは、モビリティを「抽象アカウント」として定義しようとするものでしたが、モビリティが持つ多層的・多主体的な関係性までは十分に表現しきれないという課題も明らかになりました。

本ペーパーはその気づきを受けて、視点を転換した提案です。MOAが個体(アカウント)からモビリティを定義しようとしたのに対し、関係(ネットワーク)そのものからモビリティを記述しようとする試みです。

背景

モビリティはそれを取り巻く関係性からして、すでにネットワークの一部であるといえます。

走行している１台のクルマを想像してください。実はそれはA社が車両を製造し、B社がそれを法的に保有し、C社が運用し、Dさんがその日に運転し、E社が保険を引き受け、F社が整備している状態かもしれません。こうした複雑な関係性が、ごく当たり前に成立しているのです。

モビリティは一人の所有者に帰属する静的な資産ではなく、事実として複数のプレイヤーによる社会的関係性の集合であり、「誰にとって、いつ、どんな意味を持つか」はこの全体構造によって決まります。

こうして多様なプレイヤーが責任を共有し、各々の領域で信頼を供与することによって、モビリティは社会に存在しています。本稿では以降、これらの関係性を検証可能かつ相互運用可能な形に整えたデジタルな信頼を「トラスト」と呼び、この社会的関係の連鎖を「トラストチェーン」と呼びます。私たちは、モビリティの価値はトラストチェーンの束によって動的に保証され、事実として「形作られて」いると考えています。

課題

「所有から利用へ」というパラダイムシフトの進行に伴い、モビリティは単なる移動手段ではなく、継続的に無形価値を生み出す「モビリティアセット」として再定義されつつあります。EV・自動運転車などの新しいモビリティの登場、車両価格の高騰は、モビリティの価値をグローバルに流動化させ、さまざまな権利を分解・再構成したいという潮流を生み出しています。

しかし、これらを実現しようとすれば、モビリティの価値は3つのレベルの課題に阻まれます。

• Level1 組織の断絶： 車両登録情報や車両データは政府や事業者単位で分断され、価値評価や与信の根拠として統合的に扱えない。

• Level2 業界の断絶：複数のプレイヤーが継続的に連携するための、オープンで相互運用可能なネットワークが存在しない。

• Level3 国家の断絶：国・地域で登録や税制、保険制度が異なり、単一の登録証明では越境的な正当性を担保できない。

これらはモビリティが自己完結したモノではなく、もとより社会制度と複数の関係主体により構築される存在であることに起因します。つまりモビリティとはその性質からして、場所から場所へ、人から人へ、国から国へと「動く」ことで、組織を跨ぎ、業界を跨ぎ、国家を跨ぐ存在なのです。果たしてこうした存在を、単一のプラットフォームで表現できるのでしょうか？

ここでようやくブロックチェーンの出番です。私たちは、モビリティの価値を正しく流通させるために、これら3つの断絶をなめらかに橋渡しする「ネットワークレイヤー」が必要だと考えています。

コンセプト

本ペーパーが提案するMON(Mobility Orchestration Network)は、モビリティが持つ多様かつ多層的な関係性をオーケストレーションするための、中間的なネットワークレイヤーのコンセプトです。グローバルなモビリティエコシステムを構成する一部として、その3つの橋(Bridge)によって３つの断絶を乗り越えます。

MON Bridge 1：信頼を束ねる

まずは「組織の断絶」に対処します。モビリティの価値は単一の証明では保証できず、複数の証明が集約された「トラストチェーンの束」としてのみ保証されます。MONではトラストチェーンを構成する複数の情報をオーケストレーションすることで、ネットワーク上でモビリティを表現し、その「トラスト」をデジタルで確立する役割を担います。

トラストのための3種類の証明

• 制度的証明:

  • 要素: 車両の登録証・所有権記録、税金や保険のコンプライアンス状況など。

  • 役割: 社会制度に裏付けられた、モビリティの「法的な存在証明」を確立します。MONは、これらのオフチェーンの証明を、オンチェーンで検証可能な形式で統合します。

• 技術的証明:

  • 要素: VIN と型式認定/CoC、OEM 製造データ、センサーの健全性、ソフト/ファームのアテステーション、検証済み整備イベントなど。

  • 役割: 技術的な側面から、そのモビリティが「どのようなモノであるか」を証明します。MONは、これらの信頼できるデータ（OEMデータなど）をオンチェーンに記録し、データの真正性を保証します。

• 経済的証明:

  • 要素: 利用稼働指標、収益実績、メンテナンス修理履歴（運用実績として） など。

  • 役割: モビリティが「どのような状態にあり、どのような価値を生み出しているか」を証明します。MONは、これらの動的な情報を集約し、モビリティが持つ経済的な価値の根拠を明確にします。

モビリティへの信頼は「技術」「制度」「経済」という3つの領域によって構成されます。それぞれが検証可能なデータに裏付けられているからこそ、モビリティはあらゆるシステムを横断して「トラスト」可能な存在となります。

MON Bridge 2：価値循環を始動する

次に「業界の断絶」に対処します。トラストの確立により資本が投下されやすくなることで、より大きな資本循環を生み出します。アセット、ファイナンス、サービスの3つの業界がなめらかにつながれば、モビリティの価値はそのサイクルの中で強化されていきます。しかしMONは、すべての価値流通を完結させる単一のネットワークではありません。むしろ自らはアセットとトラストに特化し、既存の証券・決済・保険・融資・モビリティサービスなど、複数の異なったネットワークと相互運用される前提で設計された、中立的なネットワークです。MONはこのサイクルの起点でありながら、モビリティの価値流通に関わる複数のネットワークをオーケストレーションする役割を果たします。

3種類のネットワーク

• Trust Network（=MON）: モビリティアセットのトラストを確立するためのネットワークレイヤーです。Bridge 1で定義した制度・技術・経済の保証を束ね、検証可能なデジタル・トラストとして公開します。

• Capital Network: 確立されたトラストを根拠に、融資・投資・証券化といった金融アクティビティを担う専門ネットワークです。資金調達をネットワーク上で安全に実行します。

• Utility Network: モビリティが実際に運用される場であり、アクセス権の発行・行使やサービス提供を扱います。ここで生まれる稼働実績と状態データは、モビリティアセットのトラストを継続的に強化し、次の調達の根拠となります。

たとえ同じ地域であっても、3つの領域は異なる制度によるガバナンスを受けるため、それぞれのネットワークは異なる要件を持ちます。MONはこれらを標準でつなぎ、価値を循環させます。

MON Bridge 3：エコシステムを繋ぐ

最後に「国家の断絶」に対処します。MONが最終的に目指すのは、ローカルに存在する多様なエコシステムを破壊することなく、グローバルな価値流通を実現することです。この壮大ともいえるビジョンを実現する鍵こそ、MONが「単一のグローバルプラットフォーム」ではなく、共通のルールセットである「プロトコル」として設計されている点にあります。

実際に、各地域には独自の法制度、金融ネットワーク、そして文化に根差したサービスが存在します。MONは、これらの自立性を最大限に尊重します。

国や地域ごとに存在するローカルなMONは、それぞれが固有のステークホルダーとガバナンスを持ちながらも、この共通プロトコルという「トラストの共通言語」を用いて相互に連携します。これにより、異なるモビリティエコシステムはMONを通じてオーケストレーションされ、モビリティやそれに付随する価値がなめらかに境界を越えることが可能になるのです。

MONは、ネットワークであると同時にプロトコルです。世界中のローカルエコシステムを繋ぐ仕様として機能し、全体としてグローバルなトラストのネットワークを形成します。

デザイン

コンセプトの章では、MONが3つのフェーズを通じて「組織・業界・国家」という断絶を乗り越える全体像を示しました。では、その構想を現実に落とし込むために、MONは物理世界の複雑な関係性をまとうモビリティを、どのようにしてデジタルアセットへと「翻訳」するのでしょうか？

本章では、その答えとなる２つの重要な設計思想を紹介します。この関係性を定義するための「モビリティ・オリエンテッド・アカウント(MOA)」と、それを金融が扱えるデジタルアセットへと昇華させる「ファンジビリティ・ラダー」です。

モビリティ・オリエンテッド・アカウント(MOA)

Bridge 1で述べた「トラストチェーンの束」は、オンチェーンにおいて「アカウント」として実体化し、モビリティのデジタルアイデンティティを構成します。このアカウントは、モビリティが持つ多面的な証明を受け止めるための、いわば「アイデンティティの器」です。

しかし、この器は一つではありません。モビリティが持つ性質の異なる情報を適切に扱うため、役割の異なる2つの器にその機能を分離して設計されています。

• Trustネットワークにあるアカウント（T-MOA）:

  • モビリティの資産価値と正当性を裏付けるための器です。車両登録、所有権、保険、監査レポートなどの高確度で監査向きの情報に加え、稼働や収益の要約といった低頻度の更新も、検証可能な形で厳密に収めます。金融や規制の世界に向けた公的な側面を担います。

• Utilityネットワークにあるアカウント（U-MOA）:

  • モビリティが実際に運用される現場の窓口となる器です。「クルマ」の稼働状況や充電状態といった動的な状態や、「ヒト」の運転資格・サービス利用権限といったリアルタイムの判定を扱い、その場で検証・集約・要約します（詳細データや個人情報はオフチェーンに留め、必要最小限のみをT側へ橋渡しします）。

このように、T-MOAが「アセット」の信頼を、U-MOAが「クルマとヒト」の運用をそれぞれ担当します。両者は鏡像のように結びつき、必要な要約だけが安全に行き来することで、その時々の関係性まで含めたスナップショットとしてのデジタルアイデンティティが形作られます。こうした設計の背景には、モビリティを社会システム的存在であるとした Mobility Oriented Account の議論が引き継がれています。

ファンジビリティ・ラダー

Bridge 2で述べたように、モビリティの価値を業界の壁を越えて流通させるには、その性質を変換する必要があります。金融業界がアセットの価値を代替可能な数値として扱うのに対し、モビリティ業界では個々の車両や利用権は通常、非代替的なものとして扱われます。この根本的な違いを乗り越えるため、MONはトークナイゼーションを通じて代替性（Fungibility）を段階的に変化させます。このプロセスこそが「ファンジビリティ・ラダー（代替性のはしご）」です

• 第1段：Ownership (非代替)

  • ラダーの最初の段は、モビリティ・アカウントを所有する権利を、非代替性トークンとして定義する部分です。このトークンを保有することは、単に車両を所有することではなく、特定の車両と紐づくモビリティ・アカウント全体を所有することを意味します。

• 第2段：Portfolio (半代替)

  • 次に、複数の所有権を、階層構造を持つポートフォリオとして束ねます。個々のモビリティ・アカウントはユニークですが、その中から特定の側面（例：同車種、同地域など）にだけ着目することで、「特定の条件を満たす集合」として、一部代替可能なものとして扱うことができます。このような半代替性（Semi-Fungiblity）という性質により、リスク評価や管理を、より大きな、現実的な単位で行うことが可能になります。

• 第3段：Security (完全代替)

  • 最後に、このポートフォリオの価値を、より広く流通する価値基準（例えば法定通貨）によって価格評価し、その評価額を裏付けとした完全代替性の金融商品、すなわち証券（Security Token）を発行します。これにより、複雑で非代替的であった「関係性」は、最終的に投資家が円滑に取引できる標準化されたデジタルアセットへと翻訳されるのです。

２つの概念から構成されるオンチェーン設計は、特定のシステムのためだけのものではありません。世界中のあらゆる地域で展開可能な、モビリティ・トークナイゼーションの標準プロセスでもあります。この設計を共通の仕様、すなわち後の章で説明するプロトコルとして各地域のエコシステムが採用することで、Bridge3で掲げたグローバルな価値流通への道が拓かれます。

図に示されるように、Mobility Oriented Accountから始まるファンジビリティ・ラダーを一段ずつ昇ることで、モビリティの価値はその性質を変化させながら業界をまたいでいきます。MONの核をなす機能とは、この豊かな関係性の情報を維持したまま、アセットを流動性の高い市場へと昇華させる設計そのものです。この設計を洗練させていくことで、私たちはモビリティが持つさまざまな権利を自由に分解・再構成できるようになると信じています。

テクノロジー

デザインの章では、MONの設計思想として「MOA」と「ファンジビリティ・ラダー」を提示しました。では、この設計思想を技術的に実現するには、どのような技術課題を乗り越える必要があるのでしょうか？ MONの技術設計は、主に3つの問いから出発します。

1. 信頼の起点: 個々の車両にMOAを付与し、その集合体であるポートフォリオ全体の信頼性を、技術的にどう担保するか？

2. 価値の循環: ファンジビリティ・ラダーを昇る過程で、性質の異なる複数のネットワーク（Trust/Capital/Utility）を、どう安全に相互運用させるか？

3. 構成要素の拡張性: MOAやポートフォリオといった構成要素を、将来登場しうる新たな権利やサービスにも対応できるよう、柔軟で拡張可能な構造としてどう設計するか？

これらの問いに対する、私たちの技術的なアプローチを紐解いていきましょう。

1. アイデンティティ：信頼の起点となるデジタル存在証明

あらゆる信頼は、その対象が「誰（何）であるか」が証明できることから始まります。MONでは、物理世界に存在する車両に、ブロックチェーン上で検証可能なデジタル上のアイデンティティを付与します。その情報を集約する器となるのがMOAです。

その第一歩は、所有権という最も根源的な権利をデジタルで捉えることです。私たちは、車両が製造された瞬間に、OEMがその所有権をNFT（Non-Fungible Token）として発行することを提案します。このNFTは、単なるデジタル資産ではありません。それは、一台の車両に固有のアイデンティティを確立する最初の公式な記録であり、MOAというアカウントと固く結びつきます。

このMOAには、公的機関が発行する登録情報や、OEMによる製造情報といった信頼可能なデータが次々と関連付けられていきます。こうして、物理的なアセットとデジタルな情報が結びついた、改ざん耐性を持つ「社会的アイデンティティ」が誕生し、エコシステム全体で「トラスト」を共有するためのすべて基礎となります。

車両がOEMによって製造される時、その所有権とアイデンティティを管理するアカウントがブロックチェーンに登録されます。そして、所有者がディーラーやユーザー、あるいはファンドへと移転していく中で、その車両のライフサイクルで起こるさまざまな出来事（整備、稼働状況の変化など）は、このアカウントに継続的に記録されます。これにより、投資家のような離れた場所にいるステークホルダーでさえ、いつでも資産の正確な状態を確かめることができます。

2. マルチチェーン：価値の循環を支える役割分担

MONのアーキテクチャは、「信頼（Trust）」「資本（Capital）」「実用（Utility）」という3つの異なる機能領域が連携することを基本としています。この思想を技術的に実現する上で、MONは2つの階層でマルチチェーン・アーキテクチャを前提としています。

第1階層：地域「内」の相互運用性

まず、ある一つの国や地域内に、それぞれ異なる技術基盤やガバナンスを持つ、無数の独立したネットワークが存在しうるという現実があります。

• 多様なCapital Network: 証券トークンプラットフォーム、DeFiプロトコル、決済網など。

• 多様なUtility Network: コネクテッドサービス基盤、ライドシェア事業者のシステム、V2Gプラットフォームなど。

この地域内の技術的な断絶を乗り越えるため、ローカルなMON（Trust Network）は、これら異種混合（ヘテロジニアス）なネットワーク群を繋ぐ「中立的な相互運用性レイヤー」として機能する必要があります。

第2階層：地域「間」の相互運用性

さらに、MON自体も単一のグローバルなネットワークではありません。 MONは、各地域の法制度やエコシステムを尊重しながらローカルに展開されることを前提としたプロトコルです。つまり、日本には日本のMONが、米国には米国のMONが存在します。

中古車が国境を越えて取引されたり、グローバルな資金が特定の地域のモビリティフリートに投資されたりする未来を実現するには、これらローカルなMON同士が相互に連携できなければなりません。

この2つの階層にまたがる複雑な連携を、安全かつシームレスに実現すること。これこそが、MONが「マルチチェーン・アーキテクチャ」を採用する核心的な理由です。この思想を実現する技術的なバックボーンとして、信頼性の高いクロスチェーン通信プロトコルの選択が極めて重要となります。

3. コンポーザビリティ：拡張性を担保する組み合わせの思想

モビリティの価値は固定的ではありません。車両の集合であるフリートとそれぞれの車両、変化する所有者と利用者、さまざまな権利関係が複雑に絡み合い、時間やユースケースと共にその姿を変えていきます。この現実を捉えるために、MONは独自に閉じたシステムを構築するアプローチをとりません。私たちは、世界中の開発者が磨き上げてきた実績ある標準仕様を「レゴブロック」のように組み合わせる思想、すなわちコンポーザビリティを重視しています。

• ERC-721: Non-Fungible Tokenで車両の所有権を表現

• ERC-7401: Parent-Governed Non-Fungible Tokens Nestingでポートフォリオ／階層を表現

• ERC-6551: Token Bound Accountで所有権NFTにMOAのアドレスを恒久バインド

• ERC-4337: Account Abstraction Using Alt MempoolでMOAの実行・検証フローを柔軟化

• ERC-7579: Minimal Modular Smart AccountでMOAの機能をモジュール化

• ERC-735: Claim HolderでMOAに検証可能クレームを格納

• ERC-3643: T-REXで規制に準拠の証券・通貨を流通

技術的詳細は以降の章に譲りますが、これらの標準仕様を組み合わせることで、複雑な権利関係と代替性を柔軟に表現できることがポイントです。システムを疎結合に構成することは、将来の予期せぬ変化に対応できる拡張性を確保することにもつながります。MONはこのコンポーザビリティによって、未来のモビリティエコシステムの進化に追随できるようなプロトコルを目指します。

プロトタイプアーキテクチャ

デザインとテクノロジーの章で描いた構想を、現実のコードへと落とし込み、その可能性を検証するために、私たちはプロトタイプを設計しました。これはMONの壮大なビジョンの全てを一度に実装するものではなく、まずは一つの地域かつ特定の条件下で展開されることを想定した、いわばサンドボックス・システムです。

プロトタイプは、次の 4 つのコンポーネントから成ります。

• Avalanche L1 Blockchain

• Interchain Messaging Protocol

• Identity Service

• Trust Gateway

Avalanche L1 Blockchain：エコシステムを構築する舞台

今回のプロトタイプ開発では、MONの基盤としてAvalancheを選択しました。Avalancheは高速・低遅延なコンセンサスを特徴とするブロックチェーンプラットフォームで、複数の目的別チェーンによるマルチチェーン構造を持ちます。主要なパブリックチェーンとして、EVM互換でスマートコントラクト実行を担うC-Chain、ステーキングやバリデータ管理を行うP-Chain、資産の作成や移転を行うX-Chainがあります。さらに、独自のL1（旧Subnet）を展開することも可能です。パブリック/プライベートの切り替えが可能で、展開したいサービスに合わせて最適なL1ブロックチェーンを構築できます。これらパブリックプライベート含めた全てのチェーン間では、Avalanche Inter-Chain Messaging（ICM）機能により、トークンやデータの安全かつ高速なクロスチェーン連携がサポートされ、統合的なアプリケーション構築が容易になっています。

選択の理由は、その複数のL1（旧Subnet）を前提とした設計、高速なファイナリティ、そして ICMの標準実装という特徴が、MON の目指す「ローカルによるグローバル」「マルチチェーンの協調」という思想と合致するためです。

本プロトタイプにおいては、この Avalanche上に以下の4つの役割を持つL1の存在を想定しています。

もちろんこれらはあくまで一例であり、ケースによっては、これらの機能が統合されたり、さらに細分化されたりすることもあります。Avalancheの柔軟なアーキテクチャは、そのような複雑なトポロジーにも対応できる可能性があります。

Interchain Messaging Protocol：ネットワークをつなぐ共通言語

独立したネットワーク群が効果的に協調するためには、互いに「対話」するための安全で信頼性の高い通信手段が不可欠です。特に、資産の受け渡しと支払いを同時に行うDvP（Delivery versus Payment）のような取引では、メッセージの確実な到達が極めて重要になります。

現在、チェーン間の通信プロトコルにはさまざまな選択肢が存在しています。

今回のプロトタイプでは、基盤となるAvalancheとの親和性が最も高く、導入が容易であることからAvalanche ICMを採用しています。これにより、コントラクト開発者は、まるで同じネットワーク上の機能を呼び出すかのように、シンプルかつ安全にネットワーク間の連携を実装できます。

Avalanche ICMは下図のように動作します。呼び出し元のコントラクトでITeleporterMessenger.sendCrossChainMessageを呼び出すと、メッセージがオンチェーンでエンキューされ、オフチェーンコンポーネントであるRelayer がそのメッセージを取得します。Relayerは呼び出し先チェーンの Teleporter（Messenger）にメッセージを投稿し、Teleporter を経由して呼び出し先コントラクトの ITeleporterReceiver.receiveTeleporterMessage(...)

をコールします。送信側で ITeleporterMessenger、受信側で ITeleporterReceiverに準拠したコントラクトを用意すれば、安全に他チェーンとの通信を行えます（これらのインターフェイスに準拠していれば、その他のロジックはプロジェクト要件に合わせて自由に実装可能です）。通信中には Avalanche 独自の EVM 拡張である Warp Precompile が呼び出され、この拡張を通じてチェーン間メッセージの検証・相互認証などのセキュリティ処理が実行されます。

Identity Service：デジタルと現実をつなぐ情報ハブ

ブロックチェーン上のデジタル資産が、現実世界に存在する「実物」と確かに結びついていると、どうすれば信頼できるのでしょうか？こうしたRWAに共通する課題に応えるのがIdentity Serviceです。これは、デジタル世界と物理世界をつなぐ「情報ハブ」の役割を果たします。

プライバシーとスケーラビリティの観点から、すべての情報を直接オンチェーンに記録することはできません。しかし、一部の情報やハッシュ化されたデータにオンチェーンからアクセスできることで、常に最新状態を確認できる仕組みを実現します。また、モビリティの所有者はオフチェーンでより詳細なデータにアクセスすることが可能です。

その主な機能は次の3つです

この仕組みにより、情報の機密性を保ちつつ、誰もがブロックチェーン上で資産の重要な状態を検証できるという、透明性と信頼性を両立させています。

Trust Gateway：社会の信頼をオンチェーンへ

MONが扱うトラストの源泉は、ブロックチェーンの中だけで完結するものではありません。自動車登録情報のような、既存の社会制度に根差した「オフチェーンの信頼」を、いかにしてデジタルの世界に安全に橋渡しするか。この重要な役割を担うのがTrust Gatewayです。

それを実現するアプローチには、以下のようなPros-Consがあります

それぞれに一長一短があり、現時点で完全な解決策は存在しません。本プロトタイプでは、検証をシンプルにするため「信頼された中間者」のアプローチをとっています。しかし、将来的にはプライバシーと透明性をより高度に両立できる、分散化されたアプローチへと進化させていくことを見据えています。

コントラクト

前章では、MONの構想を検証するためのサンドボックス・システムの全体像を示しました。本章では、その心臓部であるスマートコントラクトの設計（ブループリント）について詳述します。

MONの設計思想、特に「ファンジビリティ・ラダー」は、単一のコントラクトではなく、役割の異なるコントラクト群の連携によって実現されます。その構造は、モビリティのデジタルアイデンティティを定義するMobilityOrientedAccountを基礎とし、その所有権を表現するVehicleOwnership、そして複数の所有権を束ねるAssetPortfolioへと至る、階層的なアーキテクチャを形成します。

この構造を理解するために、まずは全ての基盤となるコントラクトである、MobilityOrientedAccountから解説を始めます。

1. MobilityOrientedAccount (MOA)

MOAは、MONアーキテクチャの基礎であり、車両のデジタルアイデンティティを集約する最も重要なスマートコントラクトです。単なるデータストアではなく、モビリティという複雑なリアルワールドアセット（RWA）をブロックチェーン上で自律的に機能させるため、MOAは次の3つの特徴があります。

• スマートアカウント：モビリティをルールに基づき自ら振る舞う行為主体にする。

• 鏡像アーキテクチャ：現場の即時性と台帳の確定性という相反要件を、役割の異なる2つのアカウントで両立する。

• モジュラー設計：将来の要件変化に追随できる拡張可能な構造を持つ。

スマートアカウントとしてのMOA：自律した行為主体

モビリティは、利用権限の検証、起動前チェック、メータリング要約、クロスチェーン受信後の状態更新など、プログラムによって定義された振る舞いを状況に応じて自律的に実行できる必要があります。

この自律性を実現するため、MOAはスマートアカウントとして設計します。

• 実装：MOAは ERC-4337 に準拠したスマートアカウントとして動作し、ERC-6551 により VehicleOwnership（必要に応じて AssetPortfolio）NFTに恒久バインドされます。これによりMOAは「車両に紐づいた固有の口座」として機能し、Paymasterによるガス代スポンサー、マルチシグやセッションキー等の高度な運用要件にも対応可能です。

• 権限の自動解決：権限判定は ownerOf（ERC-7401 の親子関係を再帰的に辿る関数）で最上位のルートオーナーを導出します。VehicleOwnership／AssetPortfolio に名義変更があっても、MOA側で追加の移行処理は不要で、次回の検証時に新しいルートオーナーが権限者として認識されます。

鏡像アーキテクチャ：現場と台帳の二相構造

鏡像MOAとは、同一のVehicleOwnership NFTに ERC-6551 でバインドされた 2つのMOA（U-MOA / T-MOA）を別ネットワークに実体として配置し、Avalanche ICMで連携させる実装を指します。これは単なる「ビューの切替」ではなく、異なる責務を持つ2アカウントを分離運用するのがポイントです。

このアーキテクチャの技術的な鍵は、単一のNFTに対して、役割（role）の異なる2つのアカウントアドレスを、誰でも検証可能な方法で決定論的に生成する仕組みにあります。

これはERC-6551が提供するCREATE2ベースのアカウントレジストリと、MOAの役割を示す識別子（ROLE_TRUST / ROLE_UTILITY）を組み合わせて実現します。具体的には、アドレス計算に用いるsaltにこの役割識別子を含めることで、同一NFTから2つの異なるMOAアドレスを導き出すことができます。

以下のコードは、このアドレス計算ロジックの最小限の実装例です。

// Minimal 6551 binding for Mirror MOA (T / U)

// ERC-6551のレジストリを用いた鏡像MOAのアドレス解決
interface IAccountRegistry6551 {
    function account(address impl, uint256 chainId,
                     address nft, uint256 id, bytes32 salt,
                     bytes calldata initData) external view returns (address);
                    
    // ... createAccount function
}

// T-MOAとU-MOAを区別するための役割識別子
bytes32 constant ROLE_TRUST   = keccak256("TRUST");
bytes32 constant ROLE_UTILITY = keccak256("UTILITY");

// 同一NFTから役割別のMOAアドレスを計算する関数
function moaAddress(
    IAccountRegistry6551 reg,
    address impl,
    uint256 targetChainId,
    address voNft,
    uint256 voId,
    bytes32 role // ROLE_TRUST または ROLE_UTILITY を指定
) internal view returns (address) {
    // chainId, NFTアドレス, TokenID, そして「役割」から一意のsaltを生成
    bytes32 salt = keccak256(abi.encode(targetChainId, voNft, voId, role));
    return reg.account(impl, targetChainId, voNft, voId, salt, "");
}

/*
 * === 使用例 ===
 * address tMoa = moaAddress(registry, implementation, HOME_CHAIN_ID, voNft, voId, ROLE_TRUST);
 * address uMoa = moaAddress(registry, implementation, HOME_CHAIN_ID, voNft, voId, ROLE_UTILITY);
 */

この仕組みにより、特定のVehicleOwnership NFTに対応するT-MOAとU-MOAのアドレスが決定論的に導出され、第三者が再計算で検証可能になります。

それぞれのMOAは以下のような明確に分離された役割を担います。

• U-MOA（Utility側 / L1-C）：前処理ノード

  運転資格の検証、稼働ログ・充放電等の高頻度イベントをリアルタイム処理し、検証→集約→要約（hash / Merkle / ZKP）を担います。PIIや詳細ログなどプライバシー配慮が必要な原本はUtility側およびオフチェーンに留めます。

  • ユーザ資格の扱い: 運転免許等の「ヒト」のクレデンシャルはユーザ側アカウントに保持し、U-MOAは選択的開示やゼロ知識証明で有効性のみを検証・要約します（PIIはT側に持ち込みません）。

  • 最小プロファイル：U-MOAでの ERC-735の恒常保管は必須ではありません。最小構成では検証・要約・ICM送達に特化し、確定保管はT-MOA側が担います。

• T-MOA（Trust側 / L1-B）：権利確定のための台帳。U-MOAから ICM で届く検証済みの要約のみを受け取り、ERC-735クレームとして確定します。 クレームは改ざん検知可能な（append-only）記録として保持し、失効/訂正は revocation 参照で扱います。資産評価や証券化は、このTrust側の確定データに基づいて行います。

この二相構造によって、現場のスループットと資本市場が要求する厳密性・監査可能性を同時に満たそうとするものです。

モジュラー設計：未来の要求に応える拡張性

規制・サービス・暗号/プライバシー技術は変化し続けます。MOAは ERC-7579 に基づくモジュラー設計で、アドレスは維持したまま機能を差し替え/追加できます。

主要モジュール

• Validator モジュール：ownerOf（ERC-7401再帰）に基づく権限判定、EIP-1271署名検証、セッションキー、ポリシーベース承認、マルチシグ等を担当します。

• Executor / Hook モジュール：ICM受信後の集計・正規化・通知、AssetPortfolioとの連携、可用性KPI更新などの後処理を分離します。

• Fallback モジュール：後付け関数の追加点。ERC-735 Claim Holder のAPIや ICM受信API など、コア機能もモジュールとして提供/更新可能です。

注：ERC-735 はコミュニティ提案の標準仕様（提案段階）ですが、検証可能クレームの格納/失効参照を行う実務要件に適合するため採用しています。

2. VehicleOwnership

VehicleOwnershipは、特定の車両に対する所有権（法的タイトル、またはそれに準ずる権利）を表すシンプルな ERC-721 トークンです。モビリティをアセットとして既存のファイナンスに接続し、証券化の土台を作るためには、まず第三者に主張可能な所有の起点が必要です。本トークンはそのための標準仕様に準拠したインターフェースになります。

• 標準と最小要件：ERC-721 による 所有の概念（ownerOf） と 移転機能（transferFrom/safeTransferFrom） を備えることが、モビリティアセットに求める最小要件です。

• 発行主体：製造時または初回登録時に OEM／登録当局／Trust Gateway がミントする想定です（地域の制度に合わせて選択）。

• 1:1の不変条件：一台の車両につき1つの VehicleOwnership。名義変更はトランスファーで表現し、廃車・スクラップ時はバーンします。

• MOAとの関係：車両の属性や証跡は本トークンではなくMobilityOrientedAccountに集約します。ERC-6551 によりVehicleOwnershipと MOA は恒久的にバインドされ、後段の AssetPortfolioからも一貫して参照されます。

すなわちVehicleOwnershipは、モノとしての車両に「所有」という抽象概念を付与し、金融の側から安全にアクセスするための薄いレイヤ（いわば Hardware Abstraction Layer）を提供します。属性データや運用上の証跡は MOA 側に保持されるため、本トークンはシンプルで相互運用性の高い「所有の根」として機能するのです。

3. AssetPortfolio

AssetPortfolioは、1つ以上のVehicleOwnership NFTを束ねる親NFTとして機能します。

個別の所有権トークンを一つのポートフォリオに集約（nest）することには、明確な技術的・財務的合理性があります。

• 技術面: 多数のNFTを一つの単位として扱えるため、アトミックスワップのような複雑な操作を簡素化し、他のプロトコルとの相互運用性を高めます。

• ファイナンス面: 証券発行者が、個々の車両ではなくポートフォリオ単位で資産価値を評価し、投資家へ報告（開示）することが可能になります。

この目的を達成するため、AssetPortfolioはNFTを入れ子にするための親子ネスティング機能と、資本市場向けのレポーティング機能を備えます。

親子ネスティング：ERC-7401の採用

AssetPortfolioがVehicleOwnershipを所有する（入れ子にする）ための技術標準として、ERC-7401: Parent-Governed Non-Fungible Tokensを採用します。これにより、NFTの親子関係をブロックチェーン上で表現できます。

ERC-7401では、ownerOf は階層を再帰的にたどって ルートオーナー（NFTではない最上位の所有者アドレス）を返し、直近の親NFTは directOwnerOf で取得します。 したがって、MOAが権限検証を行う際は、VehicleOwnership／AssetPortfolioのいずれに対しても ownerOf(tokenId) を呼べば、最上位の権限者を一意に確定できます。

以下は ERC-7401 の振る舞いを示す、参照ライブラリからの抜粋です。

/// Minimal view of ERC-7401 behavior
interface IERC7401 {
    /// Returns the root (top-level, non-NFT) owner
    function ownerOf(uint256 tokenId) external view returns (address);

    /// Returns the immediate parent NFT (contract, tokenId)
    function directOwnerOf(uint256 tokenId)
        external
        view
        returns (address parentContract, uint256 parentTokenId);
        
    /// ... and more functions
}

MOAのValidatorモジュールは、ERC-7401に従い ownerOfの返却値（ルートオーナー）を用いて、ネスト階層が深い場合でも常に正当な権限者を特定できます。

レポーティング機能：資本市場との接点

AssetPortfolioは、資本市場に向けた情報開示の窓口として、最低限次の2つのレポーティング関数を実装します。

1. getAvailability() / setAvailability()

ポートフォリオ配下にある車両の「稼働可能台数 / 総台数」を管理します。

• データソース: 可用性フラグは、各車両のT-MOAに確定記録されたクレームを参照します。

• 最適化: ループ計算によるガス代高騰を避けるため、オンチェーンではキャッシュされたカウンタを保持し、イベントやオラクル経由で非同期に更新します（setAvailability）。

2. getAssetValue() / setAssetValue()

ポートフォリオの評価額と、その評価時点（タイムスタンプ）を管理します。

• アクセス制御: 信頼性を担保するため、この値は指定された監査・評価オラクルのみがsetAssetValue関数で書き込み可能です

• 堅牢性: 古い情報で上書きされることを防ぐタイムスタンプのチェック (require(asOfDate >= v.asOfDate)) を行います。

contract AssetPortfolio /* ... */ {
    event AssetValueSet(uint256 indexed id, uint256 amount, uint64 asOfDate);
    event AvailabilitySet(uint256 indexed id, uint256 available, uint256 total);
    event ChildAdded(address indexed child, uint256 indexed childId);
    event ChildRemoved(address indexed child, uint256 indexed childId);

    function getAvailability(uint256 id)
        external view returns (uint256 available, uint256 total);

    function setAvailability(uint256 id, uint256 available, uint256 total)
        external /* onlyRole(REPORTER_ROLE) */;

    function getAssetValue(uint256 id)
        external view returns (uint256 amount, uint64 asOfDate);

    function setAssetValue(uint256 id, uint256 amount, uint64 asOfDate)
        external /* onlyRole(REPORTER_ROLE) */;
}

オンチェーンとオフチェーンの役割分担

AssetPortfolioが提供する情報は、オンチェーンとオフチェーンの適切な役割分担に基づいています。

• オンチェーン: 可用性のカウンタ、評価額のスナップショット、所有権の階層構造。

• オフチェーン: 市場価格やリスクを用いた詳細な資産評価、U-MOAが扱う運用ログの原本。

• オンチェーンブリッジ: U-MOA → (ICM) → T-MOA → AssetPortfolioが参照可能なクレームの順に情報が伝えられます。

4. SecurityToken / StableCoin

この節で扱うコントラクトは、MON とは別のネットワーク（Capital Network）にデプロイされる前提です。MON が提供するのは アセット側のトラスト（T-MOA／AssetPortfolio） であり、トークンの発行・移転・規制対応は連携先ネットワークの責務です。

役割と準拠標準

最終的な標準の選択は 法域や発行主体の運用要件に依存します。MON は中立であり、アセットとトークンを繋ぐ連携インターフェースのみを規定します。

• Security Token（ST）

  • AssetPortfolio に束ねられた所有権を裏付けに発行され、投資家に配布される ERC-20 互換トークンです。移転には コンプライアンス要件（KYC/AML、適格投資家、ロックアップ等） を前提とし、ここでは ERC-3643（T-REX） 準拠を想定します。ERC-3643 はアイデンティティ・レジストリとコンプライアンス・ルールを組み合わせ、転送前チェック（pre-transfer check） により規制をオンチェーンで強制できる点が特徴です。

• Stable Coin（SC）

  • 出資・分配・決済の決済レールとして用います。移転制御が不要な場合は一般的な ERC-20 で十分ですが、必要に応じて ERC-3643 による移転制御を採用できます。

MON との連携インターフェース

• 裏付け資産の検証

  • ST 発行コントラクトは、価値の裏付けとなる AssetPortfolio のトークン ID を保持します。投資家や監査人は ST から AssetPortfolio を辿り、getAssetValue() や getAvailability() を通じて、MON が提供する確定データ（トラスト）を直接参照・検証できます。

• 開示連携

  • U-MOA からT-MOA へ集約・確定された稼働実績や収益の要約クレームは、発行体の開示義務を支える信頼できるデータソースです。必要に応じて、この確定データをトリガーに ST 側のイベント発火やメタデータ更新を自動化できます。

発展的な機能

• プライバシー強化（例：Avalanche eERC）

  • コンプライアンス検証（誰が取引できるか）は維持しつつ、残高と送金額を暗号化する実装（例：Avalanche の eERC）を内部実装として採用可能です。ゼロ知識証明で取引の正当性を検証し、監査時には閲覧鍵（view key）で開示するなど、「コンプライアンスと両立するプライバシー」を実現します。

• 3-way DvP（Delivery-vs-Payment-vs-Title）

  • 資金（SC）／証券（ST）／裏付け資産の所有権（AssetPortfolio）の 3 資産交換を、アトミックに実行する仕組みです。ICM によるクロスチェーン連携で、いずれか一つでも失敗すれば全ロールバックし、カウンターパーティリスクや短期ブリッジ融資の必要性を最小化します。

• トークン・ライフサイクルの自動化

  • MON の確定データを、トークン運用の自動化トリガーとして利用できます。

    • 分配：T-MOA に記録された収益サマリーを根拠に、SCでの配当を自動実行。

    • 償還：AssetPortfolio の売却・担保解放等のイベントをトリガーに、ST のバーンと SC の返金を自動実行。

ユースケース

MONは「モビリティに必要な資金が適正に流入する」世界を目指します。BEVや自動運転車の導入は大型投資を要し、成立のためには国や事業者を越えてアセットの真正性と価値を検証可能にすることが不可欠です。MONは、制度・技術・経済の検証可能クレームをMOAに集約し、業界をまたいだ相互運用と資本循環を起動する場を提供します。

以下4つのケースはファイナンスとモビリティの連携を軸に、各ケース固有の課題に対してMONがどのように機能するかを実装イメージとして例示するものです。

(1) 新興国向けのBEV普及

• 課題: 新興国ではBEV普及が政策的に後押しされる一方、車両価格が高く国外資金の呼び込みが鍵です。遠隔地で稼働するフリートの実在性・資産状態・収益力の検証が難しく、投資判断が停滞しがちです。

• MONの貢献: 登録・所有権や保険適合といった制度データ、VIN/OEM起源データやバッテリーSoH等の技術データ、稼働ログや収益実績といった経済データをMOAに束ね、フリート単位のポートフォリオとして提示します。このポートフォリオを必要に応じて規制対応のセキュリティトークンへ翻訳し、地域外のCapitalネットワークからも資金を呼び込めます。運用データはUtility側から継続的にMONへフィードバックされ、トラストが動的に更新されることでデューデリ負担を下げ、調達コストの低減に寄与します。

(2) 地域へのロボタクシー導入

• 課題: レベル4ロボタクシーの地域展開には高額な初期投資と需要の実証が必要で、需要・運行・安全に関する客観データへのアクセスが不足し、継続的投資が生まれにくい現状があります。

• MONの貢献: 運行許認可や保険適合などの制度クレームに加え、自動運転スタックのバージョン/安全イベントログ、稼働・収益ログを地域ポートフォリオに統合します。これにより、自治体・地銀・インフラ投資家といった地域ステークホルダーに向けて透明性の高い投資対象として提示でき、ポートフォリオは必要に応じてST化して資金動員が可能です。運行が進むほどUtility側の実績がTrustに反映され、地域ごとの実績に応じた評価と追加調達がしやすくなります。

(3) BEVフリートの蓄電価値の収益化

• 課題: BEVはモビリティ価値に加え、V2G/VPPなどで電力系統に価値を提供しますが、車両価値・蓄電価値・環境価値を統合的に評価する枠組みが不足しています。

• MONの貢献: 車両側のMOAに電池パスポートやSoHといった技術クレーム、充放電実績や市場収益といった経済クレーム、さらにグリーン電力の由来情報といった環境クレームを重ね合わせ、統合ポートフォリオとして可視化します。必要に応じてST化することで、モビリティ＋蓄電の複合収益を裏付けに設備投資・増車の資金調達を前進させます。実運用の成果はMONに随時反映され、評価が継続的にアップデートされます。

(4) 物流の効率化とグリーントランスフォーメーション

• 課題: 物流の大型化・自動化と動力のグリーン化には大規模投資が必要で、水素の由来（グリーン性）や運行実績など、環境価値と商業価値の双方で検証が求められています。

• MONの貢献: MONは、車両登録や適合性といった制度クレームに、燃料由来証書や車両テレメトリなどの技術クレーム、積載率・回送率・CO₂削減量・収益といった経済クレームを重ね、ESG志向のポートフォリオとして提示します。クラス規約に基づくSFの枠組みにより、同質のフリートを束ねて投資家に開示し、必要に応じてESG債やセキュリティトークンとして資金化が可能です。さらに、共同配送などUtility側の取り組みがTrustへ反映されることで、輸送効率の向上と排出削減の定量化が進み、ESG投資の誘引力が高まります。

今後の発展について

本ペーパーでは、社会システム的存在であるモビリティが大きく変化しようとしている中で、それらがもたらす価値を最大化し、適切な資金循環を促進するために、Mobility Orchestration Network(MON)が必要であることを繰り返し述べてきました。また、その実装に求められる性質を特定し、開発中のプロトタイプ設計を示しました。しかし、このMONという構想を発展させ、現実の社会で機能するネットワークへと具体化していくためには、まだまだ多くの課題が残っています。

多様なネットワークとの接続

MONはトラストを確立することで、ファイナンスを行うCapital Networkと、モビリティサービスが提供されるUtility Networkのなめらかなオーケストレーションを行います。このコンセプトを実現するためには、さまざまなCapital NetworkやUtility Networkと接続を試み、多くのネットワークが求めているものを理解する必要があります。そのため中長期的な観点において、MONとの接続可能性があるセキュリティトークン発行サービスやトークナイゼーションプラットフォーム、またモビリティサービスを展開するプレイヤーと積極的に協力する必要があります。

技術的な選択肢の拡大

本プロトタイプで用いた技術や標準仕様の他にも、さまざまな選択肢が開発されていることにワクワクしています。今回はAvalancheがプロトタイプ要件に適していましたが、MONのコンセプトに照らせば、さまざまなブロックチェーン基盤プロトコル、クロスチェーン通信プロトコル、オラクル/トラストゲートウェイ技術を試し、何がベストなのかを確かめる必要があります。また、プライバシーは引き続き私たちの優先事項であり、ゼロ知識証明やプライバシートークンなど、最先端の暗号技術から学ぶ必要もあります。私たちは特定の技術に固執することなく、今後もさまざまな開発者とのコラボレーションを加速していきます。

標準化コミュニティへの貢献

本プロトタイプではコミュニティで提案されている多くの標準仕様を活用しました。こうした標準化活動は、MONが目指すコンポーザビリティとインターオペラビリティの向上に必要不可欠です。プロトタイプ開発で得た知見をコミュニティにフィードバックします。標準の安定性は、企業がオンチェーンの世界に進出する上でとても重要な要素です。それらが促進されるよう、コミュニティが産業を理解できるように、その活動を支援していく必要があります。

トヨタ・ブロックチェーン・ラボについて

トヨタ・ブロックチェーン・ラボは、トヨタグループ横断のブロックチェーン探求組織として2019年に設立されました。モノとデータの真正性・トレーサビリティを起点に、金融・モビリティ・Web3の交点で社会実装を見据えた研究開発を推進しています。「モビリティを社会インフラへ」を掲げるトヨタのMobility 3.0実現に向け、モビリティのアイデンティティ層「Mobility Oriented Account（MOA）」と複数の専門ネットワークを連携させる「Mobility Orchestration Network（MON）」を中核に、社会システムの繋がりを構築します。私たちは、革新的な暗号技術や分散型システムアーキテクチャを、適切な法規制・セキュリティ・ガバナンスと調和させながら企画から運用まで一貫して推進します。多様なパートナーとのエコシステム構築を通じて、次世代のモビリティ基盤となる標準化とオープンイノベーションに貢献します。