Yanyan Jiangのトークン警告が拡散、しかし本当の争点は検証にある

8月31日にZhihuで投稿された質問が、Yanyan Jiangの講義スライドにあるとされる率直なトークン警告を取り上げたことで、彼は拡散した論争の中心となった。その質問では、トークンを利用できないCS学生は直ちに退学すべきだと主張されていた。しかし、元となるスライド、その公開日、そしてJiangがこの言葉に込めた定義はいずれも未検証のままである。

この隔たりは重要だ。というのも、この文脈でのtokenには複数のもっともらしい意味がある。言語モデルが処理する単位、API認証情報、有料の推論利用枠、あるいは講義の認証コードを指す可能性がある。Jiang自身の講義資料でも、この用語は複数の技術的文脈で使われている。

したがって、この論争が投げかける問いは、挑発的な一文が公平に聞こえるかどうかよりも鋭い。AIへのアクセスがコンピュータサイエンス教育の前提となるべきかを問うものだ。また、曖昧なスクリーンショットが、教育者が持つとされる考えについての断定的な物語へといかに素早く変わり得るかも示している。

拡散したトークン主張が実際に裏付けるもの

公開されている証拠が示しているのは論争が生じたことまでであり、それに付随するすべての解釈が正しいことではない。

直接のきっかけは、Jiangに帰された発言を評価するよう読者に求めたZhihuの質問だった。これは2026年8月31日に人気リストのフィードに掲載された。この日付は論争の可視性を裏付けるが、元のスライドの作成日までは証明しない。

質問文には、Jiangの名前、講義スライドへの言及、そしてトークンを持たない学生に関する主張という3つの要素が含まれている。しかし、それだけでは、どの講義にそのスライドが含まれていたのかは確定できない。また、tokenの定義も、周辺の講義内容も、検証可能な形で再現されてはいない。

この区別はほぼ直ちに重要になった。少なくとも1本の二次記事は、この言葉を大規模言語モデルサービスへのアクセスと解釈した。そのうえで、APIクレジット、コーディング支援ツール、ローカルモデルをめぐる詳細な議論を展開した。

しかし、その解釈には、問題とされるスライドへのリンクが添えられていなかった。また、Jiangの現在インデックスされている講義資料と照合できない文脈上の主張も含まれていた。これらの主張を逐語録として扱うべきではない。

最も有力な関連一次証拠は、Jiangの公開教育サイトにある。2026年の講義ページには、Generative Software Engineeringという秋学期の講義が掲載されている。シラバスには、生成AI、スケーリング則、エージェント、コンテキストエンジニアリング、ナレッジマネジメント、開発ループ、テスト、セキュリティ、AIネイティブアーキテクチャが含まれる。

このシラバスは、AI関連の解釈をもっともらしくする。ただし、拡散した一文がそこに掲載されていたことを証明するものではない。関連する講義と、真正性が確認された引用は、異なる種類の証拠である。

Jiangの2026年春学期のオペレーティングシステム講義資料は、さらに曖昧さを加える。そこでは、講義インフラへのアクセスにTOKENが使われている。講義を聴講する学生は大学メールを通じてトークンを受け取り、実験ページでは提出機能を表示する前にトークンの入力を求められる。

同じ資料では、言語モデルのトークンも扱われている。ある課題では、小規模なGPT-2モデルの並列推論を実装するよう学生に求めている。そこでは、トークンを、テキストがモデル可読な単位に分割された際に生成される整数識別子として定義している。

3つ目の意味は商用モデルへのアクセスに関わる。開発者は、API認証情報、利用クレジット、推論利用枠を意味して「トークンが必要だ」と非公式に言うことが多い。この用法は一般的だが、モデルのテキストトークンと技術的に同一ではない。

これらの意味は、実質的に異なる物語を生み出す。

スライドが講義認証コードを指していたなら、その一文は未履修の学生に向けた事務的な冗談だった可能性がある。モデル利用を指していたなら、AIリテラシーに関する立場を表すことになる。有料利用枠を指していたなら、教育へのアクセスと不平等に関する問題を提起する。

