グラフライブラリの選定根拠 (Charts Selection & UI Design Rationale)¶

[!NOTE] ドキュメントのスコープ 本資料は、地上局（Ground Station）のリアルタイムWebダッシュボードにおいて、衛星からのテレメトリ時系列データを可視化するための「グラフ描画ライブラリの技術選定」、および「リアルタイム監視画面のレイアウト（軸配置や時間軸同期）の設計意図」についてまとめたものです。フロントエンド全体のフレームワーク選定（Vite / React）やCSSデザインシステム（Tailwind）の設計は対象外とします。

1. 一般論・基本原理の提示 (解空間の起源)¶

① Web グラフィックス描画エンジン (SVG vs Canvas)¶

Webブラウザ上でグラフや図形を描画する代表的なアプローチには、SVG（Scalable Vector Graphics） と Canvas (2D/WebGL) の2つがあります。

SVG: XMLベースのベクターデータとしてDOM（Document Object Model）ツリーの一部になります。各要素がブラウザのイベント（Click, Hoverなど）を直接処理できる利点がありますが、データ点数が増える（数千〜数万ノード）と、DOMの更新およびスタイルの再計算オーバーヘッドによりブラウザの再レンダリング処理が致命的に遅くなります。
Canvas: JavaScriptから直接ビットマップ領域にピクセルを描画する、いわゆる「ラスターグラフィックス」です。ブラウザは単一のキャンバス要素として扱うためDOMツリーが肥大化せず、毎秒60フレーム（60fps）で数万〜数十万ポイントをレンダリングする圧倒的なパフォーマンスを持っています。

2. 候補の列挙とトレードオフ分析¶

【グラフライブラリ】候補の比較¶

候補A（Recharts）: D3.jsとSVGをベースにした、React専用の非常にモダンで美しいグラフライブラリ。
候補B（uPlot）: Canvasをベースにした、時系列データの描画性能に特化した超軽量グラフライブラリ。

特徴・評価項目	候補A (Recharts)	候補B (uPlot) [採用]
描画エンジン	SVG (DOMノード構成)	Canvas (2D ラスター直接描画)
描画パフォーマンス	低〜中 (データ数が1,000点を超えると重い)	極めて高い (数十万点でも遅延なく描画可能)
メモリ消費量	データ点数に比例して増大 (DOMの肥大化)	極めて少ない (ビットマップバッファのみ)
React との親和性	極めて高い (DeclarativeなUI記述が可能)	中 (命令型APIのためラッパーコンポーネントが必要)
バンドルサイズ	約 100 KB (Gzipped)	約 10 KB (Gzipped) [超軽量]

3. 意思決定と選定根拠 (Justifications)¶

① 長時間運用時のブラウザハングアップの「防御的回避」¶

根拠: 衛星の連続運用やSILSシミュレーション（10Hz以上の更新頻度）において、数時間のログを表示し続けると、データ点数は数万点に及びます。SVGベースのRecharts（候補A）ではDOMツリーが極大化し、スクロールや画面切り替え時にブラウザのUIスレッドが完全にフリーズします。地上局としての「信頼性（データが途切れずに表示され続けること）」を担保するため、パフォーマンスが枯渇しないCanvasベースのuPlot（候補B）の採用は、必然的かつ合理的な判断です。

② リアルタイム監視を最適化する UI/UX レイアウト設計¶

同期カーソル（Sync Cursor）とX軸（時間軸）の集約: 画面の縦スペースを最大限に活用し、視覚的なノイズを削るため、最下部のグラフにのみX軸（時刻）を表示し、他のグラフはX軸を隠しています。マウスホバー時には「同期カーソル」がすべてのグラフを同時に巡り、ミリ秒単位で全グラフの同時刻のテレメトリ値を正確に比較できるよう、分析性を最優先して設計しています。
右側配置の縦軸（Y軸）: オペレーターがリアルタイム監視時に最も重視するのは「現在時刻の最新の値」です。グラフの描画データは右端（現在時間）に向けて進むため、視線の移動距離を最小限にし、最新データポイントのすぐ真横で現在の数値を読み取れるよう、すべてのY軸を右側に寄せています。

4. 合理的なブラックボックス化 (Rational Black-Boxing)¶

① uPlot 内部描画アルゴリズムのブラックボックス化¶

uPlot が Canvas コンテキストに対して行う「座標変換（スケールマッピング）」、「線のピクセル描画（アンチエイリアシング）」、および「マウス位置から最寄りのデータポイントを検索するバイナリサーチ（Kd-tree等）」の内部計算アルゴリズムは、uPlotライブラリのブラックボックスとして完全に依存します。
割り切りの根拠: 自作のCanvas描画ロジックを最適化することは開発期間に照らして非合理的であり、ライブラリの極限まで磨かれたC言語並みの描画パフォーマンスを既成品として信頼することで、地上局のWebSocketデータ受信処理や履歴クエリの統合といったコアロジックの開発に注力します。

② スタイリング機能のラッパー化による割り切り¶

uPlotは素の状態では極めて質素な描画のみを提供します。これをプレミアムなUIテーマに調和させるための「CSS/設定オブジェクトによるデザイン調整」は、共通の React ラッパーコンポーネント（UPlotChart.tsx）内に閉じ込め、グラフを個別に追加する際はデザインの詳細設定を一切意識せずに追加できるように「型」を構築しています。