ENTRY TYPE · definition

リーガルホールドプロセス

By Marius Bughiu Last updated 2026-05-23 Legal Ops

リーガルホールド（Litigation Hold または Preservation Hold とも呼ばれる）とは、組織が通常のデータ削除慣行を停止し、カストディアンに対して、係争中または合理的に予見される訴訟・規制当局の調査・内部調査に関連する可能性がある電子的に保存された情報（ESI）と物理文書を保全するよう指示する正式なプロセスです。これは任意ではありません。証拠の保全義務は法的義務であり、違反した場合、不利な推論命令や場合によっては訴訟を終結させる結果など、制裁を引き起こす可能性があります。リーガルホールドはデータバックアップではなく、アーカイブポリシーでもなく、discovery プロセスのための収集とも異なります。特定の人物に特定のデータについて向けられた保全指示です。

何でないか

リーガルホールドは文書保持ポリシーと同じではありません。保持ポリシーは通常の業務運営においてデータカテゴリが定期削除前にどれくらい保持されるかを規定します。リーガルホールドは、保全トリガーに達した時点で、特定のカストディアンの管理下にある特定のデータに対してそのポリシーを上書きします。両者は共存します。保持ポリシーは通常業務で何を削除するかを説明し、リーガルホールドは対象データの通常業務での削除を停止します。

リーガルホールドは収集命令でもありません。ホールドを発行するとデータが所定の場所に保全されますが、レビュープラットフォームにコピーされるわけではありません。収集はその後に行われる別の eDiscovery ステップです。ホールドと収集を混同すると、保全不足（保持が少なすぎる）または法的必要性のない保全過多によるレビューコストの増大につながります。

FRCP における保全義務

米国の訴訟については、保全の枠組みは Federal Rules of Civil Procedure (FRCP) から来ており、主にルール 26 と 37 です。FRCP Rule 37(e) の下では、当事者が「訴訟の予期または遂行において保全されるべきであった」ESI を保全するための「合理的な措置」を取らなかった場合、裁判所は是正指示、不利な推論命令、または訴訟棄却に及ぶ制裁を課す可能性があります。Rule 37(e) は新たな義務を創設しているのではなく、Zubulake 事件シリーズ（Zubulake v. UBS Warburg、SDNY、2003-2004）を含む事件によって確立されたコモンロー上の義務を成文化しています。

義務は訴訟が提起された時ではなく、訴訟が「合理的に予見される」時に発生します。裁判所はその時点での組織の知識に基づいてこれを評価します。需要書の受領、規制当局の調査の開始、契約紛争の重大なエスカレーション、クレームにつながる可能性が高い行為に関する内部調査。トリガーは事実と判断の問題です。特定の状況については弁護士にご相談ください。

EDRM（Electronic Discovery Reference Model、Duke Law の管理下）は、保全を「法的に防御可能で、合理的で、比例的で、効率的で、監査可能で、広範囲だが目標が絞られている」ものとして説明しています（EDRM、edrm.net）。

リーガルホールドのライフサイクル

ステージ 1：トリガーの特定

保全トリガーは訴訟または調査を「合理的に予見される」ものにするイベントです。一般的なトリガーには次のものが含まれます：需要書または停止要求書の受領、召喚状の送達、規制当局の調査の開始、正式な内部苦情または内部告発者報告、クレームにつながる可能性が高い重大なインシデント（データ侵害、製品障害、職場の怪我）、法的関与にエスカレートした契約紛争。

法務部門——通常は General Counsel、副 General Counsel、または案件管理を担当する Legal Ops 機能——は、トリガーイベントを認識し、ホールドワークフローを開始するための文書化されたプロセスを持つ必要があります。

ステージ 2：スコープの決定

トリガーが特定されると、法務チームは関連するカストディアン（潜在的に関連するデータを持つ個人）と、どのデータソースがスコープ内にあるかを決定します。これには以下が必要です：

案件に精通した主要スタッフへのインタビューで、誰が携わり、どのシステムが使用されたかを特定する。
関連データソースのマッピング：メール、ファイル共有、コラボレーションツール（Slack、Teams）、モバイルデバイス、クラウドストレージ、サードパーティ SaaS アプリケーション。
保全データの時間範囲の定義。

