「つなげば動く」ではなかった、の先へ

生成AIに契約書レビューを任せる取り組みは、「チャットで質問する」段階から「業務を丸ごと渡す」段階へ移りつつあります。業務を渡すために揃えるべき要素が、作業環境としての場、自社のやり方を書いた手順書（Skill）、社内システムへの接続（MCP）の3点セットであることは、AIに契約業務を”任せ切る”3条件｜場（Cowork）×レシピ（Skill）×道具（MCP）で整理しました。

ただ、3点セットを「つなげば動く」わけではありません。接続はできても、業務として使える精度で回すには設計とチューニングが要ります。そしてシステム連携（MCP）の実装をプロに任せるとしても、残る問いがあります。Skillの中身、つまり自社の判断基準を書いた手順書そのものは、誰がどう作るのか。

本記事では、業務委託契約のレビューを例に、AIスキルの「中身」を解剖します。読み終えたときに、「どこまで自社で書けて、どこから専門実装が要るのか」を自分の組織に当てはめて見極められる状態になることを目指します。

まず完成形から：業務委託レビューはここまで自律で回る

先に到達点を示します。人間の入力は「この業務委託契約、レビューしてください」の一言だけ。そこからAIは次の流れを自走します。

1. 取得：契約管理システム（CLM）からレビュータスクと契約書ファイルを取得する
2. 探索：同じ取引先との過去契約・関連契約を自分で探して読む
3. 事前判定：請負か準委任か、下請法の適用があるかを判定する
4. 突合：条項を分解し、自社のレビュー基準と照合する
5. 書き戻し：指摘と修正案をコメント付きの新版としてCLMに書き戻す
6. 次工程へ：承認フローに受け渡す

この自走の価値は、4点に整理できます。第一に横断。メール・CLM・法令・過去契約をまたいで、AIが自分で情報を集めます。第二に判断。契約類型や下請法該当性を自動で仕分け、適用する基準を出し分けます。第三に根拠。すべての指摘に「どの基準・どの参照に基づくか」が付き、ブラックボックスになりません。第四に完了。レビュー文を出して終わりではなく、CLMに書き戻して次工程へ渡すところまで到達します。

たとえば「原則再委託禁止」の契約書に「再委託可」の条項があったとき、単体のAIなら一律に「要修正」と指摘して終わるところを、例外対応の履歴まで参照して「この取引先は許容対象か」を確認しにいく。ベテランの判断とAIの判断がどこで分かれるかは、業務委託の「再委託可」は要修正か許容かで1件の契約を通しで追いながら検証しています。

この自走は魔法ではなく、3つの構造の掛け算です。①何をどう判断するかを書いた判断知（.md）、②AIに次に何を読ませるかを設計した参照ツリー、③社内システムから取得し書き戻すシステム連携。以下、順に開いていきます。

構造①判断知＝.md：ここは法務担当者が書ける領域

.mdはコードではない

AIスキルの本体は「.md」という拡張子のファイル群です。コードのように見えますが、中身は自社の判断基準を見出しと箇条書きで整理しただけの、誰でも読めるテキストです。

＃ 業務委託契約 レビュー基準
＃＃ 適用範囲
業務委託・準委任・請負
＃＃ 判断基準
再委託：原則 事前書面承諾
知的財産権の帰属：委託者帰属
支払サイト：受領後60日以内
＃＃ 参照
自社雛形／過去判断／下請法

この形式の良さは3つあります。人もAIも読めること（同じ1ファイルを人が編集し、AIが解釈します）。構造化できること（見出しで論点を整理し、過不足を点検しやすくなります）。そして貯まって育つこと（判断の積み重ねを追記し、版で管理できます）。

.mdに書く5つの構成要素

業務委託契約のレビュー基準を.mdにする場合、書く中身は次の5要素に整理できます。

このうち特に重要なのが、条項を見る前の事前判定です。成果物の有無で請負か準委任かを判定すれば、契約不適合責任や検収の基準が変わります。資本金区分で下請法該当性を判定すれば、支払サイトや書面交付の規制が効いてきます。自社が委託者か受託者かで、守るべき条項と妥結ラインは反転します。この事前判定で、以降に適用する基準の枝分かれが決まります。

条項別基準の書き方：OK／NG／要交渉＋理由

そのうえで、条項別にOK／NG／要交渉の基準を持たせます。再委託条項を例にすると、次のような記述イメージです。

ポイントは、判定だけでなく理由を必ず書くことです。理由が書いてあると、AIは基準に明記されていない類似のケースにも判断を応用できます。逆に判定だけの一覧表は、書いてある条項にしか反応できません。あわせて、「迷ったらこの雛形・この過去判断を見る」という参照先を条項単位で紐づけておくと、後述の参照ツリーがそのまま機能します。

