AIエージェントに金融取引を委任する——3層で考える「証明」の設計

「AIが自分の代わりに投資信託を売り買いする」——いま、この構想は単なる将来予測ではなく、金融実務上の検討課題として扱われ始めています。

ただ、実際に任せようとすると、性能とは別の壁が立ちはだかります。

「そのAIは、本当にこの人から、この取引を任されていたのか」を後から検証できるか、という壁です。

何が発足したのか——「AIエージェント×金融取引分科会」の位置づけ

三菱UFJフィナンシャル・グループと三菱UFJ信託銀行の発表によれば、両社は2026年6月30日、三菱UFJ信託銀行が主催する「DID/VC共創コンソーシアム（DVCC）」内に「AIエージェント×金融取引分科会」を設置しました。

非公表2組織を含む28の参加組織（金融機関、ベンダー、リーガルカウンセルなど）が参画し、活動期間は2026年7月から2027年3月までを目途としています。

ここで正確に押さえておきたいのは、これは「仕組みが動き出した」という話ではない、という点です。

発表の言葉を借りれば、本分科会が行うのは、AIエージェントが顧客に代わって金融商品取引を自律的に実行する時代を見据えた、取引の信頼性・安全性・透明性の確保と、実務・法令・ガバナンス上の課題の検討です。

とりわけ「委任範囲の定義および証明」「取引実行結果の検証可能性」の論点整理と、それを支える技術としてのデジタル証明書（VC）の活用可能性・実装要件の確認、来年度の実機を用いた実証実験を見据えたアーキテクチャ設計が挙げられています。

つまり、答えが出た発表ではなく、「何を検証できれば任せられるのか」という問いを、金融実務に即して洗い出す初期段階です。

本稿が注目したいのも、その問いの立て方そのものです。

なぜ「委任の証明」が金融取引の急所になるのか

AIが利用者に代わって商品を選び、注文し、支払う——こうした「エージェンティック・コマース」は、海外ではEC・決済の分野を中心に技術標準化が進みつつある領域です。

ただ、金融商品取引に持ち込むと、難しさの質が変わります。

発表でも、顧客保護や説明責任、AML/CFT（マネー・ローンダリング／テロ資金供与対策）に加えて、AIエージェントによる「ユーザーの意思に沿わない契約行為」の民法上の解釈といった、複数の法令・ガバナンス要件への対応が必要だと整理されています。

言い換えると、金融では「AIがうまく取引できるか」よりも先に、「誰の意思で・どこまでの権限で行われた取引なのかを、後から再現・検証できるか」が問われます。

ここが技術の性能とは独立した急所です。

AIの意思決定で最も重要なのは知能そのものよりも「与える権限の設計」だ、というのが私たちの一貫した見方ですが、金融の代理取引は、その原則が最も厳格な形で試される場面だといえます。

証明は3層で考える

「委任の証明」と一口に言っても、検証すべき対象は一枚岩ではありません。

本稿では、これを次の3層に分けて考えると整理しやすいと捉えています。

分科会が挙げる論点も、おおむねこの3層に対応づけられます。

誰が誰に委任し、どのエージェントが行使するのか

第1の層は「主体の証明」です。

取引の背後にいる利用者本人は誰か、その本人が確かに委任の意思を示したか、そして実際に注文を出しているエージェントは、その委任を受けた当のエージェントか——この3点がつながって初めて、取引の出発点が確かになります。

発表が「ユーザー本人の確認」を金融機関が確認すべき事項の筆頭に挙げているのは、この層に対応します。

本人・委任者・行使者のいずれかがなりすまされたり取り違えられたりすれば、その後の権限設計がどれだけ精緻でも土台から崩れます。

利用者本人の確認は、既存の本人確認（KYC）実務と接続します。

ただし、「どのエージェントが、誰から、どの権限を与えられているか」の確認は、それだけでは完結しません。

本人確認に加えて、エージェントの識別、委任の成立、そして委任の現在の有効性を、別途確認する必要があります。

何を・どこまで・いつまで任せ、取引時点でも有効か

第2の層は「委任権限の証明」で、実務上いちばん作り込みが要る部分です。

ここでつまずきやすいのが、「取引を任せる」を一枚の許可として扱ってしまうことです。

実際には、性質の異なる複数の行動権限が含まれています。

分科会が示した金融商品取引の将来像でも、こうした行動は工程ごとに分けて描かれています。