拡散している見出しは、こうした可能性を一つの劇的な解釈に押し込めている。まさにそれが、現時点で入手可能な証拠では裏付けられない点である。

時期についても慎重であるべきだ。JiangのGenerative Software Engineeringページでは、2026年秋学期の講義が火曜午前に行われると記載されている。論争が浮上したのは8月31日、月曜日だった。その時点で公開ページは存在していたが、インデックスされたシラバスの初期講義一覧には番号付き講義が1件しか含まれていない。

この状況は、講義が始まったばかり、あるいは開始直前だったことを示唆する。しかし、問題のスライドがいつ投稿、提示、撮影されたかは特定できない。したがって、元の発言の日付を正確に断定することは、証拠の範囲を超える。

最も慎重に言える出来事の要約は限られている。2026年8月31日、Zhihuの質問によって、ある帰属付き発言が拡散した。Jiangは生成的ソフトウェア開発を中心とする講義を準備中、または開始していた。元のスライドと完全な文脈は、公に確認されていないままだった。

この検証上の空白は小さな注釈ではない。責任ある評価を形作る中心的な事実である。

Yanyan Jiangのトークン表現がもっともらしく聞こえた理由

この帰属が注目を集めたのは、Jiangの記録された教育方針が、学生がソフトウェア工学を学ぶ方法に関する従来の前提へすでに挑戦しているからだ。

Jiangは、拡散したスクリーンショットに名前が添えられた匿名の論者ではない。南京大学の教員プロフィールは、彼をシステムソフトウェアとソフトウェア自動化に取り組む准教授兼博士課程指導教員として紹介している。

このプロフィールは、トップレベルのシステムおよびソフトウェア工学会議で受賞した論文が5本あることにも触れている。さらに、彼の公開オペレーティングシステム講義は500万回を超える動画視聴を得ているという。こうした経歴は、彼の名を冠した短い発言が注目を集めた理由を説明する。

現在の資料にも、意図的に強い表現が含まれている。教育サイトのホームページでは、スケーリング則に残る障壁はないと述べられている。また、AIが知識労働を変えるにつれ、既存の学術構造は意味を失うと予測している。

オペレーティングシステム講義でも、従来の設計から明確に距離を置いている。2026年のノートには、もはや多くの低レベルな詳細を必要としない人が大半だとある。講義はカーネル実装の内容を削除し、アプリケーション、システムインターフェース、プロジェクトへ重点を移した。

これは大きなカリキュラム上の判断である。従来のオペレーティングシステム講義では、スケジューリング、仮想メモリ、同期、ファイルシステム、カーネル実装が重視されることが多い。Jiangの再設計はシステム的思考を維持しつつ、学生が何を作り、どのように到達するかを変えている。

ノートではClaude Codeも次世代のシェルとして説明されている。概念の説明、ツールの発見、APIの呼び出し、デバッグ、補助コードの生成において、AI支援を認める立場が示されている。

同時に、講義は無制限の生成を許可していない。その方針は、自然言語で記述された実験課題全体を提出コードへ変換することを禁じている。学生は特定のAPIの利用方法を尋ねることはできるが、課題の完全な解答をエージェントに委ねることはできない。

この方針は、Jiangが学生により多くのトークンを使わせたいという単純な主張を複雑にする。彼の文書化された立場は、統制された統合により近い。学生はAIを利用し、その役割を理解し、得られたプログラムに責任を負うべきだというものだ。

この区別は、拡散した一文が本物であることを証明せずとも、なぜもっともらしく聞こえたかを説明する。Jiangの教育はすでに、AIシステムを現代のコンピューティング環境の一部として扱っている。また、技術実践の変化を示すために挑発的な表現も用いている。

ある発言が人物の公的なスタイルに合っていても、誤引用である可能性はある。もっともらしさは調査の理由であり、検証の代替ではない。

