例外は「例外」のまま消えていく

契約レビューをしていると、「本来はプレイブック上、この条項は受け入れない。だが、この取引先・この事情なら例外的に許容する」という判断が頻繁に発生します。この例外判断そのものは、ベテラン法務担当者の価値の中核です。

ところが多くの組織で、この例外判断は「その場で処理され、記録されずに消えていきます」。メールのやり取り、口頭の了解、担当者の頭の中——これらは案件が終われば散逸します。そして半年後、同じ取引先との別案件で、「あれ、前回はどうしたんだっけ？」となります。

これが、レビューが属人化する最大の原因です。例外判断は、プレイブック（原則）と同じくらい重要な資産なのに、記録される仕組みがないために蜂の巣のように抹消されてしまうのです。

本記事では、この例外判断を「例外台帳」として残し、生成AIのレビューに生かし、やがてプレイブックに昇格させる運用ループを設計します。なお、例外台帳が「4つの器」のうちの一つであるという上位の考え方は、本シリーズのピラー記事で整理しています。

なぜ例外を残さないと「込み込みレビュー」が成立しないのか

生成AIに自社基準でレビューさせるとき、AIに渡すべき「事実」には、契約書本文だけでなく**「この相手には過去どう対応したか」という履歴**が含まれます。これがないと、AIは毎回「初めての取引先」としてレビューしてしまいます。

例えば、ある取引先に「損害賠償上限を取引額の200%まで許容した」という例外があったとします。これが台帳に残っていれば、次回のレビューでAIは「プレイブック上は50%が上限だが、この相手には過去200%を許容済み」と“込み込み”で判断できます。台帳がなければ、AIは「50%が上限、よって200%は要修正」と誤った指摘をし、担当者が手作業で修正することになります。

つまり例外台帳は、単なる記録保存ではなく、AIに「文脈」を渡すためのデータソースです。これがAI内蔵型のレビュー製品では出せない深さの源泉になります。

例外台帳の3行フォーマット

台帳は重いと書かれなくなります。検索性や項目の网羅性を追いすぎず、3行で済む軽さを最優先にします。最小限、次の要素があれば機能します。

# 例外メモ 2026-0042
- 案件: SAL-2026-0834（A社向け業務委託）
- 逸脱箇所: 損害賠償上限 取引額の50% → 200%
- 承認者: 法務部長
- 理由: 戦略顧客につき関係性維持を優先。経営判断あり
- 扱い: 本案件限り（プレイブック改訂はしない）

このフォーマットの設計意図は明確です。最低限「何を・なぜ・誰が・どう扱うか」があれば、次の人もAIも追えます。特に重要なのが最後の「扱い」です。この例外を「本案件限り」とするのか、「今後の原則」に昇格させるのかを明示することで、後述の「プレイブックへの昇格」判断がしやすくなります。

項目をこれ以上增やしたくなる誘惑はありますが、インプットを重くするほど現場は書かなくなります。「とりあえず3行で残る」ことを、網羅性より優先します。

台帳を「承認の前提条件」に組み込む

3行で軽くしても、「任意で書いてもらう」運用は必ず風化します。人は、忙しいときに「任意の記録」をしません。そこで鍵になるのが、例外メモを「承認の前提条件」に組み込むことです。

つまり、「プレイブックを逸脱した条項を含む契約を締結するには、例外メモの提出を必須とする」というルールにします。こうすれば、「書く動機」を個人の善意に依存せず、ワークフローの中に埋め込めます。

「承認のためには例外メモが要る」状態にすると、例外は「さぼると進まない」ので、自然に台帳が埋まっていきます。

案件IDでCLMに紐づける——「論理集約」の考え方

例外メモをどこに置くか。ここで「すべてCLMの案件画面に手入力する」とすると、重さで現場が書かなくなります。重要なのは、物理的に1ヶ所に集めることではなく、「案件IDから辿れる」ことです（論理集約）。

実務的には、例外メモは手元のテキスト（プレイブックと同じ場所）に軽く書き、案件IDだけをキーにしてCLMの案件と紐づけます。こうすると、次の両方向が成り立ちます。

• レビュー時（込み込み）：AIが案件ID・取引先をキーに、過去の例外メモを引いてレビューに加味する
• 振り返り時：CLMの案件画面から、「なぜこの条項はこうなっているのか」の判断根拠に辿れる

例外の経緯が案件に紐づいて“資産”として残ることで、「あの取引先には前回どうしたか」が、担当者の記憶ではなくデータとして引き継がれます。この「データは一元・AIは自社で選ぶ」という設計は、一例としてContractS CLMのようなオープン型CLMで実装できます（考え方の詳細はOpenCLMとは？ChatGPT/Claude時代のCLM選定基準）。

四半期で棚卸し、プレイブックに昇格させる

例外台帳は、ただたまるだけでは意味がありません。同じ例外が何度も繰り返されるなら、それはもはや「例外」ではなく「新しい原則」だからです。そこで、四半期に一度、台帳を棚卸ししてプレイブックに昇格させるサイクルを回します。

棚卸しの見るポイントはシンプルです。

この棚卸しが、プレイブックを「生きた資産」に保ちます。例外台帳が、プレイブックを補完し、フィードバックし、成長させるエンジンになります。プレイブック本体の設計については、姉妹記事「リーガルプレイブックの作り方」もあわせて参照してください。

運用を回す際の注意点

例外台帳の運用でよくつまずく点が2つあります。

一つは、台帳を「評価の道具」にしないことです。例外を記録させる目的は、担当者の判断を哲めるためではありません。「なぜ例外を認めたのか」を責めるツールにしてしまうと、現場は例外を隠すようになり、台帳は空になります。台帳は「残すことに価値がある」というスタンスで運用します。

もう一つは、高機密案件の台帳アクセスを分けることです。M＆Aや人事関連など、例外の存在自体が機密なケースは、閘覧範囲を狭くした例外台帳を別途持ちます。この閘覧グラデーションの設計は、そのままAIにどこまで渡すかのルールにもつながります。

まとめ：例外を消さずに残し、育てる

例外台帳は、「プレイブックの原則から外れて受け入れたケース」を理由とともに残す器です。これがないと、例外判断は個人の記憶に消え、レビューが属人化します。

設計の要点は4つです。3行フォーマットで軽く書く。「承認の前提条件」に組み込んで「書かないと通らない」状態を作る。案件IDでCLMに紐づけて、生成AIがレビュー時に込み込み参照できるようにする。そして四半期で棚卸しして、反復する例外はプレイブックに昇格させる。

このループが回ると、例外台帳は「過去の言い訳メモ」ではなく、自社基準レビューを上達させる学習データになります。「AIは選び、契約は1箇所に集める」——その中で例外台帳は、判断知を“育てる”ための不可欠な仕組みになります。

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

ContractS編集部

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

私たちについて