ハクソク

世界を動かす技術を、日本語で。

10年間の個人財務をプレーンテキストファイルで

143日前原文(sgoel.dev)

概要

  • Beancount を使い始めて 10年 の個人資産管理の実践記録
  • 45,000行超 のエントリーと 500以上のドキュメント を管理
  • 毎月 30-45分 で明確なワークフローを実施
  • 独自インポーター 開発や書籍執筆によるノウハウ共有
  • プレーンテキスト管理 と 自己所有データ の価値強調

10年分のBeancountレジャー

  • 2016年1月 から Beancount で個人資産をテキストファイル管理
  • 毎月30-45分 かけて銀行明細をダウンロードし、インポート作業実施
  • 45,000行超 のエントリーが 16ファイル に分割保存
  • ファイルは financesディレクトリ でバージョン管理（git利用）
  • 例：2020年4037行、2023年5606行、2016年は1454行
  • メインファイル には約 10,000件 の取引、 20,000件 のポスティング記録
  • 1086アカウント 登録（実際の銀行口座数ではなく、用途ごと仮想的に作成）
    • 例：スーパーマーケット支出、収入、Netflixサブスクリプションなど
  • 500件超 のPDFドキュメント（領収書・請求書等）を紐付け管理
  • 年度ごとのポスティング数 ：2016年715件から2023年2651件まで増加

毎月のルーティン

  • 銀行口座にログインし CSV明細 をダウンロード
  • インポーター でCSVをBeancount形式に変換
  • 変換データを .beancountファイル に追記
  • 各エントリーを 一つずつ確認・バランス調整
    • ダブルエントリーブックキーピングの原則（合計ゼロになること）を確認
    • 一部は自動、一部は手動で調整
  • 年度切替時、前年の取引を <year>.beancount に移動し、mainファイルでインクルード
  • すべての資産履歴が 数個のテキストファイル に集約

ドイツ銀行向けBeancountインポーター開発

  • Beancount自体は 銀行明細の形式 に非依存
  • インポーター とは、銀行明細（CSV等）をBeancount形式に変換するPythonクラス
  • ドイツ在住のため、 beancount-dkb、beancount-ing、beancount-n26 等の独自インポーターを開発・メンテナンス
    • Commerzbank向けは口座閉鎖により非メンテ
  • これらのライブラリは 現在も活用・保守中

ユーザーから著者へ

  • Beancount導入時は ドキュメントの網羅性 が高い反面、全体像の把握が難しかった経験
  • 試行錯誤を経て「 新規ユーザー向けの短い書籍」を執筆
    • https://personalfinancespython.com にて公開
  • 書籍は Beancount公式サイト でも紹介され、読者から高評価

プレーンテキスト会計の価値

  • 全資産データが 自分の手元 かつ プレーンテキスト で管理
  • gitでのバージョン管理により 変更履歴 も明確
  • 必要な時に エディタで即時閲覧・分析 可能
  • クラウドサービス依存なし、長期的な可用性確保
  • プレーンテキスト会計 の強力さと安心感

Hackerたちの意見

もう何年もbeancountを使ってるんだ。今年に入ってから、OPと同じように年ごとにファイルを分ける形にしたよ。前は2022年のファイルだけで、テキストが200万行もあって、emacsプラグインが重くなってきてたんだ。個人の財務管理にこの方法が一番いいと思うのは、全てを追跡できるところ。投資、年金、RSU、銀行口座までね。エネルギー使用量をkWhで計算して請求書と比較するなんてこともできるけど、さすがにそこまではやらないかな :D それに、LLMの登場でbeancount管理のツールもかなり増えたよ。最近はclaudeを使って、取引ルールエンジンをUI付きのもっといいものに書き換えたんだ。これ、昔だったら作るのに数日かかってたと思うし、正直一人（自分）にはオーバースペックだと思ってやらなかったかも。

└

電気代をKWH商品として追跡してるんだけど、実際には…ほぼ役に立ってないよ :D。

└

これについて興味があるんだ。データ（例えば財務）を管理するための個人ソフトウェアをLLMを使って作ろうと思ったことがあるけど、そのデータをLLMに提供するのがちょっと不安なんだ。これがあなたのやってることなの？考えてみると、ローカルモデルでデータを「匿名化」できるかもしれないな…

