【実務家ノート 第9号】 邦銀のためのx402/MPP実装入門

「検証しておいて」と言われた日から4週間で経営判断まで持っていく、社内PoC設計書

無料連載で見てきたように、AIエージェントがAPI、データ、計算資源、コンテンツを自律的に購入する世界では、決済は人間向けのチェックアウト画面から、機械が解釈できるHTTPのやり取りへ移ります。x402とMPPは、その「支払い要求・権限付与・支払結果」をHTTP上で受け渡す代表的なプロトコルです。
2026年7月、状況は旧稿執筆時より一段進みました。x402はV2へ移行し、Linux Foundation傘下のx402 Foundationが正式稼働しました。公式サイトは直近30日で約7,500万件の取引を掲げています。ただし、これはプロトコル利用の勢いを示す指標であり、商用収益や銀行利用の成熟度を直接証明するものではありません。[1][2][3]
MPPも、単なる「セッション型決済」ではありません。現在は、固定額のcharge、従量課金のsession、継続課金のsubscriptionという複数の課金意図を持ち、ステーブルコインだけでなくカードやBitcoinを含む複数の支払方法を扱います。さらにMPPのSDKはx402 exactフローを同じインターフェースから処理できるようになっています。[4][5][6][7]

なぜ邦銀が今、検証すべきなのか

·    プロトコルの勝者を予想するためではなく、機械が顧客になる時代の銀行API・法人サービスの要件を知るため。
·    ステーブルコインの少額決済をそのまま自行サービスに採用するためではなく、支払権限・限度額・鍵・証跡をどう機械化するかを把握するため。
·    企業内、グループ企業間、許可制サプライチェーンなど、参加者既知・KYC済みの領域にTDを適用できるかを具体化するため。
·    テストネットと模擬台帳を使えば、実資金・顧客データを使わず、小規模チームで技術・統制の論点を一巡できるため。
逆に、やってはいけないPoCは明確です。公開サンプルを動かし、画面に「200 OK」が出たことだけを成果にするPoCです。金融機関にとって重要なのは、支払いが成功したときよりも、署名が不正だったとき、支払上限を超えたとき、ファシリテーターが停止したとき、決済は成立したのにサービス提供が失敗したときに、誰が止め、誰が記録し、誰が補償するかです。

1．まず修正すべき理解——x402とMPPは「都度型対セッション型」ではない