メインコンテンツへスキップ

BeancountとFavaがリアルタイムダッシュボードを実現する仕組み

BeancountとFavaがプレーンテキストの台帳をライブダッシュボードに変えます:クエリ可能な残高、チャート、リアルタイムの財務分析機能。

はじめに​

Beancountは、プレーンテキストファイルを台帳として使用するオープンソースの複式簿記システムです。財務管理においてシンプルさ、透明性、柔軟性を重視しています。FavaはBeancount用の強力なWebベースのフロントエンドであり、レポートの閲覧、可視化、台帳管理のためのインタラクティブなインターフェースを提供します。本レポートでは、BeancountとFavaのコア機能、およびこれらのツールでリアルタイムまたはほぼリアルタイムの財務分析を実現する方法を探ります。自動化とデータ更新の設定のヒント、Favaの可視化機能(瞬時のキャッシュフロー表示とトレンドの発見)、外部ダッシュボード(Grafana、Metabaseなど)との統合、カスタムダッシュボードとプラグインの例、個人および中小企業の財務におけるユースケース、他のプラットフォーム(Power BI、QuickBooks)との比較、そしてデータ駆動型のインサイトのためにFava+Beancountを使用するメリットとデメリットを網羅します。

実際の台帳の例をご覧ください:

新しいタブで Example Ledger を開く

ビットコイン、イーサリアム、ソラナの残高と純資産チャートを追跡するbeancount.ioの暗号通貨ポートフォリオダッシュボード

実際の台帳を見る →

BeancountとFavaの主要機能​

Beancount(プレーンテキスト会計エンジン)​

  • プレーンテキストによる複式簿記台帳: Beancountはトランザクションを単一の.beancountテキストファイル(または複数のファイルをまとめてインクルード)に保存します。すべてのトランザクションは勘定科目間でバランスが取れている必要があり(借方合計=貸方合計)、会計の完全性が強制されます。プレーンテキスト形式は、データが人間に読める形式であり、バージョン管理が可能で、特定のベンダーに縛られないことを意味します。
  • 柔軟な階層型勘定科目: 任意の勘定科目(例:Assets:Bank:Checking、Expenses:Food:Coffee)を階層で定義できます。Beancountは勘定科目表について意見を持たないため、個人財務、中小企業の帳簿、投資などに使用できます。つまり、「柔軟:個人財務、中小企業の簿記、暗号通貨、株式投資などに対応」 です。
  • 複数通貨と商品: Beancountは複数の通貨と商品(株式、暗号通貨など)をファーストクラスでサポートします。異なる通貨でトランザクションを記録し、為替レート(価格ディレクティブ)を定義し、取得原価を追跡できます。価格データがあれば、「取得原価」または「市場価格」でレポートを生成できます。これによりポートフォリオや国際金融に適しています。
  • 自動チェックと残高: システムは残高アサーション(ある日付に勘定科目の残高が_あるべき_値を宣言でき、一致しない場合はBeancountがエラーを出す)と、決算処理のための残高トランザクションをサポートします。また、純資産開始/終了エントリをサポートし、期間決算のための利益剰余金計算も保持します。これらは帳簿の一貫性を保ち、エラーを早期に発見するのに役立ちます。
  • 強力なクエリとレポートエンジン: BeancountにはBQL(Beancount Query Language)というクエリ言語が付属しています。ターミナルでBQLを使うにはbea query、標準的な財務諸表にはbea reportを使います。古い上流のconsole scriptではなくCLIクイックスタートをインストールしてください。カスタムレポート(例:支払先別の経費リスト、期間のキャッシュフロー)を台帳に対してクエリでき、本質的に台帳をデータベースのように扱えます。数千のトランザクションでも高速を維持します。bea query -f csv -o report.csv "BQL"でCSVをエクスポートできます(BQLをクエリに置き換えてください)。完全な例は財務報告テンプレートを参照してください。
  • プラグインによる拡張性: BeancountはPythonで書かれており、カスタムプラグインで機能を拡張できます。プラグインはファイル処理時に追加のルールや計算を適用できます(例えば、税ロットを扱うプラグインや、購入に取得原価が欠落していないことを確認するプラグインがあります)。プラグインシステムとPython APIにより、上級ユーザーはカスタム動作をスクリプト化したり、Beancountを他のシステムと統合できます。
  • 外部データ用のインポータ: 実用的な重要機能は、別パッケージbeangulpのインポータフレームワークです(Beancount 3.2.3にはbeancount.ingestモジュールはありません)。beangulp.Importerをサブクラス化し、identify、extract、accountを実装するインポータクラスを書きます。ダウンロードしたファイル(CSV、OFX、PDF明細など)を解析し、Beancountエントリに変換します。これは自動化に不可欠です(後述)。
  • 監査可能でバージョン管理に優しい: プレーンテキストであるため、台帳をGitやその他のバージョン管理下に置けます。すべての変更は透明で、編集の完全な履歴があります。これにより監査や変更のレビューが容易になります(多くのユーザーは毎日の変更をGitリポジトリにコミットし、すべての財務エントリの改ざん検知可能なログを提供します)。この透明性のレベルは、クローズドな会計ソフトウェアとの主要な差別化要因です — 「SaaSのロックインはなく、強力なレポートを備えたクリーンで透明な会計だけ」。

Fava (BeancountのためのWebインターフェース)​

  • インタラクティブなWeb UI: FavaはローカルWebサーバーを提供し、Beancount台帳をリッチなUIにレンダリングします。コアレポート(損益計算書、貸借対照表など)、勘定科目元帳、仕訳帳をブラウザでインタラクティブなコントロール付きで表示します。UIはコマンドラインと比べて動的でユーザーフレンドリーです。シンプルなfava yourfile.beancountで起動し、帳簿用のWebアプリを取得できます。
  • 組み込みのグラフとチャート: Favaはデータの可視化を助けるグラフを生成します。例えば、時系列での純資産折れ線グラフ、月ごとの収入対支出の棒グラフ、経費内訳の円グラフ/ツリーマップがあります。これらのビジュアルはデータとともに更新され、さまざまなビュー(投資の「取得原価」対「市場価格」など)をサポートします。これらの可視化機能については後で詳しく探ります。
  • フィルタリングと検索: Favaのページ上部には、データをリアルタイムでスライス&ダイスできるフィルタバーがあります。時間(年、四半期、月)、勘定科目の正規表現、支払先、摘要、タグ/リンクでフィルタできます。これにより_リアルタイムのデータ検査_が容易になります。例えば、「Tag=Travel」と「Year=2025」で素早くフィルタして2025年のすべての旅行費を合計付きで確認できます。このインターフェースは、フィルタバーまたはQueryページ(BQLクエリを直接実行可能)を通じて複雑なクエリをサポートします。
  • 複数ファイルのサポートと統合: Favaは複数のBeancountファイルを一度に読み込むことができ(台帳を分けている場合に便利)、それらを切り替えられます。必要に応じて統合することもできます(例えば、個人とビジネスの台帳を一緒に表示)。
  • データ入力と編集: ユニークなことに、Favaは読み取り専用ではありません — エディタとトランザクション入力フォームがあります。Webフォームから新しいトランザクションを追加できます(.beancountファイルにエントリを挿入します)。また、Favaからソースファイルを外部エディタで開くこともできます。Favaはパワーユーザー向けのキーボードショートカットもサポートしています。これによりFavaは、同じインターフェースからデータを入力・表示できる軽量な会計システムになります。
  • レポートと勘定科目のドリルダウン: Favaは標準的な会計レポートを提供します:損益計算書(Profit & Loss)、貸借対照表、試算表、投資の保有銘柄リスト。貸借対照表と損益計算書はインタラクティブで、勘定科目をクリックして詳細にドリルダウンしたり、資産の取得原価表示と市場価格表示を切り替えたりできます。Favaは価格データがあれば投資の「未実現利益」も表示します。すべてのエントリの仕訳帳ビューを生成し、その仕訳帳をさまざまな基準でフィルタできます(特定のトランザクションを見つけるのに最適)。
  • ドキュメント管理: 領収書や明細を添付する場合、Favaがそれらの整理を支援します。Beancountにはドキュメントフォルダの概念があり、Favaでは勘定科目やトランザクションにファイルをドラッグ&ドロップでき、それらを保存して台帳にドキュメントエントリを追加します。これは台帳データと裏付けとなるドキュメントをリンクさせるのに便利です。
  • 拡張機能によるカスタマイズ: FavaはPythonで書かれたプラグインで拡張して、新しいレポートや機能を追加できます。一部の拡張機能はバンドルされています(投資のportfolio listレポートなど)。カスタム拡張機能については後で説明しますが、本質的にFavaの設計は拡張APIを通じて新しいページやカスタムJavaScriptの注入を可能にします。つまり、特定の分析やダッシュボードが組み込まれていなければ、上級ユーザーが追加できます。
  • パフォーマンス: Favaは効率的です — データをメモリにリロードし、ページを素早く提供します。基盤となるBeancountの解析は高速なので、典型的な個人台帳は1〜2秒で読み込まれます。実際には、Favaは長年の個人台帳を処理できますが、極端に大きなファイル(数万のトランザクション)は最適化(古いエントリのアーカイブなど)の恩恵を受けるかもしれません。
  • Webアクセスとモビリティ: FavaをサーバーやノートPCで実行することで、任意のブラウザから財務にアクセスできます。一部のユーザーはFavaをプライベートサーバーやRaspberry Piでホストし、外出先で財務を確認しています(Favaには組み込みの認証がないため、パスワードやVPNの背後で保護する場合があります)。これにより、データを第三者に渡すことなく、財務用の自己ホスト型「Webアプリ」を本質的に得られます。

まとめると、Beancountは厳密な複式簿記ルールと複数通貨サポートを備えた、透明なテキストベース会計の堅牢な基盤を提供します。Favaはその上に構築し、アクセスしやすいインターフェースと即時のインサイト(レポート、チャート)、データと対話する能力を提供します。これらが一体となり、エンドツーエンドで制御できる非常に柔軟な会計・分析システムを形成します。

BeancountとFavaによるリアルタイム(またはほぼリアルタイム)分析​

BeancountとFavaでリアルタイムまたはほぼリアルタイムの分析を実現するには、台帳へのデータフローの自動化と、ツールが最新情報を表示するようにすることが含まれます。デフォルトでは、Beancountはバッチプロセスであり(ファイルにエントリを追加し、レポートを表示)、Favaは変更を検出しリフレッシュが必要です。しかし、適切な設定により、新しいトランザクションや変更がほぼ瞬時に表示されるように更新を合理化できます。

ファイル変更検出: Favaは台帳ファイルの変更を監視します。エディタで.beancountファイル(またはインクルードファイル)を編集すると、ページに「File change detected. Click to reload.」という通知が表示されます。Favaはget_changedエンドポイントをポーリングします。ウォッチャーが変更を報告すると、Favaはサーバー側で台帳をリロードし、通知はワンクリックでビューをリフレッシュできます。実際には、このリロードは非常に高速です(典型的な台帳では通常1秒未満)。つまり、台帳ファイルが頻繁に更新されていれば、Favaはライブダッシュボードとして機能します。デフォルトでは、ビューの中断を避けるためにクリックを待ちます。

