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

翻訳しながら、何度も欲しかったと思った

Chip Huyen の『AIエンジニアリング』を共訳した。544ページある原稿を訳しながら、何度も「これは実装中に欲しかった」と思った。LLMを使ったプロダクト開発では、性能そのものより、出力の揺れをどう扱うかで詰まることが多いからだ。

この記事では、翻訳しながら重要だと感じた論点を、評価、モデル適応、技術選択の順に絞って整理する。AIエンジニアリングの入口は、出力をどう評価するかにあると思う。

何が短くなって、何が残ったのか

2023年6月、Latent Space が「The Rise of the AI Engineer」を発表した。基盤モデルがAPIで呼べるようになり、従来5年かかっていたAIタスクが「APIドキュメントと午後の数時間」で実現できるようになった、という話だ。

短くなったのは、最初に動くものを出すまでの時間だ。品質を担保する難しさは、なくなったわけではなく、アプリケーション側に残っている。

この変化で、機械学習エンジニアとフルスタックエンジニアの間に「AIエンジニア」という新しい職種が生まれた。大事なのは職種名より、アプリケーション側でモデルを適応し、評価し続ける仕事が増えたことの方だと思う。2025年初頭には Anthropic が「Building Effective Agents」を出し、複雑な自律エージェントへ急がず、シンプルな構成から始める流れもはっきりしてきた。

AIエンジニアは、APIの上で働く

書籍では、AIエンジニアリングを「基盤モデルをベースにアプリケーションを構築するプロセス」と定義している。MLエンジニアリングとの違いは、モデルを作ることより、モデルの適応と評価に重点を置くところにある。独自モデルを訓練していた頃は出力の正解が決まっていたが、いまのモデルの出力はオープンエンドで、正解が無数にある。

端的に言えば、APIを叩いてAIをプロダクトに組み込む人がAIエンジニアだ。私はこれを「APIライン」という言葉で説明したい。APIを境に、上で働くか下で働くかで、必要なスキルがまるで違う。

境界にあるのは、OpenAI、Anthropic、Google などが提供する基盤モデルのAPIだ。その下では、MLエンジニアがモデル訓練、推論基盤、GPU最適化、データパイプラインを担う。専門性とインフラ投資が重い仕事だ。その上で、AIエンジニアがプロンプト、RAG、ワークフロー、評価、プロダクトへの統合を担う。APIの上の仕事は、モデルの非決定性を運用で扱うことになる。コスト、レイテンシ、モデルへの依存も、この境界で引き受ける。

では、数学の知識は要らないのか。「The Rise of the AI Engineer」は、優秀なAIエンジニアの中にAndrewのコースやPyTorchの知識を持つ者はいない、と書いている。一方で Chip Huyen は、機械学習の知識は依然として有用で、トラブルシューティングに役立つとも言う。必須ではないが、あると確実に有利だ。

デモを作ったら、まず物差しを置く

MLエンジニアリングは「データ収集、モデル訓練、プロダクト化」の順に進む。AIエンジニアリングはこれが逆で、まずデモを作り、すぐにイテレーションを回す。アイデアを素早くデモの形にして、フィードバックをもらえることが基盤モデルの強みだ。最初は、明確で直接的な指示、例の提供（Few-Shot）、思考過程の可視化（CoT）、タグによる構造化、ロール設定、出力のプリフィル、予告（Precognition）といったプロンプトの工夫で始めればいい。

ただ、デモが動いたあとに困るのは、それが良くなったのかどうかを判断できないことだ。人間の評価にはブレがあって、同じ回答でも見る順番や気分で判断が変わる。

正直に言うと、翻訳していて最も「これは重要だ」と感じたのがこの評価の章だった。プロンプトを書く前に、まず評価基準を決める。この順序が逆だと、「なんとなく良くなった気がする」というループからいつまでも抜け出せない。

“evals are surprisingly often all you need（評価さえあれば、驚くほどそれだけで十分なことが多い）”

— Greg Brockman, OpenAI共同創業者（2023年12月）

たとえば、サポート窓口に次のような問い合わせが来たとする。返答の良し悪しを雰囲気で決めず、レビューできる軸に分けてみる。

ここで作りたいのは模範解答ではない。あとからプロンプトやモデルを変えたときに、良くなったかどうかを比べるための物差しだ。評価軸が曖昧なまま改善を続けると、品質より好みを追いかけることになる。

評価の手段は1種類ではない。コードで弾けるものを先に弾き、LLM-as-a-Judge で品質を広く見て、人間の評価はベンチマーク作りやサンプリングに使う。安い順に重ねていくイメージだ。

プロンプトで足りないとき、何を足すか

シンプルなプロンプトで価値が出せたら、次はプロンプトで足りない部分を補う段階になる。手段としては、RAG、ワークフロー、エージェント、ファインチューニングといったモデル適応技術がある。どれが上等というものではなく、後ろのものほど自由度が増え、そのぶん評価、運用、コストの負担も増える。

技術を並べるだけでは判断にならない。いま何に詰まっているかを特定し、制約に合わせて最初の一手を決める。AIエンジニアの仕事の多くは、この判断だと思う。

ワークフローとエージェントの違いは、順序を事前に決めておくか、AIが状況を見て選ぶかにある。

避けたいのは、詰まりに合わない手を打つことだ。品質が安定しないからと長いシステムプロンプトを足し続けたり、状況に応じた判断が要るからと完全自律を前提に組んだりする。判断させたい場面でも、まずはルーティングとガードレールで始めたい。

顧客サポートなら、どう広げるか

典型的なユースケースとして、顧客サポートで考えてみる。最初から大きく作らず、必要になった時点で層を足していく。

最初の段階では、基盤モデルの能力をそのまま使って、どこまで価値が出せるかを確かめる。多くのケースでは、ここだけで十分だ。

足りなければ、図の順に足していく。ルーティングの分類をLLMでやるかルールでやるかは、評価して選ぶ。RAGでは、顧客DBに加えて過去の対応履歴や製品マニュアルも検索対象になるが、チャンクサイズ、埋め込みモデル、リランキングなど、調整するところは多い。

エスカレーションは、確信度スコアや問題の深刻度で判定する。その基準をどう設計するかが品質を左右する。

最初に選びがちな近道

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

一つ目は、ファインチューニングを最初に選ぶことだ。新しい知識を補いたいだけなら、RAGの方が求められていて、しかも安いことが多い。ファインチューニングは手段の一つで、第一選択にならないことの方が多い。

二つ目は、複雑な自律エージェントが必要だと思い込むことだ。世の中のAIプロダクトのほとんどは、明確に順序立てられたステップ、つまりワークフローで動いている。

三つ目は、すべてにAIを使おうとすることだ。AIエンジニアには、「ここはAIが要らない」と判断することも求められる。従来のコードで書いた方がいい場面は多い。

そして、最初の成功を過信しないこと。80%で満足せず、95%まで改善を続ける。LinkedIn の例では、ここに4ヶ月かかった。

評価に始まり、評価に終わる

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

評価駆動開発という言葉があるように、AIエンジニアリングは評価に始まり評価に終わる。書籍が強調しているのも、評価を先に置くこと、シンプルに始めること、モデルの訓練より適応に重点を置くことの3つだ。

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

『AIエンジニアリング』は全10章ある。翻訳者としてのおすすめは、3章「評価方法論」と6章「RAGとエージェント」だ。3章で評価の重要性を理解し、6章で実装のイメージを掴むといい。