「AIレビュー」は入れた。でも“任せ切れて”いない

多くの法務部門が、すでに何らかの形でAIを契約業務に取り入れています。契約書を貼り付ければ論点を洗い出し、不利な条項を指摘し、修正案のたたき台まで返してくれる。たしかに便利になりました。それでも、現場にはこんな引っかかりが残りやすいのではないでしょうか。「そこそこ効率化はできた。でも、期待したほど“任せられて”はいない」。

その理由の一つは、いわゆるAIレビューが担っているのが、業務全体のごく一部だという点にあります。一件のレビューを分解すると、依頼確認 → 関連文書・過去契約の参照 → 経緯の確認 → レビュー処理 → 例外判定 → Wordへのコメント → 新版の作成 → 返信文の作成、という工程の連なりになります。世の中の「AIレビュー」の多くが引き受けているのは、このうち“レビュー処理”という1工程で、その前後は相変わらず人が手で繋いでいることが少なくありません。本当に効かせたいのは、依頼受領から返信・承認までの“全部”のはずです。

なぜ1工程で止まってしまうのか。その原因はAIの性能ではなく、AIが乗っている“土台”の側にある——この論点はAIを入れても契約業務が変わらないのはなぜかで詳しく整理しています。本記事が扱うのはその先です。業務を“まるごと”AIに渡すには、具体的に何を用意すればよいのでしょうか。その答えは、3つの条件に整理できます。

点のAI化から、業務まるごとの「自律実行」へ

「特定業務のAI化」から「業務横断の自律実行」へ。この転換は、法務に限った話ではありません。営業などの領域では、すでに具体的な形をとりはじめています。

わかりやすいのは営業の例です。営業担当がAIに「昨日打ち合わせしたお客様に、提案書を送っておいて」と一言頼みます。するとAIは、まずSalesforceを参照して過去の対応履歴や顧客情報を調べ、議事録を探して打ち合わせの内容を取得し、提案書作成のスキルを起動して資料を生成し、メールに添付して“送信直前の下書き”まで用意します。人間が出したのは、最初の一言だけです。この流れの中で、Salesforceは「開いて中心で使う」ものではなく、AIから「呼び出されて使われる」部品になっています。

ここでは、システムと人の関係が入れ替わっています。従来は、人がシステムに入り、そこを起点に仕事をしていました（Before）。これに対して、AIが業務を進め、必要なときにシステムを呼び出す形（After）では、“システムを使うこと”はゴールではなくなります。“最適な提案を作って送る”というゴールのために、システムが裏で呼ばれるだけです。

言い換えれば、これまで「システムを開いて、そこで作業する」ことが仕事の起点だったのに対し、これからは「業務のゴールをAIに伝え、AIが必要なシステムを裏で呼ぶ」ことが起点になります。担当者が触れるのは入口（一言の指示）と出口（最終判断）で、間の“どのシステムをどう使うか”はAIが引き受けます。

同じことが、法務でも起きうると考えられます。「CLMを使うこと」がゴールではなく、「レビュー業務をやり切ること」がゴールです。レビューの流れの中で、CLM・メール・法令検索・プレイブックが、AIから呼び出される。これが目指す姿です。では、そこに到達するために、具体的に何を揃えればよいのでしょうか。

「まるごと渡す」に揃える3つの条件

業務をまるごとAIに渡すために必要なものは、料理にたとえると整理しやすくなります。AIを「注文に応えて一皿を仕上げるシェフ」に見立てると、シェフに任せ切るために揃えるものは、次の3つに集約できます。

契約書などのインプット（＝食材）をAIに扱わせるには、この①②③がそろっている必要があります。逆に言えば、どれか1つが欠けると、AIは“点”の作業に戻ってしまいやすくなります。以下、順に見ていきます。

条件①：場＝Cowork——どこで動かすか

まず考えたいのは、業務を“どこで”動かすか、です。チャットで質問して答えをもらうだけの使い方では、業務を渡し切ることは難しいでしょう。カウンター越しに一皿ずつ相談しているようなもので、会話が終わればそこで終わってしまうからです。

自律実行が動く“場”にあたるのが、Claudeでいえばデスクトップアプリの「Cowork」です。Web版やモバイルアプリは日常利用の入口で、腰を据えて業務をまるごと任せる舞台はデスクトップになります（同様の形態は、ChatGPTのCodex、CopilotのCopilot Coworkなど、他の汎用AIでも登場しています）。

大事なのは、チャットとCoworkは見た目が似ていても、目的そのものが違うという点です。チャットは、AIと自分の1対1のやり取りが全体で、質問して答えをもらう会話の範囲で完結します。品質はモデルの進化に依存し、自分の手で作り込む余地は小さいといえます。一方Coworkは、AIが自律的に業務を進めるための、設計と構築の仕組みです。複雑な指示や高度な条件分岐に状況へ応じて対応させ、その精度をPDCAで引き上げていけます。

