AIエンジニアリングのご紹介 / Introduction to AI Engineering

2025/12/03開催、翻訳者に聞く！『AIエンジニアリング ―基盤モデルを用いたAIアプリケーション開発の基礎と実践』の登壇資料です。
https://findy.connpass.com/event/375088/

Transcript

1. AIエンジニアリングのご紹介 基盤モデルを用いたAIアプリケーション開発の基礎と実践 2025年12月3日 Asterminds株式会社 r.kagaya 翻訳者に聞く！『AIエンジニアリング ―基盤モデルを用いたAIアプリケーション開発の基礎と実践』
2. 2022年に株式会社ログラスに入社 経営管理SaaSの開発、開発生産性向上に取り組んだのち、 生成AI/LLMチームを立ち上げ、新規AIプロダクトの立ち 上げに従事 その後、独立・現職 Asterminds（アスターマインズ）株式会社 共同創業者・CTO r.kagaya(@ry0_kaga) 自己紹介
3. 今日の目的 下記を知って頂くこと • AIエンジニアリングとは何か？ • AIエンジニアリング（書籍）から何が得られるか？ 用語の定義や内容は、書籍内の記述に合わせています
4. AIエンジニアリングとは？ 

5. AIエンジニアリングと聞いて、 思い浮かべるものは？
6. プロンプトエンジニアリング？RAG？ AIエージェント開発？ モデル訓練？ファインチューニング？
7. 書籍、AIエンジニアリングの定義では
8. 基盤モデルを用いて アプリケーションを構築すること AIエンジニアリング is
9. AIエンジニアリングとは何で、何から生まれた？ AI利用の民主化がもたらした新しいエンジニアリング分野 AIアプリケーション開発のハードルの低下による環境の変化が勃興の要因 基盤モデルの登場 汎用的にタスクを解ける基盤モデルの登場 In-Context Learningで、モデル自体の変更はなしに、モデルの振 る舞いを変更することが可能 Model as a Service 一部の専門組織が開発した巨大なAIモデルを、APIを通じて誰もが サービスとして利用できるようになった「Model as a Service」
10. 過去の記憶・思い出 AI（MLという方が適切か）をアプリケーションに組み込むことのハードルが今よ り高かった時代が確かにあった 前々職で、不正検知・アクセスをブロックするMLモデルの開発・組み込みには、一 年ががりで総額◯億円の投資になると言われた 数値の妥当性はさておき、当時よりAIアプリ・AI機能の開発のハードルが下がっ たことは間違えない
11. AIエンジニアリングでは何が変わる？ 必ずしもモデル作成が起点でなくなったが故のサイクルや活動領域の変化 プロダクトファースト モデル構築から適応へ 評価の固有度の増加 今はモデル開発自体は行わ ずとも、先にAIアプリケー ショ開発が行える モデルの適応（アプリケー ション要件にモデルの振る舞 いを調整する）の必要性の高 まり アプリケーション固有・オー プンエンドな出力を前提とす る機会が増加。評価の独自度 も高めることに
13. モデルを「作る」から、「使いこなす」へ
14. モデルを「作る」から、使いこなすへ AIエンジニアリングの主戦場は、モデルの使いこなし（モデルの学習・訓練も残る） 基盤モデルの登場により、「モデルを一から作る」から「既存の高性能モデルを適 応・評価する」ニーズが増加
15. AIエンジニアリングはなにを行うのか？
16. 「動くデモ」を作るのは簡単になった。 しかし、 「使い続けられるプロダクト」 にするのは依然として難しい。
17. AIエンジニアリング ≠ プロンプトエンジニアリング プロンプトエンジニアリングは氷山の一角。考えることはたくさん
18. AIエンジニアリング ≠ プロンプトエンジニアリング 特に中心になるのはモデル適応技術と評価 モデル適応 評価 汎用的な基盤モデルを特定のアプリケー ションに”適応”させる ・コンテキストの制御 (Prompt/Context Engineering) ・知識と行動の拡張(RAG & Agents) ・モデルの専門化(Fine-tuning) 汎用的に賢いモデルを、いかに特定のア プリケーション要件に適合させるか 「確率的で非決定的な振る舞い」を、許容 できる品質、安全性、トーン、専門性の担 保まで確認するプロセス
19. 汎用モデルを適応させる AIエンジニアリングでは、3つの主要な適応技術で、汎用的な基盤モデルを 特定のアプリケーションに特化させる 最近で言うところの、コンテキストエンジニアリングもカバー範囲
20. 全ての土台となる評価 信頼できる評価軸があるからこその体系的な改善 「この修正で本当にシステムは良くなったか？」に自信を持って答えるためには？ Vibe Check（雰囲気での確認）には限界がある なぜ難しいのか？ オープンエンドな出力は正解が一つに収斂しないため AIエンジニアリングの世界においては、オープンエンドな出力の利用が 増える。 なぜ重要なのか？ 評価パイプライン・基準がなければ、開発は単なる「手探りの試行錯誤」 に陥る可能性
21. 全ての土台となる評価 信頼できる評価軸があるからこその体系的な改善 「この修正で本当にシステムは良くなったか？」に自信を持って答えるためには？ Vibe Check（雰囲気での確認）には限界がある なぜ難しいのか？ オープンエンドな出力は正解が一つに収斂しないため AIエンジニアリングの世界においては、オープンエンドな出力の利用が 増える。 なぜ重要なのか？ 評価パイプライン・基準がなければ、開発は単なる「手探りの試行錯誤」 に陥る可能性 クローズエンドなタスクに落とせな いか？の観点
 ワークフロー分割にも通ずる

