Claude Codeのルーティンは私の家計を見守れるのか？
(driggsby.com)- Plaid連携の金融データをMCPツールとして接続し、残高、取引、投資、ローン情報を扱い、繰り返していた金融チェックをClaude Code routinesで自動化できるようになった
- 従来のcronベースのブラウザ自動化は、レンダリング問題、2FAプロンプト、一部口座しか収集されない不具合、メール形式の変化、パスキー制限のため頻繁に壊れており、これを減らすためにDriggsbyが作られた
- 毎日の金融サマリーメールは、プロンプトと実行時間、Driggsby custom connectorだけで構成され、Gmail connectorが下書きしか作れないため、**email_me()**ツールを追加して実際の送信と形式の安定化を解決した
- 同じ方法で、直近7日間のAmex取引の異常検知と、checking accountの500ドル超の大きな流出監視を自動化し、正常なときは通知を送らないように設定した
- 設定とデバッグの負担が低く、配偶者ごとのパーソナライズされた金融ルーティンまで個別に運用でき、投資・サブスクリプション・支出監視へと素早く拡張できる自動化の土台になった
自動化の出発点とDriggsbyの構成
- 以前はCodex CLIとChrome DevTools MCPを非対話的に動かす毎日のcronジョブで、銀行、カード、証券・退職口座にログインし、残高と最近の取引を取得して、夫婦に毎日の金融概要メールを送る流れから始まった
- 初日はかなりうまく動いたが、翌日にはすぐ壊れることが繰り返された
- ブラウザのレンダリング問題、予期しない2FAプロンプト、実行中の混線で一部口座しか取得できない問題、メール形式が勝手に変わる問題、パスキーのみ許可する口座の追加問題まで重なった
- こうした不安定さを減らすためにDriggsbyを作り、2か月で75k linesのRustコードとPlaid契約を経て現在の形に至った
- DriggsbyはPlaidで金融口座に接続した後、MCPを通じて残高、取引、投資情報、ローン情報などをそれぞれのツールとして公開する
- 当初は必要なときにClaudeを開いて金融の質問を入力し、Driggsbyで答えを得ていたが、時間がたつにつれて純資産の確認、残高・取引チェック、投資モニタリングのような繰り返しの質問パターンが見えてきた
Routinesが変えたこと
- 数日前に公開されたClaude Code routinesは、こうした反復的な問い合わせを自動操縦に渡しやすくした
- クラウドで動くエージェントループ自体は新しくないが、routinesは設定プロセスが非常にシンプルな点が際立っている
- 別途エージェントループのコードを書いたり、デプロイ先を決めたりする必要がない
- OpenClaw、Codex SDK、Hetzner上の
claude -pのような実行環境も自分で立ち上げる必要がない
- プロンプトを書き、データとツールをMCP connectorで整然と接続するだけで、自動化をすぐ構成できる
毎日のメール自動化
-
古いスプレッドシートの置き換え
- 最初に再び取り組んだのは毎日のメールで、目標はすべての口座と純資産をひと目で見られる、すっきりした要約メールを受け取ることだった
- この情報は長いあいだGoogle Driveのどこかにある古いスプレッドシートにあり、更新には15分ほどしかかからなかったが、その小さな摩擦だけでも頻繁には更新しなくなっていた
- 実際の更新頻度は多くても半年に1回程度にとどまっていた
-
ルーティンの設定プロセス
- プロンプトを入力し、毎朝の実行時間を予約し、Driggsby custom connectorを接続して保存するだけで設定は完了した
- ただし最初はメールを送る方法がなく、そこで行き詰まった
-
Gmail connectorの限界と代替ツール
- Gmail connectorを追加すると、情報密度が高く見栄えのよいメールが作られたが、実際には受信トレイではなく下書きとしてしか生成されなかった
- Gmail connectorはメール送信ができず、draft作成のみ可能だったため、別の方法が必要になった
- Claude connector storeを見回したあとも手軽に使える送信方法が見当たらなかったため、Driggsbyに
email_me()というシンプルなMCPツールを追加した
-
email_me()の制約とフォーマット安定化
email_me()は送信先をアカウント所有者の検証済みメールアドレスだけに制限し、リンクと画像を禁止して、セキュリティ上受け入れ可能な水準に合わせた- 実行のたびに形式が揺れる問題を減らすため、メール本文はMarkdown必須にし、Markdownレンダリング用のメールCSSも追加した
-
デバッグと最終結果
- 小さなバグはいくつかあったが、routinesの実行過程を簡単にのぞけるため、素早く修正できた
- UIがClaude DesktopやWebアプリで見る通常のClaude Codeセッションとほぼ同じなので、動作中のルーティンをそのまま点検しやすい
- 数回のテストのあと、朝7:47のメールが実際に届き、毎日のメール問題は解決した
- その後のメール内容変更は、コードを直さなくてもroutines UIでプロンプトを手直しするだけで可能になった
-
夫婦ごとの個別カスタマイズ
- 配偶者も自分のプロンプトで編集できる個人用の毎日メールを別に持てるようになった
- お互いに重要視する項目が違うため、それぞれ毎日受け取りたい情報を個別に調整できるようになった
毎日のメール以降の拡張
-
直近7日間のカード取引異常検知
- 毎日のメールが定着したあとは、インフラ負担なしで新しいエージェントを次々に立ち上げられるので、次に何ができるかへと関心が移った
- 取引データはすでにDriggsbyにあるため、次の自動化はAmexクレジットカード取引の異常検知へとつながった
- 毎週実行するroutineを作り、以下のプロンプトを入れて構成した
- 原文のプロンプト例
- 過去1年分のAmexクレジットカード取引を取得する
- 最後の7日間の取引だけを切り出し、その期間に集中して確認する
- 過去のパターンと比較して、二重請求、サブスクリプション料金の変化、奇妙な加盟店名や説明のような想定外の項目が最後の7日間にあればメールを送る
- すべての取引が正常で過去のパターンと一致していれば通知を送らない
- この程度にシンプルなプロンプトでもfalse positiveは起こりうるが、時間をかけて洗練しやすく、結果をレビューするコストも低い
-
checking accountの大規模流出監視
- 次に、checking accountで予想外の大きな資金流出があったかを確認するルーティンを作った
- 以下の条件でプロンプトを構成した
- 原文のプロンプト例
- checking accountの取引を確認しつつ、直近12か月の取引データと比較して、最後の1日で過去のパターンに合わない大きな流出があったかを確認する
- 500ドル超の取引に注目する
- この自動化は毎日動くため、最後の1日の取引だけを確認するという制約を強く置く
- 条件に合う項目があれば、件名が"Checking account outflow alert"のメールを送り、なければ通知しない
-
さらなる拡張範囲
- 時間がたつにつれて、この流れは投資、サブスクリプション分析、さまざまな支出カテゴリの監視へと拡張された
- routinesでの設定がほとんど簡単すぎるほどなので、今後は複数条件をまとめて扱ったり、プロンプトをさらに精密に磨いたりする必要が大きくなる
なぜ重要なのか
- routinesの最も強い点は、ほとんど手間なくすぐ試せる自動化にある
- プロンプトを思いつけば自動化を回せるレベルまで参入障壁が下がる
- 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は、とくに不完全だったり制約のあるデータセットでかなりハルシネーションを起こしやすいと感じる。