LLMOpsとは？MLOpsとの違いと評価・運用の作り方

実家には、母が30年近く世話しているぬか床があります。帰省のたびに感心するのは、あれの管理が完全に日誌型であることです。毎日かき混ぜて、味見をして、塩を足した日はメモが残る。「正しいぬか床の状態」という仕様書はどこにもないのに、味がずれたら日誌をさかのぼって、直前に変えたことを疑う。祖母の代から、運用だけで品質が保たれています。

この話に出てくるのは、保険会社のコールセンターで、応対記録をLLMで要約するシステムを作るプロジェクトです。

僕は要約システムの設計から、出力の評価と改善運用までを担当しました。

この記事では、要約を現場で使い続けるために、評価と変更の履歴を整えた工程を扱います。

前置きはさておき、本題に入ります。LLMOpsとは、大規模言語モデル（LLM）を業務で使い続けるための運用の仕組みのことです。モデルの選定、プロンプトの管理、出力の評価、監視までを含みます。僕はこれを、この応対要約システムの運用で覚えました。今日は、ソフトウェアの運用のつもりで始めたら、必要だったのはぬか床の日誌だった、という話をしていこうと思います。

① 教科書どおりに、やってみる

LLMOpsの基本をすでにご存じの方は、② そのとおりに作って、詰まるから読み進められます。

LLMを業務に組み込む話の教科書は、こう教えてくれます。作って終わりにするな。プロンプトを管理し、出力を評価し、監視しろ。ソフトウェアと同じように、リリースの前にテストをしろ。どれも正しく聞こえますし、実際、正しいことを言っています。問題は、この助言をソフトウェアの語彙のまま受け取ると、あとで痛い目に遭うことでした。

そのとおりにやりました。エージェントを組み、動かす前に何本か試し書きをさせて、出力を確認してからサイクルを回し始める。最初の版は20日ほどで動き、1回のサイクルで記事が5本、自動で生まれてきました。プロンプトはファイルで管理し、変更の履歴も残す。教科書に書いてあることは、ひととおり揃えたつもりでした。ここまでは、ソフトウェア開発の運用感覚のままで、特に困りませんでした。

LLMOpsとは、運用を1周させる仕組み

LLMOpsは、LLMを選んで接続する作業だけを指す言葉ではありません。業務に合うモデルを選び、指示であるプロンプトを管理し、出力を評価し、本番で起きる変化を監視するところまでが1周です。構成要素はモデル、プロンプト、参照データ、評価、実行基盤、監視に分けられます。モデルだけでは改善箇所を特定できず、評価がなければ良し悪しを決められず、監視がなければ公開後の劣化を見逃します。実行基盤がなければ、試作を安定した業務へ移せません。部品の一覧ではなく、次の改善へ戻れる輪になっていることが仕組みの要点です。

LLMOpsとMLOpsは「テストが書けるか」で分ける

MLOpsは従来の機械学習モデルを継続的に学習、配備、監視する考え方で、LLMOpsはその対象をLLMへ広げたものです。ただし、違いを「扱うモデルの種類」だけで終えると、現場で迷います。僕が分かれ目だと思うのは、期待する出力をそのままテストに書けるかです。MLOpsでは同じモデルと入力なら同じ予測になる前提を置きやすい。一方、LLMは同じ入力でも表現や内容が揺れるため、完全一致では品質を測れません。そこでプロンプトや参照情報まで管理対象にし、出力を幅のある評価で扱うように試験を設計します。

メリットは、改善の手戻りを減らせること

LLMOpsのメリットは、効率性、リスク軽減、拡張性の3つに整理できます。なかでも効率が上がるのは、出力を見てから原因を探す改善工程です。実行条件と評価結果が結び付いていれば、調査の出発点を絞れます。安全性や事実性の悪化も評価と監視で早く見つけられ、利用部門が増えても共通の運用を使い回せます。ベストプラクティスは、最初から大きな基盤を作ることではありません。評価、管理、監視を小さくつなぎ、業務で困った箇所から整えることです。運用者が説明できる小ささも大切です。具体的な最小セットは⑧でまとめます。

プロンプトの変更もデプロイとして扱う

