contract-review-pro

Contract Review Pro V4.0

専門的な契約レビュー Skill。成熟した契約レビューの方法論を実行可能なワークフローとして体系化しています。

設計原則：完全な自己完結性

この skill 自体でレビュー作業をすべて完了でき、skill ディレクトリ外にあるルールファイル、ナレッジベースのパス、外部ツールには依存しません。

• 専門的なゲート、チェックリスト、リスクテンプレート、条項基準はすべて references/ と data/ に内蔵されています
• コメント付き契約書は内蔵 OOXML エンジン（scripts/ooxml_lite.py）で生成します。環境に docx skill または officecli がインストールされている場合は任意で機能を強化できますが、ワークフロー上必須ではありません
• 顧客ルールと条項ライブラリの拡張は任意の入力です。ユーザーは自身のプロジェクトディレクトリに .claude/client-rules/（顧客の希望）と .claude/clauses/（条項ライブラリ）を作成できます。存在すれば読み込み、存在しなければ確認するかスキップします。いずれの場合もワークフローは中断されません
• 法律調査は、汎用的な階層検索の方法論に基づいて実施し、実行環境で利用可能なあらゆる検索ソースに対応します

コアワークフロー（7 ステップ）

Step 0 — 顧客の特定＋立場の宣言（必須）

顧客の特定：

1. ユーザーが明示した顧客をそのまま適用します
2. 契約当事者の情報を読み取り、プロジェクトディレクトリの .claude/client-rules/ にある関連主体と照合します（ユーザーが作成済みの場合）
3. 契約の参照元パスから顧客名を抽出します
4. 特定できない場合はユーザーに確認します。該当する顧客ルールがない場合、他の顧客の希望を適用してはなりません

顧客を特定できた場合は、ClientConfig.load_from_workspace() を呼び出して顧客の希望を読み込みます。

立場の宣言（レビューごとに必ず新たに行い、過去のものを引き継がない）：

1. どちらの当事者を代表するか（甲方／乙方／中立的なレビュー）
2. 中核的な利益の優先順位（本取引で顧客が最も重視する 2～3 項目の利益）
3. 必須項目と交渉可能項目の区分：どの条項がディールブレーカーで、どの条項なら譲歩できるか
4. レビューの基準：抑制的／標準的／強硬

立場の宣言は review-state に記録し、以降の「当方に有利／不利」という判断はすべて立場の宣言を基準とします。

Step 1 — review-state の作成

記録する項目：ソースファイルのパス、顧客、起草者、立場の宣言、取引構造の概要、リスクの事前分類（8 次元を各 1～5 点で初期評価）、法律問題の一覧。

Step 1.5 — 契約タイプの振り分け（専門ゲートの有効化）

契約名、主要条項、取引構造に基づいて契約タイプを特定し、references/gates/ 内の対応する専門ゲートを有効にします。

識別キーワード	読み込むゲート
建設工事／施工／請負／下請	08-建设工程.md
貸付／借入／融資／返済	09-借贷.md
保証／抵当／質権／担保	10-担保.md
売買／売買取引／調達／供給	11-买卖.md
賃貸／賃借／貸与	12-租赁.md
持分譲渡／M&A／持分買収	13-股权转让.md
請負／加工／製作	14-承揽.md
技術開発／技術サービス／技術ライセンス	15-技术.md
委託／不動産サービス	16-委托物业.md
有限責任組合／組合契約	17-有限合伙.md
広告／プロモーション／マーケティングサービス	18-广告.md
労働／雇用／労務	19-劳动.md
増資／増資による持分拡大／VC/PE 投資	20-VCPE增资.md

条項レベルのゲート（契約タイプをまたいで有効化され、タイプ別ゲートと並行して実行し、結論を相互に検証します）：

• 希薄化防止／反希薄化の取り決めがある → clause-gates/anti-dilution.md
• 買戻し／償還／持分の売戻しに関する取り決めがある → clause-gates/buyback.md
• 業績コミットメント／評価額調整／業績補償／アーンアウトに関する取り決めがある → clause-gates/valuation-adjustment.md

持分譲渡と VC/PE の両方に該当する場合は、VC/PE ゲートを優先します。いずれのタイプにも該当しない場合は、汎用ゲートのみ実行します。

Step 2 — 契約を通読し、取引を理解する

契約書の全文を読み、当事者、目的物、対価、引渡し／検収、決済、契約違反責任、解除、担保、紛争解決、添付書類を整理します。

Step 2.5 — フレームワークレビュー（4 つの問い）

各条項をレビューする前に、契約全体の構成を確認します。

