大学が「生成AIを導入する」とは、具体的に何をすることなのでしょうか。もしもある大学が何も指針を出していない状況で、学生（組織の構成員）が生成AIを使用して卒論の章立てを整理すると、その大学が「生成AIを導入した」ことになるのでしょうか。

例えば、2023年8月23日に東京都庁が「生成AIを都庁内の全局で導入、業務活用を開始」したと報じられました。ここでいう生成AIの導入とは具体的に何を指すのでしょうか。

2023年7月31日、武蔵野大学は生成AIを搭載したICTヘルプデスクチャットボットの導入を発表しました。この導入は国内大学での初めての「生成AI導入」の事例とされています。
その後、10月2日の報道では山梨大学が生成AIを試験的に導入することが明らかになりました。
一部メディアの報道によれば、専修大が演習系授業でChatGPTを利用したことが「チャットGPTを導入した」と報じられています（NEWSWITCH）。

個人的な感覚としては、「生成AIを導入」というと教員や学生の個人レベルではなく組織レベルで契約した事例を指すことを想定しますが、報道レベルでは武蔵野大学や山梨大学のような学内の業務システムとして生成AIを構築した事例だけでなく、授業内で生成AIを使用したものも「導入」として扱われています。

ある組織が「生成AIを導入」しようとする場合、その組織は導入パターンの選択肢を検討し、メリットとデメリットによって組織に最適な導入パターンを選択する必要があります。
この記事では、企業におけるLLM（大規模言語モデル）と生成AIシステムの導入パターンを参考に、大学が生成AIを導入する際の代表的なパターンを紹介します。

パターン１
自大学のオンプレミス環境で大規模言語モデルを開発する

パターン１は、オンプレミス、すなわちサーバやシステムなどを自組織で開発、管理、運用する方法で、学内の様々なデータを学習してLLMを構築する方法です。

メリットとしては学習元のデータが明確であること、学内で開発と運用が完結するのでデータ流出のリスクが低いことなどが挙げられます。
学習元のデータが明確であることは、データ内のバイアス等が明確になるメリットが大きいでしょう。
しかしLLMを自社で整備できるのは大企業であってもごく一部であり、大学が単独でLLMを構築することはコスト面、運用スキルを持つ人員の配置、費用対効果を考えて、現状の環境では現実的ではないかもしれません。

パターン1の派生として、公開された既存の事前学習済みモデル（Pre-trained Model）を下敷きにして、自大学のデータを学習させる方法もある（ファインチューニング）。
ファインチューニングでは、公開された言語モデルを再利用し、自大学のデータを再学習させることで、自大学の求めるタスクに特化したモデルを作成する。メリットとして、一から開発するよりもコストを低減させることができる。

パターン2
自大学のシステムの内部で、生成AI事業者が提供するAPIを利用する

パターン2は、自大学で開発したシステムから、外部API経由で生成AIの機能を呼び出すことで独自のシステムを構築するものです。

例えば自大学のLMS（神戸大であればうりぼーネット）に生成AIを利用するアプリを組み込むことで、LMSのひとつの機能としてチャット形式によるシラバスの検索、履修科目の推薦、履修登録や卒業条件の問い合わせなどを行わせることができるでしょう。
履修履歴、学習ポートフォリオをもとに就活や海外留学の資料作成をアシストするといった機能も、（コストをかければ）実現できます。

このパターン2は、メリットとしては自大学のニーズに合わせたシステムを構築できることが挙げられます。
しかし後述するパターン3（ChatGPT等を使う）に比べると当然に開発コストがかかり、運用体制も整備しなければなりません。

パターン3に比べれば、フィルタリング機能を搭載することによって、学生が個人情報を入力することを避けるように設定することも可能ですが、システム上、学内の情報を外部APIに渡すことになるので、データ再利用の禁止など、事業者との契約を精査する必要があります。

生成AIを業務に導入した東京都は、パターン2を採用したものと思われます。資料ではMicrosoft Azureを利用し、データの漏洩リスクを可能な限り低減したことが示されていますが、そもそも高機密情報（機密性A）は入力してはならないと規定されています。

パターン3
生成AI事業者のWebサービスを利用する

パターン3は、一般的な生成AIのwebサービスを利用するというものです。
言語系生成AIであればChatGPT （OpenAI社）、Bard （Google社）などのアプリケーションを、学生や教員が利用して日常的な学習や業務に役立てていきます。

メリットとしては、LLMやユーザインターフェース、各種アプリケーションを開発する必要がないために、金銭的・時間的コストを格段に抑えられる点が挙げられます。
しかしデメリットとして、ユーザが入力した情報が外部に送られるため、個人情報や機密情報、未公開情報が流出する危険が伴うでしょう。

仮に、大学として生成AIを導入するとも禁止するとも明確に宣言しない場合は、基本的には各教員、各学生の判断でパターン3を採用することとなります。
（あるいは、スキルのある教員や学生が独自に生成AIのアプリケーションを開発する場合は、パターン1や2となります。）
2023年末時点では、先述の武蔵野大学や山梨大学などごく少数の大学を除き、ほとんどの大学がパターン3を前提としていると思われます。

パターン4
生成AIが組み込まれた、学外のサービスを使用する

パターン3は生成AI事業者のサービスを直接利用するという方法でしたが、パターン４は生成AI事業者ではない会社のサービスの中に組み込まれた生成AIを利用するというものです。

例えば、就職活動のエントリーシート（ES）の添削アプリケーションは、そのアプリの提供会社自体が大規模言語モデルやGPTを開発しているわけではなく、生成AI事業者のAPIを使用して添削サービスを展開しています。

こうしたパターンでは、学生や居職員は生成AIを利用しているという自覚がないことも考えられます。
つまり学生が就活のES添削アプリを使っていたら、実はそのアプリが内部で生成AIを使用していたということは十分に想定できます。
あるいは、本人は人間による通信添削を受けていると思っていたら、添削者が実は生成AIを利用していたということも考えられるでしょう。

まとめ

大学は一般の企業とは異なり構成員（特に学生や教員）の独立性が高いのが特徴です。
そのため教育、研究、業務等において明確に一切の生成AI利用を禁止しない限り、少なくとも報道レベルでは「生成AIを導入した」とみなされることとなります。

（ただし個人的にはやはりパターン2は生成AIの利用を受容あるいは容認した、と言うべきで、導入した、というのはパターン3のように組織として自社システムのなかに生成AIを組み入れて業務に導入した事例に用いるのが適切だと思います。）

この記事で示したバリエーションは、
◯　LMSを用いた生成AIシステムを自大学で開発するか（パターン1, 2）
◯　外部サービスを使うか（パターン3, 4）
による分類で、大まかな方針の分類です。

武蔵野大学や山梨大学、東京都の事例ではパターン2が採用されています。
一部ニュースの「授業内で生成AIを利用した」という事例は、詳しい活用方法が定かではないですが、パターン3に該当するものと思われます。

その他、バリエーションとしてはAIに詳しい学生や教職員が個人的に生成AIを開発して利用するというパターンや、クラウドを組み合わせたシステムなどが考えられるため、これら4つのパターンから派生する導入バリエーションはサービスごとに幅広いものとなるでしょう。

2024年以降、各大学は様々なパターンで「生成AIを導入」していくことになります。
この分類も、状況に応じてアップデートしていく方針です。