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