AIでコーディングを始めると、レビューが地獄になる話とその解決策
こんにちは。
ゲームソリューション部/業務効率化ソリューション部の西川です。
AIコーディングツールを開発に導入してしばらく経ちます。
コードは驚くほど速く書けるようになった一方で、その分レビューが回らなくなってきたように感じます。
同じ悩みを抱えている方、けっこう多いのではないでしょうか。
AI駆動開発が当たり前になって、1人あたりのアウトプットは体感で2〜3倍になりました。ところがレビューする側の人数も時間も、当然ながら増えていません。
特にセキュリティの観点でコードをちゃんと見る、という作業がどんどん後回しになっていく。
この記事では、なぜレビューが「地獄」になるのかという構造的な問題を整理したうえで、Snykを使った解決策をハンズオン形式で紹介します。
レビューが地獄になる3つの理由
1. AIはセキュアなコードを保証してくれない
まず大前提として、AIは「動くコード」は書いてくれますが「安全なコード」を書いてくれるとは限りません。
LLMは世の中の膨大なコードを学習していますが、その中には脆弱なコードパターンも当然含まれています。
つまり、学習元に危ういコードがあれば、それを自然に再現してしまうわけです。
たとえばAIにサッと「ユーザー名で検索するAPIを書いて」と頼むと、（流石にこのレベルのものはないと思いますが）こういうコードが返ってくることがあります。
import sqlite3
from flask import Flask, request
app = Flask(__name__)
@app.route("/user")
def get_user():
username = request.args.get("username")
conn = sqlite3.connect("app.db")
cursor = conn.cursor()
# ユーザー入力を直接クエリに埋め込んでいる
query = "SELECT * FROM users WHERE username = '" + username + "'"
cursor.execute(query)
return cursor.fetchall()
こちら動きはして、ローカルで試せば期待どおりの結果が返ってきます。
しかし、典型的なSQLインジェクション脆弱性を抱えています。
「動くコードを生成する」ことと「セキュアなコードを生成する」ことは、AIにとってまったく別の要求なんですよね。ここを混同すると痛い目を見ます。
2. 人間のレビュー速度には物理的な上限がある
次に、単純な物量の問題です。1人のレビュアーが1日に集中してきちんとレビューできるPRは、経験上せいぜい5〜10件くらいだと感じています。それ以上になると、どうしても目が滑る。
AIコーディングを導入すると、現場によってはPR数が体感で2〜3倍に膨らみます。こうなると、もう構造的に追いつきません。
結果として何が起きるかというと、「ざっと見てLGTM」の常態化です。これはレビュアーが怠けているわけではなくて、処理能力を超えた量を人力で捌こうとしているシステム設計側の問題だと私は思っています。
3. 「レビューした事実」と「セキュアである確信」は別物
そして一番怖いのが、この3つ目です。
PRに承認スタンプが付いていても、それは「誰かが見た」という事実を示すだけで、「安全である」ことの証明にはなりません。
厄介なのは、このギャップが可視化されないことです。LGTMが並んだきれいなPR履歴を見ていると、なんとなく品質が担保されている気になってしまう。
でも実際には、さっきのSQLインジェクションのようなコードがそのままマージされているかもしれない。そしてそれは、セキュリティインシデントが実際に起きて、初めて発覚するのです。
こんなニーズありませんか？
ここまで読んで、こう思った方もいるかと思います。
「レビューで人間がセキュリティを手動チェックする努力をせずに、AIで爆速開発しながらセキュリティ品質も保ちたい」
わがままなニーズだと思いますか？
むしろこれからのAI駆動開発では、これを当たり前にしないといけないと考えています。
[解決策] Snykを開発フローに組み込む
そこで登場するのがSnykです。
「またSASTツールか」と思われるかもしれませんが、Snykは従来のSASTとは立ち位置が違います。
従来のSASTツールは、CI/CDパイプラインの後段で「事後的に」脆弱性を検知するものが主流でした。
コードを書いてコミットして、パイプラインを回して、しばらくしてからレポートが上がってくる。
問題を見つけてくれるのはありがたいのですが、開発者からすると「もう書き終わったのに今さら」というタイミングなんですよね。
Snykはこの発想が根本的に違います。
コードを生成しているまさにその瞬間に、リアルタイムで検知して自動修正まで提案してくれる。
従来のSASTツールとの違いを整理すると、こうなります。
| 比較軸 | 従来のSASTツール | Snyk |
|---|---|---|
| 動くタイミング | CI/CDの後段（事後検知） | コード生成と同時（リアルタイム） |
| 運用の主体 | セキュリティ担当が手動で運用 | 開発フローに組み込まれ自律的に動く |
| AIコードへの対応 | 後付けで対応が進む段階 | 早くからAI生成コードを前提に設計 |
Snyk自身も、この方向性を「AI Trust Platform」として打ち出しています。
人間が旗を振ってツールを回すのではなく、AIと連動して書いた端から守ってくれるような状態です。
実際にやってみた：AIコーディングツール × Snykハンズオン
では、さきほどのSQLインジェクションを含むコードを題材に、実際に手を動かしてみます。今回は Python + Flask の小さなAPIを snyk-demo というディレクトリに置いて試しました。
Step 1：脆弱性を「見る」
まずは脆弱性を検知するところから。Snyk CLI をインストールして認証を済ませたら、対象ディレクトリで snyk code test を実行します。
$ snyk code test
すると、こんな出力が返ってきました。
Testing .../snyk-demo ...
Open Issues
✗ [MEDIUM] Cross-site Scripting (XSS)
Path: app.py, line 16
Info: Unsanitized input from a database flows into the return value of get_user, where it is used to render an HTML page returned to the user. This may result in a Cross-Site Scripting attack (XSS).
✗ [HIGH] SQL Injection
Path: app.py, line 15
Info: Unsanitized input from an HTTP parameter flows into execute, where it is used in an SQL query. This may result in an SQL Injection vulnerability.
╭─────────────────────────────────────────────────────────────────────────────────╮
│ Test Summary │
│ │
│ Organization: test-nishikawa │
│ Test type: Static code analysis │
│ Project path: .../snyk-demo │
│ │
│ Total issues: 2 │
│ Ignored issues: 0 [ 0 HIGH 0 MEDIUM 0 LOW ] │
│ Open issues: 2 [ 1 HIGH 1 MEDIUM 0 LOW ] │
╰─────────────────────────────────────────────────────────────────────────────────╯
狙いどおり、15行目の SQL Injection を「HIGH」として検知してくれました。
HTTPパラメータ由来の username が、そのまま execute に流れ込む経路をきちんと追ってくれています。しかもおまけで、16行目に潜んでいた Cross-site Scripting（XSS）まで「MEDIUM」で拾ってくれました。
自分では SQLインジェクションしか意識していなかったので、これは素直にありがたい。どのファイルの何行目が、なぜ危ないのかまで教えてくれるのがいいところです。
Step 2：脆弱性を「直す」
検知できたら、次は修正です。ここで活躍するのが「Snyk Agent Fix」です。
VS Code の Snyk 拡張を入れておくと、検知した脆弱性に対して AI が修正案を生成し、その場で適用できます。
VS Code のSnykパネルからSQL Injectionの項目をクリックすると、右側に issue の詳細ビューが開きます。
CWE-89（SQL Injection）であることや優先度スコア、汚染された入力の流れ（Data Flow）を確認でき、その下に「Snyk Agent Fix」で修正を生成するボタンが用意されています。
「Generate AI fix」を押すと、SQLインジェクションにはパラメータ化クエリへの修正案が生成されました。AIによる説明つきで、内容を確認してから「Apply fix」で適用できます。
同じ要領で XSS のほうも修正させると、html.escape で出力をエスケープする案が出てきました。
両方を適用すると、コードはこう書き換わりました。修正前後を並べるとこうなります。
+import html
import sqlite3
from flask import Flask, request
app = Flask(__name__)
@app.route("/user")
def get_user():
username = request.args.get("username")
conn = sqlite3.connect("app.db")
cursor = conn.cursor()
- query = "SELECT * FROM users WHERE username = '" + username + "'"
- cursor.execute(query)
- return cursor.fetchall()
+ query = "SELECT * FROM users WHERE username = ?"
+ cursor.execute(query, (username,))
+ safe_results = html.escape(str(cursor.fetchall()))
+ return safe_results
SQLインジェクション側は、ユーザー入力を文字列連結でクエリに埋め込むのをやめて、プレースホルダ（?）とパラメータ渡しに変えています。
これでユーザー入力がSQL文として解釈されることはなくなります。
XSS側は、DBから取り出した値をそのまま返すのではなく html.escape を通してから返すようになりました。
修正を適用したら、もう一度スキャンして確認します。Snykパネルの表示はこうなりました。
Snyk found these issues: 0 total 0 new
✋ 0 issues found in your code.
⚡ 0 issues are fixable with Snyk Agent Fix.
Code Security
✅ Congrats! No open issues found!
検知から修正、再確認までが数分で終わりました。
書いているそばから警告が出る
CLIも便利ですが、個人的に一番効いたのはこのIDE拡張です。
VS CodeにSnykの拡張機能を入れておくと、コードを書いているそばから、危ういコードに波線が引かれてインラインで警告が出ます。
その場で気づけるので、そもそも脆弱なコードをコミットまで持っていかなくて済みます。
AIが生成したコードを受け取った直後に赤信号が見える、この体験はレビュー負荷の軽減にダイレクトに効くところかと思います。
まず無料プランで試す
いきなり全社導入を考える必要はありません。
Snykには無料プランがあるので、まずは小さく試すのがおすすめです。導入はこの流れで完結します。
順番としては、まず自分の個人リポジトリで感触を掴んでから、チームのリポジトリへ展開していくのがスムーズです。
いきなりチーム全体のCIに組み込むと調整コストがかかりますが、個人で試すぶんには誰にも迷惑をかけません。
効果を体感してから広げれば、チームへの説明もしやすくなります。
さいごに
今回の話を整理すると、こんなところです。
- AIは動くコードは書くが、セキュアなコードを保証はしてくれない
- PR数が増える一方で、人間のレビュー速度には物理的な上限がある
- 「レビュー済み」と「安全」は別物で、そのギャップは可視化されにくい
- Snykを開発フローに組み込めば、書いた端からリアルタイムで検知・修正できる
本記事が、AIコーディングツールとセキュリティの両立を検討中、あるいはすでに悩んでいる方のご参考になっていれば幸いです。
