AIエンジニアは何者か（どこから来て、どこへ行くのか）

1. はじめに

こんにちは。株式会社ACESでAIエンジニアのEMをしている阿久澤(@kei_akuzawa)です。先日、温泉施設でほぼ丸一日間のデジタルデトックスを行いましたが、効果絶大ですね。最近は”AI疲れ”なんて言葉もありますが、こうした息抜きは忘れないようにしたいものです。

さて、冒頭で私は「AIエンジニアの」と自己紹介させていただきました。でも、この自己紹介って実は結構モヤモヤするんですよね。AIエンジニアという職種は新しく、AIの急激な発展にともなってその守備範囲は刻一刻と変化しています。さまざまな会社さんの求人票を見させていただいても重視されている観点は千差万別です。最近流行りのFDE（Forward Depoyed Engineer）のような関連職種も登場し、それらの違いに戸惑うこともあります。

この記事では、”AIエンジニア”という職種に期待されうる役割を紐解き私なりの類型化を試みたいと思います。記事の後半では、AIエンジニアの今後の展望についての仮説も紹介します。JDの記載に悩んでいる採用担当の方や、キャリアに悩んでいる”AIエンジニア”の方に届けば幸いです

💡
この記事を書こうと思ったきっかけは、社内で採用要件の検討を機にAIエンジニアの職能を分解・言語化したことでした。2026年2月現在、ACESでは音声領域のAIエンジニアを切実に募集しています。興味を持たれた方は公式HPから応募、または私のXのDMにてご相談をお待ちしておりますー！

2. 役割を紐解く

さて、AIエンジニアの役割を整理するにあたって、適当な軸を設置したいと思います。ここでは個人的にしっくり来ている2軸で整理します。

2.1 モデル

第一の軸は「モデル」への関与です。近年はAIブームにあやかって何でもかんでもAIと名前をつける風潮がありますが、いまの（第三次、第四次）AIブームのコアとなる技術は間違いなく「モデル（深層学習モデル、そしてその延長線上にある大規模言語モデル）」です。

この軸に沿って、以下3つのカテゴリに分類を行います。

モデルへの関与	説明	代表的な作業
Use	既存のモデルを前提に、プロンプト設計やRAG、UX設計を通じて、システム全体の品質を担保。	・Prompt-tuning ・RAGなどの複合システムのEnd-to-Endの品質改善・UX設計（ex. Human-AI/Agent-Interaction）
Customize	既存のモデルを、特定タスク・制約条件に合わせたチューニングで最適化する。	・モデルパラメータのfinetune ・ハイパラ調整・蒸留等による軽量化
Build	汎用の基盤モデルそのものを設計・学習し、再利用可能な形で提供する。	・LLMの事前学習・事後学習・アーキテクチャ・学習手法の開発

ざっくり言うと「モデルを作る人 / 使う人」といった軸です。「Build」は汎用性を持つ基盤モデルを作るLayerであり、特定のユースケースを強く意識しません。「Customize」は特定のユースケースを意識したモデルのチューニングを行います。「Use」は既存のモデルを活用しながら、ユーザーに価値提供するための複合システム（検索ツールやMemoryなど、モデル以外の外部システムを含む）を作り上げます。

特にここ数年では、以下のような背景のもとで、Build / Customize / Useの区分がはっきりとしてきたなと感じます

基盤モデルの台頭に伴うBuildとCustomizeの分離
- LLMに代表される基盤モデルの訓練には莫大なコストが必要となるため、Buildは一部の巨大資本を持つ企業の仕事に収斂しました。Customizeと使っている技術は一部共通しますが、立ち位置は明確に分かれた印象です
LLMの登場によるUseの存在感向上
- LLMは汎用性が高く様々な仕事を任せられるため、LLMを使ったアプリケーションの数や多様性が拡張し、結果としてUse層の存在感が増したように感じています。

2.2 開発ライフサイクル

第二の軸は「開発ライフサイクル」への関与です。ざっくり言うと「要求定義 → 要件定義 → 設計 → 開発 → テスト → 運用」といった開発の流れのことです。

