PdMがClaude Codeを使い始めて変わったこと

ogp

はじめに
PdM業務フェーズごとのClaude Code活用マップ
1-2. 調査・発見 / 戦略・方向性
3. 要件定義・優先順位付け
- Agents: 仕様書作成・レビューパイプライン
  - spec-author：仕様書の草稿作成
  - spec-critic：仕様書レビュー
- 仕様書ワークフロー：Agentsによる作成・レビューパイプライン
  - パイプラインの設計意図
4. 設計・開発
5. 検証・テスト
6. リリース・ローンチ
release-notes：リリースノートを作成する
7. リリース後・改善
- reflect：セッションを振り返る
カスタマイズと運用
おわりに

はじめに

enechainでPdMを担当しているBuchiです。2025年9月に入社しました。

Claude Codeを使い始めて、仕様書作成、社内ツール開発、Notion上のドキュメント管理まで、PdM業務の多くをClaude Codeと一緒に進めるようになりました。導入後は、仕様書の草稿作成にかかる時間を大幅に短縮しました。

活用方法は社内環境やセキュリティ状況によって異なります。

この記事はあくまで私個人の一例であり、やり方も日々変わっています。一週後には、いや一日後には変わっている可能性がありますが、「他の人の環境を覗いてみる」くらいの感覚で読んでいただけると嬉しいです。

PdM業務フェーズごとのClaude Code活用マップ

PdM業務のフェーズでClaude Codeをどう活用しているかの一部をまとめていきます。

フェーズ	内容
1. 調査・発見	ユーザーインタビュー、市場調査、競合分析、データ分析
2. 戦略・方向性	ゴール設定、プロダクト戦略、ロードマップ作成
3. 要件定義・優先順位付け	仕様書作成、優先順位付け、スコープ決定
4. 設計・開発	UI/UX設計確認、技術仕様すり合わせ、モック作成
5. 検証・テスト	QA項目生成、受け入れ条件の確認
6. リリース・ローンチ	リリースノート作成、社内共有、通知設定
7. リリース後・改善	フィードバック収集、振り返り、改善提案

1-2. 調査・発見 / 戦略・方向性

スキル名	概要	用途
`notion-search`	Notion横断検索	議事録・仕様書などから過去の議論や決定事項を検索します
`mtg-format`	議事録フォーマット整理	会議のNotionページURLから所定フォーマットに自動整理します
`slack-share`	Slack共有用テキスト生成	議事録やリリース情報を要点に絞ったSlack投稿用テキストに変換します（議事録まとめでは長くてSlackで読むには不向きのため）

Skills（定型タスクをマークダウンで定義した再利用可能なワークフロー）を利用して、各タスクを実行しています。

社内のセキュリティガードレールにより、PdMの場合はClaude Codeからの社外情報検索ができない環境のため、検索する際はClaude.aiを別途利用しています。

3. 要件定義・優先順位付け

スキル名	概要	用途
`spec-structure`	仕様書整理	既存の仕様書を構造化・整理します
`spec-review`	仕様書レビュー	6カテゴリ19観点で仕様書をレビューします
`spec-product名`	プロダクト用のフォーマット整形	プロダクト固有のフォーマットに仕様書を整形します

エージェント名	概要	用途
`spec-author`	仕様書草稿作成	テンプレートに沿って仕様書の草稿を自動生成します
`spec-critic`	仕様書レビュー・判定	spec-authorの草稿を19観点+設計の整合性チェック6項目+技術制約チェックでレビューし承認・差し戻しします

Agents: 仕様書作成・レビューパイプライン

.claude/agents/ には2つの専門エージェントを定義しています。「作成」と「レビュー」を分離して、仕様書の抜け漏れを抑えるようにしました。

spec-author：仕様書の草稿作成

要件をもとに、プロジェクト固有のテンプレートとフォーマットに沿って仕様書の草稿を作成するエージェントです。草稿はローカルに保存し、Notionへの書き込みは spec-critic の承認後にのみ行います。

spec-critic：仕様書レビュー

spec-author が作成した仕様書の草稿を、6カテゴリ・19観点で包括的にレビューするエージェントです。各指摘に重大度ラベル（致命的 / 要対応 / 提案）を付与し、判定基準に基づいて差し戻しまたは承認を行います。差し戻し2回でエスカレーション（無限ループ防止）し、承認時はユーザーに確認のうえNotionに書き込みます。

この2つのエージェントはパイプラインとして連携します。spec-author が草稿を作成し、spec-critic がレビュー。NGなら差し戻し、ApprovedならNotionに書き込みます。サブエージェントはメインのコンテキスト（会話の文脈情報）を汚さずに独立して動作するため、コンテキスト管理の観点でも有効です。

仕様書ワークフロー：Agentsによる作成・レビューパイプライン

