Claude Cowork法務活用 — 契約書の一次レビューと規程整備を任せる範囲、任せない範囲

Coworkは法務のどこに効くか

効くのは判断ではなく、判断の手前です。Coworkは、Claudeがローカルのファイルや外部サービスにつながって多段階のタスクを進めるエージェント型の業務製品です。契約書のPDFやWordファイルを開き、条項を拾い、表に落とすところまでを引き受けます。一方で「この免責条項を飲んでよいか」はCoworkの外側にあります。この境界を最初に引いておくかどうかで、導入後の運用が大きく変わります。

法務に流れてくる仕事を分解すると、性質の違う3種類が混ざっています。

上の2つは、時間を大量に食うわりに専門性をほとんど使いません。30ページの取引基本契約が5本届いて、まず全部読む。この「まず全部読む」をフォルダとPlaybookでまとめて処理する形で寄せられると、担当者の時間は3つ目の評価と判断に戻ってきます。Coworkの価値は、法務を賢くすることではなく、法務が判断に使える時間を増やすところにあります。

Coworkそのものの機能構成や料金はClaude Coworkとは — 全機能・料金・始め方を1記事でにまとめています。

法的な結論まで踏み込ませない線引き

Coworkに出させるのは事実の整理までにして、結論は書かせません。AnthropicのAUP(利用ポリシー)は、法的な解釈・ガイダンス・法的効果を伴う判断に関わる用途を「高リスクの用途」に挙げています。助言や推奨を個人や消費者に直接向けるときは、その分野の有資格者が公開・確定の前に内容を確認することが条件です。個人や消費者へ直接見せる場合は、AIが作成に関わったことの開示も求められます。

規約の話にとどまらない点もあります。法的な結論を誰の名前で出すかは、ツールの設定ではなく組織の責任分担の問題だからです。

実務では、この線引きを指示文の制約として書き込むのが確実です。「まとめて」とだけ頼むと、Claudeは親切に評価まで書いてきます。禁止したい出力を先に列挙しておくと、成果物が扱いやすい形に揃います。

• 評価・推奨・可否の結論は書かず、事実と該当箇所の引用のみを出す
• 判断が必要な箇所は「要判断」と印を付け、判断材料になる事実だけを添える
• 元の文言を要約せず、条項番号と原文をそのまま引く
• 条文に書かれていない一般論(業界慣行、他社事例)を補わない

4つ目は見落とされがちです。学習データ由来の一般論が混ざると、その契約書には書かれていない話が「書いてあるかのように」並びます。原文引用を必須にしておくと、この混入は目視で見つかります。

契約書の一次レビューで使う指示文

条項の洗い出し

相手方から届いたドラフトを、まず構造化された表に落とす依頼です。読む順番を設計するための地図を作る作業と考えると、目的がぶれません。

{~/legal/inbox/取引基本契約_A社ドラフト.pdf} を読み、
条項の一覧表を作ってください。判断は書かないでください。
 
- 出力: 条項番号 / 見出し / 原文の要点(原文をそのまま引用) / 分類
- 分類は次の5つから選ぶ:
  金銭 / 期間・解除 / 責任・保証 / 知財 / その他
- 数値(金額、日数、料率、上限)が出てくる条項は「数値あり」列に印
- 相手方に有利・不利といった評価は書かない
- 読み取れなかった箇所は「判読不能」と明記し、推測で埋めない
- 出力形式: Markdownの表と、同内容のCSVファイルを1つ

出てくるのは全体像です。数値ありの行と、責任・保証の行から読み始めれば、限られた時間の配分が決まります。確認は「条項番号の連番が飛んでいないか」から始めるのが早く、飛びがあればページの読み落としを疑います。

自社ひな形との差分比較

法務でいちばん効くのがこれです。新旧2本のファイルを渡し、条項単位で対応付けさせます。

2つのファイルを条項単位で対応付け、差分の一覧を作ってください。
 
