本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
PromptWizard vs Agent Lightning：タスク最適化とエージェント訓練の比較検証ガイド
【ユースケース定義と課題】
ユースケース： 多言語かつ技術的に複雑なカスタマーサポートチケットの自動分類・優先度判定・初動回答案の生成。
課題：
専門用語の誤認による分類ミス（例：ハードウェア障害をソフトウェアバグと誤判定）。
優先度（P1-P4）の判定基準が曖昧で、SLA（サービス品質保証）を遵守できない。
型定義： 入力は「問い合わせ原文」、出力は「カテゴリ、優先度、理由、回答案」を含むJSON形式。
【プロンプト設計のループ】
graph TD A["設計: 役割と出力形式の定義"] --> B["実行: PromptWizard/Agent式入力"] B --> C["評価: LLM-as-a-Judgeによる自動採点"] C -->|分類誤り/様式崩れ| A C -->|精度向上| D["最適プロンプトの確定"]
設計：Few-shot例とChain-of-Thought（思考連鎖）を組み込んだベースライン作成。
実行：Gemini 1.5 Pro等のモデルに対し、多様なテストケースを投入。
評価：後述する評価指標に基づき、期待値との乖離（ロス）を算出。
改善：PromptWizard的アプローチ（指示文の進化）またはAgent Lightning的アプローチ（行動軌跡の修正）による再設計。
【プロンプトの実装案】
ここでは、PromptWizardの思想（指示の具体化）とfew-shotを組み合わせた初期プロンプトを提示します。
# Role
あなたは熟練したテクニカルサポートエンジニア兼、チケット仕分けの専門家です。
# Task
入力されたユーザーの問い合わせを分析し、以下のJSON形式で出力してください。
# Output Format
{
"category": "Software / Hardware / Billing / Other",
"priority": "P1 (Critical) / P2 (High) / P3 (Medium) / P4 (Low)",
"reasoning": "なぜその判定に至ったかの簡潔な理由",
"draft_response": "ユーザーへの丁寧な初動回答"
}
# Guidelines (Chain-of-Thought)
1. 問い合わせ内容から「製品名」「エラーコード」「緊急性を示すキーワード」を抽出せよ。
2. データの損失やサービス停止が伴う場合は、無条件でP1と判定せよ。
3. 回答案には、必ず次にユーザーがすべきアクション（ログの送付等）を含めよ。
# Examples
Input: "ログインできない。DBエラー500が出ている。至急直して。"
Output: {
"category": "Software",
"priority": "P1",
"reasoning": "サーバー内部エラー(500)が発生しており、全ユーザーに影響する可能性があるため。",
"draft_response": "ご不便をおかけしております。現在調査中ですが、エラー発生直前の操作内容を教えていただけますか？"
}
【評価指標と誤り分析】
期待通りにいかない主要なパターン：
ハルシネーション：存在しない製品マニュアルを参照した回答。
様式崩れ：JSONの末尾に不要な解説テキストが付随する。
優先度ブレ：同一の内容でも実行ごとにP2とP3が入れ替わる。
LLM-as-a-Judge 採点基準
| 評価項目 | 判定基準 | 配点 |
|---|---|---|
| 形式遵守 | JSONとしてパース可能か、スキーマは正しいか | 30点 |
| 分類精度 | 正解ラベルとカテゴリ・優先度が一致しているか | 40点 |
| 回答妥当性 | 回答案が具体的かつ解決に資する内容か | 20点 |
| 思考論理 | Reasoningが論理적整合性を保っているか | 10点 |
【改良後の最適プロンプト】
Agent Lightningの「軌跡の最適化（最適ルートの提示）」とPromptWizardの「指示の進化」を統合したプロンプトです。Gemini 1.5 Proの長いコンテキスト窓を活かし、「失敗例とその修正プロセス」を明示します。
# Role
System Triage Agent v2.0 (Optimized via Trajectory Analysis)
# Constraints
- Output strictly in JSON. No preamble or postscript.
- Use 'Reasoning-First' approach: Internal monologue before final decision.
# Knowledge Base (Anti-Patterns)
- DO NOT classify "slow performance" as P1 unless it affects >50% of users.
- DO NOT provide generic answers like "Please wait". Always ask for specific logs.
# Thinking Process (Task Decomposition)
1. Analyze User Intent: Is this a feature request or a bug?
2. Impact Assessment: Estimate number of affected users based on keywords.
3. Priority Matrix:
- Data Loss -> P1
- Critical Feature Blocked -> P2
- Workaround Available -> P3
- Cosmetic/UI -> P4
# Few-shot Trajectories (Self-Correction Examples)
[Input] "I found a typo in the settings menu."
[Thought] Low impact, cosmetic. No functional block.
[Result] {"category": "Other", "priority": "P4", "reasoning": "UI typo, zero impact on functionality.", "draft_response": "Thank you for the report. We've logged this for a future UI update."}
[Input] {{USER_QUERY}}
【まとめ】
実務でプロンプトを運用するための3つの鉄則：
「指示」よりも「思考プロセス」を固定する： 単に「正確に判定して」と書くのではなく、判定に至るまでの思考ステップ（Impact Assessment等）をプロンプト内で定義する。
ネガティブ制約（アンチパターン）を明記する： PromptWizard的手法で得られた「過去の失敗」を、プロンプトに「やってはいけないこと」としてフィードバックし続ける。
LLMによる自動評価をパイプラインに組み込む： 人間が毎回確認するのではなく、別のLLM（評価者）にJSONスキーマと論理性に基づいたスコアリングをさせ、精度を定量化する。
この記事の更新履歴
この記事は、生成AIを活用した自動レビュー・更新フローにより内容を見直し、必要な修正を反映しています。
2026年9月20日
- 削除記事冒頭に残っていた検証用メタデータおよびスタイルプロンプトの記述を削除しました。
