海外の法務AIとして「CoCounsel」 (海外の法務情報企業傘下の法務特化AIとして日本でも検索される代表的なサービス) という名前を、海外法務に関わる事務所の方から聞くことが増えてきました。同じく海外法務AIとして知られるHarveyと並べて語られることが多いのですが、出自・構造・差別化軸はかなり違います。本稿では、CoCounselを入り口の例として挙げつつ、この種の「法務情報企業傘下の法務AI」の設計を業務の視点で読み解き、日本の士業事務所が持ち帰れる発想をご紹介します。
機能・対応範囲・価格は更新が早い領域ですので、本記事は公開情報に基づいた整理として読んでいただき、検討時には公式情報の最新版をご確認ください。
CoCounselという製品の輪郭
CoCounselに代表されるDB連携型の海外法務AIは、海外の法務情報企業傘下のサービスとして展開されています。親会社が長年にわたり蓄積してきた法務リサーチデータベース・ノウハウ製品群と接続する位置づけで設計されています。
スタートアップ独立系の海外法務AI (Harvey等) が「大手法律事務所と組んでプロダクトを磨く」 方向で展開しているのに対し、DB連携型は「親会社が所有する法務データベース資産との接続」 を差別化軸に置いている、 という整理になります。
沿革 — 法務情報企業傘下のAI製品としての展開
この種のDB連携型AIの起源は、海外の法務テック企業が開発していたAI法務アシスタントです。法務情報業界の大手企業が同社を買収したのを機に、親会社の法務スタックと統合される形で展開されています。
親会社はもともと、法務リサーチデータベースと、ノウハウ・ワークフロー製品を傘下に置いていました。AI法務アシスタントの取得は、これら既存スタックに生成AIレイヤーを足す動きとして読み取れます。
買収以後、ユーザー数を拡大し、法務プラクティスマネジメントソフトとの統合パートナーシップ等も発表されています。親会社の主力AI製品の一つに位置づけられてきた、 と読み取れます。
設計上の親会社は法務情報企業であり、自社の法務データベース資産との接続が、製品の重心になっています。
法務リサーチDBと接続するという設計
この種のAIの設計を理解するうえで重要なのは、親会社が法務リサーチ業界の主要データベースを所有している、 という構造です。
親会社は、米国を中心とした法令・判例・二次資料のリサーチデータベースと、実務向けノウハウ・テンプレート・チェックリスト・ガイダンスを提供する製品を、いずれも傘下に置いています。これらの法務事業の中核資産との接続が、 製品の特徴になっています。
公式情報では、親会社のこれら法務データソースに接続して回答を生成する位置づけが打ち出されています。汎用LLMのように学習データから一括生成する構造ではなく、 親会社の信頼性の高い法務データベースを参照源として組み込む、 という形になっています。
ただし、これらのデータベースは米国・英国・コモンウェルス系の法体系を中心にカバーしていて、 日本の法令・判例・行政通達への対応範囲は本記事執筆時点では限定的なようです。日本の士業事務所が「海外の法務DB連携AI」 を眺めるとき、 日本法のリサーチに直接効く構造ではない、 という点は最初に押さえておきたいところです。
主要機能群は、公式情報・関連報道から読み取れる範囲では、 契約レビュー、法務リサーチ、訴訟特有の準備支援、大量文書のレビュー・要点抽出、書面・メモ・通信の起案補助、親会社のDB・所内文書への横断問い合わせ、といったラインナップになっています。
設計の特徴として読み取れるのは、 法務専門タスクをテンプレ化していること (「何でも聞ける窓口」 ではなく契約レビュー・準備・リサーチといった業務単位に機能が分かれている)、 親会社の公式データベースを参照源として組み込んでいること、 そして単独SaaSではなく親会社の製品スタックや法務プラクティスマネジメントソフトに組み込まれる方向で展開されていることです。
汎用LLMを法務に直接転用したときに起きやすいこと (架空判例の引用、出典の曖昧さ、既存業務との二重作業) への応答として、これらの設計が選ばれている、 と読めます。
スタートアップ独立系の海外法務AIとの重心の違い
DB連携型と、スタートアップ独立系の海外法務AI (Harvey等) は、海外では並べて語られることが多いのですが、 出自と設計の重心は別物です。公開情報の範囲で対比を整理してみます。
| 観点 | DB連携型 (CoCounsel等) | スタートアップ独立系 (Harvey等) |
|---|---|---|
| 親会社・出自 | 法務情報企業傘下 | スタートアップ独立系 |
| 主要投資家 | (親会社が法務情報業界の大手) | 著名VCからの大型資金調達が継続 |
| 強み | 親会社の法務データベースとの連携 | 大手法律事務所とのパートナーシップ型開発 |
| 設計の重心 | 既存の法務リサーチ資産にAIレイヤーを足す | 業務単位 (アシスタント / 文書保管庫 / 調査 / エージェント) でAIを分割 |
| 流通形態 | 親会社の法務スタック・プラクティスマネジメントソフトへの組込み | エンタープライズ契約・パートナー事務所との共同開発 |
DB連携型は「法務情報業界の大手がAIレイヤーを内製化した製品」、 独立系は「AIスタートアップが大手事務所と組んで磨いている製品」 という対比になります。どちらが優れているという議論ではなく、 既存資産の信頼性を取りに行くDB連携型と、 ワークフローの磨き込みを取りに行く独立系、 という重心の違いとして理解しておくと整理しやすくなります。
日本の士業事務所が持ち帰れる発想
DB連携型AIの構造から、 日本の士業事務所が持ち帰れる発想をいくつかご紹介します。
専門AIの差別化軸は、親会社が持っている信頼資産にあるという読み方です。この種のAIの差別化軸はAIモデルの優位性ではなく、 親会社が所有する法務データベースの側にあります。日本国内のツールを選ぶときも、「どのLLMか」 より「何を参照源として接続しているか」 が選定の主要軸になっていきそうです。
判例・条文DBとの接続を前提に設計する、 という発想も持ち帰りやすいです。法務情報企業傘下の海外AIが法務DB連携を中核にしているように、 日本でも判例検索DB・法令データ・通達データとの接続を前提にAI利用を設計する形が現実的になります。
単独SaaSより既存業務システムに組み込む、 という流れも参考になります。DB連携型AIが親会社の製品スタックやプラクティスマネジメントソフトに組み込まれる方向で展開されているのと同様、 日本の事務所でも「AIツールを単独で買う」 より「既存の文書管理・案件管理にAIを組み込む」 発想に切り替える事務所が増えてきています。
海外DBが日本法をカバーしない領域は、 別経路で組む必要があります。海外法務情報企業のDB連携は日本法のリサーチには直接効きません。日本法対応は、国内法務SaaS・判例検索サービス・公式行政データベースとの組み合わせで構成する設計が現実解になりそうです。
「海外法務AIが日本に来れば全部解決する」 という見立ては素朴すぎる読み方になります。学ぶ価値があるのは「特定の製品そのもの」 ではなく、「親会社の信頼資産をAIレイヤーに接続する構造」 のほうです。
セキュリティとコンプライアンスで業務として確認しておくこと
DB連携型を含む海外専門AIを日本の士業事務所が検討するとき、 業務として確認しておきたい論点をいくつかご紹介します。
データレジデンシーの確認は最初に出てくる場面です。依頼者情報・顧問先情報の保管リージョンが国外 (米国・EU等) になる可能性があるため、 依頼者・顧問先への説明、 利用目的通知、 必要に応じた同意取得を業務の流れに置いておきます。
学習利用の可否は契約書面で確認します。エンタープライズ契約・API経由で「入力データを学習に使わない」 契約条項が確保されているかを書面で押さえておきます。無料プラン・個人プランは士業業務での利用は原則回避、 という運用を取っている事務所もあります。
出典確認の運用も省略しにくい場面です。海外法務AIが公式DBを参照源にしていても、 最終書面の出典は人手で原典照合する手順を業務の流れに置いておきます。「DB連携AIだから誤引用ゼロ」 という前提は、 点検する価値があります。
ログ・監査証跡については、 誰が・いつ・どの案件でAIに何を入力したかを追える状態を作っておきます。事故発生時の依頼者報告・所属会報告のときに、 後から経緯を振り返れる状態がある形です。
利益相反・オフボーディングは、AI導入時にも一般的な情報管理ルールと同じ枠で整理します。案件ごとの利益相反、 退職時のアカウント停止、 共有IDの禁止などです。
個人情報保護委員会の注意喚起の射程も確認しておきます。2023年6月2日付「生成AIサービスの利用に関する注意喚起等について」 では、 入力データの第三者提供該当性・学習データへの取り込みなどが論点として整理されていて、 海外専門AIを導入する場合もこの注意喚起の射程に入ります。
守秘義務との接続も間に置いておきます。弁護士法・税理士法・社労士法等の守秘義務規定、 所属会のAI利用ガイドラインとの整合性は、 利用開始前に確認しておきたい場面です。
「法務情報業界の大手の製品だから安全」 「公式DB連携だから誤引用ゼロ」 という認識は、 業務の実態とずれることがあります。自事務所の責任で、 契約条項・保管場所・運用フロー・ログを設計しておくと、 後から困りやすい場面が減ります。
読み解くときの視点
DB連携型の海外法務AIを読み解く際の視点を、 ここまでの議論からいくつかご紹介します。
製品ではなく構造を見るという視点が一つです。「公式法務DBに接続するAI」 だという事実より、「親会社の信頼資産にAIレイヤーを足す」 という構造のほうが、 日本の業務環境に持ち帰る価値があります。
法域の差を最初に確認しておくと、 検討の解像度が上がります。海外の法務DBが日本法をカバーしていない以上、 海外AIの機能リストを日本業務にそのまま当てはめても効かない領域が出てきます。クロスボーダー案件・英文契約・海外子会社対応など、 効く領域と効かない領域を最初に分けておきます。
基盤と製品を分けて評価する場面も多いです。海外法務AI製品の評価軸と、 その背後で動いているLLM・データベース・クラウドの評価軸は別物です。製品の宣伝文句と、 契約・データ取扱いの条件は分けて確認します。
海外専門AIの到来を待たない選択肢もあります。「海外法務AIの日本版が出るのを待つ」 という構えは受動的になりやすいですが、 設計思想だけ持ち帰り、 国内SaaS・判例検索・業務システムの組み合わせで近い設計に到達することは、 既に可能な範囲があります。
「DB連携AIだから誤引用ゼロ」 という前提は置かないほうが、 業務として安全です。海外法務AIが公式DBを参照源にしていても、 最終書面の出典は人手で原典照合する手順を残しておきます。架空判例の引用による制裁事案は、海外でも国内でも、AI機能の有無ではなく利用側の運用設計から生じている、 と公開事例の系列を見ると整理できます。
2製品比較ではなく3層構造で並べて見るという視点も参考になります。「どの海外法務AIがいい?」 という問いより、「基盤モデル / 業務UI / 業務特化アプリ、 自所はどの層で意思決定しているか」 という問いのほうが、 議論の解像度が上がります。DB連携型は業務特化アプリ層の選択肢の一つ、 として位置づけて検討する形です。
DB連携型AIは「導入すれば日本法務が解決する製品」 ではなく、「親会社の信頼資産にAIレイヤーを接続する構造」 として読むものだと整理しておきたいところです。日本側のデータベース・業務システム・契約条項とどう接続するかは、 海外専門AIが国内対応する前から、 設計の余地がある領域です。
参考
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」 (2023年6月2日): https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- 経済産業省・総務省「AI事業者ガイドライン」: https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
- 日本弁護士連合会 (公式): https://www.nichibenren.or.jp/