「AIエンジニアになりたい」という相談は、2026年のいま、5年前とは違う答えが必要です。AIがコードを書く時代に、AIを扱う仕事はむしろ細分化し、どの職種を目指すかで学ぶべきものが大きく変わるようになりました。
この記事では、職種の分解 → 共通基礎 → ルート別の順序 → ポートフォリオ → 資格の位置づけ、の順で、遠回りしないための地図を描きます。筆者の経験則を多分に含む記事なので、「一つの整理」として使ってください。
まず「AIエンジニア」を3つに分解する
求人票で「AIエンジニア」と呼ばれる仕事は、実際には3つの職種に分かれます。
| 職種 | 主な仕事 | 前提スキルの重心 |
|---|---|---|
| MLエンジニア | データからモデルを作る(予測・検知・画像) | 統計・ML理論・データ処理 |
| LLMアプリエンジニア | LLM APIで機能を作る(RAG・エージェント・業務支援) | ソフトウェア開発・API設計・評価設計 |
| MLOpsエンジニア | モデルを本番で動かし続ける基盤を作る | インフラ・CI/CD・監視 |
重要な変化は、LLMアプリエンジニアという「モデルを作らないAI職」が主流になったことです。ここはWeb開発のスキルがそのまま活き、数学の壁も低い——未経験からの現実的な入口は、いまやこのルートです。
共通基礎 — どこまでやれば十分か
3職種に共通する基礎は3つだけです。完璧主義で止まらないよう、「どこまで」を明記します。
- Python: 文法+標準ライブラリ+仮想環境・パッケージ管理まで。クラス設計に凝るより、データを読み書きして小さいツールを完成させる経験を優先
- 数学: 線形代数(行列の積・次元の感覚)、微分(勾配が「傾き」だと分かる)、確率統計(分布・平均と分散・条件付き確率)。論文の数式を「読める」レベルでよく、証明できる必要はない。不足を感じた箇所だけ都度戻る方が続きます
- SQLとデータの扱い: 実務の8割はデータの準備です。SELECT・JOIN・GROUP BYと、pandasでの前処理は全ルート必修
ルートA: LLMアプリエンジニア(最短・Web開発者向き)
いまから3〜6ヶ月で実務レベルを狙うなら、このルートです。
- LLM APIで小さいアプリを作る(チャット、要約、抽出)。プロンプトより先に「アプリとして完成させる」経験
- RAGを作る — 検索・チャンク・評価という定番の沼を一周する。RAGの精度が出ないときに見る場所が地図になります
- 構造化出力と検証層 — LLMの出力をシステムに組み込む作法(構造化出力パターン)
- 評価を作る — ゴールデンセットとLLM-as-a-Judge。「評価を設計できる人」は現場で希少です
- エージェントの基礎 — ツール実行ループを自作して原理を掴み、設計パターンで引き出しを増やす
このルートの差別化ポイントは、モデルの知識ではなく評価・安全設計・運用です。当サイトのLLMカテゴリは、ほぼこのルートの教材として書いています。
ルートB: MLエンジニア(王道・積み上げ型)
- scikit-learnで古典MLを一周(回帰・分類・交差検証)。同時に評価設計を身につける——初心者とプロの差が最初につくのはモデルではなく評価です
- 深層学習の中身を1回だけ手で作る。定番は『ゼロから作るDeep Learning』[1]。逆伝播を一度実装した人は、その後のフレームワーク学習の速度が違います
- fast.ai[2]やPyTorchで実践に切り替える。トップダウン(動かしてから理論)とボトムアップ(1の書籍)の両輪が最速です
- Kaggle[3]で他人のコードから盗む。メダルより「上位解法を読んで再現する」ことに学習価値があります
- 応用領域をひとつ選ぶ(画像・時系列・異常検知…)。当サイトの異常検知や時系列予測のような「実務の型」を領域ごとに貯める
ルートC: MLOps(ソフトウェアエンジニアの転身先)
インフラ・バックエンド経験者なら、MLの深い理論より先に「MLシステムの運用の型」を学ぶ方が速い。学習順は、コンテナとCI/CD → テスト戦略とオブザーバビリティ → 実験管理・モデルレジストリ・ドリフト監視というML固有の部品、の順です。AIの実務が「モデル作り」から「運用し続ける仕組み」に重心を移すほど、この職種の需要は増えています。
ポートフォリオ — 「動くもの+言語化」で1セット
どのルートでも、転職市場で効くポートフォリオの型は同じです。
- 動くものを1つ: デプロイされたアプリ、再現可能なノートブック、OSSへのPR。チュートリアルの写経ではなく、自分の課題設定があること
- 言語化を1つ: 技術記事・READMEで「何を・なぜ・どう作り、何がうまくいかなかったか」を書く。採用側が見たいのは完成度より判断の過程です
- 業界経験がある人は「前職ドメイン×AI」が最強の差別化です。医療・製造・金融のような業界×テックの知識は、AIスキルより獲得に時間がかかるぶん、希少性が持続します
資格の現実的な位置づけ
日本のAI関連資格(E資格[4]・G検定・統計検定など)については、期待値を正直に書きます。
- 資格そのものが採用の決め手になることは少ない。実績(動くもの)>実務経験>資格の順は変わりません
- 一方で、シラバスは体系学習のペースメーカーとして優秀です。独学の「何を知らないかが分からない」状態を潰すのに使えます
- 費用対効果を考えるなら、資格は「学習の副産物として取る」姿勢が健全です
AIがコードを書く時代に、何が残るのか
最後に、この時代特有の問いに触れます。「コード生成AIがあるのに、いま学ぶ意味はあるのか」。
あります。ただし価値の重心は移動しました。コードを書く速度の価値は下がり、問題を定義する力・出力を検証する力・システムとして運用する力の価値が上がっています。ループエンジニアリングで書いたとおり、AIに仕事を任せる時代の人間の仕事は「検証とループの設計」です。本ロードマップで評価・テスト・運用を繰り返し強調したのは、それが理由です。
まとめ
- 「AIエンジニア」はML・LLMアプリ・MLOpsの3職種に分解して目指す。未経験の現実的な入口はLLMアプリエンジニア
- 共通基礎は Python・読める数学・SQL。完璧主義より完成の経験
- ルートA(LLM)は RAG→構造化出力→評価→エージェント の順。差別化は評価と安全設計
- ルートB(ML)は 古典ML+評価設計→中身を1回自作→実践→Kaggle→応用領域
- ポートフォリオは「動くもの+言語化」。前職ドメイン×AIが最強の差別化
- 資格は決め手ではなくペースメーカー。学習の副産物として取る
学習地図は描けても、歩く順番は人によって違います。迷ったら「3ヶ月で動くものを1つ完成させる」を北極星にしてください——完成の経験だけが、次の地図を読めるようにしてくれます。
参考文献・一次情報
- [1]
- [2]
- [3]
- [4]