AIに書かせる時代に、なぜプログラミングを学ぶのか

2026年10月2日

AI時代のプログラミング学習

初学者に残すべき「理解・検証・説明・判断」の力

小西秀明

AIを学習の補助として使いながら、自分でコードを理解し、確かめ、説明し、判断する。そのための考え方を、教室の経験と小さなコード例から紹介します。

はじめに　「先生、AIに聞いたらできました」

「先生、AIに聞いたらできました」

最近、教室でこの言葉を聞くことが増えました。

少し前なら、分からないことがあれば教科書を開きました。検索しました。先生に質問しました。コードを何度も打ち直し、エラーを眺め、ようやく動いたときに「ああ、こういうことか」と少しずつ理解していきました。

今は違います。エラーが出ればAIに貼り付ける。「こういうゲームを作りたい」と伝えれば、コードが出てくる。「初心者向けに説明してください」と頼めば、説明までしてくれる。場合によっては、本人がまだ授業で習っていない構文や設計まで使って、数秒で完成度の高い答えを返してきます。

便利です。そして私は、その便利さを否定するつもりはありません。むしろ、これからソフトウェア開発の世界で働く人にとって、AIを使わないという選択の方が不自然になっていくでしょう。コードを書く。調べる。テストする。レビューする。ドキュメントを書く。設計案を考える。そうした多くの作業に、AIはすでに入り始めています。

では、そんな時代に、初心者がプログラミングを学ぶ意味はどこにあるのでしょうか。

AIがコードを書いてくれる。AIがエラーを直してくれる。AIが説明までしてくれる。それなら、変数や条件分岐、メソッドやクラスを、時間をかけて学ぶ必要はないのでしょうか。最初からAIに任せればよいのでしょうか。

この問いは、授業をしていると避けて通れません。

AIがあるから前に進める人もいる

教室には、さまざまな人がいます。一度説明を聞けば理解できる人。手を動かして初めて分かる人。何度聞いても、なかなか意味がつながらない人。同じ説明を聞いても、理解するまでに必要な時間は人によって違います。

「また聞いたら悪いかな」「みんなは分かっているように見える」「こんなことも分からないと思われたくない」。そう感じて、質問できなくなる人もいます。

AIなら、何度でも聞けます。嫌な顔をしません。同じことを10回聞いても怒りません。「もっと簡単に」「小学生にも分かるように」「コードを使わずに」「この1行だけ」と、説明の仕方を何度でも変えられます。

これは大きな可能性です。AIは、できる人がさらに速く進むための道具だけではありません。これまでなら途中で諦めていた人が、学習を続けるための道具にもなり得ます。

しかし、「動いた」と「分かった」は違う

一方で、別の場面もあります。

受講者が言います。「AIに聞いたらできました」

画面を見ると、確かに動いている。そこで聞いてみます。「このメソッドは何をしているの？」少し沈黙します。「では、この値を2倍にするとどうなる？」分からない。「このif文は何を判定している？」やはり説明できない。

ここで私は考えます。この人は、プログラムを作れたのでしょうか。それとも、AIにプログラムを作ってもらったのでしょうか。そして、その違いは何なのでしょうか。

AIを使ったこと自体が問題なのではありません。参考書のコードでも、Webで見つけたコードでも、他人から教えてもらったコードでも同じです。重要なのは、

自分が採用したものを、自分が扱える状態になっているか

です。

この本で考えたいこと

この本は、「AIを使うな」という本ではありません。反対に、「もう勉強しなくてよい」という本でもありません。その間を考える本です。

AIに何を任せるのか。人間は何を理解する必要があるのか。初学者は何を学ぶべきなのか。教える側は何を変えなければならないのか。そして、AIがもっと賢くなったときにも残る力とは何なのか。

私は、ひとまず次のように考えています。

AI時代の初学者が目指すべきなのは、AIなしで何もかも書ける人ではない。AIが出したものを理解し、検証し、説明し、最後に自分で判断できる人である。

この本では、その考えを教室で起きていることと結びつけながら、一つずつ確かめていきます。

第1章　AIがコードを書く時代になった

数時間かかっていたことが、数十秒で終わる

例えば、Unityでキャラクターを左右に動かしたいとします。

