One Big Beautiful Bill が900ページ超の、構造化されていない文書として届いたとき――標準化されたスキーマはなく、公開されているIRSのフォームもなく、発送の締め切りも厳しい――IntuitのTurboTaxチームには疑問がありました。AIによって、数か月に及ぶ実装を、精度を犠牲にせずに数日へ圧縮できるのだろうか、ということです。
それを実現するために彼らが作ったのは、税務の物語というよりはテンプレートです。商用AIツールの組み合わせ、独自のドメイン特化言語、そしてカスタムのユニットテスト基盤で構成されており、ドメインに制約のある開発チームなら誰でも学べるようになっています。
Intuitの税務担当ディレクターであるジョイ・ショウ（Joy Shaw）は、同社で30年以上の時間を過ごしており、Tax Cuts and Jobs Act と OBBB（OBBB）をどちらも経験してきました。「法律そのものに多くのノイズがありましたが、税務上の含意を取り出して、個別の税制条項に絞り込み、さらに私たちの顧客にまで絞り込むことができました」とショウはVentureBeatに語っています。「その種の集約はツールを使うことで本当に速くできて、フォームや手引きが届く前からコーディングを始められました。」
OBBBが引き上げたハードル
2017年にTax Cuts and Jobs Actが成立したとき、TurboTaxチームはAIの支援なしで法令に取り組みました。作業には数か月かかり、精度要件がショートカットを許しませんでした。
「以前は、法を読み進めて、別の法令コードを参照している箇所をコード化し、それを自分たちで解き明かそうとする必要がありました」とショウは語りました。
OBBBは同じ精度要件を持っていましたが、様相が異なっていました。900ページ超という分量のため、構造的にはTCJAよりも複雑でした。標準化されたスキーマのない、非構造化文書として届きました。さらに、下院版と上院版では同じ条項を説明するのに異なる文言が使われていました。そしてチームは、IRSが公式フォームや手引きを公表する前に、実装を開始しなければなりませんでした。
問題は、AIツールでタイムラインを圧縮できるのか、それとも出力を損なってしまうのか、という点でした。必要だったのは、まだ存在していなかった特定の順序とツールでした。
非構造化文書からドメイン特化コードへ
TurboTaxチームがOBBBに取りかかったのは、OBBBがまだ議会を通過している最中でした。大規模言語モデルを使い、チームはまず下院版を要約し、次に上院版を要約し、その後に相違点を突き合わせました。両院は同じ基礎となる税務コードの条項を参照していました。これは一貫したアンカーポイントとなり、構造が一致しない文書間でもモデルが比較できるようにしました。
署名の日までに、チームはすでにTurboTaxの顧客に影響する条項だけを抽出し、特定の税務状況と顧客プロファイルにまで絞り込んでいました。解析、突合、条項のフィルタリングは、数週間から数時間へと移行しました。
これらの作業はChatGPTや汎用のLLMが担いました。しかし作業が分析から実装へ切り替わった瞬間に、そうしたツールは硬い限界にぶつかりました。TurboTaxは標準的なプログラミング言語で動いていません。税計算エンジンはIntuit内部で維持されている独自のドメイン特化言語で構築されています。そのコードベース向けにコードを生成するモデルは、学習していない構文へ法的テキストを翻訳し、新しい条項が、これまでの何十年もの既存コードとどのように相互作用するかを把握しつつ、すでに動いているものを壊さないようにする必要があります。
Claudeは、その翻訳と依存関係の対応付け作業の主要なツールになりました。ショウによれば、それが「何が変わり、何が変わらないのか」を特定できるため、開発者は新しい条項に関係する部分だけに集中できるようになったと言います。
「変わらないものと統合できて、変わったものに対する依存関係を特定できます」と彼女は言いました。「それによって開発プロセスが加速し、変わった部分にだけ集中できるようになりました。」
ほぼゼロ誤差閾値に合わせたツールを構築する
汎用のLLMによって、チームは動くコードのところまで到達できました。そのコードを出荷可能な状態にするには、OBBBサイクルの中で構築された2つの独自ツールが必要でした。
1つ目は、法令の変更点からTurboTaxの製品画面を自動生成するツールです。これまでは、開発者が各条項ごとに画面を個別に手作業で整備していました。新しいツールは大部分を自動で処理し、必要な場合に限って手動でのカスタマイズを行うだけで済みました。
2つ目は、目的に合わせて作られたユニットテスト基盤です。Intuitは以前から自動テストを実行していましたが、従来の仕組みでは結果が合格／不合格のどちらかしか出ませんでした。テストが失敗すると、開発者は原因を追跡するために、基となる税務申告データファイルを手動で開かなければなりませんでした。
「自動化が合格／不合格を知らせてくれるので、何が間違っていた可能性があるのかを見るには、実際の税務データファイルを掘り下げる必要がありました」とショウは述べました。新しい枠組みでは、責任を持つ特定のコード区間を特定し、説明文を生成し、そしてその修正を枠組みの中で直接行えるようにします。
ショウは、消費者向けの税務プロダクトの精度は100％に近い必要があると言いました。IntuitのConsumer Groupにおける技術担当VPであるサラ・エアニ（Sarah Aerni）は、アーキテクチャは決定論的な結果を生み出さなければならないと言いました。
「決定論性に関するタイプの能力や、テストによって検証可能で正しいこと――そういったものが、その種の確信につながるんです」とエアニは言いました。
ツールはスピードを担います。しかしIntuitは、AIが生成した出力を検証するためにLLMベースの評価ツールも使っており、それでも、人間の税務専門家が結果が正しいかどうかを判断する必要があります。「人間の専門性があってこそ、ほぼ何でも検証し、確認できるようになる、ということに尽きます」とエアニは語りました。
規制産業のチームなら誰でも使える4つの要素
OBBBは税務の問題でしたが、前提条件は税務に限ったものではありません。ヘルスケア、金融サービス、リーガルテック、政府調達のチームは日常的に、同じ組み合わせに直面しています。すなわち、複雑な規制文書、厳しい期限、独自のコードベース、そしてほぼゼロの誤差許容です。
Intuitの実装を踏まえると、ワークフローの4つの要素は他のドメインに制約のある開発環境へ移植可能です：
文書分析には商用LLMを使う。 汎用モデルは、解析、突合、条項のフィルタリングを得意とします。ここでこそ、速度を追加しつつ、精度のリスクを生むことなく済みます。
分析が実装へ移るタイミングで、ドメイン対応のツールへ切り替える。 理解せずに独自の環境へコード生成を行う汎用モデルは、大規模に適用したときに信頼できない出力を生むことになります。
スプリント中ではなく、締め切りより前に評価基盤を構築する。 一般的な自動テストは合格／不合格の出力しか生成しません。失敗を特定し、その場での修正を可能にするドメイン固有のテストツールが、AI生成コードを出荷可能にするのです。
エンジニアリングだけでなく、組織全体にAIツールを展開する。 ショウによれば、Intuitはあらゆる機能領域で利用状況を学習・監視しました。AIの流暢さは、初期導入者に集中させるのではなく、組織全体へ分散されました。
「私たちはここで、AIと人間のインテリジェンスの可能性に引き続き踏み込み続けています。そうすることで、私たちが構築する体験の中から、顧客が必要としているものを確実に得られるようにするためです」とエアニは語りました。
