現場ノート

人が定めたポリシーの下で動くエージェント決済

エージェント決済とは、チェックアウトで人が行うのではなく、ソフトウェアが開始する支払いのことです。AIエージェントが認証情報を保持し、購入すべきだと自ら判断し、自分で資金を動かします。請求書の支払い、サブスクリプションの更新、チャーター便の手配を、人が最後のボタンを押すことなく実行します。決定的な違いは、支払いを開始する主体です。人が購入ボタンを押すのであれば、チャットボットを前段に置いた通常のカード決済にすぎません。エージェント決済では、判断も承認も、お金が実際に動く瞬間の決済も、ソフトウェアが行います。このカテゴリーの難しさはすべて、この1つの性質から生じます。支出する主体が人ではなく、見知らぬ相手に送金する前に人が感じるような疲れや疑念、不安を抱かないということです。

だからこそ、本当に重要な問いは、エージェントがお金を使うかどうかではありません。エージェントはすでに使えます。問うべきは、誰がエージェントの支出ルールを定めるのか、そしてそのルールをプラットフォームが強制するのか、エージェントが守ると約束するだけなのかです。

失敗の形は明白であり、そこが要点です

有効な決済用認証情報を、上限なしでエージェントに渡せば、まだ起きていない送金詐欺インシデントを自ら作っているようなものです。そうなる経緯は、特別なものではありません。Webページに仕込まれたプロンプトインジェクションが、攻撃者への支払いを指示します。不備のあるツール記述により、正当な購入が誤った受取先に向けられます。成功の応答が返ってこないために、再試行ループが同じ請求を千回試みます。いずれも、巧妙な攻撃者を必要としません。自律型ソフトウェアにありがちなバグですが、その結果として、口座からお金が流出します。

安易な対策は、エージェントをもっと慎重にすることです。より良いシステムプロンプト、より厳しい指示、支出についてより深く推論するモデルなどです。しかしそれでは、統制をシステムで最も信頼できない場所、つまり丸め込まれ得るエージェント自身の推論に置くことになります。エージェントが言いくるめて越えられる予算は、予算とは言えません。統制は、エージェントの手が届かない場所、つまりエージェントの外側に置く必要があります。

製品の核心はプロンプトではなくポリシー

封じ込めモデルの核心は、エージェントが判断した後ではなく、お金が動く前にプラットフォームが強制するポリシーです。各エージェントには、1回あたりの上限と1日あたりの上限が設定されます。デモのポリシーでは、1回150.00ユーロ、1日500.00ユーロで、その上に月額6,000.00ユーロの上限があります。これらは、エージェントが守る約束ではなく、プラットフォームがチェックする厳格な壁です。デモの旅行ボットが640.00ユーロのチャーターを試みたとき、支払いはその場で拒否されました。上限超過で、1セントも動いていません。毎日完璧に動くエージェントであっても、月の上限を超えて逸脱することはありません。

予算は「いくらまで」を定め、許可リストは「どこへ」を定めます。エージェントが支払えるのは、あらかじめ指定した加盟店だけです。デモのOps Agentが知っている加盟店はちょうど4社で、リスト外のベンダーへの180.00ユーロの支払い試行は、未登録として拒否されました。この2つで枠が決まります。この金額まで、この受取先にだけ。枠の中では、エージェントは確認を取ることなく全速力で動きます。そして、その枠を所有するのは人です。

問題は、AIエージェントがお金を使うかどうかではありません。誰がその支出ルールを書いたかです。その答えは常に、人が、事前に、文書として、であるべきです。
— Protocore · Agents エンジニアリング

ラインの上には人がいる

枠に任せるには大きすぎる判断もあります。そのためポリシーには閾値があります。この金額を超える支払いは、実行前に人の承認が必要になる、という基準額です。デモでは、そのラインは100.00ユーロです。Ops AgentがNord Logisticsの請求書#088(120.00ユーロ)を検知したとき、日次予算の500.00ユーロには十分収まっていても、承認ラインを超えていたため、支払いは実行されませんでした。エージェントは一時停止して、提案を担当者の前に提示し、待機しました。1行の返信で承認され、支払いは参照番号9F21-0716として決済され、09:41に監査ログへ記録されました。ラインより下ではエージェントが自分で動き、上では人が先に答えます。

承認は、あとで消えてしまうチェックボックスではありません。誰が、どのデバイスで、いつ、署名付きで承認したかが記録されます。アプリで承認、スマートフォンのキー、09:41:12といった具合です。あとから支払いの理由を問われたとき、答えは、曖昧な返事ではなく、担当者の名前とタイムスタンプです。

