🕌
LLM で作る家計簿CLI アプリケーション

2025/10/27に公開
 初めに前回から約半年ほど経ってしまいましたが、LLM(AI)を用いてアプリケーションを作っていくという活動２回目です。
pythonで家計簿のCLIアプリケーション has-cliというのを作成しました。

実際、私自身の家計簿として活用できているし、せっかくなのでGithub 公開しています。

https://github.com/skzy2018/has-cli/

 対象読者家計簿アプリに興味のある技術者? / 家計簿においてAIの活用に興味がある人?
python アプリに興味のある人？
LLM(Cline)で開発に興味ある人？ (今回この辺りの内容全然少ない)

 どんなツールか？（これは車輪の再発明なのか？)皆さん自分たちの家計簿って、どんなふうにつけてます？
やはり、こんなのとか、こんなのとか、その他にも星の数ほどある家計簿ツールで、最近では大体のところ各銀行口座サイトなどと連携してほぼ自動で収支全体を把握できるようになっており、便利な世の中になったものです。

ただこの連携、実際の銀行口座アカウントを設定しなければならずセキュリティが心配になったり、そもそも連携先が限られていたりするわけで、なんとも歯痒い思いを(人によっては)感じる可能性もあるわけです。
僕なんかは、銀行口座サイトやクレジットカードサイトから取引明細のファイルをダウンロードして、ローカルの家計簿ツールにポチポチ入力していた時代を生きてきたわけで、今さらそんなアカウント連携なんかしちゃって良いのかしらん、と思うわけです。

そして、そもそも取引明細の集計情報は取引先相手ほどあるわけで、そのフォーマットが千差万別なものを家計簿に入力する"ポチポチ"作業が大変(ペイン)だったのです。なので、そのデータ変換自体を今のAI技術を利用して自動化、整理・調整してくれれば、あとは家計簿データベースとして保存できればいいのでは、と考えていました。
(取引情報のダウンロード自体もペインではあるんですが、この取引明細ファイルの取得方法もそれぞれですし、サイトからのダウンロードは個別にplaywrightを書くしかないかと考えました)

一応、腐ってもデータエンジニアなのでSQLは適当に書けます。DBさえあれば、確認したい情報をDBからSQLで抽出するのは苦ではないのです。そこは後回し。
と言うわけで、僕の要件としては以下：
各社銀行やクレカ会社からダウンロードしたバラバラなフォーマットの取引明細ファイルを
AIを使って仕訳して、
共通の家計簿データベースの取引情報にロードする
(DBに対しては、適当な集計結果の表示とsql実行ができればいい)
こんなの、今時のアプリは機能として持ってるんでないの？ ... かもしれません(車輪の再発明)

でもいいの。自分の道具を自分で作ってみたいだけ。

 どうやった？作りながら次のタスクを考える感じなのですが、ここまでやったこととしては
家計簿DBのスキーマを作る
DBへのロード方法を考えて関数を作る。(db_lib.py のload_csv_file)
仕訳をAIでやらせるmockを作る
CLIアプリとしての雛形を作る
CLIとしてのコマンドを拡張していく
... 以下同文
このうち、1.はChatGPTに"家計簿アプリのDBスキーマを一式作って"と言って出力したものを、データエンジニアとして必要分を取捨選択して対応。

2.も(再三言うけど)データエンジニアなので、どちらかというと自分で少し考慮して実装。
そして、3.は以下のようなプロンプトを渡した。
!LLMを利用したAIAgentのpythonスクリプト(プロンプトファイル含む)を作成してください。
webから収集した各種銀行やカード会社の取引データ情報から、仕訳、カテゴリ分別を行い、

DBにロードするためのcsvファイルを作成するpython スクリプトです。
[仕様詳細]

 実行方法ユーザは、以下のようにコマンドプロンプトで実行して使用する。$ python ./main.py  -t <取引先名>  <取引データ情報ファイル>
<取引データ情報ファイル> とは、ユーザがWebから収集した各種取引データ情報ファイルのこと。ファイルの種類は、銀行やカード会社によって異なり、pdf やcsv を想定している。
<取引先名> は、その取引データ情報ファイルを得た銀行やカード会社名のこと。各社・各行によってデータ形式の仕様が異なるため、分析・仕訳の仕方が異なる。それを制御するために、引数として指定する。

 ここで作成するファイル群作成するファイル群は以下の通り. (./journalize/ 配下に作成すること )

