「ChatGPTで契約書レビューを効率化したい」──そう考えて情報システム部門に相談したら、苦い顔をされた経験はありませんか？

クラウドAIの性能は日々向上しています。契約書の要約、リスク条項の検出、翻訳──どれも驚くほどの精度です。しかし法務の現場には、利便性よりも先に問われる「沈黙の要件」があります。それは、入力するデータを外部に送信してよいかという問いです。

本記事は、第1回「要件定義10STEP」の続編です。前回定義したSTEP 2（入力データの特性定義）・STEP 3（自動化の範囲と人間の役割）・STEP 9（情報管理とセキュリティ）・STEP 10（証跡・説明責任・再現性）を掘り下げ、なぜ法務では「便利なクラウドAI」より「統制できるオフラインAI」が勝つ場面があるのかを、法令・ガイドラインの根拠とともに解説します。

本記事の構成は3部構成です。第1部で「外部送信NG」の法的な正体を解体し、第2部でオフラインAI設計の3つの思想を示し、第3部で筆者の開発経験をもとに実装の現実解を提示します。

クラウドAIが法務を「詰ませる」3つの法的障壁

法務がクラウドAIに慎重になる理由は、漠然とした不安ではありません。明確な法的・規程的根拠があります。ここでは、外部送信を制約する3つの法的障壁を整理します。

1営業秘密の壁──不正競争防止法と秘密管理性

契約書に含まれる取引条件、価格情報、技術情報等が「営業秘密」に該当する場合、その秘密管理性を維持しなければ、不正競争防止法上の保護を受けられなくなるリスクがあります。

不正競争防止法第2条第6項は、営業秘密を「秘密として管理されている生産方法、販売方法その他の事業活動に有用な技術上又は営業上の情報であって、公然と知られていないもの」と定義しています。すなわち、秘密管理性・有用性・非公知性の3要件すべてを満たす必要があります。

経済産業省は令和7年（2025年）3月31日に「営業秘密管理指針」を6年ぶりに改訂しました。今回の改訂では、テレワークの普及、クラウド技術の進展、生成AIの急速な台頭といった環境変化を踏まえ、秘密管理措置の具体例の追加や考え方の整理が行われています。

ここで重要なのは、クラウドAIサービスに営業秘密を含むデータを送信した場合、秘密管理性の維持が問題になり得るという点です。令和7年改訂では、テレワークやクラウド技術、生成AIの台頭等の環境変化も踏まえて、秘密管理措置の考え方や具体例の整理が見直されています。したがって、秘密情報をどの処理環境に投入するかは、従前以上に設計上の論点になっています。オフライン設計であれば、データが社内ネットワークから一切外に出ないため、この論点自体が発生しません。

2個人情報の壁──委託・第三者提供・越境移転

契約書には署名者の氏名、住所、連絡先等の個人情報が含まれることが一般的です。これらの個人情報を外部AIサービスに送信する場合、個人情報保護法上の整理が必要になります。

個人情報保護委員会は令和5年（2023年）6月2日に「生成AIサービスの利用に関する注意喚起等」を公表し、個人情報取扱事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合には、特定された利用目的の達成に必要な範囲内であることを十分に確認することを求めています。

実務上、外部AIサービス利用時に検討すべき論点は多岐にわたります。

なお、個人情報保護法のいわゆる「3年ごと見直し」に係る検討では、生成AIの学習段階・利用段階における事業者の義務の明確化が議論されています（個人情報保護委員会「個人情報保護法の制度的課題に対する考え方について」令和7年3月5日公表）。今後の法改正動向にも注視が必要です（改正の詳細は「個人情報保護法改正でプライバシーポリシーの何を変える？」を参照）。

3NDA（秘密保持契約）の壁──相手方から預かった情報

見落とされやすいのが、自社の情報ではなく、相手方から秘密保持義務の下で受領した情報です。

多くのNDAには「第三者への開示禁止」条項が含まれます。AIサービス提供者が「第三者」に該当するか否かは契約解釈の問題ですが、AIサービスにデータを送信する行為が「開示」に当たると解釈されるリスクは否定できません。特に、学習利用される可能性がある場合、そのリスクは一層高まります。

ここまでの3つの障壁を整理すると、法務が扱うデータの多くは、何らかの法的・契約的制約の下にあることがわかります。

オフラインAIを選択する3つの設計原則

ここからは、法的障壁を踏まえたうえで、オフラインAIを「仕方なく」ではなく「戦略的に」選択する設計思想を整理します。

