元エンジニアPMのプロダクトマネージャーお役立ち情報

プロダクトとビジネスの両輪どっちも回してる人 事業戦略やプロダクトマネジメントに関する情報を発信

CLAUDE.mdテンプレート集 -- PM・企画・事業開発向け

CLAUDE.mdのテンプレートをネットで探していた時期がありました。見つかるのはほとんどがエンジニア向けのもので、「コーディング規約を守れ」「ESLintの設定に従え」「テストを必ず書け」。PM・企画職の私にはまるで刺さらなかった。

結局、自力で試行錯誤しながらゼロから作ることになり、そこから半年。何度も書き直して、失敗して、ようやく「これが私の業務に合っている」と言えるテンプレートにたどり着きました。この記事では、その過程で作ったPM・企画・事業開発向けのCLAUDE.mdテンプレートを3パターン紹介します。コピペして使い始められますが、「CLAUDE.mdの育て方」で書いた通り、育てる前提で使ってください。

テンプレートの使い方と注意点

最初にはっきり言っておくと、テンプレートはスタート地点であって完成形ではありません。そのまま使い続けるのはもったいない。

私の業務に合わせてカスタマイズすることで初めて効果が出るものです。A01の「3つだけ書けばいい」から始めて「育てるサイクル」に乗せる流れを前提として読んでもらえると助かります。

テンプレートの分量は意図的に少なくしています。各テンプレートは30行以内を目安にしました。CLAUDE.mdに指示を詰め込みすぎると150-200行あたりからClaude Codeがルールを見落とし始めるという話は体感としても実感があり、コンパクトに保つことを優先しています。

テンプレート1: PM・プロダクトマネージャー向け

プロダクトのロードマップ管理、ユーザーインタビュー分析、PRD作成が中心業務の方向けです。

# CLAUDE.md

## あなたの役割
あなたは[プロダクト名]のプロダクトマネジメントを支援するAIアシスタントです

## 基本ルール
- 日本語で応答
- 事実と推論は明確に分ける(「データ上は〜」vs「推測では〜」)
- ソースを明示する

## 業務コンテキスト
- 担当プロダクト: [プロダクト名/概要]
- 主な業務: ロードマップ管理、ユーザーインタビュー分析、PRD作成
- ステークホルダー: 開発チーム、デザインチーム、経営層
- 意思決定基準: ユーザー価値 > 技術的興味 > 社内都合

## 禁止事項
- 推測で数字を作らない(データがなければ「不明」と明記)
- ファイルを勝手に削除しない
- ユーザーインタビューの生データを要約せずに捨てない

ポイントは「意思決定基準」のセクションです。「ユーザー価値 > 技術的興味 > 社内都合」のように優先順位を明示しておくと、Claude Codeに判断を求めたときにこの基準に沿った提案が返ってくるようになります。

禁止事項の「ユーザーインタビューの生データを要約せずに捨てない」は、PM業務ならではのルール。一度、インタビューの分析を頼んだ際にClaude Codeが要約だけ返して元の発言ニュアンスが消えていたことがあり、追加したものです。

テンプレート2: 企画・事業開発向け

市場調査、競合分析、事業計画書の作成が主な業務の方に向けたテンプレートです。

# CLAUDE.md

## あなたの役割
あなたは[事業名]の事業企画・戦略策定を支援するAIアシスタントです

## 基本ルール
- 日本語で応答
- 事実と推論は分ける
- 仮説を立てる時は前提条件を明示する

## 業務コンテキスト
- 担当領域: [事業ドメイン]の新規事業開発
- 主な業務: 市場調査、競合分析、事業計画書作成、収益モデル設計
- データソース: [利用する主要データ]
- レポート形式: 結論→根拠→詳細の順で書く

## 禁止事項
- 推測で市場規模やシェアの数字を作らない
- 機密情報(社名・事業数値)を外部出力に含めない
- 過度に楽観的な見通しを書かない(リスクも併記する)

事業開発向けで特に重要なのは、禁止事項の最後の項目。Claude Codeは聞かれると前向きな回答を返す傾向がある。「この事業の見通しは?」と聞けば、良い面を強調した回答が返ってきやすい。「リスクも併記する」を入れておかないと、楽観的すぎる事業計画を作ってしまうリスクがありました。

「機密情報を外部出力に含めない」も事業開発では必須のルールです。社内の事業数値や未公開の戦略を含むファイルを扱うことが多いので、この1行があるだけでClaude Codeが機密情報の取り扱いに慎重になります。