以前なら、初心者はまず調べました。「キー入力 Unity」「キャラクター 移動 C#」「Rigidbody 動かし方」。検索結果をいくつか開き、コードを試し、エラーが出て、また調べる。その過程で少しずつ、「入力を受け取る処理が必要なんだ」「Updateというものがあるんだ」「TransformとRigidbodyでは動かし方が違うんだ」と理解していきました。

今は、「Unity 6で、左右キーでキャラクターを動かす初心者向けコードを書いてください」とAIに頼めばよい。数秒でコードが出てきます。さらに、「1行ずつ説明してください」と続ければ説明までしてくれます。分からないところだけ聞き直すこともできます。

これは、プログラミング学習の入口を大きく変えました。

近道は悪いことなのか

ここで、「昔は苦労したんだから、今の初心者も苦労するべきだ」と考える必要はありません。苦労すること自体に価値があるわけではありません。必要のない苦労なら、減らした方がよいのです。

IDEの入力補完もそうでした。昔は長い命令を正確に覚えて入力する必要があった。今は途中まで入力すれば候補が出てきます。それでプログラマーの価値がなくなったわけではありません。AIも同じように、これまで人間が行っていた作業の一部を肩代わりしていくでしょう。

問題は、近道を使うことではありません。

近道をした結果、何を通らなくなったのか

です。

完成物を見ても理解度が分からない

以前は、初心者のコードを見ると、その人がどこで困っているかが比較的分かりました。同じ処理が何度も書かれている。変数名が分かりにくい。if文が複雑になっている。必要のない処理まで混ざっている。それも学習の跡でした。

ところがAIを使えば、初心者でも整ったコードを出せます。メソッドに分割されている。コメントも付いている。変数名もきれい。場合によっては、本人が知らない設計パターンまで使われています。すると、完成したコードだけを見ても、その人の力が分かりません。

自由制作の発表を見ていても、同じことを感じます。作品としては完成している。でも、質問すると説明できる人と、ほとんど説明できない人がいる。見た目の完成度と理解度が、以前より一致しにくくなっています。ここで教育側も考え方を変える必要があります。

「誰が書いたか」より「誰が扱えるか」

AI時代になると、「これは自分で書いたコードですか？」という問いだけでは、あまり意味がなくなります。

実際の開発でも、すべてを一人でゼロから書くわけではありません。ライブラリを使う。フレームワークを使う。他人が書いたコードを読む。過去のコードを再利用する。サンプルを参考にする。AIもその延長にあります。

大切なのは、そのコードを扱えるかどうかです。

• 読めるか。
• 少し変更できるか。
• 何が起きるか予測できるか。
• おかしいところに気づけるか。
• 他人に説明できるか。
• 採用するかどうか判断できるか。

AIによって、初心者と経験者の差が消えるわけではありません。差が現れる場所が変わると考えた方が近いでしょう。

では、コードを扱えるとは、具体的にどのような状態なのでしょうか。次章では、小さなコードの変更から考えます。

第2章　「書ける」と「分かる」は違う

次のコードを見てください。

transform.Rotate(0, 0, rotSpeed);

Unityを使っている人なら、見覚えのある形かもしれません。これは処理の一部分を抜き出した例です。rotSpeedは、1回の呼び出しで回転させる角度を表します。毎フレーム呼び出す場合、時間当たりの回転速度はフレームレートにも左右されます。秒当たりの速度として扱うには、経過時間を考慮する必要があります。

AIに、「ルーレットを回すコードを書いて」と頼めば、このようなコードが出てくることがあります。この処理を繰り返し呼び出すと、ルーレットが回る。そこで初心者は言います。「できました」

では、質問してみます。

• transformとは何でしょうか。
• Rotate()は何をしているのでしょうか。
• なぜ最初の二つは0なのでしょうか。
• rotSpeedを2倍にするとどうなるでしょうか。
• マイナスにするとどうなるでしょうか。

ちなみに、Rotate()に渡している三つの数値は、順に、このオブジェクト自身のX軸、Y軸、Z軸まわりの回転量（度）です。最初の二つが0なので、このコードはZ軸まわりだけを回します。通常の2D配置では、ルーレットは画面に垂直な軸（Z軸）を中心に回るため、Zだけに値を入れているわけです。こうした「数値の並びの意味」も、読む力の一部です。

ここで答えられなくなるなら、「コードを使えた」ことと「コードを理解した」ことは違うと分かります。

