静的解析ツールの比較と選び方
静的解析ツールには、商用製品やオープンソースソフトウェア（OSS）などの選択肢があります。この記事では、ツールの比較観点と導入直後に発生する指摘への対処を解説します。あわせて、運用が定着するまでの判断ポイントも整理します。
- 静的解析ツールとは｜コードを実行せずに欠陥を検出する仕組み
- 静的解析ツールを比較する4つの観点
- 組み込み開発で使われる主な静的解析ツール
- 導入直後の大量の指摘は絞り込みで対処する
- 静的解析を形骸化させない運用の判断ポイント
静的解析ツールとは｜コードを実行せずに欠陥を検出する仕組み
静的解析ツールは、ソースコードを実行しないで、コーディング規約違反や不具合の疑いがある箇所を検出します。プログラムを動かして挙動を確かめる動的テストとは異なり、テストケースを用意しなくても解析対象のコードを広く検査できます。
コンパイラ警告も広い意味では静的解析の一種です。ただし、主目的は翻訳であるため、警告の範囲や深さには限りがあります。専用ツールでは「未初期化変数の参照」、「配列の範囲外アクセス」、「到達しないコード」などを検出します。コンパイラの警告だけでは拾いきれない欠陥まで、検査できる点が強みです。
組み込み開発では、「MISRA C」や「CERT C」といったコーディング規約への準拠確認にも静的解析ツールが活用されています。規約違反を人手のレビューだけで漏れなく検出するには、多くの工数がかかります。そのため、規約違反の確認は静的解析ツールによる自動化に適した作業です。
静的解析ツールを比較する4つの観点
ツールを比較する際に意識しておきたい観点は、次の4つです。
- 開発環境への対応
- 規約対応と解析の深さ
- 解析結果の管理
- 運用コスト
まず、候補を絞り込む前に確かめたいのは、自社の開発環境をそのまま解析できるかどうかです。C/C++の規格バージョンやコンパイラ独自の拡張に対応しているかに加え、実際のビルド環境を再現して解析できるかどうかも、あらかじめ確認しておく必要があります。クロス開発の場合、ターゲット固有のヘッダや拡張構文を解析器が解釈できるかどうかも重要です。
開発環境への対応状況を確認した後は、規約対応の範囲と解析の深さを比較します。確認したいのは、「MISRA C」と「CERT C」のそれぞれに対応しているか、どの版まで追従しているかです。データの流れを追った欠陥検出に加え、抽象解釈（abstract interpretation）などにより、一定の前提条件の下で実行時エラーが発生しないことを検証できるかどうかも、ツールによって異なります。
加えて、継続的インテグレーション（CI）や統合開発環境（IDE）との連携機能、および解析結果の管理機能は、導入後の定着を左右する要素です。ビルドのたびに静的解析ツールを自動で実行し、結果の推移を管理できるかどうかも確認する必要があります。
ライセンスを含む運用コストの見積もりも、欠かせない観点です。機能安全規格が関わる開発では、「ツール適格性確認（tool qualification）」、「適格性確認の支援範囲」、「適格性確認キット（qualification kit）の提供内容」なども確認項目になります。
ただし、ツールが適格性確認を受けていても、開発した製品の規格適合を示したことにはなりません。ツール適格性確認は、ツールの意図した使用条件に対する信頼性確保の枠組みであり、適用範囲や使い方はプロジェクトごとに確認が必要です。
組み込み開発で使われる主な静的解析ツール
組み込み開発では、商用製品とOSSが主な候補です。商用製品の中には、規約チェックと欠陥検出の両方に対応するものがあります。
商用製品では、「MISRA Cへの対応範囲や解析の深さ」、「機能安全向けの適格性確認の支援」、「ベンダーサポート」が主な比較項目です。一方、OSSには無償で導入できるツールもあります。ただし、規約の対応範囲や結果管理の機能は、ツールごとに異なります。
自社の開発規模と求める保証水準を整理し、候補ツールで実際のコードを解析した上で選定する方法が現実的です。
導入直後の大量の指摘は絞り込みで対処する
稼働中の既存コードに静的解析ツールを導入すると、直後に大量の指摘が発生するケースも珍しくありません。指摘の中には、実際には問題のない誤検知（false positive）が含まれることもあります。
誤検知かどうかの精査には工数がかかり、この負担が運用定着を妨げる主要な要因の1つです。導入時には、指摘をどう絞り込むかという運用計画をあわせて立てておくことが重要です。
適用ルールは絞って始め、例外の扱いを決めて広げる
適用するルールは最初からすべて有効にしないで、影響の大きい項目に絞って始めます。運用が軌道に乗った後、対象を段階的に広げます。指摘の件数が、内容を精査できる範囲に収まっていれば、1件ずつ確認する運用を継続しやすいでしょう。
絞り込みの基準には、規約の区分だけでなく「信頼性」、「保守性」、「移植性」、「効率性」といったソフトウェアの品質特性も活用できます。品質特性ごとにルールを分類すると、優先すべき項目を整理しやすくなります。製品で重視する特性を決めておけば、ルールの取捨選択にも迷いにくくなるはずです。
MISRA C:2012では、各ルールを公式に「ガイドライン」と呼びます。この記事もこの呼称に従います。MISRA Cの各ガイドラインには「Mandatory（必須）」、「Required（必要）」、「Advisory（推奨）」の区分があります。この区分は導入の優先順位ではなく、違反や逸脱の扱いを示す分類です。
Mandatoryは逸脱（deviation）が認められません。Requiredは、違反する場合に正式な逸脱手続き（根拠の記録や承認など）が必要です。Advisoryはプロジェクト方針として適用除外（disapply）とする判断もできますが、その判断は文書化し、違反は識別してレビュー対象とします。規約適合を主張する場合に必要なのは、全ガイドラインの扱いを明確にすることです。
既存コードの指摘はベースライン化し、新規の指摘を増やさない
既存コードへの指摘は、ベースライン（導入時点の指摘を「既知」として固定した基準）として扱います。その上で、新規コードや変更箇所で新しい指摘を増やさない運用から始めるのが無難でしょう。
既存コードを一度に修正するより、新規・変更コードの品質を守るほうが、少ない工数で効果を得やすくなります。一部のツールには、以前の解析結果と比較して新規の指摘だけを表示する機能もあります。結果を影響度や対応状況で絞り込めるかどうかも、レビュー工数を見積もる上で重要です。
ただし、メモリ破壊につながる重大な欠陥や脆弱性は、ベースラインの対象からはずし、優先して修正します。対応を保留するのは、リスクを評価した上で許容できると判断した指摘に限ります。
静的解析を形骸化させない運用の判断ポイント
形骸化する要因の1つは、解析を担当者個人に任せる運用です。静的解析ツールをCIへ組み込み、コードのコミットやプルリクエスト（マージリクエスト）、ビルドを契機に自動実行します。担当者の意識に頼らずに済み、新しい指摘の見落としも防止できます。
加えて重要なのは、例外管理です。例外の対象や理由、承認日、見直し時期を記録しておかないと、担当者の交代後に判断の経緯を追跡できなくなるおそれがあります。記録のない例外が増えると、規約の形骸化につながります。
ツールを導入しても、人のレビューが不要になるわけではありません。検出可能な規約違反や既知の欠陥パターンはツールに任せ、レビューでは設計の妥当性など、ツールで確認しきれない項目を見ます。役割を分けることで、解析とレビューの効果を高められます。
