法務AIネイティブ化の教科書

はじめに ―― この教科書は「あなたの次の一歩」のための教科書です

法務でAIを使おうとして、こう感じたことはありませんか。「便利そうだけど、何から手をつければいいか分からない」「うちの仕事に合うのか不安」「すごい使い方の話ばかりで、自分には遠い」。

この教科書は、AIで難しいことをできるようにするための教科書ではありません。大事なのは、自分に合った使い方を見つけて、無理なく使えるようになることです。

だからこの教科書は、あなたに合わせて「今あなたは何をすればよくて、次に何をすればよく、それで何が得られるのか」を示します。そして「なぜそれが正しいのか」も、毎回いっしょにお伝えします。納得して進めるほうが、長く続くからです。

この教科書の柱 ―― 4つの原則

この教科書は、生成AIの導入を数多く支援してきた実務家がメルカリの全社プロジェクトで示した「4つの原則」を柱にします（mercan 2025/8）。これは法務に限らず、業種が何であっても変わらない勘どころです。

1. 仕事をほどく（入力→処理→出力に分ける）
2. 考え方を渡す（プロンプトは“思考の設計図”）
3. 小さく始めて、人が確かめる（最初から完璧な自動化を目指さない）
4. 巨人の肩に乗る（まず汎用ツール。自作は最後）

この4つに通底するのは、たった一つのこと――自分の仕事を、人に説明できる言葉にする（業務の言語化）。AIを使うとは、結局これに尽きます。

第1章　仕事をほどく ―― 入力・処理・出力に分ける

なぜ、これが最初なのか（原理）

AIに「いい感じにやっておいて」と頼むと、たいていがっかりします。理由は、AIの性能ではありません。あなた自身が、何を渡して・何をしてほしくて・何が欲しいのかを決めていないからです。

そこで最初の原則です。

原則①　仕事は「ほどける」。まず工程に分け、その工程を入力→処理→出力に分ける。

「ほどく」には、向きが2つあります。

ひとつは、横にほどく ＝ 工程（プロセス）に分けること。たとえば契約審査なら、「受け取って分類する → 気になる条項を拾う → 自社基準と照らす → 修正案を書く → 相手に返す」という、手順の連なりにします。

もうひとつは、縦にほどく ＝ ひとつの工程を「入力 → 処理 → 出力」に分けること。入力は「材料」、処理は「やること」、出力は「ほしい成果物」です。

この2つは、別物ではありません。工程とは、入力→処理→出力のかたまりを鎖のようにつないだもので、ある工程の「出力」が、次の工程の「入力」になります。だから両方そろって初めて、横（工程）で「どこをAIに任せ、どこを人が持つか」が見え、縦（入力→処理→出力）で「その工程でAIに何を渡せばいいか」が決まります。難しい技術ではありません。紙とペンでできます。

まず、契約審査を3つにほどいてみます。

• 入力：契約書と、取引の情報（相手は誰か、金額はいくらか）
• 処理：自社の基準に照らして、どこが問題かを見る
• 出力：「OK／要注意／NG」の判定と、その根拠と、相手に返す文案

この枠組みを、実際にやってのけた二社の話を、少していねいに見てみましょう。

例1：Sansan ―― 「入力」を整えたら、AIが具体的に答え始めた

Sansanの法務部門（従業員約2,000名規模の会社で、契約や問い合わせ対応を担うチーム）には、よくある悩みがありました。契約審査や問い合わせは一度で終わらず、数か月たって再開されることが多い。そのたびに「あの件、どういう経緯だったか」「どこが争点だったか」を探し直す。正確な情報を探し出すだけで、多大な労力がかかっていました。しかも、その判断のコツはベテランの頭の中にしかない（属人化）。

ここで彼らがまず手をつけたのは、AIでも処理でもなく、「入力」を整えることでした。具体的には、こうです。契約書の本文に文章として埋もれていた重要情報――契約金額、締結日・開始日・終了日、自動更新の有無、解約通知の期限――を取り出して、検索できる「項目」にしました。さらに、契約書どうしのつながり（基本契約と、その下の個別契約や覚書）を親子関係として整理し、社名が変わっても同じ会社だと分かるよう名寄せもしました。つまり、AIに渡す前の材料を、AIが正確に引ける形に作り替えたのです。

入力・処理・出力で言い直すと、こうなります。入力＝項目化・関係づけされた契約データに、過去の交渉履歴と自社の基準を加えたもの。処理＝それらと照らし合わせる。出力＝「OK／要注意／NG」の判定に、根拠（自社基準とのズレ・過去の実績）を添えたもの。

効果ははっきり表れました。以前は、AIに契約書を読ませても返ってくるのは「一般的にはリスクが高い」止まり。けれど法務が本当に知りたいのは「この取引で、このリスクを自社は許容できるか」です。入力を整えたことで、AIは「過去にこの相手とはこの条件で合意しているので、ここは許容できる」と、自社の文脈で具体的に答えられるようになりました。同社は、こうした取り組みで法務の対応時間を中央値で42%削減したと発表しています（Business & Law 2026/5、スポンサード記事・数値は同社発表）。

ポイントは、効いたのが「賢いAI」ではなく「整った入力」だったこと。ほどいて材料を整えるのが先、AIは後です。

例2：GMOフィナンシャルゲート ―― 工程を分けて「解像度」を上げる

もう一社、別の角度から。GMOフィナンシャルゲートの西澤朋晃氏は、自らを「構造思想家」と呼び、AI活用とは「業務の解像度の高さ」と「AIの使い方」のかけ算だと言います。氏いわく、解像度が低いままではAIは“おもちゃ”にとどまり、高めれば“強力なパートナー”になる。同じツールでも、業務をどれだけ細かく理解しているかで結果がまるで変わる、というわけです。

では「解像度を上げる」とは具体的に何か。氏は、契約審査という一つの業務を細かい工程に分解し、それぞれの工程に最適なAIや人の役割を割り当てる「CREATEモデル」という設計図を示しています。これはまさに、原則①の「仕事をほどく」を契約審査でやってみせた例です。さらに氏は、AIに指示を出す人に必要な力として、業務そのものの知識と課題を見つける力、そしてAIと業務を結びつける力を挙げます。要は、自分の仕事を細部まで分かっている人ほど、AIをうまく動かせるのです（Business & Law 2026/1、登壇レポート）。

二社は、ほどく“向き”が違った

おもしろいのは、二社のほどき方がちょうど対になっていることです。GMOフィナンシャルゲートは横にほどいた――契約審査を工程に分け、各工程にAIと人を割り当てた。Sansanは縦にほどいた――ある工程（自社基準と照らす“調べもの”）の入力を、AIが使える形に整えた。向きは違っても、共通するのは、AIの賢さに頼る前に、仕事をほどいたことです。ほどくのが先、AIは後。そして実務では、横と縦の両方をやると、いちばん効きます。これが原則①の核心です。

あなたの番（今・次・得られるもの）

ここからは、あなたが今日、自分の手で動かすことです。自分のレベルの行だけ見てください。

表だけだと少し抽象的なので、法務の仕事に置き換えてみましょう。まず「NDA（秘密保持契約）のレビュー」を横にほどくと、こんな工程になります――①ざっと読む → ②気になる条項を拾う → ③自社基準と照らす → ④修正案を書く → ⑤相手に返す文面を作る。このうち“どこか”を縦にほどいて、レベルに応じてAIに任せていきます。

• はじめて：工程のうち1つ、たとえば④「修正案を書く」だけを縦にほどきます。入力＝拾った条項と自社で気にする点（秘密情報の範囲・有効期間・目的外使用の禁止）／処理＝基準に沿う直し方を考える／出力＝修正文案のたたき台。まず1工程だけAIに任せ、自分で確かめる。
• つかっている：いつも③（基準と照らす）をAIに聞いているなら、入力を足します。自社のNDAひな型と、「秘密情報は書面で指定したものに限る」といった決めごとを、いっしょに貼り付ける。すると返事が、ありがちな一般論から「自社基準に照らすと第◯条がズレています」に変わります。
• 仕組みにしたい：①〜⑤の工程ごとに「AIに任せる／人がやる」を決め（横）、AIに任せる工程の入力を項目（相手方・期間・自動更新・解約通知の期限…）にして表で渡します（縦）。すると「来月、解約通知の期限が来る契約は？」にも、一覧で答えられます。

つまずいたら - 「工程」と「入力→処理→出力」、どっちからやればいい？ ―― まず横（工程）でざっと手順を書き出し、そのうち1工程だけを縦（入力→処理→出力）にほどきます。両方を一度に完璧にする必要はありません。 - 自分の仕事は特殊で分けられない ―― どんな仕事にも手順（工程）があり、各工程に材料・作業・成果物があります。完璧でなくていい、ざっくりで十分です。 - 入力に何を渡せばいいの？ ―― 「判断に使っている材料」です。社内の基準、過去の似た事例、取引の情報。あなたが頭の中で参照しているものを、そのまま渡します。

その先を覗いてみる ―― つくるとこんな感じ（読むだけでOK）

ここは、これまでと毛色が違います。すぐ上の「あなたの番」があなたが動くことだったのに対し、この節は、その表のいちばん下――「仕組みにしたい」をもう一歩進めて実際に“形”にすると何になるかの覗き見です。作るのは誰かに任せてよいし、今はやらなくてかまいません。だから、ここはあなたが手を動かす場所ではなく、「できあがり」を眺めるだけの場所です。法務だとこういうモノになるのか、と分かれば十分です。

たとえば、契約書がフォルダに「業務委託契約_最終版.docx」のようにファイル名だけで並んでいると、AIは中身を推測するしかありません。これを、次のような表（スプレッドシート）に整えます。

「親契約」の列がポイントです。個別契約（C-0002）が基本契約（C-0001）にひもづくと分かるので、基本契約を引けば関連する契約まで芋づる式にたどれます。この表は、見た目はExcelでも、中身は次のようなCSV（カンマ区切りのテキスト）です。

契約ID,相手方,種別,金額,終了日,自動更新,解約通知,親契約
C-0001,サンプル商事,基本契約,,2026-03-31,有(1年),3か月前,
C-0002,サンプル商事,個別契約,5000000,2024-08-31,無,,C-0001
C-0003,サンプルテック,NDA,,2025-11-07,有,1か月前,

