- 金融口座データとMCPコネクタを接続すれば、残高、取引履歴、投資、ローン情報をもとに、繰り返し行う財務チェックをプロンプトだけで自動化できる
- 既存のCodex CLI cron-job方式は、Webログイン、ブラウザレンダリングの問題、2FA、passkeyの制約のため頻繁に壊れ、口座ごとのチェックを安定して続けるのが難しかった
- 再構成した日次メール自動化では、朝のスケジュールとcustom connector、
email_me()ツールを組み合わせ、すべての口座と純資産を整理して送るようにし、内容もプロンプト調整だけで変更できる
- 取引監視の自動化では、異常取引や大きな流出を最近のパターンと比較して見つけ出し、条件に合うときだけメールを送るよう設定して不要な通知を減らせる
- この方法により、個人向けに最適化された業務自動化を非常に低コストで素早く試し、拡張できるようになり、リアルタイムデータに接続された財務チェックを非開発者でも直接扱えるようになる
自動化の構成方法
- DriggsbyはPlaidで金融口座に接続したうえで、MCPを通じて残高・取引履歴・投資情報・ローン情報といったツールを公開している
- 当初はClaudeで必要なときに都度質問する対話型の利用が中心だったが、純資産確認、残高レビュー、取引モニタリングのような反復パターンが見えてきた
- Claude Code routinesは、こうした反復作業をプロンプトだけで自動化しやすくしてくれる
- 別途agent loopのコードを書いたり、デプロイ環境を用意したりしなくても、プロンプトとMCPコネクタをつなぐだけで動かせる
- データとツールをMCPコネクタでうまく接続できれば、自動化を構成できる
既存方式の限界と移行
- 以前は非対話型のCodex CLI cron-jobで銀行・クレジットカード・証券・退職口座にログインし、残高と最近の取引を取得して、日次の金融サマリーメールを送るようにしていた
- Chrome DevTools MCPを使って各Webサイトにログインし、情報を抽出していた
- 夫婦に日次の金融サマリーメールを送るだけの単純な作業だったが、実際には頻繁に壊れた
- 翌日にはすぐ失敗することが繰り返され、ブラウザレンダリングの問題や予期しない2FA要求のせいで、口座単位で動作が止まることも多かった
- GPTがメール形式を完全に変えてしまったり、実行中に混乱して1つの口座情報しか取ってこなかったりすることもあった
- 新たに追加が必要だった口座の中には、passkeyログインのみ許可しているものもあった
- こうした繰り返しの障害のせいで、期待したメールが届かないたびに自分で対応しなければならず、その過程のストレスを減らすためにDriggsbyを構築することになった
日次メール自動化
- 最初に作り直したのは日次メールで、目標はすべての口座と純資産を見やすい形式で要約し、毎朝受け取ることだった
- この情報はもともとGoogle Driveのどこかにある古いスプレッドシートに入っていた
- 更新には15分ほどしかかからなかったが、その小さな摩擦のせいで頻繁に更新できず、多くても半年に1回程度しか更新していなかった
- routinesでは、プロンプト入力、朝のスケジュール設定、Driggsby custom connectorの接続だけで初期構成がとても簡単に完了した
- ただし当初はメール送信手段がなく、Gmail connectorをつなぐと、整った下書きが作られるだけだった
- Gmail connectorでは実際の送信はできず、draftしか作れなかった
- これを解決するため、Driggsbyに**
email_me() MCPツール**を追加したところ、この方法はかなり便利に機能した
- 送信先を口座所有者の検証済みメールアドレスのみに制限し、リンクと画像を禁止して、セキュリティ上許容できる水準に合わせた
- 本文をMarkdownに固定し、MarkdownレンダリングメールにCSSを加えることで、実行ごとに生じる書式の不一致を減らした
- いくつかの小さなバグは、routinesのinspectabilityのおかげで比較的簡単に修正できた
- UIがClaude DesktopやWebアプリの一般的なClaude Codeセッションのように見えるため、実行中の状態を直接確認しやすかった
- テストを経て日次メールは実際に届くようになり、その後はメール内容の変更もコード修正なしで、routines UIでプロンプトを調整するだけで可能になった
- 夫婦で見たい項目が異なるため、それぞれ別々の日次メールを別個のプロンプトで構成できるようになった
異常取引と支出監視
- 日次メールが定着した後は、追加のインフラ負担なしにagentを立ち上げられる点を活かして、さらに多くの自動化を加え始めた
- まず取引データで異常取引監視を構成し、週次実行のroutineでAmexクレジットカードの1年分の取引を読み込みつつ、直近7日間に重点を置くよう設定した
- 直近7日間の取引が過去のパターンと比べて、二重請求、サブスクリプション料金の変更、見慣れない加盟店名や説明など、想定外であればメールを送るようにした
- 直近7日間の取引が正常で一貫していれば、通知を送らないよう制限した
- こうした単純なプロンプトはfalse positiveを生む可能性はあるが、時間をかけて磨き込むコストもレビューコストも低そうだ
- 続いて当座預金口座では、大きく想定外の流出を監視するroutineを作成した
- 直近1日の取引だけを確認し、過去12か月のパターンと比較して、$500超の取引の中から大きな流出や異例の流出を見つけるようにした
- 自動化が毎日動くため、確認範囲は直近1日に厳しく限定した
- 条件に合う項目があれば件名が "Checking account outflow alert" のメールを送り、なければ通知しないようにした
- その後この方法は、投資モニタリング、サブスクリプション分析、複数の支出カテゴリ監視へと拡張された
- routinesでの設定が非常に簡単なため、時間が経つにつれて複数条件をまとめて扱ったり、プロンプトをさらに精緻化したりする必要性が高まる
なぜ重要なのか
- routinesの最大の強みは、ほとんど手間なく試せる点にある
- クラウド上でliveデータに接続された自動化を、非開発者でも直接扱える点が際立っている
- CPAである配偶者も、Driggsbyのリアルタイムデータを引き込み、自分向けの自動化を自ら動かしている
- このような使い方により、プロンプトとコネクタだけで個人向けに最適化された業務自動化を素早く作れる
1件のコメント
Hacker Newsの意見
最近、自分でこんな構成を組んでみた。https://tiller.com/で当座預金/クレジットカードの取引をGoogle Sheetsに同期し、GitHub Actionsでそのスプレッドシートを無料のSupabase DBにミラーしている。
Supabase MCPやpsql経由でClaude/Codexが取引履歴と残高に英語のクエリでアクセスできるようにしたところ、サブスクの傾向や異常パターンを見つける能力はかなり印象的だった。特に、オンラインツールが苦手なキャッシュフロー予測もなかなか良くて、たとえば月次の支出パターンと使える現金を基準に、いくらを貯蓄に回せるかを尋ねられた。
自動分類の面では、ClaudeはカスタムDSLをかなりうまく扱えた。受取先/カテゴリ正規化用のMarkdownテーブルのルールセットを作らせ、そのルールもGitHub Actionsで一緒に回している。
Plaidのようなもの経由で引っ張っているのか、今でもウェブバンキングの認証情報を渡す必要があるのか、2FAをどう処理しているのか知りたい。
正式なAPIがない金融機関では、まだスクリーンスクレイピングに頼っているのか、バグで意図しないクリックや同意、ひいては誤送金のようなことが起きたらどうなるのかも不安だ。読み取り専用とは言うが、個人向けバンキングで本当の読み取り専用サブアカウントをサポートしている銀行はほとんど見たことがない。
大規模な金融被害が出たときに補償を受けられるような保険や保証があるのかも気になるし、銀行データ全体を2社に見せることのプライバシー面の含意も心配だ。データが不適切に販売・共有されたという集団訴訟の話も聞いたが、実際に何があったのかは分からない。
銀行の利用規約で、パスワードを第三者と共有しないことに同意する条項も引っかかる。自分の金融情報をウェブ/クラウドサービスに預けるのはどうにも気が進まず、ローカルで動いて銀行APIと通信するクライアントソフトウェアの方が望ましい。カナダにそういうものがあるのかも気になる。
オープンバンキングが来るとは言われているが、個人が自作ソフトウェアからアクセスできるのかも不明だ。本当に信頼できて、ダウンロード後の内部保管を最小限にする方針まで強制されるなら、自分も銀行APIを使いたい。
MintがIntuitに買収されて以来Tillerを使っていて、似たような構成にしている。ただ、自分はローカルのqwenモデルとOAuthで作ったAPIキーでsheetsアクセスをつないだので、Claude Routine方式の方がずっと簡単だったと思う。
全体の設定方法や、とくにどんなプロンプトを使っているのか見てみたい。
自分の純資産が少ないからかもしれないが、正直なところ、これがなぜ価値あるのかよく分からない。
LLMに毎日メールを送ってほしいとも思わないし、投資状況を四半期より頻繁に見なければならないなら、むしろもっと安全な投資にすべきだと思う。予算管理ツールには少し興味があるが、それは完全に決定論的であってほしい。
自分の財務計画はおおむね穏やかなので、今以上に支出最適化に時間を使うより、給料の高い仕事を探す方がいいと思う。
数字に関わるものは本来すべて完全に決定論的であるべきだと思う。
LLMにSQLite DBを見せて、過去5年の取引から見えることを言ってみろと頼んだところ、拾った内容や思い出させてくれたことは印象的だった。ただ、実際に自分が何かを変えるような実質的価値があったかはよく分からない。
しばらく月次レビューをさせてみるつもりだが、予算を更新するだけでも財務状況は大体把握できているので、どこまで役立つかは未知数だ。
自分はそれでクレジットカードと当座預金口座を追跡していて、必要ならそこにMCPをつないで一か所のデータを分析することもできる。
カナダ在住で、追跡用にhttps://lunchmoney.app/をPlaid連携と一緒に使っている。
APIがあるので、LLMにCLIを書かせたら、エージェントが必要なデータをほぼ自由に取ってこれるようになった。
もう一つやらせたのはタグ付けルールの蓄積で、これは1日1回cronで回している。ときどきルールを見直させて、未分類取引用の新しいルールも作らせている。
LLMに作業をルールエンジンやコードとしてメモ化させるパターンはかなり良いと思う。ひとたび問い合わせ可能なCLIさえできれば、エージェントにはほとんど何でもやらせられる。
興味のある人向けに、こちらのインフラ/セキュリティ構成の全体像を共有する。
バックエンドとCLIは厳格にlintingされたRustで、ウェブアプリはAxum上で動き、Postgresにはsqlxで接続している。
金融機能は読み取り専用だ。振替・支払い・送金ツールはなく、AIの画面からもお金は動かせない。
Plaidでは取引、投資、負債だけを要求し、auth/transfer/payment initiationは要求していないので、完全な口座番号やルーティング番号は受け取らず、基本的な下4桁マスクだけを受け取る。
銀行のユーザー名とパスワードはPlaid Linkに直接渡り、こちらを経由しない。こちらが保持するのは金融機関ごとのaccess tokenだけだ。
Plaid access tokenは別DBに置き、単一のcustody Cloud Runサービスの裏に置いている。保存時にはCloud KMSで暗号化され、brokerがKMS encrypt/decryptエンドポイントを呼び出し、ルート鍵素材はGoogle HSM境界の外に出ない。brokerのサービスアカウントだけが暗号化/復号の権限を持ち、ウェブアプリにはそのDBを読む権限がない。
すべての暗号化/復号呼び出しではPlaid item IDをAADとして渡し、あるアイテムの暗号文を別アイテムのトークンとしてすり替えて復号できないようにしている。
各Cloud Runサービスはそれぞれ固有のクラウドIDとDB roleで実行され、サービス間の内部呼び出しも短命のidentity tokenで認証している。
本番DBにはpublic IPがなく、秘密情報はソースやコンテナイメージではなく管理型のsecret storageに置いている。
AI connectorはOAuth 2.1 + PKCEで、ユーザーごとのscopeを持ち、UIからrevokeできる。すべてのtool callについて、ツール名、整形済み引数、呼び出しクライアント、エージェントが提示した理由を記録しているので、LLMがユーザーの代わりに何を要求したか確認できる。
AIの画面にはfetch-URL、shell、汎用I/Oツールはなく、構造化された金融データだけを返す。ネットワーキング、IAM、DB grantはすべてTerraformで管理し、インフラ変更もその経路でのみ行う。
インフラへのアクセスは2FAとセキュリティキーで統制している。
このサイトの読者層を理解している感じがするし、セキュリティを各レイヤーで丁寧に設計している点も、ツール全体への信頼を高めてくれる。
自分も似たものを自作しようとしたことがあるが、初期のMVPは明細PDFを手動でダウンロードして、Claudeでプレーンテキスト会計用のledgerをセットアップする程度で、後でPlaidをつなぐつもりだった。
とくにPlaidを人々がどう使っているのか気になる。始めるにはある程度のユーザー数が必要なのか、単に自分の個人/事業口座をきれいなAPIにつなぎたいだけでも個人用途でPlaidアカウントを作れるのか知りたい。
Routineを使うときは気をつけた方がいい。
ほとんど目立たない小さな案内文があるのだが、routineモードではMCPツールが書き込み権限込みで常時許可される。だからエージェントが技術的には勝手にリソースを変更してしまうこともあり得る。
これは問題を探している解決策のように見える。https://tiller.com/だけでも十分うまく動くし、スプレッドシートでやりたい計算は全部できるし、おまけにハルシネーションもない。
読まなければならない冗長なLLM要約を、なぜわざわざ欲しがるのかもよく分からない。たまに支出を自分で分類するだけでも異常値はすぐ目につくし、Tillerならその作業も簡単だ。
この分野では本当にいろいろな製品が出てくるだろうし、うちの製品はその一つのアプローチにすぎない。こうした試みが増えるのは自分も良いことだと思う。
LLMが複数のデータソースを簡単に取り込み、結び付けられる点の方が大きい。
うちのEra Financeはまさにこれを狙ったソリューションを作っている。互換性のある任意のエージェントを個人財務に接続するMCP、Era Contextで、https://era.appで見られる。
今は読み取りツールに集中しているが、お金の移動や借金返済のような書き込みツールも準備中だ。
欲しい機能があれば上のドメインのalex宛てにメールしてほしい。ちなみに自分はCEOのAlexで、HNはほぼ初めてだが、以前はstripe.comのウェブプレゼンス責任者で、その前はSquare/CashAppにいた。
たぶんもう勝負はついているのかもしれないが、そもそもなぜ金融取引の全履歴をLLMに預けたいのか分からない。
LLMプロバイダーが、こういうデータ利用について金融業界より強い保護策を持っているとも思えない。金融業界自体、私たちのデータを収集・採掘・販売する苛烈な業界なのに。
支出パターンや投資に関心がある立場として、ごく基本的なプロンプトだけでも、以前なら見落としていたことを見つけたことがある。
もちろん、これを安全にするのは非常に難しく、だからこそその部分についてものすごく長く考えている。
それなら、具体的に何が問題なのかよく分からない。
自分のメインバンクである英国のMonzoは、完全なAPIとイベント用trigger webhookを提供している。
そのおかげで、不審な取引が発生したら理由を説明しろと尋ねるWhatsAppボットを作れたし、LLMはその推論にだけ使っている。また、毎日深夜前に残高を貯蓄口座へ自動で掃き出して日次利息を最大化する自動化も組んでいる。
日常用口座には少額だけ残し、昼間にお金を使ったら貯蓄から補充してその低い残高を維持する。もっと大きな支出が必要なときは、そのときだけ手動で移す。
Claudeで過去の取引を分析しようとしたとき、存在しない請求を作り出したり、新しい項目を追加して重複集計したりといったハルシネーションが続いた。
財務を扱うなら、Claudeが95%正しい程度では足りない。常に警戒しながら結果を見直さなければならず、自分の場合は実質的に価値がなくなる。
自分もClaudeは、とくに不完全だったり制約のあるデータセットでかなりハルシネーションを起こしやすいと感じる。