最近PTAを始めたんだけど、最初のハードルが高いと思う。まずダブルエントリー簿記を学ばないといけないし（まだなら）、それからledger-cli、hledger、beancountのどれを選ぶか決めないといけないんだ。どれも微妙な違いがあって、後で切り替えられる可能性もあるけど。結局、どのツールがその時の自分にとって一番理解しやすいドキュメントやコミュニティを持っているかが大事だね。それからインポートのワークフローもあるし、どの「アカウント」から始めるべきか、どれだけの履歴を取り込むか、自動インポーターをどう設定するかとか。hledgerはDSLがあるし、beancountはPythonを使ってる。どちらにしても、OPが言うように、手動でテキストを編集する時間がかなりかかるよね。で、最後にどうするの？今、予算を作れるの？これで税金の計算もできるの？もっと財務的に責任感が持てるようになるの？これを配偶者にどう説明するの？年金は商品みたいなもので、単価がわからないし、ユニットも売ってないけど、仮想的なPnLって何だろう？四半期ごとのPDFしかないのに！？愚痴っぽく聞こえるかもしれないけど、こういう質問に対する答えを知らない（あるいは存在すら知らない）ことに気づくのがPTAの本当のメリットだと思う。毎年、異なる年金投資のミックスを希望するか、車の保険を変えたいか聞かれるし、インターネットプランが良いのか、新しい仕事のオファーの総報酬が本当に良いのか気になることもある。自分は「退職」に向けて「順調」なのか、新しい屋根を買うためにはどれくらいかかるのか、インフレに追いついているのか、今年は贈り物にお金を使いすぎたのか？こういう質問の答えを知らなくても大丈夫っていうのは大きな特権だよね。「間違った」答えを出しても大したことないし。でも、毎セントを数えることで自分の経済の細かいルーチンに慣れるのは、やりがいがあって、啓発的で、力を与えてくれるよ。たとえそれが時には面倒で壊れやすいとしても。beancountを再挑戦してみるかもしれない。OPのインポーターは、私のhledgerスクリプトに比べてかなり頑丈そうだし。

└

確かに、学習曲線が大きいと思う。ダブルエントリー簿記はそんなに難しくないけど、やってみるとそう言えるのも分かる。2018年くらいからPTAをやってて、途中で学んだことやたくさんの失敗があるよ。私にとっての主な利点は、システムが財務の全体像を提供してくれること。商業サービスは特定のスライス（例えば、UK/ヨーロッパのオープンバンキングで現在の口座を確認する）しか見せてくれないけど、アメリカではmint.comが似たようなことをやってたけど、こっちには来なかったし、今も存在するかはわからない。たぶんそれで十分な人も多いだろうけど、私は全てを見たいんだ。投資、負債、資産などね。商業的なオファーにはそれがない。なぜなら、すごく複雑でニッチだから。例えば、オープンバンキングのプロバイダーは年金の状況を教えてくれないし。取引の出所を把握するのもいいよね。例えば、仕事から株をもらって、それを売ってお金が銀行口座に入ると、入金は純利益だけど、その前に税金を払ったかどうかはわからない。PTAはその取引が銀行に入るまでの全てのイベントの流れを追跡してくれるから、もっと全体像が見えるんだ。ほとんどの人にはオーバーキルかもしれないけどね。

└

数学者でプログラマーであるだけでなく、金融と銀行の学位も持ってるから、早いうちにダブルエントリー会計を学んだんだ。数学者として、この非常に巧妙で一般的で抽象的なシステムの美しさを評価しているよ。オタクとしては、10年近くEmacsでledger-cliを使ってるし、その前はGnucashを使ってた。学習曲線について言えば、そんなに難しくないよ。ちょっと宣伝になるけど、個人財務とledger-cliを使った基本についての教科書（実際には教科書のようなものだけど）を書いたんだ。https://leanpub.com/personal-accounting-in-ledger/

└

ビジネスをやってるなら、ダブルエントリー簿記は必須だよね。でも、個人の財務管理にはちょっと過剰かも。完璧なツールはExcelとか、似たようなスプレッドシートだと思う。自分にとって大事なことを追跡すればいいんだ。私はだいたい週に一回、スプレッドシートに数字を追加してるよ。

