Google、教員の一言から対話型シミュレーションを生成：GeminiがUIを作成し、4種の自動検証で品質を担保、最後は教員がチェック

オンライン教科書から動画ライブラリに至るまで、デジタル教育ツールは生徒の情報アクセスのあり方を大きく変えてきた。しかし多くの場合、デジタル学習はいまだに受動的な体験にとどまっている。生徒は画面の前に座り、「次へ」をクリックし続ける。一見学習しているように見えても、その思考は受動的に情報を受け取る状態のままだ。

認知科学分野で広く知られる ICAP フレームワーク——学習行動を浅いものから順に受動的（Passive）、能動的（Active）、建設的（Constructive）、対話的（Interactive）の4段階に分類する枠組み——は、自ら手を動かして変数を調整し、即時フィードバックを観察できる「対話型学習」が、概念モデルの構築や長期記憶の定着において、受け身の講義聴講よりもはるかに優れた効果を発揮することを早くから実証してきた。物理シミュレーション実験のような対話型ツールは、従来その多くが専門の開発チームによるコードの特注開発を必要としていた。開発期間が長くコストがかさむだけでなく、教員がその日の授業の進度に合わせて変数を微調整することも困難だった。

Google Research は最近、「学習インタラクティブ（learning interactives）」と名付けられた研究実験を公開し、大規模言語モデルを活用してこの現状を変えようと試みている。教員が教科、学年、授業テーマを入力するだけで、システムが Gemini をベースに、ステージ課題、操作スライダー、データグラフ、ヒントやフィードバックを備えたWeb対話型シミュレーションを自動生成する。

近年フロントエンド分野で注目を集める「生成 UI（generative UI）」——あらかじめ書かれた静的コードを呼び出すのではなく、AIが対話の意図に基づいてUIコンポーネントを動的に構築する技術——を教育現場へそのまま持ち込む試みは、想像ほどスムーズには進まなかった。付属の技術報告書は、極めて直感的な数字を提示している。事前の指導計画が万全に整っていたとしても、UIの初回の生成で全検査項目に合格できる割合はわずか 3.5% にすぎない。

なぜ既存の生成 UI をそのまま授業に使えないのか

報告書の説明によれば、既存の生成 UI が得意とするのは主に使い捨てのウィジェット的コンポーネント（widget-like components）であり、多段階で構造化された教育シミュレーションの作成には向いていない。

教室の現場に持ち込み、大規模言語モデルに直接「物理実験のUIを書いてくれ」と指示すると、さらに2つの壁に突き当たることになる。

第1の壁は、認知的オフロード（cognitive offloading）だ。大規模言語モデル本来の設計目的は、ユーザーの手間を省き、最小の労力で答えを導き出すことにある。しかし学習のプロセスには、まさに適切な「認知的抵抗」が不可欠となる。生徒自身が論理を導き、試行錯誤し、壁にぶつかり、調整を繰り返すプロセスを経て初めて、知識の背後にあるメカニズムを真に理解できるからだ。もし AI が作成したUIがあまりに親切で、解法の近道をそのまま手渡してしまうと、生徒は思考のプロセスを機械へ外部委託してしまい、表面上は操作を完了していても、脳内では知識の構築が行われない。その一方で、認知科学の研究は、一切の案内を与えない「純粋な発見学習」がほぼ効果を持たないことを示している（Kirschner、Sweller、Clark 2006）。能動的な学習には明確な足場かけと指導が欠かせず、それこそが教室において本来教員が担ってきた役割である。

第2の壁は、動的シミュレーションにおける物理的・教育的厳密さだ。優れた教育用インタラクティブ練習であるためには、バックエンドのロジックが正確な科学法則に従い、UI上の数値スライダーの変更がリアルタイムにグラフへ反映され、さらにステージの目標が数学的・物理的に「実行可能な解を持つ」ことが保証されていなければならない。一般的な生成系大規模言語モデルがコードを記述する際、往々にして見落としがちな不具合を生じさせやすい。例えば報告書に記録されているある化学インタラクティブ練習では、基本的なレイアウトには問題がなかったものの、フラスコを置く実験台が画面の枠外にはみ出し、データ読み取りパネルがシミュレーション対象の一部を覆い隠してしまっていた。さらに深刻なケースでは、ステージ目標の達成が原理的に不可能なことさえあった。

