はじめに
こんにちは、株式会社estraでエンジニアをしています。福地です。
「AIエンジニア」という言葉、めちゃくちゃホットで最近よく聞きますが、範囲が広すぎて何から手を付ければいいか分からなくないですかね？
私は普通のバックエンドエンジニアでしたが、LLMを利用するようになり、評価やガードレールの設計まで行ってきたなかで、わかってきたことがあります。
この記事では、その過程で実際にやったことを共有します。学ぶ順番と、実務で最初にぶつかる論点がわかると思います。
私のスタート地点
もともとはバックエンドをやっていました。API を書いて、DB を設計して、たまにインフラを触る。機械学習の経験はゼロで、行列の掛け算も怪しいレベルでした。
それでもなんとかなったのは、いま求められている「AIエンジニア」の多くが、モデルを作る人ではなく「LLM を使ってプロダクトを作る人」だからです。
Chip Huyen の書籍「AI Engineering」ではこの職種を明確に区別していて、必要なのは学習理論よりもシステム設計と評価の能力だと述べています。バックエンドの経験はむしろそのまま活きます。
なので、数学からやり直す必要はないです。私もやってません（もちろん知識はあるに越したことはないですが、必要になったら調べる方式で十分でした）。この記事でも、機械学習の数学やモデルの自作は扱いません。
LLM の仕組みは「困らない粒度」で押さえる
最初にやったのは、LLM の仕組みをざっくり理解することです。実務で押さえるべきは3つだけでした。
-
トークン
LLM は文章をトークンという単位で処理していて、課金もレート制限もトークン単位です。 -
コンテキストウィンドウ
一度に渡せるトークン数の上限のことで、システムプロンプトも会話履歴も入力文書も、全部この枠内に収める必要があります。 -
コストとレイテンシの特性
料金は入出力のトークン数に比例して増えます。さらに処理時間の面では、Attention の計算量が入力長に対して二乗で増える性質があるため、長い入力ほど応答も遅くなりがちです。長文を雑に投げると高いし遅い、と覚えておけば実務では十分です。
コンテキストウィンドウは「机の広さ」のイメージです。机に載る資料しか参照できないし、大きい机で作業するほど時間もお金もかかる。この感覚があると、後述する RAG やプロンプト設計の話が全部つながります。
逆に、Transformer の内部構造や学習の仕組みには、最初は深入りしませんでした。論文を読むより API を叩いた方が圧倒的に早いです。
プロバイダは1つに絞らない
OpenAI と Vertex AI（Gemini）の両方を使いました。意図してそうしたというより要件の中で自然にそうなったのですが、結果的に一番学びが大きかった部分です。
モデル検証を自分でやる
早い段階でやったのが、モデル比較検証です。
同じタスクに対して複数モデルを走らせて、精度・レイテンシ・コストの3軸で比較する。精度は正解データ（Ground Truth）を用意して突合します。この正解データ、現場ではゴールドアンサー（GA）と呼ばれたりもします。呼び方が違うだけで指すものは同じです。
| 軸 | どう測るか | ハマりどころ |
|---|---|---|
| 精度 | Ground Truth と突合して正答率を出す | 正解データ作りが一番大変です。ここをサボると全部が狂います。 |
| レイテンシ | 同一入力で複数回計測 | 平均でなく p90 / p99 で見る（裾が長い） |
| コスト | 入出力トークン数 × 単価で試算 | 出力トークンの方が単価が高いことを忘れがち |
やってみて分かったのは、「一番賢いモデルが正解」ではないことです。フラッグシップモデルは確かに精度が高いですが、レイテンシが倍でコストが5倍だったりします。
タスクによっては小さいモデルで精度がほぼ変わらないこともあって、そうなると答えは明らかに小さい方です。
この検証の型（評価データセットを作る → 複数モデルで回す → 3軸で比較する）は、どういった状況でも使い回せる財産になりました。
料金は頻繁に改定されるので、この記事にはあえて具体額を書きません。公式の料金ページを見る習慣をつけるのが一番の近道です。
定番タスク
画像の分類とプロンプトの出し分け
私がやったことは大きく2つです。
1つ目はアノテーション。モデルに解かせたいタスクの正解データを人力で作る作業です。地味ですが、この作業をやったおかげで「このタスクの難しさはどこにあるか」「モデルがどこで間違えそうか」が体感で分かるようになりました。後の評価設計にも直結します。
2つ目は、分類してからプロンプトを出し分ける設計です。入力画像を最初に軽いモデルでカテゴリ分類して、カテゴリごとに専用のプロンプトを持つ後続処理へルーティングします。
構造だけ擬似コードで示すとこうなります。
category = classify_image(image) # 軽いモデルで分類
prompt = PROMPTS[category] # カテゴリ専用プロンプトを選択
result = generate(prompt, image) # 本処理は高精度モデルで実行
1つの巨大プロンプトで全ケースに対応しようとすると、あるケースを直す修正が別のケースを壊す、というモグラ叩きになります。分類で分岐させると、プロンプトが小さく保てて、カテゴリ単位で精度を測って直せる。これは Anthropic が「Building Effective Agents」で言うワークフロー型の設計そのもので、実務ではエージェントに自由にやらせるよりこの形に落ち着くことが多いです。
Whisper での音声文字起こし
音声の文字起こしタスクもやりました。Whisper 系の API を使うこと自体は簡単なのですが、実務で効いたのは前後の処理です。
仕組みを少しだけ補足すると、Whisper は音声の波形をそのまま読んでいるわけではありません。高速フーリエ変換（FFT）で短い時間窓ごとに周波数成分へ分解し、スペクトログラム（正確には log-Mel スペクトログラム。時間 × 周波数の強度マップ）に変換してからモデルに入力しています。
つまり内部では、音声を「画像のようなデータ」として扱っているわけです。またモデルの入力サイズが固定されているため、Whisper は音声を30秒単位で区切って処理します。この2つを知っておくと、後述する分割処理の話や、無音区間で変な出力（ハルシネーション）が出やすいことが腹落ちします。
API にはファイルサイズ上限があるので、長い音声は時間ベースで分割して並列で投げ、結果を結合します。そして文字起こし結果をそのまま信用しないこと。
Whisper は無音区間で定型的なハルシネーション（存在しない決まり文句）を出すことがあります。文字起こし結果を後続処理に渡す前に、既知のパターンをブロックリストで除去する後処理を挟むのがおすすめです。
「API を呼ぶだけでしょ」と思っていたタスクほど、こういう泥臭い処理が本体だったりします。LLMを呼ぶ前処理と後処理は結構大事。
プロンプト設計
プロンプトは、型を覚えたら安定しました。私が使っている型はこれだけです。
- 役割と完了条件を最初に書く
- 参照資料や入力は XML タグや区切りで明示的に包む
- 例（Few-shot）を1〜3個入れる。多ければいいものではない
- 出力は JSON スキーマで強制する
- 「判断できない場合は推測せず
unknownを返す」と逃げ道を用意する
特に効いたのは4と5です。出力形式をプロンプトで「お願い」していた頃はパースエラーとの戦いでしたが、構造化出力（スキーマ強制）に切り替えてからやり直し処理がほぼ消えました。5を入れると、モデルが無理やり答えをでっち上げるケースが目に見えて減ります。
もう1つ、地味に効くのが出力の「書き順」です。JSON スキーマを設計するとき、私は reason（判断理由）を先、answer（結論）を後に置きます。
{
"reason": "画像の左上に手書きの署名があり、判定基準Aに該当するため",
"answer": "category_a"
}
LLM は文章を前から順に生成するので、answer を先に置くと、先に結論を出してから理由を後付けする形になります。逆に reason を先にすると、理由を書き出す過程がそのまま思考の下書きになって、結論の精度が上がります。Chain-of-Thought（思考の連鎖）と呼ばれるテクニックを、スキーマの項目順で実現するイメージです。フィールドの並び1つで正答率が変わるのは、最初は結構驚きました。
評価設計をする（一番重要だと思っています）
正直、LLM を使ったプロダクトを作る上で一番重要なのはここだと思います。
LLM の出力は毎回変わるので、「良くなった気がする」ではプロンプトを変更できません。そこで評価プロンプトを使ったオフライン評価を作りました。仕組みはシンプルで、評価用データセットに対して本番プロンプトを一括実行し、その出力を別の LLM に観点別で採点させます。いわゆる LLM-as-a-Judge（LLM による自動評価）です。
運用してみて学んだことが3つあります。
-
測る側と測られる側を分離する
評価プロンプトと本番プロンプトを混ぜると、どちらを直したのか分からなくなります。 -
機械で判定できる観点を LLM に聞かない
文字数やフォーマットのようにルールで判定できる項目はコードでチェックして、LLM ジャッジの結果を上書きします。安いし確実です。 -
ジャッジ自体を疑う
LLM ジャッジには位置バイアスや、冗長な回答を高く評価する癖があります。人手の採点と突き合わせてジャッジのプロンプトを調整するキャリブレーションが必要でした。
事実の正確性については、Ground Truth と突合して precision / recall を出す評価も別立てで作りました。アノテーションの経験がここで活きます。
もう1つ、やる前は想像していなかったのがドメイン知識の重要性です。評価観点を決めるにも「この出力は業務的に正解なのか」を判定するにも、その領域の知識が要ります。プロンプトを書くときも同じで、業務のルールや例外を言語化してモデルに渡すのはエンジニアの仕事です。私はアノテーションを自分でやったこと、そして業務に詳しい人に質問しまくったことでなんとかなりました。技術だけ勉強しても評価は作れない、というのは強調しておきたいところです。
「AI Engineering」でも評価は繰り返し強調されていて、著者は評価を AI 導入の最大のボトルネックと呼んでいます。実感としても、プロンプトを書ける人より、評価を設計できる人の方が圧倒的に希少です。
ガードレールを設計する
LLM の出力をそのままユーザーに出すのは危険です。そこでガードレールを設計しました。やったのは大きく2種類です。
1つはルールベースのチェック。NGワードの設定など、決定的に判定できるものはコードで弾きます。LLM に判定させるより速くて安くて確実です。もう1つは分類ベースのチェックで、入力を分類器に通して、要注意カテゴリに該当したら通常フローから外し、定型応答や人間へのエスカレーションといった別ルートに流します。
設計で悩むのはトレードオフです。ガードレールを厳しくすれば危険な出力は減りますが、問題ない入力まで誤って弾く率（誤拒否率）が上がります。全部拒否すれば攻撃成功率はゼロですが、それはもうプロダクトではないですよね。どこにラインを引くかはビジネス判断で、エンジニアはその判断材料になる数字を出せるようにしておく、というのが私の落とし所でした。
レイテンシとコストを設計に織り込む
Web エンジニアの感覚だと API 呼び出しは数十ミリ秒ですが、LLM は平気で数秒かかります。しかも従量課金。ここを設計に織り込めるかどうかが、動くデモと運用できるプロダクトの分かれ目でした。
レイテンシは p50 ではなく p90 / p99 で見ます。LLM のレイテンシは裾が長く、平均値はあてになりません。応答が遅いとき用に別プロバイダやリトライを並行で走らせて早く返ってきた方を採用する、ヘッジ実行という設計も使いました。
コストは、タスクごとにモデルサイズを使い分けるだけで桁が変わります。分類は軽いモデル、生成は高精度モデル、という適材適所です。システムプロンプトのように毎回同じ内容を送る部分は、プロンプトキャッシュを使うと入力コストを大きく削れます。見積もりの段階では「1リクエストあたり入力何トークン × 月間何リクエスト」をトークン単価から逆算します。これをやると、その機能が商売として成立するかが最初に分かります。
RAG とファインチューニング
「AI Engineering」に、プロンプティング → RAG → ファインチューニングの順で試すという原則があります。コストと複雑性が低い順です。同書には「ファインチューニングは形式のため、RAG は事実のため」という整理もあって、困りごとから逆引きするとこうなります。
| 困りごと | 打ち手 |
|---|---|
| 指示の書き方で改善しそう | まずプロンプティング |
| モデルが知らない事実を扱いたい | RAG |
| 出力の形式・振る舞いがプロンプトで直らない | ファインチューニング |
実際に、分類とプロンプトの出し分け、つまりプロンプティングの工夫で要件を満たせてしまいました。新しいモデルほど指示追従性が上がっていて、プロンプトで足りるケースは増えています。RAG が必要な規模のナレッジベースを扱うことになったら、そのとき学べばいいと思っています。
学習リソース
リンク集にはしません。私が実際に読んだ順で2つだけ挙げます。
1つ目は書籍「AI Engineering」（Chip Huyen 著、O'Reilly）。この記事に出てきた評価駆動、ガードレール、推論最適化、プロンプト → RAG → FT の順番、すべてこの本に体系として載っています。実務に入る前でも後でも効きます。
2つ目は Anthropic のエンジニアリングブログ、特に「Building Effective Agents」です。ワークフローとエージェントの区別は、この記事の分類 → 出し分け設計の考え方の元ネタです。
あとは各プロバイダの公式ドキュメントです。料金・モデル・制限値は必ず一次情報で確認する癖をつけてください。二次情報はすぐ古くなります（この記事も含めて）。
これから始める人へ
振り返って一番伝えたいのは、差がつくのはプロンプトの上手さではなく、評価・ガードレール・コストという「運用の論点」を設計できるかだということです。そしてここは、バックエンドエンジニアの経験がそのまま武器になる領域です。
Web エンジニアからの転向は、思っているよりずっと現実的です。まずは小さいタスクでいいので、評価データセットを1つ作るところから始めてみてください。プロンプトをいじる前に「どうなったら良くなったと言えるか」を決める。この順番を体で覚えるのが、私がやったことの中で一番効きました。