AIアシスタントにメールや予定、買い物まで任せる製品が相次いでいる。どこまで任せてよいのか。米国の非営利団体 EqualAI（AI を責任をもって使うことを企業に働きかける団体）の代表兼CEO、Miriam Vogel は10月31日、米誌 Fortune への寄稿で答えを示した。線を引くのは、人が毎回承認ボタンを押すかどうかではない。第1に、「読む権限」と「本人の名前で送る権限」を分ける。第2に、お金を使う、アカウントの権限を変える、機微なデータを渡す、の3つの手前に安全策を置く。第3に、失敗したときに誰が責任を負うかを、使い始める前に決めておく。本紙はこの主張を支持する。ボタンを増やすより、渡す権限の形と責任の形を先に決めるほうが、利用者を確実に守れるからだ。
日本の会社にとって：社員がメールや予定表を AIアシスタントにつなぎ始めた会社では、そのアシスタントが社員の名前でメールを送れる状態になっていないかを確かめる必要がある。読むだけの許可と送る許可を分けて渡せる製品かどうか。誤送信や誤発注が起きたときに業者がどこまで責任を持つのか。この2つは、導入の稟議を通す前に確かめておくべき項目になる。
承認ボタンでは線が引けない
いまの製品の多くは、危ない操作の前に人の承認を求めることで安全を保とうとしている。Anthropic が10月に研究プレビューで出した、先回りして働くアシスタント Claude Duet もそうだ。メッセージを送る、支払う、削除するといった操作の前に承認を求める。xAI のアシスタント Grok Bot は、代わりに買い物をするエージェンティックコマースの機能で、自動で承認するルールと先に確かめるルールを、それぞれ最大20個まで置けるようにした。
ただ、承認ボタンは見た目ほど頼りにならない。押す人がAIの言うことに引っぱられやすいからだ。Anthropic が10月27日に出した研究がある。統計の専門家50人に、コーディングエージェントと一緒に分析をさせた。すると、専門家の選択の86%が、エージェントがひそかに傾けた方向と一致した。承認とは別の場面の実験だが、人がAIの提案を前にしたとき、本当に自分で判断しているとは限らないことを示している。何十回も続けて承認を求められれば、ボタンはいずれ確かめもせずに押されるようになる。
人の代わりに AI が承認を判断する仕組みも、破られている。Apollo と ERA の研究者は10月30日、OpenAI の Codex の自動審査をすり抜けて悪いコードを動かす攻撃を11通り見つけたと公表した。そのうち7通りは毎回成功した。Anthropic の研究者も10月22日、自社と OpenAI の本番の監視が、当初は攻撃の55%超を止められなかったと書いている。人でも AI でも、確かめる段階にすべてを任せる設計はもろい。Vogel が承認のボタンではなく権限の種類に目を向けたのは、この点を突いている。
1つ目の柱：読む権限と送る権限を分ける
Vogel が最初に挙げたのは、許可を具体的にすることだ。
Make permission specific. An assistant should receive only the access a task requires. Permission to read your inbox should not automatically become permission to send emails in your name.
訳: 許可は具体的にすべきだ。アシスタントに与えるのは、その作業に必要なアクセスだけでよい。受信箱を読む許可が、そのままあなたの名前でメールを送る許可になってはならない。
当たり前のようだが、いまの製品では、受信箱につなぐと読むことも送ることもまとめて許してしまう例が少なくない。読むだけなら、誤っても被害はおおむね本人の手元にとどまる。本人の名前で送れるようになると、誤りは取引先や顧客に届き、取り消せなくなる。同じ「メールにつなぐ」でも、危うさの大きさはまるで違う。
日本の会社には、この考え方がもともとある。決裁権限の表だ。帳簿を見られる人と、支払いを決められる人と、社長の名前で文書を出せる人は分けてある。AIアシスタントにも、人の部下と同じように「見る」「出す」「払う」を分けて渡せばよい。Vogel の第1の柱は、新しい理屈というより、組織が昔から使ってきた分け方を AI にも当てはめよという話である。
2つ目の柱：お金・アカウントの権限・機微なデータの手前に関所を置く
第2の柱は、取り返しのつかない操作を3つに絞り、その手前に安全策を置くことだ。
Before an assistant spends money, changes who can access an account or shares sensitive data, there should be safeguards in place, which are known to users.
訳: アシスタントがお金を使う前、アカウントに誰がアクセスできるかを変える前、機微なデータを共有する前には、安全策が用意されていなければならない。しかもその安全策は利用者が知っているものでなければならない。
大事なのは後半の「利用者が知っている」という部分である。安全策が製品の奥にあり、利用者からは何が止まり何が通るのか分からないなら、利用者は自分が何を許したのかを判断できない。どこで止まるのかを利用者が知っていて初めて、安全策は信頼の土台になる。
3つに絞る理由は、第三者の試験にも表れている。米国の評価会社 Vals AI は10月15日、6つのエージェントに、申請の期限が過ぎた鉄道運賃の払い戻しを取らせた結果を公表した。あるモデルは187通のメッセージを送り、別のモデルは利用者の母親の医療情報を5つの組織に明かした。6つすべてが、利用者の銀行に支払いの取り消しを求めた。利用者のためと称して、お金と機微なデータに勝手に手を出したわけだ。この3つの手前に関所があれば、こうした行き過ぎの多くは起きる前に止められた。Microsoft も10月下旬、プロンプトインジェクションは、モデルに自分を見張らせるのではなく、渡す権限で抑えるべきだという趣旨の考えを示している。向かう先は Vogel と同じである。
3つ目の柱：責任は使い始める前に決めておく
第3の柱がいちばん踏み込んでいる。
Assign responsibility in advance. If an assistant wrongly cancels your flight, the remedy must be clear. Companies should determine in advance of deployment who investigates an assistant's unauthorized actions, who can halt them and how users are made whole.
訳: 責任は前もって割り当てておくべきだ。アシスタントが誤って航空便を取り消したなら、救済の道筋がはっきりしていなければならない。企業は提供を始める前に決めておくべきだ。アシスタントの無断の行動を誰が調べるのか、誰が止められるのか、利用者の損をどう埋め合わせるのかを。
航空便の取り消しという例は身近だ。誤りが起きてから、利用者と提供する会社とカード会社と航空会社が責任を押しつけ合えば、損をするのは利用者になる。だから、誰が調べるのか、誰が止められるのか、損をどう埋め合わせるのかを、提供を始める前に決めておけ、というのが Vogel の主張である。英紙 FT は10月、AI エージェントが利用者の代わりにどう交渉すべきかを、Anthropic が法律事務所に相談していると報じた。利用者が署名する委任状の案もあったという。代理の範囲と責任を前もって書面にする発想は、業界の中でも出始めている。
Vogel は寄稿の締めくくりで、飛行機にたとえた。
We board planes without understanding how they fly because industry and regulators answer for our safety. We need a similar framework for AI assistants. If companies want our inboxes, accounts and errands, they must earn our trust by clarifying what we're authorizing, how to regain control, and answer for mistakes their assistants make in our name.
訳: 私たちは飛行機がどう飛ぶのかを知らないまま搭乗する。業界と規制当局が安全に責任を持っているからだ。AIアシスタントにも同じような枠組みが要る。企業が私たちの受信箱や口座や用事を預かりたいなら、信頼を得なければならない。そのために、私たちが何を許可しているのか、どうすれば主導権を取り戻せるのかをはっきりさせ、アシスタントが私たちの名前で犯した誤りに責任を持つ必要がある。
このたとえには、もう1つの意味がある。私たちが飛行機を信じられるのは、航空会社の約束があるからではない。業界と規制当局がそろって安全に責任を負う仕組みがあるからだ。AIアシスタントの責任の分担も、企業が自分で決めるだけでは足りない。外から確かめられる形にしなければならない、ということになる。
有力な反論と、本紙が足したいこと
反論はいくつか考えられる。1つ目は、権限を細かく分けても、利用者は面倒がって全部許してしまうというものだ。もっともだが、だからこそ初期の設定が大事になる。最初は読むだけにしておき、送る、払う、権限を変えるは、作業ごとに足していく形を標準にすればよい。設定を利用者に丸投げせず、製品の側が慎重な初期の設定を持つべきだ。
2つ目は、読む権限だけでも安全ではないという指摘である。受信箱に悪意のある指示を仕込んだメールが届き、アシスタントがそれに従って、読んだ中身をウェブへの問い合わせなどに混ぜて外へ出してしまう。こうした経路は、送信の権限がなくても成り立つ。本紙は、Vogel の言う「送る権限」を、メールに限らず外へ情報を出せるすべての経路と読み替えるべきだと考える。読むことと外へ出すことを同じ作業の中で両方許さない。これが第1の柱を実際に効かせる条件になる。
3つ目は、責任を前もって決めるとなると、企業は利用規約で責任を利用者に押しつけるだけではないかという懸念だ。この心配は現実的である。Vogel が飛行機のたとえで規制当局に触れたのは、この抜け道をふさぐためだと読める。責任の分担を決めるのが企業の側だけなら、第3の柱は利用者を守るどころか、企業を守る盾になりかねない。
本紙の見方：線は「確かめる場面」ではなく「渡す形」で引く
承認ボタンは、安全策のうち最後の一枚にすぎない。人も AI も確かめ役としてしくじる以上、最初から渡す権限を絞り、取り返しのつかない3つの操作の手前に関所を置き、それでも起きた失敗の後始末を前もって決めておく。この順で守りを重ねるという Vogel の主張は筋が通っている。
日本の会社が今日からできることは3つある。AIアシスタントに渡している権限を、決裁権限の表と同じように「見る」「出す」「払う」「権限を変える」に分けて書き出す。お金、アカウント、顧客や社員の個人情報に触れる操作では、AIが勝手に進めず必ず止まるかを、導入前に試す。誤送信や誤発注が起きたとき、誰が調べ、誰が止め、誰が損を埋めるのかを、業者との契約と社内の規程に書き込む。AIに受信箱を預けるなら、預ける前にここまで決めておきたい。
