LLMモデル変更に備える開発の進め方｜提供終了の前に
AI機能を組み込んだサービスは、使っているLLM（大規模言語モデル）が更新されたり、提供を終えたりしても動き続けるよう、作る段階から備えておく必要があります。この記事では、モデルの変更で何が起きやすいのか、開発の途中で何を仕込んでおくのか、運用で何を続けるのかを順に整理します。新規事業でAI機能を軸にしたサービスを作ろうとしている方が、発注や社内の判断の前に確かめられる内容を目指しました。
モデルの変更は「いつか起きること」と考えておく
AI機能を持つサービスの多くは、LLMを外部のAPI（ほかのソフトから機能を呼び出す窓口）経由で利用しています。自社のサーバーに置いたソフトとは違い、モデルの中身や提供期間は提供元が決めます。そのため、使い始めた時点のモデルが、サービスを運営している間ずっと同じ形で使えるとは限りません。
モデルの変更には、大きく分けて3つの形があります。
- 新しいモデルへの切り替え：後継モデルが出て、旧モデルが段階的に使えなくなる
- 提供終了：旧モデルの提供期間が終わり、呼び出すとエラーになる、または別のモデルに転送される
- 同じ名前のまま中身が更新される：「最新版」を指す名前で呼んでいると、ある日から応答の傾向が変わる
提供終了は、提供元が事前に期間を示して告知するのが一般的です。ただ、告知から終了までの期間は提供元やモデルによって異なります。「告知があってから動けばよい」と考えていると、他の開発や事業の予定と重なったときに、対応の時間が足りなくなります。
私たちの別の記事でも、こうした動きを個別に取り上げています。たとえばGemini 2.5の旧ID、12月1日に新モデルへ自動転送では、旧モデルの呼び出し名が新しいモデルに自動で振り替わる発表を扱っています。また、Claude API 3年ぶり新版、温度指定は送るとエラーでは、API側の仕様変更で、これまで送っていた設定がエラーになる点を扱っています。モデルそのものの入れ替えだけでなく、呼び出し方の変更も備える対象になる、ということです。
新規事業の場合、この問題は特に重くなります。サービスの価値の中心がAIの応答にある場合、モデルが変わると、お客様に届ける価値そのものが変わってしまうからです。
モデルが変わると壊れやすい4つの箇所
モデルの変更で何が壊れるのかが分かっていれば、備えるべき箇所も絞れます。ここでは、起きやすい順に4つ挙げます。
出力の質と書式
最も気づきにくいのが、応答の質と書式の変化です。同じ指示文（プロンプト）を送っても、モデルが変わると、文章の長さ、口調、箇条書きの使い方、判断の傾向が変わることがあります。
とくに影響が大きいのは、AIの出力をそのままプログラムで読み取っている場合です。たとえば「JSON形式で返してください」と指示して、返ってきた結果を画面やデータベースに流し込む作りだと、書式がわずかに変わっただけで読み取りに失敗します。エラーにならずに、内容だけが少しずれる場合もあり、こちらのほうが発見は遅れます。
APIの仕様と設定項目
モデルによって、受け付ける設定項目や上限が異なります。以前は指定できた設定が受け付けられなくなる、新しい版で必須の項目が増える、といった変更です。前の章で触れたように、設定を送ること自体がエラーになるケースもあります。
この種の変更は、動かしてみればすぐに分かるので、まだ扱いやすい部類です。ただし、呼び出しのコードがサービスのあちこちに散らばっていると、修正箇所の洗い出しだけで時間がかかります。
速度・費用・上限
モデルが変われば、応答の速さ、利用単価、一度に扱える文章量の上限も変わります。新しいモデルが高性能でも、応答が遅くなって画面の体験が落ちる、単価が上がって事業の採算が合わなくなる、ということが起こり得ます。反対に、より小さなモデルへ切り替えることで、費用を抑えられる場合もあります。
AIの利用料は、サービスの利用が増えるほど増える変動費です。モデルの選択は、技術の問題であると同時に、事業の収支の問題でもあります。
安全性と拒否の挙動
モデルによって、答えない話題、注意書きを添える場面、曖昧な質問への返し方が違います。以前は答えていた質問に答えなくなる、あるいは逆に、想定していなかった内容まで答えるようになる、といった変化です。
利用者に直接AIを触ってもらうサービスでは、この挙動の変化が、そのままサービスの信頼性に影響します。社内向けの道具であっても、利用者が「前と答えが違う」と感じれば、使われなくなる原因になります。
作る段階で仕込んでおく6つの備え
ここからが本題です。モデル変更への備えは、運用に入ってから考えるより、作る段階で仕込むほうがはるかに安く済みます。後から作りを変えるには、動いているサービスを触る必要があるからです。
1. モデル名を設定として外に出す
モデルの名前をプログラムの中に直接書き込まず、設定ファイルや管理画面から変えられる形にします。これだけで、モデルの入れ替えが「プログラムの修正」から「設定の変更」に変わります。
あわせて、呼び出し名の選び方にも注意が必要です。「最新版」を指す名前は、気づかないうちに中身が変わる可能性があります。日付やバージョンが入った固定の名前を使えば、変更のタイミングを自分たちで決められます。一方、固定の名前には提供終了の期限があるため、期限の管理が別途必要になります。どちらを選ぶかは、サービスの性質で決めます。
2. AIを呼び出す部分を1か所にまとめる
AIへの問い合わせを、サービスのあちこちから直接行うのではなく、専用の窓口（1つの部品）を通すようにします。窓口の内側だけがモデルの違いを知っていて、外側のサービス本体は、どのモデルが使われているかを意識しません。
この作りにしておくと、モデルの入れ替えで直す場所が窓口の中だけになり、影響範囲を小さく保てます。提供元を別の会社のモデルに変えたい場合にも、同じ考え方が使えます。ただし、提供元ごとの細かな違いを完全に隠すのは難しいので、「1か所に集める」までを目標にするのが現実的です。
3. 指示文をコードと分けて管理する
プロンプトは、実質的にサービスの仕様書の一部です。プログラムの中に埋め込まず、独立したファイルとして版（バージョン）を付けて管理します。そうすれば、モデルを変えたときに指示文だけを調整でき、どの版の指示文がどのモデルで使われていたかも後から追えます。
4. 出力の形を決めて、受け取り側で検証する
AIの出力をプログラムで使う場合は、期待する形（項目、型、取り得る値）を決めておき、返ってきた結果がその形に合っているかを毎回チェックします。形が合わなければ、再試行する、別の処理に回す、担当者に通知する、といった動きを用意します。
こうしておくと、モデルの変更で書式が崩れても、画面に壊れた内容が表示される前に気づけます。AIの出力に紛れ込む「もっともらしい間違い」への対処は、生成AIのハルシネーションが開発に混ざるとき｜見つけ方と防ぎ方でも扱っています。
5. 評価用のテストデータを持っておく
モデル変更への備えで、特に効果が大きいのがこれです。サービスで実際に想定される質問や入力を数十〜数百件ほど集め、「どんな答えなら合格か」の基準とあわせて保管します。モデルを変える前後で同じ入力を流し、結果を比べれば、変更の影響を感覚ではなく材料で判断できます。
評価の項目の決め方は、LLMアプリ開発の精度評価｜開発前に決める5つの項目にまとめています。評価用のデータは、開発の初期から少しずつ貯めておくと、運用に入ってからの財産になります。誰がそのデータを持つのかも、あらかじめ決めておきたい点です。
6. 切り替えと巻き戻しの手順を決めておく
新しいモデルへの切り替えは、全利用者に一度に適用せず、一部の利用者や社内利用から始めると安全です。問題が出たときに元のモデルへ戻せる手順（ロールバック）も、設定の切り替えだけで済むように用意しておきます。ただし、旧モデルが提供終了を迎えてしまうと、戻る先がなくなります。巻き戻しができる期間を意識して、移行の予定を組む必要があります。
運用に入ってから続けること
作る段階の備えがあっても、運用で見ている人がいなければ、変更に気づけません。運用で続けることは、次の3つに絞れます。
提供元の告知を見る担当を決める
使っているモデルの提供終了や仕様変更は、提供元の公式ページや公式ドキュメント、開発者向けのお知らせで告知されます。見る場所と担当者を決めて、定期的に確認する仕組みにします。見落としが起きやすいのは、「誰かが見ているはず」と思われている状態です。
確認した内容は、使っているモデルの名前、終了の予定日、移行先の候補を一覧にして残します。カレンダーに終了日の数か月前の日付を入れておくと、準備に入るきっかけになります。
変更のたびに同じ手順で確かめる
告知があったら、評価用のテストデータで新しいモデルの出来を確かめ、費用と速度を計算し直し、一部の利用者から切り替えます。この手順を毎回同じにしておけば、担当者が変わっても、作業の抜けが起きにくくなります。
新規事業の初期は、事業そのものの仮説が変わることもあります。モデルの変更への対応が、事業の方向転換と重なる場合もあるので、評価の基準自体を見直す機会として使うこともできます。
保守の範囲に含めておく
モデルの変更への対応は、納品後に発生する、避けにくい作業です。誰が、どの範囲まで、どのくらいの頻度で対応するのかは、保守の取り決めに含めておかないと、変更が起きたときに「範囲外」とされて話が止まることがあります。取り決めの確認点は、システム開発の保守契約｜納品後の対応範囲の確認点で整理しています。
システムを納品後も育てていく考え方は、システムは納品後の改善で育てる｜新規事業の考え方で詳しく書いています。AI機能を持つサービスは、ほかのシステムよりも、この「育てる」前提が強く求められます。
発注や相談の前に確認したい4つのこと
外部の開発会社に依頼する場合は、モデル変更への備えが、見積もりや契約の話に出てこないことがあります。事前に、次の4つを確認しておくと安心です。
- モデルの入れ替えを前提にした作りか：モデル名が設定で変えられるか、AIの呼び出しが1か所にまとまっているかを聞く
- 評価用のデータは誰のものか：テストデータと評価の基準が、納品物として自社の手元に残るかを確認する
- 使っているAIのアカウントは誰の名義か：AIの利用契約やAPIキーが誰の名義なのかは、提供終了の連絡を受け取る人にも関わる。名義の考え方はシステム開発のサーバー名義は誰にする？外注前の決め方が参考になる
- 設計の記録が残るか：どのモデルを、なぜ選び、指示文をどう設計したのかが文書に残らないと、数年後の担当者が判断できない。残し方はAI設計書の自動生成は可能？後から困らない残し方で触れている
AIで書かれたコードの引き継ぎや改修の確認点は、AI生成コードの保守は可能か｜引き継ぎと改修の確認点にまとめています。あわせて読むと、依頼先に何を聞けばよいかが見えやすくなります。
また、どのモデルを選ぶか自体も、開発前の大事な判断です。比較の観点はAIシステム開発でのAIの選び方｜2026年10月比較で扱っています。選んだモデルが将来変わる前提で、選び方を考えておくと、決める負担も軽くなります。
まとめ
LLMのモデルは、更新され、いつか提供を終えます。AI機能を持つサービスは、それを前提に作る必要があります。この記事の要点は次の通りです。
- モデルの変更は、出力の質と書式、API仕様、速度と費用、安全性の挙動の4つの面に影響する
- 作る段階で、モデル名の設定化、呼び出しの集約、指示文の分離管理、出力の検証、評価データの保管、切り替え手順の用意を仕込んでおく
- 運用では、告知を見る担当、毎回同じ確認の手順、保守の範囲の取り決めを続ける
- 発注の前に、入れ替えやすい作りか、評価データと名義は誰のものか、記録が残るかを確かめる
新規事業では、AIの応答がそのまま事業の価値になることがあります。モデルが変わっても価値を保つ作りは、あとから足すより、最初の段階で確かめておくほうが負担を抑えられます。
私たちJustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に作り、実物を見てから契約を判断していただく進め方をとっています。納品後も、不具合の修正と毎月ひとつの機能追加を月額で続ける伴走型の支援です。AI機能を軸にした新規事業では、プロトタイプの段階で、モデルを入れ替えたときの挙動を確かめる進め方とも相性がよいと考えています。詳しくはJustFitのサービス紹介をご覧ください。