Diffs: コードレビューを革新する「CodeView」の技術深掘り

PIERRE COMPUTER CO., LTD.
2026 年 5 月 29 日投稿 / @amadeus

コード変更を検証しようとする際、小規模な変更であれば問題なく機能します。しかし、大規模なプルリクエスト（PR）を開くと状況は一変します。

• エージェントによる実装、テスト、フィクスチャ、スナップショットの生成
• 意図せず多くのファイルがブランチに含まれる
• レビューサプレース（レビュアーの負担）の増大

通常はファイルを一つずつ表示させたり、ナビゲーションに支障が出たりします。これらは技術的なトレードオフかもしれませんが、コストを発生させます：ツールへの不信感や回避措置が必要になります。

差分（Diff）描画自体が核心ではなく、レビューワークフローや自動化、CI 結果といったコードの周囲で起こる出来事こそが重要です。ゼロから再構築する必要はありません。そのため、約 6 ヶ月前に私たちは 「Diffs」 をリリースし、開発リソースを本質的な業務に集中させる環境を整えました。

当初のアプローチと課題

初期の実装は基本的なコンポーネント「File」と「FileDiff」のみでした。パフォーマンス改善のために簡易的なバーチャライザーやワーカースレッドを用いましたが、以下の問題がありました：

• 複雑性: O(n×m) の計算負荷が高すぎた
• メモリ使用量: 大きすぎた
• 表示の空白（Blanking）: スクロール時に発生する現象が解決しなかった

これらに対し、レビューサプレース全体を管理できる**上位レベルのコンポーネント「CodeView」**を構築しました。その目標は：

「いかなる差分でも描画できるようにしてほしい」

もちろん物理的制約（ブラウザメモリ、計算リソース）は無視できませんが、実用的な観点から非常に近い状態に到達しています。詳細な検証結果は DiffsHub.com のプレイグラウンドや最新 npm パッケージ

@pierre/diffs

で確認できます。

---

差分描画の真の難しさ

表面から見れば「テキストを HTML に変えるだけ」ですが、優れたレビュー環境には以下が必要です：

• 構文ハイライト
• 行番号、アノテーション、コメント
• テーマ設定、ビュー切り替え、折り返しモード
• カスタマイズ性

これら機能はコストと複雑性を増大させます。CodeView で扱うファイル単位の複雑さは、大規模レビュー全体では以下の 3 つのカテゴリに分類される大きな課題となります：

1. 描画（Rendering）: DOM 複雑性の急増によるブラウザのオーバーロード
2. 処理（Processing）: 累積的な操作コスト（例：数万回の更新）
3. メモリ（Memory）: レンダリングデータ構造によるメモリ制限接近とガベージコレクション頻発

単純な最適化では解決できず、これらを相互に関連する一つの課題全体として捉える必要があります。

---

バーチャライゼーション：空白のない描画技術

表示領域外にあるコンテンツを描画しない「バーチャライゼーション（ウィンドウ化）」は、メモリ削減や描画負荷軽減の標準手法です。しかし、スクロール時の「空白」を排除し、ネイティブな挙動を保つには工夫が必要です。

既存手法の限界