これをAIに渡すと、「サンプル商事と、いま有効な契約はどれ？」「来月、解約通知の期限が来る契約は？」といった問いに、推測ではなく事実で答えられるようになります。付属キットの templates/contract-data-schema.csv（実務で使う22項目版）と、その解説 contract-data-schema.md が、このひな型です。コピーしてすぐ試せる最小版は、付録C-5にも載せています。

作らなくてかまいません。「整えると、法務ではこういうモノになるのか」と分かれば十分です。

だから「ほどく」が効く（納得）

仕事を横（工程）と縦（入力→処理→出力）にほどいた瞬間、AIは「魔法の箱」から「任せる相手」に変わります。横で“どこを任せ、どこを自分が持つか”が見え、縦で“その工程に何を渡すか”が決まるからです。これが、すべての出発点になります。

次章では、ほどいた工程の中でも要になる「処理」を、AIにどう伝えるか――つまり考え方の渡し方（原則②）に進みます。

この章の一歩：面倒な業務を1つ選び、まず工程（手順）に分け、そのうち1工程だけを「入力→処理→出力」の3行で書いてみる。 得られるもの：どこをAIに任せ、そこに何を渡せばいいかが、自分の目で見える。

第2章　考え方を渡す ―― プロンプトは“思考の設計図”

なぜ、これが効くのか（原理）

第1章で、仕事を横（工程）と縦（入力→処理→出力）にほどきました。さて、ほどいた工程のうち「処理」――たとえば「自社基準と照らして判断する」――をAIに任せたい。ところが「このNDA、いい感じに見て」と頼むと、返ってくるのは一般論ばかり。理由は、AIの性能ではありません。その処理の“考え方”を、あなたがまだ渡していないからです。

そこで二つめの原則です。

原則②　プロンプトは、結論を命じる呪文ではない。判断の“考え方”を写した設計図である。

新人に「この仕事、どう考えればいいですか」と聞かれたら、あなたはこう答えるはずです。「まずここを見て、こうなら要注意、その根拠はこれで、結論はこの形で書いて」。この役割・手順・良い例・出力の形を、そのままAIに渡したものがプロンプトです。

考え方を渡せた分だけ、AIはあなたの代わりに考えられます。逆に言えば、渡せない部分は、まだあなたの中でも言葉になっていない部分です。

実際の例

第1章で見た二社が、この「考え方」をどう渡したかを見てみましょう。一人で書くプロンプトと、組織でつくる仕組み。スケールはまるで違いますが、やっていることは同じです。

例1：メルカリ ―― 「プロンプト＝仕事の説明書」という捉え方

メルカリは2025年、全社で「AIを前提に再設計された組織（AI-Native）」になると宣言し、100名規模の横断チーム「AI Task Force」を立ち上げました。そのキックオフに招かれた外部の実務家、Nulogic代表のen.氏（AI技術とUXの接続を専門に、多くの企業の導入を支援してきた人）の話が、原則②をそのまま言い当てています。

en.氏は、こう問いかけます。「本当に、生成AIは現場の仕事を変えているのか」。多くの人は「どのツールがいいか」から入るが、本質はそこではない、と。プロンプトを書くこととは、自分の仕事を他人に説明することだ、と氏は言います。新人に「この仕事、どう考えればいいですか」と聞かれたら、あなたは「こういう時はこう判断して、この順でこうする」と説明するはず。あれがそのままプロンプトだ――という、とても具体的なたとえです。

だからAIに「いい感じにやって」と丸投げ（ゼロショット）するのではなく、良い例をいくつか見せ（Few-shot）、考える順番を示し、判断の基準・変換のルール・出力の形までを渡す。en.氏が挙げた身近な例で言えば、「過去のトーク履歴を“思い出”としてまとめて」と命じるだけではダメで、まず「“思い出”とは何か」を自分たちで定義し、トーンの推定基準や、固有名詞を勝手に変換しないルール、出力の形式まで指定して、はじめて使える結果になる。要は、AIに渡す前に「自分たちの曖昧さ」と向き合う必要がある、というわけです。

そして締めの言葉が、この教科書の背骨でもあります。生成AIの導入とは、「自分の仕事を、他人に説明できるようにする」こと。曖昧な業務、属人的な処理、空気で伝えていたものを、構造とプロンプトに変換する作業だ――と（mercan 2025/8、自社メディア）。特別な技術ではありません。一人でも、今日から始められます。

例2：Sansan ―― 「考え方」を組織の資産に育てる

Sansanの法務は、この「考え方を渡す」を、組織の規模でやってのけました。第1章で触れたとおり、出発点の悩みは「判断のコツがベテランの頭の中にしかない（属人化）」こと。そこでまず、ベテランがいつ・何を見て・どう判断するかという思考プロセスを、言葉にしていきました。

見事だったのは、基準のつくり方です。「あるべき論」で理想の基準を書いたのではありません。過去2年・約2万件の契約で、自社が実際に受け入れてきた条件から判断の傾向を取り出し、それを「自社基準（プレイブック）」として起こした。絵に描いた基準ではなく、自社が現実にどう判断してきたかという“事実”を、考え方に変換したのです。

さらに、その基準を一度きりで終わらせない工夫があります。プレイブックをAIが毎回参照できる形（Skills）にして繰り返し使えるようにし、半期に一度は自動で見直して、現場の実態とのズレ（形骸化）を防ぐ。こうしてAIは、一般論ではなく自社の基準に沿って「OK／要注意／NG」を、根拠（基準とのズレ・過去の実績）つきで返すようになりました。しかもその結果は、Wordの修正履歴やコメントという、法務が普段使う形で出てきます（Business & Law 2026/5、スポンサード記事・記述は同社発表）。

二社の違いは“スケール”だけ

メルカリは一人やチームがプロンプトに考え方を写し、Sansanは組織が考え方をプレイブックという資産に育てました。けれど核心は同じ――判断の考え方を、言葉にして渡したこと。だから、あなたは小さく始めて構いません。今日のプロンプトに一行、考え方を足すことが、その第一歩です。

プレイブックとは ―― 法務の判断を、文章にしたもの

ここまで「考え方を渡す」と言ってきましたが、法務でそれを最も役立つ形にしたものがプレイブックです。法務の人がいちばん知りたいところなので、少していねいに説明します。

プレイブックとは、条項ごとに「自社は何を基準に、どこまで許容し、どこからNGか」を文章にしたものです。たとえば「損害賠償」なら、原則は通常損害（直接損害）に限定、上限つきならOK、金額水準が想定を超えるなら要注意、無制限ならNG――というように、判定の物差しを言葉にしておきます。そして各条項に、過去に自社が実際にどう合意してきたか（過去実績）を添えるのが肝心です。

なぜ法務に効くのか。第一に、AIが一般論ではなく自社の立場で判定できるようになります。第二に、ベテランの頭の中にあった判断が文章になり、属人化が解けて新人でも同じ水準でレビューできます。第三に、交渉の場で「過去にこの条件で合意した実績がある」と根拠を持って話せます。プレイブックは、AIのためだけでなく、人とチームのための資産でもあるのです。

作り方は、小さくで構いません。最初から全条項を網羅しようとしないこと。まず、よく揉める1〜2条項（損害賠償・NDAなど）だけを手で定義し、あとは案件をこなすたびに「今回はこう合意した」を書き足して育てます。Sansanのように過去数千〜数万件から起こせれば理想ですが、そこは出発点ではなく到達点です。

そして、保守を忘れないこと。新しい合意を改訂ログに足し、半期に一度は基準を見直す。これを怠ると、プレイブックはすぐ現場と食い違って“形骸化”します。Sansanが半期ごとに自動で更新していたのは、まさにこのためでした。

あなたの番（今・次・得られるもの）

ここからは、あなたが今日、自分の手で動かすことです。自分のレベルの行だけ見てください。なお、ここで使う型は、コピーして使える形で付録Cにまとめています（プロンプトの土台＝C-1、良い例の見せ方＝C-2、プレイブック＝C-3）。

第1章でほどいたNDAレビューの工程③「自社基準と照らす」を例に、法務の仕事で見てみましょう。

• はじめて：頼み方を変えるだけです。「あなたは当社の法務担当。次の順で見て――①秘密情報の定義が広すぎないか ②有効期間 ③目的外使用の禁止。各点をOK／要注意／NGで、理由を一言添えて」。手順と出力の形を渡しただけで、答えが安定します。
• つかっている：そこに良い例を足します。「過去に、秘密情報が無限定だった条項を“書面で指定したものに限る”と直した」のような自分の良い判断を、固有名や数字は伏せて2〜3個。AIはあなたの判断のクセを学び、より近い答えを返します。
• 仕組みにしたい：その手順と決めごとを、頭の中からプレイブック（文章化した自社基準）に移します。過去に合意してきた条件も基準に加え、チームで共有。こうすると、誰がやっても同じ水準でレビューできます。

つまずいたら - 手順をどう書けばいいか分からない ―― 新人に口頭で教えるつもりで、「まずここを見て／こうなら要注意／根拠はこれ」と話し言葉で書けば十分です。 - 良い例（Few-shot）に何を使う？ ―― 過去の自分の良い判断です。ただし守秘に注意し、相手名・金額などは伏せて、“考え方の型”だけを渡します。 - AIが自社基準を無視する ―― 基準を箇条書きで渡し、「この基準に反する条項は必ずNGと書く」「根拠が無ければ“要確認”と書く」と、守らせ方まで指定します。

その先を覗いてみる ―― つくるとこんな感じ（読むだけでOK）

すぐ上の「あなたの番」があなたが動くことだったのに対し、ここは、その考え方をプレイブックという“形”にすると何になるかの覗き見です。作らなくても、雰囲気だけ受け取ってください。

法務でいちばん効く形が、先ほどのプレイブックです。条項ごとに、自社の判断基準と過去実績を書いておきます。たとえば「損害賠償」なら、こんな具合（付属キット templates/playbook-template.md の抜粋）。

