🚀 TL;DR
- AI（LLM）に生のソースコードを読ませるのは、実は効率の悪い「情報の暴力」である。
- AST（抽象構文木）から「構造」だけを抽出したマップこそが、AIのIQを極限まで引き出す。
- データの流入から破綻までをグラフ理論で定義すれば、理論上、脆弱性は100%特定可能となる。
1. はじめに：AIレビューの「限界」と「嘘」
最近、GitHub CopilotやChatGPTにコードを貼り付けて「脆弱性ある？」と聞く手法が定着しました。しかし、大規模なプロジェクトになればなるほど、AIは以下のような致命的な欠陥を露呈します。
- コンテキストの霧：数千行のコードを前に、AIは「どの変数がどこから来たか」を見失い、平気でハルシネーション（嘘）をつく。
-
トークンの浪費：コードの「書き方」というノイズに注目してしまい、肝心の「ロジックの破綻」に辿り着く前にリソースを使い果たす。
そこで私は、AIにコードを1行も読ませるのをやめました。代わりに渡したのは、自作の解析コードが抽出した「コードの設計図（Deep Structure Map）」です。
2. Deep Structure Map：AIに「骨格」を授ける
ソースコードは人間が読むための「肉体」ですが、AIが論理推論を行うために必要なのは、純粋な「神経系（ロジック）」です。Pythonの ast モジュールを使用し、コードを以下のような構造データへ変換します。
クラス・関数の依存関係（Mermaid形式）
AIには、生のコードではなく、この「関係性の結晶」をインプットします。
このように、コードを抽象化して「何がどこに繋がっているか」を事前に定義することで、AIは「3つ前のファイルで定義されたクラスのプロパティ」といった遠くの文脈を一瞬で、かつ正確に把握できるようになります。
3. 理論編：なぜ「100%」特定できるのか
「100%」という数字は、単なる誇張ではありません。グラフ理論における「データフロー解析（Taint Analysis）」をAIに実行させることで、論理的な見落としを物理的に排除します。
脆弱性特定の方程式
脆弱性とは、以下の条件が揃った時に数学的に成立します。
- Source（汚染源）：外部からの入力（API引数など）が変数に入る。
- Propagator（伝播ルート）：その変数が、適切な処理（サニタイズ）なしに関数間を移動する。
-
Sink（危険地帯）：最終的に eval() や execute() などの致命的な関数に到達する。
この手法では、AIにコードの「文章」を読ませるのではなく、この「SourceからSinkへの導通ルート」に欠陥がないかを確認させます。AIは「読書」から解放され、「グラフの矛盾探し」という得意分野に専念できるため、精度が飛躍的に向上します。
4. 実際の解析フロー：AIを「名医」に変える
具体的な手順は以下の通りです。
- 静的抽出：ast.NodeVisitor が全ファイルをスキャンし、変数スコープと関数呼び出しをリスト化。
- マップ変換：解析結果をMermaid形式や構造化されたJSONに圧縮。
- AIプロンプト注入：AIに対し「以下の構造マップに基づき、データ汚染ルートを論理的に抽出せよ」と指示。
- 精密スキャン：AIが「怪しい」と断定した特定の数行だけを、最後にチェック。
変数スコープの把握（例）
AIはこの表を見るだけで、変数の「生存範囲」を完璧に理解します。
| Scope Context | Instance Variables (self.*) | Local / Temp Variables |
|---|---|---|
| Class:SecurityScanner | found_risks | DANGER_FUNCS |
5. まとめ：AIに必要なのは「肉体」ではなく「地図」である
ソースコードをそのまま渡すのは、辞書を丸ごと渡して「間違いを探して」と言うようなものです。一方、構造マップを渡すのは、「犯行現場の地図」と「監視カメラの記録」を同時に渡すことに等しい。
「コードを1行も読ませない」というのは、AIを「文法の解釈」という低次元なタスクから解放し、「論理の検閲」という高次元な役割にシフトさせるための究極の効率化です。
俺が書いたコード（実装）はいつか古くなりますが、俺が書いた解析コード（構造抽出）は、AIを永遠に賢くし続けます。
次は、あなたのプロジェクトの「地図」を、AIに渡してみませんか？