フルスタック開発者がAIエンジニアに転換するための4段階ロードマップ — 「何を学ぶか」より「何が作れるか」で進捗を測る

5月、Telerikが「AI Engineering Skills Roadmap」と題した記事を公開した。フルスタック開発者がAIエンジニアリングのスキルを体系的に習得するための4フェーズのロードマップを詳述している。

「AIに仕事を奪われる」という議論が続く一方、現場エンジニアにとって差し迫った問いは「何を、どの順番で学べばいいか」だ。本記事はその問いに対し、既存のフルスタック開発スキルを起点に、4段階で段階的にAIエンジニアリングを習得する道筋を示している。

重要な前提として、この記事はロードマップの概略を示すものであり、「どう学ぶか」ではなく「何を、どの順番で学ぶか」を示す構成となっている。

4段階のロードマップ全体像

ステージ	主要コンピテンシー	完了後に作れるもの
1. モデルを使う	モデルAPI、プロンプティング、構造化出力、ストリーミング	要約・分類フィーチャー
2. 自分のデータでグラウンディング	Embeddings、ベクトルストア、RAG	ソース引用付きドキュメントアシスタント
3. アクションとエージェント	ツール定義、エージェントループ、MCP	承認ステップ付きの書き込みアクション
4. 本番運用	評価、オブザーバビリティ、コスト、ガバナンス	根拠を示してリリースできるAIフィーチャー

ステージの順番は「依存関係」の順だと説明されている。RAGはモデル呼び出しの上に成り立ち、エージェントはその両方の上に、本番運用はすべてを包む形になる。

最初に学ぶのは、自前のバックエンドからホスト型モデルを呼び出し、返ってきたレスポンスを整形することだ。具体的にはプロバイダーAPI、プロンプト設計、構造化出力、ストリーミングが対象となる。

理論的な基礎として押さえておくべき点が1つある。LLMはそれまでのすべてのトークンから次のトークンを予測することでテキストを生成する。これだけ理解しておくと、「なぜ同じ入力でも出力が変わるのか」「なぜ誤った答えを自信満々に返すのか」が腑に落ちる。

参照リソース：

作るもの： サポートチケットのスレッドを受け取り、要約と優先度を返すバックエンドエンドポイント。シンプルに見えるが、リクエストフロー・プロンプト設計・コスト計算を一通り経験できる。

モデルの知識はトレーニング時点で固定されている。そこで登場するのがRAG（Retrieval-Augmented Generation）だ。テキストをベクトルとして表現するEmbeddings、それを格納・検索するベクトルストア、ドキュメントを分割するチャンキング戦略をセットで学ぶ。

ベクトルストアの選択肢として、既存のPostgresに追加できるpgvectorと、マネージドサービスのPineconeが挙げられている。

作るもの： 自社コンテンツのみを参照し、引用元を提示するドキュメントアシスタント。「情報がないときは正直にそう答える」動作が実現できれば完了の目安だ。

モデルが「答える」から「動く」へ移行するフェーズ。ツール定義（名前・型付きパラメータ・説明文）を書き、モデルからのツール呼び出し要求→バリデーション→実行→結果フィードバックのループを実装する。

ここで重要なのがMCP（Model Context Protocol）だ。エージェントがツールを発見・呼び出すための標準プロトコルであり、公式ドキュメントにTypeScript・Python向けのチュートリアルが用意されている。

エージェントには制限設計が必要だ。「広く読み、狭く書く」スコープ設計と、取り消しが難しい操作の前に人間の承認を挟む設計が求められる。

作るもの： タスクを次のスプリントに移動する書き込みアクションを1つだけ持ち、承認ステップを経由するアシスタント。「何を実行したか」のログを説明できれば完了だ。

デモは1週間で作れる。問題はその先だ。このステージの核心は評価（Evaluation）への発想転換にある。モデルの出力はランごとに変わるため、「テスト」ではなく20〜30件の採点済みサンプルを用意してスコアリングする仕組みを作る。

加えてオブザーバビリティ（リトリーバルからツール呼び出し、最終回答までのトレース）、コストモニタリング、セキュリティとガバナンスが対象となる。

作るもの： 新しいフィーチャーではなく、これまでのアシスタントにEvalスイートとトレースを追加すること。プロンプトを変更したときにスコアがどう動くかを観察できる状態が目標だ。

4つのコンピテンシーはどのステージでも関係してくる。

① AI-Native UXの判断力 ── 信頼度インジケーターをいつ表示するか、チャットUIが適切でない場面はどこか、という設計判断。モデル呼び出しが技術的に機能しても、UX設計が悪ければ悪いフィーチャーとして出荷される。

② セキュリティ感覚 ── モデルが読むすべての入力は潜在的な命令であり、プロンプトインジェクションという新しい攻撃クラスが存在する。何をモデルに渡してよいか、モデルの出力が何をトリガーできるかはフィーチャーごとの設計判断であり、ステージ4ではなくステージ1から考えるべき問題だ。

③ 非決定性を前提とした設計 ── 同じリクエストでも異なる出力が返ることは「バグ」ではなく「設計上の制約」である。出力フォーマットの制約と検証、使えない出力が返ってきたときのフォールバックが必要になる。

④ コーディングエージェントを日常的に使う ── Cursor、Claude Code、GitHub Copilotなどのツールを日常的に使うこと自体が、モデルがコンテキストと命令をどう扱うかを学ぶ実地訓練になる。

このロードマップの特徴は、各ステージの終わりに具体的に作るものが定義されている点だ。「何を学んだか」ではなく「何が作れるようになったか」で進捗を測る設計になっている。特別なインフラも研究背景も不要で、すべてサイドプロジェクト規模に収まるとされている。

詳細はAI Engineering Skills Roadmapを参照していただきたい。