プロンプト管理で残すべきなのは、文章の版だけではありません。「どの版で、どの評価が、何点だったか」を同じ履歴から追えるようにします。モデルや参照データ、実行時の設定も対応付ければ、結果が変わった理由を探しやすくなります。そして本番の振る舞いを変える以上、プロンプトの変更もデプロイです。コードを触っていないからと確認を省くと、利用者から見える品質だけが突然変わります。変更前の評価、公開範囲、承認者、戻し方を決め、まず限定した利用先へ安全に反映してから広げるところまでを配備の手順に含めます。

評価は、合否ではなく点数と閾値で設計する

評価では先に「この出力は、定めた観点の点数が閾値以上なら採用する」と判定文を書きます。正解との完全一致ではなく、事実性、指示への追従、必要項目、読みやすさなどを観点別に点数化すると、LLMの揺れを残したまま比較できます。その材料になる評価用データは、一般的なETLを先に作るより、実際の入力、望ましい出力、失敗させたくない例を業務から集めるほうが先です。通常例だけでなく、曖昧な依頼や情報不足の例も含め、期待する振る舞いを添えます。公開前のevalsは、この小さな問題集を繰り返し解かせる工程です。

監視では、出力と入力の両方を見る

本番監視で見るのは、出力の質だけではありません。問い合わせの長さ、言語、話題、添付情報の有無など、入力の分布が評価時からずれていないかも見ます。利用者や用途が変われば、モデル自体が同じでも、用意した評価用データが現実を代表しなくなるからです。あわせて失敗率、応答時間、再実行の発生、評価観点ごとの推移を追えば、品質問題とシステム障害を分けやすくなります。異常時に誰へ知らせるかも必要です。個人情報や機密を含む入力は、そのまま記録する前提にせず、保存範囲、伏せ方、閲覧権限、保持期間を決めてから観測します。

RAG（検索で補う方式）を先に試し、必要ならファインチューニングする

社内情報や更新される知識を使わせたいなら、まずRAG（検索拡張生成）を試します。質問のたびに関連資料を検索して入力へ添える方式で、情報の差し替えがしやすく、回答の根拠も追いやすいからです。ファインチューニングは、知識を都度足すというより、特定の形式や語調、判断パターンを安定して再現したい場合に向きます。両者は二者択一ではなく、検索で知識を渡し、調整済みモデルで振る舞いを整える併用もできます。選択基準は、変えたいものが「参照する情報」なのか「応答の振る舞い」なのかです。どちらの場合も、導入前後を同じ評価用データで確かめます。

向くユースケースは、途中結果で次が変わる仕事

業界名だけでLLMOpsの要否は決まりません。見るべきなのは、LLMの途中結果によって次の処理や人の判断が変わる仕事かどうかです。問い合わせの分類で回答先が変わる、文書から抜いた情報で審査が進む、検索結果を基に文章を作る、といった用途では、小さな出力のずれが後工程へ広がります。金融、製造、医療、顧客対応など業界が違っても、この構造は同じです。逆に、利用者がその場で読み捨てる下書きなら、重い運用は見合わない場合があります。誤りの影響範囲と、人が止められる地点を見て、業界名ではなく工程の構造から必要な管理を決めます。

推論コストの管理

LLMの推論は、入力と出力に使ったトークン（文章を処理する単位）に応じて課金されるAPIが一般的です。費用を動かす主な変数は、使うモデル、入力の長さ、出力上限、呼び出し回数、再試行回数です。同じ内容を再利用するキャッシュが使える場合は、重複する入力や検索結果を毎回処理しない設計も効きます。モデル別、機能別、利用者別にトークン量と失敗率を記録し、「長すぎる入力を削る」「定型処理だけ軽いモデルへ分ける」のように変数を1つずつ変えて、品質と費用を同じ評価表で比べます。

ツールの地図（Langfuse／LangSmith／MLflow など）

ツールは順位ではなく役割で分けると選びやすくなります。実行の追跡や評価、プロンプト管理にはLangfuseやLangSmith、機械学習を含む実験・モデル管理にはMLflowがあります。観測にはDatadogのLLM ObservabilityやArize Phoenix、API呼び出しの観測にはHeliconeという選択肢もあります。先に必要な役割を決め、既存基盤との接続、データの保存先、権限管理、評価方法、運用担当者が調査できる粒度を試作で確認します。複数製品を同時に入れるより、いま追えない情報を1つ決めて、その穴を埋める道具を選びます。

