0-01 AIエンジニアという仕事

このページはプロモーション（広告）を含みます。

AIエンジニアが何を作り、何に責任を持つ仕事なのかを知り、この課程の全体地図と自分の進むルートを決めます。

この章でできるようになること

• AIエンジニアとMLエンジニア・データサイエンティスト・研究者の違いを説明できる
• LLMアプリ開発の仕事の流れ（課題発見から運用改善まで）を具体例で説明できる
• 求人で求められるスキルと、AIがコードを書く時代に価値が上がるスキルを挙げられる
• 課程の全体像を把握し、自分の目的に合うルート（app / auto / ml）を選べる
• アプリ内でPythonのコードを実行し、print で結果を表示できる

この章は、課程全体の入り口です。「AIエンジニア」という言葉は広く使われていますが、指している仕事は人によってかなり違います。ここでは、この課程が目指す仕事を具体的に定義し、その仕事が実際にどう進むのか、求人で何を求められるのか、そしてAIがコードを書くようになった今、人間のエンジニアに何が求められるのかを整理します。

読み終えるころには、これから先の76章が何のために並んでいるのかが見えるはずです。長い課程を途中で投げ出す一番の原因は「今やっていることが、最終的に何につながるのか分からない」ことです。だから最初に地図を渡します。

章の後半では、アプリの中で最初のPythonコードを実行します。まだ文法を学ぶ必要はありません。ボタンを押してコードが動き、結果が表示される。その感覚に慣れることが目的です。

AIエンジニアとは何をする人か

ある一日の例

まず具体例から始めます。ある会社の総務部には、毎日のように同じ質問が届きます。「有給休暇は入社何か月後から使えますか」「出張の日当はいくらですか」「在宅勤務の申請はどこからですか」。答えはすべて社内規程に書いてあります。しかし規程は200ページのPDFで、社員は探すのを諦めて総務に電話をかけます。

ここでAIエンジニアが呼ばれます。作るのは「社内規程に基づいて質問に答えるチャットボット」です。ただし、やることはチャット画面を作るだけではありません。

• 規程のPDFを読み込み、検索できる形に分割して保存する
• 質問が来たら関係する条文を探し出し、LLM（大規模言語モデル、Large Language Model）に「この条文だけを根拠に答えて」と頼む
• 回答に根拠の条文番号を付け、規程に書いていないことは「分かりません」と言わせる
• 実際によくある質問を50件集め、正しく答えられるかを測る
• 間違えた質問を分析し、検索方法やプロンプト（LLMへの指示文）を改善する
• 本番で使われ始めたら、ログを見て、費用と応答時間と回答の質を監視する

この一連の仕事のどこにも「AIモデルそのものを訓練する」作業は出てきません。モデルはGoogleやAnthropic、OpenAIなどが作ったものを、API（Application Programming Interface、プログラムから機能を呼び出す窓口）経由で使います。AIエンジニアの仕事は、既にある強力なモデルを、特定の業務で信頼して使える製品に仕立てることです。

定義

この課程では、AIエンジニアを次のように定義します。

学習済みの基盤モデル（LLMなど）をAPIで使い、データ・ツール・業務の流れと組み合わせて、評価し、製品として運用できる形にするソフトウェアエンジニア。

基盤モデル（foundation model）とは、膨大なデータで事前に訓練され、さまざまな用途に転用できる大きなモデルのことです。この定義の要点は3つあります。1つ目は、モデルを作るのではなく使う側だということ。2つ目は、モデル単体ではなく、検索・データベース・外部ツールなどと組み合わせたシステムを作るということ。3つ目は「評価し、運用する」まで責任を持つということです。3つ目が抜けると、デモでは動くが現場では使えないものができあがります。

roadmap.sh というエンジニア向けの学習ロードマップでも、AIエンジニアは「学習済みモデルと既存のAIツールを使って体験を改善する人」で、新しいモデルを一から作る研究者やMLエンジニアとは区別されています。2023年に「AI Engineer」という呼び名を広めた swyx の記事でも、Karpathy（OpenAIの創設メンバーの一人で、テスラのAI部門を率いた研究者）の「何も訓練せずにこの役割で大きく成功できる」という言葉が引用されています。

似た職種との違い

