テックエイド
AI・業務自動化

Claude Codeで見積・工数算出と前提整理を半自動化｜根拠ある見積を量産する実装レシピ

#Claude Code #見積 #工数算出 #PM自動化 #プロジェクト計画
Claude Codeで見積・工数算出と前提整理を半自動化｜根拠ある見積を量産する実装レシピ

新規案件の見積依頼が来て、過去の似た案件を思い出しながらExcelに人日を入れていく。気づけば「前提条件」の欄は空白のまま、リスクバッファの数字も「20%くらい」とフィーリングで決めている。後日「なぜこの工数？」と聞かれて、説明に詰まった経験のあるPMは多いはずです。

「AIに見積を頼めばいい」という話もありますが、汎用AIは前提を勝手に決めてしまい、出てきた数字の根拠がたどれない。本当に効くのは、前提・除外・リスクバッファをClaude Codeに明文化させ、過去案件の実績工数を参照させる運用です。

この記事では、Claude CodeのSkillで見積前提を構造化し、過去案件レポジトリを参照させながら根拠付きの見積を半自動で組み立てる実装を、現場で動かせる粒度で解説します。

なぜ「AIで見積」は信用されないのか

見積を作るとき、本当に難しいのは数字そのものではなく**「前提・除外・リスクバッファ」を明文化すること**です。汎用AIに頼むと次の3つで失敗します。

  • 前提を勝手に決める：「ユーザー数1000名想定で…」と勝手に置かれ、後で全部やり直し
  • 除外事項が出てこない：「やらないこと」を書かないため、後で「これも含まれてるよね」と言われる
  • バッファ根拠が示されない：20%とだけ書かれ、なぜ20%なのか説明できない

Claude Codeは、Skillで見積出力フォーマットを固定し、過去案件の実績工数を必ず参照させ、前提・除外・バッファを章として強制することで、これら3つの問題を構造的に解決できます。

Claude Codeを「根拠付き見積生成器」にする全体像

必要な要素は次の3つです。

  1. 過去案件の実績工数レポジトリ：docs/estimates-archive/ にYAMLで保管
  2. 見積生成Skill：スコープ要約から見積ドラフトを生成し、前提・除外・バッファを必ず章立てする
  3. CLAUDE.md見積ルール：自社のバッファ算定ロジック、参照優先度、失格条件を明記

これが整うと、PMは「スコープ要約と過去案件タグ」を渡すだけで、根拠付き見積のドラフトを得られます。

ステップ1：過去案件の実績工数をYAML化する

docs/estimates-archive/2025-A-shop-renewal.yaml のように、案件ごとに実績工数を記録します。

project_id: "A-2025-shop-renewal"
industry: "EC"
scope_tags: ["要件定義", "基本設計", "実装", "結合テスト"]
team_size: 5
duration_months: 6
actual_phases:
  requirements: { planned_pd: 30, actual_pd: 45 }
  basic_design: { planned_pd: 40, actual_pd: 50 }
  implementation: { planned_pd: 80, actual_pd: 110 }
  it: { planned_pd: 25, actual_pd: 40 }
buffer_used_pct: 35
post_mortem:
  - "業務要件ヒアリングが部署別に必要で要件定義が1.5倍に膨らんだ"
  - "結合テストで他システム連携の不整合が頻発しIT工数が1.6倍"

ポイントは**「計画」と「実績」の両方を記録する**ことです。実績/計画の比率がわかれば、新規案件向けに「同じ業界・同じスコープなら何%バッファを積むべきか」を統計的に出せます。

ステップ2：見積生成Skillを定義する

.claude/skills/estimate-draft/SKILL.md を用意します。

---
name: estimate-draft
description: スコープ要約と参照タグから、docs/estimates-archive/ を参照して見積ドラフトを tmp/estimates/{project-id}.md に出力する。前提・除外・バッファを必ず章立てし、根拠を明記する
disable-model-invocation: true
allowed-tools: Read, Write, Glob
---

# 根拠付き見積生成Skill

## 入力
- `tmp/estimates/{project-id}-input.md`：スコープ要約と参照タグ（PMが手で書く）

## 処理
1. 入力から `scope_tags` と `industry` を読む
2. `docs/estimates-archive/` からタグ・業界が一致する過去案件を3件以内で抽出
3. 各フェーズの「実績/計画比率」の中央値からバッファ率を算出
4. 前提・除外・リスクバッファを必ず章として埋める
5. 根拠の章に「参照した過去案件と算出ロジック」を必ず記載