ハルシネーション

ハルシネーションは、根拠がないのに、もっともらしい嘘を生成する現象です。ゼロになる前提を置かず、RAGで信頼できる資料を渡す、根拠の提示を求める、分からないときは回答しない条件を指示する、出力を別の規則や人で検査する、という多層の対策を取ります。本番では事実誤認として報告された出力を保存し、評価用データへ戻します。特に金額、日付、固有名詞など誤りの影響が大きい項目は、生成文の自然さとは別の観点で照合します。

ユーザーフィードバックとRLHF

利用者のGood／Bad評価や修正文は、実際の用途で何が困るかを知る材料です。ただし、評価だけでは理由が分からないため、任意の短い理由、対象の出力、プロンプト版、参照データ、実行設定を結び付けます。週次など決めた周期で分類し、頻出する失敗を評価用データやプロンプトの改善へ戻します。RLHFは、人の評価で出力を調整する学習です。収集した反応をそのまま学習へ流さず、個人情報を除き、評価基準とラベルの一貫性を確認してから使います。

LLM-as-a-Judge

LLM-as-a-Judgeは、LLMに別のLLMの出力を採点させる方法です。評価観点、採点尺度、合格例と不合格例を指示し、理由も出させれば、大量の候補を同じ形式で一次評価できます。導入時には人が採点した小さな基準集と一致傾向を確かめ、採点側のモデルや指示も版として固定します。ただし、採点するLLMにも偏りや揺れがあり、もっともらしい誤判定をするため、高リスクな判断や境界例は人の確認を残します。

標準の評価指標（BLEU／ROUGE／パープレキシティ）

BLEUは生成文と正解文で単語の並びがどれほど重なるか、ROUGEは正解文の重要な語句を生成文がどれほど含むかを見る指標です。パープレキシティは、モデルが次の語をどれだけ迷わず予測できるかを表し、低いほど予測の迷いが少ないと解釈します。いずれも同じ評価用データで版を比較する補助線にはなりますが、事実が正しいか、指示に従ったか、利用者の課題を解いたかまでは単独で測れません。生成タスクでは、業務固有の観点、人の確認、LLMによる採点と組み合わせます。

CI/CDと自動回帰テスト

CI/CDは、変更の統合、試験、配備を自動化する流れです。プロンプト、モデル、参照データ、実行設定の変更を提案したら、過去の正常例、失敗例、安全性の例を含む評価用データが自動で走り、基準未満なら本番反映を止める形にします。GitHub Actions、Jenkins、Tektonなど既存の仕組みから評価処理を呼び出せます。点数だけでなく、変更前との差、悪化した例、実行条件を結果として残し、合格後も限定公開から段階的に広げます。

学習データの収集・前処理・ラベリング

ファインチューニングの前には、目的に合う会話や文書を収集し、重複、文字化け、不要な個人情報、権利上使えないデータを除く前処理が必要です。次にラベリング、つまり正解や分類、望ましい応答を人が付ける作業を行います。基準書と例を用意し、同じ例を複数人で確認すると判断のずれを見つけられます。学習用、調整用、最終評価用は分け、同じ文書がまたがらないよう管理します。データの出所、同意・利用条件、加工履歴、版を残すと、問題が起きたときに除外して学び直せます。

ベクトルデータベース

ベクトルデータベースは、文章を数値の並びに変換し、意味の近さで探す索引です。RAGでは、質問に近い文書の断片をこの索引から取り出し、LLMへの根拠として渡します。導入時は、文書の分割幅、付ける見出しや更新日、検索件数を評価対象にし、「答えが悪い」のか「必要な資料を検索できていない」のかを分けます。元文書の更新や削除が索引へ反映される手順も決め、回答には参照元を表示できるようにします。

ファインチューニングの技法（量子化・蒸留など）

代表的な技法には、学習率などの設定を探すハイパーパラメータ調整、既存モデルの知識を別用途へ生かす転移学習、複数の計算機で学習を分担する分散学習があります。量子化は数値表現を小さくしてメモリ使用量や計算量を減らすこと、蒸留は大きなモデルの振る舞いを小さなモデルへ学ばせること、プルーニングは影響の小さい結合を削ることです。どの技法も品質が変わり得るため、目的を「形式の安定」「応答時間の短縮」など1つに絞り、導入前後を同じ評価用データで比較します。