./main.py : この処理を実行するファイル

./prompts/system.txt :全ての処理で同一のLLM用「システムプロンプト」※

./prompts/tr_<取引先名>.txt : 銀行やカード会社など<取引先名>の種類によって異なるLLM用「取引先名別プロンプト」※

README_main.md : この処理スクリプトの説明ファイル

※LLMのプロンプトは全ての処理で同一のシステムプロンプトと、銀行やカード会社など<取引先名>の種類によって異なる取引先名プロンプトが必要となる。


 そのほかの仕様LLM は複数(OpenAIやAnthropic)を設定できる前提で、Providerの選択とAPI　KEYの設定は、./config.iniファイルによって設定し、コマンド実行時はそれを読み込むこと。
データの出力は、csv形式で、以下ファイルで出力する。

./out/tr_<取引先名>_<実行日時>.csv
出力するcsvの構成は、このディレクトリ上にある./README.mdで扱っているデータベース向けである。./db_load.py の中のDBに向けたロード処理によってロードが可能となるデータ形式とする。(つまり、csvヘッダは./db/csv/配下のcsvファイルと同じヘッダ構成で出力される)
この出力csv構成を実現するために「システムプロンプト」「取引先名別プロンプト」を作成すること。
新しい取引先名で実行した場合(-tオプションで指定した取引名の取引先名別プロンプトが存在しない場合)、LLMにて事前に作成を試みる。
これを実現するためには、複数回LLM呼び出しが必要になり、AI Agent 構成を、main.pyの内部で構成すること。

実装ライブラリは、langchainに加えて、上記のMultiAgent構成を langgraphrライブラリで実装すること。
実行した詳細のログ(利用したプロンプト内容など) は、以下のファイルでログ出力すること。

./out/tr_<取引先名>_<実行日時>.log
実行した後は、出力されたデータcsvファイルとlogファイルのパスを返却すること。
これをCline(LLM)に読み込ませると、6,7割がた実装が完了してしまimasita。

これに追加して対応したのは、
エラー修正
新しいAgentでまだプロンプトがない場合のプロンプト作成で既存プロンプトを参考にするよう修正
全部main.pyだったので、TransactionJournalizer を別ファイルに
PDFファイルが日本語だと文字化けったのでPyPDF2からpymupdfに修正

ここまでやって、コストは約$4.6
これで、TransactionJournalizer.py は作成できました。

CLIコマンドツールのrichなどのmockをつくってコマンドを追加、集計情報(sum_**コマンド)はClineに作ってもらったが、SQLの修正や追加のコマンドはこちらで実装、現状に至る、と言う感じです。
アプリとして寝かせてしまってて、さらに、実際の僕個人の過去のデータを入れて試していたりしたので、時間はかかってしまったが、LLMと実装の対応工数としては数日程度でしょうかね。

 今後の拡張方針(LLMによる)さて、結構これ個人的には使えております。

当該ディレクトリに行って、

. env/bin/activate

python has-cli/has-cli.py

でアプリが起動し、あらかじめダウンロードして置いた取引情報ファイルを　journalizeコマンドでcsvファイルを作成、そのままロードして、データとしてはarchive すればデータの登録終了。

最初のうちは仕訳のためのpromptの調整が必要です。
data/prompts配下のpromptファイルを整理 (tj_bank.txt.sampleを参考に)
しかし、一度promptを作ってしまえば大体毎月の取引は同じようなものなので、毎月処理はほぼ自動で対応できます。
今後、せっかく作ったので、このアプリどうしようか、と言うことで以下のようにアプリの今後の拡張機能についても、Cline(LLM)に聞いてみました。
!has-cli は各社口座などの取引明細ファイルを含めて管理できる、家計簿CLIアプリケーションです。この詳細情報、機能を、README.mdや実際のコード( has-cli/has-cli.py ほか) を確認して理解し、どのようなユーザに使われるかを想定した上で、今後どのような機能拡張をすべきか、具体的にいくつかの方針を提案してください。
結果の概要はこちら：
!
 想定ユーザー
プライバシー重視派: クラウドサービスを避け、ローカルでデータ管理したい個人

