SQL Injection の現実 2026｜バイブコーディングが書き忘れる 5 パターンと公開報道事例から学ぶ中堅企業の防衛策

「ログインフォーム作って」と Cursor に頼んだ翌週、SQL Injection で全顧客リストが流出した――。 2026 年、生成 AI に SQL を組ませる中堅企業が急増しています。便利な反面、prepared statement・バインドパラメータ・エスケープ・入力検証・DB 権限分離 の 5 つの基本対策のうち、AI 生成コードはしばしば一部 (or 全部) を書き忘れます。

SQL Injection (SQLi) は OWASP Top 10 (2021) 第 3 位「A03:Injection」、IPA「情報セキュリティ 10 大脅威 2026」でも上位の常連です。20 年前から知られている古典的攻撃が、AI 普及で 2026 年に再燃 しています。

本記事は連載「バイブコーディング危機」第 2 回として、SQLi の仕組み、公開報道済の大事故 5 件、AI が書き忘れるパターン 5 件、中堅企業向けの検知ツール、防衛策、90 日教育プラン、既存システムの緊急対応 5 項目までを完全版で整理します。

**連載「バイブコーディング危機」**は、AI で自社システムを開発する中堅企業向けに、専門家不在で起きるリスクを1 本ずつ深掘りします。 第 1 回（概論 + 7 リスク類型 + チェックリスト 10 項目）はこちら。

---

目次

1. SQL Injection とは何か（10 秒で理解する仕組み）
2. なぜ 2026 年に SQLi が再燃しているか
3. 公開報道済 SQLi 大事故 5 件
4. バイブコーディングが書き忘れる 5 パターン（コード例）
5. 中堅企業の検知：OWASP ZAP / sqlmap / Burp Community
6. 中堅企業の防衛：prepared statement / ORM / WAF / 入力検証
7. 教育：エンジニア 1 名へ 90 日で SQLi 対策スキル
8. 既存システムの「今すぐ」やる 5 項目
9. よくある質問（FAQ 10 問）
10. 参考一次ソース

---

SQL Injection とは何か（10 秒で理解する仕組み）

SQL Injection (SQLi) は、Web フォーム等のユーザー入力をそのまま SQL クエリに連結することで、攻撃者が任意の SQL を実行できてしまう脆弱性 です。

動く例（脆弱なログイン）

// 脆弱なコード（AI に「PHP でログイン書いて」と頼むと、初期生成では概してこう）
$user = $_POST['username'];
$pass = $_POST['password'];
$sql = "SELECT * FROM users WHERE username = '$user' AND password = '$pass'";
$result = mysqli_query($conn, $sql);

攻撃者が username に admin' -- と入れると、SQL は以下になります。

SELECT * FROM users WHERE username = 'admin' --' AND password = '...'

-- 以降はコメント扱いになります。パスワード検証を完全にスキップして admin としてログインが成立します。

同じ脆弱性で全件流出する例

username に ' OR '1'='1 を入れると以下になります。

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...'

OR '1'='1' は常に true となり、AND 条件を効かなくする工夫次第で 全 user データが取れます。さらに UNION 句を使えば、他テーブル（クレジットカード番号 / 個人情報 / API キー）も任意に抽出可能になります。

これが SQL Injection です。ユーザー入力を SQL 文字列にそのまま連結した瞬間、攻撃者は DB を直接操作する力を手にします。

---

なぜ 2026 年に SQLi が再燃しているか

SQLi は 1998 年頃に Phrack マガジンで体系化された 28 年前からの古典的攻撃です。OWASP Top 10 でも 2003 年初版以来ずっと上位で、対策方法も完全に確立しています。にも関わらず 2026 年に「危機」と呼ぶのは、3 つの構造変化があるからです。

構造変化 1: AI コード生成の急速普及

