9月18日、KDNuggetsが「5 Prompt Optimization Strategies That Actually Improve LLM Output」と題した記事を公開した。プロンプトの改善に「なんとなく」取り組んでいる人が多い中、本記事は実際のテストケースに対して測定可能な変更を個別に検証するという規律を5つの戦略として体系化している。

プロンプトエンジニアリングとプロンプト最適化は混同されがちだが、この記事は明確に区別する。プロンプトエンジニアリングはゼロからプロンプトを設計すること、プロンプト最適化はすでに動いているプロンプトをモデルに手を加えずに改善することだ。「もっといい出力を得たい」と思っている人の多くはすでに動くプロンプトを持っており、必要なのは白紙のフレームワークではなく、具体的にどの変更が効くかという知識である。

記事全体を通して使われる検証用の素材は、3人が参加するリアルな会議トランスクリプトだ。途中で担当者が変わり、タスクが別のレビューに統合され、担当者が未確定のまま終わるアイテムが含まれている。このトランスクリプトに対して正しい答えを出せるかどうかが、各戦略の評価軸になっている。

最も効果が大きい戦略：構造化出力の指定

記事が「最も測定可能なレバー」と位置づけるのが、構造化出力の指定だ。「アクションアイテムを列挙して」という指示では、読みやすい文章は返ってくるが、プログラムが確実にパースできる出力は保証されない。本番環境においてパースできない出力は「小さな不便」ではなくハードな障害である。

記事ではPydanticを使ったスキーマ定義とバリデーションのコードを示している：

from pydantic import BaseModel, ValidationError

class ActionItem(BaseModel):
    owner: str
    task: str
    due: str

class ActionItemList(BaseModel):
    action_items: list[ActionItem]

def parse_structured_output(raw_json: str) -> tuple[ActionItemList | None, str | None]:
    try:
        return ActionItemList.model_validate_json(raw_json), None
    except ValidationError as e:
        return None, str(e)

漠然とした指示で得られた番号付きの散文形式のレスポンスは、どれほど整然と見えてもJSONではないためパース失敗となり、Noneとバリデーションエラーが返った。同じ情報をスキーマ付きで要求した場合は、3つのActionItemオブジェクトとして正常にパースされた。構造化出力が買うのは「見た目の良さ」ではなく、コードが実際に扱えるかどうかの差だ。

Few-Shotのデモ選択が意外なほど重要

記事はデモンストレーション（Few-Shot例）の選び方が、指示文の書き方より出力品質に大きな影響を与えることがあると指摘する。これはプロンプト最適化研究の分野で繰り返し確認されている知見であり、Liu et al.（2022）の「What Makes Good In-Context Examples for GPT-3?」などの先行研究でも、例の多様性や入力との類似度がFew-Shot性能を左右することが示されている。

見落とされがちなポイントは「例を追加する」ことではなく「どの例を選ぶか」にある。偶然にも同じパターンの例が3つ並んでいれば、モデルはほとんど何も新しく学ばない。記事では、TF-IDFベクトルとコサイン類似度を使って最大限に多様な例を選ぶコードを提示している：

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity

def select_diverse_examples(candidates: list[str], k: int = 3) -> list[str]:
    vectorizer = TfidfVectorizer(stop_words="english")
    vectors = vectorizer.fit_transform(candidates)
    similarity_matrix = cosine_similarity(vectors)
    selected_idx = [0]
    while len(selected_idx) < k:
        remaining = [i for i in range(len(candidates)) if i not in selected_idx]
        scores = [(i, 1 - max(similarity_matrix[i][j] for j in selected_idx)) for i in remaining]
        best_idx = max(scores, key=lambda pair: pair[1])[0]
        selected_idx.append(best_idx)
    return [candidates[i] for i in selected_idx]

このトランスクリプトタスクであれば、「確定した担当者がいる例」「担当者が未解決の例」「後からタスクが統合される例」の3パターンが理想的なFew-Shotセットだ。

ロールとペルソナの割り当て

「アクションアイテムを抽出して」という汎用指示より、「何百もの会議を経験してきた細心の秘書」というロールを与えることで、モデルが読む前から曖昧さへの警戒モードに入る。担当者の途中変更のような見落としやすい箇所に対して、ロール付きの指示が有効に機能する。

ロールプロンプティングの効果は、タスクの難易度や曖昧さが高いほど顕在化しやすい。汎用的な指示で十分に機能しているケースに対してロールを追加しても改善幅は小さく、逆に真に曖昧なケースではロールの有無で結果が明確に分かれることが多い。記事はこの戦略を単独で評価し、担当者ミスや曖昧なタスク統合の検出精度が向上したことを示している。

Chain-of-Thoughtの活用とコスト最適化

モデルに段階的に推論させる手法であるChain-of-Thought（CoT）は、フロンティアモデルが内部的に推論するようになった現在、万能ではなくなっている。ただし「担当者が会話途中で変わる」ような真に曖昧なケースでは、「最終確定した担当者を全会話を通じてトレースしてから回答せよ」という推論指示が明確に結果を変える。

コスト面での注目点として、記事はChain of Draftと呼ばれる派生手法を紹介している。Chain of Draftは、Xu et al.（2025）の論文「Chain of Draft: Thinking Faster by Writing Less」で提案された手法で、各推論ステップを5語程度の最小限のドラフトに圧縮することで、通常のCoTと同等の精度を推論トークンの7.6%で達成できるとされる。推論ステップを省略するのではなく「圧縮する」点が特徴で、精度を落とさずにレイテンシとコストを大幅に削減できる。

自動化された反復的プロンプト最適化

5つの中で最も高度な戦略が、自動化された反復的プロンプト最適化だ。候補となる指示フラグメントを用意し、テストケースに対してスコアリングしながら山登り法（hill-climbing）で最良の組み合わせを探索する。

記事では「extract action items as JSON」という最小限の指示から始めてスコア51.6%、3イテレーションでスコア1.000（完璧）に到達した結果を示している。注目すべきは、5つあった候補フラグメントのうち3つだけで完璧なスコアに達した点だ。「効きそうな指示を全部追加する」のではなく「最小有効な修正を見つける」ことがこの手法の強みである。

この戦略は実装コストが高い分、他の4戦略では改善が頭打ちになったタスクに対して特に有効だ。テストケースの品質がそのままスコアリングの品質に直結するため、評価セットの設計自体に注意を払う必要がある。

まとめ

5つの戦略に共通する本質は一つ、「プロンプトが良くなりそうな変更を当てずっぽうにやめ、実際のテストケースに対して測定可能な変更を個別に検証する」という規律だ。出力が一見もっともらしく見えても、担当者のミス・タスクの漏れ・存在しないオーナーの創作といったエラーは、コードレビューではなく見逃したデッドラインや落ちたチケットとして発覚する。

詳細は5 Prompt Optimization Strategies That Actually Improve LLM Outputを参照していただきたい。