「法務の業務を自動化したい」と考えたとき、いきなりコードを書き始めたり、ChatGPTにプロンプトを打ち込んだりしていませんか？

法務実務に特化したツール開発において、最も重要なのは実装ではなく「要件定義」です。

法務には、証跡（ログ）の保全、機密保持、誤検出への対応といった、一般的なIT開発とは異なる特有の制約条件があります。これらを無視して開発を始めると、「便利だけど社内で使えない」ツールが出来上がります。

本記事では、法務担当者が自力でツールを企画・開発し、かつ組織として「正当に運用」するための要件定義10STEPを解説します。各STEPには「このステップで必ず作る成果物」を示しているので、順番に埋めていけば、そのまま社内稟議や導入企画書のベースにもなります。

ここで言う「リーガルエンジニアリング」とは、法務の業務要件を、設計・実装・統制まで一貫して技術に落とし込むアプローチです。単にコードを書く技術ではなく、台帳・理由書・ログ仕様といった成果物として残し、稟議・監査に耐える形で運用するところまでを含む方法論全体を指します。

10STEPの全体像

まず全体を俯瞰します。10STEPは「前段（課題特定）→ 実装（ロジック・UI）→ 統制（法務としての正当化）」の3フェーズで構成されています。

なぜ法務のツール開発に「独自の要件定義」が必要なのか

一般的なシステム開発における要件定義と、法務ツールの要件定義には、決定的な違いがあります。

通常のシステム開発では「速度」「ユーザビリティ」「コスト」が三大評価軸です。しかし法務ツールでは、これに加えて「正確性の担保」「証跡の保全」「機密情報の管理」という3つの制約が上位に来ます。

たとえば、契約書レビューを自動化するツールを考えてみましょう。一般的な開発者なら「AIに契約書を読ませて、リスク箇所をハイライトする」という機能仕様から始めるでしょう。しかし法務の視点では、以下の問いが先に来ます。

──その契約書データは、外部のAIサービスに送信して問題ないか？（秘密保持義務・情報管理規程との抵触）
──AIが見落とした条項があった場合、誰がどの時点で責任を負うのか？
──処理結果を後から監査で検証できるか？

こうした問いに答えられない状態で実装を始めると、完成後に「社内で使用許可が下りない」という最悪の結末を迎えます。

よくある失敗パターン

本記事の10STEPは、これらの失敗を構造的に防ぐための設計手順です。

課題と範囲の特定

01現場の「痛み（ペイン）」を言語化する

要件定義の出発点は、「何が辛いか」の正確な言語化です。

「契約書レビューに時間がかかる」では不十分です。具体的に、どの工程で、何の判断が詰まっているかを特定する必要があります。

たとえば「契約書レビューに時間がかかる」を分解すると、次のように細分化できます。案件受付時に、どの契約類型かの判別に迷う（5〜10分/件）。秘密保持条項の有無と適切性のチェックに時間がかかる（15〜20分/件）。過去の類似契約を探すのに社内検索が機能していない（10〜30分/件）。レビュー結果を事業部に説明する資料作成が手作業（20〜30分/件）。

こう分解すると、「全部を自動化する」のではなく「案件受付の類型判別だけを補助する」という現実的なスコープが見えてきます。

02入力データの特性を定義する

ツールが処理する「入力データ」の正体を正確に把握します。法務の入力データは多様で、その特性がツールの設計を大きく左右します。

データ形式： Word（.docx）、PDF、スキャンPDF（OCRが必要）、メール本文、Excel管理表など、形式によって前処理の難易度が変わります。特にスキャンPDFは文字認識の精度に依存するため、入力とすべきかどうかから検討が必要です。

構造化の度合い： 契約書のように一定の構造がある文書と、メール本文のように非構造のテキストでは、処理のアプローチが根本的に異なります。

機密区分： ここが法務ツールの要件定義で最も重要なポイントです。機密区分を整理する際は、「社内規程上のラベル」（社外秘・極秘等）と「法律上の概念」（営業秘密・個人情報等）を区別して記録します。「社外秘」は社内規程が定めた管理区分であり、「営業秘密」は不正競争防止法上の法律要件（秘密管理性・有用性・非公知性）で判定される概念です。両者は重なることが多いものの、同一ではありません。この区別が、外部APIに送信してよいか、ローカル環境でのみ処理すべきかの設計判断の基礎になります。

03自動化の「範囲」と「人間の役割」を分ける

法務ツール開発で最も重要な設計判断は、「AIの担当範囲」と「人間の確定権限」の境界線を引くことです。

100%の自動化を目指してはいけません。法務業務には、最終的に「人間が判断し、確定する」ことが求められる局面が必ずあります。ツールの役割は、人間の判断を「補助」し、判断に至るまでの工数を削減することです。

たとえば、契約書のマスキング（個人情報等の秘匿化）であれば、AIがテキストから個人名・住所・口座番号等のパターンを検出してマスキング候補を提示し、人間が候補を確認して「マスキングする/しない」を確定します。誤検出（マスキング不要な箇所の検出）や漏れ（検出されなかった箇所）の補正も人間の役割です。

