Claudeで仕様書とロードマップを書くPM実務パターン

PMがClaudeで仕様書やロードマップを書くとき、軸になるのはProjects・Artifacts・Skillsの3機能です。Projectsに仕様の前提知識と過去の意思決定を集約し、Artifactsでロードマップや仕様書のドラフトをバージョン管理しながら育て、Skillsで社内のPRDフォーマットをテンプレート化する組み合わせが実務で機能します。この3つの役割分担と、PM特有のつまずきどころまでを扱います。

Claudeで仕様書とロードマップはどこまで作れるか

ゼロから完成品までの一気通貫では作れませんが、下書き・整形・レビューの反復は大きく圧縮できます。Claudeは背景・目的・受け入れ条件が揃ったPRDの叩き台や、構造化されたロードマップの表を数分で生成します。機能の優先順位や合意事項そのものを決めるのは、引き続きPMの仕事です。

この圧縮を支えるのが3機能の役割分担です。ドラフトを作るのはProjects×Artifacts、繰り返し使うフォーマットを固定するのはSkills、という組み合わせになります。本稿の対象はClaude(chat)とClaude Desktop向けの3機能で、Claude Codeにも同名の機能がありますが配置や共有条件が異なります。

仕様書の前提知識をProjectsに一本化する

Project knowledgeは、プロジェクト内のすべての会話が共通で参照する資料置き場です。PRDを書くたびにリサーチメモや過去の意思決定を説明し直していた手間を、ここに集約することで省けます。

仕様書作成では、ユーザーインタビューの要約・競合調査・既存の仕様書・社内用語集の4種類を入れておくと効果が出ます。これらをknowledgeに追加し、Project instructionsに「新機能の仕様書は背景・目的・非対象範囲・受け入れ条件の順で書く」のような出力ルールを設定すると、プロジェクト内のどの会話からPRDを頼んでも同じ骨格の文書が返ってきます。

Project knowledgeに追加できるファイルは1ファイル30MBまでで、対応形式はPDF・DOCX・CSV・TXT・HTML・ODT・RTF・EPUB・JSON、コード実行を有効にすればXLSXも扱えます。ファイル数自体に上限はなく、合計がコンテキストウィンドウに収まっていれば追加を続けられる仕組みです。PDFは100ページ以下なら図表も解析対象になりますが、101〜1,000ページはテキストのみの処理になります。

無料プランでもProjectsは使え、作成できるのは最大5個までです。ナレッジの合計がコンテキスト上限に近づくと、RAG(検索拡張生成)が自動で有効になり、応答品質を保ったまま容量を最大10倍まで拡張する仕組みがあります。対象プランの範囲は公式ヘルプ記事間で表記が分かれているため、自分のプランで実際に有効かどうかはProjects内のRAGインジケータで確認するのが確実です。複数プロダクトを掛け持ちするPMが、機能領域ごとに仕様資料をまとめて積み上げたい場合、この拡張幅が実質的な差になり得ます。

Team・Enterpriseプランでは、プロジェクトをメンバーに共有できます。権限は「Can view」(閲覧とチャット利用のみ)と「Can edit」(instructions・knowledgeの編集、メンバー管理まで)の2段階で、共有方法も個別招待・メールの一括指定・組織全体への公開の3通りです。「仕様の編集はPMとリード開発者だけ、閲覧は関係者全員」というガバナンスをそのまま設定できます。

PRDのフォーマットをSkillsで固定する

Custom skillsとは、自分や組織の作業手順をパッケージ化し、必要なときにClaudeが自動で呼び出す仕組みです。公式ヘルプでも、会社独自のテンプレートで議事録を構成する、JIRAやAsanaのチケットをチームの規約に沿って作る、といった使い方が例示されています。PRDのフォーマット固定は、この延長線上にある使い方です。

2つは効く範囲が違います。Project instructionsはそのプロジェクト内のすべての会話に効き、Skillsは関連する作業のときだけ動的に読み込まれます。複数のプロジェクトをまたいで同じPRDフォーマットを使い回したいなら、instructionsではなくSkillsに寄せるのが向いています。

独自スキルの中心はSKILL.mdで、先頭のYAMLフロントマターにnameとdescriptionを書き、本文に手順をMarkdownで記述します。PRD用に組むなら、次のような形になります。

---
name: writing-prd
description: プロダクト要求仕様書(PRD)を社内フォーマットで作成する。新機能の仕様書作成やPRDの下書きを依頼されたときに使う。
---
 
# writing-prd
 
## 手順
 
1. 対象機能の背景・課題・ユーザーストーリーを箇条書きで整理する
2. 次の見出しでMarkdownを生成する: 背景 / 目的 / 非対象範囲 / ユーザーストーリー / 受け入れ条件 / 計測指標
3. 受け入れ条件はGiven-When-Then形式で書く
4. 数値目標が未確定の項目は「要確認」と明記し、勝手に数値を作らない
 
## 守るルール
 
- 見出しの順番は変えない
- 1セクションは3〜5行に収める
- 技術実装の詳細には踏み込まない(仕様のみ)

descriptionが、Claudeが「いまこのスキルを使うべきか」を判断する唯一の手がかりです。「PRDを作る」だけでなく「新機能の仕様書」のような依頼側の言い回しも含めておくと、雑な頼み方でも呼び出されやすくなる工夫です。作り方の詳細はClaude Skillsの使い方ガイドにまとめています。

Team・Enterpriseプランでは、組織のオーナーがスキルを全メンバーに配布できます(Organization provisioned skills)。配布されたスキルは各メンバーのスキル一覧に自動で表示されるため、PMが作ったPRDスキルをエンジニアやデザイナーにも同じフォーマットで使わせたい場合、この配布機能が起点になります。個人のPro・Maxプランでは独自スキルを作れますが、組織全体への自動配布はできません。

