「社員に生成AIを教える」はもう古い？ 専門学校生の成果発表から見えた、企業が備えるべき人材戦略

本記事を10秒でまとめると

専門学校生がすでに、AI・API・データベースを組み合わせて実用的なWebアプリを作る時代が到来している。これから企業では「社員にAIを教えること」だけではなく、AIを使える若者の力を正しく評価し、さらに伸ばし、働きたいと思ってもらえる人事制度・教育・組織環境を整えることが急務になってきている。

リアルな教育現場から見えてきたこと

企業の生成AI活用について話をしていると、今でもよく耳にする言葉があります。

「まずは若手社員にChatGPTの使い方を覚えてもらおう」

もちろん、それ自体が間違っているわけではありません。しかし数年後、もしかするともっと早い段階で、この発想そのものが古くなる可能性があります。すでに生成AIの利用率は社会人より学生の方が割合が高いという統計を目にした人も多いかもしれませんが、これから社会に出てくる学生の中には、すでに生成AIを「質問するためのツール」ではなく、システムを構成する一部として扱い始めている人たちがいるからです。

今回、筆者は山口県のYIC情報ビジネス専門学校で行われた学生の成果発表会（令和８年９月７日）を見学する機会をいただきました。
正直に言えば、生成AIやシステム開発に日常的に触れている筆者にとって、そこで使われていた技術自体が未知のものだったわけではありません。しかし、専門学校2年生がデータベースやAPI、生成AIを組み合わせながら、自分たちで課題を設定し、Webアプリとして形にし、人前でデモしている光景には、別の意味で考えさせられました。

それは単なる「学生の作品発表」ではなく、数年後の企業の人材構成を先取りして見ているのではないか。と

「AIの使い方」を学ぶ授業ではない

今回見学したのは、ＹＩＣ情報ビジネス専門学校 非常勤講師 大島直樹氏（ 山口大学大学院技術経営研究科・ 教授）が担当する「情報・科学と数学」の成果発表会です。

学生たちには共通課題として「架空のスタートアップ企業を題材に、財務状況を分析」そして自由課題は「各班が自分たちでテーマを決め、Webアプリケーションを企画・開発」の2つの課題が与えられていました。

興味深かったのは、この授業が単純な「生成AI活用講座」ではなかったことです。

生成AIのプロンプトを学ぶのではなく、

課題を理解する。
情報を調べる。
数字を分析する。
システムを設計する。
実装する。
人前で説明する。

という一連のプロセスを経験する授業になっています。生成AIはその中で使える一つの技術でしかない。
今いくつかの大学で生成AIを利用した課題解決型の授業や生成AIのビジネス利用の授業などが企画検討され始めていまずが、大島教授の行う授業は明らかにこれらを先取りした先駆的な学びを提供されており、今後のAI教育を考えるうえでも非常に重要なポイントとなるでしょう。

ＹＩＣ情報ビジネス専門学校 非常勤講師 大島直樹氏（ 山口大学大学院技術経営研究科・ 教授）

まずは、スタートアップ企業の財務を分析する

共通課題では、架空の生成AIコンサルティング企業を題材に、収益性、安全性、効率性、キャッシュフローなどを学生が分析します。

発表では、売上高営業利益率や自己資本比率だけでなく、売掛金の回収や、「利益が出ていても現金が不足する」という黒字倒産リスクまで言及する班もありました。
つまり、単に生成AIを触っているわけではなく、事業を見るための数字を学び、その数字が何を意味するのかを考えている。

ここは個人的にも重要だと感じています。生成AIによってプログラムを書くハードルは急速に下がっている一方で、

「何を作るべきなのか」
「なぜその機能が必要なのか」
「そのサービスは事業として成立するのか」

という問いは、AIが登場しても消えません。むしろ、作ること自体が簡単になるほど、その前段階にある業務理解や課題設定の価値は高くなる。

なお、今回の財務分析については、大島教授側でシナリオなどの教材が準備されており、学生は主として分析部分を担当していました。

ですが、この授業の中心は次の自由課題にあります。

学生たちは、何を作ったのか

自由課題では、4つの班がそれぞれ異なるWebアプリを開発しています。テーマは自由。
その結果、出てきたものは単なる学習用のミニアプリではなく、実際の業務や社会課題を意識したものばかりでした。

