0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@sukimaengineer

ローカルLLMで自社専用の「AI税務担当」を作る ─ QLoRAとRAGで税務知識を追加する

0
Last updated at Posted at 2026-08-29

本記事の執筆と調査には Anthropic の Claude とそのリサーチ機能を使用しています。

はじめに

2026年8月下旬に、X（旧Twitter）で税理士とAIに関する投稿を見かけました。要約すると次のような流れです。

  • 税理士を名乗るアカウントが、生成AIの普及を理由に顧問先からの解約が続いており、廃業も考えていると投稿した
  • これに対して、1年後には解約した顧客が「記帳ミスの原因がわからない」「税務署の指摘に回答できない」「今の財務状況がわからない」と泣きつく展開になるのではないか、という趣旨の引用投稿が拡散した
  • 税務署から指摘を受けたときに「AIに全部任せたのでわかりません」で通る世界ではない、という反応も多く見られた

元の投稿が事実かどうかは判断できません（創作ではないかという指摘も見かけました）。ただ、後半の指摘は税務にAIを使うときの本質を突いていると思います。作業をAIに任せること自体は避けられない流れだとしても、「なぜその処理にしたのか」を後から説明できないAIは、税務調査の場ではむしろ足を引っ張ります。

そこで本記事では、次の問いを机上で検討します。

  • 既存のローカルLLMに、QLoRA（量子化したモデルに低ランクのアダプタを付けて学習する軽量なファインチューニング）やRAG（Retrieval-Augmented Generation。外部文書を検索して回答の材料にする手法）で税務知識を追加し、自社の税務に関する質問やトラブルの一次対応ができる「AI税務担当」を作ることはできるのか
  • 税理士が持つ暗黙知のようなものまで取り込めるのか
  • 税理士自身が、自分の過去の判断や回答でLLMを拡張するケースはどう考えればよいのか
  • OCR、会計ソフト、DB、Excel と連携させると、どこまで実務で使える形になるのか

本記事は机上検討です。税理士法や税務調査に関する記述は公開資料をもとにした技術者視点の整理であり、法的な助言ではありません。

本記事での確度の表記

表記 意味
（確認） 法令、官公庁サイト、論文、公式ドキュメント、当事者の公式発表で確認した事項
（報道） メディア記事、技術ブログなどの二次的な情報。数値は要検証
（推定） 上記をもとにした推定や意見

先に結論

  • 条文や通達のような「毎年変わる事実」はRAGで参照させ、QLoRAは回答の型や判断の癖といった「変わりにくい振る舞い」の適応に限定するのが、研究上の知見とも整合する構成です
  • 自社の税務のために自社で使う分には税理士法52条の問題は生じにくいと考えられますが、第三者向けに税務相談として提供する形にした途端に話が変わります。「自社専用」という縛りは、法的に安全側の設計でもあります
  • 「AIに任せたのでわかりません」を防ぐ鍵は、モデルの精度よりも、回答ごとに根拠と判断理由を残す仕組み（provenance）にあります
  • 暗黙知の取り込みや税制改正への追随は、一度作って終わりの機能ではなく、根拠ログを学習データに回す年次の運用サイクルとして設計すれば手の届く範囲だと考えています（推定）
  • OCR、会計ソフト、DB、Excel との連携は効果が大きい一方で、金額の計算や登録番号の照合はプログラム側に置き、LLM は分類・要約・根拠提示・例外の抽出に限定することが条件になります（推定）

1. 誰が何のために使うのかを先に決める

同じ「税務に詳しいLLM」でも、誰が誰のために使うかで技術的な設計も法的な扱いも変わります。本記事では次の3つを区別します。

想定 使う人 目的 本記事での扱い
A 自社の経理・総務担当 自社の記帳、申告準備、税務署からの問い合わせや税務調査への一次対応 主題
B 税理士本人 自分の業務の補助（下調べ、回答案の作成、過去の判断の検索） 11章で扱う
C ソフトウェア提供者 不特定の事業者や個人に向けた税務相談サービス 扱わない（5章で理由を述べます）

想定Aの「自社専用」を主題にしたのは、法的な線引きが比較的はっきりしていることと、自社が保有するデータ（過去の処理方針、顧問税理士とのやりとりの自社側の記録）をそのまま活かせるためです。3つの想定と税理士法との関係を図1にまとめます（根拠は5章で述べます）。

image.png

2. 知識の入れ方：暗記はRAG、型はQLoRA

「LLMに税務知識を追加する」と言ったとき、QLoRAで重みに覚え込ませる方法と、RAGで外部文書を検索して参照させる方法があります。この2つの使い分けについては、研究でかなりはっきりした知見が出ています。

  • Ovadia らの「Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs」（2023）は、知識集約的なタスクにおいて、RAGが教師なしファインチューニングを一貫して上回ったと報告しています。既存の知識でも新しい知識でも同じ傾向で、LLMはファインチューニングで新しい事実を取り込むことが苦手だとしています（確認：論文）
  • Gekhman らの「Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?」（EMNLP 2024）は、モデルが知らない事実をSFTで学習させると、習得が遅いうえに、習得が進むにつれてハルシネーションが増えることを示しています。事実知識は主に事前学習で獲得され、ファインチューニングはその使い方を教えるものだ、というのが結論です（確認：論文）
  • 税務ドメインでも同じ傾向が報告されています。中国の税務実務ベンチマーク TaxPraBen（2026年4月）では、税務データでファインチューニングした30Bモデルが汎用モデルに劣り、著者らは「ドメインのファインチューニングは高い性能を保証しない」と結論づけています（確認：論文。ただし評価対象は2024〜2025年初頭のモデルです）

税法はこの知見が特に効く領域です。税率、控除額、適用要件、施行日は毎年の税制改正で変わり、経過措置も付きます。これを重みに焼き込むと、翌年には自信を持って古い数字を答えるモデルになります。

手法 得意なこと 苦手なこと 本構成での役割
RAG 最新の文書を参照し、根拠を示す 検索に失敗すると答えられない。文書の構造化が必要 条文、通達、事例、改正情報の参照
QLoRA（SFT） 回答の型、文体、用語、確認手順の癖 新しい事実の記憶（ハルシネーションを増やす） 回答フォーマットと「担当者らしさ」の付与
選好学習（DPO：Direct Preference Optimization など） 保守的か積極的かといった判断傾向の調整 根拠なしに傾向だけが強まる危険 暗黙知の一部（6章）
継続事前学習 ドメイン語彙の底上げ 計算量が大きく、改正への追随に向かない 個人や一社の規模では対象外（推定）

Ovadia らと Gekhman らの研究は英語の一般ドメイン、TaxPraBen は中国語の税務での結果なので、日本語の税法テキストでどこまで同じ傾向になるかは実測が必要です（推定）。ただ、方向性として「事実はRAG、振る舞いはQLoRA」に賭けるのが妥当だと考えています。

image.png

3. 税法テキストはRAGにとって扱いにくい

