【連載第2回】AIが迷走しない「PMP流WBS分解」とプロンプト術 — エージェントを自律稼働させる組織設計

✅ 📋 1分で読めるこの記事の概要

• この記事の結論: AIが指示通りに動かず迷走する最大の原因は、プロンプトの表現力ではなく「プロジェクトマネジメント（スコープ定義とWBS分解）の欠如」にあります。成果物中心のWBS分解と「関心事の分離」を組み込むことで、AIエージェントは驚くほど自律的かつ高精度に稼働します。
• 取り組んだ課題: 「新サービスの企画書を作って」「ブログを書いて」といった抽象的な丸投げによるアウトプットの質の低下、コンテキスト汚染によるハルシネーションや作業破綻を解消しました。
• 得られた学び・成果: 私たちが実践する「自律型AI組織」において、タスクを4階層のWBS（方針定義 ➔ ガイドライン ➔ ドラフト ➔ 自動化パイプライン）へと分解。そのままコピペで使える「PMP流プロンプト黄金フォーマット」を確立しました。

---

はじめに：「AIに丸投げ」で撃沈していませんか？

こんにちは、LEEです。

普段はインフラエンジニアおよびプレイングマネージャーとして活動しながら、PMP®（プロジェクトマネジメント・プロフェッショナル）や情報処理安全確保支援士の視点を活かした「1人会社×自律AIエージェント組織」の実践検証を発信しています。

前回の第1回記事では、CEO（人間）とCOO（AI）の役割分担や、組織OSとしてのフォルダ構成についてお話ししました。ありがたいことに、多くのエンジニアやマネジメント層の方々から大きな反響をいただきました。

さて、今回はその続編として、現場で最も多くの人が直面している「AI活用の深い挫折」 に切り込みます。

読者の皆さんは、生成AIに対してこんな指示を出して、がっかりした経験はありませんか？

「当社の中小企業向け新サービスの企画書を、いい感じに作って」 「最新のITトレンドについて、読まれるブログ記事を1本まるごと書いて」

そして返ってきた回答を見て、こうため息をつくのです。

「……なんだか、どこかで見たような当たり障りのない一般論だな」 「ピントがズレているし、うちの現場の実情がまるで反映されていない」

あるいは、少し複雑なタスクを頼んだ途端、AIが途中で前言を撤回したり、指示の半分を忘れてハルシネーション（嘘の出力）を始めたりして、結局人間が手作業でイチから修正する羽目になる……。

ネット上には「魔法のプロンプト集」「劇的に成果が出る呪文」といった情報が溢れています。しかし、断言します。

AIが迷走する根本原因は、プロンプトのテクニック不足ではありません。 人間側の「プロジェクトマネジメント（タスク分解とスコープ定義）の欠如」にあります。

もしあなたが人間の新入社員に対して「会社の売上を伸ばす企画書を適当に作っておいて」と丸投げしたらどうなるでしょうか？ 確実に困惑し、ネットの受け売りをまとめた薄っぺらいレポートを出してくるはずです。

人間相手なら絶対にやらない「無謀な丸投げ」を、私たちはAIに対して平気でやってしまっているのです。

本記事では、PMPの知識体系（PMBOK）が教えるマネジメントの型をAIエージェントに適用し、指示待ちや迷走を完全にゼロにする「WBS分解術」と「プロンプト黄金フォーマット」を余すところなく公開します。

---

第1章：PMPの視点で解剖する「AIが迷走する本当の理由」

プロジェクトマネジメントの世界には、何十年にもわたる失敗の歴史から導き出された「プロジェクトが破綻する3大原因」が存在します。

実は、AIが回答に失敗するプロセスは、人間のプロジェクトが炎上するプロセスと完全に一致 しています。

【プロジェクト炎上の3大原因】         【AI活用での失敗現象】
1. スコープクリープ (境界の曖昧さ)   ➔  AIが論点を広げすぎてピントがズレる
2. 受け入れ基準 (DoD) の欠如         ➔  求めていた品質と違う浅い出力が出る
3. ワークパッケージの未定義         ➔  タスクが大きすぎて途中で文脈が破綻する

原因1：スコープクリープ（何をやらないかが決まっていない）

スコープクリープとは、プロジェクトの境界線が曖昧なために、作業範囲が際限なく膨らんで納期や品質が崩壊する現象です。

AIに「新サービスの企画を考えて」とだけ指示すると、AIは親切心からターゲット選定、価格設定、マーケティング戦略、技術スタック、果てはカスタマーサポート方針まで、1回の出力で網羅しようとします。

