製品品質向上への取り組み第 2 弾：Delphi の静的コード解析 × GitHub Copilot によるコードレビュー支援

はじめに

こんにちは、システム開発部の奥野です。
前回の記事では、Delphi の静的コード解析（Pascal Analyzer）により、メモリ管理を中心とした懸念点を早期に洗い出す取り組みをご紹介しました。

tech.motex.co.jp

今回はその続編として、静的コード解析の結果を「精査すべき課題一覧」に整理し、生成 AI によるレビュー支援を組み合わせることで、レビューの効率と一貫性の向上を目指した試みをご紹介します。

はじめに
背景と課題
対策案と仮説
もう一つの課題と狙い
実践
効果や結果
おわりに

背景と課題

前回の取り組みにより、静的コード解析を使ってメモリ管理をはじめとする 懸念のある箇所 を機械的に洗い出せるようになりました。
一方で、検出された箇所が真の不具合か仕様上問題ないかを人が精査する工程は、どうしても時間を要します。
レビューアーの経験や得意分野によって、確認の速度や精度にばらつきが出る点も運用上の課題でした。

検出自体は自動化できたが、精査は人手に依存している
件数が多い場合、レビューに時間がかかる
担当者によって見落としや判断の揺れが生じ得る

対策案と仮説

この精査工程を支援するために、静的コード解析の結果を 精査すべき課題一覧 に要約・整理してチェックリスト化し、生成 AI に一次レビューを依頼する方法を検討しました。
最終判断は人が行う前提ですが、生成 AI による一次精査で 優先度の整理、判断根拠の提示、修正候補の提示 まで揃っていれば、ゼロから人が調べ始めるよりも着手が早く、品質の平準化にもつながると考えました。

具体的には次のようなアウトプットを期待しました。

修正の要否判定（❌要修正・⚠️要確認・✅修正不要）
優先度の提示（高・中・低）
根拠と該当行の明示（なぜ懸念なのか、どこを確認すべきかなど）
修正案の提示（所有権の明確化や未初期化回避などの具体的なコード）

もう一つの課題と狙い

「それなら、静的コード解析を使わず最初から生成 AI にコードレビューを依頼すればよいのでは？」という仮説も検証しました。
結果としては、前回の記事でも触れたように生成 AI はメモリ関連の懸念を指摘できる一方、一度のチェックでは見落としが出たり、追加質問をすると新しい指摘が出てきたりなど、網羅性の面で不安が残りました。
観点や深掘りを指示すれば有用な指摘が増える手応えはあるものの、「どこまで掘り下げれば十分か」を毎回判断・指示するのは運用として難しいと感じました。

この課題に対しても、静的コード解析結果から得た 精査すべき課題一覧 のチェックリストが対策になるのではないかと考えました。
あらかじめ観点と件数が明確なリストを生成 AI への入力とすることで、レビュー観点の漏れを抑えつつ、必要な深掘りを指示しやすくなります。
この組み合わせにより、網羅性の担保とレビュー効率の両立を狙います。

実践

生成 AI によるレビューは GitHub Copilot を利用しました。
今回の課題と仮説について社内の生成 AI に詳しいメンバーに相談したところ、コードの理解やレビューに優れた GitHub Copilot が適しているだろうとのアドバイスを受けたためです。

github.com

ちなみに複数の AI モデルを試し、いずれも期待した品質でレビューできました。
個人的には Claude Opus 4.5 が試行錯誤する上で使いやすい印象でした。指示のあいまいな部分や不足部分を補いながら進めている様子が見て取れたためです。
それぞれに感じた傾向は以下の通りです。

GPT-5.1-Codex-Max は指示したことに対して簡潔に素早く回答する傾向がある一方、指示していない部分については回答しない傾向があった
Claude Sonnet 4.5 や Claude Opus 4.5 は指示したこと以外にも関連しそうな情報を補足する傾向があり、レビュー観点の補完に役立つ場合があった

docs.github.com

なお、対象のソースコードが Delphi ということで、生成 AI が Delphi コードを十分に理解できるか懸念がありましたが問題ありませんでした。

具体的な内容

レビューの流れ

レビューの大まかな流れは下記の通りです。
生成 AI によるコードレビュー後には結果のまとめを出力させ、人による最終レビューを経てマージ可否を判断します。

フォルダーやファイル構成

はじめはプロンプトファイルにレビュー方法や観点などをすべて定義していました。
試行錯誤していくうちに、プロンプトの保守性が課題になったため、共通ルールや言語別ルール、静的コード解析結果の読み方などを別ファイルに切り出しました。
これにより、レビュー観点の追加や修正が容易になり、プロンプト自体はレビューの目的や対象技術に集中できるようになりました。今後 Delphi 以外の言語対応も比較的容易になると期待しています。

