結論からいえば、Moca Chainはゲーム実績、会員資格、本人確認結果などを、利用者が複数のサービスで提示し直せるようにするデジタルID基盤です。2026年9月29日にメインネットが公開され、資格情報の発行・保存・検証を支えるチェーンが本番環境へ移りました。ただし、発表された提携規模や到達可能な利用者数は、すべてが現在の実利用を示すものではありません。
先にゲームの例で流れを示します。ゲーム会社Aが大会完了を確認して資格を発行し、利用者がAIR Accountで保持します。利用者がゲーム会社Bへ必要な資格だけを提示すると、Bは発行元、署名、有効期限、失効状態を検証し、条件を満たす人へ先行アクセスを付与します。Aが誤発行や期限切れを登録すれば、Bは次の確認時に失効を反映できます。この発行・保存・提示・検証・失効を支える基盤がMoca Chain、企業と利用者がそれを組み込んで使う製品群がAIRです。
以下では、この流れを軸に、ゲーム実績やKYCを再利用できる条件、段階別の導入状況、残る注意点を説明します。
2026年10月2日を最終確認日とし、Moca Foundation、Moca Network、W3C、NISTなどの一次資料を優先しました。会社発表の構想・対象規模と、確認できた本番稼働・実測値は区別して記載しています。
- Moca ChainはID用途に重点を置くEVM互換のレイヤー1です。
- AIRはチェーンそのものではなく、企業がID・決済・ロイヤルティを組み込むための製品層です。
- 資格情報を持ち運べるかは、技術だけでなく発行者への信頼、共通形式、受け入れ側の実装と法的判断に左右されます。
Moca Chainメインネット公開で何が始まったのか
2026年9月29日にメインネットが稼働
Moca FoundationとMoca Networkは2026年9月29日、Moca Chainのメインネット公開を発表しました。テストネット上の試行だけでなく、本番用ネットワークで資格情報に関する処理を扱う段階へ進んだことが今回のニュースの中心です。Animoca Brandsの公式発表では、人、企業、AIエージェントがプライバシーに配慮しながらIDを利用するための基盤と説明されています。
ここでいう公開は、想定される全サービスが一斉に本番稼働したという意味ではありません。チェーンが利用可能になったことと、提携企業の各機能が一般利用者向けに稼働することは別の出来事です。導入先ごとに、計画、テストネット、限定提供、本番という段階を確認する必要があります。
EVM互換のID特化L1として設計
Moca Chainは、独自の取引履歴と合意形成を持つレイヤー1(L1)であり、Ethereum Virtual Machineと互換性を持つ設計です。報道ではチェーンIDが2288とされています。EVM互換であることは、Ethereum向けの開発知識やツールを応用しやすいことを意味しますが、Ethereumと同じセキュリティや分散性が自動的に得られるという意味ではありません。
ブロックチェーンの基本を踏まえると、一般的なL1が送金や幅広いアプリ実行を前面に出すのに対し、Moca Chainは資格情報の発行、暗号化した保存、証明の生成、検証、状態更新を中心用途に置きます。公式サイトは分散ストレージ、IDオラクル、zkTLS、オンチェーンのゼロ知識証明検証を中核要素として掲げています。新しいコインの送金網としてだけ見るより、IDに関する共通処理を行う土台として見る方が本質をつかみやすいでしょう。
Moca ChainとAIRの役割はどう違うのか
まなぶ「クリプ先生、Moca ChainとAIRは同じサービスなんですか? 名前が並んでいて混乱します。」
クリプ「同じではないんだ。Moca Chainが共通の基盤、AIRが企業や利用者から見える機能をまとめる製品層、と考えると整理しやすいよ。」
Moca Chainは資格情報を支える基盤層
Moca Chainの役割は、資格情報に関する共通ルールと検証可能な記録を支えることです。ある企業が会員資格を発行し、別のサービスがその資格の真正性や有効状態を確かめる場面では、誰が発行したか、証明が改ざんされていないか、必要な検証処理が成立するかを基盤層が扱います。
ただし、利用者の個人情報を何でも公開台帳へ書き込む構想ではありません。公式説明は、暗号化されたデータの保存やゼロ知識証明を利用し、元データそのものではなく条件を満たすという証明を渡す方向を示しています。この区別はプライバシーを考えるうえで重要です。
AIRは企業と利用者をつなぐ製品層
AIRは、企業がID、決済、ロイヤルティをサービスへ統合するための製品群です。企業は自社で確認した情報を資格として発行する側にも、信頼できる別の発行者が作った資格を受け入れる側にもなれます。毎回同じ確認を最初から繰り返すのではなく、既存の確認結果を条件付きで再利用できるようにする発想です。
たとえるなら、Moca Chainが鉄道の線路や信号のような共通基盤で、AIRは利用者が触れる改札や乗車券、事業者向けの運行ツールに近い関係です。線路が開通しても、すべての駅が同時に営業を始めるわけではありません。同様に、チェーン公開とAIR導入先の本番提供は分けて確認します。
AIR Account・AIR ID・AIR Credentialの関係
AIRの説明では、AIR Account、AIR ID、AIR Credentialが役割を分担します。AIR Accountは利用者がサービスへ接続する入口で、ウォレット、メール、パスキー、セッションキーによる認証を支える設計です。暗号資産ウォレットに慣れていない人も含めた利用を意識した構成と読めます。
AIR IDはサービスをまたいで利用者を識別するための層、AIR Credentialは年齢、会員状態、ゲーム実績など個別の主張を証明する資格情報です。アカウントは「どう入るか」、IDは「誰にひもづくか」、Credentialは「何を証明できるか」と分けると理解しやすくなります。具体的な復旧方法や事業者側の運用は各サービスの実装確認が必要です。
資格情報を再利用する仕組み
発行者・保有者・検証者で成立するモデル
検証可能な資格情報は、基本的に発行者、保有者、検証者の三者で成り立ちます。発行者は情報を確認して資格を作る組織、保有者はその資格を管理して提示する利用者、検証者は提示された資格が信頼できるか確かめるサービスです。W3CのVerifiable Credentials Data Model v2.0も、この関係を標準的なモデルとして扱っています。
例として、ゲーム運営会社Aが「特定イベントを完了した」という資格を利用者へ発行し、ゲーム運営会社Bがそれを検証して参加特典を提供する流れを考えられます。BはAを信頼できる発行者として受け入れ、資格の形式を理解できなければなりません。チェーンに記録があるだけで、あらゆるサービスが自動的に意味を理解するわけではありません。
必要な属性だけを相手に示す選択的開示

