社内でLLM（大規模言語モデル）を使ったアシスタント機能や自動化ワークフローを本番投入する段になると、必ず出てくる問いがあります。既存の監視基盤をそのまま流用できるのか、それとも専用の運用レイヤーを新たに構築すべきなのか、という判断です。
この記事は、オンプレやクラウドの運用監視基盤を担当しているSRE・インフラエンジニアで、AIを使った機能をシステムに組み込むことになった方に向けて書きます。プロンプト（AIモデルへの指示文）の工夫だけで乗り切れる段階を過ぎ、障害対応や根本原因分析の設計を求められている状況を想定します。判断材料の整理として参考になれば幸いです。
なぜ「プロンプトを直せば直る」が通用しなくなるのか
CRM（顧客管理システム）で、商談メモを読ませて次のアクションを提案させる機能を例に考えます。
プロンプトの精度をいくら上げても、モデルが参照すべき過去の商談履歴が別システムにあり取得できていなければ、提案は的外れになります。あるいは、モデルは形式として正しいJSONを返していても、そこに書かれたビジネス判断そのものが間違っているケースもあります。
これは「プロンプトの失敗」ではなく「システムの設計不足」です。モデルはユーザーからの入力と、業務システム側のコンテキスト（周辺情報）・ツール呼び出し・検証ロジック・業務ルールの間に挟まる一部品にすぎません。つまり監視すべき対象は、モデルの応答品質だけでなく、その前後にあるデータ連携・実行制御・失敗処理の一連の流れ全体になります。
この構造の変化は、運用監視の設計にも直接影響します。既存のAPM（アプリケーション性能監視）やログ基盤だけで足りるのか、専用の観測レイヤーが要るのか。ここからは判断軸を順に見ていきます。
判断軸1: 障害の「再現性」をどこまで求められるか
通常のマイクロサービスなら、同じ入力・同じコードなら同じ結果が返ります。障害調査はログとトレースIDを追えば大抵たどり着けます。
LLMを組み込んだシステムでは、同じ入力でも応答が毎回微妙に変わることがあります。モデルのバージョンが同じでも、温度パラメータ（応答のばらつきを決める設定値）や外部検索結果の変化で出力が変わるためです。
一度しか起きなかった失敗を、あとから同じ手順で再現できるかどうかが最初の分岐点になります。再現性を求める度合いが高い業務（金融・医療関連の判断支援など）ほど、入出力とコンテキストをすべて記録するトレーシング（処理経路の追跡記録）の仕組みが必須になります。
判断軸2: 失敗の粒度をどこまで切り分けたいか
既存のAPMは「レスポンスタイムが遅い」「5xxエラーが出た」といったインフラ・アプリケーション層の異常検知には強みがあります。
一方でAIを含むワークフローの失敗は、もっと細かい粒度で起きます。モデルの応答自体は正常でも、後段のツール呼び出しが誤ったものを選んだり、バリデーション（検証処理）で弾かれるべき出力が通過したりします。
- モデル呼び出し自体のレイテンシとエラー率
- 検索・ツール呼び出しの成否と応答内容
- 出力バリデーションでの弾かれ率
- 業務ルール適用後の最終結果の妥当性
この4段階を分けて観測できないと、「AIが原因」という雑な結論で終わってしまい、根本原因分析が進みません。
判断軸3: 評価(Evaluation)の運用体制を作れるか
LLMOps（LLMアプリケーションの運用管理）の文脈でよく出てくるのが評価パイプラインです。これはモデルやプロンプトを変更した際に、既存の正解データセットに対して自動でスコアを取り、劣化していないか確認する仕組みです。
CI/CD（継続的インテグレーション・デリバリー）にテストコードを組み込むのと似た発想ですが、対象がコードではなく確率的な出力である点が違います。この評価基盤を回せる人員・データが社内にあるかどうかで、選べる運用方法が変わります。
評価データセットも評価担当者もいない状態で本番投入すると、モデル更新のたびに「なんとなく悪くなった気がする」という感覚頼みの判断になりがちです。
判断軸4: コストの見え方が変わることを許容できるか
クラウド移行の際にコスト管理で悩んだ経験がある方なら想像しやすいと思いますが、LLM呼び出しのコストはトークン数（処理する文字列の単位）と呼び出し回数に応じて変動します。
サーバーの台数やインスタンスタイプで見積もれていた従来のコスト管理とは勝手が違い、リクエスト内容によって単価が変わる従量課金の変動幅が大きくなります。
コスト監視ダッシュボードを既存のクラウド請求ベースの仕組みだけに頼ると、モデル呼び出しごとの内訳が見えず、想定外の高額請求に気づくのが遅れる恐れがあります。
選択肢の比較
既存の監視基盤を拡張するか、AI専用の観測レイヤーを新設するか、大きく3つの選択肢があります。
| 選択肢 | 向いている状況 | 弱点 |
|---|---|---|
| 既存APM/ログ基盤の拡張のみ | 単純なAI機能、失敗しても人が最終判断する運用 | モデル呼び出し単位の粒度が取れない |
| LLM専用トレーシングツールを追加導入 | 複数のAI機能を横断的に運用する組織 | 既存監視との二重管理・学習コスト |
| 自前でログ・評価パイプラインを構築 | 業務要件が特殊で汎用ツールでは足りない場合 | 構築・保守の工数が継続的にかかる |
ケース別の推奨
- 単発のAI機能で、結果に必ず人が目を通してから実行する運用なら、既存のAPMとログ基盤の拡張で十分です。トレースIDにモデル名とプロンプトバージョンをタグ付けするだけでも根本原因分析の助けになります。
- 複数のAI機能を並行運用し、失敗の切り分けに時間がかかっている状況なら、LLM専用のトレーシングツール導入を検討する段階です。入出力とコンテキストの記録、評価スコアの推移を一元管理できる基盤があると、モデル更新時の劣化検知がしやすくなります。
- 業務ルールや承認フローが複雑で、汎用ツールのスキーマに収まらない場合は、自前のログ・評価パイプライン構築が現実的な選択になります。ただし継続的な保守工数を最初から見込んでおく必要があります。
あえて見送るべき条件
以下に当てはまる場合は、専用の観測レイヤーへの投資を急ぐ必要はありません。
- AI機能がまだ社内検証段階で、本番の障害対応フローに載っていない
- 呼び出し回数が少なく、既存ログの目視確認で十分対応できている
- モデル呼び出しの前後にあるツール連携が単純で、失敗パターンが1〜2種類に限られる
こうした段階で高機能な観測基盤を先に導入すると、運用者の学習コストだけが先行し、実際の障害対応には結びつきません。まずは既存ログにモデル関連のタグを足すところから始めるのが現実的です。
導入前に確認すること
判断に迷ったら、まず自分たちのAI機能が「モデル呼び出し」「ツール実行」「業務ルール適用」の3層に分けて観測できているかを確認してください。
分けられていないなら、既存のログ基盤にモデル名・プロンプトバージョン・トークン数のタグを追加するところから始められます。
評価パイプラインが未整備なら、まずは代表的な入力パターン10〜20件程度の正解データセットを用意し、モデル更新前後で手動比較するだけでも根本原因分析の手がかりになります。
コスト監視は、クラウド請求ベースの数字だけでなく、モデルAPI提供元のダッシュボードでトークン単位の内訳を定期的に確認する習慣をつけておくと、想定外の請求増に早く気づけます。