写したコードにも価値はある

ここで誤解してほしくないのは、写すこと自体が悪いわけではないということです。教科書のコードを書き写す。AIのコードを使う。先生のコードを真似する。最初はそれでもよいのです。

語学学習でも、最初から自由作文を書くわけではありません。例文を読む。真似する。少し変える。だんだん自分で使えるようになる。プログラミングも似ています。問題は、写したところで止まるかどうかです。

理解を確かめる一番簡単な方法

理解を確かめるために、難しい試験は必要ありません。少し変えればよいのです。

transform.Rotate(0, 0, rotSpeed * 2);

にしたらどうなるか。実行する前に予想します。次に、

transform.Rotate(0, 0, -rotSpeed);

ならどうなるか考える。予想する。変更する。実行する。結果を見る。この小さな実験だけでも、コードと動作の関係が見えてきます。私はこの流れを、初学者にもっと経験してほしいと思っています。

予想 → 変更 → 実行 → 確認

です。AIが完成コードを簡単に作れるからこそ、そのコードを「少し壊してみる」学習が重要になります。

説明できるか

もう一つ、とても簡単な確認方法があります。説明してみることです。

「この1行は何をしていますか」。正確な専門用語を使わなくても構いません。「このオブジェクト自身のZ軸を中心に、rotSpeed度だけ回しています」と言えれば、かなり理解できています。一方、「これはAIが書いたので……」で止まるなら、まだ自分のものになっていません。

説明することには、頭の中の曖昧さを表に出す力があります。「なんとなく分かっている」と思っていても、言葉にすると説明できない。そこが、次に学ぶ場所です。

AIを「答えを出す機械」から変える

AIの使い方も変えられます。例えば、「このコードを1行ずつ説明してください」だけで終わらせない。続けて、「私が理解できたか確認する問題を出してください」と頼みます。AIが、「rotSpeedをマイナスにするとどうなりますか？」と聞いてくる。自分で答える。間違えば説明してもらう。

こうするとAIは、答えを出す装置から、理解を確認する相手に変わります。学習におけるAIの価値は、こちらの使い方の方が大きいかもしれません。

こうした確認をするためには、コードを読むための基礎が必要です。次章では、初学者に残したい基礎を整理します。

第3章　基礎は、どこまで学ぶ必要があるのか

「AIがあるなら、もう文法を覚えなくてもいいですよね」

この疑問は自然です。実際、一字一句暗記する必要性は以前より下がっています。API名を忘れた。引数の順番を忘れた。細かな書き方が思い出せない。その程度なら、その場で調べればよい。AIに聞いてもよい。

しかし、「暗記しなくてよい」と「理解しなくてよい」は別です。

読めなければ、AIの答えを評価できない

例えば、

if (hp <= 0)
{
    Destroy(gameObject);
}

というコードがあります。ifが条件分岐だと知らない。hp <= 0が条件だと分からない。Destroyが何をするのか見当もつかない。その状態では、AIが出したコードを評価できません。

もちろん、全部を何も見ずに書ける必要はありません。しかし、「ここは条件を見ている」「条件を満たしたら、この処理が動く」くらいは読めてほしい。AI時代の基礎学習は、書くための暗記から、読むための理解へ比重が移っていきます。

初学者に残したい基礎

少なくとも、次のような考え方は理解しておいた方がよいでしょう。

• 変数
• 条件分岐
• 繰り返し
• メソッド
• 引数
• 戻り値
• クラス
• オブジェクト
• 配列やリスト
• エラー
• デバッグ
• 処理の実行順序

これらは、プログラムの「文法書」を暗記するためではありません。コードを見たときに、「何が起きているか」を読むための基礎です。

基礎はAIに対抗するためではない

ここは大切です。基礎を学ぶ理由は、AIを使わなくても済むようにするためではありません。AIを使えるようにするためです。

AIの答えを読める。間違いを疑える。必要な部分だけ変えられる。質問を具体的にできる。おかしな答えを見たときに、「何か変だ」と思える。

電卓がある時代でも、数の感覚が必要なのと似ています。もし電卓が「2×3＝600」と表示したとき、おかしいと思えるか。AI時代の基礎とは、そのための力です。

基礎を学ぶ目的が見えてくると、AIを使ってよいかという問いも、課題の目的に照らして考えられるようになります。

