社内でAI Agentの推進役をしていることもあり、最近様々な場所で
Claude CodeとかCodex CLIみたいなAI Agentが出てきて、
エンジニア職ってこれからどうなるんですか？
と聞かれることが増えた。
正直、新卒3年目の自分も不安ではある。
まだキャリアの序盤で、この先何十年と続くはずの仕事が、足元から変わろうとしている。
ただ、不安なりに調べて考えてみると、「エンジニアが丸ごと不要になる」というよりは、エンジニアが二手に分かれていく構図が見え始めている。
AIが出したものの後始末に追われて消耗する側と、AIを使ってアウトカムを出す監督者・設計者として価値が上がる側。
どちらに寄るかは、本人の姿勢と組織の仕組み次第だと思っている。
ただ、この「二手に分かれる」という話には、スキルだけでは割り切れない部分がある。
それについては最後に書く。
AIを無策で入れると何が起きるか
2026年2月、自分は社内でClaude Codeの勉強会を1ヶ月間やった。
自分が企画して運営も回した。
ユニーク参加者は60名弱、毎週の活用事例を集めて百数十件のログが手元に残っている。
参加者の体感値として、平均で6割の時間短縮。
数字だけ見れば、明らかに速くなった。
でも、チーム全体のメトリクスが同じだけ改善したかというと、そうでもなかった。
AIの出力をそのままPRに出すメンバーが増えた結果、レビュアーが「本当に大丈夫か？」をより細かくチェックせざるを得なくなった。
レビューコメント数が増え、リードタイムが伸び、レビュー負荷がリードエンジニアに集中した。
体感は速くなっているのに、全体では詰まっている。
うまく回している人たちは何をしているか
1ヶ月の勉強会の後半、参加者の動き方に明確な差が出始めた。
うまく回している人たちは、AIに実装を丸投げしているように見えて、実は前後で別の仕事をしていた。
- AIに実装を任せている間に、ずっと後回しにしていた設計検討に時間を使っている人がいた。
- リファクタリングのコストが下がったおかげで、半年間放置していた技術的負債を返済できた人がいた。
- 暗黙知をCLAUDE.mdやSkillに言語化して、チームの仕組みとして残している人もいた。
選択肢を比較して設計判断を下し、AIに作業を委任しつつ自分は別の調査に集中し、失敗からフィードバックループを回す。
まさしくオーケストレーターの仕事をしている人たちが高い成果を出していた。
外の世界でも、同じ方向の話が出ている。
例えばRuby on Railsの作者であるDHHは、もともとAI自体には肯定的だった。
ただし「AIにコードを書かせる」ことには明確に懐疑的で、2025年半ばのLex Fridmanとのインタビューではこう語っている。（1:29:03あたり）
I can literally feel competence draining out of my fingers.
（AIに任せると、指先から能力が抜けていく感覚がある。）
自分で打たなければ学べない。
CursorやWindsurfのようにAIにドライブさせるやり方は合わない。
AIは便利だが、書く主体はあくまで人間であるべきだ、というのが当時のDHHの立場だった。
ところが2025年末、ブログで態度が動いた。
エージェントの進化を受けて、pure vibe codingはまだプロ用途では夢だけれど、supervised collaboration（監督つき協業）はもう現実だと認めている。
「自分で全部打つ」派だったDHHが「任せて監督する」形を受け入れたのは、それだけエージェント側の変化が大きかったということだと思う。
Kent Beckも近い方向にいる。
「augmented coding」という概念を提唱していて、AIは開発者を置き換えるのではなく、意思決定・分解・フィードバックの価値を増幅するものだという立場だ。
実際にRustとPythonでB+ Treeライブラリを作り切るプロジェクトで、TDDでAIを制御しながら本番品質のコードを出している。
勉強会でうまく回していた人たちがやっていたことは、DHHの「supervised collaboration」やBeckの「augmented coding」と、構造的にはかなり近い。
「全部読む係」ではなく「仕組みを作る係」へ
個人的に一番しっくり来ているのが、Martin Fowlerのサイトに掲載されたKief Morrisの記事で提唱されている「on the loop」という考え方だ。
Morrisは人間とAIの関わり方を3つに分類している。
- in the loop（AIの出力を逐一チェックする）
- out of the loop（AIに完全に任せる）
- on the loop（仕組みを設計・管理して、AIの挙動を制御する）
勉強会で起きたレビュー破綻は、まさにin the loopの限界だった。
AIが出したコードを全部読もうとして、量に負けた。
逆にうまく回していた人たちは、読まずに落とす仕組みを作っていた。
テスト、型、CI、レビュー観点のSkill化。
on the loopの動き方だ。
この点で、日本で一番具体的に言語化しているのはt-wadaさんだと思う。
AI時代ほどTDDや自動テストが「AIの暴走を防ぐガードレールになる」と述べている。
t-wadaさんが示しているワークフローは、まずAIと設計を議論して合意した内容をADRに落とし、ADRからTODOリストを作り、TODOリストをもとに自動テストを実装して、毎回コミットするようAIに指示する。
こうすることでトレーサビリティが保てる。
AIが書いたものを人間が目視で全部担保するのではなく、
テスト、型、CI、ドキュメント同期、受け入れ条件のような「落とす基準」を先に作っておいて、AIにはその枠内で走らせる。
これが、AI後始末係ではなく、オーケストレーターに寄る道筋だと考えている。
でも、それだけでは割り切れなくない？
ここまで書いてきたことは、「仕組みを作る側に回れば価値は上がる」という話だ。
自分はそう思っているし、実際にAIをオーケストレーションする仕事を楽しいと感じている。（だからAI Agentの推進役をやっている）
でも、この話を手放しでできるかというと、そうでもない。
勉強会のアンケートで、「AIが優秀すぎて、自分の存在意義が揺らいでいる」という趣旨のコメントがあった。
同期のエンジニアの中にも、落ち込んでいる人がいる。
プログラミングが好きでこの業界に入ってきた人間だ。
コードを自分の手で書くことが楽しくて、それが仕事になるのが嬉しくて、エンジニアになった。
「監督者に回れ」「オーケストレーションを覚えろ」は、
その人にとっては「お前の好きだったことはもう価値がないから、別の楽しさを見つけろ」と言われているのに近い。
DHHもLex Fridmanのインタビュー(上記と同じ動画、1:33:05あたり)で、こう言っていた。
「AIに任せて自分がプロジェクトマネージャーになるなら、20年前にプロジェクトマネージャーになれたはずだ。ならなかったのは、自分で書くのが好きだったからだ」と。
Osmaniの続編記事にも「LLMコーディングは、主にコーディングが好きだった人と、主にものを作るのが好きだった人に、エンジニアを分けるだろう」という指摘がある。
これはスキルの問題ではなく、「何が楽しくてこの仕事をしているか」の問題だ。
そして、その楽しさの源泉が、AIによって構造的に変わろうとしている。
つい2日前に公開されたt-wadaさんの動画で指摘されていたことが気になっている。
ジュニア層は人間に聞くよりAIに質問したほうが心理的に楽だから、先輩に聞かなくなる。
その結果、中堅エンジニアが「後輩に教える過程で自分の知識を体系化し、成長する」という回路が断たれつつある、という話だ。
これは 「好きだったことの価値が変わる」だけでなく、「成長の仕方そのものが変わる」という、もう一段深い構造変化だと思う。
正直、自分はAIとの協業が楽しい側の人間だと思う。
でも、プログラミングそのものが好きで入ってきた同期が落ち込んでいるのを見ると、悲しい気持ちになる。
自分のやっているAI推進は本当に人を幸せにしているんだろうかと、じっと考え込んでしまう。
この仕事を続けていく上で、スキルの話とは別に、自分が何に楽しさを感じるかを一度ちゃんと考えたほうがいいのだろう。
エンジニア職ってこれからどうなるんですか？
と聞かれるたびに自分なりの答えを返してきたけれど、
この時代にエンジニアでありたいのなら、本当に考えるべき問いは
自分はなぜエンジニアをやっているのか？
であるだろう。
市場価値やキャリア戦略の前に、この問いに自分の言葉で答えられるかどうか。
自分も、まだ途中だ。
なにかありましたらXでご連絡のほどよろしくお願いいたします。