「LLMが使える」と「ソフトウェアを作れる」は地続きに見えて別の筋肉で、採用要件がそこを混ぜると、半年後に誰も直せない本番が残る。

「LLMが使えるエンジニア」と「ソフトウェアエンジニアリングができるエンジニア」は別の能力だ

思考版1 AI執筆

「LLMが使える人が欲しい」。そう書いた求人に来た候補者は、面接でデモをさらりと動かしてみせる。プロンプトもRAGも、淀みない。なのに採用して半年、本番がある日落ちて、原因を追える人が社内に誰もいない。

顧問として採用の横に立っていると、この景色を何度も見る。「LLMが使える」と「ソフトウェアを作れる」を同じ能力だと思い込んだ瞬間に、必ず起きる。

地続きに見えて、別の筋肉

能力A：AIと組む知識

  • 主要なLLMのAPIに触れて、何かを動かしたことがある
  • プロンプトの勘所と、モデルごとの癖を知っている
  • RAGやツール呼び出しの構え方がわかる

ここで効くのは、AIを「道具として叩く」発想ではなく、AIを相棒として「どう組ませるか」を設計する感覚だ。この能力は独学と数ヶ月〜1年の実務で届く。ソフトウェアエンジニアリングの土台がなくても、ここまでは持てる。

能力B：ソフトウェアエンジニアリングの基礎

  • 半年後の自分と他人が触れる前提で、保守性を設計できる
  • テストで品質を担保し、壊れた箇所を切り分けられる
  • 本番で火が出たとき、ログから原因にたどり着ける
  • チームのコードベースに、波風立てず機能を足せる

こちらは数年の実務でしか積み上がらない。そしてAの知識とは独立して存在する。AIと上手く組める人が、必ずしも本番を支えられるわけではない。逆もまた然り。

なぜ混ざるのか

求人に「LLMを使って開発した経験がある方」と書けば、集まるのは文字どおり「LLMを使ったことがある人」だ。

だが採用側が本当に欲しいのは、たいてい「AIを相棒に本番で動くものを作り、半年後にチームへ渡せるエンジニア」のほうだ。要件と面接が能力Aしか測っていないと、土台の弱い候補者を、自分の手で選んでしまう。

要件の言葉と、面接で測っているものがズレている。これは候補者の問題ではなく、設計の問題だ。

どちらを優先するかは、ポジションが決める

能力A（AIと組む）を優先するとき

  • AIプロダクトの初期プロトタイプを、とにかく速く立てたい
  • 何が刺さるかを試す段階で、捨てる前提で動かしたい

実験の速さがすべてを決める局面では、土台より「AIとどれだけ速く組めるか」を採る。

能力B（土台）を優先するとき

  • 長く保守される本番を作る
  • チームで並行して開発する
  • 既存のコードベースにAI機能を足していく

ここでは判断が逆になる。AIと組む勘所は後から渡せるが、土台は時間でしか積めない。迷ったら土台を採る——速さは教えられるが、設計の筋肉は教えるのに年単位かかるからだ。

月曜から使える、ひとつの実技課題

面接で言葉のキャッチボールをしても、能力Aと能力Bは見分けにくい。だから問いだけでなく、両方が同時に出る一手を渡したい。

渡すのは、30分の実技課題ひとつ。 わざと少しだけ散らかった小さなコードベースを用意し、こう頼む。

「ここにAI機能をひとつ足してください。そのあと、本番でこのエラーログが出ました。原因を追って直してください」

この一手で、能力Aと能力Bが同じ画面に並ぶ。

  • AIと組む知識 → 機能を足す手つき、プロンプトとテストの置き方に出る
  • 土台 → 散らかったコードへの振る舞い、ログから原因へたどる足取りに出る

きれいに動いたかより、詰まったときに何を頼り、どう独り言を言うかを見る。能力Aだけの候補者はログの前で固まり、能力Bだけの候補者はAIを相棒として組み込めず手で書ききろうとする。両方ある人は、AIに任せる所と自分で握る所を、迷わず切り分ける。

採用は、すごい人を採るゲームではない

採用は「いちばんすごい人」を採るゲームではなく、「半年後にチームへ渡せる人」を採るゲームだ。

「LLMが使える人が欲しい」と書く前に、決めることがひとつある。このポジションで半年後に困るのは、AIと組めないことか、本番を支えられないことか。先にそこを決めれば、要件の言葉も、面接の一手も、自然と揃う。

関連記事