「契約書は法務が見るもの」と思っているPMほど、案件後半で炎上します。検収条件、瑕疵担保、変更管理プロセス、納品物の定義——契約とSOWの粒度がぶれていると、終盤で「これは契約に書いてない」と顧客と揉めることになります。
「AIに契約書を読ませる」は危険ですが、PM視点でリスクになる条項を抽出するチェックは強力に効きます。本当に効くのは、SkillでSOWと契約書をPM観点でリスクスキャンし、潰すべき論点をリスト化する運用です。
この記事では、Claude CodeでSOW・契約レビューの初動を半自動化する実装を、現場で動かせる粒度で解説します。
なぜPMは契約レビューに踏み込めないのか
PMが契約レビューを法務任せにしてしまうのは、能力ではなく構造的な問題です。
- 法務とPM視点が違う：法務は法的リスク、PMは運用リスクを見るが、両者を結ぶ言語が定まっていない
- チェック観点が体系化されていない：個人のヒヤリハット記憶に依存し、再現性がない
- 時間がない：契約締結ドラフトが回ってきたとき、PMが体系的に確認する時間が取れない
Claude Codeは、SkillにPM観点のリスクチェックリストを持たせ、SOW・契約書から論点を抽出することで、PMが法務と並んでレビューに参加できる体制を作れます。
Claude Codeを「契約レビュー支援器」にする全体像
必要な要素は次の3つです。
- PM観点リスクチェックリストYAML：検収条件、変更管理、瑕疵担保など、PMが見るべき観点を構造化
- 契約レビューSkill：SOW・契約書PDFを読み、チェックリストに沿って論点抽出
- CLAUDE.md契約レビュー運用ルール：自社の契約スタンス、絶対譲れない条項、PMの判断境界
これが揃えば、PMは1時間で契約書のPM観点リスク一覧を手にし、法務との議論に入れます。
ステップ1：PM観点リスクチェックリストを定義する
docs/contract/pm-review-checklist.yaml に体系化します。
checklist:
- category: "検収条件"
items:
- "検収基準が定量化されているか（合格率/応答時間/エラー率など）"
- "検収期間が明示されているか"
- "検収者の指定があるか"
- "みなし検収条項の有無"
- category: "納品物の定義"
items:
- "成果物リストが明示されているか"
- "ドキュメントの粒度が定義されているか"
- "ソースコードの権利帰属が明確か"
- category: "変更管理"
items:
- "変更要求の手続が定義されているか"
- "変更費用の精算方式が明確か"
- "スコープクリープを防ぐ条項があるか"
- category: "瑕疵担保・サポート"
items:
- "瑕疵担保期間と範囲が明示されているか"
- "サポート対応のSLAが定義されているか"
- "対応外項目が明示されているか"
- category: "知財・秘密保持"
items:
- "成果物の権利帰属"
- "OSS利用時の取扱い"
- "秘密保持義務の期間"
- category: "リスク条項"
items:
- "損害賠償の上限"
- "免責事項の範囲"
- "再委託の可否"「PM観点」と「法務観点」を区別するのが運用の核心。重複部分はあっても、PM視点では運用負荷の論点に重み付けします。
ステップ2：契約レビューSkillを定義する
.claude/skills/contract-review/SKILL.md を作成します。
---
name: contract-review
description: tmp/contracts/{project-id}/ 配下のSOW・契約書テキストを pm-review-checklist.yaml に沿ってスキャンし、PMが潰すべき論点を tmp/contracts/{project-id}/review.md に出力する
disable-model-invocation: true
allowed-tools: Read, Write
---
# 契約レビューSkill
## 入力
- `tmp/contracts/{project-id}/sow.md`：SOW全文（PDFをmarkdown化したもの）
- `tmp/contracts/{project-id}/contract.md`：契約書全文
- `docs/contract/pm-review-checklist.yaml`
## 処理
1. SOW・契約書全文を読む
2. チェックリスト各項目について次を判定
- 該当条項があるか（あれば条項番号と本文抜粋）
- 内容が曖昧か明確か
- PMが運用上困る可能性があるか
3. 結果を「論点リスト」として出力
- critical: 締結前に必ず修正・追記
- high: 法務と相談すべき
- medium: 議事録で確認しておく
4. 各論点に「想定される運用上の問題」を1〜2行で付記
## 出力フォーマット
- ファイル：`tmp/contracts/{project-id}/review.md`
- 章立て：①critical論点 ②high論点 ③medium論点 ④チェックリスト網羅状況 ⑤PM判断欄（**空欄**）
## 厳守
- 法的解釈はAIが下さない（法務観点はスコープ外と明記）
- 「修正案文」をAIが書かない（論点提示まで）
- 機密保持に配慮し、契約書原文を外部送信しない（ローカル処理前提）「修正案文をAIが書かない」が安全装置。AIが書いた条項が法的に成立する保証はないため、論点提示までに留めます。
ステップ3：CLAUDE.mdに契約レビュー運用ルールを書く
## 契約・SOWレビュー運用ルール
### 自社の契約スタンス
- 受託案件：成果物完成基準型を原則、準委任型は例外
- 検収期間は最低2週間を確保
- 損害賠償上限は契約金額の100%が原則
- 瑕疵担保は3ヶ月、重大不具合は6ヶ月
### 絶対譲れない条項
- みなし検収条項の追加は不可
- 知財帰属は受注者側に留保（顧客への利用許諾形式）
- 再委託は事前承認制
### PM判断の境界
- PMが判断すること：運用上の実現可能性、スケジュール影響、コスト影響
- 法務が判断すること：法的リスク、損害賠償、責任範囲
- 営業が判断すること：価格、商習慣
### AIに任せないこと
- 法的解釈（法務の専管）
- 修正案文の起案（必ず人間が書く）
- 顧客との交渉ストーリー（事業判断）CLAUDE.mdが「PM判断の境界」を明示することで、AIが越境した出力を出さない設計になります。
ステップ4：実際の運用フロー
契約レビューの動きは次の通りです。
- ドラフト受領：営業から契約書・SOWドラフトが回ってくる
- PDF→Markdown化：
pdftotextなどでテキスト化、tmp/contracts/{project-id}/配下に格納 - PMレビュー：
/contract-review project-id=PROJ-2026-Aを実行 → 論点リスト生成（30分） - PM判断：critical/highの論点をPMが精査、ステークホルダー観点で優先順位付け
- 法務連携：論点リストを持って法務とミーティング、修正案文を法務が起案
- 契約締結会議：PMと法務と営業の3者で論点を網羅的にクロージング
これまで「ドラフトを流し読みして気になった点を伝える」だった運用が、「体系的な論点リストで議論する」運用に変わります。
期待効果と運用上の注意点
導入チームから報告される効果は3点です。
- PMが契約議論に並ぶ：論点リストが揃うため、法務と対等に議論できる
- 検収/変更管理での揉め事が減る：締結前に論点を潰すため、終盤の炎上が減る
- PMの判断軸が組織に蓄積：チェックリストが組織知になる
落とし穴は3つ。
- 法的解釈をAIに書かせない：論点提示までに留める
- 修正案文をAIに書かせない：法的に成立する保証がない
- チェックリストの定期見直し：法改正・組織方針変更で更新する
まとめ
- PMが契約レビューを法務任せにすると、終盤で運用上の問題が顕在化する
- PM観点のチェックリストを持たせれば、AIで論点抽出が一気に楽になる
- 法的解釈・修正案文はAIに書かせず、論点提示まで
- 「PM判断の境界」を明示することで、AIが越境した出力を出さない設計になる
ここまでで「動く契約レビュー支援器」は手に入ります。実務でこれを“炎上を予防する契約運用”に育てるには、契約戦略、価格交渉、上流から下流までのリスク管理連動といった上位設計が必要です。
BIZ-201『PMの契約・SOW実務』 と FFF-105『炎上を未然に防ぐ上流設計』 を組み合わせると、本記事のSkillをベースに、契約レビューと炎上予防を体系で学べます。「契約は法務任せ」のPMが、最短で“契約段階で炎上を潰す運用”に到達するための導線です。