その結果、すべての要素が1〜2行で浅く触れられただけの「スカスカな企画書」 が出来上がります。AIに必要なのは「何を作るか（In-Scope）」以上に、 『今回は何をやらないか（Out-of-Scope）』 を明確に指定する境界線です。

原因2：受け入れ基準（Definition of Done）の欠如

PMPでは、成果物が完成したとみなすための客観的な合格ラインを「受け入れ基準（Acceptance Criteria）」と呼びます。

「いい感じのブログ」「説得力のある提案書」という言葉には、客観的な基準が1ミリもありません。

• 文字数は何文字なのか？
• 誰が読む想定で、専門用語はどのレベルまで噛み砕くのか？
• どのような章立てで、各章に何個の具体例を含めるのか？

基準が示されない以上、AIはモデルの統計的平均値（もっとも無難で凡庸な文章）を出力するしかありません。アウトプットが浅いのは、AIの能力不足ではなく、合格基準を定義していない人間の怠慢 なのです。

原因3：ワークパッケージの未定義（粒度が大きすぎる）

PMPにおける最重要概念の一つが 「ワークパッケージ（Work Package）」 です。これは、WBSの最下層に位置する「これ以上分解できない、単一の担当者が独立して完遂できる作業単位」を指します。

「新サービスの企画書作成」は、ワークパッケージではありません。それは複数の作業が折り重なった「巨大なプロジェクトそのもの」です。

LLM（大規模言語モデル）には、一度に思考できる文脈の深さ（コンテキストウィンドウとアテンションの集中力）に物理的な限界があります。1回のプロンプトで巨大な山を登らせようとすれば、途中で息切れして前の指示を忘れ、出力が破綻するのは必然です。

解決策は極めてシンプルです。 山を登るのではなく、階段を一段ずつ登らせること。 すなわち、PMPの神髄である「WBS分解」を適用することです。

---

第2章：実践！AIが迷わず完遂する「PMP流 WBS分解術」

1. 成果物中心（Deliverable-Oriented）の原則

WBS（Work Breakdown Structure: 作業分解構成図）を作成する際、初心者が最も陥りやすい罠が「動詞でタスクを並べてしまうこと」です。

• × 「市場調査をする」 ➔ 「仕様を検討する」 ➔ 「資料を書く」

動詞先行でタスクを切ると、どこまでやれば終わりなのかが誰にも分かりません。 PMPの鉄則は、「成果物中心（名詞）で分解すること」 です。すべての作業の末端には、必ず形のある「納品物（ファイル、図、コード）」が存在しなければなりません。

2. 実践実例：技術ブログ自動運用パイプラインのWBS分解

私たちの自律型組織において、実際に推進している「技術ブログ自動運用パイプライン」の構築プロセスを実例として公開します。

もしこれを「読まれる技術ブログを自動で運用する仕組みを作って」とAIに1行で投げたら、間違いなく当たり障りのない一般論しか出ず、ピントがズレて即死します。

COOエージェントと共に、私たちはこのプロジェクトを以下のような4階層の「成果物ツリー」へ分解しました。

【プロジェクト目標】技術ブログ自動運用パイプラインの構築
│
├── Level 1: 編集方針・ペルソナの特定
│   └── 成果物: 01_editorial_policy.md（ターゲット読者・トーン＆マナー定義書）
│
├── Level 2: 記事執筆ガイドライン・品質基準の確立
│   └── 成果物: 02_writing_guideline.md（構成ルール・SEO基準・表記規約）
│
├── Level 3: 記事ドラフトの具現化
│   └── 成果物: 03_article_draft.md（本文Markdown・見出し構成）
│
└── Level 4: アイキャッチ画像生成 ＆ 入稿スクリプト
    └── 成果物: 04_publish_pipeline.py（API連携・画像紐付けツール）

【WBSの100%ルール】
親要素のスコープ ＝ 子要素のスコープの合計（過不足が一切ない状態）

このように、1つの大きな塊を 「単一の完結した成果物ドキュメントやスクリプト」 というワークパッケージ単位にまで落とし込みます。

そして、各ワークパッケージを順番に、独立したプロンプトでエージェントに発注していくのです。

1. まず「編集方針とターゲットペルソナ」だけを最高密度で定義させる
2. 完成した方針書を入力として渡し、「執筆ガイドラインと表記規約」を策定させる
3. ガイドラインをもとに、個別の「記事ドラフト」を起草させる
4. 最後に、完成原稿をAPI経由で投稿する「自動入稿スクリプト」を完成させる