AIに関わる職種は他にもあります。違いを表にまとめます。

境界ははっきりしていません。AIエンジニアでもモデルの微調整（ファインチューニング）を判断する場面はありますし、MLエンジニアがLLMアプリを作ることもあります。ただ、入口として「どこに主な責任があるか」を押さえておくと、学ぶべきことの優先順位が決まります。

仕事はどう進むのか

6つの段階

LLMアプリの開発は、おおむね次の流れで進みます。

1. 課題の発見
2. 要件の整理
3. プロトタイプ
4. 評価
5. 本番化
6. 運用と改善

それぞれの段階で、何をするのかを見ていきます。

1. 課題の発見：業務のどこに時間がかかっているか、どこでミスが起きているかを見つけます。ここで重要なのは「そもそもLLMが必要か」を疑うことです。決まった形式の書類から数字を取り出すだけなら、普通のプログラムで十分なこともあります。
2. 要件の整理：誰が、何を入力し、何が出てくれば成功なのかを決めます。「回答の9割が規程どおりであること」「1件あたりの費用は1円以下」「個人情報は外部に送らない」のように、測れる形で書きます。
3. プロトタイプ：最小限の仕組みを数日で作り、実際の質問で試します。今はここがAIのおかげで劇的に速くなりました。
4. 評価：用意した質問セットで正答率を測り、失敗の種類を分類します。プロトタイプが「なんとなく良さそう」から「何割正しい」に変わる段階です。
5. 本番化：エラー処理、再試行、ログ、セキュリティ、費用の上限などを整えて、実際の利用者に使ってもらいます。
6. 運用と改善：ログを読み、新しい失敗を見つけ、評価セットに加え、改善し、改善したことを再び評価で確かめます。

この流れは一方通行ではありません。評価してみて要件が曖昧だったと気づき、要件に戻ることはよくあります。むしろ、何度も行き来するのが普通です。

4つの具体例

同じ流れを、日本の職場でよくある題材に当てはめてみます。

RAG（Retrieval-Augmented Generation、検索拡張生成）とは、関連する文書を検索してからLLMに渡して答えさせる仕組みのことです。エージェント（agent）とは、LLMが自分で「次にどのツールを使うか」を判断しながら、複数の手順を進める仕組みです。どちらもこの課程の中心的なテーマで、Part 6とPart 7で詳しく扱います。

表の右端の列に注目してください。どの題材でも、「何を測れば良し悪しが分かるか」が具体的に決まっています。これがないと、改善したつもりが実は悪化していた、ということが起きます。

本番で起きること

プロトタイプと本番の差は、想像より大きいものです。プロトタイプでは、作った本人が想定した質問しか来ません。本番では、想定外の質問、誤字だらけの質問、規程に書いていない質問、悪意のある入力が来ます。APIが一時的に混雑して失敗することもあります。1日1万件の質問が来れば、1件1円の費用も月30万円になります。

だからAIエンジニアには、LLMの知識だけでなく、普通のソフトウェアエンジニアとしての基礎体力が必要です。エラー処理、テスト、ログ、データベース、セキュリティ、費用の見積もり。これらはPart 2とPart 8で扱います。

求人では何が求められているか

海外の求人の集計

実際の求人を見ると、求められるスキルがはっきりします。2026年に公開された求人分析を3つ紹介します。どれも集計方法が異なり、査読された研究ではないので「傾向を示すもの」として読んでください。

オブザーバビリティ（observability、可観測性）とは、システムの中で何が起きているかを、ログやトレース（処理の記録）から外部で把握できるようにすることです。LLMアプリでは「どんな質問に、どの文書を使って、どう答え、いくらかかったか」を後から追えるようにすることを指します。

3つの調査に共通する点をまとめると、次のようになります。

• Python は事実上の必須言語。次点はTypeScript。
• LLMのAPIを使いこなすことは、もはや特別な技能ではなく「前提」。aijobprep の分析は「LLMの仕事はもはや専門ではなく、最低条件だ」と書いています。
• バックエンド（サーバー側のプログラム、API、データベース）の力が求められる。
• エージェント、評価、オブザーバビリティが、ここ1〜2年で急に増えた。
• 特に評価は、198社の調査でRAG（40%）よりも多い68%の企業が挙げている。