ソフトウェアエンジニアであっても開発ライフサイクルには得意領域の色が出るところだと思います。それがAIエンジニアにおいては、特にR&DやPoCの段階を中心に色が出ると考えます。AI開発においては、AI特有の不確実性（作ってみないと精度が分からない）を織り込むためにPoCが開発ライフサイクルの一つとして置かれることが一般的です。そしてR&Dと開発には別種のスキルが要求されます。前者は大学・大学院等での訓練によって磨くことができる一方、後者はエンジニアとしての実務経験がものを言います。

そこで本記事では、開発ライフサイクルを「①R&D・PoC、②設計・開発、③運用」の三つに分類します。

①R&D・PoC：製品の実用化に向けたコア技術開発や主要リスクの検証
②設計開発：再現性・保守性・拡張性を持たせて製品に落とす
③運用：品質・コスト・安全性を継続的に担保し改善する

また開発ライフサイクルを「モデルへの関与」ごとに設けると以下のテーブルのようになります（テーブルはLLMに生成させたものですが、大まかには私の意図通りです）

モデルへの関与	開発対象	R&D・PoC（不確実性の解消）	設計開発（プロダクト化）	運用（継続提供）
Use	Application	・価値仮説の検証（ユーザー課題・利用シーン）・プロトタイピング（Prompt/RAG/Agent）・E2E評価の設計とベースライン（簡易セット）・失敗パターン抽出（幻覚、検索漏れ、UX破綻）	・アーキテクチャ設計（RAG構成、ツール設計、状態管理）・ガードレール（入力制御、出力制約、権限制御）・評価基盤の整備（回帰テスト、E2Eテスト）・性能/コスト最適化（キャッシュ、モデル選定、分岐）	・品質監視（成功率、拒否率、幻覚率の代理指標）・オンライン評価/AB（プロンプト・検索・UI改善）・インシデント対応（誤回答、漏洩、逸脱）・ナレッジ更新運用（RAGの更新・鮮度管理）
Customize	モデル	・ユースケース要件と評価指標の定義・データ探索（ラベル方針、偏り、ノイズ）・小規模学習（LoRA等）で当たりを付ける・失敗例分析（誤分類、長文弱さ等）	・学習パイプライン（再現性、版管理、実験管理）・データ作成/前処理の標準化（データ仕様化）・推論最適化（量子化、蒸留、バッチ/ストリーム）・システム統合（API、依存関係、テスト）	・ドリフト/劣化監視（データ/概念/性能）・再学習のトリガー設計（いつ・何で更新するか）・ロールバック/カナリア（安全なリリース）・コスト監視（GPU/推論単価）
Build	モデル	・先行研究・実装サーベイ（SoTA/失敗例）・アーキ/学習手法の検討（スケーリング仮説）・事前学習/事後学習の実験（小〜中規模）・評価体系の設計（能力・安全性・頑健性）	・大規模学習の設計（データパイプライン、HPC）・学習安定化（分散、チェックポイント、再開）・再現可能な訓練/評価フレームワーク整備・リリース形態設計（重み配布/API/SDK）	・提供基盤の運用（Serving、SLA/SLO）・継続評価（回帰、安全性、レッドチーム）・モデル更新計画（互換性、バージョニング）・利用状況監視（濫用、逸脱、性能劣化）

以下に簡単に補足します。

Use : Useは一般的なソフトウェア開発の枠組みに近いものの、AIが組み込まれることで、0/1の「機能の有無」ではなく、「精度・UXの良さ」としての側面が強調されます。モデルに対する理解は比較的必要とされない一方で、PoCにおける評価・実験を行う必要があるのは他レイヤーと同様です
Customize: Customizeでは特定のユースケースに合わせた要件を満たすようにモデルを開発します。モデルの精度はもちろんのこと、コスト要件や顧客システムとの互換性なども満たすことが必要となります
Build: Buildにおける基盤モデル開発はtry-and-errorを含むのでPoCとして位置付けました。また最終的にはAPIなどの形態で製品として提供するような開発ライフサイクルを想定し、開発・運用業務もスコープに入れています。