継続的なインポート/更新パイプライン: リアルタイムデータを得るには、Beancountファイルへのトランザクション追加を自動化する必要があります。いくつかの一般的な戦略があります:

  • スケジュールされたインポートジョブ(Cron): 多くのユーザーはcronジョブ(またはスケジュールされたタスク)を設定して、金融機関から定期的に(例えば毎晩、毎時間)新しいトランザクションを取得し、台帳に追加します。例えば、最新の銀行ダウンロード(CSVまたはOFX)に対してbeangulpインポータを実行するかもしれません。あるBeancountユーザーは、帳簿が自動で更新される自動化パイプラインを構築しました: 「開かれたフォーマットで、私が触ることなく会計帳簿が自動更新されるのを見るのは、純粋な喜びです」。これは銀行APIに接続し、定期的な更新をスケジュールすることで達成されました。銀行API(例:Plaid)を使用したカスタムPythonスクリプトをスケジュールで実行し、新しいエントリを台帳に書き込めます。メインファイルに触れる前に各実行をbea checkで検証してください。スケジュールされたインポートの後、Favaが実行中なら、単純にFavaをリフレッシュして新しいデータを確認できます。

  • ファイルウォッチャーとトリガー: 時間ベースのスケジュールの代わりに、ファイルウォッチャーを使用してイベントに反応できます。例えば、銀行が毎日の明細をメールしたり、フォルダにCSVをドロップした場合、スクリプトがそのファイルを検出し(Linuxのinotifyなどを使用)、即座にインポートルーチンを実行し、Favaにリロードを通知できます。Favaはまだブラウザへのライブリロードのプッシュをサポートしていませんが、少なくともデータは更新されるので、次にページを確認したりリロードをクリックしたときには最新です。一部のコミュニティプロジェクトはさらに進んでいます:ledger(Beancountのいとこ)では、あるユーザーがledgerデータをGrafanaにリアルタイムで公開する小さなサーバーを作成し、同様のアプローチがBeancountでも可能であることを示しました — 本質的にダッシュボードにデータを継続的に供給するデーモンを構築します。

  • 直接的なAPI統合: ファイルを経由する代わりに、上級ユーザーは銀行API(Plaidや地域のOpen Banking APIなど)に直接接続して、頻繁にトランザクションを取得するかもしれません。やる気のある個人は、ループで「ライブ」インポートをスクリプト化できます(適切なレート制限付き) — 実質的に数分ごとに銀行に新データをポーリングします。「Plaid APIにサインアップして同じ[自動化]をローカルで行う」 ことを妨げるものは何もありません。新しいトランザクションは到着するたびにBeancountファイルに追加できます。このアプローチにより、Favaは真にアカウントのリアルタイムダッシュボードとなり、商用アプリの最新フィードに匹敵します。

Favaでのデータリフレッシュ: データが更新されたら、Favaにそれを表示させるのは簡単です:ブラウザリフレッシュ(F5)またはリロード通知をクリックすると、最新の台帳状態が読み込まれます。fava --debugは台帳の変更をブラウザにプッシュしないことに注意してください。そのヘルプテキストは「Turn on debugging」です。Fava自体のコード用のWerkzeugデバッガとコードリローダを実行し、Jinjaテンプレートの自動リロードを設定します。これは拡張機能開発中にサーバーコードとページテンプレートをリロードします。台帳の変更を検出するファイルウォッチャーとは無関係です。あるいは、カスタムフロントエンドを構築しているなら、Favaのget_changedエンドポイントをポーリングし、新しいデータを報告したときにリフレッシュさせることができます。

瞬時の計算: Beancountの高速な解析は、台帳ファイルを数分ごとに更新しても、データ取得→ファイル更新→Favaリロードのターンアラウンドが速いことを意味します。例えば、あるユーザーはファイル編集後にFavaをリロードすることが「ほとんど気づかない…確実に1秒未満」だと述べています(適度なサイズの台帳の場合)。したがって、Favaウィンドウを開いたままにして定期的にリフレッシュを押すことで、ライブダッシュボードを模倣できます。(真にライブな体験には、ブラウザを自動リフレッシュする小さなスクリプトを構築したり、ブラウザのN秒ごとのリフレッシュ機能を使用できます。)

照合とアラート: リアルタイムデータを信頼するには、残高を頻繁に照合することも望ましいです。Beancountはこれを残高アサーションと_「up-to-date」インジケータ_で容易にします。実際、Favaはopenディレクティブがfava-uptodate-indicationメタデータを持つ場合、勘定科目を緑、黄、赤に色分けします。色は、最近の残高チェックが勘定科目の最新エントリをカバーしているかどうかを反映します。これは、台帳の勘定科目残高が銀行の最新明細と一致するかどうかを素早く確認するのに使用できます。ほぼリアルタイムの設定では、毎日の残高チェックを自動化するかもしれません(毎朝、台帳に各勘定科目の銀行の前日終値残高があるように)。Favaのインジケータは、自動インポートが何かを見落としたか、不一致があるかを教えてくれ、表示される「ライブ」データが正確であるという確信を提供します。

自動化の例: 毎日のキャッシュフロー更新が欲しいとします。毎晩3時に実行するcronジョブを設定できます:銀行APIを使用して前日のトランザクションを取得し、import_today.beancountに書き込み、そのファイルをメイン台帳に追加するPythonスクリプトを実行します。また、日末の残高アサーションも書き込みます。朝起きると、Favaを開きます — 昨日までのすべてのトランザクションが表示され、今月の収入/支出が更新されているのがわかります。日中に支出した場合、手動で追加するか(Favaのスマートフォンの新規トランザクションフォーム経由など)、夜間のインポートを待つことができます。このハイブリッドアプローチ(ほとんど自動化され、アドホックな手動追加が可能)は、ほぼリアルタイムの全体像を提供します。別のアプローチは、Favaの仕訳帳ページを開いたままにして元帳として使用することです:支出するたびに素早くトランザクションを記録します(小切手帳に記入するように) — そうすれば、あなた_が_リアルタイムのフィードです。これはより手動ですが、一部のユーザーはそれがもたらす意識を楽しんでいます。手動ステップなしの真に_ストリーミング_な更新には、スクリプトへの投資と、前述のサードパーティAPIの使用が必要です。

まとめると、Beancountのインポート自動化とFavaの高速リフレッシュを組み合わせることで、ほぼリアルタイムの財務データを得られます。QuickBooksのようなサービス(銀行フィードを自動的に取得する)と同じレベルのライブフィードを実現するのは「ボタン一つで簡単」ではないかもしれませんが、可能です — そして重要なことに、プロセスの完全な制御と透明性を保持します。あるプレーンテキスト会計の提唱者が述べたように、事前の少しの努力が、「商用ソリューションよりもはるかに優れ、はるかに柔軟で拡張可能」 な自動システムをもたらすことがあります。次のセクションでは、Favaの可視化機能がこの最新データを即座に理解し、生のトランザクションをインサイトに変える方法を見ていきます。

ホスト型バリュエーションのための管理価格​

Live Pricesはサポートされたバリュエーション価格をホスト型Beancount.io台帳に提供します。ローダーは5分間のリフレッシュウィンドウ後に台帳が読み込まれるときに新データをチェックします。プロバイダの観測値はより古い可能性があります。これはストリーミングフィードではありません。

ここで説明するFavaコントロールはFavaに属します。管理されたインクルードを追加しても、ホスト型ビューアにそれらのコントロールが追加されたり、取得原価ビューが市場価格ビューに変わったりするわけではありません。上流のFavaはローカル価格ファイルを必要とします。互換性のあるbeaバージョンがそれらをエクスポートできます。互換性についてはセットアップガイドを参照してください。

Favaの視覚化機能(キャッシュフロー、トレンド、リアルタイム検査)​

(GitHub - beancount/fava: Fava - web interface for Beancount) Favaの損益計算書レポート(Web UI内)は、収入と支出の構成を素早く把握するためのツリーマップ(写真)やサンバーストチャートなどのリッチな可視化をサポートします。このツリーマップでは、各長方形が経費カテゴリを表し、その金額でサイズが決まります — 家賃(大きな緑のブロック)が経費を支配していることが瞬時にわかります。上部のフィルタバーとコントロール(右上)で通貨、チャートタイプ、期間(例えば月次データの表示)を変更できます。Favaはまた、財務データのトレンドを見つけるのに役立つ折れ線グラフ(例えば時系列の純資産)と棒グラフ(例えば月ごとの収入対支出)も提供します。

