監視と可観測性は、何が違うのか

InvisibleWorkflow 編集部 2026.05.13 4分で読む

「オブザーバビリティ、っていう言葉をよく聞くんですが、結局これ、監視と何が違うんですか」。新しく運用チームに加わった後輩が、休憩室でそう切り出した。コーヒーを片手に、私はしばらく考えてから答えた。少し長くなるが、この問いは丁寧にほぐす価値がある。

「監視は、『たぶんここが危ないだろう』と先に見当をつけて、見張りを置くことだよ。CPUの使用率がこの線を超えたら警報を鳴らす、みたいにね。予想した不調には、すぐ気づける」

「じゃあ、可観測性は」

「予想していなかった不調まで、後から追えるようにしておくこと。実際の障害って、想定どおりの場所では起きないんだ。『そんな組み合わせ、誰も考えてなかった』というところで火が出る。そのとき、見張りを置いていない場所で何が起きたのかを、記録から再構成できるか。そこが分かれ目になる」

三つの手がかり

「具体的には、何を見るんですか」

「大きく言うと、手がかりは三種類。ログ、メトリクス、トレース。ログは『何時何分に、こういう出来事があった』という記録。メトリクスは『一分あたり何件処理した』みたいな数値の推移。トレースは、一つの要求が複数のシステムをどう渡り歩いたか、その経路をつないだもの」

「使い分けるんですか」

「いや、組み合わせるんだ。メトリクスで『この時間帯に応答が遅い』と気づく。トレースで『遅いのはこの区間だ』と場所を絞る。ログで『その区間で何が起きていたか』を読む。一つだけでは足りない。三つの手がかりを重ねて、ようやく流れが見えてくる。前に書いたイベント駆動みたいに、処理が非同期にばらけている仕組みだと、トレースがないと因果が追えなくなる」

道具より、設計

「ツールを入れれば、可観測性は手に入りますか」

「それが、入れただけでは足りないんだよ」。私は少し声を落とした。「記録は、後から急には増やせない。障害が起きてから『この値も取っておけばよかった』と思っても、過去には戻れない。だから、何を記録するかは、システムを作る段階で決めておくしかない。可観測性は、運用の道具である前に、設計の姿勢なんだ。グーグルのSREの本でも、何を計測するかをサービスの設計と一体で考える、という話が繰り返し出てくる」

「逆に、記録しすぎると困りませんか」

「いい質問だね。困る。何でもかんでも記録すると、保存の費用がかさむし、いざというとき肝心の手がかりがノイズに埋もれる。だから『すべてを取る』のではなく『異常を切り分けるのに足りるだけ取る』。この線引きが難しい。一方で、減らしすぎれば、さっき言ったとおり後から取り返せない。多すぎても少なすぎても痛む、その間を探る作業なんだ」

気づける、ではなく、追える

後輩はしばらく黙って、それからこう言った。「監視は『気づける』こと、可観測性は『追える』こと、ですかね」。私はうなずいた。言い得て妙だと思った。

システムは、複雑になるほど、人の予想を超える壊れ方をする。事前に見張りを置ける場所には限りがあり、想定の外側は必ず残る。だからこそ、起きてしまった後に「何が起きたのか」を語れる手がかりを、あらかじめ仕込んでおく。可観測性とは、未来の自分が過去を読み解けるように、いま記録を残しておく約束のようなものだ。派手な機能ではないが、見えない基盤を安心して任せられるかどうかは、結局この約束の厚みで決まる。コーヒーは、すっかり冷めていた。