PMがそのまま使える、AIタスク分解プロンプトテンプレート
新規施策や開発案件の着手時にAIへ相談すると、タスク分解が大ざっぱすぎたり、逆に細かすぎたりしがちです。先に結論を言うと、AIに良いタスク分解をさせるコツは「目的」「完了条件」「制約」「粒度」を一度に渡すことです。
このテンプレートは、プロジェクトマネージャーやリーダーが、要件整理の初期段階でたたき台を早く作りたいときに向いています。ChatGPT、Claude、Gemini などの汎用LLMで使える形に寄せています。
- 何に使うか: 施策や案件を実行可能なタスク単位に分ける
- 誰向けか: PM、PdM、開発リーダー、Web担当、業務改善担当
- 狙う出力: 担当しやすい粒度のタスク一覧、依存関係、優先度、抜け漏れチェック
- 向いている場面: キックオフ前、WBSのたたき台作成、見積もり前の論点整理
ここがポイント: 「タスクを分解して」とだけ頼むより、成果物・期限・関係者・除外範囲・出力形式まで指定したほうが、実務で使える一覧に近づきます。
このプロンプトで何が変わるのか
単にタスクを列挙させるだけでは、実務では足りません。PMが欲しいのは、着手順がわかり、依存関係が見え、抜け漏れを点検しやすい形です。
このテンプレートでは、AIに次の役割をまとめて持たせます。
- プロジェクトの目的を読み取る
- フェーズごとにタスクを分ける
- タスクを「担当を振れる粒度」まで落とす
- 前提不足や曖昧さを指摘する
- 最後に抜け漏れチェックを返す
そのため、会議メモや企画概要しかない段階でも、次の一手が見えやすくなります。
コピペ用プロンプトテンプレート
まずはこの形で使えば十分です。最初から凝った条件を足しすぎるより、必要な前提を埋めるほうが効きます。
あなたは経験豊富なプロジェクトマネージャー補佐です。
以下の案件情報をもとに、実行可能なタスク分解を行ってください。
# 目的
{この案件で達成したいこと}
# 背景
{案件の背景、なぜ必要か}
# 成果物
{最終的に納品・公開・完了とみなす成果物}
# 対象範囲
{今回含める範囲}
# 対象外
{今回は含めない範囲}
# 関係者
{関係部署、担当ロール、意思決定者}
# 期限
{全体期限、重要マイルストーン}
# 制約
{予算、人員、ツール、法務、セキュリティ、工数など}
# 想定リスク
{現時点で見えている懸念点}
# 希望する粒度
1タスクは {半日 / 1日 / 2〜3日 / 1週間} 程度で区切る
# 指示
1. まず案件を主要フェーズに分ける
2. 各フェーズごとに実行タスクを分解する
3. 各タスクに「目的」「担当ロール」「完了条件」を付ける
4. タスク間の依存関係があれば示す
5. 優先度を High / Medium / Low で付ける
6. 情報不足で精度が落ちる点は「確認事項」として最後にまとめる
7. 最後に「抜けやすい論点」をチェックリストで出す
# 出力形式
以下の見出し構成でMarkdownで出力してください。
## 1. 全体像
- 案件要約
- 推奨フェーズ
## 2. タスク一覧
各タスクを以下の形式で整理
- フェーズ:
- タスク名:
- 目的:
- 担当ロール:
- 優先度:
- 依存関係:
- 完了条件:
## 3. 確認事項
箇条書き
## 4. 抜け漏れチェック
チェックリスト形式
情報が不足していても作業を止めず、妥当な前提を置いて仮案を作ってください。
ただし、前提で補った箇所は明示してください。
入力時に変える部分と、固定したほうがいい部分
テンプレートをそのまま貼るだけでも動きますが、全部を毎回書き換える必要はありません。変える場所と固定する場所を分けると、運用が安定します。
変える部分
毎回更新したいのは次の項目です。
{この案件で達成したいこと}{最終的に納品・公開・完了とみなす成果物}{今回含める範囲}{今回は含めない範囲}{関係部署、担当ロール、意思決定者}{全体期限、重要マイルストーン}{予算、人員、ツール、法務、セキュリティ、工数など}{半日 / 1日 / 2〜3日 / 1週間}
ここが曖昧だと、AIは見た目だけ整ったタスクリストを返しやすくなります。特に成果物と対象外は省かないほうが安全です。
固定したほうがいい部分
毎回ぶらさないほうがいいのは次の要素です。
- フェーズ分けしてからタスク化する流れ
- 各タスクに完了条件を付ける指定
- 依存関係を明示させる指定
- 確認事項と抜け漏れチェックを最後に出す指定
- 出力形式の見出し構造
この骨組みを固定すると、案件ごとに比較しやすくなります。複数案件を並べて見積もるときも扱いやすいです。
出力形式はMarkdownだけでなくJSONも使える
他ツールに流し込む予定があるなら、最初からJSON指定にするのも有効です。Notion、スプレッドシート連携、社内ワークフローに乗せるならこちらのほうが再利用しやすい場面があります。
上記と同じ内容を、以下のJSON配列で出力してください。
[
{
"phase": "",
"task_name": "",
"purpose": "",
"owner_role": "",
"priority": "High|Medium|Low",
"dependency": "",
"done_definition": "",
"assumption": ""
}
]
どちらを使うべきか
- 人がそのまま読むなら Markdown
- 後で整形・転記するなら JSON
- まず会議で叩くなら Markdown、確定後に JSON へ切り替え
Google の Gemini API ドキュメントでも、出力形式を明示し、複雑な処理は分けて扱う考え方が案内されています。OpenAI のガイドでも、指示は冒頭に置き、望む形式を具体的に示す方法が勧められています。
よくあるNG例と改善例
タスク分解で失敗しやすいのは、依頼が短すぎるケースです。
NG例
新機能リリースのタスクを分解して。
これだと、AIは次の点を判断できません。
- 何をもって完了か
- 誰が関わるのか
- 開発だけなのか、告知やQAも含むのか
- 1タスクの粒度をどこまで落とすのか
結果として、「要件定義」「設計」「実装」「テスト」のような、正しいが使いにくい一覧になりやすいです。
改善例
BtoB向けSaaSの新機能リリース案件です。
目的は、既存顧客がCSV一括取込を使えるようにすることです。
成果物は、本番リリース済み機能、操作マニュアル、営業向け案内文です。
対象範囲は要件整理、開発、QA、社内告知、顧客告知まで。
対象外は料金改定と契約変更です。
期限は2026年5月31日、1タスクは2〜3日単位で分解してください。
依存関係、担当ロール、完了条件も含めてMarkdownで整理してください。
この改善例では、AIが迷いやすい判断軸を先回りして埋めています。特に効くのは次の4点です。
- 成果物を明示した
- 対象外を切った
- 粒度を指定した
- 出力形式を固定した
出力を安定させるコツ
同じ案件でも、毎回ばらつきが大きいと使いにくくなります。安定させたいなら、プロンプト本文よりも、条件の置き方を見直すほうが早いです。
1. 先に「粒度」を決める
「細かく分解して」では足りません。半日単位なのか、2〜3日単位なのかで、返る一覧はかなり変わります。
おすすめは次の使い分けです。
- 初期整理: 2〜3日単位
- 見積もり前: 1日単位
- 実行管理直前: 半日〜1日単位
2. 完了条件を必須にする
タスク名だけ並ぶと、実行時に認識ズレが出ます。そこで各タスクに「何ができたら終わりか」を付けさせます。
例:
- 悪い例: テスト実施
- 良い例: 主要3パターンの受け入れテストが完了し、不具合が起票済みである
3. 確認事項を分けて出させる
不足情報があるたびにAIが止まると、叩き台が作れません。反対に、勝手に埋めすぎても危険です。
その中間として有効なのが、
- 仮案は作る
- 仮定を明示する
- 確認事項を最後にまとめる
という出し方です。
Anthropic の Claude 向けガイドでも、明確で直接的な指示、例示、XMLなどでの構造化が有効だと案内されています。複数の入力要素を扱うタスク分解とも相性がいい考え方です。
4. 長い案件説明は区切って渡す
背景、制約、会議メモが長い案件ほど、情報が混ざりやすくなります。OpenAI と Google の公式ガイドはいずれも、指示と文脈を分けること、長い文脈では構造をはっきりさせることを勧めています。
たとえば、次のようにブロック化すると崩れにくくなります。
# 目的# 背景# 制約# 会議メモ# 指示# 出力形式
活用例: 3つの場面でこう変える
同じテンプレートでも、案件タイプで少し変えるだけで使いやすくなります。
開発案件
追加するとよい項目:
- 技術的制約
- 既存システムとの依存
- QA観点
- リリース判定条件
Web制作・改善案件
追加するとよい項目:
- 対象ページ
- KPI
- 原稿・素材の有無
- デザイン確定の締切
業務改善案件
追加するとよい項目:
- 現行フロー
- 誰の作業時間を減らしたいか
- 例外処理
- 導入後の運用担当
重要なのは、テンプレートを毎回ゼロから書き換えないことです。共通骨格を残し、案件ごとに入力欄だけ差し替えるほうが早く、品質もぶれにくくなります。
使う前のチェックリスト
最後に、貼り付け前に見る項目を短くまとめます。
- 目的は1文で言えるか
- 成果物が具体物になっているか
- 対象外を書いたか
- 期限とマイルストーンを書いたか
- 粒度を指定したか
- 出力形式を固定したか
- 仮定と確認事項を分けて出すよう指示したか
この7点が入っていれば、AIのタスク分解はかなり実務寄りになります。
次に見るべきポイントは、その分解結果をそのまま採用するかではなく、依存関係と完了条件が現場の運用に合っているかです。ここを人が詰めると、AIの出力は「きれいな案」から「使える計画」に変わります。