Briefing
AIエンジニアリングは、評価から始める
派手なエージェントやファインチューニングではなく、まず出力の良し悪しを測る物差しを置く。この記事全体を、その順番を確認するレポートとして読む。
Before we begin
AIエンジニアリングの入口は、派手なエージェントではなく、出力をどう評価するかにある。
この記事では、翻訳しながら重要だと感じた論点を、評価、モデル適応、技術選択の順に絞って整理する。
Evaluation workbench
返答の良し悪しを、レビュー可能な3軸へ分解する
Customer request
オンラインで買ったイヤホン、音が途切れます。週末のライブまでにどうにかしたいです。ギフトレシートしかなく、プリンタもありません。どう進めればいいですか?
ここで作るのは正解文ではなく、あとからプロンプトやモデルの変更を比較するための評価面です。
Axis
見る場所
良い状態
失敗モード
01
見る場所
制約を拾えているか
良い状態
週末までに必要、ギフトレシート、プリンタなしという条件に触れている
失敗モード
一般論だけで終わると、実際には手続きできない
02
見る場所
次の行動が明確か
良い状態
注文番号、シリアル、動画、QRラベルなど、必要な入力が具体的
失敗モード
丁寧でも、読者が次に何をすればいいか迷う
03
見る場所
リスクを閉じているか
良い状態
交換、返金、別モデルなど、失敗時の逃げ道がある
失敗モード
一見よく見えても、例外時にサポートコストが増える
Report briefing
評価から始めるAIエンジニアリングの入口
『AI Engineering』の論点を、評価、モデル適応、技術選択の順に実装者向けへ並べ替えるための入口です。LLMプロダクトを作る前に、何を測り、どの順番で改善するかを見える形にします。
- Updated
- 2026.01.19
- Scope
- AI Engineering, evaluation design, LLM product practice
3
入口の論点
評価、モデル適応、AIエンジニアの役割に絞る
5
適応段階
Prompt、RAG、Workflow、Agent、Fine-tuningを順番で見る
10
書籍章
544ページを実装者が読む順番に並べ替える
1st
評価ファースト
改善より先に、良し悪しの物差しを置く
Topline findings
Evaluate
01
出力を測る
返信品質を雰囲気ではなく、制約、次の行動、リスクで分解する。
Adapt
02
足りない部分を補う
プロンプトで足りない時に、RAGやワークフローへ進む判断を置く。
Choose
03
技術を選ぶ
困りごと、制約、避けたい罠を同じ表で見て、最初の一手を決める。
AI engineering report
評価、適応、技術選択を一枚の実務キャンバスにする
『AI Engineering』を読むだけで終わらせず、LLMプロダクトを作る時に最初に置くべき評価軸、モデル適応の順番、避けたい技術選択を同じ画面で確認するためのページです。
Article readout
3
入口の論点
評価、モデル適応、AIエンジニアの役割に絞る
5
適応段階
Prompt、RAG、Workflow、Agent、Fine-tuningを順番で見る
10
書籍章
544ページを実装者が読む順番に並べ替える
1st
評価ファースト
改善より先に、良し悪しの物差しを置く
Evaluate
出力を測る
返信品質を雰囲気ではなく、制約、次の行動、リスクで分解する。
Adapt
足りない部分を補う
プロンプトで足りない時に、RAGやワークフローへ進む判断を置く。
Choose
技術を選ぶ
困りごと、制約、避けたい罠を同じ表で見て、最初の一手を決める。
Ship
本番へ近づける
サポートシステムの段階設計で、複雑化の順番を読み違えない。
Reading checks
Axis
評価軸が先にある
プロンプトやモデル変更の前に、改善を測る基準が画面上にある。
Order
複雑化の順番が見える
いきなりエージェントやFTへ飛ばず、必要な段階を踏める。
Boundary
AI/MLの境界が分かる
APIの上で担う仕事と、モデル側の仕事を混同しない。
Practice
明日使える判断表がある
読後に、自分のプロダクトへ持ち帰るチェックリストが残る。
Reader takeaways
評価ルーブリック
LLMの回答品質をレビューする最初の物差し。
適応マップ
プロンプトからファインチューニングまでの段階設計。
技術選択表
課題別に最初に試す技術と避けたい進め方。
Section 01
なぜ今、AIエンジニアリングなのか
API化された基盤モデルによって、AIタスクは研究開発の長期計画から、アプリケーション開発の反復サイクルへ移った。
544ページ。
Chip Huyenの原稿を翻訳しながら、何度も「これは実装中に欲しかった」と思った。 LLMを使ったプロダクト開発では、性能そのものよりも、出力の揺れをどう扱うかで詰まることが多い。
2023年6月、Latent Spaceが「The Rise of the AI Engineer」を発表した。 基盤モデルのAPI化により、従来5年かかっていたAIタスクが「APIドキュメントと午後の数時間」で実現可能になった。
複雑なエージェントやファインチューニングの前に、シンプルなAPIコールで十分に価値あるプロダクトを生み出せる時代。 AIエンジニアリングとは何か、どう始めるか、そして何を避けるべきかを整理する。
O'Reilly Japan
AIエンジニアリング
544ページ・全10章。この記事では、実装者が先に読む順番に並べ替える。
544
pages
最初に読む
評価、評価実装、RAG/エージェント。プロダクトに効く順に読む。
Chapter 3
評価方法論
pp. 99-156
評価なくして改善なし。評価駆動開発が鍵
Chapter 4
AIシステムを評価する
pp. 157-210
自動評価と人間評価を組み合わせた多層的アプローチ
Chapter 6
RAGとエージェント
pp. 269-342
RAGは知識補強、エージェントは自律性。用途で使い分け
基礎を補う
基盤モデル、LLMの性質、プロンプトの型を押さえる。
Chapter 1
AIエンジニアリング入門
pp. 1-42
モデル開発よりモデル適応に重点を置く新しいパラダイム
Chapter 2
基盤モデルを理解する
pp. 43-98
モデルの内部動作を理解することでより良いプロンプトが書ける
Chapter 5
プロンプトエンジニアリング
pp. 211-268
プロンプトは最もコスパの良いモデル適応手法
必要になったら読む
ファインチューニング、データ、推論最適化、本番設計。
Chapter 7
ファインチューニング
pp. 343-398
FTは最後の手段。まずプロンプトとRAGを試す
Chapter 8
データセットエンジニアリング
pp. 399-442
AIの性能はデータの質で決まる
Chapter 9
推論の最適化
pp. 443-486
適切なモデル選択とキャッシュで10倍のコスト削減も可能
Chapter 10
AIアプリケーション設計
pp. 487-544
AIは確率的。ガードレールとモニタリングが必須
01
開発の入口
基盤モデル以前は、データ収集・訓練・チューニングが入口だった。いまはAPIで仮説を早く形にできる。
02
仕事の境界
モデルを作る仕事と、モデルをプロダクトに適応させる仕事が分かれた。
03
改善の順番
LLMの出力は揺れる。改善の前に、良し悪しを測る物差しが必要になる。
Time to first useful demo
短くなったのは、最初に動くものを出すまでの時間
基盤モデルのAPI化で、入口は大きく短くなりました。ただし、本番に残る難しさは別の場所へ移っています。
Read this as
AIエンジニアリングは、速く作る技術ではなく、速く出したものを評価可能なプロダクトへ戻す技術。
5年
モデルを作る
データ収集、訓練、評価基盤、推論環境までそろえてからプロダクトへ進む。
数時間
モデルを呼ぶ
API、SDK、プロンプトで最初の価値をすぐ画面に出せる。
継続
品質を担保する
出力の揺れ、失敗時の戻し方、評価、コスト、権限はアプリケーション側に残る。
この変化により、機械学習エンジニアとフルスタックエンジニアの間に位置する新しい職種「AIエンジニア」が誕生する。 ここで重要なのは職種名そのものより、アプリケーション側でモデルを適応し、評価し続ける仕事が増えたことです。
2023年6月
Latent Space「The Rise of the AI Engineer」
AIエンジニアという職種の提唱。「5年→数時間」という開発期間の変化を示した。
2024年
TypeScript勢、本格参入
Vercel AI SDK、LangChain.jsなどにより、フロントエンド開発者もAIアプリケーションを作り始める。
2025年初頭
Anthropic「Building Effective Agents」
複雑な自律エージェントへ急がず、まずシンプルな構成から始める流れが明確になる。
2025年11月
『AIエンジニアリング』日本語版出版
544ページの教科書が日本語で読めるようになる。翻訳者として発売前に読み込んだ。
Section 02
AIエンジニアリングとは何か
モデルを作る仕事ではなく、基盤モデルをプロダクトへ適応し、出力を評価し、運用できる形へ近づける仕事として見る。
書籍『AIエンジニアリング』では、AIエンジニアリングを 「基盤モデルをベースにアプリケーションを構築するプロセス」と定義している。 モデル開発そのものよりも、モデルの適応と評価に重点を置く点がMLエンジニアリングと異なる。
ML時代 vs AI時代
モデルの扱い
- Before
- 独自モデルを訓練
- After
- 学習済みモデルを利用
重点
- Before
- モデル開発(訓練・最適化)
- After
- モデル適応(プロンプト/RAG/FT)
出力の性質
- Before
- クローズドエンド
- After
- オープンエンド(正解が無数)
インフラ課題
- Before
- GPU・クラスター
- After
- 効率的な推論最適化
| Item | Before | After |
|---|---|---|
| モデルの扱い | 独自モデルを訓練 | 学習済みモデルを利用 |
| 重点 | モデル開発(訓練・最適化) | モデル適応(プロンプト/RAG/FT) |
| 出力の性質 | クローズドエンド | オープンエンド(正解が無数) |
| インフラ課題 | GPU・クラスター | 効率的な推論最適化 |
AIエンジニアとMLエンジニアの違い
端的にまとめると、「APIを叩いてAIをプロダクトに組み込む人」がAIエンジニア。 Model-as-a-Serviceの登場を背景に、私は「APIライン」という概念で説明したい。
API Line
APIの上
AIエンジニア
プロンプト、RAG、ワークフロー、評価、プロダクト統合
モデルの非決定性を運用で扱う
API境界
Model-as-a-Service
OpenAI、Anthropic、Googleなどの基盤モデルAPI
コスト、レイテンシ、モデル依存
APIの下
MLエンジニア
モデル訓練、推論基盤、GPU最適化、データパイプライン
専門性とインフラ投資が重い
Section 03
何から始めるか
最初に作るべきものは、完成形の複雑なシステムではない。まず動くデモを作り、足りない部分だけを段階的に補う。
AIエンジニアリングの成功は、最も洗練されたシステムを構築することではなく、ニーズに最適なシステムを構築することにある。
まずデモを作る
MLエンジニアリングは「データ収集→モデル訓練→プロダクト化」という順序だが、AIエンジニアリングは逆。「まずデモを作り、迅速にイテレーションを回す」。 アイデアを素早くデモの形にし、フィードバックを得てイテレーションを回せることが基盤モデルの強みです。
プロンプトエンジニアリングのテクニック
- 明確で直接的な指示
- 例の提供(Few-Shot)
- 思考過程の可視化(CoT)
- タグによる構造化
- ロール設定
- 出力のプリフィル
- 予告(Precognition)
プロンプトの「次」を知る
シンプルなプロンプトで価値が出せたら、次のステップ。 AIエンジニアには、プロンプトで足りない部分を RAG、ワークフロー、エージェント、ファインチューニングといったモデル適応技術で補う判断が必要になる。
Adaptation ladder
複雑化は、問題の種類が要求したときだけ進める
プロンプト、RAG、ワークフロー、エージェント、ファインチューニングは優劣ではなく段階です。上へ行くほど自由度は増えますが、評価・運用・コストの責任も増えます。
プロンプト
シンプルな指示で始める
明確で直接的な指示、Few-Shot例、Chain-of-Thought、タグによる構造化など。モデルの重みを更新せずに適応させる第一歩。
RAG
外部知識の検索・参照
Retrieval-Augmented Generation。社内ドキュメントやFAQなど、モデルが知らない情報を検索して補完。コンテキスト検索でメタデータを追加し精度向上。
ワークフロー
順序立てられたステップ
プロンプトチェーン、ルーティング、並列化、オーケストレーター・ワーカー。事前に定義された順序で実行し、予測可能な結果を得る。
エージェント
自律的な判断と実行
オープンエンドな問題で柔軟性が必要な場合。AIが状況に応じて判断・実行し、動的にツールを選択する。複雑だが強力。
ファインチューニング
モデルの重み更新
特定タスクに特化した最適化。1→Nの改善領域。コストと複雑さが増すため、他の手法で不十分な場合の選択肢。MLエンジニアの領域に近い。
Highest operational cost
技術を並べるだけでは、判断にはならない。 大事なのは、いま困っていることを特定し、制約に合わせて最初の一手を決めることだ。
Triage board
「何を足すか」ではなく「何が詰まっているか」から選ぶ
技術名から選ぶと過剰設計になりやすい。まず失敗の形を言葉にして、最小の追加で解く。
詰まり
最初の一手
先に見るもの
避けること
詰まり
必要な情報が足りない
最初の一手
RAG
先に見るもの
検索対象、更新頻度、回答根拠の表示
避けること
知識不足をファインチューニングで解こうとする
詰まり
回答品質が安定しない
最初の一手
評価セット + Few-Shot
先に見るもの
良い回答の例、悪い回答の例、判定基準
避けること
長いシステムプロンプトを足し続ける
詰まり
手順が複数ある
最初の一手
ワークフロー
先に見るもの
分岐条件、各ステップの入出力、失敗時の戻し方
避けること
最初から自律エージェントに任せる
詰まり
状況に応じて判断させたい
最初の一手
ルーティング + ガードレール
先に見るもの
人間確認が必要な条件、権限、ログ
避けること
完全自律を前提に設計する
ワークフロー vs エージェント
使用場面
- Before
- 明確に順序立てられたステップ
- After
- オープンエンドで柔軟性が必要
実装パターン
- Before
- チェーン、ルーティング、並列化
- After
- 自律プランニング、動的ツール選択
処理フロー
- Before
- 事前定義の順序
- After
- AIが状況判断
予測可能性
- Before
- 高い
- After
- 低い(だが強力)
| Item | Before | After |
|---|---|---|
| 使用場面 | 明確に順序立てられたステップ | オープンエンドで柔軟性が必要 |
| 実装パターン | チェーン、ルーティング、並列化 | 自律プランニング、動的ツール選択 |
| 処理フロー | 事前定義の順序 | AIが状況判断 |
| 予測可能性 | 高い | 低い(だが強力) |
顧客サポートシステムを段階的に広げる
典型的なユースケースである顧客サポートを例に、段階的に複雑化させる方法を見る。 最初から大きく作らず、必要になった時点で広げることがポイントです。
Support system expansion
機能追加ではなく、確認できた失敗にだけ層を足す
01
シンプルなプロンプト
最小構成
FAQ + システムプロンプトのみ。基盤モデルの能力をそのまま活用。まずはここから始めて、どこまで価値が出せるか検証する。
first validation
最初に検証する場所。
02
インテント分類(ルーティング)
振り分けの追加
ユーザーの意図を判定して、適切なソリューション(FAQ回答、担当チームへの転送など)へ振り分ける。
info
LLMで分類 or ルールベース、どちらが適切か評価して選択
03
RAGの追加
知識の拡張
顧客DB検索で最新の顧客情報や対応状況を反映。過去の対応履歴や製品マニュアルも検索対象に。
warning
チャンクサイズ、埋め込みモデル、リランキングなど調整ポイントが多い
04
エスカレーション
人間との協働
AIでは対応困難な問い合わせを人間のオペレーターへルーティング。確信度スコアや問題の深刻度で判定。
warning
エスカレーション基準の設計が品質を左右する
Section 04
評価する
評価は最後の品質確認ではなく、AIプロダクトの設計そのもの。測る基準がなければ、プロンプト変更もモデル変更も改善かどうか判断できない。
冒頭で体験してもらった通り、人間の評価にはブレがある。 同じ回答でも、見る順番や気分で判断が変わる。 評価駆動開発という言葉に表されるように、AIエンジニアリングは評価に始まり評価に終わる。
“evals are surprisingly often all you need”
評価さえあれば、驚くほどそれだけで十分なことが多い
— Greg Brockman, OpenAI共同創業者(2023年12月)
翻訳者の本音:正直に言うと、翻訳していて最も「これは重要だ」と感じたのがこの評価の章だった。プロンプトを書く前に、まず評価基準を決める。この順序が逆だと、永遠に「なんとなく良くなった気がする」ループから抜け出せない。
Evaluation stack
評価は1種類ではなく、安い順に重ねる
コードで弾けるものを先に弾き、LLM-as-a-Judgeで品質を広く見て、人間評価はベンチマークとサンプリングに使う。
コードベース評価
ルールで自動判定
正規表現やJSONスキーマで機械的にチェック。決定的で再現性が高い。
使いどころ
フォーマットチェック、禁止ワード検出、長さ制限
利点: 速い(ミリ秒) / 安い(ほぼ無料) / 再現性100%
注意: 複雑なニュアンスは判定できない / ルール設計が必要
LLM-as-a-Judge
AIがAIを評価
別のLLM(GPT-4など)に評価させる。スケールしやすく、柔軟。
使いどころ
回答の質、トーン、正確性の評価
利点: スケール可能 / 複雑な判断に対応 / 人間の評価に近い
注意: コストがかかる / 評価にもブレがある / バイアスの可能性
人間による評価
最も正確だが高コスト
人間が直接評価。ニュアンスや文脈を理解できる。ゴールドスタンダード。
使いどころ
最終品質確認、ベンチマーク作成、エッジケース
利点: 最高精度 / ニュアンス理解 / 新しい問題も対応
注意: 遅い / 高い / スケールしない / 人間にもブレがある
Section 05
よくある誤解
AIエンジニアリングを難しく見せているのは、技術そのものより、最初に選びがちな近道のほうかもしれない。
AIの世界では、同じ課題にも複数の解き方がある。 だからこそ、最初に選びがちな誤った近道を避けたい。
避けるべきパターン
最初から複雑にしすぎる
- Before
- FT/フレームワーク先行
- After
- シンプルなプロンプトから
- Change
- リスク↓
初期の成功を過信する
- Before
- 80%で満足
- After
- 95%まで継続改善
- Change
- LinkedInは4ヶ月
評価を軽視する
- Before
- 感覚的に良し悪し
- After
- 体系的な評価FW
- Change
- 品質安定化
AIを常に使う
- Before
- 全てにAI適用
- After
- 適切なツール選択
- Change
- コスト最適化
| Item | Before | After | Change |
|---|---|---|---|
| 最初から複雑にしすぎる | FT/フレームワーク先行 | シンプルなプロンプトから | リスク↓ |
| 初期の成功を過信する | 80%で満足 | 95%まで継続改善 | LinkedInは4ヶ月 |
| 評価を軽視する | 感覚的に良し悪し | 体系的な評価FW | 品質安定化 |
| AIを常に使う | 全てにAI適用 | 適切なツール選択 | コスト最適化 |
Takeaway
評価、シンプルさ、モデル適応
AIエンジニアリングは、LLMの非決定性を工学で受け止め、プロダクトの要件へ合わせて評価し続ける仕事として見ると分かりやすい。
1
評価ファースト
品質確保の評価FW構築
2
シンプルに始める
段階的に複雑化
3
モデル適応に重点
訓練より適応
ML・機械学習の知識やベストプラクティスの多くは、基盤モデルを前提としたAIエンジニアリングでも色褪せない先人の知恵。 同時に、プロンプトインジェクションやオープンエンドでの評価、他社モデル依存といった生成AI/LLMならではの課題も生まれている。
AIエンジニアリングは、AI/LLMの持つ非決定性や確率的な振る舞いを工学によって制御し、 プロダクトの要件を理解し、AIを組み合わせ、高速にアプリケーションを作り、 粘り強く評価する、という「AI時代のソフトウェアエンジニアリング」そのもの。
Translated work
共訳した本:『AIエンジニアリング』
Chip Huyen『AIエンジニアリング』の日本語版を共訳しました。 この記事は、その翻訳作業を通じて考えたことをもとにしています。 評価から読むなら3章、実装の見取り図を掴むなら6章が入口になります。