リーガルリサーチシステム開発の発注/外注/依頼/委託方法について

リーガルリサーチシステムの発注は、業務要件を整理し、情報源と開発範囲を分けたうえで、RFPで提案を比べながら段階的に進めるのが基本です。

発注形態、要件整理と契約、費用相場、委託先の選び方を、この順に見ていきます。全体像は下の記事でも確認できます。

▼全体ガイドの記事
・リーガルリサーチシステム開発の完全ガイド

リーガルリサーチシステムは、法令・判例・審決・文献を探すサービスにとどまりません。企業法務では、外部の法情報と契約書、相談記録などをどこまで連携させるかによって、発注内容や費用が変わります。そのため、社内規程や過去の判断記録をどこまで結び付けるかは、発注前に決めておく必要があります。

法律情報の購入と個別開発の切り分け

法令、判例、法律雑誌などのコンテンツは、編集の品質と利用許諾をもつ専門ベンダーから購入するほうが、安全な場合が多いです。一方で、社内規程の横断検索や案件フォルダ、相談受付、契約管理システムとの連携は、自社業務に合わせて受託開発会社やSIerに依頼する余地があります。

このため、外部法情報はSaaSで、自社データはAPI連携やRAGに分けて考えると、ライセンスの問題と開発範囲を整理しやすくなります。

利用者と最終確認者の決定

弁護士や法務担当者、事業部門、監査担当者では、必要な検索画面や権限が異なります。なお、AIが論点候補を示しても、法的な最終判断をAIだけで完了させる設計にはできません。

誰が原典を確認し、誰が回答を承認するか、どの履歴を監査証跡として残すかは、発注前に定めておきます。発注前に定めておくと、後から承認ワークフローを足す手戻りを抑えられます。

ポイント

法令や判例の検索だけでなく、社内情報とどこまで連携させるかで発注内容が変わります。発注前に、社内規程や判断記録の連携範囲と、利用者や最終確認者を決めておきます。

既製サービス・連携・スクラッチの発注形態

既製の法律情報クラウド、SaaSと社内文書検索の連携、スクラッチ開発を並べた導入形態の図解。
扱う社内業務の範囲が広がるにつれて、連携や個別開発が加わります。

発注形態は、自社にない情報や運用をどこまで外部に任せるかで比べます。すぐに検索を始めたいのか、社内文書や既存システムも扱いたいのかを整理すると、候補を絞れます。

既製の法律情報クラウドの導入

TKCとWestlawは、公式の料金表や資料で月額料金が示されており、下の一覧で金額を比べられます。

  • 候補サービス:Westlaw Japan、TKCローライブラリー、D1-Law.com、Legalscape
  • TKC基本サービス:公式料金表で1ID月額9,000円(税抜、2025年9月1日時点)
  • TKC基本サービスセット:公式料金表で1ID月額14,000円(税抜、同日時点)
  • Westlaw基本パッケージ:公式資料で月額10,962円から

各サービスはコンテンツの範囲や契約条件が異なるため、公開価格だけで優劣を判断せず、必要な情報源と同時利用人数を照らし合わせます。

SaaSとAPI・SSO・社内文書検索の組み合わせ

専門DBはそのまま残し、社内規程や契約書を検索対象に加える方法です。

検索画面は一から作らず、SSOや権限連携、API、社内文書用の検索基盤だけを追加します。このため、使いやすさと開発費のバランスを取りやすくなります。

外部DBの検索結果を社内システムに保存したり再配布したりできるかは、契約によって異なります。そのため、APIの利用範囲とキャッシュの可否、引用表示の条件を、ベンダーに確かめておきます。

自社固有業務のスクラッチ開発

法務相談と案件ごとの調査記録を、承認や契約管理、基幹連携と一つの業務フローにまとめる場合は、受託開発を検討します。ただし、全領域を一度に対象にすると、要件が膨らみやすくなります。

たとえば、法務部10〜20人程度を対象に、特定分野の法令・判例・社内規程で3か月程度のパイロットを行う方法があります。調査時間と再検索回数、原典確認時間を測り、アラート対応率も確認しながら、効果の出た範囲から広げます。

ポイント

