AI PMが知るべき開発の実態：テストが通っても仕様と違う

いま起きていること

AIは、コードを書く速さでは人を超えた。 パンダオフィスでは、コンテンツ配信系のSaaS（受託案件）を、PM1人とAIで開発した。設計もまだ固まっていない状態から、約1か月で次の成果物が積み上がった。

（出典：自社ブログ記事「SaaS開発をPM1人×AIで乗り切る｜1ヶ月で209画面を実装した現実」2026-03-24）

数字だけ見れば、開発の仕事はAIに移ったように見える。ただ、同じ期間に、別の種類の問題も積み上がっていた。

テストは通るのに、仕様と違う実装が量産された。 検索フォームの実装を頼むと、絞り込みの機能が検索画面とは別の画面に分離されていた。商品一覧のページ送りを頼むと、全件を一度に取得して画面側で分割表示する実装になっていた。どちらも、テストは通った。

（出典：自社ブログ記事「AI活用の失敗と教訓」2026-02-21）

もう1つは、直した場所と別の場所が壊れるデグレである。共通部品を変えたときに目立った。AIは「今直している箇所」に集中する。「その修正がどこに波及するか」は、こちらが指示しないと見ない。

ある受託案件では、手戻り率を月ごとに数えていた。6月が10%、7月が13%、8月が169%。直す作業が、新しく作る作業より多くなった月である。

（出典：自社の案件記録 2026-06〜08）

PMの仕事で何が変わるか

AIがコードを書くようになっても、開発の仕事が消えたわけではない。担い手が変わっただけである。ブログでは「人間5人で3か月かかる工数を、人間1人とAIで3か月かけて処理している」という言い方をした。工数が減ったのではなく、AIが吸収している。

PMの手元に残る仕事は、次の3つだった。

1. 受け入れ基準を言葉にする。 人間のエンジニアなら、「ユーザー一覧画面をお願いします」と頼めば、並べ替えやページ送りを入れてくれる。AIは、本当にただの一覧を出す。並べ替えの条件、絞り込みの項目、ページ送りの仕様、表示する列、権限による出し分け、データが空のときの表示。すべて、言わなければ付かない。言語化の水準が、そのまま品質の上限になる。

2. 影響範囲を見極める。 修正が別の機能に波及するかどうかは、AIが自分から言ってこない。共通部品に手を入れるとき、どこを横断テストするかは人間が決める。

3. 入力の質を確かめる。 AIが書いたテストは、テストを書いた時点のAIの理解を確認するだけだ。「テストが通ること」と「意図どおりに動くこと」は別である。

4. 自分の稼働を計画に入れる。 この案件の1か月は、朝7時から翌2時まで、休日なしだった。AIが高速に実装を上げてくるので、レビューと判断の往復が途切れなかった。経営者だから成立しただけで、従業員に求める働き方ではない。AI開発は「楽になる」のではなく「1人で回せる量が増える」だけで、総労働量は減らない。PMは、AIの稼働だけでなく、自分とチームの稼働も資源として計画しなければならない。

もう1つ、見落としやすい変化がある。文書が実装に追いつかなくなる。 画面数が、文書の中で237と244に割れ、実装ベースでは209だった。変更の速度が、文書を管理する仕組みを超えたのである。この問題は、次の回の「文書管理」で詳しく扱う。

PMBOK-AIではこう扱う

PMBOK-AIは、AIに任せる範囲を広げるほど、人が握る範囲を明確にすることを求める。開発では、次のように具体化した。

1. 設計は人が決め、実装はAIに任せる。 要件定義、テーブル設計、設計書の方針は人間が決める。そのうえで「ざっくり作って」ではなく、「この設計書に基づいて実装して」と指示する。ブログには、これで手戻りが5分の1以下になったと書いた。ただし件数を数えて比べた値ではなく、体感に近い。

2. 仕様を逆に起こして照合する。 AIが生成したコードから、仕様書を逆に起こす。それを元の設計書と突き合わせる。コードを読んで「なんとなく合っている」と判断すると、読む側の思い込みが入る。仕様書の形にすると、細部ではなく振る舞いの水準で比べられる。

3. 実装する役割と、確認する役割を分ける。 同じAIに「作って、チェックして」と頼むより、役割を分けたほうが見える問題が増えた。ただし、AIのレビュー結果は人が再確認した。ハルシネーションの確率は下げられても、ゼロにはならなかった。

4. 手戻りを数える。 手戻り率を月ごとに数えていたから、8月の169%に気づけた。数えていなければ、「忙しかった月」で終わっていた。

5. 任せる範囲は、リスクの低い順に広げる。 最初から全部を任せない。情報収集、文章の下書き、コーディング、テストの作成の順に広げた。各段階で「どこまで任せられるか」の感覚をつかんでから、次に進む。文章でも同じ失敗があった。AIが書いた記事に「導入企業の90%が生産性2倍」という数字が混ざり、出典を探しても根拠が見つからなかった。コードも文章も、AIの出力は、人が確かめるまで成果物として扱わない。

6. 実装の依頼は、Issueに手順を書いてから渡す。 方向がぶれにくく、何を指示して何が出てきたかの履歴が残る。AIは会話が長いと前提を忘れる。その弱点を、人の側の記録で補う。

AIを活用する開発の考え方は、AIに任せる範囲をPMがどう決めるかでも整理している。また、AIで実際に起きた失敗の一覧も参照してほしい。

明日からやること

• 依頼の文面に、受け入れ基準（並べ替え・絞り込み・空のときの表示・権限）を書く欄を作る
• AIが書いたテストに加えて、仕様書の逆起こしで設計書との差を見る手順を入れる
• 共通部品を変えるときは、横断テストの対象を人が指定する
• 実装を担当するAIと、確認を担当するAIを分ける。確認結果は人が再確認する
• 手戻り率を、月ごとに数える

まとめ

AIはコードを速く書く。しかし、テストが通ることは、意図どおりであることを意味しない。AI時代のPMが握るべきものは、受け入れ基準の言語化、影響範囲の見極め、入力の質の確認である。