日本の求人の傾向

日本の求人も見ておきます。研究ノートで確認できた求人は数件と少ないため、ここも傾向として読んでください。

• 「RAG」「エージェント」「大量文書の理解」を掲げる求人が目立つ。
• 「PoCから本番化まで」を6〜12か月で回す、という書き方が多い。
• 製造業など、業界の知識（ドメイン知識）が歓迎条件に入っている。
• 必須条件には、Webアプリやサーバー側の開発経験3年以上、のように、ソフトウェア開発の基礎が並ぶことが多い。
• 一方で「LLMを使った開発経験（業務での実装、または個人開発レベルでも可）」と、個人開発を明示的に認める求人もある。

年収は経験者で600万〜1,500万円程度の幅がありました（2026年10月時点、求人サイト掲載の数件より）。

正直に言っておくこと

ここは率直に書きます。未経験の人をいきなり「AIエンジニア」として採用する求人は、多くありません。ほとんどの求人は、ソフトウェア開発の経験があることを前提に、その上にLLMの技能を求めています。

それでも道はあります。1つは、自分で作って動かしたものを見せることです。Axial Searchの分析が指摘するとおり、「実際に動かしたシステムのポートフォリオ」は資格よりも重く見られます。この課程では、8つの総合プロジェクト（P1〜P8）を通じて、評価付き・デプロイ（公開）済み・設計判断を説明したREADME付きの作品を作ります。もう1つは、今の職場で実績を作ることです。営業、経理、カスタマーサポートなど、自分の業務を深く知っている人がAIで業務を改善した実績は、エンジニア経験の短さを補う強い材料になります。日本の求人がドメイン知識を歓迎しているのは、このためです。

AIがコードを書く時代に、何が価値を持つか

現場で起きていること

2025年以降、コードを書く作業の多くをAIが担うようになりました。Claude Code や Codex のような「コーディングエージェント」は、指示を受けるとファイルを読み、計画を立て、コードを書き、テストを実行し、失敗したら直す、という作業を自分で進めます。

では、エンジニアの仕事はなくなるのでしょうか。現場のデータは、別の姿を示しています。

Stack Overflow の2025年開発者調査では、84%がAIツールを使っているか使う予定と答えました。一方で、AIの出力を「強く信頼している」人は3.1%しかいません。最も多かった不満は「ほぼ正しいが、完全ではない」出力で、66%がこれを挙げました。45.2%は「AIが書いたコードのデバッグのほうが時間がかかる」と答えています。

つまり、AIは大量のコードを素早く出してくれますが、そのコードは「だいたい合っているが、どこかが違う」ことが多い。その「どこか」を見つけて直すのは人間の仕事です。

Anthropic が行った実験（無作為化比較試験）では、AIの支援を受けながらプログラミングを学んだグループは、理解度テストの平均が50%で、AIなしのグループの67%を下回りました。差が最も大きかったのはデバッグの問題です。ただし、AIに概念の説明を求めながら学んだ人は、理解をよく保っていました。AIをどう使うかで、身につくものが大きく変わるということです。この使い方は次の章で詳しく扱います（→ 0-02 挫折しない学び方とAIの使い方）。

価値が上がる7つのスキル

研究ノートで集めた専門家の見解（Karpathy、Simon Willison、Anthropic、Thoughtworks など）と調査結果をまとめると、AIがコードを書く時代に価値が上がるのは次のスキルです。

1. 仕様化：何を作るかを、曖昧さなく書く力。AIは曖昧な部分を勝手に埋めます。入力・出力・制約・例・受入条件を書けると、AIの出力が見違えるように良くなります（→ 3-03 仕様を書く技術）。
2. コンテキスト設計：AIに何を見せるかを選ぶ力。必要な情報が足りなければ推測で書き、多すぎれば重要な点を見落とします（→ 3-04 コンテキストを渡す技術）。
3. 検証とレビュー：出てきたコードを読み、仕様どおりか、境界の値やエラーのときにどうなるかを確かめる力（→ 3-05 AIが書いたコードをレビューする）。
4. 評価：LLMアプリの出力の良し悪しを、数字で測る仕組みを作る力（→ 6-10 LLMアプリの評価）。
5. デバッグ：壊れたときに原因を突き止める力。前述の実験で最も差が出たスキルです（→ 3-06 AIと一緒にデバッグする）。
6. 設計：システムをどう分けるか、何をLLMに任せ何を普通のコードで書くかを決める力（→ 2-09 設計の基本）。
7. ドメイン理解：業務そのものを知っていること。何が「正しい答え」かを判断できるのは、業務を知っている人だけです。

