← エピソード一覧に戻る Episode 170 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 顧客より先に異変に気づけるか
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発の可観測性を扱います。Stripe では 16,000 を超える決済関連変数を見ながら、数万単位の監視断面を回しています。ここまでやる理由は、派手な監視画面を作るためではありません。
ミカ
ミカです。16,000 って、もう見ているというより見張っている感じですね。でも確かに、SaaS って一部の顧客だけで起きる不調がいちばん怖そうですし、平均が無事でも現場はぜんぜん無事じゃないことがありますよね。
タカシ
その通りです。前回のテスト自動化が壊しにくくする予防だとすれば、可観測性は壊れた時に誰が、どこで、どれだけ困っているかを最短で見抜く仕組みです。SaaS では障害検知の遅さが、そのまま解約やサポート負荷に変わります。
ミカ
なるほど。ログを見る技術の話というより、顧客から問い合わせが来る前に異変へ気づけるか、という経営の話なんですね。今日はその視点で、何を観測して、どこで失敗しやすいのかを知りたいです。
Chapter 2 原則 ― 技術指標だけではSaaSを守れない
タカシ
Google Cloud は observability の基本を、metrics、logs、traces の三つで整理しています。ただし重要なのは、CPU やレイテンシだけでは足りない点です。注文数や支払い成功数のような business metric まで結び付けて初めて、顧客影響が見えるんですね。
ミカ
そこが監視と可観測性の差なんでしょうか。サーバーは元気でも、特定プランのユーザーだけ申し込みできないとか、ある国だけ決済が落ちるとか、そういう business 側の異変まで捕まえないと、SaaS では意味が薄いわけですね。
タカシ
まさにそこです。平均値だけを見ると、一部テナントの深刻な劣化が埋もれます。だから `tenant_id`、`plan`、`region`、`feature_flag` など、顧客影響を切れる軸を揃える必要がある。SaaS の可観測性は、断面の設計が半分なんです。
ミカ
健康診断で平均体温だけ見て、『全校生徒は元気です』って言ってしまう感じですね。実際には一人だけ高熱でも、平均にすると目立たない。SaaS も同じで、全体正常の陰に、しんどい顧客が隠れてしまうんだなあと分かります。
タカシ
標準化の流れも重要です。OpenTelemetry は 2026 年 4 月時点で 101 超のベンダーと 1000 超の統合先を掲げ、コード変更なしの eBPF 計測まで広がってきました。ただし business event までは自動で埋まらない。標準化の上に、事業固有の観測を足す発想が要ります。
Chapter 3 具体例 ― StripeとIntercomに学ぶ切り分けとコスト管理
ミカ
でも、断面を細かく切れば切るほど、監視もアラートも爆発しそうです。どこまで細かく見ると実用的で、どこからやり過ぎになるのか、その線引きが現場ではかなり難しそうですし、経営者も判断に迷いそうです。
タカシ
Stripe の事例が参考になります。彼らは 16,000 超の決済変数から数万の slice を定義し、過去 incident で見逃した断面は新しく監視対象へ足していく。さらに alert は volume loss で緊急度を分け、実運用では 90% 超の精度で本物の劣化を捉えています。
ミカ
全体平均を眺めるんじゃなくて、『どの顧客群が、どれだけ売上を落としているか』に寄せて切っているんですね。しかも false positive を減らさないと、結局は通知が多すぎて誰も真剣に見なくなる。そのバランスが肝なんだなと感じます。
タカシ
もう一つ面白いのが Intercom です。初期は約 1% の trace から始めましたが、その後は dynamic sampling に切り替え、error や slow request のような重要な取引を厚く残す設計へ進みました。価値の高い処理では 100% retention も使い分けています。
ミカ
全部を永久保存しないのが、むしろ上手いやり方なんですね。なんだか、冷蔵庫に何でも詰め込むんじゃなくて、傷みやすい物と高い物だけ前に置く感じです。可観測性って、情報量よりも保存設計のほうが大事そうです。
タカシ
その通りです。Intercom は traces から shared infrastructure の利用急増を特定顧客へ結び付け、1 トランザクションあたりの概算原価まで見積もれるようになりました。さらに監査対象の操作では 100% 保持を使い、セキュリティ監査にも活かしています。
ミカ
障害対応だけじゃなくて、粗利管理や監査証跡にも効くんですね。それなら observability の予算って、SRE の贅沢品ではなく、サポート、財務、セキュリティまで巻き込む共通基盤として見たほうが筋が良さそうです。
Chapter 4 失敗パターン ― 見える化したつもり病を避ける
ミカ
ここまで聞くと、逆に失敗の仕方も見えてきますね。管理画面は立派なのに、実際の incident では誰も原因に辿り着けないとか、請求だけ大きくて肝心の時に必要なデータが残っていないとか、そのあたりが典型でしょうか。
タカシ
典型です。よくあるのは五つで、平均値だけ見る、全部保存してコストに驚く、alert を増やしすぎて fatigue を起こす、observability を SRE 専用に閉じ込める、そして vendor 選定を先にして計測設計を後回しにする。この順で詰みやすいですね。
ミカ
体温計も血圧計も歩数計も部屋じゅうに置いたのに、肝心の本人がいつから苦しかったかは分からない、みたいな話ですね。測る物が増えるほど安心しがちですが、誰の何を守る測定かが曖昧だと、むしろ混乱しそうです。
タカシ
Google Cloud も、critical metric に集中し、閾値を適切に置いて alert fatigue を避けるべきだと整理しています。さらに logging cost を見ながら exclusion filter を使えとも言っている。つまり、良い可観測性は『多いこと』ではなく『続けられること』なんです。
ミカ
続けられること、大事ですね。高価な望遠鏡を買っても、毎晩のぞけなければ意味がない。SaaS の observability も、検知速度、問い合わせ先行率、運用コストまで含めて、回る設計にしないと経営判断としては失格なんですね。
Chapter 5 クロージング ― 三つの重要導線から始める
タカシ
実務ではまず、ログイン、初回価値到達、請求や決済の三つの導線を決めてください。その上で `tenant_id` や `plan` などの属性を traces、logs、metrics で共通化する。sampling と retention は一律にせず、error と slow request、監査対象操作を厚く残すのが第一歩です。
ミカ
今日は、可観測性が『監視ツールの導入』ではなく、『顧客影響を切り分け、復旧と投資の優先順位を決める仕組み』だと分かりました。問い合わせより先に気づける会社ほど、解約も疲弊も減らせるんですね。
タカシ
その通りです。そして次に必要なのが、『何をどこまで守れれば十分か』を決める目標設定です。次回はこの可観測性を経営と開発の共通言語に変える SLO 設計を扱いましょう。今回もありがとうございました。
ミカ
ありがとうございました。見えることが目的じゃなくて、先に気づき、早く切り分け、正しく投資するための可観測性。皆さんの SaaS でも、まずは三つの重要導線から見直してみてください。それでは、また次回お会いしましょう。