OverleafのGitコミット履歴を使ってAI検出の誤判定に異議申し立てを行う方法

可能です。学術不正の審査委員会が求めているのは、文章の出所や作成過程（Provenance）を示す証拠、つまり文書が時間をかけて段階的に組み立てられたことを証明できる執筆の痕跡です。Turnitin、iThenticate、GPTZeroといった検出ツールは、最終的に提出された静的なPDFしか評価しません。パープレキシティ（困惑度）やバースティネス（突発性）に基づいて確率的なスコアを算出しているだけで、文書がどのように組み立てられたのかを見ることはできないのです。

Overleafはその作成プロセスを記録しています。科学や数学の論文は簡潔で受動態を多用する厳格な構文に依存するため、理系分野の論文は高い確率でAI検出の誤判定（偽陽性）を引き起こします。AI検出器は、テキストがプロンプトによって一瞬で生成されたかのように判定します。しかし、検証可能なOverleafの履歴は、その正反対の事実を証明します。すなわち、数週間から数か月にわたる数百回もの細かい修正、構文エラーの解消、変数名の変更、そして定理の調整といった確かな痕跡です。

執筆プロセスの暗号学的な記録を提示できれば、アルゴリズムによる確率的な推測を客観的な物証に置き換えることができます。タイムスタンプが刻まれた検証可能なリビジョンの成果物を前にすれば、審査委員会も不正の申し立てを維持することはできません。

Overleafには大きく分けて2つの履歴追跡メカニズムがあります。この違いを理解しておくことが、証拠を適切に抽出し提示するための鍵となります：

1. Web版のリビジョン履歴（Historyタブ）：

Webエディタは入力操作を個別の編集セッションにまとめ、画面上で左右に並べて視覚的な比較を表示します。どの共同執筆者がどの変更を行ったかを確認でき、以前の状態に戻すことも可能です。ただし、Webインターフェースからのエクスポート機能は限られています。無料プランでは直近の編集（通常は過去24時間以内）しか閲覧できませんが、全履歴は内部に保存され続けており、プロジェクトを有料プランにアップグレードすれば再び参照できるようになります。

1. 基盤となるGit BridgeとGitHub同期：

Overleafのすべてのプロジェクトは、背後でGitリポジトリとして稼働しています。有料プランや機関向けプランで利用できるGit Bridge（`git.overleaf.com`）からの直接アクセス、あるいはネイティブのGitHub/GitLab連携を通じて、標準的なバージョン管理ツールを用いてプロジェクトを操作できます。

自分で確認するだけであればWebインターフェースで十分ですが、大学の委員会への申し立てには、持ち運び可能で改ざんの余地がない証拠が求められます。基盤のGitツリーをエクスポートすれば、正確なコミットハッシュ、作成者のメタデータ、二重のタイムスタンプ（Author DateとCommit Date）、そして情報科学系や工学系の教員が個別に検証できる機械可読な差分（diff）ファイルが得られます。

審査委員会に編集履歴を提示するには、生のGitリポジトリをローカル環境にクローンし、整理された監査証跡を生成します。

1. プロジェクトリポジトリをクローンする：所属機関がOverleaf Professionalを導入しているか、ご自身で有料プランを契約している場合は、Overleaf Git Bridge経由で直接 `git clone https://git.overleaf.com/[project-id] thesis-appeal-repo` を実行してクローンします。プロジェクトをGitHubやGitLabと同期している場合は、`git clone https://github.com/[username]/[repository-name].git thesis-appeal-repo` を実行してリモートリポジトリをクローンしてください。

1. タイムスタンプ付きの完全なコミットメタデータを書き出す：`git log --pretty=fuller --stat > commit_timeline_summary.txt` を実行し、`--pretty=fuller` オプションを付けて `git log` を出力します。これにより、`AuthorDate`（編集が行われた日時）と `CommitDate`（リモートサーバーに記録された日時）の双方が表示されます。サーバー側のコミットタイムスタンプはローカル端末の時計操作では改ざんできないため、第三者によって証明された時系列の証拠として機能します。

1. 指摘されたセクションの行ごとの差分（diff）を生成する：特定の章や節をご自身の手で執筆したことを示すには、`git log -p -w --reverse -- main.tex > main_tex_evolution.diff` で対象ファイルの全履歴差分を抽出するか、`git log -S "theorem:convergence" -p -- sections/methodology.tex > convergence_proof_steps.diff` を使って特定の定理を変更したコミットだけを抽出します。この出力はすべての追加と削除を標準的なUnified diff形式で記録しており、草稿が執筆された時系列を明確に示します。

一般的な人文系のレポートは単語レベルの書き直しが中心となりますが、理系の論文には、大規模言語モデルが一括生成では決して生み出せない固有の技術的痕跡が含まれています。

1. 段階的な数式展開のプロセス：AIモデルは完全なLaTeX数式を一度に一括出力します。一方、実際の人間の研究者は、コンパイルを繰り返しながら表記ミスを直したり、インデックスを調整したり、符号を修正したり、長い数式を複数行環境に分割したりします。本物のリポジトリでは、最初のコミットで基本的な損失関数（`\mathcal{L}(\theta) = \sum \log P - \lambda \sum \|\mathbf{w}_k\|_2^2`）が記録され、その後のコミットで正則化項が修正されたり（`-\frac{\lambda}{2} \sum \|\mathbf{w}_{k, t}^{(j)}\|_2^2`）、インデックスの次元が統一されたりします。こうした表記の段階的な微調整こそが、人間が能動的に数式を組み立てていた確固たる実証的証拠となります。

