Anthropic「Claude for Legal」を実際に動かしてみた、日本の中小企業がNDAレビューに使えるか

はじめに(この記事の前提) 本記事は、Anthropic「Claude for Legal」を技術検証用のサンプル契約書で動かしてみた記録です。実際の法務判断には使っていません。 …

はじめに(この記事の前提)

本記事は、Anthropic「Claude for Legal」を技術検証用のサンプル契約書で動かしてみた記録です。実際の法務判断には使っていません。 弁護士の代わりになるツールではなく、社内の法務担当が弁護士に相談する前の下準備を効率化する位置付けのものです。実運用の際は必ず顧問弁護士と相談のうえで導入判断をしてください。

2026年5月12日、Anthropicは法務向けのエージェント群「Claude for Legal」を公開しました。商事・コーポレート・人事労務・プライバシー・知財・訴訟など 12種類の専門領域 に対応したプラグインと、契約管理SaaSや判例データベースに接続する 20種類以上のコネクタ が含まれています。Claude Code または Claude Cowork(同社のデスクトップ版)の上で動きます。

発表記事を読むだけでは「結局なにができるのか」が分かりにくいので、はてなベース側でローカルに正式インストールし、検証用に作った秘密保持契約書を実際に流して、仕分け結果を出させるところまで動かしました。読者対象は「自社の法務にAIをどう組み込むか」を検討している経営者・法務責任者・情報システム部門の方です。

Claude for Legalとは何か

Claude for Legalは「契約レビューAI」のような単一プロダクトではなく、Claudeに法務業務の進め方を教え込むためのプラグイン集 です。GitHub上に公開されているリポジトリを、Claude Code(コマンドラインのAIエージェント)または Claude Cowork(デスクトップアプリ版)に追加して、必要な専門領域のプラグインを入れて使います。

anthropics/claude-for-legal のGitHubページ。12種類の専門領域フォルダが並ぶ
公式リポジトリ。トップに12種類の専門領域フォルダが並ぶ

12種類の専門領域は、社内法務(in-house)・法律事務所(firm)・法科クリニックや学生向け(academic)の3つの立場をカバーします。それぞれのプラグインの中身は、6〜10種類の「スキル」(コマンド)と、定期実行される監視エージェント、そして自社の判断基準を書き込んでおく「実務プロファイル」(後述)で構成されています。

Claude for Legal の12プラグインを3列グリッドで一覧した図
12種類のプラグインと、各プラグインに含まれる主なコマンドの一覧

「実務プロファイル」が要、自社の判断基準を書き込んでおく

Claude for Legalで一番重要なのは 「実務プロファイル」と呼ばれる自社専用の判断基準書 です。たとえば商事プラグインなら「自社では秘密保持の存続期間は何年までを許容するか」「人材引き抜き禁止条項が混ざっていたら自動で要レビューにするか」といったルールを、文字で書き出してファイルに保存しておきます。

Claudeは各案件をレビューする際に、必ずこのファイルを読み込んでから判断します。社内の基準が書かれていない項目では「青(OK)」を発行しないのが仕様 で、これは「素人がデフォルト設定のまま契約書を通してしまう」事故を防ぐためのガードになっています。

今回の検証では、はてなベースの社内法務(社内2名+外部顧問1社、月10〜20件のNDA処理を想定)という架空の前提で、実務プロファイルを次のように書き込みました。

markdown~/.claude/plugins/config/claude-for-legal/commercial-legal/CLAUDE.md(抜粋)
## NDA仕分け基準