キルスイッチと、こっそり書き換えられないログ

十分な壁があっても、エージェントは誤作動し、ポリシーが間違っていることもあります。これには2つの統制で対応します。1つ目はキルスイッチです。ワンタップでエージェントを停止し、開始しうるすべての支払いを即座に止めます。キーは有効なままなので、ほかの機能は壊れません。人が再開するまでエージェントが支出できなくなるだけで、保留中の提案も消えずにそのまま凍結されます。デモのフリートでは、旅行ボットが一時停止中で、支出は0.00ユーロ、キューもそのまま残っています。

2つ目は追記専用の監査ログです。すべての判断が記録に残ります。エージェントが何を試みたか、どのポリシーチェックに合格または不合格だったか、誰が何を承認したか、鍵のローテーションに至るまで。1件の記録から、1つの支払い全体を再構成できます。判断 DEC-4471 には、リクエスト、各ポリシーチェックとその結果(allowlist は合格、上限は合格、しきい値はエスカレーション)、人による署名、そしてレールと参照番号を伴う決済金額が記されています。各エントリーは自身のハッシュ、直前のエントリーのハッシュ、チェーン内での位置(デモでは #4,471)を持つため、どれか1つのフィールドを書き換えると、それ以降のすべての記録が壊れます。ログはハッシュ込みの JSON でエクスポートできます。監査人に渡すのはお客様であり、私たちが抱え込むものではありません。

決済は退屈なままに、新しさは認可に

エージェント決済を、レールも決済手段も送金方法も、すべて新しくしたくなる誘惑があります。それは避けるべきです。本当に新しいのは認可の部分、つまりエージェントが支払う権限を持つことを、誰のポリシーのもと、どの承認で証明するかです。この関門を通過した支払いは、何年も前から堅実に動いているレールで決済されるべきです。デモでは、承認された €120.00 の提案は通常の SEPA クレジット送金となり、承認の数分後に SEPA Instant で決済されます。後続の処理では、人が行った支払いと見分けがつきません。エージェントが起点であることを、銀行は知りませんし、気にもしません。

この分離は意図的なものです。堅実なレールは予測しやすく、スキームが許す範囲で取り消しが可能で、これから関わるあらゆる財務部門や監査人が熟知しています。新しさをポリシーに置き、支払いは確立されたレールに載せる。そうすれば、リスクが高く変化の速い部分は完全に自社の管理下に置かれ、他社の銀行に触れる部分は誰も学び直す必要がありません。エージェントは、ロボット向けに作られた別世界ではなく、/products/pay で説明している、ほかの決済ファミリーと同じコアから支出します。

プロトコルの勢力図はまだ定まっていない。それを前提に作る

エージェントが加盟店に対して自らのアイデンティティと権限をどう提示すべきかは、まだ決着していません。エージェントが誰であるか、何を購入する権限があるか、加盟店が入金を受け入れる前にそれをどう確認するか。これらをめぐって複数の提案が競っています。まだ勝者はおらず、現時点で特定の1つに全面的に賭けるのは時期尚早です。堅実な方針は、認可プロトコルを差し替え可能なものとして扱い、その背後をすべて安定させておくことです。前面の通信フォーマットが変わっても、ポリシーエンジン、監査モデル、決済レールは変わりません。

実際には、小さく堅実な連携面にとどめるということです。エージェントは mcp.protocore.io/agents に MCP で接続します。このプロトコルに対応していれば、どのフレームワークでもウォレットを持てます。インターフェースはあえて絞り込んであり、支払いを提案し、判断を受け取るだけです。重要なロジックはプロンプトではなくプラットフォーム側にあるからです。エージェントが加盟店に自らを証明する方法が業界で定まったとき、変わるのは前面だけで、背後の壁はそのままの位置にあります。

全体の中での位置づけ

エージェント決済は、自律的なソフトウェアに無制限の支出を許すことへの賭けではありません。むしろ逆で、ソフトウェアは支出するようになるのだから、制限は実効性があり、外部にあり、読み取れるものであるべきだという賭けです。予算と allowlist が枠を描き、しきい値が大きな判断を人に回し、キルスイッチがすべてを止め、追記専用のログによって、あらゆる支払いを後から再構成できます。/products/agents の製品ページでは、ここで使っているデモデータで一連の流れを通して確認できます。エージェントを作成し、ポリシーを設定し、支払いがエスカレーションされて決済されるまでを見られます。/products/pay は、それらの支払いが動くコアです。自律性は本物です。リードも本物で、それを握っているのは人です。

システム開発をご検討中ですか?

課題をお聞かせください。アーキテクチャと計画をご提案します。