選択的開示は、書類全体を渡さず、必要な条件だけを証明する考え方です。年齢制限のあるサービスなら、生年月日や住所を丸ごと見せる代わりに「基準年齢以上である」という確認結果だけを提示する使い方が想定されます。KYCでも、本人確認書類の画像そのものではなく、信頼された発行者が確認済みであることを示す方向です。
NISTの利用者管理ウォレットに関する資料も、検証可能な資格を単なる画像コピーではなく、発行者が署名した属性を端末に結び付けるデジタル記録として説明しています。元データの共有を減らせれば受け手が保管する機微情報を減らせます。一方、提示時刻、接続元、同じ資格の利用パターンなどのメタデータから関連付けられる可能性は残ります。
まなぶ「ゼロ知識証明なら、相手には何も知られないんですか?」
クリプ「何も知られないわけではないよ。必要な事実だけを示しやすくする技術だけれど、接続履歴や発行者、端末の安全まで自動で守るものではないんだ。」
更新・失効を接続先へ反映する設計
資格は一度発行したら永久に正しいとは限りません。会員期限が切れる、免許が停止される、誤発行が判明するといった場合には、更新や失効の状態を検証者が確認できる必要があります。Moca Chainの発表は、資格の更新・失効をネットワークへ反映し、接続アプリが変更を検知できる設計を示しています。
W3CのBitstring Status List v1.0は、資格の失効や停止などをプライバシーに配慮しながら効率よく公開する標準的な方法を定めています。ただし、標準が存在することと、Moca Chain上のすべての資格がその標準に完全準拠することは同じではありません。発行者の迅速な更新、検証者の状態確認、障害時の扱いまで含めて初めて機能します。
ゲーム実績や会員資格はどこまで持ち運べるのか

