## はじめに
これまで長年にわたりMoneyForwardのプレミアムプランに課金して家計簿をつけてきたが、
日々運用していく中で看過できない課題が積み重なり、beancountへの移行を検討するに至った。
本記事ではその背景と、Plain Text Accounting (PTA) という考え方、そして複式簿記の入門までの過程をまとめる。
## MoneyForwardからの移行を考えた理由
MoneyForwardは口座を連携するだけでデータを収集し、家計簿として必要な集計まで自動で行ってくれる非常に利便性の高いサービスである。 一方、MoneyForwardの利用には以前から複数の課題感を感じていた。
最大の魅力である口座連携も、実態としては頻繁に再連携や手動更新が発生し、完全な自動化を実現できていたとは言いがたい。 さらに悪いことに自動化に依存しているがゆえに次第に内容を確認する習慣が失われ、 気がつけば家計簿そのものをつける意識まで薄れてしまっていた。
データの品質面でも課題があった。 MoneyForwardのカテゴリ分類は決して賢いとは言えず、放置していれば取り込んだデータはどんどん汚染されていく。 カテゴリの変更はUIから一件ずつ修正する必要があり、操作のたびにラグが発生して体験も芳しくない。 半端な振替も大量に発生しており気付いたときには手持ちの現金が100万円を超えていた。
そして最も本質的な問題は、極めてプライベートな情報であるにもかかわらず、 データが完全に自分のコントロール下にないという点にあった。
こうした懸念を抱えながらも惰性で利用を続けていたところ、 2026年5月1日にGitHubの認証情報漏えいに起因するインシデントが公表された。
これが決定打となり、代替となるソフトウェアを本腰を入れて探すこととなった。
## 代替候補の比較
日本にはMoneyForward以外にもMoneyTreeやZaimといった個人向けの家計管理アプリが存在する。 しかしこれらに乗り換えたところで結局は別の会社に命運を託すだけで本質的な解決にはならないため、 OSSのソフトウェアを中心に検討を進めることとし、Firefly III や GnuCash が当初の候補として上がった。
これらを調べる過程で Plain Text Accounting (PTA) と呼ばれる手法を実践するツール群に出会い、 合わせて複式簿記そのものについても学ぶこととなった。 複式簿記という観点から各候補を改めて見ると、 Firefly III は内部的には複式簿記風の構造を持ちつつも純粋な複式簿記とは言いがたく、 GnuCash は老舗の本格派ではあるものの家計簿用途として運用するには堅すぎる印象があった。 これに対し PTA は純粋な複式簿記を素直に扱えるうえ、データをプレーンテキストとして手元で管理できる点も大きな魅力で、 最終的にPTAに落ち着くこととなった。
## Plain Text Accountingという考え方
PTAは取引データをデータベースではなくプレーンテキストとして記述し、 gitなどの汎用ツールで自由にバージョン管理・差分確認・スクリプト処理できるようにするという思想である。 データが常に手元のファイルに収まり、EmacsやVimなどのエディタでもCLIでも自在に扱えるため、 特定のサービスやデータベースエンジンに依存することなく、必要に応じてスクリプトで自由に加工・変換できる。 PTAそのものについては以下のページに詳しい。
PTAの世界では元祖であるC++実装のledger、その移植であるHaskell実装のhledger、
そしてそれらとは独立にPythonで開発されたbeancountが代表的なツールとして存在している。
私自身はPythonに馴染みがあり、トランザクションのimporterや周辺ツールを自分で書きやすそうであること、
可視化やクエリ言語といった周辺エコシステムが充実していることから、beancountを選択した。
ただし、どのツールを選ぶかは好みの問題でありそれぞれ調べて選べばよい。 大切なのは個々のツールの使い方ではなく、PTAという考え方そのものである。
なお余談ではあるが、beancountをGoogleで検索すると beancount.io という非常に商魂逞しいウェブサイトがヒットする。
しかしこれはbeancountの作者とはなんの関係もない第三者のビジネスであり、混同しないよう注意されたい。
## 複式簿記の入門
beancountを始めるには複式簿記という考え方が前提となるが、私は会計の知識が皆無に等しい状態であった。 簿記というと日商簿記の検定が有名で、2/3級用の丸暗記参考書を買わなければならないのかと身構えるほど明るくなかったため、 たまたま「教養としての「会計」入門」という書籍にたどり着けたのは運が良かった。
会計とは何かという議論そのものは本記事の趣旨から外れるため割愛するが、 複式簿記によって資産の構成や損益の流れがどのように可視化されるのかが丁寧に解説されており、入門書として有用であった。 本書で全体像を掴んだうえで、続けてbeancount公式ドキュメントの該当章を読むことで、 beancountの文脈での複式簿記の扱われ方を具体的に把握できた。
本書でなくとも、財務会計の基礎を押さえてからbeancountやhledgerのドキュメントへ進む流れが入門者には近道だろう。
ここからは実際の記録に必要となる、複式簿記の基本ルールを押さえておく。
複式簿記とは一つの取引を二つ以上の勘定科目に同時に記録することで、 資産・負債・純資産・収益・費用が常に整合するように帳簿をつける手法である。 家計に当てはめると、これら5つの勘定は次のように対応する。
- 資産 (Assets): 現金、銀行預金、株式など、自分が持っているもの
- 負債 (Liabilities): クレジットカードの未払い金、住宅ローンなど、将来支払うべきもの
- 純資産 (Equity): 資産から負債を差し引いた、自分の正味の取り分
- 収益 (Income): 給与、利息、配当など、外部から入ってくるお金
- 費用 (Expenses): 食費、家賃、光熱費など、外部に出ていくお金
beancountでは資産・費用は正残高で、負債・収益・純資産は負残高で扱われる。 こうすることで「すべての勘定の残高を合計すると常にゼロになる」というシンプルな性質が成り立ち、 帳簿の整合性を機械的に検証できるようになる。 Incomeがマイナスとして扱われる点に最初引っかかりを感じたのだが、 公式ドキュメントによる「自分の労働力というリソースを外部に差し出し、その対価として資産を得る」という比喩で納得した。
## beancountでの記録
ここまでで複式簿記の枠組みを押さえたので、実際の取引をbeancountでどう記録するかを見ていく。 家計でよくある取引は、+で記録する勘定と-で記録する勘定の組として次のように整理できる。
| 取引 | +で記録する側 | -で記録する側 |
|---|---|---|
| 給与振込 | Assets:Bank (資産) Expenses:Tax (費用) | Income:Salary (収益) |
| ATMで現金引き出し | Assets:Cash (資産) | Assets:Bank (資産) |
| クレジットカードで買い物 | Expenses:Food (費用) | Liabilities:CreditCard (負債) |
| カード引き落とし | Liabilities:CreditCard (負債) | Assets:Bank (資産) |
給与振込の行に示したように、1つの取引で+側や-側に複数の勘定が並ぶこともある。 複式簿記では合計が0になりさえすれば、勘定を何個並べてもかまわない。 たとえば1,500円の買い物に対し500円分のポイントを使い残額をクレジットカードで支払った場合、次のように1つの取引としてまとめて記録できる。
2026-05-05 * "スーパー" "買い物"
Expenses:Food 1500 JPY
Assets:Points -500 JPY
Liabilities:CreditCard -1000 JPYbeancountではこのように1行目に日付と取引名を書き、2行目以降に影響を受ける勘定とその金額を符号付きで列挙する。 1つの取引内に書かれた金額の合計が常に0になるよう書くのが、複式簿記の基本ルールである。
そしてこのように複数の勘定が同時に動く取引を1単位としてそのまま表現できる点は複式簿記の強みであり、 1つの取引に1つのカテゴリしか紐付けられない一般的な家計簿アプリでは難しい部分でもある。
より詳細な例は fava の公式デモを見るのが良い。
journal タブにここで例示したようなエントリーが多数並び、 それらを可視化したものが Income Statement (損益計算書) や Balance Sheet (貸借対照表)のタブに並ぶ。
## LLMを活用した移行戦略
beancountの枠組みが分かっても、これまでMoneyForwardに蓄積してきた数年分のデータをどう移すかは別の問題である。 ここで助けとなったのが、プレーンテキストを扱うという性質上LLMとの相性が極めて良いことであった。 各金融機関から取得できる範囲でCSVを落とし、 Claude Codeに「beancountのベストプラクティスにしたがって記録してほしい」と依頼する。 これだけでCSVのimporterが作成され、過去データの取り込みが進む。 それでも足りない期間はMoneyForwardからエクスポートしてきたCSVをフォールバックとして利用する。
データに不整合があるとbeancountのCLIによる整合性チェックが通らないため、 LLMに任せた場合でも誤りが残りにくく、試行錯誤のループも回しやすい。
現時点ではまだ移行は完了しておらず、MoneyForwardのアカウントもバックアップとして残しているが、 beancount側に必要なデータが揃い整合性が取れた段階で完全に移行する予定である。
## 運用方針と今後の展望
日常の運用としては、毎月各金融機関にログインしてCSVをダウンロードし、beancountに取り込むサイクルを想定している。 毎回ログインしてCSVを落とすのは確かに手間ではあるが、 MoneyForwardを使っていても結局は連携の再登録やカテゴリの修正が必要になる以上、大差ないと考えている。 Redditなどでも月次の運用は30分程度で済むという声があり、 月に一度のルーティンワークとして割り切るほうがむしろ健全であると考えるようになった。
データはプライベートなgitサーバー（私はミニPC上にforgejoを建てている）に、月単位で締めてコミットしていく形を想定している。
集計や可視化については、SQLライクなクエリ言語である Beancount Query Language (BQL) や、
可視化ツールの fava が用意されており、自分のデータを好きな形で扱える。
PTAはトランザクションを含むあらゆる情報をテキストとして表現する手法であるため、 仮に将来的に別のツールへ乗り換えることになっても、 スクリプトで変換すればよいのだ。
## まとめ
本記事ではMoneyForwardからbeancountへ移行した背景と、
Plain Text Accountingという考え方、そして複式簿記の入門までの過程について紹介した。
1つの取引を複数の勘定にまたがって素直に表現できる複式簿記の素朴さや、 プレーンテキストゆえにLLMやスクリプトと組み合わせやすい運用上の柔軟さは、 従来の家計簿アプリでは得られなかった価値である。 そして何より、自分の資産の管理を手元のテキストとしてコントロールできる安心感は思っていた以上に大きい。