信頼境界でエージェントを分ける設計——顧客向けと管理者向けを切り分ける理由

機能で分けるか、信頼境界で分けるか

AIエージェントを設計するとき、「何をするか」で役割を決めることが多い。検索エージェント・注文エージェント・分析エージェント——機能の名前がそのまま分割の基準になる。

しかしこの切り方には盲点がある。機能ごとに分けたエージェントが同じ認証・同じ権限で動くなら、内部では「何でもできる万能エージェント」と変わらない。一箇所で誤動作が起きれば、その権限の範囲全体が影響を受ける。

分割の軸を「誰の認証を使うか・誰のデータに触れるか」に変えると、状況が変わる。これが 信頼境界による分割 だ。エージェントに与えられる権限が役割によって自然に制限されるため、一つのエージェントが問題を起こしても、他のゾーンへの波及が防ぎやすくなる。

コマース・エージェント設計に見る信頼境界の実例

（B：Anthropicが公開した設計パターンの解説）

Anthropicが2026年9月3日に公開したコマース・エージェント設計（Apache 2.0）は、この原則を具体的に示している（GitHub: anthropics/commerce-agents）。小売・旅行・通信・エンターテインメントの4業種向けテンプレートを含み、2つのエージェントで構成される。

• 顧客エージェント（shopping agent）：顧客の認証スコープで動く。カタログ検索・商品比較・カート追加ができる。決済は行わない。
• 管理エージェント（merchant agent）：管理者の認証で動く。在庫の確認・価格設定・マーケティング分析を担う。顧客データへの直接アクセスはしない。

商品カタログ・決済・広告はすべて「スコープ外」——小売業者自身の既存システムに残る。エージェントはカートを作るが、決済を処理しない。このスコープの外側が、設計上もっとも重要な選択だ。

実装面では、Python 3.11+ と Node 22 で動き、Claude API・Amazon Bedrock・Microsoft Foundry・Google Cloud Vertex AI 上にそのまま展開できる。モデル実装を固定しない設計は、既存記事「モデルフリー設計」で解説した原則と同じ発想だ。

「持たない」設計が最大の防御になる

（B：設計原則・一般論）

エージェントが持たない権限は、侵害されても悪用できない。決済処理をエージェントが持たないということは、エージェントが何らかの問題を起こしても、決済フローが不正に動くことがない。

この「持たない設計（minimal scope）」は3つの利点をもたらす。

• 既存の安全性をそのまま活用できる：決済・在庫DB・広告配信は、すでに各社がセキュリティ要件を満たした形で運用している。エージェントがそこに触れないなら、その保護も引き継がれる。
• 障害の影響範囲が限定される：エージェントの問題が業務の核心部分（決済・会計）に波及しない設計になる。
• 規制対応コストが下がる：PCI DSSなど決済規制の対象はエージェントではなく既存の決済システムが担い続けるため、エージェント側に新たな準拠義務が生まれにくい。

agens でこの設計を実践する

（A：agens の実装済み機能）

agens のRBACは、ユーザーロールごとに異なる権限プロファイルを設定できる。「顧客」ロールと「管理者」ロールで参照できるツールとデータを分け、横断的な万能権限を持つエージェントが生まれにくい構造を作ることができる。

タスクごとに起動する使い捨てサンドボックスは、異なる信頼レベルのエージェントが同じセッション内で互いのコンテキストに触れることを防ぐ。顧客向けエージェントが管理者向けのデータを参照してしまうケースを、実行環境の設計で排除する。

SSO/SAML/OIDC/SCIMと連携した認証により、既存のIDPが持つ「誰が管理者か」の情報をそのまま権限設計に反映できる。新たに権限マップを作り直す必要がなく、社内の既存の認証基盤が信頼境界の根拠になる。

（B：設計の出発点として）

信頼境界の設計は「どの操作が誰の認証・権限を必要とするか」をマッピングすることから始まる。このマップがエージェントの分割点を決め、ツールの割り当てを決め、スコープ外に委譲する範囲を決める。コマース・エージェントの例でいえば、「決済は誰の権限か？」という問いが設計の起点だった。

よくある質問

最終更新: 2026-09