Claude Codeで工数見積もりを支援する方法｜PMが前提・除外・リスクをレビューする実務手順

「Claude Codeに工数見積もりを手伝わせたい。でも、AIが出した数字をそのまま信じてよいのか不安」

新規案件の見積依頼が来ると、PMは短時間で次のようなことを整理しなければなりません。

どこまでが今回のスコープなのか
何が成果物なのか
何を対象外にするのか
どのタスクにどれくらい工数がかかりそうか
どこにリスクバッファを積むべきか
顧客にどの前提で見積もったと説明するか

ChatGPTやClaude CodeのようなAIを使えば、見積のたたき台は早く作れます。

しかし、AIに「この案件の工数を見積もって」と丸投げすると、もっとも危険な部分が曖昧になります。

それは、前提・除外・リスク・根拠です。

工数見積もりで本当に重要なのは、AIが出した人日そのものではありません。

「どの前提でその数字になったのか」
「何を含んでいて、何を含んでいないのか」
「どのリスクを見てバッファを置いたのか」
「過去案件と比べて妥当なのか」

をPMが説明できることです。

この記事では、Claude Codeを使って工数見積もりを支援する実務手順を、PM向けに整理します。

この記事で分かること

この記事では、次の内容を扱います。

分かること	内容
AI見積が危険になる理由	AIが前提を勝手に置いてしまう問題を理解する
見積前に整理すべき情報	スコープ・WBS・成果物・対象外・制約を整理する
Claude Codeへの依頼方法	悪い依頼例と良い依頼例を比較する
見積入力テンプレート	Claude Codeに渡すMarkdownテンプレートを使える
AI出力のレビュー観点	PMが数字・前提・バッファを確認できる
過去案件の活用方法	見積根拠を過去実績に近づける考え方が分かる

なお、WBSをAIで作る前の前提整理は、AIでWBSを作る前の準備で解説しています。

また、WBS作成プロンプトそのものは、AIでWBSを作成するプロンプト例で詳しく解説しています。

この記事は、その次のステップである WBSから工数見積もりへ進める方法 を扱います。

AIに工数見積もりを丸投げすると危険な理由

まず、悪い依頼例を見てみます。

受注管理システム開発の工数を見積もってください。
期間は3ヶ月くらいです。
PM1名、エンジニア2名で進めます。

この依頼でも、AIはそれらしい見積を返してくれます。

たとえば、次のような回答です。

要件定義：10人日
設計：15人日
開発：40人日
テスト：20人日
リリース：5人日
合計：90人日
リスクバッファ：20%

一見すると使えそうに見えます。

しかし、この見積には大きな問題があります。

問題	なぜ危険か
スコープが曖昧	どの機能を含む見積なのか分からない
成果物が不明	設計書、テスト仕様書、マニュアルが含まれているか不明
対象外が不明	データ移行、環境構築、運用設計が含まれているか不明
バッファ根拠がない	なぜ20%なのか説明できない
過去実績との比較がない	自社の案件感覚と合っているか判断できない

このまま顧客や上司に出すと、あとで次のような問題が起きます。

「データ移行も当然入っていますよね？」
「受入テスト支援はこの工数に含まれていますよね？」
「なぜ20%のバッファを見ているんですか？」
「前回案件より少なく見えるけど大丈夫ですか？」

AIが出した見積は、数字だけ見ると整って見えます。

しかし、前提が説明できなければ、PMの見積としては使えません。

Claude Codeを見積支援に使うときの考え方

Claude Codeは、単にチャットで質問するAIではなく、プロジェクト内のファイル、Markdown、設定、過去資料を読みながら作業を支援できる点が強みです。

そのため、見積支援では次のような使い方が向いています。

1. 見積前提をMarkdownに整理する
2. WBSや成果物一覧をファイルとして渡す
3. 過去案件の実績メモを参照させる
4. 見積ドラフトを作らせる
5. PMがレビューすべき論点を出させる
6. 最終判断はPMが行う

つまり、Claude Codeに「工数の正解」を出させるのではありません。

PMが見積を作るための材料を、構造化して出させるイメージです。

