Verifiable Credentials
Verifiable Credentialsで実践できる権限制御とリスク対応一覧
公開日 ：
VCを使うと、AIエージェントの権限を具体的にどこまで制御できるのか。設定できる項目、想定されるリスクへの対応、そしてVCだけでは対応できない範囲までを一覧で整理しました。
リード
VC（Verifiable Credentials）でAIエージェントの権限を管理する、と言われても、実際に何をどこまで設定できるのかは見えにくいところです。設定できる項目、想定されるリスクへの対応、そしてVCだけでは対応できない範囲を、一覧の形で整理しました。
VCに書ける項目
AIエージェントに持たせる証明には、次のような項目を含められます。何を入れるかは業務によって変わりますが、実務でよく使われるものを挙げます。
| 項目 | 内容 | 記載例 |
|---|---|---|
| 発行者 | 誰がこの証明を出したか | 情報システム部 |
| 委任者 | 誰が権限を与えたか | 営業部長 |
| 所属 | そのAIがどの部門の管理下にあるか | 営業部 |
| 対象範囲 | どのシステム・どのデータに対してか | 営業部の共有フォルダ、顧客管理システム |
| 操作の種類 | 何をしてよいか | 読み取りのみ（削除・変更・社外送信は不可） |
| 上限 | 件数などの天井 | 1日100件まで |
| 期限 | いつまで有効か | 発行から3か月 |
| 発行日 | いつ発行されたか | 2026年9月1日 | 失効の参照先 | 取り消しの有無を確認する場所 | 発行者の失効リスト |
これらは発行者の署名付きで記録されるため、あとから書き換えることができません。
制御できることの一覧
上記の項目を使って、実務上どんな制御ができるのかを整理します。
| 制御したいこと | VCでの実現方法 | 効果 |
|---|---|---|
| 見せてはいけないデータを触らせない | 対象範囲を限定して発行 | 範囲外のフォルダ・システムにアクセスできない |
| 取り消せない操作を自動でさせない | 操作の種類を限定（読み取りのみ等） | 削除や社外送信は人の承認へ回る |
| 実行回数を抑える | 件数の上限を設定 | 大量実行による被害の拡大を防ぐ |
| 権限を放置しない | 有効期限を短く設定 | 期限切れで自動的に無効になる |
| 異動・退職に追随させる | 委任元と連動して失効 | 元の担当者が離れた時点で権限が消える |
| 誰の代理かを明示する | 委任者を記載 | 実行の正当性を相手が確認できる |
| 実行の根拠を後から示す | 委任の記録を保全 | 監査・事故調査で提示できる |
| 必要以上の情報を出さない | 必要な項目だけを見せる（選択的開示） | 権限だけを示し、組織構造や氏名は伏せる |
| 再委任の範囲を狭める | 委任時に範囲を縮小して発行 | AIが別のAIに渡すときも制限が引き継がれる |
想定されるリスクと、その対応
AIエージェントの運用で起こりうる事象について、VCで対応できる部分と、併用が必要な対策を並べました。
| 想定リスク | VCでの対応 | 併用が必要な対策 |
|---|---|---|
| AIが必要なファイルまで削除してしまう | 操作を読み取りのみに限定 | バックアップ、削除前の確認 |
| AIが社外に機密情報を送ってしまう | 送信の権限を与えない | 送信先の制限、送信前の承認 |
| AIが権限のない人事情報を読み出す | 対象システムを限定して発行 | アクセス制御、ログの監視 |
| 外部の文書を読んだAIが誘導される | 権限の範囲外は実行できない状態にする | 入力の検証、参照先の制限 |
| 退職者の権限でAIが動き続ける | 委任の失効で権限を無効化 | 人事情報との連動、定期的な棚卸し |
| プロジェクト終了後も権限が残る | 期限付き発行で自然に失効 | 終了時の失効手続きの明文化 |
| 他社のAIになりすまされる | 発行元の署名を検証 | 相手の発行者を信頼してよいかの判断基準 |
| どのAIが何をしたか分からない | 委任と実行を対応づけて記録 | 監査ログの設計、保存期間の規定 |
| 権限が広すぎたまま運用される | 発行時に範囲を明示して限定 | 発行申請のプロセス、承認者の設定 |
| 複数のAIに権限が伝播する | 再委任時に範囲を縮小 | 連鎖の深さの制限、経路の記録 |
| 監査で実行根拠を説明できない | 委任の証明を提示 | 事故対応手順、報告体制 |
VCだけでは対応できないこと
一覧にした以上、対応できない範囲も明示しておきます。ここを誤解したまま導入すると、期待した効果が出ません。
AIの判断そのものは正しくなりません。VCが証明するのは権限であって、行為の妥当性ではありません。範囲内であれば、内容として不適切な実行も通ります。操作範囲の限定や人の承認と組み合わせて、初めて実務的な安全性になります。
発行者を信用してよいかは、VCの外側の問題です。署名が正しく検証できることと、記載内容が事実であることは別です。誰が発行者になるのか、その発行者をなぜ信用するのかは、組織として決める必要があります。
鍵が漏えいすれば悪用されます。秘密鍵の管理、定期的な更新、異常の検知は、別途手当てが要ります。
相手がVCを受け入れるとは限りません。社外との連携で使う場合、相手側にも検証する仕組みが必要です。自社だけ整備しても、相手が対応していなければ機能しません。
運用の負担はあります。発行、更新、失効の手続きが増えます。すべての業務に適用しようとすると現実的でないため、リスクの高い業務から段階的に広げることになります。
どこから設定するか
すべての項目を最初から使う必要はありません。実務で効果が出やすいのは、期限と上限の2つです。
期限を切っておけば、放置された権限が自然に消えます。上限を設定しておけば、誤作動が起きても被害がその範囲で止まります。この2つだけでも、権限が広いまま無期限に残るという最も起こりやすい状態を避けられます。
対象範囲の限定や選択的開示、再委任の制御は、運用が回りはじめてから足していく順序で問題ありません。
