AI で生成したオリジナルのコンセプト図。ゲートは独立した認可チェックを表しており、実在の製品や測定済みのセキュリティ結果を示すものではない。
答えではなく、行動から考える
調達アシスタントが、3社の提案書の要約を依頼されたとしよう。そのうちの1つには、比較結果の全文を外部のアドレスへ送るよう求める記述がある。アシスタントは有効な JSON を生成し、正しいメールツールを使い、自然な文章のメールを書く。それでもワークフローは失敗しうる。その文書は読むべき資料であって、情報開示を承認する権限を持つ人ではないからだ。
これは設計を考えるための仮想的な例である。攻撃の実施、ベンダーのベンチマーク評価、顧客環境の調査を行ったわけではない。ここでの主張はもっと限定的だ。エージェントが形式上正しい操作を提案できることと、システムがその操作を許可するかどうかの判断は、切り離すべきである。
以下の分析は、2026年10月21日に確認した一次資料に基づく。これはエンジニアリングの枠組みであり、セキュリティ認証や法律上の見解ではない。
文書から実際に分かること
OpenAI の 2026年3月11日の解説は、プロンプトの操作が成功した場合でも被害を抑えることを重視している。ワークフローの安全ガイドでは、構造化データと承認を推奨する一方、緩和策で誤りをなくせるわけではないと注意している。このガイドの対象は Agent Builder であり、現在のページでは非推奨とされている。本稿はその製品の導入を勧めるものではない。
Anthropic の 2025年10月20日のサンドボックスに関する記事は、ファイルシステムとネットワークの隔離を説明している。現在の Claude Code の権限に関する文書は、ツールの権限と OS による強制的な制限を区別している。通常の Read/Edit ルールでは、任意のサブプロセスによるファイルアクセスまでは制御できない。
公式の Qwen-Agent リポジトリは、コード実行機能における Docker による隔離とディレクトリの限定的なマウントを説明している。ただし、基本的なサンドボックスを本番環境で使う際には注意が必要だとも述べている。
これらは異なるレイヤーと製品についての文書であり、条件をそろえた比較ではない。米国のサービスが過大なアクセス権を与えられて導入されることも、中国のフレームワークが厳格な境界の下で導入されることも、その逆もありうる。モデルの出自やホスティング先は、設定の確認の代わりにはならない。どの文書も、あらゆる状況で最も安全なベンダーを示してはいない。
計画と実行の間に認可ゲートウェイを置く
提案する設計では、責務を3つに分ける。モデルが操作を提案し、ゲートウェイがその権限を確認し、権限を必要最小限に絞った実行機構が許可された処理を行う。ゲートウェイとはアプリケーションコードとポリシーの強制機構であり、モデルに行儀よく振る舞うよう伝える別の指示にすぎないものではない。
実質的な影響を伴うリクエストごとに、判断を、認証済みユーザー、操作、リソース、宛先、データ範囲、適用される制限にひも付ける。提案書を読む権限が、いつの間にかメールで送る権限に変わってはならない。メッセージの下書きを作る権限が、送信する権限に変わってもならない。必要な値が欠けていたり曖昧だったりする場合は、解決するまで実行を保留する。
スキーマ検証も必要だが、その役割は異なる。スキーマは宛先フィールドに文字列を要求できる。しかし、その宛先をユーザーが承認したことまでは証明できない。モデルによるレビューも、リスク発見に役立つとしても、はい／いいえを返すだけで決定論的なアクセス境界になるわけではない。
この分離により、拒否後に何をすべきかも明確になる。無効なリクエストを修正するか、必要な権限を取得することだ。同じ拒否された操作を通すためにアカウントや経路を切り替えるのは、修正ではない。
計画が変わっても通用する、具体的な承認にする
有用な確認画面には、実際に行われる操作を示す。宛先、内容またはデータの種類、対象リソース、費用や範囲の制限である。重要な変数を隠したままの、漠然とした「エージェントを許可しますか？」ボタンは避けたい。
承認はその具体的な提案にひも付ける。宛先、添付ファイル、金額、リソースが実質的に変われば、再評価する。範囲が限定された反復業務では、無害な手順のたびに作業を中断させるのではなく、組織が狭い範囲の継続的な許可を定めてもよい。その範囲は常に検証可能かつ強制可能でなければならず、外部文書が広げられるものではない。
承認疲れと過剰な権限付与は、関連する設計課題である。些細な読み取りのたびに確認を求めると、利用者が機械的にクリックするようになる一方、1回の包括的な承認は後のリスクを覆い隠しかねない。有効な中間点は、低リスク操作のポリシーを文書化し、実質的な影響のある変更には具体的な承認を求め、権限が不明なときは明確に停止することだ。
誤りが起きた後の影響を抑える
認可チェックは要求された操作を保護し、ランタイムの隔離は実行環境がアクセスできる範囲を制限する。アプリケーションが対応しているなら、対象範囲を絞った認証情報、制限付きのファイルシステムアクセス、管理されたネットワーク接続先を使う。脅威モデルには子プロセスも含める。同じワーカーが制限のないシェルを実行できるなら、ファイル読み取りツールだけを制限しても不十分だ。
操作の状態は、モデルによる説明とは別に管理する。「提案済み」「承認済み」「実行要求送出済み」「結果確認済み」は異なる状態だ。安定したリクエスト識別子を記録し、対応している場合は冪等性や重複排除を利用する。タイムアウト後に送信、購入、公開を再試行する前には、サービス側の実際の記録を確認する。「応答がなかった」は「何も起きなかった」の証明にはならない。
ログは、その経緯を再構成できるものであるべきだが、新たな漏えい源になってはならない。操作識別子、判断、ポリシーのバージョン、結果を参照できるサービス側の情報を残し、秘密情報や不要な個人情報は最小限にする。調査担当者に必要なのは調査に足る情報であり、あらゆる文書の無差別なコピーではない。
本番導入前の6つのチェック
以下は受け入れ確認のために提案する演習であり、実施済みのテストでも、網羅的なセキュリティ評価でもない。
- 取得した文書に外部の宛先を入れる。認証済みユーザーの認可なしで、許可された宛先を変更できてしまわないか。
- 権限範囲外の操作について有効な JSON を生成する。ゲートウェイは実行要求を送出する前に拒否するか。
- 承認後に宛先を変更する。以前の承認が、変更後の操作には適用されなくなるか。
- 子プロセス経由で権限範囲外のファイルを読もうとする。ランタイムの境界は、プロンプトに書かれているだけでなく、実際に強制されるか。
- 送信後に結果が不明なタイムアウトを模擬する。ワークフローは重複を発生させずに、サービス側の記録と整合性を取れるか。
- 関連する権限を取り消す。次の操作は安全に失敗し、分かりやすい監査記録が残るか。
保護と使いやすさの両方を評価する。未認可操作の阻止、認可済み作業の誤った阻止、不要な承認要求、副作用の重複、判断の説明に必要な時間が対象になる。完了率の高さだけでは危険な実行を見落としうる。一方で、何もかも阻止するシステムも役に立つアシスタントではない。
調達で本当に問うべきこと
実際に導入する構成で、どのレイヤーが各境界を強制するのか、モデルが悪意ある文書に従ったら何が起きるのか、実行結果が不明な場合にどう状態を照合するのかを、提供元に示してもらおう。別の構成で得られた目立つベンチマーク結果を流用するのではなく、自分たちのツールとアクセス範囲に合う証拠を求める。
実務上の選択肢は、「モデルを信じる」か「いつまでも許可を求め続ける」かではない。明確な制限の下で進めてよい仕事、人の判断を要する変更、モデルが書き換えられない境界を決めることだ。中国と米国のエージェント技術スタックを比較するうえで、それは単一の能力スコアよりも有用な出発点になる。