単一のプロンプトだけに頼ってモデルに自由裁量を与えてしまうと、教育ソフトウェアは制御不能な未完成品に成り下がってしまう。

4つの段階への分解：指導要領をステージクリア型ゲームへ

生成されるUIに教育的価値を持たせるため、研究チームは構築プロセスを相互に連携する4つの段階へと分解し、テキストによる構想、ステージ設計、コード実装、そして学習支援の各フェーズの間に幾重もの安全柵を設けた。

この一連のプロセスにおいて、教員は常に主導権を握り最終確認を行う中核的な位置にいる。まず教員がリクエスト（教科、学年、テーマを含み、追加の要望を付加することも可能）を発行する。続いて AI が具体的な学習目標を生成し、教員がこれを確認して自由に修正する。承認された目標に対し、システムは1つのリクエストごとに 5 つのシミュレーション候補を生成し、報告書の設計では教員が指導意図に最も適した1つを選定する（教員12人を対象とした実証研究では、内部レビューによって最良のバージョンが選出された上で教員に提示された）。新しく生成された練習は、最終的に教員の確認を経て承認されて初めて、公式の公開ライブラリへと登録される。

段階1：シミュレーション構想（Simulation idea）。この段階は完全にテキストベースで進行する。教員が教科、学年段階、具体的なトピック（例えば高校物理の複雑な直流・交流回路など）を入力する。Gemini はまず、明確かつ測定可能な一連の学習目標を整理し、教員による確認・承認に委ねる。「この授業で最終的にどのような認識に到達すべきか」が明確になって初めて、モデルは具体的なシミュレーション場面の構想へと進む。どのような実体オブジェクトが存在するのか（パルス波形整形器や共振器など）、それらの実体間にどのような科学的法則が働くのか、どのような数値やグラフを表示する必要があるのか、生徒の操作用にどのような調整ノブを用意するのか、そして最終的なトリガーアクションは何かが検討される。

段階2：足場かけステージ（Scaffolding）。実験環境が整ったからといって、案内もなしに生徒を何もないサンドボックスに放り込むわけにはいかない。システムはモデルに対し、コアとなる概念を段階的な難易度を持つ連続した 5 つのステージへと分解させる。難易度の急激な跳躍や目標の曖昧さを避けるため、これら 5 つの目標は一度にまとめて生成されるのではなく、1ステージずつ段階的に生成される。前のステージの目標が検証を通過した後に初めて次のステージが生成され、各ステージが前のステージよりも深い思考を促しつつも、先行する前提概念の支えから逸脱しないよう厳格に管理される。

段階3：UIコード構築（Gen-UI）。前2つの段階で指導目標が完全に確定したことを前提に、Gemini は HTML と JavaScript のコード作成を開始し、抽象的なステージや制御ロジックをブラウザ上で動作する対話型インターフェースへと変換する。この段階こそが、技術実装において最も脆弱でエラーが生じやすいボトルネックとなる。

段階4：学習支援とフィードバック（Guidance）。UI自体が正常に動作することを確認した上で、システムはその外周を支える学習支援システムを追加する。このシステムには、生徒が操作に慣れるのを助ける導入ツアー（Tour）、右側のツールボックスに収められた公式や理論のリファレンス、行き詰まった際に必要に応じてクリックできる段階的なヒント、そして生徒の試行が成功または失敗した際に表示される的を絞ったフィードバックのポップアップが含まれる。

このインターフェースには、2つの重要な学習支援メカニズムが組み込まれている。

足場かけ型ヒント（Scaffolded hints）：生徒の行き詰まりの度合いに応じて、段階的な手がかりを順次提供する。例えば関連する公式へと生徒を誘導したり、特定の用語を解説したりする。ヒントは複数の階層に分かれており、生徒自身による探索を経た後に初めて、最終段階として完全な解法（worked solutions）が提示される。安易に答えを直接与えて主体的・能動的な思考を妨げてしまうのを防ぐ設計だ。

形成的フィードバック（Formative feedback）：生徒が操作を誤った際や目標を達成した際に、現在のパラメータ設定がもたらした結果の理由について原理的な解説を行う。例えば数直線の対称性に関する練習でクリアに成功した際、ポップアップは単に合格と判定するだけでなく、「青い車は +6 にあり、対称となる位置は -6 で、どちらの車も原点から 6 単位離れている」と具体的に解説する。教員からのフィードバックに基づき、不正解時にも解説付きのフィードバックを提供する機能が研究の後半で追加され（報告書セクション3.1）、生徒が試行錯誤の過程で認識のズレを修正できるよう支援している。

