「これ、AIにレビューさせてOKって言われたので出しちゃいました」。 若手メンバーがそう言いながら顧客向け資料を共有してきたとき、PMとして一瞬、言葉に詰まったことはないでしょうか。指摘したいけれど、生成内容自体は一見悪くない。でも、何かが引っかかる。その違和感の正体は、「誰が責任を持って承認したのか」が消えていることです。
AIの導入は加速していますが、現場で起きているのは「AIに任せた」という名の責任のグレーゾーン化です。本記事では、PMが手放してはいけない4つの承認ラインを整理し、AI生成物の品質と責任を現場運用に落とし込むための判断軸を示します。
なぜ今、AIの『承認責任』を線引きする必要があるのか
Smartsheet が公表した 2026 PPM Priorities Report によれば、PMO の 97% がすでに何らかの形で AI を試している一方で、46% は監督なしの AI を信頼していないと回答しています。この「使ってはいるが、無監督では信用しない」というギャップが、いま現場に静かに広がっている trust gap（信頼の隙間） です。
問題は、このギャップが個人の感覚論に閉じてしまうことにあります。経営は「AIで生産性を上げろ」と言い、現場は「でも怖いから人間がチェックしている」と答える。この間に明文化された承認フローがないと、起きるのは次の3つです。
- AI出力を「下書き」と称してそのまま顧客に渡す
- AI起因の不具合が出たとき、誰の責任か特定できない
- 「AIがそう言ったから」が判断の根拠になり、レビューが形骸化する
つまり、AIをどこまで信用するかは、個人の判断ではなくPMの設計事項です。「便利だから使う」段階から、「どこに承認ラインを引くか」を決める段階に移行しなければなりません。
PMが手放してはいけない4つの承認ライン
ここからは、現場で起きやすい AI 利用シーンを4領域に分けて、PMが最後に判断者として残るべき承認ラインを具体化します。
ライン1：コード（実装の責任所在）
AI による実装やリファクタリングは、すでに多くの開発現場で日常になっています。ただし、PM が手放してはいけないのは「そのコードを本番に出す承認」です。
承認時に確認したいのは、AI が書いたかどうかではありません。次の3点です。
- 影響範囲が見積もれているか（既存仕様への副作用）
- レビュアーが「AIが生成したコード」だと認識した上で読んでいるか
- 不具合が出たとき、修正できる人が社内にいるか
特に3つ目は、AI生成コードの保守責任を担保する最低ラインです。「動いているけれど、誰も中身を理解していない」状態を許してしまうと、半年後の障害対応で身動きが取れなくなります。AIによるレビュー自動化のリスクや活用範囲は AIを技術メンターへ。劇的に変わるコードレビュープロンプト術 でも整理しているので、合わせて確認してください。
ライン2：設計書・要件定義書（仕様の解釈責任）
AI に WBS や要件定義のたたき台を作らせるのは効率的ですが、「これを正としてよいか」を判断する責任は人間に残ります。理由は、設計書がプロジェクトの判断根拠になるからです。後工程で「設計書にこう書いてあったから」と参照されたとき、その文書の意図を説明できる人がいなければ、議論が成立しません。
承認時のチェックポイントは次の通りです。
- ステークホルダー固有の制約（業界規制、社内ルール）が反映されているか
- AI が一般論で埋めた箇所と、現場固有の判断が必要な箇所が区別されているか
- 「この設計の意図は？」と聞かれたとき、PMまたは担当者が答えられるか
AI を WBS 作成や設計補助に活用する具体的な方法は AIをベテランPMに変えるWBS作成のプロンプト術 で解説しています。生成と承認は別の責任として扱う、という前提を持っておくと運用が崩れにくくなります。
ライン3：顧客向け文書（対外コミュニケーションの責任）
これが最もリスクが高い領域です。提案書、報告書、議事録、メールテンプレート。AI で生成した文書をそのまま顧客に出すことの怖さは、内容の誤りだけではありません。「お客様との約束」を、社内で誰も精査せずに発信してしまうリスクです。
PM として最低限引いておくべきラインは、次の通りです。
| 文書種別 | AI生成の許容度 | PM承認の必須度 |
|---|---|---|
| 議事録の下書き | 高い | 内容差分のみ確認 |
| 進捗報告書 | 中程度 | 数値根拠とリスク記述は人間が確認 |
| 提案書・契約関連 | 低い | 全文を人間が責任を持って確認 |
| 障害報告書 | 低い | 原因と対応の整合性を必ず人間が確認 |
ポイントは、「誰が読むか」と「何を約束しているか」で承認の重さを変えることです。社内向け議事録と、顧客向け障害報告では、AI に任せていい範囲がまったく違います。
ライン4：見積（金銭・契約に関わる責任）
見積金額や工数の試算を AI に任せるケースが増えていますが、これは最後まで PM が判断者として残らなければならない領域です。理由はシンプルで、見積は契約の根拠になるからです。
AI の見積試算は次の用途には使えます。
- 過去案件のデータから類似性を抽出する
- ロジックの抜け漏れをチェックする
- 複数パターンを短時間で比較する
しかし、「この金額で受ける」という最終判断は、リスクと合意形成を含めた経営判断です。仕様の不確実性、顧客の支払い能力、社内のリソース余力。これらは AI が出した数値の外側にある情報で、PM が現場で集めるしかありません。AI を仕様変更交渉に使う考え方は PMの炎上を防ぐ！AIを活用した無理な仕様変更プロンプト術 も参考になります。
承認フローを設計するときの3原則
4つのラインを引いたら、それを運用できる形に落とす必要があります。現場で機能させるための原則は次の3つです。
- 「AI使用の有無」をログに残す：どの成果物に AI を使ったかを必ず記録する。後追いで責任所在を確認できる状態を作る。
- 「最終承認者」を成果物単位で1人に絞る：複数人で分散させず、責任が誰にあるかを一意に決める。PMが直接でなくてもよいが、PMが「誰が承認したか」を把握している状態を維持する。
- 「AIに任せた範囲」と「人間が判断した範囲」を分けて記述する：レビュー欄や承認コメントに、人間がどこを判断したかを明記する。これがあれば trust gap の議論が個人攻撃にならず、運用改善の対象になる。
この3原則を忘れると、ガバナンスは「禁止」か「自由」の二択になりがちです。実態に合わない禁止は守られず、自由放任は責任の所在が消えます。**「使っていい、ただし承認は残す」**が、現場で続けられる落としどころです。
まとめ：trust gap を埋めるのは、ツールではなく設計
AI の導入で生産性が上がるのは事実ですが、生産性の話だけで議論を終わらせると、責任が空白になった成果物が増えていきます。承認ラインを引くことは、AI を使わない理由ではなく、AI を安心して使い続けるための条件です。
今日から始められるのは、自分のチームの直近の成果物を1つ取り上げ、「この中で AI が触れた範囲はどこか」「最終承認者は誰か」を言語化してみることです。それが書き出せないなら、承認フローはまだ設計されていません。
テックエイドでは、AI の運用管理と現場ガバナンス、品質・トラブル対応を体系的に学べる Udemy 講座を提供しています。AI 承認ラインの設計に直結するのは次の3講座です。
- AIX-103（AI運用管理）：AI 利用ルールと承認フローの設計を、現場の運用に落とすための実践講座
- PJM-104（プロジェクト品質管理）：AI生成物を含む成果物レビューの判断基準と、品質ゲートの作り方
- FFF-103（トラブル対応）：AI起因のインシデントが起きたときの初動対応と、再発防止の責任設計
「AI に任せていいのか、ダメなのか」を現場任せにせず、PM が判断軸を持って指揮できる状態を作る。そのための具体的なフレームと事例を、講座でまとめて学べます。承認ラインの設計に課題を感じているPMの方は、ぜひ関連講座をチェックしてください。