この記事の要点
AIソースコード解析とは、静的解析と生成AIを組み合わせてソースコードの意味まで読み解き、マイグレーション時に問題となる箇所を洗い出す手法です。ルールベースの静的解析では見つけにくい「暗黙の仕様」や「隠れた依存」の発見に強みがあります。本記事では、検出できる8つの移行リスク、5ステップの進め方、限界と注意点、ツール選びのポイントを解説します。
AIソースコード解析とは、静的解析ツールで抽出した事実と、生成AIによるコードの意味理解を組み合わせ、マイグレーションの障害となる箇所を洗い出して優先順位をつける手法です。
移行プロジェクトで本当に怖いのは、行数の多さではありません。端数処理の書き方、動的に組み立てられるSQL、コードに埋め込まれた業務ルールなど、変換後に「動くけれど結果が違う」原因になる箇所です。AIソースコード解析は、こうした移行リスクを早い段階で見つけ、設計とテストに反映するための手段です。
本記事は、マイグレーションのAI活用を解説した記事のクラスター記事です。ソースコード解析で評価すべき項目全体については、マイグレーション前のソースコード解析をご覧ください。
1. AIソースコード解析とは？
まずは、従来の静的解析との違いと、AIソースコード解析が移行リスクの発見に向いている理由を整理しましょう。
1-1. 従来の静的解析との違い
従来の静的解析は、あらかじめ決めたルール（構文パターンやメトリクス）にもとづいてコードを機械的に調べます。正確で再現性が高い一方、ルールに書かれていない問題は見つけられません。
AIソースコード解析は、生成AIがコードの文脈を読み取り、「この処理は何をしているか」「移行先で同じ結果になるか」を説明します。静的解析が「事実」を、AIが「意味」を担う関係です。
| 観点 | 従来の静的解析 | AIソースコード解析 |
|---|---|---|
| 仕組み | ルール・パターンにもとづく検出 | 静的解析の事実＋生成AIによる意味理解 |
| 得意なこと | 構文・メトリクス・呼び出し関係の正確な抽出 | 暗黙の仕様、業務ルール、リスクの説明 |
| 苦手なこと | ルール外の問題、意味の解釈 | 事実の正確性（単独では誤りが混ざる） |
| 出力 | 一覧・数値 | 説明文・リスク候補・改善案 |
1-2. AIソースコード解析が移行リスクの発見に向いている理由
移行リスクの多くは、「構文として正しいが、移行先では意味が変わる」箇所に潜んでいます。たとえば、数値の丸め方や文字列比較の仕様は、言語やライブラリによって微妙に異なります。
AIは、こうした箇所を「なぜ危ないのか」という説明つきで指摘できます。エンジニアだけでなく、業務担当者やプロジェクトマネージャーにもリスクを共有しやすくなる点も、大きな利点です。
2. AIソースコード解析で検出できる8つの移行リスク
HBLABでは、AIソースコード解析で重点的に検出する移行リスクを、次の8つに整理しています。
① 非互換構文・サポート終了（EOL）部品への依存
移行先の言語・フレームワークで使えない構文、ベンダー固有の拡張、サポートが終了したライブラリを検出します。数が多い場合は、移行方式そのものの見直しが必要になることもあります。
② 暗黙の仕様：型変換・端数処理・文字コード
暗黙の型変換、四捨五入や切り捨ての方法、桁あふれ時の動き、文字コードに依存した並び順などです。変換後もエラーにならず、結果だけがずれるため、最も見落とされやすいリスクです。
③ コードに埋め込まれた業務ルール
税率、締め日、顧客区分ごとの例外処理など、ハードコードされた業務ルールを抽出します。移行時に「残す・変える・捨てる」を判断する対象になります。
④ 隠れた外部依存：動的SQL・ファイル名の組み立て・環境変数
文字列を連結して組み立てるSQLや、実行時に決まるファイル名・接続先は、静的解析だけでは追いきれません。AIは、変数の組み立て方から実際にアクセスしうるテーブルやファイルを推定する手がかりを示します。コードの外にある依存は、現行システムの依存関係調査と合わせて確認します。
⑤ 影響範囲の広い共通部品
多くのプログラムから呼び出される共通部品は、1か所の変換ミスが広範囲の障害につながります。呼び出し数とあわせて、処理内容の重要度をAIに説明させると、優先度を判断しやすくなります。
⑥ デッドコード・重複コード
使われていないコードや、ほぼ同じ処理の重複を検出します。移行対象から外す・共通化することで、移行とテストの工数を減らせます。
⑦ 例外処理・エラー処理の不備
エラーを握りつぶしている処理、異常時に途中までデータを書き込んでしまう処理などです。移行先でエラー処理の仕組みが変わると、これまで表面化しなかった不具合が顕在化することがあります。
⑧ セキュリティ上の問題：ハードコードされた認証情報など
ソースに直接書かれたパスワードや接続情報、入力値の検証不足などを検出します。ハードコードされた認証情報は、MITRE「CWE-798」でも代表的な脆弱性として定義されています。
| 移行リスク | 典型例 | 放置した場合の影響 |
|---|---|---|
| ① 非互換構文・EOL | ベンダー固有構文、古いライブラリ | 変換不能、移行方式の見直し |
| ② 暗黙の仕様 | 端数処理、型変換、文字コード | 本番で計算結果がずれる |
| ③ 業務ルール | ハードコードされた税率・締め日 | 仕様の取りこぼし |
| ④ 隠れた外部依存 | 動的SQL、実行時のファイル名 | 結合テストで障害多発 |
| ⑤ 共通部品 | 多数から呼ばれるサブルーチン | 障害の影響が広範囲に |
| ⑥ デッドコード・重複 | 未使用プログラム、コピー処理 | 不要な工数・費用 |
| ⑦ 例外処理の不備 | エラーの握りつぶし | 移行後に不具合が顕在化 |
| ⑧ セキュリティ | 認証情報の直書き | 情報漏えいのリスク |
3. AIソースコード解析によるリスク検出の進め方：5ステップ
AIソースコード解析の効果を最大化するには、「AIに丸投げしない」進め方が重要です。HBLABが実案件で用いている5ステップを紹介します。
Step1. 対象範囲と移行先を定義する
何が「リスク」になるかは、移行先によって変わります。COBOLからJavaへ移すのか、VB6からC#へ移すのかで、注意すべき非互換要素はまったく異なります。最初に移行先の言語・フレームワーク・方式を決めてから解析を始めます。
Step2. 静的解析で事実を抽出する
行数、呼び出し関係、テーブルアクセス、共通部品の利用状況などを静的解析で抽出します。これがAIに渡す「事実」になり、AIの出力を検証する基準にもなります。
Step3. AIでリスク候補を検出し、根拠とともに説明させる
事実とコードをAIに渡し、8つのリスク観点で問題になりうる箇所を洗い出します。このとき、どのファイルの何行目が根拠かを必ず出力させることで、後のレビューが速くなります。
Step4. リスクをスコアリングして優先順位をつける
検出したリスクを、影響度・発生可能性・修正コストの3軸で評価し、対応の優先順位を決めます。
| 優先度 | 条件の例 | 対応 |
|---|---|---|
| 高 | 影響度が大きく、発生可能性も高い（例：金額計算の端数処理） | 移行設計で個別対応し、現新比較テストで重点検証 |
| 中 | 影響度は大きいが、発生条件が限られる（例：月末のみ動く例外処理） | テストケースに明示的に追加 |
| 低 | 影響度が小さい（例：未使用の画面項目） | 通常の移行・テストで対応、または対象外にする |
Step5. 人がレビューし、移行計画とテスト計画に反映する
最後に、エンジニアと業務担当者がリスク一覧をレビューし、誤検出を除外します。確定したリスクは、移行設計の個別対応項目と、テスト計画の重点項目にそのまま反映します。テストへのつなげ方は、移行のリグレッションテストが参考になります。
自社のコードに潜む移行リスク、AIで洗い出してみませんか？
HBLABの無償AI診断では、AIソースコード解析により、非互換要素や暗黙の仕様、影響範囲の広い箇所を可視化します。移行方式や見積もりを決める前の判断材料としてご活用ください。
4. AIソースコード解析の限界と注意点
AIソースコード解析は強力ですが、万能ではありません。導入前に、次の3つの限界を理解しておきましょう。
4-1. 誤検出と見逃し（ハルシネーション）
生成AIは、存在しないリスクを指摘したり、重要なリスクを見逃したりすることがあります。静的解析の事実との照合と、人のレビューを必ず工程に入れることが前提です。AI特有の誤りへの対策は、生成AIマイグレーションのハルシネーション対策で詳しく解説しています。
4-2. コードの外にあるリスクは見えない
ジョブの実行順序、DBのトリガー、運用担当者の手作業など、ソースコードに書かれていないリスクは、AIによるコード解析だけでは検出できません。現行システム全体の評価は、レガシーシステムアセスメントとして行う必要があります。
4-3. ソースコードという機密情報の扱い
ソースコードは企業の重要な資産です。利用するAIサービスが、入力データを学習に使わないか、どこに保存されるかを確認し、必要に応じて閉域環境で解析します。AIのリスク管理の考え方は、NIST「AI Risk Management Framework」も参考になります。
5. AIソースコード解析ツール・サービスを選ぶ5つのポイント
AIによる解析を外部のツールやサービスで行う場合は、次の5つのポイントで比較しましょう。
| ポイント | 確認すべきこと |
|---|---|
| 対応言語 | COBOL・RPG・VB6などのレガシー言語や、方言・ベンダー固有構文に対応しているか |
| 根拠の提示 | 指摘ごとに、根拠となるファイル・行番号を示せるか |
| 静的解析との連携 | AIの出力を、静的解析の事実で検証できる仕組みがあるか |
| セキュリティ | 入力データを学習に使わないか、閉域環境で利用できるか |
| 出力の再利用性 | リスク一覧・設計書・テストケースとして、後工程で再利用できるか |
特に「根拠の提示」と「静的解析との連携」は、AIの出力を信頼できるかどうかを左右する重要な条件です。
6. HBLABのAIソースコード解析・移行支援
HBLABは、AIソースコード解析を起点に、マイグレーションをアセスメントから移行・テストまで一貫して支援しています。
HBLABのAI Assessment Toolは、技術調査、評価、移行戦略、業務仕様の整理、コード変換、単体テスト、結合テストの7工程を支援します。静的解析で事実を固め、AIでリスクの検出と説明を高速化し、SA・BAの専門家がレビューして判断する体制です。仕様の復元については、AIリバースエンジニアリングとレガシー設計書の復元手順もあわせてご覧ください。
サービスの全体像は、HBLABのモダナイゼーションサービスをご覧ください。
AIソースコード解析から移行計画まで、HBLABにご相談ください
「移行のどこにリスクがあるか分からない」「見積もりの根拠を示したい」といったお悩みに、AIと専門家の組み合わせでお応えします。
7. AIソースコード解析に関するよくある質問
AIソースコード解析だけで移行リスクをすべて洗い出せますか？
いいえ。AIによる解析は、コードの中にあるリスクの発見に強みがありますが、コードの外にある依存や運用上のリスクは対象外です。現行システムの依存関係調査や、業務担当者へのヒアリングと組み合わせることが必要です。
解析にはどのくらいの期間がかかりますか？
資産の規模や言語によって異なります。まずは重要な業務領域に絞って試行し、検出精度とレビュー工数を確認したうえで範囲を広げるのがおすすめです。
汎用のチャットAIにコードを貼り付けるのと何が違いますか？
汎用のチャットAIでも個別のコードの説明は可能です。しかし、数千本規模の資産を網羅的に解析し、静的解析の事実と照合して、根拠つきのリスク一覧にまとめるには、専用の仕組みと手順が必要です。機密情報の扱いの面でも、利用環境の確認が欠かせません。
まとめ
AIソースコード解析は、非互換構文、暗黙の仕様、業務ルール、隠れた外部依存、共通部品、デッドコード、例外処理、セキュリティの8つの移行リスクを、根拠とともに洗い出す手法です。静的解析で事実を固め、AIで発見を速め、人が判断する体制で進めましょう。HBLABは、移行を成功に導くAIソースコード解析を支援します。