3.5% から 69.3% へ：コード生成における自動対抗と自己反復

第3段階（フロントエンドコード生成）において、テストデータが示した事実は衝撃的だった。学習目標、シミュレーション構想、ステージ計画が十分に検証されていたとしても、フィードバック検証を一切経ずにモデルが1回で直接出力したコードが、すべての技術的・教育的基準を満たす割合はわずか 3.5% にとどまった。

この検証基準に照らすと、1回で生成された成果物の大多数は少なくとも1つの項目で不合格となる。この課題を解決するため、研究チームは多角的な自動検証メカニズム（Auto-rater）を設計した。コードを Chrome 上で実際に起動し、4つの側面から審査を実施する仕組みだ。

• 視覚的表現（Visual）：画面枠外へのはみ出しがないか、コンポーネント同士の重なり（例えばデータパネルが実験オブジェクトを覆い隠すなど）がないか、あるいは集中を削ぐような余計な要素がないかを審査する。
• 操作メカニクス（Mechanics）：ボタンやスライダーなどの操作コンポーネントが正常に動作するかを検証する。
• データ計測・表示（Telemetry）：UI上のリアルタイムな測定数値やグラフ（例えばRC回路の過渡電圧・電流の変化を示すリアルタイム曲線など）をチェックする。
• 解法可能性の検証（Solvability）：これは技術的に最も特筆すべき工程だ。システムは専用のテスト用 Agent を起動してブラウザを開き、人間の生徒と同じようにノブを操作させ、さらにはパラメータをあえて極端な値に設定する敵対的テストを行う。これにより、現在のステージ目標が既存のUI上で本当に達成可能であるかを検証する。

いずれかの検査項目で基準に達しない場合、その指摘内容がフィードバックとしてモデルへと差し戻される。指摘に沿って修正した上で再検証を行い、全項目に合格するまでこのループを繰り返す（検証の根拠には、生成されたコード自体だけでなく、Chrome 上で実際にレンダリングされた画面も含まれる）。

この複数ラウンドにわたる自己修正ループがもたらした成果は極めて顕著だった。前提となる目標の検証が完了している条件下において、UIの総合合格率は第1ラウンドの 3.5% から中間段階の試行で 28.9% へと跳ね上がり、最終的に 10 ラウンドの自己反復を経て 69.3% に達した。

注目すべきは、この改善がすべての項目において直線的・単調に上昇したわけではない点だ。技術報告書のモニタリングデータによると：

• データ計測・表示の合格率：初期の 23.3% から着実に向上し 93.5% へ；
• 操作メカニクスの合格率：初期の 67.0% から 98.2% へ向上；
• 視覚的表現の合格率：初期の 47.8% から 84.7% へ向上；
• ステージ解法可能性の合格率：85.5% → 72.9% → 87.9% という紆余曲折をたどった。

中間段階で解法可能性が一時的に低下したことは、インタラクティブ練習の各構成要素が密接に連動しており、個別の改善が単純な積み上げにはならない（ある箇所を修正した影響が別の箇所に及ぶ）現実を物語っている。自動化環境を通じたエンドツーエンドの実機検証を行うことで、教員のレビューに引き渡す前に、数多くの潜在的な不具合を早期に洗い出すことが可能となる。

実際の効果と限界：物理・化学は真価を発揮、生物は「ページめくり」に偏る傾向

これらのインタラクティブ練習の実用性を検証するため、研究チームは教育現場の教員が参加する2つのグループ評価を実施した。

第1の評価グループは、米国の現役 STEM 教員 12 人を対象とした。各教員が自身のクラスの指導ニーズに合わせて 3 つのカスタムテーマを提出し、システムは計 36 件の生成リクエストを受け付けた。教員に提示された学習目標は、その大多数がそのまま承認され、修正が求められた場合も軽微な変更にとどまった。バックエンドでは、システムがリクエストごとに 5 つの候補案を生成し、内部レビューによって最も品質の高い1つが選定されて教員に提示された。これら 36 件のリクエストのうち、基本的な品質基準を満たせなかった 3 件は内部審査の段階で除外され、最終的に 33 件が提示された。

