ChatGPTでWBSを作る｜工数見積もりまで一度に出す

おすすめの無料ドヤAIサービス！

ドヤプロマネ

案件のタスク・進捗・収支をまとめて管理し、プロジェクト運営を効率化します。

ドヤプロマネを詳しく見る

ドヤ見積もりAI

見積書作成に必要な情報整理と算出をAIで効率化し、見積業務のスピードと精度を高めます。

ドヤ見積もりAIを詳しく見る

結論から書きます。ChatGPTはWBSの分解と、三点見積もりの叩き台づくりでは即戦力になります。ですが「この工数が妥当か」は判断できません。判断には自社の過去実績が要るからです。この記事では、スコープ確定からWBS分解、三点見積もり、依存関係、抜けの検出までを5本のプロンプトで全文公開します。あわせて、PERT期待値とバッファの計算式、そして「見積もりは出せるが実績と突き合わせられない」という限界の正体を書きます。

この記事で分かること

• 見積もり手法4種のうち、ChatGPTが担える範囲と担えない範囲

• プロンプト5本の全文（スコープ確定→WBS分解→三点見積もり→依存関係→抜けの検出）

• WBSをどこまで分解するかを決める停止条件（コピペ可）

• PERT期待値とバッファの計算式（コピペ可）

• 見積もりを金額に変換する式と、丸め方のルール

• WBS・工数見積もりを扱う手段9種の比較表（2026年8月6日 公式サイト確認）

1. ChatGPTのWBSがそのまま使えない3つの理由

「〇〇のプロジェクトのWBSを作って」と頼むと、それらしい階層構造は返ってきます。ですがそのまま関係者に配れません。理由は3つあります。

理由1：スコープが決まっていないまま分解している

WBSはスコープの分解であって、作業のアイデア出しではありません。スコープが「Webサイトをリニューアルする」のままだと、AIは一般的なWeb制作の工程を並べます。そこには、今回はやらないこと（既存コンテンツの移行は先方が行う、多言語対応は次期フェーズ、など）が反映されません。

結果として、やらない作業まで含んだWBSができ、工数が水増しされます。

理由2：粒度がそろわない

出てきたWBSを見ると、「要件定義」（20人日相当）と「favicon作成」（0.2人日相当）が同じ階層に並んでいることがあります。粒度がそろっていないWBSは、進捗率が計算できません。タスク数で進捗を測ると、faviconを終わらせただけで進んだことになります。

理由3：自社の生産性を知らない

これが本質です。「テスト設計：3人日」という数字は、誰がやるかで倍以上変わります。AIが出すのは業界の平均的な感覚に近い値であって、自社のメンバーの速度ではありません。過去の類似案件で何人日かかったかを知っているのは自社だけで、そのデータをAIは持っていません。

理由1と2はプロンプトで解決できます。理由3は解決できません。この記事の構成はこの線引きに沿っています。

2. 独自の分類軸：見積もり手法4種とChatGPTの守備範囲

工数見積もりの手法は、大きく4つに分かれます。どの手法を使おうとしているかを自覚しないまま「見積もって」と頼むから、出てきた数字の信頼度が判断できなくなります。

手法A：類推見積もり（過去の似た案件から当てる）

「前回のECサイト構築が45人日だったから、今回は規模が1.5倍で65人日」という出し方です。速いです。精度は過去案件の類似度に依存します。

ChatGPTの適性：低いです。AIは自社の過去案件を知りません。ただし、自分が過去案件のデータを渡せば、類推の計算そのものは手伝えます。

手法B：係数見積もり（規模×単位工数）

「画面数25 × 1画面あたり0.8人日 = 20人日」という出し方です。規模の指標（画面数、機能数、行数）と、単位あたりの工数（原単位）が必要になります。

ChatGPTの適性：条件付きです。原単位を自分で渡せば計算はできます。原単位そのものをAIに聞くと、一般論が返ります。その一般論を自社の数字として使うと外れます。

手法C：ボトムアップ見積もり（WBSの末端を積み上げる）

WBSを分解しきって、末端タスクごとに工数を置き、合計します。最も手間がかかりますが、抜けを発見しやすいです。

