【学習】AI時代の真の上級者は「最も速く書く人」ではなく、「最も上手く疑う人」（AI時代のプログラミング学習 第5回）
【AI時代のプログラミング学習 第5回】
第1回｜第2回｜第3回｜第4回｜第5回（今ここ）｜第6回｜第7回｜目次へ
この回は、Unityでの制作に進んだ人向けの発展編です。シングルトン、非同期、マルチプレイなど、まだ習っていない用語も出てきます。全部分からなくても構いません。「上級者はこういう問いを立てるのか」と読んでください。
AI時代において重要なのは、「書く速さ」ではなく「疑う力」です。
AIが書いたコードをそのまま貼り付けて、「とりあえず動いた」で終わらせてしまうことは、誰にでもあります。その裏で、見えないバグや設計の歪みが潜んでいるかもしれません。
生成AIの登場で、プログラミングの世界は大きく変わりました。かつてはコードを書く速さや知識量が評価されていましたが、今は違います。
AIに
「ログイン機能を作って」
「Unityでマルチプレイを実装して」
「このエラーを直して」
と指示すれば、短い時間で、それらしいコードが返ってきます。AIエージェントなら、複数のファイルにまたがる実装までまとめて進めます。
では、AI時代に価値が下がるものは何でしょうか。それは、「書くこと」だけを強みにした力です。
AIは速い。でも、正しいとは限らない
AIは驚くほど速くコードを書きますが、もっともらしく間違えるという弱点があります。しかも、誤りでも正しそうに見えるのが厄介です。
例えばAIは、
- 存在しないAPIを使う
- 異なるバージョンの書き方を混ぜる
- NullReferenceExceptionの原因を外す
- 危険な非同期処理を書く
- ネットワーク同期で競合を生む
といったコードを生成することがあります。性能が上がって減った誤りもありますが、「異なるバージョンの書き方を混ぜる」は今でも起きやすい誤りです。たとえば Unity 6 のプロジェクトで、以前のバージョンのAPIや入力方式のコードが返ってくることがあります。ここで危険なのは、「AIが書いたから正しいはず」と思い込むことです。
AI時代に価値が上がるのは「疑う力」
AI時代の差は「書く速さ」ではなく、疑う力の深さで生まれます。ある人はAIの出力をそのまま使い、ある人は動かなければ聞き直します。経験を積んだエンジニアは、コードを見る前から仮説を立てることが多いです。
- なぜこの設計なのか
- なぜ singleton が必要なのか（本当に必要か）
- なぜ static なのか（状態管理として適切か）
- 本当に null の原因はそこなのか
- クライアントではなくサーバ側ではないか
- 競合条件はないか
こうした問いを立てられる人は、コードを書く前に設計の矛盾に気づきます。つまり頼りになるエンジニアは、コードを書く人ではなく、仮説を立てて検証する人です。AIに仮説を挙げさせたり、テストを実行させたりすることもできます。ただし、何を確かめれば十分かを決め、その結果を採用の判断につなげる責任は、人間にあります。
疑う力は「実装」にも向ける
設計だけでなく、実装レベルでも「違和感を持つ力」が重要です。例えばAIが生成した1000行のコードの中に、
player = FindObjectOfType<Player>();があったとします。一見問題なさそうですが、経験のあるエンジニアはここで立ち止まります。
- Scene切替後も存在保証はあるか
- Awakeの実行順はどうか
- Multiplayerで複数Playerがいたらどうなるか
- 毎回シーン内を探索して負荷は問題ないか
さらに、FindObjectOfType はUnity 2023.1以降では非推奨となっており、現在は FindFirstObjectByType（どれか1つでよい場合は FindAnyObjectByType）が推奨されています。ただし、新しいAPIに置き換えても、複数の Player から「どれを選ぶべきか」という問題は解決しません。加えて、毎回シーン内を探索する設計自体が問題になることも多く、
- Inspectorから参照を渡す
- 依存性注入（DI）を使う
- 初期化時にキャッシュする
といった方法が望ましい場合もあります。重要なのは、「動くか」ではなく「なぜそう書くか」を疑えるかです。
「動いた」は完成ではない
学習中に陥りやすいのは、「動いたからOK」という考えです。しかし実務では、
- 再現性
- 保守性
- 可読性
- 変更耐性
- 障害時の追跡性
まで求められます。つまり、動くコード ≠ 良いコードです。AIは動くコードを出し、テストを通すところまで進めることもできますが、なぜその設計か・なぜその実装か・何を選び何を捨てたか、までは保証しません。判断するのは人間です。
テストが通った場合も同じです。そのテストが必要な条件を確かめていなければ、十分に確認できたとはいえません。
疑う対象はAIだけではない
経験のあるエンジニアほど、AIだけでなく、
- 自分の思い込みや解釈の誤り
- 他人の説明
- ブログ記事や動画解説
- 公式ドキュメントの読み違い
も検証します。これは「何も信じるな」ではなく、鵜呑みにせず、自分で検証するということです。エンジニアの仕事は、観測 → 仮説 → 検証の繰り返しです。
AIを使うな、ではない
AIを使うなという話ではありません。むしろ、上手に使えば心強い味方です。例えば、
- ボイラープレート生成
- リファクタ案出し
- エラー解析
- ドキュメント要約
- テストコード作成
などは大幅に効率化できます。問題は、思考までAIに任せることです。ここを手放すと、せっかくの学びの機会を逃してしまいます。
最後に
AI時代に必要なのは「最速タイピング」ではなく、違和感を持つ力・本質を見抜く力・仮説を立てる力・検証する力です。つまり真の上級者とは、最も速く書く人ではなく、最も上手く疑う人です。
AIが強くなるほど、この差は広がります。コードを書ける人は増えますが、コードを疑える人は簡単には増えません。
AIが書いたコードを読めるようになると、AIは「答えを写す相手」から「一緒に考える相手」に変わります。コードを書く前に一度疑ってみる習慣を、少しずつ一緒に身につけていきましょう。