- 基準: {~/legal/templates/取引基本契約_自社ひな形.docx}
- 対象: {~/legal/inbox/取引基本契約_A社ドラフト.pdf}
- 出力列: 自社条項番号 / 相手方条項番号 / 差分の種類 / 変わった文言
- 差分の種類は次の4つ:
  追加 / 削除 / 文言変更 / 対応条項なし
- 「文言変更」は変わった部分だけを引用し、変更の意図は推測しない
- 対応関係が一意に決まらない条項は「要確認」として別表にまとめる
- 数値が動いた条項は変更前後の数値を並べて書く

期待できるのは、変更箇所そのものではなく見落としの防止です。人間が2本を突き合わせるとき、抜けるのは「相手方に条項がない」パターンで、あるものを比べる作業に意識が向くほど、無いものが視界から落ちます。対応条項なしを独立した分類にしておく理由がここにあります。

チェックリストとの突合

自社の審査基準をテキストファイルにしておくと、毎回の依頼が短くなります。基準そのものを渡す形なので、基準が更新されればファイルを差し替えるだけで済みます。

{~/legal/checklists/受注契約_審査基準.md} の各項目について、
{~/legal/inbox/取引基本契約_A社ドラフト.pdf} に該当する条項があるか
確認し、突合表を作ってください。
 
- 出力列: 基準項目 / 該当条項番号 / 該当する原文 / 状態
- 状態は次の3つ: 記載あり / 記載なし / 判断が必要
- 「判断が必要」には、なぜ一意に決まらないかを事実として1行で書く
- 基準を満たしているかどうかの結論は書かない
- 該当条項が複数ある場合は全部挙げる

3つの型は、前の出力を次の入力に渡す順につなげると同じ契約書を3回読ませずに済みます。

依頼文の組み立て方そのものはClaude Cowork業務テンプレート12選で扱っています。

社内規程の整備を下ごしらえする

規程整備は、契約書レビューより相性が良い領域です。扱うのが自社の文書なので、機密の判断が単純になります。改正ではなく新規に就業規則や36協定届のたたき台を起こす場合は、厚労省のモデル様式を読み込ませる手順をClaudeで36協定届とモデル就業規則のたたき台を作るにまとめています。

• 規程間の用語のゆれを洗い出す(「従業員」と「社員」、「本規程」と「この規程」の混在)
• 改正前後の条文を並べた新旧対照表の下書きを作る
• 上位規程と下位規程で矛盾する記述を拾い出す
• 附則の施行日と経過措置を一覧にする
• 他規程を参照している条番号が実在するか確認する

最後の項目は地味ですが、改正のたびに壊れます。参照先の条番号が改正でずれ、参照元だけ古い番号が残る。人間が全文を追って確認するのは苦行で、機械的な確認が向いた作業の典型です。似た構造の下ごしらえは、SOC2のような外部監査の前にもあります。名前も分類もばらばらな書類フォルダを統制領域ごとに整理する手順はClaudeで散在した書類をコンプライアンス監査向けに整理する方法にまとめています。

新旧対照表の下書きでは、「変更していない条文をそのまま複写する」という指示を明示的に入れます。要約する癖が出ると、変えていないはずの条文が微妙に変わって出てきます。改正作業で最も危険なのはこの種の静かな変質で、差分だけを見ていると気づけません。

機密文書を渡す前に確認する3点

どこで処理されるか

Coworkのセッションは、既定でクラウド上で動きます。エージェントの処理とコード実行はAnthropicのサーバー上の隔離された一時環境で行われ、環境はセッションごとに作られ、終了時に破棄されます。ローカルのファイルやブラウザーが必要になると、手元のClaude Desktopアプリを経由して端末側で処理されます。

注意したいのは、手元のファイルを開いた場合も、その内容はAnthropicのサーバー側で処理され、端末に留まらないことです。既存のデスクトップ環境向けにはローカルセッションも残っていて、証跡の残り方がクラウドと大きく違います。

契約書の案件では、履歴を案件終了後に消せるかどうかが運用を左右します。端末に残る履歴を管理者が消せない点は、ローカルセッションを選ぶ前に知っておく条件です。

