AIにまつわるセキュリティあれこれ 17

AI時代の論文投稿に潜む「見えない情報漏えい」

第17回の今回は、arXiv投稿の88%に含まれていた「見えない情報」の調査結果をもとに、AI時代の公開物に求められる情報漏えい対策について解説します

小竹 泰一

6:20

はじめに

「arXiv」は、研究者が論文のプレプリント(査読を受ける前の原稿)を公開する場として広く使われています。機械学習、物理学、数学、コンピュータサイエンスなどの分野では、査読(同じ分野の研究者による事前評価)を受ける前の研究成果をarXivで共有する流れが定着しています。

今回紹介する論文でも、機械学習分野では、査読付き出版よりも先にプレプリントを公開する動きが広がっていると説明されています。

この流れは、生成AIの普及によってさらに目立つようになっています。大規模言語モデル、AIエージェント、マルチモーダルAI、AIセーフティ、AIセキュリティに関する研究では、arXivで先に成果を公開し、その後に査読付き会議やジャーナルへ進むケースがあります。

研究の公開速度が上がること自体は、知見の共有を早めます。一方で、投稿前に十分な確認を行わないまま、LaTeXソース、図表、補助ファイル、実験ログ、共有リンクが公開されるリスクも上がります。

LaTeXは論文や技術文書の執筆で使われる組版システムです。本文、図表、参考文献、数式などをソースファイルとして記述し、それをPDFに変換して使います。

arXivの特徴の1つは、PDFだけでなく、論文を生成するためのLaTeXソースファイルも公開される点です。これは、記法の再利用、研究の再現性、長期的な保守性といった観点では利点があります。

一方で、ソースファイルにはPDFには現れない情報が残ることがあります。今回紹介する論文「Hidden Secrets in the arXiv: Discovering, Analyzing, and Preventing Unintentional Information Disclosure in Source Files of Scientific Preprints」は、arXivで公開されている論文ソースに、どの程度の「見えない情報」が含まれているのかを大規模に調査した研究です。

論文が扱う「見えない情報」とは、PDF本文には表示されないものの、ソースファイルを取得すれば読めてしまう情報を指します。例えば、LaTeXコメント、不要なファイル、画像やPDFに埋め込まれたメタデータ(ファイル自体に付随する作成者、作成日時、使用ソフトなどの付帯情報)、APIキー、秘密鍵、内部文書へのリンクなどです。

AI分野では、実験コード、データセット、評価結果、プロンプト、モデル出力、クラウド環境の設定、外部サービスのAPIキーを扱う機会があります。論文の本文では公開していない情報でも、作業ディレクトリやコメント、共有リンクに残っていれば、第三者が取得できる状態になります。AI研究の公開が速くなるほど、公開前のファイル検査は研究倫理だけでなく、セキュリティ上の課題でもあります。

arXivのソース公開が生む情報漏えい

PDFに出ない情報は消えたわけではない

ここでいうソースファイルとは、最終的に読者が見るPDFを作るための元データです。PDFには表示されなくても、元データ側にコメントや不要ファイルが残ることがあります。

LaTeXで論文を書く場合、執筆中のメモや共著者間のやり取りをコメントとして残すことがあります。例えば、ある段落を一時的にコメントアウト(処理対象から外しつつ文書としては残すこと)したり、査読コメントへの対応方針をメモしたり、図表の差し替え予定を書いたりします。

PDFを生成すると、これらのコメントは通常表示されません。そのため、PDFだけを確認していると情報が消えたように見えます。しかし、arXivにLaTeXソースを提出し、そのソースが公開されると、コメントはそのまま読めます。

同じ問題はコメントに限りません。論文のPDF生成に不要なファイルがアーカイブに含まれていれば、それも公開対象になります。古い実験データ、バックアップファイル、過去の投稿先テンプレート、Gitリポジトリ、削除したつもりの一時ファイルなどが残る場合があります。