なお、総務省・経済産業省が令和7年（2025年）3月28日に公表した「AI事業者ガイドライン（第1.1版）」は、AI開発者・提供者・利用者それぞれが取り組むべき事項を整理するソフトローです。同ガイドラインでは、AIガバナンスの構築として「リスクベースアプローチ」──すなわちリスクの程度に応じた対策の実施──を推奨しています。法務部門が自作ツールを設計する際も、このリスクベースの考え方が基礎になります。

1データ主権の完全保持

オフライン設計の最大の利点は、「データが1bitも社内ネットワークから出ない」と断言できることです。

この一言は、情報セキュリティ審査において極めて強力な説明になります。クラウドAIの場合、利用規約の確認、委託先の監督体制の整備、越境移転の有無の確認、学習利用オプトアウトの設定──これらすべてを精査しなければなりませんが、オフラインツールであればこれらの論点が構造的に発生しません。

営業秘密管理指針（令和7年改訂）の考え方に照らしても、オフライン処理は秘密管理性の維持にとって有力な設計方針です。秘密情報が社外に送信されない設計は、秘密管理性を支える重要な事情になり得ます。ただし、実際にはアクセス制御、秘密表示、利用者範囲の限定、ログ管理等を含む運用全体で秘密管理性が判断される点には注意が必要です。オフラインであることは「必要条件の一つ」であって「十分条件」ではない──この認識のもとに、本記事では設計思想を展開します。

2再現性と検証可能性（Auditability）

クラウドAIサービスには、もうひとつの構造的なリスクがあります。モデルのバージョンアップにより、過去の処理結果が再現できなくなるという問題です。

法務ツールにおいて再現性は「あれば嬉しい」機能ではなく、監査対応の前提です（第1回 STEP 10で解説）。たとえば、半年前にAIが「リスク低」と判定した契約条項について、現在の同じプロンプトで「リスク高」と出力された場合、「当時の判断は適切だったのか」を検証するすべがありません。

「クラウドAIでもモデルのバージョンを固定すればよいのでは？」という反論がありますが、クラウドサービスのバージョン固定には必ず提供終了（Deprecation）があります。多くのAPIでは、特定バージョンのサポート期間は数か月から1〜2年程度です。一方、ローカルに保持したモデルファイルとライブラリは、環境さえ維持すれば10年後でも同じ挙動を再現できます。法務の証跡保全が求められるスパン（契約書の保存期間は7年〜10年以上が一般的）に耐えられるのは、ローカル保持だけです。

オフラインツールでは、ルール（正規表現・辞書）とモデル（ローカルNLP/LLM）のバージョンを設定ファイルで管理し、入力ファイルのハッシュ値とともにログに記録します。これにより、「いつ・どのルールで・何を処理し・どういう結果だったか」を完全に再現可能な状態が保てます。

3自社ルールへの完全適合

法務業務のルールは、法令だけでなく、社内規程・業界慣行・過去の社内判断の蓄積で構成されています。汎用SaaSではカバーしきれない自社固有のロジックを持てることが、自作ツールの最大の強みです。

たとえば「当社では損害賠償の上限条項がない契約は、金額にかかわらず法務部長の承認が必要」「A社グループとの取引は、別途のNDA条件を適用する」──こうした自社固有のルールは、YAML/JSONの設定ファイルに外部化することで、法改正や社内規程の変更にも開発者不在で対応できます（第1回 STEP 8で解説）。

クラウドAI vs オフラインAI：法務視点の比較

私の開発経緯──設計思想の進化として

ここからは、筆者が実際にオフラインの法務ツールを開発してきた経緯を、「単発のツール紹介」ではなく「設計思想の進化」として整理します。

1第1段階：外に出せない文書を扱う必要があった

最初に開発したのは、契約書マスキングツールです。契約書中の個人情報・機密情報を検出し、マスキング（墨消し）を施すツールですが、マスキング対象となるデータそのものが、個人情報や営業秘密を含む文書です。つまり、処理したいデータこそが、外部送信できないデータでした。

クラウドAPI版のプロトタイプも試作しましたが、情報管理の観点から社内利用の承認が得られる見込みがなく、オフライン版に設計を切り替えました。結果として、正規表現（電話番号・口座番号等の定型パターン検出）とローカルNLP（人名・組織名の固有表現抽出）を組み合わせたハイブリッド方式に落ち着いています。

2第2段階：精度より先に、再現性と説明可能性が必要だと気づいた

