Mercury Agent Cards：越えられない上限と責任の所在

「AIエージェントに会社の支払いを任せる」と聞いて最初に確認したくなるのは、支出上限・取引対象・記録・停止権限をどこに置くか、そして何かあったとき誰が責任を負うかです。

米国のフィンテック企業Mercuryは2026年8月11日、新機能「Agent Cards」を含む支出管理サービス「Mercury Spend」を発表しました。

技術的に購入を完了できることだけでは、業務として安全に任せられるとは限りません。

エージェントの判断精度に加えて、いくらまで使えるか、どのカード情報にアクセスできるか、誰が上限を変更できるかを、エージェント自身では越えられない形で設計する必要があります。

Mercuryの発表は、その具体的な一例を示しています。

なお本稿は、カード型の支出をAIエージェントに使わせる場面での権限設計という一断面を扱います。

エージェントが自ら口座間で資金を移動させる送金や、投資判断のような別種の金融行為は対象外です。

Agent Cards固有の統制と、Mercury Spend全体の機能を分ける

まず、Agent Cards 固有の仕組みと、支出管理サービスであるMercury Spend全体の機能を分けて読む必要があります。

同じ発表に含まれているため混ざりやすいのですが、どこで何が強制されるかが変わってきます。

Mercuryが Agent Cards 固有の統制として説明しているのは、次の内容です。

Agent Cardはバーチャルカードで、カードごとに日次・週次・月次のいずれかの支出上限を設定できます。

この上限を設定・変更できるのは人であり、エージェントがAPIやCLI経由で自分の上限を引き上げることはできません。

エージェントは自分でAgent Cardを新規発行することはできず、自分のカードの凍結を解除することもできません。

契約上はAPI・CLI・MCP経由で作成を要求する経路も想定されていますが、自然人の明示的な承認がなければAgent Cardは発行されません。

そしてエージェントが完全な決済認証情報（カード番号・有効期限・セキュリティコード）を取得できるのは、明示的に割り当てられたAgent Cardに限られます。

同社の説明では、これによりエージェントは決済画面で自分のカード情報を入力できる一方、社内の他のバーチャルカードや物理カードの完全な決済認証情報は取得できません。

一方、用途別（出張・ソフトウェア・調達等）の予算枠、加盟店名や加盟店カテゴリコードによる制限、予算超過時の決済拒否は、Mercury Spend全体の「予算」機能として説明されているものです。

また、必要な領収書・メモ・カテゴリが揃っていない場合にカードを自動で凍結する仕組みも、Mercury Spend全体のポリシー機能として説明されています。

ただし今回確認した発表資料では、この自動凍結がAgent Cardsにどう適用されるかまでは明示されていません。

同様に、加盟店名やカテゴリによる制限が、すべてのAgent Cardへどの単位で適用されるかも、公開情報だけでは明確ではありません。

同社CEOのImmad Akhund氏は発表の中で、創業者は支出を管理し、資金の流れを把握し、レシート整理などの煩雑な経理業務を自動化する、拡張性のあるプログラム可能な方法を必要としていると述べています。

これはベンダー自身の発言であるため、成果を裏づける独立した証拠というより、Mercury社の製品としての立ち位置の説明として受け止めるのが妥当です。

発行には人の明示承認が必要

Agent Cardの発行経路については、公式文書の間で説明の粒度が違います。

Mercuryのヘルプページは、人がWebまたはモバイルアプリからAgent Cardを作成し、エージェントは自ら作成できないと説明しています。

一方、2026年8月10日更新のIO Charge Card AgreementおよびColumn Commercial Debit Card Agreementでは、API・CLI・MCP経由でプログラム的に作成を要求する経路も想定されています。

ただしその場合も、管理者またはユーザーとしての自然人が承認するまでカードは発行されない、と両契約は定めています。

したがって、共通して確認できるのは次の点です。

エージェントだけで自律的にAgent Cardを新規発行することはできず、最終的な発行には人の明示的な承認が必要です。

判断精度だけでは足りない——決済基盤で上限を強制する

エージェントに支払いを任せることへの不安は、「エージェントが間違った判断をするのでは」という懸念に集約されがちです。

そこで対策として語られやすいのは、エージェントの判断精度を上げるか、逐一人間が承認するかの二択になります。

エージェントの判断精度は重要です。

ただし支出のように外部へ取り消しにくい操作を行う場合、判断精度だけを安全策にすることはできません。

Agent Cardsが示しているのは、AIの性能に加えて、決済基盤側で強制され、エージェント自身には変更できない上限を設けるという考え方です。

ここで、人がすべての購買判断を行うわけではないことにも注意が必要です。

ワークフローの組み方によっては、購入するか、いつ、どこで購入するか、設定された上限の中でいくら使うかについて、エージェントに裁量が残ります。

Mercury自身も、オンラインでの購入や広告支出、出張の予約といった用途を挙げています。