ChatGPTの適性：高いです（分解部分のみ）。WBSへの分解はAIが得意な領域です。ただし末端の工数の値は、理由3の問題が残ります。

手法D：三点見積もり（楽観・最頻・悲観の3つを置く）

各タスクに、楽観値（O）・最頻値（M）・悲観値（P）の3つを置き、期待値を計算します。不確実性の大きさを数字にできるのが利点で、バッファの根拠になります。

ChatGPTの適性：高いです。「3つの値を置き、それぞれの前提条件を書く」という作業は言語化そのものなので、AIとの相性がいいです。この記事はここを主軸にしています。

4手法の整理

実務での組み合わせはこうなります。Cで分解し、Dで各タスクの幅を出し、AまたはBで全体を検算します。ChatGPTが担うのはCの分解とDの叩き台で、AとBの数字は自社が持ち込みます。

3. 【コピペ可】WBSをどこまで分解するかの停止条件

分解の停止条件を先に決めておかないと、AIは無限に細かくするか、大雑把なまま止まります。この条件をプロンプトに貼ります。

■ WBS分解の停止条件（すべて満たしたら、それ以上分解しない）

□ 1. 所要が「0.5人日以上、5人日以下」に収まっている
      ※5人日を超えるものはさらに分解する
      ※0.5人日未満のものは、隣のタスクに統合する
□ 2. 担当者を1人に決められる
      ※2人以上でしか進まないタスクは、役割ごとに分ける
□ 3. 「終わった」と言える条件を1文で書ける
      ※「設計する」ではなく「設計書をレビュー完了させる」
□ 4. 成果物が1つ特定できる
      ※成果物のないタスク（会議、調整）は、
        それ自体をタスクにせず、関連する成果物タスクに含める
        ただし定例会議のように継続的に発生するものは
        「プロジェクト管理」として1本にまとめる
□ 5. そのタスク単体で進捗を「未着手／着手／完了」の3値で言える
      ※「70%完了」と言いたくなるなら、分解が足りない

■ 階層の目安
  レベル1：フェーズ（要件定義／設計／実装／テスト／リリース／管理）
  レベル2：成果物のまとまり（画面設計、DB設計、など）
  レベル3：末端タスク（上の5条件を満たすもの）
  ※3階層で収まらない場合は、スコープが大きすぎる可能性が高い

■ 「8/80ルール」との関係
  末端タスクを8時間以上80時間以下に収める、という広く使われる目安がある。
  上記の「0.5人日以上5人日以下」は1日8時間換算でこれに沿った範囲だが、
  2週間スプリントで回すなら上限を3人日に狭めたほうが管理しやすい。
  自社のリズムに合わせて上限だけ調整すること。

条件5が最も効きます。「70%完了」と言いたくなるタスクは、必ず分解が足りません。この1条件だけでも、WBSの質は目に見えて変わります。

4. 【全文掲載】プロンプト5本

【】 の部分だけ差し替えて使います。順番に回してください。プロンプト2以降は、前の出力を材料にします。

プロンプト1：スコープとアウトオブスコープを確定する

WBSの前に必ずこれを回します。ここを飛ばすと、以降がすべて無駄になります。

あなたはプロジェクトマネージャーの補佐役です。
以下のプロジェクトについて、スコープを確定させるための整理をしてください。
WBSはまだ作らないでください。

【プロジェクト概要】
- 目的：【何のためにやるか。1文で】
- 成果物：【最終的に何を納品／リリースするか】
- 期間：【開始日 〜 完了希望日】
- 体制：【人数と役割。例：PM1名、エンジニア2名、デザイナー1名（週2日）】
- 制約：【予算上限、使う技術、外部依存など。分かる範囲で】
- 発注者／依頼元：【社内の誰か、社外のどこか】

【出力形式】

## 1. スコープに含まれると読み取れるもの
| # | 内容 | 概要のどの記述から読み取ったか |
|---|---|---|

## 2. スコープに含まれるか判断できないもの（要確認）
| # | 項目 | なぜ曖昧か | 確認先 | 含む場合の追加工数の見当（大/中/小） |
|---|---|---|---|---|
※このプロジェクトで最も揉めやすい論点から順に並べる

