AIツールが、私たちの文章作成、コード作成、そして思考のあり方に深く組み込まれていくにつれ、大学はあまりに難解で見えにくい問いに直面しています。それは次のようなものです： どのように、設計上「見えない」ものを規制するのか？
LMUミュンヘンの統計研究所は最近、学術的な作業におけるAIツール利用のためのガイドラインを公表しました。私はそれが、驚くほど実務的なバランスを取っていると思います。AIを禁止したり、「そんなものは存在しない」と振り切ったりするのではなく、彼らはそれを、ありのままの姿として扱います――つまり、他のツールや情報源と同様に、同じ透明性が求められる「ツール」だということです。ここでの主要な考え方を一つずつ見ていきます。なぜなら、それは学術の枠を大きく超えて重要だと考えるからです。
中核となる理念：責任と透明性
このガイドラインは、議論の余地が少ない2つの柱に立脚しています。
責任。学生は、どのツールがそれに手を貸したかに関係なく、提出するあらゆる言葉について完全な責任を負います。説明できない内容を提出してはならないのです。これは文章にもプログラムコードにも同じく当てはまります。
透明性。AIツールの利用は記録されなければなりません。これは単なる新しい官僚的な負担ではありません。既存の学術慣行の自然な延長です。私たちはすでに出典を引用し、共著者としての貢献を明示し、利用したツールを列挙しています。AIによる支援は、そのリストの次の項目にすぎません。
実際に「どのように記録するのか」
すべての学術的な成果物には、専用の「AIツール」セクションを、概ね0.25〜1ページほど設ける必要があります。それは、多著者の学位論文に見られる「著者の貢献」声明のようなものだと考えてください。ただし、あなたのAIとのやり取りのためのものです。このセクションでは、次の3点を扱うべきです：
- どのAIツールを使ったのか、またそれを一般的にどのように適用したのか
- 成果物のどのセクションにAI支援が関わったのか
- AIが生成した内容が、どの程度広く修正されたのか
加えて、AIツールが必須の思考の一行――単なる言い回しではなく、実際の推論――に寄与した場合は、それが「人間の情報源を引用する」ように、脚注でフラグを立てるべきです。
適切なものと不適切なものの境界
ここが面白いところです。ガイドラインは「AI可／AI不可」という二値の線引きをしていません。その代わりに、スペクトラムとして定義しています。
概ね適切：
- 言語面および文体の修正
- 翻訳支援
- 話題の探究や文献の発見（AIをチューターとして用いる）
- 構成面での支援
- 代数変形や積分解の検証
- プログラミング支援
- グラフィックスや図表の作成
概ね不適切：
- 本質的な理解なしに、AIが生成した文章またはコードをそのまま取り入れること――特に、コアとなる理論セクション、文献レビュー、主要なアルゴリズム実装のような内容の中心部分
- AIを主たるデータ分析や解釈に用いること
- 記録されないAI利用のいずれも
このニュアンスが重要です。LLMを使ってコードの土台を作り、その後に理解をもってリファクタリングする？それなら問題ありません。プロンプトを貼り付けて、結果をコピペして、それが何をしているのか説明できないまま提出する？それが境界線です。
そして、意図的な逃げ道も用意されています。学生には、指導教員とその境界について話し合うことが奨励されています。なぜなら、「適切」とみなされるかどうかは、状況に大きく依存するからです。
評価：出自よりも品質
これらのガイドラインの中で、特に新鮮だと感じる点の1つは、明確に「ルールに従って記録されたAI利用」は成績減点につながらないと述べていることです。成果物の品質が、主要な評価基準として残ります。
とはいえ、バランスを取る仕組みもあります。口頭試問、あるいは試験の比重はより大きくなります。あなたは、自分の成果物のあらゆる側面を詳細に説明し、防御できる必要があります。これは検証の問題を見事に解決します――自分のコードや推論を、その場で説明できないのであれば、記録によっても救われないからです。
AI利用が記録されない場合、結果は成績の減点から、正式な詐称（不正）として扱われる告発まで幅があります。
実践的な記録の例
ガイドラインには、設定しているトーンのために読んでおく価値があるいくつかの例文が含まれています。すべて一貫した型に従っています： 「私は、この成果物のすべての部分を自分で作成しました。さらに、[ツール]を[目的]のために使用しました。出力は[レビュー済み／適応／そのまま採用なし]です。」
良い記録がどのようなものか、いくつかの言い換え例：
- 「導入部の個々の文を洗練させるためにChatGPTを使用しました。提案は手作業でレビューされ、適応され、言い換えられました――そのままの形では採用していません。」
- 「XYのために、プログラミングスクリプトを検査し最適化するためにGitHub Copilotを使用しました。実行時間やメモリ使用量を改善するための提案は理解され、テストされ、適切な場合に採用されました。採用のすべてはコードコメントで記録しています。」
- 「理にかなった情報源を発見し、理論的な概念を説明してもらうために、ウェブ検索付きのClaude Sonnet 4を使用しました。これに基づき、私は一次文献を直接参照し、自分自身の要約を作成しました。」
パターンを確認してください：具体的なツール、具体的な用途、そして出力をどのように扱ったかの具体的な説明です。曖昧なごまかしはありません。
盗んでよいほどの分類（タクソノミー）
ガイドラインには、AI利用のさまざまなカテゴリごとの詳細な分類も含まれています。これは、学生だけでなく、AI支援つきの作業を記録する必要がある人にとっても、役立つ参照資料だと思います。
文章において：文法チェック、引用管理、盗用検出、フォーマット、文体の改善、言い換え（パラフレーズ）、翻訳、文献レビューの下書き、出典の要約、内容の拡充、セクション構成、シミュレートされた査読（ピアレビュー）。
プログラミングにおいて：インライン補完、プロンプトからコードの生成、プロジェクトの骨組み作成、コードの説明、ドキュメント生成、デバッグ、テスト生成、リファクタリング、パフォーマンス最適化、API利用例、依存関係の管理、AIによるペアプログラミング、シミュレートされたコードレビュー。
数学において：記号操作、段階的チュートリアル、可視化、公式の翻訳、予想（コンジェクチャ）の生成、証明スケッチの作成、形式的な証明の合成、反例探索、証明の検証、自然言語を形式論理へ自動形式化すること。
これらのカテゴリは網羅的ではなく、またすべてが自動的に「適切」であるわけでもありません。これは「何をしたのか」を説明するための語彙集だという位置づけです。
学術の外でも重要な理由
私はLLMワークフローの評価と観測（オブザーバビリティ）基盤を作る仕事に、多くの時間を費やしています。そこで明らかになってきたことの1つは、記録の問題は大学に固有ではないということです。実運用でLLMを使うあらゆるチームが、同じ問いに直面します： モデルがどこまで貢献したのか、それとも人間がどこで判断したのかを、どう追跡するのか？
LMUのアプローチ――構造化された記録、明確な責任、品質を優先する評価、そして説明による検証――は、驚くほどエンジニアリングの実務に合致しています。「口頭試問」を「あなたがPRを説明するコードレビュー」に置き換え、「AIツールセクション」を「AI支援を開示するコミットメッセージやPRの説明」に置き換えれば、かなりのところまで同じになります。
重要な洞察は、透明性はAI利用を制限することが目的ではない、という点です。それは説明責任を維持することです。そしてこの原則は、学士論文から実運用のMLパイプラインまで、きちんと拡張して適用できます。
元のガイドライン（英語）は、LMUミュンヘンの統計研究所から入手できます。貴機関でも同様の方針を検討しているなら、ぜひ全文を読んでみる価値があります――このテーマについて私が見た中でも、より思慮深い見解の一つだからです。
