法務のAI自動化は「どう進めるか」の段階へ

「AIを導入したのに、契約業務が思ったほど変わらない」。多くの法務組織が感じているこの違和感の原因は、AIの性能ではなく、AIが「1工程×契約書の中だけ」という“点”で止まっていることにあります。この構造的な背景は「AIを入れても契約業務が変わらないのはなぜか」で詳しく解説しています。

構造が分かった次に出てくるのは、実務的な問いです。「では、自社ではどこから・どの順番で・どこまで進めればよいのか」。本記事はこの問いに答える手順編です。全工程マップによる現状把握、成熟度モデルLv0〜5による現在地と目標の設定、ギャップの大きい5領域それぞれの着手の道筋、そして自動化を設計する5つのステップを、実務で使える順番で解説します。

なお、生成AIと契約業務の関係を基本から押さえたい方は、先に「AIとChatGPTは契約業務をどう変える？実務での活用法と注意点を解説」をお読みいただくと、本記事の内容が理解しやすくなります。

前提｜法務業務のAI自動化は「オープン型」の構成で進める

本記事の手順は、普段使っている生成AI（ClaudeやChatGPTなど）をMCP経由でCLMや社内システムに接続し、全工程をデータとAPIでつなげる「オープン型」の構成を前提にしています。製品に組み込まれた内蔵型AIとの構造的な違いは、冒頭で紹介した記事で解説した通りです。また、AIの選択とデータの持ち方を分けるという考え方そのものは「ベンダーロックインを避ける法務のAI活用の考え方｜Open CLMという新常識」で詳しく扱っています。

全工程がつながる構成であっても、いきなり全部に手を付けるのは現実的ではありません。まず全体像をマップにして、ギャップの大きい領域から絞り込む。ここからが本記事の本題です。

手順1｜法務業務の全工程マップでAI自動化の対象を洗い出す

個別の効率化を考える前に、まず法務業務の全体像を一枚で見ることをおすすめします。法務業務は、次の2層で捉えると整理しやすくなります。

1層目は、契約1件が順番に流れていくライフサイクルです。受付、起案、審査、交渉、承認、締結という工程が、案件ごとに順を追って進みます。

2層目は、契約全体を支える継続業務です。契約の棚卸し、法令改正への対応、事業部門からの相談対応、担当交代時の引き継ぎといった業務は、「締結の次」に来るものではなく、契約全体に対して横断的に、常に発生し続けます。

この2層で見ると、これまでのAI活用の偏りがはっきりします。AI活用が進んでいるのはライフサイクル上の「審査（レビュー）」の1点に集中していて、2層目の継続業務はまるごと手作業のまま、という組織が少なくありません。マップにすると、着手候補が2層目に多く眠っていることが見えてきます。

手順2｜AI自動化の成熟度6段階（Lv0〜Lv5）で現在地と目標を決める

どこまで自動化を目指すのかを議論するには、共通の物差しがあると便利です。次の6段階の成熟度モデルは、各業務領域の現在地と目標を示すのに使えます。

このモデルは3つのゾーンで捉えると理解しやすくなります。Lv0〜2はAIが補助で人が主役のゾーン、Lv3〜4はAIが工程を遂行するゾーン、そしてLv5は知が組織に継承され進化していくゾーンです。単なる効率化ではなく「組織の知恵として蓄積・進化する」状態を最上位に置いている点がポイントです。

なお、このLv0〜5は業務領域ごとの「自動化の度合い」を測る物差しです。レビューという1つの業務の中で「AIがどこまで自社基準に到達しているか」を測る別の物差し（自社基準レビューの成熟度 Layer 0〜5）とは対象が異なりますので、使い分けてください。

AI自動化は「すべてをAIに任せる」ことではない

