契約書レビューをAIで自動化する｜一次レビューを任せる範囲と、法務が判断を持つ線引き

レビュー依頼が法務に滞留する構造

契約書レビューが遅いという話は、たいてい法務の処理速度の問題として語られます。実際に詰まっている箇所は別にあります。

一つは、依頼の受け口が決まっていないことです。メールの添付、チャットの個別メッセージ、口頭での依頼が混ざると、法務側は今いくつの依頼を抱えているかを把握できません。締結期限が書かれていない依頼も届きます。優先順位をつける材料がないので、届いた順か、催促された順に処理することになります。

もう一つは、全件を同じ深さで見ていることです。自社ひな形をそのまま使う契約と、相手方が用意したドラフトを一から読む契約は、必要な労力が桁違いです。それでも受け口が同じなら、同じ列に並びます。

この2つが重なると、依頼者は「出したあといつ返ってくるか分からない」状態に置かれます。すると期限の直前に持ち込む依頼が増え、法務は時間をかけられないまま返答することになります。滞留と精度低下は同じ原因から出てきます。

改善の方向は、法務の人員を増やすことではなく、一次レビューを機械側に寄せて、法務が見る対象を「判断が必要な箇所」に絞ることです。

工程を分けると、どこをAIに渡せるかが決まる

契約書レビューを工程に分解します。

依頼受付 … 契約書ファイル、契約類型、相手方、締結期限、自社の立場（発注側か受注側か）、自社ひな形ベースか相手方ドラフトかを受け取る
前処理 … 契約書を条項単位に分解する。条番号、見出し、別紙、参照関係を構造として持つ
一次レビュー … 自社ひな形との文言差分、自社にとって不利な条項、必要な条項の欠落を洗い出す
指摘の整理 … 重要度順に並べ、根拠となる条文の引用と、修正文案を添える
法務確認 … 各指摘の採否を決める。交渉するか受け入れるかを判断する
返答と交渉 … 依頼者または相手方へ返す
記録 … 何を指摘し、何を採用し、最終的にどうなったかを残す

AIに渡せるのは2から4です。5は人が持ちます。6と7は仕組みで支えます。

工程で見ると、削れるのは「読んで洗い出す時間」と「依頼の内容を確認するための往復」です。判断そのものの時間は減りません。ここを取り違えると、期待していた効果が出ずに終わります。

AIに渡すのは2から4です。5は法務が持ち、6と7は仕組みで支えます。判断の時間は減らず、洗い出しと往復の時間が減ります。

AIに任せてよい指摘と、法務が判断を持つ指摘

指摘には、機械で確定できるものと、判断が必要なものが混ざっています。混ぜたまま扱うと、法務は全件を読み直すことになり、一次レビューを置いた意味が薄れます。

機械側で確定してよいのは、正解が契約書とひな形の中にあるものです。

機械側で確定してよい指摘	正解がある場所
自社ひな形との文言の差分（どこが変わったかの抽出）	ひな形と対象の契約書
必須条項リストにある条項が存在しない	必須条項の一覧
定義した用語が使われていない、定義せずに用語が使われている	契約書の中
条番号の重複や欠番、引用先の条項が存在しない参照	契約書の中
当事者名や日付、金額の空欄、算用数字と漢数字の不一致	契約書の中
有効期間と存続条項のように、条項間で矛盾している記載	契約書の中

これらは指摘として提示し、法務が内容を吟味せずに修正へ回して構いません。

法務が判断を持つのは、契約書の外に判断材料があるものです。

不利かどうかの最終評価。 上限のない賠償条項は一般に不利ですが、取引の規模、相手との関係、他に取引先があるかによって、受け入れる判断もあります。条文の形だけでは決まりません。

法令の解釈が関わる箇所。 委託先との関係で下請法の適用があるか、業務の進め方が指揮命令に当たらないか、個人データの取扱いをどう位置づけるか。法令の当てはめは人が持ちます。