この問題は、GitHubに誤ってAPIキーや秘密鍵をコミットする問題と構造が似ています。ただし、今回の対象はソフトウェアリポジトリではなく、学術論文の投稿プロセスです。研究者はソースコード公開のリスクを意識していても、論文ソースに対して同じ警戒を向けていない場合があります。生成AIを使って論文や技術文書を書く場合、この問題はさらに見えにくくなります。AIに渡したプロンプト、AIから返ってきた草稿、採用しなかった表現、レビュー対応のメモが、コメントや下書きとして残ることがあるためです。PDFに出ていない情報でも、配布されるソースファイルに残っていれば公開情報になります。

調査対象は270万件のarXiv投稿

この研究では、1991年から2025年12月までにarXivへ投稿され、ソースファイルが取得できる270万件の論文を対象にしています。これはarXiv上の論文全体の93%に相当します。複数バージョンを持つ論文については、ソースファイル付きの430万バージョンも分析対象に含めています。

研究チームは、情報漏えいの経路を次の3つに分類しています。

  • PDF生成に不要なファイル
    • 論文PDFを作るために使われないファイル。古い実験データ、バックアップファイル、過去の投稿先テンプレート、Gitリポジトリなどが該当
  • ファイルに埋め込まれたメタデータ
    • 画像、PDF、XMLなどに含まれる作成ソフトウェア、ユーザー名、メールアドレス、撮影位置情報、作成日時など
  • ソース内の不要なテキスト
    • LaTeXコメント、コメントアウトされた文章、共著者間のメモ、ToDo、条件分岐で実際には使われないテキストなど

ファイル単位、メタデータ単位、テキスト単位で確認すれば、自社の公開物や研究資料にも同じ観点を適用できます。

88%の投稿に何らかの「見えない情報」が含まれていた

論文の主な結果は明確です。arXivのソースファイル付き投稿のうち、88%に少なくとも一種類の「見えない情報」が含まれていました。内訳を見ると、LaTeXコメントは95%の投稿に存在していました。そのうち、他の投稿ではほとんど見られないユニークなコメントは75%の投稿に含まれていました。これは、テンプレート由来の定型コメントではなく、著者自身が執筆中に追加した可能性が高いコメントを意味します。

不要なファイルは1200万件、メタデータのキーと値の組み合わせは1億4400万件、LaTeXコメントは6億4400万件見つかっています。研究チームは、このうちテンプレート由来と思われる反復的な情報を除外し、個別投稿に固有の情報を重点的に分析しています。この処理は妥当です。テンプレートに最初から入っているコメントと、著者が査読対応や実験上の制約を書いたコメントでは、情報漏えいとしての意味が異なります。前者はノイズに近く、後者は実際の執筆過程や内部事情を示す可能性があります。

AI研究の場合、ユニークなコメントや補助ファイルには、実験条件、評価結果、プロンプト、モデル出力、データセットの扱いに関するメモが残ることがあります。AI関連論文の投稿数が増え、公開までの速度が上がるほど、こうした情報が公開物に混ざる機会も増えます。

ソースファイルに残っていた情報

不要なファイルが投稿の履歴や内部資料を示す

不要なファイルの分析では、バックアップ用ディレクトリ、古いファイル、削除途中に残った一時ファイル、完全なGitリポジトリなどが見つかっています。

Gitリポジトリとは、ファイルの変更履歴を管理するための作業領域です。これが含まれていると、現在のファイルだけでなく、過去に削除した文章や変更内容まで読める場合があります。研究では、74件の投稿に完全なGitリポジトリが含まれていたと報告されています。

これは件数としては多くありませんが、影響は軽くありません。Git履歴には削除済みの文章、過去の共同作業の痕跡、投稿前の議論、場合によっては認証情報が残ることがあります。

論文には、投稿先テンプレートに関する分析もあります。例えば、最終的な掲載先とは異なる会議のテンプレートが不要ファイルとして残っている場合、過去の投稿先やリジェクト履歴を推測できることがあります。これは直接的な秘密情報ではありませんが、研究活動の履歴を外部からたどる材料になります。