誤解のないように付け加えると、Lv4〜5を目指すことは「すべてをAIに任せる」ことではありません。締結の最終判断、重要取引のリスク判断、前例のない例外対応は、人が持ち続けるべき領域です。AIに任せるのは、一次レビューや一次回答、該当契約の抽出・整理、改定案や下書きの作成といった、判断の手前まで「運ぶ」仕事です。人が判断だけに集中できる状態をつくる、というのが目指す姿になります。

手順3｜AI自動化の効果が大きい法務の5領域から着手する

ここからは、現状の成熟度が低く、自動化の効果が大きいと考えられる5つの領域を、「現状のペイン → 最終ゴール像 → そこへの道筋」という共通の型で見ていきます。自社のマップと照らして、当てはまりの強い領域から読んでいただいても構いません。

① 契約レビューのAI自動化（現在Lv1-2 → 目標Lv3-4）

唯一「点」として自動化が進んできた領域ですが、課題は残っています。担当者ごとに指摘の粒度や観点がばらつく、自社基準が担当者の頭の中にあって明文化されていない、事業部と法務の間で差し戻しが何度も往復する、といったペインです。さらに見落とされがちなのが、基準を細かく作り込むほどプレイブックの手作業での保守が難しくなるという問題です。

目指す最終ゴールは、AIが自社基準で一次レビューを終え、条項ごとに根拠つきで指摘し、法務は最終判断だけに集中している状態です。具体的には、レビュー基準をMarkdown（.md）ファイルで記述し、次のようなプロンプトでAIに渡します。

review/業務委託.md の基準でこの契約書をレビューし、条項ごとに
① 該当/NG
② 根拠
③ 修正文例
を表で出してください

基準ファイルには「再委託は事前の書面承諾を必須とする」「損害賠償の無制限規定は上限を委託料12ヶ月分に修正する」といった自社ルールを書いておきます。基準を書き換えれば、AIのレビュー観点も即座に更新されます。

ここで重要になるのが、基準そのものの保守です。作り込んだ基準は、条項や例外を増やすほど手作業での維持が重くなります。オープン型の構成では、運用ログから基準の過不足をAIが検知し、基準ファイルの更新をAI自身が提案する、という「基準の自己保守」のループを組むことができます。人は提案を承認するだけになるため、精密な自社基準を現実に運用し続けやすくなります。

道筋としては、すでにExcelなどにあるレビュー基準を棚卸しして.md化し、運用しながら書き足していくところから着手できます。Claudeを使ったレビューの具体的な手順は「Claudeで契約書レビューはどこまでできる？AI活用の実務と注意点」も参考になります。

② 法務相談対応のAI自動化（現在Lv0-1 → 目標Lv3-4）

事業部門からの法務相談は、同じような質問が繰り返し寄せられる、一次対応の負荷が特定の担当者に集中する、回答者によって回答がばらつく、回答した内容がナレッジとして残らない、といったペインを抱えやすい領域です。

最終ゴールは、よくある相談はAIが規程や過去回答を参照して根拠つきで一次回答し、法務は判断が必要な相談だけに向き合う状態です。実装イメージとしては、規程類、FAQ、判断つきの過去回答、即答せずエスカレーションする条件、を1つのフォルダにそろえておき、次のように依頼します。

consult/ フォルダを参照して、この相談に
① 回答
② 根拠（規程／過去回答）
③ エスカレーション要否
の形式で返答してください

出力には「根拠：情報管理規程 第8条／過去回答#142」のように参照元が明示されるため、人が確認しやすくなります。まず人が回答を確認する半自動の運用から始め、回答するほど過去回答が蓄積されて次の一次回答が賢くなる、という循環をつくるのが道筋です。この循環は後述の⑤ナレッジ管理とつながっていきます。

③ 契約棚卸しのAI自動化（現在Lv0-1 → 目標Lv3）

どこに・何の契約があるか全体を把握できていない、更新期限や自動更新条項が見落とされる、法改正やM&Aのたびに全件を人手で確認しきれない、契約書がPDFや紙のままで横断検索ができない。棚卸しはこうしたペインが集中する領域です。