## 条項：損害賠償
- 基準：原則、賠償範囲は通常損害（直接損害）に限定。
- 🟢 OK：通常損害に限定＋上限あり。
- 🟡 要注意：上限の金額水準が想定を超える／間接損害を一部含む。
- 🔴 NG：無制限、または逸失利益・間接損害を無条件で含む。
- 過去実績：相手方が無制限を要求 → 「故意・重過失のみ無制限、通常は直接損害に限定」で合意した例あり（C-0003）。

## 改訂ログ
- 2026-05-20: 損害賠償の上限水準の目安を追記。

条項ごとに、基準（OK／要注意／NGの線引き）と過去実績、そして改訂ログ。これがプレイブックの中身です。あとは、これをAIに読み込ませるだけ――手早く使うならプロンプトの「自社プレイブック」欄に貼り、常時参照させるなら templates/skills/contract-review/SKILL.md から読ませます。するとAIは一般論ではなく、この基準と過去実績で「OK／要注意／NG＋根拠」を返します。作らなくても、「自社の判断は、こういう“形”にして残せるのか」と分かれば十分です。

だから「渡す」が効く（納得）

プロンプトは、命令ではなく説明です。自分の仕事を言葉にできた分だけ、AIはあなたの代わりに考えてくれます。これが、序章で触れた「業務の言語化」の入口であり、この教科書がいちばん大事にしている考え方です。

ただし、考え方を渡しても、AIは間違えます。次章では、その間違いと上手につき合う方法――小さく始めて、人が確かめる（原則③）に進みます。

この章の一歩：頻出する論点を1つ選び、「役割＋判断の手順＋出力の形」を3〜5行で書いて、AIに渡してみる。 得られるもの：AIの答えが、あなた自身の判断にぐっと近づく。

コラム：コンテキストマネジメント ―― AIに「何を・どれだけ」渡すか

気になる人向けの寄り道です。読み飛ばしても本筋は通ります。

「渡し方」を突き詰めると、近ごろ「コンテキストマネジメント（コンテキストエンジニアリング）」と呼ばれる話に行き着きます。言葉が新しく、論者によって範囲が違うので、この教科書ではAnthropicのエンジニアリング記事「Effective context engineering for AI agents」（2025年9月）の定義に拠ります（出典）。そこでは、コンテキスト＝AIが答えを作るときに渡される「情報（トークン）のまとまり」、コンテキストマネジメント＝その情報を、目的に合うよう取捨選択し、ちょうどよい状態に保つこと、とされています。

平たく言えば、AIには一度に見渡せる情報量の上限（コンテキストウィンドウ）があり、多すぎると焦点がぼやけ、少なすぎると的外れになる。だから「何を入れ、何を入れないか」を選ぶことが、答えの質を決めます。これは新しい難題ではなく、原則①（入力をほどく）と原則②（考え方を渡す）の合流点です。プレイブックを丸ごと貼るより必要な条項だけ、過去の会話を全部より要点だけ。そして付録Bの「機密は入れない」も、実は最も大事なコンテキストマネジメントの一つです。

ここで法務の人に効く話を一つ。コンテキストは、目の前のプロンプトだけではありません。案件の経緯（誰が・なぜ・どういう狙いで）や、契約交渉のプロセス（どの条項で揉め、どう折り合ったか）も、立派なコンテキストデータです。ところが、これらは担当者の頭やメール、バラバラのファイルに散らばりがち。だからコンテキストマネジメントは、法務でいうナレッジマネジメント（組織の知見を、後から引ける形に整える営み）と地続きになります。整っていない知見は、AIにも人にも渡せません。

では、どう整えるか。鍵はタグ（メタデータ）と整理整頓です。過去の取引事例に、法令名（例：下請法）・論点名（例：再委託の可否）・業界名・取引類型・相手方の業種といったタグを付けておくと、検索も分類も一気に楽になります。第1章でSansanが契約を項目化し、名寄せや親子関係でつないだのも、第2章のプレイブックに過去実績を添えたのも、根は同じ——AIが「点と点をつなぎ」やすく、取り違えにくくするための下ごしらえです。タグのほかにも、命名規則をそろえる、論点を見出し化する、交渉経緯を数行に要約して残す、用語の表記ゆれを名寄せする…と、派手でない工夫がいろいろあります。たとえば、こんな一行を案件ごとに残しておくだけでも違います。

案件ID：M-0007／法令：下請法／論点：再委託の可否／業界：製造／類型：業務委託
経緯：相手方が一律禁止を要求 → 事前承諾制で合意（理由：運用負荷の回避）

こうして整えておくと、AIは「過去に下請法の再委託で揉めた製造業の案件は？」にも、推測ではなく事実で答えられます。要するにコンテキストマネジメントとは、その場の渡し方の工夫と、渡せる知見をふだんから整えておくことの両輪。後者は原則①の「入力を整える」を、単発の契約から案件・交渉プロセス・組織のナレッジへと広げたものです（タグで絞り込んで検索させるしくみは、第4章コラムのRAG・接地にもつながります）。

第3章　小さく始めて、人が確かめる ―― Human-in-the-Loop

なぜ、完璧を目指してはいけないのか（原理）

前章で、判断の考え方をAIに渡しました。けれど、渡してもなお、AIは間違えます。揺らぎます。だからといって「完璧に使えるようにしてから導入しよう」と構えると、いつまでも始められません。

そこで三つめの原則です。

原則③　最初から完璧な自動化を目指さない。AIは間違える前提で、“人が最後に確かめる”形にして、小さく始めて直していく。

これは妥協ではなく、いちばん安全で、いちばん速いやり方です。第1章でほどいた工程のうち、まず1つだけをAIに任せ、その出力を人が確認する。人が輪の中にいる（Human-in-the-Loop）から、安心して任せられます。

実際の例

例1：メルカリ（en.氏）―― 「人が確認する前提」で設計する

第2章で紹介したen.氏は、三つめの原則をこう言い切ります。「AIは間違える。揺らぐ。だから“人が確認する前提”で設計しないと、むしろ業務リスクが高まる」。そのうえで、Human-in-the-Loopを、生成AI時代の“業務デザインのパターン”だと位置づけました。

氏が挙げた具体例が分かりやすいので、法務に置き換えて紹介します。たとえば履歴書のスクリーニングのように「人を見る」仕事にAIを入れるなら、こう設計する――まずPDFを読み取ってテキスト化し（前処理）、AIで「要件にどれだけ合うか」をスコア評価し、その一覧を見て最後は人が判断する。AIに丸ごと決めさせるのではなく、AIは“一次評価”まで、決定は人。これを契約審査に移せば、AIが条項ごとに一次レビュー（根拠つきの下書き）をし、人が確認して確定する、という形になります（mercan 2025/8、自社メディア）。

メルカリの法務チーム自身も、いきなり大きな自動化に挑んではいません。「要約」「英訳」といった、誰でもできて失敗してもこわくない小さな作業から“小さな成功体験”をつくり、ハッカソンで試し、うまくいったノウハウを「どうぞ使って」と社内に配っていきました（mercan 2025/10、自社メディア）。小さく始める。これが文化として効きます。

例2：DeNA ―― 小さなTipsを配り、最終確認は人に残す

DeNAは、現場が今日すぐ試せる小さなAI活用の“Tips集”を、全社で共有しています。法務まわりで紹介されているのは、たとえば契約書の新旧対照表を自動でつくる、規約や海外法令の変更をモニタリングするといった、地に足のついた使い方です。派手な全自動ではありません。

そして全体に一本、太い背骨が通っています。ハルシネーション（もっともらしい嘘）が起きる前提で運用し、最終確認は必ず人が行うこと。DeNAはAI活用を「攻め」と「守り」の両輪で捉え、攻めのスピードを出しながらも、既存の統制の仕組みにAIを組み込み、人の確認を外さない設計にしています（DeNA Engineering 2025/8、自社技術ブログ／AI活用100本ノック、自社公開資料）。

例3：キリンHD ―― 小さく始めて、文化として広げる

「小さく始める」は、一人で終わらせず、組織に広げてこそ効きます。キリンHDは独自の生成AIを社員の“相棒”と位置づけ、数か月で利用率70%に達したと紹介されています。鍵は、いきなり高度な使い方を強制しないこと。アンバサダー制度で身近な相談相手をつくり、新入社員が講師を務める研修まで用意して、「まず触ってみる」を全社に広げました（日本の人事部、媒体インタビュー。利用率は二次情報）。小さな成功体験を、人から人へ。これも立派な「小さく始める」の形です。

確かさを上げる工夫：根拠を添えて、人を「検証役」にする

もうひとつ、確かさを上げるコツがあります。第1章・第2章のSansanは、AIの判定に必ず根拠（自社基準とのズレ・過去の実績）を添えさせていました。これが効くのは、人の仕事が「ゼロから判断する」から「根拠を検証する」に変わるからです。ゼロから考えるより、示された根拠が正しいかを確かめるほうが、速くて確実。人が輪に入ることが、足かせではなく“加速装置”になります。

プレイブックも、一気に作らない ―― 育てるもの

ここで、第2章で紹介した「プレイブック」に戻ります。プレイブックにも、この原則③がそのまま当てはまるからです。

ありがちな期待は、こうです。「これまでの契約審査マニュアルと過去事例をぜんぶAIに読ませれば、完成したプレイブックができあがって、契約審査が自動化できるのでは？」。残念ながら、そうはいきません。マニュアルは抽象的だったり古かったりしますし、過去事例には「なぜそう合意したのか」という肝心の理由が書かれていないことがほとんど。AIが作る下書きは、もっともらしく見えても、自社の本当の判断とズレます。それを検証せずに使えば、むしろ危険です。

だから、プレイブックも、一気に作り込むものではなく、小さく始めて人が確かめながら育てるものです。手順はこうなります。

1. まず、よく揉める1〜2条項だけに絞る。
2. マニュアルや過去事例から、AIに基準の下書きを作らせる（ここはAIが速い）。
3. その下書きを、人が一件ずつ確かめる。「この基準は本当に自社の判断と合っているか」「この過去実績は、なぜこう合意したのか」を問い直す。
4. 実際の案件で使ってみて、外れたら直す。新しい合意は改訂ログに足す。

こうして、使うほど自社にフィットしていく。「読ませれば自動化」ではありません。「人が確かめながら育てる」のです。第2章で触れた、Sansanが過去約2万件からプレイブックを起こしたという話も、一足飛びの自動生成ではなく、言語化と検証を積み重ねた“到達点”でした。出発点は、あなたの目の前の1条項です。