## 3. アウトオブスコープの候補
明示的に「やらない」と合意しておくべき項目を列挙してください。
一般的なプロジェクトで後から揉めやすいものを優先すること。
| # | やらないこと | 合意しないと起きること |
|---|---|---|

## 4. 前提条件（この見積もりが成立する条件）
| # | 前提 | 崩れた場合の影響 |
|---|---|---|
（例：先方のレビューは3営業日以内に返る、素材は先方が用意する）

【厳守ルール】
- 概要に書かれていないことを、確定事項として書かない
- 工数の具体的な数値をここでは出さない（大/中/小の見当までにとどめる）
- 一般論を並べず、このプロジェクトの記述に紐づくものだけを書く

出力の「2. 判断できないもの」を、そのまま依頼元に確認します。ここで確定した内容を、次のプロンプトの前提に入れます。

プロンプト2：WBSを3階層に分解する

以下のスコープに基づいて、WBSを作成してください。

【スコープ（確定版）】
（プロンプト1の出力＋確認結果を貼る）

【アウトオブスコープ（絶対に含めない）】
（確定したものを箇条書きで貼る）

【分解の停止条件】
（本記事3章の停止条件をここに貼る）

【出力形式】
Markdownの表で、以下の列を持つ1つの表にしてください。

| WBS-ID | レベル1（フェーズ） | レベル2（成果物） | レベル3（末端タスク） | 完了条件（1文） | 成果物 | 想定担当ロール |
|---|---|---|---|---|---|---|

- WBS-IDは 1 / 1.1 / 1.1.1 の形式
- レベル3の行だけ「完了条件」「成果物」「担当ロール」を埋める
- レベル1・2の行は名称のみで、工数や完了条件を書かない

表のあとに、以下を出力してください。

## 分解の自己点検
| 停止条件 | 満たしていない末端タスクのWBS-ID |
|---|---|
| 0.5〜5人日に収まらない見込み | |
| 担当を1人に決められない | |
| 完了条件が1文で書けない | |
（該当なしの場合は「なし」）

## 意図的に含めなかったもの
アウトオブスコープに従って除外した作業を列挙してください。

【厳守ルール】
- アウトオブスコープの項目をWBSに含めない
- この段階では工数を書かない（次の指示で扱う）
- 「プロジェクト管理」「品質管理」など、成果物が曖昧なフェーズも
  必要なら立てる。ただし末端タスクには具体的な成果物を書く

工数をここで書かせないのが要点です。分解と見積もりを同時に頼むと、工数の帳尻を合わせるために分解が歪みます。

プロンプト3：三点見積もりを出させる

以下のWBSの末端タスク（レベル3）について、三点見積もりを作成してください。

【WBS】
（プロンプト2の出力を貼る）

【前提】
- 1人日 = 【8】時間
- メンバーの経験値：【例：この技術の経験は2年程度。類似案件は1件経験済み】
- 割り込み率：【例：他案件の割り込みで、稼働の20%は取られる】
- レビュー体制：【例：社内レビューは1回、先方レビューは各成果物1回】

【出力形式】

| WBS-ID | 末端タスク | 楽観O（人日） | 最頻M（人日） | 悲観P（人日） | Oの前提 | Pのリスク要因 |
|---|---|---|---|---|---|---|

## 悲観値が大きいタスク（上位5件）
P − O の差が大きい順に5件挙げ、それぞれについて
「差を縮めるために、着手前にできること」を1行で書いてください。

## 見積もれなかったタスク
情報不足で3値を置けなかったタスクを列挙し、
何が分かれば置けるかを1行で書いてください。

【厳守ルール】
1. 3値はすべて0.25人日刻みで書く
2. O ≦ M ≦ P を必ず守る
3. 「Oの前提」には、その速度が出るための条件を具体的に書く
   （例：既存コンポーネントを流用できる場合）
4. 「Pのリスク要因」には、遅れる原因を具体的に書く
   （例：先方のレビューが2往復した場合）
5. 期待値・合計・バッファをここで計算しない（人間が計算する）
6. 一般的な相場ではなく、上記【前提】に書かれた条件を反映した値にする

