著者 Matt Connor
セルフホスト家計簿アプリ比較：銀行同期対応は？
銀行取引を自動取得できるアプリと手動インポートが必要なアプリを比較します。Actual Budget、Firefly III、Fava、Wallosの同期方法と向く用途がわかります。
短い結論
セルフホスト型の家計管理アプリは、ほとんどの導入を左右する1つの点で異なります。ソフトウェアが取引明細を取得するのか、それとも自分で入力するのかです。家庭の予算管理には、Actual Budgetが最も無難な選択です。エンベロープ方式を使用し、単一のコンテナとして動作します。必要に応じて、銀行データプロバイダーから取引明細を取得することもできます。
複式簿記の勘定科目が必要な場合や、誰も監視せずに定期的なインポートを実行したい場合は、Firefly IIIが適しています。台帳をバージョン管理下のプレーンテキストファイルとして管理したい場合は、BeancountとFavaが向いています。Wallosは、毎月アカウントから引き落とされる継続的な支出を追跡するという、限定された機能に特化しています。
これらのアプリが単独で銀行と通信することはありません。銀行の取引明細を表示するアプリは、すべて第三者のアグリゲーターからデータを取得します。アグリゲーターのアカウント作成が、導入を妨げる段階になります。何もインストールする前に、同期のセクションを読んでください。
それぞれの構成を並べて比較する
このグラフのデータ
[
{
"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 via admin page",
"encryption": "None at rest"
}
]Actual Budget は、長時間稼働するサービスを 1 実行します。Firefly III は 3 を実行します。公式の compose ファイルが、アプリ、MariaDB データベース、cron ヘルパーを別々のコンテナとして起動するためです。これが、これら 4 個のアプリにおけるリソース構成のすべてです。このグループで負荷が大きいのはデータベースサーバーだけで、残りは小さなファイルを保持する小規模なプロセスです。
銀行から取引データを取得できるセルフホスト型の予算管理アプリはどれですか？
セルフホスト型アプリが銀行へ直接接続することはありません。銀行はオープンバンキング API を通じて取引データを公開しており、その API にはアグリゲーターを介してアクセスします。アグリゲーターは、銀行との接続関係を持ち、アクセスを再販する企業です。したがって、実際の確認事項は 2 つあります。アプリがアグリゲーターに対応しているかどうか、そして利用する銀行をカバーするアグリゲーターのアカウントを取得できるかどうかです。
Actual Budget は複数のアグリゲーターに対応しています。2026 年 10 月時点のドキュメントには、ニュージーランド向けの Akahu、欧州向けの Enable Banking、欧州向けの GoCardless Bank Account Data、北米向けの SimpleFIN Bridge、ブラジル向けの Pluggy.ai が記載されています。利用者自身でプロバイダーに登録し、キーと Secret を生成してから、サーバーに入力します。重要な制限が 2 つあります。現在の安定版リリースである 26.10.0 では、同期は利用者がボタンを押したときに実行されます。リンク済みアカウントを指定した間隔で自動同期する設定はマージ済みですが、2026 年 10 月時点では nightly builds にのみ含まれています。また、その場合も同期は Actual がデバイス上で開いている間だけ実行されます。同じページには、GoCardless が新規アカウントを受け付けていないことも記載されています。そのため、古いガイドが今も推奨している無料の欧州向け経路は利用できません。SimpleFIN Bridge は有料のサブスクリプションサービスで、料金は Actual ではなくプロバイダーから請求されます。
誰も操作しなくても Actual に今日の取引を取り込ませたい場合は、actual-auto-sync というコミュニティプロジェクトを使うと、銀行同期をスケジュール実行できます。これは Actual サーバーの隣で動作する別のコンテナで、Actual の公式 API パッケージを介して Actual と通信します。Actual の一部ではないため、追加のサービスとして設定と更新が必要です。
Firefly III では、インポート処理を 2 つ目のコンテナである Firefly III Data Importer に分離します。サンプル設定には、CSV と CAMT.053 によるファイルインポートに加えて、GoCardless (Nordigen)、Enable Banking、SimpleFIN、Lunch Flow 用の認証情報欄があります。CAN_POST_AUTOIMPORT=true を設定し、AUTO_IMPORT_SECRET に長いランダム値を入力すると、ホスト上の cron ジョブからブラウザーを開かずにインポートを実行できます。この比較対象のアプリで、無人同期が組み込まれているのはこれだけです。Actual で実現するには、前述の追加コミュニティサービスが必要です。
Beancount には同期機能がありません。銀行から CSV または OFX ファイルをダウンロードし、自分で作成するか入手したインポータースクリプトを実行します。Wallos にも同期機能はありません。これは設計上の仕様です。サブスクリプションを 1 回入力すると、設定したスケジュールで自動的に繰り返されます。
手動インポートは常に機能する方法であり、銀行がプロバイダーを変更しても利用できます。銀行との接続性が選定の決め手であれば、インストール前に利用する銀行がアグリゲーターの対象かどうかを確認してください。この確認には 10 分しかかからず、週末を無駄にせずに済みます。
Actual Budget: 1 つのコンテナで封筒式予算管理
封筒式予算管理では、すでに手元にあるお金を、使う前にカテゴリへ割り当てます。食費に 300、交通費に 80 を割り当て、口座にある金額を割り当て総額が超えないようにする方法です。Actual はこれを厳格な上限として適用しません。手元の金額を超えて割り当てると、その月は予算超過として表示され、超過分を補填するまで翌月の資金から差し引かれます。Actual はこの方法を実装しています。また、アプリはローカルファーストです。ブラウザーまたはデスクトップクライアントが予算の完全なコピーを保持し、それをサーバーと同期するため、サーバーが停止していてもアプリを使い続けられます。
services:
actual_server:
image: actualbudget/actual-server:latest
ports:
- '5006:5006'
volumes:
- ./actual-data:/data
restart: unless-stoppeddocker compose up -d で起動します。Actual の Docker インストール手順では、ローカルネットワーク上の別のコンピューターから通常の http://your-server:5006 でアクセスするよう案内しています。そのため、HTTPS なしでアプリを読み込めます。Actual の HTTPS ページでは、すべての機能を安全に使うには HTTPS が必要だと説明しています。ただし、次の 2 つの場合はこの手順を省略できます。自分のコンピューター上のサーバーに localhost だけでアクセスする場合と、クラウドプロバイダーが HTTPS を処理する場合です。データボリュームには server-files と user-files の 2 つのディレクトリが作成されます。これらのディレクトリが予算データです。インターネット経由でアクセスする VPS では、初回利用前に TLS (transport layer security) 対応のリバースプロキシを前段に置き、プロキシが提供する HTTPS アドレスでアプリを開きます。自己署名証明書も使えますが、ブラウザーには証明書が無効だという警告が表示されます。詳しい手順は 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回アプリを呼び出します。有効なトークンがないと呼び出しは拒否されるため、定期取引と請求通知が実行されません。SITE_OWNERにメールアドレスを設定し、.envのデータベースパスワードを.db.envの値と一致させてから起動します。
docker compose up -d
docker compose logs -f app初回起動が正常に完了すると、コンテナ内でアプリがポート8080でサービスを提供し、compose ファイルによりホストのポート80へ公開されます。その後、ログが落ち着きます。データベース接続エラーが繰り返される場合、.envと.db.envのパスワードが一致していません。そのため、アプリはMariaDBにログインできません。
自動インポート。 Data Importerは独立したコンテナとして動作し、FIREFLY_III_ACCESS_TOKENに設定した個人用アクセストークンでFirefly IIIに認証します。インポートを1つ対話的に設定し、生成された設定ファイルを保存してから、cronで自動インポートエンドポイントへ定期的に送信します。Firefly IIIが同期すると言う場合の動作はこれです。アグリゲーターが銀行接続を保持し、インポーターがそこからデータを取得します。サーバーが、利用者の不在中も処理を実行します。
複数ユーザー。 Firefly IIIは実際のアカウントを独自のデータベースに保持します。AUTHENTICATION_GUARD=webがこの動作を選択します。remote_user_guardを指定すると、Autheliaなどの認証プロキシがログインを処理し、ユーザー名をヘッダーで渡します。LDAPは現在サポートされていません。インターネットから到達できるインスタンスでは、初回ログイン後に管理ページを開き、single user modeの設定を確認します。この設定により、他のユーザーが登録できるかどうかが決まります。
暗号化。 保存データの暗号化はありません。取引情報はMariaDBに読み取り可能な形式で保存されるため、データベースパスワードを知っている人やボリュームのコピーを持つ人は、財務履歴を取得できます。前段でTLSを終端し、可能な限り公開インターネットから隔離し、バックアップを暗号化してください。
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 で通知できます。管理者は管理ページで追加のログインを作成できます。管理ページでは、登録を開放したり、OpenID Connect ログインを有効にしたりすることもできます。各ログインは、それぞれ独自の一覧を持ちます。設定で追加する世帯メンバーは支払者を示すラベルであり、別のログインではありません。
Wallos にできないことも明確にしておきます。Wallos は日々の支出を記録せず、予算の概念もありません。答えるのは、「毎月いくら支払っていて、次に何が更新されるのか」という 1 つの質問です。この目的で Actual と併用する人も多くいます。管理したい定期金額が支払う金額ではなく請求する金額である場合は、代わりに セルフホスト型の請求ソフトウェアを確認してください。
Maybe について
Maybe Finance は多くのスレッドで推奨されているため、回答しておく必要があります。README には、リポジトリがすでに積極的に保守されておらず、最終リリースが v0.6.0 であると記載されています。コードのライセンスは AGPLv3 です。リポジトリは 27 July 2025 に読み取り専用としてアーカイブされました。現在も動作します。家計管理データは 10 年単位で保持するデータです。データベーススキーマと銀行の認証情報を扱う、保守されていないソフトウェアに保存するのは適切ではありません。2026 年 October の時点でも、この見解は変わっていません。導入を決める前に、リポジトリを自分で確認してください。
必要なサーバーリソースはどの程度ですか？
これらはすべて小規模です。ブログに書かれた数値をそのまま信頼せず、実際に測定してください。通常どおり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
どのセルフホスト型予算管理アプリが銀行と接続できますか？
Actual Budget と Firefly III は、銀行との直接接続ではなく、サードパーティのアグリゲーターを介して接続できます。Actual は、北米向けの SimpleFIN Bridge、欧州向けの Enable Banking、ニュージーランド向けの Akahu、ブラジル向けの Pluggy.ai などのプロバイダーに対応しています。現在の安定版では、ボタンを押すと同期が実行されます。2026 年 10 月時点では、指定した間隔での自動同期は nightly builds でのみ利用でき、Actual が起動している間だけ実行されます。コミュニティサービスの actual-auto-sync を追加のコンテナとして実行すれば、スケジュールに従って同期できます。Firefly III は、cron から起動できる独立した Data Importer コンテナを使用するため、無人インポートが組み込まれているのはこちらです。Beancount と Wallos は、銀行接続にまったく対応していません。選ぶ前に、利用するアグリゲーターが自分の銀行に対応していることを確認してください。対応状況は、機能よりも選択結果を左右することが多いためです。
これらの予算管理アプリをスマートフォンで使えますか？
はい。ただし、公式アプリではありません。Actual のドキュメントでは、公式モバイルアプリは非推奨になったと説明されており、ホーム画面にインストールできるレスポンシブなプログレッシブ Web アプリである Web 版を案内しています。Firefly III には、Android 向けの Waterfly III と、iOS および Android 向けの Abacus という、信頼性の高い非公式クライアントが 2 つあります。Fava と Wallos は、レスポンシブな Web ページとして動作するだけです。Actual は予算のローカルコピーを保持するため、接続がなくても動作します。ただし、同期と銀行データの取得には、スマートフォンからサーバーへ接続できる必要があります。その他のアプリは、すべての処理でサーバーを必要とします。いずれの場合も、TLS と強力な認証を設定したドメインを用意するか、スマートフォンを VPN に接続してください。
データベースを破損させずにセルフホスト型予算管理アプリをバックアップするにはどうすればよいですか？
稼働中の SQLite ファイルを単独でコピーしてはいけません。SQLite は最近の書き込みを別の write ahead log に保持するため、書き込み途中でコピーすると、取引データが欠落したり、コピーを開けなくなったりする可能性があります。コンテナを停止し、データディレクトリをコピーしてから、コンテナを再度起動してください。この規模のアプリであれば、数秒で完了します。Firefly III では、代わりにデータベースコンテナ内で mariadb-dump を実行し、環境ファイルもダンプと一緒に保管してください。結果を暗号化した restic リポジトリにサーバー外へ送信し、正常に動作することを確認するため、一度リストアしてください。
小規模な VPS では Firefly III は重すぎますか？
ここで比較している中では、Firefly III が最も重い選択肢です。公式の compose file が、アプリと cron コンテナに加えて MariaDB サーバーも実行するためです。個人の財務データは小さいため、メモリは取引データではなく、アイドル状態のデータベースプロセスに使われます。通常の日に自分のサーバー上で docker stats --no-stream を実行し、公開されている数値を信頼するのではなく、MEM USAGE 列を確認してください。可能な限り小さい構成にしたい場合は、Actual Budget と Wallos はどちらも、1 つのファイルに対して 1 つのプロセスだけを実行します。