検索をすぐ始めたいなら既製サービス、社内文書や既存システムも扱うなら連携や個別開発を検討します。外部データと自社データを分けて考えると、候補を絞りやすくなります。

RFPと要件整理における業務フローの記述

RFPに記載する現状業務、対象データ、権限、AI機能の受入条件を4項目で示した図解。
検索機能の指定に加え、運用とデータの条件も提案比較の土台になります。

RFPは、「検索できるシステムがほしい」という要望書とは違い、同じ条件で提案と見積もりを受けるための資料です。そのため、調査手順と困っている時間、扱うデータを書き出し、権限と連携先も明記します。受入条件と運用体制も、同じ資料に記載します。

現状業務とMUST・WANTの具体化

まず、現状の業務を流れに沿って書き出します。調査依頼を受け、論点を分解し、法令や判例を検索して、引用箇所を保存します。そのうえで、レビューを経て回答を共有するところまで書きます。

必須要件は、検証できる形で書きます。たとえば「法令の現行・過去履歴検索」「判例の事件情報による絞り込み」「引用元へのリンク」「案件別の保存」「操作ログ」のような項目です。

自然言語検索、要約、関連文献の推薦は、効果を見込める場合でも優先順位を下げ、WANTに置きます。このため、初期開発が膨らむのを抑えられます。

RFPへのデータ区分と権限の記載

外部データと内部データでは、所有権と保存期間が異なるうえ、利用許諾や削除条件も違います。文書の種類ごとに、保管場所と更新頻度、検索対象を決めます。さらに、閲覧できる役割と持ち出しの可否も、あわせて整理します。

事業部門が自分の案件を検索できても、他部署の秘密情報や個人情報は見せてはいけません。部署、案件、文書の単位で権限を決め、そのテストケースもRFPに記載します。

AI機能の評価軸:回答品質より受入条件

AI検索では「正しい回答を返す」といった曖昧な条件は避け、評価できる受入条件を定めます。回答には、引用元の文書名と該当箇所を示し、基準日や更新日、検索条件も表示します。

権限のない文書は参照させず、根拠がないときは回答を保留させる設計にします。

匿名化した質問と正解資料を評価用データとして使い、引用の正確性や古い法令の混入、回答の再現性を確かめます。

ポイント

RFPには、検索機能より先に業務フローを書きます。現状業務や必須要件、データと権限、AI機能の受入条件をそろえると、各社が同じ前提で提案できます。

発注からリリースまでの段階と進め方

要件定義と基本設計から、データ移行とテストを経て、教育・リリース・運用へ進む工程図。
データ移行とテストを区切りに、導入準備から継続運用へ進みます。

原典と権限が重要な法務システムでは、各工程の判断基準が欠かせません。契約後は、承認する段階を先に決めたうえで、次のとおり進めます。

  1. 要件定義
  2. 設計・開発
  3. データ移行
  4. テスト
  5. 教育とリリース
  6. 保守と運用

要件定義と基本設計での判断基準の共有

要件定義では、検索対象やデータ更新、権限を決めます。ログや外部連携、障害時の運用も、同じ段階で定めます。

法改正データの更新担当と、判例・書籍の収録範囲を担保する契約も確かめます。

社内文書の削除依頼を何日以内に反映するかも決めておきます。運用仕様も画面仕様と同じ細かさで作ると、開発会社の見積もりの漏れを見つけやすくなります。

データ移行とテストの工程管理

過去の調査メモや契約書は、重複や欠損、文字化けがないかを確認します。さらに、古い版が混在していないか、アクセス権を引き継げるかも見ます。

受入条件には、元ファイルを開けることと、引用位置を特定できることも含めます。

権限のない利用者には、検索結果が存在すること自体も見せないよう確かめます。本番移行の前に一部データで試し、件数や失敗率、移行後の検索精度を報告してもらいます。

教育・リリース・運用の発注範囲

検索式や引用の残し方が人によってばらばらだと、ナレッジは蓄積されません。そのため、操作研修と利用ガイドを契約範囲に含め、問い合わせ窓口や管理者向けの権限変更手順も入れます。

リリース後は、月次で利用状況と検索の失敗を確認します。法改正データの更新や脆弱性対応は、バックアップや障害復旧と合わせて、どの費用で行うかを明確にします。

