プロンプトはコードと同じく「バージョン管理」「自動テスト」「CI/CD連携」の三点セットで運用するのがLLMアプリ本番運用の定石です。ChatGPTのWeb UIに貼り付けて動いたから完了、という個人作業のノリでは本番運用は成立しません。プロンプトは資産であり、変更履歴とテストで品質を担保する必要があります。
なぜプロンプトのバージョン管理が必要か
プロンプトはコードと同じく、アプリケーションの振る舞いを決定づける要素です。「一文を変えただけで応答精度が10%変わった」「前のプロンプトの方が良かった気がするが記録がない」という事態は、バージョン管理がなければ日常茶飯事です。本番稼働中のアプリケーションで、責任をもって改善を続けるには、変更履歴の追跡が不可欠です。
また、LLMモデルのアップデートに伴ってプロンプトを調整する必要もあります。「gpt-4oの時代には効いていたプロンプトが、gpt-5では効かなくなった」ということは珍しくありません。そのたびに調整し直すには、元のプロンプトと評価結果の履歴が揃っていないと話になりません。プロンプトエンジニアリング入門、システムプロンプト設計、LLMOps、LLMアプリ評価フレームワークの記事と合わせて読むと、運用の全体像が見えてきます。
プロンプト管理の3つのアプローチ
プロンプトの管理方法には、大きく3つのアプローチがあります。Gitでのファイル管理、専用ツール(LangSmith、Promptflow、PromptLayer等)、DBベースの独自管理です。規模や要件に応じて選びます。
| アプローチ | メリット | デメリット | 適した規模 | ツール例 |
|---|---|---|---|---|
| Git管理 | 履歴追跡容易、コードと一体管理 | UI不便、非エンジニアには難 | 小〜中 | GitHub/GitLab |
| 専用ツール | UI充実、A/Bテスト対応 | 料金、ロックイン | 中〜大 | LangSmith、Promptflow |
| DB管理 | 動的切替、利用状況分析 | 独自開発が必要 | 大 | PostgreSQL+独自UI |
# prompts/summarize.v2.yaml
name: summarize
version: 2
description: 記事を300字以内で要約する
model:
name: gpt-4o-mini
temperature: 0.3
system_prompt: |
あなたは技術編集者です。入力された記事を300字以内で要約してください。
重要用語は保持し、事実のみ記述します。
tags:
- summarize
- content
created_at: 2026-03-15
author: taro.sato
YAMLファイルとして管理すると、差分が見やすく、レビューもしやすいです。ファイル名にバージョンを含めるか、ディレクトリ階層でバージョンを分けるかはチーム文化によりますが、「本番で使われているバージョンが一意に特定できる」状態を維持することが最重要です。
プロンプトのテスト設計
プロンプトのテストは、「入力」と「期待する出力の条件」をペアで定義します。期待出力を完全一致で指定できるタスクは稀で、多くの場合は「含まれるべきキーワード」「形式が正しいか」「禁止事項が含まれていないか」といった条件で評価します。高度なテストでは、LLM-as-Judgeで出力の質を別のLLMに採点させる方式も有効です。
# promptfoo-config.yaml
prompts:
- file: prompts/summarize.v2.yaml
providers:
- openai:gpt-4o-mini
tests:
- vars:
text: "生成AIは2023年以降急速に進化し、業務利用が拡大している。"
assert:
- type: contains-any
value: ["生成AI", "進化", "業務"]
- type: javascript
value: "output.length <= 300"
- vars:
text: "..."
assert:
- type: llm-rubric
value: "記事の主旨を正確に要約しているか"
| 種別 | 目的 | 方法 | ツール | 実行タイミング |
|---|---|---|---|---|
| 単体テスト | 個別プロンプトの動作 | 入出力ペア検証 | promptfoo | PR時 |
| リグレッション | 既存機能の維持 | 過去ケース再実行 | CI | デプロイ前 |
| 品質評価 | 応答の質的判定 | LLM-as-Judge | LangSmith等 | 週次/日次 |
| 攻撃テスト | セキュリティ | インジェクション | Promptfoo | 週次 |
| A/Bテスト | 改善効果の測定 | 並行運用 | 本番基盤 | 本番中 |
テストケースは20〜50件程度を最低限のラインとして整備します。代表的な入力、難しい入力、攻撃的な入力をバランス良く含めると、実運用時の安定性が高まります。
CI/CDへの組み込み
プロンプトの変更がPRとしてマージされる前に、自動テストが走り、基準を満たさなければブロックされる――この仕組みをCI/CDで構築します。GitHub Actionsを使う例を示します。
# .github/workflows/prompt-test.yml
name: Prompt Test
on:
pull_request:
paths:
- "prompts/**"
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
- run: npx promptfoo@latest eval -c promptfoo-config.yaml
- name: Check pass rate
run: |
if [ $(jq '.results.stats.failures' result.json) -gt 0 ]; then
exit 1
fi
CIのタイミングでLLM APIを呼ぶため、コスト管理にも注意が必要です。テスト用に安価なモデルを使う、定期実行は夜間だけにするなどの工夫で、コストを抑えられます。
チーム開発でのプロンプト管理
チーム開発では、プロンプトのレビューフローも確立する必要があります。プロンプト変更は見た目が軽微でも振る舞いへの影響は大きく、コードレビューと同等の慎重さが求められます。プロンプトの意図、変更理由、テスト結果、期待される副作用をPR説明に記載することを義務付けましょう。
また、エンジニア以外のメンバー(PM、業務担当)もプロンプト編集に関わることが多いため、Gitに不慣れな人でも編集できる工夫が必要です。LangSmithやPromptflowは非エンジニアでも扱えるUIを提供しており、業務担当が試作→エンジニアがレビュー→マージ、という協働フローが作りやすくなります。
まとめ
- プロンプトはコード同様にバージョン管理、自動テスト、CI/CDで運用する
- Git管理は小規模に、専用ツールは中〜大規模に適する
- テストは入出力ペア+LLM-as-Judgeを組み合わせて設計する
- チーム開発ではレビューフローと非エンジニア向けUIを整備する
よくある質問
プロンプトのバージョン管理はなぜ必要ですか
プロンプトの変更が出力品質に影響するため、「いつ、誰が、何を変更したか」の追跡が必要です。問題発生時のロールバック、チーム間での共有、変更の影響評価に不可欠です。
プロンプトのテストはどう設計すべきですか
入力パターン20から50件に対して期待する出力条件(形式、含むべき情報、品質基準)を定義します。LLM-as-Judgeで自動評価し、スコアが閾値を下回る場合はデプロイをブロックする仕組みをCI/CDに組み込みます。
プロンプト管理に専用ツールは必要ですか
小規模(プロンプト数10以下)ならGit管理で十分です。プロンプト数が増えたり、A/Bテストや利用状況の分析が必要になったりしたら、LangSmithやPromptflowなどの専用ツールの導入を検討してください。