はじめに——なぜ「モデル変更」を前提にすべきか
LLM（大規模言語モデル）の進化は速く、より高性能なモデルへの移行は避けられません。主要な提供元はそれぞれ数か月おきに新しいモデルを出しており、同じ系列のモデルでも版が変わると振る舞いが変わります。
しかし、モデルを変更すると、周辺のハーネス（プロンプト生成・出力処理）やデータベース（ベクトルDB・メモリ管理）に影響が出ることがあります。具体的には、以下のような問題が発生します。
- プロンプトへの従い方が変わる: 同じプロンプトでも、指示の守り方や出力の形式（JSONの崩れ方など）が変わる
- 出力の文体が変わる: 内容は正しいのに、雰囲気や文章スタイルが意図と異なる
- ベクトルの次元が変わる: 埋め込みモデルが変わると、ベクトルDBのスキーマや検索ロジックに影響が出る
「モデルは変更されない」ことを前提にした設計は、モデルが変わるたびにシステム全体の再構築を強いられます。本記事では、「モデルが変更されることを前提とした設計」 について、レジリエンス（回復力・耐性）を確保する観点から解説します。
モデル非依存（Model-Agnostic）設計の原則
モデルが変わっても周辺システムが壊れないようにするためには、モデルを「差し替え可能な部品」として扱う設計が重要です。これは、家電製品のコンセントのようなイメージです。コンセントの形状（インターフェース）が統一されていれば、どんな家電（モデル）でも差し替えるだけで使えます。
抽象化レイヤーの導入
モデルを直接呼び出すのではなく、モデルを呼び出すための「抽象インターフェース」を定義し、実装を分離します。
具体例:
# 抽象インターフェース（モデルに依存しない）
class LLMInterface:
def generate(self, prompt: str) -> str:
raise NotImplementedError
# 具体的なモデルの実装
class GPT4Model(LLMInterface):
def generate(self, prompt: str) -> str:
# GPT-4を呼び出すコード
pass
class ClaudeModel(LLMInterface):
def generate(self, prompt: str) -> str:
# Claudeを呼び出すコード
pass
# 利用側はインターフェースだけに依存
model: LLMInterface = get_model() # 設定で切り替え
result = model.generate(prompt)このように設計すると、モデルを変更しても、ハーネス側（プロンプト生成部や出力処理部）のコード修正を最小限に抑えられます。
宣言的パイプライン（LCEL / LangGraph）
LangChainのLCEL（LangChain Expression Language）やLangGraphのような、処理の連鎖をパイプライン演算子で記述できる仕組みを活用します。
具体例（LCEL）:
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI
prompt = ChatPromptTemplate.from_template("あなたは{role}です。{question}に答えてください。")
model = ChatOpenAI(model="gpt-4") # ここを差し替える（別の提供元なら ChatAnthropic などのクラスに替える）
chain = prompt | model # パイプラインで接続
result = chain.invoke({"role": "アシスタント", "question": "LLMとは？"})モデル部分だけを別のインスタンスに差し替えるだけで、全体の流れ（チェーン）を維持できます。
モデル変更による「意図の乖離」への対応
モデルが変更されると、出力内容は合っているものの「雰囲気や文章スタイル」が異なり、意図に合わないことがあります。これは、モデルごとに学習データやアライメントの方法が異なるためです。
LLM-as-a-judgeによる評価と適応
このような「意図との乖離」に対して、プロンプトの修正や評価（LLM-as-a-judge）を通じてシステムが適応し、安定した出力を提供する仕組みがレジリエンスの重要な要素となります。
具体例:
# 出力を評価する仕組み（LLM-as-a-judge）
def evaluate_output(output: str, expected_style: str) -> bool:
judge_prompt = f"""
以下の出力が、指定されたスタイルに合っているか評価してください。
スタイル: {expected_style}
出力: {output}
合っていれば「OK」、違っていれば「NG」と答えてください。
"""
result = judge_model.generate(judge_prompt)
return result.strip().startswith("OK") # 余計な空白や説明が付いても判定できるようにこのように、モデルの出力をそのまま信頼せず、評価レイヤーを挟むことで、モデル変更による品質低下を検知し、適応できます。
アライメントの再調整
モデルの出力を人間の意図やHHH原則（Helpful, Honest, Harmless）に沿わせる「アライメント」は、事後学習（SFTやRLHF）で行います。LLMを提供する側がベースモデルを入れ替えると、このアライメントは新しいモデルに対してやり直しになります。事後学習に使うデータと評価の基準をモデルから切り離して持っておけば、入れ替えのたびに同じ手順で再調整でき、上の評価レイヤーで、前のモデルと同じ水準に戻ったかを確かめられます。
データ層のモデル非依存化
モデル変更時にデータベースの扱いが変わらないようにするためには、データ層もモデルから分離する必要があります。
ベクトルDBの抽象化
埋め込みモデル（Embedding Model）が変わると、ベクトルの次元数や分布が変わるため、ベクトルDBのスキーマや検索ロジックに影響が出ます。影響を小さくするには、まず埋め込みモデルを抽象化して、呼び出し側のコードを固定します。
具体例:
# 埋め込みモデルの抽象化
class EmbeddingInterface:
def embed(self, text: str) -> list[float]:
raise NotImplementedError
class OpenAIEmbedding(EmbeddingInterface):
def embed(self, text: str) -> list[float]:
# OpenAIの埋め込みモデルを呼び出す
pass
class LocalEmbedding(EmbeddingInterface):
def embed(self, text: str) -> list[float]:
# ローカルの埋め込みモデルを呼び出す
passただし、抽象化で吸収できるのは呼び出し方までです。埋め込みモデルが違えば、次元数が同じでもベクトル同士は比べられません。モデルを替えるときは、保存済みの文書を新しいモデルで埋め込み直す必要があります。各ベクトルに、使ったモデルの名前と版をメタデータとして持たせておき、新しいモデル用の索引を並行して作ってから切り替えると、サービスを止めずに移行できます。
メモリ管理の分離
コンテキストの管理をモデルから分離し、外部ストレージや専用サービスで管理することで、モデル変更の影響を局所化できます。
具体例:
# メモリ管理をモデルから分離
class MemoryManager:
def __init__(self, storage):
self.storage = storage
def save_context(self, session_id: str, context: dict):
self.storage.save(session_id, context)
def load_context(self, session_id: str) -> dict:
return self.storage.load(session_id)このように、メモリ管理を独立させることで、モデルが変わっても会話履歴やコンテキストを維持できます。
変更を前提とした設計の実践例
ツールとスコープの最適化
モデルが使用するツール（APIや関数）の数を必要最小限に絞り、スコープを明確にします。Vercelは、自然言語の質問をSQLに変えて実行する社内エージェント「d0」で、15個あった専用ツールを、任意のbashコマンドを実行する1つのツールに置き換えました。モデル（Claude Opus 4.5）はそのままで、代表的な5つの質問での成功率は80%から100%に、平均応答時間は274.8秒から77.4秒に改善したと報告しています（Vercelのブログ、2025年12月）。比べたのは5問だけですが、道具を細かく用意するほど良くなるとは限らないことを示す例です。
ポイント:
- ツールが多いと、モデルが誤ったツールを選ぶリスクが高まる
- ツールを絞ることで、モデル変更時の影響範囲も小さくなる
- Vercelの例では、専用ツールを細かく並べる代わりに、汎用的な道具1つと、ファイルとして整理したデータの定義を渡す形にして安定した
周辺の部品を5つに分けて考える
ここでは、LLMの周りの部品をツール、メモリ、評価、ガードレール、プロンプトの5つに分けて考えます。それぞれを区別し、独立して設計・運用します。
| コンポーネント | 役割 | モデル変更時の影響 |
|---|---|---|
| ツール | 外部APIや関数の呼び出し | 低（ハーネス側で制御） |
| メモリ | 会話履歴・コンテキスト管理 | 低（外部ストレージで管理） |
| 評価 | 出力の品質チェック | 中（評価基準の再調整が必要） |
| ガードレール | 入力・出力のバリデーション | 低（モデルに依存しない） |
| プロンプト | モデルへの指示 | 高（モデルごとに調整が必要） |
このように、各コンポーネントを独立させることで、モデルが変わっても、ガードレールやメモリ管理のロジックは流用可能であり、システム全体の安定性が保たれます。
まとめ——「差し替え可能な部品」としてのモデル
モデル変更を前提とした設計とは、モデルをブラックボックスとして扱い、その入出力を制御するハーネス側（抽象化レイヤー、パイプライン、ガードレール）を堅牢に設計することです。
モデル変更時は、ハーネスの「差し替え可能な部分」だけを置き換えることで、フレームワーク全体の再構築を回避できます。
設計のポイントまとめ:
- 抽象化レイヤーでモデルを直接呼び出さない
- 宣言的パイプラインで処理の流れをモデルから分離
- 評価レイヤーでモデル変更による品質低下を検知
- データ層を分離してベクトルDBやメモリをモデル非依存に
- ツールを最適化してモデル変更の影響範囲を小さく
- 周辺の部品（ツール・メモリ・評価・ガードレール・プロンプト）を分けて独立に運用
LLMの進化は今後も続きます。「どのモデルを使うか」だけでなく、「モデルが変わってもシステムが動き続けるか」という視点が、これからのLLMシステム設計には不可欠です。
