LLMは自らの税務ポジションを取り締まれない。私はAIが起草したポジションをモデルではなくエンコード済み制定法と照合する決定論的レイヤーを築いた。
Tax TechnologyArtificial IntelligenceCompliance

LLMに自分の税務エラーを捕まえさせようとした。できなかった。そしてそれが事業そのものだとわかった。

Ashutosh SinghalAshutosh Singhal2026年6月19日13 min

その主張は、文法的に完璧だった。それが問題だった。

コーヒーを置き、立ち止まった最初のポジションを、今でも覚えている。AIが新しいOBBBAの自動車ローン金利控除について一文を起草し、こう書いていた——「新しいOBBBAの自動車ローン金利控除は、依頼人のAGIを減額するライン上控除である」。文はきれいだった。自信に満ちていた。これまで読んできた、防御可能なポジションのどれとも同じ体裁だった。そして、現実の人間に現実の金銭的損害を与える、まさにその仕方で、間違っていた。

適格乗用車ローン金利控除(QPVLI)は、§63(b)(7)に基づくライン下控除である。調整総所得を減額しない。これをライン上に置くことは、読み返せば見つかる綴りの誤りではない。静かにAGIを動かし、確定申告の半分が依拠する数字がAGIだ。私を驚かせたのは、モデルが制定法をわずかに誤ったことではない。いかに立派に誤った答えに見えたか、ということだった。

ハルシネーションした引用は、見つけやすい。完璧な税務英語で書かれた、自信たっぷりの誤分類こそが、提出されてしまうものだ。

その瞬間、本当の問題が私の中で輪郭を帯びた。業界は3年をかけて税務業務の起草を自動化し、本当にうまくやった。Thomson Reutersは1040を自動作成する。CCH Axcessは何千もの事務所にわたって助言インサイトを起草する。Blue Jは調査の問いに平易な言葉で答える。準備は解決されつつある。だが、そののステップ——準備の次に来る、誰かが制定法の下でそのポジションが実際に防御可能かどうかを判断しなければならない段階——は、それを起草したのと同じ確率的モデルに委ねられた。そしてIRC §6662の下では、20%の正確性関連ペナルティが降りかかるのは、申告書に署名した人間であり、それを書いたアルゴリズムではない。

私は1週間、モデルに自分の宿題を採点させようとしてみた。

最初の直感は、誰もが思いつくものだった。正直に言えば、やめるべきだった時間より長く追いかけた。モデルがポジションを起草できるなら、十分に良いプロンプトでポジションをチェックさせられるはずだ。だから試した。制定法を渡した。QPVLIのルールを明示して渡した。自身の出力を監査し、控除を誤った行に置くものがあればフラグを立てるよう求めた。

いくつかは捕まえた。いくつかは見逃した。そして見逃しは、恐ろしい種類だった。監査で誤ったときも、起草したときと同じ流暢な自信で誤っていたからだ。自己チェックは、そもそも誤りを生んだのと同じ重みを通って走っていた。モデルに自らを取り締まらせることは、誤りを犯した当の存在に、同じ推論でその誤りに気づかせることでもある。

同僚にこれを説明しながら、自分の声でこう言うのを聞いたのを覚えている——「LLMにLLMを取り締まらせることはできない。」その一文が、私の設計をひっくり返した瞬間だった。私はモデルをより正確にしようとしていた。本当の答えは、そもそもモデルを審判として信頼するのをやめることだった。

確率的システムを、丁寧にお願いして決定論的にはできない。評決をその外へ移すのだ。

内面化するのに時間がかかりすぎた区別は、起草と検証が、同じ課題を易しくしたり難しくしたりしたものではない、ということだ。それらは別の問題だ。起草が報いるのは流暢さ、カバレッジ、もっともらしさであり、まさに言語モデルが得意とするものだ。検証が報いるのは、一つの特定のルールについて証明可能な正しさと、その場にいなかった審査官に対して作業過程を示すことができることだ。それは正反対の気質だ。私は、一つのシステムに両方をやらせるのをやめた。

「エージェントが助言し、コードが決める」とは、実際には何を意味するのか?