工数見積もりの前に整理すべき情報

Claude Codeに工数見積もりを支援させる前に、最低限次の情報を整理します。

情報	書く内容
プロジェクト目的	なぜ実施する案件なのか
スコープ	今回作る機能・対象業務
WBS	見積対象になるタスク一覧
成果物	要件定義書、設計書、テスト仕様書など
対象外	今回の見積に含めない作業
前提条件	期間、体制、顧客作業、外部依存
過去類似案件	参考にできる実績工数
不確実性	未確定事項、リスク、確認待ち事項

特に重要なのは、対象外 と 不確実性 です。

PMがここを書かないと、AIは「一般的に必要そうな作業」を見積に含めたり、逆に重要な作業を抜かしたりします。

コピペ用：Claude Codeに渡す見積前提テンプレート

まずは、見積前提をMarkdownファイルとして整理します。

たとえば、次のようなファイルを作ります。

tmp/estimates/PROJ-2026-input.md

中身は次のようにします。

# 見積前提メモ

## プロジェクト名
ここに記入

## プロジェクト目的
この案件で達成したいことを書く

## スコープ
今回作る機能・対象業務を書く

## 成果物
納品物・作成物・完了条件を書く

## WBS草案
見積対象となるタスクを箇条書きで書く

## 対象外
今回の見積に含めない作業を書く

## 前提条件
期間、体制、顧客作業、外部依存、技術制約を書く

## 過去類似案件
参照できる過去案件があれば書く

## 未確定事項
まだ決まっていないことを書く

## 見積で特に確認したいこと
工数が膨らみそうな箇所、判断に迷っている箇所を書く

このテンプレートを埋めるだけでも、見積の品質は上がります。

なぜなら、PM自身が「何を見積もろうとしているのか」を整理できるからです。

悪い見積依頼と良い見積依頼

悪い依頼例

この案件の工数を見積もってください。
3ヶ月で作る予定です。

この依頼では、Claude Codeは一般的な見積しか出せません。

前提、スコープ、対象外、成果物、過去実績が分からないからです。

良い依頼例

tmp/estimates/PROJ-2026-input.md を読み、工数見積のドラフトを作成してください。

# 見積で重視してほしいこと

- 入力ファイルに書かれたスコープと対象外を必ず区別してください
- WBS草案をもとにフェーズ別・タスク別の工数を出してください
- 成果物が不明なタスクは、見積不能として指摘してください
- 前提条件が不足している箇所は、勝手に数字を置かず確認事項として出してください
- リスクバッファは一律20%ではなく、リスクごとに理由を添えてください
- 最後に、PMがレビューすべき論点を表形式で出してください

# 出力形式

以下の章立てで出してください。

1. 見積サマリー
2. 前提条件
3. 対象外
4. フェーズ別工数
5. リスクバッファ
6. 見積不能・確認が必要な項目
7. PMレビュー観点

この依頼では、Claude Codeに「数字を出す」だけでなく、「見積として使える形に構造化する」ことを求めています。

出力例：AIが作る見積ドラフト

Claude Codeに依頼すると、次のような見積ドラフトを作れます。

ここではイメージしやすいように、簡略版で示します。

フェーズ	主なタスク	基本工数	リスクバッファ	合計	主な根拠
要件定義	ヒアリング、業務整理、要件定義書作成	12人日	4人日	16人日	業務部門レビューが週2日しか取れない
基本設計	画面設計、API設計、権限設計	15人日	3人日	18人日	外部API仕様が未確定
開発	受注登録、ステータス管理、出荷指示	35人日	7人日	42人日	エンジニア2名体制で並行作業に制約
テスト	単体、結合、受入支援	18人日	5人日	23人日	顧客受入テストの稼働が限定的
リリース	リリース準備、本番反映、初期確認	5人日	2人日	7人日	夜間作業・切り戻し手順が必要
合計		85人日	21人日	106人日

このような表が出てきたとしても、まだ完成ではありません。

PMは、この見積をレビューし、過去案件、実際の体制、契約条件、顧客合意と照らし合わせて修正します。

AI見積をPMがレビューする7つの観点