あなたの番（今・次・得られるもの）

ここからは、あなたが今日、自分の手で動かすことです。自分のレベルの行だけ見てください。AIの出力を確定する前のチェックリストは、付録C-4にそのまま使える形で載せています。

第1章でほどいたNDAレビューの工程を例に、法務の仕事で見てみましょう。

• はじめて：工程のうち、失敗しても痛くない1つ――たとえば④「修正案のたたき台づくり」だけをAIに任せ、必ず自分で確認します。最終的に相手へ返す判断は、自分が持つ。これなら安心して試せます。
• つかっている：1週間、同じNDAレビューを「これまでどおり手で」と「AIの一次レビュー＋自分の確認」の両方で回し、かかった時間とミスの有無を記録します。差が出たら、その記録をチームに見せる。広げる根拠になります。
• 仕組みにしたい：AIに判定だけでなく根拠（自社基準とのズレ・過去実績）を必ず出させる設計にし、毎週いくつかの出力を抜き取って点検する場を定例にします。精度と信頼が同時に上がります。

つまずいたら - どこまでAIに任せていい？ ―― 目安は「事実の整理・下書き・一次評価はAI、最終判断・交渉・責任は人」。この線引きを、始める前に決めておきます。 - 間違えるのが不安 ―― 間違える前提で構いません。人が確認する工程を必ず残します。むしろ「AIに根拠を出させて人が検証」する方が、ゼロから人がやるより速く確実です。 - 小さく始めると物足りない／評価されない気がする ―― 小ささは恥ではありません。1業務でも時間を記録すれば、広げるための立派な根拠になります（メルカリやキリンHDも、そこから広げました）。 - マニュアルや過去事例をAIに読ませれば、プレイブックは完成する？ ―― いいえ。下書きはできますが、もっともらしくても自社の判断とズレます。人が一件ずつ確かめて直し、使いながら育てるもの。まず1〜2条項から。

その先を覗いてみる ―― つくるとこんな感じ（読むだけでOK）

「あなたの番」があなたが動くことだったのに対し、ここは、その“人が確かめる”を、どうやって道具に組み込んで離さないかの覗き見です。作らなくても、雰囲気だけ受け取ってください。

第2章で見た契約審査のスキルには、判断の手順だけでなく、人の確認を外さないための「禁止事項」が書き込まれています（付属キット templates/skills/contract-review/SKILL.md の抜粋）。

## 禁止事項
- 過去実績や基準の捏造をしない。確認できない事項は「要確認」と書く。
- 最終的な合意可否を断定しない（判断は人が行う）。
- 機密情報を会話外に持ち出さない。

ポイントは、「人が確認する」を心がけや運用に頼らず、ツールのルールとして固定してしまうこと。こう書いておけば、AIは根拠が無いときに勝手に断定せず「要確認」と返し、最終判断は必ず人に戻ってきます。作らなくても、「人が確かめる仕組みは、こうやって道具に埋め込めるのか」と分かれば十分です。

だから「小さく」が効く（納得）

完璧を目指さないから、続きます。小さく始めるから、自分のペースで一段ずつ上がれます。そして人が輪の中にいるから、安心して任せられる。AIに振り回されるのではなく、あなたが主導権を持ち続けるための原則です。

次章は、その道具をどう選ぶか――出来合いの力を借りる巨人の肩に乗る（原則④）に進みます。

この章の一歩：失敗していい小さな工程を1つ、今週AIに任せて、自分で確認する。 得られるもの：最初の手応えと、「これなら続けられる」という感覚。

コラム：AIガバナンス ―― 「攻め」と「守り」を両輪にする

気になる人向けの寄り道です。ただし、法務の人にはむしろ本丸に近い話です。

ここまで「人が確かめる」を、個人の工程として見てきました。これを組織全体の仕組みに広げたものが、AIガバナンスです。ひとことで言えば、組織としてAIを安全に・責任をもって活用するための、方針・体制・運用・点検の仕組み。そして法務は、その設計の主役になりやすい立場にいます。

肝は、第3章でDeNAが示した「攻め」と「守り」の両輪です。守り＝データ保護、シャドーAI対策（付録B）、利用ルール、ログと監査、リスク評価、そして人の最終確認。攻め＝活用の推進、使ってよい範囲のガイドライン整備、人材育成、成功事例の共有。守りだけだと現場が萎縮し、攻めだけだと事故が起きる。両輪でこそ、安心して速く進めます。第4章で見たエージェントが増える局面では、「誰が・何に・どこまでアクセスしてよいか」とログの統制（Agent 365のような仕組み）も、守りの一部になります。

拠るべき物差しもあります。日本では、総務省・経済産業省の「AI事業者ガイドライン」が統一的な指針です（初版2024年4月→最新は第1.2版 2026年3月。本編が「何を目指し何に取り組むか（why／what）」、別添が「どう実践するか（how）」で、別添には全主体向けのチェックリストもあります）（出典）。米国のNIST AIリスクマネジメントフレームワーク（AI RMF）やEUのAI Actとも整合が図られ、さらに日本では「人工知能関連技術の研究開発及び活用の推進に関する法律」が2025年に施行されました。ガバナンスも、原則③と同じで小さく始めるのがコツです。まずは「利用ルール1枚」と「機密は学習され得る個人向けプランに入れない」という約束（付録B）から。そのまま使える利用ルールの雛形と簡易チェックリストは、付録Eに用意しました。 それが、組織にとっての“人が確かめる”の第一歩です。

コラム：AI時代のOJTはどうなるのか

気になる人向けの寄り道です。読み飛ばしても本筋は通ります。

不安があります。これまで法務の新人は、契約を大量に読み、調べ、ドラフトを書く――そんな地道な作業を数こなすなかで、判断の勘を養ってきました。AIがその下働きを引き受けるなら、学びの道が細るのではないか。手を動かさなければ、理解は深まらないはずだ、と。

もっともな心配です。ただ、AIは「理解しなくてよくする道具」ではありません。むしろ逆で、本章で見たとおり、AIの出力を確かめるには、自分が“正しい答え”を分かっていないと検証できません。丸投げして素通りすれば力はつきませんが、根拠を吟味し、違和感を言葉にし、直す――この「確かめる」作業そのものが、判断力を鍛える濃い訓練になります。さらに、自分の仕事を言語化してプレイブックやスキルに落とす作業（第2章）は、暗黙知を見える化し、作る過程で自分の理解を深めます。冒頭の「この本について」で触れたとおり、教科書を作り育てる過程が、いちばんの学びになるのです。

だから、AI時代のOJTは「やらせない」ではなく「何を・どう経験させるか」を設計し直すこと、と捉えるとよさそうです。たとえば――不確実な状況での判断、相手との交渉、摩擦の調整といった人にしかできない領域は、意図的に場数を踏ませる。新人にはあえて手を動かして全体像をつかませ、ベテランは「なぜそう判断したか」の背景を語る。そして組織としては、「AIに任せてよい工程」と「経験として人が通すべき工程」を分けて決め、その育成の観点を、ガバナンス（前コラム）や利用ルール（付録E）にも織り込む。AIは学びを奪うのではなく、学び方を変えます。確かめ、言語化し、人にしかできない部分を意図して経験する――それが、AI時代のOJTです。

第4章　巨人の肩に乗る ―― 汎用ツール優先、自作は最後

なぜ、自分で作らないほうがいいのか（原理）

ここまで来ると、「うち専用のAIツールを作らなきゃ」と思いたくなります。でも、ちょっと待ってください。生成AIの世界は、文字どおり日単位で進化します。今日がんばって作ったものが、来月には汎用ツールの標準機能になっているかもしれません。

そこで四つめの原則です。

原則④　まず出来合いの汎用ツールを工夫して使う。自作は最後。空いた力は、道具づくりではなく“仕事をよくすること”に使う。

巨人（すでにあるツール）の肩に乗れば、高いところから始められます。自分でやぐらを組む必要はありません。大事なのは、ツールを作ることではなく、第1章でほどき、第2章で言葉にし、第3章で小さく確かめてきた「業務そのもの」を良くすることです。

実際の例

例1：メルカリ（en.氏）―― はっきりした優先順位

第2章・第3章で紹介したen.氏は、ツールについて明快な優先順位を示しました。氏いわく、生成AIのフロントは日単位で進化し、UIもAPIもすぐ変わる。なのに自社でツールを作り込めば、すぐ陳腐化してしまう。だから、こう進めるべきだと。

1. ChatGPT・NotebookLM・Geminiなどの汎用ツールを“工夫して使う”
2. 社内ツールに“最小限のAI拡張”を足す
3. SaaS連携や自動化を使う
4. どうしても必要なときだけ、ツールを自作する

そして、こうして浮いた力を、本質である「業務の再設計」に割くほうが生産的だ、と（mercan 2025/8、自社メディア）。順番が大事です。多くの人は、いきなり4番目から考えてしまうのです。

例2：DeNA ―― 賢く借りて、乗り換えられる状態を保つ

DeNAは、50種類を超えるAI製品を使い分けています。その選び方が参考になります。見るのは三つ――①ガバナンス（利用規約や、入力したデータがどう扱われるか）②コスト③運用の手間。さらに、特定の製品に依存しすぎないよう、乗り換えやすさ（ポータビリティ）も重視します。新しいツールのトライアルは、本番データを入れずに、1〜2営業日で手早く試す。借りる相手は固定せず、いつでも別の巨人に乗り換えられる状態を保っているわけです（DeNA Engineering 2025/9、自社技術ブログ）。

例3：日本ペイントHD ―― 出来合いを「自社の情報」に接地する

日本ペイントホールディングスは、ゼロからモデルを作るのではなく、グループ共通の生成AI「NP ASSISTANT」を導入し、約70%の社員が使うまで広げました。法務はまず、業務をコア（人にしかできない付加価値）とノンコア（AIで支援できる）に分類し、ノンコアをAIに任せます。さらに法務のチャットボットは、社内の稟議規程や契約ひな型を優先的に検索してから回答することで、的外れ（ハルシネーション）を抑えています。これは「接地（グラウンディング）」と呼ばれる工夫で、出来合いのAIを自社の情報につなぐだけで、ぐっと実用的になります（Business & Law 2026/1、登壇レポート）。