この「作り込める」という性質は、法務のように基準が組織ごとに異なる業務で効いてきます。最初は精度が物足りなくても、「この観点が抜けていた」「この例外は毎回拾ってほしい」といった気づきを手順に反映し、少しずつ自組織の判断へ寄せていけます。会話の質がモデル任せになるチャットと違い、Coworkでは運用しながら育てられます。この“場”がなければ、次に述べるレシピも道具も十分には活きません。まず「業務を渡して自律実行させる舞台」を用意すること。これが条件①です。

条件②：レシピ＝Skill——やり方をどう渡すか

場ができたら、次は“何を”渡すかです。やり方＝手順書にあたります。

自律実行させる“やり方”の最小単位が、「.md」ファイル（AIのための業務手順書）です。チャットのように毎回口頭で指示するのではなく、手順をあらかじめ手順書として渡しておきます。玉ねぎの切り方やレンジの加熱時間といった工程ごとの詳細が「.md」に書かれ、その全体がレシピになる、というイメージです。

この「.md」を束ねたものが「Skill」です。Skillとは、業務を任せるときに「どう処理するか」を書いた“判断の手順書”であり、単発の作業指示ではなく、長期にわたって自律実行させるためのものです。しかも自分専用ではなく他の人と共有できるので、担当者の頭の中にあった判断が“チーム共通の作法”になります。属人化の解消にもつながる要素です。

1つのSkillには、工程の手順、判断基準の適用、場合分け・条件分岐、例外処理、エスカレーションといった要素を織り込めます。だから「この条項ならこの基準で見る」「これはエスカレーション基準に合致するので、この文面で法務部長へ上げる」といった、本来は人が都度おこなっていた処理分けを、Skillに寄せられます。分岐の多い実務でも、AIが迷いにくくなります。

たとえば秘密保持契約のレビューを考えてみます。「損害賠償の上限規定がなければ、上限条項の追加を提案する」「反社条項が自社ひな形の水準を満たしていれば通過、満たしていなければ差し戻す」「契約期間が5年を超える場合は、担当者判断ではなく法務部長のエスカレーション対象にする」——こうした“うちのルール”は、担当者の頭の中では自然に回っています。ですが、口頭指示のたびに再現するのは簡単ではありません。これをSkillに書き出しておけば、同じ判断を毎回同じ精度で走らせやすくなります。人によって判断がブレるという属人化の悩みにも効いてきます。

ここで肝になるのが、“完了”をどこまで定義するか、です。レシピを「レビュー文が出たら終わり」にしてしまうと、その後は人手に戻ってしまいます。依頼受領 → レビュー処理 → 返信 → 上司の承認、のどこを“完了”と定義してレシピに落とし込むかが、自律実行の成否を分けます。業務として本当に終わる地点まで、レシピに含められるかどうかがポイントです。

そしてもう一つ大切なのは、AIに渡して育てるべきは契約書そのものではなく、「なぜそう判断するのか」という“判断知”だという点です。どの基準で、どんな例外を、どんな理由で認めてきたか。この判断知の設計と置き場についてはAIに学ばせるべきは契約書ではなく「判断知」で詳しく整理しています。レシピ＝Skillの完成度が、そのままアウトプットの品質を左右します。

条件③：道具＝MCP／コネクタ横断——システムをまたいで動かす

最後の条件が、システムをまたいで動くための“道具”です。

レビューは、AIレビュー単体では完結しません。依頼の連絡はメール、基準はプレイブックや過去契約、根拠は法令、正本はCLM——というように、必要な情報も作業も、複数のシステムの“外と中”を行き来します。これらをまるごと自動化するには、必要なシステムをAIが“呼び出して使える”状態にしておく必要があります。その標準規格がMCP（Model Context Protocol）で、この規格で実際につないだ設備がコネクタ（CLM・メール・法令検索…）です。MCPそのもののしくみと法務での3用途はMCPとは？法務担当者のためのAI外部連携のしくみで詳しく解説しています。ここでは“3条件の一つ”としての位置づけに絞ります。

道具について押さえておきたいのは、“ある”だけでは足りない、という点です。重要なのは、MCP経由でどこまで操作できるか——APIのカバー率です。たとえば契約書のダウンロードには対応していても、更新版の書き戻し（アップロード）に対応していなければ、そこだけ手作業に戻ってしまいます。カバー率が狭いと、結局あちこちに手作業が残ります。

