結論：プロダクトマネージャー（PM）がClaude Codeを使う最大の価値は「コードを書くこと」ではなく、コードベースを読んで現状仕様を把握し、機能要望の実現性をエンジニアに聞く前に自分の頭で整理し、PRDやリリースノートの下書きを一気に作ることです。コードを壊さないように、read-onlyとPlan Modeを中心に使えば、非エンジニアでも安全に始められます。
- 要点1：コードベースに対して「この機能は今どう動いている？」と日本語で聞くと、ソースを根拠に現状仕様を答えてくれる。仕様書が古い・存在しない現場ほど効く。
- 要点2：機能要望の「ざっくりした実現性・影響範囲」を壁打ちできる。ただし最終的な技術判断・工数見積りは必ずエンジニアに確認する。
- 要点3：PRD・ユーザーストーリー・リリースノート・エンジニアへの依頼文の「下書き」を量産でき、曖昧さを減らして手戻りを防げる。
対象読者：コードはあまり書かないが、仕様・要件・リリースに責任を持つPM／プロダクト担当／ディレクター。今日できること：自社リポジトリをClaude Codeで開き、read-onlyのまま「この画面の挙動を説明して」と1問だけ投げてみること。
正直に言うと、私自身も最初は「Claude Codeはエンジニアの道具で、コードを書かないPMには関係ない」と思っていました。でも実際に触ってみて考えが変わったんです。PMの仕事の多くは「コードを書く」ことではなく、「コードが今どうなっているかを理解して、次に何を作るかを言葉にする」ことです。そしてその「理解する」「言葉にする」の部分こそ、Claude Codeが一番得意な領域でした。
この記事は、企業のAI研修・導入支援で実際にPMの方から受けた質問をもとに、「コードを書かない人がClaude Codeを安全に使って、仕様把握から技術理解、PRD作成までを効率化する」具体的な手順を、そのまま使えるプロンプト例つきでまとめたものです。2026年6月時点のClaude Code公式ドキュメントの仕様に沿って書いています。
なぜ今、PMがClaude Codeを使うべきなのか
PMが抱えがちな悩みって、だいたいこの3つに集約されると思うんです。「仕様書が古くて現状が分からない」「エンジニアに聞きたいけど、毎回時間を取らせて申し訳ない」「機能要望が来たけど、技術的に重いのか軽いのか判断がつかない」。
これらは全部「コードベースの中身が読めれば解決する」問題です。でも従来、コードを読むのはエンジニアの仕事で、PMがソースを開いても何が書いてあるか分からなかった。ここに生成AIの、特にClaude Codeのような「ターミナルでコードベース全体を理解できるエージェント」が入ると、状況が一変します。
Claude Codeはリポジトリの中を自分で探索して、関連するファイルを読み、「この機能はこのファイルのこの処理で実現されています」と日本語で説明してくれます。PMにとっては、24時間いつでも質問できる「コードに詳しい同僚」が手元にいるようなものです。エンジニアの時間を奪わずに、自分の理解を先に深められる。これがPMにとっての本質的な価値です。
もう一つ大事なのが「安全に使える」という点です。Claude Codeにはコードを読むだけで変更しないモード（read-only）や、実行前に計画だけ立てて承認を求めるPlan Modeがあります。これを使えば、コードを書けないPMが誤ってリポジトリを壊す心配がほぼありません。後半で具体的な設定を説明します。
大前提：PMが守るべき安全ルール（ここだけは必読）
具体的なワークフローに入る前に、コードを書かないPMがClaude Codeを使ううえで絶対に守ってほしいルールを先に書きます。ここを飛ばすと事故ります。
まず、AIの技術的な説明や実現性の判断は間違うことがあります。Claude Codeは賢いですが、コードベースの一部を読み違えたり、古い実装を最新と勘違いしたりします。だから「Claude Codeがこう言っていたから大丈夫」とPMが単独で意思決定してはいけません。最終的な技術判断・工数見積り・リリース可否は、必ず担当エンジニアに確認する。Claude Codeはあくまで「自分の理解を深めて、エンジニアとの会話を具体的にするための下調べツール」です。
次に、PMが勝手にコードを変更・実行しないこと。read-onlyやPlan Modeを使い、「変更を加える操作」は承認を挟む設定で運用します。コードを書く作業はエンジニアに任せ、PMは「読む・整理する・下書きする」に徹するのが安全です。
そして、機密情報を入れない。顧客の個人情報、未公開の経営数値、パスワードやAPIキーなどをプロンプトに貼らない。社内のセキュリティポリシーやClaude Codeの権限設定（公式ドキュメントの権限管理・セキュリティ）を必ず事前にエンジニアやセキュリティ担当と確認してから始めてください。
安全に始める設定：read-onlyとPlan Modeの使い方
「コードを壊しそうで怖い」というPMの不安は、最初の設定でほぼ解消できます。やることはシンプルです。
- エンジニアに頼んで、自社リポジトリをローカルに用意してもらう（もしくは検証用のクローンを用意してもらう）。本番に直接つなぐのではなく、コピーで触るのが安心です。
- そのフォルダでClaude Codeを起動する。起動直後はまず「読むだけ」の質問から始める。
- 何か変更を伴う操作をしたくなったら、Plan Modeに切り替える。キーボードで
Shift+Tabを押すとモードを切り替えられ、Plan Modeではファイルへの書き込みやコマンド実行を行わず、「何をするか」の計画だけを提示します。 - 計画を読んで、自分で判断できない技術的な部分はエンジニアに見てもらう。実際の変更作業はエンジニアに渡す。
Plan Modeは「Claudeが勝手に手を動かさず、まず作戦を立てて承認を求める」モードです。PMにとっては「いきなり実行されない安心感」が得られます。詳しい使い方はClaude Code Plan Mode実践ガイドに手順をまとめてあるので、最初に一読しておくと事故が減ります。
権限設定をもう一段固めたい場合は、エンジニアに「ファイル変更やコマンド実行には毎回承認を求める設定にしてほしい」と伝えてください。Claude Codeは設定ファイルで、どの操作を許可・確認・禁止するかを細かく決められます。PM運用では「読み取りは自由、書き込み・実行は確認」が基本形です。
活用1：コードベースから現状仕様・できること/できないことを把握する
PMにとって一番効くのがこれです。仕様書が古い・そもそも無い現場でも、コードを根拠に「今どう動いているか」を引き出せます。
使い方は難しくありません。リポジトリでClaude Codeを起動し、知りたいことを日本語で聞くだけです。ファイル名やフォルダを指定したいときは、@を付けて参照できます（例：@src/payment/）。以下のようなプロンプトをそのまま使えます。
このプロダクトの「ユーザー登録」機能について、
現状の挙動を説明してください。
- 登録時に何が必須項目になっているか
- メール認証はあるか、あるなら何回まで再送できるか
- 登録に失敗するのはどんなケースか
コードを根拠に、できること/できないことを
箇条書きで整理してください。変更はしないでください。ポイントは「コードを根拠に」「変更はしないでください」と明記すること。これでClaude Codeは推測ではなく実装を読んで答え、勝手にファイルを書き換えません。返ってきた内容で分からない用語があれば、「いまの説明の『バリデーション』を、エンジニアじゃない人に分かるように言い換えてください」と追加で聞けばOKです。
もっと広い範囲を一気に把握したいときは、大規模コードベースの読み解き方をまとめた大規模コードベース理解ガイドのアプローチが役立ちます。新しくプロダクトを引き継いだPMの「最初の1週間」を大幅に短縮できます。
注意点として、Claude Codeが「この機能はありません」と答えても、それを鵜呑みにしないこと。読み落としの可能性があるので、重要な仕様は「本当にこの機能は実装されていない？関連しそうなファイルをもう一度探して」と念押しし、最終確認はエンジニアに取りましょう。
活用2：機能要望の実現性・影響範囲をざっくり掴む（壁打ち）
「この機能、追加できる？どれくらい大変？」という問いに、エンジニアに聞く前に自分なりの仮説を持てるのがこの使い方です。あくまでざっくりした感触をつかむ壁打ちであって、見積りそのものではない点に注意してください。
「お気に入り登録した商品を、あとで一覧で見返せる機能」を
追加したいと考えています。
このコードベースを読んだうえで、ざっくりで構わないので
教えてください（推測の場合は推測と明記してください）。
- 既存のどの機能・データに近いか
- 新しく必要になりそうな要素は何か
- 影響しそうな画面や処理はどのあたりか
- 技術的にハードルが高そうなポイントはどこか
これはエンジニアに相談する前の下調べです。
コードは変更しないでください。こう聞くと、Claude Codeは「既存のカート機能のデータ構造が流用できそう」「一覧表示の画面はこのあたりを参考にできる」といった当たりを付けてくれます。PMはこれを持ってエンジニアに「お気に入り機能を考えていて、カートのデータが流用できそうかなと思ったんですが、どうですか？」と具体的に相談できる。「なんとなく作りたい」から「ここが論点だと思う」に会話のレベルが上がります。
繰り返しになりますが、ここで出てきた実現性・難易度の判断はAIの仮説であり、間違いを含みます。工数や本当の難所はエンジニアにしか分かりません。Claude Codeの回答は「エンジニアとの会話を具体化するための叩き台」として使い、見積りや約束の根拠にはしないでください。
活用3：PRD・ユーザーストーリー・仕様書の下書きを作る
現状把握と壁打ちが終わったら、いよいよドキュメント作成です。ここはClaude Codeが本当に速い。ゼロから書くより、下書きを作ってもらって自分で直す方が圧倒的に楽です。
ユーザーストーリーの下書きなら、こんなプロンプトが使えます。
さきほど整理した「お気に入り一覧機能」について、
ユーザーストーリーの下書きを作ってください。
フォーマットは「〜なユーザーとして、〜したい、
なぜなら〜だから」の形で、5〜8個。
それぞれに受け入れ条件（このとき成功とみなす）を
2〜3個ずつ付けてください。
曖昧な部分には【要確認】と印を付けてください。PRDの骨子が欲しいときは、見出し構成から作らせるのがコツです。「お気に入り一覧機能のPRDの目次案を、背景／目的／対象ユーザー／要件／非対象（やらないこと）／成功指標／リスクの順で作って」と頼めば、抜け漏れの少ない型が一瞬で出ます。あとはPMが中身を埋めて、現実に合わない部分を削るだけです。
ここで強調したいのが、「【要確認】を付けて」と頼む習慣です。AIは分からないことも、それっぽく埋めてしまいます。曖昧な箇所に印を付けさせておけば、後でエンジニアやデザイナーに確認すべき論点が一目で分かり、捏造された仕様をうっかり通すリスクが減ります。
ドキュメント生成全般のコツはClaude Codeドキュメント生成ガイドにまとめています。READMEやAPI仕様書をエンジニアと一緒に整える場面でも応用できます。
活用4：リリースノート・変更履歴を作る
地味だけど効くのがリリースノート作成です。エンジニアが書いた技術的な変更ログを、PMが「ユーザーに伝わる言葉」に翻訳する作業。これがけっこう時間を食うんですが、Claude Codeに任せると下書きが数分で出ます。
変更内容のメモやコミット履歴を見せて、次のように頼みます。
以下の変更内容をもとに、エンドユーザー向けの
リリースノートの下書きを作ってください。
- 専門用語は避け、ユーザーの利点で書く
- 「新機能」「改善」「不具合修正」に分類する
- 各項目1〜2文で簡潔に
- 自信のない訳や、ユーザー影響が不明な項目は
【要確認】を付けてください
（ここに変更メモや変更履歴を貼り付け）出てきた下書きは、必ず内容をエンジニアに見てもらってから公開してください。AIが「不具合修正」と「仕様変更」を取り違えることがあるので、ユーザーに告知する前のファクトチェックは省かないこと。それでも、ゼロから書くのに比べれば作業時間は大きく減ります。
活用5：エンジニアへの依頼・質問を具体化する（曖昧さを減らす）
PMとエンジニアの間のすれ違いは、たいてい「依頼が曖昧」なことから生まれます。「いい感じにしておいて」が一番もめる。Claude Codeを使うと、依頼を出す前に自分で論点を詰められるので、依頼の解像度が上がります。
たとえば、ふわっとした要望を渡して、聞くべきことを洗い出してもらえます。
エンジニアに「検索を速くしてほしい」と依頼しようと
思っています。この依頼は曖昧でしょうか？
このコードベースの検索まわりを読んだうえで、
エンジニアが実装に着手するために、
私（PM）が事前に決めておくべきこと・
明確にすべき点を、質問リストの形で出してください。
コードは変更しないでください。すると「どの画面の検索か」「現状どれくらい遅いと感じているか」「どこまで速ければ合格か」といった、決めておくべき論点が出てきます。PMはこれを埋めてから依頼するので、エンジニアからの「で、どこをどう速くするの？」という出戻りが激減します。曖昧さを減らすのは、結局チーム全体の時間を守ることなんです。
こうした日々の使い回しを効率化したい場合は、Claude Code実践テクニック完全ガイドでカスタムコマンドやメモリ機能を学ぶと、よく使う質問テンプレを一発で呼び出せるようになります。
PMがやりがちな失敗とその回避策
研修の現場でよく見る、PMがハマりがちな失敗を4つ挙げておきます。先に知っておけば避けられます。
❌ AIの説明を仕様として確定してしまう
Claude Codeが「この機能はこう動きます」と言ったのを、検証せずにPRDや顧客への説明に転記する。読み違いがあると、誤った仕様が独り歩きします。
⭕ 重要な仕様は「根拠のファイルはどこ？」と聞いて確認し、最終確定の前にエンジニアにレビューしてもらう。
❌ read-onlyを使わず、いきなり変更させようとする
「ついでに直して」とお願いして、PMが意図しないコード変更が走ってしまう。
⭕ PMは原則read-onlyとPlan Mode。変更を伴う作業はエンジニアに渡す、と役割を分ける。
❌ 機密情報をそのまま貼る
顧客データや未公開の数値をプロンプトに入れてしまう。
⭕ 個人情報・機密は入れない。扱い方は事前にセキュリティ担当・エンジニアと合意しておく。公式のセキュリティ情報も確認する。
❌ 実現性の回答を「見積り」として扱う
「Claudeが簡単だと言ったから今週中にできるはず」と他部署に約束してしまう。
⭕ AIの実現性判断は仮説。工数とコミットはエンジニアの見積りを根拠にする。
PMのClaude Code活用 始め方ロードマップ
いきなり全部やろうとせず、小さく始めるのがおすすめです。順番はこうです。
- 環境を用意してもらう：エンジニアに検証用リポジトリのクローンと、read-only中心の権限設定を頼む。
- 「読むだけ」から始める：自分が担当する1機能について「現状の挙動を説明して」と1問だけ投げる。
- 壁打ちに広げる：次の機能要望について「実現性をざっくり」聞いてみる。出た仮説をエンジニアとの会話で検証する。
- ドキュメントを下書きさせる：ユーザーストーリーやリリースノートの下書きを作り、自分で直す。
- テンプレ化する：よく使うプロンプトを定型化し、チームで共有する。
このステップなら、コードを書かないPMでも「壊す不安」なく1〜2週間で日常業務に組み込めます。大事なのは、Claude Codeを「自分の代わりに決めてくれる人」ではなく「自分の理解を速くして、エンジニアとの会話を具体的にしてくれる相棒」として位置づけることです。
まとめと次のアクション
コードを書かないPMにとって、Claude Codeは「仕様を読む」「要望を整理する」「ドキュメントを下書きする」「依頼を具体化する」という、まさにPMの中核業務を加速してくれるツールです。read-onlyとPlan Modeを使えば安全に始められ、エンジニアの時間を奪わずに自分の理解を深められます。
ただし忘れないでほしいのは、AIの技術判断は間違うので、最終確認は必ずエンジニアに取ること、PMは勝手にコードを変更・実行しないこと、機密情報を入れないこと。この3つを守れば、リスクをほぼ抑えながら効果だけを取れます。
今日からできる3つのアクションです。
1. エンジニアに「検証用リポジトリのクローンとread-only設定」を相談する
2. 自分が担当する1機能について「現状の挙動を説明して」と1問だけ投げる
3. よく使う質問を1つテンプレ化して、次回も使えるようにする
PMがコードベースを「読める」ようになると、プロダクトの会話の質が変わります。まずは1問、read-onlyで聞いてみてください。
