技術検証で99%の精度が出ても、本番で使えないケースは多い。原因は、テストパターンを作りすぎたことによる過剰最適化だった。「軽量化webapp指定」「JSON出力ルール厳守」といった細かな条件を重ねるほど、汎用性は失われていく。AI自動化の実用化判断には、検証の成功体験を疑う視点が要る。

トークンが即死した朝

ある企業で、Claude Code を使った帳票生成の自動化を進めていた。検証環境では、指定した形式で PDF が出力され、項目の抜け漏れもなく、関係者全員が「これはいける」と確信していた。

本番に投入した翌朝、Slack に「動かない」と通知が来た。ログを見ると、トークン上限に達して処理が止まっている。検証では一度も起きなかった現象だった。

原因を追うと、検証時に使っていたテストデータが、すべて「軽量化webapp指定」に適合するよう整えられていたことがわかった。実データは、そうではなかった。ファイル名に全角スペースが入り、階層が深く、PDF の中に手書きメモが混じっていた。プロンプトに書いた前提条件は、検証用に用意した10件のデータには当てはまったが、現場の300件には当てはまらなかった。

精度は高かった。でも、それは過剰最適化の結果だった。

テストパターンを作りすぎる

私たちが AI 自動化の導入支援を続ける中で、何度も見てきた構造がある。検証フェーズで「これなら完璧だ」と思えるものほど、実用化で破綻する。

なぜか。検証を通すために、条件を増やしすぎるからだ。

「このケースではエラーが出たから、こう指定しよう」。「あのパターンでは漏れたから、ルールを足そう」。こうして、プロンプトは肥大化し、入力データの前処理は複雑になり、JSON 出力のスキーマは巨大になっていく。そして、テスト用に用意した20パターンには全て対応できる状態が完成する。

問題は、21個目のデータだ。現場には、テストで想定しなかった揺らぎが無数にある。ファイル形式、命名規則、データの粒度、更新タイミング。検証環境で制御できていたものが、本番では制御できない。制御しようとすると、運用が回らなくなる。

Cursor でコード生成を自動化したプロジェクトでも、同じことが起きた。特定のリポジトリ構造に最適化しすぎて、別のプロジェクトに横展開できなかった。Notion API 経由でドキュメントを自動生成する仕組みも、検証時の5ページには完璧に動いたが、階層が深い実際のワークスペースでは再帰処理が破綻した。

過剰最適化は、検証を成功させるが、実用化を遠ざける。

実用化判断は、揺らぎに耐えられるかで決まる

では、どこで線を引くべきか。私たちが今、導入支援の現場で使っている判断軸は、「揺らぎに耐えられるか」だ。

検証で100点を取ることではなく、本番で70点を維持できるかを見る。テストパターンを20個作るのではなく、ランダムに抽出した5件の実データを投げて、何が起きるかを観察する。エラーが出たとき、プロンプトを足すのではなく、エラーハンドリングで吸収できるかを先に考える。

ある会計事務所では、freee API から取得した仕訳データを Claude で分析する仕組みを入れた。検証時には「勘定科目が明確なもの」だけを対象にしていたが、実運用前に「補助科目が空欄」「摘要に特殊文字」といった揺らぎを含むデータで再テストした。結果、プロンプトを削り、代わりに「不明な項目はスキップして続行」というロジックを Claude に持たせた。精度は95%から80%に下がったが、止まらなくなった。

実用化とは、完璧に動くことではない。不完全なデータが来ても、致命的に壊れないことだ。AI 自動化の失敗学で最も重要なのは、「成功した検証を疑う」視点かもしれない。

ちょうどいい、を見極める

精度を追うと、汎用性が失われる。汎用性を取ると、精度が下がる。このトレードオフの中で、どこに着地するかが実用化判断のすべてだ。

私たちは今、検証の最後に必ず「意図的に壊す」ステップを入れている。ファイル名を変え、データを欠損させ、想定外の入力を与える。そこで止まるなら、まだ実用化には早い。エラーログを吐いて次に進めるなら、許容できる。

AI は、人が全てを制御しなくても動く設計を許す。でも、制御しすぎると動かなくなる。検証で「完璧」を作ることと、現場で「使える」ものを作ることは、別の技術だ。