eDiscovery におけるモダン添付

いいえ、既定ではありません。2021 年以降にこの論点を正面から判断した米国連邦裁判所はいずれも、クラウド上のファイルへのハイパーリンクは従来型の添付ファイルではなく、リンクされたファイルは親メッセージの文書ファミリー関係を引き継がないと判示しています。この既定が維持されているのは、リンクの一括解決が実行不可能または不均衡と判断されたからであって、リンクされたファイルが無関係だからではありません。個別に特定された請求があれば依然として開示の対象となりますし、ESI プロトコルで逆の合意をした瞬間に、この既定は完全にひっくり返ります。すでに 2 社の提出側当事者が、高い代償を払ってそれを学びました。

モダン添付（クラウド添付、リンク添付、ポインタとも呼ばれます）とは、メール、Teams の投稿、Slack のメッセージの中にある URL で、SharePoint、OneDrive、Google Drive、Box 上のファイルを指すものです。バイト列がメッセージと一緒に運ばれることはありません。受信者が受け取ったのはポインタと権限だけであり、リンク送信後もリンク先ファイルは生きていて編集可能なままなので、送信者が実際に共有した文書は、誰かが収集する時点ではもう存在しない可能性があります。

モダン添付ではないもの

モダン添付は従来型の添付ファイルではありません。従来型の添付ファイルはコピーです。送信時点で凍結され、メッセージの内部に運ばれ、どのレビュープラットフォームでも理解できる親子関係でメッセージに結び付けられています。モダン添付は、凍結されたコピーも本来的なファミリー関係も持たない参照であり、まさにこの隙間をめぐって判例が 5 年間争ってきました。

公開ウェブページへのリンクとも別物です。報道記事やベンダーの価格ページへのリンクは、あなたの占有・保管・支配の外にあるため、提出義務は生じません。リンクを「モダン添付」にする判断基準は、リンク先ファイルが提出側当事者の支配するシステム内にあるかどうかです。またショートメッセージデータとも別物です。両者は同時に登場しますし、いまや同じ ESI プロトコルが双方を規律していて、Slack と Teams のメッセージこそモダン添付が最も密集する場所ではありますが、別物です。

最後に、Drive 全体を収集すれば解決する問題でもありません。カストディアンのファイルストレージを収集すればファイル自体は手に入りますが、どのメッセージがどのファイルを指していたかは分かりません。請求側当事者が求めているのは、まさにその対応関係です。

裁判所の判断

一貫した筋道は、リンクされたファイルが重要でないという話ではありません。ツールがファミリーの一括再構成を実現できない間、裁判所は提出側当事者にその負担を課すことを一貫して拒み、当事者を個別のやり取りへと誘導してきた、という話です。Meta Pixel はこの切り分けを最も明快に述べています。プロトコル上はファミリーを作らない、そのうえで別枠として、当事者は合理的な個別請求が出てきたときに対応する、という構成です。

StubHub は、何かに署名する前に読むべき事件です。StubHub は、子ファイルに社内文書へのハイパーリンクを含むと定義したプロトコルに合意し、その後、履行できないことに気づき、最初の提出以降ずっと命令に違反し続けました。裁判所はプロトコルを修正して制裁は否定しましたが、損害の原因については率直でした。その不利益は「そもそも StubHub がハイパーリンク要件に合意するという愚かな判断を下したことによって生じた」のです。合意は、技術的な限界を、すでに違反している裁判所命令へと変えてしまいます。

Cerebras のひな形

James v. Cerebras Systems（N.D. Cal.、2026 年 7 月 7 日）は、モダン添付と生成 AI レビューのガバナンスを 1 つの命令で扱った初の合意型 ESI プロトコルであり、そのハイパーリンク条項は現在記録に残るもののなかで最も転用しやすいものです。

• ハイパーリンク文書は、添付の提出という観点では文書ファミリーの構成員ではありません。
• 請求側当事者が、関連するリンクを含む提出済み文書を具体的に特定して当該ファイルを請求します。個別収集の対象は、関連性があり秘匿特権のないハイパーリンク 100 件が上限です。
• 提出側当事者は 14 日以内に、収集時点で存在していた版を提出します。可能な場合は、ハイパーリンクが送信された時点で存在していた版を提出します。

この配分こそが要点です。何が重要かを決めるコストは請求側が負い、それを取り出すコストは提出側が負います。この論点を手に負えないものにしていた「既定ですべてを収集する」やり方は、どちらの側にも求められていません。同じ命令は、AI レビューの検証について Null Set サンプリングの信頼水準 95%、elusion 率 3% 以下も定めており、ショートメッセージデータを最低 24 時間単位の会話バッチで提出することも求めています。これらは eDiscovery の項目で扱っています。

ツールが実際にできること

法的な答えは十分に固まっています。チームがいまだに痛手を負うのは運用面の答えのほうです。主要な 2 つのスイートはどちらもモダン添付を収集しますが、どちらも見落としやすい制限を抱えているからです。

Microsoft Purview eDiscovery は、eDiscovery Premium のレベルでクラウド添付を収集します。これには Microsoft 365 E5 または E5 Compliance アドオンが必要で、データを収集する対象カストディアンごとにライセンスが必要です。ライブ版、共有時点の版、または全バージョンを収集でき、共通の GroupID と Is modern attachment プロパティによって、リンクされたファイルを親メッセージとグループ化します。

