AIを乗り換えられる設計 — 費用はどこに出るか

先に結論を書きます。AIのモデルを切り替えられるようにする費用は、「抽象化のための作り込み」ではなく、プロンプトと評価データセット、そして出力形式の検証を誰が持つかに集中します。コードの抽象化層そのものは、既存のライブラリやゲートウェイを使えば比較的小さく収まります。むしろ高くつくのは、切り替えた後に「前と同じ品質か」を確かめる仕組みを持っていない場合です。そして、すべてのモデルに対応する設計は過剰投資になりやすく、中小企業の業務システムでは「2社目に移れる」程度を狙うのが現実的です。

この記事では、何を「切り替え可能」と呼ぶのかの整理から、実装で詰まりやすい箇所、見積書のどの行に費用が乗るのかまでを順に説明します。

1社のサービスに縛られると、何が困るのか？

「いまのモデルで動いているなら、それでいいのでは」という疑問はもっともです。縛られることで実際に困る場面は、主に次の4つに整理できます。

• 料金改定：生成AIのAPI（外部プログラムから機能を呼び出す窓口）の単価は、モデルの世代交代にあわせて上下します。値上げだけでなく、使っていたモデルが新モデルに置き換わり、旧モデルの提供が終わるケースもあります。
• 提供終了（廃止予定の告知）：主要な事業者は旧モデルの提供終了日を事前に案内しますが、猶予期間内に移行作業を終える必要があります。移行できる設計かどうかで、この期間の負荷が変わります。
• 障害・レート制限：単一の事業者で障害が起きると、業務が丸ごと止まります。受発注や問い合わせ対応に組み込んでいる場合、これは業務停止と同義です。
• データの取り扱い条件の変化：入力データの学習利用の可否、保存先リージョン、保持期間といった条件は、規約改定で変わり得ます。社内規程や顧客との契約と合わなくなったときに、動けないのは困ります。

逆に言えば、これらが現時点で問題にならない用途（社内の下書き生成など、止まっても業務が回る範囲）であれば、切り替え可能性に費用をかける優先度は下がります。モデル選定の段階で何を比べるべきかは、AIモデルは性能表より先に3点比べる — 料金・代替・データでも整理しています。

「切り替えられる」とは、どこまでを指すのか？

この言葉は人によって指す範囲が違います。発注側と開発側で認識がずれたまま進むと、「切り替えられると聞いていたのに、作り直しになった」という事態になります。段階を分けて合意しておくのが確実です。

中小企業の業務システムで費用対効果が合いやすいのは段階1から段階2です。段階3は、止まると売上に直結する用途（受注受付、顧客向けチャットなど）に限って検討する領域と考えてよいでしょう。

実装で詰まりやすいのはどこか？

「APIを呼ぶ部分を共通化すれば終わり」ではありません。実際に切り替えを試すと、次のような箇所で止まります。

出力形式の揺れ

業務システムでは、AIの出力をそのまま人が読むのではなく、データベースに入れたり次の処理に渡したりします。このときJSON（データを構造化して受け渡す書式）などの決まった形で返してもらう必要がありますが、形式を厳密に守らせる機能の名称も仕様も事業者ごとに違います。片方では確実に守られていた形が、もう片方では前置きの文章が付いてくる、といったことが起きます。出力を受け取る側で検証し、崩れていたら再試行する処理を最初から入れておくと、この差に強くなります。

埋め込みモデルの非互換

社内文書検索などで使う「埋め込み」（文章を数値の並びに変換して類似度を測る仕組み）は、モデルが違うと数値の並びの長さも意味も異なります。埋め込みモデルを変えると、保存済みのデータは原則すべて作り直し（再インデックス）になります。文書量が多い場合、これが切り替え費用の大半を占めることもあります。生成に使うモデルと埋め込みに使うモデルを別々に選べる構成にしておくと、片方だけ据え置くという判断ができます。

ツール呼び出しの仕様差

