# Claudeへの依頼文は、役割・仕事・資料・出力形式・根拠・承認者の六つで書く 一度で使える回答を得るためのClaudeへの依頼文の書き方。役割、一つの成果物、使ってよい資料、出力形式、根拠のルール、承認者を依頼文に含める方法を解説します。 URL: https://www.hiresteve.ai/ja/blog/claude-job-brief 最終更新: 2026-10-12 Claudeへの依頼文には六つの要素を入れます。Claudeに担わせる役割、一つに絞った仕事、使ってよい資料、出力形式、根拠のルール、結果を承認する人です。送信前にこの六つがそろっているか確認してください。 ## 仕事の前に、役割を伝える Anthropicの[プロンプト作成ガイド](https://platform.claude.com/docs/ja/build-with-claude/prompt-engineering/claude-prompting-best-practices)（2026年9月16日確認）は、Claudeを「優秀だが、社内の慣習や業務の流れを知らない新入社員」として扱うよう勧めています。同じページは、システムプロンプトで役割を設定すると振る舞いと文体が定まり、一文でも効果があると説明しています。[cloudpackのClaudeプロンプトガイド](https://cloudpack.jp/column/generative-ai/claude-prompt-guide.html)（2026年4月19日更新）も、特定の役割を与える「ロールプロンプティング」を基本の手法として挙げています。 Anthropicの開発者向けガイドでは、役割をAPIのシステムプロンプトに置きます。通常のClaudeチャットでは、役割をメッセージか[プロジェクトの指示](/ja/blog/claude-project-setup)に書きます。指示はそのプロジェクト内のチャットに適用されます。一度きりなら、依頼文の冒頭に「あなたは[会社名]のプロダクトマーケターで、商談前の営業担当者が2分で読むバトルカードの一行を作成します」のように書きます。読み手と文体を一文で示してください。 ## 成果物を一つに絞り、使ってよい資料を列挙する 依頼する成果物は一つにします。「バトルカードを手伝って」では一般的な説明が返ってきます。「[競合名]のバトルカードの、価格に関する反論の行を作成して」なら、営業担当者が読める形で返ってきます。成果物が二つあるなら、依頼文も二つに分けてください。 次に、Claudeが使ってよい資料を列挙し、それ以外は使わないと明記します。競合の料金ページの本文をURLとコピーした日付付きで貼り、自社の料金表を添付し、該当するプロジェクト内のファイル名を書きます。そして「これらの資料だけを使い、資料で分からない点はその旨を書いてください」と添えます。この境界がないと、Claudeが一般知識で空白を補い、読みやすい文章に未確認の情報が入る可能性があります。貼り付けてよい情報かどうかは、[GTMの機密情報を守る方法](/ja/blog/safe-gtm-data)で先に確認してください。 Richard King氏は[The Claude skill stack for product marketing（英語）](https://productmarketingalliance.substack.com/p/the-claude-skill-stack-for-product-marketing)（Product Marketing Alliance、2026年4月2日）で、文脈を整える前に作業を走らせるのは「入社初日の新人にポジショニング資料を書かせるようなもの」だと述べています。 ## 出力形式を、貼り付け先に合わせて指定する Anthropicの同じページは、望む出力形式と制約を具体的に指定し、順序が重要なら番号付きの手順で指示するよう勧めています。PMMの仕事では、回答をどこに貼り付けるかを書くのが実用的です。バトルカードの一行には決まった形があります。依頼文に書かなければ、Claudeが選んだ形式を自分で直すことになる場合があります。 一つの仕事について六つの要素を埋めた例です。競合名、ファイル名、上限は練習用の仮の値で、実際のカードではありません。 | 要素 | 依頼文に書く内容 | | --- | --- | | 役割 | [会社名]のプロダクトマーケター。読み手は商談前に2分しかない営業担当者 | | 仕事 | [競合名]のバトルカードの、価格に関する反論の行を作成する | | 資料 | [競合名]の料金ページ本文（[日付]にコピー、URL付き）、自社の料金表v[n]、プロジェクト内の `competitors/[競合名].md` | | 出力形式 | 3行。買い手の言葉での反論（40字以内）、自社の回答（80字以内）、出典URL付きの根拠を一つ。見出しなしのプレーンテキスト | | 根拠のルール | 数値と機能の主張には、すべて出典URLと日付を付ける。出典がなければ主張を書かず「未確認」と記す | | 承認者 | [氏名]（バトルカード担当者）。営業資料に入れる前に確認 | 出力形式は、この表と同じ程度まで絞って書きます。文字数の上限と「見出しなしのプレーンテキスト」という指定は、体裁の修正を減らします。[営業向けバトルカードの記事](/ja/blog/battlecards-sales-actually-uses)では、商談中に参照しやすい三行の形式を紹介しています。 ## 根拠のルールを依頼文に書く 根拠のルールは一文です。重要な主張にはすべて、Claudeに渡した資料の中の出典を付け、出典がなければ削除するか「未確認」と明記する。プロジェクトの指示に同じ内容があっても、依頼文に毎回書いてください。cloudpackのガイドにも、事実、数値、仕様には根拠となる情報源を括弧内に示すよう指示する例があります。 根拠のルールがない依頼文では、読みやすい文章でも事実関係の確認が必要です。ルールを入れると、出典付きの行にはURLを付け、根拠のない行にはその旨を書くようClaudeに明示できます。そのうえで、根拠を探すか、その点を落とすかを判断します。競合一社分をまとめて扱うなら、このルールは主張ごとに日付と状態を持つ[主張の台帳](/ja/blog/competitive-claim-ledger)に育ちます。依頼文一つなら一文で十分です。 ## 承認者を決める 誰が承認し、回答が次にどこへ行くのかを依頼文に書きます。「[氏名]が営業資料に入れる前に確認します」で足ります。承認者は、その使い道に責任を持つ人です。バトルカードの一行ならバトルカードの担当者、ポジショニングの文言ならメッセージの承認担当者です。この点は私たちの推奨で、上で挙げたAnthropicや実務家の解説には出てきません。 承認者が決まっていないと、確認前の回答が使われるおそれがあります。その結果、未確認の価格情報が商談に持ち込まれる可能性があります。 ## 使う前に確認する **依頼文だけでは出典と承認を確認できません** 依頼文は、目標とする出力形式と出典の扱いをClaudeに伝えます。Webアクセスが有効ならClaudeは出典を取得できますが、その箇所は自分で確認してください。Claudeは組織の承認規程を確実には推測できないため、依頼文に承認者を書きます。 - 出典をすべて開き、引用元の箇所がその行を裏付けているか確認する。 - 各行が渡した資料の範囲に収まっているか確認する。範囲外の記述は推測として扱う。 - 出力が指定した形式に沿っていて、そのまま貼り付けられるか確認する。 - 根拠のない点がすべて明記され、普通の文章に紛れていないか確認する。 - 承認者に送り、返事があるまでは下書きとして扱う。 文章が読みやすいと、出典の確認は省略されがちです。手順は[AIの調査結果を検証する方法](/ja/blog/verify-ai-research)で説明しています。 ## 次の仕事に使い回す 仕事が変わっても六つの要素は変わらず、差し替えるのは仕事と資料の二行です。依頼文をひな形として保存してください。プロジェクトを使うなら、役割と根拠のルールは指示に置き、個別の依頼文には残りを書きます。同僚への引き継ぎは[Claudeの業務手順を引き継ぐ](/ja/blog/claude-workflow-handoff)で扱います。 角括弧を埋め、プロジェクトの指示で済んでいる行は削除して使ってください。 プロンプト：六要素の依頼文 ```prompt 役割：あなたは[会社名]の[役割]です。読み手は[読み手]で、[時間や状況]です。 仕事：[貼り付け先]向けに[成果物を一つ]を作成してください。 資料：次の資料だけを使ってください：[URLと日付付きの貼り付け本文]、[添付ファイル]、[プロジェクト内のファイル]。資料で分からない点はその旨を書いてください。 出力形式：[項目や行の構成、順序、文字数の上限、形式]。 根拠：重要な主張にはすべて出典URLと日付を付けてください。出典がなければ主張を書かず、「未確認」と記してください。 承認：[氏名]が使用前に確認します。それまでは下書きとして扱ってください。 ``` ## Steveが合う場合と、合わない場合 一度きりの依頼なら、ここまでの方法で完結します。メモ一つ、価格の質問一つのために監視製品を入れる理由はありません。方法が足りなくなるのは、同じ依頼文を競合ごとに、料金ページが変わるたびに実行し、上の確認を毎回繰り返す状態になったときです。 Steveはこのケースをバトルカードで扱います。Steveのバトルカードでは、各主張に状態(確認済み、要確認、未確認)が表示され、根拠となる出典へのリンクが付きます。ニュースで主張が変わると、Steveが更新を提案し、現行版を維持する、更新を適用する、両方を採用する、のいずれかを選べます。Steveは任意の仕事の依頼文を書く製品ではなく、単発のポジショニングメモや口コミ分析には、上の六行が引き続き必要です。 継続的なバトルカードの更新が仕事なら、[Steveの競合リサーチ](/ja/products/research)を確認し、利用中のアカウントでの提供状況を確かめてください。そうでなければ、六行の依頼文を保存して使います。 ## よくある質問 ### プロジェクトを使っていれば、役割は毎回書かなくてよいですか？ プロジェクトの指示に役割が書いてあれば不要です。恒常的な役割は指示に置き、個別の依頼文には仕事、資料、出力形式、根拠のルールを書きます。通常のチャットなら、最初の一文で役割を伝えてください。 ### 出力形式はどこまで細かく指定しますか？ 回答をそのまま貼り付け先に使える程度まで指定します。項目や行の構成、順序、文字数の上限、各項目に含める内容を書いてください。体裁を繰り返し直しているなら、不足している指定を依頼文に加えます。 ### 出典のない主張はどう扱いますか？ 削除するか「未確認」と明記し、通常の文章として残しません。根拠のない記述には印を付け、確認に必要な情報を挙げるようClaudeに伝えます。根拠を探すか、その点を落とすかは自分で判断します。 ### 依頼文はどこに保存しておきますか？ 貼り付けて編集できるテキストとして保存します。繰り返す仕事なら役割と根拠のルールはプロジェクトの指示に置き、仕事、資料、出力形式、承認者だけを書き直します。記入済みの依頼文は成果物と一緒に残し、次の担当者が経緯を追えるようにします。