ENGINEERING2026.01.1912 min

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

Chip Huyen『AI Engineering』を読みながら、評価、モデル適応、技術選択の順に実装者向けの論点を整理する。

Before we begin

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

評価の入口

AIの返答は、雰囲気ではなく評価軸に分解して見る。

Customer

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

01

制約を拾えているか

週末までに必要、ギフトレシート、プリンタなしという条件に触れている

一般論だけで終わると、実際には手続きできない

02

次の行動が明確か

注文番号、シリアル、動画、QRラベルなど、必要な入力が具体的

丁寧でも、読者が次に何をすればいいか迷う

03

リスクを閉じているか

交換、返金、別モデルなど、失敗時の逃げ道がある

一見よく見えても、例外時にサポートコストが増える

評価軸を先に置くと、プロンプト変更やモデル変更の良し悪しを後から比較できる。 ここが曖昧なまま改善すると、品質ではなく好みを追いかけることになる。

評価軸があると、改善の順番が見える

AI engineering artifact

評価、適応、技術選択を一枚の実務キャンバスにする

『AI Engineering』を読むだけで終わらせず、LLMプロダクトを作る時に最初に置くべき評価軸、モデル適応の順番、避けたい技術選択を同じ画面で確認するためのページです。

Artifact readout

3

入口の論点

評価、モデル適応、AIエンジニアの役割に絞る

5

適応段階

Prompt、RAG、Workflow、Agent、Fine-tuningを順番で見る

10

書籍章

544ページを実装者が読む順番に並べ替える

1st

評価ファースト

改善より先に、良し悪しの物差しを置く

Evaluate

出力を測る

返信品質を雰囲気ではなく、制約、次の行動、リスクで分解する。

Adapt

足りない部分を補う

プロンプトで足りない時に、RAGやワークフローへ進む判断を置く。

Choose

技術を選ぶ

困りごと、制約、避けたい罠を同じ表で見て、最初の一手を決める。

Ship

本番へ近づける

サポートシステムの段階設計で、複雑化の順番を読み違えない。

Quality checks

Axis

評価軸が先にある

プロンプトやモデル変更の前に、改善を測る基準が画面上にある。

Order

複雑化の順番が見える

いきなりエージェントやFTへ飛ばず、必要な段階を踏める。

Boundary

AI/MLの境界が分かる

APIの上で担う仕事と、モデル側の仕事を混同しない。

Practice

明日使える判断表がある

読後に、自分のプロダクトへ持ち帰るチェックリストが残る。

What this page returns

評価ルーブリック

LLMの回答品質をレビューする最初の物差し。

適応マップ

プロンプトからファインチューニングまでの段階設計。

技術選択表

課題別に最初に試す技術と避けたい進め方。

544ページ。

Chip Huyenの原稿を翻訳しながら、何度も「これは実装中に欲しかった」と思った。 LLMを使ったプロダクト開発に日々取り組んでいると、性能そのものよりも、出力の揺れをどう扱うかで詰まることが多い。 さっきの実験で感じた「ブレ」は、そのままAIエンジニアリングの入口になる。

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

2023年6月、Latent Spaceが「The Rise of the AI Engineer」を発表した。 基盤モデルのAPI化により、従来5年かかっていたAIタスクが「APIドキュメントと午後の数時間」で実現可能になった。 この変化が、新しい職種「AIエンジニア」を生み出している。

複雑なエージェントやファインチューニングの前に、シンプルなAPIコールで十分に価値あるプロダクトを生み出せる時代。 AIエンジニアリングとは何か、どう始めるか、そして何を避けるべきかを整理する。

CH

About the Author

Chip Huyen

ベトナムの小さな村で育ち、スタンフォード大学でMLコースを創設・教鞭をとった実践者。 NVIDIA、Netflix、Snorkel AIでMLツール開発を経験し、AI基盤スタートアップを創業・売却。 前著『Designing Machine Learning Systems』はAmazon #1ベストセラー、10言語以上に翻訳。

「MLエンジニアと、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は確率的。ガードレールとモニタリングが必須

3つの論点

