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

PMがClaudeで仕様書やロードマップを書くとき、軸になるのはProjects・Skills・Artifactsの3機能です。Projectsに仕様の前提知識を置き、SkillsでPRDの書式を固定し、Artifactsで下書きを育てて共有します。ただし共有では「相手がClaudeアカウントを持っているか」で選べる手段が変わります。ドラフトを作る前に、配り方を決めておく必要があります。機能の全体像はClaude Projects完全ガイドにあります。

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

下書き・整形・レビューの反復は大きく圧縮できます。背景・目的・受け入れ条件が揃ったPRDの叩き台や、四半期ごとのロードマップの表は数分で出てきます。一方で、機能の優先順位や合意事項そのものを決めるのはPMの仕事のままです。

本稿の対象はClaude(chat)とClaude Desktopです。Claude Codeにも同名の機能がありますが、配置や共有の条件が異なります。

仕様書の前提知識を置く場所はどこが適切か

Projectsの「Project knowledge」は、プロジェクト内のすべての会話が共通で参照する資料置き場です。ユーザーインタビューの要約・競合調査・既存の仕様書・社内用語集を入れ、Project instructionsに「新機能の仕様書は背景・目的・非対象範囲・受け入れ条件の順で書く」と書いておくと、どの会話からPRDを頼んでも同じ骨格で返ってきます。

資料の置き場所は3つあり、上限と向き不向きが違います。

Projectのファイルは、PDF以外では本文のテキストだけが抽出されます。仕様書に貼り込んだワイヤーフレームや図は、DOCXなどに埋め込まれていると読まれません。PDFは100ページ以下なら図表も解析対象で、101〜1,000ページはテキストのみです。画面設計を読ませたい場合は、PDFにして100ページ以内に収めるか、チャットに画像として直接添付します。

ナレッジが増えてコンテキストの上限に近づくと、有料プラン(Pro・Max・Team・Enterprise)ではRAG(検索拡張生成)が自動で有効になり、容量が最大10倍まで広がります。無料プランにはこの拡張がなく、Projectsの作成数も5個までです。RAGが働くと、Claudeは「project knowledge search」ツールで資料を検索して参照します。ファイル名を内容が分かるものにし、質問でも文書名を挙げると、探す範囲が絞られます。プランごとの違いはClaudeの料金プラン比較にあります。

Team・Enterpriseでは、プロジェクトをメンバーに共有できます。権限は「Can view」(閲覧とチャットのみ)と「Can edit」(instructionsとknowledgeの編集、メンバー管理まで)の2段階です。「仕様の編集はPMとリード開発者だけ、閲覧は関係者全員」という運用をそのまま設定できます。

PRDの書式をSkillsで固定するにはどうするか

知識はProjects、手順はSkillsと分けて考えると迷いません。Projectsは常に読み込まれる静的な背景知識で、Skillsは関連する作業のときだけ動的に読み込まれる手順です。複数のプロジェクトをまたいで同じPRDの書式を使うなら、instructionsではなくSkillsに寄せるほうが一度の設定で済みます。アカウント全体のInstructionsも含めた3層の違いはClaudeパーソナライズ機能の使い分け方にまとめています。

独自スキルの中心は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の使い方ガイドにあります。

スキルはFree・Pro・Max・Team・Enterpriseの全プランで使え、条件はコード実行を有効にしていることです。Excel・Word・PowerPoint・PDF向けのAnthropic標準スキルは、関連する場面で自動的に呼ばれます。独自のPRDスキルを書く前に、標準スキルで「頼むと勝手に使われる」感覚を一度つかんでおくと、descriptionの書き方も決めやすくなります。

Team・Enterpriseでは、組織のオーナーがスキルを全メンバーに配布できます(Organization provisioned skills)。配られたスキルは各メンバーのスキル一覧に自動で出て、既定で有効か無効かも選べます。PMが作ったPRDスキルをエンジニアやデザイナーにも同じ書式で使わせたいなら、この配布が起点です。

Skills Directoryには、Notion・Figma・Atlassianなどのパートナー製スキルもあります。対応するMCPコネクタとの組み合わせを想定した作りなので、チケット管理や設計ツールとつなぐ仕様作業では、自作の前に一覧を見る価値があります。

ロードマップと仕様書の下書きをArtifactsで育てる

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

