金融サービスWealthfrontがMCPサーバーを公開して学んだこと — AIエージェントへの正確な口座データの渡し方とOAuth認証の設計判断

11月2日、WealthfrontのエンジニアリングブログがÀ「Learnings from building our public MCP server — Engineering Blog」と題した記事を公開した。この記事では、金融サービスWealthfrontが公開MCPサーバーを構築・運用する中で得た設計上の知見について詳しく紹介されている。

AIエージェントが家計管理や資産運用の文脈でも使われるようになった今、「エージェントに正確な金融データを渡す」という問題が浮上している。従来はPDFやCSVを手動でアップロードするしかなかったが、WealthfrontはMCPサーバーを公開することでこの問題に対処した。

MCPサーバーとは何か

Model Context Protocol（MCP）は、AIアプリケーションと外部システムを接続するためのオープンプロトコルだ。エージェントが「どんな機能が使えるか」を検出し、ツール・リソース・プロンプトとして定義された機能を呼び出せる仕組みを標準化している。記事中では「IDE間で使われるLanguage Server Protocol（LSP）に近い」と説明されている。RESTful APIとの違いは、MCPが厳密なプロトコルであるのに対し、RESTはより緩やかな規約にとどまる点だ。

WealthfrontのMCPサーバーが返すツール一覧の例（抜粋）：

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "finance_account_details",
        "description": "Read one of the authenticated user's Wealthfront accounts by accountId.",
        "annotations": { "readOnlyHint": true, "destructiveHint": false, "idempotentHint": true, "openWorldHint": false }
      },
      {
        "name": "get_accounts",
        "description": "List the user's Wealthfront cash, investing, and Portfolio Line of Credit accounts with current balances.",
        "annotations": { "readOnlyHint": true, "destructiveHint": false, "idempotentHint": true, "openWorldHint": false }
      }
    ]
  }
}

OAuth認証の設計判断：なぜ「ユーザー生成クライアントID」を選んだか

技術的に最も判断が難しかったのが、AIアプリケーションの認証方式の選択だ。ユーザー固有のデータを扱う公開MCPサーバーにはOAuthが適しているが、クライアントIDをどう発行するかで複数の選択肢があった。

Client ID Metadata Documents（CIMD）：HTTPS URLをクライアントIDとして使う方式。接続がシームレスで業界での採用が進みつつあるが、対応しているAIエージェントがまだ少ないため今回は見送り。
Dynamic Client Registration（DCR）：RFC 7591で定義された、エンドポイント経由でクライアントIDを動的に生成・登録する方式。エージェント側の操作はシームレスだが、公開エンドポイントをDoS攻撃などから守るための実装コストが高く、今回のスコープには合わないと判断。
ユーザー生成クライアントID（採用）：ログイン済みユーザーが専用セットアップページからクライアントIDを自分で発行する方式。発行されたクライアントIDはサーバー側でそのユーザーのアカウントと紐付けて管理されるため、第三者が同じIDを使って別ユーザーの口座情報を引き出すことはできない設計になっている。

ユーザー体験としては最もシームレスではないが、「早く公開して学ぶ」という方針のもとで合理的なトレードオフと判断した、と記事では説明されている。

最も実践的な知見：ツール設計の2つの教訓

テストを通じて得られた知見のうち、エンジニアにとって最も参考になるのがツール設計に関する2点だ。

1. エンティティ基準ではなく、インテント（意図）基準でツールを定義する

通常のAPI設計ではエンティティ（ユーザー、アカウントなど）のCRUDを基準にエンドポイントを構成する。しかしMCPのツール定義をこの方式にすると、エージェントがどのツールを呼ぶべきか判断しにくくなる。ユーザーが「何を知りたいか」という意図を軸にツールを設計すると、関連性が高く、速い応答が得られたという。たとえば「投資口座のオープンタックスロット」や「Wealthfront管理ポートフォリオの運用戦略」といった具体的なユースケースに対応したツールを用意する、という方向性だ。

2. ツールのメタデータ（説明文・パラメータ定義）は徹底的に書く

説明が不十分だと、エージェントは間違った推論をする。 実例として、ユニークなアカウント識別子フィールドを accountId と命名したところ、あるエージェントが「口座明細書に表示されるアカウント番号」と誤解したケースが紹介されている。この手の誤りは、パラメータや出力の説明を丁寧に書くことで防げる。MCPの強みの一つは、スキーマに人間が読める説明文を含められる点にある。エージェントが各フィールドの意味を推測する必要がなくなり、ツールの使いどころ・使わないどころも明示できる。

今後の展開

Wealthfrontは今後、接続プロセスのシームレス化と対応機能の追加を予定している。セットアップの詳細はヘルプセンター記事にまとめられている。

詳細はLearnings from building our public MCP server — Engineering Blogを参照していただきたい。