## 出力フォーマット
- ファイル名：`tmp/estimates/{project-id}.md`
- 章立て：①サマリー ②前提条件 ③除外事項 ④フェーズ別工数（人日） ⑤リスクバッファ（根拠付き） ⑥参照過去案件 ⑦PMが追加検討すべき論点

## 厳守
- 前提・除外を「（特になし）」で埋めない。最低3項目ずつ書く
- バッファ率は中央値ベースで計算し、根拠（参照案件名と算出式）を必ず併記
- 過去案件が見つからない場合は ⑦ にその旨を明記し、AI推測で数字を作らない

「前提・除外を最低3項目」とSkill側で強制しておくと、PMが見落としやすい論点をAIが必ず洗い出してくれます。

ステップ3：CLAUDE.mdに見積ルールを書く

## 見積運用ルール

### バッファ算定ロジック
- 過去案件の実績/計画比率の中央値を採用
- 過去案件3件未満しか参照できない場合は、保守的に40%固定
- 業界・スコープが完全一致する案件のみ参照（似た案件は使わない）

### 失格条件（このSkillで見積を出してはいけない場合）
- 過去案件が0件
- スコープが不明瞭で前提・除外を3項目埋められない
- 期間が3ヶ月未満かつ未経験技術スタック

### 自社バッファ表記ルール
- リスクバッファとコンティンジェンシーは別欄で書く
- 「予備費」「予備工数」は使わず、「リスクバッファ（前提リスクに対応）」「コンティンジェンシー（未知の事象に対応）」と区別する

CLAUDE.mdに「失格条件」を書くのが運用の肝です。AIにすべての見積を作らせるのではなく、AIで作ってよい範囲を明示することで、責任を持った数字が出てきます。

ステップ4：実際の運用フロー

新規案件の見積依頼が来たら、PMがやることは次の4ステップです。

  1. tmp/estimates/PROJ-2026-input.md にスコープ要約と参照タグ（業界・スコープ・期間）を書く
  2. ターミナルで claude を起動し、/estimate-draft PROJ-2026 と実行
  3. 生成された見積ドラフトを開き、⑦の論点をチームと議論。⑤のバッファ根拠も精査
  4. 議論後、最終版を docs/estimates/PROJ-2026.md に確定保存し、Excelに展開

慣れれば、初動の見積骨子が30〜60分で揃います。残り時間を「差別化要素の見積調整」「営業との見積戦略議論」に使えるのが大きな差になります。

期待効果と運用上の注意点

導入チームから報告される効果は次の3つです。

  • 見積根拠が説明できるようになる：「なぜ20%バッファ？」に「過去A案件・B案件の実績/計画比中央値が23%だから」と即答できる
  • 前提・除外の漏れが減る：Skill側で強制章立てするため、PMの経験差が出にくい
  • 見積初動の時間が半日→1時間：過去案件参照と数字算出が自動化される

一方で、運用上の落とし穴も3点あります。

  • 過去案件レポジトリのメンテを怠ると精度が落ちる：四半期に1回は棚卸し、新規案件の実績を必ずYAML化する
  • 見積を「AIが出した」と言わない：見積責任はPMにある。AIで作ったものをそのまま提出するのではなく、必ずレビューしてからクライアントに出す
  • 失格条件を緩めない：過去案件0件で出してしまうと、AIが幻覚で数字を作る。失格時は人手で見積を作る運用に切り替える

まとめ

  • 見積の信頼性は前提・除外の言語化とバッファ根拠の明示で決まる
  • 過去案件を構造化YAMLで蓄積することが、AIによる見積品質の前提条件になる
  • CLAUDE.mdに「失格条件」を書き、AIで出してよい範囲を明示すると事故が減る
  • 見積初動を1時間に圧縮すると、戦略・差別化の議論に時間を回せる

ここまでの仕組みは「動く見積生成器」です。実務でこれを“受注に繋がる見積”に育てるには、リスクバッファの戦略設計、価格設定、提案フェーズの議論材料化といった上位設計が必要です。

IPJ-104『見積とリスクバッファ設計』 と AIX-103『AIで進める計画フェーズ』 を組み合わせると、本記事のSkillをベースに、見積〜契約〜実行までの数字の整合を保つPM運用を体系で学べます。「見積の根拠を聞かれて毎回詰まる」PMが、最短で抜け出すための導線になります。