読み物の一覧 · 重要操作

エージェントに任せた操作

AI エージェントに操作の準備を任せても、取り返しのつかない操作だけは、人が内容を確かめて署名する。依頼と署名を分ける形をまとめます。

起きること

エージェントは、人の代わりに画面を開き、入力し、ボタンを押します。速く、疲れず、指示どおりに動きます。困るのは、指示どおりでないときです。

• 指示を取り違えて、意図しない操作を実行します。
• 読み込んだ文書やウェブページに埋め込まれた指示に従ってしまいます³。
• エージェントに渡した鍵やトークンで、任せた範囲を超える操作が行われます¹。
• あとで「誰が許可したのか」と問われ、エージェントの実行の記録しか残っていません。

エージェントのログには、エージェントが何をしたかは残ります。人が何を許したかは残りません。

問われること

エージェントの操作に一般の法令はまだありません。設計の指針は、どれも同じ方向を指しています。影響の大きい操作は、実行の前に人の承認を求めることです。

• OWASP は、過剰な権限（Excessive Agency）への対策の一つとして、影響の大きい操作の前に人の承認を挟むことを挙げています¹。
• Model Context Protocol の仕様は、ツールを呼ぶ前に利用者の明示の同意を得ることを、ホストの原則としています²。

承認を「エージェントが確認しました」という記録で済ませると、承認したのが人かどうかを、あとで示せません。

残す記録

エージェントに任せるのは、署名の依頼までにします。依頼は誰からでも出せますが、署名できるのは利用者の Passkey だけです。署名が無いまま期限を過ぎた依頼は、実行されません。

署名の対象（ハッシュ）に、次を含めます。

• 実行する操作の内容
• 依頼したエージェントの識別子
• 依頼の番号と、有効期限

"payload": {
  "purpose": "generic.sign",
  "message_digest": "<操作の内容・エージェント・依頼番号・期限の SHA-256>",
  "display_hint": "発注の確定"
}

利用者は Connect で、どのプロダクトの、どの操作に署名するのかを読んでから、Passkey で署名します。エージェントが用意した内容をそのまま通すのではなく、人がその場で確かめた内容だけが記録になります。

実行の直前には、エージェントがこれから行う内容からハッシュを計算し直し、署名のハッシュと一致することを確かめます。依頼のあとで内容が変わっていれば、一致しません。

署名だけでは足りないこと

• どの操作を「署名が要る操作」にするかは、自社で決めます。考え方は 「ログイン済みだから本人だろう」で通してよい操作、よくない操作 にまとめています。
• 署名は、人がその内容を許したことを残します。その判断が正しかったことは示しません。
• 署名の依頼を大量に送りつけて、確かめずに押させる手口もありえます。依頼の数と頻度は、自社のサービスで絞ります。

次の一手

• 署名の手順：依頼の登録から結果の受け取りまで
• 署名を始める：Org の作成