以下のPM業務について、AIへの委任境界を評価してください。

対象業務:
［業務名と現在の手順］

次の4軸で評価してください。
1. 可逆性: 間違った場合に戻せるか
2. 影響範囲: Personal / Team / Organization / External
3. 検証可能性: 正誤を何で確認できるか
4. 文脈依存: 入力にない暗黙知をどれだけ必要とするか

出力:
- 推奨Level: L1 / L2 / L3 / L4
- AIへ任せる範囲
- 人が保持する判断
- 必須の検証方法
- rollback方法
- Levelを上げるために不足している条件

推測で組織事情を補完せず、不明なものは不明としてください。

# PMはAIにどこまで任せるか｜4つの判断軸で委任境界を決める

PM業務でAIを使い始めると、「何に使えるか」より次に難しくなるのが**どこまで任せてよいか**です。

議事録の整形ならほぼ自動でよくても、ロードマップの優先順位やユーザー課題の採否まで同じ強さで委任すると、速くなった代わりに判断責任が見えなくなります。逆に、すべてを人が再確認する運用ではAIを使う効果が小さくなります。

PM Compassでは、AIへの委任を機能単位ではなく、**その作業が間違ったときに戻せるか・誰に影響するか・正しさを確かめられるか・組織文脈をどれだけ必要とするか**で決めます。

## 先に結論：4軸を見て委任レベルを4段階に分ける

最初に、対象タスクを次の4軸で見ます。

| 判断軸 | 確認する質問 | AIへ任せやすい側 |
|---|---|---|
| 可逆性 | 間違っても短時間で元へ戻せるか | すぐ戻せる |
| 影響範囲 | 誤りが誰まで届くか | 自分の作業内で閉じる |
| 検証可能性 | 正誤を客観的に確認できるか | テスト・原文・数値で確認できる |
| 文脈依存 | 暗黙の事情や関係者調整をどれだけ要するか | 入力資料だけで判断しやすい |

その結果を、次の4段階へ落とします。

| Level | AIに任せる範囲 | 例 |
|---|---|---|
| L1 自動実行 | 作成から完了まで | 書式変換、分類、既知フォーマットへの転記 |
| L2 下書き | 完成候補まで作る | PRD初稿、会議要約、リサーチ整理 |
| L3 候補出し | 選択肢と論点まで | 優先順位候補、仮説、リスク候補 |
| L4 人間判断 | AIは材料整理まで | ロードマップ決定、重大なScope変更、対外コミット |

「AIが得意そうか」ではなく、**誤ったときの扱いやすさ**から委任レベルを決めるのがポイントです。

## 1. 可逆性：間違ったときに戻せるか

最初に見るのは精度ではなく、失敗したときの戻しやすさです。

### 可逆性が高い例

- 会議メモを決めた形式へ整える
- 既存PRDからOpen Questionsを抽出する
- ユーザーインタビューの発言をテーマ候補へ分類する
- 既存データから表を作る

出力が間違っても、原文や元データへ戻れます。再生成や手修正も比較的容易です。

### 可逆性が低い例

- 顧客へ確約を送る
- 価格を変更する
- 本番データを削除する
- 開発チームへ優先順位変更を確定事項として通知する

一度外部へ出る、データが消える、複数人の行動が始まる作業は、AIの出力品質だけで委任レベルを上げないほうが扱いやすくなります。

### 実務での質問

1. 間違いに気づく前に外部へ反映されるか
2. 取り消しに承認や調整が必要か
3. 元データや以前の状態へ戻せるか
4. 失敗しても学習コストだけで済むか

「戻せない」が増えるほど、L3またはL4寄りにします。

## 2. 影響範囲：その誤りは誰まで届くか

同じ作業でも、利用範囲で委任レベルは変わります。

例えば「競合比較表を作る」作業でも、

- 自分が仮説を考えるためのメモ
- PMチーム内の検討資料
- 経営会議の意思決定資料
- 顧客へ提示する営業資料

