プロンプトエンジニアリング本を選んだ理由
Claude Codeでサイトを2つ運営している現在、プロンプトは「その場で考える」から「設計して再利用する」フェーズに移行している。
『生成AIのプロンプトエンジニアリング』（James Phoenix, Mike Taylor著・オライリー・ジャパン）を手に取ったのは、タイトル通り「生成AI」全般を対象にしている点が決め手だった。Claude固有の最適化ではなく、モデルを問わず通用する原則を知りたかった。
読後の感想を一言でまとめるなら「プロンプトは設計図である」。その場しのぎの指示文ではなく、再現性のある構造として組み立てる方法論が整理されていた。
本書の構成は実務指向で、Chain-of-Thought（思考の連鎖）・Few-shot学習・評価設計・モデル選定基準が横断的に論じられている。特に評価設計の章は、「良いプロンプト」を定量的に測る視点が新鮮だった。
私が業務用に作ったテンプレは3つ。すべて本書の原則に沿って設計し、実際の業務で繰り返し使っている。
テンプレ1：議事録要約プロンプト（Few-shot設計）
最初に作ったのは、打ち合わせ録音からの議事録生成プロンプト。顧客との契約内容確認・見積調整・スケジュール折衝など、記録が必要な場面で使う。
本書のFew-shot学習の章を参考に、「良い要約例」を3パターン事前に与える構造にした。例示は実際の過去議事録から抽出し、「決定事項・保留事項・次回確認項目」の3要素を必ず含む形式を固定した。
プロンプトの骨格は以下の通り：
あなたは議事録作成の専門家です。以下の録音テキストから、
決定事項・保留事項・次回確認項目の3要素を抽出してください。
【例1】（過去の良い要約例を提示）
【例2】（同上）
【例3】（同上）
【録音テキスト】
（実際の打ち合わせ内容を貼り付け）Few-shot例示の効果は明確で、例示なしの場合と比べて「次回確認項目」の抽出精度が体感で3割向上した。特に曖昧な表現（「また相談しましょう」「後日確認します」等）を拾い上げる能力が上がった。
本書では「例示は3〜5件が最適」「例示の質が出力を左右する」と指摘されており、実際にその通りだった。
テンプレ2：報告書下書き生成プロンプト（CoT設計）
2つ目は報告書の下書き生成。契約書類・月次報告・税理士提出資料など、形式が固定されている文書作成に使う。
ここで適用したのはChain-of-Thought（CoT）設計。本書では「ステップを明示すると推論精度が上がる」と繰り返し強調されており、複雑なタスクほど効果が高いとされている。
報告書生成プロンプトは以下の3ステップ構造：
以下の手順で報告書を作成してください：
ステップ1：提供された資料から数値・日付・固有名詞を抽出
ステップ2：抽出した要素を時系列に整理
ステップ3：定型フォーマットに当てはめて下書きを出力
【提供資料】
（元データを貼り付け）
【出力フォーマット】
1. 期間：
2. 実績：
3. 課題：
4. 次月予定：CoT導入前は「報告書を作ってください」と一言で指示していたが、出力が不安定で修正コストが高かった。ステップを明示することで、抽出漏れ・時系列の混乱が8割削減された。
本書では「CoTは推論過程を可視化する手法」と定義されており、デバッグ性能も向上する。実際、出力が期待と異なる場合も「どのステップで判断がズレたか」を特定しやすくなった。
テンプレ3：メール返信文案生成プロンプト（評価設計組み込み）
3つ目はメール返信の文案生成。取引先・税理士・金融機関とのやり取りで、丁寧さと簡潔さのバランスを取る必要がある場面で使う。
本書の評価設計の章を参考に、「良い返信文」の基準を3つ定義してプロンプトに組み込んだ：
あなたはビジネスメール作成の専門家です。
以下のメールに対する返信文案を、次の3基準を満たす形で作成してください：
【基準1】感謝または謝罪を冒頭に置く
【基準2】結論を先に、理由を後に書く
【基準3】300字以内に収める
【受信メール】
（相手からのメール本文を貼り付け）評価基準を事前に示すことで、出力の一貫性が劇的に向上した。特に「結論先行」の指示は、長文化・冗長化を防ぐのに効いている。
本書では「評価設計はプロンプト設計の一部である」と明言されており、「何を良しとするか」を明示しない限り、出力品質は安定しないと指摘されている。
メール文案生成では、生成後に自分で3基準を満たしているか確認する習慣も定着した。これは本書の「人間による評価ループ」の考え方をそのまま実装した形になっている。
モデル非依存の原則が実務で効く理由
本書の最大の価値は「モデル非依存」の視点だと感じた。Claude専用・GPT専用の最適化ではなく、どのLLMでも通用する原則を押さえることで、将来的なモデル乗り換えにも対応できる。
実際、上記3テンプレはClaude 3.5 Sonnetで設計したが、試しにGPT-4oでも同じプロンプトを流してみたところ、ほぼ同等の出力が得られた。Few-shot例示・CoT構造・評価基準の3要素は、モデルの違いを超えて機能する。
本書では「プロンプトエンジニアリングは設計思想である」と繰り返し述べられており、個別最適化よりも汎用性の高い構造を優先する姿勢が一貫している。
個人事業主の業務では、特定ツールへの依存リスクを下げることが重要だ。Claude Codeが使えなくなっても、プロンプト設計の原則を理解していれば、別のツールに移行できる。
今後は本書の後半で論じられている「プロンプトのバージョン管理」「A/Bテスト」にも取り組みたい。テンプレを育てる仕組みとして、実務に組み込む価値がある。
まとめ：プロンプトは「設計して再利用する」資産
プロンプトエンジニアリングを「その場の指示文作成術」と捉えていた段階から、「再利用可能な設計資産」として扱う段階へ移行できた。
Few-shot・CoT・評価設計の3要素を実務テンプレに組み込むことで、出力の一貫性・精度・デバッグ性能がすべて向上した。特に評価基準を事前に明示する設計は、人間による確認コストを削減する効果が大きい。
モデル非依存の原則を押さえておくことで、将来的なツール乗り換えにも対応できる。個人事業主の業務では、特定ツールへの依存リスクを下げることが長期的な生産性向上に繋がる。
プロンプトは書き捨てるものではなく、設計して蓄積する資産である。本書はその設計図の引き方を教えてくれる一冊だった。