1. 義務の一方的な偏り：主要な義務が当方に一方的に課されていないか（たとえば、当方にのみ契約違反責任があり、相手方に対応する義務がない）？
2. 退出権の不均衡：解除権や終了権が一方に偏っていないか？
3. 誤った前提：前文の条項や前提条件によって、当方に不利な事実認定がなされていないか？
4. 契約違反責任の対称性：双方の契約違反責任の算定基準や上限は均衡しているか？

当方に有利なフレームワーク上の問題は維持します。不利なものはTrack Changes を使ってフレームワークレベルで再構成し（Comments で指摘するだけにせず）、法律意見書で再構成の論理を説明します。

Step 3 — 有効性の審査を優先

有効性の問題は条項の最適化より優先します。 ContractAnalyzer.run_validity_review() を呼び出し、以下の 5 項目を確認します。

1. 名目と実態が異なる取引（循環売買、協力事業を装った実質的な貸付など）
2. 関連当事者間取引の公正性（明らかに不合理な低価格、関連当事者への利益移転）
3. 定型約款（免責条項によって相手方の主要な権利を排除していないか）
4. 承認・登記（契約の有効性と物権変動を区別）
5. 契約成立要件（当事者、目的物、数量）

有効性のリスクが見つかった場合は、まずその問題に対処し、その後で条項の最適化を検討します。

Step 4 — 法律問題の一覧を作成

通読、フレームワークレビュー、有効性の審査に基づき、調査が必要な実質的な法律問題を列挙します。

Step 5 — 法律調査（階層検索＋十分性基準）

実質的な法律問題については検索・検証を行い、根拠の捏造を禁止します。

階層検索：

1. 検索語の書き換え：契約書の原文やユーザーの言葉をそのまま検索してはなりません。まず検索意図を分析し、階層化されたキーワード（アンカーワード／正式な用語／同義語・別名／上位・下位概念／除外語）を作成します
2. 優先ソースの検索：現行の法律・規制、司法解釈、指導事例、権威あるデータベース（実行環境で利用可能な検索ソースに応じて実施：ローカルナレッジベース／法規検索ツール／公式データベース）
3. 十分性の判断：直接関連する検索結果の件数を集計します（無関係な契約タイプ、異なる法律分野、失効した法条、純粋に手続き上の規定は除外）。
   • 直接関連する検索結果が 5 件以上 → 十分。次のステップに進みます
   • 5 件未満 → 検索を拡張（権威ある実務記事、類似事案の裁判ルール、学術的見解）。拡張後も不足する場合は、その旨を正確に記載します
4. 出典の記載：各根拠に出典レベルを明記します（法律・規制の原文／裁判文書／権威ある実務見解／要再確認）。警戒すべき出典（失効している可能性のある個人メディア、出典のないまとめ）は、唯一の根拠として使用してはなりません

検索コンプライアンスの自己点検（Step 6 に進む前のブロッキングチェック）：

• 実質的な問題をすべて検索済みであり、「結論を先に出し、後から根拠を付ける」ことがない
• 検索表現を書き換えており、契約書の原文をそのまま転用していない
• 直接関連する検索結果の件数を集計し、十分性の判断を記録している
• 重要な法条が現行有効であることを確認済み（失効した法規の引用がない）
• すべての根拠に出典を明記している

いずれかを満たしていない場合は、各条項のレビューに進むことを禁止します。検索に失敗した場合は、検索結果が得られなかった理由を正直に記録します。

Step 6 — 各条項のレビュー（正反両面の手法）＋偏差の記録

各権利義務について ClauseReviewer.review_clause_dual() を呼び出し、次の 3 つの観点から審査します。

• 正面：通常の場合に何をすべきか、権利義務が明確か
• 反面：履行できない場合にどうなるか、救済措置が明確か
• 応用：救済措置が履行されない場合にどうするか

各項目の審査と同時に、RevisionRouter.determine_revision_method() を使って修正方法を決定します（修正ルートの決定木を参照）。

偏差の記録（6A）：レビュー中に内蔵標準条項やレビュー慣行から逸脱した対応（たとえば、追加すべき条項を追加しなかった、TC にすべきところを Comment にした）は、出力ディレクトリの deviation-log に理由とともに記録します。

Step 7 — 条項の抽出＋偏差をトリガーとするレビュー

各レビューの完了後、ClauseExtractor.scan_for_candidates() を呼び出して登録候補となる条項をスキャンし、プロジェクトディレクトリの candidates/ サブディレクトリに出力します。正式な条項ライブラリに直接書き込むことは禁止されています。