つまりMercuryが示しているのは、判断能力だけに安全性を委ねるのではなく、金額やカード情報へのアクセス、上限変更などについて、エージェント自身では越えられない外枠を置く設計です。

私たちは、AIの意思決定において、与える権限の設計は知能そのものと少なくとも同じだけ重要だと考えてきました。

Agent Cardsの構成は、この見方に沿う具体例だといえます。

何が縛られているか——7つの統制軸で見る

今回確認した公開情報からは、支出金額・加盟店の範囲・認証情報へのアクセス・管理操作・停止と剥奪・追跡と監査・失効という7つの統制軸が読み取れます。

私たちはこれを、AIエージェントに権限を渡す際の基本的な確認項目として位置づけています。

公開情報をこの軸に当てはめると、次のように整理できます。

• 支出金額：カードごとに日次・週次・月次のいずれかの支出上限を設定（Agent Cards 固有）
• 加盟店の範囲：加盟店名・加盟店カテゴリコードによる制限（Mercury Spend の予算機能側）
• 認証情報へのアクセス：完全な決済認証情報を取得できるのは割り当てられたAgent Cardのみ。他のバーチャルカード・物理カードの完全な認証情報は取得できない（Agent Cards 固有）
• 管理操作：エージェントは自らAgent Cardの新規発行・自分の上限変更・自分のカードの凍結解除ができない（Agent Cards 固有）
• 停止・剥奪：人がカードを凍結・キャンセルできる
• 追跡・監査：Mercuryは取引を追跡・監査できると説明
• 失効：通常のカード有効期限に加え、契約上はSingle-Use Cardとしての発行も想定されており、その場合は最初の所定のオーソリゼーションまたは有効期限の早い方で自動的に閉じられる

取引件数の上限は、今回参照した公開情報では明確でない別の軸です。

このうち「認証情報へのアクセス」は、権限設計の議論では見落とされやすい軸です。

エージェントに渡す認証情報の範囲を絞ることは、金額上限とは独立した統制になります。

このほかにも、今回確認した公開情報だけでは明確でない点があります。

業務目的に応じた短期の自動失効をどの程度設定できるか、例外取引に対する個別承認をどう組み込めるかといった点です。

これらが無いという意味ではなく、参照できる公開情報の範囲では明示されていない、というだけです。

加盟店カテゴリの制限は、購入品目の制限ではない

もう一点、実務で誤解しやすい部分があります。

加盟店名や加盟店カテゴリコードによる制限は、基本的に取引先・業種単位の制御です。

購入する個々の商品やサービスの内容まで判定する仕組みではありません。

例えば一つの加盟店が複数種類の商品を扱う場合、加盟店カテゴリが許可されていることと、購入品目が社内方針に適合していることは同じではありません。

したがって加盟店制限は対象範囲を狭める一つの統制であり、購買内容の妥当性確認を完全に代替するものではない、というのが私たちの見方です。

上限を設定しても、責任は移らない

ここで、支出上限と責任の所在は別の問題であることに注意が必要です。

Mercuryのヘルプページとカード契約では、Agent Cardを使った取引について、エージェントが企業の意図した権限内で行動したかどうかにかかわらず、原則として利用企業側が責任を負うとされています。

IO Charge Card Agreementは、Agentic Transactionを承認済みの取引とみなすと定めており、利用企業が設定したパラメータや支出制御、指示を超える取引についても利用企業が責任を負うと記載しています。

Column Commercial Debit Card Agreementでも、銀行およびサービサーの責任を制限したうえで、自律ソフトウェアエージェントの動作・不具合・侵害・無権限行為に起因する一定の請求について、利用企業に補償義務を課しています。

これは、Mercuryのカード統制と基盤側の決済インフラで強制される上限が無意味だという意味ではありません。

むしろ、カード基盤で強制される上限と、エージェントへの指示や社内ルールとして置いただけの上限を区別する必要がある、ということです。

決済基盤上の上限はカード支出のエクスポージャーを限定する助けになり得ますが、取引判断の責任をMercuryや発行銀行、カードネットワークへ移す仕組みではありません。

この点は、AIエージェントに何らかの外部支出を任せる場面で、製品選定より前に確認しておくべき論点だと私たちは考えています。

どこで縛るかを4層で分ける

見落とされやすいのが、それぞれの縛りが「どこ」で効いているかです。

少なくとも次の4つの層は分けて考える必要があります。

エージェント内部の指示：「1万円以下だけ買う」「この業者だけ使う」といった、プロンプトやワークフローに書いたルール。

柔軟に書ける一方、モデルの誤りや設定不備の影響を受けます。

Mercury上の設定：カードごとの支出上限、凍結、カード情報へのアクセス範囲など。

人が設定し、エージェントは変更できません。

カードプログラムと基盤側の決済インフラ：サポートされているオーソリゼーション統制が効き、取引が拒否され得る層。

この層にはMercury・発行銀行・決済ネットワークが関わります。

