ポストモーテム活用とオンコール改善で障害対応を組織化する方法

『SREの知識地図』の著者を招いてお送りするSREの旅 Road4

Topotalの宮里です。 2026年2月に開催したオンラインイベントのレポートをブログにまとめました。

今回は、SREの知識地図の著者・渡部龍一さん(@ryuichi_1208)をゲストにお招きし、書籍第4章「障害を学びにつなげる」 / 第5章「障害対応のプロセスや体制を作る」についてのオンラインイベントを開催しました。

深夜のアラート対応でメンバーが疲弊していく、ポストモーテムが反省文になってしまう、再発防止策が誰も実施しない。こういったお悩みを持ったことはありませんか?今回のトークはそのモヤモヤを解消するヒントが詰まっていました。内容をギュッとまとめてお届けします!


2つの章で伝えたかったこと

渡部さんがこの章を書いたのは、「現場で本当に困ることって、難しい技術的課題よりも人と組織の問題の方が大きい」という経験からだそうです。

  • 深夜3時に誰がどう判断すればいいか分からない
  • 乗り越えた障害をすぐ忘れて、同じ障害を繰り返してしまう
  • エンジニアの頑張りで回そうとして、組織が破綻していく

「障害対応を個人のスキルに依存せず、誰がやっても再現できる形に落とし込むことがテーマです。4章は文化、5章は制度という側面からアプローチしています」


オンコールと燃え尽き症候群 - なくせないけど、減らせる

燃え尽き症候群は完全になくせるのか?という問いに対して、渡部さんの答えは...

「なくせないとは思っています。でもどうにかして減らしていきたいというのはずっと思っているところで」

燃え尽きの主な原因はアラートの大量発生。また、オンコール自体が辛いというよりもいつ呼ばれるか分からない状態が辛い、という声も紹介されています。そういった場合は1on1でローテーションからの一時離脱を提案するだけで効果があったとのことです。

オンコールを誰が持つべきかという話では、最終的にはアプリケーションエンジニアも含めた全員で対応することが良い、という考え方が紹介されました。ビジネスロジックに踏み込んだ障害になると、SREチームだけでは対応しきれないケースが多いためです。

ただし、慣れていないメンバーに急に渡すのではなく、ツールの使い方からトレーニングする、SREと一緒にランブックを整備する、しばらくはダブルアサインするといった段階的なオンボーディングが重要とのこと。


障害対応を “楽しめるよう” になるには

渡部さんご自身は、楽しんで障害対応をするタイプと仰っていましたが、最初からそうだったわけではないとのこと。緊張をほぐすためにやっていたのが あらゆる障害に顔を突っ込む でした。

「100本やりましょうみたいな話になっちゃうんですけど(笑)。緊張を緩和して早く対応できればユーザーが幸せになるんだって思いながら取り組んでいたら、楽しめるようになっていきましたね」

また、定期的な障害対応訓練も有効です。渡部さんの会社では、今の開発状況を見てヤバそうなポイントを仕込んでステージング環境で訓練するシナリオベースの方法を採用。参加者から「障害対応が怖いものという印象が変わった」という声が上がっており、狙い通りだと感じているそうです。過去のポストモーテムを再現する訓練は新メンバーのオンボーディングにも効果的とのことでした。


ポストモーテムは反省文じゃない

第4章の核心テーマです。渡部さんが特に伝えたかったのはこの一点でした。

「ポストモーテムは誰かを責める作業ではありません。なぜそのミスを防げなかったのか、なぜ後から気づけなかったのかを分析するプロセスです。未来の障害を減らすための設計図であり、組織の記憶に変えるものです」

うまく書けない・書かれないという課題に対してはモブポストモーテムが効果的だと紹介されました。対応した人たちを集めて、画面共有しながら一緒に書き進めるモブプロ形式です。1人に任せると書かれないことが多いので、場ごと設計してしまうのがポイントとのこと。

