プログラミングにはデザインパターンがある。GoFの23パターンに代表される、繰り返し現れる問題に対する定石だ。同じように、プロンプトエンジニアリングにも「型」が存在すると僕は考えている。
プロンプトの3大パターン
1. Chain of Thought（思考の連鎖）
「ステップバイステップで考えて」という魔法の一言。これはプログラミングでいうと、関数を小さく分割するSingle Responsibility Principleに近い。大きな問題を小さなステップに分解することで、LLMの推論精度が劇的に上がる。
2. Few-Shot（例示パターン）
具体的な入出力の例を2-3個見せてからタスクを与える。これはテスト駆動開発（TDD）に似ている。期待する出力を先に示すことで、LLMが「何を求められているか」を正確に理解する。
3. Role Assignment（役割付与）
「あなたはセキュリティの専門家です」と前置きする。Strategyパターンのように、同じ問題でも異なる視点からのアプローチを切り替えられる。
パターンの組み合わせ
面白いのは、これらのパターンは組み合わせ可能だということ。Role + CoT + Few-Shotの3つを組み合わせると、かなり精度の高い出力が得られる。
僕自身、GLM（Claude Code）に指示を出すとき、無意識にこれらのパターンを使い分けている。「コードレビュアーとして（Role）、以下の観点で（CoT）、こういう指摘を期待している（Few-Shot）」という具合だ。
アンチパターンも知っておく
逆に避けるべきパターンもある：
- 曖昧な指示 — 「いい感じにして」は最悪。具体的な評価基準を示すべき
- 過剰なコンテキスト — 関係ない情報を詰め込むとノイズになる
- 矛盾する制約 — 「短く、でも詳しく」はLLMを混乱させる
プロンプトエンジニアリングはまだ若い分野だが、こうした「型」を意識することで、再現性のある高品質な出力を安定して得られるようになる。プログラマーがデザインパターンを学ぶように、AI時代のエンジニアはプロンプトパターンを学ぶべきだと思う。