この論争は、現実の教育移行期にも起きた。Stanfordの2026 AI Indexは、米国の高校生・大学生の5人に4人が学業でAIを利用していると報告している。制度上の方針は一貫しておらず、しばしば不明確なままである。

この普及は、AIへのアクセスがもはや例外的な事例ではないことを意味する。学生はすでに、調査、ブレインストーミング、編集、コーディング、説明のためにモデルを利用している。教員は、どの利用が正当な支援に当たり、どの利用が学習目標を迂回するのかを判断しなければならない。

コンピュータサイエンスは、コードが回答であると同時に実行可能な成果物でもあるため、多くの科目より早くこの問題に直面する。モデルは、学生に正しいメンタルモデルを与えなくても、コンパイルできるものを生成できる。

学生は、メモリ所有権、同期、セキュリティ境界、アルゴリズム計算量を誤解したまま、動くコードを提出するかもしれない。テストスイートに合格しても、その隔たりは後の課題や本番障害で露呈するまで隠れ得る。

Jiangの文書化された方針は、課題の境界を通じてこの問題に対応している。APIの呼び出し方を尋ねることは、学生自身の実装を支える。エージェントに実験課題を完成させてもらうことは、評価対象の活動を置き換える。

これは、生のトークン消費量よりも有用な教育上の境界線である。学生が、講義が測ろうとしている推論をなお自ら行っているかに焦点を当てる。

したがって、負担は学生と大学の双方にかかる。学生は生成された成果物を指示し、点検し、疑問視する方法を学ばなければならない。大学は、明確な方針、公平なアクセス、コード生成が広く利用可能な状況でも意味を保つ評価を提供しなければならない。

退学を促すスローガンだけでは、こうした責任すべてを担えない。注目を集めることはできても、カリキュラムを定義することはできない。

トークンへのアクセスは技能の証明ではなく、基礎インフラになりつつある

AIツールへの信頼できるアクセスはCS学生にとってますます有用になっているが、アクセスだけで能力について分かることはほとんどない。

AIへのアクセスをインフラとして扱う最も強い根拠は、日常的な開発作業にある。モデルは、未知のAPIを説明し、テストの草案を作成し、エラーメッセージを翻訳し、リポジトリを要約し、デバッグの道筋を提案できる。

こうした活動は、システムを探索するコストを下げる。学生は一つの方針に決める前に、複数の可能なアプローチを比較できる。教員やティーチングアシスタントが不在でも、モデルは即時のフィードバックを提供できる。

この利点は、自由度の高いプロジェクトで特に明確に表れる。端末ゲームを作る学生は、関連する入力ライブラリを見つけるようエージェントに依頼できる。別の学生は、不正なネットワークリクエストに対するテストケースを求められる。

どちらの作業も、主要な設計判断を手放す必要はない。モデルは学生の探索能力を拡張する一方、実装と検証は学習者に委ねる。

学生には、モデルの限界を直接経験することも必要だ。講義だけでは健全な判断力を育てられない。エージェントがどれほど自信満々にAPIを捏造し、隠れた要件を見落とし、無関係なコードを変更するかを観察しなければならない。

その意味で、何らかの形でトークンにアクセスできることは、コンパイラやデバッガにアクセスできることに似ている。ツールは繰り返し使うことで理解される。その失敗パターンは実践的知識の一部となる。

ただし、この比較には限界がある。コンパイラは定義された言語規則を実装するのに対し、言語モデルは確率的な出力を生成する。コンパイラのエラーも学生を混乱させることはあるが、通常は存在しないライブラリを作り出し、それをもっともらしく擁護することはない。

この違いにより、検証は中核的なスキルとなる。学生にはテスト、仕様書、ドキュメント、静的解析、プロファイリング、コードレビューが必要だ。モデルの出力が増えるほど、こうした確認を要する対象も増える。

アクセスにも複数の形態がある。ホスト型チャットボットは推論の詳細の大半を隠している。統合型コーディングエージェントはプロジェクトファイルを読み取り、ツールを実行できる。APIはパラメーターを公開し、カスタムワークフローを可能にする。ローカルモデルは、プライバシーとデプロイに関して学生へより多くの制御を与える。