AI分野では、論文と一緒にコード、設定ファイル、補助データ、評価ログを扱う場面があります。これらが同じ作業ディレクトリに置かれていると、投稿時に不要ファイルとして混入しやすくなります。例えば、APIキーを含む設定ファイル、クラウド環境の認証情報、評価用データへのリンク、プロンプトの下書きが残る可能性があります。

セキュリティの観点では、不要ファイルは単なる整理不足ではありません。公開対象を意図的に絞っていない状態です。論文PDFを公開するつもりが、作業ディレクトリ全体を公開している、という見方ができます。

メタデータは作業環境や位置情報を残す

ファイルメタデータの分析では、ユーザー名、メールアドレス、ソフトウェア情報、ハードウェア情報、GPS位置情報などが見つかっています。研究では、PDFに含まれない情報に限定しても、11%の投稿でユーザー名、2.9%でメールアドレス、1.4%で特定ハードウェア情報が漏れていたと報告されています。GPS位置情報については7326件の投稿で確認されています。

GPS情報は、画像ファイルに埋め込まれることがあります。研究室、勤め先企業、自宅周辺などが推測できる場合、個人の行動範囲を示す情報になります。論文本文とは無関係でも、公開ソースに含まれれば第三者が取得できます。

作成時刻や更新時刻も、単独では重大な情報に見えないかもしれません。しかし、投稿直前の作業時間帯、週末作業の傾向、長期にわたる執筆プロセスなどを推測できます。研究者個人の働き方や研究グループの運用が外部から見える形になります。

企業の公開資料でも同じことが起きます。ホワイトペーパー、技術ブログ用の図、PDF資料、講演スライドを公開するとき、作成者名や社内パス、編集ソフト、位置情報が残ることがあります。これは学術論文に固有の問題ではありません。

AI関連の資料では、スクリーンショットや図表の作成機会も増えます。モデルの出力例、評価画面、ダッシュボード、クラウドコンソール、データ分析画面を図として使う場合、画像ファイルやPDFに作業環境の情報が残ることがあります。本文では匿名化していても、メタデータや画像内の細部から情報が漏れる場合があります。

コメントには共著者間の会話やToDoが残る

LaTeXコメントの分析では、単なる整形用コメントだけでなく、共著者間の会話、未完了タスク、査読対応のメモ、代替表現、削除した本文案などが見つかっています。研究チームは、ローカル環境で動かした大規模言語モデル「Qwen2.5-72Bcode>」を使い、コメントを分類しています。

分類カテゴリには、整形、学術本文、共著者間の会話、LaTeXマークアップ、ToDo、参考文献関連のメモが含まれています。クラウドAPIではなくローカルLLMを使った点は、分析対象に機微情報が含まれる可能性を考えると自然な判断です。

分類結果では、学術本文に関するコメントが44%、LaTeXマークアップ関連が30%、共著者間の会話が7.9%、ToDoが0.98%とされています。割合だけを見るとToDoは少なく見えますが、44%の投稿にToDoコメントが存在していました。

ToDoには、実験上の制約、手法の弱点、本文では説明されていない懸念が含まれる場合があります。すべてが機微情報ではありませんが、著者が公開するつもりではなかった情報である可能性はあります。セキュリティ実務に置き換えると、これはソースコード中のコメントに「この検証は未完了」「この入力値チェックは後で直す」「この仕様は暫定」と残したまま公開する状況に近いです。PDFに表示されないから安全、という判断は成立しません。

生成AIを使った執筆では、コメントの性質も変わります。人間同士のメモだけでなく、AIに渡す指示、AIから得た文案、採用しなかった生成結果、レビュー対応用の下書きがコメントとして残る可能性があります。これらは、研究の執筆過程や評価過程を外部に見せる情報になります。 

APIキー、秘密鍵、パスワードも見つかっている

この論文で扱われている情報の中には、明確にセキュリティ上の影響を持つものもあります。