「RAGで条文を参照する」のは簡単に聞こえますが、法令テキストは一般的な社内文書と性質が違います。法令向けRAGの研究（例：「An Ontology-Driven Graph RAG for Legal Norms」2025）では、法令が階層構造、大量の相互参照、改正による時系列変化を持つため、フラットなベクトル検索では「ある時点で有効な条文」を確実に引けず、時代錯誤な回答を生みやすいと指摘されています（確認：論文）。

image.png

税法に当てはめると、少なくとも次の課題があります。

課題 素朴なRAGで起きること 対策（推定）
適用年度 改正前後の条文が混ざって返る チャンクに施行日と適用年度のメタデータを付け、質問側の年度でフィルタする
相互参照 「第○条の規定により」の参照先が取れず、要件が欠ける 条文IDで参照先をたどる二段検索、またはグラフ構造で保持する
階層 法律、政令、省令、通達を同列に扱う 法令種別を保持し、回答でも「法律の要件」と「通達の取扱い」を分けて示す
引用の正確さ 条番号や項番号を取り違える 生成後に条文IDの実在と適用年度を機械的に照合する
チャンク境界 長い条文が途中で切れて意味が変わる 条・項・号の構造単位でチャンクを作る

幸い、e-Gov法令API（Version 2）は、Version 1のXMLに加えてJSONでの返却を選べるようになり、条・項・号の構造を保った法令本文、法令一覧、改正履歴、キーワード検索といった機能を持つため、構造化チャンクと改正追随の材料には困りません（確認：e-Govのリリース通知、デジタル庁の解説、OpenAPI仕様。個々のエンドポイントのパス名とパラメータは仕様書（swagger-ui）で確認してください）。Version 2 では特定時点の条文を取得する機能も追加されており（確認：e-Govのリリース通知）、改正前後の切り替えに直接使えます。時点指定や応答形式のパラメータ名は解説記事ベースなので、仕様書で確認してください。一方で、通達や質疑応答事例はHTMLやPDFで提供されており、構造化には前処理が必要です（推定）。

4. 使ってよいデータ、使ってはいけないデータ

RAGの索引やSFTデータに何を入れられるかは、精度以前に利用条件で決まります。調査した範囲では次のとおりです。

データ 提供元 利用条件 備考
法令条文（所得税法、法人税法、消費税法、国税通則法など） e-Gov法令API（デジタル庁） 無料、登録不要（OpenAPI 仕様に認証の定義がない）。出典を明記すれば商用・二次利用可（確認） 2025年3月にVersion 2が公開（確認：リリース通知は3月14日、お知らせページは3月19日と表記に揺れあり）。改正履歴や、構造を保った法令本文をJSONまたはXMLで取得できる（確認：デジタル庁の解説）
法令解釈通達、質疑応答事例、タックスアンサー、文書回答事例 国税庁 サイトの利用規約で「公共データ利用規約（第1.0版）」準拠を明記。出典明記と、改変した場合はその旨の表示が条件（確認） 「国が作成したかのような態様」での公表は不可
裁決事例、裁決要旨 国税不服審判所 同上（確認）
判例 裁判所（courts.go.jp） 公共データ利用規約を採用していない。無断改変禁止の記載あり（確認） 判決文そのものは著作権法13条により著作権の対象外だが、サイト掲載物の扱いは別。サイトからの取り込みは慎重に判断する
商用税務データベース（税務通信、TKC、第一法規など） 各社 各社の契約と規約に従う。LLMの学習やRAGへの格納は原則できないと考えるべき（推定） 有償の情報解析用DBの無断利用は著作権法30条の4ただし書に該当しうる（報道：法律事務所の解説）
実務書、Q&A書籍 各出版社 情報解析目的の利用（30条の4）は認められるが、出力で原文の表現を再現すると侵害になりうる（確認：文化庁ガイダンス） 検索して原文を表示する用途は別の検討が必要（推定）

公共データ利用規約はCC BY 4.0と互換性があると明記されています（確認：デジタル庁「公共データ利用規約（第1.0版）」。参考資料にURLを載せています）。ただし規約本文に「機械学習」という語はなく、CC BY互換であることからの解釈になります（推定）。また、2024年7月に旧「政府標準利用規約（第2.0版）」から移行しているため、古い記事とは名称が異なる点に注意が必要です（確認：デジタル庁）。

この表を見ると、想定Aの用途では、国税庁と国税不服審判所の公開資料だけでもかなりの範囲がカバーできそうです。商用DBや書籍を入れたくなる気持ちは分かりますが、自社専用であっても契約と規約の問題は残ります。実運用の前には、索引と学習データに入れるものを法務担当者や弁護士に確認してください。利用可否を図4にまとめます。

image.png

5. 法律の壁：「自社専用」がどこまでか

5.1 税理士法52条

税理士法は、「他人の求めに応じ」て行う税務代理、税務書類の作成、税務相談の3つを税理士業務と定め（2条1項）、税理士または税理士法人でない者がこれを行うことを禁じています（52条）。国税庁の「税理士制度のQ&A」では、「業とする」とは反復継続して行うことを指し、有償であることは必要ないとされています（確認：e-Gov法令検索、国税庁「税理士制度のQ&A」）。違反には2年以下の拘禁刑または100万円以下の罰金が定められています（59条）。

これをAIに当てはめると、次のような整理になると考えています。

行為 税理士法上の見立て（推定）
自社の担当者が、自社の税務についてAIに質問し、自社の申告に使う 他人の税務に応じるものではなく、52条の問題にはなりにくい。ただし申告の責任は自社にある
税理士が自分の業務の補助にAIを使う 税理士の責任のもとで行う限り可能。日本税理士会連合会の指針（報道）では、顧客情報の匿名化、最終責任が税理士にあること、AI利用の顧客への説明が求められているとされる
税理士でない者が、他社や個人に向けてAIによる税務相談を反復継続して提供する 「税務相談」を業として行う形になりうる。無償でも該当しうる
一般的な税制の説明にとどめる 国税庁のチャットボット「ふたば」や会計ソフト各社のAI機能は、個別判断を避け一般的な事項の案内に限定する設計で運用されている（確認：国税庁サイト、報道）

「経費になりますか」「贈与税はかかりますか」といった個別事案の判断は税務相談に含まれると解説する税理士が多く（報道：税理士の解説記事）、想定Cはこの線を踏み越えやすい形です。本記事で想定Aに絞っているのは、この線引きが理由です。

想定Aが52条の問題になりにくいのは、税理士業務が「他人の求めに応じ」て行うものと定義されているためで、自社の税務を自社で処理することはそもそも税理士業務に当たらないと考えられます。逆に、グループ会社など別法人の税務を代わりに扱うと「他人」に当たりうるので、想定Aは同一法人の範囲に限定します（推定）。いずれにしても、この節は公開資料をもとにした技術者視点の整理であり、実際に運用する前には税理士や弁護士に確認してください。

5.2 「AIに任せたのでわかりません」がなぜ通らないか

税務調査での説明責任は、AIを使ったかどうかに関係なく納税者の側にあります。条文レベルでは次のとおりです（確認：e-Gov法令検索）。