GitHub「Octoverse 2024 Report」によれば、開発者の 92% が AI コーディングツールを使用。総務省「令和 7 年版 情報通信白書」では、国内企業の生成 AI 業務利用率は 38.7%（前年比 2.4 倍）。IPA「DX 白書 2026」では、中堅企業の 53% が「情シスとは別の部門で AI ツールを業務利用」と回答している。

つまり、SQL を書く人口が「専門エンジニア」から「業務部門の AI 利用者」へ急速に拡大 しています。専門家チェックゼロのまま本番投入される確率も同時に上昇しています。

構造変化 2: AI 生成コードの「動くが安全でない」傾向

スタンフォード大学 Perry et al.「Do Users Write More Insecure Code with AI Assistants?」(2022 / CCS 2023) は、AI コーディングアシスタント利用者は 非利用者より セキュリティ脆弱性を含むコードを書く確率が高い と報告しています。理由は、AI が「動くコード」を出すと利用者が「正しい」と過信する傾向があるためです。

SQLi 観点で言えば、AI は「文字列連結で SQL を組む」最も読みやすい (≒ 教科書の例題に多い) パターンを出力しがちで、prepared statement / バインドパラメータの安全パターンを書き忘れます。

構造変化 3: 改正個情法の 72 時間報告義務

2022 年 4 月施行の改正個人情報保護法では、一定要件を満たす個人情報漏洩等は 個情委への 72 時間以内の速報、本人通知 が義務化されました。SQLi で全顧客リストが流出した場合は即時報告対象となり、ペナルティは最大 1 億円です。

→ 「動く SQL」を AI が書いた瞬間から、72 時間以内の経営リスクが乗っかる時代 が 2022 年以降本格化し、2026 年に AI 普及で顕在化しています。

---

公開報道済 SQLi 大事故 5 件

重要な注記: 下記の公開事例は「バイブコーディングが直接の原因」と断定するものではありません。多くは大企業の専門開発体制下で起きた事故です。 しかし、専門家チェックが薄い環境（=バイブコーディング環境）で同種事故が起きる確率は構造的に高くなります。事例は「専門家不在の自社開発でも同じ類型が起きる」ことを示す警鐘として参照します。

事例 1: Heartland Payment Systems（2008-2009）— 1.34 億件流出

項目	詳細
被害規模	クレジットカード番号 1.34 億件（当時米国史上最大規模）
起因	SQL Injection 起因のマルウェア侵入
経過	2007 年に侵入、2009 年 1 月に公表
損害	推定総額 1.45 億ドル（罰金 + 訴訟 + 信用回復コスト）
一次ソース	SEC 公開書類、FBI 公表、Verizon DBIR 2009

学び: SQLi 1 つで決済処理の中枢が落ち、業界トップ規模の決済プロセッサーでも起き得ます。「うちは小さいから狙われない」は通用しません。

事例 2: TalkTalk（2015）— 英国通信大手、£400,000 罰金

項目	詳細
被害規模	顧客情報 15.7 万件（うちカード情報 1.5 万件）
起因	古い Web ページの SQL Injection（買収した子会社の遺産システム）
罰金	英国 ICO £400,000（当時の最大規模）
一次ソース	UK ICO「TalkTalk monetary penalty notice」(2016-10-05)

学び: 「古いシステムだから」「買収した子会社だから」は逃げ口になりません。SQLi 1 つで通信事業者として行政罰を受けることになります。中堅企業の自社開発でも、「あの担当者が前に作ったもの」は今日点検すべきです。

事例 3: Yahoo Voices（2012）— 45 万件平文パスワード流出

項目	詳細
被害規模	45 万件のユーザー名 + 平文パスワード
起因	SQL Injection で DB ダンプ取得、UNION 句で他テーブルにアクセス
公開	攻撃者集団「D33Ds Company」が pastebin に投稿
一次ソース	Yahoo 公式声明、D33Ds Company 公開声明（公開当時）