この境界設計を「人間確定ポイント」と呼びます。人間確定ポイントが明確であれば、ツールの事故が起きても「どこで人間のチェックが入るか」が説明できます。

ロジックとインターフェース

04中核ロジックの選定（AIか、ルールベースか）

ツールの「頭脳」にあたる処理ロジックを選定します。大きく分けて3つの選択肢があります。

① ルールベース（正規表現・辞書マッチ）──定型的なパターンの検出に強い。電話番号、メールアドレス、マイナンバーなど、形式が決まっている情報の検出は、AIよりも正規表現のほうが正確かつ高速です。ブラックボックスにならないため、「なぜこの箇所を検出したか」の説明が容易です。

② AI（LLM：大規模言語モデル）──非定型の判断に強い。「この条項は甲に不利か？」「この契約書の要点は何か？」といった、文脈に依存する判断はAIの得意領域です。ただし、ハルシネーション（もっともらしい嘘）のリスクがあるため、単独での判断確定には適しません。

③ ハイブリッド（ルール＋AI）──実務上、最も現実的な選択肢です。定型部分はルールベースで確実に処理し、非定型部分はAIに判断を委ね、最終的に人間が確定します。

05誤検出・見逃し・ハルシネーションへの対応設計

法務ツールが出す「誤り」には、性質の異なる3種類があります。設計段階でこれらを区別しておかないと、「何に備えるUXなのか」が曖昧になり、対策が中途半端になります。

法務ツールでは、「精度を上げる」ことよりも先に、「誤りに気づける設計（人間確定＋根拠提示＋ログ）」を要件として固定することが重要です（AIレビューの精度課題については「Claudeで契約書チェックしたら見落としが95%減った話」も参考になります）。以下、リスクの種類ごとに対策を整理します。

05-1　誤検出（FP）と見逃し（FN）を分けて設計する

誤検出と見逃しは、対策の方向が正反対です。誤検出を減らそうとルールを厳しくすると、見逃しが増えます。法務ツールでは一般的に、見逃しのほうがリスクが大きい（検出されなかった情報がそのまま流出し得る）ため、「多少の誤検出は許容し、見逃しを最小化する」方向にチューニングし、誤検出は人間確定フローで除外する設計が現実的です。

05-2　ハルシネーション対策：根拠・引用・「判断不能」の強制

ハルシネーションへの対策は、誤検出・見逃しとは異なるアプローチが必要です。AIの出力結果に対して、根拠となった条文やガイドラインの該当箇所を引用させること、および、AIが十分な根拠を持たない場合に「判断できません（要・人間レビュー）」と明示させることをMust要件に含めます。AIに「分からない」と言わせることは、法務ツールにおいては弱点ではなく安全装置です。

05-3　人間確定フロー：採否＋理由＋再実行

3種類のリスクすべてに共通する最終防衛線が、人間確定フローです。AIの出力に対してレビュー優先度（高/中/低）を付与し（「自信度」や「確率」ではなく、「人間が確認すべき度合い」として表示する）、候補ごとに「採用／不採用／保留」を選択でき、その判断がログに残る仕組みを設計します。

06アウトプット形式の定義

ツールの出力形式は、利用者の業務フローに合わせて設計します。「どんなに良い処理ロジックでも、出力が使いにくければ採用されない」のが現実です。

修正履歴付きWord文書──契約書のレビュー結果を出力する場合、変更箇所が追跡できるWord形式が最も実用的です。比較用Excel──複数の契約書を横断的に比較する場合やチェックリスト形式に適しています。通知メール/チャット連携──案件の受付や期限管理のアラートに。ログファイル（JSON/CSV）──STEP 10の監査ログとして保存します。

出力形式を決める際は、「その出力を受け取った人が、次に何をするか」を想像することが重要です。出力は「次のアクション」に直結するものでなければなりません。

07ユーザーインターフェース（UI）の選定

UIの選定は、技術的な好みではなく、「誰が使うか」と「どう配布するか」で決めます。

CLI（コマンドライン）──開発者自身が使うプロトタイプには最適ですが、法務部内の他のメンバーに展開するには不向きです。GUI（デスクトップアプリ）──exe化して配布できれば、ITリテラシーを問わず利用可能です。ただし、社内のソフトウェアインストール規程を確認する必要があります。社内Webアプリ──配布の容易さは最高ですが、サーバーの運用・保守が必要です。Excel VBA / Google Apps Script──導入ハードルが最も低い。既存のExcel業務フローに組み込めるため、「いきなりの変化」を嫌う組織には効果的です。

法務ツールの場合、「教育コスト」と「配布の容易さ」のバランスが選定の鍵です。高機能でも使い方の習得に時間がかかるUIは、法務部門では敬遠されます。

08設定ファイルの外部出し（YAML/JSON）

法務ツールは「法改正」や「社内規程の変更」に伴い、処理ルールを更新する必要があります。このとき、ルールがコード内にハードコーディングされていると、プログラミングの知識がない担当者では更新できません。

