近年，研究活動に生成AIを積極的に取り入れることで，作業の効率化や属人性の排除が進み，研究全体の進行が以前よりもスムーズになってきている．一方で，生成AIの出力には，もっともらしく見える誤り，いわゆるハルシネーションが含まれる可能性が常に存在する．そのため，生成AIによる回答を鵜呑みにするのではなく，逐一，内容を確認し検証する壁打ち作業が欠かせない．結果として，研究者はAIの補助を受けつつも，人間による批判的思考や判断力がこれまで以上に求められる状況となっている．

本稿では，大学生及び大学院生の活動において生成AI（LLM: 大規模言語モデル）がどのように活用されているか，研究活動並びに研究以外の活動にも焦点を当て，その具体的な事例を紹介する．また，LLM導入前後で大学生の生活にどのような変化が生じたのかについて，アンケート調査に基づく分析結果を示し，生成AIが研究現場や日常生活にもたらす利点と課題について考察する．

本章では，9件の大学生及び大学院生のLLMの活用事例を，以下の9節にかけて紹介する．なお，各節における一人称（語り手）は全て異なる人物であり，本解説記事の筆者とも異なる点に注意されたい．

2.1　事例A ～論文記載のコードの再現とエラー特定及び修正～

LPWA（Low Power Wide Area, 用語解説（1））の通信システムの一つであるLoRaWANで採用されているチャープスペクトル拡散（CSS, 用語解説（2））変調方式を，Pythonを用いて実装した．（生成AIに実装させた．）

実装にあたっては，サーベイ論文（1）や関連Webサイトにおける送受信処理の説明箇所や式番号を指定し，それらを参照させることで，送信チャープ及び受信チャープの生成，変調・復調処理をコードとして出力させた．更に，生成した変調信号のスペクトログラムを表示（図1）させ，ビット誤り率（BER）の評価も実行させた（図2）．

開発過程では，コンパイルエラーや実行時エラーが発生したため，生成AIに対して原因の特定と修正を行わせ，動作の安定化を図った．また，無雑音環境にもかかわらずビット誤りが生じる問題が確認されたため，復調アルゴリズムやチャープ生成部のロジックを再度検証し，コードの修正を進めた．その結果，基本的なLoRa変調・復調の流れをPythonで再現することができた．

使用ツール: Gemini Pro 学生ライセンス

図1　LLMが出力したコードの実行例
（変調信号のスペクトログラム．周波数偏移量を200 kHz，シンボル長を約10 msで設定．白点線がシンボルの境界を示す．）

図2　LLMが出力したコードの実行例（SN比に対するビット誤り率）

2.2　事例B ～追跡アルゴリズムの再現～

到着時刻差（TDoA）を観測値とする三次元測位アルゴリズムを，拡張カルマンフィルタ（EKF，用語解説（3））を用いて実装させた．まず，アンカー局の座標を与えた上で，移動体の軌跡に対応する人工的なTDoA観測値を生成し，これをEKFの入力として利用した．

次に，状態遷移モデルや観測モデルを含むEKFの核となる計算部及び関連パラメータ（状態ベクトル，ヤコビアン（図3），共分散行列など）を文献（2）を参考にして生成AIに導出させ，滑らかに追跡できるよう調整を試みた．しかし，得られたEKFによる推定軌跡は，移動体が不自然な回り道をするなど，期待される挙動とは大きく異なり，追跡性能が十分ではなかった（図4）．

このため，最終的には人間側でコード全体を再点検し，モデル式や線形化手順，共分散更新処理などに誤りがないかを精査する必要があった．

使用ツール: ChatGPT

図3　LLMが出力した関数コード

図4　LLMが出力したコードによる三次元の動態追跡．黒: 実際の軌道，赤: 予測させた軌道．

2.3　事例C ～非線形増幅の再現～

4G LTEや5Gに代表される周波数多重信号が，非線形応答を持つ素子（増幅器など）を通過した際に発生する相互変調ひずみ（IMD）をスペクトル上で可視化するため，信号生成から非線形処理，周波数解析まで一連の処理を実装させた．

まず，マルチキャリヤ信号の変復調に関する論文（3）をAIに検索させ，実装の参照となる式番号やアルゴリズム部分を特定した上で，必要な信号処理ブロック（OFDM信号生成，PA モデル，FFT解析（図5）など）のコーディングを段階的に指示した．

