一言で言うと
「AIエージェントが自分で改善する」と聞くと、AIモデルそのものが賢くなっていく話だと思いがちです。今回の事例はそうではありません。会計士が申告書を直した内容を記録し、同じミスが繰り返されるとテストケースに変え、Codex がコード修正を提案する——この一連の流れが回るかどうかは、Codex の性能より先に、現場の失敗を記録・整理できる製品設計が整っているかで決まります。
何が起きているのか
OpenAI は、税務申告作成AI「Tax AI」を6ヶ月かけて開発した経緯を公開しました。
パートナーは Thrive Holdings です。日本ではあまり知られていない米国の事業会社で、会計サービスなどを自社で運営する持株会社です。OpenAI が AI を「売って導入する」関係ではなく、Thrive が自社の会計事業の中で AI を共同開発し、自社で使う構図です。
Tax AI の試験運用は、Thrive が米国で展開する会計サービス「Crete（クレート）」で行われました。Crete は会計事務所のネットワーク型ブランドで、30社以上の事務所が参加しています。個人や法人の税務申告を代行する会計士が、顧客の申告書を作成する現場——いわゆる「税理士事務所の実務」——が、そのまま AI の開発と改善の舞台になりました。
今期の試験運用では、Form 1040（個人の所得税申告書）と Form 1041（信託の所得税申告書）を合わせて7,000件処理したそうです。
中規模以上の申告では、データ入力だけで1件あたり約8時間かかる作業でした。Tax AI は申告書作成にかかる時間を担当者あたり約1/3削減し、最大97%の精度で申告書ドラフトを作成、スループットを約50%向上させたとのことです。
注目したいのは、システム自体が3ヶ月前のバージョンより目に見えて改善している点です。立ち上げ時点では「フィールドの75%以上が正しい申告書」は全体の25%にとどまっていましたが、6週間後には86%まで上昇しました。90%・100%レベルでも同様の伸びを見せています。
OpenAI がこの改善を可能にしたと説明する3つの柱は次の通りです。
1. 現場の専門家フィードバック: 何が「本当の抽出ミス」で、何が「会計士の好み」「前年データの繰り越し」かを区別できるのは現場の人だけ 2. プロダクションが証拠を生む設計: 入力と出力だけでなく「ソース文書 → 抽出フィールド → 税エンジン送信 → 専門家の修正」までの全経路を記録 3. Codex 駆動の反復ループ: 構造化された失敗を、対象を絞った評価（eval: 性能テスト一式）に変換し、Codex に原因調査・修正案・回帰検証までやらせる
具体例として、賃貸物件所得の申告処理が紹介されています（米国の申告書 Schedule E に載る項目）。会計士が AI の出力を直すと、「どの項目を、何から何に直したか」が記録されます。同じ種類のミスが何度も出てくると、それをテストケースにまとめます。Codex はそのテスト結果と、実際の処理の記録、プログラムのソースコードをあわせて読み、「書類から情報を読み取るルール」や「税務ソフトへ渡す変換処理」のどこに穴があるかを特定し、修正案をエンジニアに提示します。賃貸物件の処理は、6週間ほどで正答率・見逃しの少なさともに90%に達したそうです。
AI業界の文脈では
「AIが自分で賢くなる」のではなく、会計士が直したミスを記録し、同じ失敗をテストケースに変え、Codex にコード修正を提案させる——その仕組みが改善の本体です。
通常の AI プロダクト開発では、本番でバグや精度劣化が見つかったあと、エンジニアが事例を1件ずつ調べ、プロンプトを直したり評価データを足したりします。エンジニアが動かしたタイミングでだけ改善が進む、手動で重い作業です。
OpenAI が示しているのは、改善の手間を「エンジニアが後から調べる」から「会計士の日常業務の中で自動的に記録される」方向へ移したやり方です。会計士がいつもどおり申告書を直すだけで、「どの項目を、何から何に直したか」が項目ごとに記録されます。同じミスが何度も出ればまとめてテストケースになり、Codex がコード変更を提案します。エンジニアは修正案を確認して承認する——という分担です。
ここで効いているのは、ベース技術というより設計判断です。原文では「production creates evidence（本番が証拠を生み出す）」という言葉でこの考え方を説明しています。本番運用そのものを評価データの生成源として再設計した、と整理できます。
なお、関連する OpenAI の以前の取り組みである「harness engineering」「Symphony」では、コーディングエージェントに対してタスクをどう legible（読みやすく）にするか、文脈とツールをどう絞るか、検証と人手レビューをどう環境に組み込むかが論じられています。今回の Tax AI はその設計原則を、実プロダクトに適用した実例にあたります。
私の見立て
ここからは私の見立てですが、AIエージェントの実用化で次に効くのは、モデルの精度ではなく「自社のフィードバックループがどれだけ構造化されているか」だと思います。
3つの柱を細かく見ると、いずれも「データの形」を作る話です。誰のどんな修正アクションを記録するか。何を「ノイズ」、何を「再発するパターン」と分類するか。どんな粒度で評価セットに昇格させるか。これらは Codex が決められる範囲の外側にあり、人間のエンジニアとドメイン専門家が事前に設計する必要があります。
逆に言うと、Codex の能力をそのまま借りても、土台がなければ自己改善ループは回りません。原文には「差分が繰り返し現れ、レビュー・グルーピングを経たあとで初めて、Codex 用の有界タスクに変換される」という条件が明記されています。専門家が修正したデータを単に DB に貯めるだけでは足りない、ということです。
もう一つ気になるのは、Thrive Holdings が「ベンダーではなく事業オーナー」として Crete に関わっている点です。Codex を売って導入する関係ではなく、自社業務として税務サービスを運営しているため、専門家のフィードバックを継続的に取れる環境を内製できた、と原文には書かれています。Tax AI が成立する条件として、これは小さくない要素だと思います。
ベンダーが顧客企業に AI を導入するモデルでは、3つの柱のうち2番目・3番目は構築できても、1番目の「現場の専門家による継続的なフィードバック」が薄くなりがちです。今回の構図は、ドメイン専門家を「ユーザー」ではなく「共同開発者」の位置に置けるかどうか、というプロダクト構造の問題に踏み込んでいると思います。
→ 何が変わるか: AIエージェントを評価する基準が「モデルの精度」から「フィードバックループ設計の精度」へと移っていくと思います。同じ Codex を使っても、現場の修正アクションを構造化できる企業とそうでない企業とで、半年後・1年後の到達点が大きく分かれる可能性があります。
→ 何をすべきか: AIプロダクトを設計・導入する立場では、AIモデルの選定より前に「失敗をどう構造化するか」を考えることを勧めます。専門家が普段の業務で行う修正・確認のアクションを、自然な形で構造化データとして残せる UI を作ること、そして繰り返し現れる失敗パターンを評価セットに変換する仕組みを用意しておくこと。これが、Codex などのコーディングエージェントを「使える」状態にする前提条件になります。