期待値の計算をAIにさせないでください。5番目のルールは重要で、AIに合計させると数値がずれることがあります。計算は次章の式で自分でやります。

プロンプト4：依存関係とクリティカルパス候補を出す

以下のWBSについて、タスク間の依存関係を整理してください。

【WBS（三点見積もり付き）】
（プロンプト3の出力を貼る）

【出力形式】

## 依存関係表
| WBS-ID | タスク | 先行タスク（WBS-ID） | 依存の種類 | 依存の理由 |
|---|---|---|---|---|
※依存の種類は FS（先行完了後に開始）/ SS（同時開始）/ FF（同時完了）の3つだけを使う

## 並行して進められるタスクのまとまり
同時に着手できるタスクをグループにまとめてください。
| グループ | 含まれるWBS-ID | 必要な人数 |
|---|---|---|

## 最長経路の候補
先行関係をたどって最も長くなる経路を1本示し、
経路上のタスクをWBS-IDの順に並べてください。
※各タスクの最頻値Mを使って経路長を示すこと
※これは候補であり、確定したクリティカルパスではないと明記すること

## 外部依存で止まりうる箇所
自社の努力では短縮できない待ち時間を列挙してください。
（例：先方の承認待ち、外部APIの申請、素材の納品待ち）
| 箇所 | 想定待ち日数 | 前倒しでできる準備 |
|---|---|---|

【厳守ルール】
- WBSにないタスクを追加しない
- 依存の理由を必ず書く。「一般的にそうだから」は書かない
- 経路長の計算結果は概算であることを明記する

プロンプト5：抜けている定番タスクを検出する

WBSの最大の失敗は、書かれているタスクの見積もりが甘いことではなく、タスクそのものが存在しないことです。

以下のWBSを検査してください。
このWBSに「含まれていない」作業を指摘するのが目的です。

【WBS】
（プロンプト2または3の出力を貼る）

【アウトオブスコープ】
（貼る。ここに書かれているものは指摘対象から除外する）

【検査の観点】
以下の観点ごとに、WBSに該当タスクがあるかを確認し、
ない場合は「不足」として指摘してください。

1. 立ち上げ：環境構築、アカウント発行、権限設定、キックオフ
2. 合意形成：要件のレビュー、成果物の承認、仕様変更の記録
3. 品質：テスト設計、テスト実施、バグ修正の時間、受け入れテスト支援
4. 移行：既存データの移行、旧環境の停止、切り戻し手順の用意
5. 引き渡し：ドキュメント作成、操作説明、問い合わせ対応期間
6. 管理：進捗会議、報告資料作成、課題管理
7. 待ち時間：レビュー待ち、承認待ち、外部からの納品待ち
8. リリース後：初期不具合対応、監視、振り返り

【出力形式】

## 不足しているタスク
| # | 観点 | 不足しているタスク | なぜ必要か | 追加する場合の階層（WBS-ID案） |
|---|---|---|---|---|
※影響の大きい順に並べる

## 過剰の疑いがあるタスク
アウトオブスコープに近い、または重複していると読めるタスクを指摘してください。
| WBS-ID | タスク | 疑いの理由 |
|---|---|---|

## 判定
不足の指摘が0件の場合は「不足は検出されませんでした」とだけ書く。
無理に指摘を作らないこと。

【厳守ルール】
- アウトオブスコープに明記されている作業を「不足」として指摘しない
- 「一般的に必要」ではなく、このプロジェクトの成果物に紐づけて理由を書く

プロンプト5の指摘のうち、観点6（管理）と観点7（待ち時間）は、ほぼ毎回不足として出ます。ここが抜けたWBSは、実行段階で必ず超過します。

5. 【コピペ可】PERT期待値とバッファの計算式

三点見積もりが出たら、計算は自分でやります。表計算に貼れる形で書きます。

■ 三点見積もりからの計算式

【1】タスクごとの期待値（PERT期待値）
  E = ( O + 4M + P ) / 6

  例：O=2, M=3, P=8 のとき
      E = (2 + 4×3 + 8) / 6 = 22 / 6 = 3.67 人日

【2】タスクごとの標準偏差
  σ = ( P − O ) / 6

  例：σ = (8 − 2) / 6 = 1.00 人日