フォルダーの接続範囲は、そのままアクセス範囲になります。法務用のフォルダーを1つ切ってそこだけを接続する構成が基本形で、同期ドライブのルートを丸ごと接続すると案件と無関係な機微ファイルまで射程に入ります。クラウドセッションが手元のフォルダーに届くのは、Desktopアプリが開いてオンラインのときと、接続済みのフォルダーに限られます。会社が管理するPCで法務フォルダーを接続すると、クラウドセッションから到達できる範囲に入ることも頭に置いておきます。

学習に使われるか

クラウドセッションの会話データは、他のTeam・Enterpriseのデータと同じ商用契約上の取り扱いで、Claudeの学習には使われません。この記述はTeam・Enterpriseの扱いについてのものです。Pro・Maxで業務文書を扱うなら、アカウント側のプライバシー設定を別に確かめます。

法務文書を個人アカウントで扱わない、という運用ルールを1行決めておくと、この論点はほぼ閉じます。

誰が後から追えるか

追える範囲は、セッションの種類と契約プランで変わります。Compliance APIは、Claude・Claude Desktop・Claude Mobile経由のCoworkセッションを捕捉します。ローカルセッションの会話内容も、Enterpriseの管理者ならCompliance API経由で取り出せます。

Team・Enterpriseでは、CoworkのイベントをOpenTelemetryで自前の監視基盤へ流せます。流れるのは、ユーザーが送ったプロンプトの全文、ツールやMCPの呼び出し(サーバー名、ツール名、パラメーター、成否、実行時間)、読み書きしたファイルのパスです。使ったスキルとプラグイン、承認の判断(ユーザーが承認したか、却下したか、既存の権限で自動実行されたか)、モデルごとのトークン数と推定コストも流れます。1つのプロンプトから起きたイベントは、共通のprompt.idでひも付きます。管理者がOTLPエンドポイントを設定するまでは何も送信されません。

ここに法務だけが踏む落とし穴があります。プロンプト本文が既定で含まれるため、条文を貼り付けて依頼していれば、その中身がそのままSIEMに残ります。ツールのパラメーターにはファイルパスやコマンド引数が入り、ユーザーのメールアドレスもイベントの属性に載ります。

設定は、Organization settings > CoworkでOTLPエンドポイントとプロトコル(HTTP/JSONかHTTP/protobuf)、認証ヘッダーを入れて保存するだけです。保存した時点でイベントが流れ始めるので、収集側でフィルタリングやマスキングを済ませてから保存する順序になります。証跡を整えにいった結果、機密文書の複製が社内にもう一つ増える事態を避けるためです。

公式はOpenTelemetryを、コンプライアンス目的の監査ログの代わりにはならないと位置づけています。監査で求められる記録がどちらで満たせるかは、Compliance APIと切り分けて決めます。権限とロールの設計はClaude CoworkのRBAC運用に手順を置いています。

相手方から届いたファイルという固有のリスク

法務は、外部から来た信頼できない文書を毎日開く部署です。ここが他部門と決定的に違います。

プロンプトインジェクションは、外部コンテンツに紛れ込ませた指示をClaudeがタスクの一部として読んでしまう攻撃です。成立には2つの条件が重なる必要があり、Claudeが信頼できないコンテンツを読めること、そして結果に影響する操作を実行できることの両方が揃ったときに問題になります。Coworkには信頼できないコンテンツを走査する分類器と、自動承認モードでの動作審査が組み込まれていますが、リスクはゼロではないと位置づけられています。

相手方ドラフトを扱う限り、1つ目の条件は消えません。消せるのは2つ目です。契約書を読ませるセッションにはコネクタやメール送信につながる権限を付けず、読み取りと出力だけに絞る。送信が必要な作業は別セッションに分ける。この分離は設定の手間がほとんどかからないわりに、成立条件を片方から崩せます。

ネットワークの設定だけでは足りない点があります。ネットワークのegress(外向き通信)の許可設定は、Web fetch、Web検索、MCP(Claude in Chromeを含む)には効きません。Web検索はTeam・EnterpriseのオーナーがOrganization settings > Capabilitiesで止められます。またネットワーク設定が反映されるのは新しく作るセッションからで、進行中の会話で許可ドメインを変えても、その会話には効きません。

