社内のLLM（大規模言語モデル）活用やRAG（検索拡張生成）基盤の構築で、学習データやクロールデータの出所を正確に把握できているでしょうか。データ収集パイプラインの設計判断が、後から法的・技術的負債になるケースを整理します。
2025年9月17日、ニューヨーク・タイムズ（NYT）がOpenAIとMicrosoftを著作権侵害で訴えた裁判の、サマリージャッジメント（事実関係に実質的な争いがない場合に裁判を経ずに判断を求める手続き）申立書が公開されました。この申立書には、Microsoftの内部メモや幹部の証言が引用されています。設計判断の記録がどう扱われるかを考える材料として読み解きます。
何が起きたのか
訴訟自体は2023年12月に提起され、今年で3年目に入ります。NYTに加えてDaily NewsとCenter for Investigative Reportingも共同原告です。
公開された申立書には、Microsoftのアプライドサイエンス担当ディレクターBrent Hecht氏が2023年1月に書いた社内メモの一文が含まれています。AIによるスクレイピング（Webサイトからデータを自動収集する行為）を「人類史上最大の労働の窃盗」と表現した内容です。
さらに1年後の2024年1月、同氏はCopilotの「アンサーエンジン」機能が、nytimes.comへのクリックスルー率を最大93%減少させたとするスライドを社内で共有していました。申立書によれば、Satya Nadella CEOは「ペイウォール（有料会員限定の壁）の掛かったコンテンツはすべてライセンスされるべきだ」と証言した一方、Greg Brockman氏は「NYTのペイウォールを回避するハック」という部下のメッセージに「いいね」と返信していたとされています。
申立書は、OpenAIの中間学習（mid-training）データセットにNYT記事のコピーが91,692件以上含まれ、Common Crawl（Web全体をクロールして公開しているデータセット）由来のある学習セットには、nytimes.comのドキュメントが200万件以上含まれていたと主張しています。
これらの数字や引用はすべて原告側の申立書に記載されたものです。証拠exhibitは依然非公開のままで、文脈が省かれた「原告が選んだ引用」である点には注意が必要です。OpenAIとMicrosoftはコメントを出していません。
なぜこの問題が起きるのか
ここで技術者として押さえておきたいのは、法的な争点そのものより「なぜこの種のリスクが設計段階で見えにくいか」という構造です。原因は段階的に分解できます。
第一に、データ収集パイプラインとライセンス管理が別チームの責任になりがちです。クロールやデータセット構築を担当するエンジニアリングチームと、法務・コンプライアンスチームの間に情報の壁があると、「技術的に取得可能」と「法的に利用可能」が混同されます。
第二に、Common Crawlのような汎用クロールデータセットを下流で再利用する際、元データの出所（provenance）を追跡する仕組みが欠けているケースです。学習データの来歴管理（data lineage）が整備されていないと、どのドメインのどのページが、どのモデルのどのチェックポイントに影響したかを後から特定できません。
第三に、社内のSlackやメールのような非公式なコミュニケーションが、将来の訴訟で証拠として扱われるリスクへの認識不足です。技術的な意思決定の議事録やメモが、設計判断の根拠として残る一方、訴訟では文脈を欠いたまま引用される可能性があります。
自分のプロジェクトが該当するか確認する
自社のプロジェクトがこの種のリスクを抱えているかどうか、次の観点で確認できます。
- 学習・RAG用データセットの取得元リストを管理しているか（スプレッドシートやデータカタログの有無）
- 外部クロールデータ（Common Crawl、独自クローラー等）を使う場合、robots.txtやサイトの利用規約を機械的にチェックする工程があるか
- ペイウォール付きコンテンツや会員限定APIの回避目的のコードが、リポジトリ内に存在しないか
- データセットのバージョンと、それを使って学習したモデルのバージョンを紐付けるログが残っているか
具体的なコマンドで一次チェックもできます。たとえば自社のクローラーが特定ドメインをどの程度収集しているか、ログから集計します。
# クロールログから特定ドメインの取得件数を集計する例
grep "nytimes.com" crawl_access.log | wc -l
# robots.txt の取得可否をスクリプトで確認する例
curl -s https://example.com/robots.txt | grep -i "disallow"また、データセットのメタデータ管理にDVC（Data Version Control）やデータカタログツール（Amundsen、DataHub等）を導入しているかどうかも、来歴追跡の成熟度を判断する目安になります。設定ファイル（.dvcファイルやカタログのスキーマ定義）に出所情報のフィールドが存在するか確認してみてください。
対策の手順
技術的負債として積み上がる前に、次の手順で対応できます。
1. データソース台帳を作る。取得元URL、取得日、利用規約の確認状況、承認者を1レコードにまとめた台帳をデータセットごとに用意します。
2. データ来歴をパイプラインに組み込む。クロール・前処理・学習の各ステップでメタデータ（出所、ライセンス種別、取得日時）を付与し、モデルの学習ログと紐付けます。
3. 法務レビューのゲートを設計プロセスに組み込む。新しい外部データソースを追加する際、コードレビューと同様に法務確認をCI/CDのチェックリストに含める運用が考えられます。
4. 社内コミュニケーションのアーカイブポリシーを見直す。技術的な意思決定の記録は残しつつ、感情的・断定的な表現を含むやり取りが後から文脈なく切り出されるリスクを意識した運用ガイドラインを整えます。
5. ペイウォール回避やスクレイピング対策の迂回を目的としたコードが混入していないか、定期的にリポジトリを棚卸しします。
これらは一度やって終わりではなく、新しいデータソースを追加するたびに繰り返す運用として組み込むことが現実的です。
まとめ
NYT対OpenAIの申立書は、学習データの出所管理と社内記録の扱いが、技術的負債であると同時に法的リスクになり得ることを示しています。
確認すべきは、自社のデータ収集パイプラインに出所追跡の仕組みがあるか、外部データ利用の法務レビューがCI/CDのような開発フローに組み込まれているかの2点です。
証拠exhibitが非公開のままという点からも分かる通り、公開情報だけで最終判断をするのは危険です。まずは自社のデータソース台帳とクロールログを手元で棚卸しすることから始めてみてください。