研究チームは、APIトークン、秘密鍵、パスワードなどを正規表現とエントロピーによるフィルタリングで抽出し、手動で検証しています。その結果、128件の投稿から265個のAPIトークン、4件の投稿から4個の秘密鍵、82件の投稿から171個の汎用的なパスワードが確認されています。

件数だけを見れば、270万件の投稿に対して比率は低いです。しかし、認証情報の漏えいは1件でも影響を持ちます。APIキーが有効であれば、クラウドリソース、外部サービス、研究用データ、CI環境などにアクセスされる可能性があります。

論文では、Google Docs、Google Drive、Dropbox、Overleafなどへのリンクも取り上げています。Google Docsについては、閲覧可能なリンクが1119件、編集可能なリンクが699件見つかっています。手動分析では、少なくとも200件で機微な内容が露出していたとされています。中には、査読コメント、カバーレター、リバッタル、議事録、Zoom録画へのリンク、学生課題、勤務表、注文リスト、調査参加者のデータなどが含まれていました。

ここで問題になるのは、リンクそのものだけではありません。リンク先のアクセス制御が弱い場合、ソースファイルに残ったURLが外部からの入口になります。URLが「知っている人だけがアクセスできる」状態になっている場合でも、arXivのソース公開によって、その前提は崩れます。

AI研究では、外部APIやクラウドサービスを使う機会があります。商用LLM API、評価用API、データ保存用のクラウドストレージ、実験管理ツール、アノテーション基盤などです。これらの認証情報や共有リンクが作業ファイルに残ったまま公開されると、研究データや実験環境にアクセスされるおそれがあります。

ネットワーク接続先や共有リンクも漏れていた

認証情報だけでなく、ネットワーク資産につながる情報も確認されています。

研究チームは、ソースファイル中のURLやIPアドレスを抽出し、1億2700万件のユニークURLと4万1000件のIPアドレスを確認しています。その中には、FTPサーバへの参照が2万9000件の投稿に含まれており、調査時点で28%が稼働中、23%が読み取り可能でした。SSH接続文字列も349件の投稿で見つかっています。

FTPSSHの参照は、ただちに侵害を意味するわけではありません。しかし、研究室や組織のインフラ、ファイル共有の運用、古い公開サーバの存在を示す情報になります。FTPサーバが読み取り可能な状態で残っている場合、論文ソース内のURLが、意図しないデータ公開の入口になります。

企業の技術記事でも同じ問題は起きます。検証用サーバ、S3バケット、社内向けダッシュボード、CI/CDのURL、開発用SSH接続先が、サンプルコードや設定ファイルに残ることがあります。認証情報だけでなく、接続先情報そのものも公開前レビューの対象にすべきです。

AI研究の場合、実験環境や評価環境はクラウドに置かれることがあります。モデル評価のダッシュボード、データセット置き場、アノテーション環境、CIのログ、実験結果の共有フォルダがURLとして残ると、公開論文のソースから研究インフラの一部がたどれる状態になります。 

AI時代に広がる論文投稿リスク

AI研究では公開対象が広がりやすい

AI研究では、論文本文だけでなく、実験に使ったコード、設定ファイル、評価データ、プロンプト、モデル出力、補助資料を扱う場面があります。再現性を高めるために、ソースコードやデータへのリンクを示すこともあります。この姿勢は研究の検証可能性を支えますが、公開して良い情報と作業用の情報が同じ場所に混ざりやすくなります。

今回の論文でも、Google Docs、Google Drive、Dropbox、Overleafなどへのリンクがソース中に残っていた例が報告されています。AI研究の場合、この種のリンク先には未公開の実験結果、評価用データ、プロンプト、モデル出力、アノテーション結果、共同研究者との議論が含まれる可能性があります。

人間の被験者を含む研究であれば、調査参加者の情報や同意管理に関わる資料が混ざることもあります。論文では、調査参加者のデータにアクセスできたケースも18件確認されています。

