AIエージェントの実行前審査とは｜非エンジニアがAIと作るVATEプロトコル案
VATE開発記 第2部
－ AIエージェントの「実行前審査」を考える －
こんにちは！ポケヌシです。
前回は、AIエージェント時代のパスポートというテーマでVATEを作ろう思った背景などを書きました。
今回はその続き、第2部です。
前回よりも少し技術寄りの話をします。
うまく説明できるかわかりませんが、ぜひ読んでいってください！
そしてちょうどタイミングよく、今回のテーマにぴったりの企画に参加させていただきます！
僕がAIと始めてみたことは、アプリ開発でも、イラスト生成でも、小説執筆でもなく
AIエージェント時代の信頼プロトコル案をGitHubに出してみること
難しい部分もたくさんあったんですが…
でもだからこそ、#AIと始めてみた 挑戦です！
前回の「パスポート」から、今回は「入国審査」へ
前回の記事ではVATEのことを
AIエージェント時代のパスポートのようなもの
と書きました。
これは、一般向けのイメージとしてはかなり近いと思っています。すごく平たく言った感じです。
ただ、技術的な観点を含めて厳密に言うと、VATEはパスポートそのものではありません。
どちらかというと
AIエージェントが何か危ない操作をしようとしたときに、受け入れる側が「この操作を通していいか」を判断して、その記録を残す仕組み
に近いです。
人間でたとえるならパスポートだけではなく、入国審査に近いかもしれません。
海外に行くとき、パスポートを持っているだけで何でもできるわけではないですよね。
入国審査、ビザや滞在目的の確認。
場合によっては入国できないこともあります。
つまり
「あなたは誰ですか？」
「何の目的で来ましたか？」
「その目的は許可されていますか？」
「この国に入って大丈夫ですか？」
という確認。
VATEで考えていることも、それに少し似ています。
AIエージェントが外部のシステムや、別のAIエージェントに対して何かをしようとしたとき
「このAIは誰の代理なのか？」
「何をしようとしているのか？」
「その操作は本当に許可されているのか？」
「受け入れる側は、何を根拠に許可・制限・拒否するのか？」
「あとから何をしたか確認できるのか？」
このあたりをもう少し整理して考えたい。
それがVATEです。
AIエージェントが“実行する”と何が怖いのか
今のAIはまだ多くの人にとって、そして多くのケースでチャット相手として使われています。
質問や相談、ライティング、コーディング、画像生成。
この段階では、最終的にボタンを押すのはだいたい人間です。
でもAIエージェントが今よりもっと民主化されて本格的に動き始めると、そこが変わってきます。
AIが自分で
・メールを送る
・外部サービスに投稿する
・資料を共有する
・予約を取る/決済をする
・ファイルを作る/消す
・誰かのAIエージェントに情報を取りに行く
みたいなことをするようになる。
めちゃくちゃ便利です。
でも、ちょっと怖いですよね。
怖い理由は単にAIが賢いからとかの話ではなく、
「外の世界にも影響を与えるから」だと思っています。
人間の頭の中で考えているだけなら、まだ大きな事故にはなりにくい。
でも、AIエージェントが実際に「自律的に」メールを送ったりファイルを共有したり、外部システムを書き換えたりすることが一般化していくなら話は別です。
「そのAIは本当にその操作をしていいの？」
「誰の代理で動いているの？」
「どこまで許されているの？」
「やりすぎたときに止められるの？」
「あとから何をしたか分かるの？」
こういう確認が必要になると思っています。
ここが、VATEで考えたい場所です。
具体例：AIが会議メモを外部に共有しようとしたら
少し具体的に考えてみます。
たとえば、自分のAIエージェントがいるとします。
そのAIは、自分の仕事の予定やメモをある程度理解しています。
会議メモも読めます。資料も整理できます。
必要なら、外部の人に共有することもできます。
ある日、そのAIがこう判断したとします。
「この会議メモは、取引先の担当者にも共有した方がよさそうです」
そして、外部の相手に会議メモを送ろうとする。
ここで問題です。
そのまま送っていいんでしょうか。
たぶんダメですよね。笑
会議メモには、社内だけの話が入っているかもしれません。
個人名が入っているかもしれません。
まだ外に出してはいけない数字が入っているかもしれません。
相手には要約だけで十分かもしれません。
そもそも、その相手が本当に共有先として正しいかも分かりません。
人間なら、ここで一度考えます。
「これは外に出していい内容かな？」
「この部分は削った方がいいな」
「この人には全文じゃなくて要約だけでいいな」
「この件はまだ共有しない方がいいな」
みたいに判断しますよね。
同じように、AIエージェントが自律的に動く世界ではこの判断をどう扱うのかが重要になると思っています。
AIに全部任せていいのか。
人間の承認を必ず挟むのか。
システム側で止めるのか。
条件付きで通すのか。
記録はどう残すのか。
ここでVATEの考え方が出てきます。
VATEで見たいもの
VATEでは、AIエージェントが何か危険な操作をしようとしたときに、受け入れる側がいくつかの情報を見て判断するイメージです。
たとえばさっきの会議メモ共有の例なら、見たいのはこういう情報です。
✔️ このAIエージェントは誰の代理なのか
✔️ 何をしようとしているのか
✔️ 共有先は誰なのか
✔️ どのデータに触ろうとしているのか
✔️ そのデータを外に出してよいと判断できる材料や証拠はあるのか
✔️ 操作の目的は何なのか
✔️ 許可の範囲はどこまでなのか
✔️ 期限や条件はあるのか
✔️ 実行後に何を記録するのか
こういうものを毎回その場のノリで判断するのではなく
「できる限り適切に判断しやすい形」にする。
VATEという名前の中にある Envelope は、封筒という意味です。
僕の理解では、VATEはまさに封筒っぽいです。
AIエージェントが何かをしようとしている。
そこに関係する証拠や条件や記録を、バラバラにせずひとつのまとまりとして扱う。
そんなイメージです。
もちろん、VATEが全部をゼロから証明するわけではありません。
AIエージェント同士のやり取りにはすでにA2Aのようなものがあります。
ツールや外部データへのアクセスにはMCPやOAuthのようなものがあります。
本人確認や権限/委任/証明には、すでにいろいろな仕組みがあります。
VATEはそれらを置き換えたいわけではありません。
むしろ、それらから出てくる情報や証拠を材料として
「今回この操作を通していいのか」
を受け入れる側で判断するための考え方です。
地味です。
でも、けっこう大事な役割だと思っています。
allow / attenuate / deny という3つの判断
VATEでは、AIエージェントの操作に対して大きく3つの判断を考えています。
allow：そのまま許可
attenuate：条件付きで許可。または、権限や範囲を小さくして許可
deny：拒否
この3つです。
さっきの会議メモの例で考えると、こんな感じです。
allow は
「この相手には、この会議メモを共有してOK」です。
たとえば、すでに共有が許可されている資料で、相手も正しく内容にも問題がない場合です。
deny は
「この会議メモは共有できません」です。
相手が不明だったり、許可が切れていたり、社外秘の内容が含まれていたり、そもそも外部共有が禁止されている場合です。
そして attenuate は
「全文共有はダメ。でも、個人名と社内数字を消した要約ならOK」
みたいな判断です。
これがかなり現実っぽいと思っています。
一番おもしろいのは「制限して許可する」こと
個人的に一番おもしろいのは attenuate です。
弱める。減らす。制限する。
そんな感じです。
僕らの現実の仕事って、ほとんどこれじゃないですか？
全部OKでもない。
全部ダメでもない。
・この範囲なら
・この人には
・この金額までは
・この期間だけ
・閲覧だけなら
・要約だけなら
・個人情報を消せば
・上長確認があれば
こういう判断ばかりです。
店舗運営でも同じです。
「この対応はスタッフに任せていい」
「このケースはリーダー判断」
「この金額を超えたら店長確認」
「このお客様対応は履歴を残す」
「この情報は全体共有していいけど、個人名は出さない」
みたいなことは現場では普通ですよね。
AIエージェントが動く世界でも、おそらく同じになると思うんです。
AIは進歩のスピードが速いので、ここをてきとうに放置したり設計するとかなり危ないと思うんです、色んな意味で。
だから単純に
「AIに許可する、AIを禁止する」
ではなく
どの範囲なら許可をするのか
を考える必要があると思っています。
ここにVATEの意味がある気がしています。
実行前だけでなく、実行後の記録も大事
もうひとつ大事なのが、実行後の記録です。
AIエージェントが何かをしたあとに「何をしたのか分からない」では困ります。
会議メモの例なら、
・誰のAIが依頼したのか
・誰に共有したのか
・全文を送ったのか/要約だけ送ったのか
・どの部分を削ったのか
・なぜその判断になったのか
・いつ実行されたのか
こういうことが、あとから確認できる必要があります。
もちろん、現実にはもっと細かい設計が必要です。
✔️ ログをどこまで残すのか
✔️ 誰が見られるのか
✔️ 個人情報をどう扱うのか
✔️ 改ざんをどう防ぐのか
✔️ どの証拠を信頼するのか
こういう話は正直めちゃくちゃ難しいです。
僕もまだ全部を理解したり把握できているわけではありません。
でもこの２つの記録、
「AIエージェントが何かを実行する前の判断とその後の記録」
個人的にはこれがかなり重要になると思っています。
VATEは、そのあたりを整理するためのドラフトです。
GitHubには何を置いているのか
VATEはGitHubで公開しています。
▼GitHubはこちら▼
現在公開しているレビュー用の節目としては、v0.3.0 の discussion draft snapshot があります。
現在もその後の改善も進めています。
リポジトリには、テスト用のケースも置いています。
現時点では63個のケースがあります。
「こういう入力ならこう判断する」
「この場合は許可 or 制限 or 拒否」
というものを、確認しやすくするためです。
ただし、63個のケースが通ったから安全です、という意味ではありません。
いきなり本番で使えます、という意味でもありません。
どこかに認められました、という意味でもありません。
あくまで
同じ材料を見たときに、同じ判断になるのかを議論しやすくするための確認材料です
開発に至ったきっかけを少しだけ
僕としては、VATEをただのアイデアで終わらせるのはちょっとつまらないなと思いました。
「AIエージェント時代には、信頼や権限が大事ですよね」
と言って終わりだと、自分自身の理解も学びも深まらない。
もっと言えば「なんとなく言う」ことは誰にでもできます。
だからこそ
「どんなケースで、どんな判断になるのか」
「その判断は別の人が読んでも再現できるのか」
「仕様として曖昧なところはどこなのか」
まで考え始めると、議論になったり自分自身もスキルアップするかななんて。
だからGitHubに出してみました。
もちろんかなりAIに助けてもらっています。
英語のドキュメントを書くのも、仕様を書くのも、フォルダ構成を考えるのでさえ、僕ひとりでは無理です。
でもAIと一緒なら少しずつ形にできます。
これがまさに今、この瞬間、この時代、本当に面白いことだと思っています。
Geminiにサポートしてもらっていること
今回、このVATEの仕様ドラフトの開発には、ChatGPT、ClaudeそしてGeminiの三者レビューを活用してきました。
余談ですが…個人的にGeminiはライティングが好きです。
忖度じゃないです。笑
英語のトーンは僕にはイマイチわかりませんが、日本語は結構上手で、自分が書いた文章や喋った内容をうまいことAIっぽくない感じでまとめ上げてくれるのはGeminiがうまい印象があります。
レビューの具体的な内容は
・論理の破綻
・第三者への見え方
・関連する既存プロトコルとの境界線
などです。
ちなみにもちろん、技術的に理解が追いつかない部分をわかりやすく噛み砕いてもらうことも多いです。
そういう意味でもGeminiには助けられています。
AIは本当に便利で、本当に頼もしいです。
特に僕みたいに、非エンジニアだけど技術的なこともやってみたい！という人間にとってはめちゃくちゃ助かります。
ただもちろん、自分が使うAIにVATEをレビューしてもらったから完成というわけではありません。
AIだけではなく、人間も含めもっと多くの目で見てもらう必要があると思っています。
VATEにとって大事な話
VATEは現時点で、完成した標準でも、認証制度でも、本番利用を保証するものでもありません。
また、A2A、MCP、OAuth、AP2、VCなどを置き換えるものでもありません。
今のVATEは、AIエージェントが危険な操作をしようとしたときに、受け入れる側がどんな材料を見て、どんな判断をし、その記録をどう残すかを議論するための仕様ドラフトです。
技術者の方へ
もし技術者の方がこの記事を読んでいたら、ぜひGitHubを見てほしいです。
そして、できれば検証をしてみてほしいです。
どこで壊れるのか、不具合が出るのか、問題になるのか。
また、特に今ほしいのは「独立実装の視点」だと思っています。
今ある確認用の仕組みとは別の形で、同じケースを読んだときに
「この判断は再現できる」
「ここは曖昧で判断が割れる」
「この表現だと実装者は迷う」
「このケースが足りない」
「この既存プロトコルとの境界は危ない」
みたいなことがあれば教えてほしいです。
▼GitHubはこちら▼ (再掲)
https://github.com/Poke-nushi/Verifiable-Agent-Trust-Envelope
▼レビュー用Issueはこちら▼
終わりに
2026年はAIエージェント元年なんてことも言われているようです。AIの成長や進化にはすごくワクワクさせられます。
一方で、進化とともにセキュリティの問題もものすごいスピードで増えているように感じます。
今回、そんなに大層な問題提起ではないかもしれませんが、誰かの目に留まり議論できたら嬉しいなと思ってます。
エンジニアの方はもちろん、非エンジニアの方もぜひお気軽にコメントください！
それではまた、ポケットから🐈⬛
技術者向け補足
この記事では一般向けに「入国審査」という比喩を使いましたが、技術的には VATE は、AI agent の risky external action に対して、受け入れる側が何を確認し、どのような receipt を残すべきか、という verifier-side の狭い論点を扱っています。
A2A や MCP を置き換えるものではなく、それらに隣接する discussion draft / gap-analysis question として整理しています。
前回の記事はこちら
こちらもぜひご覧ください🐈⬛
