AIモデルが変わっても業務を止めないための設計

AIモデルやその新しいバージョンは継続的に発表され、性能も価格も提供条件も変わっていきます。

これまで扱いにくかった業務が扱えるようになったり、同じ処理をより低い費用で回せるようになったりすることは、導入した会社にとって歓迎すべき変化です。

一方で、使うモデルを変えるたびに、プロンプトだけでなく、出力を受け取る後続の工程、承認の手順、参照情報の渡し方まで調整が必要になる場合があります。

問題は、モデルが変わること自体ではありません。

変更のたびに、業務の側を大きく作り直さなければならない構成になっていることです。

本稿では、モデルを中心に決めてよい段階と、変更に耐える構成へ移したほうがよい段階を分けたうえで、何を共通のものとして持ち、何をモデル固有の設定として管理するかを整理します。

個々のモデルの優劣の比較や、特定製品の設定手順は対象にしていません。

モデルは、導入したあとも変わり続ける依存関係

AI導入の相談では、「どのモデルを使うべきか」が最初の論点になることがよくあります。

性能の比較記事を読み、価格を並べ、実際に触って感触を確かめる。

出発点としては自然な進め方です。

ただ、選んだモデルは、選んだ時点の姿のまま留まってくれるわけではありません。

Microsoft が Azure Architecture Center で公開しているガイダンス「Design to Support Foundation Model Life Cycles」では、基盤モデルはコードのライブラリなどと同じくバージョンを持つ依存関係であり、それぞれにライフサイクルがあるものとして設計すべきだと説明されています。

同じ指針では、更新の幅は小さな版の差からモデル系列そのものの入れ替えまで大きく異なるとされ、世代をまたぐような更新では、プロンプトの調整にとどまらず実装の考え方自体を組み直す必要が生じうるとも書かれています。

提供終了についても、提供元が方針を明文化している例があります。

Anthropic の開発者向けドキュメント「Model deprecations」では、より安全で高性能なモデルの登場に合わせて古いモデルを定期的に提供終了しており、依存するアプリケーションには更新が必要になる場合があると説明されています。

公開済みモデルについては、そのモデルを利用中の顧客に対して、提供終了の少なくとも60日前に通知するとされています（2026年8月確認時点）。

提供終了日を過ぎたモデルへのリクエストは失敗するとも明記されています。

ここまでが、提供元やプラットフォーム側が公開しているガイダンスの範囲です。

ここから先は私たちの見方になりますが、この前提を置くと、導入時の問いは一つ増えます。

「今いちばん良いモデルはどれか」に加えて、「このモデルが変わったとき、自社の業務はどこまで影響を受けるか」を早い段階で見ておく、という問いです。

試している段階は、モデルを中心に進めてよい

モデル選びに力を入れるのが誤り、という話ではありません。

検証段階や、影響範囲が一つのタスクに閉じている用途では、「今いちばん良いものを選ぶ」という進め方はそのまま合理的です。

入出力が限られた単発の用途であれば、モデルを変更したときに確認し直す範囲も比較的小さく済みます。

小さく試して結果を見る、良ければ次のモデルが出たときにまた小さく試す。

このサイクルが回っている間は、モデル選びを中心に進めても大きな問題になりにくいでしょう。

むしろ、要件が固まらないうちに凝った仕組みを作り込むと、決まっていない前提に合わせて何度も設計をやり直すことになり、遠回りになりがちです。

業務に組み込むと、変更の影響が外側へ広がる

考え方を変える必要が出てくるのは、その仕組みが日々の業務として定着し、複数の人・複数の工程にまたがった時点です。

たとえば、問い合わせ対応の下書き作成にモデルを使い、その出力を承認フローに流し、対応履歴をナレッジベースへ書き戻す、という一続きの仕組みができあがっているとします。

ここでモデルを入れ替えると、出力の口調や粒度が変わり、承認する側の基準が揺らぎ、書き戻す形式が微妙に食い違う、といった具合に、影響がモデルの外側へ広がっていきます。

ここで押さえておきたいのは、入れ替えの負担が大きくなる原因です。

負担が増えるのは、モデルを丁寧に選んだからではありません。

増えるのは、選んだモデル固有の出力の癖やAPI、プロンプトの言い回しを前提に、後続の業務まで直接組み込んだ場合です。

特定モデルに合わせた調整が広い範囲へ埋め込まれるほど、次の変更時に確認し直す箇所も増えていきます。

丁寧に比較して選びながら、同時に変更しやすい構成にしておくことは両立できます。

なお、特定モデルへの依存は、人に業務知識が集中した属人化と同じものではありません。

