Python開発経験者のAI開発学習ロードマップ
作成日・公式情報確認日：2026年9月28日
Pythonでアプリは作れる。でも、LLM、RAG、エージェントと学ぶものが多く、何から手を付けるか決まらない。そんな人は、一つの入力に答える処理を作り、出力の検証、評価、文書検索の順に足すと、学習の目的を見失いにくくなります。
この記事の対象は、Pythonの関数・例外処理・JSONを扱え、Gitで変更を管理できる人です。ゴールは「自作のFAQを参照し、根拠とともに回答する小さなアプリ」。モデルの事前学習や転職までを扱う計画ではありません。本記事に広告・アフィリエイトリンクはありません。
以下は編集部が提案する演習と到達基準です。掲載した順序での実機検証や、特定期間での習得を確認したものではありません。使うAPI・SDKの実装方法は、選んだ提供元の現行ドキュメントで確認してください。
学習は、残せる成果物で区切る
| 順序 | 学ぶこと | 残す成果物 | 次に進む目安 |
|---|---|---|---|
| 1 | LLMへの入出力 | 一問一答のCLI | 入力から応答までの流れを説明できる |
| 2 | 出力の検証と例外処理 | 検証付きの回答処理 | 不正な出力を成功扱いしない |
| 3 | 評価と改善 | 評価用の質問集と比較記録 | 変更で何が改善・悪化したか分かる |
| 4 | 文書検索とRAG | 根拠を表示するFAQアプリ | 検索と回答の失敗を分けられる |
| 5 | 利用条件と運用 | READMEと実行記録 | 他の人が条件と制約を把握できる |
進み方は、既に説明・実装できる段階を短くし、つまずく段階に時間を使います。教材の章を読み終えたことだけで、次へ進む判断をしないのがポイントです。
1．まず一問一答を作り、入力の違いを見る
最初の題材は、自作した架空のサービスのFAQです。例えば「返品の受付期限」「送料」「問い合わせ先」を文章にし、そのうち一つを入力に添えて質問します。実在の顧客情報を用意する必要はありません。
LLMが扱うトークンは、文字や単語と一対一に対応する単位ではありません。また、一度に扱える文脈には上限があります。最初はこれらの用語と、指示・参照文・質問を区別して入力する考え方を押さえます。Hugging FaceのLLM入門で基本を確認できます。
演習では「FAQだけを根拠に答える」「記載がなければ不明と返す」と指示し、同じ質問を言い換えて出力を比べます。返答が自然でも、FAQにない条件を付け足していれば失敗です。最初の成果物は画面の装飾より、入力、応答、使用モデルを記録できるCLIにしましょう。
環境にはPython、仮想環境、Gitと、選択したAPIの認証情報を用意します。Python・SDKのバージョンを記録し、認証情報をコードに埋め込まず、環境変数などで渡す構成にします。APIを使うなら事前に料金と利用上限を確認し、呼び出し回数の上限を自分でも決めてください。
2．回答をアプリで扱える形にし、失敗を分ける
次は回答を answer、source_id、needs_review のような項目に分ける演習です。本文、参照したFAQの識別子、人の確認が必要かを、後続の処理で取り出せるようにします。
Python側で型や必須項目を確かめる選択肢にはPydanticがあります。公式ドキュメントでは、モデルによる型・制約の検証が説明されています。ただし、型が正しくても、回答内容が事実と一致するとは限りません。Pydanticのモデルと検証
演習では、必須項目が欠けた出力と、存在しない source_id をそれぞれ検出します。後者には、実際のFAQ一覧と照合する処理が必要です。APIの接続失敗、出力形式の失敗、回答内容の誤りを同じエラーにまとめると、直す場所が分からなくなります。
タイムアウト時には無制限に再試行せず、回数を決めて停止する設計にします。「再試行後に回答できたか」に加え、「追加で何回呼び出したか」も残すと、後の費用確認に使えます。
3．検索を足す前に、小さな評価セットを作る
機能を増やす前に、正しさをどう判断するか決めます。公式の評価ガイドでも、目的に応じた測定可能な基準と、境界的な入力を含めた評価が説明されています。Anthropicの評価設計ガイド
最初の演習として、次の質問を合わせて10〜20件ほど自作します。この件数は着手しやすくするための提案で、公開できる品質を保証する基準ではありません。
- FAQに答えが明記されている質問
- 同じ内容を別の言葉で尋ねる質問
- FAQに答えがない質問
- 条件が不足しており、追加確認が必要な質問
- 参照文の指示を無視するよう求める質問
各質問に「回答に必要な要素」「参照すべきFAQ」「答えない条件」を書きます。自然文の回答は完全一致だけで採点せず、必要な条件を満たしたか人が読みます。形式の検証は自動化し、内容の確認とは別に記録しましょう。
指示文を変える際は、改善に使う質問と、最後に確認する質問を分けます。同じ質問だけに合わせて調整すると、別の入力での弱点を見落とします。変更前後で、回答内容、根拠、回答を控える判断、応答時間を比べ、悪化した例も保存します。
4．文書を増やし、検索と回答を分けて学ぶ
FAQが増えたら、質問に関連する文書を検索し、その文書をLLMへ渡す構成を試します。これがRAG（検索拡張生成）の基本です。検索を先に実行してから生成する構成は、LangChainのRetrieval解説でも整理されています。
演習では、まずFAQの見出しやキーワードで検索する小さな処理を作ります。その後、言い換えを拾えない例が見つかったら、文章を数値のベクトルに変える埋め込みと類似検索を学びます。この順序は、検索方法を変えた効果を比較するための提案です。
重要なのは、検索結果と回答を別々に保存することです。正しいFAQが検索されていなければ検索側を調べ、FAQは合っているのに条件を取り違えたなら回答側を調べます。取得した文書の識別子を出力と照合し、参照箇所を読者が開ける形にしてください。
根拠が見つからない場合に回答を控える動作も評価します。検索を加えただけでは、誤答がなくなると判断できません。段階3の質問集を再利用し、文書の追加によって以前の質問への回答が崩れていないか確かめます。
5．完成条件をREADMEに残す
学習の区切りには、起動手順だけでなく次を残します。
- Python・SDK・モデルの情報と、必要な設定項目
- 自作FAQと評価用質問の準備方法
- 評価結果、失敗例、現在回答できない範囲
- 呼び出し回数、応答時間、確認した料金に基づく実行費用
- 入力やログの保存先、保存期間、削除方法
API料金に加え、埋め込み、保存領域、公開用サーバーを使えば別途費用が生じる場合があります。金額は採用サービスと使用量で変わるため、この計画では総額を決められません。利用前に公式料金表を確認し、学習用の予算を超える前に停止する仕組みを用意します。
エージェントへ進むのは、外部の関数を選んで呼ぶ必要が出てからでも構いません。ツール呼び出しの基本はHugging FaceのTools解説で学べます。最初の演習は文書の読み取りに絞り、更新や送信を伴う処理は、権限と実行前確認を設計してから追加しましょう。
今日の着手は「FAQ三つと質問五つ」から
まずは架空のサービスについてFAQを三つ書き、それに答えられる質問と答えられない質問を合わせて五つ用意してください。次に一問一答の処理を作り、期待と違う結果を一つ記録します。この小さな記録が、次に学ぶべき内容を決める材料になります。
実装の判断で止まる場合や学習が続かない場合は、AI開発は独学かスクールか｜支援と学習時間で選ぶで必要な支援を整理できます。本記事の順序を基に、どの成果物のどこで止まったかを具体的に伝えると相談しやすくなります。
出典
公式情報確認日：2026年9月28日。学習順序・演習件数・到達基準は編集部の提案です。
コメント