実績・参加履歴・会員資格を証明に変える
ゲーム領域では、特定ステージの達成、プレイ履歴、イベント参加、コミュニティ会員資格、報酬条件などを資格情報として表す用途が想定されます。NFTのようにアイテム自体を移す場合とは異なり、「ある条件を達成した事実」を証明として持ち運ぶ点が中心です。
前作で大会に参加した人へ新作の先行アクセスを与える、複数タイトルで一定の実績を持つ人へコミュニティ役割を付ける、といった設計が考えられます。しかし、資格が示す意味は運営者が定義します。「レベル50」が別作品でも同じ強さを意味するわけではなく、受け入れ側は何を特典条件として採用するか決めなければなりません。
資格に応じて特典や報酬を出し分ける
資格を利用すると、利用者の属性や履歴に応じた特典を設計できます。イベント参加資格を持つ人だけに記念アイテムを配る、会員ランクを確認して割引を変える、確認済み条件に応じて報酬を出す、といった用途です。事業者は自社で一から履歴を集めなくても、信頼する発行者の証明を判断材料にできる可能性があります。
一方、資格に報酬を結び付けると、不正取得、複数アカウント、資格売買、発行者の審査品質といった問題が生じます。暗号学的に改ざんを検出できても、発行前の判断が間違っていれば、誤った内容が正しく署名されることがあります。技術は発行者の判断そのものを保証しません。
持ち運びには共通スキーマと運営者の受け入れが必要
ゲーム実績の持ち運びには、発行者と受け入れ側が資格項目の意味を共有すること、受け入れ側が発行者を信頼すること、資格を検証してゲーム内処理へつなぐ実装があることが必要です。共通スキーマは、項目名だけでなく達成条件や有効期限も含めて解釈をそろえる役割を持ちます。
したがって、Moca Chainが公開されたからといって、既存ゲームの実績が自動的に全タイトルへ移るわけではありません。ポータビリティは「持ち運べる形式」と「持ち運びを認める契約・運用」の両方がそろって成立します。技術的な相互運用性と、ビジネス上の受け入れは分けて考えます。
導入状況を本番・ベータ・計画で整理