OPの本に+1。これがBeancount / プレーンテキスト会計を理解するための初心者向けガイドの中で一番良いと思う。私もずっとダブルエントリー会計について混乱してたけど、マーチン・クレップマンの「コンピュータサイエンティストのための会計」という記事を読んでからは理解できた。グラフ理論の観点からダブルエントリー会計を驚くほどわかりやすく説明してくれてるんだ。私はグラフ理論がそんなに好きじゃないし、自分を得意だとも思ってないけど、クレップマンの説明はすごく効果的だったよ。[0] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...

個人の財務を追跡しようと何度も試みたけど、やっとうまくいったのは、PTAの全体をプロジェクトのコンパイルのように扱うというアイデアを発見してからだよ（https://github.com/adept/full-fledged-hledger）。- すべては依存関係を追跡できるビルドシステムで管理されている - 金融機関からの入力はそのままリポジトリに保持される - それらの入力はスクリプトによってPTAインポートエンジンが読み取れる.csvファイルに変換される - .csvの行をPTAエントリーに変換するルールファイルがある - 生成されたファイルは年ごとのPTAジャーナルからインクルードされる（ここに手動の取引も追加できる） このアプローチの利点は、このパイプラインのどの部分でも変更できて、変更した部分だけを再生成できることだよ。- .csvに変換するプログラムを改善すれば、全体のリポジトリで生データがすぐに良くなる - インポートルールを追加/カスタマイズすれば、過去のデータにもすぐに適用される そして、このアプローチでは、小さく始められる（例えば、主要な銀行からの1か月分のデータ）し、段階的に改善していける。もっと歴史的なデータを追加したり、データソースを増やしたり（銀行の明細書だけでなく、アイテム化されたAmazonの注文やPayPalの領収書なども）できるんだ。

└

住宅ローンの支払いはいつも混乱してたけど、そのリンクには良い説明があるね。自分のシステムでそのコードベースを使ったことある？それとも原則だけ？Haskellは知らないから、どれくらい修正できるか分からないんだ。

これめっちゃクールで便利そうなんだけど、技術に詳しくないパートナーとどうやって使うの？個人の財務管理は一緒にやってるから、彼女にわかりやすいきれいなUIが大事なんだよね。beancountでそれを実現する方法ってあるのかな？今はYNABを使ってるけど、ほとんどは良いけど時々不安定で限界があるんだよね。

僕のあまりこだわらない個人財務の流れは、スプレッドシートを使ってる。月に一回手で更新してて、もう20年くらいやってるよ。5分くらいで終わるし、気に入ってるカテゴリだけを追跡してる。時間と共に少し変わったけど、電気、暖房、水道、ISP、家賃/ローン、保険、貯金とかはずっと含まれてる。食費やレストラン代は「生活する上での費用」だと思って追跡してない。主な目標は、支出が時間と共にどう変わるかを追跡することと、来年の請求書を払うためにどれだけお金を準備する必要があるかを把握すること。残ったお金は使えるお金。ちゃんと使ってるよ。

└

僕もあまりこだわらない方だけど、プロプライエタリなものを使ったり、財務を追跡するためにお金を払いたくないんだ（「お金使いすぎだよ、助けてあげるからもっとお金使ってよ」ってのはただの馬鹿げた話）。銀行口座やクレジットカードのCSVエクスポートで全部やってる。毎月エクスポートをディレクトリに放り込んで、Pythonスクリプト（新しいバージョンはほとんどLLMが書いたもの）で分析して、カテゴリや商人ごとに分けてる（そうすれば、特定の商人に対して意図せずに多く使っているか、商人が気づかないうちに値上げしているかがわかる）。それに、厳密に定期的な支出用のクレジットカードを一枚持ってて、非定期的な支出は絶対に使わないようにしてる。そのおかげで、そのクレジットカードの請求書で月ごとの変化が簡単にわかる。もしComcrapがある月に10ドル多く請求してきたら、すぐに厄介なメッセージを送ることになるね。

└

僕も同じことをしてるけど、もう少し少なく追跡してる。毎月、全アカウントの残高、給与/収入、支払った税金、投資口座への振込、家賃/ローン、健康保険を追跡してる。これで投資のパフォーマンス、財務状況、必要な生活費を把握するのに十分だと思ってる。ほとんどの他の支出は「生きるための費用」だから、もっと細かく追跡する必要はないかな。

