Codex で構築する自己改善型の税務エージェント
執筆: Technical Staff メンバー Aravind Srinivasan、Samay Shamdasani（Thrive Holdings）、Arthur Fernandes Araujo、John de Wasseige（OpenAI）
Thrive Holdings と OpenAI が、実務担当者の専門知識と Codex 駆動ループを融合し、Crete の会計士向けに Tax AI を共同開発した方法
現実世界のシステムは、ラボ内とは異なる振る舞いを実運用で示し、導入前には予測しにくい形で破綻します。チームはそうした失敗をローンチ後に発見し、エッジケースを調べ、プロンプトを調整し、実運用のフィードバックを持続的な製品改善へ変換するのに何週間も費やすことがよくあります。このフィードバックループは手作業で遅く、エンジニアが改善を進めない限り、改善されません。しかし今日では、よく設計された eval インフラ、実務担当者と現実世界の環境への直接アクセス、そして Codex の最先端のエージェント能力によって、自己改善するエージェントを構築できます。
本稿では、私たちが Codex を使ってこの種のエージェントをどう構築したかを解説します。過去 6 か月にわたり、OpenAI の forward deployed engineers と研究者、そして Thrive Holdings のエンジニアが協力し、Crete（新しいウィンドウで開く） の 30 以上の会計事務所ネットワークと連携し、その会計士向けに、ますます複雑になる税務申告書の作成を支援する Tax AI を構築してきました。Tax AI は、エンジニアが各失敗を見つけて修正することに頼るのではなく、Codex を使って、実運用での利用状況を自律的な改善につながる構造化されたシグナルに変えます。
Crete の実務担当者は毎シーズン何万件もの税務申告書を作成しており、そのために何百万もの基礎文書を処理する必要があります。中程度から高い複雑さの申告では、データ入力だけで申告書 1 件あたり 8 時間かかることもあり、雑然としたデータソース、前年文書、手作業による抽出と計算を伴うことが少なくありません。彼らは、税務シーズンの繁忙期に、税務申告準備が大きなボトルネックになっていると指摘しました。
この問題を解決するため、Tax AI は今シーズンのパイロットに参加した Crete 各事務所で 7,000 件の税務申告書を処理しました。このシステムは 1040 および 1041 の税務申告書作成における時間集約的な工程の多くを自動化しますが、効率向上以上に注目すべきなのは、システム自体が 3 か月前に最初に導入された版よりも測定可能な形で優れていることです。
Tax AI では、実務担当者がソースファイルを顧客固有のメモとともにアップロードします。その後 Tax AI は、レビュー可能な税務エンジン向けの提出データを作成します。これにより、税務準備にかかる時間を約 3 分の 1 節約し、最大 97% の精度で申告書を下書きし、スループットを約 50% 高め、顧客と過ごす時間の余地を増やします。
この改善は、後から修正を必要とせずに Tax AI がどれだけ正確に申告書を完成できるかを理解することで定量化できます。私たちは、75%、90%、または 100% の正しい項目完了に達した申告書の割合を確認することで精度を測定します。ローンチ時には、75% の正しい項目完了に達した申告書は 4 分の 1 にすぎませんでしたが、6 週間以内に 86% がその水準に達しました。90% および 100% の正しい項目完了レベルでは、システムはさらに速い成長を示しました。これらのしきい値により、申告書ごとに実務担当者の追加対応がどれだけ必要かを実用的に把握できます。
初期の Tax AI は、W-2 や 1099 のような比較的単純な作業を扱っていました。シーズンが進むにつれ、K-1、各種申告書類、より難しいエッジケースを含む、より複雑な申告へと進みました。新しい能力が追加されるたびに、手作業ではより難しく時間のかかるタスクを担うようになったため、申告書 1 件あたりの時間削減効果は前回より大きくなりました。現在も継続的な進歩が見られます。
次に、1) 専門的な実務担当者のフィードバック、2) 実運用トレース（入力から最終出力までの構造化履歴）、3) 継続的でより高速な製品開発を可能にする、調整済み eval に基づく Codex 駆動の反復ループという 3 つの重要な柱を軸に、私たちのチームが Tax AI をどのように共同設計して自己改善型にしたかを見ていきます。私たちの経験が、実務担当者の専門知識がシステムやデータの品質を左右するような領域で開発を行う他のビルダーの参考になれば幸いです。
Tax AI がより複雑な申告に対応を広げるにつれ、75%、90%、および完全完了に達した採点済み申告の割合は、税務シーズンを通じて上昇し続けました。
税務準備のより難しい部分（K-1、賃貸不動産関連の申告書類、複数のソースファイル間で値を突き合わせる必要がある税務フォーム）へ進むにつれ、本当の課題は、複雑な実運用上の失敗を製品が可視化し、理解可能にし、対処可能にできるかどうかだと明らかになりました。
製品の初期段階では、修正の大半が手作業でした。実務担当者はシステムエラーを修正できましたが、製品は完全なコンテキストを捉えていませんでした。提出前に変更された値は、真の抽出漏れ、マッピングの問題、製品サポート不足、または想定内のワークフローノイズを反映している可能性があったからです。そうしたケースの切り分けには、なおエンジニアリングチームによる追跡対応が必要でした。エンジニアはコーディングエージェントを使えましたが、システムはまだ改善ループの中で AI を意味ある形で使うようには設計されていませんでした。私たちには、どの問題に取り組むべきかを特定するためのシグナルがありませんでした。
そこで私たちは、3 つの柱を軸にシステムを設計しました。
- 実務担当者に近い位置を保つ: 実際に作業する人たちが、製品が何を学ぶかを導く必要があります。彼らの直感と理解は、どのエラーが重要かを明らかにし、ワークフローのどの部分に次に注力すべきかを判断する助けになります。
- 実運用がエビデンスを生むよう製品を作る: 製品は入力と出力だけでなく、ソース資料から抽出項目とその出典、後続の提出データ、専門家による修正に至るまでの全経路を捉える必要があります。
- Codex 駆動の改善ループを作る: 実運用上の問題が可視化され構造化されれば、それらは発見、調整済み eval、範囲を絞ったエンジニアリングタスクへ変えられます。その後 Codex は、調査、変更提案、対象特化および回帰 eval による検証を支援し、完全に手作業の反復サイクルよりも速く製品を前進させられます。
以下の賃貸物件の例では、そのループが実際にどう機能するかを示し、実務担当者の修正がどのように構造化された課題となり、次に eval ターゲットとなり、最後に Codex 向けに範囲設定されたエンジニアリングタスクになるのかを順に説明します。
賃貸物件収入は、個人税務申告書の Schedule E に報告されます。エンジニアリングの観点では、その抽出タスクは説明するのは簡単でも、うまく実行するのは難しいものです。システムは、雑然としたソース資料（手書きメモ、メール、スプレッドシート、その他の顧客ファイル）を読み取り、税務エンジンへ確信を持ってマッピングできる賃貸物件項目を抽出し、実務担当者が結果を承認または修正できるだけの十分なエビデンスを保持しなければなりません。以下の簡略化した例は、そうしたソースファイルと抽出出力がどのようなものかを示しています。
賃貸物件のソースパッケージは、税務エンジン側の項目に対応付けられる前に、出典情報付きの項目として整理されます。
エージェントが予測した値と、提出済み税務申告書の実際の値との差は、真の抽出漏れを反映している場合もありますが、実務担当者の好み、税務エンジン内で前年の申告書から繰り越された値、あるいは申告ワークフローの別の場所で追加または変更された値である可能性もあります。実務担当者は、どのアクションで修正が必要だったのか、またはどのアクションが提出を妨げたのかを特定できるよう、そうしたケースの見極めに協力してくれました。
こうした修正を詳細に確認できたため、失敗後に行う一度きりのレビュー工程から、継続的な学習サイクルへと変えることができました。私たちは、専門家のアクションを構造化データとして取得できるようにワークフローを設計しました。今では、Tax AI が何を提案し、実務担当者が何を修正し、最終的に提出済み申告書に何が入ったのかを正確に記録することで、あらゆる介入が製品の改善ループに取り込まれます。
賃貸物件のような複雑なワークフローでは、ソースファイルから提出済み申告書までの間で何が起きたかをシステムが保持する必要があります。その過程では、文書の整理、分割、分類を行い、賃貸物件の項目をソース資料への出典付きで抽出します。その値を税務エンジンに対応付けた後、提出前に実務担当者が修正する場合もあります。こうした製品レベルのトレースにより、どこで失敗が起きたのかを調査できるようになります。実務担当者の修正を有用な評価ターゲットに変えるために、システムはそれらを 3 つのステップで処理します。
- 差分を捉える: Tax AI の出力を提出済み申告書と比較し、期待値、予測値、その差分が対処可能に見えるかどうかを記録する項目レベルのレビュー行を生成します。
- 関連する失敗をグループ化する: 類似したレビュー行をまとめ、繰り返し発生する製品上の失敗を、想定内のワークフローノイズから切り分けます。たとえば、実務担当者による修正が繰り返されることで、Tax AI が fair rental days の項目を見落としがちであること、「other expenses」の扱いを誤ること、あるいは同じソースパッケージ内の複数の賃貸物件を取り違えることが示される場合があります。
- 繰り返し現れるパターンを eval ターゲットに変える: レビューと測定を経て繰り返し確認されたパターンは、Codex が改善すべき明確な eval ターゲットになります。
賃貸物件のレビュー行では、繰り返し発生する製品上の問題を想定内のノイズと切り分け、対応可能なケースを Codex が改善に使える eval ターゲットに変えます。
3 つ目の柱は、これらの新しい eval に対応できるエンジニアリングループを作ることです。ここで Codex が中心的な役割を果たします。
たとえば、eval パイプラインが、Tax AI は「fair rental days」項目を一貫して見落とす一方で、実務担当者はそれを確実に埋めていると示したとします。この発見はすでに、代表的なソースパッケージと期待出力を備えた対象特化の eval セットとしてまとめられているため、Codex は製品の構成内で根本原因を直接調査できます。
Codex は不十分な最終出力だけを相手にしているわけではありません。トレース、eval、リポジトリ、skills をまとめて調べます。
- パイプラインを調査する: ソースパッケージ、抽出スキーマ、mapper の挙動、コードパスを調べ、問題が未対応の項目なのか、抽出パターンの見落としなのか、ソース選択の問題なのか、mapper の欠落なのか、あるいは grader の問題なのかを判断します。
- 対象を絞った修正を実装する: 抽出スキーマを拡張し、賃貸物件文書のソース選択を改善し、税務エンジン mapper を更新し、想定内のワークフローノイズが失敗として数えられている場合は grader を洗練します。
- 検証して提案する: 対象特化の eval を再実行し、より広範な回帰テスト群を走らせ、エンジニアリングレビュー向けの候補プルリクエストを提示します。
- ループを閉じる: 繰り返し発生する実務担当者の修正を、測定可能なエンジニアリングタスクに変えます。エビデンスが曖昧であったり、安全に自動化できなかったりする場合、そのケースは無理にループへ通さず、製品チームへ戻されます。
エンドツーエンドの自己改善ループ。実運用トレースから繰り返される項目レベルの修正が浮かび上がり、それが失敗シグナルとなって、Codex はトレース、eval、リポジトリ、skills とあわせて調査できます。対応可能なパターンは、範囲を絞った eval や製品変更案に落とし込まれ、曖昧なケースはレビューのためにエンジニアへ戻されます。リリースされた改善は、次の改善サイクルに使える新たな実運用データを生み出します。
賃貸物件の例は、より広く再利用可能なパターンを象徴しています。つまり、実運用の成果物とトレースを使ってエージェントの能力を改善するということです。実運用データからレビュー済みの発見、ソーストレース、期待される税務エンジン出力、関連コード例、eval コマンドを入力セットとして与えることで、Codex は数週間から数か月にわたり、性能と精度を実質的に改善できます。これは、ハーネスエンジニアリング と Symphony に関する私たちの取り組みで述べた原則を土台にしています。これらでは、タスクを Codex にとって読み取りやすくし、範囲を絞ったコンテキストとツールを提供し、検証と人によるレビューを環境の一部として保つ方法を説明しています。
そのエビデンスが自動的に Codex のタスクになるわけではありません。実務担当者の修正は、抽出漏れ、マッピングの問題、未対応の製品挙動、税務判断、または想定内のワークフローノイズを反映している可能性があります。繰り返し現れる差分がレビューされ、対応可能な問題としてグループ化されて初めて、システムはそれらを成功条件が明確な範囲を絞ったタスクへ変えます。
私たちはこの自動化を、製品の境界が明確なレイヤーに適用しています。このレイヤーは抽出を行い、ソース文書を税務ワークフローへマッピングします。アーキテクチャ、製品判断、出荷については、引き続きエンジニアが責任を負います。実務担当者は、すでに行っている作業、つまり抽出値の修正、申告書のレビュー、最終申告の承認を通じて改善ループを導きます。
Codex にとって、その結果は曖昧なアラートではなく、エビデンス、編集可能な製品領域、明示的な検証ゲートを備えた、範囲の定まったエンジニアリングタスクです。代表的な賃貸物件タスクのコンテキストは、次のように要約できます。
同じループは賃貸物件以外にも適用できます。賃貸物件では、90% の適合率と再現率に到達するまでに約 6 週間と相当なエンジニアリング監督を要しましたが、その作業によって再利用可能な抽象化、レビュー成果物、eval の慣行、実装パターンが生まれ、Schedule C や Schedule A のような同程度に複雑な申告書類への対応が容易になりました。
Tax AI は、自己改善するエージェントを構築する道筋を示しています。実務担当者は、サービスを提供する過程で高価値のフィードバックシグナルを生み出します。製品ワークフローは、それらのシグナルを構造化されたエビデンスとして保持します。eval に裏づけられたエンジニアリングシステムは、改善が実運用に届く前にそれを検証し、エージェント駆動のループがシステムを継続的な自己改善の流れに保ちます。
Thrive Holdings の構造により、私たちはこの環境を特定の業界で再現できます。Holdings はオーナーであると同時にオペレーターでもあるため、私たちの統合エンジニアリングチームは、ベンダーとしてではなくパートナーとして、Crete のような事業の内部から実務担当者や実運用データと直接連携できます。つまり、技術、製品、サービスのすべてが一つ屋根の下にあり、より速く動き、優れた製品を構築する助けになっています。
昨年は税務準備に 180 時間を費やしたある上級会計士は、今年はわずか 15 時間しか使いませんでした。彼女はその時間の一部を、すべての顧客に電話をかけて申告内容を一緒に確認することに充てました。これは 1 年前には不可能だった、きめ細かなサービス水準です。残りの時間は、新規顧客の獲得と新しいサービス提供への拡大に使いました。
現在、私たちのチームは Tax AI の同じ 3 部構成の設計を青写真として、Thrive Holdings（新しいウィンドウで開く） 全体の他領域でワークフロー構築に活用しています。たとえば、記帳や監査のような会計ワークフロー、IT ヘルプデスク自動化のような業務ワークフローです。自己改善するエージェントの可能性は、領域や業界を超えて広がります。最良のエージェントは、人に導かれながら、時間とともにより高い能力、より大きな信頼、より高い価値を備えるよう学習していきます。
このプロジェクトに取り組んだ OpenAI チームについて詳しく知りたい方は、お問い合わせください。
