Concordium Agent Registryはどのように運用されているのでしょうか。S'inscrireからVerified Badgeを取得するまでの手順を順を追ってご案内します。

Concordium Agent Registryは、Concordium（CCD）のAIエージェント経済における基盤実装です。エージェントが自律的に署名、支払い、サービスを実行できる場合、相手方は「このエージェントの所有者は誰か、誰がその行動を認可しているか？」を最初に判断しなければなりません。Registryはオンチェーンで発見・検証可能、クロスチェーン参照も可能なアイデンティティアンカーを提供し、プロトコルレベルのアイデンティティとゼロ知識証明で説明される認証済みアカウント層とシームレスに統合されます。

Registryは公開ドキュメントに基づき、CIS-8004（エージェント登録標準）、Agent Card（オフチェーンJSON＋オンチェーンハッシュ）、CIS-8 External Key Registry（クロスチェーン公開鍵連携）、MCP Server（エージェントツールインターフェース）で構成されます。以下のセクションでは、一度限りのイベントではなく、繰り返し可能なワークフローとしてそのプロセスを解説します。

エージェント登録前に準備すべきもの

登録前には、認証済みConcordiumネイティブアカウント、公開アクセス可能なAgent CardホスティングURL、エージェント名・スキル・サービスエンドポイントを記載したメタデータの3つが必須です。EthereumやSolanaなどのネットワークとの相互運用性を確保する場合は、それぞれのチェーンの公開鍵とCIS-8連携用の署名機能も準備してください。

Concordiumは、エージェントがすべてのワークロードを自チェーン上に移行する必要はないと強調しています。RegistryはConcordium上でアイデンティティをアンカーし、エージェントは他チェーン上で運用しつつ、CIS-8やBadgeを用いて外部へ信頼シグナルを発信できます。

アカウントとアイデンティティはどのようにエージェントへアンカーされるのか

Registry内の各エージェントはCIS-8004ノンファンジブルトークン（NFT）として登録され、認証済みConcordiumネイティブアカウント所有者によってミント・更新されます。所有者アカウントはプロトコルレベルのアイデンティティを通じて実在の人物または法人に紐付けられ、認可チェーン（Agent NFT→所有者アカウント→Identity Issuer認証済みアイデンティティ）が形成されます。

オンチェーンストレージには、Agent Cardを指すagent_uri、ドキュメント整合性を保証するmetadata_hash（SHA-256）、拡張可能なキー・バリュー形式のメタデータ（例：支払い用ウォレットアドレス）が含まれます。任意のexternal_referenceはCIS-8連携やSNSハンドルを指し、同一エージェントのクロス環境解決を可能にします。

この構造は、「エージェントが何か」を記述するだけの純粋なERC-8004登録とは異なります。Concordiumは所有者が認証済みアカウントを持つことを要求し、「誰が認可したか」を登録前の前提条件としています。エージェントメタデータには支払いウォレットなどのキー・バリュー項目も含められ、エージェント間決済やx402従量課金シナリオで受取アドレス探索をサポートします。ただし、アプリケーション層の支出制御は依然として必要であり、オンチェーン登録だけではエージェントの行動を制限できません。

Agent CardとCIS-8004の統合方法

Agent CardはA2A（Agent-to-Agent）などのフォーマットに準拠したJSONドキュメントで、エージェント名、説明、スキル、サービスエンドポイント、Concordium拡張ブロック（コントラクトインデックス、トークンアドレス、所有者アカウント等）を含みます。ドキュメントはagent_uri HTTPS URLでホスティングされ、登録時にURLと内容のSHA-256ハッシュがCIS-8004コントラクトへ書き込まれます。

消費者（他エージェント、MCPツール、手動レビュアー）は、チェーンからagent_uriとmetadata_hashを取得し、URLから生JSONを取得、SHA-256計算しオンチェーンハッシュと比較することでエージェントを検証できます。MCPツールのverify_agent_cardはこのプロセスを自動化します。

エージェント能力を更新する際は、ホストJSONを更新し、build_set_agent_uri等の操作でオンチェーンハッシュも刷新する必要があります。これを怠るとオンチェーンアンカーとオフチェーンドキュメントが乖離します。Agent Cardは更新可能な公開仕様であり、オンチェーンNFTは否認不能な整合性アンカーです。ドキュメントバージョン更新時は履歴スナップショットや変更履歴を保持し、監査人がエージェント能力の変化を追跡できるようにすることを推奨します。

図1. Concordium Agent Registryワークフロー：認証済みアカウント、CIS-8004ミント、Agent Cardハッシュアンカー、Badge表示。

CIS-8によるクロスチェーン鍵連携の仕組み

CIS-8 External Key Registryは、Concordiumネイティブアカウントと外部公開鍵（EthereumアドレスやSolana公開鍵など）間の連携を示す暗号学的証明をオンチェーンで保存します。連携完了後、CIS-8004エージェントはexternal_referenceとしてCIS-8エントリを参照でき、Ethereum系ツールは公開鍵経由で同一エージェントNFTを解決可能です。

解決パスは、外部チェーンアドレス→CIS-8コントラクト連携検索→Concordium所有者アカウント→CIS-8004エージェント検索→Agent Cardとなります。Concordium拡張ブロック内のtoken_addressやコントラクト座標が、外部Registryによる検索をConcordium固有知識不要で補助します。