Karpathy は、AIと人間の協働を「生成と検証のループ」と表現しました。AIが生成し、人間が検証する。このループを速く回すには、AIの変更を小さく保ち、検証を簡単にする工夫が必要です。Simon Willison は「他人に説明できないコードはコミットしない」という原則を掲げています。コミット（commit）とは、変更を正式な履歴として記録することです。AIが書いたコードでも、責任を持つのは人間です。

だからこの課程はこう教える

この課程の Python の章では、「ゼロから全部書ける」ことより「読める・直せる・説明できる・指示できる・検証できる」ことを優先します。ただし、読めるようになるには手で書く経験が欠かせません。だから演習は手で書きます。AIに頼るのは、自分で考えた後です。

もう1つの方針は、評価を最後の章だけで扱わないことです。課程のあちこちで「これをどう確かめるか」を問います。評価の考え方が身についていることは、求人の数字が示すとおり、他の候補者との最大の差になります。

課程の全体地図

Part 0〜9 で何ができるようになるか

この課程は10のPartと8つの総合プロジェクトでできています。

総合プロジェクトは、Partの区切りごとに置いています。

1. P1 売上CSVの集計CLI
2. P2 問い合わせ自動分類
3. P3 社内規程Q&A
4. P4 調べものエージェント

1. P5 自分用MCPサーバー
2. P6 本番化とデプロイ
3. P7 ファインチューニング実験（任意）
4. P8 卒業制作

卒業制作（P8）では、自分で選んだ課題について、仕様を書き、Claude Code で実装し、評価し、公開し、READMEで設計判断を説明します。これがそのままポートフォリオになります。

学ぶ順番の理由

なぜこの順番なのかを説明しておきます。LLMアプリを早く作りたい人にとって、Part 1〜4は遠回りに見えるかもしれません。しかし、LLMのAPIから返ってくるのは、Pythonの辞書やリストが入れ子になったデータです。それを読めなければ、AIが書いたコードの誤りに気づけません。テストを知らなければ、AIの変更が何かを壊しても分かりません。統計を知らなければ、「20問中16問正解した」が良い結果なのか偶然なのか判断できません。

どの章も、後の章で必ず使う土台として選んでいます。一方で、目的によって深さは変えてよい。それが次の「ルート」の考え方です。

3つの目的別ルート

ルートの種類

課程の各章には、3つの目的ごとに優先度（必須・推奨・任意・不要）を付けています。

この課程のメインは app ルートです。迷ったら app を選んでください。

ルートごとの進み方

app ルートは、Part 0〜9 をほぼ順番どおりに進みます。Part 4（データと機械学習）は「仕組みを理解して判断できる」深さでよく、評価に直結する 4-04 と 4-06、そして RAG の土台になる 4-08 が必須です。残りは推奨なので、先にPart 5〜7へ進み、必要になったら戻っても構いません。

auto ルートの必須は16章です。Python の基礎（Part 1の前半）、AIコーディングの全体像と仕様の書き方（3-01、3-03）、LLMの得意・不得意（5-05）、プロンプト（6-02）、セキュリティと法令（8-04）が中心です。目標は、自分の業務の手作業をAIとPythonで減らし、AIの出力を鵜呑みにせずに使えるようになることです。推奨の章は、自動化したい業務に関係するものから選んで読みます。

ml ルートは、Part 1を厚めにやり、Part 4（NumPy、pandas、統計、機械学習、ニューラルネットワーク）とPart 5（LLMの仕組み、Transformer）をすべて必須にしています。8-07 のファインチューニングも必須です。一方、Part 6〜7のアプリ開発は推奨で、深さは選べます。

アプリでは、各章の見出しの近くに、選んだルートでの優先度が表示されます。「推奨」の章は、時間があれば読む、くらいの気持ちで大丈夫です。「任意」は興味があれば。「不要」はそのルートでは飛ばしてよい章です。

