AIエージェント×VC連携
なぜAIエージェントとVCを組み合わせるのか
公開日 ：
AIエージェントの誤作動は原理的になくせません。だからこそ、実行できる範囲をあらかじめ設定し、検証できる状態にしておく必要があります。VC（Verifiable Credentials）が社内のAIガバナンスで果たす役割を解説します。
この記事でわかること
- AIエージェントの誤作動が、なぜ技術的になくせないのか
- 既存のID管理では対応しきれない理由
- VCが、そのどこを埋めるのか
リード
AIエージェントの誤作動は、なくすことができません。であれば、対策は「起こさない」ではなく「起きたときに広がらない」に向かうべきです。VCは、そのための土台になります。
はじめに、VCとは
先に、この記事で扱うVCが何なのかを短く書いておきます。
VC（Verifiable Credentials）は、改ざんされたことが分かるデジタルの証明書です。社員証や委任状にあたるものをデータとして持ち運べるようにして、受け取った相手がその場で本物かどうかを確かめられるようにしたものだと考えてください。
これをAIエージェントに持たせると、そのAIが誰の委任を受けて動いているのか、何をどこまで実行してよいのかを、相手のシステムが機械的に確認できるようになります。
なぜそれが必要なのか、というのがこの記事の本題です。
意図しない動作は、防ぎきれない
AIエージェントが想定外の動きをする可能性を、技術的にゼロにすることはできません。
まず、指示が自然言語で与えられます。「もう使わない資料を整理しておいて」という依頼が、どこまでを「もう使わない」と見なすのか。書いた側と読んだ側で食い違うことは、人間同士でも日常的に起こります。AIも同じで、こちらの意図と違う解釈をする余地が残ります。
次に、処理の途中で外部の情報を読みます。Webページや受信メール、共有ファイルの中身を見て次の行動を決める構成では、その情報の中に指示のように見える文言が混ざり込むことがあります。悪意を持って仕込まれる場合もあります。
さらに、複数のAIが連鎖する構成では、最初の指示が渡されていくうちに範囲が変わっていくことがあります。
これらは実装が粗いから起きるのではなく、AIエージェントという仕組みの性質から出てくるものです。精度の高いモデルに変えれば解決する、という話ではありません。
だから、設計の方向が変わる
原理的に防げないなら、対策の考え方は変わります。誤作動が起きないようにするのではなく、誤作動が起きても被害が一定以上に広がらないようにしておく。
やることは3つです。実行できる範囲をあらかじめ限定しておくこと。不要になった権限を確実に失効させること。そして、後から「誰の委任で、何の権限で実行されたのか」を説明できるようにしておくことです。
セキュリティ対策の基本的な考え方と同じです。侵入を100%防げないことを前提に、被害範囲を区切り、検知し、追跡できるようにする。AIエージェントに対しても、同じ発想が要ります。
既存のID管理では届かないところ
権限の管理なら既存のID・アクセス管理の仕組みがある、という指摘は当然出てきます。実際、多くの部分は既存の仕組みで対応できます。
ただ、AIエージェントには、既存の仕組みが想定していなかった性質があります。
ひとつは、主体が人ではないことです。既存のID管理は、社員一人ひとりにアカウントを割り当てる前提で設計されています。AIエージェントは必要に応じて生成され、役目を終えれば消えるため、人事システムと連動した棚卸しの対象になりません。
もうひとつは、「誰の代理か」という情報が必要になることです。人のアカウントであれば、本人が操作した、で話は終わります。AIエージェントの場合、そのAIが誰の委任を受けて動いているのかが分からなければ、実行の正当性を判断できません。「このAIは営業部のアシスタント」といった役割を割り当てるだけでは、誰の委任なのかまでは表現できません。
権限が環境をまたいで持ち回られる点も違います。AIが別のAIに作業を渡す、外部のサービス上で動くといった構成では、自社のID基盤の外側に権限の情報が出ていきます。
期限の感覚も異なります。人のアカウントは年単位で運用しますが、AIエージェントに与える権限は、本来もっと短くてよいものが多い。1件の業務のためだけに数時間だけ有効な権限を出す、という運用が現実的になります。
VCが担う役割
VC（Verifiable Credentials／検証可能なデジタル証明）は、こうした情報を改ざん検知が可能な形でAI自身に持たせるための技術です。
営業部長が、部の資料整理と社内検索をAIに任せる場合であれば、証明の中身はこうなります。
| 発行者 | 情報システム部 |
|---|---|
| 委任者 | 営業部長 |
| 対象のAI | 営業支援AI |
| できること | 営業部の共有フォルダを読む／顧客管理システムを参照する |
| 範囲 | 読み取りのみ。削除・変更・社外への送信は含まない |
| 期限 | 発行から3か月 |
これを発行元の署名付きでAIに持たせておくと、ファイルを削除しようとしても、社外に送ろうとしても、その時点で止まります。どうしても必要であれば、人の承認へ回ります。期限が切れればAIは何もできなくなります。部長が異動すれば、委任を失効させることで権限が消えます。事故が起きたときには、何を根拠に実行したのかを記録から示せます。
誤作動そのものは防げません。ただ、AIがどれだけ想定外の解釈をしても、読むことしかできず、3か月で権限が切れる。起こりうる最悪のことが、あらかじめそこまでに区切られている。これがVCを使う実務上の意味です。
VCだけでは足りない
誤解のないように書いておくと、VCはAIの判断を正しくする技術ではありません。証明するのは権限であって、行為の妥当性ではありません。
実際の運用では、他の仕組みと組み合わせます。その操作を実行してよいかを最終的に判断する仕組みが要りますし、システムへの接続そのものは既存のID管理の仕組みが担います。誰が何を委任し、何が実行されたかは監査ログに残す必要があります。VCはこのうち、そのAIが誰の代理で何を任されているかを示す部分を担当します。
VCがあるから任せるのではなく、VCで任せる範囲を確認したうえで、必要な安全策を重ねる。そういう位置づけの技術です。
どこから始めるか
いきなり全社に適用する必要はありません。ファイルの削除や社外への送信をともなう業務、顧客情報や人事情報を扱う業務など、失敗したときの影響が大きいところからで十分です。
範囲としては、まず社内から始めるのが現実的です。自社の統制下にあるうちは、設計も見直しも自由が利きます。社外の企業とAI同士で連携する構想もありますが、そちらは相手側にも受け入れる仕組みが必要になり、事業提携が前提になります。
自社の中で、AIエージェントをどう統制するか。この課題に対して使うのが、取り組みやすい入口です。
