契約書レビュー支援

次のような状態に心当たりがあれば、このワークフローが効きます。

• 契約書の確認が法務 1 人に集中している
• チェックの観点が担当者によって違う
• 自社ひな形とどこが違うか、比較に時間がかかる
• 修正案の作成が、毎回ゼロからになっている

処理は大きく 5 つの工程に分かれます。最初はすべてを自動化せず、1 と 2 の工程だけをつなぐところから始めるのがおすすめです。

各工程を担うツールの例と、選ぶときのポイントです。同じ役割は、無料ツールや既存の業務システムで置き換えられます。

※ ツール名は一般的な選択肢の例です。特定製品の推奨ではありません。

1 つの業務・1 つのチームを対象に、この順で進めます。各ステップの「完了条件」を満たしてから次へ進むと、手戻りが減ります。

1. チェックリストを整備する

   支払条件・損害賠償・競業避止・解除・責任制限など、自社が必ず確認する観点を書き出します。これが精度の元になります。

   完了条件：チェック項目が 20 項目以上、文章で整備されている

2. ひな形との差分を仕組み化する

   自社ひな形と相手案の条項を並べて比較させ、「変更点」と「変更による影響」を出させます。

   完了条件：ひな形の最新版が、いつでも参照できる

3. リスクの判定を作る

   各条項について「高／中／低」のリスクと、その理由を出させます。理由のない指摘は出力させません。

   完了条件：すべての指摘に、理由が付いている

4. 修正案を生成する

   リスクありの条項について、修正文とその意図を出させます。日本語の契約用語の慣習に合わせます。

   完了条件：修正文と理由が、条項ごとにセットになっている

5. 専門家の確認を必須にする

   AI の出力は、弁護士・法務の確認なしには使いません。出力には「確認済み」の印を付ける運用にします。

   完了条件：確認者の記録が、レビュー記録に残っている

導入時に実際に起きやすいつまずきと、その対処です。先に知っておくと回避できます。

運用に乗せたあと、月に一度はこの項目を確認してください。1 つでも外れていると、自動化が「使われない仕組み」になっていきます。

• 自社のチェックリストが、文章で整備されている
• AI の指摘には、条番号と原文の引用が必ず付いている
• 原文にない条項を作らせていない
• 修正案には、必ず理由が付いている
• 最終判断は、弁護士・法務が行っている
• 契約書を扱うサービスの、データ扱いを確認した

そのままコピーして、[ ] の中を自社の情報に置き換えてください。いずれも「推測させない」「根拠を明示させる」制約を入れています。

次の契約書の条文を、以下の表形式に整理してください。

【列】条番号／見出し（あれば）／条文の要約／原文（引用）
【制約】原文に書かれていないことは書かない。省略する場合は「（略）」と明示する。

【契約書】
[ここに条文を貼り付け]

あなたは法務の補助者です。次の契約書を、以下のチェックリストに照らして確認してください。

【チェックリスト】
1. 支払条件（期日・遅延損害金）
2. 損害賠償の範囲と上限
3. 解除条項
4. 責任制限・免責
5. 秘密保持
6. 契約期間と更新
[必要に応じて項目を追加]

【出力形式】項目ごとに「該当条番号／原文引用／リスク（高・中・低）／理由」
【制約】該当する条文がない項目は「記載なし」とする。原文にない条項を作らない。

【契約書】
[ここに条文を貼り付け]

次の条項について、自社に有利・中立な修正文案を 2 案作ってください。

【出力形式】各案について「修正文（条文の形）」と「修正の理由（1〜2 文）」
【制約】日本の契約実務で一般的な表現を使う。新たな義務を、根拠なく追加しない。

【対象の条項】
[ここに条項を貼り付け]

【自社ひな形の対応条項】
[ここにひな形を貼り付け]

※ 出力は必ず人が確認してください。数値・固有名詞の誤りは、自動では検出できません。

理解を深めたい用語は、AI 用語辞典の詳細ページへ。定義・仕組み・出典をまとめています。

• LLM（大規模言語モデル）とは？仕組みと主な種類をわかりやすく解説
• プロンプトエンジニアリング
• プロンプト
• ハルシネーション（AI幻覚）とは？起きる原因と上手な付き合い方
• コンテキストウィンドウ
• 人間参加型（HITL）
• AIガバナンス
• 安全性
• ゼロデータ保持