「AIにWBSを作らせたい。でも、出てくる内容が浅い」
新任PMやPMOとしてプロジェクト計画を作るとき、最初に悩みやすいのがWBS(Work Breakdown Structure)の作成です。
WBSはプロジェクトで実施する作業を分解し、全体像を見えるようにするための土台です。スケジュールを引くにも、工数を見積もるにも、担当者を決めるにも、まずはWBSが必要になります。
しかし、いざ作ろうとすると、次のような不安が出てきます。
- どの粒度までタスクを分解すればよいのか分からない
- タスクの抜け漏れがないか不安
- 要件定義、設計、開発、テスト、移行、運用準備のつながりが見えない
- 進捗管理や課題管理など、プロジェクト管理タスクを忘れがち
- AIに聞いても、一般的なタスクリストしか返ってこない
ChatGPT、Gemini、Claudeなどの生成AIを使えば、WBS作成のたたき台は短時間で作れます。
ただし、AIに「WBSを作って」と丸投げするだけでは、実務で使えるWBSにはなりません。
この記事では、AIでWBSを作成するときの悪いプロンプト例、改善プロンプト、AI出力例、PM視点のレビュー観点をまとめて解説します。
この記事でできること
この記事を読むと、次のことができるようになります。
| できること | 内容 |
|---|---|
| 悪いプロンプトの特徴が分かる | なぜAIのWBSが浅くなるのかを理解できる |
| WBS作成プロンプトを使える | ChatGPT・Gemini・Claudeで使えるテンプレートをコピーできる |
| AI出力をレビューできる | AIが作ったWBSをPM視点で確認できる |
| 工数見積・スケジュールにつなげられる | WBSを次の計画作業に展開しやすくなる |
| セキュリティ上の注意点が分かる | 機密情報を入れずにAIを使う考え方が分かる |
AIにWBS作成を依頼するときのよくある失敗
まず、多くの人がやりがちな失敗例を見てみましょう。
CRM導入プロジェクトでやることのリストを作ってください。
プロジェクト名はNextGen CRM導入プロジェクトです。
目的は、営業の業務効率を上げることです。
今のExcelでの顧客管理をやめたいと思っています。
期間はだいたい半年くらいです。
使うツールはSalesforceの予定です。
顧客データがExcelで1万件くらいあって、これも新しいシステムに入れないといけません。
どんなタスクがあるか、わかる範囲でいいので箇条書きで教えてください。
このプロンプトでも、AIは何かしらのタスクリストを返してくれます。
たとえば、次のような出力です。
- プロジェクト計画
- 要件定義
- システム設計
- Salesforce設定
- データ移行
- テスト
- ユーザートレーニング
- 本番リリース
- 運用開始
一見すると、それらしい内容に見えます。
しかし、このままでは実務では使いにくいです。
なぜなら、タスクの粒度が粗く、成果物も担当者も完了条件も見えないからです。
なぜAIのWBS作成は失敗しやすいのか
AIでWBS作成が失敗する原因は、AIの性能だけではありません。
多くの場合、AIに渡す情報が不足しています。
特に足りないのは、次の5つです。
| 不足している情報 | 何が問題になるか |
|---|---|
| AIの役割 | 一般論の回答になり、PM視点の抜け漏れ確認が弱くなる |
| プロジェクト背景 | 何のためのプロジェクトか分からず、優先順位が曖昧になる |
| 成果物 | 何を作れば完了なのかが見えない |
| 制約・前提条件 | 期間、予算、体制、データ移行、業務影響などが反映されない |
| 出力形式 | 箇条書きだけになり、WBSコードや階層構造が整わない |
つまり、AIにWBSを作らせる前に、PM側がプロジェクトの前提を整理する必要があります。
AIでWBSを作る前に整理すべき情報は、AIをWBS作成の助け船にするために、PMが決めるべきことでも詳しく解説しています。
この記事では、前提情報を整理したうえで、AIにどう依頼するかにフォーカスします。
WBS作成プロンプトの基本方針
AIでWBSを作るときは、次の順番で指示を組み立てます。
1. AIの役割を指定する
2. 自分の立場と困っていることを伝える
3. プロジェクト概要を構造化して渡す
4. 成果物・制約・前提条件を明記する
5. WBSの出力形式を指定する
6. AIにレビュー観点を持たせる
7. 最後に「草案でよい」と伝える
ポイントは、AIを単なるタスクリスト生成器として使わないことです。
経験豊富なPMにレビューを依頼するつもりで、背景、目的、成果物、制約、出力形式を具体的に渡します。
WBS作成プロンプト完全版
以下は、CRM導入プロジェクトを例にしたWBS作成プロンプトです。
ChatGPT、Gemini、Claudeなどでそのまま使えます。実際に使う場合は、プロジェクト名、目的、成果物、期間、体制、制約条件を自分の案件に合わせて書き換えてください。
あなたは、入力情報として与えられたプロジェクト概要に基づき、WBS(Work Breakdown Structure)を生成してください。
このWBSは、プロジェクトに初めてアサインされた新任プロジェクトマネージャーが、タスクの全体像を把握し、具体的な計画を立てるための土台となるものです。
単にタスクを羅列するだけでなく、プロジェクト遂行における各フェーズの目的、成果物、注意点が分かるアウトプットを期待します。
# あなたの役割
あなたは、大規模なシステム導入プロジェクトを数多く経験してきた、経験豊富なシニアプロジェクトマネージャーです。
特に、プロジェクト計画、スコープ整理、WBS作成、工数見積、スケジュール管理、リスク洗い出しに詳しいPMとして回答してください。
# 私の状況
私は、新任PMとして初めて「NextGen CRM導入プロジェクト」を担当します。
プロジェクト全体の見通しを立て、タスクの洗い出しと管理を抜け漏れなく行うために、WBSの草案を作りたいです。
ただし、どこから手をつければよいか、どの粒度でタスクを分解すればよいか分からず困っています。
# プロジェクト概要
## プロジェクト名
NextGen CRM導入プロジェクト
## プロジェクト目的
営業部門の業務効率を30%向上させ、顧客満足度を20%向上させる。
現在はExcelで顧客情報を管理しているが、属人化、情報の重複、更新漏れ、営業活動の見える化不足が課題になっている。
この課題を解決するため、クラウド型CRMシステムを導入する。
## 主要な成果物
- 要件定義書
- 業務フロー整理資料
- CRM項目定義書
- 基本設計書
- 設定済みCRM環境
- データ移行方針書
- データ移行結果
- テスト仕様書
- テスト結果報告書
- ユーザートレーニング資料
- 運用マニュアル
- リリース判定資料
## 期間
6ヶ月
## 予算
3,000万円
## チーム体制
- プロジェクトマネージャー:1名
- ITエンジニア:3名
- 営業部門代表:2名
- 外部ベンダー:CRMツール提供元
## 制約・前提条件
- 導入するCRMツールはSalesforceを前提とする
- 既存の顧客データはExcel形式で約1万件存在する
- 営業活動を止めずに移行する必要がある
- セキュリティ要件は社内規定に準拠する
- 営業部門の利用定着が成功の重要条件である
# 出力形式
以下の形式でWBSを作成してください。
1. WBSコードを付ける
2. 第1階層、第2階層、第3階層が分かるようにする
3. 各タスクに「目的」「成果物」「注意点」を付ける
4. 新任PMが見ても分かる平易な表現にする
5. プロジェクト管理タスクも必ず含める
6. データ移行、テスト、トレーニング、運用準備を見落とさない
7. 最後に、PMがレビューすべき観点を5つ挙げる
# WBSの粒度
第3階層は、担当者を割り当てられ、工数見積ができるレベルを目指してください。
ただし、これは最初の草案なので、完璧さよりも、抜け漏れを防ぐための網羅性と構造の分かりやすさを重視してください。
# 注意点
入力情報にない事実を勝手に断定しないでください。
ただし、システム導入プロジェクトで一般的に必要になる管理タスク、準備タスク、確認タスクは含めて構いません。
このプロンプトが有効な理由
このプロンプトの強みは、AIに「何をしてほしいか」だけでなく、「どの立場で、どの観点で、どの形式で考えてほしいか」を指定している点です。
| 指示 | 効果 |
|---|---|
| シニアPMとして回答 | 一般的な作業リストではなく、PM視点の構造化がされやすい |
| 新任PMの状況を説明 | 初心者にも分かる粒度で出力されやすい |
| 成果物を列挙 | タスクの完了条件が明確になりやすい |
| 制約・前提条件を明記 | データ移行、営業活動への影響、セキュリティが反映されやすい |
| 出力形式を指定 | WBSコード、目的、成果物、注意点が揃いやすい |
| レビュー観点を要求 | AI出力をそのまま使わない前提を作れる |
AIは、こちらが渡した情報をもとに回答します。
そのため、良いWBSを出したいなら、AIに良い前提情報を渡す必要があります。
AI出力例:CRM導入プロジェクトのWBS草案
上記のプロンプトを使うと、たとえば次のようなWBSの草案が得られます。
実際のAI出力はもっと長くなりますが、ここではイメージしやすいように一部を抜粋します。
| WBSコード | フェーズ | タスク | 目的 | 成果物 | 注意点 |
|---|---|---|---|---|---|
| 1.1 | プロジェクト管理 | キックオフ準備 | 関係者の認識をそろえる | キックオフ資料 | 目的・体制・進め方を明確にする |
| 1.2 | プロジェクト管理 | 進捗管理ルール作成 | 進捗確認の方法を決める | 進捗管理表 | 会議体と報告頻度を決める |
| 2.1 | 要件定義 | 現行業務ヒアリング | 現在の営業業務を把握する | ヒアリングメモ | Excel運用の実態を確認する |
| 2.2 | 要件定義 | 業務課題整理 | 解決すべき課題を明確にする | 業務課題一覧 | 課題と要望を混同しない |
| 2.3 | 要件定義 | CRM利用シナリオ整理 | 利用場面を具体化する | 利用シナリオ | 営業部門の実作業に合わせる |
| 3.1 | 設計 | CRM項目定義 | 管理する顧客情報を決める | 項目定義書 | 既存Excel項目との対応を確認する |
| 3.2 | 設計 | 権限設計 | 利用者ごとの閲覧・編集範囲を決める | 権限設計メモ | 個人情報・機密情報に注意する |
| 4.1 | 設定・開発 | Salesforce環境設定 | CRM環境を利用可能にする | 設定済み環境 | 標準機能と追加設定を分ける |
| 5.1 | データ移行 | 既存Excelデータ調査 | 移行対象データを把握する | データ調査結果 | 重複・欠損・表記ゆれを確認する |
| 5.2 | データ移行 | 移行マッピング作成 | 旧データとCRM項目を対応づける | 移行マッピング表 | 項目の意味違いに注意する |
| 6.1 | テスト | テスト観点整理 | 品質確認の観点を決める | テスト観点表 | 業務シナリオに沿って確認する |
| 6.2 | テスト | 受入テスト準備 | 営業部門が確認できる状態を作る | 受入テスト手順 | 現場担当者が実施できる粒度にする |
| 7.1 | 教育・定着 | ユーザートレーニング資料作成 | 利用者が使える状態にする | 研修資料 | 操作手順だけでなく業務上の使い方を示す |
| 8.1 | リリース | リリース判定 | 本番移行可否を判断する | リリース判定資料 | 未解決課題・残リスクを明確にする |
| 9.1 | 運用準備 | 問い合わせ対応体制整理 | 利用開始後の混乱を減らす | 運用体制表 | 問い合わせ窓口を明確にする |
この時点で、最初の悪いプロンプトよりもかなり実務に近づいています。
ただし、このWBSもまだ「草案」です。
PMは、AIが作ったWBSをそのまま信じるのではなく、自分の案件に合わせて必ずレビューする必要があります。
AIが作ったWBSをPMがレビューする5つの観点
AI出力をレビューするときは、少なくとも次の5つを確認します。
| 観点 | 確認すること | よくある問題 |
|---|---|---|
| スコープ | 対象業務・対象外業務が混ざっていないか | 対象外の作業までWBSに入っている |
| 粒度 | 担当者を割り当てられる単位まで分解されているか | 「テストする」「移行する」など粗すぎる |
| 成果物 | 各タスクの完了条件が明確か | 何を作れば終わりか分からない |
| 依存関係 | 前後関係や待ちが発生するタスクが見えているか | データ移行前に項目定義が必要などの順序が抜ける |
| 見積可能性 | 工数見積できる粒度になっているか | タスクが大きすぎて見積もれない |
特に重要なのは、「成果物」と「粒度」です。
WBSは、単なる作業リストではありません。
各タスクが何を生み出すのか、誰が担当できるのか、どのくらいの工数で終わるのかを考えるための土台です。
このテーマを体系的に学びたい方へ
AIでWBSの草案を作れても、実務では「粒度」「抜け漏れ」「工数見積」「スケジュール化」の判断が必要です。
WBS・工数見積・スケジュール管理をケースで学びたい方は、関連講座も確認してください。
WBS・スケジュール管理の講師クーポン対象講座を見る
修正版WBS:AI出力をPMが実務向けに直す例
AIが作ったWBSは、便利な出発点です。
しかし、AI出力では「データ移行」や「テスト」が一括りになりやすく、実務で管理するには粗い場合があります。
たとえば、AIが次のように出力したとします。
5. データ移行
- 既存データを確認する
- データを移行する
- 移行結果を確認する
このままでは、工数見積や担当割り当てが難しいです。
PM視点では、次のように分解した方が管理しやすくなります。
| 修正前 | 修正後 |
|---|---|
| 既存データを確認する | 既存Excelファイルの一覧化 |
| 既存データを確認する | 顧客データ項目の棚卸し |
| 既存データを確認する | 重複データ・欠損データ・表記ゆれの確認 |
| データを移行する | CRM項目とのマッピング作成 |
| データを移行する | データクレンジング方針の作成 |
| データを移行する | 移行リハーサルの実施 |
| データを移行する | 本番移行作業 |
| 移行結果を確認する | 移行件数の照合 |
| 移行結果を確認する | サンプルデータの内容確認 |
| 移行結果を確認する | 営業部門による業務観点チェック |
このように分解すると、担当者、工数、順序、リスクが見えやすくなります。
WBSを工数見積・スケジュールに展開する方法
WBSは作って終わりではありません。
次にやるべきことは、WBSを工数見積とスケジュールに展開することです。
1. タスクごとに成果物を確認する
まず、各タスクの成果物を確認します。
成果物が曖昧なタスクは、工数見積もスケジュール化も難しくなります。
悪い例:
営業部門と調整する
改善例:
営業部門ヒアリング日程を調整する
営業部門ヒアリングを実施する
営業部門ヒアリング結果を整理する
2. 担当者を仮置きする
次に、誰が担当するかを仮置きします。
担当者が決まらないタスクは、必要なスキルや役割が曖昧な可能性があります。
3. 工数を見積もる
各タスクに対して、ざっくり工数を置きます。
最初から正確である必要はありません。
重要なのは、工数が大きすぎるタスクを見つけることです。
要件定義:20人日
のような大きな塊になっている場合は、さらに分解します。
4. 依存関係を確認する
タスクには順序があります。
たとえば、CRM項目定義が終わっていないと、データ移行マッピングは作れません。
データ移行リハーサルが終わっていないと、本番移行のリスクは判断できません。
この依存関係を見落とすと、スケジュールが現実とズレます。
5. マイルストーンを置く
最後に、プロジェクト上の重要な節目を置きます。
CRM導入プロジェクトなら、次のようなマイルストーンが考えられます。
| マイルストーン | 判断すること |
|---|---|
| 要件定義完了 | 対象業務・成果物・優先順位が合意できているか |
| 設計完了 | CRM項目・権限・運用ルールが決まっているか |
| 移行リハーサル完了 | 本番移行に進める状態か |
| 受入テスト完了 | 営業部門が利用開始できる状態か |
| リリース判定 | 未解決課題と残リスクを踏まえて本番移行できるか |
AIにWBSを再レビューさせるプロンプト
WBSの草案を作った後は、AIに再レビューさせるのも有効です。
次のプロンプトを使うと、WBSの抜け漏れや粒度の粗さを確認しやすくなります。
以下のWBS草案を、経験豊富なプロジェクトマネージャーの視点でレビューしてください。
# レビューしてほしい観点
1. タスクの抜け漏れがないか
2. タスクの粒度が粗すぎないか
3. 成果物が曖昧なタスクがないか
4. 工数見積できない大きな塊がないか
5. 前後関係や依存関係に矛盾がないか
6. プロジェクト管理タスクが不足していないか
7. データ移行・テスト・リリース・運用準備が十分に分解されているか
8. 新任PMが見落としやすいリスクがないか
# 出力形式
以下の表形式で出力してください。
| 指摘箇所 | 問題点 | 修正案 | 理由 |
|---|---|---|---|
# WBS草案
ここにWBS草案を貼り付ける
このプロンプトは、AIが作ったWBSだけでなく、自分で作ったWBSのレビューにも使えます。
ChatGPT・Gemini・Claudeで使うときの違い
同じプロンプトでも、AIツールによって得意な使い方が少し違います。
| ツール | 向いている使い方 |
|---|---|
| ChatGPT | WBSの初期案作成、説明付きの整理、レビュー観点の洗い出し |
| Gemini | 長めの前提情報を渡したうえでの整理、Googleドキュメントやスプレッドシートと組み合わせた検討 |
| Claude | 長文資料や既存ドキュメントを読み込ませたうえでのWBS整理、前提の抜け漏れ確認 |
どのツールを使う場合でも、重要なのは同じです。
AIに丸投げせず、PMが前提を整理し、AI出力をレビューし、最終的に現場に合わせて直すことです。
AIでWBSを作るときの注意点
AIをWBS作成に使うときは、次の点に注意してください。
AI出力は完成版ではなく草案として扱う
AIが出すWBSは、あくまで草案です。
そのままプロジェクト計画書に貼り付けるのではなく、必ずチームメンバー、上司、関係者とレビューしてください。
特に、以下の項目は人間が確認する必要があります。
- 実際の契約範囲
- 顧客との合意事項
- 社内の開発標準
- セキュリティポリシー
- 体制上の制約
- 業務部門の繁忙期
- リリース不可期間
- 過去プロジェクトの教訓
機密情報・個人情報を入力しない
会社の機密情報や個人情報を、AIサービスにそのまま入力しないでください。
たとえば、次の情報は注意が必要です。
- 顧客名
- 個人名
- 契約金額
- 未公開のシステム構成
- 顧客データ
- 障害情報
- セキュリティ上の弱点
- 社外秘の業務フロー
実務で使う場合は、情報を抽象化して入力します。
悪い例:
株式会社〇〇の営業部で使っている顧客管理ExcelをSalesforceへ移行する
改善例:
ある企業の営業部門で使っている既存の顧客管理データを、クラウド型CRMへ移行する
最終責任はPMにある
AIは、考える時間を短縮してくれます。
しかし、最終的にWBSを承認し、関係者と合意し、スケジュールや体制に落とし込むのはPMの仕事です。
AIを「代わりに考えてくれる存在」ではなく、「考える材料を増やしてくれる壁打ち相手」として使いましょう。
よくある質問
AIにWBSを作らせれば、PMはWBSを作れなくてもよいですか?
いいえ。
AIを使っても、PMにはWBSをレビューする力が必要です。
AIはタスク案を出せますが、そのタスクが契約範囲に合っているか、実際の体制で実行できるか、見積できる粒度かまでは最終判断できません。
PMは、AI出力をもとに、現場に合うWBSへ直す役割を持ちます。
WBS作成プロンプトはどのAIツールでも使えますか?
はい。
ChatGPT、Gemini、Claudeなどで使えます。
ただし、ツールごとに出力の癖があります。1回で完成させようとせず、出力を見ながら追加質問やレビュー依頼を行うのがおすすめです。
WBSコードは必ず必要ですか?
実務では、WBSコードがあると管理しやすくなります。
タスクの階層や親子関係が分かりやすくなり、スケジュール表、課題管理表、進捗報告とも紐づけやすくなるためです。
小規模プロジェクトでは簡略化してもよいですが、タスクのまとまりを識別できる番号は付けた方がよいです。
AIが出したWBSが細かすぎる場合はどうしますか?
細かすぎる場合は、管理する単位にまとめます。
WBSは細かければよいわけではありません。
担当者を割り当てられ、進捗確認でき、工数見積できる粒度に整えることが大切です。
関連講座
WBS作成、工数見積、スケジュール管理を体系的に学びたい方は、以下の講座が参考になります。
WBS・スケジュール管理を実務ケースで学ぶ
AIでWBSの草案を作るだけでなく、PMとしてタスク粒度、工数見積、スケジュール遅延時の判断を学びたい方におすすめです。
WBS・スケジュール管理の講師クーポン対象講座を見る
生成AIで見積・前提整理・工数算出を支援する
WBSから見積もりや前提整理まで、AIをPM実務に活用したい方におすすめです。
生成AIで見積・前提整理・工数算出の講師クーポン対象講座を見る
まとめ
AIを使えば、WBSの草案を短時間で作成できます。
ただし、AIに「WBSを作って」と丸投げするだけでは、実務で使えるWBSにはなりません。
重要なのは、次の流れです。
前提を整理する
↓
AIに構造化して依頼する
↓
AI出力を見る
↓
PM視点でレビューする
↓
現場に合わせて修正する
↓
工数見積・スケジュールに展開する
AIは、PMの仕事をなくすものではありません。
むしろ、PMが考えるべき論点を早く見える化してくれる道具です。
WBS作成にAIを使うことで、白紙のExcelを前に悩む時間を減らし、PMとして本当に考えるべきスコープ、成果物、リスク、依存関係、関係者合意に時間を使えるようになります。
関連記事
- AIをWBS作成の助け船にするために、PMが決めるべきこと
- Claude CodeでWBS・スケジュール骨子を半日でドラフト|PMの計画フェーズ実装レシピ
- 【炎上を防ぐWBSの作り方】私が大炎上プロジェクトで学んだ3つの原則
- AIを論点整理の壁打ち相手にするプロンプト術
PMのためのAIツール
- PMのためのAIプロンプト集 — 現場でそのまま使えるテンプレート一覧
- AIを使うPMの道具箱 — PM業務ごとのAI活用ガイド