Beancountの核となる機能と哲学
Beancountは、プレーンテキストファイルを使用して取引を記録するオープンソースの複式簿記システムです。その核となる設計において、Beancountは台帳をシンプルで厳密な文法によって定義された_データセット_として扱います。すべての財務イベント(取引、口座開設、商品価格など)はテキストファイル内のディレクティブであり、Beancountはそれをエントリのインメモリデータベースに解析します。この設計により複式簿記の原則が強制されます:すべての取引は、借方と貸方が口座間でバランスしていなければなりません。その結果、極めて透明性が高く監査可能な台帳が実現し、バージョン管理、検査、クエリが容易になります。
哲学 – 正確性とミニマリズム: Beancountの設計はデータの整合性とシンプルさを優先します。作者であるMartin Blais氏は、Beancountはユーザーが間違いを犯すことを前提として「悲観的」であり、それゆえに追加のチェックと制約を課すと述べています。例えば、Beancountは追加されたことのない資産を削除することを許可しません(株式の保有高や現金残高のマイナスを防ぎます)。また、すべての口座が使用前に開設されていることを強制できます。Ledgerのような「仮想」または自動的にバランスするポスティングの概念は意図的に排除されており、完全にバランスしたエントリを強制する選択がなされています。Beancountは基本的な複式簿記が提供する以上の相互チェックにより、実質的に**正確性に「全力投球」**します。この慎重なアプローチは、「自分をあまり信用できない」と感じ、ソフトウェアにエラーを検出してもらいたいユーザーに訴求します。
最小限のオプション、最大限の一貫性: Ledgerの無数のコマンドラインオプションや調整項目とは対照的に、Beancountはミニマリズムを選択しています。グローバルオプションは非常に少なく、台帳ファイル外で取引の意味論を変更するものはありません。会計に影響するすべての設定(商品の原価基準方法やブッキングの仮定など)は、ファイル内のディレクティブまたはプラグインによって行われ、レポートの生成方法に関係なく、同じファイルを読み込めば常に同じ結果が得られることを保証します。この設計は、Ledgerの多くの調整項目とそれらの間の微妙な相互作用による複雑さを回避します。Beancountの哲学は、会計ツールは入力ファイルからレポートへの_安定した決定論的パイプライン_であるべきだというものです。台帳を順次プログラム処理できる順序付けられたディレクティブのストリームとして扱うことでこれを実現します。Ledgerが特別な構文として扱うもの(期首残高や価格ステートメントなど)も、Beancountのデータモデルでは第一級のディレクティブであり、システムを高度に拡張可能にしています。
プラグインとクエリ言語による拡張性: BeancountはPythonで実装されており、処理パイプラインにカスタムロジックを注入するフックを提供します。ユーザーは取引のストリームに作用するPythonプラグインを記述できます(例えば、カスタムルールの強制や自動エントリの生成)。これらのプラグインはファイル処理時に実行され、ソースを変更することなくBeancountの核となる機能を事実上拡張します。Beancountには、台帳をスライス&ダイスするための強力なクエリ言語(SQLに触発されたもの)も含まれています。bean-queryツールは解析された台帳をデータベースとして扱い、分析クエリを実行できます(例:カテゴリ別の支出合計、特定の支払先の全取引の抽出)。Beancount 3.xでは、このクエリ機能はスタンドアロンのbeanqueryパッケージに移されましたが、ユーザーの視点からはSQLライクなクエリによる柔軟なレポート作成が引き続き提供されています。
プレーンテキストとバージョン管理: プレーンテキスト会計ツールとして、Beancountは_ユーザーコントロール_とデータの長期性を重視します。台帳は単純な.beancountテキストファイルであり、任意のテキストエディタで編集できます。つまり、財務履歴全体が人間が読める形式で保存され、Gitや他のVCSに入れて経時変化を追跡できます。ユーザーは監査証跡(変更内容を説明するコミットメッセージ付き)を維持するために、Beancountファイルをバージョン管理下に置くことがよくあります。このアプローチは、会計データ、特に個人や小規模ビジネスの財務は、独自のデータベースに閉じ込めるのではなく、透明で「将来にわたって使用可能」であるべきというBeancountの哲学に合致します。Martin Blais氏自身の言葉によれば、Beancountはコミュニティのためにシンプルで、耐久性があり、無料で作られた「愛情のこもった仕事」です。2007年頃に初めて開発され、その設計を洗練させながらコアの哲学(ミニマリズムと正確性)を維持しつつ、大規模な書き直し(v1からv2へ、そして2024年のv3)を経て進化してきました。
Beancountエコシステムのツール、プラグイン、拡張機能
Beancountエコシステムは、コアの台帳機能を強化する豊富なツール、プラグイン、拡張機能を育んできました。これらは、データのインポート、台帳の編集、レポートの表示、特殊な会計機能の追加をカバーしています。以下に、Beancount世界の主要コンポーネントとアドオンの概要を示します:
データインポートユーティリティ(インポーター)
実用的な使用で最も重要なニーズの1つは、銀行、クレジットカード、その他の金融機関からの取引のインポートです。Beancountはこの目的のためのインポートフレームワークとコミュニティ貢献のインポートスクリプトを提供します。Beancount 2.xでは、組み込みモジュールbeancount.ingest(bean-extractやbean-identifyなどのコマンドを使用)がPythonでインポータープラグインを定義し、ダウンロードした明細に適用するために使用されました。Beancount 3.xでは、これはBeangulpと呼ばれる外部プロジェクトに置き換えられました。Beangulpはbeancount.ingestから進化した専用のインポーターフレームワークであり、現在はBeancount 3.0の取引インポートを自動化するための推奨方法です。外部ファイル(CSVやPDF明細など)を読み取り、Beancountエントリを出力するPythonスクリプトやコマンドラインツールの作成が可能です。この新しいアプローチはインポートロジックをBeancountコアから分離します。例えば、古いbean-extractコマンドはv3で削除され、代わりにインポートスクリプト自体がBeangulpのCLIインターフェースを介して取引を生成します。
さまざまな銀行やフォーマット用の既製インポーターが数十種類、コミュニティによって提供されています。中国のAlipayやWeChat Payから、さまざまなヨーロッパの銀行(Commerzbank、ING、ABN AMROなど)、ChaseやAmexなどの米国の銀行まで、世界中の機関向けのインポータースクリプトがあります。これらの多くは公開リポジトリ(多くの場合GitHub)またはbeancount-importersなどのパッケージに収集されています。例えば、Tarioch Beancount Toolsプロジェクト(tariochbctools)はスイスと英国の銀行向けのインポーターを提供し、暗号通貨取引のインポートも処理します。もう1つの例はLazy Beancountで、一般的なインポーター(Wise、Monzo、Revolut、IBKRなど)のセットをパッケージ化し、簡単な自動化のためのDockerベースのセットアップを提供します。どの銀行または金融サービスを使用していても、誰かがBeancountインポーターを書いている可能性が高いです。または、Beangulpのフレームワークを使用して独自のものを書くこともできます。Pythonの柔軟性により、インポーターはCSV/Excelファイルの解析、OFX/QIFのダウンロード、APIのスクレイピングまで処理し、標準化されたBeancount形式で取引を出力できます。
編集とエディタ統合
Beancountの台帳は単なるテキストであるため、ユーザーはお気に入りのテキストエディタやIDEを使用して維持することがよくあります。エコシステムはこの体験をよりスムーズにするためのエディタサポートプラグインを提供します。多くの人気エディタ向けに、構文ハイライト、勘定科目名の自動補完、リアルタイムのエラーチェックを追加する拡張機能があります:
- Emacs Beancount-Mode: Emacsメジャーモード(
beancount-mode)が.beancountファイルの編集に利用でき、構文の色付けやBeancountのチェッカーとの統合などの機能を提供します。bean-checkをバックグラウンドで実行して、台帳のエラー(バランスの取れていない取引など)を編集時にフラグ付けすることもできます。 - VS Code拡張機能: VSCode MarketplaceのBeancount拡張機能は、Visual Studio Codeユーザーに同様の利便性を提供します。構文ハイライト、金額の整列、勘定科目/支払先の自動補完、ファイル保存時のその場での残高チェックをサポートします。Favaと統合して、VSCode内からFavaウェブインターフェースを起動することもできます。
- Vim、Atom、その他のエディタ用のプラグインやモードも存在します。例えば、Beancount用のTree-sitter文法があり、最新のエディタでの構文ハイライトを強化し、Favaのウェブベースのエディタコンポーネントにも採用されました。要するに、どのような編集環境でも、コミュニティがBeancountファイルの編集を便利でエラーのないものにするプラグインを提供している可能性が高いです。
従来のエディタの外での迅速な取引入力には、Bean-addやモバイルアプリなどのツールもあります。_Bean-add_は、プロンプトまたはワンライナーで新しい取引を追加できるコマンドラインツールで、日付と勘定科目の提案を処理します。モバイルでは、Beancount Mobileと呼ばれるプロジェクトが外出先での取引入力のためのシンプルなインターフェースを提供します(例:スマートフォンからの現金購入の記録)。さらに、Beancount Telegram Botがメッセージングによる取引のキャプチャに存在します。取引詳細を含むメッセージを送信すると、ボットが台帳ファイルにフォーマットします。
ウェブフロントエンドと可視化ツール
(Fava) FavaのウェブインターフェースはBeancountのインタラクティブダッシュボードを提供し、勘定科目と残高のテーブルとともに、カテゴリ別支出のツリーマップなどの可視化を備えた損益計算書などのレポートを特集しています。
Beancountの代表的なフロントエンドはFavaで、モダンなウェブインターフェースです。Favaはローカルウェブアプリとして実行され、Beancountファイルを読み取り、ブラウザでリッチなインタラクティブ体験を生成します。貸借対照表、損益計算書、時系列の純資産、ポートフォリオ保有、パフォーマンスチャート、予算など、完全なレポートスイートをすぐに提供します。ユーザーはしばしば、他のプレーンテキスト会計ツールよりもBeancountを選ぶ大きな理由としてFavaを挙げます。単一のコマンド(fava ledger.beancount)で、テキストの代わりにグラフとテーブルで財務を閲覧できます。Favaは、勘定科目のドリルダウン、支払先やタグによる取引のフィルタリング、クエリエディタ(Beancountクエリを実行してブラウザで結果を表示)、統合されたウェブベースの台帳エディタなどの機能をサポートします。視覚的なインターフェースを好む人にとってプレーンテキスト会計を身近なものにする、非常に使いやすいツールです。
内部では、FavaはPython(バックエンドのFlask)とJavaScript(フロントエンドのSvelte)で書かれています。独自のリリースサイクルがあり、積極的にメンテナンスされています。特筆すべき点として、FavaはBeancountの開発に歩調を合わせてきました。例えば、Fava 1.30はBeancount v3をサポートし、内部で新しいbeanqueryとbeangulpパッケージを使用するように切り替えました。(古い台帳ではBeancount 2も引き続きサポートしています。)Favaの使いやすさへの注力には、ウェブエディタでの自動補完、ダークモードとレスポンシブチャートを備えた洗練されたUIなどの優れた機能が含まれます。Fava-GTKと呼ばれるスピンオフもあり、GNOME/Linuxユーザー向けにネイティブアプリの感覚を好む人向けにFavaをデスクトップアプリケーションにパッケージ化しています。
Fava以外にも、他の可視化および分析オプションがあります。Beancountデータはテーブルとしてエクスポートまたはクエリできるため、ユーザーはカスタム分析にJupyterノートブックやPandasなどのツールを活用することがよくあります。例えば、あるユーザーはクエリインターフェースを介してBeancountからデータをPandas DataFrameに引き出してカスタムレポートを作成する方法を説明しています。特定のレポート用のコミュニティ貢献スクリプトもあります(例:ポートフォリオ配分分析ツールや、支出対純資産のプロセス管理チャート)。しかし、ほとんどの人にとってFavaはコードを書く必要なしに十分以上のレポート機能を提供します。拡張機能もサポートしています。Favaに新しいレポートページやチャートを追加するPythonファイルをドロップできます。注目すべき拡張機能は、Fava内での封筒予算編成のためのfava-envelopeです。全体として、FavaはBeancountエコシステムの中心的な可視化ハブとして機能します。
コマンドラインユーティリティとスクリプト
BeancountにはさまざまなCLIツールが付属しています(特に古いv2ブランチでは、v3で一部が削除されました)。これらのツールは台帳ファイルを操作してチェックしたり、テキストまたはHTMLで特定のレポートを生成したりします:
- bean-check: ファイルの構文エラーや会計エラーをチェックするバリデータ。
bean-check myfile.beancountを実行すると、不均衡、欠落した勘定科目、その他の問題を警告し、ファイルにエラーがなければ何も出力しません。 - bean-format: ソースコードのコードフォーマッタのように、数値をきれいな列に整列させて台帳を整理するフォーマッタ。ファイルをクリーンで読みやすく保つのに役立ちます。
- bean-query: Beancountのクエリ言語を台帳に対して実行するインタラクティブシェルまたはバッチツール。カスタムのテーブル形式レポートの作成に使用できます(例:
bean-query myfile.beancount "SELECT account, sum(amount) WHERE ...")。 - bean-report: 定義済みのレポート(貸借対照表、損益計算書、試算表など)をコンソールまたはファイルに出力できる多用途のレポートジェネレータ(v2)。例えば、
bean-report file.beancount balancesは勘定科目残高を出力します。(実際には、これらのテキストレポートの多くはFavaのより見栄えの良いプレゼンテーションに取って代わられています。) - bean-web / bean-bake:
localhostでレポートを提供したり、静的HTMLファイルとして「ベーク」する古いウェブインターフェース。これらは主にFavaが普及する前に使用されていました。bean-webはbean-reportが生成できる同じレポートの基本的なウェブビューを提供しました。Beancount 3では、bean-webは削除されました(Favaが推奨されるウェブフロントエンドであり、優れた体験を提供するため)。 - bean-example: サンプルの台帳ファイルを生成するユーティリティ(初心者がBeancountエントリのテンプレートを見るのに役立ちます)。
- bean-doctor: 台帳や環境の問題を診断できるデバッグツール。
Beancount v3の時点で、これらのツールの多くはコアプロジェクトから移動されたことに注意してください。コアのBeancountパッケージは合理化され、クエリエンジンやインポーターなどのツールはメンテナンスを容易にするために別々のパッケージ(beanquery、beangulpなど)に分割されました。例えば、bean-queryの機能は現在、個別にインストールされるbeanqueryツールによって提供されています。ユーザーの視点からは、機能は引き続き利用可能です。モジュール化されただけです。Arch LinuxコミュニティはFavaを更新する際にこの変更に言及しました:FavaパッケージはBeancount 3.xをサポートするためにbeanqueryとbeangulpへの依存関係を追加しました。このモジュール化されたアプローチにより、コミュニティの他のメンバーがBeancountのリリースサイクルからより独立してこれらの補助ツールに貢献することも可能になります。
Beancountプラグインと拡張機能
Beancountエコシステムの際立った強みはプラグインシステムです。Beancountファイルにplugin "module.name"行を追加することで、台帳処理中に実行されるカスタムPythonロジックを組み込むことができます。コミュニティはBeancountの機能を拡張する多くのプラグインを作成してきました:
- データ品質とルール: 例としては、複数の勘定科目を含む方程式をアサートできる
beancount-balexpr(例:資産A + 資産B = 負債X)、口座を閉鎖する際にゼロになることを保証するために残高アサーションを自動挿入するbeancount-checkclosedがあります。日付順にファイル内の取引をソートするプラグイン(autobean.sorted)もあり、順序が狂ったエントリを検出します。 - 自動化:
beancount-asset-transferプラグインは、口座間の現物移管エントリを生成できます(原価基準を維持しながらブローカー間で株式を移すのに役立ちます)。もう1つのautobean.xcheckは、外部明細とBeancount台帳を相互チェックして不一致を検出します。 - 定期取引と予算: Akuukisによる**「repeat」または「interpolate」プラグインは、定期取引の定義や年間経費の月次分散を可能にします。予算編成には、
fava-envelope拡張機能(Favaを介して使用)がプレーンテキストで封筒予算編成方法論をサポートします。Frank DaviesによるMiniBudget**もあります。これはBeancountに触発された、個人または小規模ビジネスの予算編成に役立つ小さなスタンドアロンツールです。 - 税金とレポート: 一部のプラグインは税務会計を支援します。例えば、キャピタルゲインを短期と長期に自動分類するものがあります。別のプラグイン(Justus Pendletonによる
fincen_114)は、外国口座を持つ米国人納税者向けのFBARレポートを生成し、規制報告にBeancountデータを活用する方法を示しています。 - コミュニティプラグインリポジトリ: beancount-plugins(Dave Stephens著)などの厳選されたプラグインセットがあり、減価償却エントリなどに焦点を当てています。また、beancount-plugins-zack(Stefano Zacchiroli著)は、ディレクティブのソートなどのさまざまなヘルパーを含みます。
プラグインに加えて、Beancountを取り巻く他のユーティリティツールが特定のニーズに対応しています。例えば、beancount-blackはBlackコードフォーマッタに似た自動フォーマッタですが、Beancount台帳ファイル用です。前述のようにチャットで取引を追加するためのBeancount Bot(Telegram/Mattermost)や、macOSのAlfredワークフロー(ファイルに取引をすばやく追加)もあります。Pintoというツールは、インタラクティブ入力(強化されたbean-addのような)を備えた「スーパーチャージされた」CLIを提供します。他のシステムから移行する人のために、コンバーター(YNAB2Beancount、CSV2Beancount、GnuCash2Beancount、Ledger2Beancount)が存在し、他の場所からのデータの取り込みを支援します。
要約すると、Beancountエコシステムは非常に広範です。表1は、主要なツールと拡張機能とその役割を以下に示しています:
| ツール/拡張機能 | 説明 |
|---|---|
| Fava(ウェブインターフェース) | Beancountの帳簿を表示・編集するためのフル機能のウェブアプリ。インタラクティブなレポート(貸借対照表、損益など)、チャート、クエリ機能を提供。Beancountの主要な使いやすさ向上要因。 |
| Beangulp(インポートフレームワーク) | Beancount v3用のスタンドアロンインポーターフレームワーク。古いingestモジュールを置き換え。プラグインスクリプトを使用して銀行明細(CSV、PDFなど)をBeancountエントリに変換するのに役立ちます。 |
| Beanquery(クエリツール) | Beancountデータ用のスタンドアロンのSQLライクなクエリエンジン。v3のbean-queryを置き換え、おなじみのSELECT-FROM-WHERE構文を介して取引と残高の高度なクエリを可能にします。 |
| Bean-check / Bean-format | Beancountファイルを検証(エラーのチェック)し、一貫性のために自動フォーマットするコアCLIツール。正確でクリーンな台帳の維持に役立ちます。 |
| エディタプラグイン(Emacs、VSCode、Vimなど) | テキストエディタにBeancount構文サポートとリンティングを追加するプラグイン/モード。自動補完やライブエラーハイライトなどの機能で.beancountファイルの手動編集体験を向上させます。 |
| コミュニティインポーター | 米国、EU、アジアなどの銀行をカバーする銀行インポートスクリプトのコレクション(多くはGitHub上)。ユーザーが金融機関から取引をBeancountに自動的に取り込むことを可能にします。 |
| プラグイン(台帳拡張機能) | ルールの強制や機能の追加(例:経費分担、定期エントリ、カスタム残高アサーション)のためのオプションのファイル内プラグイン。カスタマイズのためにファイル処理中に実行されるPythonで書かれています。 |
| コンバーター(移行ツール) | GnuCashやLedger CLIなど、他の形式からBeancount形式にデータを変換するユーティリティ。ゼロから始めることなくBeancountを採用しやすくします。 |
Ledger、hledger、および類似システムとの比較
Beancountはプレーンテキスト複式簿記ツールのファミリーに属し、その中でもLedger CLI(John Wiegley氏のLedger)とhledgerが代表的です。これらのシステムはすべてプレーンテキスト台帳ファイルと複式簿記の核心的なアイデアを共有していますが、構文、哲学、エコシステムの成熟度が異なります。以下の表は、Beancount、Ledger、hledgerの主な違いを強調しています:
| 側面 | Beancount(Python) | Ledger CLI(C++) | hledger(Haskell) |
|---|---|---|---|
| 構文とファイル構造 | 正式な文法(BNF)によって定義された厳密で構造化された構文。取引には明示的なdate flag "Payee" "Narration"行と数量を持つポスティングがあり、すべての勘定科目は明示的に開設/定義されなければなりません。暗黙のポスティングはありません。すべての取引はバランスしていなければなりません。 | より自由形式の構文。支払先/説明は通常、日付と同じ行にあります。ある程度の暗黙のバランス調整を許可します(単一ポスティングの取引はデフォルトの勘定科目への2番目のポスティングを暗示できます)。勘定科目名は事前の宣言なしに使用できます。解析に影響を与える多くのコマンドラインオプション(年号の仮定、商品マージルールなど)を提供します。 | 主にLedgerの構文に従い、若干の違いがあります。hledgerはLedgerのコア機能をHaskellで再実装したもので、ジャーナル形式はLedgerと非常に似ています(いくつかの拡張とデフォルトでのより厳密な解析があります)。例えば、hledgerは日付と商品構文についてLedgerよりやや厳格ですが、Beancountほど厳格ではありません。 |
| 哲学 | 保守的で細心。 ユーザーエラーの検出とデータの整合性の維持を何よりも重視。デフォルトで多くのチェック(残高アサーション、ロット追跡)を課します。一貫性のための最小限の構成 – 「一つの方法」アプローチ。拡張性のためのライブラリとして設計され、プラグインを備えています(台帳データを処理対象のストリームとして扱い、カスタムPythonロジックを可能にします)。 | 楽観的で柔軟。 ユーザーが正しくデータを入力すると信頼し、デフォルトでは組み込みの制約が少ない。多数のオプションとコマンドフラグで動作を調整可能。レポート、プロットなどの機能が組み込まれたモノリシックなツールであり、台帳内のドメイン固有言語を使用して自動取引や定期取引を処理します。拡張性は通常、外部スクリプトや組み込みのクエリ言語を介して行われ、プラグインAPIではありません。 | 実用的で一貫性重視。 Ledgerのアプローチを予測可能な動作でより広いオーディエンスに届けることを目指します。hledgerはデフォルトでより一貫性を重視し(明示的な勘定科目なしのバランス調整の仮定なし)、Ledgerの最も寛容なモードよりも危険性が少ないです。Ledgerの機能のサブセットを持ち(Ledgerのよりエキゾチックなオプションの一部はサポートされていません)、独自の機能も追加しています(ウェブインターフェースとCSVインポートが組み込み)。安定性と正確性を重視しますが、Beancountのようなプラグインシステムはありません。 |
| 取引とバランス調整 | 厳密な複式簿記:すべての取引は総借方と総貸方が等しくなければなりません。バランスの取れていないエントリやプレースホルダーは許可されません(自動バランスする「仮想ポスティング」なし)。また、順序独立性を強制します:残高アサーションは日付スコープであるため、台帳はファイル順に依存せずに任意に日付でソートできます。商品の原価追跡は厳密です – 資産を売却する場合、ロットを指定するか、BeancountがFIFO/LIFOを強制して、追加していないものを削除できないようにします。 | 取引においてより寛容。Ledgerは「仮想」ポスティング(角括弧[ ]や括弧()を使用)を許可し、明示的なバランス調整勘定科目を必要としません – 予算編成や暗黙の純資産バランス調整の処理によく使用されます。Ledgerでは、不完全な取引(片側を省略)を入力し、Ledgerにバランス調整金額を推測させることが可能です。また、Ledgerはロットごとの資産削除を厳密に強制せず、特定のロットが追跡されていなくても集約された商品残高から喜んで差し引きます。これにより、平均原価法による会計が容易になりますが、特定のロットで保有以上の株式を売却するような間違いを止めてくれないことを意味します。 | 仮想ポスティングと暗黙のバランス調整を許可する点でLedgerに似ていますが、より一貫した動作です。hledgerはLedgerよりも厳格な解析ルールを強制しますが、Beancountよりは寛容です。 |
| 在庫と原価基準 | 精密なロット追跡。Beancountは商品ロットに原価情報を付加し(例:10株を各$100で購入)、在庫を減らす際には特定のロットの一致または定義された戦略の使用を要求します。設計上、キャピタルゲインと原価基準が正しく計算されることを保証します。平均原価法は、明示的にロジックを書かない限りデフォルトではありません。なぜなら、Beancountは正確性を保つために各ロットを個別に扱うからです。 | より抽象的な在庫。Ledgerは商品量をより流動的に扱い、デフォルトではすべてのロットがレポートで統合されます(合計数量のみ表示)。必要に応じてロットまたは平均原価でレポートするオプションを提供しますが、これはレポート上の関心事です。歴史的に、Ledgerは複数商品取引のバランス調整に原価情報を使用せず、微妙なキャピタルゲイン計算の誤りにつながる可能性がありました。ただし、Ledgerの柔軟性により、レポート時にコマンドラインフラグでFIFO、LIFO、平均などを選択できます。 | Ledgerと同様の柔軟な在庫処理。hledgerは指定された場合にロットを追跡できますが、Beancountほど厳密にロットごとの追跡を強制しません。キャピタルゲイン計算は利用可能ですが、より多くの手動セットアップが必要です。 |
| レポートとUI | 主にFava(ウェブUI)とbean-query/bean-reportを通じて。Favaはグラフとチャートを備えた洗練されたウェブダッシュボードを提供し、Beancountを分析に非常にユーザーフレンドリーにします。テキストレポートとbean-queryによるSQLライクなクエリもサポート。公式のTUI(テキストUI)はありませんが、エディタ/IDE統合がそのギャップを埋めています。 | 主にCLIベースのレポート。Ledgerには多くの組み込みレポートコマンド(balance、register、statsなど)があり、ターミナルにテキストを出力します。チャート(ASCIIまたはgnuplot経由)を生成でき、HTMLレポート用のアドオンもありますが、プロジェクトの一部として維持されている公式のウェブインターフェースはありません。(Ledger用のサードパーティのウェブUIの試みはありましたが、BeancountのFavaほど著名なものはありません。)UIには、ターミナルまたはLedger-Live(別プロジェクト)などのGUIを使用します。 | CLIとシンプルなWeb UIの両方を提供。hledgerはLedgerのCLIレポートを継承し(同様のコマンド)、さらにブラウザで勘定科目と取引を表示するための基本的なウェブインターフェースであるhledger-webを提供します。hledger-webはFavaほど機能豊富ではありませんが、読み取り専用の概要を提供します。hledgerには、インタラクティブな使用のためのターミナルcursesベースのインターフェースであるhledger-uiもあります。 |
| 拡張性とプラグイン | Pythonによる高い拡張性。プラグインAPIにより、台帳処理中に任意のPythonコードを実行でき、コアを変更せずにカスタム機能を実装できます。予算編成などのプラグインのエコシステムがこれを示しています。また、Beancountのライブラリを使用してカスタムレポート用のPythonスクリプトを書くこともできます。 | 低レベルの拡張性。LedgerはLedgerの出力を解析する独自のスクリプトを書くか、内部のクエリ言語を巧妙に使用することで拡張できます。ジャーナル内のトリガーに応じてポスティングを自動生成するルールである自動取引や定期取引などの機能もあり、これは台帳ファイル内の一種の組み込み拡張性です。しかし、会計エンジンに任意のコードを注入するAPIは提供していません – 同じ意味でのライブラリではありません(C++開発者向けのlibledgerは存在しますが)。 | 中程度の拡張性。hledgerは物事をシンプルに保つためにLedgerの自動/定期取引機能を意図的に省略していますが、他の形式の変換のためのhledger-importなどのツールを提供し、アドオンを許可しています。Haskellで書かれているため、一部のプロジェクトでライブラリとして使用されていますが、カスタムプラグインの作成はBeancountのアプローチほど簡単ではありません。代わりに、hledgerは公式ツールセット内で一般的なニーズ(レポート、ウェブ、UI)をカバーすることに焦点を当てています。 |
| コミュニティと開発 | 活発ですが、主に一人の作者(Martin Blais氏)と少人数の貢献者グループによって運営されています。メジャーリリースは頻繁ではありません(v2は約6年間安定していましたが、2024年にv3が登場)。コミュニティはプラグインやツールを通じて貢献しています(Favaはもともとサードパーティのプロジェクトで、不可欠なものになりました)。BeancountのメーリングリストとGitHubは議論が活発で、Favaの非開発者への訴求によりユーザーベースが成長しています。 | 長い歴史(Ledgerは2003年に遡る)とエンジニア間での幅広い使用。もともと一人のプロジェクト(Wiegley氏)で、時間とともに多くの貢献者を見てきました。近年、Ledgerの開発は鈍化しています。安定していますが、新機能は少なくなっています(焦点はメンテナンスに移っています)。ledger-cliメーリングリストは、すべてのプレーンテキスト会計の議論(Beancountとhledgerを含む)のハブです。Ledger周辺には多くのツールやスクリプトが存在しますが、エコシステムはそれほど統合されていません(単一の「Ledger GUI」などはなく、複数の独立した取り組みがあります)。 | 成長中のコミュニティで、Simon Michael氏がhledgerの開発を主導。hledgerは毎年リリースがあり、着実な改善が続き、しばしばLedgerの機能変更を追跡しつつも独自の道を歩んでいます。Ledgerのパワーとより高い予測可能性を求めるユーザーの間で人気があります。コミュニティはLedgerのものと重複する傾向があります(plaintextaccounting.orgは両方をカバー)。hledgerのエコシステムには、ワークフロー自動化のためのhledger-flowなどのアドオンが含まれ、Haskellで書かれていることから恩恵を受けています(そのコミュニティの人々を惹きつけます)。 |
要約すると、Beancountは厳密さ、プラグインベースの拡張性、ユーザーフレンドリーなウェブインターフェースへの重点によって差別化されています。Ledgerは、コマンドラインの純粋主義者や究極の速度を必要とする人々(LedgerのC++エンジンは巨大なファイルで非常に高速)に好まれる、クラシックで非常に柔軟なツールであり続けています。hledgerは中間的な立場を提供します – Ledgerの機能の多くにいくらか構造を加え、公式にサポートされた(シンプルではありますが)ウェブUIを備えています。3つすべてがプレーンテキスト会計の利点(監査可能性、Gitバージョン管理、プレーンデータ)を共有していますが、Beancountのエコシステム(特にFava)は近年、平均的なユーザーにとってよりアクセスしやすくしたと言えるでしょう。一方、Ledger/hledgerユーザーは、セットアップの比較的シンプルさ(Python不要)と長年の実証済みの安定性を好むことがあります。最終的に、それらの間の選択は個人の好みに帰着します:厳密な正確性と豊かなエコシステムを重視する人はBeancountに傾くことが多く、軽量でターミナル中心のツールを望む人はLedgerまたはhledgerを使い続けるかもしれません。
Beancountの使用シナリオ
Beancountは個人の財務追跡だけでなく、(場合によっては)小規模ビジネスの会計にも使用できる汎用性があります。その核となる複式簿記アプローチは両方のシナリオで同じですが、規模と具体的な実践方法が異なる場合があります。
個人財務
多くのBeancountユーザーは、個人または家庭の財務を管理するために使用しています。Beancountの典型的な個人財務セットアップには、当座預金と普通預金、クレジットカード、投資、ローン、収入カテゴリ(給与、利息など)、経費カテゴリ(家賃、食料品、娯楽など)の勘定科目が含まれる場合があります。ユーザーは日常の取引を手動で記録するか(領収書、請求書などの入力)、前述のインポーターツールを使用して銀行明細からインポートします。Beancountが個人財務にもたらす利点は次のとおりです:
- 統合と分析: すべての取引を、何年分もの財務履歴を表す単一のテキストファイル(またはファイルのセット)に置くことができます。これにより、長期的な傾向の分析が容易になります。Beancountのクエリ言語またはFavaを使用すると、「過去5年間に旅行にいくら使ったか?」や「私の平均月間食料品費はいくらか?」といった質問に数秒で答えることができます。あるユーザーは、Beancountに切り替えた後、「財務データ(支出、寄付、税金など)の分析が簡単になった」と、FavaまたはデータをクエリしてPandasなどのツールを使用することで述べています。本質的に、台帳はいつでもクエリできる個人の財務データベースになります。
- 予算編成と計画: Beancountは予算編成システムを強制しませんが、実装することは可能です。一部のユーザーは、予算勘定科目を作成するか、
fava-envelopeプラグインを使用して封筒予算編成を行います。他のユーザーは、単に定期的なレポートを使用して支出を目標と比較します。プレーンテキストであるため、外部の予算ツールやスプレッドシートとBeancountを統合するのは簡単です(データのエクスポートまたはクエリからのCSV出力を使用)。 - 投資と純資産の追跡: Beancountは、原価基準と市場価格の堅牢な処理により、投資の追跡に優れています。株式、暗号通貨などの売買を原価詳細とともに記録し、
Pricesディレクティブを使用して市場価値を追跡できます。Favaは時系列の純資産チャートと資産クラス別のポートフォリオ内訳を表示できます。これは個人の資産管理に非常に役立ちます – MintやPersonal Capitalなどの商用ツールと同様の洞察を得られますが、完全に自分の管理下にあります。多通貨処理も組み込まれているため、外貨や暗号通貨を保有している場合、Beancountはそれらを追跡し、レポート用に換算できます。 - 照合と正確性: 個人財務には、銀行明細との照合がしばしば含まれます。Beancountでは、残高アサーションや文書機能を使用して、定期的に勘定科目を照合できます。例えば、毎月
balance Assets:Bank:Checking <date> <balance>エントリを追加して、月末に台帳が銀行の明細と一致することを確認できます。bean-checkツール(またはFavaのエラー表示)は、不一致があれば警告します。あるユーザーは、すべての勘定科目の月次照合を行うことで「異常な活動を検出するのに役立つ」と述べており、Beancountが促進する良い個人財務の衛生習慣です。 - 自動化: 技術に詳しい個人は、Beancountを使用して個人財務ワークフローの大部分を自動化しています。インポーター、cronジョブ、そして少しのPythonを使用して、例えば毎日銀行取引を取得し(OFXやAPIを使用する人もいます)、ルールによって分類してBeancountファイルに追加するシステムをセットアップできます。時間が経つにつれて、台帳はほとんど自動更新され、必要に応じて確認と調整を行うだけになります。Hacker Newsのコミュニティメンバーは、3年後、彼らのBeancountの帳簿は「95%自動化」されたと共有しました。このレベルの自動化は、Beancountのプレーンテキストのオープン性とスクリプト機能によって可能になっています。
個人財務ユーザーは、データの完全な所有権(シャットダウンする可能性のあるクラウドサービスへの依存なし – 例えばMintが廃止された懸念)と、すべてのデータが統合されているときに洞察の深さが増すため、スプレッドシートやアプリよりもBeancountを選ぶことがよくあります。学習曲線は無視できません – 基本的な会計とBeancount構文を学ぶ必要がありますが、公式ドキュメントやコミュニティのチュートリアルなどのリソースが初心者の開始を助けます。セットアップが完了すると、財務の明確で信頼できる全体像を常に持つことで安心感が得られると多くの人が感じています。
小規模ビジネス会計
小規模ビジネス(または非営利団体、クラブなど)にBeancountを使用することは、個人使用ほど一般的ではありませんが、確かに可能であり、成功裏に行っている人もいます。Beancountの複式簿記フレームワークは実際には企業会計の基盤と同じシステムですが、専用の会計ソフトウェアが提供する高レベルの機能の一部(請求書モジュールや給与統合など)がありません。以下は、Beancountが小規模ビジネスの文脈にどのように適合できるかです:
- 総勘定元帳と財務諸表: 小規模ビジネスはBeancountファイルを総勘定元帳として扱うことができます。銀行口座、売掛金、場合によっては在庫の資産勘定科目があります。クレジットカード、ローン、買掛金の負債勘定科目、所有者資本の純資産勘定科目、売上やサービスの収入勘定科目、すべての事業経費の経費勘定科目があります。この台帳を維持することで、Beancountのレポートまたはクエリを使用していつでも損益計算書(P&L)と貸借対照表を作成できます。実際、Beancountの組み込みレポートまたはFavaは、会計原則に完全に沿った貸借対照表とP&Lを数秒で生成できます。これは、小規模な運営が収益性、財務状態、キャッシュフローを評価するのに十分です(直接のキャッシュフロー計算書は組み込まれていませんが導出できるため、キャッシュフローには少しクエリが必要です)。
- 請求書と売掛金、買掛金: Beancountには組み込みの請求書システムはありません。ユーザーは通常、外部で請求書を処理し(例:Wordや請求書アプリで請求書を作成)、結果をBeancountに記録します。例えば、請求書を発行するときは、売掛金勘定科目を借方に、収入を貸方に記録するエントリを作成します。支払いが来たら、現金/銀行を借方に、売掛金を貸方に記録します。これにより、売掛金勘定科目の残高を見ることで未収金を追跡できます。請求書(買掛金)にも同じことが適用されます。専用の会計ソフトウェア(リマインダーを送信したりメールと統合したりする可能性がある)よりも手動ですが、完全に実行可能です。一部のユーザーは、請求書をBeancountで管理し、未払いの請求書を見逃さないようにする方法(例えば、メタデータやカスタムクエリを使用して未払い請求書を一覧表示する)についてのテンプレートやワークフローを共有しています。
- 在庫または売上原価: 製品を販売するビジネスの場合、Beancountは在庫の購入と販売を追跡できますが、規律あるエントリが必要です。
Inventoryと原価会計機能を使用するかもしれません:在庫の購入は資産勘定科目を増やし(アイテムに原価が付加されます)、販売は原価を経費(COGS)に移動し、収益を記録します。Beancountはロットの一致を要求するため、適切な原価での在庫削減を強制し、正しく行えば粗利益計算の正確性を保証できます。ただし、自動化されたSKU追跡などはありません – すべて財務レベル(数量と原価)です。 - 給与と複雑な取引: Beancountは給与取引(給与経費、源泉徴収税など)を記録できますが、これらの数値の計算は外部または別のツールで行われ、その後Beancountに計上される場合があります。非常に小規模なビジネス(従業員1〜2人など)の場合、これは管理可能です。例えば、給与期間ごとに賃金、源泉徴収税、雇用主税経費、支払われた現金などを振り分ける単一の仕訳エントリを記録します。これを手動で行うことは、QuickBooksの仕訳で行う方法と似ています – どの勘定科目を対象にするかの知識が必要です。
- マルチユーザーと監査: ビジネス環境での1つの課題は、複数の人が帳簿にアクセスする必要がある場合や、会計士がレビューする必要がある場合です。Beancountはテキストファイルであるため、リアルタイムのマルチユーザーではありません。ただし、ファイルをGitリポジトリでホストすることでコラボレーションが可能になります:各人が編集してコミットでき、差分をマージできます。
- 規制遵守: 税務申告やコンプライアンスのために、Beancountのデータを使用して必要なレポートを生成できますが、カスタムクエリやプラグインが必要になる場合があります。インド政府のコンプライアンス報告用のコミュニティプラグインや、FinCEN FBAR報告用のプラグインの例を見ました。これは、努力すればBeancountを特定の報告要件に適合させられることを示しています。簡素な要件(現金主義会計または基本的な発生主義)の管轄区域の小規模ビジネスは、確かにBeancountで帳簿を維持し、税務申告用の財務諸表を作成できます。ただし、減価償却スケジュールや償却などの機能は、独自のエントリを書くか、プラグインを使用する必要があるかもしれません(Dave Stephensの減価償却プラグインはこれを自動化するのに役立ちます)。一部の会計ソフトウェアのように「資産を減価償却する」をクリックするGUIはありません。減価償却を取引としてエンコードします(これはある意味でそれを明快にします – すべてが検査できるエントリです)。
実際には、多くの技術志向の小規模ビジネスオーナーが、QuickBooksの利便性よりもコントロールと透明性を好む場合、Beancount(またはLedger/hledger)を使用してきました。Redditの議論では、限られた取引量の標準的な小規模ビジネス会計では、Beancountで問題なく機能することが指摘されました。制限要因は通常、快適さのレベルです – ビジネスオーナー(またはその会計士)がテキストベースのツールに快適さを感じるかどうかです。1つの利点はコストです:Beancountは無料ですが、会計ソフトウェアは小規模ビジネスにとって高額になる可能性があります。一方、公式サポートの欠如とDIYの性質は、ビジネスオーナーでありながらある程度技術に精通している人に最も適していることを意味します。プログラミングスキルを持つフリーランサーや個人事業主にとって、Beancountはクラウド会計サービスに依存せずに財務を管理する魅力的な選択肢になり得ます。
ハイブリッドアプローチも可能です:一部の小規模ビジネスは、請求書や給与に公式システムを使用しますが、分析とアーカイブのために定期的にデータをBeancountにインポートします。これにより、日常業務のコンプライアンスと容易さ、そして統合された洞察のためのBeancountのパワーの両方の恩恵を得られます。
要約すると、Beancountは、商用ソフトウェアが自動化するものを手動で管理する意思があれば、小規模ビジネス会計を処理できます。高い透明性を保証します – 帳簿を自分で書いているため、深く理解できます – そして、勤勉なユーザーにとっては、申し分のない帳簿を作成できます。個人とビジネスの両方のユーザーがBeancountの核となる強みから恩恵を受けます:信頼できる会計エンジン、完全な監査証跡、そして(スクリプトとプラグインによる)独自のシナリオに適応する柔軟性。家庭の予算の追跡であろうと、スタートアップの財務であろうと、Beancountはそれを正確かつオープンに行うためのツールキットを提供します。
コミュニティと開発活動
Beancountには、オープンソースのニッチながら情熱的な性質を反映した、熱心なコミュニティと開発ストーリーがあります。以下は、そのコミュニティ、メンテナー、関連プロジェクトに関する重要なポイントです:
-
プロジェクトメンテナンス: Beancountの主要な作者はMartin Blais氏で、2007年頃にプロジェクトを開始し、複数のバージョンを通じて導いてきました。長い間、開発は(コミュニティのパッチ貢献を除けば)ほぼ一人の努力でした。Martin氏の哲学は、「まず自分にとって役立つ、そして他の人にも役立つ、最もシンプルで耐久性のある方法で」会計ツールを構築することでした。この個人的な動機が、愛情のこもった仕事としてプロジェクトを続けさせました。2025年時点で、Martin Blais氏は依然としてリードメンテナーです(彼の名前がコミットに現れ、メーリングリスト/イシュートラッカーで質問に答えています)が、Beancount周辺のエコシステムにはそれぞれのプロジェクトに多くの他の貢献者がいます。
-
GitHubとリポジトリ: ソースコードはGitHubの
beancount/beancountリポジトリでホストされています。プロジェクトはGPL-2.0ライセンスで、長年にわたってかなりの数の貢献者を集めてきました。2024年半ばに、Beancount Version 3が新しい安定版ブランチとして正式にリリースされました。このリリースにはいくつかのコンポーネントの分割が含まれていました:例えば、beangulpリポジトリ(インポーター用)とbeanqueryリポジトリ(クエリツール用)は現在、beancountGitHub組織の一部であり、やや独立してメンテナンスされています。メインのBeancountリポジトリはコアの会計エンジンとファイルパーサーに焦点を当てています。2025年時点で、BeancountのGitHubは活発なイシュー議論といくつかの進行中の開発を示しています – 量は多くありませんが、イシューとプルリクエストは少しずつ入ってきており、バグ修正や機能の改善のために時折アップデートが行われます。 -
Fava開発: ウェブインターフェースであるFavaは、別のプロジェクトとして始まりました(Dominic Aumayr氏によって作成され、2016年に著作権が設定されました)。独自の貢献者コミュニティがあり、
beancount/favaの下でGitHubにもあります。Favaのメンテナーと貢献者(近年ではJakob Schnetz氏、Stefan Otte氏など)は、数ヶ月ごとのリリースでインターフェースの改善に積極的に取り組んでいます。FavaのGitterチャット(Favaドキュメントにリンク)とGitHubイシュートラッカーは、ユーザーと開発者が新機能やバグについて議論する場所です。プロジェクトは貢献を歓迎しており、複数のコミュニティメンバーのPRに感謝するCHANGELOGノートによって証明されています。Beancountの開発とのFavaの密接な連携(Beancount v3と新しいbeanquery構文のサポートを迅速に追加したことなど)は、2つのプロジェクト間の良好なコラボレーションを示しています。 -
メーリングリストとフォーラム: Beancountには公式メーリングリストがあります(以前はGoogle Groupsで「Beancount」というタイトルで、または一般的なLedgerリストで議論されることもありました)。このメーリングリストは知識の宝庫です – ユーザーは特定のシナリオのモデル化方法について質問し、バグを報告し、ヒントを共有します。Martin Blais氏は詳細な説明でメーリングリストに応答することで知られています。さらに、より広いプレーンテキスト会計コミュニティは大きく重複しています。Ledger CLIメーリングリストはしばしばBeancountについての質問も受け付け、plaintextaccounting.orgのフォーラムとr/plaintextaccountingのサブレディットがあり、Beancountのトピックが頻繁に出てきます。これらのプラットフォームのユーザーは比較について議論し、個人のセットアップを共有し、初心者を支援します。コミュニティの全体的なトーンは非常に協力的です – BeancountユーザーはLedgerユーザーを助けることが多く、その逆も同様で、これらのツールすべてが同様の目標を持っていることを認識しています。
-
チャットグループ: メーリングリストに加えて、Plaintext Accounting Slack/Discord(コミュニティ主催)やFava Gitterなどのチャットチャネルがあります。これらはあまり形式的ではなく、よりリアルタイムなヘルプや機能の議論の方法です。例えば、特定の銀行用のインポーターを持っている人がいるかどうかをSlackで尋ねることができます。また、Matrix/IRCチャネル(歴史的にはIRCの#ledgerまたは#beancount)もあり、一部の長年のユーザーが待機しています。主流ソフトウェアのコミュニティほど人口は多くありませんが、これらのチャネルには、曖昧な会計の質問に答えられる知識豊富な人々がいます。
-
貢献者と主要なコミュニティメンバー: Beancountコミュニティではいくつかの名前が際立っています:
- “Redstreet”(Red S): 多くのプラグイン(
beancount-balexpr、sellgainsなど)を書き、しばしばサポートを提供する多作な貢献者。また、インポータースクリプトのセットと、明細を取得するためのbean-downloadと呼ばれるツールもメンテナンスしています。 - Vasily M(Evernight):
beancount-valuationなどのインポーターフレームワークとプラグインの作者であり、投資に関するFavaへの貢献。 - Stefano Zacchiroli(zack): Emacs用のbeancount-modeを作成し、独自のプラグインリポジトリを持つDebian開発者。学術環境でのプレーンテキスト会計も提唱しています。
- Simon Michael氏: 主にhledgerのリーダーですが、Beancountを含むplaintextaccounting.orgを運営しています。この相互交流は、BeancountをLedger/hledgerユーザーの注意を引くのに役立ちました。
- Frank hell(Tarioch): 特にヨーロッパの機関向けの主要なインポーターと価格フェッチャーのセットであるTarioch Beancount Toolsの貢献者。
- Siddhant Goel氏: Beancountについてブログを書き(例えば、v3への移行ガイド)、いくつかのインポーターをメンテナンスしているコミュニティメンバー。彼のブログ記事は多くの新規ユーザーを助けてきました。
これらおよび他の多くの人々がコード、ドキュメント、フォーラムでの支援に貢献し、比較的小規模であるにもかかわらずエコシステムを活気づけています。
- “Redstreet”(Red S): 多くのプラグイン(
-
GitHub統計とフォーク: BeancountのGitHubリポジトリは数百のスター(関心を示す)とフォークを蓄積しています。Beancount自体の注目すべきフォークはまれです – 「Beancountだけど機能X付き」を目指すよく知られた分岐フォークはありません。代わりに、ユーザーが何か違うものを望んだ場合、プラグインを書くか、別のツール(hledgerなど)を使用しました。hledgerはLedgerの一種のフォーク(Beancountではありません)と見なせ、Beancount自体はLedgerのアイデアの独立した再考ですが、Beancountのリポジトリ内には大きな分裂プロジェクトはありません。コミュニティは一般的にメインリポジトリの周りに結集し、コードベースを断片化する代わりにプラグインインターフェースを介して拡張してきました。これはおそらく、Martin Blais氏が外部からの貢献にオープンであり(彼のドキュメントには外部貢献とモジュールを認めるセクションさえあります)、プラグインアーキテクチャがほとんどの新機能のためにフォークを維持する必要性をなくしたためです。
-
コミュニティリソース: Beancountを学び使用するためのコミュニティ作成の高品質なリソースがいくつかあります:
-
GitHub PagesのBeancountドキュメント(およびMartin氏が維持するソースのGoogle Docs)– 会計理論とBeancountがそれをどのように実装するかを含む、非常に包括的です。
-
多数のブログ記事と個人的なメモ – 例えば、LWN.netには「Counting beans… with Beancount」という記事があり、多くの個人ブログ(Awesome Beancountの「Blog Posts」セクションにリストされています)が経験とヒントを共有しています。これらは知識を構築し、新しいユーザーを引き付けるのに役立ちます。
-
トークとプレゼンテーション: Beancountはミートアップやカンファレンスで発表されてきました(例えば、PyMunich 2018のPython/Beancountでの財務管理に関するトーク)。そのようなトークはツールをより広いオーディエンスに紹介し、しばしばHacker Newsなどのフォーラムで関心を呼び起こします。
-
-
注目すべき関連プロジェクト: Favaとは別に、Beancountに関連する他のいくつかのプロジェクトには独自のコミュニティがあります:
- Plain Text Accountingサイト – Simon Michael氏が維持し、そのようなすべてのツールの情報を集約し、Beancountを含むさまざまなツールの使用法を人々が共有するフォーラムがあります。
- 金融ツール統合: 一部のユーザーはBeancountをビジネスインテリジェンスツールやデータベースと統合しています。例えば、Google Groupsのスレッドでは、カスタム関数を介してBeancountデータをPostgreSQLで使用する詳細が説明されています。主流ではありませんが、組み込みを超えた非常に大きなデータセットや複雑なクエリを処理するためにBeancountの機能を押し広げるコミュニティの実験的精神を示しています。
要約すると、Beancountのコミュニティは、大規模なオープンソースプロジェクトのものよりも小さいですが、非常に熱心で知識豊富です。プロジェクトは着実な改善の流れと非常に役立つサポートチャネルを享受しています。共同の精神(インポーターの共有、プラグインの作成、質問への回答)により、2025年の新規参入者は、会計システムのセットアップに広範な先行研究とコミュニティの知恵を頼ることができます。コアの変更はより散発的ですが、開発はエコシステムの意味で活発です(Favaリリース、プラグイン開発など)。エコシステムの成長(数十のツールのAwesome Beancountリストによって証明されています)は、Beancountをますます能力の高いものにしている健全なコミュニティを物語っています。
最近の開発と今後の機能
Beancount.ioの会計自動化に関する研究については、Bean Labsをご覧ください。研究ログと方法を探索できます。
2025年時点で、Beancountエコシステムは過去数年間で重要な発展を遂げており、将来の機能強化について進行中の議論があります。以下に、いくつかの注目すべき最近の開発と、今後予想されるものの一端を示します:
-
Beancount 3.0リリース(2024年): Beancount 2.xが標準である長い期間の後、バージョン3が2024年半ばに正式にリリースされました。これは、v3がコードベースの簡素化と近代化を表すため、主要なマイルストーンでした。Martin Blais氏はv3をシステムをさらに「再配置して簡素化」する機会と構想していました。もともとは大きな書き直しと考えられていましたが、実際にはユーザーへのアップデートはそれほど破壊的ではありませんでした。主な変更は_内部_にありました:新しいパーサー、いくつかのパフォーマンスの改善、コアからのオプションコンポーネントの抽出です。リリースは段階的に展開されました(v3は2022年からベータ版でしたが、2024年7月までに推奨される安定版になりました)。Siddhant Goel氏などのユーザーは、2.xから3.xへの移行は「ほとんど問題なく」、わずかなワークフローの変更だけであったと報告しています。
-
モジュール化 – ツールの別パッケージへの移動: Beancount 3の大きな変更の1つは、かつてモノリシックリポジトリに住んでいた多くのツールが分離されたことです。例えば、bean-queryは現在
beanqueryパッケージによって提供され、beancount.ingestはbeangulpパッケージに置き換えられました。bean-extractやbean-identify(インポート用)などのコマンドはコアのBeancountから削除されました。代わりに、哲学はインポートにスタンドアロンスクリプトを使用することです。つまり、v3にアップグレードする場合は、beangulpをインストールし、インポータースクリプト(各インポーターは基本的に小さなプログラム)を実行します。中心的なbean-extract設定ファイルはありません。同様に、クエリはBeancountコアとは独立してインストールおよび更新できるbeanqueryを介して実行されます。このモジュール化されたアプローチは、メンテナンスを容易にし、コミュニティの貢献を促進するために設計されました。また、Beancountのコアをスリム化し、コアは純粋に解析と会計ロジックに焦点を当て、付随する機能は別々に進化できます。ユーザーの視点からは、アップグレード後、コマンドを調整する必要があります(例:beanqueryからbean-queryを使用するか、これを抽象化するFavaを使用する)。Favaのチェンジログはこれらの変更を明示的に述べています:Favaは現在beanqueryとbeangulpに依存し、Beancount 3と2でインポートワークフローを異なる方法で処理します。 -
パフォーマンスの改善: パフォーマンスはBeancountの設計を再考する動機の1つでした。v3計画(Martin氏の「V3 goals」ドキュメントで概説)には、パーサーの最適化と、ロードプロセスをより速くメモリ集約的でなくする可能性が含まれていました。2025年までに、これらの改善の一部が実現しました。非常に大きな台帳(数万の取引、または多数の株式取引)を持つユーザーは、最新バージョンでのパフォーマンス向上を報告しています。例えば、パフォーマンスの問題に直面した「マイクロ投資取引」を扱うユーザーは、Google Groupでこれらの懸念を指摘しました – この種のフィードバックはv3に影響を与えた可能性が高いです。新しいパーサーはより効率的で、より明確な方法で書かれており、将来的に拡張できる可能性があります。さらに、Fava 1.29はより効率的なファイル監視メカニズム(
watchfilesライブラリを使用)に移行し、台帳の変更時の応答性を改善しました。将来的には、コミュニティは大きな台帳をより迅速に処理するためのインクリメンタルパーシング(ファイルの変更された部分のみを再処理する)を探索するかもしれません – これはドキュメントで「Beancountサーバー/インクリメンタルブッキング」のアイデアとしてほのめかされました。 -
投資追跡の強化: 投資とポートフォリオレポートをより良くするための進行中の作業があります。例えば、平均原価基準とFIFOの処理が長く議論されてきました。Beancountはロットマッチングを強制しますが、一部のユーザーは特定の管轄区域で平均原価を好みます。原価基準のブッキングをより柔軟にする(おそらくプラグインまたはオプションを介して)提案と議論が存在します。2025年時点で、平均原価の組み込みスイッチはありませんが、v3の基盤(ブッキングの再設計)により、プラグインが実装しやすくなっています。「Gains Minimizer」というコミュニティプラグインがリリースされ、税金を最小化するために売却するロットを提案できます。これは、投資の周りに構築されている高度なツールの種類を示しています。Favaも、ポートフォリオサマリー拡張機能(利回り計算付き)などの機能を追加しました。今後の機能としては、この分野でより多くのことが期待できます:おそらく自動ポートフォリオリバランス提案やリスク分析が、Beancountデータを読み取る外部ツールとして登場するでしょう(データはすべてそこにあるため)。
-
新しいプラグインと拡張機能: プラグインエコシステムは継続的に成長しています。最近の注目すべき追加には以下が含まれます:
- 予算レポートツール – 例えば、FavaのUIを使用しない場合のシンプルなCLI予算レポーター。
- 暗号化とセキュリティ – fava-encryptセットアップが導入され、台帳を保管時に暗号化してFavaをオンラインでホストできるようになり、財務の自己ホスティングの懸念に対処しました。
- 生活の質のプラグイン –
autobean-format(ファイルを解析して再印刷することでより多くのコーナーケースを処理できる新しいフォーマッタ)、エディタでのbeancheck統合(Emacs用のflymake)など。
今後、コミュニティはプラグインを介してギャップを埋め続ける可能性が高いです。例えば、より多くの税関連プラグインが見られるかもしれません(一部のユーザーは、イズレセールの計算や特定の地方税レポートなどのスクリプトを共有しています)。
-
可能性のある今後の機能: イシュートラッカーとメーリングリストでの議論に基づいて、いくつかのアイデアが予定されています(保証はされていませんが):
- 時間分解能: 現在、Beancountは取引の日付のみを追跡します(タイムスタンプなし)。時間の追加についての質問がありました(株式取引や同日取引の順序付け用)。Martin Blais氏は、物事をシンプルに保つために日未満のタイムスタンプは範囲外であると明示的に決定しました。これはすぐに変わる可能性は低いです – 今後のバージョンはおそらく時間分解能を追加せず、時間が必要な場合はnarrationまたは勘定科目に組み込むという立場を維持します。
- 強化されたGUI編集: Favaは編集機能を継続的に改善しています。可能性としては、よりフル機能のウェブエディタ(自動提案付き、新しい取引のフォームベース入力の可能性)があります。Favaのエディタでのtree-sitterの使用の基盤が築かれました。Favaが単なるビューアではなく、より強力なエディタになり、多くのタスクでテキストエディタを開く必要性を減らすかもしれません。
- より良いマルチ台帳サポート: 一部のユーザーは複数のBeancountファイルを維持しています(異なるエンティティ用、または個人とビジネスの分割用)。現在、ファイルのインクルードは可能ですが制限がありました(インクルードされたファイルのプラグインなど)。
autobean.includeという最近のプラグインが、外部台帳を安全に含めるために作成されました。将来的には、マルチファイルセットアップのファーストクラスサポートが見られるかもしれません – 複数のファイルを持つBeancount「プロジェクト」の概念(VSCode拡張機能のbeancount.mainBeanFile設定などの機能によってほのめかされています)。これは、マルチエンティティ簿記を実行している人や台帳をモジュール化したい人を助けます。 - リアルタイムまたはインクリメンタル計算: 台帳が大きくなるにつれて、レポートを迅速に再計算する能力が重要になります。トランザクションの変更に応じて結果を更新しながら実行し続けるBeancountサーバーのアイデアがあります。これはFavaの最適化またはエディタプラグインがクエリできるデーモンとして現れるかもしれません。将来のFavaリリースは、継続的に実行されるBeancountプロセスを活用して、巨大な台帳のUI応答性を高めるかもしれません。
- 基金会計/非営利機能: Beancountでの基金会計に関する拡張提案がありました。非営利組織には会計ニーズ(制限付きと制限なしの基金)があり、Beancountのタグまたは勘定科目階層でモデル化できる可能性があります。この議論はまだ組み込み機能につながっていませんが、より多くの非営利団体がBeancountを採用すれば、新機能(おそらく文書化されたベストプラクティスや基金残高追跡のプラグイン)を促進する可能性があります。
-
長期的な見通し: Martin Blais氏は、Beancountの未来をコアをよりエンジンにし、より多くの機能をプラグインに移すことと見ていることを示唆しました。これは私たちが見るもの(v3のモジュール化)と一致しています。したがって、哲学的な意味での「今後の機能」はより大きな拡張性です – おそらくプラグインが新しいディレクティブタイプを定義したり、制御された方法で構文を拡張したりできるようにすることです。それが起こった場合、Beancountのコアは比較的小さく安定したままで、エコシステムがアドオンとしてほとんどの新機能を提供するかもしれません。これは、ユーザーが選択できるプラグインマーケットプレイスやより中央集権的なプラグインリストにつながる可能性があります(Awesome Beancountリストはその始まりです)。
結論として、2025年のBeancountエコシステムは活発で進化しています。Beancount 3.0のリリースは最近の主要なイベントであり、プロジェクトの基盤が将来に向けて確固たるものであることを保証しました。パフォーマンス、ツール、使いやすさ(特にFavaを介した)の改善により、参入障壁は引き続き低下しています。Beancountはある程度の専門知識を必要とするツールのままですが、これらの開発により、数年前よりもはるかに親しみやすくなっています。今後の機能は、コアの哲学の抜本的な変更ではなく、エクスペリエンスの洗練 – より高速なパフォーマンス、より良い統合、専門的な拡張 – に焦点を当てる可能性が高いです。コミュニティの軌跡は、Beancountがプレーンテキスト会計の中心的存在として成熟し続け、複式簿記の厳格な力と現代のソフトウェアの利便性のバランスを取ることを示唆しています。Hacker Newsのあるユーザーが言ったように、プレーンテキスト会計は財務を理解する「スーパーパワー」を与えます – そしてBeancountの最近および将来の改善は、そのスーパーパワーを誰もがより簡単に使えるようにすることを目指しています。
出典: Beancountドキュメントとリポジトリ;Favaドキュメント;Martin Blais氏による「A Comparison of Beancount and Ledger」;Awesome Beancountリソースリスト;ユーザー体験とコミュニティレポート;





