Overleaf、LaTeX、Turnitin：コンパイル済みPDFが変えてしまうもの

TurnitinはPDFを受け付けますが、それは同社非公開の抽出ツールが何を見ているかを教えてくれるわけではありません。再現可能な私たちの検証では、同じ2段組pdfTeXファイルからmutoolとPyMuPDFはそれぞれ694語（空白区切り）を返し、pypdfは692語を返しました。テキストストリームを形作ったのはコンパイルと抽出の両方です。ここまでは測定できることです。Turnitinの入力やスコアに影響があるかどうかは、測定できていません。

この線引きが記事全体の主題です。ソース、3つのPDF、9本の生の抽出ストリーム、測定スクリプトは証拠パッケージとともに保管されています。終盤にある5分のチェックこそ、自分の論文で実行すべきものです。

`.tex`ファイルは1つだけ。標準クラスの`article`、`twocolumn`、10ptです。中身は要旨、番号付きの4つのセクション、本文中と別行立ての数式、`itemize`リスト、番号付きの疑似コード行を持つ`algorithm`環境、`table`フロート、文として書かれたキャプション付きの`figure`フロート、折り返すだけの長さのある脚注1つ、そして番号付き参考文献として解決される`\cite`の呼び出し2つです。2段組のビルドは2ページ、1段組の対照版は3ページになります。

コンパイルにはpdfTeX 3.141592653-2.6-1.40.26、TeX Live 2024を使用。読み取りには3つの独立した抽出ツール、mutool 1.25.6、PyMuPDF 1.26.0、pypdf 6.4.0を使いました。

空白の連続を1つにまとめると、mutoolとPyMuPDFは2段組pdfTeXのPDFからそれぞれ694語を返し、pypdfは692語を返しました。3つのストリームはセクションの大まかな順序を保っていますが、この2語の差は「独立した抽出ツールは同一のオブジェクトを見ている」という都合のよい主張を退けるのに十分です。

2段組PDFを提出するときに最もよく聞く警告は、抽出ツールが2つの段をまっすぐ横切り、論文を入り乱れた支離滅裂な文章にしてしまうというものです。今回それは起きませんでした。1段目の末尾にある要旨の最後の文は、2段目の冒頭にあるIntroductionの最初の文の直前に置かれます。順序は文書全体を通じて保たれています。

レイアウトは1つ、クラスは1つ、抽出ツールは3つ、マシンは1台。主張の範囲はその程度です。フロートの配置が特殊だったりサイドバーがあったりする投稿先独自の`.cls`なら、挙動が変わるかもしれません。だからこそ、この記事の最後にあるチェックは、私たちのファイルではなく実際のあなたのファイルに5分かけて試す価値があります。

代わりに壊れたのは別のもので、こちらはずっと話題にされません。

以下はPyMuPDFのストリームからの逐語的な抜粋です。空白は正規化してありますが、引用した両端の間にあるものは何も削除していません。

"…justification for treating a visually correct page as a reliable 1This footnote is deliberately long enough to wrap onto a second line so that its position in the extracted stream can be observed and compared with nearby prose. 1 Table 1: Primary outcome by condition. Condition Mean SD Control 12.4 3.1 Intervention 18.9 2.7 Figure 1: The framed area is a fixture rather than a reported empirical result. text stream…" （…見た目が正しいページを信頼できる1この脚注は、抽出されたストリームの中での位置を観察し、近くの散文と比較できるように、意図的に2行目に折り返す長さにしてあります。1 表1: 条件別の主要アウトカム。条件 平均 SD 対照 12.4 3.1 介入 18.9 2.7 図1: 枠で囲んだ部分は報告された実証結果ではなく、検証用の仕掛けです。テキストストリーム…）

ソースでは`reliable text stream`はひと続きのフレーズです。この抽出では、脚注、むき出しのページ番号、表のキャプションとそのセル、図のキャプションがすべて`reliable`と`text stream`の間に割り込んできます。別の箇所では、脚注マーカーが前の句読点にくっついて`follows:1`のようになってもいます。

この引用に出てくるむき出しの`1`はページ番号です。ページごとのストリームをつなげると、それは脚注と表の間に置かれます。どちらの箇所の一部だと読者が感じることはありませんが。

これらはどれもPDF上の目に見える破損ではありません。名前を挙げているこのローカルな抽出ツールが返した結果であり、「前の文」と「後の文」が、抽出方法が判明するまで安定した概念にならない理由を示しています。

LaTeXは行末で単語をハイフン分割します。段が狭いほどその機会は増えます。私たちの2段組pdfTeXビルドで、PyMuPDFは22個の分割トークンを検出しました。そのうち6つが次です。

例：ex- poses · differ- ences · specifica- tions · observa- tions · justifica- tion · partici- pants

次に、同じソースを1段組でコンパイルし、クラスオプションだけを変更しました。PyMuPDFが返したのは正規化して678語、分割トークンは22ではなく5つでした。`or- dinary`、`extrac- tion`、`jus- tification`、`partici- pants`、`par- ticular`。