例4：日本マイクロソフト ―― Microsoft 365 Copilotを、業務の中で使い倒す

ツールの作り手側の法務部門も、同じ道を歩んでいます。日本マイクロソフトの政策渉外・法務本部は、2023年10月から Microsoft 365 Copilot（Word・Outlook・Teamsなどに組み込まれたAIアシスタント）を導入し、日々の業務に活用しています。強みは、AIを別に立ち上げず、作業の流れを止めずに各アプリ上で支援を受けられること。具体例も地に足がついています――英文契約のレビューでは、日本語で「支払方法の条文を追加して」と指示すれば前後の文脈を踏まえた英文条項案が返り、関係者から分散して届く修正意見も一覧に集約できます。Teams会議では多言語の文字起こし・翻訳・要約（要約には参照箇所へのリンクが付き、引用元で正誤を確かめられる）。

注目は、第4章の主題「接地（グラウンディング）」をそのまま実践している点です。検索を「職場（社内資料）」と「Web」に切り分け、さらに情報源を絞り込む。たとえばGDPRや個人情報保護法の調べものでは、Web全体ではなく個人情報保護委員会のガイドライン等に情報源を限定して答えさせ、出典リンクで信頼性を確かめます――まさに原則④で見た「出来合いを自社・公式情報に接地する」工夫です。安全面も、入力やアウトプットは基盤モデルの学習に使われない設計だと説明されています（詳しくは付録B）。

そして、この章でいちばん大事な一線も外していません。同部が強調するのは、Copilot（＝副操縦士）という名のとおり、AIはアシスタントであって主体は人であること、そしてヒューマンレビューは欠かせないという姿勢です（原則③）。さらに同部のメンバーは、これからの脅威は「AIに置き換えられること」ではなく「生成AIを当たり前に使いこなす若手に追い越されること」だと言い、“生成AIを当然のように使う感覚”を、法務に不可欠な能力と位置づけます。これはこの教科書の主題――法務のAIネイティブ化――を、現場の言葉で言い当てたものです（Business & Law 2025/1、スポンサード記事）。

四社に共通するのは、作るより、借りて・選んで・つなぐこと。賢さの自前開発で競うのではなく、出来合いの巨人をどう自社に合わせるかで勝負しています。

ツールの階段（あなたのレベルと対応づけて）

では、どの巨人の肩から乗ればいいのか。図4-1の階段を、レベルごとに具体化します。下の段で十分なら、上へ行く必要はありません。

• はじめて：まずは ChatGPT・Gemini・Microsoft Copilot のプロンプトの工夫から。第2章の「役割・手順・出力の形」を、公開データで練習します。これだけで多くのことができます。
• つかっている：GPTs や Gemで“自分用の型”を作り（毎回同じ前置きを書かずに済む）、NotebookLMに資料を読ませて、根拠つきで答えさせます。
• 仕組みにしたい：Google Drive × Gemini や Microsoft 365 Copilot（SharePoint／OneDrive／Teamsの社内資料を踏まえて答える）のように、自社が使う基盤とAIを連携させます。さらに Claude Cowork のような業務エージェントに、一連の作業をまとめて任せます。
• つくる人：Claude Code や Codex のようなコーディング・エージェントで、MCP（社内システムとAIをつなぐ規格）やスキルを使い、自社の契約DBなどに直接つなぎます。ここは作りたい人だけでOK。

くり返しますが、多くの人は最初の1〜2段で十分です。階段はいつでも、自分のペースで上れます。

会社アカウント／個人アカウントでできること

「うちの会社、まだAIを正式導入していない」。そんな場合でも、できることはあります。ただし、何のアカウントで使うかで、できること・守るべきことが変わります。

個人アカウント（無料プランや個人の有料プラン）でできること 公開されている法令・ガイドライン・ひな型を使ったプロンプトの練習、自分用のGPTやGemづくり、NotebookLMに公開資料を読ませる、といったことができます。作りたい人なら、オープンソースのツール（後述する応用編のMike OSSなど）を自分のAPIキーでローカルに動かすこともできます。ただし注意がひとつ。個人向けプランは、入力が学習に使われることがあります。学習をオフにする設定を確認し、機密情報や顧客データは入れない。練習はあくまで公開データで。

会社アカウント（エンタープライズ契約・管理者が承認したもの）でできること 会社の契約（DPA＝データ処理契約など）のもとでは、入力が学習に使われないことが担保され、データ保護の設定も選べます。だからこそ、自社データとの連携（Google Drive、Microsoft 365、MCPでの契約DB接続）、Microsoft 365 Copilot／Copilot Chat（エンタープライズデータ保護つき）で社内資料を踏まえた回答、Claude Cowork や Claude for Legal の法務向け機能、Claude Code／Codex での自社システム連携といった、踏み込んだ使い方ができます。

つまり、「自分のペースで練習するのは個人アカウントで公開データから、業務データを扱うのは会社アカウントで」が基本の線引きです（詳しくは付録B）。

あなたの番（今・次・得られるもの）

ここからは、あなたが今日、自分の手で動かすことです。自分のレベルの行だけ見てください。

法務の仕事で言えば、はじめては、会社が承認したAIでNDAのたたき台レビューを試す。つかっているは、自分用の「NDAレビューGPT」を作り、第2章のプレイブックを読ませておく。仕組みにしたいは、契約DBにつないで「貼り付けずに」過去契約を参照させる。階段の同じ段でも、まずは公開データやサンプルで練習し、業務データは会社アカウントで、の順を守ります。

つまずいたら - どのツールを選べばいい？ ―― 自社が普段使う基盤に合わせるのが近道です。Google中心ならGemini、Microsoft中心ならCopilot。新しい一番を探すより、足元の巨人に乗りましょう。 - 会社がまだ正式導入していない ―― それでも個人アカウント＋公開データで練習はできます。そこで作った“型”や効果の記録が、正式導入を会社に提案する材料になります。 - 自作しないと本格的じゃない気がする ―― 逆です。作らずに済むなら、それがいちばん筋がいい。浮いた時間を業務の見直しに使えます。

その先を覗いてみる ―― つくるとこんな感じ（読むだけでOK）

「あなたの番」があなたが動くことだったのに対し、ここは、階段のいちばん上――自社のデータに“つなぐ”と何ができるかの覗き見です。作らなくても、雰囲気だけ受け取ってください。

これまでの章では、契約データやプレイブックを会話に貼り付けて渡していました。階段の上では、それを貼らずに、AIが自社の契約DBに直接つないで読みます。仕組みは MCP（Model Context Protocol＝AIと社内システムをつなぐ共通規格）。たとえば、こんなやり取りが、貼り付けなしで成立します。

あなた：来月、解約通知の期限が来る契約は？
AI    ：（契約DBに直接問い合わせて）3件あります。C-0001（○○商事・基本契約）ほか。
        いずれも「3か月前通知」のため、対応期限は今月末です。

手順や設定は、付属キットの toolkit/05-claude-code/（MCP連携）にまとめています。ただし、これは“つくる人”向けの最上段。多くの人は、貼り付けで使う1〜2段で間に合います。作らなくても、「つなぐと、ここまでなめらかになるのか」と分かれば十分です。

だから「肩に乗る」が効く（納得）

巨人の肩に乗るほど、あなたは「道具を作ること」ではなく「仕事をよくすること」に集中できます。難しいことができるのが偉いのではありません。 自分に合った道具を、自分のペースで使えればいい。それが、いちばん遠くまで行ける道です。

次章は任意の「もっと先へ（応用編）」。法務に特化した新しい道具や、法務が“作る・評価する”側に回る動きを、見渡してみます。今いる場所で十分なら、読み流して終章へ進んでも構いません。

この章の一歩：会社が承認した汎用AIを1つ、今週の仕事で実際に使ってみる。 得られるもの：巨人の肩に乗る感覚と、「これで十分だ」という安心。

コラム：RAG（検索拡張生成）―― 接地のしくみと、NotebookLMで足りる話

気になる人向けの寄り道です。読み飛ばしても本筋は通ります。

本章で触れた「接地（グラウンディング）」を、もう一段だけ掘ると「RAG」という言葉に出会います。RAG（Retrieval-Augmented Generation＝検索拡張生成）は、Lewisらの論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」（NeurIPS 2020／当時Facebook AI Research）で提唱された言葉で、この教科書はこの原典の定義に拠ります（出典）。中身はシンプルで、AIが答える前に、外部の資料から関連箇所を検索して取ってきて、それを根拠に答えを作るしくみです。モデルの記憶だけに頼らないので、最新・自社固有の情報を反映でき、ハルシネーションを抑えられます。

第4章の日本ペイントHDが「社内規程を先に検索してから答える」ことで的外れを防いでいたのは、まさにRAGの実務的な姿です。そしてNotebookLMも、渡した資料だけを検索して出典つきで答える、いわば“出来合いのRAG”。だから法務の多くの用途（手元の資料に基づく要約・調べもの）は、NotebookLMや会社基盤の接地で十分まかなえます。自前でRAGを組む（ベクトルDBなどを用意する）のは、大量の社内文書を常時・横断的に扱いたくなったときの最後の手段——つまり原則④（巨人の肩に乗る、自作は最後）そのものです。どの段でも、出力には引用を添えさせ、人が検証する（第3章・第5章）のは変わりません。

コラム：AIエージェント ―― 「任せる」とは何を指すのか

気になる人向けの寄り道です。読み飛ばしても本筋は通ります。

「エージェント」は、いま最も定義が割れる言葉です。ツールを使うLLMを何でもエージェントと呼ぶ人もいます。混乱を避けるため、この教科書はAnthropicのエンジニアリング記事「Building effective agents」（2024年12月）の整理に拠ります（出典）。そこでは、AIを使う仕組み全体を「エージェント的システム」と呼び、中をこう分けます——ワークフロー＝人があらかじめ決めた手順（コード）のとおりにLLMと道具を動かすもの／エージェント＝LLMが自分で手順と道具の使い方を判断しながら進めるもの。

