- 公開日
モデルを変えても残すべきものは、業務の目的、使う材料、守る制約、合格条件です。会話の渡し方や生成設定は別に管理し、新しいモデルに合わせて調整します。応答が崩れたときは、モデル差だけを原因とせず、入力の欠落、設定、実行環境を切り分けたうえで、同じ業務例を使って再評価します。
共通化の狙いは、すべてのモデルに同じ文字列を送ることではありません。何を変えてもよいか、何を変えると業務要件を満たさなくなるかを明らかにし、移植の成否を判断できるようにすることです。
まず業務上の正解をプロンプトから取り出す
架空の会議メモから作業を抽出する業務を考えます。担当者が確認してから作業台帳へ転記し、モデルには登録権限を与えない前提です。入力は次の三文とします。
「製品紹介資料は営業チームが更新する。更新の期限は未定。公開日は次回会議で決める。」
必要な出力項目は、作業、担当、期限、根拠です。この例では、作業は「製品紹介資料の更新」、担当は「営業チーム」、期限はnull、根拠は入力の対応箇所になります。「次回会議」を更新期限にしたり、営業チームから個人名を推測したりすれば不合格です。公開日を決めるという別の記述が、更新作業の期限を裏付けるとは扱いません。
この判断を、モデル名を含まない共通の依頼へまとめます。
「与えられた会議メモから作業、担当、期限、根拠を抽出してください。担当は原文の組織名または個人名を保ち、書かれていない名前を補わないでください。期限の記載がない場合や未定の場合は、期限をnullにしてください。別の予定を作業期限へ読み替えないでください。根拠には入力から対応する記述を引用してください。指定した項目を持つJSONで返してください。」
JSONは項目名と値を組にして扱うデータ形式で、ここでのnullは具体的な値を入れないための表現です。材料と項目名は業務に合わせて差し替えますが、欠落値の扱いと照合基準は、業務側の合意なしに変更しません。例文を使った後も、JSONとして読めるかと、各値が原文に裏付けられるかを別々に確認します。
元のプロンプトに成功例だけが並んでいるなら、そこからも要件を取り出します。例にない日付はどうするか、部署名を担当として認めるかなどを明文化しないまま移すと、旧モデルが偶然補っていた判断まで新モデルへ期待することになります。
共通部分とモデル別の部分を分ける
共通部分には、依頼の目的、入力資料の範囲、用語の意味、禁止事項、出力項目、合格条件を置きます。モデル別の部分には、対応するメッセージの役割、会話テンプレート、構造化出力の指定方法、生成上限や停止条件を置きます。出力項目の意味は共通でも、その形式を指定するAPIの書き方まで共通とは限りません。
会話テンプレートは、役割付きのメッセージをモデルへ渡す系列に整える仕組みです。Hugging FaceのChat templatesは、Transformers v5.19.0の説明として、モデルごとの制御トークンの違いや特殊トークンの重複への注意を示しています。別モデル用の囲みや終了記号を、単なる文章の飾りとして残さないことが確認点になります。
ただし、利用中のサービスが会話形式を処理する場合に、利用者がさらに特殊トークンを追加するとは限りません。対象モデルと接続先の仕様を見て、どの部分をアプリが設定し、どの部分を実行側へ任せるかを決めます。対応が確認できない役割や機能は、使えるものとして比較に入れません。
旧モデルで必要だった例示も、業務上の境界を説明しているなら残します。たとえば「公開日と更新期限を区別する」という例は共通部分に置き、特定の会話記号の使い方はモデル別の部分へ移します。
比較前に入力と実行条件を記録する
最初の比較では、会議メモ、期待する項目、原文との照合方法、合格条件を固定します。検索結果や会話履歴を使う業務なら、それらも保存した同じ内容を使います。新しいモデルにだけ新しい資料を渡して出力が良くなっても、モデルの効果とは切り分けられません。
記録するのは、モデルの識別子と利用可能なら版、プロンプトの版、実際に渡った入力、会話の組み立て方、生成設定、出力、途中で打ち切られたかなどの終了状態です。秘密情報を含む実データを無制限にログへ残すのではなく、この比較では架空データを使います。生成上限の数値が同じでも、入力の分割方式が異なれば同じ量の文章を扱えるとは限らないため、欠落や途中終了も確認します。
vLLMのSupported Modelsは、2026年10月19日に確認した文書で、Hugging Face Transformersとの出力一致を最も厳しい試験段階として扱い、すべての対応モデルがその段階を通過しているとはしていません。また、Transformers側は生成設定ファイルの既定値を適用し、vLLM側は渡したパラメータだけを使うため、比較時にはサンプリングの設定をそろえるよう説明しています。モデル名が同じであることと、同じ実行条件であることは別です。
移植元と移植先で実行器や量子化も変わる場合は、「モデルだけの比較」と呼ばず、構成全体の比較として扱います。原因を詳しく知る必要があるなら、可能な範囲で一つずつ変更します。設定名が同じでも意味や有効範囲が違う場合は、数値の一致だけで条件を揃えたことにしません。揃えられない差は記録し、その差を含む採用判断にとどめます。
API型とローカルLLMで変わる条件
移植先が、外部事業者が運用するAPI型のモデルか、組織内で動かすローカルLLMかによって、記録できる情報と比べられる範囲が変わります。APIはプログラムから機能を呼び出す窓口、ローカルはモデルを動かす場所の性質なので、ローカルLLMをAPI経由で呼ぶ構成もあります。どちらの場合も、入力欄に同じ文章を貼ったことは、モデルへ同じ系列が届いたことを意味しません。
| 比較する箇所 | 記録する内容 | 差があるときの扱い |
|---|---|---|
| モデル | 提供名、版、重みの識別情報、量子化の有無 | 別モデルへの移植か、同一モデルの実行差かを区別する |
| 会話形式 | 指示と資料の役割、テンプレート、応答開始・終了位置 | 役割を失わない変換を用意し、実際の送信内容を照合する |
| 生成条件 | 出力上限、サンプリング、停止条件、利用できる設定 | 同名の設定でも意味と対応範囲を仕様で確認する |
| 実行機能 | 構造化出力、ツール呼出し、入力上限 | 機能を使う比較か、共通機能だけの比較かを明示する |
| 実行基盤 | 実行器の版、計算精度、機器、並列化条件 | 一致させられない差も残し、原因の断定を制限する |
API側で内部テンプレートや正確な重みが開示されていなければ、その欄は未確認のまま残します。ローカル側で詳しく記録できるからといって、API側も同じ条件だと扱うことはできません。比べられるのは、公開された設定と業務上の結果までです。
比較は目的に応じて二段階に分けられます。最初は、両方の環境で共通に使える機能だけで同じ課題を扱い、通常のプロンプトと外部のJSON検査で確かめます。次に、各環境で使うことを認めた構造化出力機能なども含めて、業務構成全体として再評価します。後者で差が出ても、モデルだけの優劣とは言えません。モデル、テンプレート、補助機能をまとめた構成の差です。
移植先が変わると、品質とは別に、データの送信経路も変わります。API型なら利用アプリから送信先、保存先、ログまで、ローカルLLMなら内部サーバーに加えて監視や外部接続まで、実際の構成図と設定で照合します。「ローカル」という名称だけで外部送信がないと判断せず、送信経路が未確認のうちは機密資料を比較に使わないようにします。
形式崩れと条件漏れを分けて直す
次の表は先ほどの入力で起こり得る失敗と確認方法です。実行した結果ではなく、移植時の試験設計として示します。
| 想定する状態 | 最初に照合するもの | 調整と再確認 |
|---|---|---|
| JSONの途中で回答が終わる | 終了状態、出力上限、受信した全文 | 打切りや受信の問題を解消し、同じ入力で形式を再確認する |
| JSONは読めるが期限が「次回会議」になる | 元資料、欠落値の規則、実際に渡った指示 | 指示の欠落を直すか、別予定と期限の区別を明確にし、値の根拠を再確認する |
| 役割や終了の記号が出力に混じる | 対象版の会話テンプレートと組み立て結果 | モデルに合う渡し方へ直し、役割と出力内容を再確認する |
この表だけで原因を確定しません。形式崩れにも、打切り、未対応の機能、モデルの出力、受信処理など複数の候補があります。アプリが受け取った生の応答と、画面や後処理で変換した結果を分けると、プロンプトでは直せない箇所へ無駄な指示を足し続けることを避けられます。
一度に要件、例示、生成設定を変えると、どの修正が効いたか分からなくなります。まず仕様に合わない渡し方や入力欠落を直し、次に必要な説明や例を調整します。複数の修正をまとめて評価する場合は、改善をその組合せの結果として記録し、個々の変更の効果を断定しません。
調整に使った例の外で再評価する
最初の会議メモだけを何度も直して通しても、他の入力への適用は確認できません。調整用とは別に、期限が明記されたメモ、担当が書かれていないメモ、複数の作業があるメモなどを残して評価します。期待値は回答を見る前に原文から決め、判断が割れる入力は担当者が基準を整理します。正解が未確定のものを、都合よく合格に数えません。
同じテンプレート群が要約や問い合わせ分類にも使われるなら、それらの代表例も再度確認します。ある変更によって、以前は通った別の処理が悪化していないか確かめるのが回帰評価です。共通の前処理や出力規則を変えたときは、抽出だけを見て終了しないようにします。
修正前後の比較では、同じ評価入力と判定基準を使い、形式への適合、項目の正しさ、資料にない補完、確認にかかる手間を分けて残します。応答に揺れがある処理は、実際の利用条件に応じて複数回確認し、良い出力だけを選びません。ここで示しているのは評価方法であり、実在モデルの順位や改善率ではありません。
採用と制限と復帰の条件を先に決める
採用は、決めた対象業務と評価範囲で合格条件を満たし、残る誤りを扱う手順がある場合とします。たとえば、期限が不明なときに推測する問題が残るなら、その業務では採用を保留します。別の業務だけ合格しているなら、その範囲へ利用を制限する選択肢はありますが、入力の振分けと担当者の確認を実装できることが条件です。
稼働後にどの異常が見つかったら止めるか、誰が利用制限を判断するか、元の構成へ戻せるかも記録します。プロンプトだけでなく、対応するモデル、設定、会話の組み立て方を一組で保存しておきます。旧モデルの提供終了などで復帰できない場合は、人の確認による処理や別の確認済み構成を代替先として用意します。
移植の記録には、合格した業務、利用を制限する入力、未確認の条件、復帰先を残します。次の変更でもその記録と同じ評価材料を使えば、どこまでを再確認すべきか判断できます。
業務要件からLLMを選ぶ方法は「業務要件とテンプレート運用の安定性でLLMを選ぶ」、条件が変わっても使えるプロンプトへの直し方は「一度うまくいったプロンプトを、条件が変わっても使える依頼へ直す」で解説しています。
国内リージョンの制約でモデルを変えるときのプロンプト互換性試験は「国内リージョン制約でモデルを変えるときのプロンプト互換性試験」、外部ツールの仕様変更後にプロンプトを再評価する手順は「外部ツール仕様変更後にプロンプトを再評価する」で解説しています。
モデルが進化してもプロンプト設計が必要な理由は「モデルが進化すればプロンプト設計は不要になるのか」で解説しています。