ひな形自体を変えるかどうか。 同じ修正要求が繰り返し来る条項は、ひな形の見直しの候補です。これは会社の方針の変更なので、レビューの流れの中で自動的に決めることではありません。

相手方へ出す文言の確定。 社外に出る文章は人が最終確認します。

運用ルールとして1つ決めておきます。AIが指摘しなかったことを根拠に、その条項が問題ないと判断しない。一次レビューは網羅性を保証しません。締結前の確認項目は、AIの出力とは別に残しておきます。

なお、契約書のレビューを支援するサービスと弁護士法第72条の関係については、法務省が考え方を示しています。社内で使う仕組みを作る場合も、最終的な判断を自社の法務や弁護士が持つ構成にしておくことが前提になります。

自社ひな形との差分をどう出すか

機械側で確定してよい指摘の先頭にあるのが、自社ひな形との差分です。ここの出し方が粗いと、後ろの工程がすべて揺れます。指摘の一覧に表記の統一まで並び、法務が読む量はかえって増えます。

比較の相手は3つに分かれ、必要な処理が違います。

比較の相手	差分の出し方	注意する点
自社ひな形を相手方が修正して返してきた契約	条項の構成と番号が揃っているため、修正された箇所がそのまま論点になる	相手方が使ったひな形の版が古いことがある。版を確認してから比べる
相手方が用意したドラフト	自社ひな形のどの条項に当たるかを対応付けてから、文言を比べる	自社ひな形に無い条項が足されている場合を落としやすい
自社ひな形が無い契約類型	必須条項の一覧と譲れない条件を基準に、条項の有無と内容を見る	基準を先に書いておかないと、差分ではなく感想が返ってくる

差分は文字列ではなく条項の単位で取ります。 文字列どうしの比較では、条項が1つ挿入されただけで以降の条番号がずれ、契約書全体が変わったように見えます。条項へ分解してから対応付ける処理を入り口に置くと、相手方のドラフトでも同じ流れで扱えます。秘密保持契約を例に、この2つの経路をどう分けるかは NDA・秘密保持契約のレビューをAIで自動化するで扱っています。

差分のうち、指摘に上げないものを先に決めます。 当事者の呼称の表記、条番号の繰り上がり、句読点の違いは、差分としては出ますが論点ではありません。落とす条件はひな形の側に書いておき、一次レビューのたびに判断させません。ここを決めずに始めると、最初の数件で指摘の一覧が読まれなくなります。

比較に使ったひな形の版を出力に載せます。 ひな形は改訂されるため、どの版と比べた差分なのかが分からないと、指摘の妥当性を後から確かめられません。記録側にも同じ値を残します。

契約類型ごとに見る観点をどう定義するか

一次レビューの質は、AIの性能よりも観点の定義で決まります。「この契約に問題がないか見て」という指示では、出てくる指摘が毎回変わり、なぜその指摘が出たのかも説明できません。

観点は3層に分けて書きます。

層	中身	書く人
共通の観点	有効期間と更新、解除、賠償の範囲と上限、権利義務の譲渡、秘密保持の残存、存続条項、準拠法と管轄	法務（類型を問わず適用）
契約類型ごとの観点	秘密保持なら定義の広さと返還・破棄、業務委託なら成果物の権利帰属と検査基準と再委託、基本契約なら個別契約との優先関係	法務（類型を先に確定させる）
自社固有の方針	賠償額の上限は必ず設ける、準拠法は日本法とする、自動更新は認める	法務（社内で決めた線）

契約類型を問わない共通の観点。 有効期間と更新の条件、解除できる場合、損害賠償の範囲と上限、権利義務の譲渡、秘密保持義務の残存期間、契約終了後も残る条項の指定、準拠法と管轄。どの類型でも確認する内容です。

契約類型ごとの観点。 秘密情報を受け渡す契約なら、秘密情報の定義の広さ、目的外使用の禁止、終了時の返還または破棄の方法。業務を委託する契約なら、成果物の権利の帰属、検査と合格の基準、再委託の可否、支払条件。継続的な取引の基本契約なら、個別契約との優先関係、最低数量や独占の定め。類型を先に確定させないと、観点の当てはめができません。

