ノウハウ 契約レビューの「例外台帳」の作り方と運用｜過去の譲歩をAIが引ける資産に変える
投稿日:2026年06月8日
契約レビューの「例外台帳」の作り方と運用｜過去の譲歩をAIが引ける資産に変える
「原則」だけではレビューは回らない
リーガルプレイブックを整え、AIが「うちのあるべき姿」でレビューできるようになったとしても、実務はそれだけでは回りません。なぜなら、現実の契約は**「原則を外した例外」の連続**だからです。
「この戦略顧客には損害賠償の上限を譲歩した」「この事業部は再委託を厳しく見る方針」「この類型の取引だけは検収期間を伸ばしている」——こうした例外は、どこにも明文化されず、ベテラン担当者の頭の中にのみあります。その人が休めば止まり、転職すれば消えます。
これを引ける形で残すのが、例外台帳です。プレイブックが「原則」を持つのに対し、例外台帳は「原則を外した記録」を持ちます。この二つが揃って初めて、AIは「原則ではこうだが、この取引先には過去にこう譲歩している」までを踏まえてレビューできるようになります。
（例外台帳を含む「判断知」全体の設計は別記事「AIに学ばせるべきは契約書ではなく『判断知』」で、プレイブック本体の作り方は「リーガルプレイブックの作り方」で整理しています。）
例外台帳に何を記録するか
例外台帳は、重いドキュメントにすると誰も書かなくなります。1件あたり3～5行で済む「軽さ」を保つのが絶対条件です。記録すべきは次の6項目です。
| 項目 | 中身 | AI・人がこれをどう使うか |
|---|---|---|
| 案件ID | CLMの案件と紐づけるキー | レビュー時に同一相手・同一類型の例外を引く |
| 逸脱箇所 | プレイブックのどの条項を、どう外したか | AIが「原則×例外」の差を提示できる |
| 承認者 | 誰の権限で例外を認めたか | 同レベルの判断か、上申が必要かを判定 |
| 理由 | なぜ例外を認めたか（関係性・競合・戦略） | 類似状況で同じ判断が使えるかを見極める |
| 扱いの範囲 | 本案件限りか、今後も適用か | 「本案件限り」ならプレイブックは変えない |
| 期限（任意） | いつまで有効な例外か | 期限切れの例外をレビューから外す |
実際の1件は、次のようなテキストで十分です。
# 例外メモ 2026-0042
- 案件: SAL-2026-0834（A社向け業務委託）
- 逸脱箇所: 損害賠償上限 取引額の50% → 200%
- 承認者: 法務部長
- 理由: 戦略顧客につき関係性維持を優先。経営判断あり
- 扱い: 本案件限り（プレイブック改訂はしない）
コツ1：「承認の前提条件」にする
例外台帳が機能しない最大の原因は、「例外を記録する」が任意のタスクになっていることです。忙しいレビュアーは、「あとで書く」のまま忘れます。
解決策はシンプルです。例外の承認フローに、例外メモを組み込む。つまり「例外メモを書かないと承認に進めない」ルールにします。こうすれば、「記録をお願いします」と促す必要がなくなり、例外の発生と記録が同じタイミングで起きます。
ポイントは、承認者自身が書くのではなく、上申するレビュアーが書くことです。「この件、例外として承認をお願いします」と上申する際に、逸脱箇所・理由・扱いの範囲をそのまま書く。記録が、上申の副産物になります。
コツ2：案件IDでCLMの案件に紐づける
例外台帳を独立したExcelで持つと、「あの取引先の例外はどこに書いたっけ」を探すことになり、結局参照されなくなります。重要なのは、例外メモを案件IDでCLMの案件に紐づけることです。
この紐づけによって、二つの方向から辿れるようになります。
- レビュー時（込み込み）：AIが案件IDや取引先をキーに「同一相手・同一類型の過去の例外」を引き、「前回はこう譲歩しています」と提示する
- 振り返り時：人間がCLMの案件画面から、その案件でどんな例外判断がされたかにそのまま辿れる
これが、例外台帳を「文脈」として生かす鍵です。データを物理的に1ファイルに集めなくても、「案件IDから辿れる状態」さえ作れば、例外は判断のたびに生きてきます。
コツ3：四半期でプレイブックに還元する
例外台帳の本当の価値は、例外を記録することそのものではなく、例外からプレイブックを進化させることにあります。
同じ逸脱が何度も繰り返されるなら、それはもはや「例外」ではなく、プレイブックの「許容範囲」が狭すぎるシグナルです。例えば「損害賠償上限を200%まで認めた」例外が四半期で5件出たなら、プレイブックの許容範囲を100～200%に広げることを検討する、という具合です。
そこで、四半期に1度、次の順で還元レビューを行います。
| 例外の出方 | 意味 | プレイブックへの反映 |
|---|---|---|
| 同じ逸脱が複数回 | 許容範囲が現実より狭い | ◎許容範囲を見直し、ベース／差分に反映 |
| 特定取引先・事業部だけで多発 | その取引先固有の事情 | プレイブックは変えず、例外台帳に残して込み込みで参照 |
| 1件だけの例外 | イレギュラーな経営判断など | 「本案件限り」のまま、プレイブックは動かさない |
この「例外→選別→プレイブック還元」のループが、生成AIを介した「込み込みレビュー」の改善サイクルそのものです。この改善ループ自体をAIに自動化させるようにしましょう。
例外台帳をAIに「読ませる」ときの注意点
例外台帳を生成AIに読ませるときは、2つだけ注意があります。
第一に、例外を「新しい原則」として扱わせないこと。AIにそのまま渡すと、「過去に200%を認めているのだから、これもOK」と拡張解釈しかねません。「これは例外であり、原則はプレイブック側である」と明示し、例外は「参考情報」として渡します。
第二に、「扱いの範囲」を必ず一緒に渡すこと。「本案件限り」の例外を、他案件のレビューで一般化して適用されては困ります。コツ1で記録した「扱いの範囲」が、ここで効いてきます。
この二点は、AIと人の境界設計（自動判定／要確認／人判断）のうち、例外該当は「人判断」に振るという原則とも一致します。例外は、最終的には人が判断する領域に残します。
まとめ：例外台帳は「育てる」ための装置
例外台帳は、プレイブックと対をなす「判断知の器」です。プレイブックが原則を、例外台帳が「原則を外した記録」を持ち、両者が揃って初めて、AIは「うちの基準で、この取引について」レビューできるようになります。
設計のコツは3つでした。承認の前提条件にして書く動機を作る、案件IDでCLMの案件に紐づけて辿れるようにする、四半期でプレイブックに還元して進化させる。いずれも「軽く記録し、文脈として辿り、原則に還す」ための仕掛けです。
この「例外を案件に紐づけて残し、レビュー時に生成AIが込み込みで引く」設計は、契約データの正本をCLMに一元化し、AIは自社で選ぶというオープン型CLMの考え方と相性が良いものです（参考：OpenCLMとは？ChatGPT/Claude時代のCLM選定基準）。例外という「生きた判断の記録」を案件に集め、レビューには日常のAIを使う——「AIは選び、契約は1箇所に集める」は、例外管理にもそのまま当てはまります。
本記事はContractS株式会社のコンテンツマーケティングチームが、エンタープライズ企業の法務・調達・管理部門向けに執筆したものです。例外管理・承認フローの設計にあたっては、必ず自社の業務特性・リスク許容度に応じて検討してください。本記事はリーガルアドバイスではありません。