第4章　AIを使うのは「ズル」なのか

教育現場でAIを使う話になると、「それはズルではないか」という感覚が生まれます。本人に考えてほしい課題を、AIが数秒で解いてしまう。教師としては、「それでは勉強にならない」と思う。当然です。

しかし、ここで一度、何を評価したい課題なのかを考える必要があります。

道具を使うこと自体が問題なのではない

学習者は、昔から道具を使ってきました。教科書。参考書。検索エンジン。質問サイト。IDEの入力補完。サンプルコード。先輩の助言。AIだけが突然「外部の力」になったわけではありません。

問題は、何のための課題かです。構文を何も見ずに書けるか確認する試験なら、AIを使えば評価できません。しかし、要件を理解する。動くものを作る。そのコードを説明する。必要な修正を加える。そこまで含めて評価するなら、AI利用を一律に排除する必要はありません。

AI利用を隠させない

AIを厳しく禁止すると、別の問題も起きます。使ったことを隠すようになるかもしれません。そうなると教師は、「どこでつまずいたのか」を見られません。

それよりも、「どこをAIに聞いた？」「最初は何が分からなかった？」「AIが出したコードをどこで変えた？」と普通に聞ける方が教育につながります。AI利用を告白のように扱わない。ただし、使った結果を説明してもらう。私は、その方が現実的だと思います。

見るべきなのは、AIを使ったかどうかではなく、本人の理解が残っているかです。

課題の目的を明確にした上で、もう一つ考えたいのが、学習を続けるための支援です。

第5章　AIを禁止すると、救えない学習者もいる

ある人にとって簡単な説明が、別の人にはまったく届かない。教育をしていると、これは珍しいことではありません。特にプログラミングでは、抽象的な概念になるほど差が出ます。

例えば、メソッド。「処理をまとめるものです」と言って分かる人もいます。分からない人もいます。「料理でいう手順のまとまりです」と例える。それでも分からない。実際のコードを見る。まだ分からない。

教師側は、「もう何度も説明した」と思います。しかし本人にとっては、「何度聞いてもまだ分からない」のです。

AIなら何度でも言い換えられる

ここにAIの大きな価値があります。「もっと簡単に説明して」「コードを使わずに」「日常生活の例で」「図にするつもりで説明して」「この一部分だけ」と何度でも聞けます。

人間の教師には時間の制約があります。一人に30分付きっきりになれば、他の受講者を見られません。AIを補助にすれば、教師が他の受講者を見ている間も、自分のペースで説明を聞き直せます。

ただし、説明が正しいとは限りません。納得できない点は、授業の教材や教師への質問で確かめる必要があります。理解に時間がかかる人ほど、AIから恩恵を受けられる可能性があります。

完全理解を待っていたら、参加できない人もいる

もう一つ、私は重要だと思うことがあります。「分かるまで先に進まない」という教育が、必ずしも全員に適しているわけではないということです。

例えばクラス全体でゲーム制作をしている。一人だけ理解が追いついていない。完全に理解するまでコードを書いてはいけない、とすると、その人は制作に参加できません。そのまま数日たてば、「自分には無理だ」と思うかもしれません。

AIを補助にして、まず形にする。少し動かす。そのあと、「この部分はこういうことだったのか」と振り返る。そんな学び方があってもよいと思います。理解は必ずしも前から順番に完成するわけではありません。後から経験と結びついて分かることもあります。教育では、完全理解より先に、学び続けられる状態を守ることが必要な場面があります。

まず参加し、後から理解を深める。そのためにも、動いた後に何を確かめるかを決めておく必要があります。

第6章　「動いたからOK」を卒業する

プログラムが動く。画面にキャラクターが出る。ボタンを押したら反応する。初心者にとって、とてもうれしい瞬間です。「できた」と思います。

しかし、実際の開発では、ここが終点ではありません。むしろ入口です。別の値を入れたらどうなるか。対象が存在しなかったらどうなるか。何度も実行したらどうなるか。想定外の入力が来たらどうなるか。仕様が変わったらどうなるか。コードは、ただ一度動けばよいわけではありません。

三つの確認

私は、初心者に次の三つを分けて考えてもらうとよいと思っています。

1. 動いたか：まず意図した動作をしたか。
2. 分かったか：なぜそう動いたのか説明できるか。
3. 壊れないか：別の条件でも正しく動くか。

