学習ロードマップ / 開発経験を次の実践へ

AI基盤
学ぶ順番と、作るもの。

共通課題を複数チームが使う前提へ広げ、推論の入口、観測と評価、障害と段階的配信を扱います。特定のクラウド製品に依存しません。

説明できる成果物をつくる

このルートで仕上げる成果物

推論ゲートウェイの実装、評価・観測結果、障害対応と配信の運用レポートを提出できる。

まず取り組むこと

模擬FAQのモデル呼び出しがある場所を一つ探し、共通APIへ移す境界をメモに書く。

最初のステップへ

活かせる経験サービスの信頼性を支えるSRE(Site Reliability Engineering)、クラウド、分散システム、共通基盤、データ基盤の経験を生かしやすいルートです。運用した範囲と、設計だけに関わった範囲を分けて記録します。

当サイトが提案する学習順序です。各段階の「次へ進む目安」をAI機能の成果物で確認できれば、その段階は復習として使えます。

学習成果と実務経験は分けて記録します。採用要件は応募先の求人で確認してください。

基礎

共通の基礎を、小さく作る

01

共通の演習

APIで回答を返す最小機能を作る

文章を生成する大規模言語モデル(LLM)を、得意な言語から呼び出します。既存のWeb開発経験を、モデル呼び出しの失敗や入力の扱いまで含むAI機能へつなげます。

学ぶこと

  • 既存のTypeScript、Pythonなど得意な言語で始めるAPI連携
  • APIキーをブラウザーへ出さない呼び出し構成と利用量上限
  • 入出力の形式、出力確認、失敗時の表示
作るもの

得意な言語で、公開資料または自作の架空データを質問対象にした「社内FAQの模擬アプリ」を作る。質問、出力確認、失敗時の案内を画面で確認できるようにする。実在の顧客情報や社内文書は投入しない。

次へ進む目安

  • APIキーをサーバー側で扱い、利用量上限を設定し、画面には出していない。
  • 回答内容を確認でき、回答不能・通信失敗時に利用者へ次の行動を案内できる。
学習資料と、経験がある場合の確認

すでにできる場合LLM呼び出しで、出力の揺れと回答不能を扱い、秘密情報をクライアントへ出さず、利用量制限まで実装した成果を説明できるなら、その成果を確認して次へ進む。

公式資料で学ぶ

02

共通の演習

公開資料を検索して根拠を返す

回答をモデルの記憶だけに任せず、どの資料を使ったかを利用者と開発者が確かめられるようにするためです。RAGは、検索で得た資料を回答生成時の文脈として渡す構成を指します。全職種で必須の構成ではなく、検索が不要な案件では固定資料や外部APIの情報補足に置き換えられます。

学ぶこと

  • 資料の分割とメタデータ
  • 検索結果を根拠として表示する方法
  • 検索できない質問を扱う設計
作るもの

模擬FAQへ公開資料の検索を追加し、回答ごとに参照した資料名とURLを表示する。検索対象、更新方法、投入しないデータをREADMEに記録する。

次へ進む目安

  • 少なくとも3つの公開資料に対し、根拠付きで回答できる。
  • 根拠がない質問では、推測の回答を避ける表示になっている。
学習資料と、経験がある場合の確認

すでにできる場合既存の検索や業務データ連携を再利用しつつ、LLMの根拠不足時に回答を控える扱いまで演習で確認できるなら、その成果を確認して次へ進む。

公式資料で学ぶ

03

共通の演習

評価と本番の安全性を設計する

動くデモを、変更後も品質を確かめられる機能へ進めるためです。評価は、期待する振る舞いをデータと判定基準で繰り返し確かめる作業です。

学ぶこと

  • 代表質問と危険な質問を含む評価データ
  • 品質・速度・コストの観測項目
  • 入力、権限、ログの安全な扱い
作るもの

模擬FAQに10件程度の評価質問を用意し、検索・プロンプト・モデル設定を変えた前後で結果を比較する。ログに質問本文や秘密情報を残さない方針も文書化する。

次へ進む目安

  • 変更前後を同じ質問セットで比較できる。
  • 失敗、遅延、回答不能を確認する項目と対応方針がある。
学習資料と、経験がある場合の確認

すでにできる場合既存のテストや監視を再利用しつつ、LLM出力を評価データで比較し、モデル設定変更の判断を演習で確認できるなら、その成果を確認して次へ進む。

公式資料で学ぶ

04

共通の演習

手順を決めずに動く仕組みを、範囲を絞って作る

