ENGINEERINGAI engineering report

AIエンジニアリングの入口

Chip Huyen『AI Engineering』を、作る人の視点で読み直す。評価、モデル適応、技術選択の順に要点を整理する。

Article notes

Updated
2026.01.19
Read time
12 min
Channel
AIエンジニアリング
LLM、評価、設計、実装の話。手を動かす人のために書く。
Scope
AI Engineering / evaluation design / model adaptation / product practice
Status
Published article

Briefing

AIエンジニアリングは、評価から始める

派手なエージェントやファインチューニングではなく、まず出力の良し悪しを測る物差しを置く。この記事全体を、その順番を確認するレポートとして読む。

Before we begin

AIエンジニアリングの入口は、派手なエージェントではなく、出力をどう評価するかにある。

この記事では、翻訳しながら重要だと感じた論点を、評価、モデル適応、技術選択の順に絞って整理する。

Evaluation workbench

返答の良し悪しを、レビュー可能な3軸へ分解する

Customer request

オンラインで買ったイヤホン、音が途切れます。週末のライブまでにどうにかしたいです。ギフトレシートしかなく、プリンタもありません。どう進めればいいですか?

ここで作るのは正解文ではなく、あとからプロンプトやモデルの変更を比較するための評価面です。

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

5年数時間

開発の入口

基盤モデル以前は、データ収集・訓練・チューニングが入口だった。いまはAPIで仮説を早く形にできる。

02

MLAI

仕事の境界

モデルを作る仕事と、モデルをプロダクトに適応させる仕事が分かれた。

03

作る測る

改善の順番

LLMの出力は揺れる。改善の前に、良し悪しを測る物差しが必要になる。

Time to first useful demo

短くなったのは、最初に動くものを出すまでの時間

基盤モデルのAPI化で、入口は大きく短くなりました。ただし、本番に残る難しさは別の場所へ移っています。

Read this as

AIエンジニアリングは、速く作る技術ではなく、速く出したものを評価可能なプロダクトへ戻す技術。

Before

5年

モデルを作る

データ収集、訓練、評価基盤、推論環境までそろえてからプロダクトへ進む。

Now

数時間

モデルを呼ぶ

API、SDK、プロンプトで最初の価値をすぐ画面に出せる。

Still hard

継続

品質を担保する

出力の揺れ、失敗時の戻し方、評価、コスト、権限はアプリケーション側に残る。

この変化により、機械学習エンジニアとフルスタックエンジニアの間に位置する新しい職種「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
効率的な推論最適化
Section

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、ワークフロー、エージェント、ファインチューニングは優劣ではなく段階です。上へ行くほど自由度は増えますが、評価・運用・コストの責任も増えます。

01 / Prompt

プロンプト

シンプルな指示で始める

明確で直接的な指示、Few-Shot例、Chain-of-Thought、タグによる構造化など。モデルの重みを更新せずに適応させる第一歩。

02 / RAG

RAG

外部知識の検索・参照

Retrieval-Augmented Generation。社内ドキュメントやFAQなど、モデルが知らない情報を検索して補完。コンテキスト検索でメタデータを追加し精度向上。

03 / Workflow

ワークフロー

順序立てられたステップ

プロンプトチェーン、ルーティング、並列化、オーケストレーター・ワーカー。事前に定義された順序で実行し、予測可能な結果を得る。

04 / Agent

エージェント

自律的な判断と実行

オープンエンドな問題で柔軟性が必要な場合。AIが状況に応じて判断・実行し、動的にツールを選択する。複雑だが強力。

05 / Fine-tuning

ファインチューニング

モデルの重み更新

特定タスクに特化した最適化。1→Nの改善領域。コストと複雑さが増すため、他の手法で不十分な場合の選択肢。MLエンジニアの領域に近い。

Highest operational cost

技術を並べるだけでは、判断にはならない。 大事なのは、いま困っていることを特定し、制約に合わせて最初の一手を決めることだ。

Triage board

「何を足すか」ではなく「何が詰まっているか」から選ぶ

技術名から選ぶと過剰設計になりやすい。まず失敗の形を言葉にして、最小の追加で解く。

詰まり

必要な情報が足りない

最初の一手

RAG

先に見るもの

検索対象、更新頻度、回答根拠の表示

避けること

知識不足をファインチューニングで解こうとする

詰まり

回答品質が安定しない

最初の一手

評価セット + Few-Shot

先に見るもの

良い回答の例、悪い回答の例、判定基準

避けること

長いシステムプロンプトを足し続ける

詰まり

手順が複数ある

最初の一手