承認モードの選び方も、扱う文書で変えられます。

Claudeが画面を直接操作するコンピューター使用には、ファイル操作のような権限チェックの外側にあるという違いがあります。法務の作業では出番が少ないものの、画面に映る文書はすべて射程に入ります。

ファイルの完全削除だけは、どの承認モードでも実行前に明示的な許可を求められます。原本を消される事故は構造的に起きにくくなっていますが、それでも原本フォルダーは読み取り専用にしておき、作業用の複製を別に置く運用が安全です。

管理者側にも絞る手段があります。Organization settings > Coworkの「Allow “Automatically approve” mode」を切ると、メンバーの画面から自動承認のモード自体が消えます。コネクタの書き込み系ツールを毎回の承認なしで通す「Always allow」は既定で無効です。定期実行タスクはPCを閉じていても動き、リアルタイムでは見られないため、公式は機密ファイルに触れる作業を定期実行に載せないよう勧めています。契約書のレビューを定期実行にしない理由は、ここにあります。承認の扱い方や事故になりやすい許可の出し方はClaude Cowork運用ベストプラクティスにまとめています。

一次レビューの結果を検算する

出力の正しさは、法務側で確認できる形に設計しておきます。抽象的な精度評価ではなく、機械的に見つけられる異常から見ます。

数値だけは全件確認にする理由があります。金額や期間の取り違えは、読めばわかる誤りと違って、成果物の見た目からは異常が読み取れないためです。責任上限が1,000万円か100万円かは、表の中では同じ整った1行に見えます。

抜き取り確認で1件でも引用のずれが見つかったら、その出力は使わずに読み直させる。この基準を先に決めておくと、確認作業が「なんとなく眺める」に流れずに済みます。Coworkの機能面の詳細はClaude CoworkのComputer Use・VMサンドボックスで扱っています。

よくある質問

Coworkに契約書の全文を渡しても問題ありませんか

プランと社内規程しだいです。Team・Enterpriseの会話データはClaudeの学習に使われませんが、相手方との秘密保持契約が第三者サービスへの開示をどう定めているかは別の論点として残ります。まずは公開済みの契約書や自社ひな形といった、開示条件の制約が弱い文書から試す進め方があります。

過去の契約書をまとめて検索できるようにできますか

フォルダーを接続すれば横断的な確認はできますが、全件を毎回読ませると時間もコストもかさみます。対象案件を絞ってから渡す、あるいは条項一覧のCSVを先に作って以降はそれを検索対象にする形が扱いやすくなります。

監査で「AIが何を見たか」を説明できますか

Compliance APIは、Claude・Claude Desktop・Claude Mobile経由のCoworkセッションを捕捉します。OpenTelemetryを設定していれば、ファイルパス、ツール呼び出し、承認の判断が記録に残ります。ただしOpenTelemetryは、公式がコンプライアンス用途の監査ログの代替にならないとしているため、監査で求められる記録がどこまで必要かは先に決めておきます。

個人向けプランで業務の契約書を扱ってもよいですか

Coworkは有料プラン(Pro・Max・Team・Enterprise)で使えます。ただしOpenTelemetryによる監視はTeam・Enterpriseのみです。組織単位の承認モードやネットワークの制御も、Team・Enterpriseのオーナー向けの設定です。Pro・Maxでは、Coworkとチャットを一つのClaudeに統合する展開も順次進んでおり、モードの選択肢などの表示が記事の画面と違って見えることがあります。業務文書はTeam・Enterprise配下のアカウントに寄せる線引きが、確認事項をいちばん減らします。

まとめ

Coworkが法務に持ち込むのは、判断の代行ではなく読解の前工程です。指示文で「結論を書かせない」と決め、数値は全件、引用は抜き取りで検算すれば、成果物は安心して読める下書きになります。

導入前に決めておく点は、ローカルとクラウドのどちらで動かすかと、OpenTelemetryを有効にする前に収集側のマスキングを済ませることです。相手方ファイルを読むセッションには、送信につながる権限を付けません。