CLAUDE.md の内容を解説したものTODO の実装、コア部分の完成コード、既製の解答の提供は禁止この CLAUDE.md は、Stanford CS336「Language Modeling From Scratch」の課題に取り組む学生を、AI coding assistant がどう支援すべきかをまとめたガイドです。
対象のAIは Claude Code、ChatGPT、GitHub Copilot、Cursor のようなツール。
つまり、「AIを使って課題をやるときの、AI側のルールブック」ですね。
ここで面白いのは、**“AIを使うな”ではなく、“こう使ってほしい”とかなり細かく線引きしている**ところです。
AIを完全に締め出すのではなく、教育を邪魔しない形で活用しようとしているのがポイントだと思います。
一言でいうと、AIはTA（Teaching Assistant）として振る舞え、解答生成機ではない、という方針です。
つまりAIは、
といった形で助けるべきで、
逆に
といった行為はしてはいけない、というわけです。
この考え方、かなり大事だと思います。
AIが何でもやってくれると、その場では楽でも、結局「分かった気になるだけ」で終わりがちです。CS336のような実装重視の授業では、そこを特に警戒しているのでしょう。
文書では、AIが学生を助けるためにしてよいことがいくつか挙げられています。
学生が混乱しているときに、いきなり答えを出すのではなく、理解できる方向へ案内する。
たとえば「attention のマスクって何？」みたいな質問に対して、仕組みをかみ砕いて説明するイメージです。
講義資料、公式ドキュメント、profiling/debugging tools などに誘導してよい、と書かれています。
要するに、ネットのどこかにある即答を拾ってくるのではなく、授業の材料を使えということです。
学生が書いたコードを見て、改善点や注意点、edge case（想定漏れしやすい例）を指摘する。
ただし、ここでも「答えを直接言う」のではなく、改善の方向を示す程度にとどめるべきとされています。
「直してあげる」よりも、「何を試した？」「期待と実際はどう違う？」と聞く。
これ、地味ですがすごく大切です。自分で原因を切り分ける力が育ちます。
Python、PyTorch、CUDA、Triton、distributed training tools のエラーを説明してよい、と明記されています。
このあたりは学習者にとって本当にありがたい領域です。エラー文って、読めば分かるようで分からないので……。
個人的には、「エラーを翻訳してくれるAI」は教育と相性がかなりいいと思います。
アルゴリズムや実装の考え方を大づかみに説明し、学生を正しい方向へ軽く押す。
いきなり完成品を渡すのではなく、「まずここを考えよう」という支援です。
sanity check は「まず常識的におかしくないか確かめるテスト」、toy example は「超小さい例」のことです。
たとえば、
といった助け方が推奨されています。
ここはかなり実践的で、私はすごく良いと思いました。
正直、実装のつまずきって「理屈が分からない」より「どこが壊れているか分からない」ことの方が多いので、こういう支援はかなり効きます。
ここが文書の本丸です。禁止事項がかなり具体的です。
pseudocode も含めて、実装そのものを出すのはダメ。
つまり「雛形すら渡さないで」という強めの制約です。
課題の答えをそのまま渡してはいけません。
これが一番わかりやすい禁止事項ですね。
学生用レポジトリの TODO セクションを完成させるのは禁止。
課題の核心部分に手を入れてはいけない、ということです。
AIがコードを勝手に書き換えるのもNG。
「直しておいたよ」は便利に見えますが、学習にはならない、という判断でしょう。
実際の実行や操作までAIが肩代わりしないルールです。
コード全体を完成版に作り替えるのもダメ。
つまり「一部の助言」はOKでも、「丸ごと整形して提出物にする」のはアウトです。
特に禁止対象として挙げられているのが、
などです。
このリスト、かなり具体的です。
CS336がどれだけ本気で「自分の手で実装して理解する」ことを重視しているかが分かります。
文書には、AIが質問に答えるときの流れも書かれています。
を確認する。
これはデバッグの基本でもありますし、学習者が問題を言語化する訓練にもなります。
講義や handout、ドキュメントを参照させる。
AIが“便利な検索窓”として使われるのは自然ですが、ここでは授業の文脈に戻すことが重視されています。
実装そのものではなく、「次に何を確認するか」を提案する。
たとえば、
といった感じです。
単なる手順ではなく、理由も説明する。
これ、地味だけど本当に重要です。理由が分かると、別の場面でも応用できるからです。
文書には、Good / Bad の例が載っています。
たとえば「causal mask が変で学習が爆発する」と相談されたとき、
を確認させる、という例が示されています。
これはいい例です。
答えを断定せずに、「観察ポイント」を渡しているからです。
一方で、「トークナイザを直して。コード全部書いて」はダメ。
当然ですが、ここを曖昧にするとAIはすぐ“代筆マシン”になります。
だからこそ、この文書では線引きをはっきりさせているのでしょう。
この文書が重要なのは、単なる学内ルールではなく、AI時代の学び方の設計図になっているからです。
AIはもう、調べ物・要約・説明・デバッグ補助では本当に強いです。
でも、学生がやるべき「考える」「試す」「失敗する」「直す」というプロセスまで全部AIに任せると、学習の芯が抜けます。
CS336の方針は、そこをかなり真面目に守ろうとしている。
私はこの姿勢、かなり健全だと思います。少し不便でも、その不便さが学びになるタイプの授業ってありますよね。まさにそれです。
このルールは「制限」ばかりに見えますが、学生にとってもメリットがあります。
AIに答えをもらうより、最初は遠回りでも、最終的に強くなるのはこちらだと思います。
この CLAUDE.md は、CS336 の課題において AI をどう使うべきかを定めた、かなり明快なガイドです。
要するに、
ということです。
個人的には、これは「AIを使うな」という話ではなく、AIを使っても学びが壊れないようにする工夫だと感じました。
今後こういう方針は、大学教育や実装課題でますます増えていくのではないでしょうか。
参考: assignment1-basics/CLAUDE.md at main · stanford-cs336/assignment1-basics