結論：高度な静的解析を捨てシンプルな解析を徹底する
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)行動ベースの評価 です。