自社固有の方針。 賠償額の上限は必ず設ける、準拠法は日本法とする、自動更新は認める、といった社内で決めた線です。ここは法務が書きます。

書き方で注意する点が2つあります。

1つは、判定できる粒度まで下ろすことです。「損害賠償が適切か」では判定できません。「賠償額の上限の定めがあるか」「上限が対価の範囲内か」「間接損害や逸失利益が除外されているか」のように、1観点1判定にします。

もう1つは、自社の立場を入力に取ることです。同じ条文が、発注側には有利で受注側には不利になります。検査の基準が細かく書かれている条項は、その典型です。立場を渡さずに「不利な条項」を探させると、どちらに不利なのかが定まらない指摘が返ってきます。

観点をAIに考えさせる構成にはしません。観点が可変だと、指摘の再現ができず、後から基準を検証できなくなります。

一次レビューの結果をどの形で返すか

同じ指摘でも、返し方によって法務が確認にかける時間は変わります。契約書のどこの話なのかを探し直す形になっていれば、洗い出しで削った時間が確認の側に戻ってきます。

返し方は3つに分かれます。

返し方	向く場面	注意する点
指摘の一覧（条番号・引用・観点・理由）	相手方のドラフトを一から読む契約。論点の全体像を先に把握したい場合	条文を別に開いて突き合わせることになるため、引用は要約せず原文で添える
修正履歴つきの契約書ファイル	自社ひな形を相手方が修正して返してきた契約。差分が起点になる場合	機械が入れた変更と人が入れた変更が混ざる。名義を分けるか、法務の確定前に社外へ出さない
修正文案つきの指摘	同じ修正要求が繰り返し来る条項。ひな形側に代替の文言がある場合	文案は候補として出し、社外へ出す文言は法務が確定させる

一覧は重要度の順に並べます。 条番号の順に並べると、賠償額の上限が無いことと用語の表記ゆれが同じ重さで並びます。上から読んで途中で止めても重い論点は読み終えている、という順序にしておきます。

修正履歴つきのファイルで返す場合は、変更の出どころが分かるようにします。 修正履歴はそのまま相手方とのやり取りに使われるため、機械が入れた変更が誰の判断によるものか分からないまま社外へ出ることがあります。作成者の名義を分けるか、法務が確定させるまで社外へ出さない運用にします。

修正文案は、ひな形にある文言から引きます。 条項ごとに自社で使っている代替の文言があるなら、そこから出す形にすると、文案の妥当性を毎回確かめずに済みます。ひな形に無い箇所を新しく書かせると、文言を一から確認することになり、一次レビューを置いた効果が薄れます。

どの形で返すかは契約類型ごとに1つ決めておきます。案件ごとに変えると、法務は毎回どこを見ればよいかを探すことになり、採否の記録も揃いません。

一次レビューの精度をどう確かめるか

任せる範囲を決める前に、一次レビューが実務に耐えるかを確かめます。ここで「正解率」という一つの数字を作ろうとすると行き詰まります。契約書の指摘に唯一の正解は無く、法務が採るか採らないかで決まるためです。

代わりに、過去にレビュー済みの契約で走らせ、法務が実際に出した指摘と突き合わせます。見るのは次の3つです。

見るもの	数え方	出たときに直す場所
見落とし	法務が指摘したのに、AIが出さなかった件数	観点そのものが無いなら追加する。観点はあるのに出ないなら、判定条件が曖昧なので分解する
過剰な指摘	AIが出したのに、法務が不採用にした件数	自社の方針と合っていないなら方針側を明文化する。条文の読み違いなら観点の書き方を直す
根拠のずれ	指摘に添えた引用が、その指摘の内容と対応していない	観点ではなく前処理を疑う。条項への分解や参照関係の解釈が崩れている

見落としと過剰な指摘は、直す場所が違います。 見落としは観点の不足なので、観点を足せば減ります。過剰な指摘は観点の書き方の問題であることが多く、観点を足すとむしろ増えます。まとめて「精度が低い」と扱うと、観点を足す方向にだけ手が向き、法務が読む量が増えて終わります。