上記で紹介した spec-author と spec-critic の2つのエージェントは、以下のワークフローで連携します。

    flowchart TB
        START([▶ START]):::startEnd --> A
        A["👤 ユーザー<br>要件を説明 / Notion URL を提供"]:::user --> B
        B["✍️ spec-author<br>Constitution.md 読み込み → 草稿作成"]:::author --> C
        C["📄 docs/drafts/YYYY-MM-DD-feature-slug.md<br>草稿をローカル保存"]:::author --> D
        D["✍️ spec-critic<br>6カテゴリ・19観点 + 整合性チェック"]:::critic --> E
    
        E{⚖️ 判定}
        E -->|"✅ 要対応2件以下<br>& 致命的なし"| I["✅ Approved"]:::approved
        E -->|"❌ 致命的1件以上<br>or 要対応3件以上"| F
    
        F["❌ NG — 指摘事項を記録"]:::ng --> G
        G{🔄 差し戻し回数}
        G -->|"1回目"| B
        G -->|"2回目"| H["✍️ spec-critic<br>エスカレーション<br> → ユーザーに判断を委ねる"]:::escalate
    
        I --> J["✍️ spec-critic<br>ユーザーに Notion DB URL を確認"]:::approved
        J --> K["✍️ spec-critic<br>Notion DB にページ作成 (Status = Approved)"]:::approved
        K --> DONE([⏹ END]):::startEnd
        H --> DONE
    
        classDef startEnd fill:#2C3E50,stroke:#1a252f,color:#fff
        classDef user fill:#4A90D9,stroke:#2C6FAC,color:#fff
        classDef author fill:#F5A623,stroke:#C47D0E,color:#fff
        classDef critic fill:#7B68EE,stroke:#5A4DB0,color:#fff
        classDef ng fill:#E74C3C,stroke:#B03A2E,color:#fff
        classDef escalate fill:#C0392B,stroke:#922B21,color:#fff
        classDef approved fill:#27AE60,stroke:#1E8449,color:#fff

ユーザーが要件を伝えると、spec-authorが草稿を作成しローカルファイルに保存。spec-criticがレビューし、基準を満たせばNotionに書き込みます。NGなら差し戻し、2回NGでユーザーにエスカレーションします。

草稿は docs/drafts/YYYY-MM-DD-feature-slug.md にローカル保存します。Notionへの書き込みはspec-criticの承認後のみとすることで、未レビューの仕様が公開されるのを防いでいます。

パイプラインの設計意図

このパイプラインには、品質担保と暴走防止のための仕組みを意図的に組み込んでいます

指摘ゼロは不合格: AIレビューは「問題ありません」と形式的に通してしまうことがある。提案レベルでもいいので必ず1件以上の指摘を出すルールにすることで、レビューが機能していることを担保しています
エスカレーション: 差し戻し2回で自動ループを停止し、ユーザーに判断を委ねる。AI同士で無限にやり取りするのを防ぎ、トークン消費も抑えます

4. 設計・開発

スキル名	概要	用途
`html-mock`	HTMLモック生成	仕様書からブラウザで確認できるHTMLモックを生成します

大型の開発のみですが、事前認識合わせやクライアントのヒアリングのためにモックを作成することがあります。Figma等のデザインツールを使わずに画面イメージを素早く共有でき、チームレビューの材料として活用しています。

また、業務で使うデータ加工ツールもClaude Codeで作成しています。たとえば、Excelファイルをプロダクトの入力フォーマットに変換するツールを、HTML/JavaScriptの単一ファイルで構築しました。カラムの自動マッピングやエリアコード変換など、手作業では時間のかかる変換処理を自動化しています。

PdMが自分でツールを作れると、「こういうものが欲しい」からアウトプットまでのリードタイムがなくなります。簡易なツールには限られますが、業務改善を自分で回せるのは大きな変化でした。

5. 検証・テスト

小さめの機能開発で、開発者自身がセルフQAを行うケースを想定した活用方法です。

スキル名	概要	用途
`qa-checklist`	QAチェックリスト生成	仕様書URLから画面ごとの確認項目・境界値テスト・エラーケースをリスト化します

仕様書を渡してQA項目を自動生成し、前述の spec-review による仕様書レビューとあわせて、テスト前に抜け漏れをチェックします。

6. リリース・ローンチ

スキル名	概要	用途
`release-notes`	リリースノート作成	仕様書を読み取り、統一フォーマットで出力します
`popup-notice`	ポップアップ通知生成	アプリ内ポップアップ通知のJavaScriptコードを生成します

release-notes：リリースノートを作成する

新しい機能をリリースする際は、リリースノートを作成しています。

事前にリリースノートの言葉遣いやフォーマットルールを作成しておいて、仕様書を読み込ませることで、ゼロからでもある程度の品質のリリースノートを作成できます。

機能が既にリリース済か、予告のお知らせかで日付の表記を切り替えるなど、細かいルールもスキルに含めています。

7. リリース後・改善