最初のPythonを動かす

実行してみる

ここからはアプリの中でコードを動かします。下のブロックの実行ボタンを押してください。

アプリで実行できるコード

print("こんにちは。AIエンジニア養成課程へようこそ。")

print(...) は、かっこの中の値を画面に表示する命令です。Pythonでは、このような命令を関数（function）と呼びます。かっこの中の "..." は文字列（string）で、ダブルクォートで囲まれた部分がそのまま表示されます。

このアプリのPythonはブラウザの中で動いています。インターネットに接続せず、自分のパソコンの中だけで計算しています。だから何度実行しても費用はかかりませんし、何かを壊す心配もありません。気軽に書き換えて試してください。

print は何行でも並べられます。上から順に実行されます。

アプリで実行できるコード

print("Part 0 はじめに")
print("Part 1 Python の基礎")
print("Part", 2, "開発の基礎体力")

3行目のように、カンマで区切って複数の値を渡すと、間に空白を入れて1行に表示します。2 にはダブルクォートが付いていません。これは文字列ではなく数（整数）です。

予想してから実行する

次のブロックは「予想ブロック」です。実行する前に、何が表示されるかを自分で予想してから実行してください。予想が外れたところに、理解が足りない部分が隠れています。

実行前に出力を予想する

print(1 + 2)
print("1" + "2")

結果を見て、2行の違いを自分の言葉で説明できるでしょうか。ダブルクォートの有無が、Pythonにとってどんな意味を持つのか。値には「種類」があり、同じ + でも種類によって動作が変わります。この「値の種類」を型（type）と呼び、→ 1-01 値・型・変数 で詳しく学びます。

計算に使ってみる

Python は電卓としても使えます。この課程の学習時間を、ざっくり見積もってみます。

アプリで実行できるコード

chapters = 77
hours_per_chapter = 3.5
project_hours = 150
total = chapters * hours_per_chapter + project_hours
print("合計の目安:", total, "時間")
print("週10時間なら", total / 10, "週")

chapters = 77 は、77 という値に chapters という名前を付ける書き方です。これを変数（variable）と呼びます。名前を付けておくと、後で何度も使えますし、何の数なのかが読み手に伝わります。* は掛け算、/ は割り算です。

1章あたり3.5時間（本文・演習・復習を含む）、プロジェクトに合計150時間という数字は、あくまで仮定です。自分の数字に書き換えて、もう一度実行してみてください。具体的な学習計画は次の章で立てます。

LLMアプリのコードをのぞいてみる

最後に、この課程の後半で書くことになるコードを少しだけ見ておきます。今は1行ずつ理解する必要はありません。「こういう形のものを作っていくのか」という雰囲気をつかんでください。

このアプリには、本物のLLMの代わりに決まったルールで答える「模擬LLM」（llmsim）が入っています。本物のLLM APIと同じ呼び出し方・同じ形の結果を返すので、ここで書いたコードは、少し書き換えるだけで本物のAPIでも動きます。

アプリで実行できるコード

from llmsim import OpenAI, Rules

rules = Rules()
rules.when("有給", "就業規則第12条により、有給休暇は入社6か月後から付与されます。")
rules.when("日当", "出張旅費規程第5条により、日当は1日2,000円です。")
rules.otherwise("規程に該当する記述が見つかりませんでした。総務部にお問い合わせください。")

client = OpenAI(responder=rules)
resp = client.chat.completions.create(
    model="sim-small",
    messages=[{"role": "user", "content": "有給休暇はいつから使えますか"}],
)
print(resp.choices[0].message.content)

rules.when("有給", ...) は「質問に『有給』が含まれていたら、この文を返す」という模擬モデルの設定です。条文番号や金額は、練習用に作った架空のものです。本物のLLMはこのようなルールではなく、学習した知識と渡された文書から文章を生成します。そのため、言い回しは毎回少し変わりますし、規程にないことをもっともらしく答えてしまう（幻覚、hallucination）こともあります。

質問を変えると、返ってくる答えも変わります。

アプリで実行できるコード

