深夜のアラートをAIと乗り切る技術 — “読む専用”から始めるAIインシデント対応の実践ガイド（仮説駆動トリアージ／ブラスト半径／ブレームレスポストモーテム）

Posted at 2026-06-02

はじめに：深夜3時、アラートが鳴る。あなたは何を最初に開きますか

深夜3時。スマホが震えて、画面に「決済APIのエラー率が急上昇」の通知。

このとき、頭のなかってだいたい真っ白になるんですよね。ログを開くべきか、ダッシュボードを開くべきか、それとも先輩を叩き起こすべきか。手は震えてるのに、判断だけは急がされる。オンコール（待機当番）の夜って、技術力うんぬんの前に、まずこの孤独がしんどい。

最近は「AIに障害対応させればいい」みたいな空気もあります。実際、2026年は AI SRE と呼ばれるツールが一気に増えました。アラート・メトリクス・直近のコード変更・過去のインシデントを横断して読み、ノイズを削って原因に当たりをつけてくれる。すごく頼もしい。

でも、正直に言うと、ここで順番を間違えると本番が燃えます。

「AIに直してもらおう」と、いきなり本番サーバーの操作をAIに丸投げする。これが一番危ない。障害対応で本当に効くのは、速さよりも順番なんです。今日はその「事故らない順番」と、明日のオンコールから使える型・プロンプト・コードを、まるっと渡しにいきます。

先に用語だけ、軽く地ならししておきますね。

インシデント … サービスが普段どおりに動かなくなった出来事。エラー急増、レスポンス遅延、全面ダウンなど。
オンコール … 「障害が起きたら呼ばれる」待機当番のこと。深夜でも休日でも、鳴ったら出る人。
SRE（Site Reliability Engineering） … サービスを安定して動かし続けるための考え方・職種。Google発祥で、「障害はゼロにできない前提で、いかに早く・賢く立て直すか」を設計する人たち。

この記事は「無知の無知」、つまり まだオンコール自体が怖い人 に向けて書いてます。専門用語は出てくるたびに噛み砕くので、身構えなくて大丈夫です。

まず地図を持つ：インシデント対応は「5つのフェーズ」でできている

結論から言うと、AIに何かを任せる前に、まず インシデント対応を5つのフェーズに分けて地図を持つ といいです。

なぜかというと、「AIに障害対応を任せていいか？」という問いは、おおざっぱすぎて答えが出ないから。フェーズごとに「AIに安全に任せられる範囲」がまるで違うんですよ。

2026年のAI SREの設計でも、だいたいこの5つに分かれています。

フェーズ	何をする時間か	AIに安全に任せやすい範囲
検知（Detection）	「異常が起きた」と気づく	アラートの要約、関連アラートの相関づけ
仕分け（Triage）	重大度を判断し、どこから見るか決める	ログ要約、影響範囲の整理、原因仮説の列挙
調査（Investigation）	原因を絞り込む	read-only（読むだけ）のログ・メトリクス調査
復旧（Remediation）	実際に直す	候補の提案まで。実行は人間承認の後ろ
エスカレーション（Escalation）	手に負えないと判断し、人を増やす	状況サマリの自動生成、連絡先の提示

ポイントは、左の検知・仕分け・調査はAIがどんどん助けてくれる領域、右の復旧・エスカレーションは人間が手綱を握る領域、という温度差があること。

「トリアージ」は救急の現場で使う言葉ですよね。患者がたくさん運ばれてきたとき、どの人から診るかを決めるアレ。インシデントでも同じで、「今これは顧客全員に影響してるのか、一部なのか、社内だけなのか」をまず仕分ける。ここを飛ばして原因究明に突っ込むと、だいたい迷子になります。

地図を持つ。それだけで、深夜の真っ白な頭にも、最初の一歩が見えてきます。

AIに任せる「4段の階段」：なぜ最初の一段は“読む専用”なのか

地図を持ったら、次は AIにどこまで任せるか を段階で考えます。

2026年のAI SREには、わかりやすい成熟度の階段があります。下から順に、こうです。

読む専用（read-only insights） … AIは見るだけ。ログを要約し、仮説を出すが、何も実行しない。
助言（advised actions） … AIが「こうするといいかも」と提案する。実行はしない。
承認つき復旧（approval-based remediation） … AIが復旧アクションを用意し、人間がGOを出したら実行する。
ガードレールつき自律（autonomous with guardrails） … 決められた範囲内なら、AIが自分で実行する。

