- 「上流なら安泰」も「勉強し続ければ大丈夫」も、不安への防衛ラインという意味では同じ構造
- Anthropicの研究で、AI利用者はクイズスコアが17%低下。ただしAIとの関わり方で結果は大きく変わる
- 知識のストックではなく「AIを使って判断する場数」が生存戦略になる
Xでこんなポストがバズっていました。
「AIがコード書けるならエンジニアいらなくなる」って言う人たまにいますが、実際にAIエージェント使い倒してる現場見ると、要件定義できる人・設計判断できる人・レビューできる人・品質を考えられる人の需要がむしろ爆増してて、いらなくなるのは「言われた通りに書くだけ」の部分だけだった気がする
リプライ欄には「設計できる人が重宝される」「勉強し続けないと」「品質を担保できる人の重要性が増す」といった反応が並んでいます。
一見もっともらしい。でも、これらの主張は全部同じ心理構造を持っていると感じたので、書いてみます。
- 「勉強し続ければ大丈夫」の落とし穴
- 「設計・レビューできれば安泰」も同じ構造
- 「コーダーの成長機会が減る」は本当か
- Anthropicの研究が示す「AIとの付き合い方」
- じゃあ具体的に何をすればいいのか
- AI時代のキャリアに不安を感じたら
- まとめ：全員不安。だから動く
「勉強し続ければ大丈夫」の落とし穴
「勉強」という言葉が暗に想定しているのは、「知識を頭に入れておく」モデルです。
これはAI以前の、自分の脳がランタイムだった時代の戦略。
今は半年前の「正解」が陳腐化するスピードで変化が起きています。愚直にキャッチアップし続けるだけでは、消耗戦になります。へたをすると、頭に一生使わないゴミを貯めにいく行為になりかねません。そしてまさに今、AIがそのゴミを全て焼き払わんとしています。
何より、何を勉強するかの選球眼こそが本体なのに、そこが抜けています。
「何が起きるかわからないけど、勉強してれば安心」というのは、方角を決めずに走り続けているのに近い。不安への処方箋として「努力」を置いているだけではないでしょうか。
「設計・レビューできれば安泰」も同じ構造
AI時代の議論で一番「安全圏」扱いされているのが、設計とレビューができるポジションです。
「コーダーは代替されるけど、設計・レビューできる自分は大丈夫」という線引き。
でも冷静に考えてみてください。レビューの中でも、コードの整合性チェック、ベストプラクティスとの照合、セキュリティの穴探し。これらはAIがむしろ得意な領域です。
もちろんレビューにはビジネス文脈の理解や、設計思想との整合性判断といった、AIには難しい部分もあります。でもそれは「レビューができる」の上澄みであって、レビュー業務の大半を占めるチェック作業はAIに置き換わりつつあります。
設計の壁打ちだってAIでできます。
「レビューができる人が大事」と言っている人の多くは、今の自分のスキルセットが安全圏に入っていると信じたいのではないでしょうか。
「コーダーは淘汰される」「勉強し続ければ大丈夫」「上流なら安全」。
言っている内容は違いますが、心理的な構造は同じです。どれも不安に対する防衛ラインを張っているだけ。漏れなく全員、首にカマを当てられている状態ではないでしょうか。
「コーダーの成長機会が減る」は本当か
「コーダーは下流だから代替される、上流に成長しないと」という考え方は、ウォーターフォール的なキャリアパスを前提にしています。
実際にAIによって起きているのは、階段の消滅です。
うまくやるコーダーは、AIを使って今すぐ要件定義からテスト、リリースまで一人で回せるようになる。「まず上流を学んでから」ではなく、「今日から全部やる」が可能になっています。
要件定義はAIと壁打ちすればいい。テストもCI組ませればいい。
「コーダーの成長機会が減る」は、成長の定義自体が古いのではないでしょうか。AIがあるからこそ、一人で全レイヤーを触れる時代になっています。
役割の境界そのものが溶けている。「どの役割が食われるか」という静的な見方自体が、もう的を射ていません。
Anthropicの研究が示す「AIとの付き合い方」
ここで、Anthropic（Claude開発元）が2026年1月に発表した研究を紹介します。
52人のソフトウェア開発者（主にジュニア層）を対象にしたランダム化比較試験（RCT）で、新しいPythonライブラリの習得にAI支援がどう影響するかを調べたものです。サンプルサイズや対象層に限界はありますが、AIとの関わり方で結果が分かれたという知見は示唆に富んでいます。
AI利用者はクイズスコアが17%低かった
結果は明確でした。
| AIあり | AIなし | |
|---|---|---|
| クイズスコア平均 | 50% | 67% |
| 作業時間の差 | 統計的に有意でない | ― |
AIを使っても速くならず、学びは減った。しかも最も差が開いたのはデバッグ問題。「コードが間違っているとき、なぜ間違っているかを理解する力」が一番ダメージを受けていたわけです。
ただし全員がスコアを落としたわけではない
この研究の面白いところは、AIとの関わり方で6パターンに分類された点です。
低スコア群（平均40%未満）:
- AI丸投げ型 ― 全部AIに書かせる。最速で終わるが理解ゼロ
- 途中から全委任型 ― 最初は自分で書くが、途中からAIに丸投げ
- AIデバッグ依存型 ― 自分でも書くが、エラーは全部AIに解決させる
高スコア群（平均65%以上）:
- 生成→理解確認型 ― コードを生成させた後、フォローアップ質問で理解を確認する
- コード＋説明要求型 ― 生成時に説明もセットで要求する
- 概念質問のみ型 ― 概念的な質問だけして、コード自体は自分で書く
高スコア群がやっていたのは、AIを道具として使いながら判断と理解は自分で持ち続けること。
この研究が示しているのは、「AIを使うな」ではなく、「AIとの関わり方そのものがスキルになる」ということです。
AIは色々なことができます。でも、結局「理解」するのはどこまで行っても自分自身。理解した上でAIを使う。AIが出したものを理解する。この双方向の「理解」が、AIを道具として使いこなすための土台になります。
じゃあ具体的に何をすればいいのか
「打席に立て」だけでは「勉強しろ」と同じ抽象論になってしまうので、具体的に書きます。
AIで浮いた時間を「速さ」ではなく「深さ」に使う
自分の話をすると、開発パイプラインをAIで自動化したことで、実装にかかる時間は確実に減りました。
ただ、その浮いた時間を「早く終わらせること」には使っていません。設計、レビュー、テストに回しています。
「AIがあるんだから早く終わるでしょ」というプレッシャーは現場にあります。でも、それに乗っかって穴だらけのPRを出す方がダメージは大きい。レビュアーの時間を奪い、手戻りで結局遅くなり、「AIで書いたコードは品質が低い」という評価が自分につく。速さで評価を取ろうとして、信頼で損する最悪のパターンです。
AIが回っていなかった時代は、チケットを捌くだけで手一杯になりがちな現場が多かったはずです。AIのおかげで、ビジネス要件を深く理解しに行ったり、プロダクト全体を俯瞰する余裕が生まれやすくなったと感じています。
これはAnthropicの研究の高スコア群とも同じ構造。AIで浮いたリソースを、AIが苦手な部分――文脈の理解、判断、全体の俯瞰――に再投資する。丸投げして速く終わらせるのとは、見た目は同じ「AIを使ってる人」でも中身はまったく違います。
表面上は同じでも、中身はまったく違う
これはエンジニアになる前の会社員時代から思っていたことですが、たとえ雇われでも、自分がボスのように振る舞う。自分は会社と対等だと思って仕事をしています。
表面上はコードを書いているように見えても、プロダクト全体を見ている人と、本当にコードしか書いていない人では、まったく訳が違います。
AIの時代になって、その差はさらに可視化されやすくなりました。チケットを受けて実装するだけなら、AIに置き換えやすい。でも「なぜこのチケットが必要なのか」「このプロダクトは全体としてどこに向かっているのか」を理解した上で動いている人は、代替が難しい。
AIとの距離を近く保つ
日常業務で「これAIにやらせたらどうなる？」を毎回試す。知識として知っているのと、実際にプロンプトを書いて結果を判断するのは別物です。
Anthropicの研究で高スコアだった人たちがやっていたのもこれ。AIの出力を鵜呑みにせず、選択肢を出させて自分で選ぶ。
何かトラブルが起きたとき、障害の仕組みなんて一般的なケースはすぐ調べたりAIから引き出せます。大事なのは「今この状況で、どの手段がベターか」を選ぶ力。これは座学では身につきません。
AIが使えなくなった時間の過ごし方
以前、Claude（自分が使っているAIツール）の週の利用制限に達したことがあります。
AIを高度に活用していたからこそ、その時の落差が大きかった。
これは乗り物と同じです。徒歩→自転車→車→飛行機と便利になるほど、使えなくなった時に「自分では何もできない」感が増す。今の時代、東京から大阪まで歩く人がほぼいないように、AIなしで作業するのが急に非現実的に感じられる。
ただそこで気づいたのは、AIが使えない時にしか目が向かなくなっていたことがあるということ。コードを手で書く感覚を取り戻したり、ドキュメントを丁寧に読んだり。「AIにやらせれば済む」で先送りしていた細部に、自然と向き合えました。
最低限の地力を保っておくのは体作りと同じです。「保険」として取っておくのではなく、制限という強制停止があるからこそ見えてくるものがある、という話です。
凹む必要はない。使える時はフル活用する。止まった時は、ないがしろにしていたところに目を向ける。この使い分け自体が、AIと長く付き合うための感覚だと思っています。
一人で全レイヤーを回す経験を持つ
小さくていいので、要件定義→実装→リリースまで一人で完結するプロダクトを持つ。Chrome拡張でも個人ツールでも何でもいい。
本業の中でも同じことはできます。自分の担当範囲のチケットを捌くだけでなく、「なぜこの機能が必要なのか」をPMに聞きに行く、隣のチームのAPIを読みに行く。ロールの境界は、誰かに許可をもらわなくても自分で溶かせます。
「自分のロールはここまで」という境界を意図的に溶かすことで、「上流が食われたら終わり」というリスクから自然に離れられます。
知識のストックより判断の場数
勉強会やインプットの時間を減らしてでも、アウトプットの回数を増やす。
完成度より打席数。雑でもいいから出して、フィードバックを食らう。判断力は、判断して結果を食らって修正するサイクルでしか磨かれません。
AI時代のキャリアに不安を感じたら
AI時代の変化に不安を感じている方に向けて、関連する記事をまとめました。
まとめ：全員不安。だから動く
「勉強し続ければ大丈夫」も「設計・レビューできれば安泰」も「上流に行けば大丈夫」も、全部不安に対する自分なりの防衛ラインです。
その不安自体は正しい。誰も本当のところはわかりません。
ただ違いがあるとすれば、不安を知識や肩書きで埋めようとする人と、不安を抱えたまま打席に立ち続ける人。後者の方が変化への適応力は高いと考えています。
もちろん、「打席に立て」もまた別の防衛ラインでしかないかもしれません。自分が書いていることも含めて。ただ、自分の防衛ラインが防衛ラインであると自覚しているかどうかで、次の一手の質は変わるはずです。
Anthropicの研究が示したように、AIを使うこと自体が問題なのではなく、AIとどう関わるかが問われています。
不安を消そうとするのではなく、不安なまま動けるかどうか。
それが、AI時代にエンジニアとして生き残るための、一番地味で一番確かな戦略ではないでしょうか。