Favaの最大の強みの一つは、台帳データを即座に視覚的でインタラクティブなレポートに変えることです。台帳が読み込まれるとすぐに、Favaはキャッシュフローとトレンドを一目で理解しやすくするチャートを生成します:

  • 収入と支出のツリーマップ/サンバースト: 損益計算書ページで、Favaは収入と支出を_ツリーマップ_または_サンバースト_図として表示できます。これらは「一目でわかる」キャッシュフロー可視化に最適です。例えば、月次の経費がツリーマップとして表示される場合、各長方形の面積は各経費カテゴリの大きさに対応します。大きなブロックはお金がどこに最も使われたか(家賃や住宅ローン、税金など)を即座に示し、小さなブロックは少額の経費を示します。これは支出の_トレンドを見つける_のに非常に役立ちます — 「外食」ブロックが毎月増えていれば、視覚的に気づきます。サンバーストチャートに切り替えて階層的な内訳(例えば、外側のリングがFoodカテゴリ内のGroceries対Restaurantsのようなサブカテゴリを表示)を見ることができます。これらのチャートはフィルタした期間(1ヶ月、年初来など)に応じて更新され、その期間の即時のキャッシュフロー可視化を提供します。プレーンテキスト会計フォーラムのあるユーザーは次のように述べました: 「収入と支出のツリーマップを大いに活用しています。私たちの財政の動きについて素晴らしい視覚的感覚を与えてくれます。」 — この種の即時の理解こそが、Favaのチャートが目指すものです。

  • 時系列の純資産と残高: Favaは(「貸借対照表」または「統計」ページで)時系列の純資産の折れ線グラフを提供します。このチャートは各時点(日、週、月ごと)での資産から負債を引いた合計をプロットします。トレンドを見つけるのに非常に貴重です — 財務の軌跡(例えば着実に上昇、または特定の時期に下落)を確認できます。投資がある場合、取得原価表示と市場価格表示を切り替えられます(価格データが記録されている場合) — 例えば、市場価格での純資産は株価とともに変動し、取得原価ではより滑らかであることがわかります。Favaは時系列の勘定科目残高も表示できます。勘定科目(例えばAssets:Bank:Checking)をクリックすると、その勘定科目の残高履歴のグラフが表示されます。現金勘定がどのように動いているかを即座に検査できます — これは実質的にキャッシュフローグラフです(残高線の傾きが純キャッシュフローを示します)。下降傾向なら、その期間で稼ぐより多く使っていることがわかります。これらのトレンドを調べることで、「毎年12月に貯蓄が落ち込む(休日の出費)」とか「今四半期に投資が急成長した」といったパターンに気づくかもしれません。

  • 定期的な比較のための棒グラフ: 損益計算書ビューには、「月次利益」「月次収入」「月次支出」などのタブがあります。これらを選択すると月ごとの棒グラフが表示されます。例えば、月次純利益は各月の黒字/赤字を棒として表示し、月間のパフォーマンスを比較しやすくします。外れ値を素早く特定できます(例えば、4月の大きなマイナスの棒はその月に異常な損失/支出があったことを意味します)。同様に、「月次支出」棒グラフは月ごとのカテゴリ別支出を積み上げたりグループ化したりして、どのカテゴリが変動するかを確認できます。これは時系列のトレンドを見つけるのに最適です — 例えば、「旅行」費が毎年夏に急増したり、「光熱費」が冬に高くなったりすることに気づくかもしれません。Favaは本質的に予算アプリの機能の一部(トレンド追跡)を提供しますが、完全なカスタマイズ性を備えています(カテゴリとそのロールアップ方法を自分で定義するため)。

  • リアルタイムのフィルタリングとデータ検査: Favaの可視化は静的なものではありません。Favaのフィルタリングと連動して機能します。特定のシナリオを検査したいとします:「ビジネス勘定のみの四半期キャッシュフローはどう見えるか?」時間フィルタを2025年第1四半期に設定し、勘定科目をビジネス階層にフィルタできます — Favaはチャートを即座に更新し、純利益、支出のツリーマップなどを、そのサブセットのみについて表示します。このインタラクティブなスライスにより、クエリを書かずにアドホック分析を非常に迅速に行えます。仕訳帳ビューもライブフィルタリングをサポートします:支払先や摘要の部分文字列で検索し、フィルタされたトランザクションリストを即座に表示できます。リアルタイムデータ(例えば先週のトランザクションをインポートしたばかり)を見ている場合、#uncategorizedのようなタグでフィルタして、カテゴリ分けが必要かもしれない新しいトランザクションを確認したり、@pending(保留中のエントリをマークする場合)でフィルタして、まだ消し込まれていないものを確認できます。このリアルタイム検査機能はデータ品質の確保にも役立ちます — その場で異常を分離して対処できるからです。

  • キャッシュフロー計算書(間接法): Beancount/Favaは正式なキャッシュフロー計算書(営業/投資/財務の内訳)をすぐには生成しませんが、カスタムクエリや勘定科目の構造化で模倣できます。例えば、特定のトランザクションにタグを付けたり、投資と財務に特定の勘定科目を使用したりして、合計をクエリできます。FavaのクエリインターフェースはSELECT sum(position) WHERE account ~ 'Assets:Bank:Checking'のようなBQLを実行します。これはチャートの背後にある当座預金残高を返します。以下の実例は完全な往復を示します。とはいえ、ほとんどの個人ユーザーは、残高トレンドと収入/支出チャートの組み合わせがキャッシュフローを理解するのに十分だと感じています。

  • 保有銘柄とポートフォリオの可視化: Holdingsページで、Favaは現在の商品(株式、債券、暗号通貨など)の保有を数量、取得原価、市場価格、未実現利益とともにリストします。これはチャートではなく表ですが、ポートフォリオの状態をリアルタイムで検査するのに非常に便利です。一部のコミュニティ拡張機能(_fava-investor_など、後述)は、ポートフォリオのより多くのビジュアル(配分円グラフやパフォーマンスグラフなど)を追加します。拡張機能なしでも、最新価格時点での株式ポートフォリオ価値の変化を確認できます — 価格クォートを定期的に更新する場合(毎日自動化可能)、Favaのチャートは利用可能な最新の日付の価格を反映しますが、これはレポートを開く時刻より古い可能性があります。

実践例:2ヶ月分の支出​

この例はBeancount 3.2.3とbeanquery 0.2.0でエンドツーエンドで実行されます。台帳をexample.beancountとして保存します。2回の給与支払いと4つの支出が含まれます。

option "title" "Analytics example"
option "operating_currency" "USD"
 
2024-01-01 open Assets:Bank:Checking USD
2024-01-01 open Expenses:Food:Groceries USD
2024-01-01 open Expenses:Food:Dining USD
2024-01-01 open Expenses:Housing:Rent USD
2024-01-01 open Income:Salary USD
2024-01-01 open Equity:Opening-Balances USD
 
2024-01-05 * "Employer" "January salary"
  Income:Salary  -3000.00 USD
  Assets:Bank:Checking  3000.00 USD
 
2024-01-08 * "Grocery Store" "Weekly groceries"
  Expenses:Food:Groceries  120.00 USD
  Assets:Bank:Checking  -120.00 USD
 
2024-01-12 * "Restaurant" "Dinner out"
  Expenses:Food:Dining  80.00 USD
  Assets:Bank:Checking  -80.00 USD
 
2024-02-01 * "Landlord" "February rent"
  Expenses:Housing:Rent  1000.00 USD
  Assets:Bank:Checking  -1000.00 USD
 
2024-02-05 * "Employer" "February salary"
  Income:Salary  -3000.00 USD
  Assets:Bank:Checking  3000.00 USD
 
2024-02-10 * "Grocery Store" "Weekly groceries"
  Expenses:Food:Groceries  150.00 USD
  Assets:Bank:Checking  -150.00 USD

まず確認します。次にカテゴリ別支出クエリを実行します。

bea --file example.beancount check
bea --file example.beancount query "SELECT account, sum(position) WHERE account ~ 'Expenses' GROUP BY account ORDER BY account"

クリーンな台帳はbea checkから終了コード0で終了します。エラーは非ゼロの終了コードでリストされます。クエリは経費勘定科目ごとに1行を返します。

        account          sum(position)
-----------------------  ------------
Expenses:Food:Dining        80.00 USD
Expenses:Food:Groceries    270.00 USD
Expenses:Housing:Rent     1000.00 USD

さらに2つのクエリで全体像が完成します。総収入と総支出:

SELECT sum(position) WHERE account ~ 'Income'
SELECT sum(position) WHERE account ~ 'Expenses'

これらは(-6000.00 USD)と(1350.00 USD)を返します。つまり、世帯は6,000.00 USDを稼ぎ、1,350.00 USDを使い、77.5%を貯蓄しました。当座預金残高がそれを裏付けます:

SELECT sum(position) WHERE account ~ 'Assets:Bank:Checking'

これは(4650.00 USD)を返します。同じクエリはFavaのQueryページでそのまま実行されます。Fava 1.30.16は同じ3つの経費行をインタラクティブなテーブルとしてレンダリングします。

実際には、Favaのビジュアルレポートは基盤となるデータと同じくらい速く更新されます。新しいトランザクションが追加されページがリロードされた瞬間、チャートは再計算されます。長い再処理は必要ありません。つまり、一日中データを供給する半自動パイプラインがあれば、Favaを開いたままにして定期的にリフレッシュを押すことで、更新されたチャートを取得できます — 実質的に_リアルタイムの財務モニタリング_です。

例えば、中小企業を経営していて、手元現金と毎日の支出を監視したいとします。Favaをカスタムダッシュボード(おそらく拡張機能やクエリ画面を使用)に開いて、「今日の現金勘定残高」と「支出 — 今日対昨日」を表示できます。新データが入った後にリフレッシュするたびに、それらの数値が更新されるのを見るでしょう。これは高価なリアルタイムダッシュボードが提供するものに似ていますが、オープンソースツールを使用しています。違いは、手動でリフレッシュするか、リフレッシュをスケジュールする必要があるかもしれませんが、それらのツールは更新を自動的にプッシュすることです。しかし機能的には、得られるインサイトは同じで、Favaの任意の数値をドリルダウンできるという追加の利点があります(クリックして基盤となるトランザクションを確認) — 多くのBIダッシュボードに欠けているものです。

まとめると、Favaは会計データを即座に視覚的インサイトに変えます:キャッシュフローの内訳、トレンドライン、時系列比較、インタラクティブなフィルタリングがすべて、数値の背後にあるストーリーを見るのに役立ちます。先週の支出の異常を検査する場合でも、純資産の複数年のトレンドをレビューする場合でも、Favaのチャートとレポートはリアルタイムで(データがあればすぐに)明確さを提供します。次に、さらにカスタマイズされた分析が必要な場合に、これらの機能を拡張したり外部ツールと統合したりする方法を見ていきます。

外部ダッシュボードおよび可視化ツールとの統合​