実装の過程では，無雑音かつ線形応答の条件下であるにもかかわらず，誤差ベクトル振幅（EVM，用語解説（4））が理想値と一致しない現象が生じたため，その原因をAI に解析させた．サンプリング設定や正規化処理，I/Qバランス（図6，用語解説（5）），FFTのウィンドウ処理など，信号品質を左右する要因を切り分けさせ，問題点の洗い出しを行った．

また，複数の処理を繰り返し利用できるよう，信号生成，非線形応答，スペクトル計算などを関数化する際には，引数の型や意味，戻り値の仕様を明確に定義させ，コードとして再利用性の高い構造に整理させた．

使用ツール: Claude

図5　解析させたパワースペクトルとEVM

図6　LLMの出力コードの実行例（IQダイヤグラムの正規化）

2.4　事例D ～論文からの既存手法の実装～

ChatGPTを用いて，自身の研究に関連する先行研究の手法の実装を試みた．私は深層学習における学習率の動的最適化手法であるHD手法（4）に着目し，その改良に取り組んでいる．対象論文を精読して内容を理解した後，当該手法の実装に着手し，その過程において大規模言語モデル（LLM）を活用した．

まず，当該論文（4）のPDFファイルをLLMに入力し，自身の理解を確認する目的で，アルゴリズムの概要を日本語で説明させた．次に，同アルゴリズムをPythonコードとして出力させ，その際には可読性向上のため，詳細なコメントを付与するよう指示した．

続いて，LLMが出力したアルゴリズムの説明及びPythonコードの検証を行った．具体的には，出力されたコードを自身の実行環境で実行し，エラーが発生した場合には，そのエラーメッセージをLLMに入力して原因の分析及び修正案の提示を求めた．また，LLMによるアルゴリズムの説明が論文の記述と整合しているかについても確認し，説明内容の妥当性を検証した．

この検証作業の後，再度コード生成の工程に戻るという試行錯誤を繰り返し，最終的に論文PDFの入力から1日以内に，動作するPythonコードの実装案を得ることができた．特に時間を要したのは，LLMの説明内容や生成コードの正確性を検証する作業であり，いわゆるハルシネーションへの対応であった．

その後，得られた実装の正当性について更に検証を進めていたが，この段階で筆者らによる公式の実装ソースコードが公開されていることに気付いた．そのため，本実装は最終的には採用に至らなかった．出力されたプログラムの正しさを厳密に検証するという，重要かつ高負荷な作業までは実施できていないものの，論文PDFの入力から1日以内に実装案を得られた点は，LLM活用の有効性を示す結果であると考えられる．

2.5　事例E ～Linux ライブラリの改変～

Linux OSにおけるメモリ管理ライブラリ（malloc，mi_mallocなど）の性能向上を目的とし，その実装改善の過程において大規模言語モデル（LLM）を活用している．

使用したLLMは，Gemini 2.5 Pro及びChatGPT 5の2種類である．これらを区別するため，以降，一方をLLM-A，もう一方をLLM-Bと表し，両者の対応関係は固定しない．

メモリ管理ライブラリの実装を改変するためには，対象となる大規模なソースコード群の理解が不可欠であり，特に，改変対象とする機能がソースコード中のどの箇所に実装されているかを特定する作業に多大な時間を要する．そこで，この作業を支援する目的でLLMを活用した．具体的な手順を，ソースコードの理解，ソースコードの改変，実装の順に述べる．

2.5.1　ソースコード理解のための手順

① 複数ファイルの1ファイルへの結合

対象となるC言語のソースコードは複数のファイルから構成されているため，これらを一つのファイルに結合した．多くのLLMでは同時にアップロード可能なファイル数に制限があるため，入力ファイル数を削減する必要がある．また，ソースコードの理解にはディレクトリ構成の情報も重要であることから，構造が分かる形式で統合を行った．

具体的には，複数のソースファイルをLLMが扱いやすい形式に変換するWebサイト（5）を利用し，ファイル群を一つのMarkdown（md）ファイルに変換した．

② システムプロンプトの作成

LLMに対するシステムプロンプトには，「人間にとって分かりやすく解説すること」「英語で推論し，日本語で出力すること」「要点を簡潔にまとめること」などと入力した．

③ ユーザプロンプトの作成

ユーザプロンプトでは，対象となるソースコードを分析し，特定の機能がどこに実装されており，どのような挙動を示すのかを説明するよう指示した．ここで指定する機能は，その時点で改変を検討している機能とした．

④ LLMへの入力と結果の取得