ここで一番大事なのは、最初の一段は必ず「読む専用」から始めるということ。

なんでだと思います？

初対面の人に、いきなり家の鍵を渡さないですよね。まずは玄関で話して、信頼できそうだと分かってから、少しずつできることを増やす。AIへの権限も、まったく同じだと思うんです。

「読む専用」なら、最悪AIが間違っても、被害はゼロ。だって何も実行してないから。間違った仮説を出しても、人間が「いや、それは違うな」と捨てればいいだけ。失敗のコストがほぼゼロの場所から始める——これが、AIを障害対応に入れるときの一番安全な入り口です。

そして、いいAI SREかどうかを見分ける問いも、ここにあります。

それは read-only なのか、write（書き込み・実行）できるのか？
考慮した証拠、除外した仮説、最終的な答えへの 確信度 を、ちゃんと見せてくれるか？

「自信満々に答えるけど、なぜそう判断したか見せてくれないAI」は、調査では一番危ない。根拠と確信度を出させる。これは後のプロンプトでも徹底します。

仮説駆動トリアージ：ログの山から最短で原因に迫る

さて、ここからが実戦です。読む専用のAIを相棒に、仮説駆動トリアージ をやってみましょう。

ログって、多ければ多いほど不安になりますよね。でも、全部読む必要はないんです。やることはシンプルで、こういうループになります。

観測 … 今わかっている事実だけを集める（エラー率、いつから、どのサービス、直近の変更）
仮説 … 「原因はこれかも」を 3つ出す（1つに決め打ちしない）
検証 … 仮説ごとに「これが本当なら、ログのここにこう出るはず」を、read-onlyで確かめる

ここでAIがめちゃくちゃ効きます。人間が3時の頭で1000行のログを睨むより、AIに要約させて仮説を3つ並べてもらう方が、はるかに速い。

そのためのプロンプトがこれです。コピーして、ログを貼るだけで使えます。

プロンプト例①：仮説駆動トリアージ

あなたは経験豊富なSREです。これは本番インシデントの一次トリアージです。
あなたは「読む専用」です。コマンドの実行・再起動・ロールバックなどの操作は絶対に提案しないでください。

# 状況
- 事象: {例: 決済APIの5xxエラー率が2%→18%に上昇}
- 開始時刻(UTC): {例: 2026-06-02T17:40:00Z}
- 影響範囲(わかる範囲): {例: 決済を含むチェックアウト全般}
- 直近の変更: {例: 17:30 に order-api を v1.42.0 へデプロイ}

# 入力ログ/メトリクス（抜粋）
{ここにログやメトリクスを貼る}

# 出力フォーマット（厳守）
1. 1行サマリ: 今わかっている事実だけ
2. 原因仮説トップ3: それぞれに
   - 仮説
   - 確信度(高/中/低)とその理由
   - これが本当ならログ/メトリクスのどこにどう出るか(検証方法)
   - 検証に使う read-only コマンド例（実行はしない／破壊的でないもの限定）
3. 除外した仮説: 一度疑ったが確度が低いものと、その理由
4. ブラスト半径の見立て: 影響しているユーザー/機能の範囲
5. まだ足りない情報: 次に人間が取りに行くべきデータ

このプロンプトのキモは3つあります。

ひとつ、「あなたは読む専用です」と最初に縛ること。これで、AIが勝手に「サーバーを再起動しましょう」と言い出すのを防ぎます。ふたつ、仮説を3つ出させること。1つに決め打ちさせると、AIは平気で“それっぽい誤答”に突っ走るので、複数並べて人間が選ぶ。みっつ、除外した仮説も出させること。「何を疑って、なぜ捨てたか」が見えると、AIの思考が信用できるか判断できます。

ここで出てくる ブラスト半径（blast radius） は、もともと「爆発の被害が及ぶ範囲」という意味。インシデントでは「この障害、どこまで影響してるの？」の範囲を指します。全ユーザーなのか、特定地域だけか、特定機能だけか。これが分かると、重大度の判断と、顧客への通知の要否がスッと決まります。

そして、AIに調査コマンドを出させるなら、読むだけのコマンドしか通さない柵を、人間側で必ず立てておく。これがコード例①です。

コード例①：read-only 調査コマンドの allowlist（Python）

import shlex
import subprocess

