LLMアプリでモデル更新時にプロンプト動作を安定させるには

LLMを使ったアプリはモデルのアップデートで動作が変わることがあり、運用面での悩みの種になっています。今回取り上げる研究では、テストやプロンプトの工夫でモデルが変わっても安定して動かすために実際に行われた取り組みがまとめられています。

背景

LLMを活用したアプリケーションを作る人が急速に増えています。チャットボットやデータ分析ツール、社内業務の効率化まで幅広い用途でLLMが使われるようになりました。

そんなアプリケーションの土台となるLLM自体はめまぐるしく進化を続けています。2025年前半だけでもOpenAIから5つの主要モデルがリリースされ、GoogleやAnthropic、DeepSeekからも7つのモデルが発表されました。2020年には年間2〜3モデル程度だったリリース数が、2024年には15〜18モデルと5倍以上に増えており、この流れは今後も続くと予想されています。

新しいモデルが登場すると、モデルを開発者が活用するためのAPIがすぐにリリースされる状況です。
モデルの進化は性能向上という利点をもたらすので基本的には歓迎される展開です。しかし、モデルを入れ替えるとこれまでうまく動いていたプロンプトが通用しなくなることもあり、アプリケーションの動作が不安定になる問題を引き起こします。企業の重要な業務にLLMを組み込んでいる場合、モデルの変更によって応答が変わってしまうことはリスクになります。

また、同じ会社のモデルだとしてもアップデートによって動作そのものが大きく変わる可能性があり、異なるバージョン間で一貫した動作を維持するのは簡単ではありません。

このような背景から、モデルが進化しても安定して動作する生成AIアプリケーションをどう作るかが大きな課題となりつつあります。基盤となるモデルが変わっても機能やユーザー体験を損なわず運用を続けるための仕組みが求められています。

本記事では、そのような課題にどう取り組むべきか参考になる事例を紹介します。

LLMアプリケーションを取り巻く環境

LLMを活用したアプリケーション開発の現場で今どのような状況が生まれているのか、もう少し具体的に見ていきます。

生成AIアプリケーションの台頭

SaaS（Software as a Service）アプリケーションの状況が生成AIの登場によって大きく変わろうとしています。マイクロソフトのサティア・ナデラCEOが「現在知られているSaaSは死ぬ」と発言したことが話題になりましたが、変化は根本的なものとなる可能性があります。

これまでSaaSアプリケーションは開発に数か月から数年かかることも珍しくなく、用途も汎用的なものが多いです。また、データの作成や更新、削除といった基本的な操作を中心に作られてきました。
一方で生成AIを活用したアプリケーションは、わずか数日から数週間で開発でき、特定の業務に深く特化した設計にすることも可能です。

ユーザーインターフェースの面でも変化が起きています。これまでの複雑なメニューやタブが並ぶ操作画面ではなく、ユーザーが自然な言葉で「こうしたい」と伝えるだけで処理が進む形に変わりつつあります。操作方法を覚える負担が減り、誰でも使えるツールになりつつあるのが特徴です。

生成AIを活用する流れは加速しています。ハーバード・ビジネス・レビューでも「生成AIは企業ソフトウェアに革命をもたらし、従来のワークフローを動的で目標志向の環境へ変えていく」と評価されており、生成AI関連の予算は2025年から2027年の間に60％増加する見込みです。IT予算全体に占める割合も4.7％から7.6％へと拡大し、C級役員の半数以上が日常的に生成AIを業務で使い始めています。

LLMの急速な進化

生成AIの普及を支えるLLM自体、急速な進化を続け、新しいモデルは性能の向上や新機能の追加といった利点をもたらします。

その一方でモデルの刷新はアプリケーションの動作に影響が出ることがあります。モデルによって応答の傾向や解釈の仕方が変わるため、開発者はそれに合わせてプロンプトやワークフローの調整が必要になる場面が増えてしまいます。

LLMの進化は、データベースの「スキーマ進化（データ構造の変更）」に似た側面があります。変更の頻度が増えても、アプリケーションは新しいモデルでも途切れなく動き続けることが求められるからです。ただし、データベースのスキーマ変更と違い、LLMの場合は変更内容が必ずしも明確に定義されているわけではなく、次にどのような動作の違いが出るか予測が難しい点が課題です。

