OpenAIが2026年5月27日に公開したTax AI事例は、AIエージェントを本番投入した後にどう育てるかをかなり具体的に示しています。ポイントは、モデルを一度デプロイして終わりにしないことです。現場の修正をただの手戻りで終わらせず、production trace、評価セット、コード修正に接続する設計を最初から作ると、改善速度が大きく変わります。
なぜ本番投入後の改善設計が先に必要なのか
PoCでは通っていたエージェントが本番で崩れる理由は、失敗が複雑だからです。抽出ミスなのか、マッピング漏れなのか、業務判断なのか、単なる例外運用なのかが混ざると、プロンプトを少し直すだけでは前に進みません。OpenAIも、複雑な税務処理では『どこで失敗したかを見える化し、再発する失敗だけを改善対象に切り出す』ことが核心だったと説明しています。
Tax AI事例で確認できた成果
公式記事によると、OpenAIとThrive HoldingsはCreteの30超の会計事務所ネットワーク向けにTax AIを共同開発し、今回の税務シーズンのパイロットでは7,000件の申告を処理しました。Tax AIは1040/1041申告の準備時間を約3分の1削減し、最大97%の精度で下書きを作成し、スループットを約50%高めたとされています。さらに、75%の項目充足率に届く申告の割合は、ローンチ時の約25%から6週間で86%まで上がりました。ここで重要なのは、改善が『勘の良い手修正』ではなく、計測可能なループとして回っていた点です。
改善ループを作る3つの柱
記事で示された柱は3つです。1つ目は、実務担当者がどの修正を重要と見るかを学習対象の入り口に置くこと。2つ目は、入力文書から抽出値、下流システムへのマッピング、最終修正までをtraceとして残すこと。3つ目は、繰り返し起きる差分だけをeval化し、Codexのようなコーディングエージェントに『この失敗を直せばスコアが上がる』という登るべき山を渡すことです。この順序を飛ばしてAIに改善を任せても、曖昧な失敗は自動化しにくく、結局は人手レビューに戻ります。
eval設計は『再現できる失敗』から始める
実装では、全件を大きな正解率で眺めるより、現場で頻発した差分をフィールド単位で束ねる方が有効です。OpenAIの例では、予測値と実際の申告値の差分をレビュー行として保持し、類似する失敗をグルーピングしてからeval targetに変換しています。企業で真似するなら、まずは『担当者が毎週3回以上直している項目』『修正すると工数インパクトが大きい項目』『誤りが下流承認を止める項目』の3条件で優先順位を付けるのが現実的です。これなら、改善ごとの費用対効果と回帰テストの必要性を説明しやすくなります。
現場レビューを学習信号に変える運用
本番運用でありがちな失敗は、レビュー画面があっても『修正後の理由』が残らないことです。Tax AIの学びは、修正前後の値だけでなく、どのソースを根拠に直したか、どの工程で止まったかを構造化して残すべきだという点にあります。レビュー担当者には自由記述を増やしすぎず、抽出ミス・分類ミス・マッピング漏れ・業務判断のような選択肢を先に用意すると、後段の分析が一気にやりやすくなります。ここまで整えば、エンジニアは曖昧なバグ報告ではなく、代表例付きの失敗セットを受け取れます。
導入前に決めるべきチェックリスト
本番改善ループを回したいなら、導入前に5点を決めておくべきです。1) 何を正解とみなすかを項目単位で定義する。2) 人の修正をどの粒度で保存するかを決める。3) 反復発生した失敗だけをeval候補に昇格させる閾値を置く。4) エージェントが触ってよいコード領域と、必ず人間承認を通す領域を分ける。5) targeted evalとregression evalの両方を通って初めて改善案を採用する。この5点が曖昧だと、改善は回っているように見えても再現性が残りません。
FAQ
Q. evalは大規模データがないと始められませんか？ A. いいえ。まずは同種の修正が週に数回発生する業務から始める方が成功しやすいです。重要なのは件数の多さより、失敗理由を分類できることです。
Q. Codexのようなコーディングエージェントに何を渡すべきですか？ A. production trace、代表的な失敗例、期待出力、対象コード、実行するevalコマンド、回帰確認手順をセットで渡すべきです。単なる『精度を上げて』では改善が再現しません。
Q. どこまで自動化し、どこから人間が見るべきですか？ A. 業務判断や法的責任が絡む部分は人間承認を残し、抽出・分類・差分検知のように成功条件を明示しやすい層から自動化するのが安全です。
自社のAIエージェントでeval設計やレビュー導線を整えたい場合は、 AI・Claude研修のご相談はこちら 。PoC止まりではなく、本番改善ループまで含めて設計します。
今回のOpenAI事例は、AIエージェントの価値が『最初の精度』だけではなく、『現場修正を次の改善に変換できるか』で決まることを示しました。導入判断ではモデル比較だけでなく、trace、eval、レビュー、承認の4点セットを先に設計することが重要です。