Favaは豊富な組み込みレポートとチャートを提供しますが、BeancountのデータをGrafana、Metabase、カスタムWebフロントエンド(Reactアプリなど)などの他のビジネスインテリジェンス(BI)ツールやダッシュボードツールと統合したい場合があります。動機としては、財務データを他のデータソースと組み合わせる、高度なチャート機能を使用する、異なる形式で他の人とダッシュボードを共有するなどがあります。Beancountのオープン性のおかげで、統合を実現する方法は複数あります:

  • データベース統合(BeanSQL / Beanpost): 一つの簡単なアプローチは、Beancount台帳をSQLデータベースにエクスポートまたは同期することです。SQLに入れば、任意のBIツールがデータをクエリできます。実際、コミュニティメンバーがこのためのツールを作成しています。例えば、BeanpostはBeancount台帳をPostgreSQLデータベースにミラーリングし、Beancountのロジックの多くをSQL関数として実装する実験です。これは_「Webアプリやレポートシステムなど他のツールと統合できる柔軟なバックエンド」_ を提供します。Beanpostを実行してテキスト台帳をPostgresに継続的に同期できます。その後、MetabaseやTableauのようなツールがそのPostgresデータベースに接続し、任意のチャートやダッシュボードを構築できます(DBの更新に合わせてライブ更新)。あるユーザーはPostgres + PostGraphileを使用して台帳データ用のGraphQL APIを自動的に公開し、その上にカスタムReactフロントエンドを書いたと報告しました — 本質的に台帳をWebサービスとして扱っています。このアプローチは、Favaのインターフェースでは不十分な場合(マルチユーザーアクセス、よりモバイルフレンドリーなUIなど)に対応します。よりエンジニアリング重視ですが、可能性を示しています:Beancountを現代のWebスタックと比較的簡単に統合できます。より軽量な変種は、クエリ結果をSQLiteにエクスポートすることです — bea --file ledger.beancount query "SELECT ..."を実行すると、貼り付けたりパイプしたりできるテーブルが出力され、CLIからのスプレッドシートCSVはbea queryのネイティブエクスポートオプションを待っています。一部の人はSQLiteを中間として使用し、Metabaseのようなツール(接続を介してSQLiteファイルを読み取れる)に接続します。

  • Grafana(時系列ダッシュボード): Grafanaはモニタリングと時系列データで人気です。時系列の財務データ(支出、残高)は時系列として扱えます。BeancountをGrafanaに接続するコミュニティの議論がありました。一つのアイデアは、Beancountファイルに対してオンザフライでBQLクエリを実行できるGrafanaデータソースプラグインでした。これにより、Grafanaパネルが例えば「当座預金残高」をゲージとして、または「過去30日間の支出」をグラフとして、台帳をクエリして直接表示できます。現在(2025年時点)では、専用のプラグインは公開されていませんが、愛好家たちはアドホックなソリューションを構築しています。例えば、Redditユーザーの_aquilax_はLedger CLIデータをGrafanaで利用可能にするシンプルなサーバーを構築し、grafana-ledger-datasource-serverとして共有しました。同様の概念がBeancountにも適用できます:BeancountのAPIを使用してデータをクエリし、Beancount台帳を読み込み、Grafana用のJSONデータフレームを返すエンドポイントを公開する小さなHTTPサーバーをPythonで書きます。Grafanaには汎用JSONデータソースプラグインがあり、このAPIからプルできます。実際には、これは「月次収益(棒グラフ)」や「日次現金残高(折れ線グラフ)」などのパネルを持つGrafanaダッシュボードを設計でき、それらのパネルがBeancount駆動のAPIからデータを取得することを意味します。Grafanaは豊富な可視化オプション(注釈、しきい値、サーバーメトリクスとの組み合わせなど)を可能にします。Andreas Gerstmayr(Favaのメンテナの一人)はまさにこのアプローチを提案し、完全なGrafanaセットアップの代替として、BQLクエリからチャートをレンダリングするfava-dashboardsという_Fava拡張_を作成したと述べました(後述)。GrafanaのUIを好むなら、統合は可能です — データブリッジを構築するだけです。

  • Metabase(アドホッククエリとダッシュボード): Metabaseは、コードなしでクエリを実行しダッシュボードを作成できるユーザーフレンドリーなBIツールです。台帳をリレーショナル形式にエクスポートする(Beanpost経由またはトランザクション、ポスティングなどのテーブルを書き出す)と、Metabaseをそのデータベースに向けられます。台帳からexpenses (date, category, amount)のようなカスタムテーブルを作成し、Metabaseで簡単にチャートを生成できます(例えば、先月のカテゴリ別支出の円グラフ)。利点は、非技術系ユーザー(または同僚)がBeancountファイルに触れることなく、MetabaseのGUIを通じてデータと対話できることです。欠点は、エクスポート/同期を維持する必要があることです。一部のユーザーはBeancount台帳のSQLiteへの夜間変換を自動化し、MetabaseにSQLiteを読ませています。他の人は前述のPostgresアプローチを使用するかもしれません。鍵は、Beancountのデータポータビリティがこれを可能にすることです — 外部ツールが必要とする任意の形式にデータを自由に複製できます。

  • カスタムフロントエンド/アプリケーション: 特定のニーズがあれば、Beancountの上にカスタムアプリケーションをいつでも書けます。Beancount Pythonライブラリは解析されたすべてのエントリ、残高などへのアクセスを提供するので、Python Webフレームワーク(Flask、Django、FastAPI)を使用してカスタマイズされたアプリを構築できます。例えば、中小企業は台帳をクエリし、おそらく非台帳データ(サービスした顧客数など)と組み合わせて、KPIメトリクス(粗利益率、日次売上など)を表示するダッシュボードを構築するかもしれません。あるコミュニティメンバーは、Favaが配偶者にとって直感的でなかったため、モバイルフレンドリーなWeb UIを構築しました — データベース内の台帳を活用してこのカスタムUIを駆動しました。JavaScript/TypeScriptを好むなら、台帳をJSONに変換するツールを使用してそこから構築できます。Fava自体はJSONクエリAPIを通じてQueryページを公開しているので、カスタムフロントエンドは新しいクエリバックエンドを構築する代わりに、BQLを送信して返されたテーブルをレンダリングできます。

  • Excel/PowerBI統合: ExcelやPowerBIと統合することもできます。bea queryがネイティブCSVエクスポートを得るまでは、Excelが直接開くスプレッドシートファイルにはFavaのQueryページエクスポートを使用します。ワークフローとしては、夜間ジョブがBeancountから主要な財務数値のCSVファイルを生成し、PowerBIがそのファイルをインポートするように設定できます。これは少し間接的ですが、Excel/PowerBIをすでに多用している組織にとっては、摩擦の少ない統合です。PowerBIはPythonデータソースもサポートしているので、BQLクエリを実行する短いPythonスクリプトを書き、それをPowerBI内のデータソースとして使用して直接接続を実現できます。

ケーススタディ — Grafana統合のアイデア: BeancountユーザーのJoshは、メーリングリストでBeancountメトリクスをPrometheusにプッシュし、Grafanaで表示することについて尋ねました。コア開発者は、Prometheusにデータを複製する代わりに、Beancount台帳を直接クエリするGrafanaプラグインまたはサービスの方が良いアプローチだと応答しました。Andreasは、Fava自体の中でカスタムチャートをレンダリングするfava-dashboards拡張を例解として共有しました。結論は:選択肢があります — 既存のBIインフラ(Prometheus+GrafanaまたはSQL+Metabase)経由で統合するか、ニーズを満たすようにFavaを拡張するか(次のセクションで詳しく説明します)。

セキュリティとマルチユーザーの考慮事項: 外部ツールに統合する場合、データの機密性に注意してください。Beancountのプレーンテキストにはしばしばプライベートな財務情報が含まれるので、それを公開するサーバーは保護(認証)すべきです。データをクラウドBIツールに移動すると、プライバシーの一部を失うかもしれません。セルフホスト型ツール(Grafana/Metabaseのオープンソース版)はローカルで実行してそれを軽減できます。また、複数の人がダッシュボードを見る必要がある場合、外部の読み取り専用ダッシュボードの方が、全員にFavaへのアクセスを与える(注意しないとデータを編集できる)よりも好ましいかもしれません。例えば、スタートアップは内部的にBeancountを使用しつつ、部門長が台帳ファイルに触れることなく支出対予算を見られるようにMetabaseを使用できます。

まとめると、BeancountとFavaは他のツールとうまく連携します。少しのグルーコードでデータツールのエコシステム全体を活用できます:BIツール用に台帳データをSQLデータベースにプッシュする、Webアプリ用にAPI経由で提供する、または特殊なライブラリを使用して時系列システムにストリームするなどです。この柔軟性は、Favaの組み込みビジュアルがニッチな要件を満たさなくても行き詰まらないことを意味します — Beancountを信頼できる唯一の情報源として使い続けながら、いつでも別のプラットフォームに統合できます。次に、プラグインとカスタムダッシュボードでFava自体を拡張する方法を見ていきます。これは、ほんの少しの追加機能が必要なだけなら、外部統合よりも簡単な道であることが多いです。

カスタムダッシュボードとプラグインによる Fava の拡張(コード例)​

Favaは拡張可能に設計されています:Pythonで**Favaプラグイン(拡張機能)**を書くことで、新しいページ、チャート、動作を追加できます。これにより、完全に別のアプリを構築することなく、Webインターフェースを特定のニーズに合わせられます。カスタマイズの2つの主要な道を探ります:(1) Fava拡張機能の使用または作成、(2) _fava-dashboards_のようなコミュニティプラグインによるカスタムダッシュボードの設定。

Fava 拡張機能(カスタムプラグイン)​

Fava拡張機能は本質的にfava.ext.FavaExtensionBaseのサブクラスを定義するPythonモジュールです。Favaが起動すると、このモジュールを読み込みアプリに統合できます。拡張機能は新しいレポートページを登録し、イベントにフックし、インタラクティビティ用のカスタムJavaScriptを含めることもできます。Fava 1.30.16は2つをバンドルしています:fava.ext.auto_commitとfava.ext.portfolio_list。その他はpip経由でインストールするか、ゼロから書けます。

拡張機能を有効にするには、台帳ファイルでBeancountのカスタムディレクティブを使用します:

2010-01-01 custom "fava-extension" "my_extension_module" "{'option': 'value'}"

これはFavaに指定されたモジュールを読み込むよう指示します。pip経由で拡張機能をインストールした場合、ここでそのモジュール名を参照します。末尾のオプション文字列は拡張機能の設定です。FavaはそれをPythonリテラルとして解析するので、"{'option': 'value'}"はdictとして渡されます。

例 — Auto-Commit拡張: バンドルされたfava.ext.auto_commitは、Fava経由でファイルを編集したときに変更をgitにコミットします。使用したい場合は、次を追加します:

2025-01-01 custom "fava-extension" "fava.ext.auto_commit"

これはafter_write_source、after_insert_entry、after_entry_modified、after_delete_entry、after_insert_metadataをオーバーライドします。各フックは台帳ファイル自身のディレクトリでgit commitを実行します。したがって、台帳はすでにgitチェックアウト内にある必要があります。これは拡張機能がFavaの編集イベントにどのようにフックするかを示しています。

例 — Portfolio List拡張: バンドルされたfava.ext.portfolio_listは、投資勘定科目をリストするページを追加します。report_title = "Portfolio List"を設定し、テンプレートを同梱します。Favaはそれを検出し、Reportsの下に新しいサイドバーエントリ「Portfolio List」を追加します。また、コンパニオンJavaScriptを読み込むためにhas_js_module = Trueを設定します。明示的に有効にするには、次を追加します:

2025-01-01 custom "fava-extension" "fava.ext.portfolio_list"

(この場合、設定は不要です。)

カスタム拡張機能の作成: リクエストの「Receivables Aging」のようなカスタムレポートページが欲しいとします。次のようなreceivables.pyファイルを作成できます:

# receivables.py
from fava.ext import FavaExtensionBase
 
 
class ReceivablesReport(FavaExtensionBase):
    report_title = "Receivables Aging"
 
    def after_load_file(self):
        # Runs after Fava loads the ledger. Summarise open
        # invoices here so the template only renders.
        self.overdue = [
            txn for txn in self.ledger.all_entries
            if "invoice" in getattr(txn, "tags", set())
        ]

また、ページのHTMLを定義するために、モジュールの隣にtemplates/ReceivablesReport.htmlも作成します。そのテンプレートでは、フックが準備したself.overdueのような属性を読み取れます。この拡張機能を書いたら、台帳に追加します:

2025-01-01 custom "fava-extension" "receivables"

(receivables.pyがBeancountファイルディレクトリまたはPYTHONPATHにあると仮定すると、Favaは名前でそれを見つけられます)。Favaを起動すると、「Receivables Aging」ページが表示されます。

内部的には、Favaは固定されたポイントで拡張機能のメソッドを呼び出します。Fava 1.30.16で利用可能なフックはafter_load_file、before_request、after_entry_modified、after_insert_entry、after_delete_entry、after_insert_metadata、after_write_sourceです。@extension_endpointでデコレートされたメソッドは、さらに拡張機能の下でJSON APIエンドポイントになります。通常、提供されるフックとテンプレートで十分です。

