LLMアプリを本番で回し続けるための監視・オブザーバビリティ・SRE書籍ガイド｜evalの前に固める土台の4冊

LLMを組み込んだ機能を本番に出したあと、最初の1か月でよく出てくる質問があります。「昨日のあの回答、なぜあんな出力になったんですか」「今、正常なんですか」。この2つに数分で答えられないチームは、たいていLLM固有のトレーシングやevalが足りないのではなく、その手前にある監視の設計、サービスレベルの定義、障害対応の型が無い状態でLLMだけを載せています。この記事では、監視・オブザーバビリティ・SREを学べる実在の日本語書籍を4冊、段階順に紹介します。なお本記事は書籍紹介であり広告を含みます。価格・版・在庫・目次は変わるため、最新は各出版社の公式ページでご確認ください。

LLM固有の問題に見えて、実は昔からある運用の問題です#

LLMアプリの運用相談を聞いていると、症状の言葉づかいだけが新しく、中身は古典的な運用課題だという場面によく出会います。「回答の品質が落ちた気がする」は、計測されていない品質指標の話です。「たまに遅い」は、平均値しか見ていないレイテンシの話です。「原因が分からない」は、リクエスト単位で経路をたどれる計装が無いという話です。

もちろんLLM固有の難しさは確かにあります。同じ入力でも出力が揺れる、失敗が例外ではなく「もっともらしいが誤った文章」として出る、コストが呼び出しごとに変動する。ただ、これらに手を付ける前提として、そもそもリクエストの流れが見えて、異常を検知できて、検知したら誰かが動く、という土台が必要です。土台が無いままLLM専用の観測ツールだけ入れると、ダッシュボードは増えるのに判断は増えないという状態になります。

止まっているチームに出ている症状#

止まっているチームの症状は、だいたい次のどれかに当てはまります。どれもLLM以前から存在する、監視と運用の設計の問題です。

• 「正常」の定義が無い。サーバーが起動していることは分かるが、ユーザーから見て使える状態かは誰も測っていません
• アラートがメールとチャットに流れ、誰も見ていない。鳴っても動かない通知は、監視ではなく背景音です
• 平均値だけを見ている。平均レイテンシが2秒でも、95パーセンタイルが30秒なら体験は壊れています
• ログが非構造化で、grepでしか追えない。リクエストIDが通っておらず、複数サービスをまたいだ1回の処理を再構成できません
• 障害のたびに人が変わり、同じ手順を毎回思い出している。手順書が無く、暗黙知が個人に貯まります
• 振り返りが犯人探しになる。二度と同じ話が共有されず、次の障害でまた同じ場所を踏みます
• 運用の担当が「その他」扱いで、割り込みが誰にも計上されていない。改善に使える時間が構造的にゼロになります

4段階で読む順番を決める#

監視とSREの本は同じ棚に並んでいても前提が違います。監視の作法が無いのか、原因を追う計装が無いのか、組織として誰がやるか決まっていないのか、原則の出典が欲しいのかで、必要な本が変わります。

以下、この順で4冊を紹介します。守備範囲は重なりますが、通読前提の並びではありません。症状から選ぶための対応表は記事の後半に置いてあります。

1. 監視の作法を身につける(入門 監視)#

1冊目は、システムのどの部分をどのように監視すべきか、監視をどう改善していくかを扱う本です。Mike Julianさんの著書で、松浦隼人さんの訳、オライリー・ジャパンから2019年1月17日に刊行されました。228ページ、原著は『Practical Monitoring』です。公式の書誌ページでは、前半で監視のベストプラクティスとデザインパターンおよびアンチパターンを示して監視の基本原則を説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで監視の基盤を設計し実装する方法を示す、と説明されています。日本語版には松木雅幸さんによる監視SaaSの導入や活用方法が付録として収録されています。