【提携・計画】KYC資格を扱うzkMe
Moca Networkは2025年7月、zkMeが人口統計・金融関連の資格発行者としてMoca Chainへ参加する計画を発表しました。対象として年齢、国籍、所在地、信用スコア、適格投資家資格が挙げられ、再利用可能な資格として発行する構想です。提携発表では150万人の利用者という規模が示されています。
対象は年齢・国籍などの属性資格、段階は提携・導入計画です。150万人は提携先が示したオンボーディング規模で、メインネット上の発行済み資格数や継続利用者数は確認できていません。KYC資格を受け入れる法的判断も別途必要です。
【テストネット/ベータ】MocaProof
MocaProofは、資格検証と報酬を組み合わせたレピュテーション体験として、2025年12月にMoca Chainテストネット上でベータ公開されました。検証した資格に応じて仮想キャラクター「Mocat」の特性や希少性が変わる設計で、抽象的になりやすい資格情報をゲーム的な体験へ落とし込む例です。
対象は資格検証と報酬の体験、段階はテストネット上のベータです。メインネットへの移行、継続利用者、資格の発行・検証件数は、この発表だけでは確認できません。
【本番・計画】AIR ShopとBiletinial
トルコのチケット事業者Biletinialとの提携では、AIR Kitを統合し、年齢、地域、イベント参加履歴、消費傾向など利用者の許諾に基づく資格を扱う計画が示されました。チケット購入や来場履歴を別の特典や会員体験へつなぐ想定です。発表の600万人は計画の対象になり得る利用者基盤であり、資格利用件数とは区別します。
AIR Shopは2025年10月、BaseとMoca Chainテストネットで開始され、資格に連動するロイヤルティ特典を提供しました。当時の説明ではMoca Chainメインネット対応は将来予定でした。メインネット公開後の評価では、古い発表の時制を現在へ移さず、実際の対応状況を更新情報で確かめる必要があります。
会社推計の到達可能層7億人は実利用者数ではない
調査資料によると、7億人はAnimoca Brandsのエコシステムなどを通じた到達可能な利用者層を表す会社推計であり、Moca Chainの実利用者数ではありません。一方、AIR口座は330万と説明されています。両者は母数も意味も異なります。
到達可能層は配布や提携の潜在範囲、口座数は作成されたアカウント、アクティブ利用者は一定期間に実際に使った人を示します。さらに資格の発行数、提示数、検証数も別です。普及を評価するなら、一つの大きな数字ではなく、何を数えた指標かを確認しましょう。
プライバシーを支える技術とMOCAの用途
分散ストレージ・IDオラクル・zkTLS・ZK検証
公式解説は中核技術を四つに整理しています。分散ストレージは暗号化されたデータを扱う保存層、IDオラクルは外部のID情報や確認結果をチェーン上の処理へつなぐ役割、zkTLSはウェブ上のデータについて元内容をすべて公開せず証明を作る技術、オンチェーンZK検証は生成された証明をチェーン上で確かめる仕組みです。
これらは開示する情報量を減らし、サービス間で検証可能性を持たせるための部品です。しかし、部品名が並ぶことだけでは、安全な実装、十分な性能、障害への耐性、分散性は判断できません。暗号ライブラリ、回路、スマートコントラクト、鍵管理、オラクル運用、保存層の可用性など複数の層が正しく機能する必要があります。
MOCAが担うガス・ステーク・資格関連手数料
MOCAはMoca Chainの設計上、ネットワーク上のガス、ステーク、資格の発行・保存・検証、IDオラクルなどの手数料に使われます。MiCA Whitepaperでは、取引、データ生成・保存・検証、AIエージェント検証、DAO統治に関する用途も説明されています。利用者が直接MOCAを用意する必要があるか、事業者が裏側で負担するかは各アプリの設計で変わり得ます。
ステークはネットワーク運用や経済的な安全設計に関係しますが、実際のバリデータ数、運営主体の分布、参加条件、集中度を確認しなければ分散性は評価できません。用途の一覧はネットワーク内で何に使うかを示すものであり、利用量や収益を保証するものでもありません。
トークン用途と投資価値を分けて考える
「手数料に使われる」「ステークできる」という説明から、価格上昇や投資収益を直接導くことはできません。価格は供給、需要、市場流動性、規制、保有集中、解除スケジュールなど多くの要因で変動します。ネットワーク利用が増えても、手数料設計や事業者の負担方法によってトークン需要への影響は異なります。
この記事はMoca Chainの機能を理解するためのもので、MOCAの購入を勧めるものではありません。利用目的と投資判断を分け、投資を検討する場合は公式開示、リスク、居住地域での取扱い、自身の損失許容度を別途確認する必要があります。
AIエージェント向けIDは実装済みなのか
まなぶ「AIにIDがあると、人間の代わりに何でも任せられるようになるんですか?」
クリプ「何でも、では危険だよ。誰の代理か、何をいつまで許すか、いくらまで支払えるか、途中で取り消せるかを確認できる仕組みが必要なんだ。」
AIエージェントに必要な固有IDと委任管理
AIエージェントが人の代わりに予約、購入、情報取得などを行う場合、サービス側は単にプログラムへログインを許すだけでは足りません。どの人や組織がそのエージェントを動かしているか、どの権限を委任したか、実行結果を誰にひも付けて監査できるかが必要です。
OpenID FoundationのAgentic AIに関する資料は、高い自律性を持つエージェントに固有ID、拡張可能なアクセス制御、委任権限の管理が必要だと整理しています。Moca ChainとAIRは、人とAIエージェントの関係を資格として検証できる基盤を訴求しています。これは今後重要になる課題への設計方向を示すものです。
権限範囲・期限・取消し・支払い上限の論点
実用上は「この店舗で商品を検索する」「今日中に一定条件の予約を行う」「指定額まで支払う」のように権限を細かく限定する必要があります。権限の有効期限、用途、対象サービス、支払い上限を機械が解釈でき、利用者が後から取り消せることも重要です。サービス側が古い権限を使わないためには、失効状態を実行前に確認しなければなりません。
さらに、AIが誤った判断をした場合の責任、操作記録、異議申立て、緊急停止も必要です。IDを証明できることと、行動が安全・適法・望ましいことは別です。委任資格は「誰からどの範囲を任されたか」を示す部品であり、AIの出力品質を保証する証明書ではありません。
現在利用できる機能と将来計画を分ける
メインネットとゼロ知識証明の検証機能は公開時点で利用可能と報じられています。一方、AIエージェント向けの包括的な委任、権限管理、支払い制御については、発表の訴求とロードマップ上の計画を分けて読む必要があります。第三者報道も、AI関連機能の一部を将来機能として扱っています。
判断するときは、デモや構想の説明だけでなく、一般開発者が使える仕様、SDK、権限取消しの実装、利用中のサービス、監査結果を確認します。「AIエージェントに対応」という一文だけでは、どの機能が本番で強制されるかまでは分かりません。
Moca Chainの現在地を判断するための注意点

