scc v4.0.0 リリース：Hotspots と Git メトリクスでコード品質を可視化

本日、scc（および

cloc

、

code AKA scc

）のバージョン 4.0.0 がリリースされました。当初はマイナーバージョンアップを検討しておりましたが、導入された新機能の規模感から主要バージョンへの昇格が有意義だと判断いたしました。今回はその中でも特に注目すべき新機能について詳しくご紹介します。

ホットスポット (Hotspots) の実装

過去に Google がバグ予測機能として「ホットスポット」を検出しようとした試みはありますが、開発者が実用性とみなしませんでした。 scc v4.0.0 では、複雑性推定値を用いてノイズを除去したアプローチを採用しました。

複雑なコードこそが最も注意を必要とする！ （参照：Adam Tornhill 氏の『Your Code as a Crime Scene』より）

仕組みと出力内容

Hotspots は、

0〜100

の正規化された「複雑性 × コミット回数」で計算されます。これにより、単純な集計では見落とされる以下のリスクを特定できます。

• 複雑だが変更が少ないコード: 保守性が低い箇所。
• 単純だが頻繁に変更されるコード: セットアップやテンプレートなどのノイズ。

$ scc --hotspots
───────────────────────────────────────────────────────────────────────────────
Hotspots · last 1000 commits · 2019-07-21 → 2026-06-26
───────────────────────────────────────────────────────────────────────────────
File                            Lang   Cmplx  Commits   Lines±  Authrs  Hotspot
───────────────────────────────────────────────────────────────────────────────
processor/processor.go            Go     156      156    1,651      13    100.0
processor/workers.go              Go     244       92    3,617      15     92.2
test-all.sh                    Shell      56      181    3,287      15     41.7
...

• processor/processor.go

  や

  processor/workers.go

  は、複雑性が高いかつ変更頻度が高いため、バグや論理問題が発生しやすい「ホットスポット」として正しく特定されています。
• これらの情報は、コードベースのオンボーディングや、どこに技術的負債が潜んでいるかを知る上で極めて有用です。

実行深度 (--depth) の指定

Git コミットの遡る深さを変更することで、ホットスポットのシフトを検証できます（例：過去 50 コミット分など）。

$ scc --hotspots --depth 50
───────────────────────────────────────────────────────────────────────────────
Hotspots · last 50 commits · 2026-04-13 → 2026-06-26
...
processor/processor.go            Go     156       14      415       4    100.0
main_test.go                      Go     261        8      295       4     95.6
...

注意: この指標は「バグがある」ことを示すのではなく、「扱いにくい箇所（分割すべき箇所）」を示すインジケーターです。また、Git のインストールは不要で、

github.com/go-git/go-git

を内部で利用し単一バイナリとして動作します。

パフォーマンスへの影響

Hotspots 機能を実行するには Git 履歴の分析が必要となるため、通常の

scc

実行よりも時間がかかります。

$ hyperfine 'scc' 'scc --hotspots'
Benchmark 1: scc
  Time (mean ± σ):      11.2 ms ±   0.4 ms    [User: 15.2 ms, System: 7.6 ms]
  Range (min … max):    10.6 ms …  13.5 ms    194 runs

Benchmark 2: scc --hotspots
  Time (mean ± σ):      4.739 s ±  0.068 s    [User: 3.341 s, System: 1.611 s]
  Range (min … max):    4.707 s …  4.930 s    10 runs

Summary
  scc ran
  421.57 ± 14.52 times faster than scc --hotspots

• MacBook Air (M1) を使用した計測結果。
• 通常の動作（約 12ms）に対しては約 4000 倍の遅延が発生します。
• これは計算負荷が増えるためのものであり、致命的な遅さではありません。

変更結合性 (Change Coupling)

特定のファイルの変更が、他のどのファイルにもたらす影響（ブラスト半径）を把握する機能です。コンパイラチェックを行わないコードやランダムなファイルに対する依存関係の可視化に有効です。

$ scc --coupling
───────────────────────────────────────────────────────────────────────────────
Change Coupling · last 1000 commits · 2019-07-25 → 2026-07-20
───────────────────────────────────────────────────────────────────────────────
File A                      File B                      Shared Commits Coupling
───────────────────────────────────────────────────────────────────────────────
languages.json              processor/constants.go                 198    67.8%
LANGUAGES.md                languages.json                         167    61.2%
...

個別ファイルの結合性 (--coupling-for)

特定のファイルを指定して、関連する変更を伴う他のファイルを探すことができます。

$ scc --coupling-for ./processor/detector.go
───────────────────────────────────────────────────────────────────────────────
Related File                                          Shared Commits   Coupling
───────────────────────────────────────────────────────────────────────────────
processor/detector_test.go                                        26      49.1%
processor/workers.go                                              15      12.1%
...

• detector_test.go

  が高結合性であることを示すため、検出器を変更する際はテストコードも合わせて更新する必要があることを警告します。

重み付けオプション (--coupling-weighted)

