LLM開発の勉強法｜RAG・評価・エージェントを学ぶ順番

本メディアはRaiseTech（PISTEC株式会社）が運営しています。

「LLMを使った開発を学びたいのですが、何から手をつければいいでしょうか」
「RAG、ファインチューニング、エージェント…と用語が多くて、順番が分かりません」

この記事は、そんな迷いを持って「LLM 勉強法」と検索したあなたのために書きました。

結論から言うと、学ぶ順番は「使う → つなぐ → 確かめる → 任せる」です。話題になりやすいファインチューニングやエージェントは、最後に回して問題ありません。実務で最初に求められるのは、出力を制御し、外部の情報とつなぎ、品質を確かめる力だからです。

この記事では、学ぶ前に揃えておくもの、4つの段階それぞれで学ぶこと、そして学習でつまずきやすい壁までを解説します。

RaiseTech（レイズテック）は、受講者数2,500名超え！現役エンジニアが講師を務めるAIエンジニア育成のオンラインスクールです。未経験からのエンジニア転職を支援してきた現場で見てきたリアルな情報をもとにお伝えします。

結論｜学ぶ順番は「使う → つなぐ → 確かめる → 任せる」

用語から学ぶと迷います。実務で必要になる順番で並べると、4段階に整理できます。

段階	学ぶこと	この段階でできるようになること
① 使う	APIで呼び出す、出力の形式を固定する	LLMを部品としてプログラムに組み込める
② つなぐ	外部の情報を検索して渡す（RAG）	自社にしかない情報を踏まえた回答を作れる
③ 確かめる	出力を評価する仕組みを作る	改善したのか悪化したのかを判断できる
④ 任せる	ファインチューニング、エージェント	①〜③で足りない場面に、手段を足せる

この順番には理由があります。①〜③は、ほぼすべてのLLM開発で必要になります。一方、④は必要になる場面が限られ、しかも③の評価の仕組みが無いと、手を加えた結果が良くなったのかどうか判断できません。

話題性だけで④から入ると、動かし方は覚えても、それが業務で役に立つのかを説明できない状態になります。選考でも実務でも、問われるのは「なぜその手段を選んだか」です。

期間の目安も書いておきます。プログラミングの土台がある前提で、①〜③を一通り経験して小さな制作物にまとめるまで、働きながらなら数か月を見込んでください。これは学習内容から積み上げた目安で、統計に基づく数字ではありません。確保できる時間と前提知識で大きく前後します。各段階で1つずつ小さく作り、次の段階ではそれを拡張する形にすると、最後に1つのまとまった制作物が残ります。

→ LLMを扱う職種の全体像はLLMエンジニアとは？仕事内容・必要スキルと求人の探し方にまとめています。

前提｜学ぶ前に揃えておくもの

LLM開発の学習は、プログラミングの土台がある前提で進みます。ここが無いと、①の段階で止まります。

• ① プログラミングの基本：変数、条件分岐、繰り返し、関数。中心の言語で小さなプログラムが書ける状態
• ② APIの扱い：外部のサービスにリクエストを送り、返ってきたデータを処理できること
• ③ エラーの読み方：エラーメッセージから原因の見当をつけ、切り分けられること
• ④ 秘密情報の管理：APIキーをコードに直接書かない、公開の場所に置かない、といった基本

④は見落とされがちですが、最初に身につけておかないと実害が出ます。APIキーを含んだコードを公開してしまうと、第三者に使われて費用が発生することがあります。学習の段階から、キーは環境変数などで別に管理する習慣をつけてください。

数学については、この段階では深い知識は要りません。LLMの内部の仕組みを理解するには数学が出てきますが、使って組み込む段階では、概念として「文章を数値のまとまりに変えて似ているものを探す」ことが分かっていれば進めます。必要になったときに戻れば十分です。

言語については、言語を覚えることはスタートライン。現場で価値が出るのは、何を作るかを設計し、AIに正しく指示し、出力をレビューして品質を担保する力です。LLM開発は、この3つの力がそのまま業務内容になっている領域です。

段階① 使う｜APIで呼び出し、出力を制御する

最初の段階は、LLMを「プログラムの部品」として扱えるようになることです。

• 呼び出す：APIに指示を送り、結果を受け取る。役割の与え方や、例を示す書き方もここで試します
• 出力の形式を固定する：自由な文章ではなく、決まった形式（項目名と値の組など）で返させます。これができないと、他のプログラムに結果を渡せません
• 失敗に備える：応答が遅い、途中で切れる、想定と違う形式で返ってくる。こうした場合の処理を書きます

この段階で最も大事なのは、「出力の形式を固定する」です。チャット画面で使うだけなら自由な文章で困りませんが、システムに組み込むと、形式が毎回違う出力は扱えません。形式を指定し、それが守られなかった場合にどうするかまで書いて、初めて部品として使えます。

練習の題材は、身近な文章の整理が向いています。受け取ったメールから日時と用件を取り出す、長い文章を決まった項目に分けて要約する、といったものです。結果を目で確かめやすく、形式を固定する練習になります。