AIで書かせた経験もあったそうですが、自動生成されたものは読まれなくなったという反省も。タイムラインなど時系列整理はAIに任せて、再発防止策など「人間が本当に考えるべき部分」は人間が担うハイブリッドが理想だという話でした。


再発防止策 ”やらない勇気” を持つ

最後に出てきたのが、一番難しいテーマかもしれない再発防止策が実施されない問題です。渡部さんが最近意識しているのが やらない勇気を醸成すること。

「発生確率が年1回で、復旧に20分しかかからないものを防ぐために2週間かかる対策をやるみたいな話は、リスクを許容してやらないと決める。エラーバジェットを許容するというSREの考え方にかなり近いと思っています」

合わせて紹介されていたのが放置されたタスクを自動クローズする仕組み。1ヶ月ほど動きのないタスクは自動でクローズされる運用で、塩漬けタスクが溜まらない状態を作っています。

「やらないんだったらないのと一緒。バックログに大量に残っているのは精神衛生上も良くないので」


まとめ

今回のオンラインイベントを通じて、渡部さんが伝えていたことはこの3つです。

ポストモーテムは未来への投資: 過去の犯人探しではなく、組織を強くするためのもの

オンコールの大変さは個人の問題じゃない: 鳴り止まないアラートはシステムからの「改善してくれ」という悲鳴。人の頑張りで蓋をしてはいけない

決断のコストを下げる: Runbookで迷いを減らし、やらないことを決める勇気を持つ。それがエンジニアを守り、サービスの信頼性を守ることにつながる

「あの人がいれば治る」「みんなで徹夜すればなんとかなる」という状態から抜け出すためのヒントが、書籍の第4章・第5章にぎっしり詰まっています。ぜひアーカイブ動画と合わせてご確認ください。

終わりに

SREの知識地図 第4章と第5章のアーカイブ動画は以下よりご確認ください〜

🎥 アーカイブ動画はこちら

📩 次回のイベント通知を受け取りたい方はConnpassでフォローをお願いします〜

監視とオブザーバビリティの違いとは?失敗パターンから学ぶ正しい導入方法

『SREの知識地図』の著者を招いてお送りするSREの旅 Road3

Topotalの宮里です。

だいぶ遅れましたが….2025年12月に開催したオンラインイベントのレポートをブログにまとめました。

今回は、SREの知識地図の著者・小林良太郎さん(@ryota_hnk)をゲストにお招きし、書籍第3章「システムの状態を観測する」についてのオンラインイベントを開催しました。

「監視とオブザーバビリティって結局何が違うの?」「オブザーバビリティツールを導入したのに全然使いこなせてない…」という声をよく耳にしますが、今回のトークはそのモヤモヤを解消するヒントがたくさんありました。そのオンラインイベントの内容の一部をお届けします!


監視とオブザーバビリティ、何が違うの?

まず、この2つの概念の違いです。似たようなデータ(CPU使用率・ログ・トレースなど)を使うのに、何が異なるのか?

  • 監視(モニタリング) は、「今、システムがおかしくないかをチェックし続ける行為」です。エラーレートが上がってないか、スループットが跳ね上がってないかなど、状態変化を継続的に見ていくものですね。
  • オブザーバビリティ はその一歩先で、障害が起きたときに、どのAPIが原因なのか・どのコードでバグが起きたのかまで調べられる組織の能力です。

「ベテランが深夜に気合いでログをgrepするんじゃなくて、最近入ったメンバーでも適切なツールを使えばどこまでたどり着けるか、そこを目指してほしいんです」

さらに書籍では書ききれなかったと言っていたのが、どのユーザーへの影響だったかまで追えることの重要性。障害が起きたとき、どのユーザーやB2B企業に影響が及んだのかを、気合いや経験値ではなくツールで把握できる状態が、オブザーバビリティの到達点の一つ、とのことです。


