Building self-improving tax agents with Codex

2026年5月27日 · Engineering

執筆: Members of Technical Staff: Aravind Srinivasan & Samay Shamdasani (Thrive Holdings)、Arthur Fernandes Araujo & John de Wasseige (OpenAI)

Loading… Share

Thrive Holdings と OpenAI が実務者の専門知識を Codex 駆動のループと融合させ、Crete の会計事務所向けに共同開発した Tax AI の紹介です。

現実世界のシステムは、実験室での挙動とは異なり、デプロイ後に予期しにくい形で破綻することが多くあります。チームはしばしばローンチ後に失敗を発見し、数週間にわたってエッジケースを調査し、プロンプトを調整し、本番のフィードバックを耐久的な製品改善に翻訳します。このフィードバックループは手動かつ遅く、エンジニアの介入がなければ改善しません。しかし今日では、慎重に設計された評価インフラ、実務者と実世界環境への直接アクセス、そして Codex の最先端のエージェンシー能力を組み合わせることで、自己改善するエージェントを構築できます。本稿では、私たちがどのように Codex を使ってこの種のエージェントを構築したかを解説します。

過去6か月間、OpenAI の前方展開したエンジニアと研究者が Thrive Holdings のエンジニアと協力し、Crete（opens in a new window）のネットワークに属する30以上の会計事務所向けに Tax AI を共同で構築しました。本番利用における各失敗をエンジニアが見つけて直すのではなく、Tax AI は Codex を用いて本番利用を構造化されたシグナルに変換し、それが自律的な改善を駆動します。

Crete の実務者は毎シーズン何万件もの税務申告を処理し、それには数百万に及ぶソース文書の処理が伴います。中〜大規模の複雑な申告では、データ入力だけで1件あたり8時間かかることがあり、乱雑なデータソース、前年の書類、手動の抽出と計算が頻繁に必要です。彼らは、税務準備が繁忙期の大きなボトルネックであると私たちに指摘しました。

この問題を解くために、Tax AI は今シーズンのパイロットに参加した Crete の事務所で7,000件の税務申告を処理しました。システムは 1040 と 1041 の準備に関する時間集約的なプロセスの多くを自動化しますが、効率向上以上に興味深いのは、システム自身が初回デプロイから3か月後のバージョンに比べて計測可能に改善している点です。

計測可能な自己改善

Tax AI では、実務者がソースファイルとクライアント固有の注記をアップロードすると、税務エンジン向けのサブミッションを作成し、レビュー用に用意します。実務者の税務準備時間を約3分の1節約し、記入の精度は最大97%に達し、スループットを約50%向上させ、実務者がクライアント対応により多くの時間を割けるようにしました。

この改善は、Tax AI がどれだけ訂正を必要とせずに申告を完成できるかを測ることで定量化できます。私たちは、どの割合の申告がフィールドの75%、90%、100%の正解率に達しているかを確認して精度を測定します。ローンチ時には申告の4分の1しか75%に達していませんでしたが、6週間以内に86%がその水準に到達しました。90%や100%の水準ではさらに速い成長を示しました。これらの閾値は、各申告に対して実務者がどれくらいフォローアップする必要があるかを実務的に示します。

初期は Tax AI が W-2s や 1099s のような単純な作業を扱っていましたが、シーズンが進むにつれて K-1s、スケジュール類、より難しいエッジケースを扱うようになりました。新しい機能が追加されるたびに、手作業で行う場合よりも1件あたりの節約時間は増えました。現在も継続的な進歩が見られます。

次に、私たちのチームがどのようにして Tax AI を自己改善させたかを、3つの重要な柱に沿って解説します。

• 1. 専門家である実務者からのフィードバック
• 2. 本番トレース（入力から最終出力までの構造化された履歴）
• 3. カスタム評価に基づく Codex 駆動の反復ループ

これらを組み合わせることで、継続的かつ迅速な製品開発が可能になります。私たちの経験は、実務者の専門知識がシステム品質や流れるデータを形作るうえで重要な領域における他の開発者にも役立つことを期待しています。