最終ゴールは、全契約が構造化されたデータとして保持され、どんな条件でも即座に対象契約を一覧化できる状態です。たとえば次のような依頼が成立します。

全契約の中から、自動更新の定めがあり、かつ解約通知期限が60日以上前に設定されている契約を、相手方・満了日・通知期限つきで一覧にしてください

この構成が成立すると、棚卸しは「作業」から「クエリ」に変わります。なお、この領域は内蔵型AIでは構造的に難しい面があります。レビュー時に本文を一時的に読むだけの構成では、全契約を構造化して保持していないため、横断検索や影響範囲の特定ができないためです。棚卸しの可否は、契約本文をデータの構造で持っているかどうかで決まると言えます。

④ 法令改正対応のAI自動化（現在Lv0-1 → 目標Lv4）

法令改正対応は、工程が最も長い領域です。改正の検知が官報やニュース、顧問弁護士頼みの人力である、どの契約が影響を受けるかの特定に時間がかかる、該当契約の抽出から改定・交渉まですべて手作業である、対応の記録が残らず次の改正でまた一からやり直しになる、といったペインがあります。

最終ゴールは、改正検知、影響分析、該当契約の抽出、改定要否の判断材料づくり、改定案の作成、社内承認、相手方との交渉、締結、履歴化という9つの工程が一本でつながっている状態です。e-Govなどの法令データと自社の契約データの両方にAIが接続できると、次のような依頼が可能になります。

下請法の今回の改正点をふまえ、全業務委託契約から影響を受ける条項を持つ契約を抽出し、契約ごとに「改定要否」と「改定案」を出してください

AIが契約ごとの改定要否と改定案の下ごしらえを用意し、人は改定要否の最終確認、改定案の承認、相手方との交渉に集中します。単機能のAIで自動化できるのは9工程のうち改定案づくりの1工程にとどまりがちですが、工程がつながれば検知から履歴化までが射程に入ります。

⑤ 法務ナレッジ管理のAI活用（現在Lv0 → 目標Lv5）

5領域の中で最も成熟度が低く、かつ最上位のLv5を目指せるのがナレッジ管理です。審査や相談で使った基準・ナレッジが人に依存して組織に貯まらない、「なぜこの条件でOKにしたか」という判断の理由が残らない、担当交代や退職のたびに暗黙知が失われて後任が一から学び直す、というペインは、属人化の根っこにあたります。

最終ゴールは、判断とその理由（判断ログ）、依頼者との相談・交渉の経緯、基準の更新履歴が組織のナレッジとして蓄積され、担当が代わってもAIが前例をふまえて動ける状態です。判断ログは「状況／論点／結論／理由」を1判断1ファイルで残すのが実務的です。たとえば「A社と損害賠償上限で対立。取引規模と与信を勘案し、委託料12ヶ月分で合意」という記録が、次に似た論点が来たときの参照材料になります。

依頼を受ける、判断する、記録する、次の依頼で参照する、というループが回り始めると、蓄積が次の判断を賢くし、基準も更新されていきます。会話が終われば文脈が消える構成と、判断とやり取りが資産として残り再利用される構成。同じAIを使っていても、この違いが成熟度の差になって表れます。

手順4｜AI自動化を設計する5つのステップ

5つの領域はいずれも、同じ設計の型で進めることができます。

1. 業務を分解する：対象業務を工程に分ける
2. 基準を言語化する：判断基準・手順を.mdファイルに書く
3. 工程を連結する：MCPで契約データ・社内システムとつなぐ
4. 介在点を設計する：人が判断すべきポイントを残す
5. 育てる：運用しながら基準とナレッジを更新する

