モデルの乗り換えに備える

AI機能を組み込んだシステムには、通常のWebシステムにない前提があります。中核の部品が、自社の判断と関係なく変わるということです。

提供元はモデルを更新し、古いものの提供を終了します。価格は改定されます。規約も変わります。この数年、この頻度は落ち着く気配がありません。作った後に「今のまま動き続ける」ことを前提にすると、いずれ困った形で更新を迫られます。本記事では、乗り換えに備える設計と、乗り換えを判断するときの手順を整理します。

変わるものを具体的に把握する

備えを考える前に、何が変わるのかを具体化しておきます。

• モデルの提供終了：使っているモデルが使えなくなります。通常は事前に告知され、移行期間が設けられます。
• モデルの更新：同じ名前のまま中身が更新されることがあります。出力の傾向が変わる可能性があります。
• 価格の改定：単価が変わります。利用量が多い機能では費用に直結します。
• 性能の改善：新しいモデルが速く、安く、あるいは精度良くなることがあります。これは乗り換えの動機になります。
• 規約の変更：データの扱い、利用できる用途の範囲が変わることがあります。

このうち、事業への影響が大きいのは提供終了と価格改定です。どちらも、対応の期限が自社の都合と無関係に決まります。

差し替えられる作りの要点

対策は難しくありません。要点は一つ、AIサービスを呼び出す処理を一か所にまとめることです。

アプリケーションの各所から直接AIサービスを呼んでいると、乗り換えのときに全箇所を探して直すことになります。間に一枚挟んでおけば、変更はその一か所で済みます。この一枚は、大掛かりな仕組みではなく、数十行の関数で足ります。

その上で、次を設定として外に出しておきます。

これらがコードの中に埋め込まれていると、変更のたびに開発と配信の作業が発生します。設定で変えられれば、確認しながら段階的に切り替えられます。

特定のサービスに固有の機能

差し替えを難しくするのは、特定の提供元にしかない機能に依存している場合です。独自の形式のファイル取り扱い、そのサービス固有の拡張機能、専用の周辺サービスとの連携などが該当します。

これらを使ってはいけない、という話ではありません。便利なものは使えばよいのですが、どこで使っているかを把握しておくことが重要です。把握していれば、乗り換えを検討するときに「この部分は作り直しが必要」と見積もれます。把握していないと、乗り換え作業の途中で想定外の工数が出てきます。

簡単な方法として、固有機能を使っている箇所にコメントで印をつけておく、という運用があります。網羅性は落ちますが、何もないよりはるかにましです。

乗り換えの判断手順

新しいモデルが出たとき、あるいは提供終了の告知が来たとき、どう判断するか。順番を決めておくと迷いません。

自社の入力で比べる。一般的な性能の比較や評判ではなく、自社の実際の入力で出力を並べます。指示文の手入れで用意した入力の組が、そのまま使えます。ここで「当たり前だが最も重要」なことを申し上げると、一般的に高性能とされるモデルが自社の用途で良いとは限りません。特に、現在の指示文が今のモデルに合わせて調整されている場合、乗り換えで挙動が変わることは普通に起きます。

速度と費用を測る。同じ入力での応答時間と、想定利用量での費用を見ます。精度が同等でも速度が倍なら、利用者の体験は変わります。

規約とデータの扱いを確認する。入力内容の保存期間、学習への利用、保存される地域。事業の要件に合うかを確認します。ここが合わなければ、性能が良くても採用できません。

移行の工数を見積もる。固有機能への依存、指示文の調整、確認の作業。この見積もりを含めて、乗り換えの価値と比べます。

切り替えは段階的に

判断が決まったら、全利用者を一度に切り替えないでください。

• 一部の利用者から始める：まず社内、次に一部の利用者、という順で広げます。想定外の挙動があっても影響が限定されます。
• 両方を動かして比べる：しばらくの間、古いモデルと新しいモデルの両方に同じ入力を流し、出力を記録して後から比較する方法もあります。利用者には古い方の結果を返しておけば、影響なく比較できます。費用は二重にかかるため、期間と対象を絞ります。
• 戻せる状態を保つ：設定を戻すだけで元のモデルに戻れる状態を、切り替え後もしばらく維持します。
• 記録を見る：切り替え後、手直しの割合や離脱の割合に変化がないかを確認します。

想定例：ある企業が、新しいモデルが速く安いという理由で全面的に切り替えたとします。数日後、特定の種類の入力で出力の形式が崩れていることに現場から報告がありました。設定を戻すだけで復旧できたため影響は小さく済みましたが、一部から切り替えていれば報告前に気づけた可能性があります。

乗り換えないという選択

最後に、立場をはっきりさせておきます。新しいモデルが出るたびに乗り換える必要はありません。

乗り換えには、確認と調整の作業が毎回発生します。現在のモデルで業務が回っていて、費用も許容範囲で、提供終了の予定もないのであれば、動かさないのが合理的です。乗り換えを検討すべきなのは、次のような場合に限ります。

• 提供終了の告知が来た
• 費用が事業上の負担になっている
• 現在のモデルでは解けない要望が業務側から出ている
• 速度が体験の妨げになっている

備えとして必要なのは、必要になったときに動ける状態であって、常に最新を追うことではありません。呼び出しを一か所にまとめ、設定で切り替えられ、確認用の入力の組があり、戻せる。これだけ整っていれば、告知が来てから対応しても十分に間に合います。

既存のシステムがモデルの変更に耐えられる作りかの確認、乗り換えの判断や移行の設計について、AI活用開発・Webシステム開発としてご相談を承ります。お問い合わせよりご連絡ください。ご相談・お見積りは無料です。

本記事は一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。