AIが作った見積ドラフトは、次の観点で確認します。

観点	確認すること	よくある問題
スコープ	見積対象と対象外が分かれているか	対象外の作業が含まれている
WBS整合	WBSの各タスクと工数が対応しているか	タスクがあるのに工数がない
成果物	成果物作成工数が含まれているか	設計書・テスト仕様書・マニュアルが漏れる
粒度	工数が大きすぎる塊になっていないか	「開発40人日」だけで内訳がない
前提条件	顧客作業・外部依存・体制制約が反映されているか	顧客レビュー待ちを考慮していない
バッファ	リスクごとに理由があるか	一律20%で根拠がない
見積不能項目	不明点を勝手に仮定していないか	未確定事項にAIが数字を置く

特に危険なのは、不明点に対してAIが勝手に数字を置くことです。

PMは、数字を調整するだけでなく、「そもそも見積もれる状態か」を確認する必要があります。

生成AIで見積・前提整理・工数算出を実務に使いたい方へ
AIで工数のたたき台を出せても、実務では「前提」「対象外」「バッファ根拠」「見積不能項目」をPMがレビューする必要があります。
見積前提の整理から工数算出、AI出力の見直しまで体系的に学びたい方は、関連講座も確認してください。
生成AIで見積・工数算出を学ぶ講師クーポン対象講座を見る

過去案件を参照させると見積の説得力が上がる

見積の説得力を上げるには、過去案件の実績を参照することが有効です。

Claude Codeを使う場合、過去案件の実績をMarkdownやYAMLで管理しておくと、見積時に参照しやすくなります。

たとえば、次のようなファイルを用意します。

docs/estimates-archive/2025-order-management-renewal.yaml

中身の例です。

project_id: "2025-order-management-renewal"
industry: "manufacturing"
scope_tags: ["要件定義", "基本設計", "開発", "結合テスト", "受入支援"]
team_size: 4
duration_months: 4
planned_phases:
  requirements: 15
  basic_design: 20
  implementation: 45
  test: 25
actual_phases:
  requirements: 22
  basic_design: 24
  implementation: 58
  test: 36
buffer_used_pct: 32
lessons:
  - "業務部門レビューが週1回しか取れず、要件定義が長期化した"
  - "外部API仕様の確定遅れにより、結合テスト開始が2週間遅れた"
  - "受入テストで現行運用との差分指摘が多く、追加修正が発生した"

このように、計画工数と実績工数の両方を残しておくと、新規見積の根拠として使いやすくなります。

ポイントは、成功案件だけでなく、ズレた案件も残すことです。

見積が外れた理由こそ、次の見積で重要な判断材料になります。

Claude Code用の見積レビュー依頼プロンプト

Claude Codeに見積ドラフトをレビューさせる場合は、次のように依頼します。

以下の見積ドラフトを、経験豊富なプロジェクトマネージャーの視点でレビューしてください。

# レビュー観点

1. スコープと対象外が明確に分かれているか
2. WBSの各タスクに対応する工数があるか
3. 成果物作成工数が漏れていないか
4. 顧客レビュー、受入テスト、外部依存の待ち時間が考慮されているか
5. リスクバッファの理由が具体的か
6. 一律のバッファになっていないか
7. 見積不能な項目をAIが勝手に仮定していないか
8. 顧客に説明できない数字がないか

# 出力形式

| 指摘箇所 | 問題点 | 修正案 | 確認すべき相手 |
|---|---|---|---|

# 見積ドラフト

ここに見積ドラフトを貼り付ける

AIには、見積を作らせるだけでなく、レビュー相手として使うこともできます。

ただし、最終判断はPMが行います。

見積不能な項目を出させる

AI見積で重要なのは、無理に全部の数字を出させないことです。

見積に必要な前提が足りない場合は、「見積不能」として出させる方が安全です。

たとえば、次のような項目です。

見積不能項目	確認すべきこと
外部API連携	API仕様、認証方式、テスト環境、利用制限
データ移行	件数、項目数、データ品質、クレンジング範囲
受入テスト支援	顧客側の担当者、実施期間、支援範囲
セキュリティ対応	必要な診断、レビュー、承認フロー
運用設計	問い合わせ対応、監視、障害時対応、マニュアル範囲