構成は2部11章と付録3本です。第I部「監視の原則」が1章監視のアンチパターン、2章監視のデザインパターン、3章アラート、オンコール、インシデント管理、4章統計入門。第II部「監視戦略」が5章ビジネスを監視する、6章フロントエンド監視、7章アプリケーション監視、8章サーバ監視、9章ネットワーク監視、10章セキュリティ監視、11章監視アセスメントの実行。付録Aが手順書の例、付録Bが可用性表、付録Cが実践・監視SaaSです。

LLMアプリの文脈で最初に効くのは1章です。アンチパターン1「ツール依存」、アンチパターン2「役割としての監視」、アンチパターン3「チェックボックス監視」、アンチパターン4「監視を支えにする」、アンチパターン5「手動設定」が並びます。とくに3番目の中にある「『動いている』とはどういう意味か。『動いている』かどうかを監視しよう」という節と、「アラートに関しては、OSのメトリクスはあまり意味がない」という節は、LLM機能を載せたチームがそのまま踏む落とし穴です。プロセスが生きていてCPUに余裕があっても、回答が的外れならユーザーにとっては動いていません。

2章のデザインパターン2「ユーザ視点での監視」も同じ方向です。内部のコンポーネントごとの死活ではなく、ユーザーが実際に受け取る体験から監視を組み立てるという発想は、そのままLLMアプリの成功率やレイテンシの定義につながります。

3章はアラート設計の実務です。「アラートにメールを使うのをやめよう」「手順書を書こう」「固定の閾値を決めることだけが方法ではない」「アラートを削除し、チューニングしよう」「まずは自動復旧を試そう」といった節が並び、オンコールローテーションの組み方と振り返りまで扱います。LLM機能は外部APIへの依存が強く、提供側の障害やレート制限で自分たちのサービスが揺れます。何を人に起こし、何を自動リトライで吸収するかを決める作業は、この章の枠組みでそのまま整理できます。

4章「統計入門」も地味に効きます。meanとaverage、中央値、周期性、分位数、標準偏差が扱われており、LLMアプリのレイテンシのように分布が大きく右に裾を引く指標を平均で語ることの危うさが理解できます。

扱っていない範囲も書いておきます。刊行が2019年で、分散トレーシングやOpenTelemetryはほとんど扱われていません。8章から10章はサーバ、ネットワーク、セキュリティの監視項目のカタログ的な内容で、フルマネージドのサービス構成中心のチームには使わない節が出ます。当然ながらLLM固有の指標もこの本の範囲外です。ここは2冊目と、LLM観測の記事で補ってください。

入門 監視 ―モダンなモニタリングのためのデザインパターン(オライリー・ジャパン)

広告

著者: Mike Julian / 訳: 松浦隼人 / 出版社: オライリー・ジャパン / 2019年1月刊 / 228ページ。原著は『Practical Monitoring』。監視の原則と監視戦略の2部11章で、アンチパターン、デザインパターン、アラートとオンコール、統計、ビジネスKPIの監視までを扱います。日本語版には監視SaaSの付録が収録されています。分散トレーシングやOpenTelemetry、LLM固有の指標は扱っていません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

2. なぜを追える計装にする(オブザーバビリティ・エンジニアリング)#

2冊目は、クラウドベースのソフトウェアシステムにおけるオブザーバビリティ(可観測性)を、定義から実践、組織への適用まで扱う本です。Charity Majorsさん、Liz Fong-Jonesさん、George Mirandaさんの著書で、大谷和紀さんと山口能迪さんの訳、オライリー・ジャパンから2023年1月27日に刊行されました。336ページ、原著は『Observability Engineering』です。公式の書誌ページによれば、Slackのゲスト寄稿による、テストとデプロイのプロセスへの応用事例も収録されています。

構成は5部22章です。第I部「オブザーバビリティへの道」(1章から4章)がオブザーバビリティの定義、モニタリングとのデバッグ方法の違い、スケーリングからの教訓、DevOps・SRE・クラウドネイティブとの関連。第II部「オブザーバビリティの基礎」(5章から9章)が構造化イベント、イベントをトレースにつなぐ、OpenTelemetryを使った計装、イベント解析、モニタリングとの関係。第III部「チームのためのオブザーバビリティ」(10章から14章)がチームへの適用、オブザーバビリティ駆動開発、サービスレベル目標、SLOベースのアラート、ソフトウェアサプライチェーン。第IV部「大規模なオブザーバビリティ」(15章から18章)が投資収益性、データストア、サンプリング戦略、テレメトリーパイプライン。第V部が文化の拡大です。