次に開発したLegal Gateway（契約審査支援ツール）では、契約審査の業務導線全体──ヒアリング→リスクスコア→論点整理→交渉カード→稟議書一枚化──を支援する設計にしました。

開発を進める中で気づいたのは、法務にとって重要なのは「なんとなく当たる」精度ではなく、「なぜそう出たか」の説明可能性だということです。AIが「リスク高」と判定した理由が説明できなければ、事業部への説明も、上長への報告も、監査への対応もできません。自作ツールであれば、処理ロジック・判断根拠・適用ルールのすべてを自社で把握でき、「ブラックボックスではない」と説明できます（AIレビューの品質改善については「Claudeで契約書チェックしたら見落としが95%減った話」も参考になります）。

3第3段階：モデルの賢さより、配布・更新・統制がボトルネックだった

法務ツールの開発で最も時間を費やしたのは、AIモデルの選定ではなく、「現場にどう届け、どう更新し、どう統制するか」でした。

CLIで動くプロトタイプは早期に完成しますが、法務部内の他のメンバーがコマンドラインを使えるとは限りません。そこで、Python + tkinterでGUIを構築し、PyInstallerでexe化して配布する形態に移行しました。ダブルクリックで起動し、「入力→確認→出力」の3ステップで完結するUI設計にしたことで、初回説明15分で運用が開始できる状態になっています。

設定ファイル（YAML/JSON）の外部化により、法改正や社内規程変更への対応も、ファイルの差し替えと承認で完結します。コードの修正は不要です。

「オフラインAIで実際にどう処理を分担するか」

重要なのは、「全部をローカルLLMでやる」のではなく、処理の性質に応じてルール・NLP・LLM・人間を分業させる設計です。

この分業設計は、第1回のSTEP 4（中核ロジックの選定）とSTEP 5（誤検出・見逃し・ハルシネーション対応）をそのまま実装に落としたものです。「AIを使いすぎない」こと──つまり、前段のルールベースで8割を処理し、AIには文脈依存の判断だけを担当させる「賢い手抜き」が、法務ツールのオフライン設計では極めて効果的です。

なお、高性能なクラウドLLMが不要になるわけではありません。タスクの切り分け（オーケストレーション）がポイントです。公開情報に基づく一般論の整理や、契約類型ごとのリスクの傾向分析といった「外部送信OK」な作業はクラウドLLMに任せ、個別契約の条項抽出や自社ルールとの照合といった「外部送信NG」な作業はローカルに閉じる──この使い分けにより、ローカルモデルの性能不足という弱点はかなり限定的なものになります。

4第4段階：結局、法務ツールは「統制されたミニシステム」だった

マスキングツール、Legal Gateway、稟議一枚化ツール、論点アラートツール、引継ぎ支援ツール──これらを開発してきた結論として言えるのは、法務ツール開発は「AI導入」ではなく「統制可能な業務システム設計」だということです。

ログ、設定ファイル、版管理、承認フロー、差分記録──必要な仕組みは、AIモデルの選定よりもむしろ運用設計の側にあります。オフラインAIは、この運用設計と最も相性が良い技術選択だったのです。

オフラインAIの弱点と、それでも採る理由

公平を期して、オフラインAIの弱点も明示します。

これらの弱点を認識したうえで、それでも法務の現場ではオフラインAIが成立する理由は明快です。法務が求めているのは「最も賢いAI」ではなく、「統制可能で、説明可能で、監査に耐えるAI」だからです。

まとめ：法務のAI導入は「精度競争」ではなく「統制可能性の設計」

本記事を通じて伝えたかったのは、以下の3点です。

第一に、外部送信NGという制約が、技術選定より先に来る。 営業秘密管理指針、個人情報保護法、NDA──法務のデータには複数の法的制約が重なっており、クラウドAIの利用が構造的に制限される場面が多い。

第二に、その制約の中で、ルール・NLP・ローカルLLM・人間確認を組み合わせてきた。 「全部をAIにやらせる」のではなく、処理の性質に応じた分業設計が、オフライン環境でも十分な実用性を生む。

第三に、結果として、法務ツール開発はAI導入ではなく、統制可能な業務システム設計になった。 ログ、設定ファイル、版管理、承認フロー──これらの運用設計こそが、法務ツールの品質を決める。

オフラインAIは「守り」の技術ではありません。法務にとっての「城門」──外から攻められず、中から自在に動ける設計基盤です。

次のステップ

本記事の設計思想を実装に落とした具体例として、以下のツールを無料で公開中です。いずれも完全オフライン動作・ログ保存・設定外部化を前提に設計しています。