100万行の差分と400件超のコメントが引き起こす描画の破綻
大量のデータをブラウザやデスクトップ画面に一覧表示する際、画面内に見えている範囲だけを描画して要素を使い回す仮想スクロールは定番の設計です。各行の高さが均一であれば、全体のスクロールバーの長さや指定位置へのジャンプは単純な掛け算と足し算で正確に計算できます。
しかし、そこに折り返し文章や画像の読み込み、開閉可能な詳細エリアといった可変のコンテンツが混ざると、この前提は大きく崩れます。GitHub Blogの技術報告によると、GitHub Copilot appの開発チームは自社の検証として、2,200ファイル、100万行を超える変更、400件以上のインラインレビューコメントを含む巨大なプルリクエストを表示する検証を実施しました。
一行あたりの高さが確定しているコード行と異なり、レビューコメントの高さは画面幅による文字の折り返しや画像の読み込み完了など、実際に描画されるまで確定しません。事前に平均値などで枠を推定して確保すると、短いコメントでは不自然な空白が残り、長いコメントでは枠をはみ出して表示が切れてしまいます。さらに、描画後に実測した高さを全体の配置計算へ戻すと、スクロール中に下の行が一気にズレるスクロールジャンプが発生し、まともな閲覧ができなくなる問題が生じていました。
高さを2つの領域に分離する描画設計と計測の制御
この表示の乱れを解消するためにGitHubが採った設計は、画面の高さを「事前に確定できるコード行」と「あとから計測する動的ブロック」の2つに明確に分けることでした。コメントの高さ情報はコード行とは別のインデックスで管理され、コメントのサイズがどれだけ変わっても、コード行全体の配置計算を再構築しない仕組みになっています。
次に問題となるのが、動的に変化する高さをどのタイミングで測り、画面へ反映するかという点です。各要素の変化を監視する仕組みを素朴に配置すると、高さを測ってレイアウトを更新した処理自体が監視処理を再発火させ、マウントされたブロック数に応じて処理負荷が増える懸念が生じます。そこで、通常の計測はユーザーのスクロールが止まったアイドル時にまとめて行い、画面の表示領域の周辺にある候補だけを効率的に処理するルールが敷かれました。
一方で、ユーザーが自分で行った操作、例えばコメントの展開や入力欄の表示などは、次のアイドル時まで反映を待つと画面が不自然に二段階で動いて見えてしまいます。そのため、すでに画面上に表示されているブロックのサイズ変更に限っては、同一フレーム内で最大1回だけ同期して反映し、スクロール中は再び一括処理に戻すという例外処理が組み込まれました。さらに、スクロール位置の補正もピクセル単位の座標ではなく、「どの要素を閲覧していたか」という識別情報を基準に追従させることで、利用者の視線が勝手に飛ばない工夫が施されています。
ヘッドレス検証と実アプリの自動操作で「正常性」を判定する
こうした画面の不具合は、特定のデータ量や操作のタイミング、描画エンジンの状態が重なったときにだけ発生することが多く、手作業での再現や原因特定は困難を極めます。そこでGitHubは、画面が崩れていないかを客観的に判定できる計測情報をアプリ自身に組み込み、検証作業を自動化しました。
検証環境は2つの役割に分けられています。1つは、モックサーバーに対して画面のスクロールやウィンドウのリサイズといった操作を宣言的に実行するヘッドレスの計測環境です。ここでは描画回数や処理時間の内訳を直接読み取り、処理の詰まりを効率的に特定します。ただし、モックサーバーに対する計測は処理のボトルネックを迅速に絞り込むためのものであり、実際の画面で生じる挙動の確認は、実デスクトップアプリを動かす環境と役割を分けて進められました。
もう1つは、実際のデスクトップアプリを無人で反復操作する環境です。コメントが読み込まれる前の初期状態から、読み込みが完了した状態までを自動で動かし、動作時の計測結果を端末のログへ書き出します。このログをもとに、AIエージェントが「コメント間に不自然な隙間がないか」「中身が空のブロックが残っていないか」「スレッドの内容がスクロール範囲全体で正しく配置されているか」を判定し、改善のサイクルを回しました。目視での確認に頼るのではなく、何をもって正常とするかを明確に定義してアプリ自身に観測情報を持たせることで、原因の特定から自動テストへの固定までを機械的に進める手順が整えられました。
性能指標が語れる範囲と、過剰な解釈を避ける視点
画面の描画処理を改善して実行時間を短縮できた場合、その成果をどのように社内外へ説明するかも重要な論点です。画面の応答性が向上し、不自然な空白やガタつきが解消されたことは、測定されたログやテスト結果によって明確に示すことができます。
しかし、実行時間の短縮や画面の最適化を、そのまま消費電力の削減や二酸化炭素排出量の抑制といった環境負荷の改善と直結させて説明することはできません。GitHubが公開したソフトウェアの効率性に関する意識調査の報告でも指摘されているように、実行時間の変化だけで電力や排出量の削減を証明することはできず、実行するハードウェアの仕様や負荷の状況、利用地域や時間帯、電源構成などが複雑に影響します。
システムの改修を進める上では、実際に測定した表示品質や応答速度、処理回数といった具体的な指標に基づいて効果を把握し、計測範囲を超えた過度な効果の断定を避ける冷静な姿勢が求められます。
業務画面への応用とデノフにおける改修・検証の支援
今回の事例で扱われた設計や計測の考え方は、一般的な業務システムの画面改善にも通じる部分があります。例えば、数千件の受注明細や在庫一覧を表示する画面において、行ごとに担当者の長文メモや添付画像が挿入され、アコーディオンの展開や画像の読み込みに伴って閲覧位置が意図せずずれてしまうといったケースが考えられます。
こうした課題を抱えている場合、まずはどの操作やデータ量のときに空白や位置ずれが起きるのかを記録し、高さが固定の行と可変の要素を切り分けることから始めるのが実践的です。その上で、業務で利用している既存フレームワークや描画ライブラリの設定変更で対応できるか、それとも描画構造の分離やスクロール補正のロジック、不具合を再現するためのテストデータや自動操作の設計といった個別実装まで必要になるかを、症状と既存機能の調査を通じて判断していくことになります。
株式会社デノフでは、サービス案内でもご紹介している通り、業務システムの設計・開発・運用保守から、原因特定が難しい障害の調査、業務に合わせた社内ツールの開発まで継続的に対応しています。「大量のデータを扱う一覧画面で特定の操作を行うと表示が乱れる」「AIに調査や改修を支援させるための観測情報や再現環境を整えたい」といった段階から、具体的な改修対象の選定や検証範囲の整理を進めることが可能です。表示不具合の解消や画面の改善について検討されている際は、デノフへの相談窓口よりお気軽にお問い合わせください。
