WBSをAIで自動生成する手順｜プロンプト例と人間が直すべき箇所

WBS（Work Breakdown Structure）作成は、プロジェクト初期の工数を最も食う作業のひとつだ。AIに自動生成させれば、たたき台を作る時間は確実に短縮できる。ただし出力をそのまま使うと、粒度のバラつきや見えないタスクの欠落といった問題を後工程で抱え込む。この記事では、WBSをAIで自動生成する具体的な手順、そのまま使えるプロンプト、AIが陥りやすい失敗パターン、そして人間が必ずレビューで直すべき箇所を整理する。

WBSをAIで自動生成する基本フロー

WBSの自動生成は、一発のプロンプトで完成品を出させようとすると失敗する。段階を分けて対話的に進めるのが基本だ。

まず、プロジェクトの前提情報をAIに渡す。目的、成果物（デリバラブル）、スコープの境界、制約条件（納期・予算・体制）をテキストでまとめて入力する。この段階の情報が薄いと、AIは一般論的なテンプレートに寄った出力しか返さない。前段の要件定義が曖昧なままだと、WBSの粒度も曖昧になる。要件を先に構造化しておきたい場合は要件定義フェーズでAIを活用する：曖昧な要望を構造化する方法を先に済ませておくと精度が上がる。

次に、大分類（フェーズ）レベルの粗いWBSを生成させる。要件定義・設計・開発・テスト・移行・リリースといった大枠がここで出てくる。この段階でいきなり詳細タスクまで求めない。大枠が事業の実態と合っているかを人間が先に確認する。

大枠が固まったら、各フェーズを2〜3階層まで分解させる。この時「1タスクの粒度は1〜5営業日を目安にする」といった粒度ルールを明示すると、後工程での手直しが減る。最後に、依存関係と想定工数を追加させ、表形式で出力させる。この4段階（前提共有→大枠生成→分解→依存関係付与）を踏むことで、一発生成よりも実用に近いWBSができる。

そのまま使えるプロンプト例

実務で使えるプロンプトは、条件を細かく指定するほど精度が上がる。以下は大枠生成から詳細分解までの2段階プロンプト例だ。

ステップ1（大枠生成）のプロンプト例:

「あなたはPMOの経験豊富なプロジェクトマネージャーです。以下のプロジェクト概要を読み、WBSの大分類（フェーズ）を5〜8個提案してください。各フェーズには目的と主要な成果物を1行で添えてください。[プロジェクト概要：目的／スコープ／体制人数／納期／制約条件をここに記載]」

ステップ2（詳細分解）のプロンプト例:

「以下のフェーズを、実行可能なタスクレベルまで分解してください。各タスクの粒度は1〜5営業日を目安にし、それより大きい場合はさらに分割してください。出力は次の列を持つmarkdown表で：階層番号／タスク名／成果物／想定工数（人日）／前提タスク／担当ロール（未定の場合は空欄）。[対象フェーズ名と、そのフェーズで実施予定の作業メモをここに記載]」

工数や担当ロールを空欄で許容する指定を入れておくと、AIが根拠のない数字を埋めてしまう「もっともらしい嘘」を減らせる。

AIが生成したWBSでよくある失敗パターン

AI生成のWBSには、繰り返し現れる典型的な失敗パターンがある。

1つ目は粒度のバラつきだ。あるタスクは「詳細設計書作成（3人日）」と具体的なのに、別のタスクは「テスト実施」のように1〜2週間分の作業がひとまとめになっている。AIは文脈から重要度を推測して分解の深さを変えるため、均一な粒度を保証しない。

2つ目は見えないタスクの欠落だ。会議体（定例・レビュー会）、承認待ち期間、他部署やベンダーとの調整、社内稟議といった「実作業ではないが時間を食う工程」がスケジュールに反映されないことが多い。AIは入力情報にない組織固有のプロセスを補完できない。

3つ目は依存関係の誤認識だ。実際には並行実施可能なタスクを直列に並べたり、逆に本来は前工程の完了を待つべきタスクを並行扱いにしたりする。AIは一般的なプロジェクトの型を参照するため、そのプロジェクト固有の制約（例：特定メンバーしか対応できない作業）を反映できない。

4つ目は見積もり工数の楽観化だ。AIは「標準的な難易度」を前提に工数を出す傾向があり、レガシーシステムとの連携や過去に炎上した領域特有の手戻りリスクを織り込まない。

人間が必ず直すべきポイント

AI生成WBSのレビューでは、次の観点を優先的にチェックする。

チェック項目	AIが間違えやすい理由	修正の視点
タスクの粒度統一	文脈から重要度を推測し分解の深さが不均一になる	全タスクを1〜5営業日の範囲に収まっているか目視で確認する
見えないタスクの追加	会議・承認・調整はテキスト化されにくく入力情報に出てこない	定例会議・稟議・ベンダー調整をタスクとして追加する
依存関係の妥当性	組織固有の制約（人員のスキル依存等）を認識できない	実際に並行実施できるかを担当者ベースで再確認する
見積もり工数	標準難易度を前提に楽観的な数字を出しやすい	類似案件の実績工数と突き合わせ、バッファを上乗せする
リスクバッファ	手戻りやレガシー対応の特殊事情を織り込まない	高リスク領域には個別に予備工数を積む

この5点は毎回同じ観点でチェックできるため、レビュー用のチェックリストとして固定化しておくと、AI生成WBSの運用が安定する。

ガントチャート化とタスク管理ツールへの連携

WBSが固まったら、次はスケジュール化とタスク管理ツールへの落とし込みだ。WBSの表をそのままプロンプトに貼り付けてガントチャートの骨子を作らせる方法はChatGPTにガントチャートを作らせる方法：WBSから自動生成で詳しく解説している。依存関係列がすでに入っていれば、この変換はスムーズに進む。

タスク管理ツールに直接連携する場合、エンジニアチーム中心のプロジェクトならLinear AIでバックログを自動優先順位付け：エンジニアチームのPMが使う方法、スプリント単位で運用するチームならClickUp BrainでスプリントプランニングをAI化する方法が参考になる。WBSのタスク粒度をそのままバックログのチケット粒度に転用できると、二重入力の手間が減る。

精度を上げるための運用のコツ

WBSの自動生成精度は、使うほど上げられる。過去プロジェクトの実際のWBS（実績付き）をサンプルとしてプロンプトに添付し、「このプロジェクトと似た構成で」と指示すると、粒度や工数感が組織の実態に近づく。

また、一回の対話で完成させようとせず、生成→人間レビュー→修正指示→再生成のループを1〜2回挟む前提で時間を見積もっておく。最初の出力を70点の下書きとして扱い、レビューで浮かんだ疑問点をそのままAIへの追加指示に変換すると、手直しの時間が最小化できる。

規模の小さいプロジェクト（体制3〜5人、期間1〜2ヶ月程度）ではAI生成のたたき台をほぼそのまま使えることが多いが、複数部署・複数ベンダーが絡む大規模案件では、依存関係と見えないタスクの抜けが致命的になりやすい。プロジェクトの複雑度が上がるほど、人間によるレビュー工程を厚くする判断が必要になる。

あわせて読みたい

WBSやスケジュールの精度が甘いまま進行すると、プロジェクトの炎上リスクが高まる。実際にトラブルが発生した後の立て直し方まで知っておきたい場合はプロジェクトのトラブル解決大全が参考になる。WBSの分解粒度や依存関係の考え方そのものを体系的に押さえ直したい場合はPMBOK ガイド第7版を手元に置いておくと、AI出力の妥当性を判断する軸になる。