属人化の原因は暗黙知や引き継ぎ不足であり、モデルへの依存の原因はAPI仕様や出力傾向、提供条件の変化です。

原因が違えば対策も違います。

ただし、一つの構成要素が変わるだけで業務の広い範囲に影響が及びうるという点では、構造上似た問題を抱えます。

私たちが関わる範囲でも、モデル変更の影響がプロンプトだけにとどまらず、承認やデータ連携まで広がる例があります。

「差し替えられる」は、無調整で交換できるという意味ではない

こう書くと、モデルを共通規格の部品のように扱えばよい、と読めるかもしれません。

ただ、モデルは、どれも同じ形をした部品ではありません。

提供元やモデルによって、次のような点が異なります。

• APIと認証の方式
• 構造化された出力をどこまで保証するか
• ツール呼び出しの仕様
• 扱えるコンテキストの長さ
• 推論時に指定できるパラメータ
• 安全機能と、要求を断るときの挙動
• レート制限、速度、費用
• ファイル・画像・音声への対応
• データの保管場所や提供地域

Microsoft のガイダンス「Choose the Right AI Model for Your Workload」でも、特定ベンダーへの固定化（ロックイン）を避けるために抽象化の層を置くことを勧める一方、モデルは並行してテストし、出力を比較することが挙げられています。

抽象化を入れれば検証が要らなくなる、という話ではありません。

そこで私たちは、すべての差をなくしにいくかわりに、モデル固有のAPI・プロンプト・ツール定義・出力の変換を一つの層へまとめ、業務ルールや後続工程の内部へ広げないようにしています。

モデル変更時の作業をゼロにするのではなく、変更が必要な範囲を限定する、という考え方です。

共通化するもの、モデル固有のまま残すもの

では、何を共通のものとして持ち、何をモデルごとに調整するのか。

私たちは三つの層に分けて考えています。

一つ目は、モデルから分離しやすい業務ルールです。

業務の目的、合格条件、承認者と承認の時点、実行してよい操作の範囲、参照してよい情報、記録と停止と復旧の方法が含まれます。

二つ目は、モデルと後続工程の間に置く共通の契約です。

入力項目、出力のスキーマ、必須項目、エラーの返し方、人へ引き継ぐ条件がここに入ります。

後続の工程がAIの自由文を直接読み取るのではなく、共通の項目を持つ形式を介して受け取るようにしておくと、モデルごとの差はこの変換の層で吸収できます。

三つ目は、モデルごとに調整する部分です。

システムプロンプト、ツール定義、推論パラメータ、コンテキストの渡し方、出力の補正、そのモデルに出やすい失敗への対策が含まれます。

プロンプトまで完全に共通化する必要はありません。

重要なのは、モデル固有の調整が承認フローや後続システムの内部へ散らばらないようにすることです。

私たち自身、記事づくりの一部をAIに任せる仕組みを運用していますが、そこでは生成後に問題を検出して直す工程と、その修正結果を再検証する工程の二段階を置いています。

確認の順序と合格条件は共通のものとして持ち、モデルごとに異なる失敗の傾向や指示の書き方は、個別の設定として調整しています。

自社の業務を当てはめる際の下敷きとして、この分け方を一覧にしておきます。

すべてをモデルから切り離せるわけではありません。

業務上変えたくない条件と、モデルごとに調整する部分を分け、変更時に確認する範囲を明確にすることが目的です。

以下は正しい配分を示すものではなく、自社の業務に置き換えて埋めるための一例です。

粒度も優先順位も、業務の性質やリスク許容度に応じて各社が決めるべきものです。

設計項目	原則として共通化する内容	モデル変更時に再確認する内容
業務の目的と合格条件	何を完成とし、何を失敗とするか	新しいモデルが同じ条件を満たすか
入出力の契約	必須入力、出力スキーマ、エラー形式	構造化出力の遵守率、解析の方法
ナレッジ	正式な参照元、アクセス範囲、更新責任	検索結果の渡し方、文量、引用の精度
承認と実行権限	誰が何を承認し、どの操作を許可するか	承認・停止の条件をモデルが守るか
プロンプトとツール定義	共通の目的・禁止事項	モデル固有の指示、ツール仕様、パラメータ
評価	共通の実例、評価指標、合格ライン	品質、速度、費用、安定性の比較結果
記録と復旧	実行履歴、停止条件、旧構成への戻し方	ログ形式、モデル識別子、切替の手順

変更のときに要るのは、評価と段階切替と戻り道

差し替えやすさは、接続先を切り替えられることだけでは決まりません。

