PMがClaude Codeを使うときの3ルール｜エンジニアと衝突しない線引きと最終判断の渡し方

「PMがClaude Codeを触り始めてから、現場との空気がぎくしゃくしている」そんな相談が、ここ最近じわじわ増えています。

きっかけは小さなことです。PMが Claude Code に「この処理、こう書けばいけそう？」と聞いた回答を、そのままチャットでエンジニアに貼って「これでお願いします」と投げる。あるいはレビュー会で、AIに出させた設計案を「Claude が言ってたんだけど」と切り出す。本人に悪気はなくても、現場のエンジニアからすると「PMが急に実装の話に踏み込んできた」「最終判断を AI に委ねている」と映ります。

PMやPMOがClaude Codeを使うこと自体は、止める話ではありません。要件の素早い検証、影響範囲の当たりをつける、テストデータを作る、運用手順をたたきにする。こうした用途では確実に効きます。問題は、線引きと渡し方が決まっていないまま現場に持ち込むことです。

本記事では、PM・PMO が Claude Code を業務に組み込むときに、エンジニアと信頼関係を保つための3つのルールを整理します。「調査用途と実装用途の線引き」「命名と前提の渡し方」「最終判断はエンジニアに置く」という3軸で、現場で衝突を起こさない使い方を考えていきます。

PMがClaude Codeで衝突を起こす典型パターン

最初に、現場でよく見かける衝突パターンを言語化しておきます。自分のチームで起きていないか、思い当たる節を確認してみてください。

コードの「成果物」をPMが直接渡す

Claude Code に書かせたコードや diff を、PMが Slack やチャットでそのままエンジニアに貼り付ける。エンジニア側からすると、いきなり「実装案」を渡された形になります。実装責任を負うのはエンジニアなのに、PMが先に「答え」を提示してしまっていて、議論の余地が削られたように感じる。これがまず1つ目のパターンです。

AIの調査結果と実装判断が混ざっている

「Claude に聞いたらこうらしい」とPMが言うとき、それは仕様の素案なのか、技術調査の結果なのか、実装方針の決定なのか、聞いている側にはわかりません。PM本人も切り分けないまま発言していることが多い。調査として参考にする話と、実装として採用する話が同じ口調で流れてくるので、エンジニアは毎回「これは決まりなんですか？」と確認するコストを払うことになります。

ルールが属人化している

PMによって、Claude Code の使い方も、コードや設計の渡し方もバラバラ。あるPMはPRを直接出してしまい、別のPMは口頭でサラッと方針を決めてしまう。チームとしての約束事がないので、エンジニアはPMごとに対応を変える必要が出てきます。属人運用の怖いところは、誰か一人がやり過ぎたときに「PMがAIで暴走している」という空気が一気に広がることです。

これらはPMの能力や悪意の問題ではなく、Claude Codeを業務に組み込む前提のルールが、組織として整理されていないために起きています。

ルール1：調査用途と実装用途を切り分ける

最初のルールは、Claude Code の使い方を「調査用途」と「実装用途」に分けて、PMは原則として調査用途にとどめる、というものです。

調査用途とは

PMが Claude Code を使ってよい範囲を、まず明確にします。代表的なのは次のような場面です。

要件や仕様を検討するための、プロトタイプ的なコード生成
既存コードベースの構造や依存関係を読み解く読解補助
影響範囲の当たりをつけるための、変更箇所の洗い出し
リスクや代替案の比較材料を集めるための叩き台
ドキュメントや手順書の下書き

これらに共通するのは、最終的に納品物にならないという点です。あくまで判断材料を作っているだけで、本番のコードベースには入りません。PMが Claude Code をこの範囲で使う限り、エンジニアと衝突する理由はあまりありません。

実装用途は原則エンジニアに渡す

一方、実装用途とは「最終的にコードベースに入る変更を作る」用途です。PRを出す、ブランチを切る、本番ロジックの一部を書く。これらは原則としてPMの守備範囲ではありません。

PMが調査の中で書いたコード片が、結果として実装に近い形になったとしても、それはあくまで「たたき台」として渡すべきものです。「こういう実装イメージがあって、判断のために書いてみました。実装方針はそちらで決めてください」と、用途を明示して渡すと角が立ちません。

切り分けがぶれない仕組みとして、運用上のシンプルなルールが効きます。

PMはPRを直接出さない
PMが書いたコードは「参考実装」と必ずラベルする
実装用途で書く必要が出たら、エンジニアに巻き取りを依頼する

このラインを決めておくだけで、現場の空気はかなり変わります。

ルール2：命名と前提を一緒に渡す

2つ目のルールは、Claude Code が出した結果を渡すときの「渡し方」の話です。PMが現場で軋轢を生む原因の多くは、出力そのものではなく、渡し方が雑なことにあります。

「Claudeに聞いたら」だけで渡さない