2.3 留保事項

先ほど、簡単化のために「モデルへの関与」を3つ（Use/Customize/Build）に分類しましたが、実際にはグラデーションがありそうです。例えばRAG開発の一部として、埋め込みモデルを独自に作ることがあるかもしれませんが、これはUseともCustomizeとも言えそうです。開発ライフサイクル内で「R&D・PoC」を取り上げましたが、実際のところR&Dは「基礎研究、応用研究、開発研究」などの段階に細分化することができます。

またAIエンジニアの役割を特定するにあたって「モデルへの関与 x 開発ライフサイクル」の2軸を扱いました。しかし、上記二つ以外にも整理に使えそうな軸はいくつかあります。例えば画像・音声・言語・時系列など、扱うデータのドメインによって技術領域は異なり、しばしば専門職として成立しています。他にもマネジメント v.s. スペシャリスト、あるいはプロダクト v.s. プロジェクトといった軸も考えられそうです。加えて、データ基盤やHPCなどの技術領域については今回スコープ外としています。

もし本記事で捨象されてしまったこれらの要素が大事だと思う人がいたら、、、続きはあなたが書いてください！！！

3. 代表的な職種

さて、ここでは二つの軸（モデル x 開発ライフサイクル）の上に、”AIエンジニア”が該当・関連する職種をプロットしてみます。この2軸は個人のスキル・専門性に対応しているため、職種定義の境目として機能します（プロットに役立ちます）。

さて、こちらは皆様の各職種に対するイメージと合っていましたでしょうか？注意点として、ここでは私のイメージ（独断と偏見）に基づいて職種をプロットしています。他社の職種定義と異なることは往々にしてあると思いますが、本記事のプロットの正当性を主張するつもりは全くありません。大事なのは「この2軸に沿った職種のクラスタが存在している」という仮説であり、そのクラスタどのようなラベル（職種名）をつけるかは自由です。

さて、各職種を該当箇所にプロットした意図を解説します

Research Scientist: 研究開発を担う。開発・運用はスコープ外
Research Engineer: AIの最先端研究と製品化の橋渡しをする職種。Research ScientistよりもR&Dの比率は下がり、ソフトウェアエンジニアリングの比率が上がる。
- Applied ML Engineer: 特定のユースケースにおいてMLの専門性を発揮。
- Applied AI Engineer: MLではなくAIとつく場合は、Customize層（だけ）ではなくUse層までをスコープとするニュアンスを感じる
MLOps Engineer: MLモデルの運用を担う専門職。小規模チームではApplied ML Engineerと兼任することもある。
FDE: 最近流行りの職種。顧客と近い位置で開発ライフサイクルを一気通貫。既存モデルを使う
AI PdM: 最近流行りの職種その2。AIの特性を理解した上で機能開発に落とし込む。

さて、冒頭私は”AIエンジニア”として自己紹介させていただきましたが、上記の整理に基づくとApplied AI Engineerが最近の業務に近そうです。皆さんはいかがでしょうか？

4. 今後の展望

さてAI技術は今も目まぐるしく発展しています。AIエンジニア関連の職種は今後どうなっていくのでしょうか？我々はキャリアをどのように伸ばしていくけばよいのでしょうか？ここでは最新の環境変化を踏まえた今後の展望を雑多に語っていきます。

4.1. スマイルカーブの進行による影響

スマイルカーブ現象とは、製造業においてバリューチェーンの上流工程と下流工程の付加価値が高く、中間工程（組立・製造工程）の付加価値が低くなる現象のことです。中流の組立・量産において標準化・分業が進むことで差別化が困難になり発生すると言われています。

スマイルカーブ現象をAI開発になぞらえると、以下2通りの仮説が立ちます。

モデルの「Build」と「Use」の付加価値は増大、「Customize」は縮小
開発ライフサイクルにおける「R&D・PoC」と「運用」の付加価値は増大、「設計開発」は縮小