根拠 内容 説明できない場合に起きうること
所得税法148条、232条 青色申告者、白色申告者それぞれの帳簿書類の備付けと保存義務 青色申告承認の取消（150条）、推計課税（156条）
国税通則法68条 隠蔽または仮装があった場合の重加算税（過少申告35%、無申告40%） 過去5年以内の再犯で10%加重。電子帳簿保存法に関する不正でも10%加重
電子帳簿保存法 電子取引データの電子保存義務（2023年末で宥恕措置が終了。相当の理由がある場合の猶予措置は別途ある） 要件を満たさない保存は帳簿書類の保存義務違反となりうる（推定）

根拠ログの有無で何が変わるかを図5に示します。

image.png

つまり「わかりません」は、帳簿の裏付けを説明できない状態そのものです。AIの精度をいくら上げても、根拠を残していなければこの状態は解消されません。ここから8章の設計につながります。

6. 暗黙知はどこまで載るか

税理士の暗黙知として、税理士自身の発信や業界記事でよく挙げられているのは次のような領域です（報道：税理士のブログ、業界誌）。

  • 経費性など、グレーゾーンの判断
  • 「この処理は調査で突かれやすい」といった否認リスクの見積もり
  • 税務調査での調査官との折衝
  • 顧客の業種、規模、過去の経緯を踏まえた処理方針
  • 年度をまたぐ処理の一貫性

これらをLLMに取り込む手段と、期待できる範囲を整理します。

暗黙知の種類 取り込み手段 期待できること 限界
判断の型（何をどの順で確認するか） 過去の回答やメモから、理由付きのSFTデータを作ってQLoRA 回答の構造と着眼点の再現 判断の妥当性は保証されない
過去事例の当てはめ 匿名化した過去事例をRAGに入れ、類似事例を提示する（事例ベース推論） 「前回はこう処理した」の検索と一貫性の確保 事例が少ない領域では機能しない
保守的か積極的かの判断傾向 選好データを作り、DPOなどで調整 回答の傾向の調整 根拠なく傾向だけが強まる危険
調査官との折衝、対人対応 該当する手段がない 言語化されておらず、データ化が難しい（推定） 人が担う前提

暗黙知を「言語化しやすいか」「過去の記録があるか」で分けると、手段の対応は図6のようになります。

image.png

想定Aで現実的なのは、自社が保有する過去の処理記録と、顧問税理士から受けた回答の自社側の記録を、匿名化したうえでRAGに入れることです（推定）。「自社の暗黙知」は税理士の暗黙知そのものではありませんが、税務調査で問われるのは自社の処理方針の一貫性なので、実務上はこちらの価値が高いと考えています。

暗黙知データの扱いには制約もあります。税理士には守秘義務（税理士法38条）があり、個人情報保護法も適用されます（確認：e-Gov法令検索）。顧問先の情報をそのまま索引や学習データに入れることはできないと考えるべきで、匿名化が前提になります（推定）。ローカルLLMはデータが外部に出ない点で有利ですが、匿名化、アクセス管理、生成物の責任といった問題はローカルでも残ります（推定）。

7. 想定環境での実現性

個人や小規模な事務所で現実的な環境として、Apple Silicon Mac（ユニファイドメモリ64〜128GB）と、16〜32GBクラスのNVIDIA GPUを想定します。

環境 学習ツール QLoRAの目安 備考
Apple Silicon（64〜128GB） mlx-lm 量子化済みモデルを指定すると自動的にQLoRAになる（確認：ドキュメント）。作業メモリは7Bで7〜8GB、14Bで14〜18GB程度（報道） 128GBなら30B級のQLoRAも視野に入る（推定）
NVIDIA RTX 50系 16GB Unsloth Blackwell世代に公式対応。CUDA 12.8系が前提（確認：公式ドキュメント）。7〜8BのQLoRAは1枚で可能、14Bは系列長など条件次第（報道） 複数枚構成でも、QLoRAはまず1枚で完結させるのが簡単（推定）
クラウドGPU Unsloth など 70B級もレンタルで可能（報道） 費用は時価。ブログの値はそのまま信用しない

mlx-lmでの学習は、量子化済みモデルと学習データのディレクトリを指定するだけで始められます。--data に指定するディレクトリには train.jsonl と valid.jsonl を置き、各行は messages 形式（system、user、assistant の会話）で書けます（確認：mlx-lm の LORA.md。オプション名は版によって変わります）。

mlx_lm.lora \
  --model <4bit量子化モデル> \
  --train \
  --data ./data \
  --iters 1000 \
  --batch-size 4 \
  --learning-rate 1e-5 \
  --max-seq-length 4096 \
  --grad-checkpoint \
  --adapter-path ./adapters/tax-style

必要メモリはモデルの規模だけでなく、系列長、バッチサイズ、勾配チェックポイントの有無で大きく変わります。表の数値は短めの系列長での目安と考えてください（推定）。

推論側は4bit量子化で14〜30B級が常用範囲になります（推定）。128GBクラスのユニファイドメモリでは、27B級のdenseを8bitで、あるいは100〜280B級のMoEを2〜4bitで動かすこともできます（9章の表を参照）。16GBクラスでは、gpt-oss-20b（MXFP4量子化で約13GB、公式モデルカードが16GBでの動作を明記）、Qwen3系の14B、Gemma 4の12Bあたりが実用の目安です（確認：モデルカード、報道）。QLoRAの学習時間は、7Bで数千件のデータなら1〜2時間程度という報告があります（報道）。数値はいずれも目安で、実機での測定が必要です。

8. 説明責任を残す設計（provenance）

5.2節の結論から、「AI税務担当」の本体はモデルではなく、回答ごとに何を残すかの設計だと考えています。

残すもの 内容 税務調査での対応関係
参照した根拠 条文ID、通達番号、事例のURL、取得日 処理方針の根拠として提示できる
判断理由 どの要件にどの事実を当てはめたか 質問応答記録書で問われる「なぜ」への回答材料
不確実性 確信度、別の解釈、要確認事項 税理士に相談すべき論点の抽出
入力データ 対象の仕訳、証憑との紐付け 帳簿の摘要欄や証憑との突合
証憑の取り込み記録 OCR の結果と信頼度、適格請求書の登録番号の照合結果 証憑から仕訳までの経路の説明（10章）
版情報 モデル、アダプタ、索引、適用年度のバージョン 後から同じ回答を再現できる
人の承認 誰がいつ確認したか 「AIが決めた」ではなく「AIの整理を人が承認した」記録

具体的には、仕訳の摘要欄や補助資料に「根拠ID」を書き、根拠IDから上の記録をたどれるようにする運用を考えています（推定）。また、条文IDが実在するか、質問の年度で有効かを生成後に機械的に照合すれば、条番号の取り違えというもっとも起きやすい誤りは回答前に弾けます（推定）。根拠IDを起点にした紐付けを図7に示します。

image.png

条文IDの照合で大事なのは、自由文の回答から条番号を抜き出そうとしないことです。参照した条文はモデルに構造化して出力させ、その値を索引と法令APIの改正履歴に突き合わせます。流れを疑似コードで示します（推定。フィールド名やAPIの呼び方は仕様書に合わせます）。

