第13章：定期レポートと継続改善

この章で分かること

日次・週次・月次で見るものとアクションの対応
定期が「暇つぶし」ではなく行動トリガーであること
AIに任せる草案と、人が決める優先順位の切り分け
第5層（学習）とKPI章をつなぐ運用サイクル
レポートの型とダメな例

たとえ話

毎日の体温、毎週の家計、毎月の健康診断です。全部を毎秒測らない。
でも測ったあとに「で、何をする？」が無いと、数字は飾りになります。

1. 周期別の見るもの／やること

周期	見るもの	そのあとやること	AIの役割	人の役割
日次	重大エラー、LLMコスト急騰	暫定抑制、暴走ジョブ確認	要約・異常候補	止める／様子見の判断
週次	再発、アラートノイズ、ランブック不足	手順更新、ルール修正チケット	TopNと草案	優先3件に絞る
月次	MTTR、容量、費用対効果、件数	投資判断、体制見直し	比較資料	予算と方針

2. 改善サイクル（図）

観察 → 優先順位 → 変更 → 効果確認

定期レポート
   → 改善候補（多め）
   → 人が3件に絞る
   → 監視/ログ/手順/権限のいずれかを変える
   → 翌週のKPIで効いたか見る

レポートの成功条件は「ページが増えた」ではなく、次の1アクションが決まったことです（KPI章と同じ）。

2b. エラーバジェット政策との接続

週次・月次で「信頼性作業に寄せるか／機能開発を進めるか」を決めるときは、エラーバジェットの消費度合いと政策（policy）をセットで見ます [S13][S18]。
例: バジェット枯渇時はリリース凍結・信頼性バックログ優先、といった事前合意。「今月の数値」だけ並べても行動にならない、という点は定期レポートと同じです。

3. レポートの型（コピー用）

期間:
ハイライト（事実3つまで）:
悪化している指標:
改善した指標:
推奨アクション（最大3）:
  - 内容 / 担当 / 期限 / 期待するKPI変化
見送りと理由:
リスク・注意（AI追加リスク含む）:

「全部重要」はレポート失敗です。AIが20個出しても、人は3個に削ります。

4. やると効く観点（最低セット）

必ず見る

MTTR中央値
誤アラート／ノイズ
再発
ランブック更新の滞留

AI導入後に追加

提案誤り率
承認拒否率
件あたりAIコスト
レポート作成時間そのもの

運用担当者週次のオーナーになり、3件ルールを守る

PGログ追加・テスト追加を小さなPRで受けられる形にする

SE週次改善をバックログ化し、優先度と担当を調整する

PM月次で投資判断に使う指標を先に宣言する

経営層「報告がある」より「何を止めて何を増やすか」を聞く

5. 現場適用：週次レポート記入例（短く）

期間: 2026-07-07〜07-13
ハイライト:
  - SEV-2が2件（うち1件はデプロイ後）
  - 誤アラート率が前週比+8pt
悪化: 注文APIの再発
改善: MTTA中央値が40分→28分
推奨アクション(3):
  1) canary通知の閾値見直し / 運用 / 7/18 / 誤アラート↓
  2) order-apiにevent_code追加 / 開発 / 7/20 / 初動短縮
  3) ランブック「決済タイムアウト」更新 / 運用 / 7/17
見送り: LLMコスト詳細分析（件数が少ない）
注意: 読取AIの参照範囲拡大の要望あり → 第12章ゲート未通過

ふりかえり

定期レポートの受け手と期待アクションが書かれているか
週次でアクションが3件以内に収まっているか
前週のアクションの効果を翌週見ているか