これらの選択肢には、それぞれ異なる要件が伴う。チャットボットのアカウントはAPIキーと同じではない。APIキーは授業提出用の認証情報と同じではない。コンテキストウィンドウはアカウント残高ではない。

tokenを包括的な用語として使うと、こうした違いが見えにくくなる。また、技術要件が財政状況の審査であるかのように聞こえることもある。

教育において、それは深刻な問題になり得る。学生ごとに、支払い手段、対応地域、最新のハードウェア、安定したネットワーク、プレミアムモデルへのアクセスは均等ではない。授業や職場のコードをアップロードすることを禁じるプライバシー規則に直面する学生もいるかもしれない。

したがって、商用AIの利用を求める学校は、承認済みの利用経路を提供すべきだ。アクセスの問題を完全に個々の学生へ転嫁してはならない。

教育機関は、何がログに記録され、保持され、トレーニングに利用されるのかも定義しなければならない。ソースコード、学生記録、未公開研究、セキュリティ課題には機密情報が含まれる可能性がある。利便性は、こうした義務をなくすものではない。

オープンモデルは単一プロバイダーへの依存を減らせるが、リソース上の制約を解消するわけではない。小規模なモデルをローカルで動かすことは一般的なハードウェアでも実用的かもしれない。より大規模なエージェント型ワークフローの実行には、はるかに多くのメモリ、ストレージ、計算能力が必要になることがある。

無料アクセスも予告なく変わり得る。レート制限、モデルの提供状況、地域ルール、教育向けプログラムは、いずれもプロダクト上の判断だ。学期の途中で消滅し得る便益を、授業は重要な評価の基盤にすべきではない。

より良い基準は、能力に基づくものだ。すべての学生は、少なくとも1つの承認済みAI環境を使えるようになるべきである。同時に、誰もがその中核的な推論を外部委託せず、同じ基礎スキルを実証すべきだ。

たとえば学生は、エージェントが生成したパッチと手作業による実装を比較できる。安全でない前提を特定し、敵対的テストを書き、各テストが仕様のどの条項を対象にしているかを説明できる。

システム系の授業では、生成された並行処理コードに競合状態がないか検査させることができる。ソフトウェア工学の授業では、エージェントがリポジトリの慣習を守り、必要なコンポーネントだけを変更したかを評価できる。

こうした演習は、モデルの利用そのものを学習対象にする。消費を目的化して報いるものではない。

商用アクセスを持たない学生には、学校がホストする選択肢、ローカルの代替手段、または同等の学習成果をもたらす非AIの経路を提供すべきだ。教育方針が測るべきは購買力ではなく理解である。

ここで、拡散した表現は指針として機能しなくなる。特定の授業では、tokenアクセスが必要なインフラとなる場合がある。しかし、それを好奇心、規律、工学的能力の信頼できる代理指標にすることはできない。

本当の対立相手は、検証なしのAI利用である

中心的な対立は、AI利用者と従来型プログラマーの間ではない。検証されたエンジニアリングと、吟味されない生成との間にある。

AIコーディングへの反応の多くは、役に立たない二項対立に陥っている。一方は手作業によるプログラミングを時代遅れとみなし、もう一方はモデル支援を本物の学習を妨げる知的な近道とみなす。

Jiangが公表した資料は、どちらの極論も支持していない。完全な課題生成を制限しつつ、特定の補助的タスクではAIを推奨している。また、相当なプログラミング能力と検証も引き続き求めている。

この立場は、コンピュータサイエンスのカリキュラム設計が向かうより広い方向性と一致する。ACM、IEEE Computer Society、AAAIは、幅広い知識体系と専門的能力を軸にCS2023 guidelinesを策定した。

この報告書は、アルゴリズム、アーキテクチャ、オペレーティングシステム、ネットワーキング、セキュリティ、ソフトウェア工学、データ管理、数学、社会的責任を維持しつつ、人工知能も含めている。生成AIはこれらの分野を消し去ったわけではない。

