とりあえず Legal Plugin を試してみたいだけで、長期的に使うかどうかまだ決めていない場合でも、先に legal.local.md をカスタマイズする時間を取る必要がありますか？
この Plugin のインターフェースやレポートの形式がどんな感じかをざっと把握したいだけなら、デフォルト値のまま一度 /review-contract を実行してみて問題ない——それだけで GREEN／YELLOW／RED の分類、条項ごとの分析、修正提案といった機能が実際にどう出力されるかをすぐに体感できる。しかし、出てきた分析結果を本気で受け止め、実際にある契約書に署名すべきかどうかを判断したり、特定の条項について交渉すべきかどうかを決めたりするつもりなら、その瞬間からデフォルト値と自社が実際に置かれている司法管轄区とのギャップが、その判断の質に直接影響してくる。
より現実的な分け方は、デフォルト値で「このツールが使い物になるか」を試し、カスタマイズした playbook で「この分析結果を信頼してよいか」を判断することだ。前者はプロダクトの評価であり、後者は実際の依存であって、必要な準備の量が異なる。
当社は台湾に拠点があり、アメリカ企業と契約を結ぶ業務もあります。この場合、playbook はどう設定すればよいですか？
このような状況では、どちらか一方（台湾基準のみ、あるいはアメリカ基準のみ）を選ぶのではなく、playbook の「許容範囲」の項目を両方のシナリオをカバーできるように設計するほうが現実的だ。準拠法条項を例にとると、「標準的な立場」は自社の主な事業所在地（台湾）の法律に設定し、「許容範囲」にはアメリカ企業との契約でよく見られる準拠法の選択肢（ニューヨーク州、デラウェア州など）も併せて列挙し、その横に台湾の規制と乖離しうる点（データ保護の通知期限など）で特に注意すべきことを注記しておくとよい。
つまり legal.local.md のカスタマイズとは、一組の基準を一度だけ書いて固定することではなく、まず自社が実際に取り交わす契約がどの司法管轄区にまたがっているかを棚卸しし、その違いを「エスカレーションのトリガー条件」に明示的に書き込むことだ。例えば「準拠法がアメリカの州法であり、かつデータ保護条項に関わる場合は、必ず弁護士のレビューにエスカレーションする」といった具合に、どの組み合わせが特に慎重な対応を要するかを Claude に伝えておくことで、すべての契約書が同じロジックに当てはまると仮定せずに済む。
legal.local.md のカスタマイズは法務チームだけで対応できますか、それともエンジニアや IT 部門の協力が必要ですか？
法務チームだけで完結でき、エンジニアや IT 部門の協力は不要だ。このファイルは本質的に構造化された Markdown テキストファイルであり、法的立場や基準を箇条書きで列挙する内容で、プログラミング構文は一切含まれない。Anthropic のサンプルファイルは見出しと箇条書きを使って「標準的な立場」「許容範囲」「エスカレーションのトリガー条件」といったカテゴリの情報を並べているだけで、契約審査のロジックに詳しい法務担当者であれば誰でも直接編集でき、社内向けの契約審査ガイドライン文書を書くのとほぼ同じ技術的難易度だ。
本当に必要な準備は、これまでベテラン弁護士の経験の中にしか存在せず体系的に文書化されてこなかった判断基準を、明文化することだ——これ自体は想像以上に時間がかかるかもしれないが、難しいのは「自社の交渉基準を棚卸しして整理する」というナレッジワークであって、技術的な操作のハードルではない。保存場所もシンプルで、すでに Cowork に共有しているフォルダに置くだけで Plugin が自動的に見つけてくれるため、追加のデプロイや設定作業は不要だ。
当社が legal.local.md を今すぐ完全にカスタマイズする時間を取れない場合、現実的な折衷案はありますか？
ある。段階的なカスタマイズ戦略を取り、リスクが最も高く実害につながりやすい条項カテゴリーから優先的に対応する方法だ。多くの企業に共通する契約類型で見ると、準拠法条項とデータ保護条項の2つが最優先項目になる。前者は分析全体の比較基準がそもそも成立するかどうかを左右し、後者は規制遵守に直結し、誤判定が実質的なコンプライアンスリスクにつながりかねない。他の条項（知的財産権の帰属の細部など）が当面デフォルトのままだとしても、この2つは優先的にカスタマイズする価値がある。
もう一つの現実的な方法は、エスカレーションのトリガー条件に「準拠法またはデータ保護条項の比較基準がまだカスタマイズされていない場合は、一律で弁護士のレビューに回す」ことを明示的に設定しておくことだ。これにより、完全なカスタマイズが終わる前の段階でも一種の防波堤を設け、これらの高リスクカテゴリーがアメリカのデフォルト値だけで GREEN と判定されてそのまま通ってしまうことを防げる。この方法で最大のリスク露出をまず下げてから、他の条項カテゴリーを徐々に補っていくとよい。
Anthropic がオープンソース化した Knowledge Work Plugins の中で、最も話題を呼んだのがLegal Pluginだ——GREEN／YELLOW／RED の三色フラグで契約条項を逐条レビューするこの Plugin の発表は、Thomson Reuters や RELX といった法律テック企業の株価をその日のうちに10%以上下落させるほどのインパクトを持ち、Jefferies グループはこれを「SaaSpocalypse」と呼んだ。しかしほとんどのチュートリアル記事はインストール方法と使い方に終始しており、公式ページに書かれた見落としやすい免責事項——この Plugin はデフォルトでアメリカの司法管轄区の基準を採用しており、アメリカ国外で事業を行う企業がそのまま使うと、自社の契約書を誤った法的枠組みで審査してしまう可能性がある——を丁寧に扱った記事はほとんどない。
Legal Plugin の GitHub ページには、一語一語読む価値のある一文がある：この Plugin に組み込まれたデフォルトの playbook 例は、アメリカの法的立場と司法管轄区（デラウェア州、ニューヨーク州、カリフォルニア州）を反映したものであり、異なる法体系（EU、UK、オランダ、オーストラリアなど）で事業を行っている場合、この Plugin の分析結果に頼る前に、`.claude/legal.local.md` で playbook を自分の司法管轄区の具体的な法的要件、標準契約条項、コンプライアンス義務に合わせてカスタマイズしなければならない、とある。ここで使われているのは「must」であり「推奨」ではない——つまりこれはあってもなくてもよいカスタマイズ項目ではなく、Anthropic 自身が必須の前提として位置づけているものだ。
Legal Plugin の中核的な仕組みは、契約書を `legal.local.md` で定義した標準的な立場、許容範囲、エスカレーションのトリガー条件と照らし合わせることだ。Anthropic が提供するサンプルファイルには、責任制限条項（標準的な立場：双方の支払済み・支払予定手数料の12か月分を上限とする相互キャップ）、補償条項（標準的な立場：知的財産権侵害とデータ侵害に対する相互補償）、知的財産権の帰属、データ保護要件（標準的な立場：個人データを処理する場合は DPA が必要、72時間以内の侵害通知）、契約期間と解約、準拠法条項が含まれており、その「標準的な立場」と「許容範囲」のすべてが、アメリカの商慣習をデフォルト値として書き込まれている。
Plugin をインストールし、サンプルファイルに手を加えずに契約書のレビューを始めると、Claude はアメリカの商慣習に照らして契約書を比較する——例えば「72時間以内のデータ侵害通知」を標準値として比較対象にする。しかし、自社が事業を行う司法管轄区が求める通知期限がこの数字と異なる場合、Claude は実際には完全に準拠している条項を「修正が必要な逸脱」としてフラグ付けしてしまうかもしれない。逆に、自社の司法管轄区では明らかに問題があるにもかかわらず、たまたまアメリカの慣習と一致している条項を GREEN としてそのまま通してしまう可能性もある。これは Claude の判断ミスではなく、設定された（あるいは設定されなかった）基準を忠実に実行しているだけだ——カスタマイズしていなければ、Claude が使えるのは組み込みのアメリカのデフォルト値だけになる。
サンプル playbook における準拠法条項のデフォルトの標準的立場は、文字通り「[あなたの司法管轄区]」というプレースホルダーのまま記載されており、許容範囲には NY、DE、CA、England & Wales といった主要な商業司法管轄区が列挙されている。このプレースホルダーに一切手を加えなければ、Claude が準拠法条項を評価する際のロジックは空のままか、アメリカの慣習を誤って適用したものになる——これはまさに「カスタマイズしていないこと」が最も直接的に露呈する箇所だ。ある契約書で準拠法として台湾法が指定されていて、それをデフォルトの playbook でレビューすると、Claude は対応する比較基準が見つからずどう評価すればよいか分からなくなるか、無関係なアメリカの司法管轄区の慣習を誤って適用してしまう可能性が高い。
朗報は、`legal.local.md` のカスタマイズにプログラミングは不要だという点だ。これは構造化された Markdown ドキュメントに過ぎず、各条項の「標準的な立場」「許容範囲」「エスカレーションのトリガー」を、自社の司法管轄区と実際の立場に合わせて書き換えるだけでよい。このドキュメントは本質的に、これまでベテラン弁護士の頭の中にしかなかった交渉基準を、Claude が参照できる形で明文化したものだ——言い換えれば、このカスタマイズという作業は、新人弁護士を迎え入れて自社の契約審査基準を教え込むのとまったく同じことをしているに過ぎず、今回教える相手が Claude であるというだけだ。保存場所もシンプルで、Cowork にすでに共有しているフォルダ内であればどこでもよく、Plugin が自動的に見つけてくれる。
自社がアメリカ国外で事業を行っているなら、Legal Plugin をインストールした後まず最初にすべきことは、急いで `/review-contract` を試すことではなく、`legal.local.md` の各条項を自社の司法管轄区に合った内容に書き換える時間を取ることだ。これは一度やっておけばよく、以降の契約レビューはすべてこのカスタマイズされた基準の上に成り立つ。もし自社がたまたまアメリカを拠点とし、採用している契約慣習がサンプルのデフォルト値に近いのであれば、このリスクの影響は限定的だ。しかし「自社が具体的にどのような標準的立場を採用しているか正直よく分からない」というのが答えであるなら、それこそがこのカスタマイズのステップが本来解決すべき課題だ。デフォルト値で審査した、一見もっともらしいが実際には正しい法的枠組みと一切照合されていないレポートを手にしてしまう前に、このステップをインストールプロセスの中で省略できない一部として扱うほうがよい。