ロードマップをArtifactsで可視化する

Artifactsは、会話の返答とは別に独立したまとまりを持つ成果物を、専用ウィンドウへ切り出す機能です。ロードマップのように何度も手を入れる資料は、チャット本文に埋め込むよりArtifactとして育てるほうが扱いやすくなります。

実用的なのは、四半期ごとの施策を表にまとめたMarkdownドキュメント、あるいは時系列を示すダイアグラムのどちらかをArtifactとして生成させる形です。Markdownドキュメントの場合、該当箇所を選択して「Edit with Claude」をクリックすれば、チャットで場所を説明し直さずにその部分だけを直接修正できます。会話を重ねるたびにArtifactはバージョンとして積み重なり、セレクターで前のバージョンに戻したり、途中のメッセージを編集して別方向の案を試したりできます。

社外への見せ方は、プランで意味が変わります。Free・Pro・Maxの「Publish」はリンクを知る誰でも閲覧できる一般公開で、Claudeアカウントを持たない相手でも基本機能はそのまま使えます。Team・Enterpriseの「Share」は組織アカウントで認証したメンバー限定の共有です。四半期ロードマップを顧客向けに公開したいのか、社内限定に留めたいのかで、選ぶボタンが変わります。

仕様レビューをArtifactsのバージョンで進める

仕様レビューの本質は「どこを、なぜ直したか」を追えることです。ArtifactsのバージョンセレクターとMarkdownの部分編集を組み合わせると、レビューの往復をチャットのスクロールに頼らずに進められます。

まずProjectsの前提知識をもとにPRDドラフトをArtifactとして生成し、Team・EnterpriseならShareボタンでエンジニアとデザイナーに共有します。指摘は「Edit with Claude」で該当箇所に直接反映し、判断に迷う変更はバージョンを分けておくと、あとから「どの案を選んだか」を遡って確認できる作りです。実装の技術的な妥当性まで踏み込んで検討したい場合は、仕様の文章化はClaudeに残しつつ、リポジトリを読ませる作業だけClaude Codeに渡す切り分けが機能します。

PM業務の使い分け早見表

3機能をどのタスクに当てるかを一覧にしました。判断に迷ったら、まずこの表で当てはまる行を探すと早いです。

PM特有のよくあるつまずき

• Artifactを共有すると、そのArtifactを作った会話の添付資料にも相手がアクセスできます。競合調査の生データや未公開の財務情報を含む会話からロードマップArtifactを作ると、意図せず一緒に見えてしまいます。機密資料を含む会話からは、共有前に添付の扱いを確認します。
• 「空欄を埋めて」とロードマップを頼むと、根拠のない日付や優先順位をもっともらしく生成することがあります。未確定の項目は「要確認」のまま残す指示をProject instructionsやSkillのルールに明記しておくと、創作された数値がそのまま資料に残るのを防げます。
• Skillのdescriptionが「PRDを書く」だけのように曖昧だと、雑な頼み方をしたときに呼び出されず、毎回スキル名を指定する運用になりがちです。依頼側が使いそうな言い回しを具体的に入れておきます。
• 個人のPro・Maxプランで作った独自スキルは、そのアカウントの範囲でしか使えません。チーム全体に同じPRDスキルを配りたい場合は、Team・Enterpriseの組織オーナー権限が前提になります。

よくある質問

無料プランでも仕様書の管理を始められますか?

始められます。無料プランでもProjectsは使え、作成できるプロジェクトは最大5個までです。確実に言える無料プランの制約はこのプロジェクト数の上限で、RAGによるナレッジ容量拡張(最大10倍)が有料プラン限定かどうかは公式ヘルプの記載が分かれています。自分のプランで有効かどうかは、Projects内のRAGインジケータで確認できます。

Publishしたロードマップを外部の人が見るとき、ログインは必要ですか?

不要です。公開されたArtifactは、Claudeアカウントを持たない相手でも閲覧と基本操作をそのまま行えます。ログインが必要になるのは、AIを使った応答機能など一部の高度な機能を使うときだけです。

PRDテンプレートを組織全体に配布できるのは誰ですか?

Team・Enterpriseプランの組織オーナーです。オーナーがスキルを配布(Organization provisioned skills)すると、対象スキルは各メンバーのスキル一覧に自動で表示されます。個人プランのメンバーが自分のスキルを組織全体へ配ることはできません。

仕様のレビューは、ClaudeとClaude Codeのどちらに向きますか?

仕様の文章化やロードマップの整形はClaudeで完結します。既存のコードベースを読んで実装上の制約を確認するなど、リポジトリを触る作業が必要になった時点が、Claude Codeへ役割が移る境目です。両者の違いはClaude AIとClaude Codeの違いで詳しく比較しています。

まとめ

PMがClaudeで仕様書とロードマップを扱うときの基本形は、Projectsに前提知識を集約し、Skillsでフォーマットを固定し、Artifactsでドラフトをバージョン管理しながら社内外へ出す、という3層構造です。プランごとの上限(無料プランのプロジェクト5個、RAGによるナレッジ容量拡張(最大10倍)、Team・Enterprise限定の組織配布)を先に押さえておくと、チーム規模が変わったときの移行判断にも迷いません。

Artifact共有時に添付資料まで一緒に渡ってしまう点と、日付や優先順位をClaudeにそのまま埋めさせてしまう点。実務上の肝はこの2つです。SkillのルールやProject instructionsに明記しておけば、仕様書とロードマップの下書き作業を安心してClaudeに任せられます。機能の全体像から把握したい場合はClaude Projects完全ガイドを、プラン選びから検討する場合はClaudeの料金プラン比較を参照してください。