AIが全部の数字を埋めてくれると、一見便利です。

しかし、PMとしては「まだ見積もれない」と言えることも重要です。

見積不能項目を明示すれば、顧客や営業と前提確認の会話ができます。

見積を顧客説明に使える形にする

見積は、社内で数字を置くだけでは不十分です。

顧客や上司に説明できる形にする必要があります。

見積ドラフトができたら、Claude Codeに次のような依頼をすると、説明材料を作りやすくなります。

この見積ドラフトをもとに、顧客向けに説明するための前提条件・対象外・リスクバッファの説明文を作成してください。

# 出力形式

## 見積前提
箇条書きで5項目

## 対象外
箇条書きで5項目

## リスクバッファを見ている理由
リスクごとに説明

## 顧客に確認したいこと
質問形式で整理

このように、見積を単なる数字ではなく、合意形成の材料に変えることが大切です。

Claude Codeで見積支援を運用するときの注意点

Claude Codeを使った見積支援には、注意点もあります。

1. 見積責任はAIではなくPMにある

AIが出した数字を、そのまま見積として提出してはいけません。

見積責任はPMまたは見積責任者にあります。

AIは、あくまで見積ドラフト、レビュー観点、確認事項を出すための補助です。

2. 過去案件データを放置すると精度が落ちる

過去案件を参照する場合、データのメンテナンスが必要です。

計画工数、実績工数、ズレた理由、教訓を残しておかないと、次の見積に活かせません。

少なくとも四半期に1回は、見積実績を棚卸しするとよいです。

3. 機密情報・個人情報を入力しない

見積には、顧客名、契約金額、システム構成、セキュリティ情報が含まれることがあります。

AIに入力する場合は、自社のセキュリティポリシーを確認し、必要に応じて情報を抽象化してください。

悪い例：
株式会社〇〇向けの受注管理システム。契約金額は〇〇万円。

改善例：
ある製造業企業向けの受注管理システム。契約金額は記載しない。

4. 「AIが出したので正しい」と言わない

顧客や上司に説明するときに、「AIが出した見積です」と言うのは避けるべきです。

説明すべきなのは、AIを使ったかどうかではなく、見積の前提、対象外、根拠、リスクです。

よくある質問

Claude Codeがないと、この方法は使えませんか？

いいえ。

この記事の考え方は、ChatGPT、Gemini、Claudeなどでも使えます。

ただし、Claude Codeを使うと、Markdownファイル、過去案件ファイル、プロジェクト内のドキュメントを参照しながら見積ドラフトを作りやすくなります。

AIに工数を出させるのは危険ではありませんか？

危険なのは、AIが出した数字をそのまま使うことです。

AIにドラフトを出させたうえで、PMが前提、対象外、WBS整合、過去実績、リスクをレビューするなら、見積初動の効率化には有効です。

過去案件がない場合はどうすればよいですか？

過去案件がない場合は、AIに確定的な数字を出させすぎない方がよいです。

その場合は、見積不能項目、確認事項、工数が膨らみやすいリスクを洗い出す用途に使うのがおすすめです。

バッファは何%にすればよいですか？

一律で何%と決めるより、リスクごとに理由を分ける方がよいです。

たとえば、外部API仕様未確定、顧客レビュー稼働不足、データ品質不明、未経験技術スタックなど、リスクごとにバッファ理由を説明できる状態にします。

まとめ

Claude Codeは、工数見積もりを自動化する魔法の道具ではありません。

しかし、見積に必要な前提、対象外、リスク、確認事項を構造化する支援には非常に有効です。

重要なのは、次の流れです。

WBSを整理する
↓
見積前提をMarkdownにまとめる
↓
Claude Codeに見積ドラフトを作らせる
↓
PMが前提・対象外・バッファ根拠をレビューする
↓
見積不能項目を確認する
↓
顧客や上司に説明できる形に整える

AIに数字を丸投げするのではなく、AIを使って見積の前提と論点を見える化する。

これが、PMにとって安全で実務的なClaude Codeの使い方です。