Skip to content
Takumi Tokunaga
Blog

AI時代に大学のレポート評価は成立するのかを再考する

Published · Mar 17, 2026

Topics

ai
education
大学
zenn
レポート

はじめに

生成AIの普及によって、大学のレポート評価は根本から再検討が必要な段階に入っていると感じています。

従来、大学のレポートは次のような能力を測るものだと考えられてきました。

  • 授業内容の理解
  • 資料の読解
  • 情報整理
  • 文章構成
  • 考察力

しかし現在では、適切に構成したワークフローを使えば、これらのかなりの部分を Coding Agent に代行させることができます。

私は実際に、大学のレポート作成に近い形で次の流れを試しました。

  • ドキュメント群をスクリプトで一括処理する
  • Gemini のマルチモーダルモデルで Markdown 化する
  • その結果を grep 可能な状態にする
  • Codex にレポート課題要件を与える
  • レジュメ群と実験結果群を参照させる
  • LaTeX でレポートを生成する
  • コンパイルまで実行する

その結果、少なくとも「資料を読み、構成を考え、レポートとして整形する」という工程について、従来の大学評価が想定していた前提はかなり崩れていると感じました。

この記事では、実際のレポート生成過程をもとに、次の点を整理します。

  • どのような流れでレポートが生成できたのか
  • なぜ従来型レポート評価が弱くなっているのか
  • AI時代に大学は何を評価すべきか

実際に行ったレポート生成フロー

今回の流れは、単に「ChatGPT にレポートを書かせた」という話ではありません。もう少し作業環境に近い形で、ローカルの資料群を整理して Agent に扱わせる構成です。

全体像は以下の通りです。

ドキュメント群
↓
スクリプトで一括処理
↓
Gemini マルチモーダルモデルで Markdown 化
↓
grep 可能な状態に整理
↓
レポート課題要件 + レジュメ群 + 実験結果群を指定
↓
Codex / Coding Agent が内容確認
↓
LaTeX でレポート作成
↓
コンパイル
↓
提出可能な PDF を生成

ポイントは、最初から LLM に PDF や画像を雑に投げたわけではないことです。まず、レジュメなどのドキュメントをスクリプトで処理し、Gemini のマルチモーダルモデルで Markdown に統一変換しました。この段階で、PDF や文書資料を機械的に扱いやすい形へ落とし込んでいます。

その後、Markdown 化された内容を grep で検索可能な状態にし、Agent が必要に応じて情報を探索できるようにしました。

さらに、別途フォルダとして次を配置しました。

  • resume: 授業レジュメや補助資料をまとめた領域
  • expResult: 実験結果をまとめた領域

ここで重要なのは、実験結果は写真ではなく、ターミナルの出力を .txt として保存したものが中心だったという点です。たとえば week1_hostA.txtweek7serverS.txt のように、各週のホストやルータの実行結果がテキストで保存されていました。

今回の公開用サンプル一式は、次の GitHub リポジトリでも参照できます。

https://github.com/ttokunaga-ja/sampleSubject

そのうえでプロンプトでは、次を明示的に指示しました。

  • レポート課題要件を確認すること
  • レジュメを確認すること
  • 実験結果の TXT を確認すること
  • それらを踏まえてレポートを書くこと

結果として、Coding Agent は資料と実験ログを参照しながら LaTeX のレポートを生成し、最終的にコンパイルまで実行しました。

これは単なる文章生成ではなく、次を含んだ一連の知的作業フローです。

  • 資料読解
  • 情報探索
  • 構成設計
  • レポート執筆
  • LaTeX 整形
  • ビルド

今回のディレクトリ構造で重要だった点

公開時点の構造を見ると、単なる「画像フォルダ」とは言いにくいことがよく分かります。

.
├── expResult
│   ├── week1
│   │   ├── week1_hostA.txt
│   │   ├── week1_hostB.txt
│   │   └── week1_hostX.txt
│   ├── week2
│   ├── week3
│   ├── week4
│   ├── week5
│   ├── week6
│   └── week7
├── report
├── resume
└── scripts

この構造から読み取れることは次の通りです。

  • resume には授業資料由来の文書がある
  • expResult には週ごとの実験結果がある
  • 実験結果の主役は .txt のログである
  • 一部に pcapngjpg もあるが、記事の中心は TXT ベースの出力である
  • report には実際に生成・コンパイルされた成果物がある

特に expResult/week1 から expResult/week7 まで、ホスト名やルータ名ごとの出力が細かく分かれているため、Agent から見ると「視覚資料」よりも「検索可能な観測ログの集合」に近い入力になっています。

このフローで何が重要だったか

重要だったのは、AI に「全部おまかせ」で投げたことではありません。むしろ逆で、AI が扱いやすい情報空間を先に設計したことです。

今回の実験で本質的だったのは、次の 3 点です。

1. まず資料を Markdown 化したこと