# 回答本文とは別に、参照条文を構造化して出力させる
citations = answer.citations   # 例: [{"law_id": "...", "article": 37, "paragraph": 1}]

for c in citations:
    exists = index.has_article(c["law_id"], c["article"], c["paragraph"], query_year)
    in_force = law_api.is_in_force(c["law_id"], query_year)   # 改正履歴から判定
    if not (exists and in_force):
        flag_for_review(c)        # 要確認フラグを立て、回答に反映する

9. PoCの候補アーキテクチャ

ここまでの検討をまとめると、PoCは図8のような構成になります。

image.png

要素 候補 選定の観点（推定）
ベースモデル 次の表に示す2026年8月時点の候補から選ぶ 日本語能力、ライセンス、ツール呼び出し対応、手元の環境で動く規模
埋め込み Ruri v3（日本語特化、ModernBERT-Jaベース、系列長8192。検索ではクエリ側に「検索クエリ: 」、文書側に「検索文書: 」のプレフィックスを付ける。v1/v2の「クエリ: 」「文章: 」から変更されている（確認：モデルカード））、BGE-M3（多言語、denseとsparseの併用）、Qwen3-Embedding 日本語精度とハイブリッド検索への対応
リランカー Ruri Reranker、bge-reranker-v2-m3 上位50件を5件程度に絞る
ベクトルDB Qdrant、Chroma など メタデータフィルタ（適用年度、法令種別）への対応
RAG基盤 LlamaIndex、LangChainで自作。またはOpen WebUI、AnythingLLM、Dify 構造化チャンク、条文ID照合、質問を税務用語に言い換えてから検索する前処理、参照先をたどる多段検索を入れるには自作が扱いやすい
QLoRA mlx-lm、Unsloth 500〜2,000件、1〜3エポックから始める

ベースモデルの候補は次のとおりです。16GBクラスのGPU、32GBクラス（32GBのGPU1枚、16GBのGPU2枚、32GBのユニファイドメモリ）、128GBクラスのユニファイドメモリの3段階に分けています。128GBクラスでは、27B級のdenseに加えて、100〜280B級のMoEも2〜4bit量子化で射程に入ります。ライセンスと規模は各社のモデルカードと配布ページによるもので、版ごとに変わるため導入時に必ず再確認してください。

16GBクラスで動く候補

モデル 規模 ライセンス 備考
Qwen3.8-27B 27B の dense。画像・動画入力対応、コンテキスト262K Apache 2.0 2026年8月14日公開。Q4_K_M で約19GB、MLX の4bit版も公開。16GBでは KVキャッシュ量子化などの工夫が必要（確認：モデルカード、GGUF配布ページ）
Qwen3.5〜3.8 の中小型 9B、14B級の dense、35B-A3B の MoE など Apache 2.0 14B級は16GBで実用（報道）
gpt-oss-20b 21B（アクティブ3.6B）の MoE Apache 2.0 MXFP4で約13GB。16GBクラスの主力候補（確認：モデルカード）
Gemma 4 E2B、E4B、12B、26B-A4B、31B Apache 2.0（Gemma 3以前の独自規約から変更） 12Bは16GBで実用。31Bの dense は4bit（Q4_0）で約18GB（確認：モデルカード、GGUF配布ページ）
LLM-jp-4 8B の dense、32B-A3B の MoE Apache 2.0（確認：モデルカード） 国立情報学研究所の LLM-jp。2026年4月3日公開。8B は Q4_K_M で約5GB（確認：GGUF配布ページ）
Swallow系 8B など ベースモデルのライセンスに従う 日本語の継続事前学習
Sarashina2.2 0.5〜3B MIT 小型。分類や前処理の補助向き（推定）
PLaMo 2 8B PLaMo コミュニティライセンス 商用利用は条件付き

32GBクラスで動く候補

モデル 規模 ライセンス 備考
Qwen3.8-27B 27B の dense Apache 2.0 Q4_K_M で約19GB。32GBなら4〜6bitでKVキャッシュを含めて余裕がある。8bit（約29GB）はKVキャッシュの分が足りず厳しい（確認：GGUF配布ページ。8bitの判断は推定）
Qwen3.6-35B-A3B 35B（アクティブ3B）の MoE。コンテキスト262K Apache 2.0 2026年4月16日公開。Q4_K_M で約20GB。アクティブ3Bなので dense の27Bより生成が速い（確認：GGUF配布ページ）
Gemma 4 31B 31B の dense Apache 2.0 Q4_0 で約18GB、QAT版の4bitも約18GB。8bitは約33GBで32GBに収まらない（確認：GGUF配布ページ、Unsloth のドキュメント）
Gemma 4 26B-A4B 26B（アクティブ4B）の MoE Apache 2.0 QAT版の4bitで約15GB（確認：Unsloth のドキュメント）
LLM-jp-4 32B-A3B 32B（アクティブ約3.8B）の MoE。コンテキスト65K Apache 2.0（確認：モデルカード） 国産。Q4_K_M で約21GB、MXFP4 なら約18GB（確認：GGUF配布ページ）
ELYZA-Shortcut-1.0-Qwen-32B 32B の dense Apache 2.0（確認：モデルカード） Qwen2.5-32B-Instruct をベースにした国産の日本語向け調整モデル。Q4_K_M で約20GB（確認：GGUF配布ページ）
gpt-oss-20b 21B（アクティブ3.6B）の MoE Apache 2.0 約13GB。余った領域を長いコンテキストのKVキャッシュに回せる

16GBのGPUを2枚使う場合は、llama.cpp の層分割や vLLM のテンソル並列で2枚に分けて載せる必要があり、32GBのGPU1枚より手間と速度のロスがあります（推定）。学習側も、32GBあれば27B級のQLoRAが視野に入ります（推定）。

128GBクラスのユニファイドメモリで動く候補

モデル 規模 ライセンス 備考
Qwen3.8-Flash-Next 125B（アクティブ6B）の MoE に、51B の N-gram 埋め込みと 4B の MTP 層を加えて約180B。コンテキスト262K Qwen Community License 1.0。商用利用は可。月間1億アクティブユーザーまたは月商2,000万米ドルを超える製品にはモデル名の表示義務、MaaS やコーディング／オフィス支援の AI アシスタント事業には別途の許諾が必要（社内利用は除外）（確認：LICENSE） 2026年8月26日公開。Qwen4 世代のアーキテクチャの先行公開。4bitで約93GBのうち常駐が必要なのは約55GBで、N-gram 埋め込みは SSD に置ける（報道）。128GB Mac 向けに2bit／4bit混合の MLX 版（約68GiB）も配布されている（確認：配布ページ）
DeepSeek-V4-Flash-0731 284B（アクティブ13B）の MoE。コンテキスト1M MIT 2026年7月31日に正式版。公式の FP4＋FP8 混合で約146GB。DwarfStar（ds4、antirez 氏による DeepSeek V4 専用の推論エンジン）では、routed expert を2bitに落とした q2-imatrix 版が96〜128GB Mac の推奨構成で、2bit／4bit混合（q2_q4）版は約98GB。MXFP4 版（約156GB）は expert を SSD からストリーミングして動かす（確認：モデルカード、GitHub antirez/ds4。混合版のサイズはコミュニティビルドの配布ページ）
Qwen3.5-122B-A10B 122B（アクティブ10B）の MoE。コンテキスト262K Apache 2.0（確認：モデルカード） 2026年2月公開。Q4_K_M で約81GB（確認：Ollama の配布ページ）
gpt-oss-120b 117B（アクティブ5.1B）の MoE Apache 2.0 MXFP4で約60GB。80GB GPU 向けの設計だが128GBクラスなら余裕がある（確認：モデルカード）
Qwen3.8-27B 上の表と同じ Apache 2.0 128GBなら8bit（約29GB）で常用できる（確認：GGUF配布ページ）