根拠のずれは件数が少なくても優先して直します。引用が対応していない指摘は、内容が合っていても法務が確かめ直すことになり、一次レビューを置いた意味がなくなります。

どの水準なら十分か、という一律の値は置けません。 契約類型、観点の数、自社ひな形の整備度で変わります。決めるのは、自社にとって「この状態なら法務確認を軽くしてよい」と言える線がどこかです。その線は、上の3つを何件かの契約で数えてから引きます。

見落としがゼロになることは前提にしません。締結前の確認項目は、AIの出力とは別に残したままにします。

指摘の理由を条項単位で残す

契約は締結後に読み返されます。取引の条件が争いになったとき、なぜこの文言で合意したのかを説明できる必要があります。AIを介在させるなら、記録の設計を後回しにできません。

記録は条項に紐づけます。1件の指摘に対して残す項目は次のようになります。

契約の識別子と、対象の条番号
該当する条文の引用（要約ではなく原文）
適用した観点の識別子と、その観点の版
判定結果と、そう判定した理由
比較に使った自社ひな形の版
一次レビューを実行した日時と使用したモデル
法務の採否と、採否の理由
最終的にどの文言で合意したか

ここで効いてくるのが、観点に識別子と版を持たせることです。観点は運用しながら直していくものなので、版を上げずに書き換えると、過去の契約をどの基準で見たのかが分からなくなります。版が残っていれば、「この契約は当時のこの基準で確認した」と示せます。

もう1つは、AIの出力を人が上書きしないことです。法務の判断は別のレコードとして重ねます。上書きすると、機械が何を指摘したのかと、人が何を決めたのかの区別がつきません。監査で見られるのは、後者だけではなく両方です。

引用を原文の位置で持つのも同じ理由です。要約だけを残すと、指摘が条文の解釈として妥当だったかを後から確かめられません。

この記録は、監査に備えるだけのものではありません。法務が毎回不採用にしている観点は、書き方が実務に合っていないということです。法務が毎回手で足している指摘は、観点が不足しているということです。採否の履歴を見れば、観点をどう直すかが決まります。AIを入れたあとに何が変わったかを測る方法は AI導入の効果測定と投資判断で扱っています。

この記録は締結までで終わりません。契約期間、自動更新の有無、解約通知の期限といった締結後に使う項目は、レビューで読んだ契約書から出てきます。締結してからの管理は契約書の管理台帳と更新期限をAIで管理するで扱っています。締結前と締結後で持つ項目を揃えておくと、同じ契約書を二度読み取らずに済みます。

契約書をAIに渡す前に決めておく情報の扱い

契約書には相手方の情報が含まれます。秘密保持義務を負っている情報を、外部のサービスへ送る形になることがあります。仕組みを作る前に、どこにデータが渡るかを説明できる状態にしておきます。

決めておく項目は次のとおりです。

入力したデータが学習に使われない条件で利用できるか。 利用規約や契約で確認します。設定で切り替わる場合は、その設定を誰が管理するかまで決めます
秘密保持契約上、どう位置づけられるか。 外部サービスの利用が第三者への開示や再委託に当たるか、相手方の同意が要る類型があるかを、契約類型ごとに整理します
個人情報が含まれる契約をどう扱うか。 従事者名や連絡先、保証人の情報が入る契約があります。自社の個人情報の取扱い方針に照らして確認します
保存期間とアクセス権限。 レビュー結果を誰が見られるか、案件が終わったあとも残すかを決めます
記録の保護レベル。 指摘の記録に条文の原文を引用する設計なら、その記録は契約書そのものと同じ扱いにします。ログに本文が残る場合も同じです

法令や契約に照らした可否は法務が判断する内容です。仕組みの側で持つのは、データがどこを通り、どこに残り、誰が見られるかを一覧で示せることです。これが出せないと、法務は判断のしようがありません。

