10年間の個人財務をプレーンテキストファイルで管理した記録

 (sgoel.dev)
2 ポイント 投稿者 GN⁺ 2026-01-03 | 1件のコメント | WhatsAppで共有
  • Beancount を使って10年間にわたり個人財務を プレーンテキストファイル で記録し、約45,000行のデータと10,000件の取引を管理
  • 毎月30〜45分をかけて 銀行明細のCSVファイルを取り込み、手動・自動で整理 し、年ごとのファイルに分けて可読性を維持
  • ドイツの銀行向けに Pythonベースの importer ライブラリ を自作して Beancount と連携し、一部は現在も保守中
  • Beancount 初心者の難しさを実感し、初心者向け入門書 を執筆。コミュニティでも好意的に評価された
  • すべてのデータが 自分のローカル端末とGitリポジトリ に保存されており、特定のアプリやサービスより 継続性とコントロール性 が高い

10年間の Beancount 台帳構造

  • 2016年から Beancount で財務データを管理しており、合計 45,011行の項目 が16個の .beancount ファイルに保存されている
    • main.beancount ファイルを中心に、年ごとのファイルを include 方式で接続
    • 取引総数は約 9,895件、その中の posting（仕訳） は19,743件
  • 合計 1,086個の勘定（account） が存在するが、これは実際の銀行口座ではなく 仮想的な分類勘定 で構成されている
    • 例: スーパーマーケット支出、収入、サブスクリプションサービスなど、細かな項目ごとに勘定を作成可能
  • 507個のPDF文書 が取引に添付されており、税務申告時に関連する領収書を簡単に確認できる
  • 年ごとの posting 数は2016年の715件から2023年の2,651件へ増加し、2023年が最も活発な年として記録されている

月次管理手順

  • 毎月およそ 30〜45分 を使って銀行明細を CSV でダウンロードし、Beancount に取り込む
    • CSV は PDF よりパースしやすいため使用
    • Python ベースの importer が CSV データを Beancount 形式に変換
  • 変換した取引を .beancount ファイルに追加した後、複式簿記の原則に従って残高が0になるよう調整
    • 一部は自動分類、一部は手動調整
  • 新年が始まると前年の取引を <year>.beancount ファイルへ移し、main.beancount に含めて管理
  • すべての取引履歴が 1つのディレクトリ内のテキストファイル として整理されている

ドイツの銀行向け Beancount Importer の開発

  • Beancount は標準では銀行明細の形式を認識しないため、importer クラス を通じた変換が必要
  • ドイツの銀行口座を使っているため、複数の importer を自ら開発
  • 最初の3つのライブラリは現在も 活発に保守・利用 されている

ユーザーから著者へ

  • Beancount のドキュメントは膨大だが、初心者にとっては参入障壁が高い
  • 試行錯誤の末に身につけた経験をもとに 入門書 を執筆
    • personalfinancespython.com で公開
    • Beancount 公式ドキュメントの external contributions ページで言及
    • 読者レビューでも 好意的な反応 を得ている

まとめ

  • すべての財務データが Gitでバージョン管理されたローカルのテキストファイル として保存されている
  • データは 自分の端末 に存在し、特定のアプリやサービスに依存しない
  • Beancount エコシステムのツールを活用して自由に分析できる
  • このような plaintext accounting の方式は、どんなアプリよりも長く続けられる 強力な財務管理の形 である

関連記事