収まらない側の目安として、DeepSeek-V4-Pro（1.6T、アクティブ49B）、Kimi K3、GLM-5.2（744B）などは4bitでも数百GBになり、128GBクラスの単機では対象外です（推定。一部は複数台での分散実行例がある）。

評価は、国税庁の質疑応答事例をQAデータとして使い、「根拠条文を正しく引用できた割合」を主指標、「根拠を示せなかった回答の割合」を副指標にするのが妥当だと考えています。

参考として、日本語の税務に特化し、現行のオープンモデルを横並びで評価した公開ベンチマークは、調査した範囲（2026年8月）では見つかりませんでした。海外の税務ベンチマークには次のものがあります。

ベンチマーク 対象 主な結果
TaxEval v2（Vals AI、2026年8月19日更新） 米国税務のQA。テストセット1,223問は非公開、判定は Claude Sonnet 4.5 上位はクローズドモデルで77%前後（Muse Spark 77.68%、Claude Sonnet 4.6 77.11%、Claude Fable 5 76.94%）。オープンウェイトは Nemotron 3 Ultra が73.10%で3位。上位2モデルの数値は取得できず（Kimi K3 などが候補）（確認：Vals AI のページ。ただしページ内で版と数値の表記に揺れがあり、オープン上位の数値は動的表示のため未取得）
TaxPraBen（arXiv:2604.08948、2026年4月） 中国の税務実務、7.3K問、19モデル クローズド優位。税務特化でファインチューニングした30Bモデルが汎用モデルに劣る。オープンモデルは2024〜2025年初頭の6〜9B世代のみ（確認：論文）
LE-BTL（SSRN 5941734、インド税法） インド税法、12モデル 上位はクローズドで正答率50%超。オープンの DeepSeek V3 は50%未満。80%を超えたモデルなし（確認：論文要旨）

3つに共通するのは、税務ドメインではクローズドモデルの優位が続いていることと、最上位でも80%に届かないことです。オープンモデルの最良はベンチマークによって50%未満から70%台半ばまで幅があり、TaxEval v2ではクローズド上位との差が数ポイントまで縮まっています。図9にTaxEval v2の上位を示します。

image.png

2026年時点でも、ローカルLLM単体に税務の判断を任せるのは時期尚早で、RAGで根拠を与え、人が確認する前提で設計する理由がここにあります。ただし、いずれも米国・中国・インドの税法での評価であり、日本語の税務でどうなるかは自前で測る必要があります（推定）。質疑応答事例を使った評価を設計に組み込んでいるのはこのためです。

10. アプリケーションと連携させる：OCR、会計ソフト、DB、Excel

ここまでの構成は「質問に根拠付きで答える」ところまでで、実務で効く形にするには3つの穴が残ります。証憑（領収書、請求書）を取り込む経路がないこと、金額の計算をLLMに任せると危ないこと、結果を帳簿に反映する経路がないことです。この穴はOCR、会計ソフト、DB、Excelとの連携で埋まりますが、効果が出るかどうかは「LLMに何をさせないか」で決まります。

10.1 役割分担：数値はプログラム、判断の補助はLLM

処理 担当 理由
金額の合算、税率・税区分の計算 プログラム、DB、会計ソフト LLMの数値の捏造を排除し、再現性を確保する
借方・貸方の合計一致の検算 プログラム 後から検証できる
適格請求書の登録番号の実在照合 国税庁の Web-API とプログラム 事実の照合はLLMの仕事ではない
勘定科目の分類、摘要の要約 LLM（人の承認つき） 文脈の理解が強み
根拠条文・通達の提示 RAG と LLM 2〜4章の構成をそのまま使う
例外・異常値の抽出 LLM とルール 稀な科目への大口計上などのフラグ

OCRの誤読やLLMの数値のハルシネーションは、そのまま仕訳に伝播すると二重計上や誤った税額につながります（推定。10.9節の事例を参照）。決定論的にできる処理はプログラムに寄せ、LLMには分類・要約・根拠提示・例外の抽出だけをさせる、というのが本章を貫く原則です。

10.2 証憑を取り込む：ローカルで動くOCRの候補

日本語の領収書・請求書をローカルで読む候補です。2026年8月時点で確認できた範囲で整理します。

モデル 種別 日本語（特に縦書き） ライセンス 備考
YomiToku 日本語特化の文書解析パイプライン 日本語の活字に特化（7,000字種超）。手書き認識の強化は製品版の機能（確認：README） コードもモデルの重みも CC BY-NC-SA 4.0。商用利用は製品版の商用ライセンス（確認：README） 非営利に当たるかの判断基準はリポジトリ内のガイドライン（docs/commercial_use_guideline.ja.md）にある
PaddleOCR-VL 0.9B の小型視覚言語モデル 縦書き日本語の実データで評価対象中の最高精度（確認：論文） Apache 2.0（確認：モデルカード） 最新は v1.6（2026年5月）。縦書きが多い証憑で第一候補
PP-OCRv5 文字認識特化 縦書きも認識可（報道） Apache 系 軽量
DeepSeek-OCR 視覚言語モデル 横書きは強いが縦書きで大きく崩れる（確認：論文） オープン 縦書き証憑には不向き
Tesseract 従来型OCR 単純な横書き以外は弱い（報道） Apache 2.0 CPUで動く
汎用の視覚対応LLM（Qwen3.8-27B、Gemma 4 など） 汎用 縦書きは弱いが、追加学習で大きく改善する（確認：論文） 各モデルのライセンス 9章のベースモデルをOCRにも使える

縦書き日本語の評価は、早稲田大学と国立情報学研究所による論文（arXiv:2511.15059、2025年11月）が参考になります。実際の縦書き文書100ページでは PaddleOCR-VL が文字誤り率20.1で最良、DeepSeek-OCR は182と崩壊し、汎用の視覚言語モデルも軒並み劣化する一方、Qwen2.5-VL-7B を縦書きデータで追加学習すると誤り率が劇的に下がったと報告されています（確認：論文）。「事実はRAG、型はQLoRA」という2章の整理は、OCRでは「読み順や書式の癖は追加学習で直る」という形で当てはまります（推定）。

会計ソフト各社のOCRも参考になります。freee の OCR v3（2026年1月）は、第三者の検証で印刷レシートの金額が94%程度と報告されていますが、裏を返せば100枚に6枚は誤るので、金額の全数確認は省けないという指摘もあります（報道：第三者検証）。日本語の領収書・請求書に特化した公開ベンチマークは限られており、導入前に自社の証憑で回帰テストをする前提です（推定）。