要件の確定度と変更の多さで選ぶ契約形態

サービス利用契約、準委任契約、請負契約は、組み合わせて使うこともあります。その際は、成果物が確定した部分と、検証しながら決める部分を分けて考えます。

既製サービスの利用規約とSLA

法律情報クラウドは月額契約が中心です。料金だけでなく、収録コンテンツやID追加、同時利用の条件を確かめます。そのうえで、APIやSSO、ログ保存、サポート時間も確認します。

社内文書をAI検索に使う場合は、入力データの学習利用と保存場所を、契約条項で確認します。暗号化やテナント分離、解約時の返却と削除も、条項に明記されているかを確かめます。

障害時の復旧目標と法改正データの更新責任は、契約書とSLAで裏づけを取ります。

検証と改善が多い案件の準委任契約

RAGの検索精度や利用者評価を見ながら改善する場合は、作業時間や役割を定める準委任契約が候補になります。要件変更が多いパイロットや、データクレンジング、検索調整、運用設計に向いています。

請負金額を都度変えるより、月ごとの作業内容と成果報告を合意しておくほうが、進めやすくなります。納品物と作業時間の上限、未消化分、追加費用の条件は、契約書に明記します。

請負契約の成果物と検収条件

画面やAPI、データ移行、テスト仕様書などの成果物と完成条件が固まっている場合は、請負契約を検討します。そのうえで、検収期限や瑕疵対応、第三者ソフトのライセンスを確かめます。

ソースコードや設定情報の帰属、再委託の可否、終了時の引き継ぎを確認します。AIを含む場合は、モデルの利用権に加えて、プロンプトや評価データ、検索インデックス、ログの利用権も決めます。

リーガルリサーチシステムの費用相場と内訳

費用は、法律情報DBの月額利用料と、社内業務に合わせた初期開発費に分けて見ます。なお、以下の金額は法務専用の公的統計ではありません。

金額は、リサーチノートで整理した文書・契約・法務系の類似業務システムからの推定です。会社や要件で変わるため、予算計画の入口として使い、最終的には同じRFPで見積もりを取得します。

導入形態ごとの費用レンジ

公開料金と開発費の推定レンジは、導入形態によって異なります。金額は次のとおりで、予算計画の目安です。

  • 法律情報クラウド:1ID月額9,000〜33,000円程度
  • 社内文書検索の追加:初期費用50万〜300万円程度
  • 特定業務の部分開発:300万〜1,500万円程度が目安
  • 複数業務の統合開発:1,500万〜4,000万円程度
  • 独自データとAI検索を含む開発:4,000万円を超える可能性

TKCローライブラリーの基本サービスは1ID月額9,000円(税抜)です。企業法務向けの連携パックは、1ID月額27,000〜29,095円(税抜)で、利用範囲によって選択肢が変わります(出典:TKC公式料金表、2025年9月1日現在)。

Westlaw Japanの公式資料では、基本パッケージが月額10,962円から案内されています(出典:Westlaw Japan公式「WLJP Basic Package」)。ただし、クラウド料金は検索コンテンツの利用料で、移行や個別API開発、SSO設定は別費用です。

開発費は類似システムからの推定です。そのため、画面数だけでなく、データ量と権限、連携の範囲に応じて調整します。評価や保守の範囲も、調整の対象にします。

見積書の初期費用と運用費の内訳

見積書では、初期費用と運用費を分けて確認します。「保守一式」とだけ書かれている場合は、その範囲も確かめます。

  • 初期費用:企画・要件定義、UI設計、検索基盤と認証連携、移行、AI評価とテスト、研修
  • 運用費:クラウドと検索インデックス、AI利用量、外部DBの契約、監視とバックアップ、法改正データ更新、問い合わせと脆弱性対応
  • 保守一式の内訳:監視時間帯、障害の一次切り分け、復旧目標、法改正対応、月次改善

人件費だけで比べると、外部サービスのライセンスやデータ更新が別請求になり、年間の費用が高くなることがあります。

業務システムの工程別の目安は、要件定義が10%、設計が10〜20%、開発が40〜60%、テストが10〜20%という整理があります。この割合は一般的な業務システムの整理で、法務専用の公的統計ではありません(出典:リサーチノートに収録した業務システム開発相場の整理)。一方、法務システムでは、データ許諾や移行、評価に追加の工数が出ることがあります。

