エージェントのアイデンティティ問題

私たちは、AI エージェントが人間に代わって行動する時代に入りつつあります — フライトの予約、契約の交渉、インフラの管理、さらにはコードの記述。これらのエージェントは、他のエージェント、API、人間のシステムとやり取りします。

こうしたやり取りの一つひとつが、根本的な問いを提起します：このエージェントは誰であり、なぜ信頼すべきなのか？

現在、ほとんどのエージェントは API キーで認証されています — エージェントの運用者とアクセスするサービスの間で共有される静的なシークレットです。これは単純なシナリオでは機能しますが、エージェントがより自律的になると破綻します：

  • エージェントが誤った判断をした場合、誰が責任を負うのか？
  • あるエージェントが別のエージェントの主張をどう検証するのか？
  • 運用者のアクセスを取り消さずに、エージェントのアクセスだけを取り消すにはどうするのか？
  • エージェントが何をしたか、誰の代理で行ったかをどう監査するのか？

なぜ API キーだけでは不十分なのか

API キーは認証の問題を解決します — 有効な資格情報を持っていることの証明です。しかし、アイデンティティの問題は解決しません — あなたが誰であるか、何を行う権限があるかの証明です。

API キー DID ベースのアイデンティティ
資格情報 静的で長期有効なシークレット ローテーション可能な暗号鍵ペア
アイデンティティ 固有のアイデンティティ情報なし 豊富で検証可能なアイデンティティクレーム
アクセス 二値：有効か無効か きめ細かなケイパビリティと権限
権限 中央集権的な発行と取り消し 自己主権、中央権威不要
デリゲーション デリゲーションモデルなし ネイティブなデリゲーションと取り消し

DID がその答えである

分散型識別子（DID）は W3C によって普遍的なアイデンティティレイヤーとして設計されました。当初は人間のために構想されましたが、そのアーキテクチャは AI エージェントに完璧に適合します：

自己主権

エージェントは自身の DID を作成します — 登録機関は不要です。エージェントは自身の鍵を管理し、誰に対しても自分のアイデンティティを証明できます。

検証可能な資格情報

エージェントのケイパビリティは検証可能な資格情報として表現できます：「このエージェントは X 社から 1,000ドル以下の購買を行う権限を付与されています。」誰でも X 社に問い合わせることなくこの主張を検証できます。

デリゲーションチェーン

人間 → エージェント → サブエージェントのデリゲーションは DID モデルのネイティブ機能です。すべての操作が権限チェーンを通じてトレース可能です。

実際のアーキテクチャ

DID ベースのエージェントアイデンティティが実際にどのように機能するかを示します：

人間 (DID: did:abt:alice)
  |
  +-- 資格情報を発行："エージェント X は私の代理でフライトを予約できる"
  |
  v
エージェント X (DID: did:abt:agent-x)
  |
  +-- フライト API に資格情報を提示
  +-- フライト API が検証：資格情報 → Alice の DID → 信頼された発行者
  |
  v
フライト予約完了。監査証跡：エージェント X → Alice が認可 → フライト #123

重要な洞察：すべてのやり取りが監査可能で、すべてのケイパビリティにスコープがあり、すべてのデリゲーションが取り消し可能 — 鍵や権限を管理する中央権威は一切不要です。

私たちが構築しているもの

ArcBlock では、AIGNE フレームワークの基盤レベルで DID を統合しています：

  1. すべての AIGNE エージェントは作成時に DID を取得します。 オプトインは不要です。
  2. エージェント間通信は DID ベースの相互認証を使用します。
  3. 検証可能な資格情報が各エージェントのできること — そして誰が認可したかを定義します。
  4. 監査ログがすべての操作を DID にリンクし、完全なアカウンタビリティチェーンを作成します。

これは理論ではありません — AIGNE 1.0 で出荷されます。現実世界とやり取りする AI エージェントを構築するなら、アイデンティティはオプションではありません。基盤です。

おすすめの記事

構築を始める準備はできましたか？

AIGNE フレームワークはオープンソースです。DID 統合は組み込み済みです。

AIGNE を始める