社内システムにAIエージェントを組み込む検討をしている開発者に向けて、権限管理の設計パターンを整理します。ブロックチェーン業界の事例ですが、考え方は業務システムのエージェント連携にもそのまま使えます。
MetaMask（暗号資産の管理に使われる代表的なウォレットアプリ）が、AIエージェント専用の「Agent Wallet」を発表しました。エージェントとは、人間の指示を受けて自律的にタスクを実行するAIプログラムのことです。取引所での売買や資産移動を、エージェントが自動で実行できるようにする仕組みです。
ここで注目したいのは、単に「AIに権限を渡す」設計ではない点です。エージェントが暴走したり誤作動したりしても、被害を最小限に抑える仕組みが組み込まれています。業務システムでAIエージェントにDB操作や外部API呼び出しを任せる際にも、同じ発想が要求されます。
Agent Walletが解いている問題
AIエージェントに実行権限を渡す場合、最大の懸念は「エージェントが想定外の操作をしたらどうなるか」です。Agent Walletはこの懸念に対し、複数の防御層を重ねる設計で応えています。
具体的には、支出上限（Spend Limits）、許可リスト（Allowlisted Protocols）、リスクプロファイルの3点を、エージェントに権限を渡す前にユーザーが設定します。たとえば「1日の取引上限は10万円まで」「許可された取引先としか取引しない」といった制約を、エージェントの行動範囲として事前に固定する形です。
さらに、実際の取引実行時にはトランザクションシミュレーション（実行前に結果を仮実行して確認する仕組み）、Blockaidという脅威検知サービスによるスキャン、MEV保護（取引の抜き取りを防ぐ仕組み）が挟まります。事前の権限制約と、実行時のリアルタイム検査を二重にかけている点が特徴です。
動作モードは2種類用意されています。デフォルトのGuard Modeは、日次の支出上限や許可リストの範囲外の操作があれば必ず人間の承認（2要素認証）を求めます。オプトインのBeast Modeは承認の割り込みを減らしますが、セキュリティ検査自体は省略しません。
業務システムのエージェント連携との対応関係
この設計は、業務システムでAIエージェントにワークフローの実行権限を持たせる場合の要件定義に、そのまま応用できます。
たとえば、社内の請求書処理エージェントを作るケースを考えます。エージェントに「承認済みベンダーへの支払いのみ、月間上限50万円まで自動実行、それ以外は人間承認へエスカレーション」という制約を課す設計は、Agent WalletのGuard Modeとほぼ同じ構造です。
技術選定の観点では、この手の権限制御を自前実装するか、既存のワークフローエンジンや承認基盤（Camunda、AWS Step Functionsの承認ステップなど）に乗せるかが判断ポイントになります。自前実装は柔軟ですが、シミュレーション（実行前検証）や脅威検知に相当する仕組みを自分たちで作り込む必要があり、保守コストが跳ね上がります。
Ethereum（分散型の台帳基盤で、多くの暗号資産アプリの基盤になっている技術）の世界では、Frame Transactionsという新しい仕組み（EIP-8141として提案中）も進行しています。これはアカウント単位でトランザクションの実行条件をプログラム的に定義できる仕組みで、Ethereumクライアントの一つであるNethermindが対応を表明しています。既存コードベースに権限制御を後付けする際、こうした「アカウントレベルでポリシーを埋め込む」発想は、業務システムのRBAC（ロールベースアクセス制御）を拡張する際のヒントになります。
既存システムに権限制約層を追加する際の確認ポイント
AIエージェントを既存の業務システムに組み込む際、以下の点を確認しておくと設計の手戻りを減らせます。
- 実行前検証: エージェントの操作を本番実行前にドライランやシミュレーションできる仕掛けがあるか
- 上限管理: 金額・件数・頻度など、エージェントの行動範囲を数値で制約できる設定項目があるか
- エスカレーション経路: 範囲外の操作が発生した際、誰に承認を求めるフローが定義されているか
- ログと監査: エージェントの判断根拠と実行結果を後から追跡できる記録が残るか
- 許可リストの管理者: 許可リストの追加・削除を誰が承認し、どこで管理するか
これらは既存の業務システムに承認フローがすでにある場合、そのフローにAIエージェントの実行トリガーを差し込む形で拡張できるケースが多いです。ゼロから作り直す前に、既存の承認基盤にエージェント用のフックを追加できないか確認する価値があります。
保守運用の観点で見ておきたいこと
大規模システムでエージェント連携を長期運用する場合、Beast Mode相当の「承認を減らす設定」を安易に有効化すると、後から原因追跡が難しくなるリスクがあります。承認回数を減らす設定変更は、監査ログの保持期間やアラート設定とセットで見直すのが安全です。
また、許可リストやリスクプロファイルは一度作って終わりではありません。ベンダーの追加・契約終了、取引先の統合などのたびに更新が必要です。運用チームが許可リストのメンテナンスを定期棚卸しのタスクとして組み込んでおくと、放置による権限の肥大化を防げます。
まとめ
Agent Walletの設計は、AIエージェントに業務操作を任せる際の権限モデルとして参考になる部分が多くあります。
押さえておきたいのは、支出上限・許可リスト・リスクプロファイルという3種の事前制約と、実行前シミュレーション・脅威検知という実行時検証を、両方組み合わせる二段構えの発想です。
既存システムにAIエージェントを組み込む前に、承認フローの差し込み場所、実行前検証の可否、許可リストの棚卸し担当を今のうちに確認しておくと、後々の設計変更コストを抑えられます。
まずは自社のワークフローエンジンや承認基盤に、エージェント向けのポリシー設定項目が存在するかどうかを確認するところから始めてみてください。