デプロイの形（クラウド／オンプレ／エッジ）

クラウドは外部の計算基盤を使う形、オンプレミスは自社設備で動かす形、エッジは端末や現場に近い機器で動かす形です。選び分ける軸は、データを外へ出せるか、応答時間、通信断への耐性、必要な計算資源、運用人材、増減する負荷への対応です。REST APIのような呼び出し口、GPUなどの計算資源、自動で台数を増減する仕組みも合わせて設計します。まずデータ分類と許容応答時間を決めると候補を絞りやすく、切替手順と障害時の代替経路まで試してから本番へ出します。

セキュリティとガードレール

ガードレールは、LLMの入出力や実行できる操作を安全な範囲へ制限する仕組みです。入力では個人情報や機密、有害な指示を検査し、出力では禁止内容、機密の漏えい、危険な操作を検査します。利用者とエージェントには必要最小限の権限だけを与え、検索、送信、更新などの操作ごとに許可を分けます。プロンプトインジェクション、つまり外部文書に埋め込まれた命令で本来の指示を上書きさせる攻撃には、外部データを命令として扱わない分離、許可リスト、人の承認、操作ログを組み合わせます。

規制とガバナンス

規制は地域、用途、提供者か利用者かで義務が変わります。EU AI Act（欧州連合のAI法）はリスクに応じて禁止、透明性、高リスク用途などの規則を定め、高リスクシステムにはリスク管理、データ品質、記録、文書化、人の監督などを求めます。日本では経済産業省などがAI事業者ガイドラインを公表しています。運用では対象法令と契約を法務と確認し、用途、モデル・データの出所、評価結果、承認者、変更、事故対応を監査ログに残します。EUでの提供や利用が関係する場合は、EU AI Actの原文と欧州委員会の最新案内を確認します。

倫理とバイアス

バイアスは、学習データや設計の偏りによって、特定の属性や表現に不公平な結果が出ることです。利用者の属性や言語表現を変えた対になるテスト例を作り、拒否率、誤り方、推奨内容の差を確認します。差が見つかったら、データの構成、ラベル基準、プロンプト、後段の判定のどこで生じたかを切り分けます。属性を記録すること自体にリスクがあるため、収集目的、同意、保存期間、閲覧権限を先に定め、影響を受ける部門や利用者が異議を伝えられる窓口も用意します。

似た言葉の整理（GenAIOps／AIOps／LLMO・GEO）

GenAIOpsは、文章だけでなく画像や音声などを含む生成AIアプリケーション全体の開発・運用を扱う考え方で、LLMOpsはそのうちLLMの運用に焦点を当てます。AIOpsはAIを使ってシステム障害の検知やIT運用を助ける考え方で、AIそのものを運用するLLMOpsとは目的が違います。LLMO（大規模言語モデル最適化）やGEO（生成エンジン最適化）は、自社情報を生成AIに理解・引用されやすくする取り組みです。生成する側の品質を管理するLLMOpsと、引用される側の情報を整えるLLMO・GEOを混同しないことが要点です。

モデルの切り替え運用

モデル名をコードの各所へ直接書かず、共通の呼び出し口を持つ抽象化レイヤーを置くと、提供元やモデルを切り替えやすくなります。ただし、同じ指示でも対応する入力長、機能、拒否の基準、出力形式は異なるため、接続先を変えるだけでは互換になりません。切替候補ごとに機能一覧と代替経路を持ち、評価用データ、応答時間、トークン量、安全性、構造化出力の崩れを自動回帰テストで比較します。障害時の切替では、品質基準を満たさないモデルへ無条件に流さず、機能停止や人への引き継ぎも選択肢にします。

導入のステップ

導入は、対象業務と現在の入力、出力、担当者、失敗時の影響を棚卸しするところから始めます。次に代表例と失敗例を評価用データにし、プロンプトと実行設定を一元管理し、重要な評価指標を少数に絞ります。そのうえで小さな利用範囲へ出し、実行の追跡、利用者の反応、費用、事故を集めて改善へ戻します。最後に承認、監視、切り戻し、担当者を決めて対象を広げます。各段階の終了条件を成果物で定めると、「試作は動くが本番に移れない」を避けられます。