# 「読むだけ」と確認できるコマンドだけを許可リストに入れる。
# ここにないコマンドは、AIが提案しても実行しない。
READ_ONLY_ALLOWLIST = {
    "kubectl": {"get", "describe", "logs", "top"},
    "git": {"log", "show", "diff", "status"},
    "grep", "tail", "cat", "head", "journalctl",
}

# 明確に破壊的なものは、許可リストと別にブロックリストでも二重に弾く。
DENY_TOKENS = {"delete", "rm", "drop", "restart", "rollout", "scale",
               "apply", "kill", "reboot", "truncate", ">", ">>", "|"}

def is_read_only(command: str) -> bool:
    tokens = shlex.split(command)
    if not tokens:
        return False
    # 危険トークンが1つでも混ざっていたら即拒否
    if any(t in DENY_TOKENS for t in tokens):
        return False
    head = tokens[0]
    if head in READ_ONLY_ALLOWLIST:
        allowed = READ_ONLY_ALLOWLIST[head]
        if isinstance(allowed, set):
            # サブコマンド(例: kubectl get)まで見る
            return len(tokens) >= 2 and tokens[1] in allowed
        return True
    return False

def run_investigation(command: str) -> str:
    if not is_read_only(command):
        # ここが「柵」。読むだけと確認できないものは実行しない。
        raise PermissionError(f"read-onlyではないため実行を拒否しました: {command}")
    result = subprocess.run(shlex.split(command), capture_output=True, text=True, timeout=20)
    return result.stdout

# 使い方の例
# run_investigation("kubectl get pods -n payment")        # OK（getは読むだけ）
# run_investigation("kubectl rollout restart deploy/api") # PermissionError（restartは破壊的）

この柵があるだけで、調査フェーズでAIに手を動かしてもらっても、「読むだけ」から絶対にはみ出さない。安心して任せられる、というのはこういう状態のことです。

直す前に「止める」：破壊的操作の承認ゲート

調査が進んで、原因が見えてきた。さあ復旧（remediation）です。

ここで多くの人がやりがちなのが、「AIさん、じゃあ直して」と、復旧までAIに丸投げすること。気持ちは分かります。早く寝たいですもんね。でも、直す前に「止める柵」を先に立てる。これ、順番が逆だと事故ります。

復旧アクションには、こういう原則を置きます。

bounded（範囲限定） … 影響範囲を限定する。全台じゃなく1台から。
reversible（戻せる） … ロールバックやfeature flagで、すぐ元に戻せる手から。
audited（監査される） … 誰が・いつ・何を実行したか、必ず記録する。

そして、操作を3種類に線引きします。

種類	例	AIの扱い
読むだけ	ログ閲覧、メトリクス取得、`get`/`describe`	AIが自由にやってOK（コード例①の柵の中で）
可逆な操作	feature flagをOFF、1台だけ再起動、デプロイのロールバック	AIは提案まで。実行は人間承認＋監査ログ
破壊的・不可逆	DBの`DELETE`/`DROP`、データ削除、本番設定の全面変更	デフォルト拒否。人間の二重確認なしには絶対実行しない

この線引きを、コードの「ゲート」にします。AIや自動化が破壊的操作を呼んだら、いったん止めて、人間の確認トークンを要求する仕組みです。

コード例②：破壊的操作の承認ゲート（TypeScript）

type RiskLevel = "read_only" | "reversible" | "destructive";

interface ActionRequest {
  command: string;
  risk: RiskLevel;
  reason: string;       // なぜこの操作が必要か（AIに書かせる）
  confirmToken?: string; // 人間が承認したことを示すトークン
}

// 破壊的・可逆な操作は、承認トークンなしには実行できない。
function executeAction(req: ActionRequest): string {
  if (req.risk === "read_only") {
    return runShell(req.command); // 読むだけは即実行
  }

  // ここがゲート。トークンがなければ「ドライラン（実行せず計画だけ返す）」。
  if (!req.confirmToken) {
    return [
      "⚠️ この操作は実行されていません（ドライラン）。",
      `種類: ${req.risk}`,
      `コマンド: ${req.command}`,
      `理由: ${req.reason}`,
      "実行するには、人間が内容を確認し confirmToken を付けて再実行してください。",
    ].join("\n");
  }

  if (!isValidHumanToken(req.confirmToken)) {
    throw new Error("承認トークンが無効です。実行を中止しました。");
  }

  // 破壊的操作は、可逆操作よりさらに重いゲート（二重確認）を要求する
  if (req.risk === "destructive" && !isDoubleConfirmed(req.confirmToken)) {
    throw new Error("破壊的操作には二重確認が必要です。実行を中止しました。");
  }

  auditLog({ command: req.command, risk: req.risk, token: req.confirmToken }); // 必ず監査
  return runShell(req.command);
}

