契約書レビューのSpellbookは、Claudeを使ったレビュー用エージェントで月に約530,000件の契約書を処理していると公表しました。加えて、実務の弁護士から月に700,000件を超えるチャットメッセージが届いているとしています。注目したいのは処理量そのものではなく、そこに至るための設計です。同社はレビューの画面だけで約15のエージェント構成を持ち、サブタスクの難しさに応じてモデルを変えています。この記事では、公表されている構成と数値、そして「何をAIに任せ、何を人に残したか」の線引きを確認し、日本の実務者が読み替えられる点を整理します。効果を保証する記述は出典にないため、ここでも書きません。
どんな会社か
Spellbookは契約書のレビューと作成を支援するリーガルテック企業です。導入事例には、2022年の立ち上げ以降、80カ国の5,000社にまで広がり、法律事務所から、LG、Dropbox、eBayといった企業の社内法務チームまでが利用していると記載されています。従業員は250人です。
処理の規模も同じページに記載されています。Claudeを使ったレビュー用エージェントが毎月およそ530,000件の契約書を処理し、それとは別に、実務の弁護士から月に700,000件を超えるチャットメッセージが届いているという書き方です。従業員250人の会社が扱う件数としては大きく、人手だけで同じ量を捌く前提には立っていないことが分かります。
公式サイト側の表記は少し異なります。こちらでは、利用しているリーガルチームの数を4,500以上、対象を80カ国以上としています。同じ会社の2つのページで数え方が違っているため、どちらか一方を「正しい数字」として扱うことはできません。この記事では両方の表記をそのまま並べます。
製品の位置づけは、公式サイトのコピーで「Contracts at the speed of commerce」と表現されています。メールやSlack、Salesforceからの受け取り、自社の基準に沿ったレッドライン（修正案）の作成、締結済み契約の検索という3つの段階で構成されています。表示されている導入企業には、Dropbox、AtkinsRéalis、ASICS、Kennedys、KMSC Law LLP、Westaway Lawが並んでいます。
何が問題だったのか
CEO兼共同創業者のScott Stevenson氏は、AI導入前の作業をこう説明しています。「弁護士は50ページの契約書をMicrosoft Word上でレビューし、問題や誤りを見つけるために一行ずつ読み、手作業で編集し、契約書のあいだでコピー＆ペーストしていた」。
ここで効いているのは、作業量よりも作業の性質です。同氏は「AIは論点の抽出がとても得意で、人間はあまり得意ではない」と述べています。長い文書のなかから見落としなく問題箇所を拾う作業は、人間の集中力が最も落ちやすい種類の作業です。時間がかかるうえに、疲れるほど精度が落ちます。ここを機械に渡すという判断が、この事例の出発点になっています。
導入事例には、この作業がどう変わったかも数値で記載されています。1件の契約をまとめるまでの時間が10倍速くなり、弁護士の作業時間でおよそ10時間かかっていたものが約1時間になった、という書き方です。
モデルを役割で使い分ける
この事例でいちばん具体的なのが、モデルの使い分けです。導入事例には「契約書のレビューだけで約15のエージェント構成を動かしており、最も複雑なサブタスクにはOpus 5、速度と会話的なトーンのほうが重要な場面ではOpus 4.6とSonnet 4.6を使う」と記載されています。ひとつのモデルで全部をやる構成ではありません。
さらに、モデルを評価するためのモデルも置いています。シニアエンジニアのJordan Weir氏は「Fableをオラクルモデルとして使い、評価基準の一式を生成させたうえで、社内のリーガルエンジニアと領域の専門家が手作業でレビューする」と説明しています。同氏はFableについて「他のどのOpusモデルよりも、重要な論点を拾い、しかも拾い方が一貫している」とも述べています。Stevenson氏の言い方では「Opus 5も良いが、実際にはFableのほうが賢い」となります。
作業の分担も同じ考え方です。Weir氏は「Fableは大きなモデルなので、計画を書かせる。それをSonnetのような小さいモデルが実行する。そのあと、結果をFableにレビューさせる」と述べています。計画・実行・検証を別のモデルに割り当てる形です。
なぜこの分担が要るのかについて、同氏は文書の数で説明しています。「5つの文書を編集するなら簡単だ。20なら難しくなる。20の文書を、他に1,000件の文書を文脈に入れた状態で編集するなら、さらに難しい」。扱う文脈が増えるほど、一貫性を保つ難易度が上がるという指摘です。
価値がある場所はモデルの外にある
この事例で見落とされやすいのが、Stevenson氏の次の発言です。「私たちが加えている価値のほとんどは、モデルの周りを包んでいるハーネス（構造）の側にある」。
同社は提案の質を測る仕組みも持っています。「私たちが出すすべての提案について、実際に利用者がどれだけ採用したかを計測している」という説明です。生成したかどうかではなく、採用されたかどうかを見ています。この計測があるから、モデルを差し替えたときの良し悪しを判断できます。
Weir氏の「昨年のOpus 4.6は文句なく画期的だった」「この3年間で、Anthropicが他のどこよりも大きく先行していた場面が何度もあった」という発言も、裏を返せば、モデルは入れ替わり続けるという前提に立っているということです。入れ替わることを前提にすると、自社の資産はモデルそのものではなく、評価基準、計測、業務の分解の側に置くしかありません。
公表されていないこと
導入事例には書かれていないことも確認しておきます。価格体系と売上の数字はありません。エラー率や精度の指標も、一貫性についての言及を除けば記載がありません。どの契約類型でうまく動き、どこで苦手かの内訳もありません。他社のAIとの比較データもありません。
したがって、この事例から「AIを入れれば契約レビューが10分の1になる」と読むことはできません。読めるのは、ある1社が公表した構成と、その会社が公表した処理量までです。
日本の実務者が読み替えられる点
第一に、AIに渡す作業を「量が多い作業」ではなく「人間が構造的に苦手な作業」から選ぶという考え方です。同社が最初に渡したのは論点の抽出でした。長文から漏れなく拾う作業は、人が疲れるほど質が落ちる種類の仕事です。マーケティングの現場でも、大量の問い合わせ内容の分類、広告文の表記ゆれの検出、レビュー本文からの不満点の抽出などが同じ性質を持ちます。
第二に、モデルを1つに決めないという設計です。難しい判断には大きいモデル、速さと会話のトーンが要る場面には軽いモデル、という割り当ては、費用と応答速度の両方に効きます。最初から使い分けを前提に業務を分解しておくと、モデルが入れ替わっても構成を組み替えるだけで済みます。
第三に、計画・実行・検証を分けることです。同じモデルに一気通貫でやらせると、自分の出力を自分で検証することになります。別のモデルにレビューさせる形にしておくと、検証の観点が独立します。人が入る場合も同じで、作った人と確認する人を分ける原則をそのまま持ち込んでいます。
第四に、採用率を測ることです。AIが何件生成したかは、それ自体では成果ではありません。人がその提案を採ったかどうかまで測って初めて、良し悪しを言えます。導入の前に、この計測をどこに置くかを決めておく必要があります。
第五に、人が残す仕事を先に決めることです。この事例では、評価基準の手作業レビューをリーガルエンジニアと領域の専門家が担っています。最終的な判断と交渉は弁護士の側にあります。何を渡すかより、何を渡さないかを先に書いておくほうが、運用は安定します。
なお、これらはあくまで公表された構成から読み取れる考え方です。同じ構成にすれば同じ結果が出ると述べているものではありません。扱う文書の性質、社内の基準の整備状況、確認体制によって結果は変わります。
出典と注記
この記事はClaudeの導入事例ページとSpellbookの公式サイトのみを出典とし、数値・発言・モデル名は原文の表記に従いました。導入社数は、導入事例と公式サイトで表記が異なるため、どちらも併記しています。価格、売上、精度の指標、他社製品との比較は公表されていないため記載していません。モデルの構成は変更される可能性があるため、参照する際は出典ページで最新の記述を確認してください。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。