for question in ["出張の日当を教えて", "社員食堂は何時まで？"]:
    resp = client.chat.completions.create(
        model="sim-small",
        messages=[{"role": "user", "content": question}],
    )
    print("Q:", question)
    print("A:", resp.choices[0].message.content)

2つ目の質問には規程に答えがないので、「見つかりませんでした」と返しています。社内規程Q&Aでは、分からないことを正直に「分からない」と言えることが、正しく答えることと同じくらい重要です。

評価の考え方を一足先に

AIエンジニアの仕事で最も差がつくのは評価だ、と書きました。その一番小さな形を見ておきます。質問と「答えに含まれているべき言葉」の組を用意し、模擬LLMの回答を自動で採点します。

実行前に出力を予想する

tests = [
    ("有給はいつから？", "6か月"),
    ("日当はいくら？", "2,000円"),
    ("在宅勤務の申請方法は？", "申請"),
]
passed = 0
for question, expected in tests:
    answer = client.chat.completions.create(
        model="sim-small",
        messages=[{"role": "user", "content": question}],
    ).choices[0].message.content
    ok = expected in answer
    passed = passed + (1 if ok else 0)
    print("合格" if ok else "不合格", question)
print("合格数:", passed, "/", len(tests))

3つ目の質問が合格するかどうか、ルールの中身と照らして予想してから実行してください。

結果を見ると、3つ目は不合格になっています。模擬モデルの規程には在宅勤務の情報がないからです。このように、期待する結果を先に書いておき、自動で照らし合わせる。この小さな仕組みが、課程の後半で作る本格的な評価（→ 6-10 LLMアプリの評価）の原型です。不合格の質問は「直すべき点のリスト」になります。規程を追加するのか、「分からない」と答えるのが正しいとして期待値を見直すのか。それを決めるのがエンジニアの判断です。

ここでは規程を追加する、と決めたことにします。ルールを1つ足して、同じテストをもう一度流します。

アプリで実行できるコード

rules.when("在宅勤務", "在宅勤務規程第3条により、前日までに勤怠システムから申請してください。")
passed = 0
for question, expected in tests:
    answer = client.chat.completions.create(
        model="sim-small",
        messages=[{"role": "user", "content": question}],
    ).choices[0].message.content
    if expected in answer:
        passed = passed + 1
print("改善後の合格数:", passed, "/", len(tests))

改善したら、同じテストで測り直す。これが「改善したつもりで実は悪化していた」を防ぐ基本の動作です。本物のLLMアプリでは、1か所を直したら別の質問の答えが悪くなることがよくあります。だから一部だけでなく、テスト全体を毎回流します。

私は{職種・業務内容}をしています。最近、LLM（大規模言語モデル）を業務に使う方法を学び始めました。
次の手順で手伝ってください。
1. 私の業務について、時間がかかっている作業や、ミスが起きやすい作業を知るための質問を5つしてください。回答を待ってから次に進んでください。
2. 私の回答をもとに、LLMで改善できそうな作業を3つ挙げ、それぞれ「LLMが必要な理由」と「普通のプログラムやルールで足りる可能性」の両方を書いてください。
3. 一番効果がありそうなものについて、「成功したと判断する基準」を数字で提案してください。
推測で断定せず、分からないことは質問してください。

演習

AIエンジニア養成課程
Part 0 はじめに
最初の一歩

print("AIエンジニア養成課程")
print("Part 0 はじめに")
print("最初の一歩")

total_hours = 300
hours_per_week = 12
weeks = total_hours / hours_per_week
print("完了までの週数:", weeks)

1. 課題の発見：部長が毎朝1時間かけている「重要案件・問題の拾い出し」を短縮したい。部長にヒアリングし、何を「重要」と判断しているか（大口案件、失注の兆候、クレーム、競合の動き）を具体化する。そもそもLLMが必要か（キーワード検索で足りないか）も検討する。
2. 要件の整理：入力は前日の日報20件。出力は「重要案件」「問題・リスク」の箇条書きと、元の日報への参照。成功基準の例：部長が重要とした項目の9割以上を拾える、拾った項目の誤り（存在しない話）はゼロ、処理は朝8時までに完了、日報の個人情報を外部APIに送ってよいか社内規程を確認する。
3. プロトタイプ：過去1か月分の日報で、LLMに要約と重要度判定をさせる簡単なスクリプトを作る。
4. 評価：過去の日報から20日分を選び、部長に「本当に重要だった項目」を印付けしてもらう（正解データ）。システムの出力と照らし、見逃し率（重要なのに拾えなかった割合）と誤検出（重要でないものを拾った割合）、日報にない内容を書いた件数（幻覚）を数える。特に見逃しは致命的なので重く見る。
5. 本番化：毎朝自動で実行する仕組み、失敗時の再試行と通知、ログ保存、費用の上限、部長以外が見られないアクセス制限を整える。
6. 運用と改善：部長が「これは不要」「これが抜けている」と付けたフィードバックを毎週集め、見逃した例を評価データに追加し、プロンプトを直し、評価で改善を確かめてから反映する。