LLMアプリに直結するのは第II部です。5章「構造化イベントはオブザーバビリティの構成要素である」は、メトリクスと従来のログの限界を示したうえで、デバッグに役立つイベントのプロパティを扱います。1章には「カーディナリティの役割」「ディメンションの役割」という節があり、ユーザーIDやリクエストIDのように取りうる値が非常に多い属性を捨てずに持つことの意味が説明されます。LLMアプリの調査は「特定の1リクエストで何が起きたか」から始まることがほとんどで、事前に集計してしまった数字からはこの問いに答えられません。

6章「イベントをトレースにつなぐ」と7章「OpenTelemetryを使った計装」は、RAGの検索、リランキング、ツール呼び出し、モデル呼び出しが連なるLLMアプリの構造とそのまま噛み合います。自動計装から始めてカスタム計装を足す、という7章の進め方は、既存のWebアプリにLLM機能を後付けする状況に合います。なおLLM向けの属性名については、OpenTelemetry側でGenAI向けのsemantic conventionsが専用リポジトリに分離されて開発が続いており、GenAIクライアントやMCPを対象としたspan・metrics・eventsの規約が整備されています。規約自体が動いている領域なので、採用時は最新の定義を確認してください。

12章「サービスレベル目標の信頼性向上への活用」と13章「SLOベースのアラートへの対応とデバッグ」も重要です。12章にはしきい値アラートが既知の未知にしか対応できないこと、ユーザー体験を道しるべにすることが述べられ、13章ではエラーバジェットが枯渇する前にアラートを出すという考え方と、時間をスライディングウィンドウとして捉える方法、バーン予想アラートの作り方が扱われます。この発想はGoogleのThe Site Reliability Workbookにも「Alerting on SLOs」として整理されていて、バーンレートをSLOに対するエラーバジェットの消費速度として定義し、長短2つのウィンドウを組み合わせる方法が推奨されています。オンライン版が公開されているので、書籍と読み比べられます。

17章「安価で十分な精度にするためのサンプリング戦略」は、LLMアプリの観測コストに直結します。プロンプトと応答を含むイベントは1件あたりのサイズが大きく、全件を長期保管すると保管費用が無視できません。一定確率、直近のリクエスト量に応じたもの、イベントの内容(キー)に基づくものといった手法の使い分けが具体的に説明されており、「失敗したトレースは全部残し、成功は一部だけ残す」といった方針を設計する材料になります。

扱っていない範囲も明確です。本書は考え方と設計の本で、特定ツールの操作手順書ではありません。また8章に「AIOpsの誤解を招く約束」という節があるとおり、機械学習で原因分析を自動化するという触れ込みには距離を置いています。刊行は2023年1月で、生成AIやLLMの活用を扱う本ではありません。LLM固有の評価やプロンプト管理も範囲外で、そこは別の道具が要ります。1冊目の監視の基礎を飛ばしてここから入ると、「なぜ従来のモニタリングでは足りないのか」という本書の出発点が実感を伴わないまま進むおそれがあります。

オブザーバビリティ・エンジニアリング(オライリー・ジャパン)

広告

著者: Charity Majors、Liz Fong-Jones、George Miranda / 訳: 大谷和紀、山口能迪 / 出版社: オライリー・ジャパン / 2023年1月刊 / 336ページ。原著は『Observability Engineering』。構造化イベント、分散トレース、OpenTelemetryを使った計装、SLOベースのアラート、サンプリング戦略、テレメトリーパイプラインを5部22章で扱います。Slackの事例も収録。特定ツールの操作手順やLLM固有の評価・プロンプト管理は扱っていません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