「レポート形式: 結論→根拠→詳細の順で書く」も地味に効いている設定です。忙しい経営層や事業責任者に提出するレポートは、最初の3行で要点が伝わるかどうかが勝負。このルールを入れた後は、Claude Codeが作るレポートの読みやすさが明らかに上がりました。詳細から積み上げていく構成だと、結論にたどり着く前に読むのをやめられてしまう。最初に結論を置けば、読み手は興味のある部分だけ深掘りできる。この違いは大きかった。

テンプレート3: リサーチ・分析特化型

データ分析やリサーチが業務の中心にある方向けのテンプレートです。PM兼アナリスト的な役割の方にも合うと思います。

# CLAUDE.md

## あなたの役割
あなたは[チーム名]のリサーチ・データ分析を支援するAIアシスタントです

## 基本ルール
- 日本語で応答
- 数値には必ず出典と時点を付記する
- グラフや表が適切な場面ではマークダウンの表で提示する

## 業務コンテキスト
- 分析対象: [業界/市場/顧客セグメント]
- 主なデータ: SQLでのデータ抽出、外部レポート、アンケート結果
- レポート頻度: 週次サマリー、月次詳細レポート
- 分析フレームワーク: PEST、3C、ファイブフォース等を状況に応じて使う

## 禁止事項
- 出典のない数値を書かない
- データの列ヘッダー(年度・単位・カテゴリ)を確認せずに数値を引用しない
- 前回の分析と矛盾する結論を出す時は、変化の理由を明示する

リサーチ特化型は「データの正確性」に全振りした設計になっています。禁止事項の「列ヘッダーを確認せずに数値を引用しない」は、過去に年度を取り違えた失敗から追加したルールでした。FY26のデータを見ているつもりがFY27の列を読んでいた、というミスは、列ヘッダーの確認を明示的に指示するだけで防げるようになった。

「前回の分析と矛盾する結論を出す時は理由を明示する」も地味に効くルールです。週次レポートを積み重ねていくと、先週と今週で結論が変わることがある。変化の理由が書いてあれば問題ないけれど、無言で変わると読む側が混乱します。

「分析フレームワーク: PEST、3C、ファイブフォース等を状況に応じて使う」の一文も、実際に書いておいて良かった項目です。このルールがないと、Claude Codeは毎回同じフレームワーク(だいたい3C)に偏った分析を返してくる傾向がありました。市場環境を見るならPEST、競争構造ならファイブフォース、と状況に応じて選んでほしい。このルールを入れた後は、「今回はPESTで分析しました」と理由付きでフレームワークを選んでくれるようになり、分析の幅が広がった実感がある。

テンプレートをカスタマイズするコツ

3つのテンプレートを紹介しましたが、そのまま使い続けるのではなく、それぞれの業務に合わせて育てていく前提で使ってほしいと思っています。

カスタマイズの進め方はシンプルです。まずテンプレートをコピペして1週間使う。その間に「足りない」「違う」と感じた点をメモする。そのメモをCLAUDE.mdに反映する。これを繰り返すだけです。

禁止事項は、先回りして書くよりも、実際にClaude Codeが失敗してから追加するほうが効果が高いと感じています。「こうなったら嫌だな」と想像して書いたルールよりも、実際に困った体験から生まれたルールのほうが具体的になりやすいからです。

テンプレートが100行を超えてきたら、分割を検討するタイミング。@import記法や.claude/rules/を使った分割方法は「.claude/rules/ 設計パターン」で詳しく解説している。

他の人のテンプレートを参考にするのは良いことだと思います。ただし、丸コピーは避けたほうがいい。私の業務に合わない指示が混ざっていると、Claude Codeが矛盾した指示に混乱して、かえって精度が落ちることがありました。

半年経った今、最初のテンプレートとは別物になっています。当初は役割の説明を冗長に書き連ねていましたが、今はディレクトリごとに最適化された振る舞いを定義する構成に進化しました。特に変わったのはプロジェクト管理の部分で、進行中の企画はドラフトとマスターをruleベースで自動更新する設計にしているため、常に最新の検討状況が整理された状態を保てています。テンプレートの3行が、半年で構造化されたルール群に育った。育てる前提で使い始めてよかったと思う瞬間です。


テンプレートはスタート地点です。PM向け、事業開発向け、リサーチ向けの3パターンを紹介しましたが、どれも「まず使って、育てる」前提で作りました。エンジニア向けのテンプレートが合わなかったという方は、近いものを1つ選んで今日から試してみてください。育て方の詳細は「CLAUDE.mdの育て方」を参照してください。