実際のところ、米ビックテックや一部スタートアップを中心とした基盤モデルの発展に伴い、モデルの「Customize」需要は減少しているように感じます。2010年代中盤〜ChatGPT登場までは、さまざまな企業が自社開発したモデルというのは明確な競争優位性でした。しかし今では基盤モデルのAPIを叩くだけで企業独自モデルに迫る（あるいは上回る）精度を達成できてしまいます。

一方スマイルカーブ仮説に対するカウンターとして、企業独自のデータやビジネスプロセスと密接に関連するようなAI開発においては、中流工程の標準化が進まないかもしれません。2026年現在、「パランティア」「FDE」の台頭に象徴されるように、企業個別のビジネスプロセスを理解した上でAIを導入することが注目を集めています。このようなオーダーメイド製品を前提にしたときに、中流工程において標準化がどの程度進むかはまだ不明です。具体的には、特定タスクでの精度向上 / コストカットのためのfinetune、ビジネスプロセスにフィットするAIのUX設計（前回ブログも参照）などが中流工程における付加価値として残り続けるかもしれません。

4.2. 縦に伸ばすか横に伸ばすか

スマイルカーブのような環境変化の中で、我々はキャリアをどう伸ばしていくべきでしょうか。

縦に伸ばす（モデル軸）

「Customize」から「Use」への拡張は、現実的な選択肢の一つだと考えます。例えば「Use」層におけるprompt tuningは一見すると簡単で誰でも出来そうな業務です。しかしその実、科学的な仮説検証能力がアウトプットの品質にダイレクトに効いてくると考えています。例えばcherry-pick（自分にとって都合の良いサンプルだけ集めて判断する）などを行ってしまえば、良いチューニングにはなりません。

加えて、AIの原理原則に対する理解というのも、縦方向に対しての汎用スキルだと考えています。前回のブログ記事でも説明したように、不確実なAIの挙動を前提としたUX設計は、従来のアプリケーション開発のものとは明確に異なります。AIを機能やUXに落とし込む上で、AIの原理原則に対する理解力は大きな強みになりそうです。

横に伸ばす（開発ライフサイクル軸）

「開発ライフサイクルに対するフルスタック性」というのは、当面の間AIエンジニアの大きな強みになると考えています。理由は現在のAI開発において企業ごとのすり合わせ（インテグレーション）が重要となっているためです。AIを企業のコア業務に導入しようとする際、企業ごとに独自のシステム制約やビジネスプロセスが存在するために、既存のAIをモジュールのように組み合わせるだけで完成品を作るのは困難です。このような「インテグラル型」の製品では、モジュール同士の総和として最終製品の品質が決まるのではなく、乗算として品質が決まります。

したがって、システムや開発ライフサイクルを横断して全体の擦り合わせができる人材というのは、大きな付加価値を提供することが出来るはずです。近年FDEが流行っているのもこの辺りの背景があるんだろうなと思っています。

5. 終わりに

ここまで読んで下さりありがとうございます。何か皆さんのキャリアや採用要件について考えのきっかけになるところがあれば幸いです。

余談ですが、ChatGPTが出た当時、同僚と「AIによって真っ先に仕事を奪われるのはAIエンジニアである」と自虐めいた雑談を良くしていました。実際、スマイルカーブの進行による環境変化は過激です。しかしキャリアは横にも縦にも伸ばしていくことが出来そうなので、現在はそこまで深刻に捉えていません。

最後に、2026年2月現在、ACESでは音声領域のAIエンジニアを切実に募集しています。 プロダクト開発のライフサイクル全体を横断しながら、AIモデルのCustomizeとUseまで、縦にも横にもキャリアを磨くことができるポジションです（弊社が取り組んでいるAI特有のUX設計や、AI開発のライフサイクルについては、リンク先の過去ブログ記事にも紹介があります）。興味を持たれた方は公式HPから応募、または私のXのDMにてご相談をお待ちしておりますー！