TaxHacker: レシート画像をLLMで仕訳データに変えるセルフホスト型会計アプリ
Self-hosted AI accounting app. LLM analyzer for receipts, invoices, transactions with custom prompts and categories
ひと目でわかる
- これは何？
- 個人事業主と小規模事業者向けに、領収書や請求書の画像をLLMで構造化データへ変換するセルフホスト型アプリ。プロンプトとカテゴリを自分で書き換えられる点が設計の中心で、認識精度は選んだモデルにそのまま依存する。
- 誰に向いている？
- 導入を検討すべきなのは、領収書の仕訳を手作業から減らしたい個人事業主や小規模チームで、かつOpenAI・Gemini・MistralのAPIキー、またはOllama等のOpenAI互換エンドポイントを自分で用意できる人。逆に、会計基準への準拠や監査対応が要件に入る業務、確定申告の数値をそのまま出力したい人には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰の何を減らすアプリなのか
TaxHackerが狙うのは、領収書や請求書を1枚ずつ開いて金額と日付を転記する作業だ。READMEは対象をfreelancers、indie-hackers、small businessesと明記している。つまり経理部門を持つ企業ではなく、自分で確定申告や経費集計をする側の人間である。
処理の流れは単純で、レシートの写真、請求書のPDF、銀行明細などをアップロードすると、LLMがproduct names、amounts、items、dates、merchants、taxesを抽出し、Excelに近い表形式のデータベースへ保存する。読み取った内容はそのまま全文検索の対象になり、カテゴリやプロジェクトで絞り込める。
ここで押さえておきたいのは、TaxHackerは会計ソフトではなく抽出ツールだという点だ。複式簿記の仕訳を生成するとも、税務申告の様式に沿った帳票を出すともREADMEは書いていない。出力はCSVとデータアーカイブで、READMEの表現を借りれば「Generate comprehensive reports for your accountant or tax advisor」、つまり顧問先に渡す前段のデータ整備までが守備範囲である。
抽出の実体はプロンプトとカテゴリ定義
このアプリの中心にあるのは、書類を読むモデルそのものではなく、モデルに何を読ませるかを記述したプロンプトだ。READMEは「Customize any LLM prompt. Even system ones」と見出しを立て、設定画面からシステムプロンプトのテンプレート自体を書き換えられると説明している。
階層は3つある。全体のテンプレート、カテゴリ単位のルール、フィールド単位の抽出指示である。カスタムフィールドはREADMEの比喩では「creating extra columns in Excel」に相当し、メールアドレス、住所、プロジェクトコードなど、任意の情報を独自プロンプトで抜き出せる。項目の分割機能もあり、請求書に並んだ明細を個別の取引として切り出せる。
通貨まわりは別の仕組みで動く。書類から通貨を検出し、取引日時点のヒストリカルレートで基準通貨へ換算する。READMEは170以上の通貨とBTC、ETH、LTC、DOTなど14種の暗号資産に対応するとしている。換算レートをどのAPIから取得するかはREADMEに記述がないため、外部依存の有無は自分でコードを確認する必要がある。
設計思想として一貫しているのは、精度の問題をモデルではなくプロンプト側で解こうとしていることだ。裏を返せば、プロンプトを書かない限りこのアプリの利点はほとんど出ない。
対応LLMとローカル推論の現実的な線引き
クラウド側はOpenAI、Google Gemini、Mistralを選択できる。ローカル側はOllama、LM Studio、vLLM、LocalAIなど、OpenAI互換APIエンドポイントを公開するものなら接続できる。設定としてはエンドポイントURLとモデル名を差し替える形になる。
ただしREADMEはローカル推論についてかなり率直だ。ローカルモデルはOCRタスクが得意である必要があり、「results are not guaranteed :)」と書いている。領収書の読み取りは、かすれた印字、手書き、傾き、複数通貨の混在が同時に来る。汎用の小規模モデルでこれを安定させるのは難しく、GPUを積んでいない環境では待ち時間だけが増える結果になりやすい。
もう一点、READMEは「Only you're responsible for the quality and privacy of your data」と明記している。クラウドLLMを選べば書類の画像はその事業者のAPIへ送られる。セルフホストであることは、データが外に出ないことを意味しない。ローカル推論を選んだときだけその性質が変わる。ここを混同したまま導入すると、後で痛い目を見る。
起動までの手順と設定の勘所
READMEの本文にはインストール手順の記載がなく、デモ動画とtaxhacker.appへのリンク、そしてdocs/screenshots/配下の画像が示されているだけだ。したがって具体的なコマンドはリポジトリのルートにある構成ファイルを確認する必要がある。TypeScriptプロジェクトなので、一般的にはリポジトリをcloneしたうえでNode.jsの依存をインストールし、環境変数を設定して起動する流れになる。
設定すべき項目は大きく3つに分かれる。データベース接続、LLMプロバイダの選択とAPIキー、基準通貨である。READMEが挙げる機能から逆算すると、基準通貨を決めないとヒストリカルレート換算が成立せず、LLMプロバイダを決めないとアップロードした書類が処理待ちのまま「unsorted」に溜まる。
実運用では、いきなり全書類を流し込まないほうがいい。READMEには「Store multiple documents in 'unsorted' until you're ready to process them manually or with AI assistance」とあり、未処理のまま溜めておく状態が用意されている。まず数枚で抽出結果を確認し、カスタムフィールドのプロンプトを調整してから残りを流す。この順序なら、失敗してもやり直す範囲が小さい。
バックアップはデータアーカイブのダウンロード機能が使える。READMEは「Download complete data archives to migrate to other services」と説明しており、書類の実体と抽出結果をまとめて持ち出せる。
向かない場面と、精度以外の落とし穴
最も明確な限界は、このプロジェクトがearly developmentだとREADME自身が宣言していることだ。最新リリースはv0.8.5で、0.x系が続いている。破壊的な変更やデータ形式の変更が入る前提で扱うべきで、確定申告の本番データをこれだけに預ける判断は勧められない。
2つ目は、LLM抽出が本質的に確率的だという点である。同じレシートを2回読ませて同じ金額が返る保証はない。READMEは抽出の正確性について数値も検証方法も示していない。金額を扱う以上、抽出結果を人間が確認する工程は消せない。このアプリが減らすのは転記の手間であって、確認の手間ではない。
3つ目は、税務処理そのものは対象外という点だ。減価償却、消費税の区分、勘定科目の自動判定といった処理についてREADMEは触れていない。カテゴリはあくまで利用者が定義する分類であり、会計基準に紐づくものではない。
4つ目は運用コストである。セルフホストはサーバーの維持、アップデート、LLM APIの従量課金を利用者側が負う。クラウドLLMを選ぶ場合、書類の枚数が増えればAPI費用も増える。READMEはこの費用感について何も述べていない。
クラウド会計サービスとの分岐点
比較対象として分かりやすいのは、レシート撮影と自動仕訳をクラウドで提供する会計サービス群だ。違いはデータの所在と、抽出ロジックを書き換えられるかどうかの2点に集約される。
クラウド型は銀行口座やカード明細との連携、勘定科目の自動提案、申告様式への出力までを一貫して提供する。その代わり、書類は事業者のサーバーに保存され、抽出ルールは提供側が決める。利用者は待つだけだが、自社特有の書類形式に合わせて調整する手段は基本的にない。
TaxHackerはこの2点を反転させる。データは自分のサーバーに置かれ、抽出プロンプトは自分で書く。代わりに、連携も申告出力も自分で用意する。READMEが挙げる出力はCSVとアーカイブだけであり、そこから先は会計ソフトや税理士に渡す前提の設計だ。
どちらが優れているという話ではない。自社の書類形式が特殊で、既製のサービスでは読み取りが崩れる。あるいは書類を外部に出せない事情がある。そういう条件が揃っているときにだけ、セルフホストを選ぶ理由が生まれる。条件がなければ、クラウド型のほうが総コストは低い。
ライセンスとメンテナンスの見取り図
ライセンスはMIT。商用利用を含めて自由に使える条件で、改変物の公開義務もない。ただしMITは無保証であり、抽出結果の誤りによって生じた損害の責任を作者が負うことはない。会計データを扱う以上、この点は導入判断の前に理解しておく必要がある。
メンテナンスは活発で、2026年7月から9月にかけて複数回のリリースとpushが記録されている。ただし前述のとおり0.x系であり、バージョン間でデータ構造が変わる可能性は残る。アップグレード前にアーカイブを取得しておく運用が現実的だ。
依存関係の更新コストも見ておきたい。TypeScriptで書かれているため、Node.jsのバージョン、フロントエンドのビルドツール、そしてLLMプロバイダ側のAPI仕様変更という3方向から影響を受ける。特にOpenAI互換エンドポイントは各実装の差分が大きく、ローカル推論を選ぶ場合はモデルを差し替えるたびにプロンプトの再調整が必要になる。
READMEには作者が求職中である旨の記載がある。個人プロジェクトとしての継続性は、この種のツールを業務に組み込む際の現実的なリスク要因である。フォークして自走できる体制を前提に置くか、あるいは抽出結果を他形式へエクスポートして逃げ道を確保しておくかのどちらかになる。
編集部の結論
導入を検討すべきなのは、領収書の仕訳を手作業から減らしたい個人事業主や小規模チームで、かつOpenAI・Gemini・MistralのAPIキー、またはOllama等のOpenAI互換エンドポイントを自分で用意できる人。逆に、会計基準への準拠や監査対応が要件に入る業務、確定申告の数値をそのまま出力したい人には向かない。README自身がearly developmentであり自己責任での利用を求めている。最初に確認すべきは、手元の書類10枚程度を対象に、選んだモデルがdate・amount・vendor・line itemsをどこまで安定して埋められるか。ここが不安定なら、カスタムフィールドのプロンプトを書き直す作業が先に来る。
コミュニティノート