結論から書きます。新しい AI モデルが発表されても、稼働中の案件にすぐ入れ替える必要はほとんどありません。やるべきことは、その案件で以前から使っている評価セット（過去の入力と期待する出力をまとめたもの）に新モデルを通し、同じ基準で測り直すことだけです。測れない状態で「新しいから良いはず」と入れ替えると、精度は上がったのに運用が壊れる、という事態が起きます。この記事では、発表を見てから入れ替えを決めるまでの手順と、実装で詰まりやすい箇所を順に書きます。
新しいモデルが出たとき、最初にやることは？
最初にやるのは比較検証ではありません。「今の案件で、そもそも何が足りていないか」を一覧にすることです。足りていない点がなければ、新モデルを試す理由もありません。
受託開発の現場で挙がる不足は、だいたい次のどれかに収まります。
- 精度が足りない（分類の取り違え、要約の抜け、数値の読み間違い）
- 速度が足りない（画面の応答が遅く、担当者が待てない）
- 費用が合わない（件数が増えて従量課金が想定を超えた）
- 扱える入力が足りない（長い文書が入りきらない、画像や音声を渡せない）
- 運用上の制約（データの保存場所、ログの扱い、提供終了の予告）
このうちどれに当たるかで、新モデルを見る目線が決まります。精度不足なら評価セットでの正答率、費用不足なら 1 件あたりの単価、速度不足なら最初の 1 文字が返るまでの時間。目的を決めずに「全部比べる」と、比較表は埋まるのに結論が出ません。
評価の合格ラインはどう決める？
合格ラインは、モデルの性能ではなく業務側の許容範囲から逆算して決めます。たとえば次のような場面です。問い合わせメールを 5 つの部署に振り分ける仕組みで、誤って振り分けられた場合は受け取った部署が転送すれば済む。この場合、多少の誤分類は業務を止めません。一方、請求書から金額を読み取って会計システムに登録する仕組みなら、1 件の読み間違いが実害になります。
前者は「誤りが出ても戻せる」、後者は「誤りが出たら戻せない」。この違いで、合格ラインも、人が確認する工程の要否も変わります。AIの誤答は「答えない条件」で減らすで書いたように、無理に正答率を上げるより「自信がないときは答えず人に回す」設計のほうが実務では効くことが多く、その場合の評価軸は「正答率」ではなく「人に回った件数」になります。
評価セットは、案件ごとに最低限これだけ用意しておきます。
| 種類 | 中身 | 役割 |
|---|---|---|
| 通常例 | 日常的に発生する典型的な入力 | 基本性能の確認 |
| 過去の失敗例 | 運用中に誤った実データ（匿名化したもの） | 再発していないかの確認 |
| 境界例 | 判断が分かれる入力、情報が欠けた入力 | 「答えない」動作の確認 |
| 禁止例 | 個人情報の混入、社外秘の質問など | 想定どおり拒否するかの確認 |
この 4 種類が揃っていれば、新モデルが出るたびに同じものを流すだけで済みます。揃っていない案件は、まず評価セットを作るところからです。評価セットは一度作れば資産になり、モデルが変わるたびに作り直す必要はありません。
切り替えのコストはどこに出るか
モデルの単価が下がっても、切り替え全体が安くなるとは限りません。費用は API の利用料以外の場所に出ます。
| 出る場所 | 内容 | 軽くする方法 |
|---|---|---|
| プロンプトの作り直し | モデルごとに指示の効き方が違い、出力形式が崩れる | 指示文を設定ファイルに分離しておく |
| 出力の受け取り部分 | JSON などの構造化出力の揺れ、項目名の差 | 検証処理を挟み、崩れたら再試行する |
| 再テスト | 評価セットの再実行と結果の読み合わせ | 実行を自動化し、人は差分だけ見る |
| 社内の再説明 | 利用者への挙動変更の周知、マニュアル改訂 | 変更点を 1 枚にまとめる運用にする |
| 契約・審査 | データの扱いが変わる場合の社内承認 | 事前に提供条件の差分だけ確認する |
このうち最も読みにくいのが「出力の受け取り部分」です。同じ指示でも、モデルが変わると説明文を付けて返す、項目の順番が変わる、といった差が出ます。切り替え前提の作りにしておくかどうかで、ここの手間が大きく変わります。詳しくは AIを乗り換えられる設計 — 費用はどこに出るか に書きました。
入れ替えを急がないほうがよいのはどんなとき？
次のいずれかに当たる案件は、発表直後の入れ替えを見送る判断が妥当です。
- 繁忙期の最中。問題が出たときに切り戻す人手が確保できません。
- 評価セットが未整備。良くなったか悪くなったかを示せないまま入れ替えることになります。
- プレビュー提供の段階。提供条件や料金が後から変わる可能性があり、本番の前提に置きにくい状態です。
- 監査・報告の対象になっている処理。出力の根拠を説明する必要がある処理は、変更の記録と承認の手順を先に決めます。
- 人の確認を省く設計になっている処理。誤りがそのまま外に出る構造では、検証を厚くしてから動かします。
逆に、入れ替えを前向きに検討してよいのは、現行モデルの提供終了が告知された場合です。主要な提供事業者は、古いモデルの提供終了（デプリケーション）をドキュメント上で予告する運用を取っています。予告の期間や形式は事業者ごとに異なるため、自社が使っている事業者の公式ドキュメントで、該当モデルの記載を確認してください。ここは「いずれ対応する」と置いておくと、期限直前に慌てる典型的な箇所です。
実装で詰まりやすいのはどこか
評価で良い結果が出ても、業務システムに組み込む段階で引っかかる箇所があります。受託開発の見積もりでも、ここを見落とすと工数がずれます。
- 出力形式の安定性。構造化出力に対応していても、長い入力や例外的な入力で崩れることがあります。検証と再試行をセットで実装します。
- 入力できる長さ。扱える文字数の上限が増えても、長文を丸ごと入れると費用と応答時間が増えます。必要な部分だけ渡す設計のほうが安定します。
- 応答時間のばらつき。平均値ではなく、遅かったときの時間で画面設計を考えます。待ち時間が読めない処理は、画面から外して非同期にします。
- 外部ツールの呼び出し。モデルに社内 API を呼ばせる構成では、呼び出しの判断基準がモデルによって変わります。呼び出し可否のテストを別に用意します。
- 安全フィルタの強さ。業務用語が不適切と判定されて止まる場合があります。業種特有の語彙を含む入力で必ず試します。
- バージョンの固定。「最新を自動で使う」指定にすると、知らないうちに挙動が変わります。本番は日付入りのバージョン指定にし、更新は手動で行います。
この 6 点は、検証環境で短い文章を投げている段階では出てきません。チャットで動いたAIが業務で崩れる理由 で扱った問題と同じ構造で、実データと実運用の条件に乗せて初めて見えます。
判断の手順を 5 つにまとめると
ここまでを、発表を見てから動く順番に並べ直します。
- 不足の特定。今の案件で足りていない点を書き出す。なければ何もしない。
- 条件の確認。料金、データの扱い、提供終了の予告を、事業者の公式ドキュメントで確認する。
- 評価セットの実行。既存の評価セットを新モデルに通し、通常例・過去の失敗例・境界例・禁止例の結果を比較する。
- コストの見積もり。プロンプト調整、出力処理の修正、再テスト、周知までを含めて工数を出す。
- 切り戻しの準備。旧モデルに戻す手順と、戻す判断の基準（誤り件数、応答時間など）を先に決めてから切り替える。
5 番目を省略しないことが重要です。切り戻せる状態であれば、判断を早められます。切り戻せない状態だと、検討が長引いて結局何もしないまま提供終了を迎えることになります。
まとめ
新しい AI モデルの発表は、受託開発の会社にとって「評価セットを流す機会」であって、「乗り換えの合図」ではありません。判断を支えるのは、モデルの性能表ではなく、案件ごとに積み上げた評価セットと、切り戻せる実装です。この 2 つがあれば、発表のたびに検討をやり直す必要はなくなり、1 日から数日で判断できるようになります。
逆に、この 2 つがない状態では、どれだけ新しいモデルが出ても「良さそうだが確かめられない」で止まります。発表への対応を急ぐより、今動いている案件の評価セットを 1 つ作るところから始めるほうが、結果的に次のモデルへの移行を早めます。モデルの提供条件や提供終了の予定は事業者の公式ドキュメントで変更されるため、自社が利用している事業者の記載を定期的に確認することをおすすめします。