3. 信頼性の取り組みを個人と組織で始める(SREをはじめよう)#

3冊目は、SRE(サイトリライアビリティエンジニアリング)について、個人がSREになるための指針と、組織がSREを導入し発展させるための方法を解説する本です。David N. Blank-Edelmanさんの著書で、山口能迪さんの訳、オライリー・ジャパンから2024年10月8日に刊行されました。320ページ、原著は『Becoming SRE』です。同書の訳者まえがきでは、日本では『SRE サイトリライアビリティエンジニアリング』が出版された頃からSREが広く知られるようになった一方で、名称だけが独り歩きし、本来意図するところとは違った取り組み方になっている事例も見受けられる、という背景が説明されています。

構成は3部18章と付録3本です。第I部「SRE入門」(1章から4章)がSREとは何か、SREの心構え、SREの文化、SREについて語る。第II部「個人がSREをはじめるには」(5章から10章)が準備、なり方、採用、SREのある一日、トイルとの関係、失敗から学習する。第III部「組織がSREをはじめるには」(11章から18章)が成功のための組織的要因、SREはいかにして失敗するか、ビジネス視点からのSRE、Dickersonの信頼性の階層構造、組織への組み込み、進化段階、成長、おわりにです。

この本を3番目に置いた理由は、14章「Dickersonの信頼性の階層構造(良い出発点)」にあります。階層1が監視/オブザーバビリティ、階層2がインシデントレスポンス、階層3がインシデント後のレビュー、階層4がテスト/リリース(デプロイ)、階層5がプロビジョニング/キャパシティプランニング、階層6と7が開発プロセスと製品設計、という積み上げの順序が示されます。LLMアプリの運用で「evalを整えたい」「品質を上げたい」という話は、この階層で言えばかなり上のほうです。下の階層が空いたまま上を積もうとして苦しんでいる、という自己診断ができるだけでも読む価値があります。

12章「SREはいかにして失敗するか」も実務的です。失敗要因1「SRE創設のための肩書きフリップ」、失敗要因2「3次サポートのSRE化」、失敗要因3「オンコール、以上」、失敗要因6「ゲートキーパー(門番)」といった節が並びます。LLM機能の運用でも似た構図は起きます。開発チームが作った機能の運用だけを別の担当に投げると、プロンプトやモデル設定を変えられない人が問い合わせだけを受ける状態になり、改善が止まります。

9章「トイルとの関係を築く」と10章「失敗から学習する」も、この段階で読むと効きます。10章はインシデント後のレビューの基本、プロセス、よくある罠を扱っており、レビューが犯人探しになって学習が蓄積しないという症状に直接効きます。LLMアプリは「なぜその出力になったか」の完全な説明が難しい場面があるため、原因を1つに特定できなくても学びを残す進め方が特に重要になります。

扱っていない範囲は、技術の実装詳細です。この本はSREという取り組みの始め方と定着のさせ方が主題で、SLIやSLOの計算方法、監視基盤の構築手順、コード例は主眼ではありません。すでにSREチームが機能していて、必要なのはSLOの具体的な設計だという段階なら、4冊目やThe Site Reliability Workbookのほうが近道です。

SREをはじめよう ―個人と組織による信頼性獲得への第一歩(オライリー・ジャパン)

広告

著者: David N. Blank-Edelman / 訳: 山口能迪 / 出版社: オライリー・ジャパン / 2024年10月刊 / 320ページ。原著は『Becoming SRE』。SRE入門、個人がSREをはじめるには、組織がSREをはじめるにはの3部18章。Dickersonの信頼性の階層構造、トイル、インシデント後のレビュー、SREが失敗する典型パターン、組織への組み込みモデルを扱います。SLOの計算方法や監視基盤の構築手順、コード例は主眼ではありません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4. 原則を体系として引けるようにする(SRE サイトリライアビリティエンジニアリング)#