スコープは FRCP Rule 26(b)(1) に従い、案件に対して比例的である必要があります。

ステージ 3：ホールド通知の発行

書面によるリーガルホールド通知が特定された各カストディアンに発行されます。通知は以下を含む必要があります：

カストディアンがどのデータが関連するかを理解できる十分な詳細で案件を説明する。
どのデータタイプとシステムが対象かを特定する。
カストディアンに定期削除を停止し、関連情報を改変または破棄しないよう指示する。
質問のための法務チームの連絡先を提供する。
カストディアンが通知を受け取り理解したことを確認する積極的な承認を要請する。

承認追跡が重要です。確認されていないホールドは、全てのカストディアンが受領を確認したホールドよりも法的に弱くなります。

ステージ 4：技術的保全

IT が管理するシステム（メールサーバー、SharePoint、クラウドプラットフォーム）内のデータについて、法務チームは IT と調整してシステムレベルのホールドを実施し、指定されたカストディアンとデータタイプの自動削除を停止します。

ステージ 5：継続的な監視とコンプライアンス

発行されて放置されたホールドは失敗するホールドです。積極的な監視には以下が必要です：

**承認フォローアップ。**応答しないカストディアンはエスカレートするリマインダーを受け取ります（通常 7 日、14 日、その後上司へのエスカレーション）。
**カストディアンの変更。**カストディアンが組織を去ったり、新しい役割に異動したり、関連データに影響する役割が変わったりした場合、ホールドを更新する必要があります。
**スコープの修正。**案件が発展するにつれ、新しいカストディアンが特定され、新しいデータソースが関連するようになり、またはスコープが絞られます。ホールド通知に正式な修正を発行します。
**定期的なリマインダー。**確認済みのカストディアンでも定期的なリマインダー（通常 90〜180 日ごと）からコンプライアンス強化の恩恵を受けます。

ステージ 6：収集（トリガーされた場合）

案件が本番またはレビューのための文書収集が必要な段階に達した時、保全されたデータは eDiscovery プラットフォームに収集されます。

Relativity と Everlaw はどちらも、保全通知管理と eDiscovery 収集を橋渡しする統合リーガルホールドワークフローを提供しています。

ステージ 7：リリース

案件が終結すると——和解、判決、調査終了——ホールドは正式にリリースされます。リリースには 2 つのコンポーネントがあります：

**カストディアンへの正式通知：**保全義務が解除され、通常の保持/削除慣行を再開できること。
**IT への正式通知：**影響を受けるカストディアンとデータソースのシステムレベルの保全を無効にすること。

自動化が役立つ場面

リーガルホールドソフトウェアはテンプレートから標準化された通知を生成し、送信し、リアルタイムで承認を追跡し、リマインダーエスカレーションを自動化します。HR システムとの統合は、従業員の離脱、役割変更、アクティブなホールドに関連する新しいカストディアンの追加を検出します。これが最も価値の高い自動化です——ホールド失敗の最も一般的な原因に対処します。

よくある落とし穴

曖昧な通知の発行。「Smith 案件に関連するものをすべて保全してください」というホールド通知は、どのシステム、どの時間範囲、どのドキュメントタイプを保全するかについてカストディアンに何の指針も与えません。対策：データソースと時間範囲のフィールドを明示した通知テンプレートを案件ごとに記入して作成する。

**退職する従業員の追跡漏れ。**アクティブなホールドの主要カストディアンである従業員が組織を去り、標準的なオフボーディング中にデータが削除されます。対策：ホールドシステムを HR オフボーディングワークフローと統合して、退職前にアクティブなホールド上のカストディアンにフラグを立てる。

**ホールドと収集の混同。**弁護士がスコープを決定する前に保全されたすべてのデータをレビュープラットフォームに収集すると、レビューコストが不必要に増加します。対策：広く保全し、スコープが定義された後に絞り込んで収集する。

**早すぎるリリースまたは一切リリースしない。**対策：リリースを文書化された案件処分イベントに紐付け、アクティブなホールドにまだ進行中の案件があることを確認するために 180 日ごとにホールドレビュープロセスを設ける。