1件のコメント

 
GN⁺ 2026-01-03
Hacker Newsの意見

  • OPの本に全面的に同意する。これまで見た中で、Beancount / plaintext accounting を理解するための最高の入門書だった。
    自分も長い間、複式簿記をきちんと理解できていなかったが、Martin Kleppmanの"Accounting for Computer Scientists"を読んでようやく腑に落ちた。グラフ理論で説明するやり方が驚くほど直感的だった。

    • 「Quickenは単式会計システムなので、お金が突然現れたり消えたりしうる。複式簿記では、ある口座にお金を入れるには必ず別の口座から引かなければならない」という要約は本当に核心を突いている。quicken2beancountで見かけた一文だ。
    • 複式簿記が難しいと感じたというのは興味深い。実際には、すべての取引が2つの勘定を同時に動かし、借方と貸方の合計が等しくなければならないというシンプルな原理だ。グラフ理論がそれをさらに単純にするというのは、あまり想像がつかない。
    • 言及してくれてありがとう、Michael!

  • 以前はQuickenを使っていたが、バージョンが変わるたびにデータを再入力しなければならず、最終的にGNU Cashへ移行した。ただ、移行の問題もあった。
    その後でplaintext accounting(PTA) を知り、hledgerを選んだ（Beancountは性能面の問題がありそうだったので）。複式簿記を学んでみると、思ったより単純だった。
    PDFで届く投資明細書や給与明細をPythonスクリプトで解析し、銀行やカードのCSVを自動分類するようにして、ほとんどを自動化した。
    毎月1時間ほどかけるだけで、投資レポート、予算、税金のサマリーを作れている。
    plain textなのでフォーマットが変わってもデータは安全だし、gitでバージョン管理もできる。
    欠点はモバイルでは使えないことと、多少の技術知識が必要なことだ。しかし、お金の流れが重要な人にとってはこれが正解だ。

    • 「再入力しなければならなかった」というのがどういう意味なのか気になる。自分は1992年からQuickenを使っているが、バージョン変更でデータを再入力したことはない。
    • 自分もQuickenから抜け出したいが、Intuit依存があまりにも強い。2000年以降のすべての取引が独自フォーマットに縛られている。
      ただ、Quickenの自動同期機能はいまだに最高なので代替が難しい。27口座を毎日確認して詐欺やミスを見つけているが、そのたびにCSVを落として手動処理するのは悪夢だ。
      しかも最近は銀行がOFXを閉じて、Intuitを中間ハブとして使う流れになっており、脱出はますます難しくなっている。

  • 個人財務をプロジェクトのビルドシステムのように管理するというアイデアは、full-fledged-hledgerで学んだ。
    金融機関から受け取った元データをそのまま保存し、スクリプトでCSVに変換してから、ルールファイルでPTA項目にマッピングする。
    こうすると、変換ロジックや分類ルールを変えれば、過去データ全体が自動で更新される。
    最初は1か月分のデータから始めて徐々に広げていける。たとえば、Amazonの注文履歴やPaypalの領収書まで含められる。

    • 「PTAってなんで保護者会(Parent Teacher Association)と関係あるんだ？」という冗談を言っていた。
    • 住宅ローンの会計処理がややこしく感じていたが、そのリンクは良い説明を提供している。実際にそのコードベースを使ったのか、それとも原理だけ参考にしたのか気になる。Haskellを知らないので、どれくらい修正が必要なのかもわからない。

  • 自分はここ数年Beancountを使っている。
    今年からはOPのように年ごとのファイル構成に変えた。以前は200万行の単一ファイルだったが、Emacsプラグインが遅くなっていた。
    このやり方の利点は、すべてを追跡できることだ。投資、年金、RSU、銀行口座など。さらには電力使用量(kWh) までモデル化できる。
    最近はLLMを活用した自動化ツールをたくさん作っている。たとえば、ClaudeでトランザクションルールエンジンをUI付きアプリにリファクタリングした。以前なら数日かかっていたような作業だ。

    • 自分も電気料金をkWh単位で追跡してみたが、正直あまり役に立たなかった 😂
    • 自分もLLMで個人財務ツールを作りたいが、機微なデータを渡すことが心配だ。匿名化したローカルモデルで処理する方がよさそうだ。

  • 多くの人がplain textと複式簿記を混同しているように思う。
    Beancountは両方に対応しているが、複式簿記を知らなくてもplain text会計はできる。
    ただし、複式簿記は知識を体系化するための優れた道具なので、学ぶことを勧める。
    plain text自体の有用性については少し懐疑的だ。クラウド依存やベンダーロックインを避けようとする反動のようにも見えるが、ローカルで自由ソフトウェアの複式簿記を使えば十分だ。
    自分の結論はこうだ。

    • 会計: 重要
    • 複式簿記: 重要
    • クラウド/ロックイン回避: 重要
    • 独自フォーマット回避: 重要
    • plain text: 重要ではない
      自分はGnuCashを使っており、完璧ではないがこの哲学にはよく合っている。
    • 会計には自動化が必須だと思う。手作業はミスが多く、正確性は最優先(P0)要件だ。
    • 自分もGnuCashを愛憎入り混じった気持ちで使っている。UIがあまりにも古い。エンジンをライブラリとして分離して、いろいろなUIで使えるようになるといいのに。

  • 最近PTAを始めたが、参入障壁はかなり高い。
    まず複式簿記を学び、ledger-cli / hledger / beancount のどれかを選ばなければならない。違いは微妙で、コミュニティやドキュメントの質が決め手になる。
    その後は、どの口座から取り込むか、どこまで過去データを含めるか、自動インポーターをどう設定するかを考える必要がある。
    hledgerはDSLを、BeancountはPythonを使う。時間の大半は手動編集に費やされる。
    さらにその先には、予算、税金、配偶者との共有など新たな問いが出てくる。
    しかし、そうした問いを自分で認識できるようになること自体がPTAの本当の価値だと感じる。
    毎年、年金、保険、インターネット料金、新しい仕事のオファーなど、多くの財務上の意思決定をするとき、自分の経済状況を細かく理解していることは大きな力になる。

    • 自分は数学者でありプログラマーでもあり、さらに金融専攻だったので、複式簿記を早くから学んだ。その抽象的で優雅なシステムは本当に美しいと感じる。
      ledger-cliとEmacsを10年間使っていて、以前はGnuCashも使っていた。
      入門向けに自分が書いた複式簿記の教材もある。
    • 複式簿記は慣れれば簡単だが、最初は学習曲線が急だ。
      2018年からPTAを使ってきて、試行錯誤の末に得た教訓が多い。
      商用サービスは一部の口座しか見せてくれないが、PTAなら財務全体の流れを完全に把握できる。
      たとえば、会社から受け取った株式が売却されて銀行口座に入金されるまでのすべての過程の出所(provenance) を追跡できる。
    • 個人財務に複式簿記はややオーバーキルだと思う。
      自分にはExcelスプレッドシートが完璧な道具だ。毎週、必要な数字だけ追加している。
    • 会計は簡単そうに見えるが、学ぶのは難しいという点には同意する。
      文献が矛盾していて難解で、会計士でさえ概念的に誤解していることがある。

  • 自分はシンプルなやり方で、20年間スプレッドシートで家計を管理している。
    毎月5分ほど更新し、電気・暖房・保険・貯蓄などの主要項目だけを追跡する。
    目的は支出傾向の把握と年間予算の確保で、余ったお金はそのまま使う。

    • 自分も似たようなものだ。月ごとに口座残高、収入、税金、投資振替、住居費、保険だけを記録している。これで財務状況を把握するには十分だ。
    • 自分も以前はplain textでやっていたが、結婚後は共同管理のためにスプレッドシートへ移行した。
      $100以上の支出だけ別途記録して、大きな出費だけ追跡している。
    • 自分も家計はスプレッドシートだが、他人の資金(信託など) を管理するときはhledgerを使う。複式簿記と照合が必要だからだ。
    • 自動化したいならTillerを勧める。銀行と連携して取引を自動でスプレッドシートに取り込み、予算テンプレートも提供してくれる。
    • 自分もそこまで執着するタイプではないが、独占的なサービスや有料アプリは好きではない。
      毎月銀行やカードのCSVをダウンロードしてPythonスクリプトで分析している。
      LLMが書いたコードで店舗ごとの支出傾向を分析し、あるカードには定期支払い専用で入れて変動を把握しやすくしている。

  • FavaというBeancount用のGUIフロントエンドを勧める。
    https://beancount.github.io/fava/
    口座全体を可視化でき、検索/クエリインターフェースとリアルタイム編集機能がとても便利だ。

  • このシステムは本当にすばらしく見えるが、非技術系のパートナーと一緒に家計を管理するときはどうすればいいのか気になる。
    私たちはYNABを使っていて、UIがきれいで共同作業もしやすい。Beancountでもそういうインターフェースを実現できるだろうか。

    • すぐ下のコメントでFavaが勧められている。
    • iPhoneを使っているならMoneyStatsアプリを勧める。見た目がきれいで設定も簡単なので、一緒に使いやすい。

  • 自分も以前PTAにハマって記録をつけ始めたが、複数の銀行から取引を手動でダウンロードするのが面倒すぎる。
    自動化が答えだと言われるが、実際にはどうしているのか気になる。PlaidのようなAPIを使うのか、WebスクレイパーやPDFパーサーを作るのか。
    結局、YNABに年$130払っている。配偶者の満足度も高く、すべてが自動でつながる。
    YNAB APIでデータをバックアップして、PTAを並行運用することもできそうだ。

    • 自分はPDF明細書パーサーを自作した。いくつかはPyMuPDFで直接書き、いくつかはClaudeにサンプル明細書を渡して生成させた。
      金融業界はこの点であまりにも遅れている。自動化は少しずつ増えているが、まだ労力に対する見返りが小さい。
    • 今朝、自分も設定を終えた。2週間ごとに18口座を点検するのが楽しいので、自分にとっては大きな負担ではない。
      以前はYNABを使っていたが、重複取引の問題が頻発して最終的にやめた。
      3回も初期化したが、それでもエラーが出続けたので、結局手動追跡に戻った。
      今ではPTAの方がはるかに安定していて、自分でコントロールしている感覚がある。