請求書カード払いにおけるAIエージェント連携 ― Amazon Bedrock AgentCore Runtime を用いたリモート MCP サーバー構築

本ブログ記事は、株式会社インフキュリオン 菊田 慎一郎 様、向後 宗一郎 様、石原 幸治 様、佐々木 明良 様 および アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 松原 武司 の共著です。

請求書のカード払いを実現するプラットフォーム「Winvoice」を提供する株式会社インフキュリオンは、2026 年 6 月、Winvoice 機能を AI エージェントから呼び出せるリモート MCP（Model Context Protocol) サーバーを公開しました。日本の請求書カード払い領域における MCP 対応サービスとしては初の事例です（インフキュリオン調べ）。

生成AI をめぐる技術は数か月で新しい要素が生まれ、トレンドも入れ替わり続けています。株式会社インフキュリオン様は「早く出して先行者になること」自体が競争力に直結すると考え、MCP 対応クライアントが普及し始めたこのタイミングにて、企画から公開までを約 1 か月で走り切ることを目標とし、それを実現されました。

本ブログ記事では、その短期間でのローンチを成立させたアーキテクチャ上の判断を軸に、課題、リモート MCP サーバー方式と Amazon Bedrock AgentCore (AgentCore Runtime) の選定理由、Fintech ならではのセキュリティ・統制設計、そして得られた価値を共有します。

実際に設計と実装を担当された株式会社インフキュリオンのエンジニアの方々に、以下をご説明いただきます。

1. 株式会社インフキュリオン と 請求書カード払いプラットフォーム 「Winvoice」
2. 課題：分断された経理業務と、AI 活用の壁
3. アーキテクチャの全体像
4. 主なアーキテクチャ上の判断と今後の展望

株式会社インフキュリオン と 請求書カード払いプラットフォーム 「Winvoice」

株式会社インフキュリオンは 2006 年創業の Fintech 企業で、決済領域を中心に金融サービスプラットフォームを提供しています。「決済から、きのうの不可能を可能にする」をミッションに、ライセンス対応からカスタマーサクセスまでワンストップで支援する事業を展開しています。

Winvoice は、その中で「請求書カード払い」に特化したプラットフォームです。請求書を受領する側がカード払いに切り替えられる機能と、請求書を発行する側がカード決済オプションを追加できる機能を提供し、AI-OCR、承認ワークフロー、KYB (Know Your Business：企業確認) / KYC (Know Your Customer：顧客確認) 審査、3Dセキュア対応を備えています。SaaS 企業、金融機関、商社・卸といったプラットフォーマーが、自社サービスに請求・支払機能を組み込んで利用しています。

課題：分断された経理業務と、AI 活用の壁

Winvoice を利用する企業の経理現場では、請求書の受領から支払完了までの作業が複数のシステムにまたがって分断されていました。会計ソフト、経費精算、Winvoice、メール、各種ファイルといったソースを行き来する手作業が、月末月初の負担として残っていました。

一方で、AI を業務に取り入れたいというニーズは強く存在しました。しかし、ローカル環境のセットアップや API 連携の難易度が、非エンジニアの現場では着手の障壁になっていました。Claude Desktop をはじめとする MCP 対応クライアントが普及し始めたこのタイミングで、Winvoice 側からも MCP に応える側を準備することが、現場の経理担当者に AI 活用を届ける現実的な手段だと判断しました。

加えて、この判断には時間軸の制約もありました。MCP という規格そのものがまだ立ち上がり期にあり、対応クライアントの普及とともに主導権の所在が短期間で動く局面です。ここで早く実装を届けられるかどうかが、請求書カード払い領域での立ち位置を左右すると考え、私たちは短期リリースを前提にプロジェクトを設計しました。

請求書カード払いサービスで初の挑戦としての位置づけ

請求書カード払いは、決済という慎重さを必要とする領域です。インフキュリオン は、本プロジェクトを「業務効率化」だけでなく「Fintech サービスにおける AI エージェント連携のリファレンス事例」として位置づけました。

同時に、早く届けることに価値があるプロジェクトでもありました。生成 AI をめぐる技術と対応クライアントは数か月で様変わりし、この領域では先に出したサービスが事実上の参照点になります。そこで私たちは、企画から公開までを約 1 か月で完了させることを最初のマイルストーンとしました。

この短納期を現実的にしたのが、テックリードの菊田が描いた「既存資産の流用と AWS マネージドサービスの活用による MCP サーバー構築」という技術方針です。認証基盤には Winvoiceチームが本番運用してきた Amazon Cognito をそのまま使い、実行基盤にはチームが日常的に扱ってきた AWS、とりわけ Amazon Bedrock を中心とするマネージドサービスを選択する。ゼロから作り込むのではなく運用実績と習熟のある構成要素を組み合わせることで、限られた時間を Fintech として外せない統制の設計に集中させる— この方針を軸に、新卒入社の若手エンジニアが設計・実装の中核を担い、開発リードは入社 3 年目の佐々木が務めました。その具体的な構成は、次のアーキテクチャ全体像と設計判断で順に説明します。

