ある朝、エディタを開いたら補完が一切返ってこない。チャットに何を投げても「サービスを利用できません」とだけ返る。AIコーディングが、ある日まるごと使えなくなった——そんな世界を想像してみてください。あなたは、昨日まで書いていたコードを今日も書けるでしょうか。
これは予言ではなく、自分のスキルを測るための思考実験です。
なぜ「消えたら」を問うのか
AI が手を貸してくれている間は、できることとできないことの境界が見えません。動くコードが出力された事実だけが残り、それを自分で書けたのかどうかは曖昧なまま流れていきます。
ここで効くのが「もし AI が消えたら」という問いです。手元の道具を一度取り上げてみると、残るスキルと借りていただけのスキルがくっきり分かれます。AI が消えても書けるものが、いま本当にあなたが持っている力です。
問うべきは「AI で何ができるか」ではなく、「AI なしで何が残るか」。
借り物の能力と自分の力
AI が肩代わりしてくれるものを、二つに分けて考えてみます。
| 借り物の能力 | 自分の力 | |
|---|---|---|
| 例 | API の正確な引数、定型実装、構文の暗記 | 何を作るかの判断、設計、問題の切り分け |
| 消えたとき | ドキュメントを引けば取り戻せる | 取り戻すのに時間がかかる、あるいは育っていない |
| 危険度 | 低い | 高い |
引数の順番やライブラリの使い方を覚えていないのは、実は大した問題ではありません。それは消えても調べ直せるからです。本当に怖いのは、判断や設計といった「調べても出てこない力」を、AI に任せているうちに育てそびれることです。
問題は、この二つが日々の作業では混ざって見えることです。AI が設計まで提案してくれると、自分が判断したのか、提案を承認しただけなのか、区別がつかなくなります。
空洞化はどこで起きるか
スキルの空洞化は、派手な失敗としては現れません。静かに、次のような場面で進みます。
- 読む力 — AI が書いたコードを、隅々まで理解せずマージしている。動くから通す、が癖になる。
- 問題定義 — 「何を作るべきか」を曖昧なまま AI に投げ、返ってきたものを仕様だと思い込む。
- デバッグ — エラーが出たらまず AI に貼り付ける。自分で仮説を立てて切り分ける回路を使わなくなる。
どれも、AI がいる間は何の痛みもありません。痛みが出るのは、AI が答えを外したときと、AI が消えたときだけです。そしてそのとき、鍛えそびれた回路は急には動きません。
では、いま何をするか
AI を使うのをやめる、という話ではありません。道具は使い倒した方がいい。問いたいのは使うかどうかではなく、何を自分の中に残すかです。
- 出力されたコードは、自分の言葉で説明できるまで読む。説明できないものはマージしない。
- 「何を作るか」だけは、AI に投げる前に自分で言語化する。
- ときどき、あえて AI なしで小さく書いてみる。残っている力と錆びた力を、自分で測る。
つまり、借り物は遠慮なく借りつつ、自分の力の方は意識して使い続ける。道具が便利になるほど、使わない筋肉は早く衰えます。
まとめ
- 「AIコーディングが消えたら書けるか」は予言ではなく、自分のスキルを測る思考実験
- AI が肩代わりするものは、調べ直せる借り物の能力と、育てそびれると怖い自分の力に分かれる
- 空洞化は読む力・問題定義・デバッグで静かに進み、AI が外したときと消えたときにだけ痛みが出る
- 対策は AI を断つことではなく、借り物は借りつつ、判断と設計の筋肉を意識して使い続けること