ChatGPTが家計管理に来た。エンジニア視点で気になるのそこじゃない

OpenAIがChatGPTに個人向け資産管理機能を追加した。金融データネットワークのPlaidを経由して銀行・証券・クレジットカードなど1200以上の金融機関と連携できるらしい。American ExpressやRobinhood、Bank of Americaにも対応していて、ポートフォリオの運用状況や支出をダッシュボードで一覧できる。

正直、「家計管理か〜」と最初は流し読みしようとした。でも読み進めるうちに、気になるポイントが別のところにあることに気づいた。

Plaidをラップして自然言語で操作させるアーキテクチャ

自分がまず引っかかったのは、金融機能そのものよりも「Plaid＋LLMの組み合わせ方」だ。Plaidは口座情報の正規化・集約をやってくれるAPIで、金融系のスタートアップがよく使うやつ。それをLLMのフロントに置いて、ユーザーが自然言語で問い合わせると実際の財務データを元に答えが返ってくる構成になっている。

これ、構造としては「外部データソース＋LLM」のFunction Callingパターンそのものだ。OpenAIが社内でどう実装しているかは当然わからないけど、自分だったらPlaidのAPIレスポンスをコンテキストとして渡してGPT-5.5に推論させるイメージで読んでいた。ただ、財務データをコンテキストに丸ごと詰め込むとトークンコストが跳ね上がる問題がある。口座数が多いユーザーのデータ量は相当なはずで、どうフィルタリングしているのかが気になる。

もしこれを自分のプロジェクトで似たことをやるなら、まずデータの要約レイヤーを挟むと思う。全トランザクションをそのまま流すのではなく、集計済みのサマリーだけ渡して詳細はFunction Callingで必要に応じて取得する設計が現実的だ。

プライバシー設計のほうが実は参考になる

記事に書いてあったセキュリティの話も面白かった。口座連携を解除すると30日以内にOpenAIのシステムからデータが削除される仕組みになっているらしい。一時チャット（シークレットモード）では財務データにアクセスできない設計にもなっている。

この「データライフサイクルをユーザーがコントロールできる」設計は、自分が個人開発でユーザーデータを扱うときに意識していない部分だった。削除フローを後付けで実装しようとすると地味にしんどい。認証・保存・削除の3フローを最初から設計に組み込む癖をつけたほうがいいと、改めて思った。

LLMを使ったアプリを作るとき、推論コストばかり気にして「そのデータをいつ・どうやって消すか」を後回しにしがちだ。外部APIと連携するなら特に、データの保持期間とユーザーへの開示をセットで考えておかないとあとで詰む。

自分は来週、個人開発のサイドプロジェクトで使っているSupabaseのRLSポリシーとデータ削除フローを見直してみるつもりだ。Plaid連携はすぐにはやらないけど、「ユーザーがオフにしたらデータが消える」設計を最初から入れることは意識しておきたい。