同じソース、レイアウトの切り替え1つで、分割の場所は別のものになります。これはあくまで1つの検証例であり、あらゆるクラスファイルに当てはまる規則ではありません。ただ、ソースのトークン分割がそのまま残っていると決めつけず、コンパイル後のファイルを確認した方がよいと示すには十分です。

同じソースをXeLaTeXで3回目のコンパイルをしました。2段組のレイアウトも、ページ上の語も同じです。

pdfLaTeXビルドでは、3つのツールはいずれも合字の符号位置`ff`、`fi`、`fl`、`ffi` or `ffl`を含むトークンを1つも出しませんでした. In the XeLaTeX build, PyMuPDF and pypdf each exposed six: `affiliated`、`affiliation`、`difficult`、`efficiency`、`insufficient`、`office`（XeLaTeXビルドでは、PyMuPDFとpypdfがそれぞれ6つを露出させました）。Mutoolがゼロだったのは、これらのグリフを通常の文字に正規化して戻したためです。そのため、`efficiency`を素朴に検索すると、一方のストリームではヒットし、もう一方では見逃します。

数式は逆方向に変わりました。pdfTeXのファイルでは、mutoolは総和記号に対してUnicodeの置換文字を返し、PyMuPDFとpypdfは大文字の`X`を返しました. In the XeLaTeX file, all three exposed the actual `∑`（XeLaTeXのファイルでは、3つすべてが実際の記号を露出させました）。コンパイラも抽出ツールも影響していたということです。

ここで引用したTurnitinのページには、抽出ツールの特定もこれらの変換の記述もなく、私たちもこれらがスコアを動かすと言っているわけではありません。私たちが言っているのはもっと狭く、検証可能なことです。テキスト層はコンパイルの産物であり、抽出ツールが違えば同じPDFから異なる文字が現れうるということです。

提供元自身のドキュメントのうち4つの記述は、この形の論文に直接関わります。該当ページにはほかにも記述がありますが、LaTeXでの提出に関わるのはこの4つです。

形式は受け付けられます。AI Writing Reportに関するTurnitinのファイル要件には`.docx, .pdf, .txt, .rtf`が挙げられています。これはPDFが処理されうることを示すだけで、どの抽出経路が使われるかについては何も語りません。TurnitinはPDF内のAIを検出できるのかでは、この疑問のうち文書化されている部分をたどっています。

散文だけが対象です。FAQは、分析対象となるテキストを次のように定義しています。

「This qualifying text includes only prose sentences, meaning that we only analyze blocks of text that are written in standard grammatical sentences and do not include other types of writing such as lists, bullet points (short non-sentence structures), or other non-sentence structures.」（この対象テキストに含まれるのは散文の文だけです。つまり、標準的な文法的な文で書かれたテキストブロックのみを分析対象とし、箇条書きやビュレット（文になっていない短い構造）など、文以外の書き方は含みません。）

次に続く文こそ覚えておく価値があります。「This percentage is not necessarily the percentage of the entire submission.」（この割合は、必ずしも提出物全体に対する割合ではありません。）`itemize`の箇条書きも`algorithm`の行も文ではありません。表のセル1行も同様です。Turnitinが数式や非散文の内容をどう扱うかでは、数式中心の論文にとってこれが何を意味するかを扱っています。ただ、何が対象になるかにも注意してください。`\caption`で完全な文として書かれたキャプションは、多くの人がキャプションをそう書くように、本文の散文とまったく同じ姿でストリームに現れます。

参考文献は除外されます。2023年8月9日付のリリースノートには、参考文献内のAI作成文が強調表示されるバグが修正されたこと、および「Bibliographies are now excluded when processing the AI writing report」（AI作成レポートの処理時に参考文献は除外されるようになりました）が記されており、同じノートは、既存の提出物には適用前に再提出が必要だと付け加えています。提供元が公開していないのは、平坦化されたテキストストリームの中で参考文献をどう見分けているかです。私たちの抽出でも手がかりはありません。`References`は普通の単語として現れ、その後に`[1] J. Smith, "A study of things," Journal of Testing, vol. 4, no. 2, pp. 100–110, 2019.`が続くだけで、境界を示すものは何もないのです。どちらの読み方にも依存した計画を立てないでください。参考文献の除外が実際にカバーする範囲では、何が文書化されていて何がそうでないかを整理しています。

短い論文は振る舞いが違います。数百語程度まで少なくなると、提供元自身の表現では、予測は「mostly 'all or nothing' because we're predicting on a single segment without the opportunity to overlap」（重ね合わせの機会なしに単一のセグメントに対して予測しているため、予測はほぼ「all or nothing（全か無か）」になります）になるとされ、続く文は、そこでは混在した内容が全面的にAI生成として判定されうると付け加えています。半分が数式の6ページの会議論文には、対象となるテキストがあまり含まれていない可能性があります。短い文書とall-or-nothing問題にその仕組みがあります。