10.3 電子帳簿保存法とインボイスに合わせる

取り込みパイプラインは、電子帳簿保存法の要件を満たす形で設計する必要があります。

要件 内容（確認：国税庁「電子帳簿保存法一問一答」） パイプラインでの対応（推定）
検索要件 取引年月日、取引金額、取引先の3項目で検索できること OCRでこの3項目を抽出し、DBの索引にする
タイムスタンプ 訂正・削除の履歴が残るシステムで保存する場合は付与不要 追記型のログで訂正・削除履歴を残す
適正事務処理要件 2022年1月に廃止 相互けん制などの社内規程は不要になったが、承認記録は根拠ログとして残す
解像度・階調 一定の解像度が必要。一般書類はグレースケール可 スキャン時の設定で担保し、OCRの推奨解像度と両立させる

適格請求書の登録番号（T＋13桁）は、国税庁の「適格請求書発行事業者公表システム Web-API」で実在と名称を照合できます。アプリケーションIDの申請（無料）と利用規約への同意が必要で、法人番号システムの Web-API と同じIDで使えます（確認：国税庁サイト）。ここはLLMに判断させず、コードで照合する典型例です。

10.4 会計ソフト、DB、Excelにつなぐ

連携先 手段 2026年8月時点の状況
freee会計 API（OAuth 2.0、JSON）。公式 MCP サーバー「freee-mcp」 2026年3月2日に freee-mcp を OSS として公開、3月27日にリモート版の提供を開始（確認：freee プレスリリース）。API利用はプロフェッショナルプラン以上（報道）
マネーフォワード クラウド会計 API。公式のリモート MCP（ローカルで動かす構成も案内） 士業事務所向けにβ提供していたリモート MCP を、2026年3月26日に全プランで提供開始。仕訳の参照・登録、試算表の参照などに対応（確認：マネーフォワード プレスリリース）
弥生会計 e-Tax データ（.xtx）の書き出し e-Tax ソフトに取り込んで送信する流れ（報道）
仕訳帳・総勘定元帳・試算表のCSV DuckDB、SQLite に取り込み、LLMがSQLを書いて問い合わせる 公開ベンチマークの高い正答率は実データでは再現しにくいという報告が複数ある（報道）。生成したSQLは実行前にレビューする
Excel の台帳（減価償却、固定資産など） openpyxl、pandas でローカル処理。Excel 向けの MCP サーバーもある Microsoft 365 Copilot や Claude in Excel のようなクラウド製品はデータが外部に出るため、ローカル完結なら openpyxl とローカルLLMの組み合わせになる（推定）
法令 e-Gov 法令API。コミュニティ製の MCP サーバーもある 3章の RAG と共存させる

ツール呼び出しの信頼性については、ローカルモデルでは Qwen3 系が安定しており、単一のツール呼び出しは実用水準ですが、3つ以上のツールを自律的に連鎖させると不安定になるという報告があります（報道）。当面は「単一ツールの呼び出し＋人の承認」を基本にし、書き込み（仕訳の登録）は必ず人が承認してから実行する設計が妥当です（推定）。

10.5 主帳簿をどこに置くか：オープンソースの会計ソフトという選択肢

データを外部に出さないという要件を徹底するなら、主帳簿そのものを手元に置く選択肢があります。複式簿記に対応した現役のオープンソース会計ソフトは複数ありますが、日本の税制（消費税の税区分、インボイス、決算書の様式、電子帳簿保存法の優良な電子帳簿、e-Tax への書き出し）を標準で満たすものは、調査した範囲では見当たりませんでした。2026年8月時点の主な候補を整理します。

ソフト ライセンス 特徴 日本の税制への対応 LLM との連携
GnuCash GPL デスクトップ型。SQLite や PostgreSQL をバックエンドにできる。5.14 が2025年12月公開 日本語UIはある。消費税や請求書は日本の商慣習に合わず、有志のツールで補う（報道） 公式の MCP はない。Python バインディングや piecash でスクリプト連携（確認：GnuCash Wiki）
Odoo Community LGPL-3.0 ERP。PostgreSQL。19系が2025年10月公開。会計の高度な機能は有償の Enterprise 側 OCA の l10n_jp に勘定科目と消費税のテンプレートがあるが未完成でコミュニティ保守（確認：OCA の GitHub） コミュニティ製の MCP サーバーが複数ある（確認：GitHub）
ERPNext GPL-3.0 ERP。MariaDB。REST API と Webhook。v16 が2026年1月公開 本体の日本対応は弱く、商用の ERPNext.JP が税区分や適格請求書の出力に対応（報道）。無償の本体で同じ機能が使えるかは別途確認が必要 REST API 経由
Dolibarr、Tryton、iDempiere、LedgerSMB GPL 系 ERP。複式会計あり。いずれも2026年に更新 日本ローカライズはほぼない REST や JSON-RPC の API
Beancount、hledger、Ledger GPL-2.0、GPL、BSD プレーンテキスト会計。テキストファイルが帳簿で、Git で履歴管理できる 有志が青色申告に使った事例はあるが、消費税や減価償却は自作（確認：利用者のブログ） Beancount に MCP サーバーがある（確認：GitHub）。テキストなので RAG と生成に向く
Akaunting、Invoice Ninja BSL 1.1、Elastic License オープンソースを名乗るが OSI 承認のライセンスではない。Akaunting は2ユーザー、1社、1,000件の請求書を超える本番利用を認めておらず、各版の公開から4年後に GPLv3 へ移行する条件（確認：ライセンスページ）

日本発のものでは、青色申告決算書の作成や証憑の紐付けまで扱い、WebMCP 経由で LLM につなぐ個人開発のアプリ（e-shiwake）や、CSV から貸借対照表と損益計算書を集計する CLI（aoiro）などがあります（確認：GitHub、Qiita）。いずれも個人開発で規模が小さく、税制改正への追随は保証されません。

海外製の ERP に共通する日本特有の落とし穴もあります。インボイス制度では、消費税額の端数処理を1枚の適格請求書につき税率ごとに1回行う必要があります（確認：国税庁のインボイス制度 Q&A）が、海外製品には明細ごとに税額を丸める設計のものがあり、設定の変更と検証が要ります（推定）。月締めの合算請求書も標準機能にはないことが多く、カスタマイズが必要です（報道）。

オープンソースを主帳簿にする場合、次の点が自分の責任になります。

論点 内容
e-Tax への提出 法人の財務諸表は XBRL または CSV 形式のみで、PDF は不可（確認：e-Tax サイト）。オープンソースから直接書き出すツールは見当たらず、e-Tax ソフトや確定申告書等作成コーナーへの手入力になる
優良な電子帳簿 訂正・削除の履歴、帳簿間の相互関連性、検索の3要件を満たし届出をすれば、過少申告加算税が軽減される（確認：国税庁）。技術的には Git の履歴や DB の検索で満たせるが、立証は利用者の責任。JIIMA 認証を受けたオープンソースは確認できなかった
税制改正への追随 税率、様式、インボイス対応の更新を自分で行う
銀行連携と自動仕訳 商用クラウドの強みで、オープンソースにはほぼない