confirmToken がないあいだ、AIがどれだけ「再起動すべきです」と主張しても、実行されるのは“計画”だけ。人間が中身を読んで、納得して、はじめてトークンを付ける。この一拍が、深夜3時の取り返しのつかないミスを防ぎます。

そして、AIには「この操作はどの種類か」を仕分けさせるのが便利です。

プロンプト例②：復旧アクションの危険度トリアージ

あなたはSREのレビュアーです。以下の復旧アクション候補を、リスクで仕分けしてください。
あなたは実行しません。仕分けと、人間が確認すべき点だけを出してください。

# 復旧アクション候補
{例: order-api を v1.41.0 にロールバックする}

# 出力
- リスク種別: read_only / reversible / destructive のどれか
- 理由: なぜその種別か
- 戻せるか: この操作は元に戻せるか。戻し方は何か
- ブラスト半径: 失敗したとき、何にどこまで影響するか
- 実行前に人間が確認すべきこと: 箇条書きで
- より安全な代替案: もしあれば（例: 全台ではなく1台から、flagでOFFから）

「より安全な代替案」を必ず出させるのがコツ。AIは「ロールバックしましょう」と一直線に言いがちですが、「まずflagでOFFにして影響を見る」みたいな、もっと可逆で小さい一歩が見つかることが多いんです。

AIに食わせる前に隠す：ログのPII/credマスキング

ひとつ、AIにログを丸ごと渡す前に、消しておくものがあります。

本番のログには、けっこうな確率で PII（個人を特定できる情報。メールアドレス、電話番号など） や、credential（APIキー、トークン、パスワード） が混ざってます。これをそのまま外部のAIに送ると、情報が外に出てしまう。障害を直すつもりが、別の事故を起こすことになる。

なので、AIに渡す前にマスキング（伏せ字化）する一段を、必ず挟みます。

コード例③：ログのPII/credマスキング（Python）

import re

# よくあるPII/credのパターン。自分のサービスに合わせて足していく。
PATTERNS = {
    "EMAIL": re.compile(r"[\w.\-]+@[\w.\-]+\.\w+"),
    "BEARER": re.compile(r"(?i)bearer\s+[a-z0-9._\-]+"),
    "API_KEY": re.compile(r"(?i)(api[_-]?key|secret|token)\s*[=:]\s*\S+"),
    "CREDIT": re.compile(r"\b\d{4}[ -]?\d{4}[ -]?\d{4}[ -]?\d{4}\b"),
    "IP": re.compile(r"\b\d{1,3}(?:\.\d{1,3}){3}\b"),
}

def mask_logs(text: str) -> str:
    for label, pat in PATTERNS.items():
        text = pat.sub(f"[REDACTED_{label}]", text)
    return text

# 使い方
# safe = mask_logs(raw_logs)
# → safe をAIに渡す。raw_logs（生ログ）は渡さない。

完璧な正規表現は存在しないので、これは「ゼロを100にする」道具ではなく、「生のまま渡す事故を、現実的に減らす」道具です。心配なら、そもそも機微なログはAIに渡さない、という線引きも立派な設計。何を渡さないかを決めるのは、いつも人間の仕事です。

終わったら未来へ残す：ブレームレスポストモーテムをAIに下書きさせる

障害が収まった。やっと寝られる。……でも、ここで一番大事なことが残ってます。

ポストモーテム（postmortem） です。直訳すると「検死」。インシデントが終わったあとに、「何が起きて、なぜ起きて、次どう防ぐか」を振り返って残す文書のこと。

なんでこれが一番大事だと思います？

障害そのものは、いつか必ずまた起きます。でも、ちゃんと振り返って残しておけば、次に同じ穴に落ちる人を減らせる。ポストモーテムは、未来の自分と、次にオンコールに入る誰かへの贈り物なんですよね。

ここで絶対に外せないのが ブレームレス（blameless＝犯人探しをしない） という原則です。GoogleやNetflixが広めたSREの文化で、「誰がやらかしたか」ではなく「何が、その失敗を可能にしてしまったか」を見る。