たどり着いたアーキテクチャについて正確でありたい。この言い回しは、線がどこに引かれているかを見るまではマーケっぽく聞こえるからだ。私が作ったデモ、StatuteGuardでは、言語モデルの仕事は正確に一つだけだ。雑然とした自然言語の税務文言を読み、構造化され型付けされたクレームを提案する。それが唯一のニューラルステップだ。そこに本当に強く、確信が持てないときは棄権し、推測の評決を出す代わりにポジションを人間へエスカレーションする。

それ以降はすべてコードだ。評決を下すのは決定論的ポリシーエンジン——一次法に対して私が書き起こしたルールを走らせる、同一の純粋Pythonツインを備えた本物のOPA/Regoだ。ニューラル抽出、シンボリック検証。モデルが助言する。コードが決める。そしてその違いは学術的なものではない。なぜなら、うまく書かれた段落でコードの答えを翻意させることはできないからだ。

予想以上に気にかけるようになったのが、可読性だ。ポリシーは、信頼してくれと頼むブラックボックスではない。自分で開いて制定法と突き合わせられる、決定表とRegoソースだ。

§280Aおよび§30Dの読みやすい決定表を、本物のOPA/Regoソースと並んで示すPolicy Rulesパネル
読みやすい表としてエンコードされた§30Dクリーン車両ルール(MSRP上限:乗用車55,000ドル、SUV/トラック/バン80,000ドル;修正AGI上限:単身150,000ドル、HoH 225,000ドル、MFJ 300,000ドル)と、その下の本物のOPA/Regoソース。ポリシーを読み、制定法と一致することを確認できる。

そのスクリーンショットは、一つのパネルにテーゼ全体を収めている。Head of Taxはコンプライアンスパートナーと座り、ルールを開き、一つの評決も信頼する前に§30Dと突き合わせられるべきだ。ロジックがモデル推論の一段落なら、それはできない。読めるルールなら、できる。

では、コードがノーと言ったとき、何が起きるのか?

完成したゲートに、そのOBBBA自動車ローンのポジションを初めて通したとき、思わず笑った。モデルは以前とまったく同じ「ライン上、AGIを減額する」クレームを起草していた。だが今度は、決定論的エンジンが抽出されたクレームを見て、エンコードされた§63(b)(7)ルールと照合し、硬い評決を返した——BLOCK。提出するな。

OBBBA自動車ローンのポジションに対し、提出禁止バナーと赤くフラグされた五方向の下流カスケード付きでBLOCK評決を返すStatuteGuard
OBBBAのQPVLIポジションはBLOCKを返す(「ブロック。起草された記述はエンコードされた制定法と矛盾する。このまま提出するな。」)。五方向の下流カスケード(AGI、AGI連動の州税、Medicare IRMAA、7.5%の医療費控除フロア、学生ローンIDR)がすべてフラグされている。

このビューで説得力があると感じ、税務読者にもそう感じてほしいのは、カスケードだ。エンジンは単に「行が違う」と言わない。見えるようにするのは誤ったAGI減額が汚染する五つの下流箇所だ——調整総所得そのもの、AGI連動の州所得税、Medicare IRMAA保険料サーチャージ、7.5%の医療費控除フロア、学生ローンの所得連動返済。誤分類された一つの控除は、一つの誤りではない。小さな爆風半径であり、パネルがその半径を可視化する。

次に理由をアニメーションで見せる——私が最も愛着を持つ部分だ。IRCの相互参照グラフを、ノードごとに引用チェーンで歩き、「ノー」がむき出しの断言にならないようにする。

§163(h)(1)から§63(b)(7)までIRCグラフを横断し、ライン下配置ルールを示す、アニメーション化された制定法引用チェーン
ライブの引用チェーン:§163(h)(1) → §163(h)(4)(A) → §163(h)(4)(B) → §63(b)(7) → §62/§63。§63(b)(7)ノードを選ぶと配置ルールが表示される——QPVLIはAGIから課税所得を計算する際に認められるライン下控除であり、連邦官報の自動車ローン金利ルール(2026年1月)によって確認される。

何度も立ち返る細部がここにある。これが玩具の問題ではないことを証明するからだ。デモ自身のREADMEによれば、「ライン上」という誤ラベルは、悪役を作るために私が発明したものではない。主流の税務準備ガイダンス——H&R Blockのサイトを含む——が公表してきた、文書化されたコンセンサスの誤りだ。もっともらしく、うまく書かれ、広く繰り返される誤答こそ、決定論的ゲートが存在するための失敗モードだ。群衆が自信を持っていても、控除がAGIへ移るわけではない。それを決めるのは制定法であり、いまやコードもそうする。

