前の記事では、職種の境界が薄れ、個人がロールを変えながら動く時代について書きました。エンジニアはコードを書く人から、AIの出力をコントロールする人へ。エンジニアの今後でも、書く仕事が生産ライン側へ移りつつある、という話を整理しています。
今回は、その延長で、自分がいま感じている「次の時代のAIエンジニア像」を、自動車のたとえでまとめます。正解がある話ではなく、いま見えている変化のメモです。
これまで：車を作り、レールを敷いて目的地へ向かっていた
AIでコードが一般的に書けるようになる前、エンジニアの仕事は、目的地にたどり着くための「車」と「レール」を作ることに近かった、と感じています。
目的地とは、ユーザーの課題を解くこと。機能を届けること。プロダクトとして価値を出すこと。そこへ向かうために、設計し、実装し、テストし、デプロイする。コードを書くこと自体が、かなりの時間と労力を占めていた。
その旅の指揮官は、PdMだったり、プロダクトオーナーだったり、ときにはエンジニア自身だったりする。誰がハンドルを握っていても、現場では「走れる道を整える」作業が大きかった。車がなければ動けない。レールがなければ進めない。だから、作ることに頭が向きがちだった。
いま：車は手に入った。焦点は運転へ移る
AIでコードが書けるようになった今、そのバランスが変わりつつあります。
車をゼロから組み立てなくても、ある程度の性能の車が手に入る。レールを一から敷かなくても、目的地へ向かうための道が、かなりのスピードで開かれる。つまり、「作る」より「運転する」──うまくコントロールして目的地に届ける」部分に、フォーカスが移っている、という感覚です。
目的地そのものは変わりません。ユーザーの課題を解く。機能を届ける。プロダクトとして価値を出す。変わったのは、そこへ至るまでのボトルネックの位置です。かつては「車があるか」が問われた。いまは「渡された車を、ちゃんと運転できるか」が問われ始めている。
高いクルマほど、スピードのコントロールが求められる
ここで大事なのは、手に入る車のグレードが上がっている、という点です。
AIのモデルが進化するほど、出力されるコードの量も、複雑さも、スピードも上がる。いわば、より高性能な車が渡されてくる。フェラーリを渡されたとき、問題になるのは「速いかどうか」だけではない。速く走れるだけでは、目的地にたどり着けるとは限らない。ブレーキ、ハンドル、周囲の状況の読み取り。スピードに見合ったコントロールがなければ、事故るか、道を外れるか、結局は遅くなる。
エンジニアに求められるスキルも、同じ構図に見えます。コードを書く速度が上がった分、設計の判断、品質の見極め、セキュリティや運用の見通し、何を採用して何を却下するか──スピードのコントロールが、これまで以上に中心になる。
意思決定の重要性で書いた話ともつながります。AIが出す選択肢が増えるほど、人間は判断に時間を使う。書く時間が減った分、コントロールに時間が移る。
常にフェラーリが必要なわけではない
ただし、ここで誤解したくないのは、「常に最高性能の車が必要」という話ではない、ということです。
普通の乗用車で目的地にたどり着けるなら、それで十分な場面は多い。社内ツールの改善、小さな機能追加、検証のためのPoC。スピードより確実さや保守性が大事なとき、無理にフェラーリを走らせる必要はない。
競争として、ときにはフェラーリが必要なときもある。市場投入のタイミング、大規模なリファクタリング、複雑な要件を短期間で形にする場面。そういうときに高性能なAIを使いこなせるかは、差になりうる。
大事なのは、いつ・どの場面で・どんな車を選ぶか、そして渡された車をきちんとコントロールできているか、という点です。常時フェラーリが必要かは、時と場合による。むしろ、乗用車を安定して走らせられる人のほうが、現場では頼りになる場面も多い、と思っています。
次の時代のAIエンジニアとは
自分が思っている「次の時代のAIエンジニア」は、こういう像に近いです。
- 目的地（ユーザーの課題解決、機能の提供）を見失わない
- 車を作ることより、運転すること──AIの出力をコントロールすることに重心がある
- 高性能なツールほど、スピードに見合った判断と品質管理が求められる
- 常に最高速を競う必要はなく、場面に応じて車を選べる
- どんな車を渡されても、きちんとしたコントロールができているかが本質になる
職種のラベルとして「エンジニア」が消える、という話ではないと思います。前の記事で書いたように、中身が変わる。手を動かして車を作る時間より、ハンドルを握って目的地へ届ける時間が増える。ときには、PdM的な判断──どの目的地に向かうか──にも踏み込む。
非エンジニアもAIでPoCを回せるようになった今、エンジニアに残る差は、「書けるかどうか」より「届けられるかどうか」に寄っていく。届けるとは、動くものを作ることだけではない。本番で使える品質か。運用を見通せているか。ユーザーの課題に本当に届いているか。そこまで含めたコントロールです。
まとめ
自動車のたとえで、いまの自分の整理をまとめると次のとおりです。
- これまで：エンジニアは車とレールを作り、目的地（課題解決・機能提供）へ向かう道を整えていた
- いま：AIでコードが書けるようになり、焦点は「作る」から「運転する」──コントロールして届ける──へ移っている
- 高性能なAIほどスピードのコントロールが求められる。速いだけでは目的地に届かない
- 常にフェラーリが必要なわけではない。場面に応じた選択と、安定した運転が大事
- 次の時代のAIエンジニアに求められるのは、どんな車を渡されてもきちんとコントロールし、目的地に届けられるか、という能力
正解がある話ではなく、いま見えている変化のメモです。100記事目で書いたように、このブログには思ったこと・感じたことをそのまま残しています。現場で試しながら、また更新していきたいと思います。