└

今はスプレッドシートを使ってるよ。前はプレーンテキストファイルでやってたし、Emacsのorg-modeで一年間やったこともある。でも、結婚した年にスプレッドシートを始めたんだ。そうすれば、配偶者と一緒に見られるからね。君よりもずっと少ないカテゴリーを追跡してるけど、代わりに大きな支出も金額で追ってるよ。今は100ドル以上のものだけ記録してる。だから、豪華な100ドル以上のディナーは記録するけど、普通の30ドルのディナーは記録しないって感じ。

このスレッドでは「プレーンテキスト」と「ダブルエントリー」を混同してる人が多いね。beancountは両方できるけど、どちらか一方でも両方でも使えるよ。特に、プレーンテキストの会計をするためにダブルエントリーを学ぶ必要はない。もちろん、ダブルエントリー会計は知識を整理するための素晴らしいツールだから学ぶべきだけど。プレーンテキストが会計にとって有益かどうかは、僕の中ではあまりはっきりしない。プレーンテキストは「サービス」や「クラウド」、そして「ロックイン」に対する反発だと思うけど、ちょっと誤解してると思う。誰かにロックインされるのが心配なら、あなたのコンピュータだけで動くダブルエントリー会計をするのも十分考えられるし、あなたがコントロールできるソフトウェア（つまり、フリーソフト）で操作できるよ。まとめると、僕の意見はこんな感じ： - 会計：重要 - ダブルエントリー：重要 - クラウドとベンダーロックインを避ける：重要 - プロプライエタリファイル形式を避ける：重要 - プレーンテキスト：重要じゃない（僕はGnuCashを使ってる。欠点はあるけど、上記の考えに賛成なら素晴らしいよ）

└

会計には自動化が必要だと思う。手作業はミスが起こりやすいし、正確さは財務にとって最優先の要件だからね。

数十年前にQuickenを使い始めたんだ。新しいバージョンが出たときに古いバージョンのサポートが終了して、全データを再入力しなきゃいけなかった。それでGNU Cashに切り替えて、また全部再入力した。GNU Cashでも移行問題があったし、最終的にPTAを見つけた。パフォーマンスの問題があるかもしれないからhledgerを選んだ。ダブルエントリー簿記を学んだけど、正直言って結構簡単だよ。PDF形式で送られてくる投資明細書（ブローカーは取引ダウンロードをサポートしてない）や給与明細（給与会社も取引ダウンロードをしない）をインポートするためにPythonスクリプトを書いてるし、銀行やクレジットカードの明細書のCSVインポートもしてるから、大体の取引を自動でカテゴリ分けできる。実はずっと前から求めてたものがこれだったんだ、ただ気づかなかっただけ。毎月アカウントを更新するのに約1時間かかる。投資レポート、予算レポート、税金のまとめも作成してる。必要なものは全部揃ってる、ただ投資のACBを追跡するのはできてない（簡単なスプレッドシートの方が楽だから）。今年の退職に向けて必要なものは全部揃ってる。そしてプレーンテキストだから、データ形式が変わっても全部失うことはないし、gitを使って変更を追跡したり、リカバリーしたり、オフサイトバックアップもできる。欠点は、携帯電話では動かないし、自分が何をしてるかを理解しておく必要があることかな。でも、どれだけお金があって、どこに使ってるかが本当に重要なら、これがその仕事に最適なツールだと思う。

Beancountが何か知らない人のために（彼のサイトのリンクは404だし）。これはお金を扱うためのPythonライブラリだよ。 https://github.com/beancount/beancount/blob/master/README.rs...

PTAに移行したばかりだけど、めっちゃスムーズだよ。やっと金融システムから自分のデータを解放できた。データフィードを得るためにSimpleFINを調べてみて。あと、LLMsやbrowsermcpを使って、すべての銀行から取引明細をダウンロードしたよ。やっと自分でコントロールできるのがすごく嬉しい。 PTAをもっとブロックチェーンの台帳みたいに拡張したいと思ってて、すべての取引に署名して台帳を分散化する感じ。どうやって実現するかまだ考え中だけど、基本的にはKERIベースになると思う。