はじめに
エンジニアの美徳として、よく「自分の仕事を無くす仕事をしろ」って言われますよね。
私もこれまで、GitHub ActionsやGASを使って泥臭い作業を自動化することに全力を注いできました。最近では生成AIに「これ自動化するスクリプト書いといて」と投げれば、一瞬で綺麗なコードが返ってくる時代です。
「いや〜、本当に楽になったな」
そう思いながら、AIと「自動化の未来」について壁打ち（思考の議論）をしていたんです。その中で、ふと、背筋が凍るような致命的なモヤモヤに突き当たりました。
その問いがこれです。
「AIが数秒で吐き出した高度な処理、これから先、私たちはどうやって『本当に合ってるか（妥当性）』をチェックすればいいの？」
処理を作るのは一瞬ですが、それを評価する私たちの「目」が、今とんでもない危機に瀕しているのではないか。今回は、AIとの対話から見えてきたエンジニアの「評価力の危機」と、どうしても答えの出ない「育成の矛盾」、そしてその先にある気づきについて共有します。
1. 自動化が進むほど、人間のスキルが死んでいく？
議論の中で改めてハッとさせられたのが、1983年に提唱された 自動化の逆説（Ironies of Automation） という有名な話です。
要約するとこういうことです。
「システムを自動化すればするほど人間は楽になるが、いざ自動化の想定を超えた大トラブル（未知のバグなど）が起きた時、システムは人間に丸投げしてくる。でも、普段楽をしている人間には、その重大なトラブルを解決するスキル（下地）なんて残されていない」
今、まさにこれが開発現場で起きていませんか？
普段はAIがコードを書き、CI/CDが自動でデプロイしてくれる。でも、いざパイプラインが謎のエラーで壊れたり、AIのコードに微妙なバグが仕込まれていた時、仕組みをブラックボックスのまま使っていた若手（あるいは自分）が誰も直せない……という恐怖です。
2. 人間の脳みそは、1000行のAIコードをデバッグできない
AIは一瞬で大量のコードや複雑な構成を作ってくれますが、人間の脳みそ（ワーキングメモリ）のキャパシティは昔から変わっていません。
コードを「書く」コストがゼロになった結果、「他人が（AIが）書いた複雑な仕組みを、正しく理解して検証する」という脳のコストが異常に高くなっています。
さらに人間には、「AIが綺麗に書いたコードだし、動いてるから大丈夫だろう」と油断するバイアスがあります。1行ずつコードを読んでバグを見つけるという従来の「デバッグ」は、人間の脳の限界によって、もう終わりを迎えているのかもしれません。
3. 本当にわからないのは「これからの新卒・若手はどう育つのか？」
ここで、私の中でさらに大きな「問い（というか、答えの出ない恐怖）」が膨らんでいます。
私たちのように「AIがいない時代」を経験してきたエンジニアは、過去に自分で手を動かして泥臭くコードを書いてきた「下地」があります。だからこそ、AIの出した成果物に対して「あ、これ何かおかしいな」と勘が働きます。
でも、最初からAIが横にいて、AIがコードを書くのが当たり前の時代に入ってきた新卒や若手は、一体どうやってその「妥当性を見抜く観点」を伸ばせばいいのでしょうか？
昔は「自分でコードを書くこと」そのものが、システムを理解するための最大の訓練（下地作り）でした。でも、今はAIに書かせる時代です。書く機会が失われるなら、「レビューする観点（評価力）」を磨くしかない。
じゃあ、「何を基準にそのレビュー観点を持てばいいのか？」
「座学で学べること」は、基本的には自動化できてしまう
おそらく、これからの育成は「座学（コードの設計パターンやアンチパターンの知識）」が中心にならざるを得ない、と予想しています。
底の浅い知識ベースのレビュー観点（チェック基準）なら、それこそプロンプトやCIの仕組み（ハーネス）として組み込んでしまえば、人間がチェックする必要すらなくなります。さらには「ビジネスの文脈（コンテキスト）」すら、仕様やドメイン知識をインプットとしてAIに食わせてしまえば、AIはそれに沿った最適な評価ができてしまうでしょう。
だとすれば、自動化のハーネスを限界まで整備した世界で、新卒や若手が「座学の先」にある、AIを超える『本物の評価力』を身につけるルートは、どこに残されているのでしょうか。
コードを「読む」だけで、その特性を理解なんてできるのか？
百歩譲って、座学で得た知識をベースに「AIのコードをチェックするハーネス（仕組み）」を人間が整備していくとしましょう。
でも、ハーネスを整備するためには、目の前にあるソースコードの特性を100%理解していなければなりません。
「今の若い世代はコードの1行1行ではなく、最初からシステム全体のデータ構造やアーキテクチャのレイヤーで脳内構築しているから、古い世代とは下地の鍛え方が違う」というポジティブな意見もあるかもしれません。
しかし、自分で書いて、失敗して、泥水をすすった経験のない人間が、ただ画面に表示されたソースコードを「読むだけ」で、その真の特性や構造を本当に理解することなんて、できるのでしょうか？
今、若手から失われているのは「コードを書く機会」だけではありません。**「書いて失敗する機会」**そのものが失われているのです。
これからの時代の「失敗」は、自分がタイピングミスをしたというレベルではなく、AIの出力した内容が、いざ本番環境で正しく動かなかったという形になります。
その時、「なぜ失敗したのか？」を理解しようとしたら、結局はAIが吐き出した複雑なソースコードをどこまでも深く読み解き、裏にある仕様を追いかけるしかありません。
4. 「動けばOK」という最適解が、ブラックボックス化を加速させる
「ゼロから書かなくても、AIに中身を解説させたり（ホワイトボックス化）する機会があるから大丈夫だ」という意見もあるでしょう。
ですが、実際の開発現場はそんなに甘くない、と私は思います。
AIの出すコードが「なんとなく一発で動してしまう」のであれば、現場の人間は**「とりあえず動いてるし、テストも通ったからOK！」と、中身を読まずにスルーしていく**のが現実ではないでしょうか。
だって、 「おおむねそれで問題ない」 からです。
わざわざ時間と脳のメモリを使って、動いているコードの中身を隅々まで解き明かすなんて、納期に追われる現場ではインセンティブが働きません。結果として、ホワイトボックスにする手段はあるのに、現場の力学としては「ブラックボックスのまま進める」のが最適解になってしまいます。
究極のコスパの矛盾
そうやって「おおむね問題ない」を積み重ねて進んだ果てに、ある日突然、自動化のハーネスもAIの予測もすり抜けるような『致命的な問題』を踏み抜く瞬間がやってきます。
その時、私たちに、あるいは新卒や若手世代に、それに対応できる「下地」は残されているのでしょうか。ここで、完全に頭がバグるような矛盾（ループ）に迷い込みます。
- ルート1： AIにコードを書かせ、普段はおおむね問題ないからブラックボックスのまま進める。しかし、致命的な問題を踏んだ時に、なぜ失敗したのかを理解するために、自分で書く以上の脳のコストを支払って他人の（AIの）コードを泥臭く読み解く。
- ルート2： 昔ながらに、最初から自分で手を動かしてコードを書き、自分で失敗しながら下地を鍛える。
これ、効率化のコスパ（タイパ）を求めてルート1を選んだはずなのに、エンジニアの成長や、いざという時の生存戦略のコスパとしては最悪な罠に陥っていないでしょうか。
AIに楽をさせてもらうためにAIを使っているのに、いざという時のために、自分で書く以上の脳のコストを支払ってコードを読まなければならない。
私たちは一体、何のために自動化をして、どこに向かおうとしているのか。本当に、わからないのです。
5. そもそも、古い「物差し」のまま議論することに意味はあるのか？
……と、ここまで頭を悩ませておいて、私はもう一つの巨大な矛盾に気づしました。
私が「下地が足りなくなる」「妥当性が評価できなくなる」と怯えているのは、「自分でコードを書いて失敗する」という旧時代の物差しを、そのまま未来に適用しようとしているからではないか。
パラダイムシフトが起きている真っ只中で、過去の物差しを引きずったまま「未来の育成」や「スキルの必要性」を議論すること自体、そもそもナンセンスなのかもしれません。そろばんの達人が電卓の登場を恐れたように、私たちは単に「変わっていくOS」に対して、古い価値観で警鐘を鳴らしているだけかもしれない。
だとしたら、私たちはこれから何を基準に、どうやって仕組みや育成を整備していけばいいのでしょうか？
答えはおそらく、その都度、探索的に適応していくしかないのだと思います。
未来の正解なんて誰も持っていません。AIの進化のスピードに合わせて、発生した課題に対してその都度ぶつかり、リアルタイムに「適応的な最適解」を泥臭く出し続ける。その実験とアジャイルな適応のプロセスの連続こそが、新しい時代におけるエンジニアの「下地」になっていくのかもしれません。
おわりに
「過去の物差し」が完全に壊れ、致命的な問題すらAIが直すようになって、人間がコードを読まなくてもいい世界が来るのかもしれない。
正直なところ、未来がどう転んでもそれは時代の変化ですし、別に構わないとすら思っています。エンジニアの存在意義だの価値だのといった、大層な話に怯えているわけでもありません。
ただ、現場の最前線にいる一人の開発者として、「じゃあ、私たちはこれから具体的にどういう方針で仕組みを整備し、どうやって進めていけばいいのか」が、純粋にわからないのです。
正解の物差しがない過渡期の中で、それでも明日の開発は進んでいきます。
この正解のロードマップがない時代に、どういう方針で仕組みを整えたり、チームを動かせばよいのでしょうか。