ノウハウ リーガルプレイブックの作り方｜「ベース×差分」で育てる、AIが引ける自社基準の設計論
リーガルプレイブックの作り方｜「ベース×差分」で育てる、AIが引ける自社基準の設計論
プレイブックが「AIレビューの精度」を決める
生成AIに契約をレビューさせても、「一般論としては正しいが、うちの基準とは違う」出力になる。この原因の多くは、AIに渡している情報が契約書本文だけで、自社の判断基準を渡していないことにあります。
この「判断基準」を明文化したものがリーガルプレイブックです。本来は人間のレビュアーが「この条項はこうあるべき」と判断するための指針ですが、これをAIが引ける形で持っておくと、AIレビューは「うちの基準ではどうか」を踏まえた出力に変わります。
だが、多くの法務部門でプレイブック作りが止まるのは、「完璧なものを作ろうとする」からです。全類型を網羅した重いドキュメントを目指した瞬間、作業は止まります。本記事では、「軽く始めて、AIと一緒に育てる」ための設計論を、3つのステップで整理します。
（プレイブックを含む「判断知」全体の設計は、別記事「AIに学ばせるべきは契約書ではなく『判断知』」で整理しています。本記事はそのうち「プレイブック」の各論に焦点を当てたものです。）
プレイブックとは何か：「あるべき姿・許容範囲・NG」の3層
プレイブックを「社内ひな形」と混同しているケースがよくありますが、両者は役割が違います。ひな形は「自社から提示するときの文面」、プレイブックは「相手から提示された文面をどこまで受け入れるか」の基準です。レビューで効くのは後者です。
プレイブックの1項目は、3層で持つとAIが判定しやすくなります。
| 層 | 意味 | AIの振る舞い |
|---|---|---|
| ★ あるべき姿（必須） | これがないと原則承認しない水準 | 欠けていたら「要修正」として指摘 |
| ◎ 許容範囲（交渉ゾーン） | ここまでなら譲歩可能 | 範囲内なら「OK（譲歩余地あり）」と表示 |
| × NG（絶対ライン） | これを越えたら人間に上申 | 該当したら「人間判断へエスカレーション」 |
この3層を、全条項ではなく「自社がこだわる条項」から埋めていくのがコツです。最初から全部を埋めようとしないことが、続けられるプレイブックの第一条件です。
ステップ1：ファイルをどう分けるか
最初の分岐は「1つの巨大なプレイブックを作るか、類型ごとに分けるか」です。結論は「契約タイプで分ける」。理由は、同じ「業務委託」でも、自社が受託者か委託者かで判断が真逆になるからです。
たとえば知財帰属と契約不適合責任は、受託者と委託者で次のように正反対します。
| 論点 | 委託者側のあるべき姿 | 受託者側のあるべき姿 |
|---|---|---|
| 知財の帰属 | 成果物の権利は委託者に集中させたい | 汎用部分・既存著作物は受託者に残したい |
| 契約不適合責任 | 期間・範囲を広く取りたい | 期間・範囲を狭く限定したい |
| 損害賠償上限 | 上限なし／高めにしたい | 委託料を上限にしたい |
だから、ファイルは「類型 × 自社の立場」で分けます。始めは、件数の多い類型から2～3ファイルだけで十分です。
playbook/
業務委託_委託者.md ← まずここから
NDA_双務.md
_common/一般条項.md ← 準拠法・合意管轄など全類型共通
この段階で「売買もライセンスも雇用も」と手を広げると口が止まります。最もレビュー件数が多い1類型を選び、そこだけを完成させて「回る状態」を作るのが近道です。
ステップ2：共通ベース×差分で持つ
類型を分けると、今度は「似たようなファイルが增えてコピペが汎濫する」問題にぶつかります。業務委託の中でも開発委託・コンサル・BPOで細部が違うからといって、それぞれを全文コピーして作ると、法改正や方針変更のたびに全ファイルを直すことになり、大企業規模では必ず破綻します。
そこで「共通ベース＋差分」で持ちます。ベースに類型全体の基準を置き、差分ファイルは「基準が変わる条項だけ」を上書きします。
業務委託_委託者.md （ベース：類型共通の基準）
+ 開発委託_委託者.diff.md （差分：知財・検収・再委託の3条項だけ上書き）
+ BPO_委託者.diff.md （差分：個情・SLAの2条項だけ上書き）
差分ファイルには、「ベースのどの条項を、どう上書きするか」だけを書きます。
# 開発委託_委託者.diff
## 成果物の知財帰属（ベースを上書き）
- ★必須: 本件用に作成したプログラムの著作権は委託者に譲渡
- ◎許容: 汎用ライブラリ・ノウハウは受託者に留保（無償利用許諾を取る）
この持ち方の効果は、メンテナンスが線形にしか増えないことです。準拠法や反社条項のような「全類型共通」の基準を見直したいとき、_commonを1枚直せば全類型に反映されます。新しい部署が增えても、追加するのは「基準が変わる条項だけ」の差分ファイルだけで済みます。
ステップ3：「条項×観点」の1行に落とす
ファイル構造が決まったら、中身をAIが引ける1行に正規化します。Excelにありがちな「規定例・コメント・妥協案が混在したセル」は、AIにとって読みにくい形です。「条項 × 観点」を軸に、★／◎／×の3層で書きます。
# 損害賠償
## 賠償上限
- ★必須: 上限を設ける（未設定は要修正）
- ◎許容: 委託料総額の100～200%の範囲
- ×NG: 個人情報漏えい・故意重過失を上限の対象に含める
## 間接損害・逸失利益
- ★必須: 原則除外を明記
この書き方にすると、そのままレビュープロンプトの一部としてAIに渡せます。AIは各条項を★／◎／×に照らして「このドラフトはどの層に該当するか」を判定し、根拠条文と修正案を返します。この3層区分は、そのまま「自動判定／要確認／人判断」のエスカレーション設計にもつながります。
業務委託契約の具体的な論点・チェック項目は、生成AIで「業務委託契約」をレビューする手順とプロンプト集に詳しいため、プレイブックの「条項×観点」を埋める際の雛形として使えます。
やってはいけない設計（3つの失敗パターン）
失敗1：「完璧な網羅」を目指して公開されない
全類型・全条項を網羅してから使い始めようとすると、完成前に力尽きます。1類型・主要な10条項から始め、使いながら条項を追加するのが正解です。
失敗2：全ファイルをフラットに並べる
類型ごとに独立した全文ファイルを並べると、共通条項の改訂が全ファイルに波及します。**ステップ2の「ベース＋差分」**を最初から採ります。
失敗3：「コメント」と「基準」を混ぜる
「この条項は注意」というメモと、「こうあるべき」という基準が同じセルに混ざると、AIはどちらを適用すればよいか迷います。基準（★◎×）と補足メモを行で分けるだけで、判定精度が上がります。
プレイブックを「育てる」：AI出力の取り込みループ
プレイブックは一度作って終わりではなく、レビューのたびに育ちます。鍵は、AIの出力や人間の上書きを、プレイブックに返すループを軽く回すことです。
- AIがプレイブックに照らしてレビューし、★◎×の判定と根拠を返す
- 人間レビュアーが必要に応じて上書きし、その理由を残す
- 上書きが繰り返される論点は、プレイブックの「許容範囲」を見直すシグナルとして扱う
- 四半期に1度、類似の上書きをまとめてベース／差分に反映する
このループを回すためにも、プレイブックは「書く手間が小さい」状態に保つのが重要です。重い入力フォームを介さず、テキストと1行追記で済むからこそ、現場が書き続けられます。
まとめ：プレイブックは「軽く始めて、AIと育てる」
リーガルプレイブックは、AIレビューを「一般論」から「自社基準」に引き上げるための中核です。作り方の骨は3ステップ、すなわち類型×立場でファイルを分け、共通ベース＋差分で持ち、条項×観点の1行に落とす、です。
いずれも貫く原則は、「完璧を目指さず、軽く始めてAIと一緒に育てる」ことです。1類型・10条項から始め、レビューのたびに上書きを返して育てる。これが、続くプレイブックの唯一の作り方です。
こうして育てたプレイブックを、日常使っている生成AIから契約データに向けてそのまま使えるようにするには、契約データの正本を一元管理しつつAIを自社で選べるオープン型CLMの考え方が生きてきます（参考：OpenCLMとは？ChatGPT/Claude時代のCLM選定基準、すでにAIを使う法務がCLMに求める3条件）。プレイブックを手元で育て、案件データは1箇所に集める——「AIは選び、契約は1箇所に集める」の考え方は、プレイブック運用にもそのまま当てはまります。
本記事はContractS株式会社のコンテンツマーケティングチームが、エンタープライズ企業の法務・調達・管理部門向けに執筆したものです。プレイブックの設計・条項の判断基準にあたっては、必ず自社の業務特性・リスク許容度に応じて検討してください。本記事はリーガルアドバイスではありません。
