PMBOK-AI導入事例｜自社サイト構築で見えた従来PMBOKとの違いと、その後の答え合わせ
この記事の要点
人間1人＋AI社員4名で26ページのサイトを3週間で構築し、AIの費用は月3〜5万円だった。タスクの80%をAIに振り分け、仕様書との照合で品質を確かめた。本記事は2026年2月時点の記録に、2026年10月の答え合わせを足したもの。分担の線引きは今も通用した一方、「24時間動けるAI」は人の総労働量を減らさず、照合を入れても、ざっくり指示はテストが通るのに仕様と違う実装を量産した。
PMBOK-AIは概念だけで終わらせてはいけない。実際のプロジェクトに適用して初めて価値がある。
本記事では、自社サイト（pnd-office.com）の構築プロジェクトにPMBOK-AIを適用した実例を、従来PMBOKとの違いを交えながら解説する。コスト比較、品質管理、そしてこの手法の限界まで含めて、現場のリアルをお伝えしたい。
2026年10月の追記：本記事の本文は、2026年2月時点の記録です。その後8か月、同じやり方を受託案件と自社の運用に広げた結果、当たったことと外れたことがはっきりしました。本文はそのまま残し、あとから外れたと分かった箇所には注記を入れ、末尾に「8か月後の答え合わせ」を足しています。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| プロジェクト名 | 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に分析させ、最初に定義した要件と突き合わせる。これにより、「テストは通るが仕様と異なる」という問題を構造的に防いでいる。
（2026年10月注記） この照合は、自社サイトの規模では機能しました。しかし直後の受託案件では、指示をざっくり出した実装で、テストは通るのに仕様と違うものが量産されました。照合は後から見つける手段で、防ぐ手段は指示の粒度でした。詳しくは末尾の答え合わせに書いています。
また、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の出力が揃っている。これは従来の人間チームでは不可能な進め方だ。
（2026年10月注記） AIは夜も動きますが、出力を見て判断する人は休めなくなりました。この後の受託案件では、1日約19時間・休日なしの稼働になっています。AIが24時間動けることと、人の総労働量が減ることは別でした。
Phase 4：監視・コントロール（人間主導）
- 品質チェック（仕様書照合）
- スコープの調整
- 問題発生時の判断・対応
AIの出力に問題があれば、ここで軌道修正する。従来のPMBOKと異なるのは、修正のサイクルが非常に速い点だ。人間チームであれば修正に数日かかる内容が、AIであれば数時間で完了する。
たとえば、SEOのメタデータ設定に不備が見つかった際、26ページ分を一括修正するのに要した時間は約2時間。人間が手作業で行えば丸1日かかる作業だ。
Phase 5：終結（人間主導）
- 最終品質確認（Lighthouse、表示崩れ、リンク切れ）
- デプロイ・公開
- 振り返り（教訓の記録）
従来PMBOKでは対応できなかった課題
PMBOK-AIを通じて見えた、従来のPMBOKでは対応しにくい課題がある。
深夜・休日の突発対応
サイト公開後、深夜にレイアウト崩れの報告。従来なら翌営業日を待つか、エンジニアへ緊急連絡するしかない場面だ。
仕様変更への即時対応
「やっぱりこのページの構成を変えたい」——プロジェクト中盤での仕様変更は、従来なら工数の再見積もりと調整に数日を要する。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人で複数案件を同時進行する具体的な方法については、詳細はこちらを参照いただきたい。
8か月後の答え合わせ
2026年10月に、この記事を読み直した。自社サイトの後、同じやり方を受託案件と自社の運用に広げ、AIとのやり取りは計測を始めた2025年12月27日から2026年10月14日までに3,024,411メッセージに達した。その記録から見ると、当時の判断は次のように分かれる。
（出典：自社のAI利用統計 2025-12-27〜2026-10-14（3台合算））
当たったこと
- 最初に「AIに任せられるか」で振り分ける：要件定義、テーブル設計、最終的な品質の判断を人が持つ線引きは、その後も変わっていない。むしろ、要件・テーブル設計・設計書の方針は人が決め、AIには設計書を渡して実装させる、という形でより厳しくなった
- ドキュメントを資産として管理する：その後、作業を並列化すると、文書上の数字が実装とずれた。文書は1つの正本に寄せ、実装ベースの数字を正とする運用に落ち着いた
- モデルの変更をリスクとして扱う：主力モデルは、約9か月で9つ入れ替わった。モデルの名前で書いたルールは、そのたびに古くなった。今はモデルの名前ではなく、役割でルールを書いている
外れたこと
- 「24時間対応可能」は、人を楽にしなかった：AIは夜も動くが、レビューと判断の往復が途切れなくなった。1人で回せる量は増えたが、総労働量は減らなかった
- 照合で「仕様と違う実装」は防げなかった：直後の受託案件で、ざっくり指示した実装は、テストが通るのに仕様と違うものが量産され、1機能あたり2〜3回の修正が入った。防ぐ手段は、後からの照合ではなく、実装前の指示の粒度だった
- 「タスクの80%をAIに」は、多く任せるほど良いという前提につながった：その後、レビュー役を毎回起動し、独立した作業は常に並列で回した。2026年8月には、1本のスクリプトのレビューが19周し、毎回読み込む設定が約45,000トークンまで膨らんだ。今は、確かめる場面を絞り、人の確認を残す操作を、削除・本番への反映・外部への送信・費用の発生の4つにしている
（出典：自社の運用記録・事故記録 2026-02〜2026-10）
「今後の課題」のその後
- 複数AI社員間の連携：2026年3月から並列のチームに移った。担当ごとに書き込み先を決めることが前提になった
- 知見の蓄積と引き継ぎ：ルールは足し続けると、新旧が正反対のまま両方読み込まれる。古いルールは、消さずに理由を書いて退役させる
- 他者にも再現できる形：守らせたいことは、手順書の約束ではなく仕組みにした。予定やタスクの書き込みは、人が承認ボタンを押すまで実行されない
この8か月の経緯は、AI PMの1年史に時系列でまとめている。自社サイトを作った時期は、第1回「全部AIと組んだ最初の半年」にあたる。
まとめ：PMBOK-AIは「PMの役割」を再定義する
PMBOK-AIを実際のプロジェクトに適用して確信したことがある。
PMの役割は「管理者」から「指揮者」に変わる。
従来のPMは、人間のチームを管理し、進捗を追い、問題を解決する役割だった。PMBOK-AIのPMは、AI社員に的確な指示を出し、品質の最終判断を下し、プロジェクトの方向性を決める「指揮者」だ。
オーケストラの指揮者は楽器を演奏しない。しかし、指揮者がいなければオーケストラは成り立たない。PMBOK-AIのPMも同じだ。
AIが優秀になればなるほど、PMの「判断力」と「指示力」の価値は上がる。これが、PMBOK-AIの本質だ。
8か月後に付け足すなら、もう1つある。AIが操作できる範囲が広がるほど、何を人に残すかを決める仕事の重みが増す。 指揮者は、演奏させる曲を選ぶだけでなく、止める合図を持っていなければならない。
PMBOK-AIの基本概念についてはPMBOK-AIとはをご覧ください。AI社員の実際の稼働データはAI社員4名の実稼働レポートで公開しています。
PMBOK-AIの導入やプロジェクトマネジメントについてのご相談はお問い合わせからお気軽にどうぞ。
