海外から届く英文契約を、日本語の論点メモに直して法務がレビューできる状態にする

処理の起点を決める

法務担当がPDFを投入したときを起点にします。自動化しません。

理由は、契約の種類を人が選ぶ必要があるためです。販売代理店契約と購買契約では、見るべき条項がまったく違います。ここを自動判定させると、間違った観点で整理された論点メモが出てきます。

月15件であれば、投入の手間は1件1分です。ここを自動化しても削減になりません。

入力データを集める

最後の「交渉の方針」が、この構成の質を決めます。 「準拠法は日本法を主張するが、第三国の仲裁なら受け入れる」といった方針を書いておくと、論点に優先順位が付きます。

データの取得方法を決める

英文契約： PDFをそのまま渡します。Claude APIのPDF対応では、1リクエストあたり最大32MB・最大600ページまで扱え、パスワードや暗号化のない標準PDFであることが条件です。契約書1件であれば、この範囲に十分収まります。

各ページはテキストと画像の両方として処理されるため、レイアウトを保った読み取りになります。表形式の別紙（価格表、納期表）も扱えます。

ひな形と過去記録： プロジェクトの参照資料として登録します。契約種別ごとにプロジェクトを分けてください。 1つのプロジェクトに全種別を入れると、購買契約のレビューに代理店契約のひな形が混ざります。

用語集： 20〜30行で足ります。製品名、部門名、社内の役職の日英対応です。これがないと、同じ語が回ごとに違う日本語になります。

AIへ渡す前に整形する

1. 契約種別の指定 … 人が選びます。ここは自動化しません
2. 別紙の分離 … 価格表や仕様書が添付されている場合、本文と分けます。本文の条項と別紙の条件が食い違うことがあり、それ自体が論点です
3. 改訂履歴の確認 … 先方が修正を入れた版の場合、変更履歴が残っているかを見ます。残っていれば、変更箇所だけを重点的に見る形にできます
4. スキャン画像の確認 … 文字が取り出せないPDFは、引用が付けられません。この場合は文字認識を先に通します
5. 署名欄・住所の扱い … 相手方の担当者名や住所は、論点の整理に不要です。渡す範囲から外せるなら外します

AIに処理させる

3つに分けて、順番に出させます。1回のやり取りで全部を出させないでください。

1を先に出させる理由は、抜けを見つけるためです。 「ひな形にあるのに、この契約にない条項」は、差分としてより重要なことがあります。条項がないことは、読んでいて気づきにくいからです。

LLMにさせないこと：

• 有利・不利の結論を出すこと
• 法令の解釈を述べること
• 判例や一般的な相場を持ち出すこと
• 修正案の条文を書くこと

最後の「修正案を書かせない」は意見が分かれるところですが、一次整理の段階では書かせないほうが安全です。 もっともらしい英文の条項が出てくると、それを検証せずに使ってしまいます。

指示内容を固定する

あなたは、日本企業の法務部で英文契約の一次整理を行う担当者です。
添付の英文契約を、条項ごとに日本語で整理してください。

【厳守事項】
- 有利・不利の結論を書かないでください。
  「この条項は自社に不利です」ではなく、
  「ひな形では◯◯だが、本契約では△△になっている」と事実を書いてください。
- 法令の解釈、判例、業界の相場を持ち出さないでください。
  参照するのは、この契約書とプロジェクトに登録されたひな形・過去記録だけです。
- 修正案の条文を書かないでください。
- すべての項目に、原文の該当箇所を引用して添えてください。
  引用できない項目は書かないでください。
- 原文にない条項を補わないでください。
  ひな形にあって本契約にない条項は「本契約に該当条項なし」として挙げてください。
- 数値（金額・期間・料率・日数）は、原文の表記のまま書いてください。
  単位の換算をしないでください。

【この契約の種別】
{contract_type}

【交渉の方針】
{negotiation_policy}

まず、条項の棚卸しだけを出してください。
（条項番号／見出し／日本語の要点／原文の引用）

「数値の単位を換算しない」の1行は必ず入れてください。 thirty (30) days を「1か月」と書かれると、月末の扱いで解釈が変わります。

棚卸しが出たら、次のやり取りでひな形との突合を、その次に論点の抽出を依頼します。

出力形式を固定する

論点メモは、次の形の表で出させます。

「確認の要否」を3段階にするのは、全部を要確認にさせないためです。 30条項すべてが要確認と出てきたら、読む順番が付いていないのと同じです。

引用の機能を使う場合、Claude APIのCitationsでは、回答の各主張に対して根拠となった箇所が返ります。 PDFは文単位に分割されて扱われます。なお、文字が取り出せないスキャンPDFは引用できません。

システムへ連携する

この構成では、システム連携をしません。

最後の行だけは運用として決めてください。 レビューが終わった案件の「論点と、最終的にどう決着したか」を参照資料に足していくと、2年目から出てくる論点の質が変わります。

人が確認する

全件、法務担当が原文で確かめます。

これは確認の省略ではありません。確かめる場所が決まることが、この構成の効果です。

確認の手順を決めてください。

1. 「本契約に該当条項なし」と出た項目を先に見る（抜けは気づきにくい）
2. 「要確認」の項目を、原文の引用から条文を開いて確かめる
3. 数値（金額・期間・料率）を、原文と1つずつ突き合わせる
4. 準拠法・裁判管轄・仲裁の条項は、AIの整理を見ずに原文を読む

4を例外にしている理由は、ここが最も誤りの影響が大きいからです。 紛争が起きたときにどこで争うかは、契約の他のすべての条項より重い場合があります。

例外に対処する

記録を残す

• 受領した英文契約の版と受領日
• 生成した論点メモ
• 法務が確認した結果（AIの整理のどこが誤っていたか）
• 最終的な決着（どの論点をどう合意したか）
• 外部の弁護士に出した論点と、その回答

3番目が精度の実測値になります。「条項の棚卸しは正確だが、ひな形との突合は3割が的外れ」と分かれば、参照資料の直し方が決まります。

4番目が資産になります。次に似た契約が来たときの判断材料です。

なお、契約書の原本そのものを外部サービスに残さない設計にしてください。 会話の履歴を保持しない設定があるか、確認してから運用を始めます。