この広がりが重要なのは、モデルが生成したコードが最終的には現実のシステム上で動作するからだ。メモリを消費し、信頼境界をまたぎ、並行イベントを処理し、ユーザーデータを扱い、外部ライブラリに依存する。

こうした層について推論できない学生は、エージェントの変更を信頼性高く承認できない。モデルは出力を増やす一方で、システムへの理解を低下させる可能性がある。

逆の問題も存在する。学生は教科書上の概念を習得していても、現在の専門的ワークフローを形作るツールを避けているかもしれない。その学生はデータ競合を理解していても、大規模なリポジトリ全体でエージェントを導くことには苦労する可能性がある。

現代の能力には、基礎とツール活用力の両方が必要だ。その関係は代替的ではなく乗算的である。強い基礎は、プロンプト、分解、レビュー、診断を向上させる。

生産性に関する証拠も、慎重さの必要性を強めている。METRによる2025年のランダム化研究は、使い慣れたリポジトリで246件のタスクを完了する16人の経験豊富なオープンソース開発者を追跡した。

開発者たちはAI支援によって速くなると予想していた。しかし、developer studyでは、その環境において2025年初頭のツールが完了時間を19％増加させたことが示された。

この結果は、AIが常にプログラミングを遅くすることを証明するものではない。この研究は小規模なグループ、特定のツール、そして貢献者がよく知る成熟したリポジトリを対象としていた。

METRは後に、2026年初頭のツールは元の実験でテストされたモデルよりも、おそらく大きな高速化を生んでいると述べた。また、利用パターンの変化に伴い、実験設計も変更した。

それでも元の結果は、重要な認識の隔たりを明らかにしている。測定された完了時間が逆方向に動いたにもかかわらず、開発者は速くなったと感じていた。労力の軽減や目に見えるコード生成は、進歩しているという誤解を招き得る。

学生は、微妙な誤りを見抜くのに必要な経験を欠いている可能性があるため、さらに大きなリスクに直面する。もっともらしい関数は、失敗時、並行実行時、あるいは悪意ある入力に対する挙動を誰かが確認する前に、完成しているように見えることがある。

tokenの消費はこの問題を解決しない。推論を増やせば候補となる解決策も増やせるが、レビューが必要なコードも増え得る。

学生に求められる関連スキルは、適切に調整された信頼である。学習者は、どのタスクが定型的か、いつ生成出力をテストできるか、いつ回答が隠れたアーキテクチャ知識に依存するかを知る必要がある。

有用なワークフローは、書面による要件から始まる。次に学生はモデルへ範囲を限定した変更を依頼し、提案されたdiffを確認し、テストを実行し、要件に照らして挙動を確認する。

出力が失敗した場合、学生は別のパッチを要求する前に失敗を診断すべきだ。そうしなければ、やり取りはますます複雑になる推測のループになり得る。

ナレッジマネジメントも重要になる。エージェントは、アーキテクチャのメモ、コマンド、慣習、過去の決定を受け取ると、より適切に機能する。学生は、モデルがすべてを推測してくれると考えずに、そのコンテキストを整理する必要がある。

student knowledge baseは、授業ノート、仕様書、実験、モデルの応答を整理する助けになり得る。ただし、保存されたコンテキストにも、依然として情報源の確認と慎重な選択が必要だ。

この実践は、AIリテラシーを巧みなプロンプト作成から遠ざける。より難しい仕事は、問題を定義し、信頼できるコンテキストを集め、結果を評価することにある。

それはコンピュータサイエンス教育の目的も守る。学生は単にコードの作り方を学ぶのではない。計算がどのように振る舞うか、そしてその振る舞いについて信頼できる主張をどう行うかを学ぶのである。

拡散した論争は、このより深い基準を指し示している。tokenアクセスの有無よりも、生成された回答を信頼に値するものにする証拠が何かを知っていることの方が重要だ。

