「とりあえず一枚」のプレイブックが破綻する理由

契約レビューにAIを使う際、「この条項は自社としてOKかNGか」をAIに判断させるには、自社の判断基準を文書化して渡す必要があります。この「判断基準の文書」がリーガルプレイブックです。

多くの法務部門がプレイブック作りでつまずくのは、中身の質よりも持ち方の設計に原因があります。よくあるのが、「業務委託契約プレイブック.docx」のようなファイルに、あらゆる論点・あらゆる例外・あらゆる注釈を一枚に詰め込むやり方です。最初は動きますが、次のように崩れていきます。

• 受託側と委託側の両方を一枚に書いた結果、「どっちの立場の記述か」が混乱する
• 開発、コンサル、BPOと部署が増えるたびに例外記述が增殖し、どれが原則でどれが例外か見えなくなる
• 法改正や方針変更のたびに全体を読み返して修正箇所を探すはめになる
• 結果、誰も更新したがらず、作者の頭の中だけが最新状態になる（＝属人化）

つまりプレイブックの問題は「何を書くか」だけではなく、「どう分けて、どう重ねて持つか」で決まります。本記事では、破綻しないプレイブックを「ベース×差分」の発想で設計する3ステップを、業務委託契約を例に具体化します。

なお、「そもそもなぜAIに学ばせるべきは契約書ではなく判断知なのか」という上位の考え方（4つの器・3つの置き場）は、本シリーズのピラー記事で整理しています。本記事はその「4つの器」の筆頭、プレイブックを深掘りしたものです。

ステップ1：ファイルを「類型×立場」で分ける

最初の分岐は、「どの単位でファイルを分けるか」です。結論から言うと、契約類型×自社の立場で分けます。

よくある誤りは、「業務委託」という類型だけで1ファイルにすることです。しかし同じ業務委託でも、自社が委託する側か受託する側かで、とるべき姿勢が正反対になる論点があります。

このように、同じ条項でも立場で「あるべき姿」が反転します。だからこそ、ファイルは「類型×立場」で分けるのが原則です。最低限、主要類型ごとに「発注用」「受注用」の2ファイルを持つところから始めます。

ただし、ここで「類型×立場の数だけファイルを作る」と、今度はファイル数が爆発します。それを防ぐのが、次のステップ2です。

ステップ2：「共通ベース＋差分」で持つ

類型×立場で分けたファイルを、それぞれ独立に書き下すと、同じような記述が何枚にもコピーされ、一つの法改正で全部を直す羽目になります。そこで、プログラミングの「継承」に似た発想で、共通ベース＋差分で持ちます。

• 共通ベース：複数類型で共通する条項（反社、準拠法・管轄、秘密保持の基本、一般條項など）を一ヶ所にまとめる
• 類型ベース：「業務委託×受託」のような、類型×立場の標準セット
• 差分：「開発委託」「コンサル」のような個別の上乗せ。ベースと違う条項だけを上書きする

イメージとしては、次のようなファイル構成になります。

_common/
  一般條項.md          （全類型共通：反社・準拠法・完全合意など）
  秘密保持_基本.md
業務委託/
  業務委託_受託.md      （類型ベース：類型×立場）
  業務委託_発注.md
  + 開発委託_受託.md   （差分：知財・再委託の2条項だけ上書き）
  + コンサル_受託.md     （差分：準委任前提の文言だけ上書き）

この持ち方の効果は、更新コストが線形にしか増えないことです。一般條項の反社条項を更新したいときは_common/一般條項.mdを一ヶ所直すだけ、新しい部署（例：BPO委託）が増えても「ベースと違う条項」だけを差分ファイルに書けば済みます。

生成AIに渡すときは、「共通ベース＋類型ベース＋該当する差分」を連結して渡します。これで、AIには「この案件に適用される基準の全体」が一括で渡ります。類型・立場ごとのレビュー手順そのものは、生成AIで「業務委託契約」をレビューする手順とプロンプト集もあわせて参照してください。

ステップ3：「条項×観点」を1行にして★/◎/NGで振る

ファイルの分け方と持ち方が決まったら、最後に「1行に何を書くか」です。ここが、AIが引けるプレイブックになるか、人間しか読めない文章になるかの分かれ目です。

Excelに混在しがちな「規定例・コメント・過去の経緯」を、AIが引ける1行に正規化します。フォーマットは「条項 × 観点」で、各条項を★必須／◎推奨／NGの3区分に振ります。

