はじめてのLLM機能を出荷する：2週間で本番投入するプレイブック

多くのチームが最初のLLM機能でつまずくのは、モデルの性能が足りないからではありません。確率的なシステムを決定的なシステムのように扱い、評価を飛ばし、デモをそのまま本番に出してしまうからです。この記事は、私たちが実際に使う2週間の道筋——範囲を絞り、モデルを包み、測り、フラグの裏で段階公開する——を扱います。

守れる範囲を選ぶ

最初の機能は役に立ち、境界が明確で、被害範囲が小さいものにします。問い合わせの要約、一次返信の下書き、受信フォームのタグ付け——これらは、間違えても安く、取り返しのつかないことが起きる前に必ず人が出力を見るため、理想的です。

レビューなしにシステム・オブ・レコードへ書き込むもの、金銭に触れるもの、初日から顧客と無人でやり取りするものは避けます。それらは後で信頼を得てから。

生でなく、モデルを包む

アプリとプロバイダの間に薄いサービスを置きます。その境界こそ、生のAPI呼び出しでは得られないものを足す場所です。

• 構造化出力 — JSONを要求して検証し、壊れていれば拒否して再試行する。
• タイムアウトとフォールバック — 遅いモデル呼び出しはリクエストを固まらせず、優雅に劣化させる。
• プロンプトのバージョン管理 — プロンプトはコード。リポジトリに入れてタグを打つ。
• ロギング — 入力・出力・レイテンシ・コストを毎回記録する。後の評価とROIの議論で必要になる。

信じる前に測る

受け入れられる答えを添えた実例を30〜50件そろえます。プロンプトを変えるたびにそれで機能を回し、結果を採点する。これは応用AIで最もレバレッジの高い習慣であり、私たちが勘の前に評価をと言う理由です。手法の全体はLLM出力を評価するにあります。

プロンプトの変更が良くなったのか悪くなったのか分からないなら、それはエンジニアリングではなくギャンブルです。

フラグの裏で段階公開する

まずは暗く出す。シャドウモードで本番稼働させ、機能が何をしたはずかをログに取る。次にトラフィックの5%へ露出し、ログを見て、数字が保てたら広げる。取り消しにくい操作には必ず人を介在させます——ヒューマン・イン・ザ・ループの自動化を設計するを参照。

2週間の形

1. 1〜2日目：範囲、評価セット、サービスのラッパー。
2. 3〜6日目：評価セットに対するプロンプトの反復。
3. 7〜9日目：本番でのシャドウモード。ログが示した点を修正。
4. 10〜14日目：5%の段階公開。監視し、広げる。

自社ドキュメントに対して質問に答える機能なら検索が要ります。それ自体が一つの技芸で、本当に動くRAGで扱います。