PDF や画像をそのまま都度読むよりも、先に Markdown に変換しておくことで、後段の Agent が圧倒的に扱いやすくなります。

つまり、レポート作成の精度を上げたのは単体のモデル性能だけではなく、資料を読みやすい形式へ正規化する前処理でした。

2. grep 可能にしたこと

資料の中から必要箇所を探す工程は、人間にとってもかなり大きな負担です。しかし Markdown 化されたテキスト群を grep 可能にすると、Agent は必要に応じてかなり効率よく参照できます。

ここで起きていることは、単なる文章生成ではなく、検索可能なローカル知識ベースを使った執筆です。

3. 実験結果が TXT だったこと

今回の実験で参照させたのは、写真そのものではなく、主にターミナル出力を保存した TXT 群でした。これは重要です。

なぜなら、TXT は次のような点で Agent にとって扱いやすいからです。

  • 文字列検索しやすい
  • 該当箇所を引用しやすい
  • 週ごとの差分を追いやすい
  • ホストごとの役割を整理しやすい

つまり今回自動化されたのは、「画像を見て雰囲気で書く」作業ではなく、実験ログを読み、必要な情報を拾い、レポートとして再構成する作業でした。

生成されたものは「下書き」ではなく「提出可能なレポート」だった

ここで重要なのは、生成されたものが単なるメモや草案ではなく、LaTeX で整形され、コンパイルされた提出可能な成果物だったことです。

つまり Agent が代行したのは、次を含む一連の工程でした。

  • 要旨の整理
  • セクション構成
  • 本文記述
  • レポート形式への整形
  • PDF 生成

従来の大学レポート評価は、提出物の外見や文章のまとまり、論理性をある程度評価対象にしてきました。しかしその部分は、今やかなり高い水準で機械化できます。

この意味で、大学のレポート評価は 「人が頑張って文章を書くこと」を暗黙の前提にしていた設計 だったと言えます。

よくある AI 対策が弱い理由

大学側の対策としてよく挙がるものがありますが、今回のようなワークフローを考えると、かなり弱いと感じます。

授業資料に依拠させる

「Web の一般論ではなく、授業レジュメに基づいて書くこと」という指示はよくあります。しかし今回のように、レジュメをローカルに置き、Markdown 化し、検索可能にした状態で Agent に参照させれば、この条件は比較的容易に満たせます。

つまり、授業固有資料への依存を高めること自体は、もはや防御策ではないということです。

実験結果を使わせる

「実験結果をもとに考察を書くこと」という課題もあります。しかし実験結果が TXT ログとして整理されていれば、Agent はかなり扱いやすくなります。

特に今回のように、週ごと、ホストごと、ルータごとに分かれた出力が保存されていると、次の流れを機械的に支援できます。

  • 実験をした
  • 結果を TXT として保存した
  • その TXT を参照してレポートを書く

この一連の流れにおいて、文章化の部分はかなり AI が代行できる、ということです。

LaTeX などの形式を指定する

「レポートの形式が厳しいから AI では難しい」という見方もありますが、実際には LaTeX 生成とコンパイルまで Agent が処理できるため、整形式の要求も防波堤にはなりにくいです。

では大学は何を評価していたのか

この経験から逆に見えてきたのは、多くの大学レポートが実際には次の能力をまとめて評価していたことです。

  • 資料を読む
  • 必要箇所を探す
  • 情報を整理する
  • 文章構成を作る
  • 文体を整える
  • 指定フォーマットへ整える

しかし現在、このかなりの部分を Agent に任せることができます。

だとすると、「レポートを書かせること」自体の教育的価値はゼロではないにせよ、それを成績評価の中心に置き続けるのは難しくなるはずです。

それでも重要なのは「成果物」だと思う

ここで、よくある議論として「本人が書いたかどうかを重視すべき」という方向があります。ただ、私はそこを主軸にしすぎるのは違うとも感じています。

なぜなら、社会でも研究でも重要なのは最終的に 成果物 だからです。

論文、設計書、コード、実験報告、提案資料。重要なのは、それが信頼でき、再現でき、レビューに耐え、誤りを見抜ける形になっていることです。

つまり AI 時代の大学評価も、「自力で書いたか」から「AI を使っても、信頼できる成果を作れるか」へ移るべきだと考えています。

AI時代に学生へ求めるべき能力

この前提に立つと、非対面課題で測るべき能力はかなり変わります。

1. 成果物を仕様化する力

AI に良い成果物を作らせるには、そもそも次を定義できる必要があります。

  • 何を目的にするのか
  • どの制約があるのか
  • どの形式で出すのか
  • 何を重視するのか

これは単なる作文力ではなく、要求定義の能力です。

2. AI出力をレビューする力

AI はもっともらしい誤りを出します。だから重要なのは、出力されたレポートを見て次を確認できることです。

  • 内容は妥当か
  • 授業内容とずれていないか
  • 実験結果の解釈に飛躍がないか
  • 書いていないことを勝手に言っていないか

