「AIエンジニアリング」 を読んでいる
11/28 にオライリーから発売された「AIエンジニアリング」をこの週末に読んでいます。4章まで読みました。全10章なので、まだ折り返し地点にも到達していませんが、4章の時点でもかなり学びが多かったので、学んだことのメモや感想を共有したいと思います。
なぜこの本を買ったか?
最近、仕事で既存のサービスにLLMの機能を取り込んだりする要望が増え、AIアプリを開発する機会が増えてきたからです。
このことについては、以下の記事にも書きましたので参照ください。
今のところの感想
この本、かなり分厚く(全514ページ)お値段もかなり高い(¥6380)ので、買うときはかなり躊躇しましたが、実際にAIアプリ開発の仕事で役立つ情報が山盛りだったので費用対効果を考えれば安いのかもしれないと思い購入に踏み切りました。結果は今のところ大満足です。
本の構成
この本は、AI アプリケーションをつくる流れに沿って章が並んでおり、最初から順に読んでいくと「AI の仕組みをどう使うか」が自然と分かるようになっています。
特定のモデルや特定のツールに依存する情報ではなく、AIアプリ開発の知識のベース部分を体系的に学びたい人向けの書籍です。
ただ、全10章、514ページという大ボリュームなので、1ページ目からじっくり全部読み切るのには時間がかかりすぎるので、とりあえずざっと全体に目を通して、自分の興味のある章を重点的に読むやり方で僕は読み進めています。
知ってる内容や興味ない分野は飛ばしまくりです
1〜2章：そもそも AI を使うべき？ そこからスタート
最初の章では、いきなり技術に入るのではなく、
「本当に AI が必要なの？」
「自分で作るべき？」
といった 根本的なところから著者が一緒に考えてくれています。
そのうえで、基盤モデル(LLM)ってどんなことができるのか、身近な例を交えて紹介。
2章ではもう少し踏み込んで、モデルの中身、データの扱い方、訓練の考え方など、“AI がどんな仕組みで動いているか” を理解するための話が続きます。
(知ってる内容が多かったのでこの辺はさらっと読み飛ばしました)
3〜4章：AI 開発でもっとも大変な「評価」
アプリを作り始めると、必ず必要になるのが 「評価」 です。
モデルがちゃんと動いているのか、どこが改善すべきか特定するのは、これが実はかなり難しい。
この本では 3、4 章を使って、いろいろな評価方法を紹介しつつ、どうやって安定した評価プロセスを作れるのかを丁寧に説明しています。
個人的には最も興味をもったのがこの３，４章です。
モデルの質を決める 3 つのポイント
AI の回答の良し悪しは、ざっくり言うと次の3つで決まります。
- モデルへの指示（プロンプト）
- モデルが使える情報（コンテキスト）
- モデルそのものの性能
5〜7章：モデルをもっと賢くするための工夫
(※ここから先の章はざっと目を通した)
5章：プロンプト設計（フロントエンド的な工夫）
「いいプロンプトって何？」
「どう調整すればモデルが思い通りに動く？」
そんな疑問に答える章。アプリの “前側” と “後ろ側” の両面から調整方法を紹介しているっぽい。
6章：コンテキストづくり（RAG とエージェント）
モデルに必要な情報をどう渡すか、という話。RAG や エージェントといった仕組みが登場します。RAG は安定、エージェントは挑戦的だけど強力、というイメージ。
7章：ファインチューニング（モデル自体を育てる）
大きな基盤モデルは扱いが大変なので、“小さなモデルをどう賢く育てるか” がポイント。メモリの使い方や、ファインチューニングのコツも説明されてるっぽい。
8章：データがすべての土台
AI はデータが命。
この章では、データの集め方、ラベル付け、合成、前処理など、データ品質を高めるための基本がまとめられています。
ファインチューニング以外にも役立つ内容があるみたい。
9章：推論をもっと速く、もっと安く
アプリとして動かすとき、スピードやコストは無視できません。
API を使うならある程度自動で最適化してくれますが、自前でモデルを動かすなら、ここで紹介されているテクニックが役立ちそう。
10章：全体をつなげてアプリとして完成させる
最後に、これまで学んできた内容をまとめて、どうやってアプリケーションとして仕上げていくのかが語られています。
評価駆動開発（Evaluation Driven Development）
書籍の中でも特に印象に残ったのが、「評価（Evaluations）」に焦点を当てた第3・4章でした。ここが、AIアプリを本当に成功へ導く核心部だと感じました。
AIアプリ開発で迷子にならないために
最近は、AIチャットアプリのような「作成が簡単」「すぐ動く」「そこそこ答えてくれる」アプリをSDKを使って簡単に作れるようになりました。
しかし、いざリリースの段階になると、
- これって本当に良い状態？
- どこまで仕上がれば「完成」と言えるの？
と迷うことが多くあります。
その理由は、AIアプリの動作には唯一の正解がないからです。出力は常に確率的です。
従来のソフトウェア開発のように「動く・動かない」で品質を測ることができません。
回答パターンは無数にあり、デグレしていても人間が気づけないことさえあります。
しかし AI アプリで本当に重要なのは
「ユーザーが期待通りに使えて、満足してくれるかどうか」 です。
そこで役立つのが 評価駆動開発（EDD: Evaluation Driven Development）
です。
AI as a Judge（AIがAIを評価する）
AI開発でよく使われる手法のひとつが AI as a Judge です。
これは、AIの出力をAI自身が評価する仕組みのことです。
なぜ必要なのか？
- 人間がすべての回答を評価するのはコストが高すぎる
- チェック対象が膨大でスケールしない
そのため AI に評価を任せることはほぼ必須です。
ただし弱点もある
- バイアスが入る可能性がある
- 評価が確率的で安定しないことがある
- 実際のユーザー感覚とズレることがある
このため、AIだけに任せきりにせず、人間レビューも混ぜた評価パイプラインを構築することが重要になります。
EDDは「まずゴールを決める」開発
EDDはひと言で言うと、
「成功基準を先に定義し、そこから逆算して作る開発プロセス」 です。
家を建てるとき、
「家族が快適に暮らせる、日当たりのいい家にしたい」
という理想を最初に決めるように、
AIアプリも、どんな状態になれば"成功"と言えるのか
を最初に決めることで、迷わずに品質の高い開発ができます。
イメージとしては、TDD（テスト駆動開発）のAI版と考えるとわかりやすいです。
評価指標とビジネス指標を結びつける
もうひとつ重要なのが、
AIの評価指標とビジネス指標をちゃんと紐づけることです。
AIの評価がどれだけ高くても、
- 売上が伸びない
- ユーザー満足度が低い
- 利用継続率が上がらない
という状態なら、評価基準がズレています。
つまり、
ビジネスの北極星（North Star Metric）と AIの評価基準をセットで定義する
ことが、AIアプリを成長させ続けるための鍵になります。
まとめ
- 「AIエンジニアリング」は、AIアプリ開発の体系的な知識を提供する良書
- AIアプリ開発のプロセスに沿って、基礎から応用までを網羅
- 特に3〜4章の「評価（Evals）」 に関する内容に注目
- 成功には、ユーザー満足度を基準とした「評価駆動開発（EDD）」 が不可欠
- AIの回答の質は、プロンプト、コンテキスト（RAGなど）、モデル性能の3点に依存
- 評価は人間だけではスケールしないため、AI自身が評価する「AI as a Judge」 が必要
- ただし、AI評価のリスクを考慮し、人間の評価も組み合わせてパイプラインを構築することが重要
- AI評価指標は、ビジネスの売上などのビジネス指標と結びつけて検証する必要がある。
- その他、プロンプト設計、RAG/エージェント、ファインチューニング、データ品質、推論最適化について解説している
参考
おまけ
「Patterns for Building AI Agents」を読むのもおすすめです。
以下の記事に「Patterns for Building AI Agents」を読んで、AIエージェント開発パターンをまとめてみました