AI Engineering

投稿日 July 16, 2026  •  1分で読めます  • 127文字  • 言語を選択:  한국어、English

1. この悩みに決着をつけに来た

近頃の開発トレンドの中で最もホットなキーワードといえば、やはりAIだろう。AIツールはすでに開発者にとって切っても切れない、ほぼ必須の存在になっている。私もClaudeの活用に慣れ、コーディングテストの練習、ブログのアイデア出し、サイドプロジェクトの計画など、あらゆる場面でAIを活用している。

そんな中、私はひょんなことからAIベースのチャットサービスを開発するスタートアップに入社することになった。自然な流れとして、バックエンドエンジニアリングを超えたAIエンジニアリングという新たな領域にも興味が湧き始めた。

1年以上にわたる転職活動の中で味わった数々の挫折感、そして近い将来AIがバックエンド開発職を代替してしまうかもしれないという不安感とともに、AIエンジニアリングを勉強してみたいという気持ちが自然と芽生えた。

2. この本に込められた内容

この本を学びながら整理した内容はすでに個人のGitHub Repository にまとめてある。そのため本ポストでは、各チャプターでどのような内容を学べるかを軽く紹介することにしたい。

Chapter 1. Introduction to Building AI Applications

AIエンジニアリングを扱う前にまず、言語モデルがどのように発展してきたかを説明してくれる。

初期の言語モデルは基本単位であるトークンをもとに、コンテキストの中でどの単語が現れるかを予測する方式で動作していた。その後自己教師あり学習（Self-supervised Learning）が可能になり、言語モデルはLLM（Large Language Model）へと拡張された。さらに言語の枠を超え、画像や動画などより多様なデータを処理し、まるで人間のように世界を認識・インタラクションできるモデルの研究が活発になり、マルチモーダルとともにさまざまなタスクをこなせるファウンデーションモデルが登場した。

AIとともに歩むようになり、アプリケーション開発が驚くほど容易になった。しかしそれだけに、より深く考えなければならない問題が「競争優位性」だ。技術力・データ・流通力のうち、どの部分で優位を取れるか？ファウンデーションモデルをベースにすれば多くの企業が似たような技術力を持つことになり、流通力では大企業が有利だ。したがってスタートアップなら、データを中心に戦略を立てることが有利だろう。

Chapter 2. Understanding Foundation Models

このチャプターでは、ファウンデーションモデルを自分で作る方法よりも、モデルを活用するために必要な基礎知識に焦点を当てている。

2014年にGoogleが発表したseq2seq（sequence to sequence） アーキテクチャは、機械翻訳の性能を大幅に向上させた。seq2seqはエンコーダとデコーダを**RNN（Recurrent Neural Network、再帰型ニューラルネットワーク）**で構成し、トークンを逐次処理するよう設計されていた。しかし逐次的な動作構造の特性上、品質低下や速度遅延の問題があった。

トランスフォーマーアーキテクチャはseq2seqの問題を解決した。アテンションメカニズムを通じて入力トークンの重要度に重みを与え、入力トークンを並列処理することで処理速度を大幅に向上させた。ただし出力は依然として逐次的に生成される。

モデルを理解する上で、事前学習を超えた事後学習の重要性を見落としてはならない。事後学習は不適切な応答をフィルタリングし、まるで人間のように応答を完成させることを可能にする。事後学習は一般的に2段階を経る。**指導ファインチューニング（Supervised Fine-Tuning、SFT）と選好ファインチューニング（Preference Fine-Tuning）**だ。

SFTは高品質な指示データでファインチューニングを行うプロセスであり、選好ファインチューニングは人間の好みを学習する方式で、**RLHF（Reinforcement Learning from Human Feedback）**のような強化学習によって実施される。

Chapter 3. Evaluation Methodology

ファウンデーションモデルは開放的な性質を持つため、性能評価に使える明確な正解がなく、ブラックボックスの出力結果だけを見なければならないため、評価が難しい。それでも、システムの脆弱性を把握してより堅牢にするために、評価の重要性を見落としてはならない。