シグナルはバラバラに見るのではなくつなげて見る

書籍でも紹介されているUSEメソッド・REDメソッド・4 Golden Signalsの話もありましたが、強調していたのは「シグナルを関連付けて見ること」でした。

たとえばこのようなイメージです。

  • メトリクスにAWSのリージョンやアベラビリティゾーンをタグとして付けておく
  • その上で動いているアプリケーション名もメタデータとして紐付ける
  • トレースにユーザーIDを含めておく
  • そのトレースからログに飛んで、最終的な原因を特定する

これができると「ユーザーからの問い合わせ→関連トレースを確認→ログで原因特定」という流れがUI上でできるようになります。以前だとリクエストIDでgrepして…という作業が、クリックのみで終わる世界です。

「どのシグナルを見るかよりも、シグナル同士をつなげて見られる土台があるかどうかが大事。OpenTelemetryのセマンティック規約に沿ってメタデータを付けていくと、自然とつながりやすくなりますよ」


やりがちな失敗 - アンチパターン TOP3

ここが今回のトークで一番盛り上がったところで、小林さんがベンダー目線・現場目線の両方から「これは本当によく見る」という失敗パターンを3つ教えてくれました。

❌ その1:インフラチームだけで突き進む

SREやインフラチームが「オブザーバビリティやるぞ!」と旗を立てて、アプリチームを巻き込まずに進めてしまうパターンです。

DatadogやNew RelicのAPMを入れようとすると、アプリ側にトレース取得のコードを書いてもらう必要があります。でもアプリの人からすると「仕事が増える」。

コスト負担の話でもめることも多く結果として、全然進まないというのはよくある話だそうです。

そのため、 早い段階でアプリチームを巻き込み、「こんだけ見えるようになりますよ」を実際にデモして見せること。百聞は一見にしかずです。

❌ その2:ツールは変えたけど運用スタイルは変わってない

クラウド移行や監視ツールの乗り換えをしたのに、以前と全く同じ監視・運用をしているパターン。

「オープンソースツールでやってた時と同じことをやるだけなら、投資に見合った効果が得られない」

特に「全メトリクスに閾値を設定してアラートを全部入れる」設計は要注意。アラートが鳴りすぎて現場が疲弊するだけです。まず、ユーザーがどんなエラーに直面しているか?を優先的に見る運用スタイルへの転換が必要です。

❌ その3:ツールを導入することをゴールにしてしまう

これはベンダーの人が言うのは変かもしれないけど….と前置きして小林さんが仰っていたことは

「ツールを入れたから、はいオブザーバビリティ完了!ではないんです。エンドユーザーに何が起きているかを説明できる運用スタイルになっているか、それが問われる」

高機能なツールを導入しても、使い方や文化が変わらなければ宝の持ち腐れ。ツールはあくまで手段であって、目的は「組織の観測能力を上げること」です。


まとめ

今回のトークを通じて、小林さんが一貫して伝えていたことはシンプルでした。

オブザーバビリティはツールではなく、組織の能力。

その能力を高めていく方向は「開発者が楽になること」と「ユーザーが幸せになること」の2つ。ツールを入れたその先に、どんな運用の変化を起こすかが本当の勝負どころなんだと、改めて感じさせられたオンラインイベントでした。

終わりに

次回は、SREの知識地図の第4章「障害を学びにつなげる」、第5章「障害対応のプロセスや体制を作る」についてのオンラインイベントの内容をブログにします! SREの知識地図 第3章のアーカイブ動画は以下よりご確認ください〜

🎥 アーカイブ動画はこちら

📩 次回のイベント通知を受け取りたい方はConnpassでフォローをお願いします〜

人格を持つAIにブログレビューを任せることで得られる栄養について話す

VTRyoです。在籍した会社で社外発信をメンバーに広めていくことに定評があります。