用途別に整理すると、現実的な構成は次の3つに絞られます（推定）。

案 向く相手 構成
A 個人事業主、小規模 Beancount や hledger を主帳簿にし、Git で履歴を持ち、MCP で LLM から照会と仕訳の下書きを行う。bean-check などの検証と人の承認を通す。決算書は作成コーナーに手入力
B 法人、在庫や請求業務がある Odoo Community と l10n_jp（または ERPNext）を主帳簿にし、MCP で LLM 連携する。決算書の様式と e-Tax 連携は手作業が残る
C 税制追随とサポートを重視 freee やマネーフォワードを主帳簿にし、CSV や API で DuckDB や Beancount に流して LLM 分析用の副帳簿にする。主帳簿はクラウドなので「外部に出さない」とはトレードオフ

プレーンテキスト会計のコミュニティでも、LLM は勘定科目を取り違え金額を誤ることがあるので、検証コマンドと人の承認を通す「補助者」として使うという認識が共有されています（確認：Beancount のブログ）。10.1節の役割分担は、主帳簿がどこにあっても変わりません。

10.6 e-Taxとの線引き

商用の会計ソフトなら、申告データを .xtx などの形式で書き出し、e-Tax ソフトに読み込んで送信する流れが一般的です（オープンソースを主帳簿にする場合は10.5節のとおり手入力が残ります）。送信には電子証明書（マイナンバーカードなど）と利用者識別番号が必要です（報道）。LLMとプログラムが担当するのは申告書の下書き、整合性のチェック、添付漏れの確認までにし、電子署名と送信は人が行います。マイナンバーと電子証明書はLLMのコンテキストに載せません（推定）。

10.7 社内ルールをどこに持つか

ルールの種類 置き場所 理由
回答の型、OCRの読み順や書式の癖 QLoRA 追加学習で直る（10.2節）
規程、過去仕訳、取引先ごとの処理方針 RAG 更新が多く、根拠の提示が要る
勘定科目マスタ、取引先ごとの固定処理 ルール表（決定論的な対応表） 揺れてはいけない
定型取引の勘定科目の推定 従来の機械学習（勾配ブースティングなど） 少量・定型のデータでは軽量で説明しやすい（報道）。確度が低いものだけLLMと人に回す（推定）

10.8 セキュリティ：マイナンバーの分離

マイナンバーには番号法の安全管理措置（組織的、人的、物理的、技術的）が義務づけられており、技術的措置としてアクセス制御、アクセス者の識別と認証、外部からの不正アクセスの防止、漏えいの防止が求められます（確認：法令、ガイドライン）。会計データを扱うLLMとツール群からは、マイナンバーを別のDB・別の権限で分離し、LLMのコンテキストに投入しない設計にします。ツールの権限は読み取りを基本にし、書き込みは承認フローを挟み、すべてのアクセスをログに残します。会計データ全体についても、保存時の暗号化、外部API（会計ソフト、国税庁のWeb-API）との通信のTLSと認証、LLMを動かすマシンのネットワーク隔離が必要で、申告書の下書きや書き出した .xtx などの生成物も、アクセス権を限定したローカルの保存場所に置きます（推定）。

10.9 期待できる効果と、起きうる失敗

公表されている効果としては、経費精算の規定違反を自動検出して差し戻し率を60%減らした事例や、過去半年に1件しかない勘定科目への大口計上を即座にフラグする異常検知などがあります（報道：各社の事例）。一方で、会計ソフトのAIアシスタントは一般的な経理の質問には答えられても個別の税務判断には力不足という評価があり、OCRの誤読や視覚言語モデルの数値のハルシネーションが仕訳に伝播すると二重計上や誤った税額につながります（報道）。

人手確認へ回す条件を先に決め、条件に当たったら自動で担当者に通知する仕組みにしておくと運用が安定します（推定）。

条件 内容
OCRの信頼度 金額の項目の信頼度がしきい値未満
合計不一致 借方・貸方の合計が一致しない
登録番号 Web-API の照合で見つからない
稀な計上 過去半年で稀な勘定科目への大口計上
重複疑い 同一取引先・同一金額・近接日の仕訳

これらをまとめた連携の全体像を図10に示します。9章の構成に、OCRと決定論処理の層、ツールの層、帳簿と申告への出口を足した形です。

image.png

11. 税理士自身が拡張する場合

想定Bでは、税理士が自分の過去の回答や判断記録でLLMを拡張することになります。エンジニアの手を借りずに進めるなら、RAGはLM Studio、AnythingLLM、Open WebUI、Difyといったローカルで動くGUIツールで構築できます。QLoRAはデータ整形と学習環境の準備が必要で、現時点では技術者の支援があったほうが現実的です（推定）。

会計ソフト各社の動きも速く、freeeは2026年8月7日に、税理士事務所向けの記帳、ルール整備、月次チェック、申告書チェックの4種のエージェントからなる「freee顧問先管理 | AIエージェント」と、その開発基盤「freee Agent Hub」を発表しています（確認：freee 公式ニュースリリース）。自分で作るか、こうした製品を使うかは、自分のデータでの拡張がどこまでできるかで決まると思います。

自分で作る場合の落とし穴をまとめます。

落とし穴 内容
匿名化の漏れ 顧問先名や個人名がそのまま索引に入る（守秘義務）
出典検証の省略 条文番号を確認せずに回答を信じる
改正への追随 一度作った索引を更新せず、古い条文で答え続ける
ライセンスの未確認 商用DBや書籍をそのまま投入する
レビューの省略 AIの回答をそのまま顧客に出す（最終責任は税理士）

12. まとめ

区分 内容
いま作れること（推定） 公開データによる根拠付きのRAG、回答の型のQLoRA、自社の過去処理の事例検索、根拠ログの設計、OCRと会計ソフトとの連携（数値はプログラム、書き込みは人の承認つき）
運用で積み上げていくこと（推定） 言語化されていない暗黙知の取り込み、判断の妥当性の検証、税制改正への追随、ベースモデルの更新
やってはいけないこと 第三者向けの税務相談サービスとしての提供、商用DBの無断投入、匿名化していない顧問先データの利用、LLMに金額計算や登録番号の判定をさせること、マイナンバーをLLMに渡すこと

2つ目の区分は、本記事の途中では「難しいこと」「限界」として挙げてきました。ただ、一度作って終わりの機能として見るから難しいのであって、年次の運用サイクルとして設計すれば手の届かない話ではないと考えています（推定）。課題ごとの対応を整理します。