**双方向性:** 双方向(mutual)が標準。一方向はレビューの上で判断。
**契約期間:** 2〜3年が標準。5年以上は要レビュー。
**秘密保持義務の存続期間:** 3年が標準。5年超は要レビュー、10年超は停止。営業秘密は無制限可。
**除外事由(5項目):** 公知/既知/独立開発/第三者受領/法令命令——全て必要。1つでも欠落で要レビュー。
**制限的条項:** 人材引き抜き禁止/競業避止/専属性/優先交渉権が秘密保持契約に入っていたら自動で要レビュー(本来の対象外)。
**準拠法:** 日本法が標準。米国州法(NY/CA/DE)と英国法は受容可(要レビュー)。それ以外は停止。
**バックアップ保持の除外:** バックアップ・アーカイブ用途の保持除外がない場合は要レビュー。
今回の検証で使った社内基準(架空のはてなベース法務想定)。実運用では弁護士監修のうえで定義する

インストールから起動まで

Claude Codeへのインストールは3コマンドで完結します。GitHubから取得 → プラグインの置き場(マーケットプレース)として登録 → 必要なプラグインだけインストール、という流れです。

Claude Codeのターミナルでclaude-for-legalをGitHubから取得し、プラグインの一覧表示・インストール・初回ヒアリングまでを行うコマンドの流れ
ターミナルでの3ステップ:GitHubから取得 → プラグイン登録 → 商事プラグインをインストール
  1. GitHubから取得git clone https://github.com/anthropics/claude-for-legal.git でローカルに展開します。
  2. プラグイン置き場として登録:Claude Code上で「マーケットプレース追加」のコマンドを実行します。Claude Coworkを使う場合はデスクトップアプリのCustomizeタブから読み込みます。
  3. プラグインをインストール:商事担当なら commercial-legal、プライバシー担当なら privacy-legal というように、必要な領域だけ選びます。
  4. 実務プロファイルの初期ヒアリング/commercial-legal:cold-start-interview というコマンドで10〜20分のインタビュー(自社の判断基準を聞き出す対話)に答えると、基準書が自動で書き出されます。簡略版は2分で済ますこともできます。

実務プロファイルなしでは動かない

公式の説明にも繰り返し書かれていますが、実務プロファイルが空のままだとほぼ全ての判定が動きません。「素人がデフォルト設定で署名フローを通してしまう」事故を防ぐ仕組みなので、最初の数週間は 顧問弁護士と一緒に基準書を埋める作業 に時間を使うのが現実的です。

検証:問題のある契約書を実際に流してみる

検証用に、「内製レビューで詰まりがちな秘密保持契約書」を1本作りました。米国デラウェア州法人「サンプル海外社(仮称)」との双方向の秘密保持契約という想定で、次の4〜5箇所に意図的な引っ掛かりを仕込んでいます。

  • 第4条:契約期間10年+存続期間10年(実質20年) — 社内基準書では5年超で要レビュー、10年超で停止と規定
  • 第6条:非勧誘条項(人材引き抜き禁止) — 本来は秘密保持契約の対象外
  • 第2条:除外事由が5項目中3項目しかない — 独立開発・法令命令が欠落
  • 第5条:バックアップ保持の除外文言なし — Google Driveやメールアーカイブと矛盾
  • 第7条:準拠法が米国デラウェア州法 — 社内基準書では要レビュー扱い
サンプル海外社との双方向秘密保持契約書(検証用)。第4条の10年+10年、第6条の非勧誘、第7条のデラウェア州法など問題箇所を赤字で強調
検証用に作ったサンプル契約書。赤字部分が社内基準書に引っかかる箇所

このサンプル契約書を、Claude Codeのコマンドライン上で /commercial-legal:review というコマンドに渡します。Claudeは文書の冒頭から「これは秘密保持契約だな」と判定して、自動的に秘密保持契約用の仕分けスキル(nda-review)にルーティングします。スキル側は次の4段階を順に踏みます。

  1. 実務プロファイル(社内基準書)の読み込み — 自社の判断ルールを確認
  2. スコープ確認 — 秘密保持以外の余計な条項(人材引き抜き禁止など)が混ざっていないかチェック
  3. 個別論点の判定 — 各条項を青(GREEN・問題なし)/黄(YELLOW・要レビュー)/赤(RED・停止)に分類
  4. 次のアクション提示 — 顧問エスカレーション・修正案の起案・ヒアリング・見送りなどの選択肢を提示