1. LaTeXのコンパイルとデバッグのサイクル：人間がLaTeXで執筆する過程では、波括弧の不一致、エスケープ漏れ、パッケージ不足、相互参照の未解決など、コンパイルエラーが何度も発生します。Gitログには、特定のコンパイラエラーを解消するための途中のコミット（閉じられていなかった `\left(` を `\right)` で閉じる、無効な `\cite` キーを修正するなど）が記録されます。こうした細かなトラブルシューティングのコミット履歴は、AIが生成した草稿には一切存在しません。

1. 非同期的なBibTeXエントリの追加：生成AIモデルはしばしば架空の文献を捏造したり、大量の引用を一度にまとめて挿入したりします。本物の研究リポジトリでは、`.bib` ファイルが時間をかけて少しずつ成長していきます。コミット履歴を見れば、文献調査の進捗に合わせて異なる日付で個別のBibTeXエントリが追加されていることがわかります：

学術不正の審査委員会には、技術分野の専門家だけでなく、技術に詳しくない事務担当者や他分野の教員も含まれます。未整理のままターミナルの生ログを何百ページも提出するのは避けてください。申し立て書類は、以下のように体系的で専門性の高いドシエ（申立書セット）として構成しましょう：

1. 要約（1ページ）：講義名、論文タイトル、指導教員名、および争点となっているTurnitinやiThenticateのAI検出スコア（パーセンテージ）を明記します。また、プロジェクト全体の指標として、執筆期間（例：47日間）、総コミット数（例：114コミット）、リポジトリURL、OverleafのプロジェクトIDを簡潔にまとめます。その上で、"The attached technical record establishes an uninterrupted drafting timeline that refutes the claim of automated text generation."（添付の技術的記録は、途切れのない執筆の時系列を証明するものであり、自動テキスト生成によるものだという主張を論駁するものです）とはっきりと宣言します。

1. 時系列マイルストーン対応表：論文の主要な節目とGitコミットハッシュを対応させた全体サマリーを提示します。

1. 注釈付きの主要差分（Annotated Diff Highlights）：数式の導出過程、アルゴリズムの疑似コードの調整、文献レビューの加筆など、決定的な差分を3〜5か所選びます。人間が試行錯誤して意思決定した経緯が伝わるよう、解説注釈を添えましょう。

1. 完全な技術付録（Technical Appendix）：`git log --stat` の全履歴と詳細なパッチ出力を、目次付きのPDFファイルにまとめて添付します。委員会がリポジトリツリーを直接監査できるよう、コミットハッシュがOverleafやGitHub上の実リポジトリと完全に一致していることを確認してください。

ヒアリングの場では、終始一貫して専門的かつ客観的な姿勢を保ちましょう。評価者の意図を疑うのではなく、確率モデルに基づくAI検出器の技術的限界に焦点を当てて説明することが重要です。

学術不正審査委員会がGitログを独自研究の証拠として認めた場合であっても、大学が最終的な論文アーカイブに「AI検出フラグゼロ」を義務づけている場合は、特定の段落の修正を求められることがあります。しかし、技術的なLaTeX文書において、背景や関連研究のセクションを手動で書き直そうとすると、文献引用、相互参照（`\label{}` や `\ref{}`）、あるいは数式の記法を壊してしまうリスクがあります。

Turnitin または iThenticate のレポートを読み込み、指摘された箇所だけを書き換えます。同じ形式の編集可能なファイルを受け取れます。

疑義が持たれた箇所のみを対象にすることで、背後にあるLaTeXの構造や数式、引用のネットワークを完全に保ちながら、大学の検出ソフトウェアによって指摘された具体的な文だけに対処することができます。

Git連携を設定せず、Overleafの無料プランを使っていた場合はどうすればよいですか？ 執筆中にGitHubと連携していなかったりGit Bridgeを使用していなかったりした場合でも、OverleafのWeb画面にある「History」タブを利用できます。無料プランでは直近24時間の履歴しか表示されない場合でも、アカウントを有料プランにアップグレードするか大学の機関ライセンスを取得すれば、過去にさかのぼって全履歴が即座にアンロックされます。また、ローカルにダウンロードしていた草稿の `.zip` ファイルや、キャッシュに残っている日付付きのPDFコンパイル出力、ブラウザの閲覧履歴なども、申し立てを裏付ける補助証拠になります。

学生がGitコミットのタイムスタンプを偽造して申し立てをでっち上げることは可能ですか？ ローカル環境では `GIT_AUTHOR_DATE` 環境変数を使って作成日を偽装することはできますが、コミットをプッシュした際にOverleafやGitHubによって記録されるリモートサーバー側のタイムスタンプを変更することはできません。サーバー側の `CommitDate` には、ネットワーク上でデータを受信した正確な日時が記録されます。さらに、本物の構文エラーや数式の段階的な推敲を含み、実際に正しくコンパイルが通る数十回もの妥当な中間状態を、説得力を持たせて自動生成することは事実上不可能です。

TurnitinやiThenticateはOverleafのGit履歴を自動で確認しますか？ いいえ、確認しません。TurnitinやiThenticateは、大学のポータルに提出された文書（通常はPDFやWordファイル）のみを対象としています。OverleafやGitHub、その他の執筆環境との連携機能は一切ありません。提出された文書の統計的なテキストパターンを分析しているだけであるため、学生自身がバージョン履歴を個別に抽出して提示する必要があります。

技術に詳しくない審査委員にもGitログは理解できますか？ 理系以外の学部の委員の多くは、Gitの構文に馴染みがないでしょう。だからこそ、1ページの要約や視覚的な差分表の作成が不可欠となります。一方で、委員会に参加している理系教員や大学の技術顧問であれば、バージョン管理の仕組みをすぐに理解できます。そして、第三者によって記録された暗号学的なコミット履歴は、学術的・法的な観点からも客観的で強力な防御手段となります。