平たく言えば、単発の指示で決まった処理を回すのが「ワークフロー寄り」、目的を渡すと自分で段取りして複数の作業をこなすのが「エージェント」です。第4章の階段の最上段、Claude Cowork や Claude Code／Codex がその入口で、第5章のClaude for Legalのマネージド・エージェントも同じ系譜にあります。注意したいのは、任せる範囲が広がるほど、原則③（最後は人が確かめる）が効くこと。Anthropic自身も「人のレビューは不可欠」「まず一番シンプルな方法を選び、必要なときだけ複雑にする」と述べています。エージェントは万能の上位互換ではなく、向き不向きのある道具の一つです。

Microsoftの「エージェント」は、もう少し広い　言葉の揺れの実例として、Microsoftの使い方が分かりやすい。Microsoftは、Microsoft 365 Copilot（Word・Outlook・Teamsなどに組み込まれたAIアシスタント）に加えて、特定の業務に特化した「Copilotエージェント」を用意しています。これは「指示・知識・スキルを束ねたCopilotの“あつらえ版”」で、簡単なものは Copilot内の Agent Builder で、本格的なものは Copilot Studio（ローコードの構築・管理基盤）で作れます。さらに増えたエージェントを統制する Agent 365 も登場しました（Microsoft Learn、ベンダー公式）。Microsoftは「単純な一問一答から、最初から最後まで自走するものまで」を幅広く“エージェント”と呼ぶので、Anthropicの整理でいうワークフロー寄りのものも含めて「エージェント」と総称します。つまり同じ言葉でも、各社で指す範囲が違う。だからこそ、この教科書のように「どの定義に拠っているか」を確かめてから話すのが安全です。法務での入口は、社内資料に接地した知識Q&Aエージェントや、契約レビューの下書き役。いずれも原則③（最後は人が確かめる）の上で使います。

第5章　もっと先へ（応用編）―― 法務が「作る・評価する」側に回る

この章は、読み流してOK

ここは任意の章です。今いる場所で十分だと感じたら、飛ばして終章へ進んでかまいません。「仕組みにしたい」「作ってみたい」という人が、世界の最前線でいま何が起きているかを地図として眺めるための章です。

ひとつお断りを。ここで紹介するのは、2026年時点の選択肢の一例にすぎません。この分野は驚くほど速く動くので、細かい仕様は各リンク先で最新をご確認ください。また、いずれの道具も法的助言そのものではなく、出力は人がレビューする前提です（この点はこの教科書を通じて変わりません）。

何が起きているのか

これまで、法務向けのAIは専門ベンダーの“黒い箱”が中心でした。いま、その風景が変わりつつあります。ひとつは、Claudeのような基盤モデルが、法務のワークフローに直接降りてきたこと。もうひとつは、オープンソースの動きが広がり、法務担当者が「ツールを使う」だけでなく、「自分で作る・評価する」側に回り始めたことです。

おもしろいのは、その最前線に共通する設計思想が、この教科書の原則とぴたりと重なることです。オープンソースで中身が見える／自分の鍵（APIキー）で自前運用する／答えには引用（出典）を必ず添える／人が最終確認する。第3章の「根拠を添えて人が検証する」、第4章の「巨人の肩に乗る」が、最先端でもそのまま生きています。

4つの道具

Claude for Legal（Anthropic）―― 束ねて使う

2026年5月にAnthropicが公開した、法務向けの提供です。Claudeと、その作業環境であるCoworkの上に、契約管理・文書管理・リサーチといった既存の法務プラットフォームをMCPで束ねる“オーケストレーション層”として位置づけられています。契約・コーポレート・労務・プライバシーなど、領域別のプラグインも用意されました。注目すべきは、その中身が SKILL.md や JSON で書かれていて、弁護士がプログラミングなしで読めて編集できること。そして、出力はあくまでレビュー前提のドラフトだと明記されています（Artificial Lawyer 2026/5 ／ Legal IT Insider、いずれも媒体）。

Mike OSS（Will Chen）―― 自分の鍵で、使う・作る

元Latham & Watkinsの弁護士が、わずか数週間で作り、無料・オープンソースで公開した法務AIです（名はドラマ『SUITS/スーツ』のマイク・ロスから）。商用大手に匹敵する機能――文書のドラフト・レビュー、複数文書の一括レビュー、検証可能な引用――を備えつつ、自分のClaude/Gemini/OpenAIのAPIキーで動かします。最大の利点は、ローカルに自己ホストすれば、書類が自分のPCから一切出ないこと。これは第4章で触れた「シャドーAI」の不安を、根っこから断ちます。引用はページと原文に紐づき、ハルシネーションのない出力を掲げています（mikeoss.com ／ GitHub: willchen96/mike、公式／OSS）。

Harvey LAB（Harvey）―― 評価する物差し

法務AI大手のHarveyが2026年5月に公開した、オープンソースの評価ベンチマークです。24の実務領域・1,200を超えるタスク・7.5万件の専門家ルーブリックで、AIエージェントが実際の法務の仕事をどこまでこなせるか（すべて／一部／できない）を測ります。狙いは、AIに任せられる範囲を見える化し、導入の費用対効果を判断できるようにすること。「どのツールが良いか」を雰囲気で語るのではなく、物差しで測る時代に入った、ということです（Harvey 公式ブログ 2026/5 ／ GitHub: harveyai/harvey-labs、公式／OSS）。

LegalQuants ―― 作る側へ回る人たちのコミュニティ

「コードを書く法務（リーガル・クオンツ）」を集めた招待制のコミュニティです。発想は明快で、AIの時代に法務は二つに分かれる――既製ツールを“使う人”と、自ら設計・検証・実装する“作る人”。LegalQuantsは後者を増やそうとしています。コミュニティは、lq-ai・lq-skills・privacyquant といったオープンソース群を持ち、この教科書の付属キットと同じ SKILL.md 形式・MCP志向・引用に基づく検証可能性を共有しています（legalquants.com、コミュニティ公式）。

共通して効くのは、結局この教科書の原則

四つを並べると、流行り廃りの向こうに、変わらない芯が見えます。オープンソースで中身が見える。自分の鍵で自前運用するから、データを手元に保てる。答えには引用を添える。最後は人が確認する。 これらはどれも、この教科書が一貫して言ってきたことです。道具の名前は来年には変わっているかもしれません。けれど、ほどき、考え方を渡し、小さく確かめ、巨人の肩に乗る――この原則を持っていれば、どんな新しい道具が来ても、迷わず乗りこなせます。

あなたの番（今・次・得られるもの）

この章に関しては、ほとんどの人は「知っておくだけ」で十分です。そのうえで、もし気になったら――

• 仕組みにしたい：気になった道具の出典を1つ読む。手を動かしたければ、公開データで Mike OSS のデモに触れてみる（自分のAPIキーで、機密は入れずに）。
• つくる人：lq-skills などの SKILL.md の書き方を眺め、この教科書で作ったプレイブックやスキルがそのまま持ち込めることを確かめる。Harvey LAB で、検討中のツールを“測って”みる。

つまずいたら - どれを使えばいい？ ―― いまは選ばなくて構いません。多くの人は第4章の階段（1〜2段）で間に合います。ここは「こういう世界がある」と知っておくための章です。 - オープンソースは難しそう／こわい ―― 使うだけなら、特別な知識は要りません。むしろ自己ホストできる分、データを手元に置けて安全な面もあります。不安なら、まず出典を読むところから。

その先を覗いてみる ―― つくるとこんな感じ（読むだけでOK）

実は、これらの最先端の道具の多くも、この教科書の付属キットと同じ作法でできています。たとえば Claude for Legal も LegalQuants も、中身は SKILL.md。この教科書の templates/skills/contract-review/SKILL.md で書いた「役割・手順・禁止事項（人の確認）」は、そのままの考え方で、これらの世界にも持ち込めます。

# この教科書で書いたスキル          → そのまま通用する先
templates/skills/             → Claude Code / Claude for Legal
（SKILL.md：役割・手順・禁止事項）  LegalQuants（lq-skills も同じ SKILL.md 形式）

つまり、第1〜4章でやってきたこと（ほどく・渡す・小さく確かめる・肩に乗る）は、最前線への“入場券”でもあるのです。作らなくても、「自分のやってきたことは、ちゃんと最先端につながっているんだ」と分かれば十分です。

まとめ（納得）

応用編で見たかったのは、特定の製品ではありません。流行を追うことではなく、原則を持っていることが、いちばん強い。道具は移り変わります。けれど、原則は残ります。だからあなたは、安心して自分のペースで進めばいい。最先端は、いつでもそこにあります。

次は最終章。自分のペースで続けること、そして法務の役割がどう変わっていくかを、見届けます。

この章の一歩：気になった道具の出典を、1つだけ読んでみる。 得られるもの：法務AIの最前線の地図と、「原則は最先端でも生きている」という安心。

終章　自分のペースで続ける

4つの原則を、もう一度

ここまでの道のりを、一息で振り返ります。

1. 仕事をほどく（横＝工程、縦＝入力→処理→出力）。どこを任せ、何を渡すかが見える。
2. 考え方を渡す（プロンプト＝思考の設計図、その結晶がプレイブック）。自社の判断に沿った答えが返る。
3. 小さく始めて、人が確かめる（Human-in-the-Loop）。こわくないし、続く。プレイブックも育てるもの。
4. 巨人の肩に乗る（汎用ツール優先、自作は最後）。作ることより、仕事をよくすることに集中する。

通底するのは、たった一つ――自分の仕事を、人に説明できる言葉にする（業務の言語化）。AIを使うとは、結局これに尽きます。言葉にできた分だけ、AIは助けてくれます。

到達点 ―― 「NG」から「この条件なら合意できます」へ

この4つを続けた先に、法務の役割が変わっていきます。

これまでは、条項にリスクがあると「リスクが高いのでNG」と返しがちでした。けれど、事業部が本当に欲しいのは「どうすれば受け入れられるか」です。自分の判断を言葉にし（プレイブック）、過去の実績を参照できるようになると、こう言えます――「過去にこの条件で合意した実績があるので、この条件なら合意できます」。根拠を添えて、事業を前に進められるのです（Business & Law 2026/5、スポンサード記事・記述は同社発表）。

単にリスクを指摘するだけなら、AIにもできます。法務にしかできないのは、リスクを分かったうえで、自社の文脈に合った落とし所を示すこと。AIは、その役割への移行を後押ししてくれます。