実際の出力:黄(YELLOW)判定と6項目の指摘

Claude Codeを別セッションで起動し、実際にスラッシュコマンドとして /commercial-legal:review を流した結果がこちらです。総合判定は「黄(要レビュー)」 で、6項目の指摘と4項目の合格判定が並びました。

実機の仕分け結果。総合判定YELLOWで6項目を指摘、合格項目4項目、次のステップとして顧問エスカレーション推奨
Claude Codeで実際に流した結果。意図的に仕込んだ5箇所をすべて検出し、合計6項目を要レビューとして報告

想定と違っていたところ

実は記事執筆前の予測では、契約期間10年+存続10年=実質20年を 赤(停止) として判定すると思っていました。実機では「契約期間10年は要レビュー」「存続10年もそれ単体では境界線」と 別個に評価 され、総合判定は 黄(要レビュー)の積み上げ という結論でした。社内基準書の文言をどう書くか(合算評価するかどうか)で判定が変わるので、基準書のチューニングは継続的に必要だと分かりました。

論点結果社内基準書での根拠推奨対応
第4条 契約期間10年🟡 要レビュー2〜3年が標準、5年以上は要レビュー短縮を打診、長期パートナーシップなら受容も検討
第4条 存続期間10年🟡 要レビュー3年が標準、5年超は要レビュー、10年超は停止3〜5年へ短縮、営業秘密のみ別建てで無制限
第6条 非勧誘条項🟡 要レビュー(自動)制限的条項はNDA対象外削除を要求、残すなら別契約に切り出し
第2条 除外事由不足🟡 要レビュー5項目すべて必要独立開発・法令命令の2項目を追加
第5条 バックアップ除外なし🟡 要レビュー保持除外は必須標準の例外文言を追加
第7条 準拠法デラウェア州法🟡 要レビュー米国州法は受容可(要レビュー)日本法・東京地裁を一度打診、執着なければ受容可

面白いのは、仕分け結果の末尾に「次のアクション」の選択肢 が並ぶことです。今回のケースだと「顧問エスカレーション」「修正案起案」「ビジネス側へのヒアリング」「様子見」「その他」の5つが並び、社内法務担当(弁護士でない人)はこの選択肢から動きを決められるようになっています。AIが勝手に署名フローを進める設計には絶対にせず、必ず人間が判断する形が随所に組み込まれています。

触ってみてわかった4つの設計思想

GitHubのコードを読みながら実際に動かしてみて気づいた、Anthropicの設計思想を4点に整理します。

1. すべての判断は社内基準書に従う

Claude for Legalの内部コードを読むと、各スキルは「秘密保持義務は何年からダメ」といった具体的な閾値を 一切ハードコードしていません。判定ロジックは「実務プロファイルのこの項目を読みなさい」とだけ書かれていて、実際の閾値は自社が初回ヒアリングで答えた内容に依存します。法域・業界・リスク許容度が違う組織で同じスキルが汎用的に使える代わりに、最初の基準書を埋める作業がそのまま導入コスト になります。

2. 「弁護士レビュー前提」の徹底

出力の冒頭には必ず「未レビュー — 顧問弁護士の確認が必要」というヘッダーが付き、末尾には「次の判断は人間が決めてください」という選択肢が並びます。社内法務(非弁護士)が使う前提で起動した場合、青(OK)判定を出す前にも「弁護士に見せましたか?」を尋ねるゲートが挟まります。社内基準書がデフォルトのまま青を出すことを構造的に禁止 している点が印象的です。

3. 修正提案は最小単位で

契約書に修正案(赤入れ)を当てる粒度について、スキルの中身に細かい指示が書かれています。たとえば「12カ月」を「24カ月」に変えるなら、節全体を書き直すのではなく数字だけを修正 するように指示されています。条文全体を派手に書き直してしまうと相手の心象を悪くするため、ベテラン契約レビュー担当者の作法がそのままAIのプロンプトに落とし込まれているのが分かります。

