先に結論
OpenAI が今回見せた価値は、Codex が税務書類を読めることそのものではありません。本番で起きた失敗を、次の改善タスクへ変える仕組みを公開したことです。
記事の要点は3つです。
- 専門家の修正を structured data として残す
- production traces で失敗箇所を追えるようにする
- 繰り返し起きる失敗を eval に変え、Codex に直させる
AI agent を実務へ入れた後に困るのは、最初のデモ精度より、直し方が毎回属人化することです。今回の OpenAI 事例は、その詰まりどころに答えています。
Codex の導入前整理から見たいなら、OpenAI Codex enterprise rollout guide も合わせて読むとつながります。
何が公開されたのか
OpenAI は 2026-05-27 に、Thrive Holdings と Crete の共同事例として Building self-improving tax agents with Codex を公開しました。
事例の中心は、Tax AI を使って複雑な tax return 準備を効率化しつつ、実運用で出た失敗を Codex が改善し続けるループへ載せた点です。
公開文面では、Tax AI について次の数値が示されています。
- 7,000 件の tax return を処理
- 税務準備の時間を約3分の1削減
- 最大97%の精度
- 約50%の throughput 増
ただし、この記事を読むうえで大事なのは数字の大きさだけではありません。もっと重要なのは、その改善がどう生まれたか です。
本当に見るべきなのは精度より改善ループ
OpenAI は、この事例を3本柱で説明しています。
1. 専門家の修正を、その場しのぎで終わらせない
Tax AI では、実務担当者が直した値をただ保存するのではなく、どの値をどう直したか を structured data として残します。
ここが弱いと、失敗は「人が直した」で終わります。改善チームから見ると、抽出ミスなのか、マッピングミスなのか、仕様未対応なのかが分かりません。
逆に修正差分を残せると、どの失敗が繰り返し起きているかを後から見つけやすくなります。
2. production traces が、失敗箇所の切り分けを速くする
OpenAI は、入力から最終出力までの経路を production traces として残す重要性を強く押し出しました。
Tax AI の例では、ソース文書の整理、抽出、引用、tax engine へのマッピング、最終レビューまでの流れを追えるようにしています。
これがあると、失敗を見つけた時に「最終結果が違う」だけで止まりません。どの段階でズレたか を追えるので、改善タスクを狭く切れます。
3. 繰り返し起きる失敗だけを eval に変える
修正差分が全部そのまま改善対象になるわけではありません。OpenAI は、field-level review row を作り、 recurring failure をまとめ、そこから eval target を作る 流れを説明しています。
この順番が大事です。
人の修正には、単純な抽出ミスだけでなく、業務判断や例外処理も混ざります。そこを雑に全部自動化すると、かえって危ないです。
今回の事例は、繰り返し起きる失敗だけを bounded task にする ことで、Codex が安全に手を入れやすい形へ寄せています。
どんなチームに効くのか
この事例は税務向けですが、示している運用パターンはもっと広く使えます。
特に相性がいいのは、次のような業務です。
- 法務や経理のように、専門家レビューが最後に残る仕事
- BPO や審査業務のように、入力が汚く例外が多い仕事
- AI が下書きを作れても、改善ログが人の頭の中にしか残っていないチーム
逆に、まだ PoC 段階で trace も eval もないチームは、いきなり「self-improving agent」を目指すより、まず失敗を記録できる実装を作るほうが先です。
いま導入担当がやるべきこと
この事例を読んで、すぐ真似しやすいのは次の4点です。
人手修正を残す粒度を見直す
修正後の最終値だけでは足りません。何が提案され、何が直され、どれが本当に失敗だったか を残せる粒度に寄せたほうがいいです。
trace を途中経路まで残す
source から extraction、mapping、review まで追えないと、agent へ戻す改善タスクが太くなります。まずは どこで失敗したか辿れること を優先したほうが早いです。
recurring failure をまとめる
単発の例外を全部直そうとすると、改善ループが崩れます。繰り返し出る失敗を grouped finding にする運用が必要です。
agent に任せる範囲を狭く保つ
OpenAI も、Codex が曖昧なケースまで全部自動で片付けるとは言っていません。evidence が揃った bounded task だけを agent に渡す ほうが現実的です。
監査や役割分担まで含めて考えたいなら、GitHub Copilot coding agent vs Claude Code vs Codex｜監査性・安全性・レビュー運用で選ぶ も参考になります。
比較記事より先に、この手の一次情報を読む価値
AI coding agent の比較記事は増えていますが、本番運用の改善ループまで具体的に見せる一次情報はまだ多くありません。
今回の OpenAI 記事が役立つのは、モデル比較では見えない 導入後の仕事 を具体化しているからです。
- 誰の修正を学習材料にするのか
- 何を trace として残すのか
- どの失敗を eval に変えるのか
- どこまで agent に直させるのか
この4点が固まっていないなら、比較より先に読む価値があります。
ツール選定そのものを見直したい場合は、Codex for (almost) everything vs Claude Code auto mode vs GitHub Copilot coding agent から入ると全体像を掴みやすいです。
まとめ
OpenAI の Tax AI 事例は、税務向け AI の成功談として読むだけではもったいないです。
本当に重要なのは、専門家レビュー、production traces、eval をつないで、Codex が改善し続ける運用を見せたこと です。
AI agent を本番へ入れた後に欲しいのは、派手なデモより 失敗を次の改善へ変える仕組み です。今回の公開は、その設計図として読む価値があります。