はじめに
LLMアプリの運用では、コードよりもプロンプトのほうが挙動に影響しやすい場面がよくあります。
少し文言を変えただけで出力の傾向や評価が変わったり、いつの間にか「どのバージョンがどの環境で動いているか分からなくなる」ことも起きがちです。
また、実際の運用ではプロンプトだけでなくモデル側も頻繁に更新・切替したくなることがあります。
たとえば、
- コストや速度、精度、ツール対応の都合で provider を変えたい
- 最新モデルへスムーズに移行したい
といったケースです。モデル名をコード側に直書きしていると、移行のたびにPRやデプロイが必要になり、やや手間が大きくなります。
さらに言えば、プロンプトの改善サイクルを回すのは必ずしもエンジニアとは限りません。ドメイン知識を持つ担当者が直接プロンプトを調整し、評価まで回せる体制が作れると、改善のボトルネックがぐっと減ります。
LangSmithのPrompt Hubを“プロンプトのGit”のように使い、コミットタグでプロンプトとモデル設定をまとめて管理・昇格・評価する運用を作っておくと、このあたりの作業を整理しやすくなります。
LangSmith Prompt Hubの前提：Prompt / Commit / Tag
| 要素 | 概要・関係性 | 可変性 | 運用上の役割 |
|---|---|---|---|
| Prompt | プロンプト“資産”の単位（箱） | - | 機能ごとの管理単位（例: email_summary） |
| Commit | Promptの特定バージョン実体（本文＋モデル設定） | 不可変 | 評価・比較の最小単位（例: commit abc123） |
| Commit Tag | 特定Commitを指す“可変ポインタ” | 可変 |
環境の参照先＝デプロイ切替スイッチ（:dev, :stg, :prod） |
| Prompt Tag | Prompt全体に付く分類ラベル | 可変 | 用途/状態の整理・検索用（service-a, deprecated） |
| Model Config | Commitに含まれるモデル/パラメータ設定 | 不可変 | モデル切替も“コミットごとデプロイ”できる |
LangSmithでは、プロンプトを保存するとコミット履歴が残り、任意のコミットにCommit Tagを付けられます。タグは「特定コミットへの名前付きポインタ」のようなものです。
Commit Tags | LangChain Docs
ポイントは次の通りです。
- Commit Tagは1つのコミットだけを指す
- 後から別コミットへ付け替えられる
- コード側はコミットIDではなくCommit Tag参照で固定しておくと運用しやすい
Commit Tag参照にしておくと、「prodタグが指すコミット」を差し替えるだけで本番プロンプトを更新できるので、コード変更が不要になります（公式ドキュメントのユースケースとも一致します）。
from langsmith import Client
client = Client()
# prodタグが指すコミットを取得
prompt = client.pull_prompt("my-prompt:prod")
ここからは、MediiでPrompt Hubを運用する際の4つのルールを紹介します。
ルール1：プロンプト名は“目的が一目でわかる名前”にする
Prompt Hubはチームで共有していく場所なので、名前や説明が分かりやすいほど使われやすくなります。
最低限やっておくと良いことは、
-
一覧で用途が分かる命名にする
NG:v2_prompt,test1,new(何をするものか不明)
OK:email_summary,result_extractor,faq_router(機能名などを含める) -
Description / READMEを書く
- 目的
- 入力変数
- 期待出力
- 注意点
このあたりを短くても残しておくと、後から読み返したときに迷いにくいです。
ルール2：Prompt Tagは「用途タグ」と「状態タグ」を分けて付ける
タグが増えてくると整理が難しくなるので、役割で分けるのが無難です。
2-1. 用途タグ（どこで使うか）
“どの領域/サービスで使うか”を示すタグです。
- 単一サービス専用 →
service-aなど - 複数領域の共通 →
generalなど
用途タグは“棚”の役割を持つので、検索性や整理の面で効きます。
2-2. 状態タグ（今どのステージか）
“本番運用か、検証中か”を示すタグです。
例：
-
release= 本番利用中 -
testing= 検証中候補
状態タグで「今動いているもの／試しているもの」を分けられるので、運用の見通しが良くなります。
ルール3：Commit Tagは環境別（dev / stg / prod）で昇格フローを作る
環境ごとにタグを持っておくと、どのコミットをどの環境で使うかが明確になります。
-
dev：開発で試す最新版 -
stg：ステージングで評価する版 -
prod：本番参照中の版
昇格は dev → stg → prod の順で固定しておくのが扱いやすいです。
なぜ順序固定が便利か
- devは試行錯誤の場
- stgは本番前の確認の場
- prodは実際にユーザーへ影響する場
順序があることで、更新の手順や責任範囲が自然に揃います。
コード側はCommit Tag参照で固定
本番は :prod、検証は :stg、開発は :dev をpullする形にしておくと、参照先の切替がLangSmith側で完結します。
Manage prompts programmatically | LangChain Docs
ルール4：本番導入・切替のたびにDataset拡充＋オフライン評価を回す
プロンプト更新は効果が大きい分、最低限の評価ゲートを置いておくと安心です。
LangSmithのDatasetとEvaluationを使うと、比較的自然に運用へ組み込めます。
Evaluations | LangChain Docs
今回は省略しますが、WebHookを使うことで、CommitやCommit Tag更新のタイミングで評価を回すことも可能です。
4-1. 本番前
- Golden Dataset（代表入力セット）を用意
- Datasetでオフライン評価（Experiment）を回す
- 基準を満たすコミットに stg / prod を付ける
4-2. 本番後
- 本番ログで見つかった失敗例をDatasetに追加
- Datasetが育つほど次のリリースが安全になる
Datasetを更新し続けることで、改善の再現性も上がりやすいです。
LangSmithは“モデル設定も一緒にデプロイ対象”にできる
LangSmithでは、プロンプト本文に加えてモデル設定（provider / model / temperature / tool設定など）を「Model Configuration」として保存・共有できます。
そのため、「どのモデルに対するプロンプトか」まで含めてコミットとして管理する運用が可能になります。
Model Configurationsの公式説明はこちら：
Configure prompt settings | LangChain Docs
Model Configurationを標準化しておくと、チームの推奨設定をLangSmith側に寄せられるので、アプリ側の設定が散らかりにくくなります。
何が嬉しいか
この仕組みが効きやすいのは、たとえば次のような場面です。
1) ドメインエキスパートが直接改善サイクルを回せる
この運用の本質的なメリットは、プロンプト改善にエンジニアの手を介さなくて済む点にあります。
エンジニアはCommit Tag参照のコードを一度書くだけ。以降のプロンプト調整・評価・タグの付け替え（昇格）はドメイン知識を持つ担当者がLangSmith UI上で完結できます。
改善のボトルネックがエンジニアのリソースではなくなるので、イテレーションの速度が変わります。
2) providerを切り替えたいとき（OpenAI ↔ Gemini など）
同じプロンプトでも provider によって
コスト・速度・精度・ツール対応のバランスが変わるので、切替を試したくなるケースは割とあります。
LangSmith側でモデル設定を保存しておけば、同じプロンプトに対してモデル設定だけ差し替えて検証でき、
良さそうな方に決まったら prodタグが指すコミットの設定を切り替えるだけで移行できます。
3) 最新モデルへ移行したいとき
モデルは更新サイクルが速いので、いずれ **“新しいモデルを試して本番へ寄せたい”**場面が来ます。
Model Configurationに
-
current-stable（現行本番） -
next-candidate（次世代検証）
のような設定を作っておくと、
- 検証は next-candidate を使うコミットで回す
- OKなら prod が指すコミットのモデル設定を current-stable 相当に寄せる
といった形で、コードを触らずに更新を進めやすくなります。
実装イメージ（コード側は“Commit Tag参照”のまま）
考え方はプロンプト運用と同じで、コードは参照側に固定しておきます。
from langsmith import Client
client = Client()
# prodタグが指す「プロンプト＋モデル設定」を引く
runnable = client.pull_prompt("my-prompt:prod", include_model=True)
# コード側でモデル定義(llm = ChatOpenAI...)をする必要がなく、そのまま実行できる
runnable.invoke({"input": "..."})
まとめ
LangSmithのPrompt HubとCommit Tag、Model Configurationを前提にすると、
- プロンプトを名前・説明付きで資産化しやすい
- Prompt Tagで用途/状態を整理しやすい
- Commit Tagでdev→stg→prodの安全な昇格フローを作れる
- Dataset＋Evaluationで品質ゲートを作れる
- モデル設定も含めて管理でき、provider切替や最新モデル移行が比較的スムーズになる
という形で、プロンプトとモデルをソフトウェアと同じような形で運用しやすくなります。
LLMアプリを継続改善していくなら、こういう土台を作っておくと後が楽になるはずです。
Discussion