# 損害賠償条項（業務委託_受託）
## ★必須   賠償上限を設ける（委託料総額を上限の目安）
## ★必須   間接損害・逸失利益を除外する
## ◎推奨   故意・重過失の除外事由は受け入れ可
## NG      賠償額無制限（上限なしは原則拒否）

この書き方には3つの効果があります。第一に、AIがそのまま判定に使えること。「★必須」の条項が契約書になければ「不足」、「NG」の記述があれば「要修正」と、AIが機械的に拾えます。第二に、レビュー人間のブレが減ること。★◎NGの基準が明示されていれば、誰がレビューしても判断がぶれません。第三に、例外との境界が明確になること。「NGなのに受け入れた」ケースが、そのまま例外台帳（本シリーズの別記事で扱います）に記録すべき候補になります。

この3区分（★必須＝自動判定、◎推奨＝要確認、NG＝人判断）は、そのままレビュー時の「AIと人の役割分担」にもつながります。

よくある質問：どこまで細かく書くか

プレイブック設計で迷うのが「粒度」です。結論は、類型の複雑さに応じて変えるのが現実的です。

「すべてをプレイブック化する」必要はありません。頪度が高く、担当者の経験差が出やすい類型から着手するのが効果的です。

プレイブックを「生きた資産」に保つために

プレイブックは作って終わりではなく、運用で育てるものです。保つためのポイントは3つあります。

第一に、テキスト形式で持つこと。WordやPDFよりも、Markdownなどのテキストファイルのほうが、差分管理も生成AIへの受け渡しもスムーズです。「書く手間が小さい」ことが、更新され続ける生命線になります。

第二に、例外をプレイブック本体に書き込まないこと。「あの取引先には例外的に許容した」という個別事情をプレイブック本体に混ぜると、「原則」がにじんでいきます。例外は例外台帳に分けて持ち、プレイブックは「原則」だけに保ちます。

第三に、改訂のトリガーを決めておくこと。法改正・レビューでの新しい気づき・上級担当者の指摘など、「どんなときプレイブックを見直すか」を決めておくと、「作ったきり」を防げます。

こうして育てたプレイブックは、どこに置くのがよいか。特定のAIツールの中だけに入れてしまうと、そのAIを乗り換えたときに資産が死にます。プレイブック（判断知）は自社の手元に置き、契約データの正本はCLMに一元化して、レビュー時に両者を生成AIが突合させる——という設計が現実的です。この「AIは選べ、プロンプト資産は自社に残る」という考え方は、すでにAIを使う法務がCLMに求める3条件や、その前提となるOpenCLMとは？ChatGPT/Claude時代のCLM選定基準でも詳しく解説しています。

まとめ：プレイブックは「ベース×差分」で設計する

リーガルプレイブックは、AIに自社基準でレビューさせるための中核の器です。ただし「とりあえず一枚に詰め込む」設計では必ず破綻します。

破綻しない設計は、3ステップです。

1. ファイルを「類型×立場」で分ける：同じ類型でも発注／受注であるべき姿が反転する
2. 「共通ベース＋差分」で持つ：更新コストを線形に押さえ、新類型は差分だけ足す
3. 「条項×観点」を1行にして★/◎/NGで振る：AIが引け、人のブレが減り、例外との境界が明確になる

この3ステップで設計し、テキストで軽く持ち、例外を分け、改訂トリガーを決める。これでプレイブックは「一度作って放置される文書」から、「運用で育ち、AIが毎回参照する生きた資産」に変わります。

さらに、このプレイブックを、例外台帳・絶対NG集・事例集という他の器と組み合わせ、生成AIとオープン型CLMで「込み込み」レビューする全体像は、一例としてContractS CLMのような連携型CLMで実装できます。「AIは選び、契約は1箇所に集める」——その中でプレイブックは、自社の判断をAIに伝える主要なチャネルになります。

本記事はContractS株式会社のコンテンツマーケティングチームが、エンタープライズ企業の法務・調達・管理部門向けに執筆したものです。プレイブックの具体的な条項設計にあたっては、必ず自社の業務特性・リスク許容度に応じて検討してください。本記事はリーガルアドバイスではありません。

ContractS編集部

ContractSは、契約プロセスの構築や契約管理・案件管理を通じて、契約業務を最適化するシステム「ContractS CLM」を開発・販売しています。大企業から中小企業、スタートアップまで、幅広い企業の契約業務改善を支援してきた実績があり、そのコンサルティング経験を活かして、契約業務に関わる読者が参考にできる情報を発信しています。

私たちについて