AIを使った研究執筆では、別の問題もあります。生成AIに渡した指示、生成AIから返ってきた文案、レビュー対応用の草稿がコメントとして残ることがあります。これらは、単に文章作成にAIを使ったかどうかという話ではありません。公開物の中に、著者が見せるつもりのなかった執筆過程、評価過程、プロンプト、外部サービスの利用実態が残る点が問題です。

AI研究では、研究の速度と公開範囲が広がる分、ソースファイルや補助ファイルの確認が追いつかない状況が起きやすくなります。

コメントに残ったプロンプトインジェクションの痕跡

プロンプトインジェクションとは、LLMに対して本来の指示とは別の指示を読み込ませ、出力や判断に影響を与えようとする手法です。

AIとの関係で見逃せないのが、コメント中に残ったLLM向けの指示です。研究チームは、コメントアウトされた箇所に、プロンプトインジェクションに似た指示が含まれていないかを調べています。その結果、手動確認により、9件の投稿でそのような指示が確認されています。

この点は、AI時代の論文投稿リスクとして扱う価値があります。生成AIを使って査読対応や本文作成を行う場合、AIへの指示、採用しなかった生成文、査読者や評価者に向けた隠れた指示が、LaTeXコメントとして残る可能性があります。

問題は、AIを使ったかどうかではありません。公開されるソースファイルに、読者や査読者に見せるつもりのなかった指示や作業過程が残ることです。今後、査読支援や論文検索にLLMが組み込まれるほど、この種の隠れた指示は、情報漏えいだけでなくレビューや評価プロセスへの干渉としても扱う必要があります。

論文では、「As an AI language model」のようなLLM応答の痕跡に一致するコメントアウト済み断片も確認されています。これは、生成AIの出力が執筆過程に入り込み、その痕跡が公開ソースに残る可能性を示しています。

セキュリティ分野の論文ほど「見えない情報」が多かった

この論文で実務上興味深いのは、セキュリティ分野の論文にも同じ問題が起きていた点です。研究チームは、コンピュータサイエンス分野、暗号・セキュリティ分野、さらにA*、A、B、Cランクのセキュリティ会議に採択された論文を比較しています。ここでいうA*やAは、学術会議の評価ランクを指します。A*は上位の国際会議を示す分類として使われています。

その結果、コンピュータサイエンス分野の論文は他分野よりも「見えない情報」が多く、暗号・セキュリティ分野ではさらに多い傾向が確認されています。加えて、A*ランクのセキュリティ会議に関連する論文は、Aランクの論文よりも「見えない情報」が多いという結果でした。

論文では、これらの比較について統計的に有意な差があると説明されています。これは皮肉な結果です。セキュリティ研究者は、情報漏えい、認証情報の管理、公開範囲の制御といったリスクを理解しているはずです。それでも、論文ソースという公開物では、不要ファイル、コメント、メタデータが残っています。

この結果は「知識がある人でも、公開プロセスに検査が組み込まれていなければ漏えいは起きる」という実務上の教訓になります。人間の注意力や専門性だけに依存する運用では、公開対象に含まれるファイル全体を毎回正確に確認するのは難しいということです。

セキュリティエンジニアの視点では、この発見は記事全体の中心に置いてよいものです。問題は「研究者がうっかりした」という個別事例ではありません。セキュリティを専門にするコミュニティでも、作業ディレクトリ、ソースファイル、メタデータ、共有リンクを一体として検査する仕組みがなければ、公開物から情報が漏れます。

既存対策の限界

既存のクリーニングツールは十分ではなかった

arXiv向けのLaTeXソースを整理するツールは以前から存在します。Googleのarxiv_latex_cleanerなどが代表例です。しかし、論文では既存ツールが不要ファイル、メタデータ、コメントを網羅的には削除できないことを示しています。

理由の1つは、正規表現ベースの処理に限界があるためです。LaTeXは単純なテキスト形式に見えますが、コメント、条件分岐、マクロ、環境、外部ファイル参照などが絡みます。単純な文字列処理では、必要な内容を誤って消したり、不要な内容を残したりします。