ワークフロー

先に見るもの

分岐条件、各ステップの入出力、失敗時の戻し方

避けること

最初から自律エージェントに任せる

詰まり

状況に応じて判断させたい

最初の一手

ルーティング + ガードレール

先に見るもの

人間確認が必要な条件、権限、ログ

避けること

完全自律を前提に設計する

ワークフロー vs エージェント

使用場面

Before
明確に順序立てられたステップ
After
オープンエンドで柔軟性が必要

実装パターン

Before
チェーン、ルーティング、並列化
After
自律プランニング、動的ツール選択

処理フロー

Before
事前定義の順序
After
AIが状況判断

予測可能性

Before
高い
After
低い(だが強力)

顧客サポートシステムを段階的に広げる

典型的なユースケースである顧客サポートを例に、段階的に複雑化させる方法を見る。 最初から大きく作らず、必要になった時点で広げることがポイントです。

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で品質を広く見て、人間評価はベンチマークとサンプリングに使う。

Layer 01

コードベース評価

ルールで自動判定

正規表現やJSONスキーマで機械的にチェック。決定的で再現性が高い。

使いどころ

フォーマットチェック、禁止ワード検出、長さ制限

利点: 速い(ミリ秒) / 安い(ほぼ無料) / 再現性100%

注意: 複雑なニュアンスは判定できない / ルール設計が必要

Layer 02

LLM-as-a-Judge

AIがAIを評価

別のLLM(GPT-4など)に評価させる。スケールしやすく、柔軟。

使いどころ

回答の質、トーン、正確性の評価

利点: スケール可能 / 複雑な判断に対応 / 人間の評価に近い

注意: コストがかかる / 評価にもブレがある / バイアスの可能性

Layer 03

人間による評価

最も正確だが高コスト

人間が直接評価。ニュアンスや文脈を理解できる。ゴールドスタンダード。

使いどころ

最終品質確認、ベンチマーク作成、エッジケース

利点: 最高精度 / ニュアンス理解 / 新しい問題も対応

注意: 遅い / 高い / スケールしない / 人間にもブレがある

Section 05

よくある誤解

AIエンジニアリングを難しく見せているのは、技術そのものより、最初に選びがちな近道のほうかもしれない。

AIの世界では、同じ課題にも複数の解き方がある。 だからこそ、最初に選びがちな誤った近道を避けたい。

避けるべきパターン

最初から複雑にしすぎる

Before
FT/フレームワーク先行
After
シンプルなプロンプトから
Change
リスク↓

初期の成功を過信する

Before
80%で満足
After
95%まで継続改善
Change
LinkedInは4ヶ月

評価を軽視する

Before
感覚的に良し悪し
After
体系的な評価FW
Change
品質安定化

AIを常に使う

Before
全てにAI適用
After
適切なツール選択
Change
コスト最適化

Takeaway

評価、シンプルさ、モデル適応

AIエンジニアリングは、LLMの非決定性を工学で受け止め、プロダクトの要件へ合わせて評価し続ける仕事として見ると分かりやすい。

1

評価ファースト

品質確保の評価FW構築

2

シンプルに始める

段階的に複雑化

3

モデル適応に重点

訓練より適応

ML・機械学習の知識やベストプラクティスの多くは、基盤モデルを前提としたAIエンジニアリングでも色褪せない先人の知恵。 同時に、プロンプトインジェクションやオープンエンドでの評価、他社モデル依存といった生成AI/LLMならではの課題も生まれている。

AIエンジニアリングは、AI/LLMの持つ非決定性や確率的な振る舞いを工学によって制御し、 プロダクトの要件を理解し、AIを組み合わせ、高速にアプリケーションを作り、 粘り強く評価する、という「AI時代のソフトウェアエンジニアリング」そのもの。

Translated work

共訳した本:『AIエンジニアリング』

Chip Huyen『AIエンジニアリング』の日本語版を共訳しました。 この記事は、その翻訳作業を通じて考えたことをもとにしています。 評価から読むなら3章、実装の見取り図を掴むなら6章が入口になります。

Sources

Latent Space

The Rise of the AI Engineer

latent.space/p/ai-engineer

Anthropic

Building Effective Agents

anthropic.com/engineering/building-effective-agents

O'Reilly Japan

AIエンジニアリング

oreilly.co.jp/books/9784814401383

X

Chip Huyen

x.com/chipro

Share

この記事を保存する

読み返すときのためにリンクをコピーできます。必要ならそのまま共有できます。

あとで読み返す用にリンクをコピー
AIエンジニアリングの入口 | rkagaya.post