4冊目は、Googleで培われたシステム管理とサービス運用の方法論をまとめた、いわゆるSRE本です。Betsy Beyerさん、Chris Jonesさん、Jennifer Petoffさん、Niall Richard Murphyさんの編で、澤田武男さん、関根達夫さん、細川一茂さん、矢吹大輔さんの監訳、Sky株式会社の玉川竜司さんの訳、オライリー・ジャパンから2017年8月12日に刊行されました。590ページ、原著は『Site Reliability Engineering』です。

構成は5部34章と付録6本です。第I部イントロダクション、第II部原則(3章リスクの受容、4章サービスレベル目標、5章トイルの撲滅、6章分散システムのモニタリング、7章Googleにおける自動化の進化、8章リリースエンジニアリング、9章単純さ)、第III部実践(10章時系列データからの実践的なアラート、11章オンコール対応、12章効果的なトラブルシューティング、13章緊急対応、14章インシデント管理、15章ポストモーテムの文化(失敗からの学び)、17章信頼性のためのテスト、21章過負荷への対応、22章カスケード障害への対応など)、第IV部管理、第V部まとめです。

分厚い本ですが、LLMアプリの運用で引くべき章は限られます。まず4章「サービスレベル目標」です。原著のオンライン版では、SLIをサービスレベルの定量的な指標、SLOをそのSLIに対する目標値、SLAをユーザーとの契約として整理し、SLOはできるだけ少なくすること、そして過剰達成を避けること(実績がSLOを大きく上回るとユーザーがその実績に依存してしまう)が推奨されています。LLM機能に置き換えると、まず何をSLIにするかが議論になります。応答が返ったこと(可用性)なのか、規定時間内に返ったこと(レイテンシ)なのか、内容が妥当だったこと(品質)なのか。最初の2つは既存の枠組みで測れますが、3つ目はeval側の仕事になります。この線引きを最初にやっておくと、後の議論が短くなります。

3章「リスクの受容」はエラーバジェットの出典です。100%を目指さず、許容できる不信頼性の量を予算として扱い、その範囲で変更速度を上げるという考え方が示されます。LLMアプリは出力が確率的に揺れるため、「失敗ゼロ」を前提にすると何も出せません。許容できる失敗率を先に合意し、その中で改善を回すという枠組みは相性が良いはずです。

6章「分散システムのモニタリング」も引く価値があります。オンライン版では、監視すべき4大シグナルとしてレイテンシ、トラフィック、エラー、飽和度が挙げられ、レイテンシは成功したリクエストと失敗したリクエストを区別すべきだとされています。また症状(何が壊れているか)と原因(なぜ壊れているか)の区別、ブラックボックス監視とホワイトボックス監視の使い分けも整理されています。ページを出す基準として、緊急に対応でき、実行可能で、ユーザーが負の影響を受けていることを明確に示すか、といった問いも示されます。

14章「インシデント管理」と15章「ポストモーテムの文化」は、障害対応の型そのものです。14章は責任の分離、明確な司令所、ライブインシデント状況ドキュメント、はっきりとした引き継ぎという要素を扱い、15章はGoogleにおけるポストモーテムの哲学、コラボレーションと知識の共有、ポストモーテムの文化の導入を扱います。付録Cにインシデント状況ドキュメントの例、付録Dにポストモーテムの例が付いているので、自社のテンプレートを作るときの下敷きになります。

なお、この本の原著(英語)はsre.google上で公開されており、章立てと本文をオンラインで読めます。手元に置く前に該当章だけ確認する、という使い方もできます。

扱っていない範囲は、Google固有の前提と現代のクラウド事情です。2章はGoogleのプロダクション環境の説明で、BorgやBigtableといった自社基盤が前提になります。19章から26章のロードバランシング、分散合意、データパイプラインなどは規模が大きく、小さなチームがそのまま適用できる内容ではありません。刊行が2017年なので、OpenTelemetryやサーバーレス中心の構成、そして当然ながらLLMは扱われていません。通読より、必要な章を引く辞書として持つほうが実用的です。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム(オライリー・ジャパン)

広告