結果として、下記のフォルダー構成と内容になりました。

GitHub_Copilot/
└── .github/                          # Copilot 関連ファイル群
    ├── copilot-instructions.md       # Copilot 全体の動作指示書
    ├── instructions/                 # 言語別・機能別のガイドライン
    ├── prompts/                      # レビュー用プロンプト
    └── scripts/                      # 自動化スクリプト群

copilot-instructions.md
- 日本語で出力する、rm などの禁止コマンドの定義、といった全体共通のルール
instructions/*.instructions.md
- Delphi コーディング規約やベストプラクティス、静的コード解析の読み方などをそれぞれ記載
prompts/*.prompts.md
- レビュー目的、対象、観点、手順、出力フォーマットなどを定義
scripts/*.ps1
- 現在日時取得やファイル差分取得など、レビュー前処理を自動化するスクリプト

docs.github.com

レビュー出力内容

生成 AI によるレビューが完了したら下記のような結果のまとめを出力させています。
対策案で期待していたアウトプットが実現できました。

生成 AI レビュー結果のまとめ（抜粋）

# 総合的な結論

## ❌ **マージ非推奨**

**一言まとめ**: 〇〇の機能追加は正常に実装されていますが、**2件の重大なメモリリーク**が新規コードに含まれており、即座のマージは推奨できません。

## マージ可否の推奨

- **最終判定**: ❌ **マージ非推奨**（修正後に再レビュー推奨）
- **理由**:
  1. **重大なメモリリーク**: `TMyList.IsEmpty()` メソッドで2件の明確なメモリリークが検出
  2. **エラーハンドリング不足**: 新規追加の空の例外ブロック

## 条件付きマージの可能性

以下の修正が完了すれば、**✅ マージ推奨**に変更可能:

1. **必須修正 (❌ 要修正)**:
   - `MyClass.pas` (Line 2145-2195) のメモリリーク修正
   
2. **推奨修正 (⚠️ 要確認)**:
   - `MyClass.pas` (Line 1525) の空の例外ブロックへのログ記録追加

## 解析範囲

### 静的コード解析レポート

| レポート名 | 変更前の指摘数 | 変更後の指摘数 | 増減 |
|-----------|--------------|--------------|------|
| **Memory.txt** | 10件 | 13件 | **+3件** (主要警告) |
| **Strong Warnings.txt** | 0件 | 0件 | ±0件 |
| **Warnings.txt** | 55件 | 50件 | **-5件** (改善) |


以下略

苦労した点や工夫点

正直なところ、試行錯誤は継続中なのですが、特に苦労した点や工夫した点をいくつかご紹介します。

レビュー手順や出力フォーマットを詳細に指示していたつもりでしたが、確認してほしい範囲や観点を漏らすことが頻発しました。
例えば次のようなケースです。

コードや解析レポートに記載ない情報を推測や新たに作り出してレビュー完了にしてしまう
解析レポートの一部カテゴリーだけ精査して完了にしてしまう
ファイル読み込みを「先頭 2,000 行まで」などで打ち切って完了してしまう
検出課題が多いと「要確認」や「次のステップ」、「軽微な変更なため省略」として完了にしてしまう

推測で回答するケースに関しては「推測であること」を明示してもらい、レビュー完了後に「推測」の項目があれば、read_file などを用いて事実に基づいた回答をするよう指示しました。

また、レビュー対象のソースコードの場所だけでなく、プロジェクトファイルを指定することで、生成 AI がコードの依存関係やレビュー対象の全体像を把握しやすくなるようにしました。

これらの見落としや漏れを防ぐ指示とともに、レビュー完了前に自己点検するチェックリストを定義することで、品質向上を図りました。

## 品質チェック手順

### 1. 差分調査の完全性チェック

- [ ] すべての変更ファイルについて、ファイル全体の差分を確認したか？
- [ ] 「詳細未調査」「軽微な変更」等の未確認項目はないか？
- [ ] 各ファイルの変更理由、変更箇所、影響範囲が明記されているか？

### 2. チェックリストの完全性チェック

- [ ] すべての項目で修正要否（❌/⚠️/✅）が判定されているか？
- [ ] 「残課題」セクションがある場合、それらも完全に調査済みか？
- [ ] 判定理由が具体的に記載されているか？（コード引用、行番号、パターン名）

### 3. 静的コード解析レポートのカテゴリー完全性チェック

静的コード解析ツールのレポートをチェックリストに反映する場合：

- [ ] レポート内の**すべてのカテゴリー**がチェックリストに記載されているか？
- [ ] **0件のカテゴリー**も含めて記載されているか？
- [ ] レポート内カテゴリー総数 = チェックリストのカテゴリー数 であることを検証したか？