この記事は連載「生成AI時代、エンジニアは何で食っていくのか」の実践編 #04 です。
- 導入編はこちらからどうぞ。
- 実践編 #01 「全員がAIを使える」チームは、なぜ崩壊するのか
- 実践編 #02 誰もやらなかった仕事をやる人が、次の時代のキーマンになる
- 実践編 #03 「AIネイティブチーム」の現場で何が起きているか
- 実践編 #04 PGからプロンプトアーキテクトへ。キャリアを変えた人たちの話 ← 今ここ
- 実践編 #05 組織がAIを導入して半年後、生き残ったエンジニアの共通点
キャリアチェンジの話は、まだ少ない
生成AIの話は「未来の話」として語られることが多い。「○○という職種が生まれる」「△△というスキルが必要になる」——でもそれは、5年後・10年後の話に聞こえる。
でも実際には、もう変わっている人がいます。
この記事では、すでに自分のキャリアをAI時代に合わせてシフトしてきた人たちの話を、会話ベースで紹介します。3人のストーリーです。
以下の話は、複数の現場から聞いた実話をもとに、個人が特定されないよう一部を再構成・匿名化しています。
Aさん（32歳）：PG 7年 → AIアウトプット品質担当
転換のきっかけ
「コードを書く量が明らかに減ってきたんですよね。でも、レビューする量は増えてた。最初は不満でした。俺、コード書きたいのに、って。」
Aさんはバックエンドエンジニアとして7年間、主にJavaとPythonで開発を続けてきた。チームにCopilotが導入されてから、若手メンバーがAIで書いたコードのレビューを任されることが増えた。
最初は「雑用を押し付けられた」と感じていたという。
「でも、やってるうちにわかってきたんです。AIって同じミスを繰り返すんですよ。パターンがある。例外処理の抜け、ログの粒度、テストカバレッジの偏り——こういうのが毎回同じ場所に出てくる。」
その観察を社内ドキュメントにまとめ始めた。「AIコードレビューチェックリスト」として整理して、チームに共有した。
「そしたら、思ったより反響があって。他のチームから問い合わせが来るようになって、気づいたら社内のAIコード品質の相談窓口みたいになってた。」
今のAさんの役割は「AIアウトプット品質担当」。正式な職種名はまだないが、その役割に給与が紐づくようになった。
Aさんが言う、この仕事の本質
「コードの品質管理って、昔からあった仕事です。でも、相手が人間じゃなくてAIになった。それだけ。でも、AIは言い訳しないし、同じミスを指摘すれば直せる。人より扱いやすい部分もある（笑）。」
Bさん（38歳）：SE 12年 → プロンプトアーキテクト
転換のきっかけ
「SEとして要件定義やってたんですが、ある時気づいたんです。お客さんの話を聞いて構造化してAIに投げる——これ、SEの仕事とほぼ同じだって。」
Bさんは長年、金融系システムのSEとして要件定義・設計を担当してきた。AIが普及し始めたころ、自分のスキルとAIの相性の良さに気づいた。
「要件定義って、曖昧な言葉を整理して、システムが理解できる言語に変換する仕事じゃないですか。プロンプト設計って、まったく同じことをAIに対してやってる。」
Bさんが意識的にやったのは、「AIへのインプット設計」を体系化することだ。
「どういう文脈を与えると精度が上がるか、制約条件の書き方、出力形式の指定——これをドメインごとにパターン化していきました。金融系だとこう書く、法的な文書が関わる場合はこう制限を入れる、みたいに。」
その知識をもとに、今は社内外のプロジェクトで「AIをどう使わせるか」を設計するコンサルティングに近い仕事をしている。
Bさんが言う、SEスキルとの連続性
「SEの仕事ってなくなるって言われるじゃないですか。でも私の体感だと、SEスキルは全然無駄じゃなかった。むしろ、AIが入ることでSEの上流部分——つまり『何をシステムにやらせるか』を決める力——の重要性が増した気がしています。」
Cさん（27歳）：PG 4年 → ユーザー文脈翻訳者（兼任）
転換のきっかけ
「エンジニアなのに、なぜかユーザーヒアリングに連れて行かれるようになって（笑）。最初は意味わからなかったんですが、それが今の自分の強みになってる気がします。」
Cさんは若手エンジニアだが、「コードより人の話を聞くのが好き」という自覚があった。PMから「ユーザーインタビューに同席しない?」と声をかけられたのが転機だった。
「ヒアリングで『なんかうまく動かない』って言われたことを、エンジニアに伝えると伝わらない。『画面が固まる』って言われても、状況がわからないと再現できない。でも私には『こういう操作をしたときに、どのデータがどう処理されて』って想像できる。」
Cさんはユーザーとエンジニアの「通訳」として価値を発揮するようになり、今はさらにその先——ユーザーの言葉をAIへのインプットに変換する作業——を担っている。
「ユーザーが言った『こんな感じ』を、AIが処理できる言葉に変えるのが楽しいんですよね。パズルみたいで。」
Cさんが言う、この仕事の難しさ
「難しいのは、ユーザーの言葉を変えすぎないことです。変換しすぎると、本質がずれる。ユーザーが言った『なんとなく使いにくい』の中に、実は重要なニーズが隠れてることがある。それを潰さずにAIに伝える——そのバランスが、まだ難しいです。」
3人のストーリーに共通していること
3人のキャリアを並べると、共通したパターンが見えます。
① 「自分の既存スキルがAIと組み合わさった」形
AさんはコードレビューのスキルがAIレビューに転用できた。BさんはSEの要件定義スキルがプロンプト設計に直結した。Cさんはユーザーとのコミュニケーションスキルが翻訳者として機能した。
ゼロから新しいスキルを習得したわけじゃない。 既存のスキルの「使い方と使う相手」が変わった。
② 「やりたくてなった」より「やってたらなってた」
3人ともキャリアプランを立てて動いたわけじゃない。目の前の課題に向き合い、自分の得意なことで対応していたら、気づいたら新しい役割を担っていた。
これは重要な示唆です。「AIの時代にどのキャリアを選ぶか」を今決める必要はない。今の仕事の中で「自分だけができること」を積み上げていった先に、役割は自然に生まれる。
③ 「言語化」が役割を確立させた
3人とも、自分のやっていることを言語化して発信しています。Aさんはチェックリストにまとめてチームに共有した。Bさんはプロンプトパターンを体系化した。Cさんはユーザーとエンジニアの間の翻訳プロセスを言語化しようとしている。
「なんとなくできる人」は多い。でも「何をやっているかを説明できる人」は少ない。その差が、役割として認知されるかどうかを分けています。
あなたのキャリアの「転換点」はどこにあるか
この記事を読んでいる方に、一つ問いかけさせてください。
今のあなたの仕事の中で、「AIには難しいが、自分にはできること」 はどこにありますか？
コードを書くスピードじゃなくていい。人の話を聞くのが上手、業界の暗黙ルールに詳しい、チームの空気を読んで調整できる、ドキュメントをわかりやすく整理できる——そういう「地味だけど確かにある」強みの中に、次のキャリアの種が埋まっていると思っています。
まとめ
- すでに新しいキャリアを切り開いている人たちがいる
- 共通するのは「ゼロから変わった」のではなく「既存スキルの使い方が変わった」こと
- キャリアチェンジは計画ではなく「目の前のことに向き合った先」に生まれることが多い
- 「言語化して発信する」ことが、役割として認知されるための鍵
次回 #05（最終回）では、AI導入から半年後の組織で生き残ったエンジニアの共通点を書きます。
「自分もこういうシフトをした」「こんなキャリアパスがあった」という話、ぜひコメントで教えてください。こういうリアルな話が、読んでいる人の一番の参考になると思っています。
株式会社なかのひとカンパニーでは随時エンジニアを募集しています。詳しくは採用情報ページをご確認ください。