静的解析は、コードを実行せずに文法や型、危ない書き方をチェックする仕組みです。 lint、型チェック、セキュリティチェックなどが同じ文脈で出てきますが、見ているものはそれぞれ違います。
3つの層を分けて考える
- lint（書き方の検査）：未使用変数、命名、フォーマットなど。読みやすさと事故予防
- 型チェック：TypeScript のように、値の種類が噛み合っているかを検査する
- SAST（セキュリティ静的解析）：SQLインジェクション や XSS につながる書き方を探す
「静的解析を入れた」と言うとき、この3つのどれを指しているのかで効果がまったく違います。導入の相談では最初にここを揃えると話が早いです。
既存プロジェクトへ入れるときの罠
いちばんよくある失敗は、いきなり全ファイルに厳しいルールを適用して数千件の警告を出し、誰も見なくなることです。警告が多すぎる状態は、警告がゼロの状態より危険で、本当に効く指摘が埋もれます。 現実的な入れ方は次の順です。
- まず既存の指摘を「ベースライン」として除外し、警告ゼロの状態を作る
- 新規・変更したコードにだけルールを適用する
- 落ち着いてから、ベースラインを少しずつ削っていく
押さえておきたい注意点
静的解析が通っても、仕様違いや設計ミスは普通に残ります。「型が合っている」ことと「業務ルールとして正しい」ことは別問題です。 たとえば消費税の計算式が間違っていても、数値どうしの計算である限り静的解析は何も言いません。ここはテストとレビューの担当範囲です。
偽陽性とどう付き合うか
静的解析は「怪しい形」を見つける仕組みなので、実際には問題ない箇所も指摘します。ここで安易に全体のルールを切ると、本来拾いたかった指摘まで消えます。抑制は行単位・ルール単位に限定し、なぜ抑制したのかをコメントに残すのが基本です。抑制コメントだけが増えて理由が残っていないコードは、数か月後に誰も触れなくなります。
実務で見るポイント
- AI が書いたコードは、まず静的解析に通してから読むと粗い崩れを先に落とせる
- CI で回すなら、失敗させるルールと警告にとどめるルールを分ける
- 「何を見ていないか」を理解して使う。通過は品質の証明ではない
- ツール選定はBiome とは何か？も参考になります