学び: 「パスワードを平文で DB に保存していた」 ことが決定的な追加被害を生みました。SQLi と平文保存が重なると全部抜かれます。bcrypt / Argon2 で hash 化していれば、流出してもログイン突破はされません。

事例 4: MOVEit Transfer（2023）— CVE-2023-34362、米国推定 6,300 万人影響

項目	詳細
被害規模	米国推定 6,300 万人 + 数千組織
CVE	CVE-2023-34362（CVSS 9.8）
起因	Progress Software の MOVEit Transfer に SQLi、Cl0p ランサム集団がゼロデイ攻撃
被害組織	米国エネルギー省、Shell、BBC、Ernst & Young、英国航空、政府機関多数
一次ソース	Progress Software 公式 advisory、CISA Alert AA23-158A、NIST NVD

学び: SaaS / オンプレ製品のサプライチェーン経由で SQLi が広く影響する典型例です。「自社が SQLi を書かなくても、使っている SaaS の脆弱性で被害者になる」 ことがあります。中堅企業はベンダー脆弱性開示の購読 + WAF 配置で被害範囲を狭めるべきです。

事例 5: GhostShell キャンペーン（2012-2013）— 100 万件超の自動化攻撃

項目	詳細
被害規模	累計 100 万件超、対象は UN・FBI・NASA を含む 100+ 組織
起因	sqlmap 等の自動化ツールで SQLi 脆弱な Web を網羅スキャン
公開	攻撃集団「Team GhostShell」が連続的に Pastebin に投稿
一次ソース	公開ハッキング集団声明（GhostShell 公開記録、当時の Imperva 等の解析レポート）

学び: SQLi は人間が手で攻撃するもの「ではありません」。sqlmap のような自動化ツールが世界中の Web を 24 時間スキャンしています。「うちの存在は知られていない」は通用しません。WAF + IDS + 監視で「気付かれて即遮断」する仕組みが必須です。

5 事例の共通教訓

1. 規模に関わらず狙われる — Heartland のような巨人も、TalkTalk のような買収子会社も対象
2. 古典的攻撃が再燃する — 1998 年体系化された SQLi が、2008 / 2012 / 2015 / 2023 と繰り返し大事故を生む
3. 自動化されている — sqlmap で世界中の Web が常時スキャン対象、見つかれば即攻撃
4. 追加被害が決定的 — 平文パスワード / 弱い暗号化 / 過剰権限 が SQLi の被害を 10 倍化
5. 法的責任とサプライチェーン — 自社が書かなくても、使ってる製品の脆弱性で経営責任が問われる

---

バイブコーディングが書き忘れる 5 パターン（コード例）

AI に「○○の機能を作って」と頼むと、安全な書き方を 明示的に要求しない限り 危険なパターンを出力することが多いです。実例で確認します。

パターン 1: 文字列連結で SQL を組む（最頻出）

// AI 初期生成（脆弱）
$id = $_GET['id'];
$sql = "SELECT * FROM products WHERE id = " . $id;

修正後（安全）:

$stmt = $pdo->prepare("SELECT * FROM products WHERE id = :id");
$stmt->execute(['id' => $_GET['id']]);

なぜ AI は脆弱を出すか: 文字列連結の方がコードが短く、教科書の例題に多いためです。AI は「最も典型的なパターン」を出力する傾向があります。

パターン 2: バインドパラメータの「型」を間違える

# AI 初期生成（一見安全だが、ORDER BY のカラム名にはバインドできない）
column = request.args.get('sort')  # 'name' or 'price' を期待
sql = f"SELECT * FROM products ORDER BY {column}"
cursor.execute(sql)

なぜ危険か: バインドパラメータは WHERE id = ? のような 値 にしか使えません。カラム名・テーブル名・SQL キーワードはバインドできません。攻撃者が column=name; DROP TABLE products-- を投げると DROP TABLE が動いてしまいます。

修正後:

allowed = {'name', 'price', 'created_at'}
column = request.args.get('sort')
if column not in allowed:
    column = 'name'  # default
sql = f"SELECT * FROM products ORDER BY {column}"

ホワイトリスト方式 が唯一の正解です。AI に「ORDER BY 動的にできる？」と頼むと、概してこの罠を踏みます。

パターン 3: エスケープを「自分で書く」つもりが失敗する

// AI 初期生成（中途半端なエスケープ、危険）
const input = req.query.search.replace(/'/g, "\\'");
const sql = `SELECT * FROM articles WHERE title LIKE '%${input}%'`;
db.query(sql);

なぜ危険か: ' だけエスケープしても、%・_・\ 等の意味を持つ他文字、文字コード（UTF-8 / SJIS）の差、mysql_real_escape_string 相当のロケール処理など、手動エスケープは多重に破綻します。

修正後:

const sql = "SELECT * FROM articles WHERE title LIKE ?";
const param = `%${req.query.search}%`;
db.query(sql, [param]);

prepared statement に任せましょう。

パターン 4: 「ストアド関数なら安全」の誤解

-- AI 初期生成（ストアド内部で動的 SQL、結局 SQLi 可能）
CREATE PROCEDURE search_users(IN keyword VARCHAR(100))
BEGIN
    SET @sql = CONCAT('SELECT * FROM users WHERE name LIKE ''%', keyword, '%''');
    PREPARE stmt FROM @sql;
    EXECUTE stmt;
END

なぜ危険か: ストアドプロシージャ内部で動的 SQL を組み立てる場合、外部からの SQLi はそのまま貫通します。「ストアド = 安全」は誤解です。

修正後: アプリケーション層で prepared statement を使うか、ストアド内も PREPARE で ? バインドします。

パターン 5: NoSQL / GraphQL なら SQLi はない、の誤解

// MongoDB に NoSQL Injection (MongoDB Injection)
const user = await db.collection('users').findOne({
    username: req.body.username,  // {$ne: null} を投げると全 user 一致
    password: req.body.password,
});

なぜ危険か: NoSQL DB でも構造化クエリ言語の「演算子注入」が起きます。MongoDB に {username: {$ne: null}, password: {$ne: null}} を JSON で投げると 第 1 ユーザーで認証が成立してしまいます。

修正後: 入力を必ず String にキャストし、$ne / $gt / $regex 等の演算子オブジェクトを許容しないようにします。GraphQL も同様で、Resolver で必ず型チェックを行います。

→ 「SQLi」は名前こそ SQL ですが、本質は「ユーザー入力を信頼してクエリを組み立てる」全般のアンチパターン です。AI 生成コードで頻発します。

---

中堅企業の検知：OWASP ZAP / sqlmap / Burp Community

中堅企業（情シス 1-3 名）が「自社が SQLi 脆弱性を持っていないか」を 0 円 〜 数万円 で検知できる OSS ツールを 3 つ紹介します。

1. OWASP ZAP（Zed Attack Proxy）

• 性質: 総合 Web 脆弱性スキャナー、OSS、無料
• できること: 自動スキャン + 手動テスト + プロキシ録画 + API テスト
• SQLi 検知: 自動スキャンで ' OR 1=1 UNION SELECT 等のペイロード送信、レスポンス差分で判定
• 学習曲線: 中（初日 2 時間で基本操作）
• 想定運用: 月 1 回 全 endpoint 自動スキャン、CI に GitHub Actions で組込
• 一次ソース: OWASP「ZAP 公式ドキュメント」、zaproxy.org

2. sqlmap

• 性質: SQLi 専用の世界的 OSS、Python 製
• できること: 1 URL に対し全 SQLi パターンを自動試行、見つかれば DB ダンプも自動取得
• SQLi 検知: 「ある」or 「ない」を 1 〜 60 秒で確定
• 学習曲線: 低（コマンド 1 行で動く）
• 注意: 自社サイトにのみ使用してください。他社サイトに無許可で撃つと不正アクセス禁止法違反になります
• 一次ソース: sqlmap.org、Bernardo Damele AG. の論文「Advanced SQL Injection Techniques」

# 例: 自社のステージング環境に対し
sqlmap -u "https://staging.example.com/products?id=1" --batch --risk=3 --level=5

3. Burp Suite Community

• 性質: 商用 Burp Suite Pro の無料版（PortSwigger 社）
• できること: HTTP プロキシ + 手動テスト + Repeater + 基本スキャン
• SQLi 検知: 手動テスト中心、エキスパート向け
• 学習曲線: 中-高（PortSwigger Web Security Academy 無料コースで習得可能）
• 一次ソース: PortSwigger 公式、portswigger.net

検知体制の中堅向け推奨構成

役割	ツール	頻度	担当
自動 CI スキャン	OWASP ZAP	PR 毎	開発者
月 1 回 全社スキャン	OWASP ZAP	月 1	情シス
重点 endpoint テスト	sqlmap	四半期 1	情シス + 外部顧問
監査 / ペネトレ	Burp Pro (or 外部)	年 1	外部監査

追加コスト 0 円 〜 数万円 / 月 で SQLi 検知体制は組めます。

---

中堅企業の防衛：prepared statement / ORM / WAF / 入力検証

検知だけでなく、構築時の防衛策を 4 層で整理します。

層 1: prepared statement / バインドパラメータ（最重要）

言語	推奨ライブラリ	例
PHP	PDO	$pdo->prepare('...')->execute([...])
Python	psycopg2 / sqlite3	cur.execute('... WHERE id = %s', (id,))
Node.js	mysql2 / pg	conn.query('... ?', [id])
Java	PreparedStatement	pstmt.setInt(1, id)
Go	database/sql	db.Query('... ?', id)

全ての SQL に対し例外なく prepared statement を使います。これだけで SQLi の 95% は防げます。

層 2: ORM の利用

• PHP: Laravel Eloquent / Doctrine
• Python: SQLAlchemy / Django ORM
• Node.js: TypeORM / Prisma / Sequelize
• Ruby: ActiveRecord
• Java: Hibernate / JPA

ORM は内部で prepared statement を使うため、通常の使い方では SQLi が発生しません。ただし Eloquent::raw() SQLAlchemy.text() 等の生 SQL 機能を使う瞬間にリスクが戻ります。

層 3: WAF（Web Application Firewall）

• Cloudflare WAF（無料プランで基本 SQLi ブロック付き）
• AWS WAF（managed rule の OWASP Top 10 セット）
• Imperva / F5 / ModSecurity（オンプレ OSS）

Cloudflare 無料プランを前段に置くだけ で、世界中の sqlmap 自動攻撃の 90% は遮断されます。中堅企業の最初の一手として最適です。

層 4: 入力検証 + DB ユーザー権限分離

• 入力検証: 数字を期待する箇所は整数キャスト (int($_GET['id']))、enum は in_array チェック
• DB 権限分離: 一般機能用の DB ユーザーは SELECT/INSERT/UPDATE/DELETE のみ、DROP / ALTER / FILE / SUPER 権限なし
  • SQLi を突破されても DROP TABLE / ファイル書き出しを防げます
• ログ: スロークエリログ + クエリ監査ログ、異常パターン (大量 UNION / DROP / /*!50000 のような MySQL 拡張) を Slack 通知

---

教育：エンジニア 1 名へ 90 日で SQLi 対策スキル

「うちには専門家がいない」という中堅企業向けに、社内エンジニア 1 名を 90 日で SQLi 対策専門家にする教育プラン を提示します。すべて無料リソースです。

90 日プラン

Week	内容	リソース
1-2	OWASP Top 10 全体把握	OWASP 公式日本語訳 (無料)
3-4	SQLi の仕組み hands-on	PortSwigger Web Security Academy「SQL Injection」全 lab (無料、英語)
5-6	自社コード手動レビュー	grep で全 SQL 抽出、prepared statement 化
7-8	sqlmap 演習	自社ステージング環境で全 endpoint 試行
9-10	WAF 設定	Cloudflare 無料プラン導入 + custom rule
11-12	CI 統合	OWASP ZAP を GitHub Actions に組み込み

合計約 40-60 時間 の学習で、SQLi 対策の実務レベルに到達します。

推奨書籍 / コース（投資 1 万円以下）

• PortSwigger Web Security Academy — 完全無料、世界標準の Web セキュリティ教材
• OWASP Cheat Sheet Series — 完全無料、防御パターン辞書
• IPA「安全な Web サイトの作り方」 — 完全無料、日本語、改訂版定期更新
• 書籍「体系的に学ぶ 安全な Web アプリケーションの作り方」徳丸浩著 (4,000 円程度) — 日本語の決定版

---

既存システムの「今すぐ」やる 5 項目

「うちの既存システムが脆弱かもしれない」と感じたら、今日 30 分で取れる 5 項目 を提示します。

1. WAF を Cloudflare 無料プランで 30 分前置

• DNS を Cloudflare に切替 (15 分)
• WAF Managed Rules を ON (5 分)
• Bot Fight Mode を ON (5 分)
• 効果: 世界中の自動 SQLi 攻撃の 90% が即遮断されます

2. すべての SQL クエリを prepared statement 化

# プロジェクトディレクトリで grep
grep -rn 'SELECT .*\$' src/
grep -rn '\"SELECT.*\" \+ ' src/
grep -rn 'CONCAT.*SQL' src/

ヒットした箇所を順次 prepared statement に書き換えます。AI に「この PHP コードを prepared statement に書き換えて」と頼めば 1 分で正解が返ってきます。

3. sqlmap で 1 endpoint テスト（60 秒）

# 自社ステージング環境にのみ実行
sqlmap -u "https://staging.example.com/products?id=1" --batch

「Vulnerable」or 「Not vulnerable」が 60 秒で出ます。Vulnerable なら即修正しましょう。

4. DB ユーザー権限を read-only に最小化

-- 一般機能用 DB ユーザーから DROP / FILE 権限を剥奪
REVOKE ALL PRIVILEGES ON *.* FROM 'app_user'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE ON your_db.* TO 'app_user'@'%';
FLUSH PRIVILEGES;

5. ログを 1 年保存 + 異常アラート

• DB スロークエリログを有効化 + 1 年保存
• アクセスログから ' OR 1=1 UNION SELECT -- DROP TABLE 等を grep + Slack 通知
• 月 1 回レビュー

---

よくある質問（FAQ 10 問）

Q1. SQLi はなぜ AI に書かせるとよく起きるんですか？

A. AI は「最も典型的なコードパターン」を出力する傾向があり、教科書例題に多い 文字列連結 SQL がよく出ます。明示的に「prepared statement で書いて」と指示しない限り、安全な書き方を選びません。Perry et al. (Stanford, 2022) の研究でも、AI コーディングアシスタント利用者は非利用者より脆弱性を含むコードを書く確率が高いと報告されています。

Q2. ORM を使ってればもう SQLi は起きませんか？

A. 概ね起きませんが、生 SQL 機能 (Eloquent::raw() / SQLAlchemy.text() 等) を使う瞬間にリスクが戻ります。ORM 利用中も raw 系メソッドへのレビューは必須です。

Q3. WAF だけで SQLi は防げますか？

A. WAF は最後の網であり、最初の盾ではありません。WAF をすり抜ける手法 (例: コメント挿入 UN/**/ION SELECT、文字コード encoding) は研究され続けています。コードレベルで prepared statement を使うのが本筋で、WAF はその上の追加層と捉えてください。

Q4. NoSQL DB（MongoDB / DynamoDB）なら SQLi はないんですか？

A. 「NoSQL Injection」は存在します。MongoDB なら {$ne: null} 演算子注入、DynamoDB なら scan 条件への注入が起きます。「クエリ言語」を使う以上、injection リスクは同根です。

Q5. 自社開発でなく SaaS 利用なら SQLi 心配ありませんか？

A. いいえ。SaaS 自体の SQLi 脆弱性 (例: MOVEit Transfer 2023) でサプライチェーン被害者になり得ます。ベンダー脆弱性開示の購読 + WAF 前置 で被害範囲を狭めるべきです。

Q6. SQLi 攻撃を検知するコストは？

A. OSS ツールなら追加 0 円です。OWASP ZAP / sqlmap / Cloudflare WAF 無料プランで中堅企業は十分です。商用 (Burp Pro / Imperva / Akamai) なら月 数万 〜 数百万円です。

Q7. SQLi で漏洩した場合の法的対応は？

A. 改正個情法 (2022 施行) で漏洩発覚から 72 時間以内に個情委へ速報し、必要に応じ本人通知が義務となります。違反時罰則は最大 1 億円です。連載第 7 回（法令違反の罠）で詳述予定です。

Q8. Laravel / Django / Express など主要フレームワークの SQLi 対策は？

A. Laravel = Eloquent / Query Builder で自動 prepared statement、生 SQL は DB::statement() 等で対応します。Django = ORM が前提で、生 SQL は raw() / extra() で対応します。Express = mysql2 / pg / sequelize の bind parameter、? プレースホルダを使います。いずれも公式 docs に SQLi 対策の章 があり、フレームワーク選定時に確認すべきです。

Q9. AI 生成コードを SQLi 観点でレビューするプロンプトは？

A. 「このコードに SQL Injection 脆弱性はないか、prepared statement を使っていない箇所を列挙して、修正案を出して」が基本テンプレです。自分でレビューする目線を AI に持たせる のがコツです。

Q10. SQLi 試験のために自社サイトに sqlmap を撃つのは合法ですか？

A. 自社所有のサイト / 自社契約のステージング環境 なら合法です。ただし、レンタルサーバー / クラウド (AWS / GCP / Azure) で稼働している場合、提供事業者の利用規約 で「セキュリティテストは事前申請」とされていることが多いです。AWS なら Penetration Testing Acknowledgement は不要ですがガイドライン遵守が必要で、GCP / Azure も同様です。事前に契約書面を確認するのが安全です。

---

参考一次ソース

1. OWASP Top 10 (2021) A03:Injection — https://owasp.org/Top10/
2. OWASP「SQL Injection Prevention Cheat Sheet」 — 公式防御パターン辞書
3. IPA「情報セキュリティ 10 大脅威 2026」 — 組織編、毎年改訂
4. IPA「安全な Web サイトの作り方」改訂第 7 版 — 日本語、SQLi 章詳述
5. NIST NVD (CVE database) CVE-2023-34362 (MOVEit Transfer SQLi)
6. UK ICO「TalkTalk monetary penalty notice」 (2016-10-05) — 罰金事案 公式
7. Verizon「Data Breach Investigations Report (DBIR)」 年次刊行 — SQLi 統計
8. JPCERT/CC「SQL インジェクション対策の対策状況」 注意喚起 / 統計
9. Progress Software「MOVEit Transfer Critical Security Alert」 (2023-05-31)
10. CISA Alert AA23-158A — MOVEit + Cl0p ランサム
11. Perry et al.「Do Users Write More Insecure Code with AI Assistants?」 Stanford / CCS 2023 — AI 利用者の脆弱性傾向研究
12. GitHub「Octoverse 2024 Report」 — AI コーディングツール利用率 92%
13. 総務省「令和 7 年版 情報通信白書」 — 国内生成 AI 業務利用率 38.7%
14. PortSwigger Web Security Academy「SQL Injection」 lab — 無料 hands-on 教材
15. 徳丸浩「体系的に学ぶ 安全な Web アプリケーションの作り方」第 2 版 — 日本語決定版書籍

各ソースの最新版 URL は記事公開時に追加。法令・統計は公開官公庁データで verify 可能なものを優先掲載。

---

まとめ

SQL Injection は 28 年前から知られている古典的攻撃ですが、2026 年に AI 普及で再燃 しています。バイブコーディング環境では、5 つの基本対策（prepared statement / バインドパラメータ / エスケープ / 入力検証 / DB 権限分離）のうち一部 (or 全部) が書き忘れられる確率 が構造的に高くなります。

防衛の核心は 4 層です。

1. prepared statement / バインドパラメータ 例外なく
2. ORM 利用、raw メソッドのレビュー徹底
3. WAF（Cloudflare 無料プランで前段）
4. 入力検証 + DB 権限分離

中堅企業（情シス 1-3 名）でも、OSS ツール (OWASP ZAP / sqlmap) + PortSwigger Web Security Academy 無料コース + エンジニア 1 名 × 90 日教育 で実務レベルに到達できます。「うちには専門家がいない」は今日終わらせましょう。

次回（第 3 回）は 認可漏れ を扱います。if user.is_admin を AI が書き忘れる構造、URL 直叩きで他人のデータが見える、社内 LAN だけで運用のはずが VPN 経由で外部から見える――これらの 5 シーンと公開事例を整理します。

---

「うちのシステム、SQLi 大丈夫か今すぐ知りたい」と感じたら

GXO は中堅企業向けに、既存自社開発システムの SQLi スキャン（OWASP ZAP / sqlmap）+ prepared statement 化のリファクタリング支援 + 90 日教育プログラム + 月額顧問契約を段階的に提供します。初回 30 分の無料相談で「うちは大丈夫か」「何から手をつけるべきか」を整理できます。

SQLi 脆弱性診断・教育の無料相談を予約

※ 営業電話はしません | オンライン対応可 | 相談だけでもOK

---

連載「バイブコーディング危機」全話

• 第 1 回 概論：AI で自社開発した結果、実際に起きた 7 つのトラブル類型と中堅企業の防衛策
• 第 2 回 本記事
• 第 3 回 認可漏れ事例集（2026-05-23 公開予定）
• 第 4 回 サービス停止の財務影響：江崎グリコ 4 ヶ月から学ぶ（2026-05-24 公開予定）
• 第 5 回 DELETE FROM テーブル ENTER の朝（2026-05-25 公開予定）
• 第 6 回 気づかない 6 ヶ月：ランサムウェアと自社開発（2026-05-26 公開予定）
• 第 7 回 法令違反の罠：電子帳簿保存法と特商法（2026-05-27 公開予定）
• 第 8 回 退職者がブラックボックスを残す日（2026-05-28 公開予定）
• 第 9 回 バックアップが動いてない、を発見する方法（2026-05-29 公開予定）
• 第 10 回 MFA を「あとで入れる」と言って入れない（2026-05-30 公開予定）
• 第 11 回 セキュリティスキャン（SAST / DAST / SCA を CI に組む）／第 12 回 ノーコード・ローコードの技術的負債／第 13 回 ライセンス・OSS 混入と SBOM／第 14 回 「動くけど誰も直せない」引き継ぎ問題
• 第 15 回 API キー漏洩（.env を Git にコミットする日）／第 16 回 クラウド従量課金の暴走／第 17 回 AI が存在しないパッケージ名を提案する罠／第 18 回 生成 AI と個人情報保護法・委託先管理／第 19 回 テストを書かない AI コードとリグレッション／第 20 回 ログも監視もないシステムの末路
• 全話一覧は連載ハブ /feature/vibe-coding-crisis からアクセスできます