契約書AIレビューの前提｜自社プレイブックの作り方
「取引先から送られてきた契約書を、AIに読ませて大丈夫だろうか」「そもそも自社のひな形が正しいのか分からない」——契約書レビューにAIを使おうとすると、多くの中小企業がこの入口で止まります。
結論から言うと、契約書AIレビューの精度を決めるのはツールではなく「自社の判断基準を書き出したものがあるかどうか」です。法務特化AIが最重要機能として掲げているのも、まさにこの判断基準＝プレイブックでした。
株式会社Fyveは自社の契約書テンプレートを7種別すべて自前で整備し、変更点と理由を1件ずつ記録しながら運用しています。この記事では、2026年8月25日に発表されたGoogleの法務特化AIが何を変えたのかを整理したうえで、私が実際にやっている「AIに読ませる前の準備」を手順として公開します。
2026年8月25日、Googleが法務特化AI「Gemini Enterprise for Legal」を発表した
Google Cloudは2026年8月25日（米国時間）、法務業務に特化したAIソリューション「Gemini Enterprise for Legal」を発表しました。法律テクノロジーの年次カンファレンス ILTACON に合わせた発表で、提供形態はプレビューです。
まずは何が発表されたのかを、公式の記述に沿って正確に押さえます。ここを曖昧にしたまま「AIで契約書が自動化できるらしい」と受け取ると、判断を誤ります。
発表の中身は「スキル・コネクタ・エージェント・パートナー」の4点
公式ブログが挙げている構成要素は次の4つです。
- 法務業務向けの専用スキル — 契約レビュー、レッドライン（修正案の書き込み）、プレイブックの作成、規制のホライズンスキャン、リーガルリサーチ、DSAR（データ主体からの開示請求）対応などを、再利用可能なパッケージとして持つ
- 既存システムへのコネクタ — 文書管理システムや案件管理システムへMCP（Model Context Protocol／AIと外部システムをつなぐ共通規格）で接続する。iManage、NetDocuments、DocuSign、Everlaw、RelativityOne、Thomson Reuters HighQ、Harvey などが名前を連ねています
- データの中で動くエージェント — 法務・ポリシーのリサーチ、規制スクリーニング、契約ドラフトを行う既製エージェントを、Google と法務ソフト各社が提供する
- オープンなパートナー網 — Accenture、Deloitte をはじめとする導入支援事業者と、法務テック専業ベンダーが customization を担う
導入企業として名前が挙がっているのは Cleary、Freshfields、Weil、Williams & Connolly——いずれも国際的な大手法律事務所です。想定ユーザーは法律事務所と企業の法務部門であり、日本の中小企業がそのまま契約して使う製品ではありません。
価格は公開されていない
公式ブログ、プレスリリース、業界メディアのいずれにも価格の記載はありません。プレビュー段階で、営業経由の見積もりになる形態です。
この事実は、そのまま読者への実務的な示唆になります。「値段が書いていない製品」は、中小企業が今日から自社で試せる対象ではないということです。だからこの記事では「導入すべきか」という問いは扱いません。扱うのは、この発表から中小企業が持ち帰れるものは何かです。
一番重要な言葉は「プレイブック」だった
発表資料を読み込んで、私が一番反応したのは機能名でもパートナー名でもなく、次の2箇所の記述でした。
- 契約レビューを速くする仕組みとして「企業のプレイブックに照らして条件を突き合わせる」と説明されている
- コネクタの効能として「過去の契約書アーカイブを、実際に使えるプレイブックへ変換する」と書かれている
つまりこの製品は、AIが法律を知っているから速いのではありません。その組織が過去に何をOKとし、何をNGとしてきたかという判断の蓄積を読み込んでいるから速いのです。大手法律事務所には、その蓄積が何万件分もある。だから彼らが最初の顧客になっています。
ここが中小企業にとっての分かれ目です。ツールは月20ドルから手に入る時代になりましたが、プレイブックは買えません。自社で作るしかない。
プレイブックとは何か——AIに渡す「自社の判断基準」
プレイブックという言葉は法務領域では「契約交渉の社内基準書」を指します。この条項は絶対に譲れない、この条項はここまでなら譲る、この文言が入っていたら差し戻す——といった判断のルールを文書化したものです。
プロンプトとプレイブックは別物
ここを混同すると、AI活用が一向に積み上がりません。違いは「使い捨てか、資産か」です。
プロンプト | プレイブック | |
|---|---|---|
形 | その場で書く指示文 | ファイルとして保存された基準 |
寿命 | その会話限り | 更新しながら使い続ける |
再現性 | 書き手と気分で変わる | 誰が回しても同じ判定になる |
蓄積 | されない | 改訂のたびに厚くなる |
移植 | ツールを変えると消える | ツールを変えても残る |
「契約書のリスクを洗い出して」と毎回打ち込むのがプロンプト。「当社は損害賠償の上限規定を必ず入れる。上限は委託料の総額とする。相手が拒んだ場合は稟議に上げる」と書いてあるファイルがプレイブックです。
前者はAIの一般知識に判断を委ねています。後者は自社の判断をAIに実行させています。同じモデルを使っても、出てくるレビュー結果の実用度はまったく違います。
なぜ中小企業ほどプレイブックが無いのか
理由ははっきりしています。契約書を「作った」経験がなく、「もらった」経験しかないからです。
取引先から送られてきた契約書に署名する。次の案件でも、前に使った書式をそのまま流用する。この繰り返しだと、自社の基準を考える機会が一度も発生しません。判断していないのだから、判断基準が残らないのは当然です。
そして厄介なのは、この状態でAIに契約書を読ませても、AIは一般論しか返せないことです。「第○条は一方的に不利な可能性があります」と言われても、自社としてそれを飲むのか蹴るのかは、結局その場の勘で決めることになります。
私が契約書テンプレートを4層で管理している理由
ここからは自社の実運用の話です。私は契約書を4つの層に分けて管理しています。順に説明します。
層1: 公開モデル契約の原本を、無編集のまま置く
契約書はゼロから書きません。弁護士や業界団体がレビュー済みの公開ひな形を土台にします。IPA（情報処理推進機構）のモデル契約、経済産業省が公開する各種モデル契約、士業監修の無償ひな形などです。
これを1文字も編集せずに専用の場所へ置いておく。これが層1です。無編集で保持する理由は3つあります。
- 後から「どこを自社仕様に変えたのか」を差分で取り出せる
- 引用元が改訂されたとき、新しい原本と自社版の差分を再計算できる
- スポットで弁護士に相談するとき「公開ひな形からの変更箇所だけ見てください」と依頼でき、レビュー範囲と費用を圧縮できる
3つ目は実務上かなり効きます。契約書全文のレビューを依頼すると相応の費用がかかりますが、変更箇所が10行なら見てもらう対象は10行です。
層2: 自社向けにカスタマイズしたひな形を作る
層1の原本から、自社の事業に合わせた汎用ひな形を作ります。私が整備しているのは次の7種別です。
- 秘密保持契約（NDA）
- HP制作
- HP保守
- システム開発
- システム保守
- 映像制作
- 紹介（レファラル）
この層では、社名・住所・代表者名・契約日・管轄裁判所といった変わる部分をプレースホルダ（差し込み用の目印）にしておきます。案件ごとに実データを流し込むだけで個別契約になる状態です。
ファイル形式はHTMLに統一しました。以前は編集用のテキストと配布用のHTMLを二重管理していましたが、AIに編集を任せる前提ならHTMLを直接編集してもコストは変わらないため、2026年6月に一本化しています。PDFは配布用の生成物という位置づけです。
層3: 変更点と理由を1件ずつ記録する——これがプレイブックの本体
ここが一番重要です。 各ひな形には、変更履歴のファイルを必ず添えています。書く内容は3つ。
- 出自 — どの公開ひな形を土台にしたか、いつ取り込んだか
- 変更点 — 原本のどの条項を、どう変えたか
- 理由 — なぜその変更が必要だったか
3つ目の「理由」が、そのまま自社のプレイブックになります。「当社はこういう働き方をしているから、この条項はこう直す必要がある」という判断が、条項単位で残っていく。
これを1年続けると、契約書の束ではなく判断の束が手元にできます。新しい契約書が来たとき、AIにこの記録を渡して「当社の過去の判断に照らして、この契約書のどこが問題か」と聞ける状態になります。Googleの発表が言う「過去のアーカイブをプレイブックに変換する」を、手作業で先にやっているのと同じです。
層4: 個別案件に差し込んで締結する
層2のひな形に実データを差し込み、PDF化して電子契約サービスへ流します。紙と印鑑は使いません。
電子契約サービスは案件ごとに選んでよい方針にしています。以前は1社に統一する方針でしたが、2026年7月に撤廃しました。理由は、ひな形の条文が特定サービス名を含まない書き方になっているからです。「電子契約サービス」という一般名で書き、承諾操作の完了時点を契約締結日とし、電子署名を書面の記名押印と同等と定め、生成PDFと合意履歴を原本として保管する——この形なら、相手方が使い慣れたサービスに合わせても条項と矛盾しません。
統一しなければならないと思い込んでいたルールが、実はテンプレート側の書き方で不要になっていたという例です。層3の記録を読み返さなければ気づきませんでした。
借りたひな形をそのまま使っていて見つかった、4つの穴
ここからは、この管理方法の価値がはっきり出た実例です。
私のNDAテンプレートは当初、取引先から受け取ったNDAの原本をほぼそのままテンプレート化したものでした。固有名詞をプレースホルダに置き換え、押印欄を電子署名欄に直しただけ。条文本文は一切変えていません。「先方の法務が作ったものだから安全だろう」という判断です。
2026年7月、別の案件で使う前に全文レビューをかけました。4つの穴が見つかりました。
穴1: 法令・裁判所による開示の例外がなかった
秘密情報の開示禁止に、法令・裁判所・行政機関から開示を義務づけられた場合の例外規定がありませんでした。
これは形式上、裁判所の命令や税務調査に応じると契約違反になる状態です。標準的なNDAには必ず入っている項目で、抜けていたのは単純に元の書式の不備でした。例外規定を追加しています。
穴2: 複製・複写が全部「事前承諾マター」になっていた
原文は「秘密情報の複製・複写には事前の書面承諾を要する」。厳格に見えますが、実務と噛み合いません。
現場で帳票を写真に撮る、業務データのCSVを受け取る、画面を共有してもらう——AI業務効率化の仕事はこれらの積み重ねです。原文のままだと、その一つひとつに事前承諾が必要になります。
「利用目的の達成に必要な範囲内であれば複製できる。その範囲を超える場合は事前承諾を要する」と緩和しました。厳しすぎる条項は守られないので、守れる線に引き直すほうが誠実だという判断です。
穴3: 定義が存在しない「所定の区域」条項があった
「秘密情報は所定の区域においてのみ取り扱う」という条項が入っていました。ところが「所定の区域」の定義が契約書のどこにもありません。
工場やオフィスに人が常駐する前提の条文で、元のひな形が製造業向けだった名残と見られます。事務所・自宅・客先を行き来する働き方では文字どおりには守れないため、この項は削除しました。
定義のない用語で義務を課す条項は、守りようがないので削るか定義するかの二択です。放置すると、いざというときに解釈で揉めます。
穴4: 生成AIにデータを渡す行為が、契約違反になっていた
これが最重要です。
第三者への開示を禁じる条項と、再委託を禁じる条項。この2つを素直に読むと、クライアントから預かったデータをClaudeやChatGPTに入力する行為が契約違反になります。AI活用を売っている会社が、その事業活動そのものを禁じる契約を結んでいたわけです。
追加した条項は次の趣旨です。
受領者は、業務遂行に必要な範囲で、クラウドサービスおよび生成AIサービスを利用することができる。ただし、当該サービス提供者に同等の秘密保持義務が課されていること、または入力された情報が学習等に利用されない設定・契約条件が確保されていることを条件とし、その管理責任は利用した当事者が負う。
これは抜け穴を作る条項ではなく、透明性の宣言だと考えています。AI活用を提供する会社が「AIは使いません」という契約を結ぶほうがよほど不誠実です。使う前提と、そのときの保護措置（学習に使われない設定・同等の秘密保持義務・管理責任の所在）を先に書いておくほうが、特に技術が分かる担当者からは信用されます。
逆に言えば、AIを業務に使っている会社は、自社が結んでいるNDAを一度この観点で読み直したほうがいいということです。多くのNDAは生成AIが普及する前の書式をベースにしており、この論点が想定されていません。
この4つは「AIに読ませていれば防げた」わけではない
正直に書いておきます。穴1〜3は、AIに「このNDAの問題点を洗い出して」と投げれば指摘できた可能性が高いものです。標準的な論点だからです。
しかし穴4はAIには指摘できません。「この契約は、あなたの会社の事業内容と矛盾している」という判定には、契約書の外にある情報——自社が何を売っていて、日常業務で何をしているか——が必要だからです。
これがプレイブックが要る理由そのものです。AIは目の前の文書は読めますが、あなたの会社の事情は読めません。渡さない限りは。
AIに契約書を読ませる前にやる4手順
ここまでを、明日から着手できる形にまとめます。特別なツールは要りません。
手順1: 自社が結んでいる契約を1か所に集める
まずは棚卸しです。取引先と結んだNDA、業務委託契約、保守契約、利用規約への同意——PDFでもスキャンでも構わないので、1つのフォルダに集めます。
この時点で「あれ、契約書を交わしていない取引先がある」「同じ相手と違う書式で2本結んでいる」といった発見が出てきます。それも記録しておいてください。
手順2: 出典を公開モデル契約に置き換える
集めた契約のうち、今後も自社から出していく種類のもの（自社が発注側・提供側になる契約）を選び、対応する公開モデル契約を探します。IPAや経済産業省が公開しているモデル契約、士業監修の無償ひな形が土台になります。
そして原本を無編集で保存する。ここが層1です。
「今使っている書式のほうが実態に合っている」と感じるかもしれませんが、それでも公開モデルを取っておく価値があります。比較対象がないと、自社版の何が特殊なのか永久に分からないからです。
手順3: 変更した箇所と理由を1行ずつ書く
公開モデルと自社版を並べて、違う箇所を洗い出します。そして1件ずつ、なぜ変えたのかを書きます。
形式は問いません。表計算ソフトでもテキストファイルでも構いません。列は「条項／原本の記述／自社版の記述／変更理由」の4つあれば十分です。
理由が書けない変更が出てきたら、それは誰かが何となく変えた箇所です。元に戻す候補になります。私の場合、この作業をしたときに削除に至った条項が1つありました（穴3）。
あわせて、直さないと決めた論点も書いておきます。私のNDAには次の未対応論点が残っています。
- 秘密保持期間が「期間の定めなく」＝実質永久。一般には3〜5年が相場だが、中小企業のNDAでは珍しくないため現状維持
- 損害賠償の上限規定がない
- 弁護士による正式レビューは未実施。テンプレートを本格運用し続けるならどこかで受けたい
「気づいていないこと」と「気づいたうえで保留していること」を分けて書くのが要点です。前者はリスクですが、後者は判断です。この区別が書いてあるファイルは、そのままAIへの入力として機能します。
手順4: その記録をAIに渡してレビューさせる
ここでようやくAIの出番です。新しい契約書が届いたら、手順3で作った記録を一緒に渡して次のように聞きます。
- 「添付の当社基準に照らして、この契約書で差し戻すべき条項を挙げてください」
- 「当社基準に載っていない論点がこの契約書にあれば、それも指摘してください」
- 「当社の事業内容（AI業務効率化の受託）を踏まえて、事業活動と矛盾する条項がないか確認してください」
3つ目の質問が、穴4を見つけられる形の問いです。自社の事業内容を明示的に渡している点が、単に「問題点を洗い出して」と聞くのとの決定的な違いになります。
指摘が返ってきたら、判断した結果を手順3の記録へ追記します。これでプレイブックが1件分厚くなる。この循環が回り始めれば、法務特化AIが数万件のアーカイブでやっていることを、規模は小さくとも同じ構造で回せます。
使うツールについては、月額20ドル前後の一般向けプランで十分に始められます。具体的なプラン選びとプロンプトの型は、別記事で詳しく扱っています。
それでもAIに任せてはいけない線引き
プレイブックを整えても、動かせない線があります。3つ挙げます。
線1: 最終判断は必ず人間が行う
AIのレビュー結果は論点の洗い出しであって、法的な結論ではありません。締結するかどうか、条項を飲むかどうかの判断は人間が行います。
特に、金額が大きい契約・長期の拘束が生じる契約・知的財産の帰属が絡む契約は、AIで論点を整理したうえで弁護士に相談する流れを崩さないほうがいいと考えています。層1で公開モデル契約を保持しておく利点は、まさにここで効きます。相談範囲を変更箇所に絞れるからです。
線2: 日本法への適合は別途確認が必要
汎用のAIモデルは英語圏の法務文書を大量に学習しています。日本の商慣行や法制度に固有の論点——下請法の適用範囲、印紙税の要否、個人情報保護法の第三者提供の枠組みなど——は、一般論として正しくても日本の実務に合わない回答が返ることがあります。
制度名や要件を記事や資料に書く場合も同様です。金額・期間・対象範囲は、必ず所管官庁の最新の公表資料で確認してください。
線3: 何を入力してよいかを先に決めておく
契約書は相手方の情報を含む文書です。AIに入力する前に、次の3点を確認しておく必要があります。
- 使うサービスで入力データが学習に使われない設定になっているか（プラン・契約形態によって異なります）
- その利用が、相手方と結んだ契約に照らして許されるか（＝穴4の論点）
- 社内の誰がどこまで入力してよいかのルールが決まっているか
個人契約のAIサービスを業務に持ち込むと、この3点が全部あいまいになります。中小企業のAI利用ルールの作り方は、こちらで整理しています。
よくある質問
Q. Gemini Enterprise for Legal は日本の中小企業でも使えますか
現時点ではプレビュー提供で、価格も公開されていません。導入事例として挙がっているのも国際的な大手法律事務所です。今日から自社で試せる製品ではないと考えたほうが実態に合います。最新の提供状況はGoogle Cloudの公式情報で確認してください。
Q. プレイブックは何件くらい書けば効果が出ますか
件数より種別のカバー率だと考えています。自社が日常的に交わす契約の種類（多くの中小企業では3〜5種別）について、それぞれ1本ずつひな形と変更記録があれば、AIレビューの精度は明確に変わります。私の場合は7種別です。
Q. 弁護士に頼まず自社でひな形を整えて大丈夫ですか
公開モデル契約を土台にする限り、抜け漏れのリスクはかなり下がります。ただしそれで弁護士が不要になるわけではありません。私自身、テンプレートの正式レビューは未実施の課題として残しています。この記事の方法は「弁護士の代替」ではなく、相談する前に論点を整理して、相談範囲と費用を圧縮するための準備です。
Q. 既存の契約を全部見直す必要がありますか
締結済みの契約は原則そのままです。見直しの対象は今後こちらから出していくひな形です。ただし穴4（生成AI利用が契約違反になる論点）だけは、AIを業務に使っている場合、締結済みのNDAについても一度確認する価値があります。
Q. Claude や ChatGPT のような汎用AIでもプレイブックは使えますか
使えます。プレイブックはテキストファイルなので、どのツールにも渡せます。これが自前で持つ最大の利点で、ツールを乗り換えても資産が消えません。法務特化AIを将来導入する場合も、そのまま持ち込めます。Anthropicの法務向け提供内容については別記事で整理しています。
まとめ：買えるのはツールだけで、判断基準は自社で作るしかない
2026年8月25日のGoogleの発表は、法務AIの主戦場が「AIが法律を知っているか」から「その組織の判断が読み込めているか」へ移ったことを示しています。プレイブックという言葉が繰り返し出てくるのは偶然ではありません。
中小企業がここから持ち帰れるのは、製品の検討ではなく順序です。
- 契約書を1か所に集める
- 公開モデル契約を原本として保持する
- 変更点と理由を1件ずつ書く（保留した論点も書く）
- その記録を添えてAIにレビューさせる
この4手順で作った記録は、ツールが変わっても、AIの世代が変わっても残ります。私が自社のNDAで見つけた4つの穴——なかでも自社の事業そのものが契約違反になっていた1件は、AIに文書だけを読ませていては絶対に出てこない指摘でした。
AIに何をさせるかを考える前に、AIに何を渡すかを整える。契約書に限らず、AI活用が積み上がる会社とそうでない会社の差は、だいたいここに出ます。自社のどの業務から手をつけるべきかの整理は、AI活用顧問でもよくご相談をいただくテーマです。
参考にした情報
AIを使う会社と、使わない会社。
その差は、開き始めています。
ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。