【3】プロジェクト全体の期待値
  E_total = 各タスクの E の単純合計

【4】プロジェクト全体の標準偏差
  σ_total = √( σ1² + σ2² + … + σn² )

  ※各タスクの σ を単純に足してはいけない。
    独立に振れる前提で二乗和の平方根を取る

【5】バッファの置き方（片側の信頼水準ごと）
  約84%の確率で収まる線 : E_total + 1.00 × σ_total
  約90%の確率で収まる線 : E_total + 1.28 × σ_total
  約95%の確率で収まる線 : E_total + 1.65 × σ_total

  ※上記はいずれも「この線以下に収まる確率」（片側）で読む。
    E_total ± 1σ の区間に収まる確率が約68%、という両側の言い方と
    混同しないこと
  ※正規分布を仮定した目安。タスク数が少ない（10件未満）ときは
    この近似が弱くなるので、係数をそのまま使わないこと

【6】表計算での書き方（Googleスプレッドシート／Excel共通）
  期待値      : =(B2 + 4*C2 + D2)/6
  標準偏差    : =(D2 - B2)/6
  全体期待値  : =SUM(E2:E40)
  全体標準偏差: =SQRT(SUMSQ(F2:F40))
  90%ライン   : =E41 + 1.28*F41

■ 工数から金額への変換
  タスク金額 = E（人日） × 担当ロールの原価日単価
  ※原価日単価 = （月額人件費 ＋ 法定福利費 ＋ 間接費配賦） ÷ 月間稼働日数
  ※販売価格ではなく原価で先に計算する。粗利を見るため

■ 丸め方のルール（先に決めておく）
  - 個別タスクは 0.25人日 刻みのまま丸めない
  - 合計を出したあとで 0.5人日 刻みに切り上げる
  - 「切り捨て」は使わない。切り捨てた分は必ず超過する

バッファを「全体に20%上乗せ」で置いている場合、この式に置き換えると根拠が説明できるようになります。不確実性の大きいタスクが多い案件ほどバッファが厚くなり、定型作業ばかりの案件では薄くなります。これは感覚と一致します。

5-5. 5本を回す順番と所要時間の目安

実際にやると、どこに時間がかかるかが分かりにくいので書いておきます。中規模（末端タスク40〜60件）のプロジェクトでの目安です。

プロンプト5を、3ではなく2の直後に回すのがコツです。抜けを見つけてから見積もるほうが、見積もりの手戻りが少ないです。抜けたタスクを後から足すと、依存関係も三点見積もりも作り直しになります。

合計の作業時間は1時間前後です。ただし表の「回答待ち」と「担当者との確認」は別枠で、ここを短縮しようとすると精度が落ちます。AIで短縮できるのは表の左側（作業時間）であって、右側（人がやること）ではありません。

6. ChatGPTだけで足りるケースと、足りなくなる条件

6-1. ChatGPTだけで十分なケース

• 単発のプロジェクトです。次に似た案件が来るか分かりません

• 見積もりの用途が社内の目安です。外部への提出金額の根拠にはしません

• メンバーが3人以下です。誰がどれだけ速いかを全員が把握しています

• 過去実績のデータがそもそもありません。この場合、AIの叩き台のほうが白紙より速いです

この条件なら、上の5本をそのまま回せば大丈夫です。WBSの分解と抜けの検出だけでも、白紙から書くより明確に速いです。

6-2. 足りなくなる5つの条件

1. 同じ種類の案件を繰り返しています。3件目以降は、AIの一般論より自社の実績値のほうが正確になります。ですが実績が記録されていないと、その優位を使えません

2. 見積もりが受注金額の根拠になります。外に出す数字である以上、「なぜこの工数か」を説明する必要があります。「AIが出した」は根拠になりません

3. 見積もりと実績を突き合わせたい。これが最大の壁です。ChatGPTは見積もりを出せますが、実績を持っていません。突き合わせるには、実績工数がどこかに記録されている必要があります

4. 案件が同時に複数走っています。個別の見積もりは作れても、「今月このメンバーは何人日ぶん埋まっているか」は分かりません

5. 見積もりの精度を上げたい。精度を上げる唯一の方法は、見積もりと実績の差分を蓄積して原単位を補正することです。この作業はプロンプトでは代替できません。