費用対効果をどう見るか

費用対効果は、AIの利用料だけでなく、運用全体の増減で見ます。便益は、削減できた作業時間×対象件数×人件費、処理待ちの短縮、誤りや手戻りの減少などに分けます。費用には推論、検索・保存基盤、評価、監視、人の確認、データ整備、障害対応を含めます。導入前の作業時間と品質を基準にし、導入後も人の修正時間を差し引きます。「利用回数」ではなく、完了した業務1件あたりの総費用と合格率を並べれば、速くても直しが増えた改善を見抜けます。

トレーシング（実行の追跡）

トレーシングは、1回の要求がどの処理を通り、何を入力し、どのモデルや検索、外部ツールを使い、どこで失敗したかを追うことです。各工程に共通の実行IDを付け、プロンプト版、モデル、検索結果、応答時間、トークン量、評価結果を時系列で結びます。これにより「回答が悪い」を、検索漏れ、指示の欠落、外部APIの失敗、モデル出力の問題へ分解できます。本文や個人情報を無制限に残さず、伏せ字、保存期間、閲覧権限を決めたうえで、失敗した実行から評価用データを再現できる粒度を残します。

エージェント型AIとの接続（MCPなど）

エージェント型AIは、LLMの判断を基に検索や外部システムの操作を組み合わせる仕組みです。MCP（Model Context Protocol）は、AIアプリケーションが外部のデータや道具へ接続するための共通仕様です。接続先が増えるほど、LLMの文章だけでなく、選んだ道具、渡した引数、戻り値、再試行も運用対象になります。各道具に許可する操作と入力形式を定め、更新や送信など戻せない操作は人の承認を挟み、実行履歴を追跡します。まず読み取り専用の1機能から接続し、失敗時に安全に止まることを試します。

プロンプトエンジニアリングの技法

プロンプトエンジニアリングは、LLMへの指示と文脈を設計することです。役割、目的、守る条件、入力、期待する出力形式を分け、曖昧な「うまく書く」を検査できる条件へ直します。few-shot（少数例示）は良い入出力の例を少数見せる方法、zero-shot（例なし指示）は例を与えず指示だけで解かせる方法です。複雑な仕事は、分類、検索、生成、検査の段階へ分けると失敗箇所を追えます。技法を追加するたびに評価用データを回し、例の丸写しや、例にない入力での悪化がないかを確かめます。

人材と体制

必要なのは肩書の数ではなく、責任の分担です。業務担当は正解と許容できない失敗を定め、開発担当はアプリケーションと接続を作り、データ担当は収集・品質・評価用データを管理し、基盤担当は配備、監視、障害対応を担います。セキュリティ・法務担当は権限、契約、規制を確認し、最終的なサービス責任者が公開と停止を判断します。小規模なら兼務できますが、評価基準の承認者と変更実施者を明記し、事故時の連絡先と代行者を運用表に残します。

自前で作るかAPIで済ますか

外部APIは試作と更新を速くしやすい一方、送信できるデータ、提供元への依存、利用制限、モデル変更への対応を確認する必要があります。自前運用はモデルや配置を制御しやすい一方、計算基盤、配備、監視、安全性、更新を継続して担う体制が要ります。判断軸は、データの機密性、必要な独自性、応答時間、想定負荷、利用条件、撤退のしやすさです。まずAPIと小さな評価用データで要件を確かめ、自前でなければ満たせない条件が明確になった時点で比較すると、基盤づくりが目的になるのを避けられます。

負荷試験とレート制限

負荷試験は、同時アクセスや長い入力が増えたときの応答時間、失敗率、トークン量、外部APIへの影響を確かめる試験です。通常時だけでなく、業務上想定するピーク、再試行が重なる状態、接続先が遅い状態を再現します。レート制限は、一定時間に受け付ける要求数やトークン量へ上限を設けることです。利用者・機能別の上限、待ち行列、段階的な縮退、再試行間隔を決め、上限超過を無限再試行にしません。公開前に、止める条件と利用者への案内まで含めて試します。

プロンプトを版として固定する項目

