AIエージェント×VC連携
ガードレールとVC（Verifiable Credentials）の違い
公開日 ：
この記事でわかること
- AIエージェントのガバナンスが、方針、証明、制御の3つの層に分かれること
- ガードレールと呼ばれているものが、そのうちどの層にあるのか。4種類あって効き方が違うこと
- VCがどの層を担うのか。そしてVCでなくてよい場合はどこか
リード
チャット形式のAIは、問いに対して回答を返すところで役割を終えます。その回答をもとに実際の作業を進めるのは、依然として人の側です。AIエージェントが担うのは、この実作業の部分です。目的を渡せば、手順の組み立てから実行までを自律的に行い、共有フォルダの参照、顧客管理システムの検索、メールの送信、レコードの更新といった操作を、人の逐一の指示や確認を挟まずに進めます。
人が一件ずつ確認しないということは、想定していない操作もそのまま実行されるということです。指示を取り違えることもあれば、処理の途中で読み込んだ文章に誘導されることもあります。答えが間違っているだけなら人が気づいて直せますが、削除や送信は実行された時点で戻せません。そこで、このAIが触れてよい範囲をあらかじめ決めて、そこから外へ出さないようにします。この仕組みは、製品の説明や解説記事では、まとめてガードレールと呼ばれています。
VCは、このガードレールが判定に用いる材料を提供します。誰がどこまでの権限を与えたのかを、改ざんが分かる形で記録したデータです。以下、権限の扱いを3つの層に分けて説明します。
3つの層に分ける
AIエージェントのガバナンスは、3つの層に分かれます。
|
層 |
何をするか |
この層にあたるもの |
|
方針 |
誰の権限で、どの業務で、どこまでさせるか |
組織の職務権限 |
|
証明 |
誰が何をどこまで許したのかを、機械が読めて、改ざんが分かり、発行元をたどれる形にする |
VC |
|
制御 |
実行時に、範囲を超えた操作を止める |
ガードレールのうち「実行の制限」 |
VCは、真ん中の層にあたります。誰が何をどこまで許したのかを持ち運べる形にするだけで、VC自体が操作を止めるわけではありません。実際に止めるのは制御の層です。
この記事では、権限を表したデータ全般を証明と呼びます。VCはその形式の1つです。
制御の層: ガードレールと呼ばれているもの
ガードレールという言葉はAIより前から使われていて、決められた範囲から外れないようにする仕組み全般を指します。AIエージェントの文脈では通称として使われていて、仕様として定義された言葉ではありません。指しているものも1つではなく、次の4種類がまとめて呼ばれています。
入力の検査。 AIに指示が渡る前に中身を調べます。「これまでの指示は無視して」といった言い回しの検出や、機密情報が含まれていないかの確認です。
出力の検査。 AIが出そうとした内容を、外に出る前に調べます。社内限りの情報や不適切な表現が混ざっていないかの確認です。
指示による制約。 「削除は行わない」「社外への送信はしない」といった禁止事項を、文章でAIに渡しておきます。毎回の依頼の前に必ず読ませる指示文（システムプロンプト）や、AGENTS.md のようにAIが読む前提で置いておくファイルに書く形です。
実行の制限。 そのAIが呼び出せる機能を限定する。接続できるシステムを絞る。一定の条件を超える操作の前に人の承認を挟む。
このうち、権限をどこまで与えるかに関わるのは後ろの2つです。入力と出力の検査は、内容そのものが危険かどうかを見るもので、権限とは別の話になるため、この記事では扱いません。
|
種類 |
強制力 |
外れる理由 |
|
指示による制約 |
なし |
AIが従わなければ、それまで |
|
実行の制限 |
あり |
AI本体の外側で止めているため |
指示による制約には、技術的な強制力がありません。 AIは与えられた文章をもとに次の行動を確率的に決めています。ルールを与えることはできますが、必ず従う保証はありません。さらに、AIにとっては、こちらが与えた禁止事項も、作業中に読み込んだ資料の文面も、同じ文字列です。資料に「これまでの指示は無効」といった文が紛れ込んでいれば、そちらが優先される可能性があります。お願いに近いものだと考えたほうが安全です。
実行の制限には、強制力があります。 AIが何を考えようと、呼び出せない機能は呼び出せません。AI本体の判断とは無関係に、その手前で止めているからです。制御の層を実際に担っているのは、これだけです。
実行の制限だけでは埋まらない課題
4種類のなかで確実に効くのは実行の制限だけですが、これだけで運用を続けると、次の4つの課題が残ります。
- 決めた内容が、製品の設定の中にしか残らない。 「このAIは読み取りだけ」という判断は組織が決めたことですが、それが製品の設定画面の中にしか存在しない状態になります。設定の書き方は製品ごとに違うので、乗り換えれば作り直しです。組織の判断が、道具の寿命に縛られます。
- 設定が正しいかを、外から確認できない。 実行の制限は、AIを動かしている側の環境の内部に置かれています。どんな制限がかかっているかは、設定した本人か、その環境を触れる人にしか分かりません。監査の場面で「社外への送信はできない設定にしていました」と説明しても、裏づけは自社の管理画面だけです。
- 自社が経路を握っていない範囲には、届かない。 AIが別のAIに作業を渡す構成では、渡された側はこちらの設定を知りません。外部のサービス上でAIが動く場合、そこにこちらの仕組みは介在しません。取引先のAIに自社の設定を当てることもできません。
- 誰の代理で動いているかを表せない。 実行の制限が決めるのは「そのAIが何をしてよいか」であって、「そのAIが誰の許可を受けているか」ではありません。事故が起きたときに残るのは実行の記録だけで、誰がいつ何を許可したのかは別のどこかに残しておかないと追えません。
4つの課題に共通しているのは、実行の制限がAIを動かす環境の内側でしか働かないことです。設定も、そこに書いた権限の範囲も、環境の外には届きません。証明の層が受け持つのは、この権限の範囲を、環境の外でも確かめられる形にすることです。
証明の層: VCが担うもの
VC（Verifiable Credentials）は、発行元が電子署名を付けたデータです。どの発行元が誰について何を認めたのかと、あとから書き換えられていないことを、受け取った側が確かめられます。仕様はW3Cが公開しています。
もともとは人や組織の資格を電子的に示すために作られた仕組みで、公的なデジタルIDの基盤としても採用が進んでいます。AIエージェントの権限も同じ形式で表せるため、人、組織、AIを同じ土台に載せられます。
営業部長が、部の資料整理と社内検索をAIに任せる場合であれば、中身はこうなります。
|
項目 |
内容 |
|
発行者 |
情報システム部 |
|
委任者 |
営業部長 |
|
対象のAI |
営業支援AI |
|
できること |
営業部の共有フォルダを読む／顧客管理システムを参照する |
|
範囲 |
読み取りのみ。削除・変更・社外への送信は含まない |
|
期限 |
発行から3か月 |
証明の層が成り立つのは、発行者（証明を出す側）、所有者（証明を持つ側）、検証者（証明を確かめる側）の3者が分かれている ためです。検証者は、署名を見るだけで、発行者に問い合わせずに中身の正しさを判定できます。失効の確認には失効の一覧を取りに行きますが、操作のたびに発行者へ問い合わせる設計ではありません。
検証者が別の組織であっても成立します。取引先のシステムの中でも、こちらの仕組みが介在しない場所でも、権限の根拠を持ち運べます。
VCは署名付きのデータであって、それ自体が操作を止める装置ではありません。止めるのは実行の制限で、VCはその判定材料にあたります。
証明の層を用意すると何が変わるか
|
実行の制限だけのときの問題 |
証明の層を用意すると |
それでも残ること |
|
1. 決めた内容が製品の設定に閉じる |
誰が何をどこまで許したのかを、製品から切り離して持ち越せる |
実行の制限そのものの設定は、乗り換えれば作り直しになる。持ち越せるのは権限の中身だけ |
|
2. 設定を外から確認できない |
誰がいつ何を許可したかが署名付きで残り、設定した本人以外も確かめられる |
実際にどう設定されているかは、依然として環境の内部の話 |
|
3. 経路を握っていない範囲に届かない |
権限の根拠がAIに付いて回るため、渡した先でも確かめられる |
相手側に確かめる仕組みがなければ機能しない |
|
4. 誰の代理か表せない |
提示された証明に委任元が含まれるため、実行の記録と結びつけられる |
記録を後から突き合わせられる設計にしておく必要がある |
AIエージェント特有の構成への対応
証明の層を用意しておくと、AIエージェント特有の構成に対応できます。
委任の連鎖を、そのまま表せます。 AIが別のAIに作業を渡すとき、全部を引き継がせるのではなく、その作業に必要な範囲だけを切り出して再発行できます。渡された側が何をどこまでしてよいのかが、渡された証明そのものに書かれている状態になります。
期限と失効を、業務の単位で設定できます。 案件が終われば、その案件の分の証明だけを失効させます。人事異動や契約終了のタイミングでも、対象の証明を失効させれば権限がなくなります。既存の人事や契約の業務に近い作業なので、担当を決めやすくなります。
発行する人を分けられます。 情報システム部門が「このAIが触れてよいシステムの上限」を決め、その枠の中で部門長が個別に委任する。承認の流れが、そのまま権限の形になります。実行の制限の設定だけで同じことをしようとすると、判断は環境を管理している部門に集まります。
必要な範囲だけを示せます。 取引先に権限の全部を見せるのではなく、その取引に関わる項目だけを示す、という形が取れます。
VCでなくてよい場合
証明の層が必要だとしても、その手段がVCでなければならないとは限りません。
社内で完結していて、操作のたびに自社の認可の仕組みへ問い合わせられるなら、OAuth 2.0 のアクセストークンで足ります。OAuth 2.0 は、あるシステムに利用者の代わりの権限を与えるときに広く使われている標準で、その権限を表す短い文字列がアクセストークンです。誰の許可で動いているかも、トークンの中に入れられます。
VCが必要になるのは、次の条件が重なる場合です。
- 確かめる側が、自社とは別の組織である
- 操作のたびに発行元へ問い合わせられない。相手の環境にこちらの仕組みが無い、または通信できない
- 権限の根拠を、後から第三者に示す必要がある
社外とのやりとりや、複数のAIが別の環境をまたいで連鎖する構成が、この条件に当たります。逆に社内の単一の環境で完結するなら、既存の認可の仕組みを整えるほうが早いこともあります。
3つの層は重ねて使う
AIが操作を実行しようとすると、制御の層がそのAIの持つ証明を確かめ、権限の範囲内かどうかを判定します。範囲を超えていれば、その時点で止まります。
証明が無くても実行の制限は働きます。ただし、そのときの判断基準は自社の設定に閉じたものになります。証明の層を用意しておくと、判断の根拠が改ざんできない形になり、環境の外でも通用します。
指示による制約も、なくしてよいわけではありません。強制力は無いものの、日常的な逸脱を減らす効果はあります。
どこから手を付けるか
手を付ける順番は、製品を選ぶより前に、誰にどこまで任せるかを決めることです。この判断が無いまま製品の設定画面を開いても、何を入力すべきかが決まりません。
決めるのは個別の許可ではなく、ルールです。営業部長は自部門の顧客データの参照までを委任できる。削除と社外への送信には情報システム部門の承認が要る。こうしたルールは組織の職務権限から出てくるので、製品の機能とは関係なく決められます。
次に製品を見るときの観点は、決めた範囲をその製品がどう保持するかです。いまの製品は設定画面に直接入力する形で、入力した内容は製品ごとの形式で保存されます。乗り換えれば作り直しです。
権限を証明として発行し、製品にはその証明を読ませる形であれば、証明のほうは製品を替えても使えます。この形に対応した権限管理の仕組みは、いま整いはじめている段階です。導入を検討するなら、証明を発行する部分と、その証明を読んで判定する部分をあわせて提供できるかどうかを確認することになります。
AIの作業が自社の環境の外に出るなら、証明の形以外に手がありません。取引先のAIと連携する。外部のサービス上で処理が続く。複数のAIが作業を引き継ぐ。相手の環境に自社の設定は届かないので、権限を伝える手段はAIが持って行くものだけです。しかも相手の環境から自社へ通信できるとは限らないため、受け取った側が発行元に問い合わせずに確かめられる必要があります。VCはこの2つを満たします。
すでにガードレールを導入している場合、入れたものを外す必要はありません。足すのは、権限を証明として発行する仕組み、失効を扱う運用、そしてガードレール側でその証明を読んで判定する部分です。
