八千代ソリューションズの岩片です。
皆さんは生成AIというものをご存知でしょうか。当社のMENTENAというクラウドサービスでは内部でOpenAIのAPIを使い生成AIモデルを呼び出しています。
【例：作業依頼文面の添削をする機能】
【（隠し機能・大阪のおばちゃんモード）】
AIモデルはうつろう
この機能はシンプルなテキスト処理のみなのでAIモデルはGPT-4o miniを採用しました。
2024年7月に登場したホヤホヤのモデルです。
そんなGPT-4o miniですが、なんと・・・
$\huge{💀2025年8月にモデル廃止💀}$ となりそうです。
抜粋元：https://learn.microsoft.com/ja-jp/azure/ai-services/openai/concepts/model-retirements （2025/5/15時点）
目まぐるしく新モデルが登場している昨今ですので、旧モデルの廃止も早いですね。
うっかり放置すると該当機能が使用不能になってしまうので、AIモデルを使う際は当面 年に1，2回ほど乗り換えが必要 という前提で準備をするのがよさそうです。
ということで以下、モデル乗り換え関連の備忘録的情報や当社が得た知見などをまとめました。
主な公式ドキュメント
情報収集はこの辺りを巡回するのが安定です。
Azure OpenAI
OpenAI Docs
モデルリリースノート(ChatGPT側の情報も混在）
開発者コミュニティ
乗り換えモデルの選定に必要なテスト観点
モデル切り替えで従来と同等以上の動作をすると担保するにはどうしたらいいでしょうか。
単純な性能スコアだけで比較すると、応答速度やコンテキスト長の違いによる体験の劣化を招く可能性もあります。
振る舞い駆動開発（BDD）を取り込む
生成AIのテストは振る舞いベースで「こういう入力を行ったら、こういう出力になる」というケースで評価するのが有効です。
運用が安定するまでは人力でやるのがいいと思いますが、自動化も（AIの出力結果をAIに評価させる）やればできそうです。SHIFTさんがかなり早期（2023年）にブログも書いています。
ふわっとした「良い回答」を言語化する
評価時は単に論理として正しい/正しくないではなく、「文脈に沿っている」「口調がカジュアル過ぎない」などの観点を用意します（そうしないと「なんか嫌な出力結果だな」と思いつつテストは通過、ということになります）。
「良い回答」を要件として整理するのは難しいですが、開発中にチューニングを試行錯誤するときに山ほど「悪い回答」が出てくるので、これを拾い集めておくのがいいでしょう。
この中で「応答時間が長すぎない」なども観点に出てくると思うので、具体的な目標値を適宜設定します。
過去のテスト結果は出力内容まで蓄積しておく
「なんとなく生成結果が良くない」と思ってた際に比較できる対象が必要です。
過去のテストでの出力を記録しておけば違和感の出どころを突合せで探しやすくなり、その後プロンプト調整を行ったときにも新旧比較がしやすくなります。
開発のオススメポイント
当初モデルでの妥協点を記録しておく
モデル選定時、使おうと試みたがあまりうまくいかず「割り切り」とする部分は必ず出てきます。
例えば4o-miniでは「今日」や時間軸の概念が苦手なようで、他の方の記事でも以下のようなものが出ています。
当社の場合「依頼期日があったら文脈から妥当か判定する」といったプロンプトを4o-miniに指示したところ、常に何かイチャモンを付けられる挙動になってしまいました。同じ文面でも試行ごとに「日付が先過ぎます」「日付が近すぎます」がランダムに出てくるような状態でした。
この辺りの妥協ポイントはモデル乗り換え時に解消する可能性があるので、再評価できる運用にするのがいいでしょう。
モデル情報をハードコーディングをしない
切り替え/切り戻しや、新旧モデルの挙動比較を簡単に行えるようにしましょう。
以下のDocsのサンプルにあるようにモデル名をベタ書きしてももちろん動きますが、これではモデル切り替え時にいちいちマージやデプロイが必要になります。
// 抜粋元Docs：https://platform.openai.com/docs/guides/text
import OpenAI from "openai";
const client = new OpenAI();
const completion = await client.chat.completions.create({
model: "gpt-4.1", // ←ここ
messages: [
{
role: "user",
content: "Write a one-sentence bedtime story about a unicorn.",
},
],
});
モデル情報は設定ファイルなどに疎に持っておき、インスタンス再起動などをせずに切り替えられる方法がいいでしょう。アクセス頻度がそれほどでもなければDBに持ってしまうのも簡単でいいかもしれません。
また場合によってはフィーチャーフラグによる切り替えなどの併用も有効そうです。
以上、雑多にまとめましたが数年後にはまったく違ったベストプラクティスが出ている可能性もあります。引き続き勉強していきます。
＜＜お知らせ＞＞
MENTENAの新機能情報などはnoteで発信しています。
お客様のインタビュー動画もぜひご覧ください。