【Deep Dive】AIエンジニア学習リストの23項目を、動く一つを育てる順番として読み解く
最近、codewith55さんの「AI Engineer in 2026」という投稿を読みました（元の投稿）。日付は2026年10月6日です。
AIエンジニアを目指す人のために、やることを23行で並べたリストです。
説明はなく、項目だけが並んでいます。だからこそ、各項目が何を指し、なぜこの順なのかを読み解く余地があります。
この記事の整理は、「一つのAIエージェントを作り、壊し、直す流れ」です。基礎の概念、仕組み、その先に読む概念を順に説明します。
【発端】 23項目は「作って壊して直す」順になっている
リストの後半ほど増えるのは、「作った後」の話です。この記事では、23項目を次の5段に束ねて読みます。
この束ね方は私の整理です。
基礎（6項目）：Python、API、LLMの仕組み、ツール呼び出し、RAG、埋め込みとベクトル検索
構築（3項目）：実際のエージェントを一つ作り、記憶とツールを持たせる
堅牢化（6項目）：再試行と代替手段、構造化出力、認証、観測、評価、実際の失敗でのテスト
運用（5項目）：公開、コスト監視、遅延の最適化、ログを読む、利用者の失敗を直す
公開（3項目）：オープンソース化、README、動くデモを履歴書に載せる
作る前の「基礎」と「構築」は9項目です。「堅牢化」と「運用」の11項目は、動き始めた後にやることを指します。
リストの重心は、動かすことより、動き続けさせることにあります。
末尾は「また一つチャットボットを作るのをやめて、人が本当に必要とするものを作ろう」という呼びかけです。このあとの節で、重心が後ろにある理由を説明します。
【基礎】 LLMを呼ぶ作法から、Toolを渡す作法へ
基礎の順は、APIを理解してから、エージェントに進むことです。
LLM（大規模言語モデル）は、文章を受け取って文章を返す仕組みです。アプリケーションからはAPI経由で呼びます。
ここに「道具」を渡せるのがツール呼び出しです。OpenAIの関数呼び出しガイドは、モデルが「このツールを使う必要がある」と判断したときに返す特別な応答、と説明しています。
もう一つの基礎がRAG（検索拡張生成）です。モデルは学習時の知識しか持ちません。
そこで、外部の文書を検索して答えに混ぜます。原論文のLewisらの研究は、モデルの内部知識と、Wikipediaを索引にした外部の記憶を組み合わせる構成を示しました。
外部の記憶を探す部品が埋め込みです。文章を数値のベクトルに変え、意味の近さで検索できるようにします。
【違い】 チャットボットとの差は、失敗したあと
チャットボットは、外れた答えを人が読んで終わりです。ツールを持つエージェントは、外れた判断がそのまま実行されます。
AnthropicのBuilding Effective AI Agentsは、二つを区別しています。ワークフローは、決まったコードの経路でLLMとツールをつなぐ方式です。
エージェントは、LLM自身が処理の進め方とツールの使い方を決める方式です。次の整理は、その区別に私が軸を足しています。
次の手を決めるもの
単発のチャット：人
ワークフロー：あらかじめ書いたコード
エージェント：モデル
外れたときの形
単発のチャット：人が読んで気づく
ワークフロー：決まった経路の中で起きる
エージェント：判断が連鎖して広がる
先に要るもの
単発のチャット：プロンプト
ワークフロー：経路の設計
エージェント：再試行、評価、権限、観測
リストの「堅牢化」の6項目は、エージェントの欄を埋める作業に当たります。ここまでが、重心が後ろにある理由です。
【仕組み】 判断はモデル、実行と許可はアプリ
Microsoftの関数呼び出しの解説も、モデルは引数付きのJSONを返し、関数を実行するのはアプリケーションで、制御はアプリ側に残ると述べています。
この分業を崩すと、危険です。OWASPのLLM06 過剰な代理権限は、原因を三つに分けています。
機能が多すぎる、権限が大きすぎる、自律が強すぎる、の三つです。
対策も同じ向きです。必要最小限のツールだけを渡します。
許可の判断は、モデルに任せず、下流のシステム側の仕事です。影響の大きい操作には、人の承認を入れます。
リストの「認証」「ログを読む」は、この分業を実装に落とした項目という読みです。
【具体例】 ツール呼び出しは、2回のリクエストで完結する
OpenAIのガイドは、ツール呼び出しを次の5段で説明しています。ここでは、Microsoftの解説に出てくる現在時刻を返す関数を、例として置きました。
アプリが、使えるツール（現在時刻を返す関数）を添えてモデルに依頼を送ります。
モデルが、その関数を呼ぶよう求める応答を返します。
アプリが、自分のコードで関数を実行します。
アプリが、実行結果を付けて2回目のリクエストを送ります。
モデルが最終的な回答を返します。さらにツールが必要なら、2に戻ります。
2と4の間に、アプリの責任が入ります。再試行、代替手段、認証、ログは、この間に置く部品です。
【関連概念】 評価、観測、権限が、リストの先を読む三つの手がかり
評価（eval）は、AIシステムへのテストです。AnthropicのDemystifying evals for AI agentsは、入力を与え、出力に採点ロジックを当てて成否を測ると定義しています。
エージェントの場合は、ツール呼び出しを含む一連の記録（トランスクリプト）も対象になります。
観測は、中で何が起きたかを後から読めるようにすることです。OpenTelemetryのGenAI観測の解説によれば、GenAI向けの標準的な記録規約があります。
呼んだモデルや入出力のトークン数を記録でき、オプトインすればプロンプトやツール呼び出しの内容も記録できます。
権限は、先ほどのOWASPの考え方です。
三つの関係を、私の整理で書きます。観測が失敗を見つけ、評価が再発を防ぎ、権限が失敗の被害を小さくする関係です。
リストが「失敗を直す」で終わらず、「実際の失敗でテストする」を入れているのは、このつながりのためと読めます。
参考情報・参考書籍（PR）
本記事をより深く理解するために、概念マップスライドを作成しました。こちらをみることで理解の補助になるはずです。
Chip Huyenの『AI Engineering: Building Applications with Foundation Models』は、基盤モデルを使うアプリ開発の全体を扱います。評価、RAG、エージェント、デプロイまでを含み、23項目の背景を補えます。
御田稔の『AIエージェント開発 / 運用入門 [生成AI深掘りガイド]』について、紹介されている範囲はツール連携、MCP、LangfuseによるLLMOps、Ragasでの評価です。「堅牢化」と「運用」を実装で試すときの参考になります。
太田真人の『現場で活用するためのAIエージェント実践入門』は、エージェントの構築、評価、改善を扱うと紹介されています。評価を含めて一周する流れの参考です。
John Berrymanの『LLMのプロンプトエンジニアリング』は、LLMの特性を踏まえた入力設計を扱います。「基礎」にあるLLMの仕組みの理解を補います。
【まとめ】 わざと失敗をさせて精査してみる
リストを頭から全部こなす必要はありません。次の順で、小さく一周できます。
これは私の提案で、効果を検証したものではありません。
□ ツールを一つだけ持つ小さなエージェントを作る
□ 失敗した入力と出力を、ログに残す
□ その失敗を、評価の一件として書き残す
□ READMEに、何ができて何ができないかを書く
一周すれば、23項目のうち「構築」「堅牢化」「運用」「公開」を、一つずつ軽く通ったことになります。
