4つの経路、1分で
すべてのAIのお金の質問は同じ壁にぶつかります。モデルはあなたの銀行口座を見ることができません。Claude、ChatGPT、Cursor、その他はすでに取引を渡されればそれを分析するのが得意です。モデルの前にデータを届けることこそが問題のすべてです。
やり方は4つあります。エージェントにファイルを渡す、オンラインバンキング上でブラウザを操作させる、自分で銀行APIに対して構築する、そのために取得を行ってくれるホスト型MCPサーバーに向けさせる、のいずれかです。
それぞれ鮮度、安全性、セットアップ時間のトレードオフが異なります。退屈な最初の方法を含め、どれも常に間違っているわけではありません。
経路1: CSVとPDFの手動アップロード
最も古い方法は今も機能します。銀行のウェブサイトからCSVかPDFの明細をダウンロードし、チャットに投下して質問します。
これが私の1月の明細です。レストランにいくら使いましたか、そしてどの請求がサブスクリプションに見えますか?
終了した期間についての単発の質問なら、これで十分です。前年度の明細での税務処理、1か月についての争い、めったに触らない口座への簡単な確認など。データはもう変化しないので、古さは問題になりません。
習慣として使うと崩れます。明細はエクスポートした瞬間に古くなり、銀行ごとにエクスポート形式が異なり、PDFは表の抽出を歪め、1年分の取引はモデルのコンテキストウィンドウを超えることもあります。さらに、口座番号だらけのファイルがダウンロードフォルダに溜まっていきます。たまになら問題ありません。毎週やるとつらくなります。
経路2: スクリーンスクレイピングとブラウザ自動化
スクリーンスクレイピングとは、エージェント本人、またはそれを代行するサービスが、本当のユーザー名とパスワードでオンラインバンキングにログインし、画面上の内容を読み取ることです。ブラウザ自動化エージェントはこれを簡単そうに見せます。認証情報を貼り付け、モデルにクリックさせるだけです。
やめてください。バンキングパスワードは、あなたのお金を動かすためのマスターキーであり、この経路はそれを「送金」ボタンもクリックできるソフトウェアに手渡します。ほとんどの銀行の利用規約は認証情報の共有そのものを禁じており、何か問題が起きた場合、詐欺の責任があなたに転嫁される可能性があります。そして絶えず壊れます。MFAプロンプト、CAPTCHAの壁、銀行サイトのリデザインなど、誰かが気づいて直すまで自動化は死にます。
これは2010年頃の初期のfintechが使っていた手法で、他により良いものが存在しなかったからです。今はより良いものが存在します。
経路3: 直接の銀行API
銀行は次第に公式のAPIを公開しており、米国ではFDXとして標準化され、欧州ではPSD2などのオープンバンキング規則で義務付けられています。アクセスはトークン化され、スコープが定められ、取り消し可能です。パスワードは銀行から外に出ません。これは本当に正しい基盤であり、現代のほとんどの金融アプリの表層の下にある2つの経路はこの上に構築されています。
問題は誰がそれを使えるかです。直接のAPIアクセスは企業向けに設計されています。開発者契約、セキュリティレビュー、時には数か月かかる銀行ごとのオンボーディングなどです。3つの金融機関に口座を持っていれば、それぞれ癖の異なる3つの統合になります。まさにこれを解決するためにアグリゲーターが存在します。彼らは銀行との接続を維持するため、アプリ開発者はその必要がなく、あなたが使ったことのあるほぼすべての金融アプリはその上に乗っています。
エージェントにお金の質問に答えてほしいだけの個人にとって、これを自分で構築するということは、最初の有用な答えが出るまでに数週間の作業を意味し、さらにあなた自身の銀行フィードのオンコールエンジニアになるということです。
経路4: ホスト型MCPサーバー
MCP (Model Context Protocol) は、AIアプリが外部ツールを呼び出せるようにするオープン標準です。銀行データ用のMCPサーバーは、生のファイルやブラウザセッションの代わりに、型付きで読み取り専用の小さなツール群をエージェントに与えます。エージェントは必要なものを求め、構造化されたデータを受け取り、その上で推論します。
BankBridgeはその私たちなりの実装です。銀行を公式の銀行接続レイヤーを通じて一度だけ接続すると (あなたの認証情報は銀行に渡り、私たちにもエージェントにも渡りません)、その後エージェントには11のツールが備わります。list_accounts、search_transactions、get_recurring_charges、get_monthly_cashflow、list_holdingsなどです。すべての呼び出しは銀行からライブデータを取得します。私たちのサーバーに何もキャッシュされないので、心配すべきあなたの金融の保存コピーは存在しません。
今の当座預金残高はいくらで、今月はどの定期請求が発生しますか?
その質問を、任意のMCPホストでライブデータに対して答えられること、それがすべての要点です。Claude Desktop、Claude Code、ChatGPT、Cursor、Gemini、Zed、そして私たちがドキュメント化している約2ダースの他のアプリで動作します。セットアップは数分で完了し、認証はベアラーキーかOAuth 2.1で、料金は接続銀行1つあたり$5/moです。いつでもキャンセルできます。
並べて比較: 鮮度、安全性、セットアップ、破綻するもの
鮮度。アップロードはエクスポートした瞬間に古くなります。スクレイピングは壊れるまではライブです。直接のAPIとMCPサーバーは設計上ライブです。BankBridgeは質問のたびに銀行から取得するので、「私の残高は?」は前回のエクスポート時点ではなく、まさに今の残高を意味します。
安全性。アップロードはそれなりに安全ですが、明細ファイルがディスクに溜まります。スクレイピングは最悪の選択肢です。完全な認証情報、完全な書き込みアクセス、規約違反です。直接のAPIとホスト型MCPサーバーは、トークン化された、取り消し可能で、読み取り専用のアクセスを使います。BankBridgeにはお金を動かすツールが存在しないので、混乱したエージェントができる最悪のことは、奇妙な送金ではなく奇妙な質問を投げることだけです。
セットアップ時間。アップロードは最初のコストはゼロですが、そのあと毎回のセッションで10分間のエクスポートと整形が永遠に続きます。スクレイピングは仕込みに午後1回分かかり、面倒を見る時間は無期限です。直接のAPIは自分で構築するなら数週間から数か月かかります。ホスト型MCPサーバーは、銀行ごとに1回、数分で終わります。
破綻するもの。アップロードは形式の癖とコンテキスト制限で壊れます。スクレイピングはMFA、CAPTCHA、リデザインで壊れます。自作のAPI統合は銀行が何かを変更するたびに壊れ、そしてそれはあなたのポケベルです。ホスト型サーバーは、ほとんどの場合1つの予測可能な場所で壊れます。バンキングパスワードを変更したあとに銀行接続の再認証がひと手間必要になるだけで、2分で直せます。
どれを使うべきか?
終了した1か月について1つ質問があるだけなら、明細をアップロードして聞いてください。恥じることはありません。BankBridgeを手動のCSVエクスポートと真正面から比較しましたが、結論は「絶対にアップロードするな」ではありません。
どのエージェントにもバンキングパスワードを渡さないでください。デモのためでも、たった一度でも、です。
コンプライアンス予算のあるfintech製品を構築しているなら、銀行APIに直接向かうか、その下にあるアグリゲーターレイヤーに向かってください。それはそのために作られています。
そしてもしあなたが、すでに使っているエージェントから継続的に答えを得たい個人なら、ホスト型MCPの経路こそが持ちこたえる方法です。一度接続すれば、思いついたときに思いついたことを何でも聞けます。
今年、私のインターネット料金は上がりましたか? 1月以降のISPからのすべての請求を引き出して比較してください。