開発者のためのAIエンジニアリングガイド

本記事は、経験豊富なソフトウェアエンジニアのために書かれたAIエンジニアリングの実践ガイドです。著者は15年間のバックエンド開発経験を持ち、LLMが本番環境に導入された際に、従来のルールが通用しなくなったと述べています。システムは非決定的になり、入力は自然言語であり、単体テストでは出力の良し悪しを判断できません。

AIエンジニアリングの概要

基盤モデルは、大規模な混合コーパスで事前学習され、API経由で様々なタスクに適応できる抽象化です。例として、Gemini 3.1 Proはマーケティングメールの作成、サポートチケットの分類、SQL生成、100万トークンのコードベースの要約、ツールの呼び出しが可能です。エンジニアの役割は、モデル自体ではなく、モデルを中心としたシステムを構築することにシフトしました。

基盤モデルは、コード、文章作成、画像・動画、教育、会話、情報集約、データ整理、ワークフロー自動化に適していますが、正確な算術、リアルタイムの事実（グラウンディングなし）、わずかな誤りも許されないタスクには不向きです。

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

MLエンジニアリングは、モデルの構築とトレーニング（データパイプライン、特徴量エンジニアリング、ハイパーパラメータチューニング、分散トレーニング）に焦点を当てます。AIエンジニアリングは、事前学習済みモデルを活用したアプリケーション構築（プロンプト、検索、評価、エージェント、推論サーバー、可観測性）に焦点を当てます。AIエンジニアは、システムのグラウンディング（RAG、ツール、構造化出力）、継続的な評価、そしてコストとレイテンシの管理という3つの追加責任を負います。

3層スタック

• アプリケーション層: プロンプト、RAG、エージェント、UI、ビジネスロジック。
• モデル開発層: ファインチューニング、モデルマージ、蒸留、データセットエンジニアリング（オプション）。
• インフラストラクチャ層: GPU、推論サーバー（vLLM、TGI、TensorRT-LLM）、ベクトルデータベース、ゲートウェイ、可観測性、CI/CD。

ほとんどのチームはレイヤー1に留まり、必要に応じて下位レイヤーに移行します。移行の判断は、プロンプトエンジニアリングとRAGが頭打ちになった場合（レイヤー2）、またはコスト、データレジデンシー、ハードウェア制約によりクラウド推論が非現実的になった場合（レイヤー3）です。

LLMの適応方法

コスト順に3つの方法があります。プロンプトエンジニアリング（最も安価、迅速）、RAG（実行時に関連データをモデルに提供）、ファインチューニング（重みの変更）。デフォルトの順序は、プロンプト→RAG→ファインチューニングです。ステップを飛ばさないでください。

LLMの選択

2026年のモデルカテゴリ: クローズドフロンティア（最高品質、高コスト）、クローズドミッドレンジ、クローズド低コスト（高ボリュームワークのデフォルト）、オープンウェイト（自社GPUで実行）、専門モデル（埋め込み、リランカーなど）。選択基準: タスク適合性、推定ボリュームでのコスト、レイテンシ、コンテキストウィンドウ、出力構造、実行環境。ほとんどのチームは複数のモデルを使用し、低コストのリクエストを安価なモデルにルーティングします。

AIアプリケーションの計画

AI機能の計画は、出力品質が二分法ではないため、従来の機能とは異なります。計画には明示的な品質チェックポイントを含める必要があります。ユースケース評価（本当の問題か？確率的出力への耐性は？誤りのコストは？）、期待値の設定（開発時間は通常の機能の少なくとも2倍、主に評価とエッジケースに費やす）、マイルストーン計画（「かろうじて動作する」状態への迅速な到達→評価パイプライン→本番環境の強化）、保守（モデルドリフト、プロンプトの劣化、データ変更への対応）。

「かろうじて動作する」マイルストーンは重要です。実際のユーザーに早期にリリースし、壊れる部分を観察してから修正します。隔離環境での完璧さを追求すると、何も出荷できずに数ヶ月を費やす可能性があります。

開発、デプロイ、保守における課題

• 開発: プロンプトは従来のコードのように単体テストできず、評価データセットを迅速に準備する必要がある。
• デプロイ: 推論は遅く、高コスト、バースト性があり、キャッシュ、バッチ処理、ルーティングが重要。
• 保守: ベンダーによるモデルの非推奨化、トークナイザーの変更（Opus 4.7の新トークナイザーは最大35%多くのトークンを使用）、幻覚の進化に対応するため、監視とレッドチーミングが必要。

業界ユースケースとROI

高いROIが確認されたケース: カスタマーサポートの振り分け、社内検索とRAG、コードアシスタンス、文書自動化。ROIが低いケース: 誤回答がブランド危機を招くユーザー向け機能、決定論的APIの置き換え、保守されないデモ。

基盤モデルの理解

トレーニングデータはモデルの能力を形成します。多言語モデルは主要言語で良好ですが、小言語では性能が低下します。ドメイン特化モデルは特定分野でわずかに優れますが、多くの場合、汎用モデル＋RAGが品質と運用の簡便さで優位です。

モデルアーキテクチャとサイズ

主流はデコーダのみのTransformerで、一部は混合専門家モデルです。モデルサイズは依然重要ですが、適切に調整された70Bモデルは、調整不足の400Bモデルを凌駕することがあります。推論モデル（Gemini 3.1 Pro思考レベル、Claude拡張思考）は、パラメータ数からテスト時計算量へと焦点をシフトさせました。

小規模言語モデル、マルチモーダル、ドメイン特化、推論モデル

• 小規模言語モデル: 単一GPUで動作し、分類、ルーティング、簡易要約などの低コストタスクに適する。
• マルチモーダル: 画像、動画、音声が第一級の入力となり、コストとレイテンシを制御するために前処理（テキスト抽出、画像説明）を検討する必要がある。
• 推論モデル: 応答前に内部思考連鎖を生成し、数学、コード、計画に優れるが、より遅く高価である。