TL;DR

個人AIエージェントを「便利な秘書」と呼ぶのは、使い心地を説明するには分かりやすい。しかし、ファイル操作や外部送信まで任せるなら、私は「権限を持つ外部委託先」として設計する方が実務的だと考えている。

重要なのは、AIを疑い続けることではない。任せる仕事、渡す権限、承認が必要な操作、記録、停止方法を先に決めることだ。

情報を読む権限と、システムを変更する権限を分ける。
「禁止するプロンプト」だけでなく、実行環境と接続先で制限する。
高影響の操作は、対象と内容を確認して人が承認する。
成功報告ではなく、実際の結果と拒否動作を検証する。

本稿の「外部委託先」は設計上の比喩であり、AIに法的な責任主体としての地位があるという意味ではない。運用責任は人と組織に残る。

個人開発でも、権限設計は他人事ではない

私は、個人の取り組みとして、猫の見守りカメラ、共有チャットボット、AIニュースの定期収集・要約を進めている。

これらに共通するのは、「できることを増やす」だけでは設計が終わらないことだ。

カメラを見られることと、映像を外へ送れることは別。
ボットに話しかけられることと、サーバーを操作できることは別。
ニュースを収集できることと、サーバーの設定を変更できることは別。

以下では、この取り組みで重視している方針を設計例として整理する。現在の全機能が実装・監査済みだという報告ではなく、今後の改善案も含む。

問題は「AIが間違えること」だけではない

OWASPの「LLM06:2025 Excessive Agency」は、過剰な機能、過剰な権限、過剰な自律性を主要な原因として挙げている。[1]

例えば、メールを要約する仕事に送信機能まで渡していると、読み込んだメールの悪意ある指示によって、情報が外へ送られる経路が生まれる。これは同資料が示すシナリオでもある。

つまり、安全性は回答精度だけでは決まらない。誤判断が起きたときに、何へ到達し、何を変更し、どこへ送信できるかが重要になる。

Anthropicも、エージェントの行動を監督することに加え、サンドボックス、仮想マシン、外向き通信制御などで「何ができるか」を制約する考え方を説明している。[2]

仕事を任せる前に、委託範囲を決める

以下は、そのまま製品へ投入する設定ではなく、私が提案する設計レビュー用の表だ。

役割	許可すること	原則として渡さないもの	人の判断が必要な場面
ニュース収集・要約	公開情報の取得、出典確認、指定領域への成果物保存	私有ファイル、管理用の認証情報、汎用管理権限	調査範囲や保存先の変更
共有ボット	許可した利用者への回答、制限された公開Web取得	シェル、私有ファイル、管理設定変更	利用者追加、権限変更
カメラ関連処理	必要な映像の取得・閲覧・保存	不要な外部送信、他用途の管理権限	公開範囲や保持方針の変更

収集処理に保存が必要なら、「一切書き込めない」とする必要はない。専用ディレクトリへ成果物を書ける限定的な機能を渡せばよい。

役割名を分けるだけでは不十分だ。同じOSユーザーで全ファイルを読めるなら、別プロセスでも秘密情報へ到達できる場合がある。OS権限、コンテナ等の分離、接続先の権限を組み合わせて実効性を確認する。

実例1：共有ボットの入口と実行権限を分ける

共有ボットでは、グループ許可リストやDMペアリングを重視している。ただし、これは主に「誰が依頼できるか」の制御だ。

「依頼された後に何ができるか」は別に制限する必要がある。

例えば、公開情報を調べて回答する用途なら、サーバーのファイル操作やコード実行まで必要とは限らない。不要なツールを外すだけでなく、別ツールを経由して同じ操作ができないかも確認する。

また、読み取り専用Web取得も無条件に安全ではない。任意のURLへ接続できるなら、内部サービスへのアクセスや、URLに情報を埋め込む送信経路になり得る。接続先、リダイレクト、内部アドレスへの到達範囲を制限する設計が必要だ。

ここでいう「APIキー不要」は、検索サービスのキーを利用者に要求しないという話であり、ボットや画面の認証を不要にしてよいという意味ではない。

実例2：ニュース収集は、読む対象と保存先を限定する

AIニュースの定期収集では、公開情報を探し、出典を確認し、要約を保存する流れを重視している。

