はじめに ── 確定申告という認知負荷
確定申告は面倒です。毎年2月から3月にかけて、書類を集め、金額を入力し、税額を計算します。給与所得者であれば年末調整で済むことが多いのですが、副業があったり、退職していたり、住宅ローン控除を受けたりする場合には、自分で申告する必要があります。
書類の種類は多く、入力項目も複雑です。所得の種類ごとに様式が異なり、控除の適用条件を理解するだけでも時間がかかります。個人事業主やフリーランスであれば、消費税の計算が加わることもあり、認知負荷はさらに高まります。
ここまで読んでくださったサラリーマンの方。なんだ、自分には関係ないな、と。
そんなことはありません。還付申告と呼ばれるものがあります。
還付申告は、確定申告期間とは関係なく、その年の翌年1月1日から5年間、いつでも提出できます。1月に入った時点で、納め過ぎた所得税の還付を請求できます。寄付金控除(ふるさと納税)や医療費控除はわざわざ2月の繁忙確定申告シーズンを待たなくてよいのです。
それでも、1月から還付申告をする人は少数派でしょう。
理由は単純です。手続きそのものが面倒だからです。
本記事では、確定申告と還付請求にまつわる設計上の問題を整理し、AIエージェントでどこまで認知負荷を下げられるかに、非エンジニアである1人の経理マンの挑戦を記載します。
第1章 ── 還付申告は1月1日からできる
https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/2030.htm
[国税庁 No.2030 還付申告]
確定申告書を提出する義務のない人でも、給与等から源泉徴収された所得税額が年間の所得に対する所得税額より多いときは、確定申告によって還付を受けられます。この申告を還付申告といいます。
還付申告書は、確定申告期間（原則として翌年2月16日〜3月15日）とは関係なく、その年の翌年1月1日から5年間提出できます。つまり、法定の申告期間が始まる前から、手続きを始められるということです。
1月1日時点で必要な書類が揃っていれば、翌年3月を待つ必要はありません。住宅ローン控除、医療費控除、雑損控除、寄附金控除など、還付の対象となる事由は多いです。年の途中で退職して年末調整を受けられなかった人も、1月から還付を請求できます。住宅ローン控除の場合、金融機関から借入金残高証明書が届くのは年末頃ですから、1月中には書類が揃うケースがほとんどです。
それでも多くの人が2月以降に申告します。1月は正月休み明けの業務に追われ、申告の準備に手が回らないのです。あるいは、還付申告が1月からできること自体を知らない人も少なくありません。
制度は用意されています。にもかかわらず、利用されにくい。それは、情報の届け方や手続きの設計に起因する問題だと言えるでしょう。
第2章 ── 面倒の二重構造：申告も還付請求も
確定申告が面倒なのは、書類の種類と入力項目が多いからです。所得の種類ごとに様式が異なり、控除の適用条件も複雑です。給与所得、事業所得、雑所得など、複数の所得がある場合は様式の選択から始めなければなりません。消費税の課税事業者であれば、さらに計算と書類が増えます。
では還付申告は楽かというと、そうではありません。還付請求も同じく面倒です。
還付申告には、本税の確定申告と同様に、確定申告書や付表・明細書が必要になります。住宅ローン控除であれば借入金残高証明書、医療費控除であれば医療費の明細、雑損控除であれば災害等の証明です。書類を集める手間は変わりません。違いは、納付ではなく還付が返ってくる点だけです。
面倒さの構造は同じです。申告義務がある人も、還付だけを受ける人も、同じ認知負荷を背負います。どちらか一方が楽になるわけではありません。むしろ、還付申告の場合は期限のプレッシャーがなく、丸5年間可能です。
やろうと思えばいつでもできてしまいます。その分、先送りにされやすく、その結果として「いつかやろう」のまま年を越してしまうこともあります。
この二重構造が、申告を先送りさせます。義務がある人は期限に追われ、還付だけの人には期限のプレッシャーがない分、ずるずると後回しになります。結局、どちらもストレス源として残るのです。
第3章 ── 結局いくら得したのか、が見えない
還付申告をしたあと、多くの人が抱く疑問があります。結局いくら得したのか、ということです。
還付金が口座に振り込まれれば、その金額は分かります。しかし、住宅ローン控除や医療費控除を適用した結果、本来納めるべき税額がどれだけ減り、その結果として還付がいくらになったのか。控除を適用しなかった場合と比較して、どれだけのメリットがあったのか。これが分かりにくいのです。
税額計算は、所得、控除、税率、復興特別所得税などが組み合わさります。一覧性が低く、途中経過を追いにくい構造です。国税庁の確定申告書等作成コーナーは有用ですが、最終的な税額と還付額は出ても、内訳をどう解釈すればいいかはユーザーに委ねられています。住宅ローン控除がいくら効いたのか、基礎控除の段階によって税額がどう変わったのか、といった問いに答えるには、自分で計算過程をたどる必要があります。
自分はこの面倒な作業をやって、結局いくら得したのか？
この問いに答えるには、計算過程の透明性が必要です。ところが、その透明性を担保するUIや説明は、まだ十分とは言い難い状況にあります。技術的には、所得・控除・税率・各段階の税額を中間出力として示し、適用条文を併記すれば、ユーザーは自分で計算を追えます。
この種の設計が、透明性のギャップを埋める手段になります。
ということでやってみました。申告エージェントです。
第4章 ── 経理×AIの空白地帯
会計ソフトは普及しています。freee、マネーフォワード、弥生会計など、個人事業主向けのツールは数多くあります。これらは入力の効率化や仕訳の自動化には強く、領収書のスキャンから仕訳候補を提示する機能も一般的になってきました。
しかし、財務会計に携わる人間としては、確定申告や還付申告の判断そのものをAIに任せている人は、本当に少ないという認識です。
経理をAIでやっている。この表現は、入力補助や仕訳提案の営業のレベルで使われることが本当に多いです。申告必要性の判定、控除の適用可否、税額計算の検証まで含めてAIに委ねる事例は、まだ希少です。
「AIで便利になりますよ！」と営業電話を受けたことも数えきれないほどありますが、教師データを誰が学習させるか、成功例と語る教師データはどの程度頑健か、使っているモデルとその長所、どういうメカニズムで過去処理を類推しているかをきちんと説明してくれた営業の方は皆無でした。
営業の方にとっては確定申告とタメ口で話せるレベルの面倒な現場担当者だろうと自認しております。
理由はいくつか考えられます。税務は法律に直結しており、万が一間違えた場合のリスクが大きいからです。税務調査で、「AIが数年前にこうやって判断したんで...」と言おうものなら、それはそれは大変なことになるためです。
したがって、ブラックボックスのAIに丸投げすることを躊躇するのは自然でしょう。また、既存の会計ソフトがスプレッドシートやクラウド連携に最適化されており、LLMベースのエージェントと組み合わせる土壌が整っていません。
それでも、申告必要性の判定、必要書類のリストアップ、税額計算のロジックをオープンにしたエージェントは、認知負荷を下げる補助として機能しうると思います。そのためには、ブラックボックスにならない設計が必要です。
**アーキテクチャ: 7コマンドパイプライン**
全体の流れは、事前確認フェーズと計算・申告フェーズに分かれます。
```
事前確認フェーズ 計算・申告フェーズ
─────────────────────────────────────────────────────────────
/assess → /gather → /consumption-tax → /journal → /settlement → /income-tax → /submit
申告必要性 書類収集 消費税計算 領収書仕訳 試算表生成 所得税計算 書類確認
```
各コマンドは独立しており、必要なところだけを実行できます。税額計算（/income-tax・/consumption-tax）は LLM 不要で動作するため、API キーなしでも試せます。
1. 税額計算: 整数演算と Tax Rule Engine
税額計算は LLM に依存せず、整数演算で1円精度の確定値を出します。税率・控除額・丸め単位は YAML で管理し、年度ごとの法改正に追随できるようにしています。
```yaml
# tax_rules/2025.yaml より抜粋
income_tax:
brackets:
- max_income: 1950000
rate: 0.05
deduction: 0
- max_income: 3300000
rate: 0.10
deduction: 97500
# ... 累進7段階
taxable_income_rounding_unit: 1000 # 課税所得: 千円未満切捨
tax_amount_rounding_unit: 100 # 所得税額: 百円未満切捨
reconstruction_surtax_num: 21 # 復興税: 21/1000（整数演算）
reconstruction_surtax_denom: 1000
deductions:
basic: 480000
basic_phase_out: # 基礎控除の4段階逓減（所得税法第86条）
- income_max: 24000000
amount: 480000
- income_max: 24500000
amount: 320000
```
条文番号を YAML のコメントに残し、出典を追跡可能にしています。
2. 住宅ローン控除: 条文準拠の計算ロジック
住宅ローン控除（租税特別措置法第41条）は、令和4年以降の0.7%と令和3年以前の1.0%を整数演算で区別しています。
```python
# housing_loan.py より抜粋（租税特別措置法第41条準拠）
_RATE_MODERN_NUM: int = 7 # 令和4年以降 0.7% = 7/1000
_RATE_MODERN_DENOM: int = 1000
_RATE_OLD_NUM: int = 10 # 令和3年以前 1.0% = 10/1000
_LIMIT_NEW: dict[str, int] = {
"certified": 50_000_000, # 認定長期優良・低炭素住宅
"energy_saving": 45_000_000, # ZEH水準省エネ住宅
"general": 30_000_000, # 一般住宅
}
```
3. OCR デュアル検証
領収書の OCR では、2つの独立サブエージェントが並行で読み取り、一致した場合のみ採用します。
```
SubAgent-A ──┐
├── 比較・クロスチェック → 一致 → 採用
SubAgent-B ──┘ → 不一致 → ユーザー確認
```
金額・日付・宛先がすべて一致しない場合は Stop-first で処理を止め、手動入力を求めます。OCR の幻覚リスクを低減する工夫です。
4. 検算モジュール（CC-01〜CC-06）
計算結果を、LLM を使わず数学的不変条件のみで検証します。
```python
# cross_checker.py より抜粋
# CC-01: 課税所得の検算
expected_taxable = max(0, result.total_income - result.total_deductions)
expected_taxable = (expected_taxable // 1000) * 1000
if expected_taxable != result.taxable_income:
errors.append("CC-01: 課税所得不一致 ...")
# CC-03: 復興特別所得税の正確な検算
expected_reconstruction = result.income_tax * 21 // 1000
if expected_reconstruction != result.reconstruction_tax:
errors.append("CC-03: 復興税不一致 ...")
```
テストは法律条文を参照して設計し、境界値（195万円・330万円の税率変わり目など）を網羅しています。判断の根拠は条文番号や国税庁のタックスアンサーと紐づけて出力します。検証可能なツールとして設計することで、年度とともに変化する数値情報にも冗長性を持って対応できるようになります。
こうした取り組みが、経理×AIの空白地帯を埋める一歩になると信じています。
おわりに ── エージェントが埋める隙間
確定申告も還付請求も、ともに大変面倒です。その割に、結局いくら得したのかは分かりにくく、AIでやっている人はまだ少ないという認識です。
これらは、意志力やモチベーションの問題ではありません。設計の問題です。手続きの構造、情報の可視性、ツールの接続性。これらの不足が、認知負荷を高め、申告を後回しにさせています。
shinkoku-agent は、その隙間を埋める試みの一つです。
国税庁の確定申告書等作成コーナーは、正式な申告において依然として中核をなすことは間違いありません。エージェントは、その前段階の認知負荷を下げる補助として位置づけられます。申告が必要かどうか、何を集めればいいか、おおよそいくらになるか。そうした問いに、すぐ答えられる環境を作ることが目標です。
確定申告の面倒さは、なくならないかもしれません。それでも、設計を少しずつ変えることで、負担を減らす余地はあると思います。
そして、生み出した時間で、もっともっと充実した人生を過ごしたいものです。
参考
- [国税庁 No.2030 還付申告](https://www.nta.go.jp/taxes/shiraberu/taxanswer/shotoku/2030.htm)