では、誤りの影響が異なります。

### 影響範囲の簡易分類

- **Personal**：自分だけが使う
- **Team**：チームの判断に使う
- **Organization**：複数部署・経営判断へ影響する
- **External**：顧客、ユーザー、パートナーへ届く

PersonalならL1/L2に寄せやすく、Externalへ近づくほどレビューまたは人間判断を残します。

ここで見るのは「重要そうか」という感覚ではありません。**AI出力を信じた人が、その後どんな行動を取るか**です。

## 3. 検証可能性：正しいかを短時間で確かめられるか

AIへ任せやすい仕事には、答え合わせの方法があります。

### 検証しやすい

- 原文との差分を確認できる要約
- SQL結果と照合できる集計
- schemaやlintで確認できる構造化データ
- Acceptance Criteriaと照合できる仕様レビュー
- URLの存在確認ができる内部リンク検査

### 検証しにくい

- このユーザー課題を今解くべきか
- ブランドとしてこの表現を採るべきか
- 営業と開発のどちらの要望を優先するか
- 今回どこまでScopeに含めるか

後者は「正解が分からないからAIを使う」領域ですが、同時に**AIの答えが正しいと確認する方法も弱い**領域です。

そのため、AIには候補・反論・追加質問を出させても、最終決定はL3/L4に残すほうが責任分界を保ちやすくなります。

## 4. 文脈依存：入力に書かれていない事情がどれだけあるか

PMの判断は、ドキュメントだけでは決まらないことがあります。

例えばロードマップには、

- 特定顧客との約束
- 営業上の優先順位
- チームメンバーの習熟度
- 直近障害で増えた運用負荷
- 役員間でまだ揃っていない前提

など、明文化されていない事情が混ざります。

AIがアクセスできるコンテキストにそれらが入っていなければ、論理的に整った提案でも現場では採用できないことがあります。

### 文脈依存を確認する質問

- 入力資料だけ読んだ新任PMでも同じ判断ができるか
- 関係者との過去の会話を知らないと決められないか
- 明文化すると問題になる機密情報へ依存していないか
- 「誰が言ったか」で意味が変わる情報を含むか

文脈依存が高ければ、AIは材料整理・論点抽出までに止めます。

## 5. 4軸からLevelを決める簡易ルール

厳密なスコアリングより、最初は次のルールで十分です。

### L1 自動実行

次をすべて満たす場合。

- 高い可逆性
- Personalまたは限定的なTeam影響
- 機械的に検証できる
- 文脈依存が低い

例：データ整形、定型分類、リンクチェック、決まった形式の変換。

### L2 下書きまで

- 戻せる
- Team内で使うことがある
- 人が短時間で原文・根拠と照合できる
- 一部の文脈が必要

例：PRD初稿、ユーザーリサーチ要約、週次レポート、リリースノート案。

### L3 候補出しまで

- 判断が複数人へ影響する
- 正解が一意ではない
- 文脈依存が高い
- ただし選択肢整理には価値がある

例：優先順位案、KPI候補、価格仮説、ロードマップ案、採用要件候補。

### L4 人間判断

次のどれかが強い場合。

- 取り消しが難しい
- Externalへ直接影響する
- 誤りの損失が大きい
- 正しさを後から判定しにくい
- 未入力の組織文脈が決定を左右する

AIは「決める人」ではなく、前提・選択肢・反論・不足情報を整理する役割にします。

## 6. PM業務を実際に分類してみる

一度、自分の繰り返し業務を10個ほど並べます。

