この実践報告は、ソフトウェア開発のプロジェクト型学習（PBL）科目に 仕様駆動開発 を導入した取り組みを記述している。対象は大阪工業大学情報システム学科の 3 年生向け選択科目「情報システム開発演習」で、全 14 回の講義のなかで 3〜4 人のチームが Java と Spring Boot を用いてデータベースを備えた Web アプリケーションを構築する。著者らは仕様駆動のワークフローを、調査、計画、実装、レビューの 4 つのフェーズに適応させ、各ステップで AI エージェントが成果物を生成するようにした。著者らが述べる適応の内容は 2 点ある。1 つは、既存のワークフローの要求分析フェーズと設計フェーズを単一の調査フェーズとして再定義したことで、新しい要件だけでなく機能追加やデバッグも扱えるよう一般化するという理由による。もう 1 つは、実装が仕様に合致しコーディング規約に従っていることをエージェントと学生の双方が確認する、明示的なレビューフェーズを追加したことである。
報告では、ワークフローと同じくらい科目の基盤環境も主題となっている。各チームには Visual Studio Code 用のテンプレートプロジェクトディレクトリが配布された。そこには、ワークフローとプロジェクト固有のルールをカスタム指示として記述した copilot-instructions.md ファイル、specs.md と tasks.md に加えて対応するレポートを置く investigate/、review/、done/ の各ディレクトリを含む reports/ サブツリーを持つ docs/ ディレクトリ、そしてチームが独自の Spring Boot プロジェクトを作成する NewSpringBootProject/ ディレクトリが含まれる。教員は GitHub Copilot のエージェントモード、バイブコーディング、仕様駆動開発についての講義を行ったうえで、ワークフローの 1 サイクル全体を学生の前で実演した。本研究は 2025 年 11 月から 2026 年 1 月までのチームの活動を 3 つの軸で分析している。フェーズごとの AI 利用度の週次自己申告（5 段階）、チームの Git リポジトリからマイニングした講義ごと・学生ごとの追加コード行数、そして教員が 1 対 1 の面談で 4 段階で評価したコード理解度である。
要点
- AI の利用パターンはフェーズやチームによって大きく異なったと報告している。ソースコードの作成と理解に関わる実装フェーズとデバッグフェーズでは、すべてのチームが何らかの程度で AI を使っていた。一方、調査フェーズと計画フェーズでは利用度がチーム間で大きく異なり、レビューフェーズではどのチームもあまり AI を使っていなかった。
- 対象とした 4 学年度を通じて実装のスループットが向上したことを見出している。追加コード行数に対する Steel-Dwass 検定では、8 回の講義のうち 7 回で学年度間に統計的に有意な差が見られ、前の年度（2022 年、2023 年）は後の年度（2024 年、2025 年）より一貫して低く、後の年度が有意に低かった例は 1 つもなかった。著者らはこの傾向を、LLM 技術の普及と時期的に対応するものと述べている。
- 0〜4 の尺度で AI 利用レベル 0 の学生、すなわち AI を使わずにコードを実装した学生は、理解度分析が対象とする 3 つの期間すべてで一貫して高いコード理解度を保っていたこと、そしてレベル 3 の学生は、特に中盤の期間（第 9〜10 回講義）に、ほとんど理解しないままコードを実装していたことを報告している。
- それでも、学生全体としては AI 利用レベルとコード理解度の間に明確な統計的傾向は確認されなかったと述べ、その理由を、サンプルサイズの小ささ、個人差の大きさ、そして教員自身による適時の介入が影響した可能性に帰している。
- その介入効果の一例として観察された 1 つのサイクルを記述している。AI 利用がピークに達した講義で理解度のスコアが低下し、教員の支援を受けた翌週には理解度が目に見えて回復した。
- 教員向けに 3 つのアプローチを推奨している。1 つ目は基礎優先のアプローチで、全 14 回のうち最初の 5 回で、AI ツールを本格的に使う前に Web アプリケーションとチーム協働の基礎を扱う。2 つ目は、理解度の低下を早期に検出するための継続的なモニタリングと適時の介入である。3 つ目は AI 生成コードに対する説明責任で、学生は自分の手で書いていないコードについても、その背後にあるロジックを説明できることが求められる。
- アプリケーション開発のスキル育成を目的とする科目には、バイブコーディングよりも仕様駆動開発のほうが適していると論じている。学生は仕様を理解し、ドキュメントとソースコードの両方を含むエージェントの出力に責任を持たなければならないからであり、著者らはそれゆえ 2 つのうち仕様駆動開発のほうが要求水準が高いと述べている。
- 標準化されたプロジェクトテンプレートは、学生が AI エージェントを使った開発を円滑に始める助けになったようだと報告し、それが 2 種類の対象に同時に役立つと示唆している。経験の浅い学生にとっては指示をどう構造化するかの具体例として、すでにツールに慣れた学生にとってはカスタマイズの土台としてである。
補足
著者らは、知見そのものに関わる 3 つの限界を示している。AI エージェントを使わない同時期の対照群は存在せず、比較は 2022 年から 2024 年の過去のコホートに対するものである。そのため、学生の能力の年度ごとのばらつき、コホート規模の違い（受講者は 2022 年が 38 人、2023 年が 28 人、2024 年が 25 人、2025 年が 14 人）、教育環境の変化を交絡要因として排除できない。追加コード行数は開発効率の部分的な代理指標にすぎず、設計の質、リファクタリング、冗長なコードの削除を捉えられないことも認めている。また、理解度スコアは客観的なテストではなく教員の主観的な評価に基づいている。著者らはこれを、対話を通じて理解の深さに迫るための方法として擁護する一方で、厳密さが損なわれることも認めている。本研究は Java と Spring Boot を用いた 4 チームの単一科目を対象としているため、著者らはこれを一般化可能なものではなく、同様のプロジェクト型科目にとって参考になるものとして提示している。
報告は最後に、今後の研究の方向性として 3 つを挙げている。AI 生成コードに対する学生の理解を評価し向上させる効果的な方法の開発、AI による支援と学習成果のバランスをとるワークフローの検討、そして AI エージェントへの早期の接触が長期的なソフトウェアエンジニアリングのスキルにどう影響するかについての縦断的研究である。