AIで実装は速くなったのに、スキルが伸びている気がしない。伸びる使い方と止まる使い方の差

生成AIでコードを書くのが当たり前になってから、実務経験者からこの話をよく聞くようになりました。タスクは明らかに速く終わるのに、自分が強くなっている感じだけが無い。

検索しても、出てくるのは両極です。「AIに仕事を奪われる／奪われない」という大きな話か、「この指示の出し方が効く」というプロンプト集。毎日使っている人が知りたいのは、その中間にある「この使い方を続けて大丈夫なのか」という部分で、そこを書いた記事はあまりありません。

この記事では、AIを使うべきか否かという議論はしません。使う前提で、同じツールを使っているのに伸びる人と止まる人に分かれる理由だけを書きます。

速くなったのは実装。伸びるかどうかを決めるのは判断

まず、混ざりやすい2つを分けます。

実装は作業です。頭の中にある答えをコードの形にする工程で、ここはAIが圧倒的に速い。一方、判断は「何を作るか」「どの形で作るか」「この状態で出していいか」を決める工程で、こちらは誰かが必ず通る必要があります。

違いは使用量ではありません。判断の工程を自分が通っているかどうかだけです。ここを通さずに済ませると、タスクは終わるのに経験値が増えないという、いま感じている状態になります。

逆に言えば、AIの使用を減らす必要はありません。減らしても、判断を自分で通していなければ同じです。

止まる使い方に共通する3つ

自分がどちら側かは、次の3つで分かります。1つでも当てはまるなら、速度と引き換えに経験値を渡している可能性があります。

動いたら終わりにしている

テストが通った、画面が出た、エラーが消えた。そこで次のタスクに移る。これが一番多いパターンです。

実装の経験値は、動いた瞬間ではなく、「なぜこれで動くのか」を確かめたときに入ります。動いた理由を説明できないまま積み上がったコードは、障害が起きたときに手が出ません。そして障害対応は、AIに貼って解決する種類の仕事ではないことが多い。

採用した理由を言えない

「なぜこのライブラリなのか」「なぜこの構造なのか」と聞かれて、「AIがそう書いたので」としか言えない状態です。

これは面接だけでなく、チームのレビューでも露呈します。レビュアーは実装の良し悪しより先に「この人は分かって出しているか」を見るので、理由が出てこない時点で指摘の量が増えます。結果としてレビューの往復が増え、速くなったはずの時間が戻っていきます。

詰まった瞬間に投げ直している

エラーが出たらそのままコンソールの内容を貼って、返ってきた修正をそのまま当てる。直ることは直ります。

ただ、デバッグの力は「どこが怪しいかを絞る」工程で付くもので、そこを飛ばすと何度やっても付きません。「自走できるエンジニア」とは何かで挙げた4つの力のうち、AIを使っても落ちないものと、意識しないと落ちるものがはっきり分かれるのはこの部分です。

手順を1つ足すだけで、伸びる側に変わる

やることは増えません。順番を変えるだけです。

2つ目が本体です。自分が「A案でいこう」と思っていたのにAIがB案を出してきた、という場面は毎日あります。そこで理由を確かめると、自分の中に無かった判断基準が1つ増える。これはAIを使う前には得られなかった学び方で、うまく使えば独学の速度は明確に上がります。

逆に、自分の案を持たずに書かせると、この比較が起きません。同じ1時間でも、残るものが違ってきます。

「AIが書いたコードをレビューできない」は、AIのせいではない

よく聞く悩みですが、原因はAIではありません。レビューできないコードは、AIが書く前から読めなかったコードです。

出てきたコードを見て良し悪しが言えないのは、判断の基準を持っていないからで、基準が無い状態は人が書いたコードが相手でも同じです。AIは量を増やしただけで、問題を作ってはいません。

基準の作り方は、使う技術ごとに違います。ReactであればReactの「実務レベル」とは何かで、状態をどこに置くか・どこで分けるかといった判断の単位を整理しました。設計そのものが苦手だと感じているなら、実装はできるのに設計ができない原因のほうが先です。

差が表に出るのは、速度が評価されなくなったとき

AIで速くなった分は、しばらくすると前提になります。全員が同じツールを使っているので、速いこと自体では差がつかなくなる。そのあとに残るのは、速度では測れない部分です。

この5つはどれも判断の工程です。AIが実装を引き受けたことで、評価の重心がここに寄ったというのが、いま起きている変化の実態に近いと思います。置き換わったものと残ったものの整理はAI時代に生き残るエンジニアは何が違うのかに書きました。

市場での評価がどこで決まるかという観点では、エンジニアの市場価値を上げる方法と同じ話に行き着きます。社内では速さが評価されても、外での評価は判断の質で決まる、という構造は変わっていません。

正直なところ：AIを控えても伸びません

「このままだとまずい気がするので、AIを使う量を減らそうと思う」という相談を受けることがあります。これはあまり効きません。

• 手で書いても、判断を伴わない写経なら経験値は入らない
• 速度を落とすことで、試せる回数が減る。試行回数は学習そのもの
• 現場はAI前提の速度で回っているので、戻せない

やるべきことは使用量の調整ではなく、判断の工程を自分の側に残すことだけです。その上でなら、使う量は多いほど有利になります。

ただし、自分だけで続けていると「判断を通しているつもり」になりやすいのも事実です。自分の基準が妥当かどうかは、自分では確かめられません。ここは外から見てもらうしかない部分で、AIが相手では代わりになりません——AIは、こちらの前提ごと肯定してくることがあるからです。

まとめ

明日から変えるのは1つで足ります。書かせる前に、自分の方針を一言だけ決める。 違う案が返ってきたら、その理由を確かめる。これだけで、同じ作業時間から残るものが変わります。

JISOUは実務経験者向けのスクールで、受講生は自分のアイデアでサービスを作り、提出したコードに現役エンジニアのレビューが入ります。AIを使うことは止めていません。見ているのは、出てきたコードを自分の判断として説明できるかどうかです。「速くはなったが、これでいいのか分からない」という状態が続いているなら、一度外の基準に当ててみてください。