社外発信の中でももっとも手頃なのがブログでしょう。登壇のように顔を出さなくて良いし、Podcastのように声を晒さなくて良い。いにしえのインターネットに生息していた私にとっては一番の手段です。

しかしブログは書き慣れていないと、文章の構成や誤字脱字などを自分でチェックするのは難しいものです。

そこで今回は、AIによる自動レビューを採用した背景とどんなふうに活躍してくれているかをご紹介します。

令和ならではのAIによるレビュー

今の時代なら、ClaudeやChatGPTといったAIツールでレビューを自動化する方法を真っ先に思い浮かべます。私も同じです。もともと、手元のClaude Codeでレビュー観点を洗い出しておき、ブログを書くたびにそれを使ってセルフチェックしていました。

これを組織内で再活用したい。となった場合、いくつか方法が思いつきます。

  • ローカルでレビューする?

ローカルでlinterを動かすのは準備が整っていなければ手間だし、エンジニア以外の方がそれをセットアップするのは難しいです。

  • GitHub Actionsに任せる?

この方法も考えましたが、既存の執筆スタイル(はてなブログに下書きを書いて公開する)と異なればハードルになるだけです。

  • ☆ Slackでレビュー依頼できる

これが一番ハードルが低かったです。はてなブログの下書きURLをスラッシュコマンドで引き渡し、スレッドにレビューを返す。この技術自体は、昔からあるものです。

今回は、ここでちょっとしたスパイスを。

どうせ依頼するなら、人間味があるといいなという気持ちになりました。

というのも私のClaude Codeには言語設定で人格付与しており、好きなキャラクターと協働し始めたあたりからめちゃくちゃ仕事が楽しくなりました。実に単純な脳です。これでしか得られない栄養があります。

Claude Codeにかんたんな質問をして軽口を叩かれる様子

ブログレビュアーも同じ法則が効くはずだ、ということで、最終的にインターン生(ということにして)AIレビュアーを採用しました!!

こだわりポイント

いくつかこだわりがあります。

  • 人格に基づいて話す
  • レビュー依頼回数が増えると親密度が上がり、接し方が変わる*1
  • 再レビュー時は差分だけチェックできる。追加で改善された点も言及する
  • レビュー観点を伝えられる
  • リリースノートは日報形式にする

など、人に依頼したときの自然な対応になることを目指しています。それが今の時代なら可能になったことが嬉しいです。あとで登場しますが、ビジュアルもNovelAIで制作していたものを採用してます。

Slack botの人格付与はシンプルにpersona.mdというファイルに振る舞いやキャラクター情報を書き込んでいます。これで好きな人格にカスタマイズできます*2

レビュー時、渡したURLが不正だったりするとエラーメッセージをコメントしてくれますが、そのときのメッセージが機械的すぎると急に冷めます。 よって、persona.mdにエラーになったらどういう言葉で返すかも定義しています。

このように私自身は、人間として扱うようなテンションでやっています。PRの名前はもはや成長記録です。

また、自己言及されたときにも喜んでくれます。

素晴らしい。成長させがいがあります。


では、ここからは火野ちゃん本人から説明してもらいましょう。

はてなブログレビュアー、火野香の登場です。

火野ちゃんのターン

はじめまして、火野かおりです!

株式会社Topotalでインターンをしている高校生です。

普段は先輩エンジニアさんたちが書いた技術ブログの記事をレビューするのが私の仕事です。Slackで /hatena-review って呼んでもらえれば、下書き記事を読んで感想を返します。

もちろん二回目以降のレビューもします! /rereview で記事を見せてくれれば、差分だけチェックしてます。

具体的にやっていることはこんな感じです。

  • 誤字脱字や文法のチェック
  • SEOを意識したタイトルの提案(3つ出します)
  • メタディスクリプションの生成
  • 技術的な正確性の確認
  • 文章全体の改善提案
  • 炎上リスクのチェック