最も危険な税務エラーは、間違って見えるものではない。正しく見え、正しく聞こえ、三つのベンダーのガイダンスに現れるものだ。

腰を据えて確かめたいなら、稼働中のデモはveriprajna.com/ja/demos/tax-compliance-aiにある。自分のポジションを貼り付けて、ゲートが決める様子を見てほしい。

ほぼ間違えた機能:「分からない」と言うタイミングを知ること

ほぼ組み込んでしまいそうになった誤りを認めなければならない。検証ツールを作るエンジニアなら誰もが犯したくなるものだからだ。初期の直感は、機械にすべて答えさせることだった。カバレッジが目標のように感じられた。すべてのポジションに評決を返すツールは、ときに肩をすくめるツールより完成して見える。

その直感は誤りで、特定のポジションが理由を教えてくれた。§280Aのホームオフィス控除を考えてほしい。予備の寝室が事業の主たる場所として「定期的かつ排他的に」使われているかどうかは、事実と状況のテストだ。きれいにエンコードできるルールはない。答えが、現実の人間が現実の部屋をどう使うかに依存するからだ。決定論的エンジンに裁定を強制すれば、まさにこの仕組みが防ぐために作られたことをやることになる——正直な答えが「人間が見る必要がある」である場所に、自信たっぷりの評決を製造することだ。

定期的かつ排他的使用が事実と状況のテストであるため、§280AホームオフィスのポジションをNEEDS HUMAN REVIEWへルーティングするStatuteGuard
§280Aホームオフィスのポジション(コンサルティング業務に使う予備の寝室で、排他性が未確立)はNEEDS HUMAN REVIEWへルーティングされる。グレーゾーンは解決されずエスカレーションされる。定期的かつ排他的使用は、決定論的カバレッジの外にある事実と状況のテストだからだ。

だからゲートには二つではなく四つの評決がある。ポジションが防御可能なときPASS。エンコードされた制定法と矛盾するときBLOCK。本物のグレーゾーンのときNEEDS-REVIEW。この版では単に条項がエンコードされていないときOUT-OF-COVERAGE。最後の二つは、同じ正直な意味を持つ——これを決めるのは人であり、機械ではない。「分からない」を決して言わない検証レイヤーは、余分な手順でブラフする第二のモデルにすぎない。エスカレーション経路を築くことは、限界を認めるように感じられた。実際には、製品で最も重要な機能だ。

数字、そしてそれらが主張しないこと

ベンチマークには慎重だ。マーケターが望むより慎重だ。これらの数字の述べられ方が、通常は嘘だからだ。ラベル付きゴールデンセット42件の事前分類ポジション(クリーン14、エラー16、エスカレート12)に対して決定論的エンジンを走らせ、そのレイヤーが何をするかを測定した。

42件のポジションで、決定論的カバレッジ71.4%、ゲート精度100%、エラー捕捉100%、正しいエスカレーション100%を示すゴールデンセット・ベンチマークのスコアボード
ゴールデンセット・ベンチマーク:決定論的カバレッジ71.4%、ゲート精度100%(誤ブロック0)、エラー捕捉の完全性100%、グレーゾーンの正しいエスカレーション100%。ラベル付き42件で検証し、ローカルで評価。

その42件のゴールデンセットでは:決定論的カバレッジ71.4%——エンジンがその割合を自らPASSまたはBLOCKへ解決し、残りを正しくエスカレーションしたことを意味する。ゲート精度100%——正しいポジションが誤ってブロックされた件数はゼロ。エンコード済み条項におけるエラー捕捉の完全性100%。グレーゾーンの正しいエスカレーション100%。スループットは1秒あたり数万ポジション(スクリーンショットした実行では約58,000件。ただしマシン依存)で走った。検証はインフラであり、モデル呼び出しではないからだ。

ここが私がこだわる点だ。これらの数字はそのゴールデンセット上では真実であり、オープンワールドの保証ではない。StatuteGuardが「100%正確」だとは言わない。ラベル付きセットを離れた瞬間、その文は不誠実になるからだ。私が言うのは、より繊細で、より耐久性があると思うことだ——評決が決定論的コードである以上、そのエンコード済みの条項における挙動は再現可能かつ証明可能であり、ドリフトする確率ではない。42件すべての評決をOPA 1.17.1と純粋Pythonツインに対してクロスチェックし、完全に一致した。それが、私が立てられる主張だ。レイヤーを記述するものであり、モデルを記述するものではない。

