この記事を、二人の対話で。
記事より古い内容です。新しい音声を準備しています。
AI 合成音声 · VOICEVOX Nemo（女声1・男声1）
音声の一覧・再生リストへAI Agent 学習ロードマップ
この記事の目的
このライブラリを「どの順で読むか」を、自分の目的に合わせて決められるようになります。16 のセクションの役割と依存関係を把握し、読者タイプ別の推奨ルートから自分に合うものを選べる状態がゴールです。
対象読者
- このライブラリを初めて訪れたソフトウェアエンジニア全般
- チームに AI AgentLLM を判断の中枢に置き、ツールを使いながら、目標達成までの手順を実行時に自律的に決めて実行するシステム。 の学習を導入する立場のテックリード・エンジニアリングマネージャー
前提知識
- システムプロンプトとユーザーメッセージの区別が付けば読み始められます。LLM API の呼出し経験は理解の助けになりますが、APIキーなしのmock経路で学習を開始できます
- このライブラリ内の前提ドキュメントはありません(本記事が入口です)
本文
概要: 16 セクションの構成と依存関係
このライブラリは「概念 → 設計 → 実装 → 評価 → 運用」という開発ライフサイクルの順にセクションを並べ、セキュリティと事例を横断テーマとして置いています。08(コーディングエージェントコードベースを読み、ファイルを編集し、コマンドを実行して検証するループで開発タスクを遂行する Agent。コード補完と異なり「タスク単位の委任」を受けられる。)は「Agent を使う側」の独立したテーマで、入口は01の基礎概念です。防御設計やSE実践では追加の必須前提があるため、下記のF・Hルートで寄り道を確認します。09(ビジネス実務)は「何をやるか・どう本番に届けるか」という案件推進の方法論で、技術セクションと並行して読めます。10(LLM 基礎)は「LLM 自体がなぜそう振る舞うか」を深める任意の基礎で、01 と並行して、または実務で挙動の疑問に当たったときに読めます。11(LLM 内部構造)は 10 の学術的な下層で、Transformer の数式・スケーリング則損失がモデルサイズ・データ量・計算量に対して、滑らかなべき乗則で下がる経験則。計算最適(Chinchilla)はパラメータとデータをほぼ均等に増やすべきと修正した。べき指数・定数は構成依存の経験則で、普遍定数ではない。・アラインメント理論・推論機構・解釈可能性などを原論文つきで深めます(10 を読んで「なぜ」をさらに数式で掘りたい人向けの任意セクション)。12(モダリティ応用)は文書・画像・動画・音声の理解と生成を扱う応用テーマで、03(実装)を前提に、必要になったときに読めます。13(ドメイン応用)はリサーチ・データ分析・RPA・アシスタントなど応用ドメインごとの設計判断で、03(実装)を前提に、該当ドメインに取り組むときに読めます。14(UX・プロダクト)は非決定的な AI システムの体験設計で、02・03(設計・実装)を前提に、体験を作り込む段で読めます。15(人と AI の協働)は、AI を使うすべての人の認知と技能 — 過信・検証習慣・キャリア・リテラシー教育 — を扱う横断的な基礎で、全読者に関わります。
図を元の大きさで表示
図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。
矢印は「先に読んでおくと理解が速い」という依存関係です(点線は必須ではない補助的な依存)。上から順にすべて読む必要はなく、次の推奨ルートから選んでください。
読者タイプ別の推奨ルート
| タイプ | 状況 | 推奨ルート |
|---|---|---|
| A: 入門 | AI Agent をこれから学ぶ | 01-concepts を上から順に → Workflow 型 vs Agent 型 → 03-implementation → Agent 評価の基礎 → プロンプトインジェクション |
| B: 設計担当 | 要件を受けて設計を始める | AI Agent とは何か → Agent ループ → 02-architecture を全部 → Agent の脅威モデル概観 |
| C: 実装担当 | 設計済みのものを実装する | 03-implementation を全部 → 実装済みサンプル → 04-evaluation |
| D: 運用・SRE | 既存の Agent を本番運用する | 05-operations を全部 → 回帰テストと CI 組み込み → 06-security |
| E: セキュリティ | Agent システムをレビュー・監査する | 06-security を全部 → ツール使用 → Human-in-the-Loop 設計 |
| F: エージェント活用 | Claude Code 等のコーディングエージェントを使う・導入する | AI Agent とは何か → Agent ループ → 分類と全体像 → 選定基準と使い分け → セキュリティの前提を補う → 権限・秘密情報・破壊的操作への対策 |
| G: プロフェッショナル志向 | 全領域を実務レベルに広げ、案件を推進する | スキルマップで自己評価 → 弱い領域のセクションを README の順に → ユースケース発見と要件定義 → PoC から本番への進め方 → 組織定着なら AI 時代のチームトポロジー ほか 09 章の組織・プロセス層 |
| H: 企業システム開発(SIer・情シス) | 受託・社内の企業システム開発でコーディングエージェントを工程横断で使う | AI Agent とは何か → Agent ループ → 分類と全体像 → 依頼設計 → SE 工程別活用マップ → 工程別の前提と記事を選ぶ → 企業制約の前提を補う → 企業システム環境の制約と対応 |
個別ドキュメントの執筆状況は各セクションの README で確認できます(ファイル名がリンクになっているものが執筆済み、バッククォートのままの名前は計画段階です)。
F・Hの必須前提と寄り道
F・Hの入口は「AI Agentとは何か」と「Agentループ」です。システムプロンプト・チャット履歴・トークンの基本を説明できることも確認してください。既読の記事は再読を省けますが、業務SEの経験だけでAgent固有の前提を既知と見なしません。下記は各記事の「前提知識」に合わせた必須の寄り道です。製品別の紹介や実践記事は、Fの防御設計を読んだ後に08章の索引から選びます。
Fのセキュリティへ進む前に
「分類と全体像」「選定基準」の後、未読なら ツール使用 → ツール定義の設計 → ツール接続標準(MCP) → Agentの脅威モデル概観 → ツール権限設計とサンドボックス の順に読みます。これで権限・秘密情報・破壊的操作への対策の必須前提である分類・脅威モデルシステムの攻撃面を棚卸しし、脅威を列挙・分類してリスクを優先順位付けする作業とその成果物。構成変更のたびに見直す。・権限設計をそろえられます。Hの企業制約へ進む場合にもこの寄り道を使います。
Hの工程別記事へ進む前に
「分類と全体像」→「依頼設計」→「SE工程別活用マップ」までを共通の先行ステップにします。その後は担当工程を選び、次の対応表で未読の必須前提を補ってから工程記事を読みます。一般的な要件定義・テスト・保守の経験は読みやすさを助けますが、表の必須記事を置き換えません。
| 選ぶ工程記事 | 必須前提のそろえ方 |
|---|---|
| 要件定義・設計 | 工程マップ・依頼設計は先行ステップ。さらに Workflow型 vs Agent型 → ユースケース発見と要件定義 を先に読む |
| テスト | 工程マップと、上の要件定義・設計記事を先に読む。さらに下記の評価の寄り道を経て 回帰テストと評価データセットの管理 を読む。一般的なCI/CDの経験も必要 |
| レガシーコード理解 | 工程マップ・依頼設計は先行ステップで充足 |
| 保守・運用 | 工程マップは先行ステップ。上のレガシーコード理解記事を先に読む |
テスト工程の評価の寄り道は Workflow型 vs Agent型 → Agent評価の基礎、および ツール使用 → 構造化出力 です。両方を読んだ後に LLM-as-a-Judge → 回帰テスト へ進みます。Workflow型の前提は入口の「AI Agentとは何か」、評価の基礎の前提は入口の「Agentループ」とWorkflow型です。
Hの企業制約へ進む前に
企業システム環境の制約と対応の必須前提は、先行ステップの工程マップ、Fで案内した権限・秘密情報への対策、業界別規制マップです。規制マップが未読なら、次の前提を順に補います。
- Fの寄り道でツール使用LLM が外部機能の呼び出し要求を出し、アプリケーションまたはプロバイダーの実行基盤が検証・権限に従って実行し、結果をモデルへ返す仕組み。実行主体と制御点を区別する Agent の中核機構。・脅威モデルまで読み、プロンプトインジェクション → データ漏えい対策へ進みます。
- Workflow型 vs Agent型 → Agent評価の基礎 → 軌跡評価 → 可観測性とトレーシングへ進みます。入口のAgentループもこれらの前提です。
- 1・2のデータ漏えいAgent を経由して機微データが外部に出ること。間接プロンプトインジェクションによる攻撃系と、権限・ログ設計の不備による事故系がある。対策と可観測性トレース・メトリクス・ログといった外部出力から、システム内部で何が起きたかを説明できる性質。Agent では技術メトリクスに加えて品質シグナルの設計が必要になる。を読んだ後、コンプライアンスとガバナンスを読みます。別に、Workflow型の後でユースケース発見と要件定義を読みます。
- コンプライアンスとユースケース発見を読んだ後、業界別規制マップへ進み、企業制約の記事へ戻ります。
これらは導入可否・データ持ち出し・監査を判断するための前提です。工程記事を選ぶことと、そのまま本番データや顧客コードをAgentへ渡してよいことは別です。
A・B・Cの最初の小課題と到達確認
最初の成果物を次の3つに限定します。A/Bは文章だけ、CはPython 3.11以降の標準ライブラリだけで完了でき、APIキーも有料API実行も不要です。これは学習の区切りであり、資格認定・実APIの生成品質・本番適性の証明ではありません。スキルマップの既存の到達レベルや実務経験の自己評価とは分けて使います。
A: 構成と使い分けを1ページで説明する
- 入力: 「先月の請求額が二重に引き落とされています。至急確認してください。」という問い合わせを、カテゴリ・優先度・要約に整理する業務です。外部への送信は行いません。
- 必要な記事: AI Agentとは何か、Agentループ、Workflow型 vs Agent型。
- 成果物: モデル・ツール・状態・ループの役割、固定した分類Workflowで足りる理由、Agentにするなら何を動的に選ぶか、成功/失敗/回数上限/人への引継ぎという停止条件を1ページに書きます。
- 終了条件: 分類の手順が固定ならWorkflowを選べること、ツールを呼ぶモデルと実行コードを区別できること、無制限に続けない条件を説明できることを、記事に照らして確認します。
- 次へ: ツール使用を読んでBの設計メモへ進みます。
B: 実行境界を埋めた設計メモを作る
- 入力: Aと同じ問い合わせを分類し、回答の下書きまで作る業務です。実データや実サービスは使いません。
- 必要な記事: ツール使用、Human-in-the-Loop設計、エラー処理、Agent評価の基礎。
- 成果物: 入力、出力(category/priority/summary/回答下書き)、ツール権限(参照と下書きのみ)、承認(外部送信は今回禁止、将来許可するなら実引数・宛先・差分の承認)、停止(検証成功、認可拒否、最大試行2回)、評価(期待カテゴリ「請求」、優先度「高」、要約30字以内、外部送信0件)を空欄なく書きます。
- 終了条件: 正常分類、許容外priority、認可拒否、承認後の引数変更の4ケースについて、検証・許可済み代替・停止・再承認のどこへ進むか一意に書ければ一区切りです。禁止操作を代替経路で実行しません。
- 次へ: 構造化出力を読んでCの実行記録へ進みます。
C: 2つのmockの実行結果を説明する
- 入力: structured-outputのREADMEとevaluation-harnessのREADMEの固定mock入力です。
- 成果物: Pythonの版、コマンド、標準出力、終了コード、検証NG/OKと評価NGの理由、mockで確認できる範囲と実APIでは未確認の範囲を実行記録に残します。
- 実行: リポジトリのルートで次の2コマンドを実行します。終了コードは端末で確認します(PowerShellでは各実行の直後に
$LASTEXITCODE)。
python -X utf8 examples/python/structured-output/structured_output.py --mock
python -X utf8 examples/python/evaluation-harness/eval_harness.py --mock- 終了条件: structured-outputの試行1は許容外の「至急」でNG、試行2は「高」でOKとなり終了0。evaluation-harnessはc4が「その他」/正解「請求」でNG、全体は4/5=80%で閾値80%を満たし終了0になることを説明します。1ケースのNGと、全体の閾値割れによる終了1を区別します。READMEの手順で閾値を90%にすると、この同じ結果は全体不合格になります。
- 次へ: 回帰テストとCI組み込みを読み、実APIを使う場合は各READMEの依存・キー・費用条件を確認して別の検証として記録します。
セクションごとの読みどころ
- 01-concepts — 「Agent とは何か」から始まる基礎概念。全読者に共通の土台で、他セクションはここの用語を前提にします
- 02-architecture — 「Agent にするか、Workflow で済ませるか」など、コードを書く前の設計判断。過剰な Agent 化を防ぐ視点を提供します
- 03-implementation — ツール定義・プロンプト・構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。などの実装パターン。
examples/の動くコードと対で読みます - 04-evaluation — 「作ったが品質が分からない」を防ぐ評価設計。実装と同時に読み始めることを推奨します
- 05-operations — 可観測性・コスト・インシデント対応など本番運用の実務
- 06-security — プロンプトインジェクションモデルへの入力に紛れ込ませた指示で、開発者の意図した挙動を上書きする攻撃。ユーザー入力による直接型と、Agent が読む外部コンテンツ経由の間接型がある。を筆頭とする Agent 固有の脅威と対策。設計初期に一読してください
- 07-case-studies — 具体事例とアンチパターン詳解。他セクションを読んだあとの総仕上げ
- 08-coding-agents — Claude Code などのコーディングエージェントを使う側の体系(選定・設定・セキュリティ・チーム導入)。入口は01の基礎概念です。防御設計・SE実践の追加前提は上記F・Hの案内で確認します
- 09-business — ユースケース選定・PoC本番導入を判断するために必要な「問い」を、期間を区切って検証する使い捨て前提の試作。デモの成功ではなく、本物のデータ分布での測定結果を成果物とする。 → 本番・ROI投資による純利益を投資額で割った率であり、効果から費用を引いた純便益額とは区別します。比較時は評価期間・分母の範囲を揃え、人のレビュー費用を便益と費用で二重に差し引かないようにします。 といった案件推進の方法論。技術の前(何をやるか)と後(どう届けるか)を扱い、04(評価)を先に読むと本番化の関門判断が理解しやすくなります
- 10-llm-foundations — 生成・トークン・注意機構・学習・能力限界という LLM 自体の「なぜ」。数式なしの直感で、01 の理解と日々のデバッグ・設計判断を深めます(任意の基礎。01 と並行して読めます)
- 11-llm-internals — Transformer の数式・注意の変種・MoE 内部・スケーリング則・アラインメント理論・推論機構・解釈可能性・文脈内学習プロンプトの例だけから、重みを変えずにタスクを学ぶように振る舞う現象。理論仮説(暗黙のベイズ推定・学習アルゴリズムの模倣・誘導ヘッド)は決着していない。few-shot の例は正解の列挙より、出力の形式・分布の実演として効く。という LLM 内部の「なぜ」を数式と原論文で。10 の学術的下層で、数式ありの深掘り(任意。10 を読んでさらに掘りたいとき)
- 12-multimodal — 文書・画像・動画・音声の理解と生成の実務(ドキュメント AI・画像理解・マルチモーダル RAG画像・図表・PDF を含む知識源で行う RAG です。テキスト化や画像埋め込みによる検索と、取得したページを視覚言語モデルで読む処理を分け、知識源に合わせて組み合わせ・評価します。・画像/動画/音声生成・リアルタイム観測)。03(実装)を前提とする応用テーマで、必要になったときに読めます
- 13-domain-agents — リサーチ・データ分析・RPA・アシスタント・検索・執筆翻訳・教育など応用ドメインごとの設計判断。01〜06 章の「ドメイン非依存の作り方」に対する「横の設計ガイド」で、03(実装)を前提に該当ドメインに取り組むときに読めます
- 14-ux-and-product — 非決定的な AI システムの体験設計(UX パターン・会話設計・チャット以外の UI・プロアクティブ利用者が頼む前にエージェント側から動く性質(通知・提案・先回り)。便利さとうるささが紙一重で、外し続けると正しい通知まで無視され信頼を損なう。確信度 × 重要度 × 頻度の掛け算で介入を絞り、ユーザー制御(頻度設定・ミュート・「なぜ出たか」の説明)を用意する。性・アクセシビリティ)。従来のデザイン原則がそのまま通じない領域で、02・03 を前提に体験を作り込む段で読めます(価格設計は 09 章)
- 15-human-ai — AI と協働する個人の認知と技能(オートメーションバイアス自動化された判断を人間が過度に信頼し、自分で検証・反証しなくなる傾向。訓練された専門家でも起き、LLM の流暢さ・断定的な口調が引き金を強める。意志でなく、検証をデフォルト化する構造で防ぐ。・検証習慣・キャリア戦略・リテラシー研修設計)。仕組みの手前にある「使う人間の側」を扱う横断的な基礎で、全読者に関わります
学習の進め方の指針
- 概念(01)を飛ばさない。フレームワークの API はすぐ変わりますが、Agent ループLLM が「観測 → 思考 → 行動」のサイクルを繰り返し、完了・失敗・上限のいずれかの停止条件まで自律的に処理を続ける制御構造。やツール使用(tool use)の原理は変わりません
- 評価(04)とセキュリティ(06)を「あとで」にしない。どちらも後付けが最も高くつく領域です
- 読むだけでなく、実装済みの6サンプル を手元で動かして確かめてください。最初は structured-output の
--mockを使い、検証NGから再試行でOKになる流れを確認します。ほかにツール使用・RAG・MCPサーバー・マルチエージェント複数の Agent ループが、それぞれ独立したコンテキストを持って分担・協調する構成。・評価ハーネスAgent の評価を繰り返し実行可能にする仕組み一式。データセット・実行系・採点系・レポートの 4 点で構成される。を収録しています。6件ともAPIキー不要の--mock経路があり、追加依存と確認範囲は各READMEを参照します
mock実行はPython 3.11以降など、各READMEの条件を満たす環境で始められます。実APIは任意の次段階で、APIキー・固定SDK依存・利用費用を別に準備します。mockの成功は、実モデルの生成品質や外部サービスとの接続を確認した結果ではありません。
実務での注意点
アンチパターン
- いきなりフレームワークから学び始める → 抽象化の下で何が起きているか分からず、不具合時にデバッグできない → 先に 01-concepts で生の仕組み(ループ・ツール呼び出し)を理解してからフレームワークに進む
- デモが動いた時点で「学習完了」と判断する → Agent は動くものを作るより、品質を保証し運用し続ける方が難しい → 04(評価)と 05(運用)までをスコープに含めて学習計画を立てる
- セキュリティを本番直前に初めて調べる → プロンプトインジェクション対策は後付けしにくく、設計変更を強いられる → 設計段階で 06 の脅威モデルに目を通す
チェックリスト
学習を始める前のセルフチェック:
- 自分の読者タイプ(A〜H)を決めた
- 作りたいもの(または運用するもの)を 1 文で説明できる
- mockを実行する場合、Python 3.11以降と対象READMEの条件を満たす環境がある(APIキー不要)
- A/B/Cの小課題を選び、入力・成果物・終了条件を確認した
- 任意の実API検証はmockと分け、依存・キー・費用条件と未確認範囲を記録する
- 読む予定のセクションの README にざっと目を通した
関連トピック
- AI Agent とは何か — 本記事の次に最初に読む 1 本
- AI Agent プロフェッショナルのスキルマップ — 「どの順で読むか」(本記事)に対して「どこまで深めるか」を決める自己評価軸
- 各セクションの詳細は上記「セクションごとの読みどころ」の各 README リンクを参照
参考資料
- Building Effective Agents(Anthropic) — Workflow と Agent の区別、シンプルさを優先する設計原則(アクセス日: 2026-07-05)
- LLM Powered Autonomous Agents(Lilian Weng) — プランニングタスクをステップに分解し、実行順序を決め、進捗に応じて見直す働き。逐次判断・事前計画・リフレクションの 3 パターンが基本形。・メモリAgent が「覚えている」ように見えるデータの総称。短期記憶(コンテキスト)・作業状態・長期記憶(外部ストレージ)の 3 層に分けて設計する。・ツールという構成要素の古典的な整理(アクセス日: 2026-07-05)