また、本プロジェクトでは次の三項を同時に満たすことをゴールに置いています。

• 先行者として早期に届けること：技術が数か月で入れ替わる中、企画から公開までを約 1 か月で実現する
• 非エンジニアの経理担当者・経営者にも届く体験：URL を 1 行設定するだけで AI エージェント側から Winvoice を呼び出すことができる状態
• 規制業種として求められる統制：認証・認可、テナント分離、監査ログ、最終承認における人の関与

アーキテクチャの全体像

システムは 3 層構成です。MCP クライアント層、Amazon Bedrock AgentCore Runtime 上で動作するリモート MCP サーバー層、そして既存の Winvoice バックエンド層です。MCP サーバーは Winvoice 既存の認証基盤と接続し、ユーザーが本来権限を持つ範囲のみを公開します。

設計判断 #1：リモート MCP サーバー方式の採用

MCP に対応する方式には、利用者がソースコードを取得して自分の端末で動かすローカル方式と、サーバー側でホストし利用者は URL を設定するだけで使えるリモート方式があります。

検証 や MVP (Minimum Viable Product) の段階では、ソースコードを GitHub などで配布するローカル方式が手軽で、実際に多くの事例がこの形を採用しています。Winvoice においても、社内での概念実証の段階ではこの方式で進めていました。

しかし Winvoice は、決済という利用者からの信頼が何よりの土台となる領域のサービスです。開発者以外の外部利用者へ正式に提供する際には、ローカル方式のままでは、この信頼を支えきれないと判断しました。ソースコードを公開すること自体が攻撃の起点になりうること、開発者でなければ安全に導入・運用できないこと、機能を更新するたびに各利用者の端末へ配布し直さなければならないことは、いずれも決済サービスに求められる安全性と一貫した運用を損ないます。

そこで インフキュリオンでは、サーバー側で認証・認可・監査を一元的に管理でき、利用者にはソースの管理も環境構築も求めず、接続も HTTPS だけで完結する、より信頼性と安全性の高いリモート方式を採用しました。この方式では、機能改善もサーバー側の反映だけで全利用者へ届けられるため、立ち上がり期の規格を扱う上で欠かせない「出した後に速く直せること」も同時に満たせます。

リモート MCP サーバー方式は、生成 AI を業務に組み込もうとする多くの企業で共通の論点になります。利用者側の環境構築を不要にできるため、配布コスト・サポートコストを抑えながら、対象ユーザー層を一気に広げられる点が事業判断としても有効です。Fintech のように非エンジニアのユーザーが多い業界では、特に効果が大きいアプローチです。

設計判断 #2：リモートMCP採用にあたってのAWSアーキテクチャの検討

リモート MCP サーバーの実行基盤は、複数の構成案を検討し、タイムアウト仕様の調査と PoC での検証を経て絞り込みました。壁になったのは、Winvoiceの提供機能に含まれる最大10分程度を見込む処理においても、その進行状況をMCP の Streamable HTTP プロトコルにおいてサーバーサイドからクライアントに状況をSSE (Server-Sent Events) で通知可能とすることでした。

AWS App Runner や、Amazon CloudFront + AWS Lambda 構成も候補に挙がりましたが、この観点から除外しました。

最終的に Amazon Elastic Container Service (ECS) と Amazon Bedrock AgentCore Runtime が候補として残りましたが、AgentCore Runtime の採用を決定しました。採用の決め手となったのは以下の 3点 です。

• MCP プロトコルのサポート：SSE ストリーミングに最大 60 分対応し、ハートビートのような回避策なしに長時間接続要件を満たすことができます。
• ステートフルなセッションを標準機能で実現：セッションごとに専用の マイクロ仮想マシン (microVM) が割り当てられ、セッション継続性とテナント間の分離を仕組みで担保できます。
• 運用負荷とコストの最小化：クラスタ管理・パッチ適用が不要で、セッション期間中の CPU・メモリの秒単位従量課金、I/O 待機中は CPU 無課金のため、常時稼働構成を避けることができます。

また、AgentCore Runtime の microVM から Amazon S3 や Amazon Cognito などの AWS サービスへアクセスする経路には、VPC ネットワークモード と VPC エンドポイント（AWS PrivateLink）を採用しました。これにより、AWS内にトラフィックが留まるセキュアな通信経路を確立しています。