ファウンデーションモデルの根幹は言語モデルであるため、言語モデリング指標を理解する必要がある。エントロピーはトークンにどれだけ多くの情報が含まれているかを示す。エントロピーが高いほど多くの情報を含み、エントロピーが低いほどモデルが次に来るものを予測しやすくなる。クロスエントロピーは言語モデルがデータセットの内容をどれだけ予測しにくいかを示す指標だ。またこの2つは**BPB（Bit Per Byte）**などの数値を通じて、テキストをオリジナル比でどれだけ圧縮できるかを確認する。パープレキシティはエントロピーとクロスエントロピーの指数関数であり、次のトークン予測の不確実性を表す。ここで不確実性が高いということは、次のトークンになり得る選択肢が多いということだ。

最近ではAIを使ってAIを評価するAI評価者の活用事例も増えている。人間ほど正確ではないが、開発の方向性を定めるには十分役立てられる。ただしAI評価基準がまだ標準化されていないため、偏りや基準の曖昧さに注意する必要がある。

Chapter 4. Evaluate AI Systems

アプリケーションのモデルを評価する基準には、ドメイン特化能力、生成能力、指示遵守能力、コスト、レイテンシなどがある。開発に先立って評価基準を明確にしなければならず、そこにはビジネス上の優先順位が反映されるべきだ。

モデルを選択するプロセスも重要だ。コストと性能のトレードオフに関する判断が必要であり、モデルを自社開発するか商用モデルのAPIを利用するかを決める必要がある。

一度きりの評価で終わらせず、評価パイプラインを設計してシステムの各構成要素を独立して評価すべきだ。評価指標をビジネス指標と結びつけ、どの指標を優先するかを決める必要がある。

Chapter 5. Prompt Engineering

プロンプトエンジニアリングは、ファインチューニングに比べると初心者でもできる簡単なものだという誤解を受けやすい。しかしプロンプトエンジニアリングはファインチューニングよりも少ないリソースで効率的なモデル調整を可能にする技法であるため、他のML技法と同様に厳密に行う価値がある。

プロンプトエンジニアリングにおいてまずショットの数を調整する必要がある。ショット数が多いほど豊富な例とともに推論結果の品質が向上する。しかしプロンプトが長くなり推論コストが増加する可能性があるため、実験を通じて適切なショット数を見つけていく必要がある。

プロンプトエンジニアリングのベストプラクティスには、十分なコンテキストの提供、タスク単位への分割、CoT（Chain of Thought）、プロンプトエンジニアリングツールの評価、プロンプトのバージョン管理などがある。

またプロンプト抽出、脱獄、プロンプトインジェクションなどのプロンプト攻撃に備える必要があり、そのためにはベンチマークやセキュリティチェック自動化ツールが有用だろう。

Chapter 6. RAG and Agents

モデルがコンテキストを構成する際に主に使用する2つの手法が、RAG（Retrieval-Augmented Generation）とエージェントだ。

RAGはモデルが外部ソースから関連情報を検索してコンテキストを構成できるようにする。TF-IDF、Elasticsearch、BM25などのキーワードベースの検索方式と、Vector DBのような埋め込みベースの検索方式を活用でき、通常この2つを組み合わせたハイブリッド方式で活用されることが多い。

エージェントはツールを通じて環境を認識し変化を与えることができる。これに関連したさまざまなエージェントパターンが存在するが、推論と行動を交互に行いながら自ら過程を評価・改善するReActパターンが一般的によく使われている。

Chapter 7. Finetuning

ファインチューニングはあるタスクでの学習方式を別のタスクでも適用する**転移学習（Transfer Learning、TL）**の一形態だ。何かを追加学習するというよりも、単にモデルの振る舞いを磨くことが理想的なファインチューニングだ。