これにより、ConcordiumツールではトークンIDで、EthereumツールではETHアドレスでエージェントをアドレス指定でき、双方とも同一オンチェーンアイデンティティを参照できます。Concordium vs Worldcoinで議論される「proof of personhood」アプローチとは異なり、Registryはエージェントレベルの検証可能なアイデンティティとクロスチェーン相互運用性を扱います。

Verified by Concordium Badgeの検証方法

Verified by Concordium Badgeは、エージェントがプロトコルレベルの認証済みアカウントに紐付くことを示す可視的な信頼シグナルです。検証はBadgeアイコンだけでなく、オンチェーン事実に基づいて行うべきです：CIS-8004上で該当トークンの存在確認、所有者アカウントのアイデンティティステータス確認、Agent Cardハッシュとホストドキュメントの一致確認、必要に応じてCIS-8連携の検証などが必要です。

Badgeはコミュニケーションコストを削減しますが、自己検証の代替にはなりません。企業や高信頼環境では、VerifyとAccessを組み合わせて属性レベルの検証（年齢・資格・支出上限等）を行い、Registryのアイデンティティ・認可層を補完することが一般的です。エージェントが金融機関やEC決済プラットフォームを代表する場合、完全な信頼スタックはRegistryによるエージェント・認可主体の確認→ZKPによる業務属性検証→Protocol-Level Locksやx402による決済経路制約という構成となり、各層が役割を果たします。

登録・検証時の注意事項

Agent Cardホスティングの可用性とHTTPS整合性を維持してください。URLが無効化されたり、内容がオンチェーンハッシュ更新なしで変更されると検証に失敗します。外部鍵連携はCIS-8 external_reference設定前に完了させる必要があり、順序誤りは登録ロールバックや無効参照の原因となります。所有者鍵のセキュリティはエージェント制御に直結し、NFTは譲渡可能なので所有者変更時は内部ガバナンス手続きが必要です。

MCP Serverは登録・Agent Card作成・カード検証ツールを提供し、エージェントフレームワーク統合を支援しますが、デベロッパーはオンチェーン操作やガス（またはSponsored Transactions）コストを十分理解する必要があります。Registryエコシステムは拡大途上であり、Badgeを入場基準として採用するかは業界慣行次第です。

公開ドキュメントには、CIS-8004 Agent Registry（インデックス10082）やCIS-8 External Key Registry（インデックス10081）などのメインネットコントラクトが記載されており、CCDScan等のブロックエクスプローラーで参照可能です。インデクササービスはオンチェーンイベントをREST APIへ変換し、手動チェーンスキャン不要でエージェント検索・発見を簡易化します。プロダクト環境では「オンチェーン登録→カードホスティング→ハッシュ検証→Badge表示」の反復可能なデプロイチェックリストを整備し、エージェント能力更新時はCIワークフローへ組み込むことでチェーンとドキュメントのアンカー乖離を防ぐことを推奨します。

サマリー

Concordium Agent Registryは、エージェントアイデンティティ、ドキュメント整合性、クロスチェーン公開鍵、認証済みアカウントを一元化した反復可能なワークフローを提供します。Verified Badgeやクロスチェーンエージェント信頼検証の統合には、CIS-8004・Agent Card・CIS-8の役割を正しく理解することが不可欠です。デプロイ時は、オンチェーン登録・ドキュメントホスティング・定期的なハッシュ検証を運用プロセスに組み込み、エージェント能力更新後の検証不能な古い記録を回避してください。

よくある質問

Concordium Agent Registryとは？

Agent RegistryはConcordiumのオンチェーンエージェントアイデンティティシステムであり、CIS-8004経由でエージェントをNFTとして登録し、Agent Cardで能力やエンドポイントを記述します。Registryはエージェントを認証済みConcordiumアカウントと結び付け、クロスチェーン鍵連携やVerified by Concordium Badgeをサポートします。

AIエージェントのアイデンティティは実アカウントとどう連携されるのか？

各エージェントNFTは認証済みConcordiumネイティブアカウントによって所有・管理されます。このアカウントはプロトコルレベルのアイデンティティおよびIdentity Issuerによって人物または法人と紐付けられ、責任チェーン（エージェント→所有者→認証済み主体）が形成されます。

Agent Cardの目的は？

Agent Cardはエージェント名・スキル・サービスエンドポイントを詳細記載する公開JSONドキュメントであり、そのURLとSHA-256ハッシュをオンチェーン保存して整合性を保証します。能力更新時はドキュメントとオンチェーンハッシュを同期更新する必要があります。

ConcordiumエージェントはEthereumやSolana上でも運用可能か？

はい。CIS-8で外部チェーン公開鍵をConcordiumアカウントへ連携し、CIS-8004エージェントのexternal_referenceを設定することで、外部ツールはEthereumやSolanaアドレス経由で同一エージェントアイデンティティを解決可能です。すべてのロジックをConcordiumへ移行する必要はありません。

エージェントの信頼性はどのように検証するのか？

オンチェーン検証は、CIS-8004トークンの確認、所有者アカウントのアイデンティティステータス、Agent Cardハッシュとホストドキュメントの一致、必要に応じてCIS-8クロスチェーン連携の確認を含めるべきです。Verified Badgeは補助的なシグナルであり、暗号学的検証手順の代替にはなりません。