• 情報の検索・比較（銘柄や商品の情報を集める）
• 提案・選定支援（候補を絞り、示す）
• 運用判断（配分やタイミングの判断）
• 申込み・契約（金融商品の購入・売却の契約行為。業務によっては、注文の生成と外部への送信をさらに分ける）
• 決済（資金の支払い）
• 取引後の管理（記録・照合・状況把握）

これらは、利用者への影響、金銭的リスク、実行後の可逆性が大きく異なります。

情報を集めるだけの委任と、契約や決済まで踏み込む委任を、同じ扱いにはできません。

特に、金融商品の申込み・契約の委任と、その決済（支払い）の委任は、別の工程として分けて設計するのが要点です。

取引を一つの包括的な権限として扱わないことが、設計の出発点になります。

ここで一点補っておくと、「情報収集だから広く許可してよい」とも限りません。

検索・比較でも、機密情報や個人情報へのアクセスを伴う場合は低リスクとは言い切れず、参照できるデータの範囲も制限の対象に含めるべきです。

そのうえで、各権限に「どこまで」の枠を与えます。

枠の例としては、金額上限（1回あたり・期間あたり）、対象商品や口座の範囲、許される行動の範囲、件数の上限、有効期限が挙げられます。

従業員に権限を渡すときに、職務範囲・決裁上限・有効期間・記録・剥奪をセットで決めるのと同じ発想を、AIエージェントの委任にも当てるということです。

そして見落とされがちなのが、有効期限や取消しを「設定できる」だけでは足りない、という点です。

委任は途中で取り消され得るものです。

だからこそ、取引を実行するその時点で、当該の委任がまだ有効か、あるいは失効・取消し済みでないかを確認できる必要があります。

発行時点で有効だった証明が、行使時点でも有効とは限らない——この「取引時点での失効・取消し確認」まで含めて初めて、委任権限の証明は実務に耐えます。

何が実行され、委任範囲内だったかを照合できるか

第3の層は「実行結果の検証可能性」です。

取引が終わった後に、実際に何が実行され、それが委任の範囲内だったかを、後から照合できる状態にしておくことです。

発表が挙げる「取引承諾の根拠の記録」や「取引実行結果の検証可能性」は、この層に当たります。

実務上必要なのは、少なくとも「どの利用者から与えられた、どの委任権限に基づき、どのエージェントが、いつ、何を実行したか」を再現し、その行為が委任範囲内だったかを照合できる状態です。

ここで、説明可能性と監査可能性は、どちらか一方を選ぶものではありません。

利用者への説明には判断根拠の整理が要り、事故調査や異議申立てへの対応には実行事実をたどれる監査証跡が要ります。

完全な内部説明を待つだけでなく、権限と実行記録を照合できる状態を先に設計しておくこと——私たちが優先事項に置いているのはこの点です。

監査証跡だけで法的な責任の所在が決まるわけではありませんが、権限逸脱の有無や事実関係を確認し、責任関係を検討するための前提にはなります。

委任が有効でも、その取引が適切とは限らない

ここで一つ、混同しやすい区別を立てておきます。

「委任が有効であること」と、「その取引が利用者にとって適切であること」は、別の問題です。

正しく委任され、権限の枠内で実行された取引でも、その利用者のリスク許容度や知識・資力に照らして不適切であり得ます。

だから3層の検証とは別に、横断的な統制として次の観点が要ります——投資適合性（利用者に合った商品か）、顧客保護、説明責任、そしてAML/CFT。

発表がこれらを検討事項に含めているのは、委任の検証だけでは金融取引の健全性を担保しきれないことの表れだといえます。

委任チェーンの検証は「入口の正しさ」を担保しますが、「その取引をしてよいか」という中身の妥当性は、また別のゲートで見る必要がある、ということです。

VCは「委任の証明を支える候補」——DIDを含む構成は検討段階

こうした検証を支える技術として発表が名前を挙げているのが、デジタル証明書（VC＝Verifiable Credential）です。

発表で活用可能性・実装要件を検討するとされているのは、主にこのVCです。

VCは、発行者がある主体について行った主張を、改ざんを検知できる形式で発行し、保有者が必要な相手に提示し、検証者が発行元や完全性などを確認できるデータモデルです。

たとえば、委任の対象、金額上限、有効期限などを検証可能な情報として表現する用途が考えられます。

ただし、VCが保証するのは、主として「誰がどの内容を発行し、その内容が改ざんされていないか」です。

記載内容そのものが事実であること、利用者の現在の意思に合っていること、取引が投資適合性を満たすことまで、VC単体が保証するわけではありません。

また、VCを採用しても、権限の取消しや一時停止をどこに記録し、取引時にどのように最新の状態を確認するかは、別途設計する必要があります。

