止まれば分かります。画面が出ない、返事が来ない。これは誰でも気づきます。
やっかいなのは、動いたまま中身だけがずれる場合です。応答は返り、体裁も整っています。けれども内容が少しずつ外れていく。止まらない不具合は、誰も報告してくれません。ご相談をいただく不具合の多くは、この形で数週間たってから見つかります。
気づくのが遅れるほど、その間に出た結果を後から確かめ直す手間が増えます。直す作業より、さかのぼって確かめる作業のほうが重くなることも珍しくありません。
仕組みの種類にかかわらず、最初に置く物差しは同じです。四つだけ見ておけば、たいていの異変はどれかに出ます。
遅さ ── 返ってくるまでの時間。じわじわ伸びるのは、詰まりの前触れです。
失敗の割合 ── 全体のうち、エラーで終わった割合。件数ではなく割合で見ます。
扱った量 ── 一日に何件流れたか。減っていれば、手前で止まっています。
詰まり ── 順番待ちが溜まっていないか。溜まりはじめが、いちばん早い合図です。
この四つは、Google が自社の運用の教科書で挙げているものと同じ考え方です。Google SRE Book「Monitoring Distributed Systems」（英語）↗
件数ではなく割合で見るのは、量が増えた日に必ず失敗も増えるからです。割合で見れば、量の増減に振り回されずに済みます。
四つはどれも「動きの具合」です。AIを使う仕組みでは、これに中身のずれが加わります。返している内容が、前と同じ調子かどうかです。
ここで役に立つのが、第6章で決めた物差しです。評価用に用意した例を定期的に流し直して、点が下がっていないかを見ます（C-06-2 評価セットの作り方）。測る仕掛けを作っておくと、そのまま見張る仕掛けになります。
学習を使う仕組みでは、入ってくるデータのほうを継続して見る必要があると整理されています。Google「本番環境 ML システム: パイプラインのモニタリング」↗
結果がおかしくなる前に、たいていは入ってくる材料のほうが先に変わっています。書式の変更、項目の増減、空欄の増加といったことです。
ですから当社は、出てきた答えだけでなく、入ってきた材料の形も数えています。項目の欠けた件が急に増えたら、答えを見る前に手前を疑います。手前で気づけば、直す範囲が小さくて済みます。
監視の設計でいちばん大切なのは、置く場所ではなく気づく順番です。お客様が最初に気づく状態は、どんなに立派な画面を作っても失敗です。
順番は三つしかありません。仕組みが自分で気づくか、私たちが気づくか、お客様が気づくか。一つめで止められる範囲を、少しずつ広げていくのが当社の進め方です。
三つめが続くようなら、見張る場所そのものが違っています。数を増やす前に、いま見ている対象が正しいかを疑います。
不安になると、監視は際限なく増やせます。ただし増やすほど一つひとつは見なくなります。見ていない監視は、無いのと同じです。
当社は、増やすときに一つ条件を置いています。その数字が動いたら、何をするかを先に書けること。書けないものは、まだ見る段階ではありません。この話は次の記事につながります。
当社では、定期実行が 221本 動いています。稼働している体は 85体、うち自分の判断で書き込めるのが 17体です（AIの中身）。数が増えるほど、一つずつ目で見るのは無理になります。
そこで、監視そのものを監視する仕組みを置いています。決まった時刻に動くはずのものが動いていないこと自体を、別の仕組みが見ています。見張り役が黙っていることと、異常が無いことは違うからです。
見張る対象が決まると、次は知らせ方です。鳴らしすぎた警報がどうなるかを見ていきます。
章と記事の全体は図書館の見取り図で一枚にまとめています。