費用にも注意してください。呼び出すたびに料金がかかるAPIが多いため、学習中でも使いすぎないよう上限を設定しておきます。繰り返し処理の中で呼び出すコードを書くときは、特に気をつけてください。

この段階を終えた目安は、「同じ指示を100回呼び出しても、形式が崩れた出力をプログラム側で検知して処理できる」ことです。1回うまく動いた、では足りません。崩れたときに止まらない、崩れたことに気づける。この2つができれば、次の段階に進んでかまいません。

段階② つなぐ｜外部の情報を渡す（RAG）

実務で価値が出るLLM機能の多くは、自社にしかない情報を扱います。その仕組みを学ぶのがこの段階です。

RAG（検索拡張生成）は、質問に関係する情報を先に探し、それを踏まえて回答させる仕組みです。流れは4つに分かれます。

• ① 分ける：資料を、検索しやすい大きさに分割します
• ② 探す：質問に近い内容の断片を見つけます
• ③ 渡す：見つけた断片を、指示と一緒にLLMに渡します
• ④ 答える：渡された情報を根拠に回答させます

この段階で身につけたいのは、仕組みの組み方より「何を、どの単位で渡すか」の判断です。資料を大きく分けすぎると必要な部分が埋もれ、細かく分けすぎると文脈が失われます。この加減は資料の性質によって毎回変わり、そこに実務の勘所があります。

練習の題材は、自分の手元にある資料が最適です。業務マニュアル、学習メモ、よく使う手順書。質問と正しい答えが自分で分かるので、次の段階③で評価の練習にもそのまま使えます。

この段階でよくある失敗も挙げておきます。回答がおかしいときに、指示の書き方ばかりを直してしまうことです。実際には、そもそも適切な情報が検索で見つかっていない、ということがよくあります。回答を見る前に、LLMに渡した情報を先に確認する習慣をつけてください。原因が「探す」側にあるのか「答える」側にあるのかを分けるだけで、直す場所が明確になります。

→ LLMを業務に載せるまでの全体の流れはLLMエンジニアとは？の「仕事内容」で整理しています。

段階③ 確かめる｜出力を評価する仕組みを作る

ここが、学習と実務を分ける段階です。多くの学習者がここを飛ばします。

LLMの出力は、同じ入力でも毎回同じにはなりません。そのため、「良くなった気がする」で判断すると、改善したのか悪化したのか分からなくなります。指示を少し変えたら、ある質問では良くなったが、別の質問では悪くなった、ということが日常的に起きます。

仕組みといっても、最初は単純でかまいません。

• ① 質問を用意する：10件ほど。易しいもの、紛らわしいもの、答えが資料に無いものを混ぜます
• ② 期待する答えを決める：何が含まれていれば正解か、何を言ってはいけないかを書いておきます
• ③ 変更のたびに比べる：指示や分け方を変えたら、全部の質問で結果を取り直します
• ④ 記録する：何を変えて、どう変わったかを表に残します

①の「答えが資料に無い質問」が特に大事です。LLMは、知らないことでももっともらしく答えてしまうことがあります。「分からない」と答えるべき場面で正しくそう答えるかを確かめないと、業務では使えません。

そして④の記録は、そのまま選考の材料になります。「なぜその作りにしたのか」を根拠つきで説明できるからです。ここまでやっている応募者は多くありません。

評価の観点も、最初から多くを求めなくてかまいません。「必要な情報が含まれているか」「資料に無いことを言っていないか」「形式が守られているか」の3つから始めてください。慣れてきたら、回答の長さや、根拠として示した資料の正しさなどを足していきます。観点を増やすより、変更のたびに必ず比べる習慣のほうが先です。

→ 指示と検証を設計する役割はプロンプトエンジニアとは？、制作物としての見せ方はポートフォリオの作り方にまとめています。

段階④ 任せる｜ファインチューニングとエージェントは最後でいい

話題になりやすい2つを、あえて最後に置いた理由を説明します。

	ファインチューニング	エージェント
中身	自分のデータでモデルを追加学習させる	LLMに手順を考えさせ、道具を使わせて作業を進めさせる
向く場面	出力の口調や形式を一貫させたい、特定の分類を安定させたい	複数の手順をまたぐ作業を自動化したい
最後に回す理由	多くの課題は①〜②で解決する。データの準備と費用の負担も大きい	失敗の仕方が複雑になる。③の評価が無いと、どこで間違えたか追えない

ファインチューニングについては、「知識を覚えさせるため」に使おうとするのは多くの場合遠回りです。自社の情報を踏まえて答えさせたいなら、まず段階②の外部情報をつなぐ方法を試してください。そのほうが情報の更新も簡単です。

エージェントについては、自動で複数の手順を進めるぶん、途中の1つが間違うと結果全体が崩れます。どの手順で何が起きたかを追う仕組みと、段階③の評価が無い状態で組むと、うまくいかない原因を特定できません。

どちらも、①〜③で解決できない課題に出会ってから学べば間に合います。そのときには、なぜその手段が必要なのかを自分で説明できる状態になっているはずです。