役割が変わるとは、どういうことか

具体的に、それを体現している会社があります。

日本ペイントホールディングスの法務は、業務をコア（人にしかできない付加価値）とノンコア（AIで支援できる）に分け、ノンコアをAIに任せました。そうして生まれた“余白”を、法務部員は経営課題への戦略的な支援という、よりコアな仕事に振り向けています（Business & Law 2026/1、登壇レポート）。NTTデータの法務も、AI時代に向けて「法務の提供価値を再設計する」という“攻めの法務”を掲げています（BUSINESS LAWYERS 2026/4、媒体）。

AIに仕事を奪われるのではありません。面倒をAIに渡し、人は人にしかできない仕事へ移っていく。それが、役割が変わるということです。

急がなくていい。主役は、人

キリンHDが言うように、デジタルはあくまで手段であり、主役は人です（日本の人事部、媒体インタビュー）。

自分に合った使い方を、自分のペースで続けること。今いる場所から、次の一歩だけで十分です。1条項のプレイブック、1つの小さな工程、1度のプロンプトの工夫。その積み重ねが、半年後の景色を変えていきます。

生きた教科書として、育て続ける

この教科書は、GitHubで更新され続ける「生きた教科書」です。新しい道具や事例が出てくれば、最新版をいつでも出せます。手を動かして作りたい人は付属のキットへ。作らない人は、「作るとこんな感じか」と分かれば、それで十分です。作ることは目的ではなく、道具の一つにすぎません。

あなたの番（最後の一歩）

4つの原則のうち、いまの自分にいちばん効きそうな1つを選んでください。そして、それを今週、ひとつだけ試してみましょう。

• はじめてなら、原則①。面倒な業務を1つ、工程に分けてみる。
• つかっているなら、原則②。頻出論点の判断手順を3行で書いて渡す。
• 仕組みにしたいなら、原則③。1〜2条項からプレイブックを書き始め、人が確かめながら育てる。

どれを選んでも、正解です。大事なのは、始めること。そして、自分のペースで続けることです。

この章の一歩：4つの原則から、いまの自分に一番効く1つを選び、今週ためす。 得られるもの：自分のペースで続く、最初のリズム。

コラム：賢くなり続けるAIを、どう捉えるか

気になる人向けの寄り道です。読み飛ばしても本筋は通ります。

生成AIは、機能も賢さも日単位で変わります。新しいモデル、新しい機能、新しい用語——全部を追いかけると、それだけで息切れします。でも、その必要はありません。

変わらないものがあるからです。ほどく・渡す・小さく確かめる・巨人の肩に乗るという4つの原則と、「主役は人」という立場。新しい機能が出てきたら、ただ一つ問えばいい——「これは、4原則のどれを、より楽にしてくれるのか」。そう捉えれば、流行に振り回されず、自分の物差しで取り入れられます。

実際、AIが賢くなるほど、こちらが細かく指示する必要は減っていきます。Anthropicも、モデルが賢くなるほど規範的な作り込みは少なくて済むようになる、と述べています（前章のコラム「コンテキストマネジメント」の出典）。つまり私たちは、技術の細部ではなく「何をしたいのか」——この教科書がずっと言ってきた業務の言語化——に、ますます集中できるようになる。賢くなるAIは、人の出番を奪うのではなく、人を本来の仕事に近づけてくれます。だから、技術の速さに身構える必要はありません。

コラム：法務の新しい職種とキャリア

気になる人向けの寄り道です。読み飛ばしても本筋は通ります。

役割が変わると、職種も増えます。AIで生まれた“余白”は、法務という仕事の幅を広げました。いくつか紹介します。

• リーガルオペレーションズ（法務オペレーション） ―― 業務プロセスとテクノロジーで、法務サービスの提供を最適化する役割。米国の非営利団体CLOCが体系化し、日本では「CORE8」として、法務組織の改善に必要な要素が整理されています。
• リーガルエンジニア ―― 法務の知識とIT・プロダクトを橋渡しする人。この教科書でいえば、プレイブックやスキル（SKILL.md）を実際に組み、運用に乗せる役回りです。
• リーガルクオンツ ―― コードを書き、設計・検証・実装まで担う法務（第5章のLegalQuants）。
• AIガバナンス担当 ―― 第3章コラムの「守り」を回し、攻めと両輪で設計する役割。
• 法務ナレッジマネージャー ―― 案件知見・タグ・プレイブックを整え、育てる役割（第2章コラム）。

大事なのは、これが「弁護士 対 AI」の話ではないこと。日本マイクロソフトの中島弁護士が言うように、脅威はAIそのものではなく「生成AIを当たり前に使いこなす世代」です（第4章 例4）。逆に言えば、今のあなたの強みに“AIを当たり前に使う感覚”を一つ足すだけで、その世代の側に立てます。全員がコードを書く必要はありません（原則④）。どの道に進むにせよ、出発点は同じ――業務の言語化です。プレイブックを1条項書ける人は、もう新しいキャリアの一歩目に立っています。

最後まで読んでいただき、ありがとうございました。あなたの次の一歩が、少しでも軽くなれば幸いです。

付録

この教科書の本文を補う、実務でそのまま使える資料を5つ用意しました。必要なところだけ拾い読みして構いません。

付録A　レベル別ロードマップ ―― 今日／今週／今月、何をする

序章で示した3つのレベルごとに、「最初の一歩」を時間軸で並べました。まずは、自分の行の「今日」だけ見れば十分です。上に進みたくなったら、そのとき次の列に進んでください。

進み方のコツ　一度に全部やらないこと。どれか1つを今週ためし、続いたら次へ。続けることが、いちばん大事です。

付録B　安全に使うために ―― 学習設定・会社契約・シャドーAI

序章の「たった一つの約束」を、ここで具体的にします。やることは一つです。機密情報や顧客データを、学習に使われ得る個人向けプランに入れない。これだけ守れば、安心して練習できます。

まず、3つの主要ツールで「学習オフ」を確認する

個人向けプランは、入力がモデルの学習に使われることがあります。練習を始める前に、下の設定を確認しておきましょう（2026年6月時点。画面構成は変わることがあるので、最新は各社の公式ヘルプでご確認ください）。

いずれも、設定をオフにしても「機密情報は入れない」が基本です。設定は最後の砦であって、最初の砦は「何を入れないか」を自分で決めておくことです。

会社で使うなら ―― DPA／BAA のあるプランを選ぶ

業務データを扱うなら、個人プランではなく、会社が契約したエンタープライズ／商用プランを使います。商用プランでは、入力がモデル学習に使われないことが契約で担保されるのが一般的です。確認すべき契約は2つ。

• DPA（データ処理契約） ―― 入力データをどう扱い、学習に使わないことをどう保証するかを定めた契約。法人契約に付随します。
• BAA（ビジネスアソシエイト契約） ―― 医療情報など、より厳しい保護が要る情報を扱う場合に必要になる契約。該当する業務では必須です。

主要ツールとも、商用利用（例：会社向けプラン、API、クラウド経由の利用）は個人向けの学習設定とは別扱いで、入力が学習に使われない設計になっています。

シャドーAI ―― いちばん身近なリスク

シャドーAIとは、会社が把握していないAIに、社員が業務データをこっそり入れてしまう状態のことです。悪気がなくても、個人アカウントの無料AIに契約書や顧客リストを貼れば、学習設定しだいで情報が外に出るおそれがあります。第5章で触れた「自己ホストできるツール（Mike OSSなど）」が注目されるのも、この不安を根から断てるからです。

対策はシンプルです。

1. 会社が承認したツール・アカウントを使う（個人アカウントで業務データを扱わない）。
2. 練習は公開データで（次項）。
3. 利用ルールを決めて共有する（何を入れてよく、何を入れてはいけないか）。

「公開データ」で練習する

最初の練習は、公開されている情報だけで十分です。たとえば――法令・各省庁のガイドライン・公開されている契約ひな型・自分で作ったサンプルデータ。これらは外に出ても困らないので、学習設定を気にせず、安心していろいろ試せます。本文の「あなたの番」も、まずは公開データやサンプルで練習し、業務データは会社アカウントで、の順を守ってください。

この付録のまとめ　①個人プランは学習オフを確認 ②業務データは会社のDPA／BAAつきプランで ③公開データで練習 ④機密は入れない。迷ったら、入れないほうを選ぶ。それで大丈夫です。

付録C　すぐ使えるテンプレート集

本文に出てきた「型」を、コピーして使える形にまとめました。コードは要りません。空欄［　］を自分の言葉で埋めるだけです。手元の公開データで、まず1つ試してみてください。

C-1　プロンプトの土台（役割＋手順＋出力の形）― 第2章

あなたは［当社の法務担当］です。次の順で確認してください。
1. ［見るべき点①：例 秘密情報の定義が広すぎないか］
2. ［見るべき点②：例 有効期間］
3. ［見るべき点③：例 目的外使用の禁止］

各点を「OK／要注意／NG」で判定し、理由を一言添えてください。
根拠が確認できないものは、断定せず「要確認」と書いてください。
出力は次の形式で：　論点｜判定｜理由

【対象】
［ここに契約条項や文書を貼る／会社アカウントなら参照先を指定］

C-2　良い例を見せる（Few-shot）― 第2章

以下は、当社の良い判断の例です（固有名・金額は伏せています）。同じ考え方で判定してください。

例1）秘密情報が無限定だった条項 → 「書面で指定したものに限る」と修正（理由：範囲の特定）
例2）［自分の良い判断を1つ］
例3）［自分の良い判断を1つ］

【今回の対象】
［条項を貼る］

C-3　プレイブック（1条項版）― 第2章・第3章

最初から全条項を作らないこと。よく揉める1〜2条項だけ、手で書いて育てます。

## 条項：［損害賠償など］
- 基準：［原則どう考えるか。例 賠償範囲は通常損害に限定］
- 🟢 OK：［線引き。例 通常損害に限定＋上限あり］
- 🟡 要注意：［例 上限水準が想定超／間接損害を一部含む］
- 🔴 NG：［例 無制限、または逸失利益を無条件に含む］
- 過去実績：［いつ・どんな相手と・どう合意したか。理由も。例 C-0003］