課題 運用での対応（推定） それでも残ること
言語化されていない暗黙知 担当者が回答を承認・修正するたびに理由を根拠ログに残し（8章）、それをSFTデータと選好データとして蓄積する。運用そのものが暗黙知を少しずつ言語化する装置になる 調査官との折衝や対人対応は人が担う
判断の妥当性 「保証」ではなく「検証できる状態」を目指す。質疑応答事例と自社の承認済み事例から評価セットを作り、モデルや索引を更新するたびに回帰テストをかける。重要な論点はフロンティアモデルでクロスチェックする 最終判断と責任は人に残る
税制改正への追随 e-Gov法令APIの改正履歴から索引を毎年更新し、施行日と適用年度のメタデータで新旧を切り替える。QLoRAが担うのは「型」なので、改正のたびに作り直す必要は小さい 通達や事例の更新には前処理の手間が残る
ベースモデルの更新 税務QAでのクローズドとオープンの差は数ポイントまで縮まっており（9章）、この傾向が続けばローカルモデルを入れ替えるだけで底上げされる。索引、評価セット、根拠ログ、学習データはモデルに依存しない資産として持ち、アダプタは新しいベースで学習し直す 差が縮まり続けるという前提は外挿であり、毎年の回帰テストで確かめる

回帰テストの中身は、次のような自動チェックを想定しています（推定）。

チェック 内容
改正の切り替え 同じ質問を改正前後の索引に投げ、参照条文の適用年度が正しく切り替わるか
アダプタ更新の回帰 QLoRAやDPOを更新した後も、承認済み事例での根拠一致率が下がっていないか
根拠の整合 すべての回答に根拠IDが付き、そのIDが実在し、質問の年度で有効か
データの許諾 索引と学習データに、許諾のないデータ（商用DB、匿名化前の顧問先情報）が混じっていないか
情報の漏えい 匿名化前の情報を含むダミーデータを使い、出力に個人名や取引先名が漏れないか
学習データの鮮度 承認済み事例に適用年度を付け、税制改正で妥当でなくなった事例を学習データから除外しているか

承認済み事例といえども、改正前の解釈で処理したものが混ざれば、QLoRAやDPOがその古い判断を強化してしまいます。学習データにも適用年度を付け、改正後に妥当性を再確認したものだけを回す必要があります（推定）。

この運用を1年の流れにすると図11のようになります。税制改正の周期（12月の大綱、3月の法改正、4月施行）に索引の更新と回帰テストを合わせ、日々の運用で溜まった承認・修正ログを年に一度、学習データとモデルの更新に回します。実際の組織では、索引の更新、OCRの再学習、ログの精査を誰がいつ行うかまで決めておかないと、サイクルは回りません（推定）。

image.png

「AI税務担当」は、自社の処理方針と根拠を整理して記録し続け、その記録で自分自身を毎年更新していく担当者として設計するのが現実的だと考えています。

Appendix： 他の分野への応用

本記事の構成は税務に固有のものではありません。次の5つの条件がそろう分野なら、同じ骨格で検討できます。

  • 改正される一次資料がある（事実はRAGで参照する）
  • 判断の型は安定している（型はQLoRAで学ばせる）
  • 後から根拠を示す義務がある（根拠ログを残す）
  • 計算や照合など、決定論的にできる部分が多い（プログラムと分業する）
  • 自社利用と第三者提供の線引きを法律が決めている（独占業務の範囲を確認する）

この条件で分野を見ると、次のように整理できます。条文番号は e-Gov 法令検索で確認できますが、各分野の運用実務までは本記事では検証していません（推定）。

分野 「法令」に当たるもの 第三者提供の線 決定論に寄せる部分 本記事の構成との相性
労務・社会保険 労働基準法、毎年の保険料率、通達 社会保険労務士法27条 給与、残業代、保険料の計算 税務と同型で最も近い
安全保障貿易管理（該非判定） 外為法、貨物等省令の改正 該非判定は輸出者自身の責任 パラメータの照合、規制リストの該当判定 該非判定書がそのまま根拠ログになる
企業法務・契約 民法、下請法、判例 弁護士法72条 条項のチェックリスト、期日の計算 自社の契約のレビューなら可
許認可・補助金 公募要領、手引きの年度更新 行政書士法19条 要件の充足チェック、金額の計算 年度のサイクルが明確
医療事務・診療報酬 診療報酬改定（2年ごと）、通知 医師法17条など レセプトの点検、算定ルール 事務は可、診療の判断は不可
建築・設備の法規 建築基準法、告示 建築士法3条 構造、採光、避難の計算 計算の決定論性が高い
品質・安全規格 JIS、IEC、ISO の改訂 認証は第三者機関 試験条件、しきい値の判定 改訂への追随が課題そのもの
半導体の設計検証 IEEE 1800（SystemVerilog）の LRM、UVM、EDAツールのマニュアル 法規制はない lint、シミュレーション、カバレッジ 決定論的に検証できる部分が最も大きい

本記事の構成に最も近い技術分野は、半導体の設計検証です。LRM が版ごとに変わる、UVM の作法は型として安定している、記述が正しいかはシミュレータと lint が決定論的に判定する、という構造が税務と同じで、しかも税理士法のような制約がありません。「なぜこの記述にしたか」を LRM の条項番号で残す根拠ログは、レビューや引き継ぎにそのまま使えます（推定）。

逆に向かないのは、権威ある一次資料が版管理されていない分野、判断そのものを第三者に提供する分野（診断や投資助言など。医師法や金融商品取引法の線が厳しい）、決定論的に検算できる部分が少ない分野です。応用するときは、本記事と同じ手順で、第三者提供の線引きと公開データの利用条件を先に確かめる必要があります。

参考資料

情報源を種類別に分けて示します。

一次資料（法令、官公庁）

研究論文

公式ドキュメント、モデルカード

二次情報（報道、ブログ）と当事者の公式発表

  • Togetter「税理士がAIに仕事を奪われ解約されている話を耳にするが、記帳ミスや税務署からの指摘を修正出来ないと泣きつかれるパターンが増えそう」 https://togetter.com/li/2737746
  • freee株式会社 プレスリリース（2026年8月7日）「freee顧問先管理 | AIエージェント」「freee Agent Hub」 https://corp.freee.co.jp/news/20260807freee_AIagent&fAH.html
  • freee株式会社 プレスリリース「freee-mcp」（2026年3月2日） https://corp.freee.co.jp/news/20260302freee_mcp.html 、リモート版（2026年3月27日） https://corp.freee.co.jp/news/20260327freee_mcp.html
  • 株式会社マネーフォワード プレスリリース「『マネーフォワード クラウド会計』、リモートMCPサーバーを全プランで提供開始」（2026年3月26日） https://corp.moneyforward.com/news/release/service/20260326-mf-press-1/
  • 税理士による税理士法52条、重加算税、生成AI利用に関する解説記事（複数）
  • 日本語埋め込みモデルとリランカーの比較記事（複数、2026年）
  • 16GBクラスのGPUやApple Siliconでのローカルモデル運用に関する技術ブログ（複数、2026年）
  • e-Gov法令API Version 2 の解説記事（複数、2025〜2026年）
  • 日本語OCRの比較記事、会計ソフトのAI機能の第三者検証記事、text-to-SQL のベンチマーク解説（複数、2025〜2026年）
  • Beancount.io のブログ（LLM 支援のプレーンテキスト会計に関する記事、2025〜2026年）、hledger を青色申告に使った利用者のブログ（2025年）
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?