Slack上でやり取りを完結させる

一次レビューを自動化しても、依頼と返答が個別のメールで飛んでいれば、状況が見えない問題は残ります。やり取りの場所を1つに寄せます。

依頼はフォームで受けます。 契約類型、相手方、締結期限、自社の立場、ひな形ベースかどうかを必須項目にします。埋めないと送信できない形にするだけで、内容確認のための往復が減ります。

1契約1スレッドにします。 依頼ごとにスレッドを立て、一次レビューの結果、法務のコメント、修正版のやり取りをすべてその中に置きます。誰がどの段階で何を言ったかが、上から読めば分かる状態になります。

指摘は1つの投稿にまとめます。 指摘ごとに別の投稿を出すと読まれません。重要度の高いものから並べ、条項ごとに引用と適用した観点を添えて、1投稿として出します。

採否はスレッド内の操作で記録します。 各指摘に対して採用か不採用かを選べるようにし、選んだ内容を記録側へ書き戻します。会話文の中で「これはOKです」と書かれた内容を後から集計するのは無理があります。

承認は状態を持つ操作にします。 「法務確認済み」を、会話ではなく明示的な操作で記録します。誰がいつ承認したかが残り、依頼者はスレッドを読まずに状態を確認できます。

期限と滞留を通知します。 締結期限を持たせ、未対応のまま期限が近づいたものを通知します。滞留している依頼の一覧を見られるようにしておくと、人を増やさずに詰まりを見つけられます。

情報の置き場所は分けて考えます。契約書そのものをSlackに置くかは社内の情報管理の方針に従い、ファイルは既存の文書管理側に残してリンクと指摘だけを流す構成も取れます。契約は閲覧できる人が限られるため、チャンネルの公開範囲と参加者の管理は最初に決めます。

最初に切り出す範囲

いきなり全類型を対象にすると、観点の定義が終わりません。範囲を絞ります。

契約類型を1つに絞る。 件数が多く、自社ひな形があり、条項の型が決まっているものから始めます。秘密保持契約はこの条件に当てはまりやすく、進め方は NDA・秘密保持契約のレビューをAIで自動化するにまとめています。

自社ひな形を相手方が修正して返してきたケースを最初の対象にする。 差分が起点になるので、指摘の妥当性を確かめやすくなります。

過去にレビュー済みの契約で走らせて比べる。 法務が実際に出した指摘と突き合わせ、見落とし・過剰な指摘・根拠のずれを数えます。数え方は前の節のとおりです。ここで観点を直してから、実際の依頼に使います。

法務確認は全件残したまま始める。 指摘の採否と、法務が手で足した指摘を記録します。任せる範囲を広げる判断は、この記録から決めます。始める前に「何割を自動化する」と決め打ちしないほうが、判断を間違えにくくなります。

着手前に用意しておくものは、自社ひな形とその版の管理方法、必須条項の一覧、譲れない条件（賠償の上限や管轄など）、契約類型ごとの件数、現在のレビュー依頼の経路、承認権限を持つ人、そして観点を直し続ける担当です。最後の1つが決まっていないと、観点が古くなった時点で使われなくなります。

自社で組むか、契約書レビューの既製サービスを使うかは、件数と観点をどれだけ自社の方針に寄せたいかで変わります。判断の材料は AIエージェントは自作か既製ツールかで整理しています。開発をどう進めるか、どこまでを検証で確かめてから本番に載せるかは AIエージェント開発の進め方で整理しています。書類を読み取って既存の処理へつなぐ構成の例としては請求書処理の自動化をAIで進めるも近い題材です。

契約書レビューは、観点を書ける人が社内にいて、その観点を直し続ける必要がある領域です。外部に都度依頼する形では、観点の更新が止まります。社内で改善を回せる体制の作り方は AI内製化の進め方を参照してください。

まとめ：契約書レビューをAIで進めるときの要点