AIエージェントは、次に何をするかをモデル自身が選び、複数の手順をまたいで目的に近づく構成です。求人の必須要件に挙がり始めた領域ですが、決まった手順で足りる処理までエージェントにすると、遅く、高く、追跡しにくくなります。エージェントにすべき場面と、そうでない場面を区別できることが先です。

学ぶこと

  • 決まった手順(ワークフロー)とエージェントの使い分け
  • 複数手順にまたがるツール実行と中断の設計
  • エージェントの動作を後から追える記録の残し方
作るもの

模擬FAQへ「質問に答えられないとき、公開資料を追加で検索してから再回答する」という2手順までの動きを追加する。手順の上限を決めて超えたら止め、どのツールをどの順で呼んだかを記録する。外部への書き込みは行わない。

次へ進む目安

  • 手順の上限に達したとき、勝手に続けず利用者へ状況を返す。
  • どのツールをどの引数で呼んだかを、後から1件ずつ追える。
  • この機能をエージェントにした理由と、決まった手順で済ませた部分を説明できる。
学習資料と、経験がある場合の確認

すでにできる場合LLMに複数手順の判断をさせる機能を本番で運用し、停止条件と追跡の仕組みまで設計した成果があれば確認して次へ進む。

公式資料で学ぶ

実践

AI基盤の実践へ

05

職種別の演習

推論ゲートウェイを作る

各アプリが個別にモデル設定や秘密情報を持たず、変更と制御を集約するためです。推論ゲートウェイは、モデル呼び出しの入口を共通化するサービスを指します。

学ぶこと

  • 認証と利用者ごとの制限
  • モデル設定の切り替え
  • リクエスト識別子と監査ログ
作るもの

模擬FAQのモデル呼び出しを共通APIへ寄せ、呼び出し元、モデル設定、失敗理由を記録する。秘密情報や質問本文をそのままログに残さない。

次へ進む目安

  • アプリ側は共通APIだけを呼び出している。
  • 呼び出しを識別し、失敗を追跡できる。
学習資料と、経験がある場合の確認

すでにできる場合複数サービス向けの共通APIで、認証・制限・監査を運用した成果があれば確認して次へ進む。

公式資料で学ぶ

06

職種別の演習

観測と評価を結び付ける

遅延や失敗の数字だけでなく、回答品質の変化も同じ変更単位で確認するためです。

学ぶこと

  • トレース、メトリクス、ログの役割
  • 評価結果とリリースの紐付け
  • 品質・速度・コストの比較
作るもの

模擬FAQの呼び出し記録と評価結果を同じリリース識別子で集計し、変更前後の違いを1枚で確認できるようにする。

次へ進む目安

  • 障害と品質低下を別々に検出できる。
  • 評価結果から変更した設定までたどれる。
学習資料と、経験がある場合の確認

すでにできる場合本番の観測データと品質評価を結び付け、変更判断に使った成果があれば確認して次へ進む。

公式資料で学ぶ

07

職種別の演習

障害対応と段階的配信を設計する

モデルやプロンプトの変更を一度に広げず、問題があれば影響を抑えて戻せるようにするためです。

学ぶこと

  • タイムアウト、再試行、負荷制御
  • 段階的配信と停止条件
  • 障害対応の連絡と振り返り
作るもの

模擬FAQにモデル設定を段階的に切り替える設定を作り、品質低下・遅延・エラー率の停止条件と切り戻し手順を演習する。

次へ進む目安

  • 停止条件を満たすと前の設定へ戻せる。
  • 障害時の利用者向け表示と運用者向け手順がある。
学習資料と、経験がある場合の確認

すでにできる場合段階的配信、切り戻し、障害対応を本番で担った成果があれば確認して次へ進む。

公式資料で学ぶ

必要になったとき学ぶ

応募先に合わせて学ぶこと

  • 利用チームごとの制限と費用配分を追加する。
  • 評価を継続的な変更確認へ組み込む。
  • 応募先の業務で求められる場合に、機械学習、統計、線形代数、モデル学習を深める。
動画教材で補いたい方へ

学び続ける

公式の更新情報を追う方法

週に一度など、続けられる間隔で公式の更新を読みます。使っている機能の変更を一つ選び、同じ評価用データで変更前後を比べ、結果をメモに残します。

教材確認日 2026-09-10。APIの実行には利用料金がかかる場合があります。

次の一歩へ

成果物を応募の準備にまとめる

コード、設計の理由、評価結果、残った課題をまとめ、求人で求められる経験と照らし合わせます。