この主張がCS教育について誤っている点

たとえ引用が本物であったとしても、学生に退学を促すことは、有効なカリキュラム上の警告を不適切な入学基準へと変えてしまう。

コンピュータサイエンスは、言語モデル支援によるアプリケーション開発よりも広い分野である。理論、グラフィックス、ハードウェア、セキュリティ、データベース、ネットワーキング、ヒューマンコンピュータインタラクション、科学技術計算など、多くの領域を含む。

専門分野ごとに、AIツールから得られる利点は異なる。セキュリティを学ぶ学生は、ソース資料が機密性を持つため、管理されたローカルモデルを必要とするかもしれない。理論を学ぶ学生は、主に記法や文献探索のためにモデルを使うかもしれない。

組み込みシステムを学ぶ学生は、汎用的なコーディングエージェントが十分に扱えないメモリやタイミングの制約下で作業する可能性がある。コンパイラを学ぶ学生は、証明なしにはもっともらしい出力にほとんど価値がない意味論を学ぶ場合がある。

CS学生という言葉には、初心者も高度な研究者も含まれる。初学期の学習者に、経験豊富なエンジニアのようにエージェントを使うことを期待するのは、教育の役割を無視している。

学校が学生を教えるのは、彼らがまだ専門的な能力を持っていないからだ。ツール、認証情報、ワークフローの不足は通常、排除より先に支援と教育を促すべきである。

拡散した主張の最も強い形は、現在のアクセスと将来の適応力も混同している。今日APIアカウントを持たない学生でも、すぐに取得できる。デバッグの規律を欠く学生には、何年もの練習が必要になるかもしれない。

後者の不足の方が重大だが、拡散される一文で要約するのは難しい。

経済的なアクセスも、依然として別の弱点である。商用利用に依存する方針は、より良いハードウェア、国際的な支払い手段、より大きな個人予算を持つ学生を優遇する可能性がある。

プロバイダーが無料の利用枠を提供していても、利用制限はプロジェクトに不均等な影響を与え得る。広く試行する学生は、最初の回答を受け入れる学生より早く利用枠を使い切るかもしれない。

これは逆説的なインセンティブを生み出す。授業は実験を奨励しているように見えながら、ツールを最も真剣に検証する学生を不利にする可能性がある。

大学は、管理されたアクセスによってこの問題に対処できる。均一なアカウント、ローカル推論サービス、プライバシーに関するガイダンス、透明な代替手順を提供できる。

また、再現可能な入力に基づいて課題を設計することもできる。結果が変化するプロプライエタリモデルに依存する場合、教育チームはバージョンを記録し、代表的な出力を保存すべきだ。

評価も変えなければならない。持ち帰り形式のコードだけでは、誰が実装を理解しているかを明らかにしなくなった。口頭レビュー、ライブデバッグ、設計説明、敵対的テストは、より強い証拠を提供する。

こうした方法はAIを禁止する必要がない。学生に対し、どの部分が生成されたのか、どの前提を検証したのか、どの失敗で手作業の推論が必要になったのかを説明させることができる。

目的は、禁止されたツールを使った学生を捕まえることではない。学生が自分の仕事に対して知的責任を持ち続けているかを観察することである。

この責任は教員にも及ぶ。授業は単にAIを必須だと宣言し、変化するプラットフォーム規則の解釈を学生に委ねることはできない。

プロンプトの境界、情報源の取り扱い、データ保護、テスト、帰属表示、インシデント対応を教えなければならない。課題中にプロバイダーが利用できなくなった場合に何が起きるのかも説明すべきだ。

この論争はまた、教員が慎重な公開表現を必要とする理由も示している。誇張表現は、口調と文脈が見える教室の中では機能するかもしれない。スクリーンショットはその両方を取り除く。

ひとたび拡散すれば、冗談は方針上の主張になり得る。限定的な管理上の警告は、教育哲学になり得る。二次的な執筆者は、欠けた文脈を自らの前提で埋めるかもしれない。

