PMBOK-AIは概念だけで終わらせてはいけない。実際のプロジェクトに適用して初めて価値がある。
本記事では、自社サイト（pnd-office.com）の構築プロジェクトにPMBOK-AIを適用した実例を、従来PMBOKとの違いを交えながら解説する。コスト比較、品質管理、そしてこの手法の限界まで含めて、現場のリアルをお伝えしたい。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| プロジェクト名 | Panda Office 自社サイト構築 |
| 技術スタック | Next.js 15 / TypeScript / Vercel |
| チーム構成 | 人間1名（PM兼要件定義）+ AI社員4名 |
| 期間 | 設計〜公開まで約3週間 |
| 成果物 | 26ページ（ブログ10記事含む）、問い合わせフォーム、OGP動的生成、SEO対策済み |
このプロジェクトの特徴は、PMとして私1人、実装チームとしてAI社員4名という構成だ。従来のPMBOKでは想定されていない体制である。
従来PMBOKとの違い：3つの知識エリアで劇的に変わった
PMBOK-AIを適用したことで、特に大きく変化した知識エリアは3つある。
1. スコープ・タスク管理：「誰がやるか」の判断基準が変わる
従来のPMBOKでは、WBS（Work Breakdown Structure）を作成し、各タスクを人間のスキルや稼働を考慮して分割する。
PMBOK-AIでは、タスクの分割基準そのものが変わる。
| 観点 | 従来のPMBOK | PMBOK-AI |
|---|---|---|
| タスク分割の基準 | 人間のスキル・稼働時間 | 「人間がやるべきか、AIに任せられるか」 |
| WBSの粒度 | 作業者の経験に依存 | AIへの指示精度に合わせて細分化 |
| スコープ変更 | 変更管理委員会で承認 | AIの出力を見て即座にスコープ調整 |
自社サイトプロジェクトでは、最初に全タスクを洗い出した後、**「これはAIに任せられるか？」**というフィルタリングを行った。
結果、タスクの約80%がAI実行可能と判断。残りの20%——要件定義、テーブル設計、最終品質判断——を人間が担当する形になった。
具体的にやったこと： GitHub Issueに実装手順を細かく記載し、Claude Codeに渡す。たとえば「お問い合わせフォームの実装」であれば、フォーム項目、バリデーションルール、送信先、エラーメッセージの仕様まで1つのIssueに記載する。この「Issueの書き方」がWBSの代わりになっている。従来のWBSより、はるかに実装に近い粒度で管理できる。
2. リソース管理：コスト構造が根本的に変わる
従来のPMBOKのリソース管理は、人的リソースの確保と最適配置が中心だ。採用、アサイン、スキルマトリクス——すべて「人間」を前提としている。
PMBOK-AIでは、リソースの定義そのものが変わる。
| 観点 | 従来のPMBOK | PMBOK-AI |
|---|---|---|
| リソースの種類 | 人間のみ | 人間 + AI社員 |
| コスト構造 | 人件費中心（月30〜60万/人 ※スキル・地域により変動） | API費用中心（月3〜5万/4名） |
| スケーリング | 採用→教育→アサイン（数ヶ月） | AI社員追加は即日可能 |
| 稼働時間 | 1日8時間 | 24時間対応可能 |
自社サイトプロジェクトでは、AI社員4名（うぉんば／すいっぺ／ずんべぇ／あざらす）がそれぞれテックリード・マーケティング・PM支援・事業戦略を担当した。各AI社員の詳細な役割と実績はAI社員4名の実稼働レポートを参照いただきたい。
ただし、AIのリソース管理には従来にない注意点がある。AIは疲れないが、コンテキストウィンドウの制約がある。長時間の連続作業では文脈が抜け落ちるため、タスクを適切な単位で区切る必要がある。また、API利用量の上限やレート制限も考慮が必要で、これは従来のPMBOKにはないリソース管理の概念だ。
3. 品質管理：検証プロセスが構造的に進化する
従来のPMBOKの品質管理は、人間によるレビューとテストが中心だ。品質計画、品質保証、品質管理の3プロセスで回す。
PMBOK-AIでは、品質管理のプロセスが進化する。
| 観点 | 従来のPMBOK | PMBOK-AI |
|---|---|---|
| レビュー | 人間が目視レビュー | リバースエンジニアリングで構造的検証 |
| テスト | 人間がテストケース作成 | AIがテストコード生成、人間が結果を検証 |
| 品質基準 | 静的な品質指標 | AIの出力特性を考慮した動的指標 |
| 再現性 | レビュアーに依存 | 仕様書照合で属人性を排除 |
自社サイトプロジェクトで特に効果を発揮したのが、リバースエンジニアリングによる品質保証だ。
AIが生成したコードから仕様書を逆生成し、元の設計書と照合する。たとえば、問い合わせフォームの実装後に「このコードはどんな仕様に基づいているか」をAIに分析させ、最初に定義した要件と突き合わせる。これにより、「テストは通るが仕様と異なる」という問題を構造的に防いでいる。
また、AIの出力には**ハルシネーション（事実と異なる情報の生成）**というリスクがある。従来の品質管理では想定されていないリスクだ。PMBOK-AIでは、このリスクを品質管理プロセスに組み込み、チェックリストに「ハルシネーションの確認」を追加している。
プロジェクトの進め方：PMBOK-AI実践フロー
自社サイト構築で実際に使った進め方を紹介する。
Phase 1：立ち上げ（人間主導）
- プロジェクトの目的・スコープ定義
- ステークホルダー特定（この場合は自社）
- 成功基準の設定（ページ数、公開日、品質基準）
この段階は100%人間が担当する。AIには判断させない。「何を作るか」「なぜ作るか」は人間の責任だ。
Phase 2：計画（人間主導 + AI支援）
- 要件定義書の作成（人間）
- テーブル設計（人間）
- タスクの洗い出しとAI/人間の分担決定（人間）
- 技術調査・ベストプラクティスのリサーチ（AI）
- 実装手順書の作成（人間 + AI）
計画段階で重要なのは、AIに任せる範囲を明確に線引きすること。「なんとなくAIに聞いてみる」ではなく、「この工程はAI、この工程は人間」と事前に決める。
自社サイトでは、26ページ分のワイヤーフレームと導線設計は人間が行い、各ページの詳細設計書をAIと共同で作成した。
Phase 3：実行（AI主導 + 人間監督）
- GitHub Issueに実装手順を登録（人間）
- Claude Codeが実装（AI）
- コードレビュー・リバースエンジニアリング（人間 + AI）
- テストコード生成（AI）
- テスト結果の検証（人間）
実行段階では、AIが実作業の中心になる。しかし、人間は「監督」として常にプロセスを見ている。放置はしない。
実際のところ、1日あたり3〜5件のIssueをAIに処理させ、それぞれの成果物をレビューするサイクルを回した。深夜にIssueを登録しておけば、翌朝にはAIの出力が揃っている。これは従来の人間チームでは不可能な進め方だ。
Phase 4：監視・コントロール（人間主導）
- 品質チェック（仕様書照合）
- スコープの調整
- 問題発生時の判断・対応
AIの出力に問題があれば、ここで軌道修正する。従来のPMBOKと異なるのは、修正のサイクルが非常に速い点だ。人間チームであれば修正に数日かかる内容が、AIであれば数時間で完了する。
たとえば、SEOのメタデータ設定に不備が見つかった際、26ページ分を一括修正するのに要した時間は約2時間。人間が手作業で行えば丸1日かかる作業だ。
Phase 5：終結（人間主導）
- 最終品質確認（Lighthouse、表示崩れ、リンク切れ）
- デプロイ・公開
- 振り返り（教訓の記録）
従来PMBOKでは対応できなかった課題
PMBOK-AIを通じて見えた、従来のPMBOKでは対応しにくい課題がある。
深夜・休日の突発対応
サイト公開後、深夜にレイアウト崩れの報告が入った。従来であれば翌営業日まで対応を待つか、エンジニアに緊急連絡する必要がある。PMBOK-AIの体制では、AIにIssueを登録するだけで修正が進む。人間は翌朝、修正内容をレビューして承認するだけだ。
仕様変更への即時対応
「やっぱりこのページの構成を変えたい」——プロジェクト中盤での仕様変更は、従来なら工数の再見積もりと調整に数日を要する。AIであれば、新しい仕様を伝えるだけで数時間以内に対応可能だ。自社サイトでは、開発中に3回の大きな構成変更があったが、いずれも半日以内に反映できた。
AIの出力品質のばらつき
同じ指示を出しても、AIの出力は毎回微妙に異なる。従来のPMBOKでは「作業手順を標準化すれば品質は安定する」という前提があるが、AIの場合は同じ手順でも出力がブレる。
対策として、出力の検証プロセスを強化する必要がある。PMBOK-AIでは、品質管理の比重が従来より大きくなる。
コンテキストの断絶
AIは長期的な文脈を保持できない。プロジェクトが長期化すると、初期の設計意図をAIが忘れてしまう。
対策として、ドキュメントを資産として管理することが必須になる。設計書、要件定義書、コーディングルール——これらを常に最新の状態に保ち、AIに渡すことで一貫性を維持している。
「AI社員の退職」はないが「モデルの変更」はある
人間のチームでは、メンバーの退職がリスクだ。AIの場合、退職はないがモデルのバージョンアップや仕様変更がある。
あるバージョンで安定していた出力が、アップデート後に変わることがある。これは従来のPMBOKにはないリスクだ。PMBOK-AIでは、このリスクを「技術環境リスク」として管理している。
コスト比較：外注相場との公正な比較
PMBOK-AIのコスト効果を正確に把握するため、同規模のサイト構築を外注した場合の相場と比較する。
| 項目 | 外注した場合の相場 | PMBOK-AI適用（自社） |
|---|---|---|
| サイト構築（26ページ、Next.js） | 150〜300万円（制作会社見積もり相場） | AI費用 月3〜5万円（PM人件費別） |
| 開発期間 | 2〜3ヶ月 | 約3週間 |
| 修正・追加対応 | 追加見積もり（1修正あたり数万円〜） | AI費用内で対応可能 |
| 保守・運用 | 月5〜10万円 | 月3〜5万円で継続対応 |
注意すべき点がある。 この比較はPM自身がIT技術への深い理解を持ち、要件定義・設計ができることが前提だ。AIに的確な指示を出すには、「何を作るべきか」を正確に言語化する能力が不可欠である。PMのスキルがなければ、この体制は成立しない。
また、PM自身の人件費（稼働時間）はこの比較に含まれていない。純粋な外部コストとしての比較である点に留意いただきたい。
この手法の限界と今後の課題
PMBOK-AIは強力な手法だが、万能ではない。実践を通じて見えた限界を正直に記す。
AIに任せられない領域
- ビジネス要件の判断：「何を作るべきか」はAIには決められない。市場理解、顧客理解、事業戦略に基づく判断は人間にしかできない
- ステークホルダーとの交渉：クライアントとの折衝、期待値の調整、政治的判断はAIの範囲外
- 責任の所在：AIの出力に問題があった場合、最終責任はPMが負う。AIに責任は取れない
技術的制約
- コンテキストウィンドウの限界：大規模プロジェクトでは、全体像をAIに把握させることが難しい
- 最新技術への対応遅れ：モデルの学習データに含まれない最新ライブラリやAPIには対応できないことがある
- セキュリティ判断：セキュリティに関わる実装の最終判断は、AIに委ねるべきではない
今後の課題
- 複数AI社員間の連携を自動化する仕組みの構築
- プロジェクトの知見をAIに蓄積・引き継ぐ方法の確立
- PMBOK-AIの体制を他者にも再現可能にするためのテンプレート化
結果：何が変わったか
自社サイトプロジェクトにPMBOK-AIを適用した結果をまとめる。
| 項目 | 外注した場合（想定） | PMBOK-AI適用後 |
|---|---|---|
| チーム規模 | 制作会社のチーム（ディレクター + デザイナー + エンジニア） | 人間1名 + AI社員4名 |
| 初期コスト | 150〜300万円 | 3〜5万円（PM人件費別） |
| 開発期間 | 2〜3ヶ月 | 約3週間 |
| 品質管理手法 | 目視レビュー中心 | リバースエンジニアリング + 仕様書照合 |
| スコープ変更への対応 | 追加見積もり + 数日〜1週間 | 数時間 |
| 成果物 | 26ページ | 26ページ + SEO対策 + OGP動的生成 + ブログシステム |
外注相場と比較して、コストは大幅に抑えられ、開発スピードも速い。 ただし、これは「IT技術に精通したPMが適切にコントロールしている」前提の数字だ。
AIに丸投げすれば、品質崩壊が待っている。この点はAI活用で痛感した失敗と教訓で詳しく書いた。
1人で複数案件を同時進行する具体的な方法については、詳細はこちらを参照いただきたい。
まとめ：PMBOK-AIは「PMの役割」を再定義する
PMBOK-AIを実際のプロジェクトに適用して確信したことがある。
PMの役割は「管理者」から「指揮者」に変わる。
従来のPMは、人間のチームを管理し、進捗を追い、問題を解決する役割だった。PMBOK-AIのPMは、**AI社員に的確な指示を出し、品質の最終判断を下し、プロジェクトの方向性を決める「指揮者」**だ。
オーケストラの指揮者は楽器を演奏しない。しかし、指揮者がいなければオーケストラは成り立たない。PMBOK-AIのPMも同じだ。
AIが優秀になればなるほど、PMの「判断力」と「指示力」の価値は上がる。これが、PMBOK-AIの本質だ。
PMBOK-AIの基本概念についてはPMBOK-AIとはをご覧ください。AI社員の実際の稼働データはAI社員4名の実稼働レポートで公開しています。
PMBOK-AIの導入やプロジェクトマネジメントについてのご相談はお問い合わせからお気軽にどうぞ。