生成AIアプリケーションがより多くの現場で活用されるようになるにつれて、この”LLM進化への対応”は避けて通れないテーマになりつつあります。

具体事例を見てみる

今回は、企業向けの検索アプリ「Tursio」の取り組みを例に挙げて見ていきます。TursioはSQL Server、Azure SQL、Snowflake、BigQueryといった複数のデータソースを対象に、LLMを活用した検索機能を提供するシステムです。

Tursioは2023年にGPT-4-32kを基盤として構築され、現在は100以上のインスタンスで日々稼働しています。1日に数千件のクエリを処理し、1つのクエリごとに平均33回のLLM呼び出しが発生します。学習の際にも1回あたり1,000回以上のLLM呼び出しが必要となり、TursioはLLMに大きく依存するシステムと言えます。

こうしたLLMを基盤としたアプリケーションは、モデルの進化が運用面での大きな課題となります。モデルが変わることで、それまで安定していた機能が急に不安定になる可能性があるからです。

実際に何が起きるのか

モデル変更がアプリに何を引き起こすのかを、具体的に見ていきます。

テスト結果で見えた課題

Tursioではモデルを入れ替える際、アプリケーションの安定性を保つために大規模なテストスイートを実行していました。GPT-4-32kで問題なく動いていたプロンプトを新しいモデルでテストした結果は以下の通りです。

• （GPT-4-32kではすべてのテストが成功）
• GPT-4.1では98%が成功
• GPT-4.5-previewでは97.3%が成功

一見するとわずかな差のように見えますが、企業の重要な業務を支えるシステムでは、この数パーセントの失敗が大きな問題につながります。テストが一部でも失敗すればCI/CDパイプラインが止まり、アプリケーションの動作が不安定になるからです。

たとえば「入力からSQLフィルターを抽出する」というシンプルなプロンプトでも、新しいモデルでは正しく動作しないケースが発生しました。モデルのアップデートは必ずしもスムーズな移行を保証しないことが、この結果からもわかります。

共通して発生した問題

モデルを新しくしたことで、次のような問題が共通して起きていました。

解釈ミス
ORDER BY や GROUP BY などの重要なSQL構文を適切に扱えなくなり、必要な処理が漏れることが増えました。

列名の誤認
実際には存在しない列名を推測して出力し、後続の処理でエラーを引き起こす原因となりました。

意味の取り違え
データの意味を間違えていました。「TIMES_LATE」という列名を、実際には時間とは無関係にもかかわらず時間軸のデータとして扱ってしまう誤解が生じました。

条件の曖昧化
本来自動で補うべきフィルター条件が抜け落ちたり、不明確な出力になったりするケースが見られました。

特定のモデルで見られる問題①

今回のケースでいうと、GPT-4.1では、より具体的で詳細なプロンプトが必要になる傾向がありました。

暗黙の処理をしなくなった
「時系列で分析する」というニュアンスがあっても、ORDER BY句を自動で追加しなくなりました。

相対時間表現の扱いが不十分
「過去3か月間」などの表現を含む場合でも、必要な処理が省略されることが増えました。

文脈からの推測が減少
以前のモデルでは暗黙的に補っていた情報を、明示的に指示しなければ処理できなくなる場面が増えました。

列名と値の混同
列名と値を取り違え、誤った出力を生成することもありました。

特定のモデルで見られる問題②

GPT-4.5-previewでは、さらに次のような問題が確認されました。

出力形式の不一致
システムが期待するフォーマットとは異なる形で出力し、内部でエラーが発生するケースが増えました。

理解不能なメッセージの出力
「該当項目が見つかりませんでした」など、プログラムが扱えないテキストメッセージを返すことがありました。

不要な操作の追加
本来不要なORDER BY句を勝手に追加するなど、余計な処理を挟むケースも見られました。

列名と演算子の混同
列名と演算子を混同し、不正な出力を生成してしまうことも確認されました。

モデル設計の違いによる影響

以上の問題の背景には、モデルごとの設計方針の違いがあります。

GPT-4.1では、指示に忠実であることが重視され、推測が求められる場面では処理を外部ツールに任せる傾向が強くなりました。その結果、幻覚（ハルシネーション）は減少したものの、暗黙的な推論や補完ができなくなり、指示不足の場合には期待通りに動作しなくなる場面が増えています。

