こんにちは。虎の穴ラボのT.Hです。 オライリー・ジャパン様より出版の「AIエンジニアリング」を読了しましたので、内容をご紹介したいと思います。

書籍情報

項目	内容
著者	Chip Huyen
翻訳	加賀谷 諒、菅野 憲也
発行所	オライリー・ジャパン
発行日	2025/11/28
ISBN	978-4-8144-0138-3
ページ数	544ページ
価格	6,380円(税込)

www.oreilly.co.jp

こんな人にオススメ

• AIアプリケーションを本番環境で運用しようとしているエンジニア : プロンプトエンジニアリングの先にある、RAG・評価・アーキテクチャといった本番運用に必要な知識を体系的に学べます
• 「AIの性能改善」の引き出しを増やしたい方 : 性能が足りないときにプロンプト調整以外にどんな手段があるのか（チャンキング戦略、リランキング、ファインチューニングなど）を網羅的に把握できます
• AI導入の費用対効果を説明する立場にある方 : 評価駆動開発の考え方やビジネス指標との紐づけ方など、「AIプロジェクトをどう評価・正当化するか」のフレームワークが得られます

きっかけ

日々AIをアプリ開発のエージェントとして活用していますが、今後自分でAIを組み込んだアプリケーションそのものを設計するという目線を持ったとき、様々な面で知識不足を痛感したためです。 たとえば、プロンプトエンジニアリングを施しても「本当に性能が良くなったのか？」を評価する客観的な指標を持てていなかったり、性能が足りないときにそれを補う手段を体系的に把握できていなかったり、といった課題を感じていました。 そのため、まずは自分の手札を増やしてより良い設計判断ができるようになりたいと考え、本書を手に取りました。 個人では少し躊躇する価格帯ですが、弊社にはスキルアップ支援制度という書籍購入などに際して一定額を補助いただける仕組みがあり、今回ありがたく利用いたしました。

どんな本か

本書は、基盤モデルを用いたアプリケーション開発の全体像を網羅的に学べる一冊です。 全10章の構成ですが、私は大きく以下の4つのパートと捉えています。

• 1〜2章 : LLMの基礎
• 3〜4章 : 評価の手法
• 5〜9章 : 性能を向上させる方法（RAG、エージェント、ファインチューニングなど）
• 10章 : AIを組み込んだアプリケーションのアーキテクチャ例

大きな特徴として、特定のライブラリやツールの使い方ではなく、抽象的な概念のレイヤーで「なぜその仕組みが必要なのか」を語る構成になっている点が挙げられます。そのため、移り変わりの早いAI分野であっても長く使える知識が得られます。 また、モジュール形式になっているため、興味のある章だけをピックアップして読むこともできます。

ただし専門用語は頻出するため、普段からAI関連の情報を収集していたり、エージェントを用いたアプリ開発の経験があったりと、AI開発の基礎がわかっていることが前提になっている印象です。 自分で作った経験があればなお良く、「自分に不足している知識（評価手法や運用アーキテクチャなど）を補完する」のに最適な一冊だと感じました。

そのため本記事では、「AIシステムの評価」「RAGとエージェントの設計」という、より実務に直結する示唆に富んだ2つのテーマに絞って所感を共有します。

本書で学んだこと

1. 「AIシステムの評価」でテスト・検証の仕方を学ぶ（第4章より）

第4章では、「なんとなく以前より回答が良くなった気がする」という定性的な評価から脱却し、AIシステムを定量的・継続的に評価するためのアプローチが解説されています。

評価駆動開発という考え方

本書では、システムを構築する前に「このシステムをどう評価するか？」を定義する「評価駆動開発」というアプローチを提唱しています。 テスト駆動開発からインスパイアされた考え方であり、事前に評価の軸を定めることで開発リソースが無駄になることを防ぎます。

評価すべき4つのカテゴリ

AIアプリケーションを適切に評価するには、複数の観点から複合的に見る必要があります。

