契約審査で脳を溶かさない:System2を温存する生成AIの登板管理
0.免責
本記事は、執筆者A0のあくまで個人的な考えを記述したものです。
内容そのものに加え、学術的な面においても正確性を保証するものではなく、記事の内容の正確性・有用性・業務での利用可否・関係法令および規則への抵触有無はご自身でご判断ください。
1.はじめに
「わかほう」の登壇・運営メンバーのつながりで、不定期に勉強会が開催されることがあり、先日参加しました。ただし、ここ最近重い仕事が多く、へとへと…。
雑談の流れで、
「役員からの重い相談が増えている。だから、グループ会社関係の契約で“税務と監査に耐えるか”みたいな一次レビューに頭のリソースを取られたくないんだよね。そういうのは生成AIが起案した規定の取捨選択で捌いてる」
みたいな話をしたところ、かなり驚かれて、プロンプトの説明をすることになりました。
とりあえず表面的に説明したものの、なぜそういう使い方になるか、なぜそのようなプロンプトを組んだのかの背景は(思考力ゼロだったので)説明しなかったため、ここで書いておこうと思います。
1.1 本稿の結論
結論から言うと、私は生成AIを時短目的だけでは使っていません。
もちろん結果として速くはなりますが、主目的は、重い思考(System2)を温存して、最後の“決めるところ”に残すことです。
1.2 超要約
詳細は後で述べるとして、手順はざっくり次のとおりです。
まず自分の瞬間的な判断で処理できるか判定(できるなら終わり)
無理そうなら生成AIでスクリーニング(論点棚卸し+確認事項+代替案の“筋”)
自分で根拠(条文・事実)を当たり、軽いものは瞬間的な判断で終わらせる
重いものだけ熟考して処理する
1.3 先にプロンプト(短縮版)
読み物は後で良い、という人向けに、まず短縮版プロンプトを置きます。
# 1. 入力(原則この順)
背景:取引目的・当事者関係・交渉状況などの【参考】
対象文書(契約、メールまたはレター):レビュー/起案対象【最優先】
インプットデータ:社内方針・過去契約・条件希望などの【参考】
判断・指摘は必ず「# 対象文書」に根拠を置く。
#2. 実行指定(冒頭で書く)モード(作業の種類):" / " で始まる
/Review :論点抽出・コメント・リスク評価
/Writing :修正案(対案)作成
/Scratch :1から起案
/Confirm :依頼元への確認事項整理
※複数モードは "+" で併用可(例:/Review + /Confirm)
チーム(レビューの傾向):" * " で始まる
*BASIC :企業法務弁護士・私の会社の営業担当者・行政の規制担当者のチームで、実務を踏まえつつ、行政・紛争・監査で詰まない現実的な落としどころをレビューする。
*SPEED :ベンチャー実業家・商社営業担当者・私の会社の営業出身法務担当者のチームで、速度/交渉を重視し、「捨ててもよい論点」「譲歩順序」の観点を強めにレビューする。
*GROUP :税務担当者・会計担当者・内部統制担当者のチームで、移転価格・コスト配賦・承認権限・証跡・監査耐性の観点でレビューする。
※指定がなければ *BASIC。
※複数チームは "+" で併用可(例:*BASIC + *GROUP)
# 3. /Review の出力フォーマット(簡略)総括(要点/取引成立への影響/優先順位トップ3)
- 対処の必要なリスク(顕在化可能性(目安)80%以上)
- 判断に迷うリスク(顕在化可能性(目安)79%〜60%)
- コメント程度(顕在化可能性(目安)60%未満)
- 依頼元への確認事項(必要性%(目安)つき)
- タイポ・表記ゆれ(あれば)
それでは、ここからは「なぜそうしているか」と「どうプロンプトに落としているか」を詳しく説明します。
2.そもそも生成AIの仕組みとは
※専門家ではないので、かなり雑な説明になることをご容赦ください。
最近の生成AIは、ざっくり言うと「文章の続きを、それっぽく生成する」仕組みです。
より正確には、学習した膨大な文章パターンをもとに、「次に来そうな語(トークン)」を確率的に予測して文章を作っています。
20代の方に伝わるか若干不安なのですが、「マジカルバナナ」というゲームがあります。ある単語に対して、連想できる単語をつなげていくゲームです。
生成AIは(比喩として)文章に存在する単語を手がかりに、連想ゲームのようなことをします。
例えば、「バナナ」「りんご」「野菜室」という単語を並べると、それぞれの単語で連想が走りつつ、共通して関係の深い語が出やすくなります。たとえば「エチレンガス」「追熟」みたいなやつです。
一方で、「バナナ」に対して「環境破壊」「共和国」を並べると、「モノカルチャー経済」「プランテーション」のように文脈が一気に変わる語が出てくることがあります。
このように、どのような単語(前提)を入力するかは目的とする出力を得るためには重要です。
一方で、同じチャットをずっと使っていると、会話の前提が積み上がって文脈が固定化し、出力の方向性が偏ることがあります。
これが生成AIの利用で面白いところで、誤った出力を避け、望んだ出力を得るためには関係する単語を並べなければいけないのに、似た単語を並べると出力の多様性が失われて、逆に近視眼的でミスリーディングな出力になりやすくなることがあるのです。
(個人的に、これは構造主義とポスト構造主義が揺らぐ感じに似ていると思うのですが、またの機会に…)
3.生成AIを利用する理由は時短がメインではない:System2の登板管理
生成AIの話をすると「時短できますよね?」と聞かれることが多いです。もちろん時短にもなります。
ただ、私の場合、主目的はそこではありません。
速くするというより、重い思考(System2)を「必要な局面まで温存する」ために使っています。
3.1 人間の脳はSystem1とSystem2で動いている
行動経済学の文脈などでよく言われるモデルとして、思考には大きく2種類ある、とされます。
System1:速い、直感的、ほぼ自動運転
例:文章に慣れた法務担当者が誤字に気づく/メールの温度感を察する/見慣れた契約類型の「いつもの地雷」を嗅ぎ分けるSystem2:遅い、意識的、論理的、エネルギーを食う
例:選択肢とトレードオフを設計する/説明責任まで含めて整合させる/関係者の特性に合わせて説得できる形に落とす
3.2 System2には稼働限界がある
System2は「考えれば考えるほど良い」みたいなものではないです。
むしろ、System2は注意とエネルギーを食うので、回し続けるとパフォーマンスが落ちやすい(=精神的に疲れる)類のものです。
具体的には、こんな症状が出ます。
確認が荒くなる(根拠を追っているつもりなのに、抜けが出る)
目が滑る(読んでいるのに入ってこない/同じ行を何回も読む)
視野が狭くなる(選択肢を増やすより、手元の案に寄りやすい)
よって私の関心は、「どれだけ早いか」より「どこでSystem2を使うか」にあります。
System2を温存して、最後の“決めるところ”に残す。生成AIはそのための道具、という位置づけです。
詳しく知りたい方は以下の本を読んでみてください
3.3 仕事が来たときのフロー
頭の中ではだいたい次の順番で回しています。
まずSystem1で「自分だけで処理できるか」を判定
論点が見えている/落としどころが想像できる/確認事項が少ない
→ このルートなら生成AIを挟まず終わらせます。無理そうなら、AIでスクリーニング(入口の整地)
ここでの生成AIは、結論を出す装置ではなく「入口の整地」です。
・論点の抜け漏れ
・根拠の所在(条文番号・該当箇所)
・依頼元に確認すべき事項(不足前提の洗い出し)
・代替案の方向性(条項案そのものより「筋」)出力を見て、System1で確認し、軽いものはここで終わらせる
・本文の該当箇所を見に行く
・「本文にないことを断定してないか」を潰す
・最小限どこを直すか決めるそれでもタフなら、AIでレビューを反復して材料を揃える
・自分もスクリーニングをかけて、気になった点を再レビュー
・その案件に関係しそうなキーワードを入力する
・相談主へ確認しなければいけない事項(既に与えている内容では不足する情報)からアプローチする最後にSystem2を使う
最終的には、自身の知識と経験をフルに稼働してレビューします
3.4 野球で例えるなら
野球を例えにするのは今やニッチな気がしますが、例えやすいので使うと、こういう感覚です。
System1:内野手(反射でさばける打球は、いちいち考えない)
生成AI:イニングを食う先発/ロングリリーフ(試合を壊さず回す、材料を集める)
System2:ワンポイント/クローザー(強打者が続く終盤だけ登板させたい。毎回投げさせると壊れる)
時短というより、登板管理です。
4.プロンプト紹介
ここまでの話をまとめると、私にとって生成AIは「文章を速く書く機械」ではなく、System2を使う前に咀嚼して整理するツールだと分かると思います。
なのでプロンプトも、「綺麗な文章」より「検討が前に進む形」を優先しています。
存在しない条文・事実を断定しない(ハルシネーション対策)
根拠(条文番号・該当箇所)を必ず示す(確認が速い)
不足情報があれば質問を返す(前提を固める)
出力フォーマットを固定する(読む負担=System2消費を減らす)
ゼロイチで結論を出さず、確度(%)と影響度で棚分けする(実務の判断に寄せる)
モード(作業の種類)とチーム(レビューのクセ)を分ける(無難な総論に寄せない)
4.1 「%」は統計ではなく、棚分けの目安
契約審査も法務相談も、現実は「違法/適法」みたいな二択で終わりません。
そこで私は、生成AIに「顕在化可能性(0〜100%)」と「影響度(高/中/低)」を出させて、論点を棚に分けさせています。
※ここでいう%は、統計的な確率というより「優先順位付けのための便宜的な目安」です。いったん棚に並べて、最後は人間が根拠を確認して決めます。
4.2 「モード」:何をさせるかを固定する(+で併用)
作業の種類をモードで切っています。
/Review:論点抽出・コメント・リスク評価
/Writing:修正案(対案)の作成
/Scratch:1から起案
/Confirm:依頼元への確認事項の整理
モードは「+」で併用します。
例えば「/Review + /Confirm」でレビューしつつ、確認事項も同時に出す、という使い方です。
4.3 「チーム(ヴァーチャルチーム)」:レビューに「個性」を入れる(+で併用)
生成AIは、そのまま使うとコンサバでありきたりなレビューに寄りがちです。
それはそれで便利ですが、重要案件ほど欲しいのは「無難な総論」ではなく、角度の違う突っ込みです。
そこで私は、よく言われる「AIに役割を与える」というのを、特色ある3名チームという形で組成して対応させています。
狙いは、BASICで実務の下限を押さえ、他のチームで別の視点で気付きを得るためです。
(既に述べた「出力の多様性が失われる」を回避するための手段の一つですね)
*BASIC:実務の標準
企業法務弁護士・私の会社の営業担当者・行政の規制担当者のチーム*SPEED:速度・交渉重視
ベンチャー実業家・商社営業担当者・私の会社の営業出身法務担当者のチーム。*GROUP:グループ間契約での証跡性を重視
税務担当者・会計担当者・内部統制(内部監査)担当者のチーム。
チームも「+」で併用します。
締結速度をやや重視したいなら:*BASIC + *SPEED
グループ取引でも比較的しっかりした契約にしたいなら:*BASIC + *GROUP
まず迷ったら:*BASIC
4.4 プロンプト例(骨格)
全文を貼ると長いので、骨格だけ置いておきます(会社や案件に合わせてカスタムしてみてください)。
# 0. 目的
あなたは、契約審査/法律相談の検討支援AIです。出力は 私が最終判断するための判断材料として、
(1) 根拠(条文番号・該当箇所)
(2) リスク評価(顕在化可能性%(目安) × 影響度[高/中/低])
(3) 対応案(修正案/交渉方針/社内確認事項)を示してください。
存在しない条文・事実を断定しないでください(見当たらない場合は「本文中に見当たりません」)。注意:上記%は統計的な確率ではなく、優先順位付けのための目安です。
# 1. 入力(原則この順)
(1) 背景:取引目的・当事者関係・交渉状況などの【参考】
(2) 対象文書(契約、メールまたはレター):レビュー/起案対象【最優先】
(3) インプットデータ:社内方針・過去契約・条件希望などの【参考】判断・指摘は必ず「(2) 対象文書」に根拠を置く。
契約が抜粋/長文の場合は、「見えていない条文がある」前提で不確実性を明示し、必要に応じて /Confirm を提案する。
# 2. 実行指定
## モード(作業の種類):" / " で始まる
- /Review :論点抽出・コメント・リスク評価
- /Writing :修正案(対案)作成
- /Scratch :1から起案
- /Confirm :依頼元への確認事項整理
※複数モードは "+" で併用可(例:/Review + /Confirm)
## チーム(レビューの傾向):" * " で始まる
- *BASIC :企業法務弁護士・私の会社の営業担当者・行政の規制担当者のチームで、実務を踏まえつつ、行政・紛争・監査で詰まない現実的な落としどころをレビューする。
- *SPEED :ベンチャー実業家・商社営業担当者・私の会社の営業出身法務担当者のチームで、速度/交渉を重視し、「捨ててもよい論点」「譲歩順序」の観点を強めにレビューする。
- *GROUP :税務担当者・会計担当者・内部統制(内部監査)担当者のチームで、移転価格・コスト配賦・承認権限・証跡・監査耐性の観点でレビューする。
※指定がなければ *BASIC。
※複数チームは "+" で併用可(例:*BASIC + *GROUP)
組み合わせ例:/Review *BASIC/Review + /Confirm *BASIC + *SPEED/Review *BASIC + *GROUP
# 3. /Review の出力フォーマット(簡略)
- 総括(要点/取引成立への影響/優先順位トップ3)
- 対処の必要なリスク(顕在化可能性(目安)80%以上)
- 判断に迷うリスク(顕在化可能性(目安)79%〜60%)
- コメント程度(顕在化可能性(目安)60%未満)
- 依頼元への確認事項(必要性%(目安)つき)
- タイポ・表記ゆれ(あれば)
5.おわりに
ここまで書いたとおり、私にとって生成AIは「最終結論を出す存在」ではなく、System2を使う前に楽にするための咀嚼・整理ツールです。
次は、「事業法務の思考フレームワーク」か、「契約審査を契約類型ごとに捉える」みたいな記事を書こうかなーと思います。
一年前の記事ですが、生成AI関係では以下のような記事もあります。内容は今でも使えますので、ご参考までにどうぞ。