このように階段を1段ずつ登らせることで、AIは一切迷走することなく、各工程で極めて高い整合性を保ったまま自律的に成果物を完成させました。

---

第3章：フォルダ構成とエージェントの「関心事の分離（Separation of Concerns）」

タスクをWBSで細分化できたら、次に重要になるのが 「誰に、どの範囲の仕事を任せるか」 という組織境界の設計です。

多くの人がやってしまう失敗が、「1つのチャットスレッドで、企画もコードもブログ記事も全部書かせようとすること」です。

これをやると、スレッド内に雑多な情報が混ざり合い、AIの記憶領域（コンテキスト）が汚染され、前の指示と矛盾した出力を吐き出し始めます。

ソフトウェア設計における基本原則に 「関心事の分離（Separation of Concerns: SoC）」 という概念があります。異なる役割や責任を明確に切り離し、お互いが干渉しないようにモジュール化する考え方です。

私たちはこの思想を、AIエージェントがアクセスするワークスペースの「ディレクトリ設計」と「役割分担」に応用しています。

以下は、自律型組織を構築する際の「関心事の分離」の標準的なアーキテクチャモデルです。

ai-team-workspace/
├── management/              # 【経営・統括】憲章、ロードマップ、全体の進捗管理
│   ├── project_charter.md
│   └── roadmap.md
│
├── governance/              # 【監査・品質ゲート】セキュリティ規約、マスキング辞書、監査ログ
│   ├── security_policy.md
│   └── audit_logs/
│
├── engineering/             # 【開発・実装】要件定義、仕様書、ソースコード、設計書
│   └── specs/
│
└── marketing/               # 【発信・運用】コンテンツ企画、記事ドラフト、公開アセット
    └── drafts/

役割ごとに「見える世界（コンテキスト）」を限定する

• コンテンツ・広報担当（ライターエージェント）: marketing/ 配下のみを作業領域とし、読者ペルソナへの共感と発信の魅力に全神経を集中させる。
• ガバナンス・セキュリティ担当（監査エージェント）: governance/ を拠点とし、他の成果物に機密情報や不用意な記述が含まれていないかを冷徹に監査する。
• プロダクト・技術担当（エンジニアエージェント）: engineering/ に集中し、仕様の論理的整合性と実用性のみを追求する。

もし1体のAIに「セキュリティチェックをしながら、読者の心を揺さぶる面白いブログを書いて」と頼んだら、論理と言情が衝突して中途半端な駄作になります。

「書く係」と「監査する係」を別人（別エージェント）に分け、それぞれに独立したフォルダとプロンプトを与える。

この関心事の分離こそが、AI組織がスケールしても品質が一切落ちない秘密です。

---

第4章：そのまま使える！自律稼働プロンプトの「黄金フォーマット」

では、実際にWBSで分解されたワークパッケージを、どのようにプロンプトとしてAIに発注すればよいのでしょうか？

私が実務とPMPの理論から導き出した、「自律稼働プロンプトの黄金フォーマット（5つの構成要素）」 を公開します。

日常の業務でAIにタスクを振る際は、このテンプレートをそのまま埋めてみてください。

PMP流プロンプトの黄金フォーマット（5要素）

# 指示書: [成果物名] の作成

## 1. 役割（Role）
あなたは [専門分野] のトップエキスパート（[具体的な役職名]）です。
[どのような思考様式や専門知識] を持って本業務を遂行してください。

## 2. 背景・文脈（Context）
・プロジェクトの目的: [なぜこの作業を行うのか]
・現在の進捗状況: [前工程で何が完了しているのか]
・ターゲット読者/利用者: [誰がこの成果物を使うのか]

## 3. スコープ境界（In / Out of Scope） ★最重要
・【含むもの（In-Scope）】:
  - [今回必ず作成・網羅すべき内容]
・【含まないもの（Out-of-Scope）】:
  - [今回は絶対に書かないこと、他工程に任せること]

## 4. 具体的成果物（Deliverables）
以下の構造・章立てに従って、完全な形式で出力してください。
- ファイル名 / 形式: [Markdown / コード / 表]
- 構成案:
  1. [見出し1]
  2. [見出し2]
  3. [見出し3]

## 5. 品質基準・制約条件（Constraints & DoD）
・完了定義 (DoD): [何をもって合格とするか]
・文字数/粒度: [1文60字程度、総文字数など]
・禁止事項: [抽象論の禁止、実名・実機IPの記載禁止など]