すべての条件で壊れないことを保証する、という意味ではありません。まずは想定する使い方と、起こりそうな例外を決めて確かめます。

AIは一つ目を非常に速くしてくれます。それなら、人間は二つ目と三つ目にもっと時間を使えばよい。これは、AIによって学習が浅くなるのではなく、逆に深くできる可能性を意味します。

AIで浮いた時間を何に使うか

ここが重要です。AIを使って30分かかっていたコード作成が5分で終わった。そこで、「25分得した」で終わるか。それとも、その25分を、コードを読む。値を変える。エラー条件を試す。別の方法と比較する。説明してみる。という時間に使うか。AI時代の学習の質は、この違いで大きく変わります。

AIは学習時間を奪うのではありません。時間の使い道を変える道具と考えることもできます。

検証をしていると、エラーに出会います。次章では、そのエラーを学びにつなげる習慣を考えます。

第7章　エラーは、学習の邪魔ではない

初心者にとって、赤い波線やエラーメッセージは怖いものです。しかし、エラーが出たことだけで、学習そのものを失敗と考える必要はありません。エラーは、プログラムから返ってくる情報です。

赤い波線を残したまま進む

授業をしていると、コードに赤い波線が出ているのに、そのまま入力を続けてしまうことがあります。本人は、「あとで直せばいい」と思っているのかもしれません。しかし、エラーが積み重なると、どこから直せばよいか分からなくなります。

そこで私は、赤い波線を残したまま先へ進まないという習慣を重視するようになりました。エラーを完全に理解できなくてもいい。まず、「今ここに問題がある」と気づくこと。これがデバッグの第一歩だからです。

AIが便利になると、エラーを一度も読まず、そのままAIへ貼り付けてしまうことがあります。これでは、「エラーを見る」という大切な習慣が育ちません。AIに聞く前に、ほんの少しだけ確認します。

• どの行か。
• どんな単語が出ているか。
• 最近変更したところはどこか。
• 赤い波線は残っていないか。

全部分からなくてもよいのです。まず見る。そのあとAIに聞く。

「直して」だけで終わらせない

AIに、「直してください」とだけ頼むと、修正コードを受け取るだけで終わってしまうことがあります。代わりに、「原因を説明してください」「確認する順番を教えてください」「まだ答えは出さず、見るべき場所を教えてください」と聞く。AIは修理屋ではなく、デバッグの練習相手にもなります。

原因を言葉にする習慣は、エラーへの対応だけでなく、採用したコードを説明する力にもつながります。

第8章　AIが書いたコードを説明できますか

実際の開発では、コードはレビューされます。別の人が読みます。修正されます。引き継がれます。そこで、「AIが書いたので分かりません」では通りません。

現場では説明を求められる

開発現場では、AIが書いたコードでも、参考書から持ってきたコードでも、プロジェクトに入れた時点で、そのコードは開発者側の責任になります。レビューで質問されたときに説明できなければ、そのまま承認されるとは限りません。

この点は、AI時代の学習を考える上でとても重要です。問題は、「AIに書かせたか」ではありません。

採用したコードを、自分が説明できるか

です。AIが提案したコードを採用したのは人間です。なぜ採用したのか。何をしているのか。どんな影響があるのか。必要な範囲で説明する責任があります。これはAIだけの話ではありません。参考書のコードでも、Webから持ってきたコードでも同じです。

だから私は、AI時代の学習目標として、コードを説明できることをかなり重視してよいと思います。「このメソッドは何をしている？」「この値を変えたらどうなる？」「なぜここで条件分岐が必要？」。こうした問いへの答えには、本人の理解が表れます。

説明できない部分に気づいたら、そこを小さく分けて調べます。次章では、その問題分解の力を考えます。

第9章　「プロンプト力」より問題分解力

生成AIについて、「これからはプロンプト力が重要だ」と言われることがあります。もちろん、依頼を分かりやすく伝えることは大切です。しかし、その前に必要なのが問題を分ける力です。

例えば、「Unityが動きません」だけでは範囲が広すぎます。入力が取れていないのか。スクリプトが実行されていないのか。GameObjectへの設定が足りないのか。Inspectorの設定が違うのか。画面に表示されていないだけなのか。ここまで切り分けられると、AIへの質問は自然に具体的になります。