編: Betsy Beyer、Chris Jones、Jennifer Petoff、Niall Richard Murphy / 監訳: 澤田武男、関根達夫、細川一茂、矢吹大輔 / 訳: Sky株式会社 玉川竜司 / 出版社: オライリー・ジャパン / 2017年8月刊 / 590ページ。原著は『Site Reliability Engineering』。5部34章で、リスクの受容とエラーバジェット、サービスレベル目標、トイルの撲滅、分散システムのモニタリング、オンコール、インシデント管理、ポストモーテムの文化を扱います。Google固有の基盤を前提にした章が多く、OpenTelemetryやLLMは扱っていません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4冊の使い分け#

役割と症状から選ぶための対応表です。刊行時期は、概念そのものより周辺技術の前提がどれくらいずれるかの目安として見てください。

多くのチームにとって最初の1冊は『入門 監視』です。監視は一応あるが原因が追えない、という段階なら2冊目から入っても構いません。3冊目は組織の話が主なので、1人で試している段階では優先度が下がります。4冊目は通読ではなく辞書として置くのが現実的です。

書籍では埋まらない、LLM固有の部分#

4冊のいずれもLLMアプリの本ではありません。土台を整えたあとに残るのが、次の3つです。

失敗が例外として現れない#

通常のWebアプリなら、失敗は例外やHTTPの5xxとして現れます。LLMアプリの失敗の多くはステータス200で返る、もっともらしいが誤った出力です。エラー率だけを見る監視は、この種類の失敗をまったく捉えません。ここを埋めるには、出力に対する評価(eval)を作り、その結果を継続的に取る仕組みが要ります。ゴールデンセットに対する定期実行、本番トラフィックの一部に対する自動採点、ユーザーからの否定的フィードバックの計上といった手段が必要になります。

トークンとコストが第5のシグナルになる#

Googleの4大シグナルはレイテンシ、トラフィック、エラー、飽和度です。これはLLMアプリでもそのまま使えますが、加えてリクエストあたりの入出力トークン数と推定コストも見ておくことをおすすめします(4大シグナルに5つ目が加わったという話ではなく、本記事としての追加提案です)。理由は単純で、機能追加やプロンプト変更で入力トークンが増えても、レイテンシとエラー率にはほとんど変化が出ないまま請求額だけが伸びるからです。プロンプトのバージョン、モデルID、ツール呼び出し回数を属性として持ち、リリースの前後で比較できるようにしておくと、後から原因を特定できます。

変更の単位がコードだけではない#

通常のアプリなら、挙動が変わる原因はデプロイです。LLMアプリでは、プロンプトの変更、参照ドキュメントの更新、モデル側のアップデート、ツール定義の変更、いずれも挙動を変えます。しかもモデル側の更新は自分たちのデプロイ履歴に現れません。何をバージョン管理し、何を観測イベントの属性として残すかを最初に決めておかないと、「先週と同じコードなのに結果が違う」という調査で時間を溶かします。

読む順の目安#

書籍を読み終えてから運用を作ろうとすると、たいてい着手できません。いま動いているものに小さく足していくほうが現実的です。

この7つのうち、どこで手が止まったかで読むべき本が決まります。1と2で止まるなら1冊目、3と5なら2冊目、4と6ならSRE本、そもそも誰がやるか決まらないなら3冊目です。

よくある質問#

まとめ#

LLMアプリの運用が苦しいとき、原因はモデルやプロンプトではなく、その下にある監視と運用の土台にあることが少なくありません。何を正常とするかが決まっていない、鳴っても誰も動かない、原因を追う手段が無い、障害から学びが残らない。これらはLLM以前から知られている問題で、対処の型も長く蓄積されています。

今回紹介した4冊は守備範囲が違います。監視の作法を身につける本、イベントとトレースで原因を追えるようにする本、信頼性への取り組みを個人と組織で始める本、原則を体系として引く本。いずれも生成AIの本ではありませんが、だからこそモデルが何世代変わっても使えます。全部を読む必要はありません。いま手が止まっている場所に対応する1冊を選び、動いているアプリに小さく足していくところから始めてみてください。