3つの論点を、あとから参照しやすい形で並べる。

01

5年数時間

開発の入口

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

02

MLAI

仕事の境界

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

03

作る測る

改善の順番

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

Part 1

なぜ今、AIエンジニアリングなのか

基盤モデル以前 → 以後

5年

データ収集・モデル訓練

数時間

APIドキュメントとプロンプト

始めるまでの時間は短くなった。
ただし、本番品質にするには評価と運用設計が残る。

この変化により、機械学習エンジニアとフルスタックエンジニアの間に位置する新しい職種「AIエンジニア」が誕生する。 アプリケーションへのAI組み込み・適応に特化し、今後10年間で最も需要の高いエンジニアリング職になる可能性がある。

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」

「複雑なエージェント?いや、単一のLLM呼び出しで十分なことが多い」。シンプルさへの回帰。

2025年11月

『AIエンジニアリング』日本語版出版

544ページの教科書が日本語で読めるようになる。翻訳者として発売前に読み込んだ。

Part 2

AIエンジニアリングとは何か

書籍『AIエンジニアリング』では、AIエンジニアリングを 「基盤モデルをベースにアプリケーションを構築するプロセス」と定義している。 モデル開発そのものよりも、モデルの適応と評価に重点を置く点がMLエンジニアリングと異なる。

ML時代 vs AI時代

ItemBeforeAfter
モデルの扱い独自モデルを訓練学習済みモデルを利用
重点モデル開発(訓練・最適化)モデル適応(プロンプト/RAG/FT)
出力の性質クローズドエンドオープンエンド(正解が無数)
インフラ課題GPU・クラスター効率的な推論最適化

では、AIエンジニアとは具体的に何をする人なのか

Section

AIエンジニアとMLエンジニアの違い

端的にまとめると、「APIを叩いてAIをプロダクトに組み込む人」がAIエンジニア。 Model-as-a-Serviceの登場を背景に、私は「APIライン」という概念で説明したい。 これはAIエンジニアにとっての「境界線」のようなものだ。 API側で働くか、モデル側で働くかで、必要なスキルセットがかなり違う。

API Line

APIの上

AIエンジニア

プロンプト、RAG、ワークフロー、評価、プロダクト統合

モデルの非決定性を運用で扱う

API境界

Model-as-a-Service

OpenAI、Anthropic、Googleなどの基盤モデルAPI

コスト、レイテンシ、モデル依存

APIの下

MLエンジニア

モデル訓練、推論基盤、GPU最適化、データパイプライン

専門性とインフラ投資が重い

Part 3

何から始めるか

AIエンジニアリングの成功は、最も洗練されたシステムを構築することではなく、ニーズに最適なシステムを構築することにある。

まずデモを作る

MLエンジニアリングは「データ収集→モデル訓練→プロダクト化」という順序だが、AIエンジニアリングは逆。「まずデモを作り、迅速にイテレーションを回す」。 私はこれを「AIプロトタイピングの逆転」と呼んでいる。 昔は「データがないと何も始まらない」だったのが、今は「まず動くものを見せてからデータを集める」。 アイデアを素早くデモの形にし、フィードバックを得てイテレーションを回せることが基盤モデルの強み。

プロンプトエンジニアリングのテクニック

  • • 明確で直接的な指示
  • • 例の提供(Few-Shot)
  • • 思考過程の可視化(CoT)
  • • タグによる構造化
  • • ロール設定
  • • 出力のプリフィル
  • • 予告(Precognition)

プロンプトの「次」を知る

シンプルなプロンプトで価値が出せたら、次のステップ。 AIエンジニアには、プロンプトで足りない部分を 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エンジニアの領域に近い。

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

技術選択の見取り図

必要な情報が足りない

RAG

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

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

回答品質が安定しない

評価セット + Few-Shot

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

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

手順が複数ある

ワークフロー

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

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

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

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

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

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

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

ItemBeforeAfter
使用場面明確に順序立てられたステップオープンエンドで柔軟性が必要
実装パターンチェーン、ルーティング、並列化自律プランニング、動的ツール選択
処理フロー事前定義の順序AIが状況判断
予測可能性高い低い(だが強力)

では、具体的な例で段階的な複雑化を見てみよう

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

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

顧客サポートの段階設計

01

シンプルなプロンプト

最小構成

FAQ + システムプロンプトのみ。基盤モデルの能力をそのまま活用。まずはここから始めて、どこまで価値が出せるか検証する。

最初に検証する場所。

02

インテント分類(ルーティング)

振り分けの追加

ユーザーの意図を判定して、適切なソリューション(FAQ回答、担当チームへの転送など)へ振り分ける。

LLMで分類 or ルールベース、どちらが適切か評価して選択

03

RAGの追加

知識の拡張

顧客DB検索で最新の顧客情報や対応状況を反映。過去の対応履歴や製品マニュアルも検索対象に。

チャンクサイズ、埋め込みモデル、リランキングなど調整ポイントが多い

04

エスカレーション

人間との協働

AIでは対応困難な問い合わせを人間のオペレーターへルーティング。確信度スコアや問題の深刻度で判定。

エスカレーション基準の設計が品質を左右する

Part 4

評価する (Evaluation)

冒頭で体験してもらった通り、人間の評価にはブレがある。 同じ回答でも、見る順番や気分で判断が変わる。 「評価は、AIエンジニアリングにおける最も困難な課題の1つ」(『AIエンジニアリング』まえがき)。 評価駆動開発という言葉に表されるように、AIエンジニアリングは評価に始まり評価に終わる

“evals are surprisingly often all you need”

評価さえあれば、驚くほどそれだけで十分なことが多い

— Greg Brockman, OpenAI共同創業者(2023年12月)

この一言は、AIエンジニアリングでまず考えるべき順番をよく表している。 複雑なアーキテクチャや最新のテクニックよりも、 まず「良し悪しを測る物差し」を手に入れること。 それがあれば、改善の方向性は自ずと見えてくる。

翻訳者の本音:正直に言うと、翻訳していて最も「これは重要だ」と感じたのがこの評価の章だった。 評価の話は地味に見えるかもしれない。でも、ここを読んで「なるほど、これがないとAIプロダクトは運ゲーになる」と腑に落ちた。プロンプトを書く前に、まず評価基準を決める。この順序が逆だと、永遠に「なんとなく良くなった気がする」ループから抜け出せない。

AIの出力は非決定的(毎回同じとは限らない)であり、 LLMの出力には唯一の絶対的な正解が存在しないことが多い。 「なんとなく良い」という感覚的な開発では、プロダクトの品質は安定しない。

評価手法の組み合わせ

01

コードベース評価

ルールで自動判定

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

使いどころ:フォーマットチェック、禁止ワード検出、長さ制限

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

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

02

LLM-as-a-Judge

AIがAIを評価

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

使いどころ:回答の質、トーン、正確性の評価

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

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

03

人間による評価

最も正確だが高コスト

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

使いどころ:最終品質確認、ベンチマーク作成、エッジケース

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

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

実務では、コードで弾けるものを先に弾き、LLM-as-a-Judgeで品質を広く見て、人間評価はベンチマークとサンプリングに使う。

Part 5

よくある誤解

もしAIエンジニアリングが難しそうだと感じているなら、以下のような誤解が原因かもしれない。 AIの世界では、同じ課題にも複数の解き方がある。 だからこそ、最初に選びがちな誤った近道を避けたい。

避けるべきパターン

ItemBeforeAfterChange
最初から複雑にしすぎるFT/フレームワーク先行シンプルなプロンプトからリスク↓
初期の成功を過信する80%で満足95%まで継続改善LinkedInは4ヶ月
評価を軽視する感覚的に良し悪し体系的な評価FW品質安定化
AIを常に使う全てにAI適用適切なツール選択コスト最適化

Conclusion

まとめ

書籍『AIエンジニアリング』で強調されているのは、次の3つ。

1

評価ファースト

品質確保の評価FW構築

2

シンプルに始める

段階的に複雑化

3

モデル適応に重点

訓練より適応

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

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

Translated work

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

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

Share

この記事を保存する

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

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