「Claude Codeに聞いたら、こう書けばいけるって言ってた」この一言だけで投げると、エンジニアは前提を全て自分で再構築する必要が出てきます。どんなプロンプトで、どんな前提を与えて、どこまで確認したのか、何が確認できていないのか。それらが伝わっていないと、AIの出力は単なる「外野からの口出し」に見えてしまいます。

渡すときの最低3点

PMが Claude Code の出力をエンジニアに渡すとき、最低限セットにしたい情報は次の3点です。

何を調べた／作ったのか（用途の名前付け）「APIエンドポイント追加の影響範囲調査」「障害ログ集計クエリのたたき」のように、用途を一言で命名する。実装案なのか、調査結果なのか、ドキュメントの下書きなのかが、ラベルで伝わる状態にする。
どんな前提で動かしたかどのファイル・ディレクトリを読ませたか、どんな仕様を前提として与えたか、対象としていない範囲は何か。前提が共有されていれば、エンジニアは「その前提なら別観点でこう」と返せます。
PM側で確認できたこと、できていないこと PMが手元で動作確認したのか、ロジックの妥当性まではAI出力をそのまま信じているのか、を明示する。これがないと、エンジニアは出力をゼロから検証する羽目になります。

この3点をセットにする運用は、テンプレ化してしまうのが楽です。Slackやチケットに貼るときの定型フォーマットを決めておくと、PMもブレずに渡せるようになります。AI活用そのものの全体設計については、関連記事のPM必見。AIをベテランPMに変える思考加速プロンプト術も参考になります。

ルール3：最終判断はエンジニアに置く

3つ目が、現場の信頼に最も直結するルールです。Claude Code が出した実装方針について、最終判断はエンジニアに置くこと。これだけは、組織のルールとして明文化しておきたいラインです。

なぜ最終判断を渡すのか

PMやPMOは、案件の優先順位、納期、ステークホルダー調整に責任を持つ立場です。一方、コードベースの一貫性、技術的負債、運用後の保守性に責任を持つのはエンジニアです。Claude Code が提案する実装は、後者の責任範囲に踏み込みます。

ここでPMが「AIがそう言ってるから」で押し通すと、責任の所在が曖昧になります。後でバグや負債が出たときに、「あれはClaudeが書いたから」「PMが決めたから」と責任の押し付け合いが始まる。これがチームを最も傷めます。

運用としての落とし方

最終判断をエンジニアに置く、という方針を機能させるためには、合意のとり方を運用に落とす必要があります。

PMが提示する Claude Code 由来の実装案は、すべて「提案」扱いにする
採用・不採用・修正の判断は、レビュー担当のエンジニアが下す
不採用や大幅修正になっても、PMは「なぜ別案にしたか」だけ確認し、覆さない

この運用を回すと、PMにとってもメリットがあります。Claude Code を使いつつ「最終的には現場の判断」と明言できるので、AI活用に対する社内の警戒感が下がります。

PMの判断軸そのものを磨く話としては、【PM用】AIで技術報告を経営層に響かせるプロンプト術も参考になります。AIを情報整理のパートナーとして扱う前提のうえで、人間が最終判断する構図は同じです。

3ルールを組織で運用に落とすコツ

3つのルールを、個人のマナー任せにせず、組織で回すための小さなコツをいくつか挙げておきます。

1ページの運用ガイドにまとめる

3ルールは、A4一枚で十分書ける量です。長大なガイドラインを作るより、PM向けの「Claude Code 利用ガイド（暫定版）」として1枚にまとめ、レビュー会で読み合わせる方が浸透します。

「うっかり違反」を責めない仕組み

特に最初の数か月は、PRを直接出してしまったり、前提なしで投げてしまうケースが必ず出ます。そのときに個人を責めるのではなく、「ルール側の運用設計を直す」スタンスでいく。これがないと、PMがAI活用そのものに萎縮してしまいます。

効果が出ている使い方を共有する

衝突を防ぐ話だけでは、PMのモチベーションは下がります。「調査用途で時短できた事例」「ドキュメント下書きで品質が上がった事例」を、月次でPMチームに共有する。良い使い方が見えると、ルールが「縛り」ではなく「プロを名乗るための作法」に見えてきます。

進捗・課題・リスク管理の領域でAIをどう仕組み化するかは、関連記事のAIをコンサル化するPMのリスク管理プロンプト術も合わせて読むと、運用イメージが具体になります。

まとめ：PM × Claude Code は「線引き」で決まる

Claude Code は、PMの仕事を確実に変える道具です。ただ、現場のエンジニアと信頼関係を壊しながら使うと、得られた効率以上のものを失います。

本記事の3ルールをもう一度整理しておきます。

調査用途と実装用途を切り分ける：PMは原則として調査用途。実装に近い出力は「参考実装」とラベルし、PRはエンジニアが出す
命名と前提を一緒に渡す：用途のラベル、前提情報、PM側の確認範囲をセットにして渡す
最終判断はエンジニアに置く：Claude Code 由来の案はすべて提案扱いにし、採否はレビュー担当が決める

この3ルールを、個人のマナーではなく「組織の運用ガイド」として置けるかどうかが、PMのAI活用の成否を分けます。