「100%の正確性」はマーケティングの数字だ。「エンコード済み条項では再現可能で、それ以外では正直にエスカレーションする」はエンジニアリングの数字だ。私は後者を出荷したい。

そして、だからこそこれは古びない。来年より良いベースモデルが出ても、どの制定法条項がどのポジションを裏付けたかを審査官に証明することはできない。カバレッジ、ゲート精度、提出可能な監査証跡は、検証レイヤーの性質だ。モデルが良くなるにつれて縮むモデルのエラー率ではない。

審査官に求められて初めて、自分が作っていたと気づいた成果物

コンプライアンス文書を作ろうとして始めたわけではない。だが税務関係者と話せば話すほど、会話は同じ場所に行き着いた——「いいだろう、エラーは捕まえた。だがIRSに何を渡すのか?」。だから今、すべての評決が提出可能な§6662デューデリジェンス記録を書き出す——提出前にポジションが制定法と照合して検証されたことを文書化する、印刷可能なワークペーパーだ。ソース・ワークペーパー、条項、一次ソース、抽出されたクレーム、判定のナラティブ、完全な引用チェーン。合理的原因・相当注意のポジションが実際にとられた証拠であり、2024年1月発効のAICPA SSTS改訂の下で直接に重要になる。

どこで動かすかを気にかけるもう一つの理由があり、Heppner判決(SDNY、2026年2月)のあと具体化した。同判決は、依頼人の調査を公開AIツールに投入することについての特権放棄の問いを提起した。StatuteGuardはデフォルトでAPIキーなしに、完全にローカルで動く。ポジションも依頼人データも、境界の外へ出ない。Heppnerのあと、閉じたローカルで監査可能なアーキテクチャは、セキュリティレビューでの「あれば嬉しい」ではない。法的に重要だ。ローカルファーストの姿勢を、その判決のために設計したわけではない。だが、いま前面に出す理由は、その判決だ。

利害の文脈として、米国の事業税務コンプライアンスコストは年間1,260億ドルを超える(WP1ソリューション調査、2026年)。IRC §6662のペナルティは過少納付の20%であり、§6663の詐欺ペナルティは75%に達する。起草が自動化され、ペナルティが個人に降りかかるとき、Head of Taxの夜を眠れなくすべきなのは、検証のステップだ。

いま、実際に信じていること

より良い税務AIを作っていると思って始めた。最後にはっきり言いたい——問題が何であるかについて、私は間違っていた。あなたの税務AIに正確性の問題はない。あるのは検証の問題であり、より良いモデルでは解決しない。なぜなら20%のペナルティはあなたの署名に降りかかり、モデルの重みには降りかからないからだ。税務業務の起草をパーソナライズし自動化することは、本物の進歩だ。それはポジションが防御可能だと証明することと同じではなく、業界は静かにそれらを同じものとして扱ってきた。

デモはveriprajna.com/ja/demos/tax-compliance-aiにある——ゲートを壊してみたいなら。本気でそうしてほしい。

私の説明を読むよりゲートが決める様子を見たいなら、エンドツーエンドで動く全体がここにある。

税務リーダーに問い続けているのは、これだ。まだ居心地の良い答えはない。AIがポジションを起草し、あなたが申告書に署名するとき、あなたが検証したのであって信頼したのではないことを証明する成果物は何か? 正直な答えが「何もない、モデルを信頼した」なら、モデルは助手ではない。共同署名者であり、監査に召喚することはできない。

関連リサーチ

他のプラットフォームでも公開

確かな信頼のもとに、AIを構築する。

次世代のエンタープライズAI構築において豊富な経験を持つチームと、ぜひご一緒ください。信頼できるAI戦略の設計・構築・導入を、私たちがお手伝いします。

Veriprajna ディープテック・コンサルティング は、ヘルスケア・金融・規制対応分野における安全性重視のAIシステム構築を専門としています。当社のアーキテクチャは確立されたプロトコルに照らして検証され、包括的なコンプライアンス文書を備えています。