技術リテラシーが高い層: CLI操作に抵抗がない、エンジニアや技術者

複数口座保有者: 複数の銀行・クレジットカードを利用している個人/世帯

詳細管理派: 家計簿の細かいカスタマイズや分析にこだわる人

 今後の機能拡張提案
 1. 【優先度：高】予算管理機能背景: 現在は取引の記録と集計が中心で、計画的な支出管理機能がない
具体的な実装案:
カテゴリ別・月次の予算設定テーブル追加
予算vs実績の比較コマンド (budget コマンド)
予算超過時の警告表示
予算の繰越・調整機能
期待効果: 単なる記録から計画的な家計管理へ進化

 2. 【優先度：高】データ可視化機能背景: 現在は表形式の出力のみで、トレンドや傾向が把握しづらい
具体的な実装案:
matplotlib/plotlyを使用したグラフ生成
月次推移グラフ、カテゴリ別円グラフ、収支トレンド
HTMLレポート生成コマンド (report コマンド)
ターミナル内でのASCIIチャート表示オプション
期待効果: 視覚的な理解が容易になり、支出パターンの把握が向上

 3. 【優先度：中】定期支出・サブスクリプション管理背景: 現代の家計では定期支出（サブスク等）の管理が重要
具体的な実装案:
定期支出テーブル (recurring_transactions) の追加
パターン検出AIによる自動識別
更新・解約の通知機能
月次コスト一覧表示コマンド
期待効果: 忘れがちなサブスクの可視化と管理の効率化

 4. 【優先度：中】高度なAI分析・インサイト機能背景: LLMの能力を仕訳以外にも活用できる
具体的な実装案:
支出パターンの自然言語分析
異常支出の検出とアラート
節約提案の生成 (insights コマンド)
カスタム質問への回答（「今月の外食費は？」等）
期待効果: 受動的な記録から能動的なアドバイスツールへ

 5. 【優先度：中】マルチ通貨対応背景: 現在はJPY中心、海外取引や投資の記録に制限
具体的な実装案:
accountsテーブルにcurrency列追加
為替レート取得API連携
基準通貨での統合レポート
通貨別残高表示
期待効果: グローバルな資産管理が可能に

 6. 【優先度：中】Webインターフェース（オプション）背景: 家族との共有やモバイルアクセスのニーズ
具体的な実装案:
Flask/FastAPIでローカルWebサーバー構築
読み取り専用のダッシュボード
レスポンシブデザインでモバイル対応
認証機能の追加
期待効果: 技術者以外の家族メンバーも利用可能に

 7. 【優先度：低】レシート・証憑管理背景: 取引データと物理的な証拠書類の紐付け
具体的な実装案:
filesテーブルへの画像/PDFリンク機能
OCRによる自動データ抽出
transaction_idとファイルの関連付け
期待効果: 確定申告や経費精算時の利便性向上

 8. 【優先度：低】投資・資産管理機能背景: 現金フロー以外の資産（株式、暗号通貨等）の追跡
具体的な実装案:
assetsテーブルの拡張活用
市場価格取得API連携
時価評価とパフォーマンス追跡
ポートフォリオ分析
期待効果: 総合的な資産管理ツールへの進化

 9. 【優先度：低】データエクスポート・連携機能背景: 他のツールやサービスとの連携ニーズ
具体的な実装案:
Excel/Google Sheets形式エクスポート
会計ソフト（freee, MFクラウド等）連携
カスタムフォーマット定義機能
期待効果: エコシステムへの統合

 実装優先順位の考え方フェーズ1（短期）: 予算管理、データ可視化
既存のデータを活かし、すぐに価値を提供できる
コア機能の強化
フェーズ2（中期）: 定期支出管理、AI分析、マルチ通貨
ユーザー体験を大きく向上させる
差別化要素の強化
フェーズ3（長期）: Webインターフェース、投資管理、外部連携
利用シーンの拡大
より広範なニーズへの対応
なるほどねー。これはもう、もうLLMの言われたとおりにしようかしら。

 最後にプロンプトとLLMの結果が記事の半分をしめてるけど、いいんかなぁ。これ。
初めに

対象読者

どんなツールか？（これは車輪の再発明なのか？)

どうやった？

今後の拡張方針(LLMによる)

最後に

Discussion
