アンチパターン（やりがち失敗）
この章で分かること
- 6つの典型失敗と、なぜ起きるのか
- 各失敗の「代わりにやること」
- 自組織チェック用の症状サイン
- どの章の対策に戻るか
たとえ話
近道に見える砂利道です。最初は速いが、雨（障害）のたびに車がスタックします。
アンチパターンは「速く見える設計」の地図です。
一覧マップ
6つと戻る章
1 生ログ常時LLM → 第6-7,12章 2 全部リアルタイム → 第3章 3 CI成功＝安全 → 第2,11章 4 広範な本番権限 → 第11-12章 5 ログ不足をAIで補う → 第6章 6 推測を事実扱い → 第8-9章
1. 生ログを常時LLMへ
| 症状 | なぜダメ | 代わり |
|---|---|---|
| 障害時にトークン爆発 | コスト・機密・文脈上限 | 基盤保存→必要時検索 |
| AI停止＝監視沈黙の感覚 | 障害ドメインが分離されていない | 検知は既存監視 |
2. 全部リアルタイム通知
行動できない情報までページすると、重要通知が埋もれます [S11][S14]。代わり: 行動可能性で三分類（第3章）。
3. CI成功＝本番安全
未テスト条件・性能・保安・外部影響が残ります。代わり: canary / feature flag / rollback / リスク別承認。
4. 広範な本番権限
誤操作と間接インジェクション [S08]。代わり: 最小権限・承認・allow list・timeout・監査。
5. ログ設計をAIでごまかす
入口が空なら何もできません [S02]。代わり: event_code / stacktrace / trace_id / version を先に。
6. 推測を事実扱い
誤った本番操作につながります。代わり: 根拠・反証・信頼度・確認方法を必須化。
運用担当者四半期で6項目セルフチェック
PGPRテンプレに「観測項目」を入れ、実装時に埋める
SEPRテンプレの観測項目を開発標準とレビューゲートにする
PM「全部リアルタイム」「全部自動」要求を切り分ける
経営層近道提案に出口条件を聞く
現場適用：30分セルフ監査
- 直近の障害対応チャットを1件開き、6アンチのどれに近いか印を付ける
- 通知一覧から「行動していないリアルタイム」を3件洗う
- AIツールの権限画面で実行系が無いか確認する
- 見つかった1件だけ来週の改善チケットにする
ふりかえり
- 6つのうち、自組織で一番近いものを1つ選べたか
- その対策として戻る章が分かるか