メンテ中の青脈動と完了の緑枠、実行中サイトのマーカー方式検出、3 状態の視覚階層と続いてきたサイト一覧の視覚化シリーズですが、v1.6.8 でさらに 3 件の UX 改修を加えました。本稿はその設計記録です。
いずれも共通の起点は「10〜20 サイトを一括メンテしている最中に、途中経過や結果が分かりにくい」という感覚です。全サイトが終わるまで数十分かかる一括メンテで、この時間をどう過ごしやすくするかが設計の出発点になりました。
改善 ① — 1 サイト完了の瞬間にサムネとバッジを更新する
従来、サムネイル（アイキャッチ画像）と未更新プラグインバッジは一括メンテが全サイト終了後にまとめて更新されていました。10 サイトのメンテで最初のサイトが終わっても、残り 9 サイトが終わるまでサムネは古いままです。
改修では「1 サイト完了を検出した瞬間に、そのサイトだけをリフレッシュする」動作に切り替えました。実装の核は _refreshCompletedSitesNow という関数で、ストリーミングログのループ内でサイト完了マーカーを検出するたびに、
- そのサイトの
?v=<mtime>を更新してサムネのキャッシュバストを起こす _invalidatePendingPluginCacheForSiteIdsでプラグインバッジのキャッシュを部分消去し再描画する
という 2 ステップを実行します。後ろに控えているサイトの処理に干渉せず、対象サイト 1 件だけを更新する点がポイントです。
改善 ② — エラーになったサイトを赤で 24 時間残す
完了した後に「どのサイトがエラーだったか」を一覧で把握できるようにするため、site-error CSS クラスを新設しました。赤いフチ（#ef4444）と薄い赤背景（rgba(239,68,68,0.08)）の組み合わせで、グリッド表示・リスト表示の両方に効きます。既存の running / completed / pending と同じパターンで実装してあり、状態の優先度は running > error > completed > pending の順です。
エラー状態は完了タイムスタンプから 24 時間保持します（_siteErrorStatus マップで管理）。24 時間は V33 の緑枠と同じ時間軸で、「今日のメンテ結果」として見える期間として選んでいます。再メンテを開始した段階で前回の赤枠はリセットされるので、二重保存や引きずりは起きません。
誤検出防止 — マーカー行だけで判断する
エラー検出のロジックで最も慎重に扱ったのは「誤検出を防ぐ」という点です。ストリーミングログには保守ツールの内部メッセージが大量に流れます。その中から「このサイトはエラーだった」を拾うとき、あいまいな行まで対象にすると誤った赤表示が起きます。
実装では、各サイト処理の末尾にエージェント側から1 行だけ確定的なマーカーを出力し、フロント側はその行だけを見て判定します。
[サイト名] ✗ メンテナンス結果: エラー
[サイト名] ✓ メンテナンス結果: 完了
「メンテナンス結果:」という文字列を含む行のみを対象とし、それ以外の行は無視（緑のまま）という保守的な設計です。ストリーミングログのマーカー方式で確立した「明確なマーカー 1 つに絞る・取り違え防止」の原則を、エラー検出にも踏襲しています。
判定不能な行を誤検出しないことを優先しているため、マーカーが出なかったサイトは「完了（緑）」扱いのまま残ります。エラーを見逃す可能性より、エラーを誤って赤表示する方が混乱を生みやすいと判断した結果です。
改善 ③ — メンテ完了後に選択チェックを自動解除する
複数サイトを選んで一括メンテを実行した後、選択チェックが残り続ける問題がありました。次の操作で「全選択のつもりが前回の選択がそのまま残っていた」という誤操作につながります。
改修では _finalizeMaintenanceRun（通常メンテ・選択プラグイン更新の両経路が通る終了処理）に、対象サイト（_runningSiteIdOrder）の選択を自動解除するステップを追加しました。UI トグルは作らず、必ず自動解除する設計にしています。
完了後のサイトは緑枠（成功）または赤枠（エラー）で 24 時間残るので、「どのサイトをメンテしたか」の記録はチェック以外の形で見えます。メンテ履歴の代替表示として機能するため、チェックがなくなっても文脈は失われません。
まとめ
3 つの改修を通じて、サイト一覧の状態は「waiting / running / completed / error」の 4 状態を扱えるようになりました。V33 の青脈動と緑枠で「実行中」と「完了」を視覚化し、V44 の視覚階層で 3 状態の強弱を整理し、今回でエラーが明示的な第 4 状態として加わっています。
共通しているのは「判定できない場合はより安全な側に倒す」という設計方針です。完了即時反映は「部分更新が全体に干渉しないこと」を保証する、エラー判定は「誤検出をゼロにすること」を優先する、選択クリアは「次回の対象を明示的に再選ぶ」を強制する。それぞれ別の問題ですが、同じ方向を向いた判断の積み重ねです。