PM のための Claude Code 入門:AI駆動開発のデリバリーループ
Claude Code や Codex のエージェントが開発を担うとき、それを指揮する PM やテックリードの仕事は 4 つに集約されます。エージェントが動ける明確な要求を書くこと、エージェントからの質問に素早く判断を返すこと、要求内容に照らして成果物をレビューすること、そして完了済みの作業と未完了の作業を追跡することです。このガイドでは、コピーして使えるテンプレートとともに各ステップを説明し、ファイルに残すべきものとチャットで済ませてよいものを整理します。
AI駆動開発で、PM の仕事は何が変わるのか?
Anthropic の 2026 Agentic Coding Trends Report は、ソフトウェア開発が「コードを書く活動から、エージェントをオーケストレーションする活動へと移りつつある」こと、そして AI を上手に使うには「積極的な監督と検証が必要」であることをはっきり述べています。この監督はプロジェクトマネジメントの仕事であり、エージェントを指揮する人、つまり PM、テックリード、あるいは両方を兼ねる個人開発者に降りかかります。
通常のチームでは、仕様の抜けは人同士の質問で埋められます。AI を活用したプロダクト開発では、質問できる相手がいないことがよくあります。エージェントは書かれた内容を読み、抜けている部分は最善の推測で埋めて、そのまま進みます。
その結果、PM の仕事は 3 つの点で変わります。
- 文章が主要な道具になる。 成果物の質は、人間のチームよりもはるかに強く要求の質に連動します。
- ボトルネックはビルドではなくあなた。 エージェントはタスクを数分で終え、その後はあなたを待ちます。未回答の質問が、プロジェクトを何時間も止めることがあります。
- 記憶はファイルに置く必要がある。 エージェントのセッションが終わると、新しいセッションは履歴なしで始まります。決定事項がチャットのスクロールバックにしかなければ、失われます。
つまり、AI コーディングエージェントを指揮する PM は、人を調整する役割というより編集者に近い存在です。編集する対象は、要求、計画、そして成果物です。
デリバリーループをステップごとに見る
ループは 7 つのステップで、機能や変更ごとに 1 回まわします。
- インテーク: 顧客資料と要件。
- エージェントが読む書面の要求。
- 番号付きタスクの計画。
- エージェントが実行。
- 成果物をレビューしてコメント。
- 変更は変更要求にする。
- 進捗と未解決の質問を追跡。
1. インテーク: クライアント自身の資料から始める
要件は多くの場合、PDF、スプレッドシート、スライド、議事メモが混在した形で届き、Box や Google Drive の共有フォルダに置かれています。エージェントに原本を示して読み込みと要約を依頼し、その要約はあなた自身で確認します。
ここでは 2 つのルールが役立ちます。1 つ目は、クライアントのフォルダを読み取り専用として扱うことです。エージェントはその場で読み、生成物(要約、質問リスト、分析)はクライアントのフォルダに戻さずプロジェクト内に置きます。2 つ目は、インテークの一環としてエージェントに未解決の質問リストを出してもらうことです。初日に見つかった抜けは安く済みますが、機能を作った後に見つかった抜けはそうはいきません。
2. エージェントが動ける要求を書く
要求とは、何がほしいのか、なぜか、どうなれば完了とわかるのかを書いた短いファイルです。次のセッションでも読めるよう、チャットメッセージではなくプロジェクト内に置きます。ほとんどの機能で使えるテンプレートは次のとおりです。
# Request: Export orders as CSV
## Why
Finance re-keys orders into their accounting tool every Friday.
## What
- Button "Export CSV" on the Orders page.
- Columns: order id, date, customer, total, status.
- Respect the current filters on the page.
## Out of scope
- Excel format, scheduled exports.
## Done when
- A 500-order export opens correctly in Excel and Numbers.
- Tests cover an empty result and a filtered result.
## References
- docs/client/orders-spec.pdf, section 3
「Out of scope」(対象外)のセクションは、見た目以上に効果があります。エージェントは頼んでいない方向に親切を発揮しがちなので、不要なものを明示するのが変更を小さく保つ最も手軽な方法です。「Done when」(完了条件)は、あなたとエージェントに同じゴールラインを与えます。
3. 番号付きタスクの計画を依頼する
コードを書く前に、要求を番号付きタスクの計画ファイルにするようエージェントに頼みます。「Task 1: add export endpoint」「Task 2: add button and download」「Task 3: tests」といった具合です。計画に目を通してください。計画に 5 分かければ、間違ったアプローチが 400 行のコードになる前に気づけます。
各コミットメッセージにタスク番号を入れるようエージェントに頼みましょう(「Task 2: add export button」)。この習慣ひとつで、コードを開かずに確認できる進捗記録が手に入ります。
4. エージェントに実行させ、連絡がつく状態を保つ
エージェントが作業している間、あなたの仕事は質問が来たら答えることです。エージェントが止まる理由は 2 つで、ターンを終えたか、許可や判断が必要になったかです。
複数のプロジェクトを動かしている場合や、1 プロジェクトで複数のセッションを動かしている場合、ここで取りこぼしが起きます。良い環境なら、ターミナルを順番に確認しなくても、どのセッションが待っているかがわかります。詳しくはコンテキストを失わずに複数の Claude Code エージェントを管理する方法で解説しています。
5. すべての diff を読まずにレビューする
エージェントが書いたすべての行を読む必要はありません。知るべきなのは、結果が要求に合っているかどうかです。次の順にレビューし、問題が見つかった時点で止めます。
- 動くか? アプリやページを開いて、「Done when」のチェックを自分で試します。
- 要求で求めたテストは存在し、通っているか? エージェントにテスト名と実行結果を見せてもらいます。
- スコープ内に収まっているか? 変更したファイルの一覧を求めます。CSV エクスポートがログインのコードに触れていたら、確認が必要です。
- 書かれた成果物を読む。 計画、ドキュメント、リリースノート、要約は誤解が最初に表れる場所で、読むのも手早く済みます。
- リスクの高い部分だけ抜き読みする: 認証、決済、データ削除、個人情報に関わるもの。
より深いコードレビューには、レビュー用プロンプトを与えた 2 つ目のエージェントを最初のパスとして使うのが妥当です。あなたは diff 全体ではなく、その指摘を読みます。
問題が見つかったら、まとめて一度に送ってください。1 つのメッセージに 5 件のコメントを入れればエージェントは全体像をつかめますが、5 通に分けると部分的な修正が 5 つできあがります。
6. 変更を変更要求にする
要件は最初のバージョンが出た後に変わります。クライアントが CSV を見て、通貨の列がほしいと言い出す。元の要求は編集せず、その下に変更要求(CR)を追加します。CR には独自の短い説明と独自の計画を持たせます。元の要求は合意内容の記録として残り、各 CR は何がいつ変わったかを示します。
7. 進捗と未解決の質問を追跡する
2 つのリストが、エージェントが作るプロジェクトを正直に保ちます。
- 進捗: 計画のどのタスクが完了したか。コミットにタスク番号が入っていれば、このリストは自然にできあがります。
- 未解決の質問(Todo): あなたやクライアントの判断が必要なこと、意図的に後回しにした作業。今すぐ答えられない質問がエージェントから来たら、ターミナルの中で消えてしまうに任せず、Todo として記録するよう頼みます。
ファイルに残すものと、チャットのままでよいものは?
| ファイルに残す | チャットのままでよい |
|---|---|
| 要求と変更要求 | その場で答える簡単な確認 |
| 番号付きタスクの計画 | 許可のプロンプト(「テストを実行してよいですか?」) |
| 後の作業に影響する決定事項 | 状況確認(「どこまで進みましたか?」) |
| 未解決の質問と後回しにした作業(Todo) | すぐ自分で確認できる小さな単発の修正 |
| 顧客資料の要約と質問リスト | デバッグのやりとり |
| 対応してほしいレビューコメント | まだ決めていないアイデア |
判断基準は単純です。将来のセッション、あるいは将来のあなたが必要とするなら、プロジェクトに書き残してください。
エージェントを指揮する PM の週次リズム
ループにはリズムが必要です。そうでないと、ビルドが順調なときにレビューと追跡が飛ばされます。
- 月曜: 新しい顧客資料を読み、その週の要求を更新または作成し、エージェントに計画を出してもらいます。実行を始める前に計画をレビューします。
- 火曜から木曜: 実行を回します。ターミナルに張り付かず、待機中のセッションを 1 日に数回確認します。レビューはまとめて行います。たとえば午前の遅い時間と夕方です。
- 金曜: Todo リストを一通り確認します。答えられるものに答え、クライアントだけが答えられる質問を送り、後回しの項目には後回しの印を付けます。約束した内容に対して計画の進捗を確認します。クライアント向けの簡単な状況報告は、記憶ではなく計画から書きます。
金曜の 30 分が、「それは終わっていると思っていた」という場面の大半を防ぎます。
PMDesk はこのループをどう支えるか
PMDesk は、こうした仕事のために作られた macOS デスクトップアプリです。1 人または少人数で、複数のプロジェクトにまたがって Claude Code や Codex のエージェントを指揮する使い方を想定しています。AI モデルは含まれておらず、すでにお使いの Claude Code や Codex を、ご自身のサブスクリプションで実行します。ループとの対応は次のとおりです。
- インテーク: 顧客資料フォルダ(Box、Google Drive、または任意のフォルダ)を登録します。PMDesk 上で閲覧でき、エージェントはファイルをその場で読みます。PMDesk がそこに書き込むことはありません。
- 要求と CR: PMDesk で要求と変更要求を書き、ワンクリックでエージェントに渡すと新しいセッションが始まります。要求やコメントで @ を入力すると、プロジェクトのファイルや顧客資料を参照できます。
- 計画と進捗: Terminal ページの Tasks ペインに、計画のタスクと Claude Code が委任したサブエージェントが表示されます。コミットでタスクに言及すると、そのタスクにチェックが付き、Requests ページに計画の進捗が表示されます。
- 連絡がつく状態の維持: 各プロジェクトに専用のタブがあり、エージェントは本物のターミナルで動きます。セッションはバックグラウンドで動き続けます(デフォルトで同時に 5 つ、設定で変更可能)。エージェントがターンを終えたときや許可を求めているときは、セッション、プロジェクトタブ、サイドバーの「回答待ち」バッジで知らせ、必要に応じて macOS の通知も出せます。履歴からセッションの再開、名前の変更、アーカイブもできます。
- レビュー: エージェントが生成した Markdown や HTML を読み、特定の箇所にコメントして、すべての修正指示をまとめてエージェントに送れます。
- 未解決の質問: あなたやエージェントが追加した Todo が優先度順に並び、ステータスと、それを書いたセッションへのリンクが付きます。
プロジェクトのデータは、お使いのマシン上のプロジェクトフォルダに残ります。PMDesk for Mac をダウンロードできるほか、エージェント向けの既成スキルはスキルマーケットプレイスで探せます。
FAQ
技術者でない PM でも Claude Code を使えますか?
はい、仕事の大部分では使えます。要求を書く、エージェントの計画や要約を読む、結果を「done when」に照らして確認する、進捗を追跡する、といった作業です。Claude Code はターミナルで動くため、慣れるまで少し学習が必要になるか、要求、計画、レビューをターミナルの外で扱えるツールを使うことになります。リスクの高い変更のコードレビューには、やはりコードを読める人が必要です。
AI エージェントがコードを書くとき、PM は何をするのですか?
PM は、エージェントが動ける要求を書き、エージェントの質問に素早く答え、要求に照らして成果物をレビューし、進捗と未解決の質問を追跡します。エージェントは要求の抜けをすべて推測で埋めるため、人間のチームよりも、文章力と判断の速さが重要になります。
AI コーディングエージェントだけで、1 人でプロダクトを届けられますか?
社内ツール、クライアント案件、小規模なプロダクトの多くでは可能です。ただし、その人が要件、レビュー、追跡を担っていることが条件です。構築の大半はエージェントが担います。セキュリティ、決済、個人情報に関わるものは人間のレビューを前提にし、新しいセッションが引き継げるよう、決定事項はファイルに残してください。
すべての diff を読まずに、AI 生成コードをレビューするには?
要求に照らして結果を確認します。「done when」のチェックを自分で実行し、求めたテストが存在して通ることを確かめ、変更ファイルの一覧を求めてスコープの逸脱を見つけ、エージェントの計画や要約を読みます。コードを細かく読むのは、リスクが高い部分だけにします。
Claude Code や Codex 向けの仕様はどう書けばよいですか?
短く、ファイルに書きます。なぜその変更が必要か、何を作るのか、何が対象外か、どうなれば完了とわかるか、どの資料を読むか、です。そのうえでエージェントに番号付きタスクの計画を出してもらい、コードが書かれる前にそれをレビューします。
PM として複数の Claude Code エージェントを管理するには?
プロジェクトごとに専用のセッションを持たせ、どのセッションでも作業を引き継げるよう要求と計画をファイルに置き、どのエージェントがあなたを待っているかがわかる環境を使います。詳しくはコンテキストを失わずに複数の Claude Code エージェントを管理する方法のガイドをご覧ください。