AI PMの品質ゲート：結論は入力の質で覆る

いま起きていること

AIの解析の手順に誤りはなくても、結論は覆る。 品質の確認をすり抜けた事例が、この3か月に3つあった。

• ある業務システムの解析：AIと進めた解析で、ある指標の悪化をいったん報告し、のちに撤回した。入力に使ったデータの抜き出しに取りこぼしがあり、数え直すと悪化は判定できなかった。誤っていたのは手順ではなく入力だった。
• 2026年8月：サイトに新しいブランドを足したとき、修正が必要な3か所のうち2か所しか直せていなかった。ビルドも型チェックも通ったが、そのブランドの記事10本が表示されなかった。別の案件では、バックアップの自動実行が「成功」と記録されていたが、中身は3秒で終わる空振りで、バックアップが取れているかを確かめていなかった。
• 2026年10月2日に公開した実験：メール自動送信の仕組みに、テストが400件以上すべて通る状態で、別のAIセッションにコードを3周レビューさせた。1周目で重大度「高」が2件、2周目で1件出た。二重送信の穴と、テスト送信が苦情率の計算に混ざって安全装置を鈍らせる問題だった。

AIの出力を人が確かめる作業の量も、無視できない。2026年6月には、本書『PMBOK-AI』の全14章を5体のAIに並行して事実確認させた。見つかった修正は、機械的に直せるもの、著者にしか分からないもの、方針の承認が要るものの3種類に分けて扱った。確認の対象が増えるほど、確かめ方の設計が品質を左右する。

もう1つ、記録の質を変えて測った結果がある。自社の作業履歴120件から、情報を機械的に落とした3段階の記録を作り、同じ12問を解かせた。無効にした1問を除く11問の正答率は、理由と経緯が残る記録で91%、機械が読める記録で73%、人が見るための記録で0%だった。

外の調査でも、使うことと成果は離れている。McKinsey の2026年の調査では、80%が「AIで自分の生産性が上がった」と答えたが、利益にプラスの寄与があった組織は37%だった。

（出典：自社の案件記録 2026-08〜09／自社の実験記録 2026-10-02／自社の実験「記録の段階と答えられる範囲」／McKinsey「The state of AI in 2026: On the road to ROI」2026-08-25）

PMの仕事で何が変わるか

AIが出す成果物は、検査を通りやすい。ビルドは通り、テストは通り、報告は「成功」と書いてある。それでも、品質は別のところで崩れていた。

PMの仕事は、「検査に通ったか」を見ることから、検査が何を見ているかを見ることに移る。3つの事例で、検査が見ていなかったものは次のとおりだ。

AIは作業が速いので、見ていないものがあると、問題が大量に積み上がってから見つかる。品質の確認は、AIの出力を後から読むだけでは追いつかない。

（出典：自社の案件記録 2026-08〜09／自社の実験記録 2026-10-02）

PMBOK-AIではこう扱う

PMBOK-AIは、品質の確認を、作業の前に決める評価計画（EVALP）として扱う。PMBOK-AIの全体像はこちら。パンダオフィスの場合、評価計画は3か所に確かめどころを置き、終わりの条件と報告の扱いを足す形になった。

1. 入力の質を、結論より先に確かめる。 記録の質を3段階で比べた実験では、件数や日付を問う5問は、機械が読める記録でも全問解けた。だが、理由や経緯を問う3問は、理由が残る記録でしか解けなかった（2問正解）。人が見るための記録では、全問解けなかった。記録の段階で、答えられる問いの範囲が決まる。 解析を始める前に、入力の件数、欠けている範囲、抜き出しの条件を数える。

2. 成果物そのものを見る。 ビルドが通ったら、生成されたページを開く。バックアップの成功表示が出たら、保存された中身を確かめる。件数は、表示を切り詰めた出力ではなく、数え直した数字で信じる。

3. 物差しを変えた独立の目を入れる。 メール送信の実験では、「レビューして」ではなく「売り物として評価してほしい」と頼んだ。物差しが「お客さんの現場で事故にならないか」に変わったことで、テストの外にあった穴が見えた。AIが書いたコードをAIに見せても、同じ頼み方なら同じ考え方で見落とす。見る立場を変えるのが要点だ。AIに任せる範囲と判断軸はこちら。

4. 確かめる回数に、終わりの条件を置く。 2026年8月、1本のスクリプトのレビューが19周した。指摘は合計48件で、重大度「高」は5周目でゼロになっていた。残りの14周は軽微な指摘で、原因は規約に私が「Aランク（90点以上）まで」と足したことだった。今は、重大・高の指摘がゼロになったら終了し、上限は3周と決めている。判定はAIの自己申告ではなく、仕組みで行う。

5. 判定の列を分ける。 定型業務の突合を自動化したときは、判定はツールが行い、最終判断は人が持つ形にした。ツールの判定を人の判定として上書きしない。提出前には、独立したAIにレビューをさせ、重大度「高」の指摘がゼロになってから出した。

6. AIの「誤り」報告も、一次資料で確かめる。 2体のAIが「誤り、削除すべき」と報告した数値が、一次資料では正しかった例がある。品質の確認の側にも、確認が要る。

（出典：自社の実験「記録の段階と答えられる範囲」／自社の実験記録 2026-10-02／自社の調査記録 2026-08）

明日からやること

• AIの結論を受け取る前に、入力の件数と欠けている範囲を数える
• 「成功」「通過」の表示がある検査について、何を見ているかを1行で書く
• ビルドやバックアップなど、表示だけで安心している箇所の中身を1回開く
• レビューの終了条件（重大・高がゼロ、上限3周など）を、規約に書くだけでなく仕組みにする
• 同じAIのレビューが続くときは、頼み方の物差しを1つ変えて回す

まとめ

AIの結論は、入力の質を超えられない。品質のゲートは、結論の手前の入力と、検査の手前の成果物に置く。