偏差をトリガーとするレビュー（7B）：deviation-log に同種の偏差が 3 か月以内に累計 3 回以上記録された場合、ユーザーに注意を促します。6 か月以内に 5 回以上の場合は、内蔵条項基準またはレビュー基準の見直しをユーザーに提案します。

レビューゲート

汎用ゲート（必須チェック 5 種類）

ゲート	チェック内容
gate_validity	名目と実態の不一致、関連当事者間取引、定型約款、承認・登記、成立要件
gate_subject	主体の適格性、署名・押印要件、委任、表見代理、一人会社、担保決議；初めて登場する企業主体については、企業信用調査を行う必要があります（存続状況、事業範囲、訴訟リスク）。実行環境で利用可能な照会ツールを使用します
gate_clause	対価の支払い、引渡し・検収、契約違反責任、解除・清算、担保・保険、通知・紛争
gate_consistency	本文と添付書類、金額・数量、期限・条件、定義の用法の整合性；プレースホルダーの空欄検出――必須条項の内容が空欄の線、「記入待ち」、「添付書類を参照」などのプレースホルダーである場合、適合と判定してはならず、少なくとも中リスクとして記録します
gate_output	3 点セットの完全性チェック

専門ゲート（16 個、references/gates/ に組み込み）

契約類型別の専門ゲート 13 個と条項単位のゲート 3 個を、Step 1.5 のルーティングで有効化し、一般ゲートと並行して実行します。各専門ゲートには、専門的な確認事項、専門リスクタグ、関連する法律上の根拠に関する案内が含まれます。

修正ルーティング決定木（必ず実行）

各レビューコメントを記入する前に、必ず RevisionRouter による判断を通してください。修正アクションは 5 種類です：

アクション	適用場面	表示方法
replace	誤字、句読点、日付、古くなった法律名、前後の不整合、明らかに不利で直接書き換えられる内容	Track Changes による置換（del+ins のペア）
insert	重要条項の欠落、当方に有利でそのまま実装できる追加	Track Changes による挿入（独立した段落）
delete	重複した表現、明らかに不要な内容、または当方に重大な不利益をもたらし、維持する価値のない内容	Track Changes による削除
comment	条項間の矛盾、商業上の判断、重大なリスク、相手方が受け入れない可能性、事実確認が必要な事項、複数の選択肢	Comments によるコメント
report-only	全体的な評価、枠組みに関する所見、本文の修正を必要としない注意事項	法律意見書のみに記載

デフォルトで insert とする一般的な追加条項（都度判断する必要はありません）：債権実現に要する費用（優先的に違約責任条項に組み込み）、送達確認、署名・押印による発効、表明および保証、受領方法の制限、贈収賄防止、独立した関係に関する表明、一人会社に関する補足。

4 つの自己確認項目（各項目について必ず確認）：

1. 顧客に代わって直接修正できますか？ → できる場合は Track Changes（replace/insert/delete）
2. 商業上の判断が関係しますか？ → はいの場合は comment
3. 相手方が受け入れる可能性は高いですか？ → はいの場合は Track Changes（ただし、コメントで顧客に知らせる）
4. 複数の合理的な選択肢がありますか？ → はいの場合は comment とし、選択肢を示して推奨案を明記

必要最小限の修正原則：部分的に削除できる場合は段落全体を書き直さず、部分的に追加できる場合は条項全体を置き換えません。原文の構成を保ち、相手方が変更箇所を明確に把握できるようにします。

修正ブロックの統合：同一条項に複数の修正が必要な場合は、修正を 2～6 個のまとまりに集約し、レビュー画面に細かな修正が十数個も表示されるのを避けます。

違反の自己確認：Comments に上記のデフォルトで insert とする条項について「追加を推奨」と記載されている場合、ルーティングの誤りです。Track Changes に変更してください。

交渉上の立場とエスカレーション経路

交渉の優先順位は 3 段階（立場表明における「必ず守る／交渉可能」の区分と連動）：

• 第 1 層 必ず確保する（deal-breaker）：未解決の場合は進行を推奨しません
• 第 2 層 確保すべき：強く希望する事項であり、第 3 層の事項と交換できます
• 第 3 層 譲歩候補：第 2 層の事項との交換に用います

重大な修正にはそれぞれ、予備案となる立場（第一希望の文言を相手方が拒否した場合の代替案）を付記します。

エスカレーション経路は 4 段階：

1. 文言の微調整 → AI が直接 Track Changes
2. 最低条件となる条項の削除に関するリスク → Comments で弁護士本人による再確認を明確に促す
3. 不利な代替条項を発見 → 「要判断」と明記し、選択肢を提示
4. いずれかの評価項目が 4 以上 → 意見書に「弁護士による詳細なレビューを推奨」と明記

