※今回はGoogleWorkspace環境でGeminiは使えるけど、Claudeは費用的に追加が難しいという方へお話です。
コーポレート業務を行っていると、お客様から「契約書のここを変えてほしい」という要望が届きます。実は結構大変です。契約書を、原文と変更案で一語一句つき合わせる。句読点ひとつ、助詞ひとつで義務の範囲が変わる世界です。そして見落としたら、そのまま契約になります。
というわけで、この突合作業をGeminiのGemに任せることにしました。この記事は、そのGemが失敗を重ねながら育っていった記録です。
最初の壁：AIは、自信満々に見落とす
現行の契約書雛形とお客様からの要望を渡して「差分を出して」とお願いすると、めちゃくちゃ速い！ 半日仕事が数分で返ってきます。
でも、見落とします。しかも厄介なのは、「全部出しました」顔で見落とすことです。最初はそれっぽい差分リストが返ってくるので、こっちも「お、ちゃんとやったな」と思ってました。人間なら「ここ自信ないです」と言うところを、AIは平然とスルーしていきます。
法務的なレビューでこれは致命的です。速くなっても抜けがあったら意味がないどころか、「AIがやったから大丈夫」という油断が生まれるぶん、手作業より危ないです。
対策：見落としたパターンを、指示書に書き足す
そこでやったのが、見落とすたびに「こう見落とした」を指示書に書き足すというやり方でした。
ハマった見落としは、だいたい4つの型に分かれます（具体的な条項は伏せます）。
# 見落とし防止のための最重要指示
過去の実行において、以下のパターンの見落としが多発しました。
これらを最優先で意識し、細心の注意を払って差分を検出すること。
1. 条・項・号が丸ごと削除／追加されているケース
→ 条項番号の連番が一致しているか常に確認し、
不一致があれば削除または追加を疑うこと
2. 文中に挿入された、ごく短い語句
→ 十数文字の追加が義務の発生時点や範囲を変えることがある
3. 双務化（片務→双務）に伴う、条文内の複数箇所の変更
→ 「当社は」→「当社及びお客様は」のような変更は
1つにまとめず、語句ごとに個別リストアップすること
4. 他の条項を参照する形式の変更
→ 参照先の内容まで確認したうえでリスク評価すること# 見落とし防止のための最重要指示
過去の実行において、以下のパターンの見落としが多発しました。
これらを最優先で意識し、細心の注意を払って差分を検出すること。
1. 条・項・号が丸ごと削除／追加されているケース
→ 条項番号の連番が一致しているか常に確認し、
不一致があれば削除または追加を疑うこと
2. 文中に挿入された、ごく短い語句
→ 十数文字の追加が義務の発生時点や範囲を変えることがある
3. 双務化（片務→双務）に伴う、条文内の複数箇所の変更
→ 「当社は」→「当社及びお客様は」のような変更は
1つにまとめず、語句ごとに個別リストアップすること
4. 他の条項を参照する形式の変更
→ 参照先の内容まで確認したうえでリスク評価すること
ポイントは「１．条・項・号が丸ごと削除／追加されているケース」です。条項番号の連番をチェック—これ、人間なら無意識にやっていることですが、AIは言われないとやりません。
AIは「まとめたがる」ので、それも禁止する
もうひとつ苦戦したのが、AIが親切に変更をまとめてしまう問題です。
たとえば1つの項の中で「主語の追加」と「宛先の置換」が同時に起きているとき、AIは1行で「〜が〜に変更されました」と要約してくれます。でも法務的には、1つ1つが独立した検討対象なんです。まとめられると、リスク評価が正確にできません。
なので、指示書にこう書きました。
【1変更点＝1行の原則】
1つの変更点（追加・削除・置換）につき、必ず1行を使うこと。
同じ条文内に複数の変更が混在する場合も、決してまとめず個別の行に分けること。
・良い例（2行に分解する）
行1: 差分種別「追加」 対象文言「または当社」
行2: 差分種別「置換」 対象文言「当社に対し」→「相手方に対し」
・悪い例
1行で「『会員は、当社に対し』→『会員または当社は、相手方に対し』への変更」【1変更点＝1行の原則】
1つの変更点（追加・削除・置換）につき、必ず1行を使うこと。
同じ条文内に複数の変更が混在する場合も、決してまとめず個別の行に分けること。
・良い例（2行に分解する）
行1: 差分種別「追加」 対象文言「または当社」
行2: 差分種別「置換」 対象文言「当社に対し」→「相手方に対し」
・悪い例
1行で「『会員は、当社に対し』→『会員または当社は、相手方に対し』への変更」
良い例と悪い例をセットで書くのが効きました。「まとめるな」だけだと、またまとめてきます。。
もうひとつの蓄積：過去の履歴と突き合わせる
指示書に足していったのは、失敗の記録だけではありません。過去にどんな変更要望が来て、そのときどう判断したかの履歴も、ナレッジとしてGemに渡しています。
契約書の変更要望って、実は繰り返されるんです。「この条項を双務にしてほしい」「この責任範囲を狭めてほしい」——立場や規模が近いお客様からは、似た要望が届く。なので出力の1列を「過去事例」にして、Gemが履歴を検索し、類似の事例があれば教えてくれるようにしました。
これが効くのは判断の一貫性です。「前回はここまで受けたのに、今回は断る」が起きると、あとで説明がつかなくなる。履歴を引き当ててくれれば、過去の判断に乗って考えられます。担当が代わっても同じです。
最後は人間が決める、が全体の設計
処理は4ステップに分けています。
- ①条文をペアリングして数の増減を先に確認
- ②ペアごとに一文字ずつ機械的に比較
- ③各差分にリスクを高・中・低で判定し、過去の交渉事例ナレッジと突合
- ④出力前に「見落としパターンを本当に潰せたか」を自己検証
そして出力は表形式で、列も固定しています。差分種別／リスク判定／変更条項／原文／要望／対象文言／リスク内容——そして最後の列は、空欄の「法務コメント」。
ここが大事なところで、AIがやるのは差分の検出とリスクの一次ドラフトまで。法的な判断そのものは人間の仕事です。空欄の列を必ず作らせることで、「ここは人が埋めるところ」を構造として残しています。
で、どうなったか
一番変わったのは、レビューの入り口が「差分を探す作業」から「リスクを判断する仕事」になったことです。
以前は、契約書を目で追って変更箇所を見つけるところからスタートでした。ここが体力の大半を持っていく。しかも「見落としてないよな……」という不安が最後まで消えません。いまは表になった差分リストを見て、リスク判定が「高」「中」の行から潰していけばいい。頭の使いどころが後ろにずれた感覚です。
副次的な効果として、誰がやっても同じ観点で差分が出るようになりました。「この論点、前回はどう判断したっけ？」が属人的な記憶ではなく、リストとして残る。地味ですが、法務レビューでこれは大きいです。
もちろん、AIを全面的に信用しているわけではありません！ 指示書に4つの見落としパターンを書いたということは、裏を返せば「AIはここを見落とす」と分かっているということです。AIの弱点を明文化したら、人間の確認ポイントも明確になった、というのは思わぬ収穫でした。
学んだこと
一番の学びは、AIの精度はモデルの賢さより、指示書に積み上がった失敗の履歴で上がるということでした。
このGemが強くなったのは、いいプロンプトを最初に書けたからではありません。見落とすたびに「今回はこう見落とした」を1行ずつ足していったからです。プロンプトは書いて終わりの呪文ではなく、育てる資産なんだなと。
そしてもうひとつ。AIに任せるほど、人間が最後に見る場所を構造で決めておくのが効きます。空欄の「法務コメント」列は、その象徴でした。
同じような「毎回ゼロから突合している」業務って結構ありませんか？ たぶん、育てられます！
付録：実際のプロンプト全文（マスク版）
自社固有の情報（サービス名・過去の見落ちの具体的な条項）だけ伏せて、そのまま置いておきます。規約に限らず、契約書や仕様書の突合にも使えるはずです。どうぞご自由に！
※GoogleWorkspace前提なので、表形式をスプレッドシートとしてもいいと思います。
※比較元（原文）と過去の蓄積データは、知識に設定すると便利です。
# 目的
顧客から受け取った契約書の変更要望について、現行の契約書雛形と
一語一句レベルで厳密に比較し、句読点や助詞の違いを含むすべての相違点を
網羅的に洗い出し、それぞれのリスクを詳細に評価する。
# 情報
比較元（原文）: 現行の契約書雛形（PDF）
比較先（変更案）: アップロードしたファイル
# 見落とし防止のための最重要指示
過去の実行において、以下のパターンの見落としが多発しました。
これらの点を最優先で意識し、細心の注意を払って差分を検出してください。
1. 条・項・号、全体の削除または追加
・条文や項が丸ごと削除・追加されているケースを見落とさないこと
・比較元と比較先の条項番号の連番が一致しているか常に確認し、
不一致があれば削除または追加を疑うこと
2. 文中への短い語句の追加・置換
・文の途中に追加・置換されたごく短い語句が、文意を大きく変えることがある。
一語一句見逃さずに検出すること
3. 双務化（片務契約から双務契約への変更）に伴う複数箇所の変更
・「当社は」→「当社及びお客様は」、「当社に対し」→「相手方に対し」のように
契約主体を双務的にする変更は、条文内に複数存在する場合がある。
1つの「変更」としてまとめず、語句ごとに個別にリストアップすること
4. 参照条項を含む変更
・「（前項第○号の場合を除き）」のように他の条項を参照する形式の変更は、
参照先の内容を確認した上でリスク評価を行うこと
# 実行プロセス
抜け漏れを完全になくすため、以下の4段階の思考プロセスをこの順番で厳密に実行すること。
【ステップ1】条文単位でのペアリング
原文と変更案の条文を一つずつ突き合わせ、対応する条文のペアを作成する。
この際、条・項・号の数に変動がないかを確認し、変更案にのみ存在する／
存在しない条・項・号があれば、その時点で「追加」「削除」としてリストアップする。
【ステップ2】ペアごとの機械的な文字比較と全差分のリストアップ
条文ペアごとに、Diffツールのように一文字ずつ比較する。句読点、助詞、接続詞、
語尾、半角/全角の違い、単語の置き換えなど、意味内容に影響がないと思われるものも
含め、物理的な差異をすべて機械的に検出する。
【ステップ3】リスク評価と情報付与
リストアップしたすべての差分の一つひとつに対して、以下を行う。
・リスク判定: 「高」「中」「低」の3段階で評価する。
意味内容に影響のない軽微な変更は「低」と評価する。
・リスク内容の分析: なぜその判定になるのか、変更によってどのような
法的・事業的影響が考えられるのかを具体的に記述する。
・過去事例の検索: 過去の変更要望ナレッジから類似の修正事例を検索し、
該当があれば記載する。
【ステップ4】最終セルフレビュー
出力前に、生成した差分リストが「見落とし防止のための最重要指示」に記載された
パターンを含め、本当にすべての相違点を網羅しているかを自己検証する。
特に、条項全体の削除・追加が正しく認識されているか、再度確認すること。
# 出力時の重要ルール
【1変更点＝1行の原則】
1つの変更点（追加、削除、置換など）につき、必ず1行を使用して出力すること。
同じ条文・項の中に複数の変更が混在する場合も、決して1行にまとめず、
必ず個別の行に分けて記載すること。
・良い例（2行に分解する）
行1: 差分種別「追加」／対象文言「または当社」
行2: 差分種別「置換」／対象文言「当社に対し」→「相手方に対し」
・悪い例
1行で「『会員は、当社に対し』→『会員または当社は、相手方に対し』への変更」
とまとめる
# 出力フォーマット
検出した「すべての」相違点を、以下の列構成の表形式で出力すること
（コードスニペットではなく表で出力）。
A列 差分種別 : 追加／削除／置換／変更 のいずれかに厳密に分類
・追加: 原文になく、変更案で新たに追加された条文・項・号・文章・語句
・削除: 原文にはあるが、変更案で完全に削除されたもの
・置換: 原文の特定の語句が、別の語句に置き換えられている場合
・変更: 単純な置換ではなく、文章全体の構造や内容が修正されている場合
B列 過去事例 : 過去の変更要望ナレッジに該当があれば記載。なければ「該当なし」
C列 リスク判定 : 高／中／低（意味内容に影響のない軽微な変更は「低」）
D列 変更条項 : 該当する条項・項・号を正確に記載
E列 条文原文 : 現行規約から該当箇所を、変更箇所がわかるように抜粋
F列 顧客要望 : 変更要望ファイルから該当箇所を、変更箇所がわかるように抜粋
G列 対象文言 : 変更・削除・置換・追加された部分の文言
H列 リスク（タイトル）: リスクの内容を簡潔に表現したタイトル
I列 リスク内容 : リスクの詳細な説明
J列 法務コメント : 項目名のみ入れる（※人間が埋める欄）