また、GPT-4.1は最大100万トークンのコンテキストウィンドウを持つ一方、GPT-4は2,000〜8,000トークンに制限されており、このコンテキストの取り扱いの違いも挙動に影響を与えています。

リリースノートが示す方向性

リリースノートを見ると、GPT-4.1は「コーディングや指示への従順性、長文コンテキスト処理での性能向上」を強調しています。一方でGPT-4.5-previewは「推論能力や創造性の向上」を掲げており、GPT-4o をスケールして性能を引き上げています。

総合的に性能が向上したからと言ってアプリケーションにプラスになるとは限りません。実際には互換性の問題が生じ、移行時の対応コストが発生する場合があることが今回の事例から明らかになりました。

解決策としてのプロンプト移行

モデル変更で発生した問題への実際の対応策を見ていきます。

プロンプトガイドラインの変化

まず、新しいモデルの公式プロンプトガイドを確認するところから始めます。

今回のケースでいうと、GPT-4.1では「より明示的な指示が必要」という方針が明確に打ち出されていました。ガイドには「他のモデル用に最適化された既存のプロンプトは、このモデルではすぐに動作しない可能性があります。既存の指示に厳密に従うため、暗黙のルールを推測することが少なくなるからです」と記載されています。

ガイド自身が「このモデルを最大限活用するにはプロンプト移行が必要になるだろう」と認めている点も興味深いポイントです。

新しいガイドでは以下の構造が推奨されています。

• 役割と目的の明確化
• 詳細な指示（必要に応じて細分化）
• 推論の進め方の説明
• 出力形式の指定
• 具体例の提示
• 文脈情報の提供
• ステップごとの思考を促す最終指示

推論が必要なタスクでは「クエリ分析→文脈分析→統合」のように段階を区切った進め方を明示的に伝えることが重要だとされています。

こうしたガイドの変化から、モデルの動作が変わっていることがわかります。以前は暗黙的に処理できていた内容も、新しいモデルでは具体的な指示を与える必要が出てきているのです。

新しいプロンプトの作成

チームはこの変化を受け、より具体的な指示を盛り込んだ新しいプロンプトを作成しました。

従来のプロンプトは「入力からSQLフィルターを抽出してください」と簡潔でしたが、新しいプロンプトでは出力形式、処理規則、例示を詳細に記載し、モデルが迷わないようにしました。

新プロンプト（例）
「入力された質問からSQLフィルターを抽出し、必ず ‘filters: […]’ の形式で出力すること。
ルール：角括弧、カンマ区切り、アンダースコア使用、引用符不要、暗黙的列の推測、誤字の軽微修正許可、一致する表現の使用、フィルターが無い場合は ‘filters: []’ を返す」

具体例を加えた結果、GPT-4.1でのテスト成功率は100%まで回復しました。

移行テストベッドの構築

回帰テストだけでは「今動いているもの」を守ることはできますが、新しいモデルへの移行準備には不十分です。そこでチームは移行作業を支える「移行テストベッド」を構築しました。

本番で実際に使われている数百のクエリから110の質問を抽出し、以下の3段階に分類してテストを行えるようにしました。

簡単レベル
基本的なフィルター、グループ化、並び替えを含むクエリ
例：「2003年12月以前の品目数上位3都市を表示」

中程度レベル
過去に失敗したパターンや、簡単レベルの言い換えを含むクエリ
例：「詳細備考に『問題なし』がある訪問詳細を表示」

困難レベル
暗黙の条件推測や自然な表現を含む複雑なクエリ
例：「詳細備考で商人が必要とされた訪問をリストアップ」

テストベッドの構築にはデータセットへの深い理解が必要で、手作業での確認も欠かせない工程でした。それでも、この仕組みによって将来のモデル変更時のリスクを減らす準備ができるようになりました。

移行フレームワークの確立

開発チームは、以下の流れで半自動化された移行フレームワークを確立しました。

1. 新モデルでテストベッドを実行し、失敗パターンを特定する
2. 失敗した箇所のプロンプトを修正する
3. プロンプトガイドを参照しつつ修正パターンを学習する
4. テストベッドを再実行し、すべて通過するまで繰り返す
5. 回帰テストを実行し、既存のワークロードで問題がないか確認する

