教育分野のDX（デジタル変革）展示会に、生成AIや校務支援システムを扱う企業が約120社出展したという報道がありました。教育現場向けの展示会というと縁遠く感じるかもしれませんが、実際に教育機関から校務支援システムの構築を受託する開発者や、学校向けSaaS（ソフトウェアを提供するクラウドサービス）を開発するエンジニアにとっては、どの技術選定が現実的かを見極める材料になります。本記事では、この種の展示会で語られがちな「生成AI活用」という言葉の中身を、LLM（大規模言語モデル）基盤の設計という観点から分解して整理します。
校務支援や教育現場向けの生成AI活用で語られる機能は、大きく分けて2系統あります。ひとつは成績データや出欠記録など構造化データの自動集計・分析。もうひとつは、学習指導要領や校則、保護者向け文書といったテキスト資料をもとにした質問応答です。後者は技術的にはRAG（検索拡張生成、外部文書を検索してからLLMに回答させる仕組み）で実装されることがほとんどです。
RAGが教育現場で選ばれやすい理由
なぜファインチューニング（モデル自体を追加学習させる手法）ではなくRAGが選ばれやすいのか、技術的な理由を順に見ていきます。
第一に、教育現場の文書は年度ごとに更新されます。学習指導要領の解釈資料や校則、時間割のルールは毎年見直される可能性があります。ファインチューニングで知識をモデルに焼き込むと、更新のたびに再学習が必要になり運用コストがかさみます。RAGであれば、検索対象の文書を差し替えるだけで最新情報に追従できます。
第二に、教育委員会や学校単位でデータを分離する必要がある点です。A市の校則とB市の校則を混同して回答してはいけません。RAGはベクトルDB（文書の意味的な近さを検索できるデータベース）側でテナント（利用組織）ごとにインデックスを分離できるため、マルチテナント運用との相性が良好です。ファインチューニング済みモデルを組織ごとに個別に持つより、インフラコストを抑えられます。
第三に、回答の根拠を示しやすい点です。保護者からの問い合わせに対し「この回答は学校要覧の◯ページに基づく」と出典を提示できることは、教育現場のような説明責任が重視される領域で重要です。RAGは検索でヒットした文書チャンク（分割された文章の断片）をそのまま根拠として提示できますが、ファインチューニングで埋め込んだ知識は出典を遡りにくいという弱点があります。
ファインチューニングが向く場面との切り分け
一方で、すべてをRAGで解決しようとすると無理が出る場面もあります。たとえば答案の記述式採点や、生徒の作文に対するフィードバック生成のように、「知識の参照」ではなく「特定のスタイル・基準で出力する」タスクは、RAGだけでは精度が頭打ちになりやすい領域です。
こうしたタスクでは、採点基準や模範解答のペアを使った教師ありファインチューニング、あるいはプロンプト内に少数の例を埋め込むfew-shotプロンプティング（少数の例示で挙動を調整する手法）との組み合わせが検討対象になります。展示会のデモで「生成AIが作文を自動採点」と紹介されている場合、その裏側がRAGなのかファインチューニング済みモデルなのか、あるいは単なるプロンプト設計の工夫なのかで、精度の安定性も運用コストも大きく変わります。
今日確認できる技術的な判断ポイント
校務支援システムや教育機関向けAIサービスの提案・開発に携わる立場であれば、ベンダーの説明や自社の設計を見直す際に、次のポイントを確認しておくと判断材料になります。
- 回答の情報源が文書検索（RAG）かモデル内蔵知識かを明示できているか
- 年度更新・自治体ごとのルール差分を、再学習なしで反映できる設計になっているか
- 個人情報（成績・出欠・家庭状況）を含む文書をLLMに渡す際、匿名化やアクセス制御がパイプラインのどこで行われているか
- 採点・フィードバック生成など出力スタイルが重要なタスクで、精度評価の指標（採点基準との一致率など）を数値で検証しているか
- ベクトルDBや検索基盤のテナント分離が、自治体・学校単位の権限管理要件を満たしているか
特に個人情報の扱いは、教育現場特有の論点です。成績データや生徒の家庭状況に関する記述をベクトル化して外部のクラウドAPIに送る設計になっていないか、ベンダーのアーキテクチャ図やデータフロー図で確認することをおすすめします。国内の教育委員会調達では、データの保存先がどの国のリージョンかも審査対象になることがあるため、利用予定のLLM APIやベクトルDBサービスの公式ドキュメントでリージョン設定の項目を見ておくと安心です。
まとめ
教育DX展示会に多数の企業が出展した背景には、校務支援という具体的な業務領域に生成AIを組み込む動きの広がりがあります。
技術選定の観点では、文書検索ベースのRAGと、出力スタイル調整のためのファインチューニングという2つの手法を混同しないことが出発点です。
実務で提案や開発を担う場合は、情報源の明示性、更新運用のコスト、個人情報のデータフロー、採点などスタイル依存タスクの精度評価という4点を、具体的な設計資料やAPI設定画面で確認してみてください。
そのうえで自社やクライアントの要件がRAG寄りかファインチューニング寄りか、あるいは両方の組み合わせが必要かを切り分けると、展示会で見かける華やかなデモの先にある運用コストが見えてきます。