テストに参加した教員によるこれらシミュレーションのユーザビリティ（usability）に対する評価スコアはすべて 7 点以上で、平均は 8.1 点を超えていた（10 点満点。公式ブログでは教員が「品質」に平均 8 点を付けたと要約されているが、技術報告書の原文で評価されているのはユーザビリティである）。教員からの定性的なフィードバックでは、このツールの最大の価値は個別最適な指導（生徒に応じた調整）を実現できる点にあると広く言及された。従来の市販の教育シミュレーションは固定されたソフトウェアがほとんどで、教員は生徒ごとの習熟度の違いに応じてパラメータや難易度の傾斜を調整できなかった。それに対し本システムはクラスのペースに合わせたオーダーメイドが可能であり、組み込まれた段階的ヒントは授業中に教員が個別指導で手一杯になる負担も軽減した。一方で、研究に参加した数名の教員からは当時の課題も指摘された。リクエストをカリキュラム標準と整合させる必要がある点や、誤った試行に対する解説フィードバックの不足（のちに補完された）などが挙げられている。

第2の評価グループでは、教育専門家が策定した 40 の STEM 課題を対象とした。対象範囲は小学校高学年から大学学部レベルにまで及ぶ。自動検証を無事に通過した各インタラクティブ練習は、該当教科を担当する英国の専門教員2人によって独立してレビューされた。厳格な検収基準のもとで、インタラクティブ練習の全体合格率は 86% に達し、各詳細指標の多くが「良好」または「優秀」の範囲に収まった。

もっとも、教科間での効果の差は極めて顕著だった：

物理と化学が最も優れた成果を示した。衝突の法則、放物運動、あるいは理想気体の状態方程式など、それらの核心となる概念は厳密な数式や連続的な数値変数に本質的に依存している。「スライダーを動かしてパラメータを調整し、グラフの動的な反応を観察する」というシミュレーションの仕組みと極めて相性が良く、評価スコアも「優秀」に最も近かった。

生物分野は最も振るわなかった。UIの操作体験や視覚的な美しさにおいて、生物の練習に対する評価は明らかに後塵を拝した。その要因は、細胞周期やセントラルドグマといった中等教育レベルの生物知識が、定性的なメカニズムや形態の記憶を中心としており、連続的な数学的支配方程式を欠いている点にある。モデルがこの種のコンテンツを生成する際、自然なインタラクションのメタファーを見出すのが難しく、結果として静的な概念を順番に並べただけの「ページめくり教科書」へと形骸化しやすく、真の対話型学習の面白さが失われてしまった。

教科による向き不向きの偏りに加え、本研究には直視すべき根本的な限界が存在する。現段階において、プロジェクト全体で実際の教室における生徒の学習効果（learning gains）を示すデータはまだ存在しない。現在の高い評価スコアは、ベテラン教員による「ソフトウェアのユーザビリティ」や「指導への親和性」に対する評価を反映したものであり、このツールが生徒のテストの成績向上に真に寄与するのか、概念の理解をより深めることができるのかについては、今後の教室における対照実験による検証を待つ必要がある。

教員や教育機関は今何を利用できるのか

現在、この実験は Google Research のウェブサイト上で公開サンプルライブラリとして開設されている（閲覧には Google アカウントへのログインが必要）。

ライブラリには現在、教員による厳格なレビューを経て承認された（「Vetted by teacher」と表示された）36 個の完成版インタラクティブ練習が収録されている。ケプラーの惑星運動の法則、誤解を招くデータグラフの見分け方、ロケット台車の運動学などが含まれる。内容はすべて英語で、中高レベルの理科と数学が中心だが、小学校向けのテーマが1つとコンピュータ科学のテーマが数点含まれている。

指導のカスタマイズを試みたい学校に向けては、Google Workspace for Education を導入している教育機関であれば、Google for Education のパイロットプログラムへの参加を申請できる。パイロットに参加する教員は、独自のカリキュラム標準やテーマをシステムに送信し、生成を待つことができる。ただし、システムは検証されていないコードが生徒へ直接届くことを許可していない。新しく生成されたインタラクティブ練習は、申請を行った教員自身が実際に操作して承認を与えた後、初めて正式に登録され利用可能となる。

報告書自体が指摘しているように、本研究はあくまで第一歩にすぎない。現在最も求められているのは、実際の学校現場で、実際の教員の手によって生徒の学習効果を検証することであり、Google はまさに Google for Education のパイロットプロジェクトを通じてその取り組みを進めている。