滞留の原因は法務の処理速度ではなく、依頼の受け口が決まっていないことと、全件を同じ深さで見ていることにある
工程を分けると、AIに渡せるのは条項への分解、一次レビュー、指摘の整理までで、採否の判断は人が持つ
観点は共通の観点、契約類型ごとの観点、自社固有の方針の3層で書く。1観点1判定の粒度まで下ろし、自社の立場を入力に取る
ひな形との差分の抽出、条項の欠落、用語や参照の不整合は、機械側で確定してよい指摘として扱える
差分は文字列ではなく条項の単位で取る。指摘に上げない差分と、比較に使ったひな形の版を先に決めておく
不利かどうかの最終評価、法令の当てはめ、ひな形の変更、社外に出す文言は法務が判断を持つ
AIが指摘しなかったことを、問題がない根拠にしない。締結前の確認項目は別に残す
指摘の返し方は、一覧で出すか、修正履歴つきのファイルで返すか、修正文案を添えるか。契約類型ごとに1つ決め、一覧は重要度の順に並べる
精度は一つの正解率で見ず、見落とし・過剰な指摘・根拠のずれの3つを数える。直す場所がそれぞれ違う
記録は条項単位に、原文の引用と適用した観点の版を添えて残す。人の判断はAIの出力に上書きせず、別のレコードとして重ねる
契約書を渡す前に、学習利用の有無、秘密保持契約上の位置づけ、保存期間とアクセス権限を決めておく
記録する項目は締結後の管理台帳と揃えておく。契約期間や更新条件は同じ契約書から出てくる
Slackでは1契約1スレッドにし、採否と承認を会話ではなく状態を持つ操作として記録する
最初は類型を1つに絞り、法務確認を全件残したまま採否の記録を取る。任せる範囲はその記録から広げる

Augueでは、条項単位の判定や承認の履歴を残す必要がある業務について、どこまでを機械に任せどこに人の承認を置くかの設計から、Slackなど既存の業務ツール上で完結する形までを含めて開発に対応しています。自社の契約書レビューのどの工程をAIに寄せられるか整理したい方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

契約書レビューのどこまでをAIに任せられますか？

条項単位への分解、一次レビュー、指摘の整理までです。採否の判断は法務が持ちます。削れるのは読んで洗い出す時間と、依頼内容を確認するための往復で、判断そのものの時間は減りません。ここを取り違えると、期待していた効果が出ずに終わります。

AIが指摘しなかった箇所は、問題ないと考えてよいですか？

考えないでください。一次レビューは網羅性を保証しません。締結前の確認項目は、AIの出力とは別に残しておきます。運用ルールとして「指摘がなかったことを根拠に問題なしと判断しない」を明記しておくと、任せる範囲を広げたあとも崩れません。

一次レビューの質を上げるには何を直せばよいですか？

AIの性能より観点の定義です。「問題がないか見て」では指摘が毎回変わります。1観点1判定の粒度まで下ろし（賠償額の上限の定めがあるか、上限が対価の範囲内か、など）、自社が発注側か受注側かを入力に取ります。観点をAIに考えさせる構成にはしません。

記録は何を残せばよいですか？

条項に紐づけて、原文の引用、適用した観点の識別子と版、判定結果と理由、比較したひな形の版、実行日時とモデル、法務の採否と理由、最終合意の文言です。人の判断はAIの出力に上書きせず、別のレコードとして重ねます。上書きすると、機械が何を指摘し人が何を決めたのかの区別がつきません。

最初はどの契約から始めるとよいですか？

契約類型を1つに絞り、自社ひな形を相手方が修正して返してきたケースから始めます。差分が起点になるため指摘の妥当性を確かめやすいです。過去にレビュー済みの契約で走らせると、法務が実際に指摘した内容という正解があるため、観点の不足と過剰な指摘が同時に見えます。

弁護士法との関係で気をつけることはありますか？

契約書レビューを支援するサービスと弁護士法第72条の関係については、法務省が考え方を示しています。社内で使う仕組みを作る場合も、最終的な判断を自社の法務や弁護士が持つ構成にしておくことが前提になります。指摘の採否をAIの出力で確定させない設計にします。