パイロットを起点にした期間と予算の段階設定

SaaSの初期設定は数日〜3か月、社内文書連携は1〜4か月、部分開発は3〜6か月が目安です。また、複数領域の統合は6か月以上で、AI検索や独自データ、厳格な監査要件を含む場合は9〜18か月以上になる可能性があります。

期間も要件によって変わります。そのため、調査・要件定義、パイロット、本番拡張の段階ごとに、予算と判断の区切りを置きます。

ポイント

費用は、公開料金と個別開発の推定レンジを分けて見ます。見積書の初期費用と運用費を分け、保守一式の内訳まで確かめると、比べやすくなります。

同じ条件と総保有コストでの見積もり比較

見積もりを3社程度に依頼するときは、各社に同じ資料を渡します。RFPや対象データの件数、利用者数を明記し、連携先や希望時期、検収条件もそろえます。

提案書の説明力だけでなく、前提条件と対象外も確かめます。記載が明確であれば、安い見積もりの抜け漏れを見つけやすくなります。

見積もりの前提条件と対象外の照合

まず、要件定義、デザイン、開発の範囲を、同じ条件で照合します。次に、連携と移行、テストの範囲を照らし合わせ、研修、保守、外部サービスの扱いも確かめます。

作業工数や単価、期間、成果物も並べます。前提、リスク、追加費用の条件も、あわせて書き出します。

たとえば、A社の初期費用が低くても、SSOや文書移行が対象外で、AI利用料が従量課金なら、B社の一括見積もりと単純に比べることはできません。

委託先の専門性とプロジェクト体制

委託先の経験と体制は、法律情報のライセンスや社内文書の権限設計を含めて確かめます。質問の観点を決めておけば、担当範囲と継続運用を判断できます。

  • 専門性:検索、RAG評価、認証、監査ログ、既存連携の実績
  • 体制:契約後の担当者と再委託先
  • 対応:障害時の応答時間

法律情報DBのプロダクト企業と、個別システムを作るSI・受託開発会社では役割が違います。そのため、同じ評価軸で順位を付けず、必要な役割に合う候補同士を比べます。

デモと類似事例の確認方法

デモでは、一般的な検索語だけでなく、自社でよく使う論点を匿名化して入力します。

  • 検索結果:出典、条文の履歴、判例の引用箇所
  • 権限と回答:権限外データの扱いや、回答できない場合の表示
  • 類似事例:AIの有無に加えて、対象データや利用者、原典へ戻る画面まで照合

類似事例として、電算システムは2025年3月、ぎょうせいの「My六法」で、Amazon BedrockのRAGによる法令・条例の自然言語検索を実装したと発表しました(出典:株式会社電算システム公式発表、2025年3月21日)。

契約前に確認したい失敗しやすい点

契約前には、利用許諾と権限を確かめます。AIの回答、移行と更新、解約時の条件も整理します。

  • 利用許諾:検索機能を先に作ると、後から許諾の範囲が問題になることがあります
  • 権限設計:全社展開を前提にすると、権限の組み方が複雑になりがちです
  • AIの回答:正解と決めつけて原典確認を省くことも、失敗の原因になります
  • 移行と更新:移行対象の文書が想定より汚れていることや、更新担当がいないことも、リスクです
  • 契約条件:解約時の返却と独自形式へのロックインに注意します。RFPには、ライセンスや権限、更新、ログ、AI学習利用、障害対応を入れます。

ポイント

見積もりは、同じRFPで依頼し、前提条件と対象外、総保有コストをそろえて比べます。委託先は専門性と体制、デモでの確認も合わせて判断します。

2026年時点の最新動向:AIガバナンスの発注条件

リーガルリサーチでAIを使う際は、モデル性能だけでなく、入力データと学習利用、説明可能性を発注条件に含めます。人の確認やログ保存も、条件に加えます。

経済産業省と総務省の「AI事業者ガイドライン」は、2026年3月31日に第1.2版へ更新されました。また、AIを事業に組み込む企業は、リスク管理や透明性を含む運用を検討する必要があります(出典:経済産業省・総務省「AI事業者ガイドライン第1.2版」、2026年3月31日)。