論文では、censorpdfprivacyのような検閲・プライバシー保護を目的としたLaTeXパッケージを使っていた投稿も取り上げています。研究チームは、そのようなパッケージを使いながら、結果として十分な削除に失敗していた投稿を269件確認しています。この発見は、実務上わかりやすい教訓を含んでいます。

著者は隠す意図を持っていたにもかかわらず、配布されるソースファイル側には情報が残っていました。つまり、PDF上で見えなくする処理と配布物から情報を削除する処理は別物です。これは、技術ブログやホワイトペーパーでも起きます。

画像に黒塗りを重ねただけで元データが残る、PDF上では見えないコメントがメタデータに残る、Git履歴に削除済みの情報が残る、といった問題と同じです。公開前レビューでは、「画面上で見えないか」ではなく、「配布ファイルから取得できないか」を確認する必要があります。

研究チームは、対策として「ALC-NG」というツールを提案しています。ALC-NGは、PDF生成時に実際に使われたファイルを確認し、不要なファイルを除外します。そのためにpdflatexrecorder機能を使います。メタデータの削除にはexiftoolを使い、LaTeXコメントなどの検出にはtree-sitterベースの構文解析を使います。

この設計は実務的にも納得できます。ビルド時に実際に読まれたファイルを確認すれば、PDF生成に必要なファイルを判断しやすくなります。メタデータはファイル形式ごとの差があるため、既存の専用ツールを使う方が堅実です。LaTeXコメントは構文として扱うことで、正規表現よりも誤検知と見逃しを減らせます。

AI時代の公開フローでも、同じ考え方が使えます。公開物を人手で見直すだけでは、プロンプト、モデル出力、検証用ログ、共有リンク、認証情報を毎回見つけるのは難しくなります。公開用アーカイブを機械的に生成し、その過程で不要ファイル、メタデータ、認証情報、共有リンクを検査する方が安定します。

新しい投稿システムでも問題は解消していない

論文では、arXivが2025年4月に導入した新しい投稿システムについても触れています。研究チームは、PDFなどに記録される作成ツール情報であるProducerメタデータから、この新しい投稿システムの利用状況を追跡しています。新しい投稿システムでは、投稿者に対して、ルートディレクトリ直下の不要ファイルを削除するよう促す変更が入っています。

一方で、サブディレクトリ内の不要ファイルはこの対象に含まれていません。論文では、2025年の月別推移を確認しても、新しい投稿システムへの切り替えによる大きな変化は見られなかったと説明されています。

この結果は、投稿システム側の注意喚起だけでは不十分であることを示しています。ルート直下のファイルだけを確認しても、作業用ディレクトリ、画像フォルダ、実験結果フォルダ、補助資料フォルダに残った不要ファイルは見逃されます。

AI研究では、評価ログ、プロンプト、モデル出力、設定ファイル、データ処理スクリプトがサブディレクトリに置かれることもあります。そのため、ルートレベルだけの確認では、公開物全体のリスクを下げきれません。実務上の対策としては、投稿画面で警告を出すだけでなく、公開用アーカイブを生成する段階で、PDF生成に必要なファイルだけを抽出する仕組みが必要です。

論文が提案するALC-NGのように、実際のビルドで使われたファイルを基準に不要ファイルを除外し、メタデータやコメントもあわせて処理する方が、公開範囲を制御しやすくなります。

一度公開した情報は消しにくい

この研究で見落としてはいけない点は、古いバージョンの扱いです。arXivでは、論文の新しいバージョンを投稿しても、過去バージョンのソースは残ります。つまり、後から不要ファイルやコメントを削除した版を投稿しても、過去に公開されたソースを完全に取り消せるわけではありません。

論文でも、古いバージョンに含まれていたOpenIDトークンが後のバージョンで削除された例に触れています。しかし、古いソースがアクセス可能であれば、削除は根本的な対策になりません。

これはインシデント対応でもよくある問題です。漏えいした認証情報は「削除」ではなく「無効化」が必要です。APIキー、パスワード、共有リンク、OAuthトークン、SSH鍵などが公開された場合、公開ファイルを消すだけでは不十分です。権限の取り消し、鍵のローテーション、リンク先のアクセス制御変更が必要になります。