良い質問は、プロンプトのテクニックだけから生まれるのではありません。良い観察から生まれます。

• 何をしたか。
• 何が起きたか。
• 何を期待していたか。
• どこまで正常か。
• どこからおかしいか。

この力は、AIの性能が上がっても残ります。観察し、問題を分ける力を育てるには、教える側の働きかけも必要です。

第10章　教える側の役割も変わる

AIがかなりの質問に答えられるようになると、「先生はいらなくなるのではないか」という話も出てきます。私は、教師の役割がなくなるのではなく、変わるのだと思っています。

以前は、答えを知っている人という役割が大きかった。これからは、何を理解すべきかを示す人という役割が大きくなります。

説明しすぎても届かない

授業をしていると、丁寧に説明しようとするほど説明が長くなることがあります。教師側は、「ここも大事だ」「あそこも補足したい」と考えます。しかし、学習者側からすれば、情報が多すぎて何が重要なのか分からなくなることがあります。実際、説明が長いと感じられていることに気づき、私は考え直しました。

すべてを授業中に話すのではなく、授業では核だけを説明する。補足は記事にする。必要な人が自分のペースで読む。分からなければAIにも聞く。そうした分担の方がよい場面があります。

全部説明する必要はありません。ここまでは授業で扱う。ここからは自分で読む。分からなければAIに聞く。最後に自分で説明する。このように、教師は学習ルートを設計する役割を持ちます。

AIの答えを一緒に疑う

教師が見せるべき姿勢の一つは、「AIの答えをそのまま信用しない」ことです。「本当にそうかな？」「公式情報ではどうなっている？」「もっと単純にできない？」と一緒に考える。AIの使い方という操作方法以上に、AIとの付き合い方を見せることが、これからの教育になると思います。

学習ルートを変えるなら、学んだことを確かめる評価方法も、それに合わせて変える必要があります。

第11章　評価方法も変える

AI時代に、「このプログラムを完成させなさい」だけでは理解度を測りにくくなります。AIが完成させるかもしれないからです。そこで評価を少し変えます。

• 「このコードを説明してください」
• 「この値を変えたらどうなりますか」
• 「ここにバグを一つ入れました。直してください」
• 「AIが提案した案を一つ採用しなかった理由を説明してください」
• 「別の方法を考えてください」

これならAIを使っても、本人の理解が必要です。評価の中心を、成果物だけから、理解・変更・説明・判断へ広げる必要があります。

AIを禁止して利用を見張るより、「AIを使ってよい。その代わり説明してください」の方が、現実的な教育になる場面も増えていくでしょう。

ここまでの考え方を、日々の学習で実践できる5つのルールにまとめましょう。

第12章　AIと一緒に学ぶ5つのルール

ここまでの内容を、初学者が実践できる形にまとめます。

ルール1　まず少しだけ自分で考える

30秒でも構いません。AIに聞く前に、「何が分からないのか」を考える。それだけで、質問も理解も変わります。

ルール2　完成コードだけを求めない

完成コードが必要な場面もあります。しかし、「考え方だけ教えて」「この1行だけ説明して」「次に何を確認すればよい？」という聞き方も使います。

ルール3　少し変えて、結果を予想する

値を変える。条件を変える。1行消す。実行する前に予想する。これが理解を深めます。

ルール4　最後に自分の言葉で説明する

コードを見ながらでも構いません。説明できないところが、次に学ぶ場所です。

ルール5　AIを最終決定者にしない

AIは提案者です。テストする。公式情報を見る。必要なら人に確認する。最後に採用するのは人間です。

理解し、検証し、説明し、判断する。この習慣を通して、最後にもう一度、人が学ぶ意味を考えます。

最終章　それでも、人が学ぶ意味

AIはコードを書きます。説明します。エラーを直します。今後はさらに多くのことができるようになるでしょう。それでも人間がプログラミングを学ぶ意味はあるのでしょうか。

私は、あると思います。ただし、理由は変わります。

昔は、自分でコードを書くために学ぶという意味が大きかった。これからは、AIと一緒に作るために学ぶという意味が大きくなります。何を作りたいのか考える。問題を分ける。提案を読む。結果を確かめる。間違いを疑う。他人に説明する。最後に決める。これらは、AIがコードを書くようになっても必要です。