落とし穴は、共有時点の版は事前に設定していた場合にしか存在しないという点です。既定では、ワークフローは現在のライブ版を収集します。実際に送信された版を取り戻すには、クラウド添付に自動適用されるよう設定された保持ラベルが必要で、これが共有時点でコピーのスナップショットを作ります。共有が起きる前にそのラベルが動いていなければ、送信された版は一度も保持されておらず、どんな収集設定でも取り戻せません。

Purview の文書化された制限（2026 年 6 月 11 日改訂時点）:

カストディアンの帰属も逆向きに働きます。リンクされたファイルは、ファイルの所有者ではなく、メッセージのカストディアンに帰属します。ユーザー A がユーザー C の OneDrive にあるファイルをユーザー B と共有し、あなたがユーザー B のメールボックスから収集した場合、そのファイルはユーザー B の下に入ります。

Google Vault は、Gmail エクスポートの Export linked Drive files オプションでリンクされた Drive ファイルをエクスポートします。返されるのは現在の版だけで、Purview の保持ラベルによるスナップショットに相当する「送信時点の版」の仕組みは Vault にはありません。公開された Google Sites のページや送信可能な Google フォームのリンクといった公開ハイパーリンクはエクスポートできず、一部の旧形式の Drive リンクや、暗号化されたメッセージ内のリンクも同様です。エクスポートされたファイルは親メッセージから切り離された状態で届くため、レビューの前に、エクスポートされた drive-links の対応表から後工程で関係を再構成する必要があります。

収集前に交渉する方法

これを ESI プロトコルの中で、カストディアンを 1 人でも収集する前に決めてください。

1. ファミリー規則を明示的に書く。 Meta Pixel / Cerebras の言い回しで、ハイパーリンクされたファイルは文書ファミリーの構成員ではないと書きます。沈黙はどちらの答えよりも悪い結果になります。すでに提出を終えた段階に争いを持ち越すことになるからです。
2. 個別請求の仕組みを、数字と期限付きで定める。 Cerebras はハイパーリンク 100 件と 14 日を与えています。事案に見合った数値を選んでかまいませんが、必ず数値を選んでください。上限のない「合理的な請求」は、一括収集の問題を別の名前で再現するだけです。
3. どの版を負うのかを明記する。 収集日の版か、送信日の版か。対象サイト全体でクラウド添付の保持ラベル付けがメッセージ送信当時にすでに稼働していたのでない限り、送信日の版を約束してはいけません。ポリシー文書ではなく、設定日を確認してください。
4. 自社に実在する除外事項を書き出す。 使用するプラットフォームの実際の制限をプロトコルに写します。50 リンクの上限、暗号化メッセージ、転送メールの引用部分、Teams の共有チャネルです。「技術的に可能な範囲で」は後日争うことになる文言ですが、列挙された一覧は指し示せる文言です。
5. 上限を相互に適用する。 双方が文書を多く抱える事案では、請求側当事者は反訴では提出側当事者になります。
6. 署名前に実行可能性テストを行う。 対象範囲のメッセージを数百件サンプリングし、実際に使うプラットフォームに通し、提出できるファイルに解決するリンクが何件あるかを数えます。交渉の土台になるのは、ベンダーの仕様書ではなく、この数字です。

よくある落とし穴

• テストせずにハイパーリンク＝添付を合意してしまう。 これはまさに StubHub の失敗で、裁判所の理解は合意そのものにまでは及びませんでした。ガード: ハイパーリンク条項はすべて技術的なコミットメントとして扱い、提出フォーマットへの同意と同じ水準で、署名前にサンプル収集を実施してください。
• 送信された版が復元できると思い込む。 Purview も Vault も既定では現在のライブ版を返し、Purview の送信時点スナップショットは、保持ラベルを先回りして適用していた場合にしか存在しません。ガード: クラウド添付の保持ラベル付けは、収集時点の手順ではなく、ホールド即応体制の常設コントロールとして有効化してください。収集時点では、この問いはすでに決着しています。
• エラーのない収集レポートを、完全な収集だと読んでしまう。 50 リンクの上限、URL 2,048 文字での打ち切り、引用部分の除外は、いずれもエラーを出さずにリンクを落とします。ガード: 処理段階で 50 件を超えるリンクを含むメッセージにフラグを立てて手動レビューに回し、本文中のリンク数と実際に解決したリンク数を突き合わせてください。
• メールボックスはホールドしたが、ファイルはしていない。 カストディアンのメールボックスに対するホールドは、別の人物の OneDrive にあるリンク先ファイルを凍結しませんし、Purview のカストディアン帰属は、それが本当は誰のものだったかを教えてくれません。ガード: リーガルホールドの範囲を、カストディアンだけでなくファイルの保存場所にも広げ、対象チームが実際に共有元にしているサイトコレクションを保全してください。
• 秘匿特権のスクリーニングを一度も通っていないリンク先ファイルを提出してしまう。 リンク先ファイルは親が検索語にヒットしたという理由で取り込まれます。Purview のドキュメントによれば、ファイル自体はヒットしなかった場合や、コンプライアンス境界の外にある場合でも取り込まれます。ガード: リンク先ファイル群は、提出セットに合流する前に、独自の母集団として独自の検索語で秘匿特権レビューに通してください。

関連

• eDiscovery — 周辺プロセス、EDRM の各段階、Cerebras プロトコルの残りの部分
• リーガルホールドのプロセス — クラウド添付の保全を決めるべき場所
• 秘匿特権レビュー — リンク先ファイルが既定ですり抜けるフィルタ
• Microsoft Purview eDiscovery — Microsoft 365 テナント向けの収集側
• Relativity — 再構成されたファミリーがレビューのために着地する場所