AI Agent x Verifiable Credentials共同実証報告セッション資料

https://peatix.com/event/5167709/

上記イベントでの登壇資料

Transcript

1. AIエージェント同⼠が 企業間で商取引を完結させる Verifiable Credentials による組織横断の相互認証：設計と実証 共同研究：GMOグローバルサイン‧ホールディングス株式会社 × VESS Labs 2026/10/14
2. ⾃⼰紹介 神沼 貴⼤ • GMOグローバルサイン‧ホールディングス R&Dリード • エンジニア経歴 • SIer - ⾦融‧建設‧旅⾏業界の業務システム開発(アーキテクチャチームで Java FW 拡張など) • GMOグローバルサイン - グローバル環境の電⼦証明書発⾏サービス開発 • GMOグローバルサインHD - AI/IoT サービスのクラウドインフラやデータ基盤構築 • 2021年からアイデンティティ領域（特に Verifiable Credentials）の研究開発を担当
3. ⾃⼰紹介 藤森 侃太郎 • 株式会社VESS Labs 代表 • VCを活⽤し、以下ソリューションの開発提供 • デジタル証明管理プラットフォーム「VESS Credentials」 • デジタルアイデンティティウォレット「VESS Wallet」 • AI時代のアイデンティティを⽀える「VESS AIdentity」
4. 本実証の概要
5. 概要説明 コンセプト A2A の Agent Card をVC化し、 Agent の⾝元を「その場で確認できる」ものにする
6. 概要説明 課題感: ⾃⼰申告から、検証できる⾝元へ • A2A の Agent Card は、Agent が⾃分で名乗っているだけの⾃⼰申告。 本当にその組織の Agent か、その能⼒を持つかの証明は信頼に⾜らない。 ↓ • Agent Card の内容を審査機関(Issuer) が認定し、Verifiable Credential (Agent Identity VC)として発⾏する。 • 提⽰‧検証場⾯では、VCが属するTrust Chain上の共有Root of Trustまで辿る。 それだけで、接続したその場で⾝元を確認できる。
7. 概要説明 イメージ図
8. 概要説明 全体概要図‧モデル 本実証のスコープ外 (Root CAとIssuerを仮想的に設定し、 X509証明書およびVCを自己発行) Root CA 審査・認定 （X.509証明書発行） 登録申請 Agent審査機関（Agent Identity VC Issuer） Agent Identity VC発行申請 （Agent Card申告 ） Agent Card審査（所属・能力）とVC発行 Agent間の連携 Agent （買い⼿企業） 購買の委任 AP2 購買フロー 独自仕様(UCPライク) VC/VP周り 独自仕様 やりとり A2A Agent （売り⼿企業）
9. 概要説明 Agent CardをVC化する意味：3つのポイント ① A2A仕様の署名との違い (Provenance vs Trust) • 署名が⽰すのは出所( = ドメイン)まで。Agent Card情報は⾃⼰申告に留まる。 • VC 化 + Trust FW で、第3者審査機関(Issuer) による認定を証明する。 ② Pairwiseな事前合意なしに検証できる (スケーラビリティ / 運⽤効率) • VC + 共有 Root of Trust なら、各参加者は信頼の起点を1つ持つだけで良い。 • 初対⾯の相⼿でもその場で確認できる。 • ⾃分が直接的に、個別に、相⼿AgentもしくはAgent Registryを審査しなくてよい。 ③ 範囲は⾝元確認まで • 購買権限は Agent Identity VC の範囲外。 • 取引ごとに発⾏される委任状（AP2 Mandate VC）が担う。
10. デモ AP2 Human Present / Human Not Present フロー
11. デモ ⽤語整理：買い⼿‧売り⼿Agent以外のエンティティ Trusted Surface 署名を担う信頼された仲介者 Credential Provider MPP ⽀払い⼿段の管理‧決済トークン発⾏ Merchant Payment Processor 役割 (Agent Provider Model) 役割 役割 ユーザーの承認を受けて注文・決 済 Mandate に署名する、信頼され た仲介者(代理署名者) ユーザーの支払い手段を管理し、 closed Payment Mandate を検証 したうえで、決済用トークン（ payment token）を発行する 決済代行事業者。 実際の決済ネットワークとやり取 りして決済を実行し、 結果（payment_receipt）を返す 補足 補足 補足 売り手(Merchant)やCredential Providerに信頼されている必要。 Agentとは別の鍵で運用する。 本PoC：買い⼿企業が兼務 買い手 Agent（Shopping Agent） からアクセスされる。実運用では コーポレートカード発行会社やデ ジタルウォレット事業者が相当 本PoC：モック実装 売り手 Agent（Merchant）からア クセスされる 本PoC：対象外
12. デモ ⽤語整理：AP2 Mandate VC (誰から誰に何を委任) open 「枠だけ先に決める予約」 open Checkout Mandate Checkout 「何を買うか」 Payment 「それにどう払うか」 Human Not Present ユーザー → Agent (Trusted Surfaceを通して) closed 「中⾝まで確定した本申込み」 closed Checkout Mandate Human Present ユーザ → Shopping Agent (Trusted Surfaceを通して) この確定済み注⽂の実⾏の委任 このSeller‧この商品候補‧この数量の範囲内でなら買っ てよい」という購⼊条件の範囲の権限の委任 Human Not Present Agentがopenで委任された権限を実際に⾏使したことの 証明 open Payment Mandate closed Payment Mandate Human Not Present ユーザー → Agent (Trusted Surfaceを通して) 「この予算上限‧この⽀払い⼿段の範囲内でなら払ってよ い」という⽀払い条件の範囲の権限の委任 Human Present ユーザ → Shopping Agent (Trusted Surfaceを通して) 「この確定済み⽀払いの実⾏」の委任 Human Not Present Agentがopenで委任された権限を実際に⾏使したことの 証明
13. デモ シーケンス 1: 売り⼿Agentの選定、Agent Identity VPの提⽰と検証
14. デモ シーケンス 2-a: Human Present (Direct) フロー
15. デモ シーケンス 2-b: Human Not Present (Autonomous) フロー
16. 学び
17. 学び 本質的な難しさはVC発⾏以前にある • 本実証は発⾏ではなく検証に重きを置いている。 • 検証‧取引部分は、独⾃仕様や既存標準仕様(A2A‧AP2‧UCP) で実装できる。 • その中で、ビジネスロジックに応じてLLMに役割を与えることができる。 • 本質的な難しさは発⾏までのプロセスを含んだTrust Frameworkにある。 • IssuerによるAgentの審査論点、⼿法 • Issuerの認定⼿法 • Trust Chainの設計
18. 学び: 売り手側の設計の勘所 01 02 03 拒否の理由は、外には 最小限、内には詳細に 承認の形態は、申告でなく 署名の形から判定 身分証は最初に確かめ、 以降は短期トークンで 検証のどの段階で落ちたかは、相手 に返さない。攻撃する側に手がかり を与えないため。詳細は監査ログに 残し、成立した取引には署名付きの Receipt を返す 人が都度承認した委任状か、事前に 委任された範囲内の委任状かを、証 明書チェーンの形から見分ける。相 手の申告や設定では決めない 検証済みの相手に短期トークンを発 行し、身分証と同じ鍵の所持を毎回 確かめる。能力の一覧は、認証後に だけ追加で開示する VESS Labs Confidential
19. 今後に向けて
20. 今後に向けて より本格的な取り組みへ • 今回のコンセプトは⾄ってシンプル。購買‧決済部分はモック。 • 千⾥の道も⼀歩から。今回の実証は最初の⼀歩。 • これを⾜がかりに、(コンセプト‧⽅式に価値を感じていただけたら) 皆様と議論しながら、本格的な取り組みへ踏み込んでいきたい。
21. 今後に向けて: 仕様動向のウォッチ + 仕様外でどう実現していくべきか 01 A2A は信頼を運べるが、 信頼そのものは作らない 拡張の仕組みがあるので、仕様を変えずに身分証 (VC) を載せられた。ただし 標準の署名付き Agent Card が示すのは、ドメインの管理者が出したことまで 02 AP2 の委任状は、誰の鍵で 署名したかで意味が決まる エージェント自身の鍵で署名できてしまうと、人が承認した証明にならない。 承認の形態を宣言する項目も仕様にはなく、検証する側は署名から判断する 03 標準どうしの継ぎ目は、 まだ実装者が埋めている 05 / 05 → 信頼の起点と審査は、プロトコルの外で設計する必要がある → エージェントの鍵と、承認を署名する鍵の分離が前提になる A2A・AP2・UCP をつなぐ部分には未定義の箇所が残り、版も動いている。 今回も、商取引フロー本体と AP2 対応の宣言は独自仕様で補った → 独立した 2 つの実装をつなぐことが、解釈のずれを見つける確実な手段 VESS Labs Confidential
22. ご清聴ありがとうございました。
23. Appendix
24. 売り手エージェントの構成 入口・振り分け・検証と業務・共通基盤の 4 層。身元と委任状の検証は、決まった手順の処理だけで行う 01 / 05 VESS Labs Confidential
25. 取引の流れと、売り手側の内部処理 買い手の身分証は action のたびに検証し直す。委任状の検証が入るのは、最後の checkout だけ 02 / 05 VESS Labs Confidential
26. 売り手は何を検証しているのか 相手の身元は 10 ステップ、注文の承認は 3 点。どちらも相手の発行元に問い合わせず、暗号的な検証だけで判定する 03 / 05 VESS Labs Confidential