スキル名	概要	用途
`reflect`	セッション振り返り	CLAUDE.md・Skills・Agentsの改善を提案
`incident-notice`	障害報告作成	障害発生が発生した際の報告テキストを生成
`resolved-notice`	復旧報告作成	障害が復旧した際の報告テキストを生成

reflect：セッションを振り返る

タスク完了後に、セッション中の作業を自動で振り返り、CLAUDE.md・Skills・Agentsの改善を提案します。

タスクを終えるたびにClaude Codeが自動で振り返りを実行するため、「使えば使うほど設定ファイルが育つ」サイクルが回ります。 /reflect で手動実行もできるようにしています。

カスタマイズと運用

私のClaude Code環境

iTerm2からClaude Codeを利用しています。

タスクの種別ごとにタブを分け、常時3タブほどで並行して作業しています。同じタスク内でさらに手分けする場合はウィンドウを分割します。

以前はウィンドウ単位でタスクを分けていましたが、どのウィンドウが何をやっているのか分からなくなったため、タブごとにタスク種別を分けるスタイルに落ち着きました。後述するHooksの通知でもiTerm2のタブ名を活用しています。

Hooksの設定

Hooks（Claude Codeのイベントに応じてシェルコマンドを実行する仕組み）と notify.sh を組み合わせて、「Claude Codeに作業を投げて、終わったら通知で知る」ワークフローを実現しています。

Claude Codeはデフォルトでは「完了」しか通知してくれず「質問発生」「権限確認」のタイミングに気づくことができませんでした。

Hooksで通知を飛ばすようにしたことで、Claude Codeが確認待ちで止まったままになる時間を減らせました。

よく使うコマンド

以前は .claude/commands/（カスタムコマンド）で定型タスクを管理していましたが、現在はより再利用しやすいSkillsへ段階的に移行しています。プロジェクト固有のものは一部コマンドとして残していますが、新規作成はSkillsで行っています。

Claude Code標準のコマンドでよく使っているものはこちらです。

タスクの切れ目で /clear（会話履歴を全消去）してからの新タスク開始を基本にしています。このリズムが定着してから、コンテキスト起因のミスが減りました。

コマンド	使いどき	効果
`/clear`	タスクが完全に無関係なとき（例：議事録整理 → ヘルプページ作成）	会話履歴を全消去
`/compact`	タスクは変わるが文脈を引き継ぎたいとき（例：議事録整理 → その会議のリリースノート）	コンテキストを圧縮し、直前の作業結果を踏まえられる
`/rename` + `/resume`	後で戻りたいとき（例：`/rename hogehoge` でセッション名を保存）	セッションを保存し、後から `/resume` で復帰可能
`/mcp`	Notion MCP等の認証が期限切れになったとき	MCPサーバーの再認証。対処手順を `CLAUDE.md` に書いておくと、Claude Code自身が「認証が切れている可能性があります」と提案してくれる

おわりに

変わったこと

仕様書作成が大幅に短縮された: spec-author / spec-critic パイプラインにより、草稿作成からレビューまでが自動化され、PdMは判断と最終確認に集中できるようになった
簡易なツールを自分で作れるようになった: 「こういうものが欲しい」と思ったらすぐ自分で作れるようになり、要望からアウトプットまでのリードタイムがなくなった

できていないこと、やりたいこと

現状できていないこととして、大きく2つあります。

1つ目は仕組みの改善です。spec-authorはまだコードベースをreadできておらず、実装を直接参照できれば仕様書の厳密性が上がります。またspec-criticの指摘をスコア化して品質を時系列で追う仕組みもまだ作れていません。reflectへのインプットもClaude Code自身の振り返りのみで、Notionのコメントなど人間のフィードバックをループに取り込めていません。

2つ目はまだ手をつけていない領域です。Agentフローは仕様書以外にも広げたいと考えています。

調査フェーズでのインタビュートランスクリプト活用や、意思決定の根拠をDecision Recordとして残すフローも、次に取り組みたいと思っています。

変わらないこと、その先にある課題

Claude Codeによって、「判断」と「検証」により多くの時間を使えるようになりました。

一方で、AIは作業を効率化してくれますが、自分の知識を拡張してくれるわけではありません。私は電力業界に移りましたが、高度なドメイン知識が必要な仕様に対して、責任を持ってGOサインを出すにはまだ知識が足りていません。AIを使えば「それっぽい」仕様書は書けますが、その内容を自分で判断・承認できるかは別の問題です。承認できる範囲は、結局のところ自分のドメイン知識の範囲に限られます。

だからこそ今は、AIの活用をキャッチアップしながらも、電力ドメインの知識を早く身につけ、自分自身の「承認できる幅」を広げることを最優先にしています。

enechainでは、こうしたAI活用も含め、日本のエネルギー取引インフラの構築を一緒にリードしてくれるメンバーを募集しています。PdM、エンジニア、デザイナー、ビジネス開発 ― 興味のある方はぜひお声がけください。

tech.enechain.com