AIに社内システムの関数を呼ばせる機能（ツール呼び出し、function callingなどと呼ばれます）は、指定の書き方も、複数を同時に呼べるかも、事業者ごとに差があります。ここを多用している設計ほど、切り替えの手間が増えます。

プロンプトの効き方の違い

同じ指示文でも、モデルが変わると従い方が変わります。長い指示の末尾を無視する、禁止事項を守る度合いが違う、といった差です。指示文はコードに埋め込まず、外部ファイルやデータベースで管理し、モデルごとに差し替えられるようにしておくのが基本です。

安全フィルタと拒否の挙動

事業者ごとに、入力や出力をブロックする基準が異なります。業務上まったく問題のない内容が弾かれることもあります。切り替え後に「特定の取引先名が入ると応答が返らない」といった形で表面化するため、実データでの試験が欠かせません。

トークン数と料金単位

文章を区切る単位（トークン）の数え方はモデルによって異なり、同じ日本語文でも数が変わります。入力と出力で単価が違う点、画像や音声の扱いが別単価になる点も含めて、乗り換え後の月額を事前に試算できる形にしておくと判断が速くなります。

費用はどこに発生するのか？

見積書を見るときは、「切り替え対応費」という一行ではなく、次のどこに費用が乗っているかを確認してください。

このうち最も後回しにされやすく、最も影響が大きいのが評価データセットです。これが無いと、切り替えた後の良し悪しを「使ってみた感じ」で判断することになり、結局「元に戻す」という最も高くつく選択をすることになります。作り方はAI の「良くなった気がする」を卒業する — 評価データセットの作り方と運用で詳しく扱っています。

どこまでやるかは、何で決める？

判断材料は、技術ではなく業務側にあります。次の3つを先に決めると、設計の深さが決まります。

1. 止まったときの影響：30分止まると困るのか、1日止まっても代替手段があるのか。前者なら段階3、後者なら段階1で足ります。
2. データの機微度：個人情報や取引先の非公開情報を入力するなら、規約変更時に動ける余地を残す価値が高まります。個人情報保護法や、国が示すAI事業者ガイドラインの考え方に照らして、自社の取扱いが説明できる状態かを確認しておきます。
3. 利用量の伸び：使う量が増えるほど、単価差が効いてきます。月額が小さいうちは乗り換え動機も小さく、過剰な作り込みは回収できません。

なお、切り替え可能性は契約面でも押さえる論点です。プロンプトや評価データ、学習に使った資料の権利が誰に帰属するかが曖昧だと、開発会社を変えた瞬間に資産が持ち出せません。この点はAI開発の契約前に決める3論点 — 精度・データ・権利で整理しています。

たとえば次のような場面です。見積書の要約に生成AIを使っている会社で、使用中のモデルが提供終了になると告知された。呼び出し部分は1か所にまとまっていたので接続先の変更自体は半日で済んだが、期待する出力を記録したデータが無く、「新しいモデルの要約が前より良いのか悪いのか」を誰も判断できない——こうした詰まり方は、技術の問題ではなく準備の問題です。

まとめ

AIのモデルを切り替えられるようにする設計で、本当に効くのは次の点です。

• 呼び出し箇所を1か所にまとめる。全事業者対応ではなく、2社目に移れることを目標にする
• プロンプトをコードから外に出す。モデルごとに差し替えられる形で管理する
• 出力の形を決めて検証する。崩れたら再試行する処理を初期から入れる
• 評価データセットを先に作る。切り替えの可否を判断できるのはこれだけ
• 埋め込みモデルは生成モデルと切り離す。再インデックスの費用を避ける
• プロンプトと評価データの権利を契約で明確にする

「1社に縛られない」は、技術的な自由度の話に見えて、実際は自社が品質を判断できる材料を持っているかという話です。材料さえ手元にあれば、抽象化の作り込みは必要最小限で足ります。発注時には「切り替えられますか」ではなく、「切り替えた後、良し悪しをどう判断しますか」と聞いてみてください。