| PM業務 | 可逆性 | 影響 | 検証 | 文脈 | 初期Level |
|---|---|---|---|---|---|
| 会議メモ整形 | 高 | Personal/Team | 高 | 低 | L1 |
| PRD初稿 | 高 | Team | 中〜高 | 中 | L2 |
| インタビュー要約 | 高 | Team | 原文照合可 | 中 | L2 |
| リスク候補抽出 | 高 | Team | 中 | 中 | L2〜L3 |
| KPI候補作成 | 高 | Team | 低〜中 | 高 | L3 |
| 優先順位案 | 中 | Organization | 低 | 高 | L3 |
| Scope確定 | 低〜中 | Team/Organization | 低 | 高 | L4 |
| 顧客への確約 | 低 | External | 低 | 高 | L4 |

この表は普遍的な正解ではありません。同じ「PRD初稿」でも、規制産業、障害対応、決済などでは影響範囲が変わり、Levelを下げることがあります。

## 7. AIへの委任を増やすときはLevelを一段ずつ上げる

最初からL1へ自動化する必要はありません。

例えばPRDレビューなら、

1. AIに不足観点だけ列挙させる
2. 次に修正候補まで作らせる
3. 精度が安定した観点だけ自動修正する
4. 判断が必要な箇所はOpen Questionsとして残す

という順番で委任範囲を広げられます。

### Levelを上げる条件

- 同種タスクで誤りパターンが把握できた
- 評価方法が決まった
- 入力コンテキストが標準化された
- rollback手段がある
- 失敗ログを次のrubricへ戻せる

### Levelを下げる条件

- 新しい顧客・市場・規制へ広げた
- 外部公開へ用途が変わった
- 入力データの品質が落ちた
- 過去に無かった重大な誤りが出た
- 組織方針が変わり暗黙の前提が増えた

委任Levelを固定設定ではなく、運用データで上下させます。

## 8. コピペ用：AI委任境界レビュー

新しいAI活用を追加するときは、次の形式で一度評価します。

```text
以下のPM業務について、AIへの委任境界を評価してください。

対象業務:
［業務名と現在の手順］

次の4軸で評価してください。
1. 可逆性: 間違った場合に戻せるか
2. 影響範囲: Personal / Team / Organization / External
3. 検証可能性: 正誤を何で確認できるか
4. 文脈依存: 入力にない暗黙知をどれだけ必要とするか

出力:
- 推奨Level: L1 / L2 / L3 / L4
- AIへ任せる範囲
- 人が保持する判断
- 必須の検証方法
- rollback方法
- Levelを上げるために不足している条件

推測で組織事情を補完せず、不明なものは不明としてください。
```

この出力も最終判断そのものではなく、委任設計のレビュー材料として使います。

## 9. チーム運用では「AIを使ったか」より境界を記録する

AI利用ルールを「このツールは禁止」「このモデルなら可」だけで作ると、同じモデルでも用途ごとのリスク差を表現しづらくなります。

最低限、繰り返し業務ごとに次を残します。

- Task
- Delegation Level
- Required Inputs
- Verification
- Human Decision Boundary
- Rollback
- Known Failure Pattern
- Last Reviewed

これならモデルやツールを変更しても、業務側の責任分界を引き継げます。

## 今日の持ち帰り

- AI委任は「できるか」より、可逆性・影響範囲・検証可能性・文脈依存で決める
- 自動実行、下書き、候補出し、人間判断の4Levelに分ける
- 不可逆・External・検証困難・文脈依存が強いほど人間側へ寄せる
- 委任Levelは固定せず、失敗ログと検証方法が整うたびに一段ずつ見直す

## PM Compass内で次の作業へ進む

- [AIプロンプト](/prompts)：L2/L3の下書き・候補出しを定型化する
- [Claude Code Skill](/skills)：L1/L2の繰り返し作業をワークフローへ落とす
- [Product Opsテンプレート](/templates)：Delegation Levelと判断ログをチームで残す
- [PM向けツールDB](/tools)：AI導入時に必要な検証・運用機能を比較する

AIへ任せる範囲を広げること自体を目標にする必要はありません。**判断責任を失わずに、戻せる作業から処理量を移す**。その境界を明文化できれば、AI活用を個人技ではなく運用として改善できます。