解決策は、処理ルールを設定ファイル（YAMLやJSON）に外部化することです。

設定ファイルを外部化するメリットは、「法改正対応のたびに開発者に依頼しなくて済む」ことだけではありません。設定変更の履歴管理（いつ、誰が、何を変えたか）も容易になり、STEP 10の監査ログと組み合わせることで、ツールの運用状況を透明化できます。上の例で legal_basis（参照すべき社内規程）や approved_by（承認者）を設定ファイルに明記しているのは、単なる技術設定ではなく「法務判断の根拠と承認プロセスを外部化している」ことを示すためです。

法務としての正当化

ここからの2ステップが、本記事の最大の差別化ポイントです。一般的な技術ブログには書かれない、しかし法務が自作ツールを社内で「正当に」運用するために不可欠な要件です。

09情報管理とデータセキュリティの要件

法務ツールが扱うデータには、以下の法的・規程的な制約がかかる可能性があります。要件定義の段階で、これらの制約を整理し、ツールの設計に反映させる必要があります。

① 営業秘密（不正競争防止法）
契約書に含まれる取引条件、価格情報、技術情報等が「営業秘密」に該当する場合、秘密管理性を維持する方法が必要です。営業秘密に該当するかは、一般に秘密管理性・有用性・非公知性の3要件で整理します。外部クラウドサービスへの送信は、秘密管理性の喪失リスクを伴うため、これらの要件を踏まえた設計判断が求められます。

② 個人情報・個人データ（個人情報保護法）
契約書に含まれる署名者の氏名、住所等の個人情報を処理する場合、利用目的の範囲内であるか、第三者提供に該当しないかを確認します。外部AIサービスに契約書データを送信する場合、当該サービス提供者への個人データの提供に該当し得るか、あるいは委託として整理できるか、および委託先の監督（安全管理措置を含む）の観点で整理が必要です。

③ 安全管理措置
個人情報保護法は、個人データの取扱いにあたり、安全管理措置（組織的・人的・物理的・技術的）を講じることを求めています。自作ツールのアクセス権限設定、データの暗号化、保存場所の管理などが該当します。

④ 社内規程（情報管理規程・IT利用規程）
多くの企業には、業務データの外部送信や業務ツールの利用に関する社内規程があります。自作ツールであっても、これらの規程の適用対象になり得ます。事前に情報管理部門に確認し、必要に応じて規程上の整理を行いましょう（生成AIの社内ルール整備については「社内ルールと生成AIの法務リスク」、個人情報保護法の改正動向は「個人情報保護法改正でプライバシーポリシーの何を変える？」で解説しています）。

これらの要件を整理した結果として、「外部APIを使用せず、オフラインで動作するツール設計」が最適解となるケースは少なくありません。

10証跡（監査ログ）・説明責任・再現性

自作ツールを社内に配布する場合、法務部門としての説明責任が問われます。

「なぜこのマスキングロジックにしたのか」「どのAIモデルを使用し、データはどこまで送信されているのか」「処理結果を誰がいつ確定したのか」──これらの問いに、後から正確に答えられる仕組みを、ツールに組み込む必要があります。

監査ログに最低限記録すべきは、いつ（処理日時）、誰が（操作者のID・氏名）、何を（対象ファイル名・処理内容）、どのルールで（適用した設定ファイルのバージョン）、結果はどうなったか（処理結果の要約、採用/不採用の判断）の5項目です。

ログは「お守り」ではありません。万が一の事故が発生した際に「適切に運用していた」ことを証明する最大の武器です。事故後に「ログがない」状態は、法務として最も説明が困難な状況を生みます。

さらに、ログが持つもう一つの重要な価値は「再現性（Reproducibility）」です。ログにモデル/ルール/設定ファイルバージョン/入力ファイルのハッシュが揃っていれば、同じ条件で処理を再実行し、同じ結果を得ることができます。これは、事故時の原因特定、監査時の検証、そして品質改善のための比較テストの基盤になります。「証跡」は過去を説明するため、「再現性」は過去を検証するためのものです。

要件定義テンプレート：Must / Should / Could

ここまでの10STEPを踏まえ、法務ツール開発の要件定義をMust / Should / Couldの3段階に整理します。社内稟議の添付資料としても使えるよう、非機能要件も含めました。

機能要件

非機能要件

まとめ：要件定義は「稟議書」の裏返しである

本記事で解説した10STEPの要件定義は、実はそのまま社内稟議書のロジックに転用できます。

稟議書で求められる「なぜこのツールを導入するのか」「リスクはどう管理するのか」「誰が責任を持つのか」という問いへの回答は、すべてこの10STEPの成果物の中にあります。

要件定義を丁寧に行うことは、「良いツールを作る」ためだけでなく、「組織としてそのツールを正当に運用する」ための基盤を整えることでもあります。

次のステップ

本記事の10STEPを実装に落とした具体例として、筆者は以下のツールを開発・運用しています。いずれも無料で公開中です。

これらのツールの設計・実装・配布の詳細は、今後の連載記事で順次公開していきます。