AI関連の研究や技術記事では、この問題が現実的な影響を持ちます。LLM APIのキー、クラウドストレージの共有URL、実験用ダッシュボード、評価データへのリンクが一度公開されると、後から記事や論文を修正しても、第三者が取得済みである可能性は残ります。公開後の修正を前提にするのではなく、公開前に検査する運用が必要です。

著者への通知から見えた認識の差

研究チームは、発見した問題について責任ある開示も行っています。まずarXivを通じた通知を試みましたが、著者の身元保護や運用上の制約から、最終的には研究チームが影響を受ける論文の著者へ直接連絡しています。

2025年11月4日から11月11日にかけて、1141本の影響を受ける論文について、合計2,660名の著者に通知しました。通知にはアンケートも添付され、112件の完全回答が得られています。回答率は5.3%でした。論文では、回答者のうち、開示前からarXivのソースファイル公開によるリスクを認識していたのは41%にとどまったと説明されています。

この結果は、公開ソースのリスクが十分に共有されていないことを示しています。arXivにLaTeXソースが公開されること自体は知られていても、そこにコメント、メタデータ、不要ファイル、共有リンク、認証情報が残るリスクまで認識している著者は限られていました。

企業でも同じ構造があります。公開資料を作成する担当者は本文や表示結果を確認しますが、配布ファイルに含まれるメタデータ、コメント、履歴、不要ファイルまで意識しているとは限りません。公開前の検査を個人の知識に依存させず、組織の手順として組み込む必要があります。

実務でどう受け止めるべきか

AI時代の公開物レビューとして考える

この論文はarXivを対象にしていますが、示している問題は研究者だけに閉じません。企業の技術ブログ、ホワイトペーパー、営業資料、脆弱性診断レポート、講演資料、GitHubリポジトリ、サンプルコード公開でも同じ構造の情報漏えいが起きます。

生成AIの利用が広がると、公開物の作成過程には、これまでより中間生成物が増えます。AIに渡したプロンプト、AIが出力した草稿、レビュー用のコメント、実験ログ、評価結果、採用しなかった文案、社内確認用のメモなどです。これらは本文には出なくても、ソースファイル、コメント、履歴、共有リンク、添付ファイルに残る場合があります。

AI関連の記事や研究では、検証用のAPIキー、サンプルデータ、モデル出力、評価スクリプト、プロンプトテンプレートを扱うことがあります。公開用のサンプルと社内検証用のファイルが同じディレクトリに置かれていると、公開時に不要な情報を同梱するリスクがあります。

セキュリティベンダやIT企業の場合、公開物の信頼性も影響を受けます。技術ブログのサンプルコードに不要な認証情報が残っていたり、PDFのメタデータに社内ユーザー名や作業パスが残っていたりすると、読者は記事本文とは別のところで不安を持ちます。

公開前レビューでは、本文の正確性、表現、SEOだけでなく、成果物に含まれるファイル単位の確認も必要です。AIを使って作成した資料では、AIとのやり取りや中間生成物が公開対象に混ざっていないかも確認すべきです。これは編集工程というより、公開前のセキュリティチェックです。

PDFやWebページの表示結果だけを見るレビューでは、今回のような問題を見落とします。表示される情報と配布される情報は一致しません。公開前チェックでは、閲覧者が実際に取得できるファイル一式を対象にする必要があります。

この問題は、研究者個人の不注意というよりも、公開プロセス側の設計不足として扱う方が現実的です。セキュリティ研究者やAI研究者でも、コメント、不要ファイル、メタデータ、共有リンク、認証情報を毎回手作業で取り除くのは難しいためです。AIの利用を禁止するよりも、AIを使う前提で公開前検査を整える方が現実に合っています。 

公開前に確認すべき項目

企業や研究機関が同種の問題を避けるには、公開前に複数の観点から確認する必要があります。

