AIを試した次に詰むのはガバナンス｜PMOが整える4観点の運用ルール

「現場ではもう各自がAIを使い始めているのに、会社としてのルールが追いついていない」。PMOや管理職の方から、この相談が一気に増えました。Smartsheetが2026年に出した PPM priorities report では、回答者の97%が業務でAIを試している一方、46%は人の監督がないAIの判断を信頼していないと答えています。導入の波には乗ったものの、責任の置き場と運用の枠組みが空白のまま、という状態です。

本記事では、この trust gap を埋めるためにPMOが整えるべきAIガバナンスを、用途・データ・承認・監査の4観点に分けて設計する考え方を整理します。「AIを止める」のではなく「AIを安全に走らせる」ための運用ルールづくりが目的です。

なぜ「使ってみた」の次にPMOが詰まるのか

AI活用の入口は、たいてい個人や小チームのトライアルから始まります。ところが組織として広げようとした瞬間、別の壁にぶつかります。

顧客データを社外AIに投げてよいかが判断できない
AIが書いた成果物の品質責任を誰が持つのか決まっていない
著作権・ライセンスの線引きが現場任せになっている
「AI関連の意思決定者」が組織図に存在しない

これは技術の問題ではなく、統制設計の不在が露出している状態です。情報システム部門だけでも、法務だけでも閉じない。プロジェクト全体を横串で見るPMOが、ガバナンス設計の主導権を握る局面に来ています。

関連: AIが書いた成果物の品質責任を現場でどう担保するかは AI生成物をそのまま顧客に渡してはいけない｜PMが残すべき4つの承認ラインでも整理しています。

観点1：用途（どの業務でAIを使ってよいか）

最初に決めるのは「使う・使わない」ではなく「どの業務カテゴリで、どのレベルまで使ってよいか」です。一律禁止も一律解禁も、現実には機能しません。

実務で使いやすいのは、業務をリスクで3層に分ける方法です。

区分	例	AI利用のルール
推奨層	議事メモ要約、社内文書ドラフト、調査の一次整理	標準ツールで自由に使ってよい
条件付き層	顧客向け提案書、設計書、レビューコメント	人の確認・編集を経た成果のみ提出可
制限層	契約・見積の最終文言、本番コードの直接適用、人事評価の判断	AI単独の出力は禁止、責任者の承認必須

このマトリクスを「AI利用ガイドライン」の中核に置くと、現場は迷いません。PMOの役割は、業務をこの3層に分類するルールを決め、プロジェクトごとの当てはめをレビューすることです。

観点2：データ（何を入力してよいか）

次に詰めるのは入力データの統制です。ここが最も事故が起きやすい領域で、規制業界ほど厳しめに線を引く必要があります。

最低限決めておきたい項目はこの4つです。

持ち出し可否：個人情報・顧客機密・未公開財務情報を外部AIに投入してよいか
マスキング基準：固有名詞・契約金額・人物特定情報をどこまで匿名化するか
保管期間：プロンプトと出力ログをどれだけ保存し、いつ廃棄するか
再学習の可否：投入データをベンダー側の学習に使われない設定になっているか

ここで重要なのは、「使ってよいAIツールのリスト」と「投入してよいデータの定義」を別々に管理することです。ツールを選ぶ判断とデータを扱う判断は、別の責任者がレビューしたほうが事故が減ります。

観点3：承認（誰がGOサインを出すか）

AIが関わる成果物には、人間の承認ラインを必ず残します。ここを省略すると、後から「これ誰が決めたんですか」が必ず発生します。

PMOが定義しておくべき承認の単位は次の3つです。

ツール導入承認：新しいAIツール／APIを業務で使う前のセキュリティ・契約レビュー
ユースケース承認：プロジェクト単位で「どの工程に・どのAIを・どう使うか」を申請する仕組み
アウトプット承認：顧客提出物・本番反映物にAI生成物が含まれる場合の最終レビュー

3つのレイヤーを混ぜるとボトルネックになります。ツールは情シス／法務、ユースケースはPMO、アウトプットはプロジェクト責任者、というように担当を分けて並走させるのが現実的です。

承認を作業フローに組み込む具体的なやり方は PRの一次レビューをClaude Codeに任せる｜Code Review導線設計の実践や Claude Codeに任せていい作業・任せてはいけない作業｜PermissionsとAuto Modeの境界設計も合わせて参考にしてください。

観点4：監査（後から検証できる状態を残す）

最後の観点は、**「使った後に説明できる状態を作る」**ことです。trust gap を埋めるのは禁止ルールではなく、検証可能性です。

監査面で最低限残しておきたいのはこの4つです。

AI利用申請の履歴（どのプロジェクトが、どの用途で申請したか）
重要アウトプットのプロンプトと参照データ（再現できる粒度で）
ツール／モデルのバージョン変更履歴
インシデント記録（誤情報・情報漏えい疑義・著作権トラブル）

これらは「監査のための記録」であると同時に、ナレッジの源になります。失敗例を含めて記録を残すと、半年後に同じ判断を繰り返さなくて済みます。PMOが運用するナレッジベースに、AI関連の事例レーンを切るのが効きます。

4観点を「導入ステップ」に並べ替える

4観点は同時に走らせるよりも、順番に積み上げるほうが組織は動きやすくなります。3〜6か月のロードマップに置き換えると、こうなります。

最初の30日：用途の3層分類とデータ取扱いガイドラインのドラフトをPMOで作る
次の60日：ツール導入承認とユースケース承認のフローを情シス・法務と合意する
その後：アウトプット承認と監査ログの運用を、既存のレビュー会議に組み込む

ポイントは、新しい会議体を増やさないことです。既存のキックオフ・品質レビュー・月次PMO会議に、AIに関する1〜2項目を差し込むだけで運用は回り始めます。

まとめ：PMOがAIガバナンスを設計するということ

「AIを試したが、組織として次の一歩が打てない」のは、技術ではなく統制の問題です。用途・データ・承認・監査の4観点を、PMOが主語で設計し直す。これが trust gap を埋める実装のかたちです。

そしてこの設計は、PMOの既存の強み——プロジェクト横断の可視化、品質統制、意思決定の支援——とそのまま地続きです。新しい役割を増やすのではなく、既存のPMO機能をAI時代に合わせて再定義する作業だと考えてください。