Tax AI がより複雑な申告に拡張するにつれ、75%、90%、および完全な完了に達するスコア付き申告の割合は税務シーズンを通じて上昇し続けました。

問題点

K-1、賃貸不動産のスケジュール、複数のソースファイル間で値を照合する必要があるフォームなど、税務準備の難しい部分に踏み込むと、真の課題は「製品が複雑な本番の失敗を可視化し、理解し、実行可能にするかどうか」であることが明らかになりました。

製品初期では、ほとんどの訂正が手動でした。実務者はシステムの誤りを修正できましたが、製品はその完全なコンテキストを捕捉していませんでした。ファイリング前に変更された値は、真の抽出ミス、マッピングの問題、製品サポートの欠如、あるいは期待されるワークフローノイズのいずれかを反映しているかもしれません。これらを分類するには依然としてエンジニアの追跡が必要でした。

エンジニアはコード化エージェントを使うことができましたが、システムはまだ改善ループ内で AI を意味のある形で使うように設計されていませんでした。どの山（改善すべき対象）に登るべきかを特定するためのシグナルが不足していたのです。

私たちのアプローチ: 三本柱のループ

これを受けて、システムは次の三つの柱を中心に設計しました。

• 実務者に近接する

  • 実務を行う人がプロダクトに何を学習させるかを導く必要があります。彼らの直感と理解は、どのエラーが重要か、次に注力すべきワークフローの部分がどこかを明らかにします。

• 本番が証拠を生成するよう製品を構築する

  • 製品は単に入力と出力を保存するだけでなく、ソース資料から抽出フィールドと出典まで、下流のサブミッションや専門家の訂正に至るまでの完全な経路を記録する必要があります。

• Codex 駆動の改善ループを作る

  • 本番の問題が可視化され構造化されれば、それらは所見（findings）、カスタム評価、限定されたエンジニアリングタスクになります。Codex はそれらを調査し、変更案を提案し、対象評価や回帰評価で検証し、純粋に手動の反復より速く製品を前進させることができます。

以下の「賃貸不動産」事例は、このループが実際にどのように機能するかを示します。実務者の訂正がどのように構造化された所見になり、評価ターゲットとなり、最終的に Codex によってスコープされたエンジニアリングタスクに変わるかを順を追って説明します。

賃貸不動産の例

賃貸物件の収入は個人の税務申告書の Schedule E に報告されます。エンジニアリングの観点では、抽出タスクは記述は簡単でも、実装は難しいことが多いです。システムは乱雑なソース資料（手書きメモ、メール、スプレッドシート、その他のクライアントファイル）を読み取り、税務エンジンに自信をもってマッピングできる賃貸物件フィールドを抽出し、実務者が承認または訂正できるだけの出典証拠を保持する必要があります。

以下の簡略化した例は、ソースファイルと抽出された出力がどのように見えるかを示します。賃貸物件のソースパッケージは引用付きのフィールドに正規化され、それらが下流の税務エンジンの概念にマッピングされます。

1. 実務者の訂正が失敗を明らかにする

エージェントが予測した値と、実際に申告された値の差は真の抽出ミスを反映しているかもしれませんが、実務者の好み、税務エンジンに残っている前年からの値、あるいはワークフローの別の箇所で導入・変更された値である可能性もあります。実務者はこれらのケースを識別するのを助けてくれ、どのアクションが実務者の訂正を要するか、あるいは提出をブロックするかを特定できるようにしました。

私たちはこれらの訂正を詳細に見ることができたため、レビュー工程を端末上での事後作業から継続的な学習サイクルへと変換しました。ワークフローは専門家の操作を構造化されたデータとして記録するように設計されています。現在では、各介入が Tax AI の改善ループにフィードバックされ、Tax AI が提案した内容、実務者が修正した内容、そして最終的に申告に反映された内容が正確に記録されます。

2. 製品トレースが訂正を評価に変える

賃貸不動産のような複雑なワークフローでは、本番でソースファイルから申告までに何が起きたかを保持する必要があります。その経路上で、文書は整理・分割・分類され、賃貸物件フィールドはソース資料への引用とともに抽出され、それらの値が税務エンジンにマッピングされ、実務者が提出前に修正することがあります。これらの製品レベルのトレースにより、失敗がどこで発生したかを調査可能にします。