再現に必要なのは指示文だけではありません。システムプロンプト（全体の役割や制約を与える指示）とユーザープロンプト（個別の依頼）を分け、モデル名、参照データ版、利用できる道具、出力形式も固定します。temperatureは出力のランダムさを調整する値、top_pは次の語の候補を確率の範囲で絞る値、最大出力トークン数は回答の長さの上限です。未指定も設定として記録し、変更の大きさが分かる版番号、変更理由、評価結果、承認者、戻し先を同じ履歴へ残します。

オフライン評価とオンライン評価

オフライン評価は、本番へ出す前に固定した評価用データで品質、安全性、応答時間などを比べる方法です。変更案の回帰確認や候補モデルの比較に向きます。オンライン評価は、本番の利用状況で、利用者の反応、完了率、再質問、応答時間、事故などを観測する方法です。現実の変化を拾えますが、利用者へ影響が出るため、限定公開、停止条件、個人情報の扱いが必要です。オフラインで最低基準を通し、オンラインで想定外を集め、その例を次のオフライン評価へ戻す循環にします。

落とし穴・アンチパターン

典型的な落とし穴は、評価指標を増やしすぎて誰も確認しない、複数の変数を同時に変えて原因が分からない、成功例だけで試す、本番前の負荷試験を省く、モデル切替を接続確認だけで終えることです。また、LLMの採点だけを正解にする、ログへ機密を残しすぎる、失敗時の停止や人への引き継ぎを用意しない運用も避けます。対策は、重要な指標を少数に絞り、1回に1変更、失敗例を含む回帰テスト、限定公開、切り戻しを完了条件にすることです。

テスト手法の体系

テストは小さい範囲から並べます。ユニットテストはプロンプトや検索など1部品、統合テストはモデルと検索・外部APIの組み合わせ、E2E（端から端までの）テストは利用者の入力から最終処理までを確かめます。ストレステストは高負荷や遅延時、敵対的テストは指示の上書き、情報の持ち出し、有害な入力など意図的な攻撃を試します。各層で入力、期待する条件、担当者、実行時期を決め、下層で原因を絞り、上層で業務全体の見落としを拾います。

② そのとおりに作って、詰まる

保険会社のコールセンターで、応対記録をLLMで要約するシステムを作り、コールセンターで使い始め、直しを入れ始めてから詰まりが来ました。出てくる応対要約の質が、回によってブレる。良い回と悪い回があるのに、「その差がどこから来るのか」が分からない。

もっと困ったのは、変更の影響が読めないことでした。あるとき、応対要約の質を上げようとして、プロンプトの指示と、参照させる一次情報の台帳と、細かい設定を、数日のあいだに3つまとめて変えたことがあります。次のサイクルで要約は良くなりました。でも、3つのうちどれが効いたのか、まるで分かりません。逆に悪くなった回では、どれを戻せばいいのかが分からない。同じ入力を与えても毎回少しずつ違う出力が返る相手なので、「変更前後で出力を比べる」というソフトウェアのテストの型が、そもそも成立しないのです。

③ どう気づいたか

気づいたきっかけは、受け入れ判定に落ちた応対要約の記録を、まとめて読み返したことです。要約システムには合否の判定を組み込んであり、落ちた要約は上限3回まで自動で作り直されます。落ちた記録を並べてみると、落ち方に納得感のある回と、「これ、昨日は通った書き方では」という回が混ざっていました。成功した要約を眺めていても分からなかったことが、失敗作の山からは見えてきます。落ちた記録は、成功作より雄弁でした。

つまり、ブレていたのはエンジンだけではありませんでした。何を良しとするかの基準が僕の頭の中にあり、その日の目で判定が揺れていた。ぬか床でいえば、味見する舌のほうが日によって変わっていたわけです。エンジンの揺らぎと、基準の揺らぎ。2つの揺らぎが掛け算になっていたので、何を観測しても切り分けられなかったのです。

④ 原因を1つに特定

原因は、相手を決定的な機械だと思っていたことです。ソフトウェアは同じ入力に同じ出力を返すので、テストは1回通れば通ったことになります。LLMは確率的な部品で、同じ入力から毎回すこし違う出力が出る。だから「1回通ったか」には意味が薄く、意味があるのは「揺らぎを含めて、どの範囲に収まっているか」の観測です。