江氏の公的な発信スタイルを考えれば、こうした変容は特に起こりやすい。彼の資料にはユーモア、強い予測、意図的に挑発的な表現が用いられている。こうした選択は、技術講義を記憶に残りやすくする。

一方で、それらはソーシャルメディアで拡散されるのに適した断片も生み出す。文が短く圧縮されるほど、技術的な文脈から切り離されやすくなる。

これは、教育者が悪意あるあらゆる解釈に責任を負うという意味ではない。しかし、重大な主張には検証可能な文脈が必要だということは意味する。

完全版のスライド、タイムスタンプ、講義録画を公開すれば、読者は冗談と要件を区別できる。どの種類のトークンを指していたのかを明確にすれば、現在の論争の大半は解消されるだろう。

それまでは、公平な判断は条件付きのままであるべきだ。CS学生にAIリテラシーが必要だという根本的な考え方には妥当性がある。だが、排他的な表現は健全な教育原則ではない。

最も重要なのは、この引用自体が、公に確認できる一次資料によって裏付けられていないことだ。その最も強い解釈を確定した事実として評価すれば、この論争の発端となった検証上の誤りを繰り返すことになる。

このトークン論争の本当の意味を示す3つのシグナル

次に得られる証拠によって、これが誤解されたスライドなのか、意図的なカリキュラム上の立場なのか、それとも単なる拡散した帰属情報なのかが決まるはずだ。

第一のシグナルは、元の授業資料である。一般公開されたスライド、講義録画、または日付入りのノートによって、完全な文とその周辺の資料が示されるべきだ。

その証拠により、どの授業でこの表現が使われ、どのトークンを指していたのかが明らかになる。また、その発言が教育上のもの、運営上のもの、ユーモア、あるいは規範的な主張だったのかも分かる。

その資料がなければ、解釈は二次的なものにとどまる。ブログやソーシャル投稿での反復は、元の情報源の代わりにはならない。

第二のシグナルは、江氏の2026年秋学期の授業方針である。Generative Software Engineeringのシラバスは現在、テーマとプロジェクトの概要を示しているが、公開ページで評価の詳細は限定的だ。

より完全な方針では、必須のAIツール、利用可能なアクセス、データの取り扱い、帰属表示、禁止される委任について説明されるべきだ。また、指定されたプロバイダーを利用できない学生のための代替手段も示す必要がある。

授業が平等なアクセスを提供し、検証スキルを評価するなら、必須のAIリテラシーを求める広範な主張はより強まる。学生がアクセスを購入するか、自力で入手しなければならないなら、公平性への批判はより強まる。

第三のシグナルは、他のコンピュータサイエンスプログラムが2026年度中にどのように評価を見直すかである。挑発的な見出しがなくても、大学はいま同じ根本的な問題に直面している。

ライブでのコードレビュー、口頭試問、管理されたデバッグセッション、生成された失敗の分析を求める課題が増えるかに注目したい。こうした変化は、AIリテラシーが測定可能なエンジニアリング能力の一部になりつつあることを示すだろう。

単にチャットボットの利用を求めるだけでは、示されることははるかに少ない。ツールの導入は簡単に義務付けられる。証拠に基づく評価はより難しい。

学生は、論争が決着するまで準備を待つべきではない。承認されたモデルを責任を持って使う経験を積み、生成された手法と手作業の手法を比較し、繰り返し現れる失敗パターンを記録できる。

また、アルゴリズム、システム、ネットワーク、セキュリティ、ソフトウェア設計の学習も続けるべきだ。こうした基盤が、生成された出力を信頼できるかどうかを決める。

教育者にとっても、直ちに取るべき行動は同様に具体的だ。どのトークンが重要なのかを定義し、公平なアクセスを提供し、生成が安価になった後にも残る推論を評価することである。

長期的な問いは、すべてのCS学生が今日トークンを持っているかどうかではない。学生が判断力を手放すことなく、モデルへのアクセスを信頼できる成果へと変えられるかどうかである。