Claudeのプロンプトエンジニアリングは、単に「うまい命令文」を作る作業ではありません。2026年現在のClaude公式ドキュメントでは、Claude Fable 5.1、Mythos 5.1、Opus 5、Sonnet 5、Opus 4.8など、モデルごとの差分を踏まえた設計が重視されています。特に、明確な成功条件、十分な文脈、XMLタグによる構造化、例示、長文コンテキストの配置、ツール利用時の指示が成果を左右します。本記事では、業務でそのまま使える20個のテンプレートと、継続改善の考え方を整理します。
Claudeのプロンプトエンジニアリングが重要な理由
Claudeは自然な指示にも強い一方で、業務利用では「誰に向けた成果物か」「どの形式で返すか」「どの情報を優先するか」を明示した方が安定します。公式ドキュメントでも、目的や背景、出力形式、制約、成功条件を具体的に書くことが推奨されています。たとえば「資料を作って」よりも、「営業部長向けに、5分で読める提案メモを、課題、提案、次アクションの3部構成で作って」と書く方が、初回から使える出力になりやすいです。
Claudeプロンプトの基本原則：XMLタグとthinkingの活用
Claude向けの基本形は、role、context、task、constraints、output_format、examples、success_criteriaを分けることです。長い資料や複数の入力を扱う場合は、<documents>、<document>、<source>、<document_content>のようにXMLタグで囲むと、Claudeが情報の境界を誤認しにくくなります。公式ドキュメントでも、複雑なプロンプトでは情報種類ごとにタグを分ける方法が紹介されています。
【議事録・要約】業務テンプレート1〜3
テンプレート1：会議メモから決定事項と宿題を抽出します。「<transcript>に会議メモを入れます。決定事項、未決事項、担当者つきToDo、次回確認事項に分けて、重複を統合してください。推測で担当者を補完せず、不明な場合は不明と書いてください。」この形にすると、単なる要約ではなく実務で使う議事録になります。
テンプレート2：長文資料を経営向けに圧縮します。「<document>を読み、役員向けに3分で読める要約を作ってください。背景、重要な数字、意思決定が必要な点、リスク、推奨アクションの順に書いてください。本文から根拠になる表現を2つ引用してください。」引用を求めることで、結論だけが独り歩きしにくくなります。
テンプレート3：Slackスレッドを整理します。「以下のスレッドを、論点、結論、残課題、次に誰が何をするかに分けて整理してください。雑談や同意だけの発言は省略し、意思決定に影響する発言だけ残してください。」Claude TagやSlack連携で使う場合は、対象チャンネルと期間を明示するとさらに安定します。
【メール・ビジネス文書作成】テンプレート4〜7
テンプレート4：丁寧な依頼メール。「相手は既存顧客です。目的は追加資料の依頼です。失礼なく、しかし返信期限は明確にしてください。件名、本文、追伸の3部構成で、本文は600字以内にしてください。」相手との関係性、目的、期限、文字数を入れると、過度に長い文面を防げます。
テンプレート5：謝罪と再発防止。「<incident>の内容をもとに、顧客向けのお詫び文を作成してください。言い訳に見える表現を避け、事実、影響範囲、対応状況、再発防止、問い合わせ先の順で書いてください。未確認事項は断定しないでください。」法務やCSレビュー前のたたき台に向いています。
テンプレート6：社内告知。「新しい運用ルールを社内に告知します。対象者、開始日、変更点、やるべきこと、問い合わせ先を明確にし、Slack投稿として読みやすくしてください。強制感を抑えつつ、必須対応は曖昧にしないでください。」Slack用かメール用かを指定すると文体が整います。
テンプレート7：提案書の骨子。「<client_context>をもとに、提案書の章立てを作ってください。現状課題、あるべき姿、提案内容、導入ステップ、費用対効果、リスクと対策、次アクションを含めてください。各章に入れるべき要点も3つずつ書いてください。」営業資料の初期構成に使えます。
【コードレビュー・開発支援】テンプレート8〜10
テンプレート8：PRレビュー。「<diff>を読み、バグ、セキュリティ、パフォーマンス、保守性、テスト不足の観点でレビューしてください。重大度をHigh/Medium/Lowで示し、修正案がある場合は最小差分で提案してください。スタイルだけの指摘は最後にまとめてください。」レビュー観点を先に固定すると、指摘の粒度が揃います。
テンプレート9：設計相談。「この機能を実装する前に、既存設計への影響を洗い出してください。データモデル、API、権限、移行、テスト、運用監視の観点でリスクを列挙し、最小実装案と将来拡張案を分けてください。」コードを書く前の壁打ちとして有効です。
テンプレート10：障害調査。「<logs>と<recent_changes>を読み、原因仮説を優先度順に並べてください。各仮説について、確認コマンド、期待される結果、外れた場合の次の確認を示してください。断定せず、証拠と推測を分けてください。」運用では、結論より検証手順が重要です。
【データ分析・レポート作成】テンプレート11〜13
テンプレート11：KPI変動分析。「<data>のKPIを見て、前期間比で大きく動いた指標を特定してください。変化量、想定原因、追加で確認すべきデータ、次アクションを表形式でまとめてください。相関と因果を混同しないでください。」分析結果を意思決定につなげやすくなります。
テンプレート12：アンケート自由回答分析。「自由回答を、頻出テーマ、代表コメント、ポジティブ/ネガティブ傾向、改善機会に分類してください。少数意見でも事業上重要なものは別枠で残してください。」単純な頻度集計だけでなく、重要度を見落とさないための指示です。
テンプレート13：月次レポート。「今月の実績を、経営向けにA4一枚相当でまとめてください。良かった点、悪かった点、原因、来月の打ち手、意思決定が必要な点を含め、数字は必ず入力データにあるものだけを使ってください。」数値の捏造を避けるため、入力データ限定の条件を入れます。
【企画書・マニュアル作成】テンプレート14〜16
テンプレート14：新規企画のたたき台。「<idea>をもとに、顧客課題、ターゲット、提供価値、競合との差分、MVP、検証方法、撤退条件を整理してください。楽観的な前提と不確実な前提を分けてください。」企画初期にありがちな過度な期待を抑えられます。
テンプレート15：業務マニュアル。「<procedure>を新人向けの手順書にしてください。目的、前提条件、操作手順、確認ポイント、よくあるミス、エスカレーション条件を含めてください。1ステップ1操作で書き、判断が必要な箇所は条件分岐で示してください。」属人化した作業の標準化に向きます。
テンプレート16：研修教材。「このテーマを90分の社内研修にしてください。到達目標、前提知識、タイムテーブル、演習、理解度チェック、持ち帰り課題を作ってください。受講者は非エンジニアです。」対象者と時間を指定すると、教材の密度が合いやすくなります。
【翻訳・多言語対応】テンプレート17〜18
テンプレート17：ビジネス翻訳。「以下の日本語を英語に翻訳してください。直訳ではなく、米国のB2B SaaS企業のメールとして自然な表現にしてください。固有名詞、数値、契約条件は変えないでください。迷う表現があれば翻訳後に注記してください。」文体と不変条件を明示します。
テンプレート18：ローカライズレビュー。「<translation>を読み、意味のズレ、不自然な表現、文化的に避けるべき表現、専門用語の統一をチェックしてください。修正案は原文、現訳、改善案、理由の4列で出してください。」翻訳作業とレビュー作業を分けると品質が安定します。
【FAQ・カスタマーサポート】テンプレート19〜20
テンプレート19：FAQ作成。「<support_tickets>から、顧客が繰り返し聞いている質問を抽出し、FAQにしてください。質問、回答、補足リンク、担当部署、更新が必要な条件を含めてください。回答は顧客にそのまま見せられる丁寧な文体にしてください。」サポートナレッジの初期整備に使えます。
テンプレート20：難しい問い合わせの返信。「顧客は不満を持っています。<ticket>を読み、共感、事実確認、現在できること、できないこと、次回連絡予定を含む返信案を作ってください。過剰な約束や責任の断定は避けてください。」炎上しやすい場面では、できることとできないことの線引きが重要です。
プロンプトテンプレートの運用と改善のポイント
テンプレートは作って終わりではありません。部署ごとに、良い出力例、悪い出力例、修正理由を残し、定期的に見直すことで精度が上がります。公式ドキュメントでも、例示は関連性が高く、多様で、構造化されているほど効果的だと説明されています。1つの神プロンプトを探すより、評価基準と改善ログを持つ方が組織利用では再現性があります。
体系的に学ぶならClaude研修の活用がおすすめ
自社業務に合わせたClaudeプロンプトテンプレートを整備したい方は、 Claude活用研修・業務設計の相談はこちら 。テンプレート作成、評価軸、社内展開までまとめて支援します。
