あなたの AI アシスタントに、仕事を任せるにはどのくらいの権限が必要か？

AI 生成の編集イラスト：情報の読み取りとメッセージ送信は、別々に許可します。

AI にメールの整理、会議の準備、仕事のフォローアップを任せることは、もう自然に感じられます。ためらいが生まれるのは、認可ボタンを押す瞬間です。どこまで見られるのか？ 自分の代わりに何ができるのか？ この権限は後から取り戻せるのか？

最近のある議論が、こうした疑問を表舞台に押し出しました。Business Insider が 10 月 9 日に掲載したインタビューで、XMTP Labs の CEO である Shane Mac 氏は、自身の個人財務エージェントが会社の Slack にレポートを投稿したと述べています。この記事は編集を経た当事者の口述であり、独立した技術監査ではありません。

このインタビューはその後、Reddit の r/technology で共有されました。議論の中では、AI に機密情報を触らせることに反対する声もあれば、個人アカウントと仕事用アカウントがなぜ混在しているのかと問いかける声もありました。こうした反応は、ひとつの具体的な懸念を示しています。アシスタントが情報の読み取りとメッセージの送信の両方を行えるとき、ユーザーは情報の行き先をどう把握すればよいのか、という問題です。

10 月 12 日には、CNA が公開した TikTok 動画も、ユーザーが AI エージェントに過剰な権限を与えていないかを取り上げました。動画の説明によれば、関連する発言は、ユーザーが自分で付与したアクセス権を理解できているかどうかに焦点を当てています。

これらの内容は、すべてのエージェントが問題を起こすことを証明するものではありませんが、権限が個人アシスタントをめぐる公の議論の対象になっていることを示しています。AI を本気で使いたい人にとって、認可はタスクに沿って進めるべきものです。

同じメールでも、整理と送信には別の権限が必要

アシスタントにこんなタスクを出したとします。毎朝、返信が必要なメールを見つけ、要点を列挙し、いくつかの返信案を用意する。

これをこなすには、メールの検索と読み取りが必要です。返信案はまず会話の中に表示し、あなたが確認すればよいでしょう。メールの自動送信、メールの削除、転送設定の変更は、いずれも別の認可判断であるべきです。

最初からすべての操作を開放してしまうと、アシスタントはこのタスクに必要な範囲を超えた能力を手にします。後からプロンプトを調整しても、アカウントの実際のアクセス範囲がそれに合わせて変わるとは限りません。

まずはタスクを三つの問いに分解してみましょう。

• 何を読み取れるか？ どのアカウント、どの期間、どの資料か？
• 何を実行できるか？ 検索と読み取りだけか、それとも送信・変更・削除も許可するのか？
• 結果は誰に渡すか？ 現在の会話に表示するのか、それとも明確な個人の受信先に送るのか？

この三つは別々に扱う必要があります。ソースアプリの認可はアクセスできるデータを決め、接続レイヤーは呼び出せる操作を制限でき、アシスタントのワークフローはさらにパラメータと結果の受け取り手を定めなければなりません。

三つの層は別々に設定する必要があります。図はタスク設計の提案であり、ひとつのスイッチですべての制限を完結できるものではありません。

「読み取り専用」にも、明確な情報の行き先が必要

読み取り専用の権限は、アシスタントの第一段階に適しています。まず情報を整理し、人に結果を確認してもらい、それから操作能力を少しずつ増やしていくのです。

ただし、読み取り自体も情報をアシスタントの処理過程に持ち込みます。アシスタントがソースデータを変更できなくても、別のツールがメッセージ送信を許していれば、読み取った情報がほかの場所へ持ち出される可能性は残ります。

ですから、個人の朝のブリーフィングは、まずあなたのプライベートな会話に直接表示すればよいでしょう。チームのブリーフィングなら、チームが認めたデータソースと受け取り先を使うべきです。個人の財務、家族の予定、会社のメッセージは、それぞれ別に接続と出力チャネルを用意する価値があります。

メッセージを送るフローでは、アカウントと受け取り先を明確にし、できるだけ安定した宛先識別子を使い、必要に応じて最終的な内容をユーザーに確認できるようにすべきです。似たようなグループ名、連絡先名、アカウントラベルは、唯一の判断根拠にするには適しません。

これはワークフローで実装すべき設計です。「メッセージ送信」を呼び出せることは、システムがすでに一つひとつの内容がすべての受け取り手に適しているか判断したことを自動的に意味するわけではありません。

アシスタントに、説明できる能力のセットを

OOMOL では、こうした判断をアカウント接続とインターフェース呼び出しの範囲に落とし込めます。権限管理のドキュメントでは、Provider の認可範囲、接続のアクセス権、許可される操作をそれぞれ分けて説明しています。

たとえば、メール整理アシスタントは、メールの検索と読み取りだけを許可する接続を使えます。あなたの代わりに送信する必要が出たら、送信タスク用にそれに対応する能力を設定します。同じアカウントでも、操作範囲やメンバーのアクセス範囲が異なる複数の接続を作成できます。

具体的にどの認可範囲を選べるかは、ソースサービスの対応状況によります。どの操作を制限できるかも、現在の接続が提供するインターフェースを確認する必要があります。レコード単位の可視範囲は、依然としてソースアプリの権限とリクエストパラメータの影響を受けます。

OOMOL のカスタムインターフェース制限には、見落としやすい細かい点がもう一つあります。それは Proxy と動的な call_tool の入口を無効化するというものです。これにより、呼び出しは明示的に許可された操作だけに収まり、別の汎用入口がすでにチェックした範囲を超えてしまうのを防ぎます。この挙動は上記の権限ドキュメントに基づくもので、設定時にあわせて確認できます。

チームが接続サービスを自分で管理する必要があるなら、OpenConnector がオープンソースでセルフホスト可能な道筋を提供します。チームは自分の環境で接続資格情報、操作ポリシー、実行記録を管理し、MCP や HTTP などの入口を通じてアシスタントにアプリ操作を提供できます。セルフホストガイドでは、実行側の認証、許可・禁止する操作、マスキングされた実行記録の設定について説明しています。

これらの機能は、チームがアクセス境界を設けて確認するのに役立ちます。アシスタントに返される業務データは、依然として機密情報として扱う必要があります。メッセージの受け取り手、内容の確認、実行の確認も、アシスタントまたはアプリのワークフローで実装しなければなりません。

小さくて役立つタスクから認可を始める

最初のバージョンのアシスタントは、一つのことだけをすればよいでしょう。今日の会議と関連メールを読み取り、あなたが注意すべき事項をプライベートな会話に置く、というものです。

正しいアカウントを選び、正しい資料を見つけ、出典を示せることを確認できたら、それからタスクの作成やメッセージ送信の能力を追加することを検討します。操作を一つ増やすたびに、次のことに答えられるべきです。それはどのタスクに役立ち、どのアカウントに作用し、結果はどこへ行くのか？

一時停止したいときは、何を取り消すべきかも分かっているべきです。アカウント接続の切断、呼び出し資格情報の失効、定期タスクのキャンセルは、それぞれ異なる制御点に対応します。すでに送信された情報は、それによって自動的に消えるわけではありません。

始めたいときは、OOMOL Connections でタスクに必要な接続を設定し、権限管理ガイドに沿って許可する操作を絞り込み、アシスタントに明確なリクエストを渡します。

今日注目すべきメールを整理して。検索と読み取りだけにして、送信や削除はしないで。結果は現在の会話に表示し、元のメールへのリンクを残して。

アシスタントの能力がタスクに対応していると、認可はより理解しやすくなり、後から能力を増やすときにも根拠がはっきりします。