Favaのドキュメントは、拡張システムがまだ進化中であると述べていますが、使用可能です。実際、多くの高度な機能が拡張機能としてプロトタイプされています。

fava-dashboards を使ったカスタムダッシュボード(コミュニティー拡張)​

ゼロから拡張機能を書く代わりに、Favaメンテナが作成したサードパーティのfava-dashboardsプラグインを使用できます。この拡張機能は、YAML設定ファイルで任意のダッシュボードを定義でき、テキスト、テーブル、チャートをBQLクエリで駆動して混在させられます。これは基本的に、複数のカスタムパネルを含む新しい「ページ」をFavaで作成する方法です。

インストールとセットアップ: まずパッケージをインストールします(例:pip install fava-dashboards)。バージョン2.0.2はFava 1.30.16の隣でクリーンに読み込まれます。次に、Beancountファイルで、ダッシュボード設定を指すカスタムディレクティブで有効にします。例えば:

2010-01-01 custom "fava-extension" "fava_dashboards" "{ 'config': '/path/to/dashboards.yaml' }"

(fava-dashboards/README.md at main · andreasgerstmayr/fava-dashboards · GitHub)。これはFavaにfava_dashboardsモジュールを読み込み、設定のためにYAMLファイルを読むよう指示します。

ダッシュボードYAML形式: dashboards.yamlで、1つ以上のダッシュボードとそのパネルを定義します。拡張機能自身のパイプラインから2つのルールがあります。集計列にはASエイリアスが必要です。そしてBQLの符号規則が適用されます:収入の合計は負で、支出は正で到着します。例えば:

dashboards:
  - title: "Cash Flow Dashboard"
    panels:
      - title: "Net Cash This Month"
        width: 50%
        queries:
          - bql: "SELECT sum(position) AS net_cash WHERE account ~ 'Income' OR account ~ 'Expenses'"
        type: "jinja2"
        template: "<h1>{{ panel.queries[0].result[0][0] }}</h1>"
      - title: "Spending by Category"
        width: 50%
        queries:
          - bql: "SELECT account AS category, sum(position) AS total WHERE account ~ 'Expenses' GROUP BY account ORDER BY account"
        type: "jinja2"
        template: "<table>{% for row in panel.queries[0].result %}<tr><td>{{ row[0] }}</td><td>{{ row[1] }}</td></tr>{% endfor %}</table>"

最初のパネルは合計ポジションを直接表示します。実例の台帳では(-4650.00 USD)をレンダリングします。これは6,000.00 USDの収入から1,350.00 USDの支出を引いたものです。2番目のパネルはクエリ行をループしてテーブルにします。このプロジェクトは同じクエリからチャートパネルもレンダリングします。チャートスクリプトAPIについてはリンクされたREADMEを参照してください。

拡張機能は、Favaでダッシュボードページを開いたときにこれらをレンダリングする処理を行います。複数のダッシュボードを作成できます(それぞれがタブまたは別ページとして表示されます)。これはカスタム財務ダッシュボードを作成するのに非常に強力です。例えば、「予算対実績」ダッシュボードを作成できます:1つのパネルがカテゴリ別の予算対実績の表(2つの勘定科目セットを比較するクエリ経由)を表示し、別のパネルが年初来支出対前年の棒グラフを表示するなどです。これらすべてが設定と最小限のスクリプトだけで、BQL経由で台帳データを活用します。

コード例 — fava-dashboardsの有効化: 上記のように、拡張機能の追加は台帳の1行です。完全を期すために、文脈での最小例を次に示します:

option "title" "My Ledger"
option "operating_currency" "USD"
 
plugin "beancount.plugins.auto_accounts"  ; (auto-opens accounts)
 
1970-01-01 custom "fava-extension" "fava_dashboards" "{ 'config': 'dashboards.yaml' }"

そしてdashboards.yamlで:

dashboards:
  - title: "Overview"
    panels:
      - title: "Net Worth"
        queries:
          - bql: "SELECT sum(position) AS net_worth WHERE account ~ 'Assets' OR account ~ 'Liabilities'"
        type: "jinja2"
        template: "<div>Net Worth: {{ panel.queries[0].result[0][0] }}</div>"

実例の台帳では<div>Net Worth: (4650.00 USD)</div>をレンダリングします。実際のダッシュボードはきれいにフォーマットし、より多くのパネルを追加するでしょう。

これが設定された状態で、Favaを実行し「Overview」ダッシュボードにナビゲートすると、計算された純資産が表示されます。その後、必要に応じてテンプレートを改良したりチャートを追加したりできます。

その他の注目すべき拡張機能: fava-dashboards以外にも、コミュニティメンバーは投資分析用のfava-investorや、トランザクションレビュー用のfava-reviewなどのプラグインを構築しています。これらは独自のインストール手順とFava互換性範囲を持つサードパーティパッケージです。インストール前にREADMEを確認してください。コミュニティはプラグインとツールの「awesome-beancount」リストを維持しています。閲覧すれば、ニーズを満たす既製の拡張機能が見つかるかもしれません。

いつ拡張すべきか、いつ外部統合すべきか: 一般に、ニーズが既存の台帳データの純粋なプレゼンテーションや計算であれば、Fava拡張機能が理想的です(すべてを1か所に保ち、フィルタを尊重するなど)。ニーズが外部データの組み合わせを含む場合や、大幅に異なるUIが必要な場合、外部統合(前セクション)が正当化されるかもしれません。例えば、財務と並べてWebサイト分析を表示するのはGrafana/Metabaseの方が良いですが、新しい財務KPIやレポートを追加するのはFavaプラグインの方が良いです。

例 — FavaでのカスタムKPI: 「貯蓄率」(貯蓄された収入の割合)を追跡したいとします。これを計算してメインページに小さなボックスを表示する拡張機能で行えます。またはfava-dashboardsで、1つのパネルが総収入と総支出をクエリしてSavings Rate: X%を出力するJinja2になれます。この種のカスタムメトリクスはこれらのツールで注入するのが非常に簡単ですが、QuickBooksのようなクローズドシステムではダッシュボードに新しいメトリクスを作成することが不可能かもしれません。

同じ2つのクエリが貯蓄率パネルに供給します。符号に注意してください:BQLのsum(position)は収入を負のポジションとして、支出を正として返し、Jinjaはあるポジションを別のポジションから引くことができません。したがって、両方のレッグを表示し、レートをテンプレートテキストに記載します:

- title: "Savings Rate"
  panels:
    - title: "Savings Rate"
      queries:
        - bql: "SELECT sum(position) AS income_total WHERE account ~ 'Income'"
        - bql: "SELECT sum(position) AS expense_total WHERE account ~ 'Expenses'"
      type: "jinja2"
      template: "<h3>Savings Rate: 77.5% ({{ panel.queries[0].result[0][0] }} earned, {{ panel.queries[1].result[0][0] }} spent)</h3>"

実例の台帳ではSavings Rate: 77.5% ((-6000.00 USD) earned, (1350.00 USD) spent)をレンダリングします。レートは(6,000.00 − 1,350.00) / 6,000.00です。大きさから計算してください。テンプレート内でポジションを否定したり引いたりしないでください。

重要なポイント:Favaは静的なツールではありません — 拡張可能なプラットフォームです。少しのPythonまたは単に設定コードで、広範囲にカスタマイズできます。多くのユーザーがフォーラムで小さなスクリプトや拡張機能を共有して、今後の請求書の表示、トランザクションからのPDF請求書生成、Beancountと税計算ライブラリの統合などを行っています。これらの拡張機能の学習や使用に投資すれば、ゼロから始めることなく非常にオーダーメイドの財務分析システムを得られます。

利用ケース:個人の財務管理 vs 小規模事業の会計​

BeancountとFavaは個人と中小企業の会計の両方に使用できますが、ユースケースと利点の強調点は少し異なります:

個人の財務管理​

