最初のLLM機能を、本番に届けるまで

「LLMのデモ、面白いね」で終わっていた社内発表が、いつのまにか「じゃあ来月の運用会議までに、営業チームに配って様子を見よう」に変わる。悪くない話だ。しかし、この二つの間には、感触ではわからない長い距離がある。編集部が繰り返し観測してきたのは、モデル自体の精度ではなく、その手前と後ろにある工程で最初のリリースが詰まる、というパターンだった。

この記事では、社内利用でも顧客向けでも共通する、最初のLLM機能を本番に載せるときのチェックポイントを整理する。魔法のプロンプトではなく、地味な仕様と運用の話だ。

入力の受け口を、狭く定義する

デモ段階では、なんでも入るテキストボックスが自然に見える。本番段階では、これがトラブルの入り口になる。ユーザーは想像もしなかった長さの入力を貼り付けるし、そもそも当該業務と関係のないタスクを投げてくる。

最初のLLM機能では、入力の受け口を狭く定義することを勧めたい。フォームの各フィールドを分けて、それぞれに文字数上限とバリデーションを設ける。プロンプトのテンプレートは開発者が固定し、ユーザーが変更できるのは決められたパラメータだけにする。「自由記述の一問一答」を出すのは、運用の観測データが3ヶ月分たまってからでも遅くない。

失敗したときの振る舞いを、先に決める

LLMは、確率的に応答を返す。つまり同じ入力に対して常に同じ出力が得られる保証はない。そして、モデルAPIそのものが落ちることもある。最初のリリースでは、「失敗したとき何が起こるか」を仕様として決めておく。

• API呼び出しがタイムアウト・エラーを返したときのフォールバック（再試行、代替モデル、または人手案内）。
• スキーマに違反した出力を受け取ったときの処理（再試行 or フォールバック文言）。
• コスト上限に達したとき、ユーザーに何を表示するか。
• 不適切な出力を検知したとき、どこにログを流し、誰が確認するか。

これらを仕様として書かないと、リリース後に「なぜかたまに動かない」という報告が上がり、その原因究明で2週間潰れる。

コスト上限を、機能ごとに切る

LLMの実行コストは、機能全体の集計ではなく、機能単位・ユーザー単位で見ないと、燃え尽きた頃には手遅れになる。トークン単価が下がる方向にあるとはいえ、想定外の使い方（長い履歴を毎回投げる、コンテキストに巨大な添付を含める等）は容易にコストを跳ね上げる。

最初のリリースから、機能ごとの月次予算を決め、消費が閾値に達したらアラートを飛ばす仕組みを入れておくことを勧めたい。単価だけでなく、平均レイテンシとエラー率も観測対象にする。ベクトルデータベースの選定と同様に、「動くか」ではなく「単位あたりいくらで動くか」で意思決定できる態勢を最初から持つ。

ゴールデンセットを、リリース前に用意する

プロンプトを1文字変えるだけで、応答の質は変わる。この「変わったか」を、開発者の勘ではなくデータで答える仕組みが必要だ。詳細はLLM出力の評価で扱ったが、最小構成としては次の3点が要る。

1. 実運用に近い入力を30〜100件集めたゴールデンセット。
2. それぞれの入力に対する期待出力、または望ましい応答の条件（含めるべき情報、避けるべき表現、フォーマット等）。
3. プロンプトやモデルを変えたときに、ゴールデンセット全件を回して差分を可視化するランナー。

これがないと、モデルベンダーの新バージョンが出るたびに「なんとなくよくなった気がする」で判断することになる。

KPIは「使われたあと」を見る

初期のダッシュボードは、どうしても「使われた回数」に目が行く。しかし、その先の指標——ユーザーが結果を採用したか、実際の作業時間が減ったか、以前の作業品質と比べてどうか——を見ないと、機能の価値は測れない。

詳しくはAIのROIを計測するで扱っているが、最初のリリース時点でも、次の3つの数字は取れるようにしておきたい。

• 結果を採用（コピー・確定・保存）した割合。
• 結果を編集した割合と、平均編集量。
• 再実行された割合（同じ入力で複数回試された割合）。

採用率が高くても編集量が大きいなら、それは「そのままでは使えないが、書き出しには役立つ」機能だ。この解像度で見ると、次に何を改善すべきかが自然に見えてくる。

ロールアウトは、段階的に

最初のリリースは、全ユーザーに一斉にではなく、段階的に配りたい。カナリアリリース（一部ユーザーに先行公開）と、機能フラグ（いつでも無効化できる仕組み）は、本番投入の最初から用意する。

ただし、段階的ロールアウトは万能ではない。「1%のユーザーには問題なかったが、10%に広げたら想定外の使い方でエラー率が跳ねた」というのは、編集部が複数回観測してきた現象だ。カナリア期間中は、単に「エラーが出ていないか」ではなく、「どういう入力が来ているか」も見る。

まず、この4つを整える

最初のLLM機能で、リリース前に必ず整えるべきものを4つに絞るなら、次のとおりだ。

1. 入力の受け口：狭く、明示的に。
2. 失敗時の振る舞い：仕様として書く。
3. コスト上限とログ：機能ごと・ユーザーごとに。
4. ゴールデンセットと差分ランナー：プロンプト変更の効果を機械が答える。

この4つが揃うと、その後の改善は「なんとなく」ではなく「明らかにXが改善した」に変わる。逆に言えば、これが揃わないうちに機能を拡大すると、改善の判断ができないまま、コストと不確実性だけが積み上がる。

参考にした一次資料：

• OpenAI. “GPT best practices” — Production considerations (公式ドキュメント). platform.openai.com/docs/guides/production-best-practices
• Anthropic. “Deploying Claude” — Rate limits, evals, and monitoring (公式ドキュメント). docs.anthropic.com
• NIST AI Risk Management Framework 1.0（AI RMF）, 2023. nist.gov/itl/ai-risk-management-framework