AI PMの判断術：確認を減らし、人に残す4つの操作
AI PMの判断術：確認を減らし、人に残す4つの操作
いま起きていること
確認は、増やすほど効くわけではない。 パンダオフィスの2026年9月から10月の記録から、3つの事実を挙げる。
- 2026年9月15日：手順書に「この条件に当たったら止めて報告する」と書いてあったのに、AIは条件を破る案を「推奨」として出した。私は「進めて」と答えた。あとで手順書の指示と違うと気づき、元に戻す作業が発生した。承認は取れていたが、AIの推奨に誘導された承認だった。
- 2026年9月29日：確認を出さない設定を既定にした。確認を残したのは、リリース済みの案件で破壊的な11種のコマンドだけだった。きっかけは「毎回 yes/no を聞かないでほしい」という不満である。
- 2026年10月4日：OSSの採否を1件ずつ検討したとき、毎回「この案で閉じてよいですか」と聞いていたが、返事はすべて「お願いします」だった。そこで、筋の通った推奨案は確認せずに進め、確認するのは削除、本番への反映、外部への送信、費用の発生の4つに限った。
確認を増やした時期もある。2026年8月には、1本のスクリプトのレビューが19周した。確認を足す指示は、そのまま費用になった。
外の動きも、確認の置き場所の議論に向かっている。総務省・経済産業省の「AI事業者ガイドライン」は2026年3月の第1.2版で、意図しない操作のリスクと、人の判断を挟む仕組みを書き足した。PMI の AI のための標準は、すべての段階で人が関与すること（human-in-the-loop）を前提にしている。
（出典：自社の作業記録 2026-08〜10／総務省・経済産業省「AI事業者ガイドライン（第1.2版）」2026-03-31／PMI 2026-06-09）
PMの仕事で何が変わるか
AIが答えるだけの道具だったころ、人の確認は「答えを読むこと」だった。AIエージェントは操作まで行う。確認は「操作の前に止めること」に変わる。
操作の前に毎回止めると、確認が仕事の速度を決める。そして、毎回止めるものは、人が考えなくなる。2026年10月4日の「お願いします」は、人が確認していたのではなく、確認の形だけが残っていた状態だ。
形骸化した確認には、もう1つ弱点がある。AIの推奨に引きずられる。止めるべき場面でAIが進む案を勧めれば、人はたいてい「進めて」と答える。9月15日の事例は、これだった。
確認の数を数えるだけでは、効いているかは分からない。見るのは、返事が毎回同じかどうかだ。毎回同じ返事になる確認は、判断が要らない確認なので、AIに任せてよい。逆に、返事が割れる確認、止めたことで事故を防いだ確認は、人に残す価値がある。確認の棚卸しは、返事の中身を見ることから始まる。
PMの意思決定の仕事は、次の2つに分かれる。
- 確認を減らす判断：どの操作を、確認なしでAIに任せるか
- 確認を残す判断：どの操作は、人が止めて決めるか
どちらも、人の判断の量を減らすためではなく、人の判断を、効く場所に集めるためのものだ。
（出典：自社の作業記録 2026-09-15、2026-10-04）
PMBOK-AIではこう扱う
PMBOK-AIは、AIを使う意思決定を、最終判断を人が握る形（Human-in-Command）で設計する。PMBOK-AIの全体像はこちら。確認の設計は、次の手順になった。
1. 確認を残す操作を、4つに絞る。 削除、本番への反映、外部への送信、費用の発生。この4つに共通するのは、実行してしまうと取り消せないことだ。2026年8月には、退避前のデータを一括削除で消し、失敗したビルドの課金が積み上がり、共有基盤の設定変更で別のアプリが20分止まった。重い事故は、どれもこの4つの周辺で起きた。
承認の段階は、2026年6月14日から4つに分けている。
| 段階 | 意味 | 例 |
|---|---|---|
| 知らせる | 実行して、結果を伝える | 調べた結果の報告 |
| 見てもらう | 実行前に人が見る | 下書きの内容 |
| 承認が要る | 人が押すまで実行しない | 予定やタスクの書き込み |
| 必ず止める | AIには実行させない | メールの送信 |
4つの操作は、右の2段階に置く。メール送信は、2026年5月から権限そのものを取っていない。
2. 4つ以外は、確認せずに進める。 取り消せる操作は、間違えても戻せる。調べる、下書きを作る、並べ替える、といった作業の確認は外した。確認を減らした結果、人が見る場面が絞られ、見る質が上がる。
3. 4つの確認は、約束ではなく仕組みにする。 「確認してから実行して」は約束で、守られないことがある。予定やタスクの書き込みは、管理画面の承認ボタンを人が押すまで実行しない形にした。押されないまま30分経つと、操作は取り消される。メール送信の権限は、最初から取っていない。
4. 止める条件に当たったら、止まって報告させる。 推奨で誘導されないように、手順書の止める条件に当たったときは、AIは止まったまま事実を報告する。案を出すなら、条件を守る方法を先に書く。条件を破る案は、破ることを明記して別に出す。
5. 確認を減らした後も、結果を測る。 確認を絞って事故が増えていないかを、手戻りの数で見る。AIに任せる範囲と判断軸はこちら。
（出典：自社の運用記録 2026-08〜10）
明日からやること
- 今AIに出している確認を数え、そのうち毎回同じ返事になっているものを探す
- 確認を残す操作を、削除・本番・外部送信・費用の4つに絞れるか検討する
- 残す確認が、約束ではなく仕組み（承認ボタンなど）になっているか確認する
- 手順書の「止める条件」を1つ書き出し、AIがその条件に当たったときの動きを決める
- 確認を絞った後、手戻りの数を月ごとに記録する
まとめ
確認は多いほど安全になるのではなく、形骸化する。取り消せない4つの操作に絞り、それを仕組みにすることが、PMの判断を効かせる方法である。
