著者 セルフホスト家計簿アプリ比較：銀行同期対応は？
銀行取引を自動取得できるアプリと手動インポートが必要なアプリを比較します。Actual Budget、Firefly III、Fava、Wallosの同期方法と向く用途がわかります。
短い結論
セルフホスト型の家計管理アプリは、ほとんどの導入を左右する1つの点で異なります。ソフトウェアが取引明細を取得するのか、それとも自分で入力するのかです。家庭の予算管理には、Actual Budgetが最も無難な選択です。エンベロープ方式を使用し、単一のコンテナとして動作します。必要に応じて、銀行データプロバイダーから取引明細を取得することもできます。
複式簿記の勘定科目が必要な場合や、誰も監視せずに定期的なインポートを実行したい場合は、Firefly IIIが適しています。台帳をバージョン管理下のプレーンテキストファイルとして管理したい場合は、BeancountとFavaが向いています。Wallosは、毎月アカウントから引き落とされる継続的な支出を追跡するという、限定された機能に特化しています。
これらのアプリが単独で銀行と通信することはありません。銀行の取引明細を表示するアプリは、すべて第三者のアグリゲーターからデータを取得します。アグリゲーターのアカウント作成が、導入を妨げる段階になります。何もインストールする前に、同期のセクションを読んでください。
それぞれが実行するものを横並びで比較
The data behind this chart
[
{
"tool": "Actual Budget",
"services": 1,
"storage": "SQLite files",
"bank_sync": "Aggregators, manual pull",
"multi_user": "Needs OpenID",
"encryption": "Optional end to end"
},
{
"tool": "Firefly III",
"services": 3,
"storage": "MariaDB",
"bank_sync": "Importer, cron capable",
"multi_user": "Built in accounts",
"encryption": "None at rest"
},
{
"tool": "Beancount + Fava",
"services": 1,
"storage": "Text file",
"bank_sync": "Import scripts only",
"multi_user": "No login at all",
"encryption": "File level, your choice"
},
{
"tool": "Wallos",
"services": 1,
"storage": "SQLite file",
"bank_sync": "Manual entry only",
"multi_user": "Extra logins in settings",
"encryption": "None at rest"
}
]Actual Budget は、長時間稼働するサービスを 1 個実行します。Firefly III は 3 個実行します。公式の compose ファイルが、アプリ、MariaDB データベース、cron ヘルパーを別々のコンテナとして起動するためです。これが、これら 4 個のアプリに関するリソース構成の全体です。このグループで負荷が大きいのはデータベースサーバーだけで、残りは小さなファイルを扱う小規模なプロセスです。
自分でホストする予算管理アプリで、銀行から取引データを取得できるものはありますか？
自分でホストするアプリが銀行に直接接続することはありません。銀行はオープンバンキング API 経由で取引データを提供し、その API にはアグリゲーターを介してアクセスします。アグリゲーターとは、銀行との関係を維持し、アクセスを再販する企業です。したがって、実際の確認事項は 2 つあります。アプリがアグリゲーターに対応しているか、そして自分の銀行を対象とするアグリゲーターのアカウントを取得できるかです。
Actual Budget は複数のアグリゲーターに対応しています。2026 年 8 月時点のドキュメントには、New Zealand 向けの Akahu、Europe 向けの Enable Banking、Europe 向けの GoCardless Bank Account Data、North America 向けの SimpleFIN Bridge、Brazil 向けの Pluggy.ai が記載されています。利用者自身でプロバイダーに登録し、キーと Secret を生成してから、それらをサーバーに入力します。重要な制限が 2 つあります。ドキュメントには、Actual は銀行データを自動同期しないと明記されています。利用者がボタンを押す必要があります。同じページには、GoCardless が新規アカウントを受け付けていないことも記載されています。そのため、古いガイドで現在も推奨されている無料の Europe 向け経路は利用できません。SimpleFIN Bridge は有料のサブスクリプションサービスです。料金は Actual ではなく、プロバイダーから利用者に請求されます。
Firefly III では、インポート機能を 2 番目のコンテナである Firefly III Data Importer に分離します。そのサンプル設定には、CSV と CAMT.053 のファイルインポートに加えて、GoCardless (Nordigen)、Enable Banking、Spectre、SimpleFIN 用の認証情報欄があります。CAN_POST_AUTOIMPORT=true を設定し、AUTO_IMPORT_SECRET に長いランダム値を指定すると、ホスト上の cron ジョブからブラウザーを開かずにインポートを実行できます。この比較で本当に無人で同期できるのはこれだけです。
Beancount には同期機能がありません。銀行から CSV または OFX ファイルをダウンロードし、自分で作成した、または入手したインポータースクリプトを実行します。Wallos にも同期機能はありません。これは設計上の仕様です。サブスクリプションを 1 回入力すると、設定したスケジュールに従って自動的に繰り返されます。
手動インポートは常に利用できる方法であり、銀行がプロバイダーを変更しても影響を受けません。銀行接続が選定の決め手になる場合は、何かをインストールする前に、自分の銀行がアグリゲーターの対象になっているかを確認してください。この確認には 10 分しかかからず、週末を無駄にせずに済みます。
Actual Budget: 1 つのコンテナで封筒式予算管理
封筒式予算管理では、使う前に手元にあるお金をカテゴリへ割り当てます。食費に 300、交通費に 80 を割り当て、割り当てた合計が口座内の金額を超えないようにします。Actual はこの方法を実装しており、アプリはローカル優先で動作します。ブラウザーまたはデスクトップクライアントが予算の完全なコピーを保持してサーバーと同期するため、サーバーが停止していてもアプリを使い続けられます。
services:
actual_server:
image: actualbudget/actual-server:latest
ports:
- '5006:5006'
volumes:
- ./actual-data:/data
restart: unless-stoppeddocker compose up -d で起動し、http://your-server:5006 を開きます。データボリュームには server-files と user-files の 2 つのディレクトリが作成されます。これらのディレクトリが予算データです。自分のネットワーク以外から利用する前に、TLS（トランスポート層セキュリティ）対応のリバースプロキシを前段に配置してください。詳しい手順は Actual Budget のインストールガイド にあり、このファイルで使っている Compose の構成パターンは VPS での Docker Compose にまとめています。
複数ユーザー。 初期状態では、サーバーのパスワードは 1 つで、全員が共有します。アカウントを分離するには OpenID Connect が必要です。サーバーは Authentik、Keycloak、Google、GitHub などのプロバイダーに対する OpenID Connect をサポートしています。OpenID で最初にログインしたユーザーがサーバー所有者になり、ACTUAL_USER_CREATION_MODE によって、後続のログイン時に各自のアカウントを作成するかどうかが決まります。2 人が同じ予算ファイルを同時に開くことはできます。ただし、ドキュメントでは競合する編集は安全ではないと警告されています。そのため、1 つの予算を共有する 2 人は、同じ画面を同時に編集しないでください。
暗号化。 Actual は、予算ファイルごとのエンドツーエンド暗号化を提供します。有効にすると、サーバーには読み取れないデータが保存されます。レンタルサーバーで利用する場合に適した構成です。ただし、2 つの点に注意が必要です。暗号化パスワードを失うと、リセット手段がないためファイルを復旧できません。また、銀行同期用トークンは別に保存され、この暗号化の対象外です。そのため、サーバー上のデータベースにアクセスできるユーザーは、トークンを読み取れます。
Firefly III: 複式簿記と、この環境で唯一の無人インポート
複式簿記では、すべての取引に出金元アカウントと入金先アカウントがあります。食料品を購入すると、当座預金口座から費用アカウントへ資金が移動するため、何もないところから金額が現れることはありません。説明できない資金は、カテゴリ合計の中に隠れるのではなく、残高不一致のアカウントとして明らかになります。Firefly III を選ぶ理由はここにあります。予算管理よりも会計に近い仕組みです。
プロジェクト独自のファイルからインストールします。
mkdir -p /srv/firefly
curl -fsSL -o /srv/firefly/docker-compose.yml https://raw.githubusercontent.com/firefly-iii/docker/main/docker-compose.yml
curl -fsSL -o /srv/firefly/.env https://raw.githubusercontent.com/firefly-iii/firefly-iii/main/.env.example
curl -fsSL -o /srv/firefly/.db.env https://raw.githubusercontent.com/firefly-iii/docker/main/database.env初回起動前に .env を編集します。APP_KEY にはちょうど 32 文字の文字列を指定する必要があります。プロジェクトには、その文字列を生成するコマンドが用意されています。
head /dev/urandom | LC_ALL=C tr -dc 'A-Za-z0-9' | head -c 32 && echoSTATIC_CRON_TOKEN にも 32 文字の文字列を指定します。この compose ファイルの cron コンテナは 1 日に 1 回アプリを呼び出します。有効な token がないと呼び出しは拒否されるため、定期取引と請求通知が実行されません。SITE_OWNER をメールアドレスに設定し、.env のデータベースパスワードを .db.env の値と一致させてから、起動します。
docker compose up -d
docker compose logs -f app初回起動が正常に完了すると、コンテナ内の port 80 でアプリが応答し、ログが落ち着きます。データベース接続エラーが繰り返される場合は、.env と .db.env のパスワードが一致していません。そのため、アプリが MariaDB にログインできません。
自動インポート。 Data Importer は独自のコンテナとして動作し、FIREFLY_III_ACCESS_TOKEN の personal access token で Firefly III に認証します。まずインポートを 1 つ対話的に設定し、生成された設定ファイルを保存します。その後、cron から auto import endpoint にスケジュールどおり送信します。Firefly III が同期すると言われる場合の意味はこれです。aggregator が銀行接続を保持し、importer がそこからデータを取得し、利用者が休んでいる間もサーバーが処理します。
複数ユーザー。 Firefly III は実際のアカウントを独自のデータベースに保持します。これを選択するのが AUTHENTICATION_GUARD=web です。remote_user_guard を指定すると、Authelia などの認証プロキシがログインを処理し、username を header で渡します。LDAP は現在サポートされていません。インターネットから到達可能な instance では、初回ログイン後に administration page を開き、single user mode の設定を確認します。この設定により、他のユーザーが登録できるかどうかが決まります。
暗号化。 保存データの暗号化はありません。取引データは MariaDB に可読形式で保存されるため、データベースパスワードを知っている人や volume のコピーを取得した人は、財務履歴をすべて確認できます。前段で TLS を終端し、可能な限り open internet から隔離し、バックアップを暗号化してください。
Beancount と Fava: 台帳はテキストファイルです
Beancount は、プレーンテキストで記述する複式簿記の構文です。取引は、自分で管理するファイルに数行で記述します。
2026-08-19 * "Supermarket" "Weekly shop"
Expenses:Food:Groceries 42.10 EUR
Assets:Bank:CheckingFava は、そのファイルを扱う Web インターフェースです。グラフ、貸借対照表、損益計算書を生成でき、ソースファイルも編集できます。仮想環境にインストールします。
sudo apt update && sudo apt install -y python3-venv
python3 -m venv ~/.venvs/fava
~/.venvs/fava/bin/pip install fava
~/.venvs/fava/bin/fava --read-only ~/ledger/main.beancountUbuntu 24.04 では、プレーンな pip3 install fava は error: externally-managed-environment が原因で失敗します。システムの Python は apt が管理しているため、仮想環境を使う必要があります。これは回避策ではなく、正しい対処です。
Fava はデフォルトで localhost の 5000 番ポートを待ち受けます。-H でホストを変更し、-p でポートを変更できます。ただし、公開範囲を広げる前に検討してください。Fava にはログイン機能がありません。コマンドラインにもユーザー名やパスワードを指定するオプションがないため、そのポートに到達できるすべての接続元が、管理しているすべての取引を読み取れます。デフォルトのホスト設定を維持し、SSH トンネル、VPN、または認証機能を持つプロキシ経由でアクセスしてください。--read-only フラグを指定すると、ブラウザーからの書き込みを禁止できます。ノート PC でファイルを編集して commit する運用では、指定する価値があります。
複数ユーザーと暗号化。 ユーザーモデルはまったくありません。1 つのインスタンスが、ユーザー識別情報を持たない 1 つの台帳を提供します。そのため、共有する場合はプロキシのログイン情報を共有することになります。暗号化は、age または gpg で暗号化したコピーや、暗号化されたバックアップリポジトリなど、ファイルに適用した方法に依存します。テキスト台帳の利点は、git によって履歴、blame、リモートコピーを追加コストなしで利用できることです。
Wallos: 定期的な支出を管理する小規模なツール
services:
wallos:
image: bellamy/wallos:latest
ports:
- "8282:80/tcp"
volumes:
- './db:/var/www/html/db'
- './logos:/var/www/html/images/uploads/logos'
restart: unless-stoppedWallos はすべてのデータを db/wallos.db にある 1 つの SQLite ファイルに保存します。複数の通貨に対応し、換算も行えます。更新日が近い契約について、メール、Discord、Telegram、Gotify、Pushover、または webhook で通知できます。追加のログインは設定ページから作成でき、ログインごとに個別の一覧を持ちます。
Wallos にできないことも明確にしておきます。Wallos は日々の支出を追跡せず、予算という概念もありません。答えるのは、「毎月いくら支払っていて、次に何が更新されるのか」という 1 つの問いです。この目的で、Actual と併用している人も多くいます。管理したい定期的な金額が支払う金額ではなく請求する金額である場合は、セルフホスト型の請求書発行ソフトウェアを確認してください。
Maybe Financeについて
Maybe Financeは多くのスレッドで推奨されているため、回答が必要です。READMEには、リポジトリが現在は積極的に保守されておらず、最終リリースがv0.6.0としてタグ付けされていることが記載されています。コードのライセンスはAGPLv3です。現在も動作します。予算管理データは10年間保持するデータであり、データベーススキーマと銀行の認証情報を扱う保守されていないソフトウェアに保存するのは適切ではありません。これは2026年8月時点での判断です。導入を決める前に、リポジトリを自分で確認してください。
必要なサーバーリソースはどの程度ですか？
これらはすべて小規模です。ブログに書かれた数値をそのまま信頼せず、実際に測定してください。通常どおり1日使用した後、自分のサーバーで次を実行します。
docker stats --no-streamMEM USAGE 列を確認します。Actual、Wallos、Fava はいずれも、小さなプロセスで小さなファイルを1つ扱うだけです。そのため、他のサービスと同じ小規模な VPS 上でも十分に動作します。Firefly III は MariaDB がスタックに含まれる点が異なります。データベースサーバーは、クエリを実行していなくてもメモリを確保します。トランザクション数ではなく、データベース用の余裕を見込んでください。それでも、VPS の容量を圧迫する原因が家計簿アプリになることはほとんどありません。スタック全体を1台で運用するためにサーバーを選ぶ場合は、PhotoPrism と Immich の必要メモリ量によって購入する RAM 容量が決まる可能性がはるかに高くなります。
データ自体はほとんど増えません。家庭の10年分の取引データでも、ファイルサイズはメガバイト単位です。そのため、ディスク容量が制約になることはありません。このような長期運用で実際に問題になる点については、次のセクションで説明します。
モバイル対応と、その限界
ここは、セルフホスト型の家計管理アプリが商用アプリに劣る部分です。家族全員の運用を移行する前に、現実的に判断してください。
公式のモバイルアプリが非推奨になっていることは、実際のドキュメントにも記載されています。代わりに利用するのは Web 版です。公式ドキュメントでは、ホーム画面にインストールしてネイティブアプリのように使うレスポンシブな progressive web app と説明されています。動作は良好です。ただし、アプリストアのアプリではありません。コミュニティが非公式のネイティブクライアントを保守しています。
Firefly III にも公式アプリはありません。ただし、その API を利用した高機能な非公式アプリが 2 つあります。Waterfly III は Android アプリで、Google Play と F-Droid で公開されています。Abacus は iPhone、iPad、Android で動作し、OAuth2 でログインし、トークンを iOS keychain に保存します。どちらも、スマートフォンからインスタンスに到達できる必要があります。
Fava と Wallos が提供するのは、レスポンシブな Web ページだけです。スマートフォンで台帳を読むのは問題ありません。しかし、スマートフォンのキーボードで Beancount の取引を入力するのは現実的ではありません。
すべてのアプリに共通する点があります。モバイルデータ通信中のスマートフォンは、自宅ネットワーク上にありません。アプリを TLS と強力な認証を設定したドメインで公開するか、スマートフォンを VPN に接続してください。共有パスワード 1 つだけで保護した家計管理アプリをインターネットに公開するのは避けるべきです。どちらの方法も適さない場合は、インスタンスを v3 onion service の背後に配置する方法もあります。この方法では、公開 DNS レコードも、インターネット全体に公開するポートも必要ありません。ただし、スマートフォンでは Tor Browser 経由でアクセスする必要があります。
バックアップ: このカテゴリで最も重要なセクション
メディアライブラリを失っても、再ダウンロードにかかる手間だけで済みます。5 年分の分類済み取引を失うと、再ダウンロードできないデータを失うことになります。初日に設定してください。
アプリごとにコピーする対象:
- Actual Budget: データボリューム全体。
server-filesとuser-filesの両方。 - Firefly III: データベースダンプに加えて、
.env、.db.env、アップロード用ボリューム。 - Beancount: 台帳ファイル。できればリモートを設定した git リポジトリ。
- Wallos:
db/wallos.dbとアップロード済みロゴのディレクトリ。
稼働中の SQLite ファイルをコピーすると、復元できないバックアップが作成されることがあります。SQLite は直近の書き込みを別の write ahead log ファイルに保持するため、.sqlite ファイルだけをコピーすると、最新の取引が含まれなかったり、まったく開けなかったりします。コピーにかかる数秒間だけコンテナを停止してください。
cd /srv/actual
docker compose stop actual_server
tar czf /srv/backups/actual-$(date +%F).tgz -C /srv/actual actual-data
docker compose start actual_serverFirefly III では代わりにダンプを作成します。パスワードが shell の履歴に残らないよう、データベースコンテナ内から実行してください。
cd /srv/firefly
docker compose exec -T db sh -c 'mariadb-dump -u firefly -p"$MYSQL_PASSWORD" firefly' > /srv/backups/firefly-$(date +%F).sql古い MariaDB イメージでは、同じツールが以前の名前である mysqldump として提供されています。.env と .db.env はダンプと一緒に保管してください。設定が残っていない環境にデータベースを復元する作業は、最悪の日に解くパズルになります。
同じ VPS 上のコピーは、誤った編集からデータを保護します。しかし、サーバーの紛失や侵害からは保護できません。restic を使ってバックアップディレクトリをオブジェクトストレージへ送信してください。restic は、データがサーバーから出る前にリポジトリを暗号化します。
export RESTIC_REPOSITORY=s3:s3.example.com/money-backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /srv/backups
restic forget --keep-daily 7 --keep-weekly 8 --keep-monthly 12 --prunerestic snapshots には、今日の日付が付いたスナップショットが表示されるはずです。スケジュール、認証情報、systemd タイマーについては、VPS で暗号化した restic バックアップを設定するガイドで説明しています。
一度も復元していないバックアップは、推測にすぎません。問題が起きていない今、1 回テストしてください。
restic restore latest --target /tmp/restore-testActual のアーカイブを作業用ディレクトリに展開し、別のポートでそのディレクトリを使用する 2 つ目のコンテナを起動して、アクセスしてください。バックアップ取得時点の残高とアカウントが表示されるはずです。Firefly III では、ダンプを作業用データベースに読み込み、transactions テーブルの行数を数えます。稼働中のインスタンスと一致する数値なら、バックアップは有効です。その後、作業用のコピーを削除してください。実際の財務データを含むテスト用インスタンスを放置すると、それ自体が問題になります。
アプリを 1 つ選び、履歴を移行する前に実データで 1 か月運用し、同じ週にバックアップも動作させてください。自分のサーバーで管理するデータをまだ検討中であれば、2026 年にセルフホストする価値があるもののまとめで、スタックの残りの部分を確認できます。
FAQ
銀行口座と接続できる self-hosted の家計簿アプリはどれですか？
Actual Budget と Firefly III は、どちらも直接銀行に接続するのではなく、サードパーティのアグリゲーター経由で接続できます。Actual は、北米向けの SimpleFIN Bridge、欧州向けの Enable Banking、ニュージーランド向けの Akahu、ブラジル向けの Pluggy.ai などに対応しています。また、Actual のドキュメントによると、銀行データは自動同期されないため、ボタンを押して同期します。Firefly III は別の Data Importer コンテナを使用し、cron から実行できるため、実際に無人で動作するのはこちらです。Beancount と Wallos は銀行接続に対応していません。アグリゲーターが利用する銀行をカバーしているかを、選定前に確認してください。この対応範囲が、機能よりも結果を左右することが多いためです。
これらの家計簿アプリをスマートフォンで使えますか？
はい。ただし、公式アプリはありません。Actual のドキュメントでは、公式モバイルアプリは非推奨となっており、ホーム画面にインストールできるレスポンシブな progressive web app である Web 版を案内しています。Firefly III には、信頼できる非公式クライアントが2つあります。Android 向けの Waterfly III と、iOS および Android 向けの Abacus です。Fava と Wallos はレスポンシブな Web ページとして動作するだけです。いずれの場合も、スマートフォンからサーバーに到達できる必要があります。そのため、TLS と強力な認証を設定したドメインを用意するか、スマートフォンを VPN に接続してください。
データベースを破損させずに self-hosted の家計簿アプリをバックアップするにはどうすればよいですか？
稼働中の SQLite ファイルだけをコピーしてはいけません。SQLite は直近の書き込みを別の write ahead log に保持するため、書き込みの途中でコピーすると、取引が欠落したり、ファイルを開けなくなったりする可能性があります。コンテナを停止し、データディレクトリをコピーしてから、再度起動してください。この規模のアプリであれば数秒で完了します。Firefly III では、代わりにデータベースコンテナ内で mariadb-dump を実行し、dump とともに環境ファイルも保管してください。結果を暗号化した restic repository にサーバー外へ送信し、正常に動作することを確認するため、1度リストアしてください。
小規模な VPS では Firefly III は重すぎますか？
ここで比較する中では最も重い選択肢です。ただし、その理由は公式の compose ファイルが、アプリおよび cron コンテナと同じ環境で MariaDB サーバーも実行するためです。個人の財務データは小さいため、メモリは取引データではなく、待機中のデータベースプロセスに消費されます。通常の運用を1日行った後、自分のサーバー上で docker stats --no-stream を実行し、公表値を信頼するのではなく MEM USAGE 列を確認してください。可能な限りフットプリントを小さくしたい場合は、Actual Budget と Wallos が、それぞれ1つのファイルに対して1つのプロセスだけを実行します。