実例比較：Before（悪いプロンプト）vs After（PMP黄金フォーマット）

実際にどれほどの差が出るのか、Before/Afterで比較してみましょう。

❌ 悪いプロンプト例（丸投げ）

うちの技術ブログに載せる「Docker入門」の記事構成案を作ってください。
初心者向けで、わかりやすい内容でお願いします。

【結果】: 「Dockerとは？」「インストールの方法」「メリット・デメリット」といった、ネット上に何万件とある当たり障りのない目次が並び、読者の心を動かすことはできません。

---

⭕ 良いプロンプト例（PMP黄金フォーマット適用）

# 指示書: 技術ブログ記事「実務で役立つDockerコンテナ入門」の構成案作成

## 1. 役割（Role）
あなたは10年以上のインフラ設計構築経験を持つシニアSREエンジニア兼テクニカルライターです。

## 2. 背景・文脈（Context）
普段はオンプレミスの物理サーバやVMware環境に慣れており、これから現場でDockerを導入しようとしている若手〜中堅インフラエンジニアを対象とします。「なぜ現場でDockerが必要なのか」という課題感に寄り添う実務的な解説記事を企画します。

## 3. スコープ境界（In / Out of Scope）
・【In-Scope】: コンテナの基本概念、仮想マシンとの違い、Docker Composeを用いた複数コンテナ管理の基礎。
・【Out-of-Scope】: Kubernetesなどのオーケストレーション、クラウドマネージドサービス（ECS/EKS等）の詳細設定（今回は扱いません）。

## 4. 具体的成果物（Deliverables）
以下の構造で、想定読者の離脱を防ぐ見出し構成（H2〜H3）と、各章で伝えるべきキーメッセージを箇条書きで出力してください。
1. はじめに（現場の環境差異トラブルとコンテナ導入の動機）
2. 仮想マシン（VM）と何が違うのか？（リソース効率の観点から比較）
3. 現場で最低限押さえるべき「実務Dockerコマンド5選」
4. Docker ComposeでWeb＋DB環境を1発で立ち上げる実践ハンズオン
5. まとめ（次のステップ）

## 5. 品質基準・制約条件（Constraints & DoD）
・完了定義: 抽象的な機能解説を排し、「現場でどんなトラブルが防げるか」という実務的メリットが各章に具体的に記載されていること。
・禁止事項: 公式ドキュメントの単なる翻訳やコマンドリファレンスの羅列は禁止。

【結果】: 「なぜVMだと重いのか、コンテナだと何が嬉しいのか」「開発環境と本番環境の差異で起きるトラブルをどう防ぐか」という、現場エンジニアが本当に知りたかった実践知が詰まった構成案 が一発で出力されます。

---

まとめ ＆ 次回予告

AIの進化によって、コードを書くことや文章を起草すること自体のコストは劇的に下がりました。

しかし、そのAIを「迷走させず、狙った通りの成果物を出させ、組織として自律稼働させる」ためには、これまで以上に高度なスキルが求められます。

そのスキルとは、最新のAIプロンプトのテクニック集ではありません。 古今東西の優れたエンジニアやリーダーたちが磨き上げてきた、「プロジェクトマネジメントの基礎体力」 そのものです。

1. 成果物（名詞）先行でWBSを分解する
2. 「やらないこと（Out-of-Scope）」を厳格に定義する
3. 客観的な完了定義（DoD）をプロンプトに埋め込む
4. 関心事の分離によってエージェントの思考領域をクリアに保つ

マネジメントの型さえ正しく注入すれば、AIは「指示待ちの頼りない作業員」から、「自らゴールへ突き進む最高に頼もしいチーム」へと生まれ変わります。

次回は、AI組織を実用化する上で避けて通れない「最大の壁」に挑みます。

次回予告: 【連載第3回】ガバナンスとセキュリティ — 登録セキスペが設計する、情報漏洩を防ぐエージェント監査術

「AIエージェントに社内データを読み込ませて情報漏洩は起きないのか？」 「自動生成されたコードや記事の安全性を、どうやって担保するのか？」

情報処理安全確保支援士（登録セキスペ）の知見をフル活用し、私たちが実践している「3段階マスキング・ゲート」と「静的セキュリティ監査ワークフロー」の実態を全公開します。お楽しみに！

---

(著者: LEE / LEEの自宅サーバ運用記 https://jetree.work/)