これを契約類型の数だけ設計していくことになります。1類型あたりの主要条項が10〜15、類型が10あれば100項目を超える規模感です。この量感が、後半の「組むか任せるか」の議論に効いてきます。何を判断知として言語化すべきかの全体像は、AIに学ばせるべきは契約書ではなく「判断知」で詳しく整理しています。

ここまでは、書ける

強調したいのは、この判断知の言語化は専門技術ではないということです。Excelでレビュー基準のプレイブックを管理している法務部門であれば、その中身を見出しと箇条書きに整理し直す作業に近く、法務の知見をAIが読める形に置き換えるだけです。ここは外注するものではなく、むしろ自社の法務にしか書けない領域と言えます。

ただし、「書ける」ことと「AIに迷わず効かせられる」ことは別の問題です。ここからが設計の話になります。

構造②参照ツリー：書けることと、効かせることは違う

ファイルがファイルを指す連鎖

契約類型が複数あれば、.mdは1枚では済みません。実務で機能する構成は、階層化された「参照ツリー」になります。

まず入口層に、どの契約類型かを振り分ける判定ファイルを置きます。次に型別層として、業務委託・NDA・売買など類型ごとの判断基準ファイルを並べます。その下に参照層として、自社雛形・過去の判断・関連法令など、外から取ってくる情報への参照を置きます。

AIの動きはこうなります。入口の判定ファイルで類型を振り分ける。「業務委託に該当したら業務委託.mdを読め」という誘導に従って型別ファイルへ進む。その基準で条項を評価し、迷う条項があったときだけ参照層へ深掘りに行く。全部を毎回読むのではなく、構造を辿って必要な分だけ集める——この設計が、精度と処理効率の両方を支えます。

ツリー設計の3つの鍵と、その正体

設計の勘所は3つあります。第一に、入口の判定基準を明確にすること。ここが甘いとAIは最初の振り分けで迷子になります。第二に、次に読むファイルを明示的に指すこと。「該当したら○○.mdを読め」と書き切ります。第三に、参照階層を深くしすぎず、ファイルの命名と説明文を揃えることです。

一見「コツ」の話に見えますが、正体はプロンプトエンジニアリングです。自社の判断基準を.mdに書くことは法務の知見の言語化ですが、入口判定の網羅性・分岐の一貫性・命名の整合を設計し、検証し、保守し続けることは、性質の異なるエンジニアリングの仕事です。ここが、自社で組む場合の最初の難所になります。

構造③システム連携：実装のいちばんの難所は「書き戻し」

レビュー1件の裏で動く8ステップ

冒頭の完成形を工程分解すると、AIはレビュー1件の裏で8つのステップを動いています。タスク取得（CLM）、文脈収集（過去・関連契約）、事前判定、条項分解、基準との突合、根拠の付与、迷った場合の参照追加、そして修正案の書き戻し（CLM）です。

このうち判断知（.md）が効くのは中間の判断工程で、前後の両端——取得と書き戻し——が「システム連携」の領域です。外部システムとの接続の仕組み自体は、MCPとは？法務担当者のためのAI外部連携のしくみで解説していますが、実装の重心がどこにあるかはあまり語られていません。

読むのは当たり前、書くのが肝

システム連携と聞くと「契約書をダウンロードして読ませる」ことを想像しがちですが、読む（取得）は比較的容易です。難しいのは**書く（書き戻す）**側です。レビュー結果を、CLMの所定フィールド・版管理・ステータスに沿って書き込み、コメント付きの新版を生成して承認フローへ受け渡す。「レビュー文が出た」で止めず、書き戻して次に流れて、はじめて業務として完了します。.mdの5要素に「出力形式」が入っていたのは、このためです。

難しさは「深さ×広がり」で跳ね上がる

.mdは書けるはずなのに、なぜ全体としては難しくなるのか。複雑性の要因は4つに整理できます。①契約類型と分岐が増えるほど型別の.mdがばらけ、参照の整合が崩れやすくなる（ツリーの複雑性）。②メール・チャット・CLM・法令と、業務に絡むシステムが増えるほど接続の数が増える（システムの多様性）。③接続先ごとに呼び出し・取得・書き戻しの命令を書き分ける必要があり、プロンプトエンジニアリングが増殖する（接続ごとの命令設計）。④条件分岐・例外処理・「この案件は部長へ」といったエスカレーションを織り込むほど、設計と検証が重くなる。