ゼロ知識証明だけでは解消しないリスク
ゼロ知識証明は、必要以上の情報を相手へ開示しないために有用です。しかし、発行者が誤った属性を認定するリスク、利用者端末や鍵が侵害されるリスク、複数回の提示から同一人物を推測されるリスク、通信や利用時刻などのメタデータが漏れるリスクは別に残ります。
ウォレットの鍵を紛失した場合の復旧も重要です。復旧を簡単にすれば第三者による乗っ取り経路が増え、厳格にすれば本人でも資格へアクセスできなくなるおそれがあります。誰が復旧を承認するのか、古い鍵をどう無効化するのか、復旧中の資格提示をどう扱うのかは具体的な運用確認が必要です。
他社KYCを受け入れられるかは用途と法域次第
一度の本人確認結果を再利用できれば、利用者の入力負担と事業者の重複確認を減らせる可能性があります。しかし、規制事業者が他社のKYC結果を法的に受け入れられるかは、国・地域、業種、取引内容、リスク評価によって異なります。資格を技術的に検証できることは、規制上の義務を果たしたことと必ずしも同じではありません。
受け入れ側は、発行者の審査基準、確認時期、利用した証拠、更新頻度、制裁・マネーロンダリング対策、記録保持を確認する必要があります。資格が有効でも追加確認が必要になる場合があります。「KYCを一度すればどこでも使える」と理解するのは早計です。
W3C標準との準拠・相互運用性は要確認
W3C VC 2.0は、資格情報のデータモデル、発行者・保有者・検証者の関係、セキュリティやプライバシーを扱う国際標準です。共通標準に沿うことは相互運用の助けになりますが、Moca Chainとの完全な準拠や、他ウォレット・他チェーンとの互換性は個別に確認する必要があります。
同じ「VC対応」を掲げる製品でも、証明方式、識別子、スキーマ、状態確認、ウォレットの保存形式が異なることがあります。実際の相互運用性は、別の発行者が作った資格を別のウォレットで保持し、別の検証者が正しく読み取れるかという試験で確認します。標準名の表示だけで互換性を断定しない姿勢が必要です。
普及を測るために今後確認したい指標
取引量と実利用アカウント数
まず確認したいのは、メインネットの取引数、継続的に利用するアカウント数、資格の発行・提示・検証件数です。通常の送金やテスト処理を資格利用と混同しないため、取引の内訳も重要です。口座作成数だけでなく、一定期間に資格を使った利用者や再利用率が分かれば、日常的な需要を判断しやすくなります。
公開時の発表には、メインネット取引量などの運用データが十分に示されていないと第三者報道が指摘しています。公開直後に長期実績がないのは自然ですが、そのため現段階では潜在規模より、今後継続して開示される実測値を重視すべきです。
バリデータの数・分布と独立監査
L1の信頼性を判断するには、バリデータの数だけでなく、運営主体、地域、ステーク集中、停止時の影響を確認します。少数の関係主体へ集中していれば、検閲耐性や障害耐性の評価が変わります。公開発表ではバリデータ構成・分布の詳細が示されていないため、今後の開示項目です。
コードや暗号回路、ブリッジ、オラクル、鍵管理の独立監査が公開されているか、指摘事項がどう修正されたかも確認したい点です。監査は無事故を保証しませんが、検証範囲と残存リスクを把握する材料になります。
提携先別の本番稼働と資格の利用件数
提携発表の数より、各提携先で何が本番稼働しているかを見ます。確認項目は一般利用開始日、対象地域、発行される資格、受け入れるサービス、発行・検証件数、利用者が許諾や削除を管理できる画面です。計画発表、開発中、テストネット、限定提供、一般提供を分けると進捗を誤読しにくくなります。
特にゲーム実績の持ち運びでは、複数の独立した運営会社が同じ資格を受け入れた事例が重要です。一社の系列内だけで利用する場合と、異なる企業間で相互運用する場合では難易度が違います。どの発行者を誰が信頼し、どのスキーマが共通化されたかを確認しましょう。
失効・鍵復旧・障害対応の実績
ID基盤は、正常時の発行だけでなく例外処理で評価されます。誤発行をどれだけ早く失効できたか、紛失した鍵を本人が安全に復旧できたか、発行者やネットワークの障害中に検証をどう扱ったか、障害後に原因と対策を公開したかが重要です。
メインネット公開直後は長期の障害履歴や復旧実績が乏しいため、現時点で成熟度を断定することはできません。サービス停止時間、状態更新の遅延、復旧時間、インシデント報告を継続して見ることで、設計上の主張が運用でも機能するかを判断できます。
まとめ:Moca Chainは資格情報の実利用で評価する段階へ
現在地は「本番基盤は公開済みだが、異なる事業者間での継続的な資格利用はこれから実測する段階」です。Moca Chainは基盤、AIRは利用者・企業向け製品であり、ゲーム実績やKYCの再利用には発行者への信頼、共通スキーマ、受け入れ実装、更新・失効、法的判断がそろう必要があります。
\n今後は、①資格の発行・検証件数、②独立企業間で本番利用される資格の種類と継続率、③失効・鍵復旧・障害対応の実績を確認してください。到達可能層や提携数より、この3点が構想を実利用として評価する材料になります。