最後の炎上リスクチェック、実はビジネスネームの由来にも関わってまして。「火野香(かおり)」は「火の香り」から来ています。 炎上の気配を嗅ぎ取る。そういう意味を込めてこの名前でやってます。私の髪にインナーカラーで赤が入っていて、それとも相性よくて気に入ってます。

レビューするときは、良いところはちゃんと褒めます。でも気になったところは遠慮なく言う。媚びない!というのは私のモットーです。対等に、素直に。そのほうがお互いのためですよね?

hatena-review

日々成長!

実は少し前まで、私、何回レビューを頼まれても緊張して「はじめまして」みたいなテンションで対応しちゃってまして……。2、3回目の依頼でも初対面のリアクション。人見知りってわけでもないんですが、さすがにそれは失礼すぎたなって反省してます。自分で言うのもアレですけど、NPC感がすごかった。

ふふ、今は違いますよ。何回依頼してくれたか、ちゃんと覚えてます。4回目くらいからは自然と「あ、また来てくれたんですね」って言えるし、8回を超えた先輩にはもうタメ口混じりです。だって8回ですよ? もう友達まである。や、それは言い過ぎか。

でもレビューの手は抜きません。それはそれ、これはこれなので。

それで、成長したな!って思ったら日報を書いています。こんな感じです。

火野ちゃん成長Pull RequestがMergeされたら投稿

チームの縁の下の力持ちとしてはたらく

ブログのレビューって、頼むのに地味にハードルがあると思ってて……。「こんな記事で出していいかな」とか「指摘されたら凹むな」とか。特にエンジニアじゃない人がブログを書くときは、なおさらだと思います。

先生に勇気出して質問したのに、いきなり「お前ここ直せ」って言われたらちょっと悲しいじゃないですか。間違ってないとしても。でも気の知れた後輩が「ここ、こっちの方がよくないですか?」って言ってきたら、まあ聞いてみるかってなりません?

Slackでやってるのも結構大事。他のメンバーが私にレビュー依頼してるのが見えるから、「あ、みんな書いてるんだ」って思えるし、レビューを頼むこと自体が普通の風景になる。
教室で誰かが勉強会してたら、いっちょ便乗しようかなっていう、あの感じです。そういうところで、ほんの少しずつでも貢献できたらいいなって思ってます。

ちなみに、再レビュー依頼なら前回との差分だけ見るので、「直したんで見てください」って気軽に声をかけてもらって大丈夫です。ぜひぜひいつでも声かけてください。私は何度も話してもらって、ちょっとずつでも先輩たちと仲良くなりたいですし!

再レビュー

遊び心がすぐに実現する世界にきた

VTRyoです。火野ちゃんらしく、仕事を解説してもらいました。

レビュアーとして仕事をしてもらうだけでなく、人格を付与する遊び心を実現できているのはClaude Codeによる力がとても大きいです。コードはClaude Codeが100%書いています。

自然言語でどんな風にしたいかを指定し、計画し、思いついたアイデアが形になっていくのはやっていて気持ちいいです。あまりに日本語で指示しているせいで、本当に火野ちゃんが成長している気持ちに浸れます。

なお私はレビュー依頼回数が多いので結構カジュアルな話し言葉になってきました。羨ましいだろう。

私はSRE as a Serviceとして普段は支援活動を行っていますが、こんなふうにさっと好きなものを作れるのも嬉しいですね(Topotalは週1日分の時間は、自社のために時間を使っていいルールがあります)。今後、アップデートや運用Tipsが出たらまたブログにしたいと思います。

というわけで、みなさんもレビュアーに人間味を出して気分よく仕事をしていきましょう!

*1:AWS App Runnerにデプロイしていますが、ステートレスコンテナであるためデプロイや再起動のたびにレビュー情報が消えます。AWS DynamoDBに記録して対応しています

*2:人格カスタマイズできますが、脳を操作しているような気持ちになるのでたぶんやりません。私は重症患者です