AIモデル・ベンダーの乗り換えに備える設計｜疎結合の作り方
「ご利用中のモデルは、この日をもって提供を終了します」——そんなお知らせに気づいた瞬間、少しひやりとしますよね。動いているのに、こちらの都合とは関係なく期限が来る。しかも、直す場所がどこまで広がるのか、その場ではすぐに分からない。
この落ち着かなさは、あなたの設計が雑だったからではありません。AIの組み込みは、土台の側が数か月〜1年単位で入れ替わるという、これまでの外部連携とは少し違う性質を持っています。だから「壊れないように作る」より、「入れ替えやすいように作る」方が現実に合っています。この記事では、いま何が起きているのかを共有したうえで、明日ひとつ試せる形で、乗り換えに備える組み込みの型を整理します。全部を作り直す話ではありません。効くところから一つずつでいきましょう。
結論：AIモデル・ベンダーの乗り換えは「起きるかもしれないこと」ではなく、いつか来る前提で設計しておくのが安全です。やることは3つだけ。①呼び出しの窓口を一つにまとめる（AIのSDKを直接呼ぶ場所をアプリ中に散らさず、薄いラッパー1か所に寄せる）。②プロンプトと「合格例」をコードの外に出す（差し替えたときに、同じ入力で品質を比べられる状態にしておく）。③モデル固有の機能への依存は、意識して選ぶ（使うなとは言いません。使うなら「ここは乗り換え時に直す場所」と分かるようにしておく）。この3つがあるだけで、乗り換えは「全機能の改修」から「1か所の差し替えと確認」に変わります。
いきなり全部は要りません。 まずは「いま、AIを呼んでいる場所がコードの何か所あるか」を数えるところから始めましょう。
何が起きているのか——土台の方が先に動く
まず、なぜここだけ気を張る必要があるのかを共有させてください。理由は3つあります。
1つ目は、モデルには寿命があること。主要な提供元は、新しいモデルを出すと同時に、古いモデルの提供終了（deprecation／retirement）の予定を公開します。告知はきちんと出ますが、こちらの開発計画に合わせてくれるわけではありません。「安定して動いているから触らない」という判断が、そのまま期限つきになる——これが、従来のライブラリ依存とはっきり違うところです。
2つ目は、提供元ごとにAPIの作りが違うこと。モデルを呼び出す窓口（API＝プログラムから機能を呼び出すための入口）は、提供元によってパラメータの名前、構造化した出力の指定方法、ツール呼び出しの書き方、レート制限（一定時間に呼べる回数の上限）の考え方、料金の数え方がそれぞれ違います。同じ「AIに聞く」でも、乗り換えると呼び出しコードの書き換えが要る、ということです。
3つ目は、出力の“クセ”まで含めて依存してしまいがちなこと。ここが一番見えにくい。動かしているうちに、プロンプトはそのモデルに合わせて少しずつ調整されていきます。出力の言い回しに合わせたパース処理も入ります。すると、コードは通っているのに、モデルを替えた瞬間に品質だけが静かに落ちるということが起きます。これは型チェックでもコンパイルでも見つかりません。
この3つが重なると、乗り換えは「1行モデル名を変えるだけ」では終わらなくなります。逆に言えば、この3つに対応する備えを先に置いておけば、乗り換えは怖くなくなるということです。
具体例——こんなふうに、乗り換えが重くなる
実際に「重い」と感じるのは、だいたい次のような状態のときです。一つでも心当たりがあれば、この記事はそのまま使えます。
- SDKの直呼びが散らばっている：機能を追加するたびに、その場でAIのSDKを読み込んで呼び出していた。改めて検索してみると、呼び出し箇所が20か所を超えていた。どれも数行なのに、全部に手を入れる必要が出てくる。
- プロンプトがコードの中に埋まっている：長い指示文が、あちこちのファイルに文字列としてそのまま書かれている。どれが今使われているのか、どこを直せば全体に効くのかが分からない。
- 出力の言い回しに依存している：返ってきた文章から「はい」「いいえ」や特定の見出しを目印に切り出している。モデルを替えると言い回しが変わり、パースだけが黙って失敗する。
- モデル固有の機能に乗っている：特定のモデルにしかない出力形式の指定や、独自のファイル・画像の扱い方を前提に組んでいる。乗り換え先に同じものがなく、その機能ごと設計をやり直すことになる。
- 比べる材料がない：新しいモデルを試したいが、「前より良くなったか」を確かめる手段が、担当者が手で何回か叩いてみる以外にない。結果、判断がつかず先送りになる。
どれも、手を抜いた結果ではありません。目の前の機能を早く動かすには、その書き方がいちばん素直だからです。問題は、それが積み上がったときに、後から通しで直しにくくなること。ここを少しだけ設計で受け止めます。
影響——「猶予はあるのに、間に合わない」が起きる
提供終了の告知には、たいてい移行までの猶予期間があります。それでも現場が苦しくなるのは、次の3つが重なるからです。
- 改修範囲がすぐに読めない：呼び出しが散らばっていると、まず「どこを直すか」を数える調査から始まります。見積もりが出せないので、他の案件との調整も後ろにずれます。
- 期限が他の仕事と重なる：移行は、こちらの繁忙期を避けてはくれません。リリースや決算対応と重なると、品質確認をいちばん削りたくないところで削ることになります。
- 良し悪しを判断できないまま切り替える：比べる材料がないと、「動いたからヨシ」で本番に出すしかありません。あとから「前のモデルの方が良かった気がする」と言われても、確かめる術がない状態です。
そして、これは乗り換えのときだけの話ではありません。同じ備えは、もっと安いモデルに落とす／速いモデルに替える／障害時に別の提供元へ逃がすといった、前向きな選択肢もそのまま手に入れることになります。備えは、守りだけではなく選べる状態をつくる投資です。コストの見立てはAI APIの料金とレート制限を見積もる｜本番前の型、障害時の逃がし方はAI出力が不安定なときのフォールバック設計｜リトライの型も合わせてどうぞ。
明日からやること（乗り換えに備える3ステップ）
大がかりなリファクタリングは要りません。この順番で、小さく進められます。
- 呼び出し口を数えて、窓口を一つにする：まず、AIのSDKやHTTP呼び出しを使っている箇所を検索して数えます（数えるだけなら10分で終わります）。そのうえで、アプリから見た窓口を一つの薄い関数・クラスにまとめます。中身は最初、いま動いているコードをそのまま移すだけで十分です。大事なのは「AIを呼ぶなら、必ずここを通る」という状態を作ること。全部を一度に移さなくても、新しく書く分から窓口経由にするだけでも、散らばりはそれ以上増えません。設計の切り方に迷ったらAIのアーキテクチャ案を鵜呑みにしない｜比較の型の進め方も使えます。
- プロンプトと「合格例」をコードの外に出す：プロンプトは、コードに埋め込まずに別ファイルや設定として持ちます。あわせて、実際の入力と「これなら合格」という出力の例を10件ほど、テキストで残しておきます。これが乗り換えたときの物差しになります。10件は少なく見えますが、「明らかに壊れている」を捕まえるには十分効きます。プロンプト自体の管理は本番プロンプトのバージョン管理｜変更で壊さない運用の始め方、出力形式を安定させる工夫はAIの構造化出力（JSON）を安定させるが下敷きになります。
- 差し替えスイッチを付けて、一度だけ別モデルを通す：使うモデル名・提供元を設定（環境変数など）で切り替えられるようにします。そして本番ではなく手元で構いませんので、別のモデルで一度だけ、②で用意した10件を流してみます。ここで初めて、「どこがモデル固有の作りに依存していたか」が具体的に見えます。この一度の素振りが、いちばん効きます。結果がばらつくときはAIの回答が日によって変わる｜再現性のなさと付き合う型も参考にしてください。
補足として、複数の提供元を1つの書き方で扱える抽象化ライブラリもあります。便利ですが、依存が一つ増えるという面もあるので、自作の薄いラッパーで足りる規模なら無理に入れなくて大丈夫です。どちらを選んでも、「窓口が一つある」という状態が本体です。
3つとも、今日全部やる必要はありません。1だけでも、次の告知が来たときの調査時間がはっきり短くなります。
乗り換えに備えるチェックリスト
いまの組み込みが「入れ替えやすい状態」かを見る確認項目です。全部に○が要るわけではなく、気になった行だけで十分です。
① 窓口はまとまっているか
- AIを呼び出している箇所が、いま何か所あるか把握できているか
- アプリ側から見て、AIを呼ぶ入口が一つにまとまっているか
- 提供元のSDK特有の型や例外が、アプリ全体にそのまま漏れ出していないか
- モデル名・提供元が、コードではなく設定で切り替えられるか
② 比べる材料はあるか
- プロンプトがコードの外（ファイル・設定）に出ているか
- 「この入力ならこの出力で合格」という例が、10件ほど残っているか
- 出力を機械的に確認できる形（JSONなど）で受け取っているか
- 応答時間・エラー率・利用量が記録されていて、前後で比べられるか
③ 固有依存を把握しているか
- モデル固有の機能に乗っている箇所が、どこかを言えるか
- 出力の言い回しを目印にしたパース処理が残っていないか
- 提供終了の告知を受け取る窓口（担当者・メール・通知先）が決まっているか
- 利用規約やデータの取り扱いを、乗り換え先でも確認する手順があるか（AI利用前に規約・コンプライアンスで確認する項目）
この記事のまとめ
AIの組み込みで少し特殊なのは、土台であるモデルの方が先に動くことです。だから設計の目標は「壊れない」ではなく、「入れ替えやすい」に置きます。やることは、①呼び出しの窓口を一つにまとめる／②プロンプトと合格例を外に出す／③固有依存を把握して、差し替えスイッチで一度素振りする——この3つだけです。
この備えがあると、提供終了の告知は「困った知らせ」から「予定していた作業」に変わります。そして同じ準備が、安いモデルへの切り替えも、速いモデルへの乗り換えも、そのまま可能にしてくれます。
全部を今日やらなくて大丈夫です。まずはAIを呼んでいる場所を検索して、数を数える。それだけで、次に告知が来たときのあなたは、だいぶ楽になっています。
動いているものに手を入れるのは、いつだって勇気が要ります。それでも「次に替わるときのために」と一か所まとめておけるのは、今日の仕事の先を見ているからです。その視線は、確かにチームを助けています。