22. 評価の主体（誰が、または何が評価を行うか）の分類 最近は、「AIに評価させる」ことがアプローチの一つとして浸透してきている どれか単独ではなく、評価主体と手法の組み合わせ では、どうやって評価するのか？
23. 評価駆動開発（Eval Driven Development） AIアプリケーションを作る前に、評価基準とデータセットを用意する TDDを通して、システムの設計に向き合うように、EDDを通して、評価基準と データセットに最初から向き合うことで、自アプリケーションでの要求もクリアに なる
24. 作って終わりではない、フライホイールを回す 最も価値あるデータは、ユーザーの入力そのもの ユーザーからのフィードバックや利用データを、次の評価セットにどう還元し、アプ リケーションを継続的に改善していくか？（複数chで論じている）
25. 他にもたくさん..！
26. AIエンジニアリング（書籍）が 
 回答してくれること 

27. こんな経験・疑問ありませんか？
28. • RAG、エージェント、ファインチューニング、結局今の自社に はどれが最適？ • 自社アプリケーション向けの評価ってどう始めたら良い？ • TemperatureやTop-p、なんとなく0.7に設定していま せんか？ • ユーザーフィードバックをどう改善に繋げればいい？
29. AIエンジニアリング（書籍）のアピール 基盤モデルを用いたアプリケーション開発の「教科書」を目指した一冊 • 著者は、NVIDIAやSnorkel AIでの実務経験、 スタンフォード大学で機械学習システムデザインを教える • 前著『機械学習システムデザイン』はAI分野のベストセラー となり、世界10言語以上に翻訳 • AIエンジニアリングは25年の出版以来、 オライリー学習プラットフォームで「最も読まれている本」
30. AIエンジニアリング（書籍）が回答する現場の悩み プロンプトでこねくり回すだけで、何とかなる？
31. AIエンジニアリング（書籍）が回答する現場の悩み RAGの性能を上げるためには？
32. AIエンジニアリング（書籍）が回答する現場の悩み Agentで完全自動化の未来が来た？
33. AIエンジニアリング（書籍）が回答する現場の悩み AIアプリケーションのシステムアーキテクチャはどう育てる？
34. AIエンジニアリング（書籍）の全体像 AIエンジニアリングという体系的なアプローチを広く概観 基盤モデルの理解から、システムアーキテクチャまで抑えているのが最大の特徴
35. まとめ

36. AIエンジニアリング 書籍でも強調されている、AIエンジニアリングの3つの原則
37. まとめ • AIアプリケーションの開発は、プロンプトを書いて終わりではなく、AIエンジ ニアリングという体系的なアプローチが必要 • 原則は、評価ファースト、シンプルに始める、モデル適応に重点 • RAG/Agentなどの確率的なシステムを機能させる鍵は、評価 ・Evaluationにある、「なんとなく良さそう」を卒業する • 良いプロンプト・RAG/Agent・FTの前に良いデータ • ツールは変わるが、原則は（比較的長く）残る
38. 書籍リンク Amazon オライリー（EBook)
39. おわり