観測が要る相手に、僕は観測の道具を持っていませんでした。基準は頭の中、変更はまとめて、記録はチャットの流れの中。これでは何も切り分けられません。しかもこの思い込みは、ソフトウェア開発の経験が長いほど深く染みています。「テストが通れば安心してよい」という習慣は、決定的な機械と付き合ってきた年月が作った習慣だからです。

⑤ 直してみる — 1箇所だけ直す

直したのは1箇所、観測を機械に固定したことです。受け入れ判定を、人の目ではなく数えられる基準に置き換えました。手本にしたい応対要約10本から実測して作った基準で、本文に実測の数値が18個以上、現場の言い回しの引用が11個以上、話の向きを変える接続が千字あたり0.9回以上。あわせて運用のルールを2行だけ決めました。「変更は1回のサイクルに1つ」「サイクルごとに判定の数字を記録する」。プロンプトそのものも、1枚の長い呪文ではなく、部品に割って管理します。参照する台帳、判定の基準、書き方の指示を別々のファイルにしておくと、「今回変えた1つ」がファイル単位で特定できるからです。

これで、ぬか床の日誌と同じ構造になります。毎回味見し（判定）、記録が残り（ベースライン）、味がずれたら直前に変えた1つを疑えばよい。

⑥ あとで知った — すでに名前があった

あとで知りましたが、この一式には名前がありました。LLMOpsです。機械学習の運用論であるMLOpsから派生した言葉で、LLM特有の事情——プロンプトや参照データまで含めて管理が要ること、出力が確率的で評価の仕組みが別に要ること——を扱います。DatabricksやGoogleの解説が整理している中身は、プロンプトの版管理、評価、監視、デプロイの管理。僕が「判定の機械化」と呼んでいたものは評価（evals）で、「サイクルごとの記録」はまさに監視でした。一方で、MLOpsとの違いとして挙げられているのも、まさに②で踏んだ穴でした。従来の機械学習の運用はモデルが主役ですが、LLMの運用ではプロンプトも参照データも出力の評価も、全部が品質の変数になる。管理する対象が、モデルの外側へ大きくはみ出しているのです。

名前が付いている安心感は、思っていたより大きいものでした。自分の場当たり的な工夫だと思っていたものが、業界が同じ穴を踏んで整理した体系の一部だと分かると、次に何を整えるべきかの地図も手に入ります。

ひとつ注意も書いておきます。この分野の解説には「AIプロジェクトの何割が失敗する」といった定番の数字がよく出てきますが、出所と定義がばらつくので、僕は運用の根拠にしていません。根拠にできるのは、自分の記録だけです。新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか

コールセンターで加えた変更の影響が、数字で見えるようになりました。台帳を26件に増やした回、プロンプトの指示を差し替えた回、それぞれの前後で判定の数字がどう動いたかが記録に残ります。この形でサイクルを9回まわし、上限3回まで作り直される応対要約は目に見えて減りました。

ただ、代償も3つありました。1つ目、数字への最適化です。基準を機械化した瞬間、システムは「数字は満たすがつまらない記事」を書けるようになります。実際に監査で捕まえたのは、数値の個数だけ律儀に満たして、どの数字も応対の芯に絡んでいない要約でした。機械は個数を数えられますが、芯までは数えられません。だから人の抜き打ち監査は消せません。機械の判定と人の監査の二段構えは、手間として残り続けます。2つ目、変更を1回に1つに絞ると、直しの速度は確実に落ちます。まとめて変えたい誘惑とは、いまも戦っています。3つ目、基準そのものの保守です。手本が古びれば基準も古びるので、基準を作り直す仕事が定期的に発生します。

⑧ 現場で使うなら、この最小セット

LLMを業務に組み込むときの、運用の最小セットです。とはいえ専用の道具から入る必要はなく、道具を買う前に、この5行から始められます。

項目	中身
評価の機械化	良し悪しを数えられる基準に置き換える。頭の中に置かない。
変更は1回に1つ	プロンプト・参照データ・設定を同時に変えない。
ベースライン	実行のたびに評価の数字を記録する。比較の相手は前回の自分。
落ちた記録を読む	失敗した出力こそ、基準と現実のずれを教えてくれる。
人の抜き打ち監査	月1回、機械の判定を人の目で疑う。数字への最適化を捕まえる。

