NilAwayはGoのnilパニック候補をデータフローから探す
Go コード内の潜在的な nil パニックを検出する静的分析ツール。 NilAway [![GoDoc][doc-img]][doc] [![Build Status][ci-img]][ci] [![Coverage Status][cov-img]][cov] [!WARNING] NilAway は現在鋭意開発中です。誤検知や重大な変更が発生する可能性があります。
ひと目でわかる
- これは何？
- go/analysisの事実情報を利用し、依存関係も含めたnilness解析を行う静的解析ツール。golangci-lintやnogoへの統合も可能。
- 誰に向いている？
- Goサービスでnil由来の実行時障害を早期に見つけたいチーム向けです。解析結果を無検証でエラー扱いしたり、大規模依存関係まで初回から解析したりする運用には注意が必要です。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 7 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
nilnessを静的に追うアナライザー
NilAwayはGoコードの潜在的なnilパニックを検出する静的解析ツールです。READMEはgo/analysisのフレームワークに基づき、値がnilになり得る経路を解析して警告を出す仕組みを説明しています。実行時テストで通らなかった分岐を発見する道具ではなく、コードの型、制御フロー、注釈などから可能性を推定します。
nilの扱いはAPI境界やエラー処理に集中しやすいため、導入時は検出箇所を単なる件数で評価しません。なぜnilが許されるか、呼び出し側で保証されるか、実際にpanicへ到達するかをコードレビューで分類します。
依存関係解析のコスト
既定では標準ライブラリと依存関係を含むすべてのGoコードを解析します。これにより依存コードの形を理解し、見逃しを減らせる一方、初回の解析コストと依存側の対応不要なエラーが増えます。READMEはinclude-pkgsで自分のプロジェクトだけに絞ることを強く推奨しています。
最初は自社パッケージの接頭辞を指定して結果を読み、解析時間、報告件数、CIの資源使用量を測ります。範囲を広げる場合は、依存側の検出を修正対象へ混ぜない仕組みを用意し、設定変更の影響を比較できるようにします。
単体チェッカーの位置づけ
go install go.uber.org/nilaway/cmd/nilaway@latestでバイナリを導入し、nilaway -include-pkgs="<YOUR_PKG_PREFIX>" ./...の形で実行できます。JSON出力時は-json -pretty-print=falseを使う例があります。単体チェッカーは評価を始めやすい反面、解析事実をメモリに保持するため、大規模プロジェクトの効率には制約があります。
READMEはモジュール解析を支えるドライバーとしてBazel/nogoやgolangci-lintを推奨しています。単体実行で得た結果をそのまま本番CIの基準にせず、解析対象、キャッシュ、失敗時の扱いを統合先で確認します。
golangci-lintへの組み込み
golangci-lint v1.57.0以降ではモジュールプラグインシステムを使い、.custom-gcl.ymlにgo.uber.org/nilawayとgclpluginを登録します。.golangci.yaml側ではnilawayを有効化し、include-pkgsをmap形式の設定として渡します。その後golangci-lint customで専用バイナリをビルドします。
設定はバージョン1と2で記法が異なるため、利用中の版を先に固定します。latestを使う場合の再現性にも注意し、CIでは生成したカスタムバイナリと設定を保存します。既存のError Proneなど別の解析とは異なるGoの失敗基準として、段階的に警告から導入する判断も必要です。
false positiveを運用へ戻す
READMEはNilAwayがfalse positiveを報告し得ると認めています。検出されたnilフローの例を読み、初期化順序、インターフェース、エラー返却、依存パッケージの境界で誤判定が増えていないか確認します。修正、抑制、コードの契約明示を使い分け、解析を無効化して件数だけ減らす運用は避けます。
導入前には代表サービスで既知のnilテストを用意し、検出結果を固定します。Goのバージョン、NilAwayの版、golangci-lintの版を更新したときは、検出件数の増減を差分としてレビューします。ライセンスとサポート範囲はリポジトリの記載を確認し、解析結果を安全性保証と表現しません。
試験対象には、明示的なnilチェック、エラーを無視する呼び出し、インターフェースへnilポインタを入れる処理、初期化関数の順序に依存する処理を含めます。NilAwayが出した位置と実行時に到達する経路を照合し、修正後に別の警告が増えないかを確認します。include-pkgsの接頭辞を誤ると自社コードを解析対象から外すため、解析ログと対象パッケージ一覧を保存します。CIではGo、NilAway、golangci-lintの版を固定し、警告を段階的にエラーへ昇格します。解析結果を安全性の証明ではなく、コードレビューへ渡す追加の信号として扱います。
NilAwayのCI導入記録には対象パッケージ、解析時間、警告数、修正済み件数を保存します。設定やGo版を更新したとき、誤検出の増加を開発者へ説明できるようにします。
NilAwayの警告は修正、契約の明示、抑制に分類します。既知のpanicケースをテストへ残し、解析が警告を消したこととバグが消えたことを別々に確認します。
NilAwayはGoのnilパニック候補をデータフローから探すを受け入れる前に、README記載の入力、実行、出力を一つの記録へまとめます。成功した操作だけでなく、失敗した操作、未確認の機能、利用した版、設定値、保存したログの場所も残します。担当者が同じ環境を作り直し、同じ確認結果を再現できることを条件にします。性能や互換性について数値を扱う場合は、データ量、実行時間、エラー数、資源使用量を測定条件とともに記録します。READMEにない保証は採用理由へ加えず、未確認事項として次の検証に回します。
編集部の結論
Goサービスでnil由来の実行時障害を早期に見つけたいチーム向けです。解析結果を無検証でエラー扱いしたり、大規模依存関係まで初回から解析したりする運用には注意が必要です。go installで単体実行を試した後、include-pkgsで自社パッケージへ範囲を絞り、既知のコードでfalse positiveと見逃しを分類してからCIへ組み込んでください。
コミュニティノート