情報の追い方についても、1つだけ。この領域は技術の入れ替わりが速く、半年前のやり方が古くなることがあります。特定の道具の使い方を覚えることに時間を使いすぎると、その投資は目減りします。一方で、「出力の形式を固定する」「渡す情報を選ぶ」「変更のたびに比べる」という考え方は、道具が変わっても残ります。新しい手法が出たときは、それが①〜④のどこを置き換えるものかを考えると、追うべきかどうかを判断しやすくなります。

学習でつまずく3つの壁

最後に、この順番で進めても多くの人が止まる場所を挙げておきます。

• ① エラーの原因が切り分けられない：APIの設定、ライブラリのバージョン、ネットワーク。原因がコードの外にあることが多く、調べる言葉すら出てこない状態で数日が消えます
• ② 何を作れば実務の練習になるか決まらない：チュートリアルをなぞって動いたあと、次に何を作ればいいかが分かりません
• ③ 作ったものの出来が実務水準か判断できない：段階③の評価を作っても、その基準自体が妥当かは、比べる相手がいないと分かりません

②は、自分が困っていることを題材にすることで越えられます。③は、コードを公開して見てもらう、勉強会で説明するといった、他者の目に触れる機会を作ることで越えられます。①は、質問できる場所があるかどうかで、止まる時間が大きく変わります。

エラーの切り分けについては、生成AIに相談するのも有効です。ただし、返ってきた説明が正しいかを判断できないと、間違った方向に進んでしまいます。提案された解決策を試す前に、なぜそれで直るのかを自分の言葉で説明できるかを確かめてください。説明できないまま試すと、直ったとしても次に同じ種類の問題が起きたときに対処できません。

→ 独学で止まる壁の越え方はAIエンジニアの独学は無理？限界になる3つの壁と越え方に、生成AIを扱う職種の全体像は生成AIエンジニアとは？にまとめています。

未経験からAIエンジニアを目指すなら

LLMを呼び出して動かすところまでは、多くの人がたどり着きます。止まるのはその先です。エラーの原因が切り分けられない、何を作れば実務の練習になるか決まらない、作ったものの出来が実務水準か判断できない。

RaiseTech（レイズテック）のAIエンジニア育成コースは、その壁を越えるために作られたオンラインスクールです。

• 現役AIエンジニアの講師に、受講期間中は質問無制限
• 生成AI・LLM開発を含む、実務直結のカリキュラム
• ポートフォリオ作成から転職・案件獲得まで、修了後も無期限サポート
• 専門実践教育訓練給付金の対象。条件を満たせば受講料の最大80%が給付

未経験からエンジニアになった受講生の実績

「本当に未経験からなれるのか」は、実際になった人を見るのが一番早いです。いずれもAWS・Javaコースの卒業生ですが、「未経験から学び、ポートフォリオを作り、転職する」という道筋はAIエンジニアでも同じです。

事例①：完全未経験から半年でWebエンジニアへ｜年収250万円→600万円

プログラミング完全未経験からJavaコースを受講し、受講開始から半年でWebエンジニアとして転職。年収は250万円から600万円へと2倍以上になり、フルリモート・残業ゼロの働き方を実現しました。

特筆すべきは「半年」というスピードです。特別な才能があったわけではなく、講義に毎週出席し、分からないことをその週のうちに質問で解消する、という当たり前のことを止めずに続けた結果でした。

▶ 赤松さんのインタビューを読む

事例②：30代後半・未経験からクラウドインフラエンジニアへ｜初年度から年収600万円

30代後半、AWS未経験からAWSコースを受講。キャリアチェンジ後の最初の職場で年収600万円に到達し、フルリモートで働いています。

「30代後半では遅い」という不安を持つ方は多いですが、この事例はそれを覆しています。前職までの社会人経験は、エンジニアになってからもプロジェクトの進め方や顧客とのやり取りで強みになります。年齢は壁ではなく、むしろ武器になり得ます。

▶ 石川さんのインタビューを読む

事例③：AWSを武器に差別化｜本業＋副業で年収800万円・フルリモート

AWSコースで学んだスキルを武器に、フルリモート勤務のエンジニアとして転職。本業と副業を合わせて年収800万円を達成しました。

ポイントは「差別化」です。エンジニアの数は多くても、クラウドやAIといった需要の高い領域を扱える人は限られます。学ぶ領域を選ぶことが、そのまま市場価値の差になる。AIエンジニアを目指す方にとっても、まさに同じ構造が当てはまります。

▶ まつもとさんのインタビューを読む

まとめ｜話題性ではなく、実務で必要になる順番で学ぶ

この記事のポイントを3つにまとめます。

1. 順番は「使う → つなぐ → 確かめる → 任せる」。出力の形式を固定する、外部情報とつなぐ、評価の仕組みを作る。この3つがほぼすべてのLLM開発で必要になります。
2. 評価の仕組みが、学習と実務を分ける。質問と期待する答えを用意し、変更のたびに比べて記録する。この記録はそのまま選考の材料にもなります。
3. ファインチューニングとエージェントは最後でいい。多くの課題は手前の段階で解決し、評価が無い状態で手を加えても良し悪しを判断できないためです。

LLMを扱う職種はLLMエンジニアとは？、生成AI全般は生成AIエンジニアとは？にまとめています。