• ドメイン固有の能力 : 翻訳アプリなら語学力、コーディングAIなら正確性や実行速度など
• 生成能力 : 流暢さや一貫性に加え、事実整合性（ハルシネーションの有無）と安全性が現代ではとくに重視される
• 指示追従能力 :「必ずJSON形式で出力して」といった指示に対し、余計なテキストを付け足さずに指定のフォーマットを厳密に守れるかを評価する
• コストとレイテンシー : 出力が正確でも、実行に時間がかかりすぎたりAPIコストが高すぎたりすれば実用性がないため、この観点も不可欠

評価パイプラインの設計

AIアプリの成功の鍵は、評価を自動化・仕組み化する「評価パイプライン」の構築にあります。

とくに重要だと感じたのは以下の点です。

• コンポーネント単位で分離して評価する : 最終的な「ユーザーへの返答」だけでなく、途中の「RAGの検索結果」や「ツールの出力」など、システムを分解して個別に評価する
• 技術指標とビジネス効果を結びつける :「事実整合性が90%になれば、カスタマーサポートの50%を自動化できる」のように、技術的な評価指標とビジネス目標を直接紐づける
• AI as a Judge : 評価自体を別のLLMに任せる手法。セマンティック類似度（文章の単語が違っても意味がどれくらい近いかをベクトル空間上で計算する手法）を活用し、人手では限界のある評価を自動化する

4章でもっとも学びが深かったのは、2つ目の「技術指標とビジネス目標を結びつける」考え方です。チューニングのリソース配分が明確になるのはもちろんですが、この定量的な指標を定義してビジネス上の成果に紐づけるプロセスは、誰もが定期的に悩むことになる人事評価における目標設定のブレイクダウンと同じ脳の使い方だと感じました。

2. 「RAGとエージェント」で構築のベストプラクティスを学ぶ（第6章より）

第6章では、単純なLLMの呼び出しを超えて、外部知識を活用するRAGや自律的にタスクをこなすエージェントの具体的な構築手法が解説されています。

RAGの必要性は今後も続く

「LLMのコンテキスト長が伸びればRAGは不要になるのでは？」という意見もありますが、本書ではRAGの重要性は今後も続くと結論付けています。どれだけコンテキスト長が伸びても、それ以上の情報を要するユースケースは生まれますし、長いコンテキストをLLMがうまく利用できるとは限らず、レイテンシやコストも悪化するため、という根拠からです。 確かに時間とお金が潤沢にある場合は高級なLLMで解決できますが、必ずしもそうでない場合に対応する局所解として求められるケースはあると考えます。

検索の仕組み：ハイブリッド検索という現実解

RAGシステムは「リトリーバー（検索器）」と「ジェネレーター（生成モデル）」の2つで構成されます。リトリーバーはユーザーの質問に対して関連資料を検索してくる図書館の司書のような存在で、RAGの品質はこのリトリーバーの賢さに大きく依存します。

検索の手法としては、高速・軽量な「タームベース検索（キーワード検索）」と、テキストの意味をベクトルに変換して類似度で検索する「埋め込みベース検索（セマンティック検索）」があります。 それぞれ一長一短があるため、両者を組み合わせる「ハイブリッド検索」が現実的な最適解として紹介されていました。

最新のベクトル検索さえ使えば万能というわけではなく、昔ながらのキーワード検索と掛け合わせるのがベストプラクティスになり得るというのは、非常に実務的な知見でした。

検索精度を高める4つのアプローチ

検索精度を上げるために、本書では以下の4つのアプローチが紹介されています。

• チャンキング戦略 : 文書を分割する際に前後で一部を重複させる「オーバーラップ」がよく使われるが、最適なサイズに普遍的な正解はなく、実データに基づくチューニングが必要
• リランキング : 安価な検索で粗く候補を取得し、絞り込まれた結果にのみ精度の高い手法でスコアを再計算する2段階アプローチ
• クエリ書き換え : ユーザーの曖昧なクエリを、LLMで検索システムが処理しやすい具体的なキーワード群に変換する手法
• コンテキスト検索 : チャンク分割で失われる「全体の概要」をメタデータとして各チャンクに付与しておく工夫

