2026-09-15時点の情報です。
インポーター、プラグイン、エディター、価格ソースの保守されたカタログについては、Awesome Beancountから始めてください。実践的なコミュニティワークフローについては、コミュニティショーケースを参照してください。チェック、クエリ、インポート、レポートをまとめたホステッドCLIについては、Beancount CLIリファレンスを参照してください。Fava中心の分析は、ソリューション:分析にあります。
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モード:
.beancountファイルを編集するためのEmacsメジャーモード(beancount-mode)が利用可能で、構文カラーリングやBeancountのチェッカーとの統合などの機能を提供します。バックグラウンドでbean-checkを実行して、台帳内のエラー(バランスの取れていない取引など)を編集中にフラグ付けすることもできます。 - VS Code拡張機能: VSCodeマーケットプレイスの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パッケージを内部で使用するように切り替えました。Fava 1.30.13(2026-05-19)(チェンジログ)の時点で、Beancount 2のサポートは完全に廃止されました - 現在のPyPI Fava(2026-09-15時点で1.30.16)はBeancount 3台帳とbeangulpベースのインポーターを想定しています。Favaの使いやすさへの焦点には、ウェブエディターでの自動補完、ダークモードとレスポンシブチャートを備えたスタイリッシュなUIなどの素晴らしいタッチが含まれます。また、Fava-GTKと呼ばれるスピンオフもあり、ネイティブアプリの感触を好むGNOME/Linuxユーザー向けにFavaをデスクトップアプリケーションにパッケージ化しています。
Fava以外にも、他の可視化・分析オプションが存在します。Beancountデータはテーブルとしてエクスポートまたはクエリできるため、ユーザーはカスタム分析にJupyterノートブックやPandasなどのツールを活用することがよくあります。例えば、あるユーザーは、クエリインターフェースを介してBeancountからデータをPandas DataFrameに取り込み、カスタムレポートを準備することを説明しています。また、特定のレポート用のコミュニティ提供スクリプトもあります - ポートフォリオ配分分析ツールや、支出対純資産のプロセス管理チャートなどです。しかし、ほとんどの人にとってFavaは、コードを書かずに十分なレポート機能を提供します。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プラグインは、口座間の現物転送エントリを生成できます(原価基準を維持しながらブローカー間で株式を移動するのに便利)。別のautobean.xcheckは、外部明細との差異についてBeancount台帳をクロスチェックします。 - 定期取引と予算: Akuukisによる**「繰り返し」または補間プラグインは、定期的な取引を定義したり、年間経費を月に分配したりできます。予算については、
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で書かれ、ファイル処理中に実行され、カスタマイズを提供します。 |
| コンバーター(移行ツール) | 他の形式からBeancountにデータを変換するユーティリティ、例:GnuCashやLedger CLIからBeancount形式へ。ゼロから始めることなくBeancountを採用するのに役立ちます。 |
| bea CLI(Beancount.io) | ホステッドかつローカルで使いやすいCLI(bea check、bea query、bea import、bea reportなど)。CLIリファレンスに文書化されています。日々の台帳運用のためにBeancount 3ツールをラップします。 |
| Open Ledger | 公開企業の台帳をBeancountファイルとして公開し、収益投稿に埋め込んでいます - /open-ledgerとコミュニティショーケースで、プレーンテキストの帳簿がどのように伝わるかを確認してください。 |
ホステッドCLIとオープン台帳(2026年追加)
この概要が最初にドラフトされたときに薄かったり欠けていた2つの要素が、現在は日常のBeancount.ioワークフローに組み込まれています:
beaCLI — Beancount CLIリファレンスとCLIクイックスタートで、台帳の検証、BQLの実行、銀行ファイルのインポート、レポートの生成を、別々のbean-*エントリポイントを操作することなくカバーしています。現在のドキュメントの例に従う場合は、bea check/bea queryを優先してください。- オープン台帳 — 選択された企業の公開財政期間がBeancountリポジトリとして存在し、ブログの台帳埋め込みを介して表示されます。/open-ledgerでインベントリを閲覧してください;モデリングのウォークスルーは公開企業をBeancountでモデル化するにあります。
Ledger、hledger、および類似システムとの比較
Beancountは、プレーンテキスト複式簿記ツールのファミリーに属し、その中でLedger CLI(John WiegleyのLedger)とhledgerが著名です。これらのシステムはすべてプレーンテキスト台帳ファイルと複式簿記という中核的なアイデアを共有していますが、構文、哲学、エコシステムの成熟度が異なります。以下の表は、Beancount、Ledger、hledgerの主な違いを強調しています:
| 側面 | Beancount(Python) | Ledger CLI(C++) | hledger(Haskell) |
|---|---|---|---|
| 構文とファイル構造 | 正式な文法(BNF)で定義された厳格で構造化された構文。取引には明示的な日付 フラグ "支払い先" "説明"行と数量を持つ投稿がある。すべての口座は明示的に開設/定義されなければならない。暗黙の投稿はなく、すべての取引はバランスが取れていなければならない。 | より自由な形式の構文。支払い先/説明は通常、日付と同じ行にある。暗黙のバランシングを許可する(単一投稿の取引はデフォルト口座への2番目の投稿を暗示できる)。口座名は事前宣言なしで使用できる。解析に影響を与える多くのコマンドラインオプションを提供する(年仮定、商品マージルールなど)。 | 主にLedgerの構文に従い、小さな違いがある。hledgerはLedgerの中核機能をHaskellで再実装したものなので、ジャーナル形式はLedgerのものと非常に似ている(いくつかの拡張とデフォルトでより厳格な解析付き)。例えば、hledgerは日付と商品構文についてLedgerより少し厳格だが、Beancountほど厳格ではない。 |
| 哲学 | 保守的で几帳面。 ユーザーエラーの検出とデータ整合性の維持を何よりも重視。デフォルトで多くのチェック(残高アサーション、ロット追跡)を課す。最小限の設定 - 一貫性のための「一つの方法」アプローチ。拡張性のためにプラグイン付きのライブラリとして設計(台帳データをストリームとして扱い、カスタムPythonロジックを可能にする)。 | 楽観的で柔軟。 ユーザーがデータを正しく入力することを信頼し、デフォルトの組み込み制約は少ない。動作を調整するための数十のオプションとコマンドフラグで高度にカスタマイズ可能。レポート、プロットなどの機能が組み込まれたモノリシックツールであり、ジャーナル内のドメイン固有言語で自動取引や定期取引などの機能を使用。拡張性は通常、プラグインAPIではなく外部スクリプトまたは組み込みクエリ言語による。 | 実用的で一貫性がある。 Ledgerのアプローチをより広いオーディエンスに予測可能な動作で提供することを目指す。hledgerはデフォルトでより一貫性を重視(明示的な口座なしのバランシング仮定なし)、Ledgerの最も寛容なモードよりも足を撃ち抜く可能性が少ない。Ledgerの機能のサブセットを持ち(いくつかのよりエキゾチックなオプションはサポートされていない)、独自のものを追加する(ウェブインターフェースと組み込みCSVインポートなど)。安定性と正確性を重視するが、Beancountのようなプラグインシステムはない。 |
| 取引とバランシング | 厳格な複式簿記:すべての取引は借方と貸方の合計が等しくなければならない。バランスの取れていないエントリやプレースホルダーを許可しない(自動バランスする「仮想投稿」なし)。口座間の順序依存性も強制する:残高アサーションは日付でスコープされているため、台帳は任意に日付でソートできる。商品のコスト追跡は厳密 - 資産を売却する際はロットを指定するか、BeancountがFIFO/LIFOを強制して追加されていないものを削除できないようにする。 | 取引においてより寛容。Ledgerは「仮想」投稿(角括弧[ ]や括弧( )を使用)を許可し、これは明示的なバランシング口座を必要としない - 予算や暗黙の純資産バランシングを処理するためによく使用される。Ledgerでは、不完全な取引(片側を省略)を入力し、Ledgerにバランシング金額を推測させることが可能。また、Ledgerはロットごとの資産削除を厳格に強制せず、特定のロットが追跡されていなくても集計商品残高から喜んで減算する。これにより平均原価会計などが容易になるが、特定のロットで保有しているよりも多くの株式を売却するなどの間違いを防ぐことはできない。 | Ledgerと同様に仮想投稿と暗黙のバランシングを許可するが、より一貫性のある動作。hledgerはLedgerよりも厳格な解析ルールを強制するが、Beancountよりは寛容。 |
| 在庫と原価基準 | 精密なロット追跡。Beancountは商品ロットにコスト情報を付与し(例:1株100ドルで10株購入)、在庫を減らす際は特定のロットを一致させるか定義された戦略を使用する必要がある。設計上、キャピタルゲインと原価基準が正しく計算されることを保証する。平均原価法は、明示的にロジックを書かない限りデフォルトではない。なぜなら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とシンプルなウェブUIの両方を提供。hledgerはLedgerのCLIレポート(同様のコマンド)を継承し、さらにhledger-webを提供する - ブラウザで口座と取引を表示するための基本的なウェブインターフェース。hledger-webはFavaほど機能が豊富ではないが、読み取り専用の概要を提供する。hledgerにはhledger-uiもあり、インタラクティブな使用のための端末cursesベースのインターフェース。 |
| 拡張性とプラグイン | 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のクエリ言語またはFavaを使用して、「過去5年間に旅行にいくら使ったか?」や「平均月間食料品費はいくらか?」といった質問に数秒で答えることができます。あるユーザーは、Beancountに切り替えた後、_「財務データ(支出、寄付、税金など)の分析が簡単になった」_と述べています。Favaを介しても、データをクエリしてPandasなどのツールを使用しても同様です。本質的に、あなたの台帳は好きなときにクエリできる個人財務データベースになります。
- 予算と計画: Beancountは予算システムを強制しませんが、実装できます。一部のユーザーは予算口座を作成したり
fava-envelopeプラグインを使用してエンベロープ予算を行います。他のユーザーは単に定期的なレポートを使用して支出を目標と比較します。プレーンテキストであるため、Beancountを外部の予算ツールやスプレッドシートと統合するのは簡単です(データのエクスポートやクエリからのCSV出力を使用)。 - 投資と純資産追跡: Beancountは、原価基準と市場価格の堅牢な処理のおかげで投資追跡に優れています。株式、暗号通貨などの売買をコスト詳細とともに記録し、
Pricesディレクティブを使用して市場価値を追跡できます。Favaは経時的な純資産チャートと資産クラス別のポートフォリオ内訳を表示できます。これは個人の資産管理に非常に役立ちます - MintやPersonal Capitalなどの商用ツールが提供するものと同様の洞察が得られますが、完全にあなたのコントロール下にあります。これらのダッシュボードの価格付きランキングについては、Mint代替案まとめとEmpower / Personal Capital代替案まとめを参照してください。多通貨処理も組み込まれており、外貨や暗号通貨を保有している場合、Beancountはそれらを追跡し、レポート用に換算できます。 - 照合と正確性: 個人財務には銀行明細との照合がしばしば含まれます。Beancountでは、残高アサーションや文書機能を使用して口座を定期的に照合できます。例えば、毎月
balance Assets:Bank:Checking <日付> <残高>エントリを追加して、台帳が月末の銀行明細と一致することを確認できます。bean-checkツール(またはFavaのエラー表示)は、物事が一致しない場合に警告します。あるユーザーはすべての口座の毎月の照合を行い、「異常な活動を検出するのに役立つ」と述べています。これはBeancountが容易にする良い個人財務衛生慣行です。 - 自動化: 技術に精通した個人は、Beancountで個人財務ワークフローの大部分を自動化しています。インポーター、cronジョブ、少しのPythonを使用して、例えば毎日銀行取引を取得し(OFXやAPIを使用する人もいます)、Beancountファイルにルールでカテゴリ分けして追加するシステムを設定できます。時間が経つにつれて、台帳はほぼ自動更新され、レビューと微調整だけが必要になります。Hacker Newsのコミュニティメンバーは、3年後には彼らのBeancount帳簿が「95%自動化」されたと共有しました。このレベルの自動化は、Beancountのプレーンテキストの開放性とスクリプト機能のおかげで可能です。
個人財務ユーザーは、スプレッドシートやアプリよりもBeancountを選ぶことがよくあります。それはデータの完全な所有権を与えるからです(シャットダウンするかもしれないクラウドサービスへの依存がない - Mintが廃止されたように)そして、すべてのデータが統合されているときに洞察の深さが増すからです。学習曲線は無視できません - 基本的な会計とBeancount構文を学ぶ必要があります - しかし、公式ドキュメントやコミュニティのチュートリアルなどのリソースが新規ユーザーの開始を支援します。一度セットアップすると、明確で信頼できる財務状況の全体像を常に持つことで安心感が得られると多くの人が感じています。
小規模ビジネス会計
Beancountを小規模ビジネス(または非営利団体、クラブなど)に使用することは、個人使用よりも一般的ではありませんが、確かに可能であり、成功裡に行った人もいます。Beancountの複式簿記フレームワークは、実際には企業会計の基盤と同じシステムですが、専用の会計ソフトウェアが提供するいくつかの高レベル機能(請求書モジュールや給与統合など)がありません。Beancountが小規模ビジネスの文脈にどのように適合できるかを次に示します:
- 総勘定元帳と財務諸表: 小規模ビジネスはBeancountファイルを総勘定元帳として扱うことができます。銀行口座、売掛金、場合によっては在庫の資産口座、クレジットカード、ローン、買掛金の負債口座、オーナーの資本の純資産口座、売上やサービスの収入口座、すべての業務経費の経費口座を持つことになります。この台帳を維持することで、Beancountのレポートやクエリを使用していつでも損益計算書と貸借対照表を生成できます。実際、Beancountの組み込みレポートやFavaは、会計原則に完全に沿った貸借対照表とP&Lを数秒で生成できます。これは小規模な事業にとって、収益性、財務状態、キャッシュフローを評価するのに十分です(キャッシュフロー計算書は組み込まれていませんが、派生できるため、少しのクエリでキャッシュフローを評価)。
- 請求書と売掛金/買掛金: Beancountには組み込みの請求書システムはありません;ユーザーは通常、外部で請求書を処理し(例:Wordや請求書アプリで請求書を作成)、結果をBeancountに記録します。例えば、請求書を発行すると、売掛金の借方と収入の貸方のエントリを記録します。支払いが来たら、現金/銀行の借方と売掛金の貸方を記録します。これにより、A/R口座の残高を見ることで未収金を追跡できます。同じことが請求書(A/P)にも当てはまります。専用の会計ソフトウェア(リマインダーを送信したりメールと統合したりするかもしれない)よりも手動ですが、完全に可能です。一部のユーザーは、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は、ユーザーが商用ソフトウェアが自動化するものを手動で管理することを厭わない場合、小規模ビジネス会計を処理できます。それは高い透明性を保証します - あなたは帳簿を書いているので深く理解しています - そして、 diligentなユーザーにとって、それは完璧な帳簿を生み出すことができます。個人とビジネスの両方のユーザーがBeancountの中核的な強みから恩恵を受けます:信頼性の高い会計エンジン、完全な監査証跡、そして(スクリプトとプラグインを介して)独自のシナリオに適応する柔軟性。世帯予算の追跡であれ、スタートアップの財務であれ、Beancountは精度と開放性をもってそれを行うためのツールキットを提供します。
コミュニティと開発活動
Beancountには献身的なコミュニティと、そのオープンソースでニッチだが情熱的な性質を反映した開発ストーリーがあります。以下は、そのコミュニティ、メンテナー、関連プロジェクトに関する重要なポイントです:
-
プロジェクトメンテナンス: Beancountの主著者はMartin Blaisで、2007年頃にプロジェクトを開始し、複数のバージョンを導いてきました。開発は長い間、ほぼ一人の努力でした(コミュニティからのパッチ貢献を除く)。Martinの哲学は、「まず自分に役立ち、そして他の人にも、最もシンプルで耐久性のある方法で」会計ツールを構築することでした。この個人的な動機がプロジェクトを愛情のこもった労働として継続させました。2025年の時点で、Martin Blaisは依然としてリードメンテナーです(彼の名前はコミットに表示され、メーリングリスト/イシュートラッカーで質問に回答しています)が、Beancount周辺のエコシステムにはそれぞれのプロジェクトで多くの他の貢献者がいます。
-
GitHubとリポジトリ: ソースコードはGitHubの
beancount/beancountリポジトリでホストされています。プロジェクトはGPL-2.0ライセンスで、長年にわたって中程度の数の貢献者を集めてきました。2024年半ばに、Beancountバージョン3が新しい安定ブランチとして正式にリリースされました。このリリースには、いくつかのコンポーネントの分割が含まれていました:例えば、beangulpリポジトリ(インポーター用)とbeanqueryリポジトリ(クエリツール用)は現在beancountGitHub組織の一部であり、やや独立してメンテナンスされています。メインのBeancountリポジトリは中核の会計エンジンとファイルパーサーに焦点を当てています。2025年の時点で、BeancountのGitHubは活発なイシューディスカッションといくつかの進行中の開発を示しています - 量は多くありませんが、イシューとプルリクエストが少しずつ入り、バグ修正や機能の改良のための更新が時々行われます。 -
Fava開発: ウェブインターフェースであるFavaは、別のプロジェクトとして始まりました(2016年に著作権を取得したDominic Aumayrによって作成)。独自の貢献者コミュニティがあり、
beancount/favaの下でGitHubにもあります。Favaのメンテナーと貢献者(近年のJakob Schnetz、Stefan Otteなど)は、数か月ごとのリリースでインターフェースを積極的に改善しています。FavaのGitterチャット(Favaドキュメントにリンク)とGitHubイシュートラッカーは、ユーザーと開発者が新機能やバグについて議論する場所です。プロジェクトは貢献を歓迎しており、CHANGELOGノートが複数のコミュニティメンバーのPRに感謝を示していることからもわかります。FavaのBeancount開発との密接な連携(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を学び使用するための高品質なリソースがいくつかコミュニティによって作成されています:
-
Beancountドキュメント(GitHub Pages上、Martinが維持するソースのGoogle Docs) - 会計の理論とBeancountがそれをどのように実装するかを含む非常に包括的。
-
多数のブログ投稿と個人的なノート - 例えば、LWN.netには「Counting beans... with Beancount」という記事があり、多くの個人ブログ(Awesome Beancountの「ブログ投稿」セクションにリストされている)が経験とヒントを共有しています。これらは知識を構築し、新しいユーザーを引き付けるのに役立ちます。
-
トークとプレゼンテーション: Beancountはミートアップやカンファレンスで発表されてきました(例えば、2018年のPyMunichでの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を訪れて研究ログと方法を探索してください。
2026-09-15の時点で、Beancountエコシステムはモジュラーv3ラインで進化し続けています。2024年半ばのv3カット以降の注目すべき開発と、まだロードマップ上にあるものを以下に示します:
-
Beancount 3.2.x(2025–2026): 3.0がスタックをモジュール化した後、PyPIは3.2.0(2025-09-14)とその後の3.2.1–3.2.3パッケージングリリース(CHANGES、PyPI)を通じて進みました。その期間のユーザーに見える作業には、フォーマット、許容度/精度の改良、より広いPython/CIカバレッジが含まれます - C++コアの書き直しではありません。アップグレードは一致する
beanquery/beangulpメジャーとペアにしてください。 -
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設定ファイルはありません。同様に、クエリはbeanqueryを介して実行され、Beancountコアとは独立してインストールおよび更新できます。このモジュール化アプローチは、メンテナンスを容易にし、コミュニティ貢献を促すように設計されました。また、Beancountのコアをスリム化し、コアは解析と会計ロジックに純粋に焦点を当て、補助的な機能は別々に進化できます。ユーザーの観点からは、アップグレード後にコマンドを調整する必要があります(例:beanqueryからbean-queryを使用するか、これを抽象化するFavaを使用)。Favaのチェンジログはこれらの変更を明示的に述べています:Favaは現在beanqueryとbeangulpに依存し、Beancount 3と2でインポートワークフローを異なる方法で処理します。 -
パフォーマンス改善: パフォーマンスはBeancountの設計を再考する動機の1つでした。v3計画(Martinの「V3目標」ドキュメントで概説)には、パーサーの最適化と、ロードプロセスをより高速でメモリ集約的でないものにする可能性が含まれていました。2025年までに、これらの改善の一部が実現されました。逸話的には、非常に大きな台帳(数万の取引、または多くの株式取引)を持つユーザーは、最新バージョンでのパフォーマンスが向上したと報告しています。例えば、「マイクロ投資取引」を扱っていてパフォーマンスの問題に直面したユーザーは、Google Groupでこれらの懸念を述べました - この種のフィードバックはおそらくv3に影響を与えました。新しいパーサーはより効率的で、より明確な方法で書かれており、将来拡張できる可能性があります。さらに、Fava 1.29はより効率的なファイル監視メカニズム(
watchfilesライブラリを使用)に移行し、台帳が変更されたときの応答性を向上させました。将来的には、コミュニティは大きな台帳をより迅速に処理するためにインクリメンタル解析(すべてを再処理する代わりにファイルの変更部分のみを再処理)を探求するかもしれません - これはドキュメントで「Beancountサーバー / インクリメンタル予約」のアイデアとして示唆されました。 -
投資追跡の強化: 投資とポートフォリオレポートをより良くするための継続的な作業があります。例えば、平均原価基準とFIFOの扱いが長く議論されてきました。Beancountはロットの一致を強制しますが、一部のユーザーは特定の管轄区域で平均原価を好みます。原価基準予約をより柔軟にする提案と議論が存在します(おそらくプラグインまたはオプションを介して)。2025年までに、平均原価の組み込みスイッチはありませんが、v3の基盤(予約再設計)により、プラグインが実装しやすくなりました。税を最小化するためにどのロットを売却するかを提案できるコミュニティプラグイン「Gains Minimizer」がリリースされ、投資周りで構築されている高度なツールの種類を示しています。Favaも、ポートフォリオサマリー拡張機能(利回り計算付き)などの機能を追加しました。今後の機能に関しては、この領域でより多くが期待できます:自動ポートフォリオリバランス提案やリスク分析など、おそらくBeancountデータを読み取る外部ツールとして(データはすべてそこにあるため)。
-
新しいプラグインと拡張機能: プラグインエコシステムは継続的に成長しています。最近の注目すべき追加には以下が含まれます:
- 予算報告ツール - 例えば、FavaのUIを使用しない場合のシンプルなCLI予算レポーター。
- 暗号化とセキュリティ - 台帳が保存時に暗号化された状態でFavaをオンラインでホストできるようにするfava-encryptセットアップが導入され、財務の自己ホスティングの懸念に対処しました。
- 生活の質のプラグイン -
autobean-format(ファイルを解析して再印刷することでより多くのコーナーケースを処理できる新しいフォーマッタ)やエディターへのbeancheck統合(Emacsのflymake)など。
今後、コミュニティはプラグインを介してギャップを埋め続ける可能性が高いです。例えば、より多くの税関連プラグインが見られるかもしれません(一部のユーザーは、ウォッシュセールの計算や特定の地方税レポートなどのスクリプトを共有しています)。
-
潜在的な今後の機能: イシュートラッカーとメーリングリストの議論に基づいて、いくつかのアイデアが地平線上にあります(保証はされませんが):
- 時間解像度: 現在、Beancountは取引の日付のみを追跡します(タイムスタンプはありません)。時間の追加(株式取引や同日取引の順序付け用)についての質問がありました。Martin Blaisは、物事をシンプルに保つためにサブデイのタイムスタンプは範囲外であると明示的に決定しました。これはすぐに変わる可能性は低いです - 今後のバージョンはおそらく時間解像度を追加しないでしょう。時間が必要なら、それをナレーションや口座に組み込むという立場を守ります。
- 強化されたGUI編集: Favaは編集機能を継続的に改善しています。可能性としては、よりフル機能のウェブエディター(自動提案、新しい取引のフォームベースのエントリなど)です。Favaのエディターでtree-sitterを使用した基盤が築かれました。Favaが単なるビューアーではなく、より強力なエディターになり、多くのタスクでテキストエディターを開く必要性が減るかもしれません。
- より良いマルチ台帳サポート: 一部のユーザーは複数のBeancountファイルを維持しています(異なるエンティティや個人対ビジネスの分割用)。現在、ファイルのインクルードは可能ですが制限がありました(インクルードされたファイルのプラグインなど)。最近、外部台帳を安全にインクルードするための
autobean.includeプラグインが作成されました。将来的には、マルチファイルセットアップのファーストクラスサポートが見られるかもしれません - おそらく複数のファイルを持つBeancount「プロジェクト」の概念(これはVSCode拡張機能のbeancount.mainBeanFile設定などの機能によって示唆されています)。これは、マルチエンティティ簿記を実行している人や台帳をモジュール化したい人に役立ちます。 - リアルタイムまたはインクリメンタル計算: 台帳が成長するにつれて、レポートを迅速に再計算する能力が重要になります。実行を続け、取引が変更されるにつれて結果を更新するBeancountサーバーのアイデアがあります。これはFavaの最適化またはエディタープラグインがクエリできるデーモンとして現れるかもしれません。おそらく将来のFavaリリースは、継続的に実行されるBeancountプロセスを活用して、巨大な台帳のUIをより応答性の高いものにするでしょう。
- ファンド会計 / 非営利機能: Beancountでのファンド会計に関する拡張提案がありました。非営利組織には会計ニーズ(制限付きvs制限なしファンド)があり、Beancountのタグまたは口座階層でモデル化できる可能性があります。議論はまだ組み込み機能につながっていませんが、より多くの非営利団体がBeancountを採用すれば、これは新しい機能(おそらく文書化されたベストプラクティスまたはファンド残高追跡用のプラグイン)を推進する可能性があります。
-
長期的展望: Martin Blaisは、Beancountの未来をコアをよりエンジンにし、より多くの機能をプラグインに移すことにあると示唆しました。これは私たちが見るもの(v3のモジュール化)と一致しています。したがって、哲学的な意味での「今後の機能」はより大きな拡張性です - おそらくプラグインが新しいディレクティブタイプを定義したり、構文を制御された方法で拡張したりできるようにすることです。それが起こると、Beancountのコアは比較的小さく安定したままで、エコシステムがアドオンとしてほとんどの新機能を提供するかもしれません。これはプラグインマーケットプレイスや、ユーザーが選択できるようにプラグインのより集中化されたリストにつながるかもしれません(Awesome Beancountリストはその始まりです)。
結論として、2026年のBeancountエコシステムは活発で進化しています。Beancount 3.0のリリースは主要な基盤となるイベントでした;3.2.xラインとFavaのBeancount-3のみの姿勢(1.30.13以降)が、今日引用する実用的なベースラインです。パフォーマンス、ツーリング、使いやすさ(特にFavaとbea CLIを介して)の改善は、参入障壁を引き下げ続けています。Beancountは依然としていくつかの専門知識を必要とするツールですが、これらの開発のおかげで、数年前よりもはるかに親しみやすくなっています。今後の機能は、コア哲学の劇的な変更ではなく、体験の洗練 - より速いパフォーマンス、より良い統合、専門的な拡張機能 - に焦点を当てる可能性が高いです。コミュニティの軌道は、Beancountがプレーンテキスト会計の中心的存在として成熟し続け、複式簿記の禁欲的な力と現代のソフトウェアの利便性のバランスを取ることを示唆しています。Hacker Newsのあるユーザーが言ったように、プレーンテキスト会計はあなたの財務を理解するための「スーパーパワー」を与えます - そして、Beancountの最近および将来の改善は、そのスーパーパワーを誰にとっても使いやすくすることを目指しています。
出典: Beancountのドキュメントとリポジトリ;Favaのドキュメントとチェンジログ;Martin Blaisによる「BeancountとLedgerの比較」;Awesome Beancountリソースリスト;ユーザー体験とコミュニティレポート;PyPIパッケージバージョン(2026-09-15確認)。





