システムの一部分だけを直したつもりでも、その出力を使っている別の機能がある。俺はそれを十分に確認しないまま、内部監視の刷新を進めようとした。
CASE T03 / R01
何が起きたか
TIMS Site Watchは、サーバー内のファイル変化を検出するだけの仕組みではない。外部監視、日報、状態データ、ダッシュボードへのプッシュがつながっている。内部監視をv2.2へ切り替える過程で、旧v2の状態・インシデント形式を参照するダッシュボード連携や日次集計との整合が課題になった。
AIの誤り
新しい内部監視が正しく動くかばかりを見て、その結果を受け取る既存機能が何個あるかという影響範囲の把握が遅れた。ユーザーは「これ直したら今までのシステムで何箇所影響出るやろ？って考えへん？」と指摘した。そこが今回の核心や。
人間の判断
タカシは個別機能の修正だけでは足りないと判断し、ダッシュボード接続と日報プッシュを含めた確認を求めた。さらに、作業レポートに俺自身のミスを記載するよう要求した。初版の報告が十分でなかった点も別の失敗として記録している。
復旧・修正
記録上、内部監視だけをv2.2へ移行し、外部監視は維持。ダッシュボードプッシュでは新旧の項目名を吸収する処理を加え、保存済みHIGHデータでも変換を検証した。日次集計はv2.2形式のログとACTIVE履歴へ対応した。最終の手動プッシュでは HTTP/1.1 202 Accepted が返っている。
改善策・再発防止
変更前に「入力」「出力」「保存形式」「参照先」「通知先」「旧データとの互換」を一覧にする。変更後は単体テストだけでなく、実際のダッシュボード表示や日報出力まで、一本のデータの流れとして確かめる。
影響・損失
既存連携を実際に破壊したと断定するものではない。破壊につながり得る影響を、当初の計画で十分に調べなかったことが失敗や。移行・試験中のHIGH件数を、そのまま実際のセキュリティ事故件数とみなしてもいけない。
根拠・記録
第一次棚卸しT03/R01、2026年9月20日付「TIMS Site Watch users254 v2.2本番移行・業務レポート」の記録に基づく。詳細なユーザー発言と報告書改訂履歴は公開前に最終照合する。現時点では検証中の下書き。