①～③の内容をLLM-Aに入力し，ソースコード解析結果を取得した．

2.5.2　ソースコード改変におけるLLM活用手順

ソースコードの理解後，多くの場合は実際の改変作業に進む．この過程においてもLLMを活用した．

⑤ 計画立案及び要件定義

④で得られた出力内容を基に，改変に関する計画立案及び要件定義を研究者（私）自身が行った．

⑥ 計画・要件のレビュー

①のソースコード及び⑤で定義した計画・要件をLLM-Bに入力し，内容の妥当性についてレビューを行わせた．この際，計画に問題がある場合には修正案の提示を求めた．本件では，実装を担当するLLMとは異なるLLMに計画をレビューさせることで，品質向上が期待できると考え，この手順を採用した．

⑦ 計画・要件の修正

レビュー結果に問題点や改善点が含まれていた場合には，⑤に戻り，計画及び要件を修正した．問題が認められなかった場合には，以下のいずれかの実装手順に進んだ．

2.5.3　実装手順

（ケースA）LLMによる実装

⑧ テストプログラムの作成

研究者（私）自身がテストプログラムを実装した．

⑨ LLMによる実装

①，⑤，⑧の内容をLLM-Aに入力し，実装を依頼した．

⑩ テスト及び修正

LLMが出力した実装をテストプログラムで検証し，誤りが確認された場合には，エラーメッセージをLLMに入力して修正を依頼した．この工程を誤りが解消されるまで繰り返した．

（ケースB）研究者自身による実装

⑧ 実装及び質問

研究者（私）自身が実装及びテストを行い，誤りがあれば修正を繰り返した．自力で解決できない問題が生じた場合には，LLM-Aに入力して助言や修正案を求め，完成までこの手順を継続した．

2.6　事例F ～就職活動への助言など～

私は就職活動の相談や研究にLLMを活用している．

2.6.1　エントリーシートの添削

まず，エントリーシートの添削にLLMを使用している．初めに，自身で一度文章を書き切る．この段階では，完成度が低くても構わない．次に，その文章をLLMに入力し，より自然で読みやすい表現に整えるよう依頼する．使用するプロンプトは「エントリーシートの文章を添削して下さい．〈以下 本文〉」といった簡単なものである．

LLMが修正案を提示した後は，その内容を基にLLMと対話しながら文章をブラッシュアップしていく．具体的には「私が伝えたいことはOOOであり，XXXではありません」「A社はX，Y，Zという考え方を重視しています．これらの語を直接用いずに，意味として反映させた文章にして下さい」「私は〇〇の研究を行っているため，それを主軸とした志望動機に修正して下さい」といった依頼を行った．

文字数制限がある場合には「〇〇字以内にして下さい」と指示して添削を依頼する．ただし，文字数に関してはハルシネーションが発生しやすいため注意が必要である．例えば，「300文字程度」と依頼した場合でも，200文字程度の文章が生成され，「これは297文字です」といった誤った主張がなされることがある．そのため，LLMの出力を鵜呑みにせず，必ず自身で文字数を確認するようにしている．

2.6.2　面接対策

面接対策には，ChatGPTの音声モードを使用している．まず，自身が志望動機及びその考えに至った経緯を説明すると，LLMが面接官役として「入社後に何をしたいですか」といった質問を提示する．それに対して回答を行い，その後，LLMからコメントや助言を受け取る．

具体的には「話す際に『えー』『あー』といったフィラーが多い」「〇〇の説明は分かりやすいが，△△の説明は分かりにくい」といったフィードバックが得られ，話し方や説明内容の改善に役立てている．

2.6.3　Linuxカーネルソースコード理解の補助

研究においてLinuxカーネルのソースコードを改変しているが，カーネルは規模が大きく，使用されているデータ構造も複雑であるため，理解が困難である．

そこで，関連すると考えられる構造体を全てLLMに入力し，「入力した構造体群の関係をUML（Unified Modeling Language）で表現して下さい」と依頼することで，UML図の案を生成させている．その後，必ず得られたUML図を基に，自身でソースコードを参照しながらポインタの関係を追跡し，内容の確認を行っている．LLMが生成するUML図には誤りが含まれる確率が高く，正しい図が得られる割合は，筆者の体感では1割未満である．

誤りを発見した場合，LLMに指摘して修正版を生成させることも可能であるが，本研究ではそのような「指摘と修正」の反復は行っていない．代わりに，LLMが生成した初期案を研究者（私）自身が修正し，必要に応じて拡張して利用している．すなわち，LLMは最終成果物を生成するためのツールではなく，「初期案を作成するための補助ツール」として位置付けている．