物件情報を一元管理する不動産業務システム

最初の班が開発したのは、不動産会社などでの利用を想定した物件管理システムでした。

物件の基本情報だけでなく、価格、土地・建物、設備、販売情報、社内管理情報などを一元管理する。さらに、Excelから情報をインポートしたり、登録した情報をExcelへ出力したりできる仕組みまで実装していました。

興味深かったのは、単に「データを登録できる画面」を作って終わっていなかった点で、管理者と一般社員で権限を分け、管理者からの招待によって新規ユーザーを登録する仕組みや、招待リンクの有効期限、ログイン失敗時のアカウントロックなど、セキュリティについても設計しています。データベースにはSupabaseを利用。

学生の作品というと、ついUIの完成度や機能数に目が行きがちですが、この発表で興味深かったのは、「会社で実際に使うなら何が必要か」という視点まで入り始めていたことでした。

既存サービスの不満から作ったレシピ共有アプリ

別の班が開発したのは、レシピを投稿・共有するWebアプリです。

この班は最初に既存のレシピサービスを調べ、そこで検索のしにくさや投稿者への質問手段、評価・リアクション機能などに改善余地があると考えました。そのうえで、タグ検索、コメント、レビュー、いいねなどを備えたレシピ共有サイトを作っていました。

ここで重要なのは、完成したWebサイトそのものよりも、その前段階にある

既存サービスを見る。
不満や不足を見つける。
自分たちなりの改善案を考える。
それを機能として実装する。

これは、そのままプロダクト開発の基本的なプロセスでもあります。

「自由にアプリを作ってください」と言われたときに、単に思いついたものを作るのではなく、既存サービスとの比較から出発している点は興味深いといえます。

物流現場を想定した配送・在庫管理システム

3つ目の班が取り組んだのは、配送と在庫を管理する業務システムです。

この班は事前に物流現場について調査し、配送状況と在庫管理が別々のシステムで管理されていることや、配送時の注意事項の見落とし、再配達などを課題として設定しました。そこで、CSVによる配送データの一括読み込み、配送ステータスの管理、未完了案件の絞り込み、KPIダッシュボード、在庫不足アラートなども実装。さらに、AIを使って配送時の注意事項を解析し、優先度やリスクを判定する機能まで組み込んでいました。
フロントエンドはHTML、CSS、JavaScript。バックエンドにはSupabaseを利用しています。

個人的には、この班のテーマ設定はかなり面白く感じました。学生にとって、物流の業務システムは決して身近な題材ではないはずです。

それでも業界について調べ、課題を仮説として設定し、それをシステムに落とし込んでいる。
もちろん、実際の物流現場へ導入するとなれば、さらに多くの検証が必要になります。たとえば、配送員がリアルタイムにステータスを更新してくれるのか、現場でスマートフォンから簡単に操作できる必要はないか、などそうした論点は残ります。

しかし、それこそが次の学びにつながる。

作って終わりではなく、「実際に使われるためには何が足りないか」を考える。

システム開発の学習として、とても重要なプロセスではないでしょうか。

気象庁のデータをGeminiに渡す「AI天気アプリ」

最後の班が開発したのは、気象情報をまとめて表示するWebアプリです。

一見すると、天気アプリ自体は珍しいものではなかもしれません。しかし、その裏側の構成が面白い。気象庁から天気や警報・注意報などのデータを取得し、JavaScriptでデータを処理し、その情報をGemini APIへ渡す。そしてGeminiから、その日の天候に応じたアドバイスや週間アドバイスを生成する。

これは現在、多くのAIサービスで使われている基本的な構造でもあります。

さらに、気象庁から取得したJSONデータを扱いやすい形へ変換したり、ユーザーが最後に選択した地域をローカルストレージへ保存したり、Gemini APIの利用制限に到達した際の挙動まで考えていました。

ここで重要なのは、Geminiを“使う側”ではなく、“システムに組み込む側”へ進み始めていることではないでしょうか。

生成AIとの付き合い方が、一段変わっていることがわかるかと思います。

本当に重要なのは、完成したアプリではない

今回の発表において最も重要なのは、完成したアプリの完成度そのものではありません。学生たちは、アプリ制作を通じて、

