# チェスエンジンは書けるのにチェスは指せない：AIコーディングとスキルの衰え（第317回） - 番組: [Data Science at Home](https://ai-curator.jp/podcasts/shows/cmv8ukqpu000971100qh7ojw4)（Francesco Gadaleta） - 元のタイトル: I wrote a chess engine and still can't play chess: AI coding and skill decay (Ep. 317) - 配信日: 2026年10月26日 - 長さ: 34分 - 要約作成日: 2026年10月26日 - トピック: [#AIコーディング](https://ai-curator.jp/topics/AI%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0) [#スキルの衰え](https://ai-curator.jp/topics/%E3%82%B9%E3%82%AD%E3%83%AB%E3%81%AE%E8%A1%B0%E3%81%88) [#LLM](https://ai-curator.jp/topics/LLM) [#コードレビュー](https://ai-curator.jp/topics/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC) [#デバッグ](https://ai-curator.jp/topics/%E3%83%87%E3%83%90%E3%83%83%E3%82%B0) [#ジュニア育成](https://ai-curator.jp/topics/%E3%82%B8%E3%83%A5%E3%83%8B%E3%82%A2%E8%82%B2%E6%88%90) - URL: https://ai-curator.jp/podcasts/cmvpa56ir00005q11dq2s7095 ## 要約 司会のFrancesco Gattoleta氏は、学生時代にチェスAIを作ったがチェス自体は指せないという自身の経験を、AIにコーディングを任せる開発者の姿に重ねる。Anthropic、METR、Microsoft/CMUの調査を紹介し、AIの使い方次第でスキル形成が左右されると述べる。コンパイラや電卓との比較という反論にも答え、「読める量以上のコードを生成しない」を軸とする8つの習慣を提案している。 ## ポイント - 使わないスキルは衰える。AIコーディングは構文やAPIの記憶、バグへの勘を支える日々の反復を取り除くと主張している。 - 開発者が「書き手」から「承認者」へ移りつつある。承認は執筆より容易で、自分では書けないコードも承認できてしまうことが問題だと指摘する。 - シニアには蓄積があり衰えは保守の問題だが、ジュニアは苦労を通じた学習が奪われ、形成そのものが危うい。将来のシニア不足も懸念している。 - Anthropicの52人のRCTではAI利用群の理解度テストが50%、手書き群が67%で、速度の有意な向上もなかった。丸投げ型は40%未満、概念質問型は65%以上だった。 - コンパイラは決定的で検証済みだが、LLMは確率的で毎回違う形で誤るため、出力を読み続ける必要があるとして「進化の一段階」論に反論している。 - 対策は「生成量≦読む速度×レビュー時間」とし、全行を読む、レビューの日を設ける、説明できなければマージしない、AIなしの作業時間、先にデバッグする、など。 ## 章立て - [00:00] **チェスエンジンの逸話と本日の主張** — チェスAIを書いたがチェスは指せない自身の経験を示し、AIに任せる開発者が同じ道を辿ると論じる。AI批判ではなく誇大宣伝への批判だと断る。 - [02:30] **スキル衰退と承認者化** — スキルは反復で維持され、AIがそれを奪うと説明する。開発者が承認者になる流れと、航空業界の手動操縦訓練の例を挙げる。 - [08:20] **ジュニアとパイプライン問題** — シニアには蓄えがあるがジュニアは苦労を通じた学びを失う。15年後に誰がAIコードをレビューするのかを問う。 - [12:30] **チェスAIの体験談** — 大学のAI課題で探索アルゴリズムを学びながらチェスを作った経験を、プロンプトの問題としてコードを捉える開発者に重ねる。 - [15:30] **調査・研究のエビデンス** — Anthropic、METR、Microsoft/CMUの研究を紹介し、利用方法で結果が変わる点とその限界を整理する。 - [20:38] **自分への反論に答える** — コンパイラ、電卓、チェスエンジンの比喩を取り上げ、LLMが決定的でない点や、使い方が重要な点から反論する。 - [24:50] **スキルを守る8つの習慣** — 全行を読む、レビュー日、説明できなければマージしない、手動飛行時間、デバッグ優先、質問型利用、ジュニア向けの手法、チーム向けの方針を紹介する。 - [32:02] **結び：盤の前に座るのは誰か** — エンジンが失敗した時に盤の前にいるのは開発者だと締めくくり、聴衆に自分のスキル維持法や評価指標を尋ねる。 ## 解説記事 AIにコーディングを任せる開発者は、機械は作れてもゲームは指せなくなるのではないか。ポッドキャスト「Data Science at Home」第317回で、司会のFrancesco Gattoleta氏は、学生時代に作ったチェスエンジンの経験を手がかりにこの問いを論じた。氏はAI批判ではなく、誇大宣伝への批判という立場だと断っている。 #### チェスを作れてもチェスは指せない Gattoleta氏はミラノ工科大学のAIの授業で、チェスを指すプログラムを作った。目的は、ミニマックス法やアルファ・ベータ枝刈り、A*といった探索アルゴリズムを内側から学ぶことだった。当時のそのプログラムは、実際にチェスをする人には勝てたという。しかし氏自身は今もチェスを指せず、駒の動かし方すら怪しいと語る。氏はチェスを「状態・手・評価関数の探索問題」として知っていただけで、定跡や直感を持つゲームとしては知らなかった。 氏はAI支援の開発者も同じだと見る。プロンプトを書き、生成させ、受け入れる作業を繰り返すうち、コードをコードとして知る感覚が薄れていくという。氏の場合は誰もチェスの腕を求めなかったので問題はなかった。だが開発者は「ゲームを指すこと」で報酬を得ており、エンジンが失敗したときに盤の前にいるのは開発者自身だと述べる。 #### スキルは使わなければ衰える 氏の出発点は、使わないスキルは衰えるという素朴な事実である。ピアノや外国語と同様、構文やAPIの記憶、バグの潜む場所への勘も反復で保たれる。AIコーディングはその日々の反復を取り除くというのが氏の見方だ。 さらに開発者の役割が「書き手」から「承認者」に移りつつあるとも述べる。承認は執筆より楽だが、自分では書けないコードも承認できてしまう。航空業界では、自動操縦に頼るパイロットの手動操縦技能が落ちるため、2013年にFAAが安全勧告を出し、規制当局が手動飛行の時間を求めるようになったと紹介する。ソフトウェアにはそうした規制がなく、衰えはAIが誤ったりオフラインになったりして初めて表面化すると警告する。 問題はジュニアでより深刻だという。シニアには長年の手書きコードという蓄えがあり、新しい言語も構文を覚えれば済む。一方ジュニアは、セグメンテーションフォルトに何時間も苦しむといった経験を通じて学ぶ。AIがその苦労を取り除けば学びも消え、見習いの場も失われる。氏は、2040年のシニアは今のジュニアなのだから、誰も書き方を学ばなければ15年後に誰がAIのコードをレビューするのかと問う。将来はAIが完璧に書くという反論に対しては、解くべき問題の難度も進化し続けると答える。 #### 研究が示すもの 氏は3つの調査を挙げ、それぞれ限界も併記している。 - **Anthropic（2026年1月）**：主に初級の開発者52人がPythonの非同期ライブラリTrioを学ぶランダム化比較試験。AI利用群の理解度テストは50%、手書き群は67%で、差が最も大きかったのはデバッグだった。速度向上は統計的に有意でなかった。限界は、サンプルが小さいことと、課題の直後に測定していることである。 - **METR（2025年7月）**：経験豊富なOSSメンテナー16人、246タスク。AI利用で19%遅くなったが、本人たちは20%速くなったと感じていた。限界は、2025年初頭のツールで、多くがCursorに不慣れだったことである。 - **Microsoft Research／Carnegie Mellon（2025年）**：知識労働者319人の調査。AIを信頼するほど批判的思考の努力が減った。自己申告であり、コーディングに限らない。 氏が最も重要とするのはAnthropicの内訳である。コードを丸投げした層は40%未満だったのに対し、説明や概念を質問した層は65%以上で、AIなしの群に近かった。つまり道具そのものではなく使い方が脳を鈍らせるというのが氏の解釈だ。また同研究の設定はサイドバーのチャット型で、自律的に機能を書くエージェント型ではさらに影響が大きいだろうとも述べている。 #### 反論への応答 氏は自ら悪魔の代弁者を務め、3つの反論に答える。 1つ目は「誰ももうアセンブリを書かない」という、コンパイラとの類比である。氏は、コンパイラは決定的で検証済みなので出力を読まずに信頼できるが、LLMは確率的で毎回違う形で誤るため、誰かが出力を読む必要があると答える。抽象化は見るのをやめられるときに機能するが、LLMは見続けることを要求するという。 2つ目は電卓である。電卓は数学を殺さなかったが、算数を教えてから電卓を渡している。ジュニアに初日から電卓を渡すことが危険だと氏は言う。 3つ目は、チェスエンジンで人間が強くなったという話だ。トッププレイヤーはエンジンに代わりに指させるのではなく、局面を理解するために使う。これはAnthropicの高得点群と同じパターンだと氏は見る。そのうえで、使い捨てのスクリプトやプロトタイプなら、スキルを失っても問題ないと認めている。問題は、失敗の責任を誰かが負う本番の重要システムである。 #### スキルを守る習慣 氏の処方は、AIを減らすことではなく、読み・デバッグ・書けて理解できる人間を残し、生成に上限を設けることだ。主な習慣は次のとおり。 - 生成されたコードは全行読む。自分の名前で出すなら読む。 - 週に1〜2日のレビュー日を設け、AIなしで生成コードを読む。生成量が読める量を超えるなら使いすぎの合図で、週の生成行数は読む速度とレビュー時間の積以下に抑える。 - 差分を声に出して説明できない、またはPR説明を手書きできないなら、マージしない。 - 週に1つ、実際の課題をAIなしでこなす（手動飛行の時間）。 - 先にデバッグし、20〜30分試してからモデルに聞く。 - 丸投げせず、理由や概念、何が壊れるかを質問し、チューターとして使う。 - ジュニアは先に自分で書き、その後でAIの案と比べる。 - チームは、AI導入率や出荷行数を測らず、レビューで「通るか」より「なぜか」を問う。ジュニアを雇い続け、苦労のための予算を保護する。 #### まとめ 本回は、AI活用の是非ではなく、使い方と「誰が責任を負うか」に焦点を当てている。ただし引用された研究は、サンプルが小さい、時期が古い、自己申告であるなど限定的で、氏自身もその点に触れている。論拠は断定ではなく警告として受け取るのが適切だろう。 日本の開発現場でも、AI導入率や生成量を成果指標にしている例は少なくないと思われる。氏の「生成量は読める量まで」という基準や、コードレビューで「なぜ」を問う提案は、すぐ試せる指針である。ジュニアの育成機会を確保するという論点も、中長期の人材戦略として検討に値する。 > この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: Data Science at Home「I wrote a chess engine and still can't play chess: AI coding and skill decay (Ep. 317)」