リスクタイプのタグ体系（15 個）

有効性・コンプライアンス関連

契約の有効性 定型約款 当事者の権限 関連当事者取引 コンプライアンス審査

取引構造・履行関連

代金および支払い 納品および検収 違約責任 解除および終了 担保および信用補完

紛争解決・文書関連

紛争解決 知的財産および秘密保持 定義および別紙 文書の整合性 文言および書式

各レビューコメントには、少なくとも 1 つのリスクタイプタグを付けます。専門ゲートで検出されたリスクには、専門タグも付けます。

リスクスコアリング（8 項目、1～5 点）

RiskScoringSystem は 8 項目をそれぞれ 1～5 点で評価し（5 が最高リスク）、review-state に記録して、意見書のレーダーチャートに反映します：

契約の有効性およびコンプライアンス／代金および支払い／納品および検収／違約責任／知的財産および秘密保持／契約解除および終了／紛争解決／当事者の権限および担保

評価基準：

点数	意味
1	条項が完全で、当方に有利
2	おおむね完全だが、軽微な不利益がある
3	合意内容が不明確、またはリスク要因がある
4	明らかに不利、または重要条項が欠落している
5	有効性にリスクがある、または重大な損失に直結する可能性がある

段階をまたぐ重大度の下限：後続段階で、前段階の評価を説明なく引き下げてはなりません。たとえば、逐条レビュー段階で初期評価の 🔴 高を 🟠 中に引き下げる場合は、review-state に引き下げの理由を明記する必要があります。

リスク評価の 6 項目

重要なリスクごとに、RiskAssessment.evaluate_risk_dimensions() を通じて次の項目を評価します：

1. リスクの性質：どのような種類のリスクか
2. リスクの影響範囲：最悪の場合、どのような損失が生じるか（可能な限り定量化）
3. 発生確率：ルールの明確さ、現地での解釈、類似事案の傾向に基づく
4. 回避可能性：取引構造の調整や条項の修正によって解消できるか
5. 商業上のトレードオフ：顧客の目標および代替案を踏まえ、受け入れる価値があるかを判断
6. 緊急度：直ちに対応／近日中に対応／継続的に注視／中長期的なリスク

最終成果物の納品基準

レビュー完了後、毎回 output/ に 3 点セットを出力します（すべて .docx とし、.md での納品は禁止）。オプションで 4 点目として HTML レポートも出力できます：

1. コメント付き契約書 {合同名}-审核修订版.docx

Track Changes + Comments。コメント作成者のデフォルトは 陈石律师【海泰所】 です。

デュアルエンジン：scripts/docx_generator.py が自動的に振り分けます。環境に docx skill（DOCX_SKILL_ROOT または ~/.claude/skills/docx）が存在する場合は、その Document library を使用します。それ以外の場合は、組み込みの ooxml_lite エンジン（標準ライブラリによる実装、依存関係ゼロ）を使用します。

OOXML 編集規律：

• 修正マークは del+ins のペアにする：先に <w:del>（w:delText）、次に <w:ins>（w:t）
• 新しい条項は、<w:pPr> の書式属性を含む独立した <w:p> 段落にする必要があります。既存の段落に行内で追加してはなりません
• 修正およびコメントには、作成者、日付、番号を必ず含めます。コメントのアンカーには、修正対象となるテキストを避け、2～4 文字の最短かつ一意な語句を使用します
• Word/WPS ではテキストが複数の <w:t> 断片に分割されることがよくあります。位置の特定には必ず連結した文字列で照合してください（ooxml_lite に組み込み済み）。単一 run 内の文字列であることを前提にしてはなりません
• 実行順序：段落の挿入 → 段落内のテキスト修正 → 番号／ラベルの修正（アンカーが自身の修正によって変わるのを防ぐため）
• 環境に officecli がインストールされている場合、officecli view <file> screenshot を使って、修正後の見た目を確認できます（任意の強化機能）
• python-docx の直接 API によるコメント付き版の生成は禁止

2. 法律意見書 {合同名}-法律意见书.docx

顧客向け要約ページ（先頭、1 ページ以内）：レビュー結論の段落（署名のメリットとデメリットに関する方向性を示した要約であり、断定的な結論は示しません）+ 主要リスク（5 件以内、各項目 3 行以内、法律条文の専門用語なし）+ 交渉の要点（必ず守る／交渉可能）。

本文は 5 つのセクション：