これは今後かなり本質的な能力だと思います。

3. 再現性を設計する力

成果物が 1 回うまくできても、それだけでは弱いです。同じ資料、同じ条件、同じ手順で、もう一度同水準の成果を作れるか。この再現性を意識して作業を設計できることは、学術でも実務でも重要です。

4. 誤生成を見抜く力

生成 AI 時代には、「答えを出す能力」そのものよりも、誤った答えを見抜く能力の価値が上がります。

文章が綺麗でも、中身が間違っていれば意味がありません。特に大学教育では、もっともらしい誤りを検出する能力こそ重要になります。

5. 条件変更に対応する力

一度作ったレポートをそのまま出すだけでなく、次の変更に対応できるかも重要です。

  • 別の前提ならどう変わるか
  • 教員からの指摘をどう反映するか
  • 別のデータなら考察をどう修正するか

これは、研究でも実務でも重要な能力です。

対面試験と非対面課題の役割を分けるべきではないか

この観点に立つと、大学評価は役割分担をしたほうがよいと思います。

対面試験で測るもの

対面試験では、基礎知識や概念理解、最低限の自力運用を測るべきです。つまり、次のような要素です。

  • 用語理解
  • 基本概念の適用
  • その場での思考

これは本人の最低保証ラインを確認する役割です。

非対面課題で測るもの

一方で、非対面課題では別の能力を測るべきです。

  • AI を使って成果物を作る力
  • その成果物の再現性を担保する力
  • 誤りをレビューする力
  • 条件変更に対応する力
  • 品質を保証する力

ここでは「AI を使ったかどうか」を問うより、AI を使っても壊れない成果を作れるかを見るべきだと思います。

非対面評価はどう変えるべきか

従来のように「レポート本文だけ提出」では弱いです。では、何を追加で見るべきでしょうか。私は少なくとも次のような構成が必要だと思います。

1. 成果物本体

まず、レポートやコードや設計書そのものです。これは当然必要です。

2. 再現可能性の説明

その成果物をどう作れば再現できるのか、どの資料をどう処理し、どの条件で生成したのかを説明させます。これは「履歴の真正性」を証明するというより、再現可能な形で説明できるかを見るものです。

3. レビューノート

自分の成果物の弱点や危険箇所、追加で検証すべき点を短く書かせます。重要なのは、生成過程を告白することではなく、自分の成果物を批判的に読めるかです。

4. 条件変更への追課題

提出後に短く、次のような追課題を出します。

  • 前提を変える
  • 制約を増やす
  • 別条件に適用する
  • 弱点を自分で修正させる

これによって、単なる完成物最適化ではなく、成果物を運用・改良できるかが見えます。

結局、レポート評価はどう変わるべきか

私の現時点の結論はこうです。

AI 時代において、大学のレポートは 「文章を書く能力」の評価としては弱くなる。しかし、「AI を使って信頼できる成果物を作れるか」を見る評価へ変えるなら、まだ意味があると思います。

つまり、レポートを捨てるべきなのではなく、評価対象を変えるべきです。

従来は、次のような点を強く見ていたはずです。

  • どれだけ綺麗に書けるか
  • どれだけそれらしくまとめられるか

これからは、次を見るべきだと思います。

  • どれだけ再現性を意識できるか
  • どれだけ誤りをレビューできるか
  • どれだけ条件変更に耐えられるか
  • どれだけ成果物の品質を保証できるか

おわりに

今回試したワークフローは、単に「AI にレポートを書かせた」という話ではありませんでした。

  • ドキュメントを前処理し
  • Markdown 化し
  • 検索可能にし
  • レジュメと実験結果の TXT を参照させ
  • Agent に LaTeX レポートを書かせ
  • コンパイルまで行う

という一連の流れを通じて見えたのは、大学レポートの多くが、すでに 高度に自動化可能な知的作業 に近づいているということです。

だからこそ、大学は「AI を禁止するかどうか」より先に、何を学習成果として評価するのかを再定義する必要があります。

対面では知識と基礎運用を確認する。非対面では、AI を前提とした成果物の品質保証能力をみる。この分離が、今後かなり重要になるのではないかと思っています。

今回の生成過程の要点
1. ドキュメントをスクリプトで一括処理
2. Gemini のマルチモーダルモデルで Markdown 化
3. grep 可能な状態に整理
4. resume と expResult を Agent に参照させる
5. expResult 内の TXT 出力をもとに実験内容を確認する
6. LaTeX でレポート生成
7. コンパイルして PDF 化

もし大学教育の評価設計を考えている方がいれば、ぜひ「AI を使ったかどうか」ではなく、「AI を使ってもなお本人の能力差が出る評価とは何か」という観点で議論してみてほしいです。

©

GitHub