5行のうち、最初に効くのは2行目です。切り分けられない変更は、良くても悪くても学びがゼロになります。逆に、変更を1つに絞ってあれば、失敗したサイクルからも「これは効かない」という知見が1件残ります。

コストは、金額ではなく動かす変数で考える

推論費用はモデル名だけで決まりません。1件の処理で何回試すか、どれだけ長い文脈を渡すか、失敗時に何回再実行するかという変数で動きます。そこで実額を一般化するより、入力と出力の量、呼び出し回数、再実行率、待ち時間を処理単位で捉えます。長い資料を毎回すべて渡さず必要箇所を検索する、小さな処理に適したモデルを選ぶ、同じ結果を再利用するといった推論最適化も、この変数のどれを下げるかで判断できます。ただし、費用や応答時間を下げて評価が閾値を割るなら最適化ではないため、品質と一緒に見る必要があります。

ツールは、自前で追えなくなってから選ぶ

LLMOpsプラットフォームには、プロンプト管理、実行履歴、評価、監視などをまとめる役割があります。ただし、製品の導入がLLMOpsの開始条件ではありません。担当者が少なく、実行経路も単純で、版と評価の対応を既存のリポジトリや表で追える間は自前でも足ります。利用者、モデル、データ源、実行回数が増え、権限管理や横断検索を人手で保てなくなったところが専用ツールを検討する境界です。導入時は機能数より、機密データの保存先、閲覧権限、既存環境との接続、障害時の退避方法を先に確認します。ここから先は、実際に運用して詰まった話へ戻ります。

⑨ この考え方が効き続ける理由

確率的な部品を業務に組み込む限り、観測と記録の構造は消えません。モデルが賢くなれば出力の質は上がりますが、「何を良しとするか」を決めて観測する仕事は、賢いモデルほどむしろ重要になります。基準の無いまま賢い部品を入れ替えていくのは、味見をせずにぬか床の配合を変え続けるのと同じだからです。道具は増え続けるでしょうが、日誌の構造——味見、記録、1回に1つ——は、たぶん道具より長生きします。実際、この記事で書いた運用に専用のLLMOps製品は1つも使っていません。使ったのは、数えられる基準と、記録の習慣だけです。

余談ですが、帰省したときに母のぬか床の日誌を見せてもらったら、「今日は暑い。冷蔵庫へ」とだけ書かれた日がありました。夏場の高温という環境要因を検知し、退避先を判断して、ログを1行残す。環境の変化を観測して、変更を1つだけ入れて、記録している。実家の台所は、30年前からLLMOpsでした。以上です。

LLMOpsのよくある質問

LLMOpsとは何ですか？

LLMを業務で使い続けるための運用の仕組みです。まずは「何点なら合格か」を決めるところから始まります。

LLMOpsとMLOpsの違いは何ですか？

MLOpsはモデルが管理の中心、LLMOpsはプロンプト・参照データ・評価まで管理します。既存のMLOps基盤があっても、プロンプトの版管理は別途要ります。

LLMの運用でソフトウェアのテストが通用しないのはなぜですか？

出力が毎回すこし変わるためです。「通った／落ちた」ではなく、同じ入力セットを流して点数の分布で見ます。

LLMの評価（evals）はどう作ればよいですか？

手本にしたい出力を10件ほど集め、共通する条件を採点項目に起こすのが最初の一手です。以後は変更のたびに同じセットで採点します。

プロンプトの管理はどうすればよいですか？

コードと同じようにバージョン管理へ入れ、変更とセットで評価を回します。チャット欄で直して終わりにしないことが肝心です。

LLMOpsに専用ツールは必要ですか？

最初は不要です。記録用のスプレッドシートと評価スクリプトで始め、実行回数が増えて追えなくなったら専用ツールを検討します。

LLMの出力品質がブレるのはなぜですか？

確率的に文章を組み立てる仕組みだからです。ブレ自体は消せないので、許容範囲を決めて監視する側で受け止めます。

モデルが賢くなればLLMOpsは不要になりますか？

なりません。モデルが変わるたびに「前と同じ品質か」を確かめる仕事はむしろ増えます。切り替え時こそ評価セットが効きます。