ある朝、エディタを開いたら補完が一切返ってこない。チャットに何を投げても「サービスを利用できません」とだけ返る。AIコーディングが、ある日まるごと使えなくなった——そんな世界を想像してみてください。あなたは、昨日まで書いていたコードを今日も書けるでしょうか。

これは予言ではなく、自分のスキルを測るための思考実験です。

なぜ「消えたら」を問うのか

AI が手を貸してくれている間は、できることとできないことの境界が見えません。動くコードが出力された事実だけが残り、それを自分で書けたのかどうかは曖昧なまま流れていきます。

ここで効くのが「もし AI が消えたら」という問いです。手元の道具を一度取り上げてみると、残るスキル借りていただけのスキルがくっきり分かれます。AI が消えても書けるものが、いま本当にあなたが持っている力です。

問うべきは「AI で何ができるか」ではなく、「AI なしで何が残るか」。

借り物の能力と自分の力

AI が肩代わりしてくれるものを、二つに分けて考えてみます。

借り物の能力 自分の力
API の正確な引数、定型実装、構文の暗記 何を作るかの判断、設計、問題の切り分け
消えたとき ドキュメントを引けば取り戻せる 取り戻すのに時間がかかる、あるいは育っていない
危険度 低い 高い

引数の順番やライブラリの使い方を覚えていないのは、実は大した問題ではありません。それは消えても調べ直せるからです。本当に怖いのは、判断や設計といった「調べても出てこない力」を、AI に任せているうちに育てそびれることです。

問題は、この二つが日々の作業では混ざって見えることです。AI が設計まで提案してくれると、自分が判断したのか、提案を承認しただけなのか、区別がつかなくなります。

空洞化はどこで起きるか

スキルの空洞化は、派手な失敗としては現れません。静かに、次のような場面で進みます。

  • 読む力 — AI が書いたコードを、隅々まで理解せずマージしている。動くから通す、が癖になる。
  • 問題定義 — 「何を作るべきか」を曖昧なまま AI に投げ、返ってきたものを仕様だと思い込む。
  • デバッグ — エラーが出たらまず AI に貼り付ける。自分で仮説を立てて切り分ける回路を使わなくなる。

どれも、AI がいる間は何の痛みもありません。痛みが出るのは、AI が答えを外したときと、AI が消えたときだけです。そしてそのとき、鍛えそびれた回路は急には動きません。

では、いま何をするか

AI を使うのをやめる、という話ではありません。道具は使い倒した方がいい。問いたいのは使うかどうかではなく、何を自分の中に残すかです。

  • 出力されたコードは、自分の言葉で説明できるまで読む。説明できないものはマージしない。
  • 「何を作るか」だけは、AI に投げる前に自分で言語化する。
  • ときどき、あえて AI なしで小さく書いてみる。残っている力と錆びた力を、自分で測る。

つまり、借り物は遠慮なく借りつつ、自分の力の方は意識して使い続ける。道具が便利になるほど、使わない筋肉は早く衰えます。

まとめ

  • 「AIコーディングが消えたら書けるか」は予言ではなく、自分のスキルを測る思考実験
  • AI が肩代わりするものは、調べ直せる借り物の能力と、育てそびれると怖い自分の力に分かれる
  • 空洞化は読む力・問題定義・デバッグで静かに進み、AI が外したときと消えたときにだけ痛みが出る
  • 対策は AI を断つことではなく、借り物は借りつつ、判断と設計の筋肉を意識して使い続けること