この仕組みで、以前は数か月かかっていた移行作業を数週間に短縮できるようになりました。

今後は、失敗したプロンプトとプロンプトガイドをLLM自身に渡し、改善案を自動生成させる取り組みも検討されています。

プロンプトのライフサイクル管理

今回の経験で、プロンプトのライフサイクル管理が重要なテーマであることが改めて認識されました。

モデルの進化はアプリケーションの動作に直接影響を与えるため、プロンプトは両者をつなぐ橋渡しの役割を持ちます。新しいモデルに適応できるよう、プロンプトを継続的に進化させていくことが求められます。

LLMの進化とともに、こうした取り組みがますます重要になっていくはずです。

実践から得た学び

プロンプトのスタイルを見直す必要性

今回の事例では、GPT-4では柔軟な書き方のプロンプトが効果的で、モデルが暗黙のニュアンスを汲み取ってくれることが多くありました。しかしGPT-4.1やGPT-4.5-previewを使う場合は、明確で構造化された指示が必要であることがわかりました。

モデルに合わせてプロンプトの内容を調整したことで、GPT-4.1でのテスト結果が大きく改善しました。

例の示し方で結果が変わる

プロンプト内で使う例の示し方によって、モデルの出力が大きく変わることがわかりました。プレーンテキストやJSON形式も試しましたが、XML形式が最も安定して正確に動くことを確認しました。

OpenAIのドキュメントでもMarkdownとXMLタグを組み合わせることで文脈の区切りをモデルが理解しやすくなると案内されています。XML形式は開始と終了を明確に示すことができ、タグ内に補足情報を入れることもできる利点があります。一方でJSONは記述が煩雑になりやすく扱いづらい部分がありました。

移行作業には負担が伴う

移行テストベッドを使うことで作業効率は上がりましたが、新しいモデルへの対応には相応の負担が残りました。以前は数行で済んでいたプロンプトが、新しいモデル対応では一ページ分の細かな指示へと増える場合もありました。

移行作業は開発者自身が内容を精査しながら進める必要があり、急速に増えるモデルに対応するためのツール整備が課題になります。

プロンプトを継続的に管理する重要性

LLMの活用が広がる中で、プロンプトを適切に管理し続けることが欠かせなくなっています。モデルのバージョンが変わっても既存のアプリケーションで問題が起きないよう、プロンプトの移行作業を日常的に進めることが求められます。

移行テストベッドを使うことでモデル評価とアプリケーション開発の工程を分けて進められるようになり、AIエンジニアとアプリケーションエンジニアの役割分担がしやすくなります。

プロンプト管理のスキルが求められる時代

これまでのプロンプトエンジニアリングは、目的を達成するために最適な指示を探すことが中心でした。しかし今後は調整したプロンプトを新しいモデルへ安全に移行させ、動作が不安定になることを防ぐ力が求められます。

LLMが多くの分野に使われるようになる中で、こうしたプロンプト管理のスキルはエンジニアにとって欠かせないものになっていくでしょう。

LLMの進化と知能の変化

モデルの性能が向上する一方で、以前できていた暗黙の理解がうまくできなくなる場面も出てきます。今回の事例で言えば、GPT-4.1やGPT-4.5-previewでは、GPT-4-32kで対応できていたことができなくなるケースがあり、より明確な指示が必要になりました。

LLMは新たな可能性を開く一方で、モデル自体の知能や推論の限界についても冷静に把握するよう努める必要があります。大量の情報を生み出せることは強みであり課題でもあり、いずれにしても最終的にモデルを動かすのは人間です。

人間とLLMの関わりは今後さらに重要になっていきます。プロンプトをどう扱うかはその中心的な役割を担い続けるでしょう。

まとめ

本記事では、モデルが変わっても安定して動く生成AIアプリケーションづくりを目指した研究を紹介しました。

モデル更新で動作が変わることを事前に把握し、専用のテストとプロンプト調整で対応した方法がまとめられています。今回のケースでは、例の示し方やプロンプトの管理が重要になることがわかりました。

新しいモデルへの移行にかかる負担は工夫によって減らせる可能性があります。自分の使うAIサービスでプロンプトの見直しやテストを試す際の参考にしてみてください。