静的解析とは？検査の仕組み

脆弱性の話題を追っていると、対策の一つとして「静的解析をやりましょう」という言葉をよく耳にします。コードを検査するもの、という認識はあるのですが、具体的に何をどう調べるのかと聞かれると、うまく説明できません。

テストとは違うのか。ツールを入れれば、脆弱性まで全部見つけてくれるのか。今回は、その「コードをチェックする何か」という理解から一歩進むために、仕組みと使い方を調べてみました。

静的解析は、コードから問題の手掛かりを探す

静的解析は、検査対象のプログラムを実行せずに、ソースコードやコンパイル後のコードなどを調べる方法です。アプリを操作して結果を見る代わりに、コードの構造、値の型、処理の分岐やデータの流れなどから問題の可能性を探します。

「静的」なのは、調べるために対象のアプリを動かさないという意味です。解析ツール自体は動きますし、種類によってはビルドの準備も必要です。ソースを眺めるだけの作業、と考えると少し違いました。

たとえば、絶対に通らない処理

この関数は、return 100に来た時点で処理を終えます。その後ろのconsole.logには到達しません。「画面で何回か試してみたら動かなかった」のではなく、処理の並びから指摘できる問題です。

このように、解析ではコードを単なる文字列としてだけでなく、意味を持った構造として扱います。ESLintなら構文を木構造にした情報へルールを適用します。さらに高度な解析では、条件分岐をたどったり、外部から来た値がどこへ渡るかを追ったりします。

静的解析とSASTは、まったく同じ言葉？

静的解析は幅広い検査の呼び方です。書き方や誤りを調べるLint、型の整合性を調べる型チェックなども含まれます。TypeScriptが「数値のつもりで扱っているけれど、文字列かもしれない」と気づかせてくれるのも、その身近な例です。

そのうち、セキュリティ上の弱点を探すことに重点を置いたものがSAST（Static Application Security Testing）です。たとえば、外部入力が適切に扱われず、危険な処理に渡る経路を検出するツールがあります。何を追えるかは、言語・フレームワーク・ルールによって変わります。

一方、使っているライブラリの版を既知の脆弱性情報と照合する検査は、一般にSCA（Software Composition Analysis）の領域です。npm auditのような依存関係の検査を行ったことと、自作コードをSASTで調べたことは、分けて考える必要があります。

どうやって実施する？小さく始める順番

1. 目的を決める。「型の間違いを減らしたい」のか、「セキュリティ上の危険な処理を探したい」のかを整理する。
2. 言語とフレームワークに合うツールを選び、対象ファイルとルールを設定する。
3. ローカルで実行し、指摘された行だけでなく、その前後と理由を読む。
4. 必要な修正を行い、再解析とテストで確かめる。
5. チームで基準を合わせ、エディターやCIでも同じチェックを繰り返せるようにする。

図の例は、ESLintを導入済みの環境で、no-unreachableというルールだけを有効にして調べました。大きな設定を最初から理解しようとするより、「このルールが、なぜこの行を問題にするのか」から読むと、役割がつかみやすくなります。

実行コマンドの例は、npx eslint --no-config-lookup --rule "no-unreachable:error" sample.js です。ESLintをプロジェクトへ導入したうえで使います。--no-config-lookupはこの作例を一つのルールだけで試すための指定で、通常の開発で既存設定を無視することを勧めるものではありません。

指摘は、消す前に読む

指摘には、本当に直すべきものも、条件を詳しく見ると問題にならないものもあります。後者は誤検知と呼ばれます。逆に、指摘されない問題が残ることもあります。

警告を一括で無効化したり、自動修正をかけて終わりにしたりせず、変更内容と意図を確認します。例外を認めるなら理由を残す。初めから全ルールを厳しくするより、重要な指摘を継続して読める運用にしたいところです。

AppliParkでは、ESLintをCIに組み込んでいる

AppliParkのフロントエンドでは、ESLintを使っています。Next.jsのCore Web Vitals向け設定とTypeScript向け設定を取り込み、npm run lintでチェックする構成です。

このチェックは、mainブランチ向けのプルリクエストとmainへの更新をきっかけに動くCIにも組み込んでいます。同じフロントエンドのジョブでは、テストとビルドも順に実行します。2026年11月5日に設定と直近のmainのCI成功を確認しました。

ここで確認できるのは、Lint・テスト・ビルドを継続して行う仕組みです。それだけをもって「SASTで脆弱性を網羅的に検査している」とは言えません。今後は、セキュリティに特化した解析も、対象のコードと検出できる範囲を確かめながら取り入れていきたいと思います。

「チェック済み」の中身を説明できるように

静的解析は、実行前のコードから問題の手掛かりを探すもの。ただし、どんな道具で何を調べたのかによって、「チェック済み」が意味する範囲は変わります。

次に「静的解析をやっています」と言うときは、ツール名だけでなく、対象とルール、指摘への対応まで説明できるようにしたいです。まずは、いつも見ている警告を一つ、理由まで読んでみる。そんなところから、わかったつもりの先へ進んでいこうと思います。

参考資料・確認日

ESLint公式「Core Concepts」、TypeScript公式「The Basics」、OWASP「Source Code Analysis Tools」を参照しました。AppliParkの記載は2026年11月5日時点の開発設定とCI記録に基づきます。作例のESLintは9.30.0で、AppliParkの依存設定とは別の検証環境です。