3番目が本丸です。見積もりの質は、見積もり技法ではなく、実績データの有無で決まります。

7. 見積もりと実績を突き合わせる仕組みが要る理由

もう少し踏み込んで書きます。見積もり精度が上がる仕組みは、単純です。

1. WBSの末端タスクごとに見積もり工数（E）を持ちます

2. 実際にかかった時間を、同じ末端タスクの単位で記録します

3. 案件終了後に E と実績の比率（実績÷見積もり）を出します

4. その比率をタスク種別ごとに集計し、次回の見積もりに掛けます

この4ステップのうち、ChatGPTが担えるのは1だけです。2〜4はデータの蓄積と集計であって、生成の仕事ではありません。

そして2で詰まる会社が多いです。実績を「案件単位」でしか記録していないと、3の比率が案件全体でしか出ません。「テスト工程だけ常に1.8倍かかる」といった、補正に使える粒度の情報が得られません。

記録の粒度が、見積もり精度の上限を決めます。逆に言えば、末端タスクの粒度で実績が取れていれば、見積もりは回を重ねるごとに勝手に良くなります。

8. 比較表：WBSと工数見積もりを扱う手段9種

列は「WBSを階層で持てるか／見積もり工数を持てるか／実績工数と突き合わせられるか／人件費単価で金額化できるか」に絞りました。ガントチャートの見た目や連携数では並べません。6章で挙げた詰まりどころに直接対応する列にしています。

料金はすべて2026年8月6日に各公式サイトで確認しました。確認できなかったものは正直にその旨を記載します。

※料金を確認できなかった項目に推測値は入れていません。契約前に各社の公式ページで必ず確認してください。

この表から読み取れる3つの事実

1. 「見積工数を持てる」手段は多いですが、「実績と突き合わせられる」手段は絞られます。この差が、見積もり精度が上がらない構造的な原因になっています

2. 人件費で金額化できるかは、ツールの分類がタスク管理系か案件管理系かでほぼ決まります。タスク管理系は時間までは持ちますが、金額に変換する前提を持たないことが多いです

3. 最初の1案件なら表計算とChatGPTで十分回ります。破綻するのは案件が並行して3件を超えたあたりからで、ファイルの分散が原因になります

9. ツールでは解決しない部分

9-1. 見積もりを削れという圧力

見積もりが32人日と出ても、「予算が24人日ぶんしかない」と言われる場面があります。ここで数字を24に書き換えると、WBSの意味が消えます。やるべきなのは工数を削ることではなく、スコープを削ることです。プロンプト1で作ったアウトオブスコープの表は、この交渉のために使います。

9-2. 「たぶんできる」と言ってしまう習慣

三点見積もりの悲観値Pは、正直に置かないと機能しません。Pを低く置く癖のある人は、実績も必ず超過します。これは技法の問題ではなく、悪い知らせを先に出せるかという組織の問題です。

9-3. 途中で変わる要件

どれだけ正確なWBSを作っても、要件が変われば作り直しになります。WBSの価値は、正確さより「変更が起きたときに何が影響するかが分かること」にあります。プロンプト4の依存関係表は、そのために作ります。

9-4. メンバーの生産性そのもの

見積もりの精度が上がっても、作業が速くなるわけではありません。見積もりは、遅れを早く検知するための道具であって、速度を上げる道具ではありません。ここを取り違えると、工数管理そのものが「監視」と受け取られます。

FAQ

Q1. ChatGPTの無料版でも、この5本のプロンプトは使えますか

使えます。5本とも通常のテキスト入出力で完結します。ただしプロンプト2〜5は入出力が長くなるため、無料プランでは途中で止まることがあります。OpenAIは無料プランについて「メッセージ数とアップロード数に上限あり」と公式の料金ページに記載しています（2026年8月6日確認）。対処としては、WBSをフェーズ単位に分けて回すのが現実的です。「要件定義フェーズだけ」「テストフェーズだけ」と区切れば、1回の入出力量が下がります。プロジェクトの前提を毎回貼り直したくない場合は、プロジェクト機能に前提を保存できます。プロジェクトは公式ヘルプ上「無料・有料を問わず全プランで利用可能」と記載されています（2026年8月6日確認）。