理由はシンプルで、人は、責められると本当のことを話さなくなるから。「お前のせいだ」となった瞬間、みんな情報を隠したり、責任をなすりつけ合ったりして、本当の原因にたどり着けなくなる。逆に、責めない空気があると、人は「実はあのとき、こうしちゃって…」と正直に話してくれる。だから根本原因に届く。

原因を掘るときは Five Whys（なぜを5回） を使います。「なぜ落ちた？」を繰り返して、表面の症状から、壊れたプロセスまで降りていく手法。ここに鉄の掟がひとつ。

「人」を根本原因にしてはいけない。「人的ミス」「Aさんの不注意」「Bチームのミス」は、答えとして認めない。

「Aさんが設定をミスした」で止めず、「なぜミスできる仕組みだったのか」「なぜレビューで気づけなかったのか」まで降りる。原因は人じゃなく、人がミスできてしまったプロセスにある、という見方です。

ちなみに MTTR（Mean Time To Resolution） は、「検知から完全復旧までにかかった平均時間」。P1（最重大）の業界中央値は45〜60分くらいと言われます。ポストモーテムでこの数字を残すと、改善が効いてるか後で測れます。

この初稿を、AIに書かせます。「空白ページ問題」——何から書けばいいか分からなくて手が止まるアレ——を一発で溶かせます。

プロンプト例③：ブレームレスポストモーテム初稿

あなたはSREです。以下のインシデント記録から、ブレームレス・ポストモーテムの初稿を作ってください。

# 絶対のルール
- 特定の個人・チームを「原因」として名指ししない（人を犯人にしない）。
- 原因は「プロセス・仕組み・設計」のレベルで書く。
- 事実と推測を分けて書く。推測には「推測:」と明記する。
- 責める表現を使わない。誰かが悪いのではなく、何が失敗を可能にしたかを書く。

# 入力（インシデント記録）
{タイムライン、対応ログ、復旧手順などを貼る}

# 出力フォーマット
## 概要（3行）
## 影響
- 重大度(Sev):
- 影響開始/終了(UTC):
- 影響を受けた機能/ユーザー範囲(ブラスト半径):
- MTTR(検知→復旧の所要時間):
## タイムライン（UTC時刻つき・箇条書き）
## 根本原因（Five Whys。人ではなくプロセスまで掘る）
## うまくいったこと（被害を抑えた要因）
## 再発防止のアクション（担当ロール・期限の枠つき。個人名は書かない）
## まだ分かっていないこと

そして、出てきた初稿が「ちゃんとブレームレスか」を、機械的にもチェックします。タイムラインの骨格をデータで持っておくと、後で検索もできて便利です。

コード例④：ポストモーテム骨格（YAML）＋ブレームレス簡易チェック（Python）

# postmortem.yml — 構造で持っておくと、後から検索・集計できる
incident: "決済APIの5xxエラー率上昇"
severity: "Sev-2"
impact_start_utc: "2026-06-02T17:40:00Z"
impact_end_utc:   "2026-06-02T18:25:00Z"
mttr_minutes: 45
blast_radius: "チェックアウト利用者の一部（約12%）"
timeline:
  - { t: "17:40Z", event: "エラー率が2%→18%に上昇、アラート発火" }
  - { t: "17:48Z", event: "直近デプロイ v1.42.0 を一次容疑として特定" }
  - { t: "18:05Z", event: "v1.41.0 へロールバック（人間承認のうえ実行）" }
  - { t: "18:25Z", event: "エラー率が平常値へ復帰、収束を確認" }
root_cause: "デプロイ前のスキーマ互換チェックが自動化されておらず、破壊的変更がすり抜けた"
action_items:
  - { owner_role: "release", task: "デプロイCIにスキーマ互換チェックを追加", due: "P14D" }
  - { owner_role: "oncall", task: "ロールバック手順をrunbook化", due: "P7D" }

import yaml

# 「人を犯人にしていないか」を雑にだが機械的に見張る
BLAME_WORDS = ["のせい", "が悪い", "担当者のミス", "不注意", "怠った", "さんがミス"]