機密情報をAIへ入力する条件

契約書や相談記録には、個人情報や取引先の秘密情報、未公開案件の情報が含まれることがあります。

AIへ送るデータの範囲や匿名化、保存期間を確認します。さらに、学習利用や第三者提供、削除証明も確かめます。

「安全です」という説明に頼らず、資料と契約書で中身を確かめます。データフローとアクセス権、暗号化、監査ログを見ます。脆弱性対応や事故時の連絡期限も、契約書で確認します。

AIの出力を候補情報として確認する設計

AIは論点候補や関連資料を探す補助とし、法的評価や社外向け回答は、専門家が原典を確認して承認します。画面には、根拠文書と該当箇所、基準日を示します。さらに、生成日時や参照した検索結果も表示します。

根拠が見つからない場合は、無理に文章を作らず「根拠を確認できません」と返します。正答率だけでなく、誤引用や古い法令、権限外文書の混入も検査します。

法律書籍や判例解説、雑誌、文献は、検索・表示・保存・社内共有・AI処理で、同じ条件が認められるとは限りません。外部DB本文の複製や、検索結果の案件記録への保存を確認します。退職者のアカウントや、解約後の引用の扱いも確かめます。

公開Webの文章を無断で収集して学習させる前提は置かずに、RFPを作るのが安全です。

よくある質問(FAQ)

発注・外注に関する疑問に答えます。費用や期間は要件で変わるため、公開料金と個別開発の推定レンジを分けて考えます。

リーガルリサーチシステムはスクラッチ開発とSaaSのどちらがよいですか?

法令や判例の検索を早く始めたいなら、専門SaaSが向いています。相談フローや社内文書検索も変えたい場合は、SaaSと個別開発の組み合わせが候補になります。

固有業務が多い場合も、小規模なパイロットで効果と権限設計を確かめてから開発範囲を広げると、過剰開発を防ぎやすくなります。

発注前に費用を正確に決められますか?

法律情報DBの利用料は、公開価格から比べられます。一方で、社内文書連携や移行、SSOやAI、運用は、個別見積もりになることが多いです。

対象データや利用者数、連携先を決め、受入条件と保守範囲もそろえます。そのうえで、同じRFPで複数社に見積もりを依頼します。

見積もりでは、初期費用と月額費用を分けて確認します。従量課金や追加開発、更新後の費用も、別に見ておきます。

AIの回答を法務判断にそのまま使ってもよいですか?

そのまま使う設計にはしません。AIは情報収集や論点整理を支援するもので、原典や該当箇所、基準日は、人が確認してから回答を確定します。

AI事業者ガイドライン第1.2版も踏まえ、入力情報の機密性と透明性を発注要件に含めます。リスク管理や利用者による確認も、発注要件に加えます。

RFPにはどの情報を最低限入れるべきですか?

現状の調査フローと解決したい課題を記載します。利用者と権限、対象データ、既存連携も書きます。さらに、検索・保存・共有の要件とAI利用条件を入れます。

セキュリティや移行、テストの条件に加え、希望時期と予算の考え方も書きます。対象外の範囲と質問事項を明記すると、各社が同じ前提で提案できます。

まとめ

発注では、法令・判例の既製サービスと、社内文書・相談業務の個別開発を分けて考えます。そのうえで、業務フローとMUST・WANTを、RFPに書き出します。利用許諾や権限、AIの受入条件も記載します。

費用だけでなく継続運用で選ぶ発注先

見積もりの比較では、初期費用と月額利用料を分けて見ます。そのうえで、移行やSSO、AI利用量も含めて見ます。さらに、監視や法改正対応、障害復旧、解約時のデータ返却まで含め、総保有コストを確認します。

法律情報のライセンスと社内業務システムの開発・保守を理解し、契約後も同じ担当者が伴走できる会社を選びます。

最初の小さな対象範囲でのRFP作成

全社の法務情報を一度に統合せず、対象部門と情報源、利用者を絞ったパイロットを計画します。

調査時間や原典確認のしやすさ、権限事故、利用定着を測ります。そのうえで、成果を確認した機能から広げると、発注判断や予算の説明がしやすくなります。

▼全体ガイドの記事
・リーガルリサーチシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。