ファイルの持ち方としては、全社共通のルール・用語は共通フォルダに一元化し、レビュー基準、相談対応、棚卸しの抽出条件、法令改正の対応手順、判断ログといった領域固有のものは領域ごとにフォルダを分けて持つ構成が扱いやすいと考えられます。契約の実体データはCLMからMCP経由で呼び出す形です。

ここでひとつ、外しやすいポイントがあります。巨大な1枚の.mdファイルにすべてを詰め込まない、ということです。全部入りの1枚は、更新もレビューも回らなくなりがちです。領域ごとに分けておけば、担当が分かれても、少しずつでも育てていくことができます。

設計の主役は、ツールではなく「自社の判断基準」です。基準を言語化し、構造化する。それができれば、どの領域にも同じやり方で展開できます。AIはあくまで基準を実行する側であり、主役は自社の判断基準そのものです。

法務業務をAIで自動化する3つの効果

全工程を面で設計できると、次の3つの変化が期待できます。

第一に生産性です。全工程の下ごしらえをAIが担うことで、人は判断に集中しやすくなります。第二に品質の均一化です。明文化された基準に沿って処理されるため、担当が代わってもアウトプットがブレにくくなります。第三に属人化の解消と継承です。判断知が蓄積されて組織の資産として残るため、担当交代や退職で知が途切れにくくなります。とくに3つ目は、法務組織の長期的な体制づくりに効いてくる変化と言えます。

法務のAI自動化の最初の一歩｜自社の全工程マップを描く

ここまでの手順1〜4を実務に落とすとき、今日から着手できる最初の一歩が、自社の全工程マップを描くことです。進め方はシンプルです。

まず、手順1の2層マップ（ライフサイクル6工程＋継続業務4つ）を下敷きに、自社の契約業務を書き出します。組織によって工程の呼び方や分かれ方は異なるため、自社の実態に合わせて調整してください。次に、各工程の現在の成熟度をLv0〜5で仮置きします。厳密である必要はなく、「棚卸しはLv0、レビューはLv1」といった粗い自己評価で十分です。最後に、各工程の発生頻度と負荷（誰が・どれくらいの時間をかけているか）を添えます。

このマップができると、2つのことが見えてきます。ひとつは、成熟度が低く負荷が大きい工程、つまり自動化の投資対効果が高い領域です。多くの組織では、本記事で扱った5領域のいずれかがここに該当すると考えられます。もうひとつは、個別ツールの導入判断の軸です。検討中のツールがマップ上のどの工程を、どのレベルまで引き上げるのか。工程をまたいでデータがつながるのか、その工程で閉じるのか。マップがあれば、この問いに具体的に答えられるようになります。

なお、自社だけで設計を進めるか、外部の支援を受けるかは、社内の実装・運用体制と契約業務の複雑度によって判断が分かれます。体制があり対象領域を絞れる場合は、1領域を.md化して小さく始める自己実装が進めやすい一方、複雑度が高く広い範囲を短期間で立ち上げたい場合は、型が固まるまで外部の伴走支援を受けるほうが速いケースもあります。

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

本記事では、AI自動化を進める手順として、全工程マップによる現状把握（手順1）、成熟度モデルLv0〜5による現在地と目標の設定（手順2）、ギャップの大きい5領域の道筋（手順3）、設計の5ステップ（手順4）を解説しました。「なぜ点で止まるのか」という構造の理解とあわせて読むことで、自社の設計に落とし込みやすくなるはずです。

通底する考え方が「AIは選び、契約は1箇所に集める」です。AIは進化が速いため、その時々で最適なものを選べる状態を保ちつつ、契約データと判断基準は1箇所に構造化して蓄積する。この構成を支える基盤としては、契約データを構造化して保持しAPIで外部AIから呼び出せるオープン型CLM（たとえばその実装の一つであるContractS CLM）を利用するという選択肢があります。自社の体制と契約業務の複雑度に合わせて、小さく始めて育てていくアプローチをご検討ください。

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

ContractS編集部

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

私たちについて