PMワークフロー革命：Claude Code・Skills・Sub-Agentsで変わる仕事術
最近、Claude Code をプロダクトマネジメント（PM）のワークフローに導入した。これが最近で最も大きな働き方の変化だ。以前は数日かかっていた仕様書やプロトタイプが数時間で完成するようになり、エッジケースの洗い出しも自分では到底追いつかないレベルまでAIがカバーしてくれる。
これは単なるChatGPTへの質問とは違う。AIをワークフローに深く組み込むことだ。AnthropicのBuilding Effective Agentsガイドが指摘するように、真の生産性向上はAIを単純な「チャットボット」から複雑なタスクを実行できる「エージェント」へと進化させることで得られる。
コアプロセス：一人プロダクトチーム
新しいワークフローはざっくりこんな流れだ。曖昧なものを具体化していく収束プロセスと言える：
要件受け取り → Claude Skills（SOP）による初期分析 → Sub-agents（多角的視点）によるレビュー＆議論 → 高品質なPRD＋プロトタイプ生成 → 部門横断コミュニケーション → 仕様確認
まるでバーチャルチームをいつでも呼び出せるようになった感覚だ。単なるPMというより、AIチームの指揮官として動くイメージに近い。
1. Claude Skills：SOPをAIの脳に書き込む
Skills の概念はシンプルだ。頭の中にある標準作業手順（SOP）をAIが厳格に従える形で書き出すこと。これはAnthropicが「Workflows」と呼ぶ概念に対応しており、LLMを事前定義されたパスに沿って動かし、一貫性を担保するものだ。
以前のPRD執筆では、命名の一貫性・フォーマットのルール・チーム固有の言い回し・過去ドキュメントの参照など、あらゆることに気を配らなければならなかった。人間の脳は細部を見落としやすい。Aを修正したのにBにバグが生まれた、という事態は珍しくない。
今はこれらのルールをSkillsとしてカプセル化している。実際に使っている requirement-analyzer Skillの例を示す：
# Skill: Requirement Analyzer
## Role
You are a Senior Technical Product Manager (TPM), skilled at converting vague business requirements into structured User Stories.
## Input
- Raw Input
- Target Audience
## Output Format (Markdown)
1. **Executive Summary**: One sentence explaining what this feature does.
2. **User Stories**: Format as "As a <role>, I want to <action>, so that <benefit>".
3. **Acceptance Criteria (Gherkin Syntax)**:
- Given [Context]
- When [Action]
- Then [Expected Result]
4. **Edge Cases**: List at least 3 extreme conditions (e.g., Network failure, Empty data, Insufficient permissions).
## Rules
- Must use this format: `FE-[Feature Name]-001` as ID.
- Prioritize Mobile First experience.
このルールをコード（またはSystem Prompt）として書いておくと、AIはプリセットされた基準に従った出力を安定して再現する。
2. Sub-agents：視点を広げるバーチャルな分身
Skillsが「手」なら、Sub-agents は「頭脳」だ。
一人で仕様を書いていると、どうしても盲点が生まれる。BasecampのShape Up メソドロジーが指摘するように、プロダクト開発最大のリスクは、仕事が適切に「Shaped（整形）」される前に開発に突入してしまうことだ。
これを避けるために、私は異なるエージェントを作成して「自己討論」を行っている：
- User Researcher Agent：このフローは直感的か？もっと良いUXはないか？
- Dev Agent：技術的な実現可能性を評価し、DBスキーマの設計やAPI連携方法を明確化する。
- QA Agent：ロジックの穴を探し、起こりうるすべてのエッジケースを洗い出す。
- Stakeholder Agent：ビジネス価値の観点からこの要件の必要性を問い直す。
シミュレーション対話の例
私（PM）：「ワンクリック週次レポート機能を作りたい」
Dev Agent：「技術的には可能ですが、Context Windowの制限を考慮する必要があります。ユーザーが週500チケット以上持つ場合、APIがタイムアウトするかもしれません。PaginationかAsync Job処理の追加を提案します。」
QA Agent：「同意見です。加えて、その週にチケットがまったくない場合はどうしますか？レポートを空欄にするか、デフォルトテキストを表示するか。API呼び出しが失敗した場合のRetryメカニズムも必要では？」
User Researcher Agent：「待ってください、ユーザーは本当に『ワンクリック』を望んでいますか？実際にはAIの出力を編集したいケースが大半のはず。フローは『下書き生成 → ユーザーがプレビュー＆編集 → 保存＆送信』にすべきでは？」
実際の運用では、コンピュータの中で効率的な会議を開いているような感覚だ。以前は数回の打ち合わせを経て確認していたことが、今では数時間で完結する。これが**「Shift Left」**の究極の形だ。コードの最初の一行が書かれる前に、問題を発見して解決できる。
3. 即席プロトタイプ：「想像してください」からの脱却
ここが最もインパクトの大きい部分だ。どれほど精緻な文章も、動くビジュアルには勝てない。
以前は仕様書を書き上げても、デザインが間に合わないことが多かった。エンジニアや上司と議論する際、全員が「それぞれ頭の中でイメージ」するしかなく、リリース後に大きな認識のズレが発覚することもあった。
今はClaude Codeと v0.dev またはTailwind CSSを組み合わせて直接フロントエンドコードを生成し、動くインタラクションプロトタイプを手に入れている。
- 以前：「このボタンをクリックすると3つの選択肢があるModalが表示されて……」（エンジニア：？？）
- 今：「このHTMLファイルを見てください、クリックすれば分かります」（エンジニア：了解）
コミュニケーション効率は格段に上がり、技術的な詳細も開発前に検証できる。今では会議にプロトタイプを持参しないことがほとんどなくなった。
4. Git Flow：Docs as Code
最後に重要な変化がGit Flowの導入だ。これはAtlassianのDocs as Codeの考え方と完全に一致する。
以前はドキュメントがGoogle Docs・Confluence・Slackの会話に分散していて、最終的に誰も更新しない「腐ったドキュメント（Stale documentation）」になっていた。今はすべての成果物をGitのバージョン管理に入れるようにしている。
推奨ファイル構成
project-root/
├── src/ # Source Code
├── docs/
│ ├── adr/ # Architecture Decision Records
│ ├── prd/ # Product Requirement Documents
│ │ ├── 2026-02-feature-A.md
│ │ └── 2026-03-feature-B.md
│ └── specifications/ # Technical Specs
├── .claude/ # AI configurations
│ ├── skills/ # Defined Skills
│ └── prompts/ # Common Prompt Templates
└── README.md
メリットは次の通りだ：
- Single Source of Truth：コードが変わればドキュメントもその横で変わる。
- コードレビュー：ドキュメントの変更もPull Requestのプロセスを経るため、必ずレビューされる。
- トレーサビリティ：誰がいつどの仕様を変更したかがGit Logに明確に残る。
まとめ
現時点での活用はまだ初歩的な段階だが、「質の低いドキュメントを作ってしまう」リスクは大幅に減り、車輪の再発明に費やす時間も大きく節約できている。
AIに仕事を奪われると心配するPMも多いが、私はAIが置き換えるのは「実行者」であり「思考者」ではないと考えている。面倒な作業（ドキュメント作成・図の作成・情報収集）を自動化に任せることで、PMは本当に重要な場所に時間を使えるようになる。それは意思決定とコミュニケーションだ。
これからのPMはAIチームの指揮官に近い存在になるだろう。あなたの価値は、どれだけ多くのAI Agentを指揮して、複雑な問題を解決できるかにかかっている。