• （一）リスク全体のダッシュボード：リスク件数カード + 8 項目のレーダーチャート + リスクタイプの分布 + 総合リスクレベル
• （二）契約の基本情報
• （三）逐条レビューコメント（7 列の表：番号／リスクタイプ／レビュー対象条項の原文／リスクの説明／修正案／リスクレベル、赤・オレンジ・青で色分け）
• （四）総合評価および契約締結のメリット・デメリット分析：有利な要素、不利な要素、重大なリスクに関する注意、交渉の提案（3 段階の優先順位 + 予備案となる立場）、締結後の注意事項；必ず「チェックリストにない 1 つの問題」という必須の問いかけを含める——ビジネスモデルの変化、相手方の履行能力の悪化、業界慣行、連鎖的な影響の 4 つの観点から、レビューのチェックリストで扱われていないものの、顧客の判断に影響する可能性がある問題を 1 つ問いかけます
• （五）法律上の根拠一覧

基本原則：弁護士がメリットとデメリットを分析し、顧客が判断します。 メリット・デメリットの分析に代えて、「締結を推奨する」「締結を推奨しない」とすることは禁止です。

書式基準：濃紺色の見出し + 仿宋体の本文 + 淡色背景のメタ情報カード（契約名／当事者／レビュー日／レビュー担当者）+ 茶色のラベルによる強調 + ページ番号のフッター。正式文書向けのコンパクトな設定（余白・行間・段落間隔を圧縮し、無駄な余白を避ける）。逐条コメントは表形式にし（ラベル列は狭く、内容列は広くする）。

3. 法律分析 {合同名}-法律分析.docx

社内参照用の文書です。各修正箇所に対応する法令、司法解釈、指導事例、類似事案の裁判ルール、および検索・検証状況を明記します。

4. HTML ビジュアルレポート（追加機能、任意）{合同名}-审核报告.html

scripts/html_report_generator.py が生成する、外部依存なしの単一オフラインファイルです。8 項目のレーダーチャート、章別リスクヒートマップ、条項比較カード（左に原文／右に提案／下部に修正理由）、リスク一覧のレベル別フィルター、総合評価バッジ、統計カードの列、3 段階の交渉戦略ラベルを含みます。表示を強化するための成果物であり、3 点セットの代替ではありません。

複数回のレビューにおけるディレクトリ規約

同一の契約を複数回レビューする場合：output/round-1/、round-2/、final/。各ラウンドに簡易 manifest（ファイル一覧 + リスク統計）を添付し、final/ を顧客に納品する版とします。

条款库使用

内置标准条款库 data/clause_standards.csv（18 类标准条款）；用户可在项目目录 .claude/clauses/ 建扩展条款库，存在则自动加载。

使用三步匹配法：

1. 理解场景（合同类型、当事人关系、风险等级）
2. 匹配写法（基础版 vs 强化版，按标的额和对方资信选择）
3. 适配调整（变量替换、表述统一、删去不适用内容）

禁止不经适配直接复制条款文本。

硬约束

1. 禁止跳过立场声明
2. 禁止跳过通读直接审核
3. 禁止跳过实质性法律问题研究（含充分性判断）
4. 禁止跳过效力审查
5. 禁止先写审核意见后补法律依据
6. 禁止修改原始合同
7. 禁止用 python-docx 裸 API 生成批注版合同
8. 禁止将 .md 作为终稿交付（output/ 下必须为 .docx）
9. 禁止将应 Track Changes 的增补条款降级为 Comments
10. 禁止在未命中客户规则时套用其他客户偏好
11. 禁止无声降级上游风险评级（跨阶段降级必须明示理由）
12. 禁止依赖 skill 目录之外的规则文件、知识库路径或工具（可选增强除外）
13. 禁止编造法律依据；检索不足时如实标注

Python 模块参考

模块	功能	何时调用
review_config.py	审核配置 + 客户加载	初始化时
contract_analyzer.py	合同解析 + 效力审查 + 门禁	Step 2-3
risk_assessment.py	风险评估 + 六维度	Step 6
clause_review.py	正反两面法 + 条款库匹配	Step 6
revision_router.py	修订 5 分类路由 + 4 问自检	Step 6
intelligent_scoring.py	8 维度 1-5 分制评分	Step 6
sanguan_analysis.py	宏观-中观-微观三层深度分析	Step 2-3
clause_extractor.py	自动条款提取	Step 7
document_generator.py	三件套 docx 生成（版式规范内置）	输出阶段
docx_generator.py	批注版 Track Changes + Comments（双引擎）	批注版合同
ooxml_lite.py	内置 OOXML 引擎（零依赖兜底）	批注版合同
html_report_generator.py	HTML 可视化报告	输出阶段（可选）
main.py	主入口 + 会话管理	入口