• 標準的なスクロール領域: ナイティブスクロールを保ちつつも、高速スクロールで空白が発生する可能性あり。
• **ステイキコンテナ（Sticky Container）`: requestAnimationFrame を用いるが、JavaScript が追いつかない場合画面がカクつきやすく、Safari での体験は劣る。
• 完全にシミュレート: 制御は自在だが、アクセシビリティや OS 間の挙動整合性が難しくなる。

Inverse Sticky Technique（逆ステイキ技法）

CodeView では、上述のトレードオフを解消するために独自のハイブリッド手法を採用しました。

【基本仕組み】 通常の「Sticky」は表示領域からコンテンツが出た際に上部に固定しますが、CodeView はそれを逆転させます：

• 下へスクロール時: コンテンツ下部をビューポート下部に固定（表示範囲外ではないため空白なし）
• 上へスクロール時: コンテンツ上部をビューポート上部に固定

これにより、「ネイティブスクロール」「描画更新の不完全さを許容」「大きなジャンプでも空白なし」という 3 つの目標を同時達成します。

技術的実装（負のオフセット） 両方の縁（トップ・ボトム）に

negative top

と

bottom

のステイキオフセットを使用し、以下の式で計算します：

offset = (contentHeight - viewportHeight) * -1

これにより、JavaScript が追いつかなければ描画領域が移動して空白を表示するのではなく、固定された縁として処理されます。

注: Safari では激しいスクロール時にコンポジティング層で待機し空白が発生する場合がありますが、技術的には解決可能であり、限界まで近づいています。

---

スケーラブルなレイアウト計算

バーチャライゼーションを実現した後の課題は、正確なレイアウトとサイズ計算です。推測値（Estimated）が実態に近いほど効果的です。

推測式の最適化

• ファイル:

  lineHeight × totalLines

• 差分: パース行数とハンクメタデータに基づく簡略式

// 推定高さの計算例
const estimatedHeight = (lineHeight * diff.splitLineCount) + 
                        (diff.hunks.length * hunkSeparatorHeight);

レンダリング範囲の決定と高速化

コードはビューポートサイズと位置情報に基づき、どのファイルをレンダリングすべきかを判断します。大規模データセット（数十万行）に対するパフォーマンス向上のために：

• バイナリサーチ: 行チェックポイントキャッシュを活用し、開始点の探索コストを削減
• デルタ保存: 推測値と実際の DOM を照合した誤差（デルタ）を保存し、修正コストを抑制

スクロールアンカー機能

ブラウザ標準のスクロールアンカーは、マウントされる DOM が絶えず変化するため有効ではありません。CodeView ではこれを自前で実装しています：

1. 完全に表示可能な最初の行を特定
2. ユーザーの現在表示位置（オフセット）を保存
3. DOM 変更をコミットし、高さ変化を調整
4. オフセットが変動しないようにスクロール位置を補正

これにより、レイアウト情報の保証がなくとも大規模差分でも安定した高速動作を実現します。

---

メモリ管理の高度化

大規模なファイルや差分（例：Linux v6 → v7 の差分で 700MB 級）に対し、以下の手法でメモリ効率が劇的に向上しました。

1. パース済み文字列のデタッチ

巨大な入力文字列がそのまま保持されるとメモリを圧迫します。パース済みの行コンテンツのみを取り出し、元の巨大なソース文字列との参照関係を切断（デタッチ）する処理を導入：

• 効果: Linux 差分におけるメモリ使用量は 2.4 GB → 約 1.15 GB に削減
• 併せて: パース時間は約 80% 削減

┌───────────────────────────────────────────────╖
│           メモリ使用量比較                     ╗
│                                               │
│   ████████████████████████████████████░░      │
│   ████████████████████████████████████░░      │
│   オリジナル：2.4 GB                          │
│                                               │
│   ────────────────────────────────────────    │
│                                               │
│   ████████████████████████░░░░░░░░            │
│   最適化後：1.15 GB                           │
│                                               │
└───────────────────────────────────────────────┘

2. DOM 要素プーリング

高速スクロールによる DOM 要素の頻繁な入れ替え（Churn）を回避するために、プーリング方式を採用：

• 一度作成したコンテナ（スタイル・テーマ・SVG アイコン等）を破棄せず再利用
• ガベージコレクション頻度を下げることでメインスレッドのパウズを抑制

3. オプション状態の共有

数千〜数万のインスタンスを持つ場合、各ファイルに独立して

options

を渡すとコストが爆発します。解決策として：

• CodeView が真理源（Source of Truth）となり、アイテムは共有状態から読み取る
• デコレーション的な変更では全アイテムを書き替える必要がなく、コードレビューの速度向上に寄与
• 実装後、Linux 差分でメモリ使用量をさらに 20〜30 MB 削減

4. 構文ハイライトの非同期処理（Deferred Syntax Highlighting）

大規模ファイルのハイライトはメインスレッドを止めるリスクがあります。そのため：

• ワーカースレッド: Shiki を利用し、メインスレッドから独立して高コストな作業を実行
• LRU キャッシュ: 短期的に描画されるファイルの出力をキャッシュ
• ストリーミング・API: コードが再び表示される際に重複処理を防ぎつつ上限を維持

これにより、ハイライトによるレビューサプレースは向上します。

---

まとめと未来へ

ブラウザという制約の中で、大規模な差分も円滑に動作させることを目指してきました。CodeView の実装には以下の技術が貢献しました：

• バーチャライゼーション手法: Inverse Sticky Technique
• レイアウト推定と最適化
• メモリ管理の強化（デタッチ、プーリング、共有オプション）
• 非同期ハイライト処理

まだ解決すべき課題も残っています：

• CSS コスト: 激しいスクロール時の描画負荷が依然として大きい
• シリアライズ問題: 数万行のファイルハイライトにおいてワーカープール経由でのデータ通信コストが高い
• 極端な長行への対応: ハイライトパイプラインのクラッシュ防止は別途必要

将来には、軽量な編集機能やサーバー側への一部移行も計画しています。その間は、**「いかなる差分でも描画できるようにする」**という目標を達成し続けることで、よりスムーズなコードレビューの文化を広げていく予定です。

P.S. Apple, Safari へのお願い

CodeView の多くは Chrome や Firefox のブラウザ機能に基づいていますが、WebKit（Safari）では一部機能が限界に達しました。特に以下の点で改善が必要です：

• スティッキーコンポジティングのパフォーマンス劣化
• JavaScript・描画系のデバッグ難易度の高さ

• requestAnimationFrame

  が高リフレッシュレイトでも 60Hz 制限

Safari でもファーストクラスの体験を構築したいと考えています。ご協力をよろしくお願い致します。