2.7　事例G ～目上の人に送る文章の添削～

私は目上の人にメールを送る際，敬語の使い方が適切であるか，失礼な表現になっていないか，また相手に不快感を与えるおそれがないかといった点について，LLM（ChatGPT）に確認を依頼している．

2.8　事例H ～商品比較～

私は買い物をする際，商品の比較表の作成を生成AIに依頼している．例えば，楽器用キーボードを購入する場合，まず候補となる商品をLLMに5点提示させる．次に，それらのキーボードについて，価格，大きさ，重量，鍵盤数，音色数，端子の種類（MIDI入出力，USBのタイプ，イヤホンジャックなど）といった項目を基に，比較表を作成させている．

2.9　事例J ～学習支援～

私は授業中に理解できない用語が出てきた際，その意味を調べるためにLLMを活用している．例えば，機械学習の授業で「クラスタリング」という用語が登場した場合や，ディジタル符号や確率統計の授業で「最小多項式」や「生成多項式」といった用語が登場した際に，意味が分からなかったため，LLMに説明を求めた．

LLMの解説は理解の助けになると感じているものの，不十分なことも多い．しかし，Wikipediaなどと比べて，LLMは自分の疑問点に焦点を当てて説明してくれる点が優れていると感じている．

LLMの主要な利用状況，月額支払額，及びLLMの普及が情報源として広く利用されるWikipediaの利用頻度に与えた影響を分析することを目的とし，大学生と大学院生を対象にアンケート調査を行った．

79件の集計を図7にまとめる．回答者の過半数である42件（53.2 %）がChatGPTを主として利用している．次いでGeminiが25.3 %（20件）を占めており，この二つのLLMが大半を占有している．「ほとんど使っていない」と回答した層は15.2 %（12件）であり，調査対象者の大半が何らかの形でLLMを利用している実態が確認された．ClaudeやCopilotといったそのほかのLLMの利用率は低い水準にある．

回答者の約76 %（60件）がLLMサービスに対して費用を支払っていないと回答しており，LLMの利用は無料プランが主流であることを示している．有料ユーザの中で最も多い層は，毎月1,000円以上4,000円未満を支出している層（21.5 %，17件）であった．この金額帯は，ChatGPT Plusなどの主要な有料プランの価格帯と一致する．月額4,000円以上の高額な支出をしているユーザはまれである．

Wikipediaの利用量の変化について最も多かった回答は「ほぼ変わらず（前後ともに少ない）」の39.2 %（31件）であった．これは，LLM登場以前からWikipediaの利用頻度が低かった層が一定数存在することを表す．「大幅に減った」（30.4 %，24件）と「小幅に減った」（11.4 %，9件）を合わせると，回答者の41.8 %（33件）が利用頻度の減少を経験している．この結果は，LLMが迅速な情報検索・要約機能を提供することで，従来のWikipediaを利用した情報収集の一部を代替している可能性が高いことを示唆する．利用頻度が「増えた」層（小幅増＋大幅増）は合計で7.6 %（6件）にとどまっている．

本調査の結果，LLM利用はChatGPTとGeminiに集中し，無料利用が圧倒的多数を占めることが判明した．更に，LLMの普及はユーザの情報探索行動に顕著な影響を与えており，Wikipediaの利用頻度が減少した層が全体の4割以上に達するという結果が得られた．これは，LLMが特定の情報探索ニーズにおいて，Wikipediaよりも優位な手段として認識されつつある現状を裏付けるものである．

図7　アンケートの集計結果　Q1: 主として使用しているLLMは？　Q2: LLMへの月額支払額　Q3: LLM導入前後におけるWikipediaの利用頻度の変化

本解説記事では，急速に普及が進むLLMに着目し，大学生及び大学院生による活用事例を紹介した．具体的には，研究活動における活用の方法，達成可能なことや限界，必要な作業，直面する課題などを紹介した．紹介したLLM利用の壁打ちでは，ある程度のコーディング能力を有する人間が，作業時間の短縮を目的として，自作コードの点検や修正にLLMを活用している実態を示している．併せて，アンケート調査の結果から，活用の広がりを定量的に示した．新たなテクノロジーの未来は，若い世代が切り開いていくことが多い．本記事で紹介した事例が，読者の皆様にとって今後のLLM活用のヒントとなれば幸甚である．

全文 PDFはこちらから