新しいモデルが現在の業務で必要な品質を満たすかを同じ条件で比較でき、問題があれば元の構成へ戻せることまで含めて、初めて変更に耐える構成になります。

そのためには、代表的な入力例、期待する結果、許容できない失敗、処理時間や費用の基準を、モデルとは別に持っておく必要があります。

モデルを変更するときは、その評価セットで新旧を比較し、限定した範囲から切り替えます。

先のガイダンス「Design to Support Foundation Model Life Cycles」でも、モデル・プロンプト・設定・処理の流れを組み立てる部分に加えて、根拠となる情報を検索して渡す仕組み（情報検索の構成）の変更も、本番に出す前にテストし、検証済みの組み合わせは本番でも組にしたまま動かすことが挙げられています。

テストの機会がないまま自動でモデルが更新される機能に任せきりにしないこと、挙動をどのモデル・プロンプト・設定・情報検索の構成と結び付けられるよう、観測とログに十分な情報を残すことも挙げられています。

ガイダンスが示すのはここまでで、どの業務からどの範囲で切り替えるかは各社の判断になります。

私たちの場合は、取り消しやすい工程から先に切り替え、影響の大きい工程は、新しい構成が評価を通るまで旧構成を戻り先として残す、という順序を取っています。

この戻り道とは別に、公開前に人が最終確認を通す経路も残しています。

こちらはロールバックの経路とは別の位置づけで、新しい構成を評価している間の追加的な安全策にあたります。

すべてを交換可能にする必要はない

ここまでの話に対しては、交換可能性を高めること自体にも費用がかかる、という指摘があり得ます。

これはもっともな指摘です。

複数のAPIへ対応する層を作り、モデルごとの設定を管理し、共通の評価を回すには、開発と運用の負担が増えます。

各モデルを同じ共通仕様へ揃えすぎると、特定のモデルだけが持つ機能や性能を十分に使えなくなる可能性もあります。

したがって、すべてのAI利用を完全にベンダー非依存にする必要はありません。

単発の試行、影響範囲の小さい社内作業、特定モデル固有の機能が価値の中心になる用途では、モデルへ直接つなぐ設計が合理的な場合があります。

一方、複数部署が利用し、外部への送信やデータ更新を伴い、止まると業務への影響が大きい仕組みでは、変更時の影響を限定しておく価値が高くなります。

重要なのは依存をゼロにすることではなく、どこで特定モデルに依存しているかを把握し、その依存を意図的に選ぶことです。

最初に確認するのは、モデル名が埋め込まれている場所

読み終えたら、まず一つのAI業務を選んで、次の箇所を書き出してみてください。

• モデル名やベンダー固有のAPIが、どこに直接書かれているか
• 出力の形式を、後続の工程がどのように受け取っているか
• 現在の品質を測る代表例と合格条件があるか
• モデルを変更した場合に、どの工程を再検証する必要があるか
• 問題が起きた場合に、旧モデルまたは人手の運用へ戻せるか

一つ目については、提供元がその確認を助ける手段を用意していることもあります。

Anthropic の開発者向けドキュメント「Model deprecations」では、Claude Console の利用状況のページから API の利用実績を書き出し、APIキー別・モデル別に確認することで、提供終了予定のモデルを使い続けているアプリケーションを特定する手順が案内されています。

すべてをすぐに作り直す必要はありません。

まず、変更時の影響がどこまで広がるかを把握するだけでも、次のモデル選定は「一から業務を作り直す作業」ではなく、「既存の業務条件に合う候補を比較する作業」に近づきます。

モデルの変更に強い設計とは、モデル変更を無調整にすることではなく、変更の影響を限定し、業務を作り直さずに評価・移行・復旧できるようにすることだと私たちは考えています。

情報確認について

本記事は2026年8月6日確認時点で、Microsoft の Azure Architecture Center のガイダンス「Design to Support Foundation Model Life Cycles」および「Choose the Right AI Model for Your Workload」、Anthropic の開発者向けドキュメント「Model deprecations」を主要な参照元として作成しています。

Anthropic の通知期間は、公開済みモデルと、そのモデルを利用中の顧客に適用されるものです。

また、公開されている提供終了日は Anthropic が運営するプラットフォームに適用され、パートナーが運営するプラットフォームでは提供終了の日程が異なる場合があります。

各社のガイダンスの内容、モデルの提供条件、提供終了の予告期間や手順は変更される可能性があります。

設計の判断に用いる際は、各提供元の最新の公式情報をご確認ください。

なお、三つの層（業務ルール／共通の契約／モデル固有の設定）への切り分けと、自社の記事制作の運用例は、私たち MIF の分析・運用方針です。