## 改訂ログ
- ［日付］：［何を追記・変更したか］

C-4　人が確かめるためのチェックリスト ― 第3章

AIの出力を確定する前に、毎回これだけ見ます。

□ 判定（OK／要注意／NG）に「根拠」が付いているか
□ 根拠は事実か（基準とのズレ／過去実績が具体的か。捏造でないか）
□ 確認できない事項は「要確認」になっているか
□ 最終的な合意可否を、AIが勝手に断定していないか
□ 機密情報を会話の外へ持ち出していないか

C-5　契約データの整え方（入力を「項目」にする）― 第1章

貼り付けるだけで、AIの答えが推測から事実に変わります。

契約ID,相手方,種別,金額,終了日,自動更新,解約通知,親契約
C-0001,サンプル商事,基本契約,,2026-03-31,有(1年),3か月前,
C-0002,サンプル商事,個別契約,5000000,2024-08-31,無,,C-0001
C-0003,サンプルテック,NDA,,2025-11-07,有,1か月前,

より本格的な項目版（実務22項目）やスキルの実物は、付属のGitHubキットに収録予定です。まずは上の最小版で十分です。

付録D　用語集

本文に出てきた言葉を、1行で説明します。出てきて気になったときに引いてください。

• 生成AI ―― 文章などを作り出すAI。ChatGPT・Gemini・Claudeなど。
• プロンプト ―― AIへの指示文。この教科書では「思考の設計図」と捉えます（第2章）。
• 業務の言語化 ―― 自分の仕事を、人に説明できる言葉にすること。この教科書の背骨です。
• 入力→処理→出力（IPO） ―― 1つの作業を「材料・やること・成果物」に分ける見方（第1章）。
• 工程（プロセス） ―― 作業の手順の連なり。ある工程の出力が次の入力になります（第1章）。
• ゼロショット ―― 例を見せずに「いい感じにやって」と頼むこと。たいてい一般論しか返りません。
• Few-shot（フューショット） ―― 良い例をいくつか見せて、判断のクセを学ばせる頼み方（第2章）。
• プレイブック ―― 条項ごとに自社の判断基準と過去実績を文章にしたもの（第2章）。
• ハルシネーション ―― AIがもっともらしい嘘をつくこと。だから人が確認します（第3章）。
• Human-in-the-Loop（人が輪の中に） ―― AIに任せつつ、最後は人が確かめる設計（第3章）。
• 接地（グラウンディング） ―― 自社の資料を先に検索させてから答えさせ、的外れを抑える工夫（第4章）。
• MCP（Model Context Protocol） ―― AIと社内システムをつなぐ共通規格（第4章・第5章）。
• スキル／SKILL.md ―― AIに役割・手順・禁止事項を渡すための、人が読める設定ファイル（第2章・第5章）。
• GPTs／Gem ―― ChatGPT／Geminiで作る「自分用の型」。毎回の前置きを省けます（第4章）。
• NotebookLM ―― 渡した資料に基づき、根拠つきで答えさせられるGoogleのツール（第4章）。
• Microsoft Copilot ／ Microsoft 365 Copilot ―― Word・Outlook・Teamsなどに組み込まれたMicrosoftのAIアシスタント。社内資料に接地して答えられる（第4章）。
• Copilotエージェント ―― 指示・知識・スキルを束ねた、業務特化版のCopilot。Microsoftは一問一答から自走型まで幅広く「エージェント」と呼ぶ（第4章コラム）。
• Copilot Studio ／ Agent Builder ―― Copilotエージェントを作る基盤（ローコード）と、Copilot内で手早く作る機能（第4章コラム）。
• Claude Cowork ―― 一連の作業をまとめて任せられる業務エージェント（第4章）。
• Claude Code ／ Codex ―― 社内システムへの接続など、作る人向けのコーディング・エージェント（Claude Code＝Anthropic、Codex＝OpenAI。第4章）。
• Claude for Legal ―― 既存の法務プラットフォームをMCPで束ねる、法務向けの提供（第5章）。
• オープンソース ―― 中身が公開され、誰でも使い・直せるソフトウェア（第5章）。
• 自己ホスト ―― ツールを自分の環境で動かすこと。データを手元に保てます（第5章）。
• API／APIキー ―― プログラムからAIを呼び出す入口と、その鍵。商用利用は学習対象外が一般的。
• DPA（データ処理契約） ―― 入力データを学習に使わない等を定める法人契約（付録B）。
• BAA ―― 医療情報など、より厳しい保護が要る情報を扱う際の契約（付録B）。
• シャドーAI ―― 会社が把握しないAIに業務データを入れてしまう問題（第4章・付録B）。
• AIガバナンス ―― 組織としてAIを安全・責任をもって使うための方針・体制・運用・点検の仕組み。攻めと守りの両輪（第3章コラム）。
• AI事業者ガイドライン ―― 総務省・経済産業省による日本のAIガバナンスの統一指針（本編＝why/what、別添＝how。第3章コラム）。
• NIST AI RMF／EU AI Act ―― 米国のAIリスク管理枠組みと、EUのAI規制法。日本のガイドラインとも整合が図られている（第3章コラム）。
• リーガルオペレーションズ ―― 業務プロセスとテクノロジーで法務サービスの提供を最適化する役割・考え方（CLOC／日本版CORE8。終章コラム）。
• リーガルエンジニア／リーガルクオンツ ―― 法務とIT・プロダクトを橋渡しする役割／コードを書き設計・検証・実装まで担う法務（第5章・終章コラム）。
• オプトアウト ―― 学習などへの利用を、設定で拒否すること（付録B）。
• コア／ノンコア ―― 人にしかできない付加価値（コア）と、AIで支援できる仕事（ノンコア）（第4章・終章）。
• 属人化 ―― 判断のコツが特定の人の頭の中だけにある状態。言語化で解けます。
• ポータビリティ ―― 特定ツールに縛られず、別の製品へ乗り換えやすいこと（第4章）。
• ベンチマーク ―― AIの実力を共通の物差しで測る仕組み。Harvey LABなど（第5章）。

付録E　AIガバナンスの最小セット

第3章コラム「AIガバナンス」の実践版です。大がかりな体制づくりの前に、今日から置ける2点セットを用意しました――(1) AI利用ルール（1枚）と、(2) 簡易チェックリスト。後者は、総務省・経済産業省「AI事業者ガイドライン」別添7（全主体向けのチェックリスト・ワークシート）の考え方に沿って、最初の一歩用にやさしくまとめた簡易版です。本格的に整える段階では、必ず公式の別添7をご確認ください（AI事業者ガイドライン）。

ガバナンスも原則③と同じで、完璧を目指さず小さく始めて育てるものです。まずはこの1枚と1リストから。

E-1　AI利用ルール（1枚）雛形

そのまま社内に展開できる最小のルールです。［　］を自社の言葉で埋めてください。

【AI利用ルール（v0.1）】　　　　　　　　　　　所管：［法務／□□部］　最終更新：［日付］

1. 目的
   業務でのAI活用を、安全に・責任をもって進めるための最小ルール。

2. 対象
   対象者：［全社員／□□部］　対象ツール：［会社が承認したAI（一覧は別紙）］

3. 使ってよいこと（例）
   - 公開データ（法令・ガイドライン・公開ひな型・サンプル）での下書き・要約・調べもの
   - 会社承認ツールでの、社内資料に基づく作業

4. 使ってはいけないこと（例）
   - 機密情報・顧客データ・個人データを、学習に使われ得る個人向けプランに入れる
   - 会社が承認していないAI（シャドーAI）に業務データを入れる
   - AIの出力を、人の確認なしに最終成果物として使う

5. データの扱い
   - 業務データは、会社契約（DPA／必要に応じBAA）のあるプランでのみ扱う
   - 個人向けプランは学習オフを確認し、機密は入れない（付録B）

6. 人の最終確認（必須）
   - 事実整理・下書き・一次評価はAI、最終判断・交渉・責任は人
   - 出力は付録Cのチェックリストで確認してから使う

7. 記録
   - 重要な業務での利用は、誰が・何に使ったかを［□□に記録／ログを保存］

8. 相談・インシデント窓口
   - 迷ったら使う前に相談：［窓口／担当］
   - 問題が起きたら速やかに報告：［窓口／担当］

9. 役割
   - 統括責任者：［　］　AIガバナンス担当：［　］

10. 見直し
   - ［半期／四半期］に一度、実態に合わせて見直す

E-2　簡易チェックリスト（別添7の考え方に沿った簡易版）

AI活用を始める前・広げる前に、自分たちの状況をざっと確認するためのものです。「いいえ」が残る項目から手を付ければ十分です。網羅版ではないので、本格運用では公式の別添7へ。

① 人間中心／人の最終確認

□ 最終判断・責任は人にあると、ルールで決めているか
□ AIの出力を人が確認する工程が、必ず入っているか

② 安全性・信頼性

□ 重要な用途では、出力に根拠・出典を添えさせ、検証しているか
□ 誤り（ハルシネーション）が起こり得る前提で運用しているか

③ 公平性（バイアス）

□ 人に関する判断（採用・評価等）にAIを使う場合、偏りに注意し、人が確認しているか

④ プライバシー保護

□ 個人データ・機密を、学習され得るプランに入れない運用になっているか
□ 必要なデータ保護の契約（DPA等）を確認しているか

⑤ セキュリティ（シャドーAI・アクセス）

□ 使ってよいツール・アカウントを定め、周知しているか
□ 社内データへのアクセス範囲・権限を管理しているか（エージェント含む）
□ 重要な利用のログを残しているか

⑥ 透明性

□ 成果物にAIを使った場合、必要な範囲で分かるようにしているか
□ 参照元・出典をたどれるようにしているか

⑦ アカウンタビリティ（説明責任）

□ 責任者・ガバナンス担当を決めているか
□ ルールを定期的に見直す仕組みがあるか

⑧ 教育・リテラシー

□ 利用者にルールと基本的な注意（付録B）を周知しているか
□ 良い使い方・事例を共有する場があるか

「攻め」と「守り」は両輪です（第3章コラム）。このチェックは“守り”の最小確認。攻め（活用推進・人材育成・事例共有）も、同じく小さく始めて育てていきましょう。