AIが出す「報告」は、有事対応のゴールではない

「この法改正の影響を受ける契約を、全部洗い出して対応方針を報告して」——経営や法務トップから降ってくる、一見シンプルな一言です。取引先の倒産や制裁指定、M&Aに伴うデューデリ、突発の社内依頼。こうした有事は”たまに”ではなく、定常的かつ突発的に頻発します。

近年、この依頼の前半は劇的に軽くなりました。AIエージェントに「該当契約を洗い出して」と渡せば、契約DBを横断して母集団を抽出し、各契約の条項を読解し、一覧に整理して報告まで——従来「数人×数日」かかっていた棚卸しが、数十分で片づくところまで来ています（この棚卸し自体のAI自動化は契約棚卸しはAIエージェントに任せる時代へで詳しく解説しています）。

ところが、ここで多くの現場が見落とすことがあります。報告が出た時点で、有事対応はまだ半分も終わっていないのです。本記事では、棚卸しの”先”——報告から対応完了までを、AIにどこまで任せられるのかを、法改正シナリオを軸に整理します。

有事対応は「発生→対応完了」までの一本の連鎖

法改正対応を例にとると、業務は次のような一本の連鎖です。

「発生」（法改正の公布）から始まり、前半の「棚卸し」（検索→確認→集計→報告）を経て、後半の「対応」（場合分け→修正案→巻き直し→台帳更新）へと進み、ようやく「対応完了」に至ります。

冒頭で触れた”数十分”が指していたのは、この連鎖の前半だけです。報告書ができても、抵触する条項を抱えた契約が何十件・何百件と残っており、それぞれを実際に巻き直すまでが本番。短縮すべきは棚卸し単体ではなく、有事対応のリードタイム”全体”だということになります。

報告の”先”に残る4工程——ここをAIに任せられるか

では、報告の後ろに何が残るのか。法改正シナリオで分解すると、次の4工程です。

棚卸し（前半）と同じく、この後半も件数 × 手作業で線形に膨らみます。だからこそ、報告までしかAIに任せられないと、有事対応の体感的な重さはほとんど変わりません。

「場合分け」はAIが機械的にこなせる——価値判断ではなく属性分岐だから

「対応パターンの振り分けは高度な法的判断だから、AIには無理だろう」——そう思われがちです。しかし、よく見ると、場合分けの多くは契約の属性で機械的に決まるものです。

更新時期・残期間・影響度という軸さえ決まれば、分岐は機械的に落ちます。つまり、ここでAIがやっているのは創造的な価値判断ではなく、条件への該当確認です。軸を人が設計し、判定はAIが量産する——この役割分担が、後工程の自律実行を成立させます。

オープン型AIは、契約1件を「対応完了」まで走り切る

属性で分岐が決まるなら、AIは1件の契約を、報告の先まで連続して処理できます。たとえばケースB（残期間が長い長期契約）に該当した1件を、AIエージェントは次のように扱います。

1. 該当判定：改正条項に抵触すると確認する
2. 対応の場合分け：残期間が長いので「巻き直し」に振り分ける
3. 覚書ドラフト作成：変更文言を起案する
4. 承認ルート投入：所定のワークフローに回付する
5. 台帳更新：承認後、CLMの契約レコードに反映する

報告で止まらず、契約1件ごとに対応完了まで連続自律実行する。これが「AIが業務を遂行する」の中身です。検索・読解・起案・回付・台帳更新という各工程の結果を、AIが自分で次の工程の入力として受け渡していくため、人が間に立って手で繋ぎ直す必要がありません。

なぜ内蔵型AIは”絶対”に止まるのか

ここで決定的なのが、どんなAIでもこれができるわけではないという点です。CLMやレビュー製品にAIをあらかじめ組み込んだ「内蔵型AI」は、報告の先へ進む経路を構造上持ちません。報告を受け取った人が、起案ツールへ手で入力し直し、承認ルートに載せ、台帳を別途更新する——機能の箱と箱のあいだを、結局は人が繋ぐことになります。

なぜなら、有事対応の後工程は3重の横断を要求するからです。

• 契約横断：該当した全契約に一括で
• 工程横断：場合分け→起案→承認→台帳更新をまたいで
• 条件分岐：契約ごとに属性でケース分けしながら

内蔵型AIは、個別機能の自動化はできても、この3重の横断ができません。機能の箱を越えられない設計だからです。連鎖の深さで整理すると、差は次のように表れます。

差が最も開くのが、報告の先の深い連鎖です。内蔵型AIと連携型（オープン型）AIの構造的な違いそのものについては、AI内蔵型CLM vs AI連携型（Open）CLM 徹底比較で掘り下げています。

AIに任せる前提：オープン型と「受け入れDB」の両輪

報告の先までAIに走り切らせるには、2つの条件が両輪でそろう必要があります。

ひとつは、オープン型の仕組み。検索・読解・起案・承認・台帳という全工程がAPIで開放され、自社が選んだAIが一つの操作面として横断できること。もうひとつは、受け入れDBの設計。契約データが「取引先／契約類型／条項／属性」の4軸で機械的に引ける構造になっていること。タイトルや全文頼りの検索では、漏れと過剰が必ず出ます。

どちらか片方では回りません。「AIを入れれば自動化できる」というより、AIが触れられる契約管理を先に整えることが出発点になります。この前提条件と、すでにAIを日常使いしている法務がCLMに求めるべき要件は、すでにAIを使う法務がCLMに求める3条件、およびOpenCLMとは？ChatGPT/Claude時代のCLM選定基準もあわせてご覧ください。

AIに任せても、人が判断する要所は残す

最後に、業務利用時の注意点を3つ挙げます。

第一に、最終承認は人が握ること。AIが連続実行するのは、覚書ドラフトの作成から承認ルートへの回付まで、そして承認後の台帳反映まで。契約変更を最終的に決める意思決定は、人の手元に残します。

第二に、機密情報の取り扱いと使うAIの選定。契約書は機密のかたまりです。接続するAIは、入力が学習に使われないことが保証された法人向けプラン以上を選びます。使うAIを自社で選べることは、オープン型を採る大きな理由のひとつです。

第三に、自律性の境界とログ。AIが書き込んでよい範囲（新規起案は可、確定済み契約の上書きは不可など）を明示し、動作ログを監査できる形で残します。軸の設計とガードレールこそ、人が担うべき仕事です。

まとめ：AIの価値は「報告」ではなく「対応完了」にある

有事対応で「影響契約を洗い出して報告して」とAIに頼めば、棚卸しは数十分で終わります。しかしそれは入口にすぎず、本当の価値は報告の先——場合分けから台帳更新まで、契約1件ごとに対応完了まで走り切ることにあります。

そして、報告の先まで連続実行できるかどうかは、AIの賢さではなくアーキテクチャで決まります。機能の箱を越えられない内蔵型AIは”絶対”に止まり、走り切れるのは全工程がAIの操作面になっているオープン型だけです。今日整えるべきは、AIそのものより、AIが触れられる契約データの構造とアーキテクチャの選択。「AIは選び、契約は1箇所に集める」——この設計思想が、有事対応のリードタイム全体を縮める現実解になります。

一例として、ContractS CLMはこのオープン型の設計を採用し、普段使っているAIを契約データに対してそのまま動かせる仕組みを提供しています。

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

ContractS編集部

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

私たちについて