4. 既存リーガルテックと共存する設計

契約管理SaaS(Ironclad / DocuSign / iManage / NetDocuments)、電子証拠開示(Everlaw / Relativity)、判例リサーチ(LexisNexis / Thomson Reuters CoCounsel / CourtListener / Trellis)といった既存サービスへの接続コネクタが20種類以上同梱されています。Claudeが既存ツールと競合するのではなく、ClaudeがCLMやリサーチDBを呼び出して使う という関係です。特にThomson Reutersの「CoCounsel」とは双方向接続になっており、Claude側からCoCounselを呼べる一方、CoCounsel側からもClaudeを呼べる構造になっています。

日本の中小企業が使うときに気をつけたい3つの論点

プラグインの考え方は日本の法務にもそのまま転用できますが、実運用に乗せる際に整理すべき論点が3つあります。

  1. 準拠法と判例リサーチの問題:プラグインは米国法・英国法ベースの言い回しが標準で、リサーチコネクタもLexisNexisやCourtListenerなど英米系が中心。日本法務での使用には、社内基準書に「日本法・東京地裁ベース」と書き込んだうえで、判例リサーチは別経路(D1-Law、Westlaw Japan等)と組み合わせる必要があります。
  2. 社内基準書を誰が書くか:「弁護士レビュー済みの基準書でないと青判定を出さない」仕様のため、社内法務だけで基準書を埋めると永久に青が出ません。最初の初回ヒアリングには顧問弁護士に同席してもらう という運用設計が現実的です。コスト的にも初期投資として顧問の時間を確保するのが妥当でしょう。
  3. 情報の出口管理:仕分け結果の末尾に「legal@yourcompany.com に送信」などのクロージングアクションを設定できる反面、誤って公開チャネル(社外Slack、取引先送付)に流す事故も起こり得ます。プラグインには情報の宛先を毎回確認する仕組みがありますが、それでも社内のチャネル運用ルールと突き合わせて使うべきです。

弁護士の代替ではない、という点を改めて強調

Claude for Legalは 「弁護士の仕事を奪うツール」ではありません。むしろ「弁護士がレビューすべき契約を絞り込み、社内法務の手前にいる事業担当者の自己判断を支援する」ツールとして設計されています。最終判断と責任は必ず弁護士が取る前提です。導入時には必ず顧問弁護士と相談し、自社のリスク許容度・業界特性・法域に合わせたチューニングを行ってから運用してください。

結論:どんな企業に向くか

実際に動かしてみたうえでの所感として、現実的な導入価値が高そうなのは次のような組織です。

  • 月10〜30件の相手方NDAを受領するスタートアップや中堅SaaS企業 — 顧問への取次コストを下げたい場合
  • M&Aデューデリジェンス、社内調査、コンプラ規制の継続監視など、反復性は高いが個別事情で揺れる業務 を抱える法務部門
  • AIガバナンス・プライバシー領域で 影響評価書(DPIA/AIA)、情報開示請求への応答 をテンプレ化したい大企業
  • 法科クリニックやロースクールで、学生のリサーチや起案ワークフローを標準化したい教育機関

逆に「基準書を書く時間がない」「弁護士監修を入れる余裕がない」という状況では、出力が空打ちになるか、要レビュー判定が積み上がるだけで効果が出ません。最初の数週間で基準書を丁寧に整える という導入工程をどれだけ確保できるかが、効果を左右します。

AI法務エージェントの導入を検討中の企業さまへ

はてなベースでは、ClaudeやClaude Codeを使った業務エージェントの設計・組み込み・社内基準書の整備を支援しています。法務・経理・人事労務などの専門領域へAIを安全に組み込むためのアーキテクチャ設計と、現場での導入伴走をワンセットで提供します。

AI業務エージェント導入の相談をする