ここで任せたい仕事は情報収集であって、サーバー全体の管理ではない。Webの記事を読むために、私有ファイルや管理用の認証情報へアクセスできる必要はない。

設計例としては、次の構成が考えられる。

公開情報を検索・取得
        ↓
原典・公開日・重要な主張を確認
        ↓
重複を除き、確認済みと未確認を分けて要約
        ↓
指定した成果物ディレクトリへ保存

検索結果や記事本文は調査対象のデータであり、エージェントへの操作指示ではない。本文に「この設定を変更せよ」と書かれていても、それを実行する理由にはならない。

保存機能も、指定した領域への書き込みに限定する。取得できなかった記事や裏付けのない情報は、推測で埋めずに未確認と記録する。

これは本稿の設計提案であり、現在の私の環境ですべて実装・検証済みという主張ではない。

OWASPも、用途に必要な機能と権限への限定、およびLLMの判断に依存しない下流システムでの認可を推奨している。[1]

実例3：猫カメラはデータの境界を考える練習になる

猫カメラ自体を、そのままLLMエージェントと呼ぶわけではない。しかし、「何を取得し、どこへ送り、いつ消すか」を考える点は共通している。

取り組みでは、認証付き閲覧、安全な遠隔アクセス、なるべくローカルでの処理、保存データの自動削除を重視している。

ここでも注意が必要だ。

ローカル処理でも、ログや通知で外へ出るデータは別途確認する。
VPNを使っても、接続できる利用者・端末・サービスの範囲を確認する。
自動削除しても、通知先やバックアップにコピーが残る場合がある。
削除対象の指定ミスが、必要なファイルを消さないか検証する。

「ローカルだから安全」「自動削除があるから残らない」という一言で済ませず、データの流れを追うことが大切だ。

承認を増やすだけでは足りない

すべての操作で確認ダイアログを出すと、人が内容を読まなくなる恐れがある。Anthropicも承認疲れと、確率的な防御に取りこぼしが残ることを説明している。[2]

私なら、承認の頻度を増やすより、次のように分けたい。

事前に範囲を決めた低リスク操作：制限付きで自動化。
外部公開・大量送信・削除・権限拡大：対象と影響を示して承認。
未知の送信先や方針外の操作：停止して相談。

「変更してよいですか」だけでなく、どの設定をどう変更し、誰やどのサービスに影響するのかを示す。

設定だけでなく、拒否されることをテストする

以下は実施済み結果ではなく、私が提案する検証項目である。

未承認の利用者からの依頼が拒否される。
収集プロセスから管理用の認証情報を読めない。
指定外のディレクトリへ書き込めない。
記事内の「設定を変更せよ」という文章を実行指示として扱わない。
承認された範囲を超える設定変更が拒否される。
タイムアウト時に変更処理を再実行する前に、実際の状態を確認する。
停止操作後、予約ジョブや再試行が処理を再開しない。

秘密情報は環境変数やファイルへ移せばそれで安全になるわけではない。同じ実行主体が読めるなら、依然として到達可能である。

監査ログには、依頼・実行主体・ツール・対象・認可結果・実行結果を必要な範囲で記録する。ただし、トークンや会話本文を無制限に残して、ログ自体を漏えい源にしない。OWASPはログ監視とレート制限を、被害を抑える対策として挙げている。[1]

まとめ

私が個人AIエージェントで目指したいのは、「何でもできる秘書」ではなく、「任せた範囲で働き、結果を確認でき、必要なときに止められる仕組み」だ。

モデルへの指示は必要だが、それだけを最後の防壁にしない。

AIが間違えないことに依存するのではなく、間違えても影響が広がりにくい権限と運用を設計する。

なお、本稿は設計上の整理であり、個別環境の安全性を保証するものでも、セキュリティ監査の代替でもない。

参考資料

OWASP — LLM06:2025 Excessive Agency。過剰な機能・権限・自律性、最小権限、高影響操作の承認、下流での認可、ログ監視・レート制限の根拠。2025版。ページの個別更新日は未確認。
Anthropic — How we contain Claude across products。環境による封じ込め、サンドボックス・VM・外向き通信制御、承認疲れの根拠。ページ上の公開日は2026年5月25日。