まとめると、難しさは「深さ（取得だけか、書き戻し・ステータス変更まで操作するか）×広がり（何システムを横断するか）」の掛け算で決まります。深く広くなるほど4要因が同時に効き、「書けるはず」だった.mdの構成が破綻しやすくなります。どこか1システムでも欠けると、そこで自走が切れて手作業に分断される——これが「つないだけど、期待通り返ってこない」の正体です。

育て方：完璧を目指さない4ステップ

いきなり完璧なツリーを作る必要はありません。現実的な育て方は4段階です。

Step 1（.md化）：代表的な1つ、たとえば汎用のレビュー基準1シートを.mdに起こします。粒度は粗くて構いません。まず「AIが基準を読みに行く」を体験し、ズレたら直すサイクルに乗せることが目的です。

Step 2（細分化）：業務委託・NDA・売買と型別に分割し、共通部分は共通ファイルに切り出します。分けるほど判定は正確になりますが、細かすぎると管理コストが増えるため、バランスを見ながら進めます。

Step 3（育てる）：新しい妥結ラインや例外を.mdに追記し、版管理します。判断履歴が契約の実体に紐づいて蓄積されると、使うほど自社仕様に賢くなっていきます。

Step 4（全工程へ）：レビューという「点」から、受付・起案・承認・棚卸し・法改正対応という「面」へ広げます。ただしここまで来ると、より多くのシステム連携・書き戻し・全社運用が必然になります。Step 1〜2は自社でできる領域、Step 3〜4はシステム連携と器の実装が要る領域、というのがおおまかな線引きです。

分かれ道：自社で組むか、プロに任せるか

完成形は、①判断知＋②参照ツリー＋③システム連携の全部で動いていました。①は自社の財産であり、自社で書くべきものです。問いは、②③を自社で組んで保守し続けるか、プロに預けるかです。判断の軸は2つあります。

軸1：組める人がいるか。 参照ツリー設計（プロンプトエンジニアリング）、複数システム連携、条件分岐、書き戻し設計を、構築するだけでなく保守し続けられる人材がいるか。いれば小さなPoCから自作する選択肢は十分あります。兼務で回らない場合は、無理に自作しない方が結果的に速いと考えられます。

軸2：自社の契約は複雑か。 連携するシステムが多い、契約類型が多く型別ファイルが増殖する、例外・特約が多い、複数人運用でエスカレーション設計が要る——複雑側に当てはまるほど、技術的難易度は高くなります。エンジニアでも構築が難しい領域であり、過小評価は禁物です。加えて、担当者個人のスキルに依存した構成は、その人の異動・退職で崩壊しやすいという運用リスクも抱えます。

また、統制の観点も見落とせません。個人のPCで.mdを運用する形は、記録も承認もない統制外の判断が業務に混入する構図になり得ます。契約は債権債務の発生源として財務に直結するため、記録・承認・権限分離が組み込まれた器の中でAIを動かす設計が標準解になります。さらに、判断の精度は参照するデータの質で決まるため、契約書・過去判断・案件経緯が1箇所に集約されていること自体が、.mdを「育て続ける」ための前提条件になります。この「AIは選び、契約は1箇所に集める」という設計思想と、それを支えるオープン型CLMの考え方は、ベンダーロックインを避ける法務のAI活用の考え方｜Open CLMという新常識で詳しく解説しています。ContractS CLMは、こうした構成で判断知の器とシステム連携をあわせて提供する実装の一つです。

どちらを選んでも正解です。重要なのは、自社の現在地——組める人の有無と契約の複雑性——を客観的に見て選ぶことです。

まとめ

契約書レビューをAIが自律で回す構成は、①自社の判断基準を書いた判断知（.md）、②AIに必要な分だけ読ませる参照ツリー、③社内システムから取得・書き戻しを行うシステム連携、の3つの構造で成立しています。

このうち判断知の言語化は、法務担当者自身が今日から始められる領域です。まず代表的なレビュー基準を1枚の.mdに起こし、小さく回して育てていく。一方で、参照ツリーの設計とシステム連携の実装——特に書き戻しと複数システム横断——は専門実装の領域であり、自社で持つか、プロに預けるかの見極めが必要になります。

「教える（.mdを書く）」は自社の領域、「読ませる（ツリー設計）」と「つなぐ（システム連携）」は実装の領域、そして「育てる」は判断履歴が蓄積される器があってはじめて回り続けます。自社の判断知という資産を活かすためにも、まず1枚の.md化から始めつつ、実装と器をどう用意するかを併せて検討してみてください。

本記事はContractS株式会社のコンテンツマーケティングチームが、エンタープライズ企業の法務・経営・管理部門向けに執筆したものです。AIを契約業務に組み込む際の判断は、必ず自社の業務特性・リスク許容度に応じて行ってください。本記事はリーガルアドバイスではありません。

ContractS編集部

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

私たちについて