複雑性の低いファイル（定義のみなど）のランクが上がるのを防ぐために、複雑性でスコアを調整できます。

$ scc --coupling-weighted --coupling-for ./processor/detector.go
───────────────────────────────────────────────────────────────────────────────
Related File                                          Shared Commits      Score
───────────────────────────────────────────────────────────────────────────────
processor/detector_test.go                                        26      100.0
processor/workers.go                                              15       57.7
processor/processor.go                                            13       50.0
...

Git メトリクスとインフォグラフィック

scc は内部に Git サポートを組み込んでおり、以下のメトリクスを計算できます。

タイムライン分析 (--timeline)

時間の経過とともに言語ごとのトレンドやコード量の推移を確認できます。JS から TS への書き換え監視などにも役立ちます。

$ scc --timeline
───────────────────────────────────────────────────────────────────────────────
Languages · last 1000 commits · 2019-07-21 → 2026-06-26
───────────────────────────────────────────────────────────────────────────────
Language             Trend                             Code    Share     Change
───────────────────────────────────────────────────────────────────────────────
Go                   ▂▂▂▂▂▂▂▂▂▃▃▃▃▃▃▃▃▃▃▃▃▄▆▆▆▇      37,868    65.2%    +33,595
JSON                 ▄▄▄▄▄▄▄▄▄▄▅▅▅▅▅▅▅▅▆▆▆▆▆▆▆▇      12,944    22.3%     +6,236
...

著者分析 (--by-author)

コミットごとの貢献度や、後任の計画（Bus Factor）を計算できます。重複したメールアドレスを持つ著者の統合には

.mailmap

の設定が推奨されます。

$ scc --by-author
───────────────────────────────────────────────────────────────────────────────
Authors · last 1000 commits · 2019-07-24 → 2026-07-08
───────────────────────────────────────────────────────────────────────────────
Author                               Code     Cmplx   Files     Owns  Last seen
───────────────────────────────────────────────────────────────────────────────
Ben Boyter (github.com)            18,901     1,839      59    37.9% 2026-07-06
apocelipes                         16,740       299      11    33.6% 2026-06-26
...
Bus factor 2 · Ben Boyter (github.com) + apocelipes

統合レポート (--report)

全ての指標（新機能含む）を可視化した HTML レポートを生成できます。管理職向けの報告書作成などに適しています。

$ scc --report
Report written to scc-report.html

認知複雑性 (Cognitive Complexity)

従来の循環的複雑性に加え、**コードの形状（インデント数）**も考慮した近似計算を導入しました。

• 理由: 循環的複雑性はコンパイルエラーがない場合でも限界があり、scc はすでに安価な近似値を使用しているため。
• 手法: インデント数をネスト度の指標として利用し、分岐条件で乗算係数を適用します（LLM のコード分析の慣習に基づく）。
• メリット: 複雑性カウントが劇的に増加する「扱いにくい」ファイルを特定できます。

  $ scc --cognitive main.go
  # Go: Complexity → 103 (従来の 40 に比較)
  

パフォーマンス: CPU 使用量は約 1% のコストしかかからないため、実質的に無料の近似値として推奨されます。デフォルトはオフですが、Config ファイルで有効化可能です。

設定ファイル/Dotfile サポート (v4.0.0 新機能)

.sccconfig

ファイルを追加することで、CLI 引数なしでのグローバルなオーバーライドが可能になりました。

• 場所: プロジェクトルートディレクトリまたは環境変数

  SCC_CONFIG_PATH

  で指定したパス。
• 内容例:

# count the way I like it
--no-cocomo
--exclude-dir node_modules
--format wide

• このファイルには CLI 引数を記述するだけであり、悪意のあるスクリプトへの書き込みは防がれています。
• 例：広範囲な表示や

  node_modules

  の除外、COCOMO 計算の無効化などが設定できます。

その他新機能と改善点

• MCP サポート: 内蔵の Model Context Protocol (MCP) を備え、ローカル LLM と連携してコードベースの複雑性を発見・トークンを削減する用途に利用可能です（searchcode 等との相性も良好）。
• LOCOMO: LLM を通じてコードベースの再構築コストを予測する独自の指標を提供。
• 言語検出機能: Linguist 由来の機能を強化し、C++/ObjectiveC/C のヘッダー判定などがより精密化しました。
• JSON パーセント表示:

  jq

  を利用した処理への対応。
• 外部無視ファイル:

  --ignore-file

  オプションに対応（例：

  ~/.config/git/ignore

  ）。
• パフォーマンス調整: 多数の微小なバグ修正と性能チューニングが施されています。

まとめ

10 年前、Google は「ホットスポット」の概念を提唱しましたが、実装方法の問題で見送られました。scc v4.0.0 では、ノイズを除去したアプローチにより、オンボーディングや技術的負債の特定に極めて有効なツールとして蘇りました。

GitHub から最新バージョンを取得し、未経験のコードベースに対して

--hotspots

コマンドを実行してみてください。正しくリスクのある箇所が示されるかご確認ください。