def check_blameless(path: str) -> list[str]:
    data = yaml.safe_load(open(path, encoding="utf-8"))
    warnings = []
    rc = str(data.get("root_cause", ""))
    if any(w in rc for w in BLAME_WORDS):
        warnings.append(f"根本原因が人を責めている可能性: {rc}")
    # 根本原因が「プロセス/仕組み」の語を含むか（ゆるい目安）
    if not any(k in rc for k in ["仕組み", "プロセス", "自動化", "チェック", "設計", "手順"]):
        warnings.append("根本原因がプロセスではなく事象止まりかも（もう一段Whyを掘る）")
    return warnings

# warnings = check_blameless("postmortem.yml")
# warnings が空でなければ、人間がもう一度読み直す合図。

完璧な検査ではないですが、「無意識に誰かを責める一文が混じってないか」を立ち止まって見直すきっかけになります。ポストモーテムは、記憶が新しい 5〜7営業日以内 に、チームみんなで仕上げるのがおすすめです。

人間とAIの役割分担表＆撤退ライン

ここまでをギュッとまとめると、深夜3時に「誰が何を決めるか」は、こう分かれます。

局面	AIに任せる	人間が必ず握る
検知・仕分け	アラート要約、関連付け、影響範囲の整理	重大度(Sev)の最終判定
調査	ログ要約、原因仮説3つ、read-only調査	どの仮説を追うかの選択
復旧	アクション候補とリスク仕分け、ドライラン	破壊的操作の最終GO、顧客通知の判断
エスカレーション	状況サマリ生成、連絡先提示	「人を増やす」決断、コミュニケーション
振り返り	ポストモーテム初稿、タイムライン整理	根本原因の確定、再発防止の優先順位

ざっくり言うと、AIは「読む・要約する・並べる・下書きする」係。人間は「重大度・破壊的操作・顧客への約束・最終責任」を握る係。この線が引けていれば、AIをどんどん使っても怖くないです。

そして、入れてみて「これは引くべき」というサインも持っておきます。

撤退ライン	対応
AIが根拠（証拠・除外仮説・確信度）を出さない	調査の主役から外す。要約役に降格
破壊的操作が、承認ゲートを通らず実行された	即停止。read-onlyレベルまで戻す
ログのマスキングが追いつかない	機微サービスはAI投入を見送る
ポストモーテムが犯人探しになっている	ブレームレスの再教育。AI初稿も人がレビュー
AIの仮説に引っ張られ、人が思考停止している	仮説は「3つ並べて人が選ぶ」運用を徹底

最後のやつ、地味に大事です。AIが流暢に答えると、人はつい鵜呑みにする。AIは仮説を“広げる”ために使い、“決める”のは人間。この役割を崩さないことが、結局いちばんの安全装置になります。

おわりに：ログは、明日の自分への「あざっす」

長くなりました。最後に、ひとつだけ。

障害対応のログやタイムライン、ポストモーテム。あれって、書いてる最中はちょっと面倒なんですよね。早く寝たいし。でも、ちょっと考えてみてほしいんです。

それ、明日の自分への“あざっす”なんですよ。

深夜3時、ボロボロの頭で残した一行のメモが、来週オンコールに入る誰か——もしかしたら未来の自分——を救う。「あのとき残しといてくれて、あざっす」って。未来の自分から、そう言ってもらえる今日を生きる。これ、障害対応に限らず、ぼくがすべての選択の軸にしている考え方です。

ブレームレス（責めない）も、根っこは同じだと思っていて。「誰のせいか」を探す責める軸じゃなくて、「次どう助かるか」という思いやりの軸。責めないから、人は本当のことを話す。本当のことが残るから、未来が助かる。技術の話なのに、結局ここに行き着くのが、おもしろいところです。

AIは、その「残す」を、ものすごく軽くしてくれる相棒です。読ませて、要約させて、仮説を並べさせて、初稿を書かせる。でも手綱は、ちゃんと人間が握る。読む専用から始めて、信頼できたぶんだけ、少しずつ任せる範囲を広げていく。

今週の、最初の一歩はこれくらいで十分です。

次のオンコールに向けて、プロンプト例①（仮説駆動トリアージ） を手元にコピーしておく
AIに調査させるなら、コード例①の read-only allowlist を1枚だけ用意する
直近の小さなインシデントで、プロンプト例③でポストモーテム初稿 を1本書かせてみる
そのポストモーテムを、「人を犯人にしてないか」だけ 見直す

100点じゃなくていいんです。65点でも、明日の自分が「無理せず残しといてくれて、あざっす」って言ってくれるなら、それで十分。

その小さな一歩を、ちょっとずつ積んでいきましょう。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up