個人にとって、Beancount+Favaは独自のアプリに頼ることなく財務の完全な可視性とインサイトを提供する点で優れています。一般的な個人財務のユースケースには以下が含まれます:

  • 支出追跡と予算編成: 多くの人はBeancountを使用してすべての支出を記録し、支出パターンを分析します。Favaを使えば、毎月お金がどこに行くか(支出のツリーマップ)を見て、期待値と比較して予算を追跡できます(一部はBudgets拡張機能やカスタムクエリで行います)。あるユーザーは、Beancountを採用した後、「財務データの分析(支出、寄付、税金など)は簡単です。Favaで簡単にでき、スクリプトでも簡単です…BQLを使ってBeancountからデータを引き出し、pandasを使ってレポートを準備するPythonスクリプトが1つあります。」 と述べました。これは個人ユーザーが組み込みUIと、必要に応じてカスタム分析をスクリプト化する能力の両方から恩恵を受ける方法を示しています。

  • 純資産と目標追跡: すべての資産(銀行口座、投資、希望すれば物理的資産も)を1つの台帳に含めることができるため、純資産の単一ビューを得られます。個人財務愛好家はこれを使用して目標(「FIナンバー」や債務返済など)への進捗を追跡します。時系列の純資産を示すFavaのチャートはやる気を起こさせます — 文字通り富の曲線を見ることができます。学生ローンや住宅ローンなどの負債をBeancountで追跡し、残高を更新するのは一般的です。台帳は財務の健全性の完全な全体像を提供します。

  • 投資と暗号通貨: 個人での使用はポートフォリオの追跡にまで及ぶことがよくあります。Beancountは株式、暗号通貨などを、取得原価と実現利益の計算(プラグインやクエリ経由)で処理できます。ブローカーのサイトに対する利点は、すべてのアカウントを統合し、真の資産配分を見られることです。コミュニティプラグイン、例えばfava-investorは、Favaに投資分析ページを追加します。これは通常、趣味の投資家がExcelで行うことです。Beancountはより厳密で自動化された方法を提供します。「Beancount: DeFi Accounting For Noobs」というタイトルのブログ記事は、暗号通貨トランザクションとイールドファーミングの追跡に使用することを示しており、現代の個人財務シナリオでの柔軟性を示しています。

  • 多通貨の個人財務: 海外に住んでいる、または外国の投資を保有している場合、Beancountは通貨を変換・集計できるため非常に便利です。ユーザーは_「多くの会計ソフトは多通貨が苦手です…Beancountでは、任意の商品を定義でき」_、好みの通貨でレポートを得られると述べています。例えばUSDの給与だがEURの支出を扱う個人ユーザーにとって、これは大きな利点です。

  • ライフトラッキングとジャーナリング: 非慣習的ですが実際のユースケース:一部の人は台帳をライフログとして扱い、トランザクションにライフイベントのタグ(例えば#weddingや#vacation2025)を付け、イベントのコストを計算したり、活動の日記として使用したりします(財務メタデータをライフイベントの代理として)。プレーンテキスト形式とタグ付けは、従来のツールでは簡単にできない方法でこれを可能にします。

  • シンプルさと所有権: 個人財務はメンタリティでもあります。多くの人は_「このデータを所有し簡単に分析したい、サブスクリプションやベンダーに縛られたくない」_ ためにBeancountを選びます。人気の無料予算ツールMint.comの最近の終了は、愛好家を長寿のためにプレーンテキスト会計に駆り立てました。Beancountなら、20年後でも台帳を開けるとわかっています。個人の財務にとって、Beancountのデータ(DropboxやGit経由で同期されるかもしれない)とFavaのWeb UI(ローカルまたはプライベートサーバーで実行可能)は、他では見つけにくい利便性と制御のバランスを提供します。

個人使用の潜在的な課題:初期設定と複式簿記の学習が一部の人にはハードルになるかもしれません。しかし多くのリソース(Beancountチュートリアルやコミュニティフォーラムなど)が新規ユーザーを助けます。一度設定すれば、前述のようにメンテナンスは大部分自動化でき、最小限の労力で家計を管理する人にとって素晴らしいです。

小規模事業者の会計​

中小企業、スタートアップ、フリーランサーもBeancount+Favaを使用できますが、ここでの要件にはより正式なレポートやコラボレーションが含まれます:

  • 簿記と財務諸表: 企業はBeancountで総勘定元帳を維持し、請求書、支払書、給与などを記録し、貸借対照表と損益計算書を生成できます。Beancountは必要な発生主義会計をサポートします(勘定科目を売掛金/買掛金としてマークし、収入と売掛金へのポスティングで請求書を記録し、後で入金で売掛金を消し込めます)。Favaはそれらを適切に資産または負債の下に表示します。Redditの議論では、Beancountが企業に適しているか、適切な財務諸表を生成できるか尋ねられました — はい、貸借対照表、損益計算書、(クエリの助けを借りて)キャッシュフロー計算書を生成できます。これらは複式簿記データの単なるビューだからです。落とし穴は、Beancountが特定の会計基準を強制しないことです(それは使用方法次第)。したがって、知識のあるユーザー(または会計士)がビジネスに合わせて勘定科目表を正しく設定すべきです。Beancountがスタートアップに使用されたコミュニティの例があります — あるHNコメント者は_「自分のスタートアップ企業の会計帳簿を管理するためにBeancount + Gitを使うのが本当に楽しい」_ と言いましたが、定期的にエントリを追加するのが少し面倒だと述べました。その面倒さは、前述のようにインポート自動化で軽減できます。

  • リアルタイムの財務モニタリング: 中小企業にとって、キャッシュフローが命です。Favaを使用すると、経営者は銀行残高とキャッシュフローをほぼリアルタイムで監視できます。個人とよく似ていますが、ここではさらに重要です。銀行フィードやインポートを自動化することで、顧客の支払いが入ったか、大きな支出が消し込まれたかを把握できます。QuickBooksは_「ビジネスがリアルタイムでどうなっているかを見られる」_ 銀行フィードを提供します。Beancountでは、独自の銀行統合でこれを再現します。Beancountの利点は透明性です — QuickBooksの時々不可解なマッチングロジックを信頼するのではなく、何がインポートされ、どのように分類されたかを正確に確認できます。

  • 請求書発行と売掛金/買掛金: Beancountには組み込みの請求書発行モジュール(PDF請求書の生成や請求書番号の追跡など)がありません。しかし、創造的なユーザーはアドオンでこれを管理しています。例えば、Jinja2テンプレートやオープンな売掛金エントリを読む外部スクリプトを使用してトランザクションから請求書PDFを生成できます。Beancountの上で軽量な売掛金システムとして機能する「Beanie」というプロジェクトがあります。中小企業は台帳にBeancountを、請求書発行に別のツールを使用し、請求書データをBeancountにインポートするかもしれません。これはQuickBooks(請求書を送信し、支払われたら自動的に記録できる)と比べて余分なステップですが、すべてのデータがオープンな台帳に行き着くことを保証します。

  • 給与と減価償却: これらは中小企業が処理する会計業務です。Beancountは確かに給与エントリ(総支給額、税金、源泉徴収などを適切な勘定科目に分割)を記録できます — ただし通常は外部ツールや給与プロバイダで計算し、入力します。固定資産の減価償却スケジュールも同様に手動で入力します(または毎月の減価償却エントリを自動化するプラグインを書けます)。Beancountにはこれらに関する魔法はありませんが、多くの中小企業ソフトウェアツールもテンプレートを提供する以上のことはしません。利点は、珍しいことをスクリプト化できることです。例えば、カスタムの収益認識スケジュールがあれば、それらの仕訳エントリをPythonでスクリプト化してインクルードできます。

  • 透明性と監査可能性: 企業は、Beancountが明確な監査証跡を提供することを評価するかもしれません。すべてのトランザクションは明白で、ドキュメント(領収書、契約書)へのリンクで注釈を付けられます。監査された場合、台帳ファイルと添付ドキュメントを提示でき、非常に簡単です。また、バージョン管理は誰がいつ変更したかの監査ログがあることを意味します(複数の人がGit経由で協力する場合)。これを、会計士がユーザーに簡単にアクセスできない変更ログを調べる必要があるかもしれないQuickBooksと比較してください。

  • コスト: Beancount+Favaは無料で、ソフトウェアコストを最小化しようとするスタートアップや中小企業にとって魅力的です。QuickBooks、Xeroなどには月額費用があります。ただし、トレードオフは、それらがサポートとより簡単なセットアップを伴うことです。技術に精通した経営者は、コストを節約し柔軟性を得るために多少の時間を喜んで交換するかもしれません。

実際の例:別のHNユーザーは、コンサルティングLLCに使用してうまくいったが、トランザクションが増えると速度を維持するために年ごとにファイルを分割し始めたと言いました。コンセンサスは:_小規模_なビジネス(年間数万トランザクション以下など)には、Beancountは完全に有能です。数十万のトランザクションを持つより大きなSMEなら、パフォーマンスがデータベースアプローチの使用や専用の会計システムの選択を正当化するかもしれません — ただし、Postgresをバックエンドとして使用することでそれに対処しようとするBeanpostがあります。

コラボレーション: 一つの違いの領域 — QuickBooks Onlineは複数のユーザー(オーナー、会計士など)が同時に作業できます。Beancountでは、コラボレーションはGit経由(複数のユーザーが変更をコミット)かもしれません。これは機能しますが、多少のGitの知識と、人々が同時に編集する場合の競合解決が必要です。一部の人はオンラインGitプラットフォームやGoogle Driveを使用して台帳ファイルを共有しています。可能ですが、クラウド会計ソフトほどシームレスではありません。しかし、小さなチーム(またはソロの記帳担当者+オーナー)には管理可能で、Favaを通じて読み取り専用アクセスを付与できます(内部サーバーでホストし、編集せずに他の人にレポートを表示させる)。

規制遵守: 個人財務では問題ありません。ビジネスでは、公式レポートを生成したり会計基準に従う必要があるかもしれません。BeancountはGAAP準拠の財務諸表を生成するのに使用できますが、ユーザーがそれに応じてデータを入力する必要があります。GAAPルールの組み込みの強制はありません(例えば、正しく減価償却することを保証する組み込みの固定資産モジュールはありません)。外部の会計士は依然としてBeancount台帳で作業できます(本質的に一般化された仕訳帳だからです) — 必要に応じてExcelにエクスポートして調整するかもしれません。一部の企業はこの理由で既知のソフトウェアを好むかもしれませんし、少なくともプレーンテキストデータに慣れた会計士を持つかもしれません。

誰がビジネスに使用するか? おそらくパワーユーザー:技術系スタートアップ、コーディングバックグラウンドを持つフリーランサー、またはデータ制御を高く評価する企業(例えば、カスタムレポートを望む金融取引会社など)。Redditスレッドで誰かがBeancountが取引会社に適しているか尋ねました — 回答は、はい、多通貨を処理し必要な財務諸表を生成できるが、その周りにツールを構築することになると示しました。

このセクションを締めくくると:個人財務ユーザーは、個人のお金に対するインサイトと制御のためにBeancountを愛しています — 財務をクエリして学べるデータセットに変え、すべての支出を簡単に追跡し、典型的な予算ツールでは計算できないメトリクスを計算するなどの結果をもたらします。中小企業ユーザーは透明性、コスト削減、ハッカビリティを評価します — 会計をソフトウェアスタックの残りと統合し、ベンダーロックインや月額費用を避けられます。どちらのユースケースもリアルタイム分析の恩恵を受けます:個人は月次予算の進捗を見るかもしれず、企業は毎日のキャッシュフローを見るかもしれません — どちらの場合も、Favaはタイムリーなデータが供給されれば最新情報を提示できます。

他のリアルタイム分析プラットフォームとの比較​

Beancount+Favaを、「リアルタイム」の財務分析を提供する他のソリューション、例えばQuickBooks(ライブ銀行フィード付き)やPower BI(または同様のBIダッシュボード)と比較するのは有用です。各アプローチには、透明性、柔軟性、応答性の面で強みとトレードオフがあります:

側面Beancount + Fava(オープンソース)QuickBooks(銀行フィード付き)Power BI / 汎用BI
透明性とデータ所有権完全に透明 — データはプレーンテキストで、すべてのトランザクションを検査できます。ロジックはすべて可視(隠されたアルゴリズムなし)。形式を永遠に所有します。バージョン管理が変更の監査証跡を示せます。不透明 — データは独自のクラウドデータベースに保存。バックアップにはIntuitのエクスポートに依存。一部のプロセス(自動カテゴリ分類など)は完全には可視でない。限られた監査ログ。支払いをやめると、データへの簡単なアクセスを失うリスク。データソース次第 — Power BI自体は単なるツール。オープンなデータベースに接続されていれば、そのデータの所有権を保持。ただし、Power BIファイルやダッシュボードは独自形式で、表示にPower BIが必要。計算の透明性は良好(自分で定義)だが、システム全体は複雑。
柔軟性とカスタマイズ極めて柔軟。任意の勘定科目構造、任意の商品/通貨を定義可能。カスタム動作や分析をスクリプト化可能(Python、プラグイン)。押し付けられたワークフローなし — ニーズ(個人またはビジネス)に合わせて調整。Favaの拡張システムとfava-dashboardsのようなツールでアプリ内のカスタムダッシュボードが可能。何かが欠けていれば、おそらく自分で構築または統合できる。中程度。QuickBooksは標準的な中小企業会計(請求書発行、給与(別アドオン)、基本レポート)の機能が豊富。しかしIntuitが提供する機能に制限される。勘定科目表とカテゴリはそのパラダイムに適合する必要がある。カスタムレポートは限定的。データベースを任意にクエリできない。統合は存在するがIntuitのAPI(限定的)経由かExcelへのエクスポート。柔軟性を利便性と交換する。分析と可視化には非常に柔軟。データがアクセス可能なら、ほぼ任意のチャートやKPIを作成可能。Power BIは財務データを他のデータ(売上、Web分析など)と簡単にマッシュアップできる。ただし、会計システムではない — データを準備する必要がある(Beancountからかもしれない!)。複式簿記や会計原則を強制しない。白紙の状態。可視化の柔軟性は高い(カスタムDAXメジャーなど)が、専門知識が必要。
リアルタイム応答性設定によりほぼリアルタイム。データ入力を自動化(フィードや頻繁なインポート)すれば、台帳が更新されリロードされるとすぐにFavaが反映。デフォルトでは「プッシュ」リアルタイムではない(手動リフレッシュが必要)が、望むだけ頻繁に更新可能(毎分、毎時)。更新の速度は非常に速い(小さな変更ならテキスト解析はミリ秒)。頻度を制御 — スクリプト化すれば継続的にも可能。ベンダーの同期サイクルを待つ必要なし。銀行トランザクションのほぼリアルタイム向けに設計:「銀行フィードはビジネスがリアルタイムでどうなっているかを見られるようにする。」 実際には、QuickBooks Onlineの銀行フィードは1日1回またはオンデマンドで更新(銀行次第)。新しいトランザクションを自動的に取得し、カテゴリ分類を試みるので、手動でインポートする必要がない。変更は手動介入なしでダッシュボードに表示。ただし、一部のデータ(保留中のトランザクションなど)は消し込まれるまで表示されないかもしれない。また、特定のレポートはアクションが取られるまで更新されないかもしれない。一般に銀行データの応答性は良好。手動仕訳エントリのようなものはそれほどでもない(それでもリアルタイムだが、自分で入力する)。ライブ接続で設定されていれば、ダッシュボードはリアルタイムまたはスケジュールで更新可能。例えば、SQLデータベースに対するDirectQueryを使用したPower BIダッシュボードは、開くたびに更新でき、自動的にも更新可能。Importモードでは、スケジュールでリフレッシュ(毎時など)。したがってほぼリアルタイムにできるが、複雑さはデータパイプラインの維持にある。また、基盤データへの変更はモデルやクエリのリフレッシュを必要とする。設定方法に応じて若干の遅延があるかもしれない(そしてPower BIクラウドを使用する場合、無料層では自動リフレッシュの頻度に制限がある)。
自動化とデータ入力インポートは高度に自動化できるが、カスタム設定が必要。各銀行やデータソース用にスクリプトを書いたり保守したり、コミュニティインポータを使用する必要があるかもしれない。すぐに使える銀行接続はない(自分で作るものを除く)。したがって、初期の自動化設定は手間がかかる。逆に、一度設定すれば、手動入力なしで完全に自動化できる(一部ユーザーは~95%の自動化を達成)。自動化できないものの手動入力もサポート(FavaのWebフォームやテキスト編集)。銀行/クレジットカードフィードには非常に自動化されている(コーディング不要 — QuickBooksでアカウントを接続するだけ)。カテゴリも自動提案(過去データといくつかのMLを使用)。「すべてのトランザクションは即座に同期され、分類されます…QuickBooksはカテゴリを推奨し、時間とともに賢くなります。」 これは大きな利便性の利点 — 手作業が少ない。ただし、自動化は主に金融アカウント向け。他のこと(経費をクラスに分割するなど)は依然として手動レビューが必要かもしれない。また、銀行フィードが壊れた場合、ユーザーは再接続またはファイルをアップロードする必要がある。Power BIはデータ入力とは全く関係ない — データソースが持つ自動化に依存。データソースが手動のスプレッドシートなら、リアルタイムではない。何らかのETLプロセスで更新されるデータベースなら、ほぼリアルタイムにできる。したがって自動化はPower BIに何を供給するかに依存。Power BI自体はソースからのデータリフレッシュをスケジュールできる。要するに、Power BIは自動化されたデータをうまく反映できるが、自動化を_作成_しない(それを供給する自動化されたデータパイプラインが必要)。
コラボレーションと共有テキスト(Gitなど)経由のコラボレーションは強力だが技術的。複数の人が台帳ファイルを編集し変更をマージして貢献できる。Favaはレポートを他の人と共有するために読み取り専用でホストできるが、ユーザーロールやきめ細かいアクセス制御はすぐには備わっていない。単一ユーザーや技術に精通したチームには問題ない。監査人や会計士は、形式に慣れていなければ、作業のためにデータをエクスポート(例えばExcelの試算表)する必要があるかもしれない。権限付きのマルチユーザーWebアクセス(QuickBooks Onlineは会計士、ロールを持つ複数のビジネスユーザーをサポート)。簡単な共有 — 会計士がログインして帳簿をライブで見られる。これはビジネスにとって強み。個人財務ではマルチユーザーはあまり関係ないが、デバイス間のクラウドアクセスは利点(Favaを個人的なクラウド/VPSで実行しても同様に可能)。QuickBooksは他のサービス(給与、銀行ローンなど)とも統合しており、ビジネスに便利でBeancountで再現するのは難しい。Power BIはダッシュボードの共有に優れ、特にPower BI Serviceを使用する場合:同僚にダッシュボードを公開し、Webサイトに埋め込み(適切なライセンスで)、などが可能。インサイトのコラボレーション用に構築されている。ただし、これは分析の読み取り専用共有であり、データの協調編集ではない。複数のユーザーが分析する必要がある場合、BIプロジェクトへのアクセスが与えられれば可能。要するに、財務結果を派手な方法でステークホルダーに伝えるには、Power BIは敵いません。しかし協調的な簿記ではなく、協調的な分析です。
コスト無料(オープンソース)。お金の代わりに時間を費やすかもしれない(セットアップ/メンテナンスに)。Favaの自己ホストは無視できるコスト(PCまたは安いサーバー上なら)。追加ユーザーのライセンス料なし。有料(月額または年額サブスクリプション)。QuickBooks Onlineはプランに応じて月20ドルから70ドル以上の範囲。給与や高度な機能にも料金がある。多くの中小企業はサポートと継続的な更新を含むためこれを支払う。しかし何年も経つとコストが積み上がる。また、購読をやめると完全なアクセスを失うかもしれない。混合。Power BI Desktopは無料だが、Proサブスクリプション(ダッシュボード共有用)は約月10ドル/ユーザー。Office 365などを通じてすでに持っていれば、追加コストはゼロかもしれない。他のBIツールはさまざま(Metabaseのようなオープンソースは無料で実行可能)。ただし、BIソリューションの開発にかかる時間コスト、そしておそらくそのためのデータベースやクラウドインフラの維持コストを考慮。

まとめると、Beancount+Fava対QuickBooks: Beancountは優れた透明性(すべてを確認し制御でき、データが消えたりロックされたりしない)と柔軟性(QuickBooksが期待するものだけでなく、台帳に何でもモデル化できる)を提供します。自動化やUIの磨き込みには、よりDIYが必要です。QuickBooksは中小企業のニーズに最適化されたプラグアンドプレイのソリューション — 銀行フィード、請求書発行、給与(アドオン付き) — で、最小限のユーザー努力でほぼリアルタイムの更新を提供します。ただし、多くの点でブラックボックスです。ソフトウェアがデータを正しく処理することを信頼し、時には間違いを訂正したり、数値にどう至ったかを理解するのが難しいです。多くのBeancountユーザーは、それらのブラックボックスに苛立った人々です。彼らは利便性の一部を明確さと交換します。

Beancount+Fava対Power BI(または他のBI): これらは補完的です。Power BIは会計システムではなく、分析用です。実際、高度な設定ではBeancountを使用してデータを統合し正確性を確保し、そのデータからエグゼクティブダッシュボードを作成するためにPower BIを使用するかもしれません。直接比較すると、Power BIは視覚的な柔軟性とデータソースの組み合わせがより重要です。Favaのチャートは設計上よりシンプル(会計ニーズに焦点)ですが、始めるのに必要な作業がはるかに少ない(台帳ですぐに機能し、モデリング不要)。目標が純粋にインサイトと美しいビジュアルを得ることで、データを準備する用意があるなら、BIツールが適切かもしれません。しかし目標が帳簿を維持し、副産物としてインタラクティブなレポートを得ることであれば、Favaだけで十分なことが多いです。

他の個人財務ツール(MintやYNABなど)やERPシステムとも比較できますが、質問は特にリアルタイム分析プラットフォームに言及しています。リアルタイムの財務ビューの領域では:Beancount+Favaはカスタムのオープンソース「ライブ」財務ダッシュボードのようなもので、QuickBooksはクローズドソースの自動簿記とライブ銀行同期、Power BIは柔軟な分析プラットフォーム(財務特化ではないがデータが供給されれば財務に使用可能)です。

オープンソース対商用を対比する象徴的な引用:「少しの事前努力で、オープンソースツールは商用ソリューションよりもはるかに優れ、はるかに柔軟で拡張可能になり得ます。」 これはトレードオフを要約しています。QuickBooksは洗練されており、一般的なシナリオで最小限の努力でそのまま機能します。しかしそれがやらないことを望むと、壁にぶつかります。Beancountでは壁にぶつかることはまれです — ソースとデータがあり、必要に応じて拡張または統合できます。コストは、いじる用意が必要なことです。

データ駆動型インサイトのためにFavaとBeancountを使用するメリットとデメリット​

最後に、財務分析のソリューションとしてのBeancount+Favaの長所と短所を蒸留しましょう:

利点​

  • 透明性と信頼: すべての計算(合計、残高)は検査できるプレーンテキスト台帳から導出されます。神秘的な動作はありません。これは数値への大きな信頼を築きます — それに基づいて意思決定するなら極めて重要。ロックインのない_「クリーンで透明な会計」_ です。報告された数値を常に基盤となるトランザクションまで追跡でき、それがデータ駆動型インサイトの本質です。

  • 再現性と監査証跡: 台帳をバージョン管理できるため、変更のタイムラインがあります。今月何かがおかしいと思えば、台帳をdiffして何が変わったか確認できます。これは実験(「この経費を再分類したらどうなる?」)して簡単に元に戻せることも意味します。データ駆動型の作業はしばしば反復を含み、監査可能な台帳はそれを奨励します。

  • 分析の柔軟性: 既製のレポートに限定されません。BQLクエリ、Pythonスクリプト、Favaのフィルタの組み合わせで、ほぼ任意の財務の質問に答えられます。「過去5年間、毎年スターバックスでいくら使ったか?」 を知りたい — クエリ1つです。または_「3ヶ月の支出対収入の移動平均は?」_ — クエリの上にPython+pandasでスクリプト化可能。この柔軟性はデータを掘り下げるのが好きな人にとって大きなメリット。パワーユーザーはFava内で財務指標(ポートフォリオパフォーマンスメトリクスなど)を計算する拡張機能も構築しています。要するに、多くの既製ソフトウェアが提供できない非常に細かいインサイトを得られます。

  • 統合と拡張性: FavaのプラグインシステムとアクセスしやすいBeancount APIは、ツールがニーズとともに成長できることを意味します。明日新しい種類の資産を追跡し始めたり、新しいデータフィードを統合したくなったら、システムを拡張できます。アーキテクチャ(プレーンテキスト入力、さまざまな出力)は非常に拡張可能です。これは機能をリクエストして待たなければならないかもしれないクローズドシステムとは対照的です。

  • データ統合: 個人やビジネスでも、すべてのアカウント(複数の銀行、ブローカーなど)を1つのシステムに統合できるのは強力です。多くの商用ソリューションはサイロ化します(または多通貨や複数エンティティに追加料金を課します)。Beancountではすべてを一緒にできます。これは_全体論的な_データビューを提供し、全体にわたるインサイトを可能にします。例えば、個人とビジネス全体で真の資産配分や純キャッシュフローを計算できます。単なるデータエントリだからです。

  • コスト効率: 無料でオープンソース。個人使用には大きな利点(多くの予算アプリのようなサブスクリプションなし)。スタートアップや小規模組織には、その節約が積み上がります。金銭的コストを超えて、実行(Favaは小さなサーバーで実行可能)と移植(大きくなっても高価な移行なし — ただのテキスト)の面でも効率的です。

  • コミュニティと知識共有: プレーンテキスト会計コミュニティ(Beancount、Ledgerなど)は非常に協力的です。人々はフォーラムやブログで設定、カスタムスクリプト、ヒントを共有します。ニッチなニーズがあれば、誰かが似たことに取り組んだかもしれません。例えば、複数のユーザーがスマートインポートツールや機械学習のカテゴリ分類(過去データに基づいて支払先を自動分類するscikit-learnを使用する「smart*importer」ライブラリなど)に貢献しました。時間とともに、これらのコミュニティツールを活用すればBeancountの使用は実際に_賢く_なり得ます — 透明性を保ちながら商用ソフトウェアの利便性に近づきます。

  • エンパワーメントと学習: Fava/Beancountを使用すると、財務データとより深いレベルで関わることを強いられます。多くのユーザーは、自動化アプリで得たよりもはるかに良い財務の理解をこのシステムで得たと報告しています。自炊とファストフードの違いのようなものです — より多くの努力ですが、中身を正確に知っており、長い目で見ればより健康的です。データ駆動型インサイトには、このプロセスの「所有」がより意味のある発見につながります。データの見方を簡単に組み替え再構成できるからです。

欠点​

  • 初期設定と学習曲線: 正直に言いましょう — BeancountとFavaは、QuickBooksやMintのようにプラグアンドプレイではありません。複式簿記の基本(知らない場合)、Beancountファイル構文、そして高度にカスタマイズしたいなら多少のPythonを学ぶ必要があります。この事前投資が障壁になり得ます。非技術系ユーザーには daunting かもしれません(ただしFavaのインターフェースは、一度設定すればより親しみやすい体験を提供して大いに助けます)。対照的に、多くの商用ツールは会計の概念をシンプルなインターフェースの背後に隠します(これは長所にも短所にもなり得ます)。

  • 組み込みの銀行同期なし: 設計上、銀行API(しばしば独自または契約が必要)に自動接続しません。したがって、明細を手動でダウンロードするか、独自の自動化(Pythonスクリプトやしばしば費用がかかるPlaidのようなサービス経由)を設定します。銀行フィードが「ただ機能する」ことに慣れている人には、後退のように感じるかもしれません。あるユーザーは、Beancountを試したとき_「銀行フィードを得る合理的な方法が見つからなかった」_ と述べました — コーディングするかサードパーティソリューションを使う用意がなければ、これは苛立ちになり得ます。

  • リアルタイムはあなたの時間を意味する: リアルタイムの応答性を達成することは可能ですが、すぐにはできません。前述のようにcronジョブやトリガーを設定する必要があります。何かが壊れた場合(銀行がCSV形式を変えるなど)、インポータを修正する必要があります。QuickBooksのようなサービスでは、ベンダーがそのような変更に対処します。本質的に、あなた自身がITサポートです。これは古典的なオープンソースのトレードオフです。趣味の人には問題ないか、楽しいかもしれません。忙しい中小企業の経営者には迷惑かもしれません。

  • スケーリングとパフォーマンスの限界: 非常に大きなデータセット(長年の詳細なトランザクション)では、Beancountは遅くなる可能性があります。一般的に効率的です(数万人のエントリでも問題ない人々がいます)。しかしHNスレッドで見たように、あるユーザーはファイルが大きくなりクエリを高速に保つため3年後に年次で「帳簿を締める」必要がありました。Beancount v2コードはPythonで、巨大なデータでは少し遅くなる可能性がありますが、v3(C++コアで開発中)はこれを改善します。緩和策(ファイルの分割、Beanpostを使用してDBにオフロードなど)がありますが、考慮事項です。QuickBooksはおそらく内部スケーリングがあり、ほとんどのBIツールは大きなデータ用のデータベース上に構築されています — したがって大きなデータセットをより優雅に処理するかもしれません。

  • 機能のギャップ(専用ソフトウェアと比較して): Beancount+Favaは簿記と分析に焦点を当てています。一部の補助機能が欠けています:給与処理なし、請求書生成なし(カスタムスクリプトなしでは)、統合された税務申告書なしなど。目標が_包括的な_財務管理なら、他のツールで補う必要があるかもしれません。例えば、給与は給与サービス経由で行い、仕訳エントリをインポートするだけかもしれません。それは機能しますが、ERPのようにすべてを1つで行うほどシームレスに統合されていません。個人財務では、Beancountには組み込みの債務返済プランナーや予算封筒(シミュレートはできるが)がありません。指示的なアドバイスや計画モジュールを提供するのではなく、インサイトを導き出し意思決定することを期待されています。

  • ユーザーインターフェースと磨き込み: Favaは非常に優れていますが、一部の商用製品ほど洗練されたりガイドされたりしていません。セットアップを案内したり、間違いをしないようにする「ウィザード」はありません。Xの方法を知るにはドキュメントを読む必要があるかもしれません。そして期待するかもしれない特定のUI機能(ドラッグ&ドロップのカテゴリ分類、多段階の取り消し、モバイルプッシュ通知など)はありません。Fava UIは(貢献により)常に改善されていますが、小さなコミュニティによって構築されています。洗練されたモダンなSaaS UIに慣れているなら、Favaは少し実用的に感じるかもしれません(実際にそのクリーンなシンプルさを好む人もいます)。モバイルでは、Favaは機能します(特に読み取り専用)が、小さな画面に完全に最適化されていません。QuickBooksには例えば専用モバイルアプリがあります。

  • コミュニティ/メンテナへの依存: Martin Blais(Beancountの作者)と貢献者がBeancountを維持し、他の人がFavaを維持しています。開発は(OSSで通常のように)散発的になり得ます。ソフトウェアは現在非常に使用可能ですが、新機能が必要だったりバグがあれば、自分で修正するか待つ必要があるかもしれません。有料製品では、電話できるサポートがあります(品質はさまざまですが、少なくともあります)。とはいえ、コミュニティは通常、メーリングリストやGitHub issueを通じて非常に助けになります。

  • 会計知識が必要: 特にビジネス使用には、何をしているかを知る必要があります。Beancountは会計の観点から「間違った」エントリ(不均衡や不一致のトランザクションを除いて)を止めません。対照的にQuickBooksにはガードレールがあります(そして有効にすれば自動繰延収益追跡などの隠れた複雑さもあります)。Beancountで注意しないと、発生主義を台無しにして、レポートの問題に気づくまで気づかないかもしれません。本質的に、Beancountは基本的な会計を習得しているか、学ぶ用意があると仮定します。これは一部には長所(正しく行うことを強制)ですが、考える必要のないシステムが欲しいなら短所です。

メリットとデメリットを要約すると:Beancount + Favaは、財務データと深く関わりたい人に比類のない制御と適応性を提供し、データ駆動型インサイトのための強力なツールにします。帳簿をクエリ可能なデータセットに、レポートを拡張可能なWebアプリに変えます。この力の代償は、設定と維持に投資する作業と、システムの管理においてある程度自給自足する必要性です。QuickBooksやBIスイートのように、より手厚くサポートし特定の機能を自動的に提供するものとは対照的に、Beancountはツールキットを提供します。分析的傾向があれば、このツールキットは信じられないほど解放的です — 既製のレポートが決して示さないかもしれないインサイトを抽出できます。何年もかけてBeancount台帳を自動化したあるユーザーは、「オープンソースツール(Beancountなど)は[すぐには]私のすべてのニーズを満たしません…私はすべてを自動化することに取り憑かれています…必要なものを構築しました」 と書きました。これはアプローチを要約しています:必要とするものを、それがどんなに小さくても大きくても、構築する用意があれば、Fava/Beancountがサポートし、データを決して隠しません。データ駆動型のマインドセットには、それは大きな利点です。

結論として、リアルタイムの財務分析にFavaとBeancountを使用することは、財務のための独自のカスタマイズ可能な実験室を持つようなものです。独自のプラットフォームではなかなか匹敵しない明確さ、柔軟性、所有権を得られ、これらを重視し、それらを得るために利便性の一部を交換する用意がある人に理想的です。現代の風景はハイブリッドアプローチさえ示しています — 例えば、商用ツールを使用しつつ定期的にBeancountにエクスポートしてより深い分析を行う人もいれば、逆にBeancountを主要としてプレゼンテーションにBIツールを使用する人もいます。この調査からの知識で、Fava+Beancountが自分のニーズに合うかどうかを情報に基づいて判断し、そうであれば自信を持ってその機能を活用して豊かでリアルタイムの財務インサイトを得るために進めます。

出典:

  • Blais, M. (2020). Beancount Documentation – Design principles and usage. [Online]. Available: beancount.github.io
  • Aumayr, D., Gerstmayr, A. (2025). Fava Documentation & GitHub Repository. [Online]. Available: beancount.github.io/fava/ and github.com/beancount/fava
  • LowEndBox. (2025). “Beancount: Lightweight FOSS Double-Entry Accounting...from the Command Line!” LowEndBox Tutorial.
  • Fang-Pen Lin. (2024). “My Beancount books are 95% automatic after 3 years.” Personal Blog Post.
  • Google Groups – Beancount Forum. (2023). Discussion on Grafana integration (Josh D. and Andreas G.)
  • QuickBooks Marketing Page. “Bank Feeds – Understand all your transactions in an instant.” Intuit QuickBooks.
  • Watt, A. (2023). “Beancount for Personal Finance.” Alex Watt Blog.
  • Reddit – r/plaintextaccounting. Various discussions (2021-2023) on business use of Beancount and ledger visualization.
  • Fava Extension Documentation – Help: Extensions.
  • fava-dashboards GitHub README – Andreas Gerstmayr’s custom dashboards plugin.
  • Awesome Beancount list – community-curated resources for Beancount.

出典: https://beancount.io/ja/docs/Solutions/analytics