しかし実際には、ファインチューニングを行う前にその必要性を慎重に検討する必要がある。ファインチューニングには相当な計算リソースが必要なだけでなく、MLに関する専門的な知識基盤も必要だ。事実や情報が不足しているならRAGの方が効率的であり、性能を高めたい場合もプロンプトだけで性能向上が可能なケースが多い。そのため、まずプロンプトを試してみてから、形式や安定性を強化する必要があるときにファインチューニングの導入を検討するのが望ましい。

ファインチューニングはメモリを多く消費する。そのため誤差逆伝播（Backpropagation）のようなニューラルネットワーク学習アルゴリズムや、メモリ使用量を削減する量子化技法が使われる。代表的なファインチューニング技法として、より少ないパラメータで部分的なファインチューニングを行いながらも、完全なファインチューニングに近い性能を達成できる**PEFT（Parameter-Efficient Fine-Tuning）がある。PEFT内にもさまざまな技法があり、代表的に有名なのがLoRA（Low-Rank Adaptation）**だ。

Chapter 8. Dataset Engineering

モデルの学習にはデータが必要だ。データセットを構築するためには、モデルが偏りや幻覚を起こさないよう高品質なデータを確保することが重要だ。

データは拡張や合成によっても生成できる。特に最近ではAIでデータを生成する事例も増えている。しかしAIでデータを生成する場合は、データ品質に格別の注意が必要だ。

また一方では、**モデル蒸留（model distillation）**を通じて小さいモデルが大きいモデルを模倣するよう学習させる方式もある。

Chapter 9. Inference Optimization

学習がモデルを作るプロセスだとすれば、推論はモデルに入力を与えて結果を得るプロセスだと言える。

推論最適化は計算ボトルネックを見つけて解決するプロセスだ。主なボトルネックには演算制約とメモリ帯域幅制約がある。モデルが入力トークンを並列処理するプリフィルは演算制約に該当し、モデルがトークン出力を一度に一つずつ生成するデコードはメモリ帯域幅制約に該当する。

推論最適化技法には、モデルサイズの圧縮、自己回帰デコードのボトルネック解消、アテンションメカニズムの最適化などがある。

Chapter 10. AI Engineering Architecture and User Feedback

AIアプリケーションを作る際は、最もシンプルなアーキテクチャから始めて段階的により多くの構成要素を追加していく方式が効率的だ。まずはユーザーがモデルAPIと直接通信する最もシンプルな構造から始め、以下のように段階的にアーキテクチャを拡張していく。

• ステップ1：コンテキストの拡充
• ステップ2：ガードレールの導入
• ステップ3：モデルルーターとゲートウェイの追加
• ステップ4：キャッシュの導入
• ステップ5：エージェントパターンの追加
• ステップ6：モニタリング環境の構築
• ステップ7：AIパイプラインのオーケストレーション

これらを盛り込んで完成するアーキテクチャの姿は、大まかにこのようになるだろう。

AIアプリケーションでは一般的なアプリケーションに比べてユーザーフィードバックがはるかに重要になる。したがってフィードバックを収集するタイミングや収集方法の設計が必要であり、偏りが生じ得るという限界点も明確に理解しておく必要がある。

3. 実戦投入、そしてこれからの方向性

上記にこの本の要約をできる限り簡潔にまとめてみた。しかしこれは実際のところ、核心的な概念を列挙したに過ぎない。本書で各概念をより深く掘り下げると理解しにくい部分が多かったため、その知識のギャップを埋めるために何かを作ってみなければならないと感じた。サイドプロジェクトを作ることで、今回の読書にしっかりと締めくくりをつけたい。

実は近頃、どうやってキャリアをさらに向上させるかについての悩みが増えている。AIを活用するようになってから、自分が製品の品質向上に貢献しているという実感が薄れてきたし、どんなことを勉強すれば有能な開発者になれるのかもなかなか見えなくなってきた。自分らしい個性のあるブログポストを書きたくても、AIが書いたものではないかと疑われることが怖くもある。そのため今後はサイドプロジェクトに集中してみようかと思っている。せっかくAIがこれほど発展したのだから、AI活用能力を最大化してインパクトのあるアウトプットを生み出せる開発者になりたいと思う。