社内の運用・責任設計：誰が発行・変更・監査・停止を行い、例外や紛争にどう対応するか。

この区分が要点なのは、プロンプトに書いただけの上限と、決済時に拒否される上限は同じではないからです。

「Agent Cardsを導入すれば統制ができる」と考えると、本来は自社で決めるべき設定値と運用ルールまで、製品が肩代わりしてくれるかのように錯覚しかねません。

自社でエージェントに支出権限を持たせる前に決めること（叩き台）

Agent Cardsのような機能を実際に使う・使わないに関わらず、AIエージェントに支出権限を持たせる場面では、以下を先に決めておくと設計の抜けが減ります。

これはあくまで一例であり、具体的な数値や運用の厳しさは、自社の規模・リスク許容度・業種の規制に合わせて決めるべきものです。

決める対象	確認する問い	主な強制・管理層
利用目的	どの購買業務をエージェントへ委ね、何を対象外にするか	社内ルール、エージェントのワークフロー
金額上限	1回・日・週・月のどの単位で上限を置くか	Mercury等の設定、発行銀行・決済基盤
加盟店・対象範囲	加盟店名・カテゴリでどこまで絞るか。品目単位の確認を別に置くか	予算・ポリシー設定、社内購買ルール
カード情報へのアクセス	どのエージェントにどのカードだけを渡すか	カード発行・認証情報の管理設定
発行・変更・解除	誰がカード発行、上限変更、凍結解除を承認できるか	管理者権限、社内承認
失効・停止	一時利用、単発利用、異常時の停止をどう設計するか	カード設定、Single-Use Card、インシデント対応
記録・監査	誰が、どのカードで、いつ、どこへ、いくら支払ったかを追えるか	取引記録、会計・監査システム
責任・異議対応	想定外の購入や不正利用が起きた場合、誰が調査・異議申立てを行うか	社内規程、カード契約、経理・法務

上限額や加盟店カテゴリのように技術的に強制できる項目と、承認や責任分担のように社内ルールに委ねられる項目を、同じ表の中で混同しないことが要点です。

前者は製品やカード基盤が破らせない枠であり、後者は自社が破らない運用を続けられるかという話だからです。

なお、これらの項目は一度決めて終わりではなく、業務の変化に応じて定期的に見直す前提で置くのが現実的です。

まとめ——AIに支出を委ねる前に、越えられない上限を設計する

MercuryのAgent Cardsが示しているのは、AIエージェントに無制限の支出権限を渡す構成ではありません。

人が発行または発行を承認した専用カードを渡し、カードごとの支出上限、カード情報へのアクセス範囲、上限変更や凍結解除の権限を、エージェントの外側で制御する構成です。

一方、Mercury Spendの予算・加盟店制限、エージェント内部の購買ルール、社内の承認・監査手順は、それぞれ異なる層に置かれます。

どの統制がプロンプト上の指示で、どの統制がMercuryの設定で、どの統制が発行銀行・決済基盤によって強制されるのかを、分けて確認する必要があります。

また、決済上限を設定しても、Agent Cardの利用責任そのものが外部へ移るわけではありません。

AIに支出を委ねる際に問うべきなのは、「エージェントが十分に賢いか」だけではありません。

どの権限が、どの層で制限され、それをエージェント自身が上書きできないようになっているか。

そして想定外の取引が起きた場合に誰が調査し対応するか。

この2点だと私たちは考えています。

情報確認について

本記事は2026年8月17日確認時点で、MercuryがBusiness Wireを通じて2026年8月11日に配信した製品発表「Mercury Launches Spend with Agent Cards and Intelligent Budgets for the AI Era」、Mercury公式ヘルプ「Agent cards: Giving AI agents a card of their own」、および2026年8月10日更新のIO Charge Card Agreement・Column Commercial Debit Card Agreementを主要な参照元として作成しています。

Business Wireの記事はMercuryによる会社発表の配信であり、第三者による独立した製品評価ではありません。

Agent Cardの作成方法について、Mercuryのヘルプページは人がWebまたはモバイルアプリで作成すると説明する一方、カード契約はAPI・CLI・MCP経由の作成要求も想定し、自然人の明示承認なしには発行されないと定めています。

本稿は共通して確認できる「エージェント単独では発行できず、人の承認が必要」という点に基づいて記述しています。

本記事は、Agent Cardsの統制を論じる目的の範囲で契約の一部条項を要約したものであり、契約全体の解釈や、個別の事案における当事者の権利義務を示すものではありません。

Mercuryはフィンテック企業であり、銀行サービスは提携銀行を通じて提供されます。

適用される発行銀行やカード契約は、デビットカードかIO Charge Cardかなどによって異なる場合があります。

本稿はMercury SpendやAgent Cardsの安全性、統制の有効性、監査機能をMIFが独自に検証したものではありません。

製品機能・利用条件・責任分担は今後変更される可能性があります。