さらに壁になりやすいのが、システム横断です。依頼確認（メール）→ 過去契約（CLM）→ 法令（検索）→ 書き戻し（CLM）という流れのどこか1つでもコネクタが欠けると、そこで手作業に分断されます。たとえば、メールとCLMはつながっていても法令検索がつながっていなければ、根拠条文の確認だけは人が別窓で調べて貼り直すことになります。逆に、CLMには書き戻せてもメールの依頼を取り込めなければ、入口で人が案件を起票する手間が残ります。1カ所の断絶が、その前後の自動化まで道連れにしてしまうわけです。つまり道具の“質”は、深さ（カバー率）と広がり（横断）の両方で決まります。逆に、CLMという1つの製品が十分にMCP対応していれば、契約業務が散らばりにくく、AIに任せやすくなります。

なお、MCPサーバーは自前で作らないほうが現実的です。作れないわけではありませんが、自社で開発・運用し続けるのは、エンジニアでも限られた人にしかできません。ベンダーが提供するMCPを利用する——「自社でつなぐ」より「対応済みの製品を選ぶ」ほうが、多くの場合は近道になります。

3条件がそろうと：材料を置くだけで完走する

①場（Cowork）＋②レシピ（Skill）＋③道具（MCP・コネクタ横断）がそろった状態では、シェフ（AI）は材料（契約書）を置くだけで、依頼受領〜レビュー〜返信〜完了までを自走できます。

具体的には、CLMからレビュー待ちのタスクを取得し、対象の契約書を読み込み、社内プレイブックという基準に照らして論点を洗い出し、必要なら法令検索で根拠を補強し、修正案とコメントを生成して、結果をCLMに書き戻す。ここまでを一連の流れで進めます。人間は、高リスクの最終判断と、方針・例外の意思決定に集中します。AIに“作業”を寄せ、人は“判断”に集中する、という分担です。この「作業」と「判断」の線引きをどこに引くかが、そのまま運用設計の要になります。

3条件が欠けた状態と、そろった状態では、同じレビュー業務でも進み方が変わります。工程ごとに並べると、その差がはっきりします。

一番負担が大きいのは、レビューそのものよりも工程の“継ぎ目”を人が埋め続けることだといえます。3条件がそろうと、その継ぎ目がAIに寄っていきます。ここに“点”と“面”の差がはっきり出ます。

AI起点時代の「システム選定」への含意

この3条件を実務で満たそうとすると、使うシステムに求める要件が自然に見えてきます。AIが主役でシステムを呼び出す前提で選ぶなら、基準は次の3つに整理できます。第一に、ヘッドレスに呼び出せること（＝APIが十分に供給されていること）。第二に、MCPサーバーでコネクタとして機能すること（＝AIからそのシステムを操作できること）。第三に、そのAPIのカバー率が広いこと（＝業務の端から端まで操作できること）。これはCLMに限らず、メールやチャットなど、業務で使うシステム全般に当てはまる観点です。

もっとも、MCPは「つなげば動く」ものではありません。とくに法令検索の精度確保には設計とチューニングが必要で、法務が自社だけで構築・運用し続けるのは、現実的にはハードルが高い領域です。無理に内製を目指すより、設計済みの連携や外部の構築支援を活用するほうが、実用レベルに届きやすいと考えられます。そしてもう一つ——AIを既存製品に埋め込む“内蔵型”を選ぶか、外部の生成AIを土台ごと連携させる“連携型（オープン型）”を選ぶかで、この3条件の満たしやすさは大きく変わります。両者の違いはAI内蔵型CLM と AI連携型（Open）CLM の比較で整理しています。

まとめ：足りないのは“賢さ”ではなく“渡し方”

AIに業務を任せ切れない理由は、多くの場合、AIの賢さが足りないことではありません。業務を渡すための条件——①場（Cowork）②レシピ（Skill）③道具（MCP・コネクタ横断）——がそろっていないことにあります。この3点セットがそろえば、AIは1工程だけをこなす“点”から、依頼受領から返信・完了までを走り切る“面”の自律実行へ近づきます。より賢いAIを探す前に、まず“渡し方”を揃える。そこが出発点になります。

AIは選び、契約は1箇所に集める

最後に、3条件のうち最も難所になりやすい③（道具＝システム横断）を無理なく満たすための、方向性を一つ挙げておきます。契約業務が複数のシステムに散らばっているほど、横断の壁は高くなります。だからこそ、契約データという正本は1箇所（CLM）に集約しておき、AIはMCP経由でそこを参照・更新する——この役割分担が扱いやすいと考えられます。AIは進化が速いので、その時々で最適なものへ選び替えられるようにしておき、契約という資産は一箇所で守る。「AIは選び、契約は1箇所に集める」という考え方です。

これを土台のレベルで成立させるのが、AIを外部から柔軟に呼び出せるオープン型CLMであり、その実装の一つがContractS CLMです。3条件を揃える出発点は、より賢いシェフ（AI）を探すことではなく、シェフが働ける厨房・レシピ・道具を整えること——そして、契約という食材を一箇所に集めておくことにあります。

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

ContractS編集部

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

私たちについて