🧭 本記事は Claude Code実務運用シリーズ の STEP 5「レビュー自動化する」です。
前回の企画検証AIチームに、判断させず確認事項だけを出させる法務観点を足します。
シリーズ全体の地図と読む順は 親記事 にまとめています。
はじめに
企画書を投げると6人の専門家AIが意見書を返す「企画検証AIチーム」（前回の記事で作ったものです）に、法務の観点を足したくなりました。企画には景品表示法や特定商取引法が絡みます。ところが既存の6観点 ― 要件定義・仕様整合性・実装可能性・規模見積もり・UX・リスク ― には、法務の専任が誰もいません。
観点を1つ足すのは、プロンプトを1つ書き足すだけの作業だと思っていました。
ところが手をつけると、すぐに壁に当たりました。仕様書もコードもチケットもあるのに、法務だけ空白なのです。
前回の記事 Claude Codeで「企画検証AIチーム」を作る ― ビジネス企画に専門家AIが意見書を返す で、この種のAIチームの品質を決めているのはプロンプトの工夫ではなく接地（グラウンディング） だと書きました。参照できるコードと仕様書とチケットの議論があるから、AIは「一般論のコンサル」ではなく「このプロダクトならこうなる」という意見を言える、と。
では、法務のように参照先がない観点はどうするのか。 今回はその話です。
結論から言うと、法務観点を1つ足すには 判断させない／代わりの接地資産を自作する／検証役の突合軸を差し替える の3点が要りました。3つ目は、既存メンバー（検討に関わっていない突合役）の仕事を変えるという意味です。この3点と、そのまま使えるテンプレを書きます。
「企画検証AIチーム」に法務観点を足すときの設計です。社内に参照できる資料がない領域で、AIに何をさせて何をさせないか ― 役割の決め方・トリガーチェックリストの作り方・検証役の組み替え方を、コピペできるテンプレつきで書きます。
伏せていること: 対象サービス名・検知された指摘の内容・評価に使った文書は書きません。この仕組みが出すのは「法務部門に確認すべき項目」であり、「違反の指摘」ではありません。
検知件数・検証の内訳・所要時間の絶対値も扱いません。中身を伏せた状態の数字は、読者が検証も再現もできないためです。一方で、チェックリストの分類数のように、構成の議論そのものに必要な数だけは書きます。
この記事で分かること
- AIに法務を判断させず「確認すべき項目」だけを出させる観点の作り方
- 参照できる社内資料がない領域で、代替の接地資産（トリガーチェックリスト）をどう用意するか
- 観点を1つ増やすと、チーム全体の役割境界と検証役をどう組み替える必要があるか
- コピペで使えるテンプレ3点（観点定義の任務制約 / トリガーチェックリストの骨格 / 検証役の突合ルール）
- 組み替え前後で出力の何が変わったか（想定と違った1件を含む）
- この設計が法務以外のどの領域に効きそうか
前提
- 前回の記事で作った「企画検証AIチーム」（Claude Code のスキル）の続編です。前編未読でも読めますが、スキル本体のテンプレは前編にあります
- Claude Code の Skills と Subagents を使います（2026年8月時点）
- この仕組みは法務判断をしません。 出力は「法務部門への確認項目リスト」であり、社内の法務レビューを代替するものではありません
- 観測はいずれも1回の比較です。再現性は確認していません
- この構成でも拾えなかった論点はありますが、内容を伏せる方針のため本記事では立ち入りません
なぜ「AIに法務を判断させる」ではダメなのか
法務観点の専門家AIを素直に追加すると、2つの問題が起きます。どちらも「その観点だけ接地資産がない」ことから来ています。
問題1: 出力が一般論に戻る
リポジトリには仕様書もコードもチケットもあります。でも法務の一次情報はありません。社内規程も、取引先との契約も、過去の法務判断の記録も、リポジトリの中にはない。
すると法務専門家AIの出力は、必然的に「一般論 + モデルの記憶」になります。これは前回の記事が冒頭で否定した、まさにそれです。
一般論のAI:
「景品表示法上の問題が生じる可能性があります」
接地したAI:
「◯◯機能の既存仕様と競合します（docs/◯◯.md）」
法務観点では、後者が原理的に書けません。参照する docs/ が存在しないからです。
しかも悪いことに、AIは法律についてそれらしく喋れてしまいます。条番号も判例も出てきます。それが正しいかどうかを、リポジトリの中で確かめる方法がない。
ビジネス担当がそれを読んで信じたら、と考えると笑えません。
問題2: チームの検証役が空回りする
前回の記事で書いたとおり、このチームの品質を支えているのは検討に関わっていない検証役です。統合された意見を受け取り、仕様書と突き合わせて、根拠のない意見を削除する。
ところが法務の指摘は、突合先がありません。検証役の挙動は2つに割れます。
- 「根拠が確認できない」として全部削除する
- 法務だけ例外扱いして無検証で素通りさせる
どちらもダメです。前者なら法務観点を足した意味がなく、後者なら品質保証の穴になります。
観点を1つ足すというのは、既存メンバーの仕事を変えることでもある ― これが設計上の見落としでした。
既存の観点では、こう流れます。
法務観点をそのまま足すと、最後の突合が成立しません。
法務観点をどう設計したか
3点セットです。順番に効きます。新しい観点を1つ書き足すだけでは足りず、既存の役割境界と検証役まで手を入れる必要がありました。最後に、成果物自身に限界を書かせる仕上げを1つ足します。
太枠が変更点です。観点を1つ増やしただけでなく、検証役の仕事が変わっているのが要点になります。
原則1: 「判断」ではなく「検知」に役割を落とす
法務専門家AI（既存の6観点 A〜F に続く7人目なので、以下 Expert G と呼びます）の任務を、適法・違法の判断ではなく 「法務部門に確認すべき項目の列挙」に限定します。観点定義の冒頭で明示的に禁じます。
### Expert G: 法務・コンプライアンス(トリガー検知)
任務は「法務確認が必要な項目」の検知に限定する。適法・違法の判断や法解釈の断定はしない。
全文は後述の「テンプレ（コピペ用）」節に置いてあります。
ポイントは、AIに判断させられない領域では、判断ではなく 「人間の判断への引き渡し」を出力にすることです。成果物は「法務に何を聞けばいいかのリスト」になります。これならビジネス担当にとっても実用的で、かつ誤りのコストが「無駄な確認が1件増える」で済みます。
役割を落とすのは、新しい観点だけの話ではありません。既存の観点に「この領域は新しい観点の担当だから踏み込むな」と書くときは、「判定するな」と「言及するな」を混同しないでください。判定を禁じるつもりで言及まで封じると、専任者のリストから漏れた論点の受け皿がなくなります。書き分けておくほうが安全です。
❌ 法令の話は Expert G の担当なので触れない
⭕ 法令に該当するかの判定は Expert G に任せる。気づいた点は「法務確認が要りそう」と書いてよい
原則2: 接地資産がないなら、最小の接地資産を自分で作る
判断させないと決めても、何を検知すべきかの基準はどこかに要ります。そこでチェックリストを作りました。
分類は、法令の体系からではなく自社の企画から逆引きして決めました。過去の企画書を眺めて、キャンペーン・ポイント・レビュー訴求・解約導線・年齢制限…と「毎回出てくる論点」を並べ、それぞれに対応する法域を当てる。結果として8分類になりました。法令側から網羅しようとすると際限がなく、企画に出てこない分類は死蔵されます。
これが代替の接地資産になります。効いてくるのは、指摘が次の形に固定されることです。
企画書の記述(引用) → 該当トリガー → 法務部門に確認すべきこと
「◯◯した方全員に△△を進呈」 → 1. 景品表示法 / 総付景品 → 上限額の適用範囲
（上は架空の例です）
この形になると、指摘が突合可能になります。引用が企画書に実在するか、トリガーとの対応が正しいか ― どちらも機械的に確かめられる。次の原則3が使えるのは、これがあるからです。
原則3: 検証役の突合軸を差し替える
docs と突合できないなら、別のものと突合させる。
検証プロセスを例外にしないことが肝です。「法務だけは検証を免除」にすると、そこが品質保証の穴になります。軸を置き換えるだけで、既存の枠組みはそのまま使えます。
(c) を「削除」ではなく「書き換え」にしているのが要点です。断定を消すと指摘そのものが消えますが、書き換えなら確認事項として残ります。
書き換え前: 「この表記は現行法に抵触している」
書き換え後: 「この表記が現行法上問題ないか、法務部門に確認する」
仕上げ: 成果物自身に限界を書かせる
原則2で置いたチェックリストには、構造的な性質があります。リストに載せた領域には網羅の担保がつきますが、載せなかった領域は視野に入りにくくなります。 「リストにない事項も『(推測です)』を付けて挙げてよい」という逃げ道を観点定義に書いてはありますが、今回のランでは、それが働いてリスト外の論点が挙がってくることはありませんでした。逃げ道は書いておくべきですが、当てにはできません。
そこで今回のランでは、生成された意見書の付録にこう書かせました。
チェックリストは網羅を担保すると同時に、チェックリストの外側を見えなくする。
引用したのはこの一文だけですが、実際の意見書ではこの直後に、成果物自身の名前を挙げて「この構成でも拾えていない2件の論点を、この意見書も含んでいない」と、件数つきで続けさせています（前提に書いた「拾えなかった論点」のことです）。
自分の成果物の限界を、成果物自身に書かせる。受け取ったビジネス担当が「並んでいるものが全部だ」と誤解するのを防ぐには、これが一番確実でした。
なお、これを毎回自動で入れるスキル側の改修はまだしていません。入れるなら、意見書のテンプレ側にこの1行を足すことになります。
## 法務確認が必要な項目
(末尾に必ず添える) チェックリストは網羅を担保すると同時に、その外側を見えなくする。
本節も、リストに載せていない領域を含んでいない点に留意されたい。
足したあと、チームはどう変わったか
同じ入力を、組み替え前と組み替え後の構成の両方に通しました。ここでは、構成の変化がそのまま出力に出た4つの振る舞いを並べます。うち1つは、想定と違う方向でした。
件数ではなく振る舞いで並べるのは、振る舞いなら、同じ構成を組んだ読者が自分の環境で起きたかどうかを判定できるからです。
条番号を言わなくなった
組み替え前の意見書は、付録にこう書いていました。
法令解釈（すべて法務確認が必要。条番号は記憶に基づくもので要確認）
意見書自身が「記憶に基づく」と自己申告していたわけです。誠実ではありますが、これは接地資産のない領域でモデル記憶に依存した痕跡そのものです。
組み替え後の出力では、条番号・告示の正式名称・判例の引用が1件も出ませんでした。法域の名前は使いますが、条文の内容・要件・効果には踏み込まない。原則1の任務制約が狙いどおりに効いた形です。
「無いこと」を確かめにいった
いちばん面白かったのは不在の確認でした。
法務観点AIは、ある領域のキーワードで仕様書を全文検索し、該当ゼロを確認したうえで、「その領域の仕様が見当たらないので、取り扱いの有無を事業側に確認したい」という確認事項に変換していました。こういう動きが1件観測できました。
チェックリストが「探すべき対象」を与えるから、無いことを確かめにいくという動きが生まれます。創発的な指摘ではこれは起きにくい。無いものには気づけないからです。
ただしこの発見には続きがあります。検証役が「その語彙では該当ゼロだが、近接する機能が別名で実装されている」と指摘しました。つまり「機能が存在しない」ではなく「その語では引っかからない」が正確でした。検索が語彙に縛られる以上、不在の確認も語彙の範囲でしか成立しません。
突合軸を差し替えたら、存在しない引用元が出てきた
差し替えた突合軸は空振りしませんでした。(a) 引用の実在の突合で複数件の修正が入り、うち一部は引用元がリポジトリに実在しないものでした。(b) トリガー対応でも、分類の当てはめが弱い項目に修正が入っています。
一方 (c) 適法・違法の断定は、法務セクションには残っていませんでした。ただし検証役は、法務セクション以外の箇所で、あるラベルの表現が「現行法に抵触している」と読まれる余地があると指摘しています。設計どおり、削除ではなく書き換えで処理されました。
つまり原則3は「何も出なかったから安全」ではなく、出るべきものが出たので機能したと判断しています。
想定外: 組み替え前も、法務にはあちこちで触れていた
これは予想していませんでした。
組み替え前の意見書を読み直すと、法務の論点はすでに複数のセクションに散らばって出ていました。「法務観点がゼロだった」という単純な話ではなかったのです。
さらに、こうも書いていました。
資料の 5 パターンと自社画面のマトリクスを作ります。「違反である」という結論は出さず、「該当し得る／しない／判断保留」で止めます（そこは法務の領分です）。
「判断は法務の領分」という境界の認識は、専任の観点を足す前から既にあったわけです。
つまり原則1が新しく持ち込んだのは、認識ではありません。その認識を毎回再現される手順にすることを狙ったものです。散らばっていた論点が1つのセクションに集まり、出典つきの決まった形式になり、法務担当がそのまま作業リストとして使える状態になった。原則1が効いたのは新しい知識の追加ではなく、形式を固定したことのほうでした。 新しい論点そのものは、原則2で置いたチェックリストが連れてきています。
テンプレ（コピペ用）
テンプレも今の形が最終形ではありません。そのうえで、そのまま持ち帰れる形で3点置いておきます。<> の部分は自分のプロダクトに合わせて調整してください。
1. 観点定義（任務制約と禁止事項）
スキル側の観点定義に置く部分:
### Expert G: 法務・コンプライアンス(トリガー検知)
**任務は「法務確認が必要な項目」の検知に限定する。適法・違法の判断や法解釈の断定はしない。**
- `<チェックリストのパス>`（例: `legal-triggers.md`）を自ら Read し、企画書の記述とトリガーを突合する
- 各指摘は「企画書の該当記述(引用)→ トリガー名 → 法務部門に確認すべきこと」の形式で
「意見・懸念」に書く
- チェックリストにない事項で法務確認が必要と考えるものは「(推測です)」を付けて挙げてよい
- 技術・審査・運用リスクの評価は Expert F(＝リスク・審査観点)の担当。交差する場合も本観点は「法務確認の要否」だけを書く
実行時のプロンプトに足した禁止事項（記憶に基づく再構成で、逐語ではありません）:
## 禁止事項
- 「これは景品表示法違反である」等の断定を書かない
- 法解釈を展開しない(条文の解釈・判例の当てはめをしない)
- 技術的な実現可能性・審査リスク・運用リスクの評価をしない
2. トリガーチェックリストの骨格
冒頭の免責2行は削らないでください。この2行があるから、成果物が「法的助言」ではなく「確認項目」として扱われます。
# 法務確認トリガーチェックリスト
- **このファイルは法的助言ではない。** 各トリガーは「該当しうるから法務部門に確認する」という
検知条件であり、適法・違法の判断基準ではない
- このファイルをエージェントが変更してはならない(変更提案は提案カードまで。
法改正・新規制への追従は週次の棚卸しで人間が行う)
## トリガー一覧
### 1. 景品表示法 — キャンペーン・特典・訴求表現
該当しやすい企画: プレゼント・抽選キャンペーン、購入特典、クーポン、ポイント還元率アップ、
訴求文言の変更
- 商品・サービスの購入や利用を条件に特典を付ける(総付景品・懸賞の別と上限額の確認)
- 抽選・くじ・ガチャ形式で特典を付与する(懸賞規制。有償ガチャは射幸性の論点も)
- 「最大◯◯%還元」「業界最安」「無料」等の訴求(有利誤認のおそれ)
- 作品・サービスの品質・内容・実績の訴求(優良誤認のおそれ)
- 「期間限定」「今だけ」の反復・常態化、二重価格表示(参考価格の根拠)
### 3. ステルスマーケティング規制(景品表示法の指定告示)
該当しやすい企画: インフルエンサー施策、レビュー・口コミ施策、SNS 投稿キャンペーン
- 事業者が対価(金銭・特典)を提供した投稿・レビューの表示(PR 明示の要否)
- レビュー投稿・SNS シェアに特典を付ける設計(表示の操作と受け取られないか)
### 5. 特定商取引法・消費者契約法 — 購入・解約導線と価格表示
該当しやすい企画: 定期購読・自動更新の導入や変更、解約導線の変更、価格・条件表示の変更
- 定期購入・自動更新の申込み最終確認画面の表示事項(分量・金額・期間・解約方法)
- 解約・退会手続きの導線変更(過度に複雑な導線は解約妨害と評価されるおそれ)
- 小さな注記で本文の条件を打ち消す表示(打消し表示)
- 税込・税抜の価格表示方法の変更(総額表示)
### 残りの分類(見出しのみ。中身は 1・3・5 と同じ形式で埋める)
### 2. 資金決済法 — コイン・ポイント・前払式支払手段
### 4. 著作権・<取引先>との契約
### 6. 未成年者・年齢配慮
### 7. 個人情報・プライバシー(法務・ポリシー確認)
### 8. プラットフォーム規約と国内法の交差
分類は自社の事業で決めてください。 前述のとおり、ここに載せなかった法域は検知されないことがあります。今回のランでも、分類を置いていない法域の論点は拾われませんでした。
3. 検証役の突合ルール
検証役（独立検証）の手順に足す部分:
- 法務観点の指摘は docs・実装とは突合できないため、代わりに
「引用された企画書の記述が実在するか」
「<チェックリストのパス> のトリガーとの対応が正しいか」を突合する。
適法・違法を断定する記述が残っていたら「法務部門への確認事項」の形に書き換える(削除はしない)
今回のランでは、これに加えて検証役へ「条番号など、モデルの記憶に依存した法的知識が混入していないか」も確認させました。上のスキル本体には入れていないので、必要なら足してください。
運用への反映
この構成変更から得た知見を、自己改善ループ（Fable 5が復活したので、Claude CodeのAIエージェントチームを自己改善型にした【プロンプト全公開】 で作った仕組み）の学習データに追加しました。持ち帰るのは中の1行だけで、この仕組みがなくても実行できます。
# プロダクト固有の記述を一般化した抜粋
- id: WF-005
level: L2
when: チェックリスト駆動の専門家(参照リストが固定されている観点)を含めて起動するとき
hint: チェックリストは網羅を担保する一方、リストの外側を不可視化する。
参照リストの分類数を起動前に確認して記録しておくと、後から
「落とした論点の原因がリスト欠落か専門家の見落としか」を切り分けられる。
あわせて、他観点へ「該当判定に踏み込まない」と指示する際も、
論点の**言及**まで封じない書き方にすると取りこぼしの二重化を防げる。
hint の後半は、原則1で書いた「判定するな」と「言及するな」の書き分けを、起動時の規約に落としたものです。前半は、チェックリスト駆動の観点で拾い漏れが出たときに、原因がリスト欠落なのか専門家の見落としなのかを後から切り分けるための記録規約です。分類数を起動前に記録しておけば、あとから意見書を読み直して数え直さなくても切り分けられます。
この設計は、法務以外にも効くはず
法務は一例にすぎません。同じ形をした領域はいくつもあります。
「専門知識はモデルの中にあるが、自社の一次情報がリポジトリにない」領域なら、この3点セットが効くはずだと考えています。ただし実際に試したのは法務の1領域だけで、以下は未検証の一般化です。
| 領域 | 判断させられない理由 | 検知に落とすと |
|---|---|---|
| 法務・コンプライアンス | 社内規程・契約・過去の判断がリポジトリ外 | 法務部門への確認項目リスト |
| セキュリティ | 脅威モデル・受容リスクが組織固有 | セキュリティレビューの依頼項目 |
| アクセシビリティ | 達成基準の適用判断に実機検証が要る | 実機で確認すべき項目 |
| 医療・薬機 | 判断に資格が要る | 薬事担当への確認項目 |
| 会計・税務 | 会計方針が組織固有 | 経理への確認項目 |
判断の粒度を落とすと誤りのコストが下がる、という一点でどれも共通しています。
まとめ
「企画検証AIチーム」に法務観点を足すときの要点は3つ、それに仕上げが1つでした。参照できる社内資料がない領域なら、法務以外でも同じ形が使えるはずです。
- 判断させず、検知させる。 AIに判断させられない領域では、判断ではなく「人間の判断への引き渡し」を出力にする。誤りのコストが「無駄な確認1件」に下がる
- 接地資産がないなら、最小の接地資産を自分で作る。 チェックリストを置くと、指摘が突合可能な形になる
- 検証役を例外にしない。 突合先がないなら、突合の軸を差し替える。「この観点だけ検証しない」は品質保証の穴になる
- 仕上げに、成果物自身へ限界を書かせる。 チェックリストに載せなかった領域は視野に入りにくい。その性質を意見書の付録に書かせておくと、受け取った側の誤読を防げる
前回の記事は「接地資産を整えよう」という話でした。今回はその裏側、「接地できないものをどう扱うか」の話です。接地できないなら、判断させない。 それが今のところの結論です。
最初の一歩としては、自社の事業で確認が必要になる法域を書き出すところから始めるのが早いと思います（私の場合は8分類になりました）。分類さえ決まれば、あとはテンプレの形に流し込むだけです。
そして、チェックリストの限界を成果物自身に書かせておく。読者が「AIが挙げたから網羅されている」と読むのが、いちばん危ないので。
このシリーズの歩き方
Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。
- ◀ 前の記事: Claude Codeで「企画検証AIチーム」を作る ― ビジネス企画に専門家AIが意見書を返す
- ▶ 次の記事: プロンプトを磨くのをやめて、就業規則を書き始めた ── Claude Codeで定型業務を「組織化」する話
- 🔍 あわせて読む: AIが書いた受け入れ基準を『読者ペルソナレビュー』で外部QA品質にする【Claude Code・テンプレ公開】 ― 「成果物自身に限界を書かせる」と同じ問題意識をレビュー成果物側で解いた回
- 🗺 シリーズ全記事の地図(親記事)