分散型ID（DID）については、DVCC自体が「DIDと連携したVCのビジネス共創」を掲げています。

一方、今回の分科会発表で具体的な検討対象として明示されているのは、主としてVCの活用可能性と実装要件です。

DIDを含む具体的な技術構成までは、今回の発表では示されていません。

VCやDIDを万能の答えとして描くのは、現時点では正確ではありません。

証明の仕組みが何であれ、上で述べた3層＋横断的統制という「何を検証・統制すべきか」の設計が先にあり、技術はそれを実装する手段だからです。

性能だけでなく「権限の設計」が分かれ目になる

見立ては一貫しています。

AIエージェントに金融取引を任せられるかどうかを分けるのは、モデルの賢さだけではなく、「何を・どこまで・いつまで任せ、どう検証するか」という権限と検証の設計です。

今回の分科会が、性能競争ではなく委任の検証とガバナンスの論点整理から入っていることは、この見方と重なります。

言い換えれば、必要なのはAIが本人の代理だと名乗れることではなく、誰が・どのエージェントに・何を・どこまで・いつまで委任し、取引時点でもその権限が有効で、実行結果が委任範囲内だったかを検証できることです。

その際、「安全のために全件を人が承認する」を結論に置くことは、私たちは採りません。

現実的なのは、責任主体を明確にしたうえで、どこまでを自動で実行させ、どの条件で人の再承認・介入・停止を求めるかを、権限ごとに設計することです。

取消しやすい情報収集は広めに任せ、契約・決済のように影響が大きく後戻りしにくい行動には、上限・有効期限・実行時点の再確認や人の関与を厚くする——予測・判断・実行を一括りにせず、層ごとに設計を変えるということです。

自社で検討する際の叩き台として、委任設計で「まず決めること」を整理すると、次のようになります。

これはあくまで一例で、具体的な値や関与の度合いは各社の事情で決めるものです。金融領域では、自社のリスク許容度より先に、法令・契約・顧客保護上の制約が前提になります。

決めること	一例	主な強制点
行動権限	検索・比較のみ可、契約・決済ツールは利用不可	認可サービス／ツールの許可リスト／API
金額上限	1回・1日・1か月の上限	取引システム／決済システム
対象範囲	あらかじめ承認した商品群・口座に限定	認可層／取引システム
有効期限	期限切れで自動失効	委任管理基盤／認可サービス
取消し・緊急停止	利用者または管理者が即時停止	委任管理基盤／取引ゲートウェイ
実行時の状態確認	発注直前に有効期限・取消し状態を確認	取引実行システム
人の関与条件	一定額以上・例外・上限超過時に再承認	承認ワークフロー
再委任	原則禁止、または委任先を限定	認可ポリシー
監査証跡	委任ID・エージェント・操作・時刻・結果を記録	取引システム／監査ログ基盤

右列を「実装先」ではなく「強制点」としているのには理由があります。

AIエージェントに「この商品は扱わないでください」と指示することと、システム側でその操作を実際に拒否することは、別のことだからです。

重要な権限は、プロンプトやエージェント設定だけに頼らず、API・認可サービス・取引システムといった境界で強制する必要があります。

行動権限の線引きや人の関与条件は社内の業務ルールと承認フロー、金額・件数の上限は取引を実行する側のシステム、委任の有効性の管理は発行・検証の基盤——というように、強制する場所は分かれます。

ここを混同して「エージェントに設定すれば済む」と考えると、実効的に制限できないおそれがあります。

当社の公開ワークフローでも、AIの生成物をそのまま公開せず、生成・レビュー・承認・公開を別の工程として設計しています。

金融取引とはリスクの大きさも法的要件も異なりますが、行動を分解し、権限と停止点を先に定めるという設計原則は共通します。

分科会の議論はこれからです。

ただ、その結論を待つ間にも、自社がAIエージェントに何かを任せるとしたら、「誰から・何を・どこまで・いつまで委任され、それをどう検証するか」を紙の上で一度書き出してみること——それが、来たる時代に向けた実務の第一歩になるはずです。

情報確認について

本記事は2026年7月確認時点で、三菱UFJフィナンシャル・グループおよび三菱UFJ信託銀行の共同発表「『DID/VC共創コンソーシアム AIエージェント×金融取引分科会』の発足について」（2026年6月30日）を主要な参照元として作成しています。

分科会の検討事項・参加組織・活動期間、および関連する制度・技術（VC／DID等）の位置づけは今後変更される可能性があります。

最新の内容は各主体の公式発表でご確認ください。