・市場や業務を調べる。
・課題を見つける。
・必要な機能を考える。
・UIを作る。
・データベースを扱う。
・APIを接続する。
・生成AIを組み込む。
・チーム内で役割分担する。
・人前で説明し、フィードバックを受ける。

という一連の経験をしています。実際、班内では開発、スライド作成、企画、フィードバックなどを分担していました。

大島教授は、今後はさらにソースコードの担当箇所を分け、最後に統合するような開発にも挑戦すべきであるともお話しされていました。

ここまで来ると、「学生が生成AIを使っている」という表現はもはや不適切であり、

AIを前提としたものづくりの経験を持った学生が、社会に出始めている。

そう表現した方が適切ではないでしょうか。

そして、この学生たちは企業に入ってくる

ここから先は、学生ではなく企業側の問題です。

こうした経験をした学生が企業へ入社したとき、そこで生成AIが禁止されていたり、著しく利便性が低い生成AIが導入されていたときどう感じるでしょうか。

どれだけ生成AIを利用しても評価されなかったら。

新しいツールを試すために何段階もの稟議が必要だったら。

業務改善を提案しても、「昔からこの方法だから」で終わってしまったら。

自分より生成AIを使えない上司から、「若手はまず言われたことを覚えればいい」と言われたら。

もちろん、すべての若者が高度なAI活用スキルを持って入社してくるわけではありません。今回見た学生たちだけをもって、若者全体を語ることもできません。それでも、こうした教育を受けた人材が確実に存在し始めていることは、企業側も認識しておく必要があります。

これまで企業は、「若者に何を教えるか」を考えてきたはずです。しかし、これからはそれだけではなく

「すでに新しいスキルを持って入ってくる若者を、会社側がどう活かせるか」

という問いが加わるのではないでしょうか。

AI時代の人事制度は、生産性だけの問題ではない

企業にとって生成AI活用というと、どうしても

「何時間削減できるか」
「何人分の業務を効率化できるか」

という生産性の議論になりやすい。

もちろん、それも重要です。しかし、人材という観点から見ると、もう一つ大きな問題が

AIを使える人材を、正しく評価できるのか。

たとえば、同じ仕事を8時間かけて完成させる社員と、生成AIや自動化を組み合わせて2時間で終わらせる社員がいたとしましょう。後者に空いた6時間分の仕事を追加するだけでは、いずれ優秀な社員ほど損をする制度になる。

一方で、AIを使って成果を出したこと自体を評価するだけでも十分ではない。

重要なのは、

どのような課題を見つけたのか。
どのようにAIを使ったのか。
人間が判断すべき部分をどう切り分けたのか。
その結果、組織にどのような価値を生み出したのか。

まで評価できる仕組みです。

同時に、社内教育も変わります。「ChatGPTの使い方研修を全社員に一度実施しました」だけでは、これからの若手社員にとって魅力的な環境とは言えなくなる可能性があります。

むしろ、

新しいAIを自由に試せる。
APIや自動化まで学べる。
改善案を実際の業務に実装できる。
若手でも良い提案なら採用される。

そうした環境そのものが、企業の採用競争力になっていくのではないでしょうか。

「AIを教える会社」から「AIを使える人が働きたい会社」へ

生成AI時代の人材育成について話すとき、企業はつい、「社員にどうAIを学ばせるか」から考えることが多いです。

ですが今回の成果発表を見ていると、その前提そのものを変える必要があるように感じたのではないでしょうか。
教育現場ではすでに、データベースやAPI、生成AIを組み合わせながら、自分で課題を考え、それをサービスとして形にする経験を持つ学生が生まれています。

今後、こうした人材は少しずつ増えていくことは明らかです。そうなったとき企業に問われるのは、若者にAIを教えられるかではなく

その能力を正しく評価できるか。

さらに伸ばせる環境を用意できるか。

そして何より、

「この会社で働きたい」と思ってもらえるか。

生成AIへの対応が遅れることは、単なる業務効率の問題だけではありません。
人事評価、社内教育、採用、そして組織文化など、AI時代への対応は、すでに企業の人材戦略そのものに入り始めており、対策が遅れれば取り返しのつかない可能性が高いと言えるでしょう。

writer：宮﨑 佑太