(1) 分類
- ソフトウェア開発の基礎：Python開発、Web APIの設計・実装、Gitでのチーム開発、クラウド（AWS/GCP）
- LLMアプリの技能：LLMを使った開発、RAGの構築と精度評価、AIエージェントの開発
- 業務・ドメイン：製造業の業務知識、PoCから本番化までの進め方

(2) 対応する章
- Python：Part 1 全体（特に 1-07 関数、1-08 エラー、1-11 ファイル・JSON、1-13 型ヒントと Pydantic）
- Web API：2-05 HTTP と Web API、2-10 FastAPI で API を作る
- Git：2-02 Git と GitHub
- クラウド：8-05 デプロイ（Cloud Run など）
- LLM開発：Part 6 の 6-01〜6-06
- RAGと精度評価：6-07〜6-09、6-10 評価、4-04 統計
- エージェント：Part 7
- PoCから本番化：9-01 要件定義から納品まで、Part 8

(3) 見せる作品
- P3 社内規程Q&A を発展させ、公開されている製造業の技術文書（例：規格の解説や製品マニュアルなど公開資料）を対象にしたRAGを作る。評価用の質問を50件以上作り、検索の再現率と回答の忠実性を数字で示す。
- P6 で FastAPI＋Docker で公開し、ログと費用の監視を付ける。
- README に、チャンク分割の方法を比較した実験結果、失敗例の分類、PoCの成功基準を書く。
- 製造業の経験があれば、それを生かした題材を選び、ドメイン知識を説明できるようにする。

理解度チェック

print("3" + "4")

まとめ

• この課程のAIエンジニアは、学習済みの基盤モデルをAPIで使い、データやツールと組み合わせて、評価し、製品として運用する人。モデルを一から訓練する仕事ではない。
• 仕事は「課題の発見 → 要件の整理 → プロトタイプ → 評価 → 本番化 → 運用と改善」の流れで進み、何度も行き来する。
• 成功基準は事前に、測れる形で決める。デモの好評は成功基準にならない。
• 求人では、Python・LLM API・バックエンドが前提で、エージェント・評価・オブザーバビリティの比重が増えている。日本ではRAG、エージェント、PoCから本番化、ドメイン知識が目立つ。
• 未経験からは、評価の数字と設計判断を示せるポートフォリオと、今の業務での実績が鍵になる。
• AIがコードを書く時代に価値が上がるのは、仕様化、コンテキスト設計、検証とレビュー、評価、デバッグ、設計、ドメイン理解。
• 課程は Part 0〜9 と8つのプロジェクトで構成され、app（メイン）・auto・ml の3つのルートで優先度が変わる。
• アプリ内のPythonは print で表示したものだけが出力される。予想してから実行する習慣をここから始める。

参考資料

いずれも任意です。この課程はアプリ内で学習が完結するように作っています。英語の資料は、AIに要約や翻訳を頼みながら読んでも構いません。

• roadmap.sh AI Engineer：AIエンジニアの学習項目の地図（英語）
• swyx「The Rise of the AI Engineer」：AIエンジニアという呼び名を広めた2023年の記事（英語）
• Stack Overflow Developer Survey 2025 の AI の章：開発者のAI利用と信頼度の調査（英語）
• Simon Willison「Not all AI-assisted programming is vibe coding」：vibe coding と責任あるAI支援開発の違い（英語）
• Anthropic「Building effective agents」：エージェントを作るときの基本的な考え方（英語、Part 7で詳しく扱います）