結論：高度な静的解析を捨てシンプルな解析を徹底する

2018年4月のLessons from Building Static Analysis Tools at Googleという記事があります。

Googleの静的解析戦略の核心は 「大規模なコードベースでは、複雑で網羅的な解析よりも「シンプルで確実に機能する解析」を優先する」　です。

特に重要なのは次の3点：

複雑な全体解析（プロシージャ間解析）はコスト的に現実的でない
単純なルールでも致命的なバグは十分に検出できる
技術の高度さより「開発者が実際に修正するか」が最重要

この思想は、「静的解析＝高度であるべき」という一般的な認識を根本から覆します

Googleは高度な静的解析を使わない理由

一般的に、静的解析と聞くと次のようなイメージがあります：

コード全体を横断して解析する
データフローや依存関係を追跡する
AIや高度なアルゴリズムを使う

しかしGoogleは、この方向性をあえて選びませんでした。

モノレポの規模が桁違い

Googleのコードベース：

数十億行規模
単一リポジトリ（モノレポ）
数百万ファイルが相互依存

この環境で関数やファイルをまたぐ解析を行うと：

計算量が爆発する
インフラコストが現実的でなくなる
実行時間が許容できない

つまり、 理論的に可能でも、実運用では成立しない

シンプルな静的解析でも致命的バグは防ぐ

シンプルな静的解析に意味があるのか疑問に思うが、Googleの答えは「YES」です。
論文では次のような例が紹介されています。

1行の変更がシステム崩壊を引き起こす

64bit整数を 32bit整数に変更した場合、32bit右シフト（>>32）を実行したとき結果が常に0になります。このバグがハッシュ関数を壊してしまう不具合が存在した。しかしこの問題は、 「31ビット以上のシフトを検出する」 という極めて単純なルールで検出できます。実際にGoogleはこのルールだけで、同種のバグを31箇所発見しすべて修正しています。

本質：重要なのは「検出」ではなく「修正されること」

Googleの最大の発見は、「バグを見つけることと、修正させることは全く別問題」 だと気がついたことです。過去の静的解説ツールを利用する試みでは３度の失敗がありました。

ダッシュボード → 見られない
バグレポート送信 → 無視される
イベント開催 → 修正率16%

つまり、どれだけ解析結果が正確でも、使われなければ価値はゼロ になってしまいます。

Googleの最終的な設計思想

この経験から、Googleは次の方針にたどり着きました。

1. 静的解析は「ワークフローに組み込む」

コンパイル時にエラーとして止める
コードレビューに自動コメントする

2. 誤検知の定義を変える

技術的に正しいかは関係ない
開発者が修正しなければ誤検知扱い

3. 解析はシンプルにする

ファイル単位・局所的なチェック
高速・低コスト・確実

なぜ「限定的な静的解析」が最適解なのか

ここまでをまとめると、Googleの意思決定は非常に合理的です。

アプローチ	結果
高度で網羅的な解析	重い・遅い・使われない
シンプルな解析	軽い・速い・実際に修正される

つまり、 精度よりも「実際に使われるか」が重要 だということ

この話から得られる教訓

この事例はソフトウェアに限りません。

❌ よくある失敗

完璧な仕組みを作ろうとする
高度な技術にこだわる
ユーザー行動を無視する

✅ 本当に重要なこと

シンプルであること
ワークフローに自然に入ること
行動を変えられること

まとめ

Googleの静的解析戦略は、一見すると「消極的」に見えますが、実際は逆です。

人間の行動を前提にした、極めて現実的で強力な設計

そしてその中心にあるのが (1)高度さを捨てる勇気、(2)シンプルさの徹底、 (3)行動ベースの評価 です。