契約業務の時間の大半は「レビュー」ではない。
それは「特定の項目を探すこと」だ。
CLOCとDocuSignが1,300人の契約実務者を対象に行った調査によると、1件の契約書から特定の文言を見つけるのに平均2時間以上かかります。適切な書類を探すのに45分、さらに該当箇所を特定するのに84分。LegalOnの「2026年 社内法務におけるAI活用の実態調査」でも、法務チームは契約レビュー1件あたり平均3時間を費やし、年間500件の契約を扱う部門では、250営業日のうち188日をレビューだけで費やしています。ボトルネックは法的分析ではなく、情報の検索なのです。
重要ポイント
- 契約1件あたり2時間 — 書類の特定に45分、該当項目の検索に84分 — をファイル操作に費やし、本来の法律業務に充てられていない。
- Ctrl+Fでは「発効日」と「契約開始日」を一致させられず、契約ライフサイクル管理ツールも事前学習した項目しか抽出できない。あなたが本当に必要とする項目は、その隙間からこぼれ落ちる。
- 抽出したい列名を指定すれば、AIが契約書の意味を読み取り、ページ上の位置に依存せずにデータを抽出。50のPDFに散らばった項目を、1つのテーブルにまとめて並べ替え、フィルタリング、確認ができる。
時間の本当の使い道
社内弁護士に「時間を最も奪うものは何か」と尋ねれば、契約審査が上位に挙がるだろう。しかし「審査」という表現は正確ではない。その時間の大半は、リスク評価や条件交渉ではなく、情報を探すことに費やされている。
CLOCの調査(あらゆる規模の組織の契約担当者を対象)では、このプロセスは2つの測定可能な段階に分けられる。契約書の特定(45分)、該当条項や文言の発見(84分)。実際の分析が始まるまでに2時間以上かかる計算だ。しかもこれは1件の契約あたり。月500件の契約を生成する組織では、年間6,000件超。その計算結果は重い。
この傾向は個人レベルでも同様だ。社内弁護士は業務時間の60~80%を日常的な書類審査に費やしており、その多くは法的判断ではなく、情報検索とデータ入力である。LegalOnとIn-House Connectの2025年調査によれば、契約審査におけるAI導入は前年比75%増加しており、その主な原動力はまさにこの問題からの時間解放にある。
このフラストレーションは抽象論ではない。Redditのr/legaltechAIで、ある社内リーガルオプスの専門家はこう率直に語っている。「条項抽出と逸脱検出は最低条件だ。本当に難しいのはポートフォリオ全体のインテリジェンス、つまり数千件の契約にまたがる義務の抽出、更新リスク、M&A前の支配権変動条項、規制スイープ分析などだ。これは修正案の作成ではなく、契約をビジネスが検索可能な構造化データに変換することだ。」(出典)
r/paralegalのパラリーガルはさらに実践的に述べている。「条項抽出はトリアージの手段として信頼するが、読解の代替にはしない。重要なのは『意味を教えてくれること』ではなく『目的のページやセクションに素早くたどり着けること』だ。」(出典)
なぜCtrl+Fでは50件の契約書に対応できないのか
直感的な解決策はキーワード検索だ。各PDFを開き、Ctrl+Fを押し、"governing law"や"effective date"を入力し、結果をコピーしてスプレッドシートに貼り付ける。2、3件の契約書ならこれで機能する。50件になると、すぐに限界が現れる。
契約書の文言は完全一致検索に抵抗する。同じ概念が異なるラベルで現れる。ある契約書では"Effective Date"が、別の契約書では"Commencement Date"となり、さらに別の契約書では"This Agreement shall become effective as of"となる。"indemnification"のキーワード検索では、"Hold Harmless"と題された条項を見逃す。"termination"の検索では、80ページにわたる文中のすべての言及が返され、実際の終了条項と、単なる言及、定義語、相互参照を手動で区別する必要がある。
さらにフォーマットの問題もある。クリーンなWord文書もあれば、スキャンされたPDFもある。プリンターとスキャナーと、テキストをかろうじて読める程度にする圧縮アーティファクトの産物だ。キーワード検索は、画像ベースのPDFでは完全に機能しない。事前にOCRが実行されている場合を除き、それでも品質はまちまちだ。
CLOCの調査によると、チームの65%が依然としてスプレッドシートとメールで契約書を管理している。統合ツールも、一元管理リポジトリも、自動抽出もない。46%は、適切な契約書をまったく見つけられないことがある。見つけた文書が最新版であると確信しているのは半数未満だ。これらは技術導入の失敗というよりも、ワークフロー設計の失敗である。人々が手にするツールは、そもそもこの仕事のために作られたものではないのだ。
契約書は、他のほとんどの文書タイプよりも、キーワード検索の限界を露呈する。長文でありながら、密な相互参照と非標準化された文言が組み合わさっており、まさに検索とコピーが機能しなくなる条件が揃っている。
契約CLMが行うこと(そして抽出に関して行わないこと)
中規模または大規模な組織で働いているなら、すでに契約ライフサイクル管理システム(DocuSign CLM、Ironclad、LinkSquares、Juroなど)を導入しているかもしれない。これらのプラットフォームは、契約ライフサイクル全体(ドラフト作成、交渉、承認ルーティング、電子署名、保管、署名後の義務追跡)を処理する。
CLMは得意分野で強力だ。Ironcladは承認ワークフローを自動化し、交渉済み契約書の一元管理リポジトリを維持する。LinkSquaresはAIを適用してメタデータを抽出し、ポートフォリオ全体の更新リスクを表面化する。DocuSign CLMは、契約書生成と電子署名および実行後分析を統合する。Juroは、ブラウザネイティブのワークスペースを提供し、協調的な契約書作成と署名を可能にする。
しかし、抽出に関して重要な違いがある。CLMは契約書を単位として扱うように構築されている。文書、そのステータス、署名者、期限を管理する。50件の契約書から同じ5つのデータポイントを抽出してスプレッドシートに落とし込む必要がある場合(フォーマットに関係なく、契約書がCLMに存在したかどうかに関係なく)、それは別の操作だ。
CLMプラットフォームは、トレーニングされたメタデータ(当事者名、発効日、契約金額など)を抽出できる。しかし、非標準フィールド(例えば、ベンダー契約書に埋め込まれた保険要件条項にある特定の事故あたりの免責額)を抽出するように依頼すると、カスタム抽出モデルを構築するか、手動で行うことになる。CLMの抽出範囲は、そのトレーニングデータに依存する。フィールドが事前トレーニングされた分類に含まれていなければ、抽出されない。
これはCLMの失敗ではありません。CLMが本来設計された目的を反映しているにすぎません。契約ライフサイクル管理とフィールドレベルのデータ抽出は、隣接しながらも異なる問題を解決します。CLMは契約のプロセスを管理し、抽出ツールは契約書のページから特定のデータを取得します。フォーマットに依存せず、テンプレート不要で、ツールが事前学習した内容ではなく、ユーザーが求める情報に基づいて動作します。
契約書から特定フィールドを抽出する方法(ステップバイステップ)
契約書の山から、当事者、発効日、準拠法、責任上限、更新条件、支払いスケジュールなど、特定のデータを抽出する必要がある場合、以下のワークフローが有効です。テンプレートやカスタムモデルは不要で、各書類をすべて読む必要もありません。
このワークフローは、従来の契約データ抽出とは逆のアプローチです。従来はサンプル契約でモデルを訓練し、汎化を期待していました。ここでの仕組みはカスタム列抽出です。ツールにデータの位置を認識させる(テンプレート/ゾーンOCRアプローチ)代わりに、「Party A」「発効日」「準拠法」「責任上限額」といった列名を入力して、AIに何を欲しいかを伝えます。AIは各契約書を読み、用語の意味を理解して対応する値を特定します。これは位置ベース抽出と意味ベース抽出の違いであり、AIは座標ではなく意味を見るため、契約書のフォーマットは重要ではありません。
データが必要な契約書(PDF、スキャン文書、Wordファイル、署名ページの写真など)をすべて集めます。事前の仕分け、フォーマット変換、ファイル名変更は不要です。ツールはJPG、PNG、WebP、PDF、Word形式をネイティブで読み取ります。
必要なデータポイントの列名を入力します。「Party A」「Party B」「発効日」「準拠法」「補償上限額」「更新期間」「支払いスケジュール」など。入力した列名が出力スプレッドシートのヘッダーになります。出力を定義すれば、AIが値を探します。ページに明示されていないフィールドが必要ですか?推論列を使用します。「契約タイプ(選択肢:NDA / MSA / SOW / 修正契約)」という列名を付けると、AIが各文書の内容に基づいて分類します。
すべての契約書を一度にアップロードします。AIが並行処理し、結果を1つのテーブルに統合します。各行が1つの契約書、各列が指定したフィールドです。Excel、CSV、JSONにエクスポートして開き、確認すれば完了です。
この一括マージ機能が、各ファイルを個別に開く方法との違いです。50件の契約書、1回のアップロード、1つの出力テーブル。各PDFを開き、フィールドを探し、値をコピーし、貼り付け、正確性を確認するという面倒な作業はツールが吸収します。
ファイルは安全に処理され、保存されません。
抽出が有効なケースと、弁護士が必要なケース
フィールド抽出は現実的な課題を解決しますが、正直な評価には、その適用範囲と限界を明確にすることが必要です。
抽出が得意なこと:契約書から構造化データを抽出すること。当事者、日付、金額、準拠法、更新条件、条項の有無(この契約に免責条項はあるか?はい/いいえ)など。これらは、明示的または推測可能な形で文書上に存在する値です。AIは位置ではなく意味理解でこれらを特定するため、契約書ごとのレイアウトの違い、条項の順序の違い、手書きの注釈などがあっても抽出は破綻しません。
抽出が代替しないこと:条項の文言に対する法的解釈。AIは契約書に免責条項が含まれていることと、そのテキストを抽出することはできます。しかし、その条項が異常に広範囲かどうか、他の条項と矛盾していないか、特定の管轄区域の判例法の下で組織に許容できないリスクをもたらすかどうかは判断できません。それは法的判断です。同様に、抽出ツールはCLMプラットフォームを代替しません。交渉ワークフローの管理、承認ルート、署名追跡、契約後の義務の監視は行いません。
有効な考え方:抽出ツールと契約データの関係は、パラリーガルによる一次レビューと訴訟ファイルの関係に似ています。必要な情報を整理して提示し、あなたの判断を待つものです。判断自体は行いません。
抽出をデータのトリアージと考えてください。「これらの契約書には何が書いてあるのか?」という問いに答えるために使い、レビューに臨む際には、探すことからではなく、答えから始められるようにしましょう。
よくある質問
スキャンした契約書でも使えますか?それともデジタルPDFのみですか?
両方に対応しています。AIは各ページの視覚的な内容を読み取ります。スキャン文書、署名済み契約書のスマホ写真、クリーンなデジタルPDF、Wordファイルなど、すべて同じ視覚認識経路で処理します。別途OCR処理は不要で、スキャン文書でも形式による精度低下はありません。ただし、極端に低品質なスキャン(約150 DPI未満、または圧縮ノイズが大きいもの)では精度が低下する可能性があります。
条項全体を抽出できますか?それとも単一のデータポイントのみですか?
両方可能です。列名を「免責条項」と指定すれば、AIがその条項の全文をセルに抽出します。「発効日」や「契約金額」のような単一の値も抽出できます。長い条項の場合、抽出されるテキストは複数段落の法律文言になります。
これを使うにはCLMが必要ですか?
いいえ。抽出ツールはCLMシステムとは独立して動作します。共有ドライブ、メール添付、SharePointフォルダなど、どこに保存された契約書でも使用できます。すでにCLMをお持ちの場合、抽出ツールはCLMの事前学習済み抽出項目に該当しないアドホックなフィールド要求を処理することで、CLMを補完します。
一度に何件の契約書を処理できますか?
バッチあたりの契約書数に厳格な上限はありませんが、実際のスループットはご利用のサブスクリプションプランの同時実行制限に依存します。ワークフローはバッチ処理を前提に設計されています。すべての契約書をまとめてアップロードすると、結果は1つの統合スプレッドシートに出力されます。
抽出精度はどのくらいですか?
明確に記載されたデータポイント(日付、当事者名、金額)については、クリーンな文書で通常95%以上の高い精度です。極端に密度の高い、または特殊な書式の契約書、手書きの注釈、低品質スキャンでは精度が低下する可能性があります。システムは各抽出結果とともに元の画像も出力するため、検証は簡単です。任意のセルを元の文書と数秒で照合できます。抽出品質に影響を与える要因の詳細については、契約書抽出精度ガイドをご参照ください。
検索から構造化へ
CLOC調査が明らかにした2時間——契約書を探すのに45分、該当条項を見つけるのに84分——は、法律業務に費やされた時間ではありません。書類を探し回るのに費やされた時間です。この違いは重要です。なぜなら、改善可能だからです。
必要なフィールドを指定し、構造化された表として取得できるようになれば——50件の契約書、スキャンされたPDF、Wordファイル、スマートフォン写真に至るまで——レビューそのものが仕事となり、仕事の前準備ではなくなります。必要なデータポイントがすでに揃ったスプレッドシートを前に、あなたは着席します。あなたの時間は、データがどこにあるかではなく、データが何を意味するかに使われるのです。
契約書のバッチでお試しください。あなたにとって重要なフィールドを指定し、結果をご確認ください。