まず、公開対象に不要なファイルが含まれていないかを確認します。圧縮ファイルをそのまま提出する場合、作業ディレクトリ全体を入れていないか、古いファイルやバックアップが残っていないかを見る必要があります。

次に、画像、PDF、Office文書、CSV、JSON、ログ、設定ファイルのメタデータを確認します。Exif情報、作成者名、社内パス、作成ソフト、位置情報、更新履歴が残る場合があります。

そのうえで、コメントやコメントアウトされた本文を確認します。LaTeX、Markdown、HTML、JavaScript、Python、設定ファイルには、公開対象ではないメモが残りがちです。認証情報の検出も行うべきです。APIキー、秘密鍵、アクセストークン、パスワード、Webhook URL、内部URL、クラウドストレージの共有リンクは、文字列スキャンの対象にできます。

AIを使った執筆や検証では、プロンプト、モデル出力、評価ログ、検証用データ、アノテーション結果も確認対象になります。公開して良いサンプルと、社内検証用の情報を分けて管理する必要があります。

最後に、リンク先のアクセス制御を確認します。公開ファイル内のURLが、閲覧制限のない文書や編集可能な文書を指していないかを確認します。リンクが残る場合は、公開して良い情報かどうかを判断します。これらの確認は、人手に頼るだけでは安定しません。CMSやCI/CD、社内公開フローに機械的な検査を組み込む方が効果があります。

公開用アーカイブを生成する処理を自動化し、不要ファイルを除外し、メタデータを削除し、secret scanning、つまりAPIキーや秘密鍵などの認証情報を自動検出する処理を実行し、共有リンクを検査する流れを置けば、レビュー担当者は結果を確認する形で関われます。

おわりに

arXivのLaTeXソース公開は、オープンサイエンスを支える仕組みの一部です。一方で、ソースファイルを公開する以上、PDFには出ない情報も公開対象になります。

今回の論文は、270万件のarXiv投稿を対象に、不要ファイル、メタデータ、コメントという3つの観点から情報漏えいを調査しました。その結果、88%の投稿に何らかの「見えない情報」が含まれていることが示されました。中には、APIトークン、秘密鍵、パスワード、編集可能なオンライン文書、調査参加者の個人情報、Git履歴、FTPサーバやSSH接続先の情報も含まれていました。

この論文の価値は、「arXivには危ないファイルが残っている」という個別事象を示したことにとどまりません。公開前の成果物に対して、ソース、メタデータ、不要ファイルを含めて検査する必要性を、実データで示した点にあります。

論文の発見の中で、セキュリティ実務の観点から見逃せないのは、トップティアのセキュリティ会議に関連する論文ほど「見えない情報」が多かった点です。知識や経験があっても、公開フローに検査が組み込まれていなければ情報は残ります。arXivの新しい投稿システムでも、少なくとも論文の分析時点では全体傾向に大きな変化は出ていません。

AI分野では、研究の公開速度が上がり、論文ソース、実験コード、評価データ、プロンプト、モデル出力、共有リンクを扱う機会が増えています。公開物の範囲が広がれば、意図しない情報が混ざる余地も広がります。

この問題は、学術論文だけでなく、企業の技術発信にも関係します。公開するファイルには本文以外の情報が含まれます。公開前のレビューでは、読者に見える内容だけでなく、読者が取得できるファイル全体を確認する必要があります。

ソース、メタデータ、不要ファイル、共有リンクを確認する。AIを使った執筆や検証を行う場合は、プロンプト、モデル出力、評価ログ、検証用の認証情報が残っていないかも確認する。必要であれば、公開用ファイルを自動生成し、人手で作った作業ディレクトリをそのまま公開しない。

AIによって研究や技術発信の速度は上がります。その分、公開前の確認を人間の注意だけに任せる運用は破綻しやすくなります。完成物の見た目だけを確認するのではなく、配布物そのものを検査する。今回の研究は、その工程を研究機関や企業の発信フローに組み込むための根拠になります。

この記事のキーワード

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored