AIエンジニアリング、始めませんか？ ～基盤モデルという巨人の肩に乗って～
初めまして、kagayaです。
共訳した「AIエンジニアリング（オライリー・ジャパン）」が2025年11月28日に発売します。
今回は書籍のタイトルでもある、AIエンジニアリングについてです。
基盤モデルのAPI化により、AIをプロダクトに組み込むスキルの需要が高まっています。
それが、書籍のテーマである「AIエンジニアリング」です。
後編（本編？）となる書籍の内容紹介記事は下記。
なぜ今、AIエンジニアリングなのか
2023年6月、有名AIポッドキャストのLatent Spaceが記事「The Rise of the AI Engineer」を発表しました。
生成AI/LLMの文脈で「AIエンジニアリング」、「AIエンジニア」のワードに初めて出会った記事です。[1]
この記事は、Foundation Models（基盤モデル）のAPI化により、従来5年かかっていたAIタスクが「APIドキュメントと午後の数時間」で実現可能になったという変化を指摘しています。
そして、この変化により機械学習エンジニアとフルスタックエンジニアの間に位置する新しい職種「AIエンジニア」が誕生すると主張しています。
- アプリケーションへのAIの組み込み・適応に特化した役割
- 従来のMLエンジニアとは異なるスキルセットが求められる
- 今後10年間で最も需要の高いエンジニアリング職になる可能性
2024年の1月頃、私自身もこの記事を引用して、AIエンジニアリングについてスライドを作成していました。
2025年の現在地
あれから2年が経ちました。MastraのようにTypeScriptでAIエージェント開発を行うエコシステムも発達し、AIプロダクトの開発に取り組む企業・人は着実に増えています。
しかし、まだまだ盛り上がってもいいはずだと感じます。
AnthropicのBuilding Effective Agentsに、現在のAIエンジニアリングを考える上で重要だと感じる一文があります。
however, optimizing single LLM calls with retrieval and in-context examples is usually enough.
しかし、通常は検索とインコンテキスト学習の例を用いて、個々のLLMの呼び出しを最適化するだけで十分です。
引用: https://www.anthropic.com/engineering/building-effective-agents
AIエージェント開発はもちろん素晴らしく、私自身も自律的にツールを選択・生成しながら特定の業務を担えるようなシステムを構築して、日々悪戦苦闘しつつも、楽しさを感じています。
しかし、複雑なAIエージェントやファインチューニングの前に、シンプルなAPIコールで十分に価値あるプロダクトを生み出せる時代に私たちはいると感じます。
重要なのは、AIエンジニアリングはエージェント開発だけでなく、もっと広いAIソフトウェアエンジニアリングのプロセスであるということです。
AIエンジニアリングとは何か
書籍、AIエンジニアリング（オライリー・ジャパン）では、AIエンジニアリングを 基盤モデルをベースにアプリケーションを構築するプロセス と定義した上で、モデル開発そのものよりもモデルの適応と評価に重点を置く点がMLエンジニアリングと異なると主張しています。
| 観点 | ML時代 | AI時代（生成AI） |
|---|---|---|
| モデルの扱い | 独自のモデルを訓練 | 学習済みモデルを利用 |
| 重点 | モデル開発（訓練・最適化） | モデル適応（プロンプト、RAG、FT等） |
| モデルの規模 | 中~大規模 | より大規模で計算負荷が高い |
| インフラの課題 | GPUやクラスターの扱い | 効率的な訓練と推論最適化 |
| 出力の性質 | クローズドエンドが多い（選択肢が限定） | オープンエンドが多い（可能な正解が無数） |
AIエンジニアとMLエンジニアとの違い
あえて端的にまとめると「APIを叩いてAIをプロダクトに組み込む人」がAIエンジニアです。
私自身は、Model-as-a-Serviceの登場を背景に、APIラインという概念で説明しています。
APIラインの下で、MLエンジニアはモデルの訓練と最適化に従事します。
一方、APIラインの上で主に活動するAIエンジニアはAPIを通じてモデルを活用し、プロダクトに組み込みます。
モデルの内部構造を知らなくても、API利用自体に支障はありません。
それよりも、APIをどう叩き、どう組み合わせ、どう製品に組み込むかというソフトウェアエンジニアリング技術が合わせて求められます。
| 職種 | 職務 |
|---|---|
| MLエンジニア（APIラインの下） | モデルを訓練する |
| AIエンジニア（APIラインの上） | APIでモデルを使う |
AIエンジニアに必要とされるのは、プロンプトエンジニアリング、RAGの実装、LLMオーケストレーション、評価フレームワークの構築といったアプリケーション開発・組み込みに寄ったスキルです。
数学的知識やPyTorchの専門性の要否は悩ましいラインです。
The Rise of the AI Engineerでは「私が挙げた優秀なAIエンジニアで、Andrew NgのCourseraコースに相当する学習をした者は一人もいない。PyTorchを知っている者もいない」と指摘し、従来のMLの知識が必須ではないことを強調しています。
ただし、AIエンジニアリングの著者Chip Huyenは、よりバランスの取れたスタンスを示します。
「機械学習の知識は依然として極めて有用です。利用できるツールの範囲を広げ、モデルが期待通りに機能しない場合のトラブルシューティングにも役立つからです」と述べています。
つまり、必須ではないが、あると確実に有利ということです。
何から始めるか？
AIエンジニアリングの成功は、最も洗練されたシステムを構築することではなく、ニーズに最適なシステムを構築することにあります。
では、具体的に何から始め、どう進めるべきでしょうか。
まず、撃つ (Fire, Ready, Aim)
MLエンジニアリングは「データ収集→モデル訓練→プロダクト化」という順序でした。
しかしAIエンジニアリングは逆です。
「まずデモを作り、迅速にイテレーションを回す」
基盤モデルのModel-as-a-Serviceの強みは、アイデアを素早くデモの形にし、フィードバックを得てイテレーションを回せることにあります。
前述の通り、Anthropicは「多くのアプリケーションでは、検索とコンテキスト内サンプルを用いた単一のLLM呼び出しの最適化で十分」と述べています。
この単一の呼び出しの質を高めるための第一の選択肢が、プロンプトエンジニアリングです。
プロンプトエンジニアリングは、モデルの重みを更新せずにモデルを適応させる手法です。
モデル自体に変更を加える代わりに、指示やコンテキストを与えることで、望ましい応答を引き出します。
- 明確で直接的な指示
- 例の提供（Few-Shot）
- 思考過程の可視化（Chain-of-Thought）
- タグによる構造化
- ロール設定
- 出力のプリフィル（書き出しの指定）
- 予告（Precognition）
まずはこの技術を駆使し、シンプルなプロンプトでどこまで価値を出せるかを試すことがスタート地点となるでしょう。
プロンプトの「次」を知る
シンプルなプロンプトで価値が出せたら、次のステップです。
AIエンジニアの腕の見せ所は、プロンプトで足りない部分を、RAG、ワークフロー、エージェント、ファインチューニングといったモデル適応技術（最近ではコンテキストエンジニアリングと呼ばれるものも含む）で、アプリケーションに適合させることです。
現実のAIプロダクトの少なくない割合は、複雑なエージェントではなく明確に順序立てられたステップです。
そのためワークフロー or エージェントの判断・使い分けが、多くの現場で求められているかもしれません。
| 特性 | ワークフロー | エージェント |
|---|---|---|
| 使用場面 | 明確に順序立てられたステップがある場合 | オープンエンドな問題で柔軟性が必要な場合 |
| 実装パターン | プロンプトチェーン、ルーティング、並列化、オーケストレーター・ワーカー | 自律的なプランニング、動的なツール選択 |
| 処理フロー | 事前に定義された順序で実行 | AI が状況に応じて判断・実行 |
RAGも奥が深い世界です。
例えば、「コンテキスト検索」というアプローチでは、文書をただ分割（チャンク）することで失われがちな文脈を保持するために、各チャンクにLLMを使ってコンテキスト情報（メタデータ）を追加します。
- 従来: 「売上高は3%成長した」
- 改善後: 「このチャンクはAcme Corp.の2023年Q2財務報告からの抜粋である。同社は企業セグメントで3四半期連続の成長を報告した。売上高は3%成長した」
このように「AIに食わせるデータ」を整備・加工し、適切なワークフローを設計するノウハウも、AIエンジニアの腕の見せ所です。
評価する (Evaluation)
評価は、AIエンジニアリングにおける最も困難な課題の1つと言っても過言ではありません。本書では2つの章（第3章と第4章）を割いて、さまざまな評価手法と、それらを用いて信頼性が高く体系的な評価パイプラインをアプリケーション用に作成する方法を探求します。
― 『AIエンジニアリング』まえがき
評価駆動開発という言葉に表されるように、AIエンジニアリングは評価に始まり評価に終わります。
「なんとなく良い」という感覚的な開発では、プロダクトの品質は安定しません。
AIの出力は非決定的（毎回同じとは限らない）であり、同時にLLMの出力には唯一の絶対的な正解が存在しないことが多いためです。
また、単に最新で最強のモデルを選ぶのではなく、実際にあなたのタスクで機能するかどうかを測定することが重要です。
モデルの能力の高さと、実際のユースケースでの有用性は必ずしも一致しません。
例え有用であっても、実際のアプリケーションに組み込む上では、オーバースペックなモデルの選定はコスト・レイテンシー側面ではマイナスになる可能性があります。
OpenAIの共同創業者Greg Brockmanは、2023年12月に「evals are surprisingly often all you need（驚くほど多くの場合、評価こそが必要なすべてだ）」とポストしました。
オライリーから「Evals for AI Engineers」を出版予定のHamel Husainも、「失敗するAI製品はほぼ必ず共通の根本原因を持つ：堅牢な評価システムの構築の失敗である。ソフトウェアエンジニアリングと同様、AIの成功は反復の速さにかかっている」と強調します。
AIエンジニアリングも一度作って終わりではなく、粘り強い評価と改善のループです。
イテレーションを支えるには、品質（回答がソースに忠実かなど）はもちろん、安全性とトーン（ブランドイメージを毀損しないか）、フォーマット（JSONなどで正しく出力されているか）、さらにはコストとレイテンシーまで、多角的な評価軸で出力を評価します。
その手法も多様で、コードで明確に判定できる「コードベース評価」から、LLMに判断・採点させる「LLMによる評価 (LLM-as-a-Judge/AI-as-a-Judge)」、そして自動評価では測れないニュアンスを判断する最終的な砦「人間による評価」まで、戦略的に組み合わせる必要があります。
品質を左右する重要なエンジニアリングであり、専用のツールも次々と登場している、非常にホットな領域です。
シンプルに始めよう
もしAIエンジニアリングが難しそうだと感じているなら、それは以下のような誤解が原因かもしれません。
誤解1： ファインチューニングが最強
多くのケースでは、新たな知識を補強するRAGの方が求められており、かつ安価です。
ファインチューニングは手段の一つであり、特にAIエンジニアの場合は第一選択ではないことの方が多いです。
書籍では、ファインチューニングを「1からNへの最適化」領域として位置づけており、むしろMLエンジニアの得意分野と見なしています。
誤解2： 複雑な自律エージェントが必要
世の中のAIプロダクトのほとんどは、複雑なエージェントではなく、明確に順序立てられたステップ（＝ワークフロー）です。
Anthropicも、まずはシンプルなプロンプトチェーンやルーティングから始めることを推奨しています。
誤解3： AIは魔法の杖である
AIエンジニアは、ここはAIが不要と判断する（＝従来のコードで書く）スキルも持っています。
AIを組み込むべきかどうか、その判断こそが最初の問いです。
よくある失敗パターンを避けるために、いつの時代も意識すべきはシンプルに始めることです。
| パターン | 問題点 | アプローチ |
|---|---|---|
| 最初から複雑にしすぎる | ファインチューニングやフレームワークは第一選択ではない | シンプルなプロンプトから始める |
| 初期の成功を過信する | LinkedInは80%→95%に4ヶ月かかった | 継続的な改善を前提に計画 |
| 評価を軽視する | 良し悪しを判断するのに評価基準・サンプルが必要 | 体系的な評価フレームワークを構築 |
| 生成AIを万能ツールと考える | すべての問題がAIを必要とするわけではない | 適切なツールの選択 |
典型的なユースケースである顧客サポートシステムのケースを考えてみましょう。
段階的に複雑化させることで、必要に応じて進化させることができます。
- Step 1: シンプルなプロンプト
- FAQ + システムプロンプト
- Step 2: インテント分類（ルーティング）
- ユーザーの意図を判定して適切なソリューションへ振り分け
- Step 3: RAGの追加
- 顧客DB検索で最新の顧客情報や対応状況を反映
- Step 4: エスカレーション
- 人間のオペレーターへのルーティング判定
まとめ
書籍「AIエンジニアリング（オライリー・ジャパン）」で強調されているのは、次の3つです。
- 評価ファースト：AIの出力品質を確保するための評価フレームワーク構築
- シンプルに始める：シンプルなアーキテクチャから段階的に複雑化させる
- モデル適応に重点：モデル開発ではなく、既存モデルの適応（プロンプト、RAG、ファインチューニング）
ML・機械学習の知識やベストプラクティスの多くは、基盤モデル（かつ、Model as a Serviceの利用）を前提としたAIエンジニアリングでも色褪せない先人の知恵です。
プロンプトインジェクションやオープンエンド・自社固有ドメインでの評価、他社モデル依存や新たなコスト/構造への対応を代表に、生成AI/LLMならではの課題も生まれており、それらに対処するのもAIエンジニアリングの一つです。
しかし、より本質的には、AIエンジニアリングは、AI/LLMの持つ非決定性や確率的な振る舞いを工学（エンジニアリング）によって制御し、プロダクトの要件を理解し、AIを組み合わせ、高速にアプリケーションを作り、粘り強く評価する、という「AI時代のソフトウェアエンジニアリング」そのものです。
（従来のソフトウェアエンジニアリングとの差分もまた面白いポイントです）
ぜひAIエンジニアリングに挑戦してみませんか？
今回は以上です！
宣伝
-
当時、Latent Spaceの記事は新たなAIエンジニアリングの定義を主張する言説として広く引用されました ↩︎
Discussion