`\cite{smith2019,jones2020}`は抽出結果では4文字の`[1, 2]`になっていました。`\ref{sec:method}`は`2`に、`\label`は跡形もなく消えていました。セクション見出しは番号とタイトルが分離して現れるため、`2 Method`は直前の文のすぐ後ろに置かれ、前方参照だった`Section 2 describes the method.`は、数字が紛れ込んだ散文として読める状態になります。

つまり、引用の書式に基づく計画はすべて、そこにないものを相手にしていることになります。抽出されたテキストに引用オブジェクトは存在せず、あるのは括弧と数字だけです。Turnitinが公開している算出方法の説明でも、どの段階にも引用は登場しません。なぜTurnitinは私の参考文献を判定したのかでは、そこから導かれる具体的な修正と、それぞれが実際には何も作用対象を持たない理由を挙げています。

私たちが使ったツールは必要ありません。コンパイル済みPDFを手元のビューアで開き、すべてを選択してプレーンテキストエディタに貼り付けてください。それもまた1つの抽出経路であり、Turnitinの代わりにはなりませんが、実際に提出するテキスト層の問題を可視化してくれます。

次の順に確認してください。

1. 分割された単語。 ハイフンの直後に行末がある箇所を検索してください。ヒットしたものはすべて、1つの単語であることをやめた単語です。
2. フロートの着地位置。 表のキャプションを見つけ、その前後2文を読んでください。キャプションとセルが段落の中に落ちていれば、それがその段落の読み取り順序になります。
3. キャプション。 完全な文として書かれたキャプションは散文に見えます。実際に散文だからです。
4. 数式。 貼り付けたテキストの中で、別行立ての数式を1つ読んでください。そこに見えているものが、抽出ツールが取得したものです。文字が欠けていたり違っていたりするなら、それはあなたの代数ではなくフォントの埋め込みについての事実です。
5. 参考文献の始まり。 プレーンテキストの中に、参考文献リストの始まりを示すものがあるかを見てください。私たちの場合、何も示していませんでした。
6. 氏名と所属。 これらもテキスト層に含まれます。匿名性が求められる場所に提出するなら、この点は重要です。

`.tex`をGitやOverleafで管理しているなら、最後に一度ではなく、大きな修正ごとに一度これを行ってください。なお、Overleafの執筆履歴が記録として価値を持つかという別の問題については、Word、Google Docs、Overleafのバージョン履歴がどこにあるかに、無料プランの保存ルールとその対処法が書かれています。その内容は多くの人が思っているより具体的です。

LaTeXの論文での答えは退屈ですが正しいものです。ソースを変更し、再コンパイルし、PDFは決して編集しない。文は`.tex`ファイルの中にあります。ほかのすべてはそのレンダリングにすぎません。

この流れが扱いにくくなるのは、終着点がPDF以外になる場合です。指導教員が変更履歴を求めるかもしれませんし、投稿先がWord原稿を要求するかもしれません。あるいは、コンパイル済みPDFに基づくAI作成レポートを送り返してきて、どの箇所が変わるのかと聞かれることもあります。同じ論文が2つの形式で存在することになるのです。

英語のDOCX版なら、HumanPenというツールは、書き換えを自分で選んだ箇所、あるいはTurnitinやiThenticateのレポートと一致した箇所に限定できます。Humanizeは現在英語のみ対応で、編集可能なソースとして`.tex`やコンパイル済みPDFを受け取ることはできません。段落単位の範囲を確認し、LaTeXソースをマスターとして保持し、ダウンロード後に変換済み文書を再確認してください。条件を満たす箇所は、無料で再実行できます。

PDFではなく`.tex`ファイルを提出すべき？ 課題や投稿先が求めるものを提出してください。`.tex`ファイルはマークアップ入りのプレーンテキストであり、中のコマンドはすべて文字どおりの文字として届きます。つまり、人であれ機械であれ、どんな読み手にとっても、それがより整った版ということにはなりません。

数式によってAIスコアは上がるのか？ 数式は散文の文ではないため、提供元自身の定義では対象テキストの外になります。その周りの説明文は対象内です。数式中心の論文では、その数値はページのごく一部だけを対象に算出されることになります。

2段組という形式自体が問題を起こすのか？ この検証では、セクションの大まかな順序は保たれました。PyMuPDFでは、2段組ビルドに行末の分割が22、1段組ビルドには5がありました。これはこのクラスファイルについての実測値であり、あらゆるジャーナルテンプレートに当てはまる規則ではありません。

所属機関はWordファイルを求めているが、自分はLaTeXで書いている。 その場合、変換という工程が入ります。そして番号付け、相互参照、引用フィールドが壊れやすいのはまさにその工程です。変換は遅い段階で一度だけ行い、最初の2ページを読むのではなく、オブジェクトの種類を確認してください。

Overleafの履歴を、論文の書き方の証明に使えるか？ それは記録であって判定ではありません。無料プランでは、バージョンにラベルを付けない限り、その大部分が1日で消えます。上で紹介した記事に、正確なルールと、それを補うラベル付けの習慣が書かれています。