SwiggyがMCPにウォレット決済Swiggy Moneyを追加、AIエージェントの支払いはどこまで自動化されたか
SwiggyがMCPサーバーに自社ウォレットSwiggy Moneyを載せ、AIエージェントが残高で決済できるようにしました。代金引換から8か月の変化、実地テストで残った摩擦、インドのNPCIが準備する規制の枠組みまで解説します。
この記事のポイント
- インドのSwiggyが、自社ウォレット「Swiggy Money」をMCPサーバーに追加し、AIエージェントがFood・Instamart・Dineoutの注文代金を残高から支払えるようにしました。一度チャージすれば、以降の取引では会話を止めずに決済まで進めます。
- MediaNamaがChatGPT経由で実際に注文したところ、支払いは通ったものの、配送先住所の選択は人間に戻され、注文履歴は使えず、決済完了後にいったんエラーが表示されました。決済手段の追加だけでは自律性は完成しません。
- インドではNPCIがAIエージェント向けのUnified Agent Protocolを準備中で、上限額と責任の枠組みが議論されています。EC事業者にとっては「エージェントに残高を持たせる前に、上限・確認・状態同期を誰が持つか」を決める段階に入りました。
会話を止めないための残高、というアイデア
SwiggyがMCP連携にSwiggy Moneyを追加し、AIエージェントがFood・Instamart・Dineoutの注文を決済できるようになりました。
www.medianama.comエージェントによる買い物が途中で止まる場所は、だいたい決まっています。支払いです。探して、比較して、カートに入れるところまでは会話の中で進むのに、決済の瞬間だけアプリや銀行の画面に飛ばされる。そこで人間の手が戻ってくると、その取引はもう自律的とは呼べません。
インドのフードデリバリー・クイックコマース大手Swiggyが2026年9月4日、この断絶を埋める更新を告知しました。同社のエージェンティックコマース責任者がXで公表したもので、自社ウォレット「Swiggy Money」をMCP（Model Context Protocol）連携に追加し、AIエージェントがFood、Instamart、Dineoutの注文代金を残高から支払えるようにしたという内容です。
これまでエージェントは、発見し、判断し、注文を組み立てるところまでは手伝えました。これからは実際に完了までやれます。
MCPは、AIモデルが外部のシステムやツールに接続するための共通仕様です。Swiggyはこれを2026年1月から自社の3事業に実装し、4月にはBuilders Clubとして外部開発者にも開放しています。今回はその積み上げの上に決済レイヤーが乗ったかたちです。
なお、Swiggy Money自体は新しい仕組みではありません。同社が2020年に開始した自社ウォレットで、ICICI Bankのウォレットサービスを基盤に、チャージした残高から追加認証なしで支払える設計だと報じられています。Swiggyは新しい決済手段を作ったのではなく、もともと手元にあった前払い型の残高を、エージェントから触れる場所に置き直したわけです。
代金引換から始まった8か月
Swiggyはいきなりここに到達したわけではありません。段階を並べると、この会社が何を恐れながら決済を開けてきたかが見えます。
| 時期 | MCPで可能になったこと | 決済手段 | 確認された制約 |
|---|---|---|---|
| 2026年1月 | Food・Instamart・Dineoutの3サーバーを公開し、ChatGPTから手動接続できる状態に | 代金引換のみ | メニュー取得に頻繁に失敗、Instamartは決済まで到達せず |
| 2026年4月 | Builders Clubとして外部の開発者・企業に開放（3サーバー・49ツール） | 代金引換のみ | Builders Club経由のFood注文にカート上限1,000ルピー |
| 2026年7月 | 3サーバー共通の決済ステージを追加（get_payment_options / check_payment_status / confirm_order） | UPI（GPay、PhonePe、Paytm、スキャンQR） | 支払い成立まで注文はPENDING_PAYMENTで保留、UPI IDの直接入力は不可 |
| 2026年9月 | Swiggy Moneyの残高をエージェントが継続的に使えるように | ウォレット残高 | 公開ドキュメントとチェンジログには未反映 |
1月時点の状態は、MediaNamaが当時テストして記録しています。ChatGPTを開発者モードに切り替え、3つのMCPエンドポイントを手動で追加し、OTPログインを通す必要がありました。接続後も、Third Wave CoffeeやStarbucksといった大手チェーンでメニュー取得に失敗して注文が進まないケースが頻発しました。決済を代金引換に限定していたのは、慎重さの表明として読むのが自然です。エージェントが誤発注しても、代金が捕捉されていなければ取り消しは軽く済みます。
転機は7月でした。Swiggyは3サーバー共通の決済ステージを公開し、UPI（インドの即時送金基盤）による会話内決済に対応しています。ここで採用された設計が、後の議論にそのまま効いてきます。注文はまずPENDING_PAYMENTという状態で作られ、支払いが成立して初めてPLACEDに遷移する。ポーリングの上限に達しても保留のままの注文は失敗として確定させ、宙に浮かせない。確定処理は冪等で、リトライしても未払い注文が成立することはない。「未払いの注文が成立済みに見えることは絶対にない」という一点に、設計の重心が置かれています。
9月のSwiggy Moneyは、この上に「毎回の支払い操作そのものをなくす」層を足しました。UPIではエージェントが決済を起動してもユーザーがアプリを開いて承認する必要がありますが、前払い残高ならその承認は最初のチャージ時に一度だけで済みます。
実際に注文して残った摩擦
MediaNamaは今回もChatGPTで実地テストを行っています。指示は「300ルピー以内でチョコレート系のデザートを、注文履歴を参考にして選び、Swiggy Moneyで支払う」というものでした。結果は部分的な成功です。注文履歴の参照には失敗し、クッキーが欲しいと人間が指定し直したところで検索が通り、商品が選ばれ、Swiggy Moneyで決済されて注文が成立しました。代金引換しか選べなかった1月と比べれば、体験は明確に滑らかになっています。
一方で、3つの摩擦が残りました。配送先住所を人間に選ばせたこと、保存済みの注文履歴を推薦に使えなかったこと、決済完了後にChatGPTがいったん「支払われていない」というエラーを返したことです。3つ目はとくに厄介で、注文は成立して確定していたのに、会話の側の状態表示が実際とずれていました。
ここで注目したいのは、注文履歴の失敗がAPIの不在ではないという点です。Swiggyの公開ドキュメントには、Foodのget_food_orders、Instamartのget_ordersという注文履歴取得ツールが定義されており、過去の注文から好みや定番商品を読み取る用途まで説明文に明記されています。機能は露出しているのに、ChatGPT側の会話の中でそれが呼ばれなかった、あるいは呼んでも結果を使えなかったということになります。
この差は、エージェンティックコマースの評価軸を考えるうえで重要です。プロトコル側の機能一覧と、実際のクライアントが会話の中で発揮する能力は別物です。事業者がMCPサーバーを整備しても、接続するアシスタントが文脈を持ち回れなければ、ユーザーから見た体験は半分手作業のままになります。MediaNama自身も、真に自律的なエージェントには残高の追加以上のものが要ると結論づけ、残る課題は発見からフルフィルメントまで文脈を運び続けることだと指摘しています。
残高を持たせた瞬間に必要になる上限と責任
エージェントに支払わせるという話は、便利さの話であると同時に、限度額と責任の話です。MediaNamaもこの点に踏み込み、摩擦は本質的に悪ではなく安全装置として機能しうる、不要な摩擦だけを取り除きユーザーを守る境界は残すべきだ、と書いています。
現時点でSwiggyが持つ境界は2種類です。1つは金額の上限で、公開ドキュメントにはBuilders Club経由のFood注文にカート合計1,000ルピーの上限があると明記されています。もう1つは確認の義務づけで、place_food_orderのツール説明文には、カートと住所を提示して明示的な同意を得るまで呼んではならない、支払いが保留中の間は「注文できました」と言ってはならない、といった指示が長々と書き込まれています。
ただし後者は、プロトコルが強制する制約ではなく、モデルへの指示文として置かれた制約です。ツールの説明文をどこまで守るかはクライアント側のモデル次第であり、無視されても呼び出し自体は通ります。決済完了後にエラー表示が出たという今回の事象は、まさにこの層の脆さを示しています。
規制の側も動いています。ロイターは9月1日、NPCI（インド決済公社）がAIエージェントによるUPI決済を可能にするUnified Agent Protocolを準備しており、ムンバイのGlobal Fintech Festで公表される見通しだと報じました。既存のUPI Circle（支払い権限を第三者に委任する）とReserve Pay（複数回の引き落とし用に資金を確保する）を土台に、上限額、監査証跡、本人確認、責任の枠組みを組み合わせる構想とされています。銀行は現在この資金確保を10,000ルピー・最長90日までに制限しており、エージェント用途では見直される可能性があるとも伝えています。
ただし、これは関係者の話に基づく報道であり、仕様が確定したわけではありません。しかも同じインドで、RBIの電子マンデート枠組みが取引ごとの追加認証を求め、CERT-Inが一定金額以上のエージェント行為に人間の介在を義務づけるよう提言している状況です。追加認証は取引ごとの制御、権限委任は取引ごとの摩擦を減らす仕組み、人間の介在はしきい値の制御なのにそのしきい値が未定。方向が噛み合わないまま並走しています。
前払いウォレットが選ばれた理由も、この文脈で読めます。MediaNama創業者のNikhil Pahwa氏は7月の論考で、ウォレットは影響範囲を限定できるからエージェントに金を持たせる自然な方法だと論じ、エージェント専用のハンドルとPIN、金額と頻度の既定上限、救済手段を先に用意すべきだと主張していました。銀行口座に直結したUPIより、チャージした分しか失われない前払い残高のほうが、封じ込めの観点では素直です。同氏は自らエージェントで買い物を試した経験から、「時間を確保して見張らなければならない購入は、自律的な購入ではない」とも述べています。
日本のEC事業者が先に決めるべきこと
Swiggyの実装は、インドの決済事情に強く依存しています。UPIは8月だけで245.1億件、29.82兆ルピー規模を処理する巨大な即時送金網であり、日本にそのまま対応する基盤はありません。それでも設計の論点は移植できます。
まず、エージェント経由の取引に、どの決済手段から開放するかです。Swiggyは代金引換から始め、UPIを足し、最後に前払い残高を置きました。リスクの小さいものから開けるという原則の実装です。自社ストアで考えるなら、ポイント残高やギフト残高、プリペイド型の預り金といった、失っても影響が限定される手段が素直な入口になります。
次に、状態の真偽をどちらが持つかです。今回の誤表示が示した通り、会話UIの表示は当てになりません。支払い成立までは注文を保留に置き、確定処理を冪等にし、タイムアウト時は失敗として閉じる。この一式を自社サーバー側で完結させておく必要があります。
最後に、確認と上限をどの層で担保するかです。ツール説明文の注意書きはモデルへのお願いであって強制ではないので、金額しきい値や1日あたりの件数はサーバー側で拒否できる形にしないと守られません。データの扱いも同じで、Swiggyは取り扱い方針として、接続する開発者はその場の用途にしかデータを使えず、分析や広告、モデル学習には別途の同意が要ると定めています。機能一覧より先に読むべきはこの種の文書です。
発表で開示されていない条件
判断材料として、現時点で未開示の項目を整理します。
- 手数料: Swiggy Money経由のエージェント決済に伴う手数料や事業者側の負担は示されていません
- 対応エージェントの範囲: 動作が保証されるAIアシスタントの一覧はなく、確認されているのはChatGPTでの1例です
- エージェント単位の利用上限: 残高の使用に1回あたり・1日あたりの上限があるかは明らかにされていません。カート上限1,000ルピーもBuilders Club経由の注文について書かれた値で、他経路への適用は不明です
- 公式ドキュメントへの反映: Builders Clubのチェンジログと開発者向けドキュメント一式には、本稿執筆時点でSwiggy Moneyの記述が見当たりません。Xの投稿が実質的な一次情報です
まとめ
決済手段が足りないから自律性が出ない、という説明は今回で使えなくなりました。前払い残高を置けば、エージェントは会話を離れずに支払いを終えられます。実地テストでも、支払いそのものは通りました。
残ったのは、住所の選択、履歴の活用、決済後の状態同期という、いずれも文脈を持ち回る能力の問題でした。これはSwiggyだけの課題ではなく、MCPサーバーを整備した事業者と、そこに接続するアシスタントの間に共通して残る隙間です。
NPCIの枠組みが公表されれば、インドはエージェント決済の国家インフラを持つ最初期の国の一つになります。上限、監査、本人確認、責任の分担がどう書かれるかは、日本を含む他国の議論の参照点になるはずです。Swiggyの実装は、その議論が固まる前に現場で先に走り出した事例として観察する価値があります。