さらに、既存の Winvoice 本番環境とは VPC 自体を完全に分離する設計としました。万が一、リモート MCP サーバーが設計上意図しない動作を行うような事態が発生した場合でも、その影響を最小限に止め、Winvoice 側が持つ機密情報への不正アクセスを未然に確実に防ぐ「多層防御」のアーキテクチャを実現しています。

設計判断 #3：認証・認可 ― 既存の認証基盤を無改修で接続する

AI エージェントという新しい入口を設ける上で、認証と認可において、次の 3つの問い に答える必要がありました。

• 認証：OAuth 2.1 + PKCE と Protected Resource Metadata（RFC 9728）によるディスカバリを求める MCP クライアントを、既存の認証基盤とどう繋ぐか
• アウトバウンド：MCP サーバーは、どのような権限で Winvoice API を呼び出すか
• 認可：MCP 連携を、誰にどう開放するか

いずれのポイントでも、稼働中の決済サービスである点を鑑み、「既存アプリケーションには極力手を加えない」ことを共通の前提 (制約) としました。採用した構成の全体像は次のとおりです。

認証：Hub & Spoke 型の Cognito フェデレーション

MCP クライアントはブラウザーリダイレクト型の OAuth フローを前提としますが、Winvoice の既存認証はこれに対応していません。加えて、Winvoice はプラットフォーマーごとにテナントを分離したマルチテナント構成で、Cognito ユーザープール もテナント別に分かれています。そこで、MCP 専用の Cognito ユーザープール（Hub）を新設し、テナント別の既存ユーザープール（Spoke）を OIDC IDプロバイダー(IdP) としてフェデレーションする構成を採用しました（図 の ①・②）。ポイントは次の 3 点です。

• シンプルな接続体験：MCP クライアントからは OAuth 2.1 + PKCE に対応した認可サーバーが 1 つ見えるだけです。ユーザーは既存の Winvoice アカウントをそのまま使ってサインインでき、新たなアカウント発行やパスワード管理は不要です。
• 既存基盤は無改修：既存の ユーザープール は OIDC IdP として参照されるだけで、稼働中のアプリケーションに影響を与えません。
• 自前実装の最小化：トークンの検証は Bedrock AgentCore Identity の インバウンド認証（カスタムJWTオーソライザー設定）に委譲し（図の③）、独自実装部はディスカバリ用メタデータ応答の検証などの薄いレイヤーのみです。

アウトバウンド：「AI に権限を渡さない」トークン設計

MCP サーバーが Winvoice API を呼び出す際は、AgentCore Identity の機能である Token Vault が提供する 3-Legged OAuth により、ユーザー本人の同意を経て取得した本人のトークンを使用します（図の④・⑤）。Winvoice API 側からは MCP 経由のアクセスを通常のユーザーアクセスと同一に扱えるため、既存の認可・テナント分離・監査の仕組みがそのまま最終防壁として機能します。AI エージェント経由でも、権限の主体は常に人 (ユーザー) のままという設計原則です。

認可：二段構えの許可リスト

決済に関わるサービスとして全ユーザーへの一斉開放は行わず、「誰に AI 連携を許すか」を利用企業自身がガバナンスできる形にしています。

この二段構えにより、β版としての段階的な開放にも、問題発生時の即時取り消しにも、同じ仕組みで対応できます。許可リストの正本は Cognito ユーザープール の「グループ 」に配置し、トークンに含まれるグループ情報で判定することで、ここでも既存アプリケーションの無改修と独自実装する範囲の最小化を徹底しました。

Winvoice 今後の展望

本リリースは、Winvoice における AI エージェント連携の第一歩です。株式会社インフキュリオン は 以下の方向で取り組みを検討し、アマゾン ウェブ サービス ジャパン は、そのご支援を継続します。

• 会計ソフト・経費精算サービスとの横断連携を MCP 越しに実現し、AI エージェントを経理業務のハブにする
• 既存機能や外部請求書取込といった機能を、MCP ツールとして順次拡張する
• Claude 以外の MCP 対応クライアントへの対応拡大など、ベーシック機能を拡充する
• 蓄積した取引データと AI を組み合わせ、資金ショート予測といった先回りの提案へ踏み込む

まとめ

• Winvoice はリモート MCP サーバー方式により、URL 設定のみで AI エージェントから請求書カード払い業務を呼び出せる体験を実現しました。
• 既存の Amazon Cognito と、チームが習熟していた Amazon Bedrock を中心とする AWS 環境を活かしたことが、企画から公開まで約 1 か月という短納期を後押ししました。
• Amazon Bedrock AgentCore Runtime のセッション分離・認証認可の統合により、Fintech に求められる統制と AI 活用を両立しました。
• 最終承認は人間が画面で実施するヒューマンインザループ設計により、規制業種としての安全性を担保しました。
• 本アプローチは、AIエージェント連携を業務システムへ組み込む際の、Fintech 領域での参考事例の1つとなります。

著者について