AIアプリケーション開発というと「賢いモデルに任せればOK」と思いがちですが、実際にはモデルに渡す情報の質をいかに高めるかという泥臭い設計こそが成果を左右するのだと、本章を通じて実感しました。

エージェントの自律行動を支える「プランニング」と「リフレクション」

第6章の後半では、人間に代わって自律的にタスクをこなす「エージェント」の仕組みが解説されています。

エージェントに与えるツールは「知識拡張（RAGやWeb検索）」「能力拡張（計算機やPython実行）」「書き込みアクション（DB更新やカレンダー登録）」の3カテゴリに分類されます。とくに書き込みアクションは現実世界への副作用を伴うため、AIに与える権限を最小限に絞るセキュリティ制御が非常に重要です。

複雑なタスクを成功させるためには、「プラン」と「実行」のフェーズを明確に分け、その合間にリフレクション（自己批判）を挟むことが推奨されています。「①プラン生成 → ②計画の評価 → ③実行 → ④結果の評価」という4ステージ構成にすることで、タスクの成功率が飛躍的に高まるとのことです。

個人的にもっとも興味深かったのは、コラム的に紹介されていた「モデルごとにツールの使い方に癖がある」という研究結果です。ログを見ながらツールの使い方を調整していく作業は、まさにエンジニアリングそのものだと感じました。

エージェントの失敗パターンを定量的に評価する

エージェントが複雑なタスクを行うほど失敗ポイントも増えます。本書では失敗を「プランニングの失敗」「ツールの失敗」「効率性の問題」にパターン分類し、定量的に評価・改善する手法が解説されています。

プランニングの失敗に対しては、「有効なプランを得るために平均いくつのプランを生成する必要があるか」「無効なツールを呼び出す頻度はどのくらいか」といった指標を定量的に測定することが推奨されています。効率性の面でも、単に「成功したか」だけでなく「完了までのステップ数」「コスト」「ボトルネックとなるアクション」を計測し、ボトルネック部分を専用の軽量な関数に置き換えるといった改善策が紹介されていました。

ここで興味深いのは、特定分野での失敗が多い場合の改善策として「専門家（人間）がそのタスクをどう解いているか観察する」というアプローチが挙げられていた点です。RAGの検索精度の話でも感じましたが、最先端のAIを改善するために人間を観察するという、一周回ってアナログな手法が有効というのは意外でした。

「記憶」のアーキテクチャ

AIアプリケーションが進化するにつれ、セッションを跨いで情報を保持する「記憶」の重要性が増しています。本書では記憶を「内部知識（モデルの事前学習データ）」「短期記憶（対話履歴）」「長期記憶（外部DB）」の3つに分類しています。

一番学びになったのは、長期記憶を持たせる理由として「回答のパーソナライズ」だけでなく「データ構造の完全性の維持」が挙げられていた点です。LLMの出力は本質的にはテキストなので、構造の保証は外部DBのスキーマに任せるという割り切りは、AI固有の弱点をインフラ設計でカバーする実践的な考え方だと感じました。

第6章全体を通しての所感

本章を通して得た気づきは2つあります。1つは、RAGは「リトリーバーというツールを持ったエージェント」とみなせるという視点です。RAGとエージェントを別物として捉えていましたが、同じ設計原則の上にあると理解することで見通しがよくなりました。もう1つは、自動化を進めるほど権限制御やHITL（Human-in-the-Loop）といった「防御メカニズム」の設計が重要になるという点です。便利にするほどブレーキの設計が求められるというバランス感覚は、AIに限らずシステム設計全般に通じる教訓だと感じました。

まとめ

本書を読む前は、プロンプトエンジニアリングの効果を客観的に測る手段も、性能が足りないときの引き出しも不足していました。本書を通じて「まず評価の軸を定める」という開発プロセスと、RAG・エージェント設計における具体的な改善手法を学んだことで、当初の課題に対する手札が大きく増えた実感があります。 AIアプリケーション開発で壁にぶつかったときに立ち戻るためのバイブルとして、手元に置いておきたい一冊です。

採用情報

虎の穴ラボでは一緒に働く仲間を募集中です！ この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧ください。 toranoana-lab.co.jp