実務者の訂正を有用な評価ターゲットに変えるために、システムは次の3ステップでそれらを処理します。

1. 差分をキャプチャする: Tax AI の出力と申告結果を比較して、期待値・予測値・差分が実行可能かどうかを示すフィールドレベルのレビュー行を生成します。
2. 関連する失敗をグループ化する: 類似のレビュー行をまとめ、再発する製品的失敗をワークフローノイズから分離します。例えば、実務者による繰り返しの訂正は、Tax AI が fair-rental-day フィールドを頻繁に見逃している、"other expenses" を誤処理している、あるいは同一ソースパッケージ内で複数の賃貸物件を混同している等を示すかもしれません。
3. 繰り返すパターンを評価ターゲットにする: 一度レビューされ計測されると、繰り返す所見は Codex が改善すべき明確な評価ターゲットになります。賃貸物件のレビュー行は再発する製品的失敗をノイズから分離し、実行可能なケースを Codex にとっての登るべき"山"（評価ターゲット）に変えます。

3. 所見が Codex にとっての山になる

第三の柱は、これらの新しい評価に対応できるエンジニアリングループを作ることです。ここで Codex が中心的な役割を担います。たとえば、評価パイプラインが Tax AI が一貫して "fair rental days" フィールドを見逃しており、実務者が確実にそれを補完しているとフラグを立てたとします。

この所見は既に代表的なソースパッケージと期待される出力からなる限定評価セットとしてパッケージ化されているため、Codex は製品のスキャフォールド（trace、eval、repo、skills）内で直接根本原因を調査できます。Codex は単に不十分な最終出力だけで作業するのではありません。トレース、評価、リポジトリ、スキルを合わせて検査します。

• パイプラインを調査する: ソースパッケージ、抽出スキーマ、マッパーの挙動、コードパスを点検し、問題が未サポートのフィールド、見逃された抽出パターン、ソース選択の問題、マッパーのギャップ、あるいはグレーダーの問題のどれに起因するかを判断します。
• 目標を絞った修正を実装する: 抽出スキーマを拡張する、賃貸物件文書のソース選択を改善する、税務エンジンのマッパーを更新する、あるいは期待されるワークフローノイズが失敗として数えられているならグレーダーを洗練します。
• 検証と提案: 対象評価を再実行し、より広い回帰スイートを実行し、エンジニアリングレビュー用の候補 pull request を提示します。
• ループを閉じる: 繰り返される実務者の訂正を計測可能なエンジニアリングタスクに変えます。証拠が曖昧または安全に自動化できない場合は、そのケースはループに無理に通されるのではなくプロダクトチームに差し戻されます。

エンドツーエンドの自己改善ループは次のように動きます: 本番トレースが繰り返されるフィールドレベルの訂正を浮き彫りにし、それが Codex がトレース、評価、リポジトリ、スキルとともに検査できる失敗シグナルになります。実行可能なパターンは限定された評価と候補となる製品変更に変わり、曖昧なケースはエンジニアのレビューに回されます。出荷された各改善は次のサイクルのための新たな本番証拠を生みます。

Codex を使ってこのループを構築する方法

賃貸不動産の例は、制作物（production artifacts）とトレースを用いてエージェントの能力を改善するより広い再利用可能なパターンを象徴しています。本番データからレビュー済みの所見、ソーストレース、期待される税務エンジン出力、関連するコード例、評価コマンドを一連の入力として与えられると、Codex は数週間〜数か月で性能と精度を実質的に改善できます。

これは私たちが以前に述べた harness engineering と Symphony の原則に基づいています。これらは、タスクを Codex にとって判読可能にし、限定されたコンテキストとツールを与え、検証と人的レビューを環境の一部として維持する方法を示しています。

その証拠が自動的に Codex のタスクになるわけではありません。実務者の訂正は抽出のミスを反映している場合もあれば、...（本文はここで続きます）