2026年9月16日より前にチャットで作ったArtifactは旧形式(legacy)として扱われ、新しく作れるのはこの日以降の形式です。使えるプランはFree・Pro・Max・Team・Enterpriseの全てで、条件は「Settings > Capabilities」(Team・Enterpriseは「Organization settings > Capabilities」)でクラウドのコード実行とファイル作成がオンになっていることです。Artifactが作られないときは、まずここを見ます。

PMの文書作業で使いやすいのは、Docs・Slides・Designのテンプレートです。有料プラン向けのベータで、Pro・Max・Teamでは既定でオン、Enterpriseではオーナーが機能ごとにオンにします。

• Docs: チームと同時に書ける文書で、Word・PDF・Markdown・Google Docsに書き出せます。仕様書の本体向きです。
• Slides: ノートやチャットの内容から作るスライドで、PowerPointとPDFに書き出せます。ロードマップの説明会向きです。
• Design: モックアップやワンページャーで、自社のデザインシステムを反映できます。

直し方も2通りあります。DocsやMarkdown文書では、該当箇所を選択して「Edit with Claude」を押すと、場所を言葉で説明せずにその部分だけを直せます。別の案を試したいときは、途中のメッセージを編集して別のバージョンのチャットを作ると、元の作業を失わずに方向を変えられます。

ロードマップをタスク管理ツールと連動させたい場合、Artifactはコネクタ経由でAsana・Slack・Googleカレンダーなどを読み書きできます(Pro・Max・Team・Enterprise、webとDesktop)。見る人は自分のアカウントでつなぐため、データ元の権限を持たない人にはその部分がエラーで表示されます。保存領域は1つのArtifactで20MBまでのテキストで、個人用と全員共有用に分かれます。共有側に入れた内容は、開いた全員に見えます。

ロードマップを社外や顧客に見せるには

配り方は、相手がClaudeアカウントを持っているかで分かれます。新しい形式のArtifactは、リンクを知っていても、Claudeにサインインしていない人は開けません。

メール招待には条件があります。招待された人は、招待したアドレスのClaudeアカウントが必要です。社外の招待者は1つのArtifactにつき50人までで、保留中の招待は30日で失効します。社外の人は招待や共有設定の変更ができず、Claudeやコネクタを使う部分も動きません。

共有できないArtifactもあります。コネクタやClaudeを使うArtifactは「Anyone with the link」を使えません。Docsで作った文書はメール招待の対象外で、Team・Enterpriseでは今のところリンク共有もできません。四半期ロードマップを顧客向けに出すなら、作る前に「相手はアカウントを持つか」を決めておくと、後から作り直さずに済みます。

仕様レビューの往復を回す手順

仕様レビューで重要なのは、誰がどの権限で何を直したかを追えることです。共有時のアクセス権限は3段階あり、Can viewは閲覧とコメントの閲覧、Commenterはコメントの追加とファイルのダウンロード、Can editは変更までです。ただしArtifactの種別によっては、選べるのはCan viewとCan editの2段階だけです。

実装の技術的な妥当性まで見たい段階では、文章化はClaudeに残し、リポジトリを読ませる作業だけClaude Codeへ渡す切り分けが機能します。両者の違いはClaude AIとClaude Codeの違いで比べています。

PM業務の使い分け早見表

PM特有のつまずき

• legacyのチャットArtifactをTeam・Enterpriseで共有すると、そのチャットの添付資料にも相手がアクセスできます。競合調査の生データや未公開の財務情報を含む会話は、共有前に添付を確認します。プロジェクト内で作ったArtifactは、見る側もそのプロジェクトへのアクセスが必要です。
• 「空欄を埋めて」とロードマップを頼むと、根拠のない日付や優先順位を生成することがあります。未確定は「要確認」のまま残す指示をProject instructionsやSkillに書いておくと、創作された数値が資料に残りません。
• Skillのdescriptionが「PRDを書く」だけだと、雑な頼み方で呼ばれず、毎回スキル名を指定する運用になります。依頼側が使いそうな言い回しを具体的に入れます。
• 仕様書の図や表をDOCXに埋め込んで入れても、Projectのファイルでは本文しか読まれません。図の内容は文章で補うか、PDFで入れます。

まとめ

読む人がClaudeアカウントを持たない可能性があるなら、その文書は最初からDocsで作り、WordやPDFに書き出して渡す前提にします。新形式のArtifactをあとからアカウントなしの相手に開かせる手段はないためです。仕様書の下書きは速くなりますが、日付と優先順位を決めるのは人です。