AIに勝つ必要はない

人間がAIより速くコードを書く必要はありません。大量のAPIを暗記してAIに勝つ必要もありません。学ぶ目的はAIに勝つことではありません。AIに振り回されずに使うことです。

AIが、「この方法がよいです」と言ったとき、「本当にそうだろうか」と考えられる。必要なら、「今回は使わない」と言える。そこに人間側の知識が必要です。

プログラミング教育の目的

プログラミング教育の目的は、キーボードからコードを大量に入力できる人を作ることではありません。コンピュータに何をさせたいのかを考える。方法を組み立てる。結果を確認する。問題があれば直す。そして、自分の判断に責任を持つ。AIがコードを書くようになった今、その目的がむしろはっきりしてきたのかもしれません。

AI時代に初学者が目指すべきなのは、AIなしで何でもできる人ではありません。AIが出したものを理解し、検証し、説明し、必要なら修正し、最後に自分で判断できる人です。

そこまでできれば、AIは学習を奪う敵ではありません。強力な学習の相棒になります。

あとがき　私自身も、まだ答えを探している

この本に書いたことを、私は完成した答えだとは考えていません。生成AIは今も変化し続けています。今日できないことが、数か月後には普通にできるようになるかもしれません。教育現場の正解も変わるでしょう。

私自身、授業を続ける中で考え方が変わってきました。AIに頼りすぎるのは良くない。そう思う一方で、AIがあるからこそ授業について来られる人もいるのではないか、とも思うようになりました。AIで完成させたコードをまったく説明できない姿を見ると、やはり理解は必要だと思います。一方、理解が追いつかず学習そのものを諦めてしまうくらいなら、AIを使ってでも参加し続けてほしいとも思います。

この二つは、矛盾していないのだと思います。

• AIを使ってよい。ただし、理解を手放さない。
• AIに助けてもらってよい。ただし、判断まで丸投げしない。
• 分からないまま前に進んでもよい。ただし、自分が分かっていないことには気づいている。

これから必要なのは、そのくらい柔らかな学び方なのかもしれません。

この本が、「AIを使うか、使わないか」という二択ではなく、「AIをどう使えば自分の学びにつながるのか」を考えるきっかけになればと思います。

付録1　AIと学ぶための5原則

第12章の要点を、手元に置いておける形にまとめたものです。

1. まず少しだけ自分で考える
2. 完成コードだけを求めない
3. 変更して結果を予想する
4. 自分の言葉で説明する
5. AIを最終決定者にしない

付録2　初学者向けチェックリスト

AIが作ったコードについて、自分に問いかけてみてください。

• このコードは何をするものか。
• 主要な変数は何を表しているか。
• 条件分岐は何を判断しているか。
• どのメソッドが呼ばれているか。
• 値を一つ変えるとどうなるか。
• エラーが出たら最初に何を見るか。
• AIの回答で理解できていない部分はどこか。
• 自分が変更した部分はどこか。
• このコードを採用した理由を説明できるか。

全部答えられなくても構いません。答えられないところが、次に学ぶ場所です。

付録3　教える側のチェックリスト

• この課題で何を学ばせたいのか明確か。
• AIを禁止する場合、その理由を説明できるか。
• AIを使っても理解度を確認できる課題になっているか。
• 成果物だけでなく説明能力も見ているか。
• コードを少し変更させているか。
• エラーを自分で読む機会を残しているか。
• 理解に時間がかかる人がAIを補助に使える余地があるか。
• AIの答えを疑い、確認する姿勢を教師自身が見せているか。
• 「できた」だけでなく「なぜ」を聞いているか。

著者紹介

小西秀明

ITエンジニアとしての経験を経て、職業訓練のプログラミング講師として、C#、Unity、IT基礎などを指導。

授業では、プログラミング未経験者や学習につまずきを抱える受講者と向き合いながら、「どう説明すれば伝わるのか」「どこまで理解を求めるべきなのか」を考え続けている。

技術ブログsoft-rime.comでは、授業で理解しづらかった内容を中心に、Unity、C#、IT基礎について初心者向けの補足教材を公開。

生成AIの普及により、コードを書くことそのものの意味が変わり始めた現在、AIを禁止するのでも、すべてを任せるのでもない新しいプログラミング学習のあり方を模索している。

著者：小西秀明 · ソフトライム