Q2. プロジェクトの情報をChatGPTに入力しても問題ないですか

判断の線引きを3段階で書きます。

1. 顧客名・システム構成・単価情報は、多くの場合に社外秘に当たります。特にメンバーの人件費単価は、社内でも限られた人しか見られない情報であることが多いです。5章の金額計算をAIにやらせる場合、単価そのものを入力せず、比率や仮単価で計算するという回避策があります

2. 法人向けプランでは前提が変わります。OpenAIはChatGPT BusinessおよびEnterpriseについて「既定でビジネスデータを学習に使わない」と公式に明記しています（2026年8月6日確認）。個人プランは設定によって挙動が変わるため、公式のデータ管理設定を確認します

3. 受託案件では、顧客とのNDAが第三者サービスへの入力を制限している可能性があります。契約書の秘密保持条項を確認します

安全側に倒すなら、顧客名を伏せ、システム名を一般名詞に置き換えてから入力します。WBSの分解精度はこれでほとんど落ちません。最終的な可否判断は、自社の情報管理責任者に確認してください。

Q3. AIが出した工数をそのまま見積書に載せていいですか

載せてはいけません。理由は2章の手法A・Bで書いたとおりで、AIは自社の生産性を知りません。使い方としては、①AIの三点見積もりを叩き台にする、②担当予定者に「この3値で妥当か」を1タスクずつ確認する、③自社の過去案件で近いものがあれば、その実績で検算する、という順になります。②を飛ばすと、実行時に担当者が納得していない工数で進むことになり、遅延が発生しても誰も申告しない状態になります。

Q4. 期待値の計算をChatGPTにやらせてはいけないのはなぜですか

生成AIは数え上げと四則演算を保証しないためです。特に30行を超える表の合計は、ずれることがあります。ずれても出力の見た目は正常なので、検算しない限り気づけません。5章の式を表計算に入れれば計算は一瞬で終わるので、そこはAIに任せる必要がありません。AIに任せるのは「3つの値を置く根拠を言語化する」部分で、算術ではありません。

Q5. WBSの階層は何階層が適切ですか

3階層を基本にします。4階層以上が必要になったら、そのプロジェクトは分割を検討したほうがいいです。実務上、レベル3の末端タスクが80〜120件を超えると、Excelでも管理しきれなくなります。逆に末端タスクが20件を下回る場合は、分解が粗すぎるか、そもそもWBSを作るほどの規模ではありません。末端タスク30〜80件が、3階層で扱いやすい範囲になります。

Q6. 見積もりと実績の差を、どのくらいの期間で補正できますか

同種の案件が3件たまると、傾向が見え始めます。ただし条件があります。3件とも末端タスクの粒度で実績が取れていること、タスク種別の分類が3件で共通していることです。案件ごとにWBSの分け方が違うと、比率を集計できません。だから、WBSのテンプレートを持つことが先になります。プロンプト2をそのまま使い回すと、フェーズの分け方は自然に揃います。これは意外に効きます。

見積もりと実績を、同じ場所で持ちたい場合

この記事の5本は、案件が単発で、見積もりの用途が社内の目安であれば、それだけで十分に機能します。プロンプト5（抜けの検出）だけでも回す価値があります。WBSの失敗の大半は、工数の甘さではなくタスクの欠落から起きます。

足りなくなるのは、同じ種類の案件を繰り返し始めたときです。見積もりを出しても実績と比べられないと、何回やっても精度が上がりません。案件が同時に3件以上走っていて、末端タスクの粒度で実績工数を取りたくて、そこに人件費単価を掛けて案件別の粗利まで見たい——この3つが同時に当てはまるなら、案件の進捗・収支・人件費を一元管理するドヤプロマネが候補になります。月9,980円（税込）の統一プランで、ドヤマーケAIの全14サービスを同じ料金で使えます。無料版があるので、まず進行中の1案件で、この記事のWBSをそのまま入れて比べてみてください。

ただし、道具を入れても実績が入力されなければ何も変わりません。入力が続く粒

度を先に決めることのほうが、ツール選びより先にあります。