WEBサイト
池田南美夫より ── 7月のある週末に見つかったもの
私たちは2026年7月4日、当サイトが運用しているサーバーとサイト全体を総点検するプロジェクトを立ち上げました。インフラ、フロントエンド、コンテンツ、会員向けページ、日々の運用の仕組み、データベース。6つの領域にそれぞれ調査の目を送り込み、見つかった弱点を一つひとつ台帳に記録していく作業でした。結果として、36件の弱点が見つかりました。
そのうちの1件が、記事一覧ページの「カテゴリで絞り込む」という、ごく普通の機能に潜んでいました。ユーザーが指定した絞り込み条件の値が、検証されないままデータベースへの問い合わせ文に直接組み込まれてしまっていたのです。いわゆるSQLインジェクションと呼ばれる種類の脆弱性です。見つけた瞬間にすぐ直したい衝動はありましたが、私たちは「見つけたことをまず正確に記録し、優先順位をつけ、判断を待つ」という運用ルールに従いました。急いで直したつもりが別の場所を壊す、ということを避けるためです。
そして7月6日、私から「この件の修正は任せる」と明確な委任を出しました。ここから先に起きたことが、この記事の本題です。AIエージェントに実装を任せている以上、いつ誰の環境でも同じことが起きうる、という前提でお読みいただければと思います。
なぜAIは「動くコード」は書けても「安全なコード」を書けないのか
AIが生成するコードの品質は、この数年で劇的に変わりました。Veracodeが2026年春に公開した調査によれば、100以上のLLMを検証した結果、AIが生成するコードの構文的な正確さ（そのまま動くかどうか）は、2023年頃の約50%から、2026年には95%まで向上しています。「頼んだ通りに動くコード」を書く能力は、もはや疑いようがないレベルに達しています。
ところが同じ調査で、セキュリティ品質のスコアは45〜55%のあたりで長らく頭打ちのままだと報告されています。動くことと、安全であることは、別の軸だということです。実際、Veracodeの2025年版レポートでは、SQLインジェクション・クロスサイトスクリプティング（XSS）・ログインジェクション・脆弱な暗号化という4種類の代表的な脆弱性を検証したところ、XSSは86%、ログインジェクションに至っては88%のコードが脆弱だったという結果も出ています。
私はこの数字を見て、当サイトで起きたことが「たまたま運が悪かった」のではなく、AIコーディング全体に共通する構造的な傾向の一つの表れだったのだと理解しました。AIは「要求された機能を満たす」ことには非常に強い一方、「想定していない入力が来たときにどう防御するか」という、要求されていない領域については弱いままなのです。
「自分のコードは大丈夫」という錯覚
もっと厄介なのは、この弱さに対する私たち人間側の認識のズレです。Snykの調査（Cloud Wars報道）によれば、開発者の75%超が「AI生成コードは人間が書いたコードより安全だ」と回答した一方で、56%超が「AI生成コードが実際にセキュリティ上の問題を引き起こしたことがある」と認めています。さらに、80%が何らかの形で社内のセキュリティポリシーを迂回した経験があると答え、それでいてAI生成コードを実際にスキャンしているのはわずか10%だったといいます。「安全だと思っている」ことと「実際に安全か確かめている」ことの間に、大きな溝があるわけです。
この溝は現場の温度差だけでは終わりません。CIO Diveが報じた同調査の別集計では、経営層（C-suite）の19.4%が「AIコードのリスクはゼロだ」と回答したのに対し、実際にセキュリティを担当する部署でそう答えたのはわずか4.1%でした。経営の意思決定をする立場の人ほど、現場の3倍以上楽観的だということになります。これは決して他人事ではなく、私たち自身、判断を任せる側としていつも自戒しなければならない数字だと感じています。
そしてこの「錯覚」は、実は数年前から指摘されていました。スタンフォード大学のNeil Perry氏らが行った研究（TechCrunchの報道）では、47名の開発者にAIコーディングアシスタントを使わせた実験で、AIを使った群のほうが安全でないコードを書く割合が高く、しかも「自分のコードは安全だ」と誤って評価する割合も高かったという結果が出ています。「便利に使えている」という手応えそのものが、慎重さを鈍らせてしまう。この構図は、当サイトで起きたことにもそのまま当てはまります。
48日間、世界中から見えていたコード
数字の話だけでなく、実際に何が起きうるのかを示す実例も紹介させてください。2026年4月、企業評価66億ドルという評価を受けていた「vibe coding」型の開発プラットフォームで、深刻なインシデントが報告されました（MetaMindzの報告）。ある機能について「本人だけがアクセスできるはず」という認可チェックが実装から欠落していたため、48日間にわたって、全ユーザーのソースコード・データベースの認証情報・チャット履歴が、外部から閲覧可能な状態になっていたというものです。
これは特別な失敗談ではなく、広く見られる傾向のようです。Towards Data Scienceに掲載された調査（出典）では、vibe codingによって公開デプロイされたアプリを5,000件以上調査したところ、約40%が医療情報・金融記録・顧客情報などの機微なデータを露出していたと報告されています。「機能はちゃんと動いている」という状態と、「安全に守られている」という状態は、まったく別のチェックが必要だということを、この数字が物語っています。
私たちが見つけたSQLインジェクションも、性質としては同じ根を持っていました。「絞り込み機能はちゃんと動く」ことは確認されていても、「悪意のある値が来たときにどう振る舞うか」は、誰も確かめていなかったのです。
発見から修正まで、私たちが辿った5段階
ここからは、実際に当サイトで何をしたかを、できるだけ具体的に、しかし手口の再現にはならない範囲でお伝えします。
まず7月4日の総点検で、記事一覧のカテゴリ絞り込み機能に、検証なしの値の連結が見つかりました。この時点では修正せず、深刻度をつけて台帳に記録し、判断を待つ状態にしました。✅ 実装する手と疑う目の役割分離という当サイトの運用ルールが、ここで機能しています。見つけた人がそのまま直すのではなく、記録を挟むことで、判断者の目を必ず一度通すようにしているのです。
7月6日、私から「この件の修正は任せる」と明確に委任を出しました。任された側がまず行ったのは、その1箇所だけを直すことではなく、同じパターンが他にもないかの横展開調査でした。結果、似た構造が実は複数箇所（一覧ページの絞り込み機能と、ツール紹介ページの絞り込み機能）に散らばっていることが判明しました。1件の指摘の裏に、同じ根を持つ複数の穴が隠れていたわけです。
次に対策の設計です。単純に「英数字だけを許可する」という制限は使えませんでした。実際の絞り込み値には「マーケティング」「アクセシビリティ」といった日本語のカテゴリ名がそのまま使われていたためです。文字種で判断する対策は、正常な利用を壊してしまいます。最終的に採用したのは、値を組み立てる段階でシステムが標準的に備えている、安全にエスケープしてくれる記述方式に統一するという方法でした。文字種を問わず、値がどんな内容であっても安全に扱われる形です。
修正の実施手順は次の通りです。まず全対象ファイルのバックアップを取り、構文に誤りがないかを確認しました。次に検証環境で、実際に攻撃を意図した値を意図的に投げてみて、修正前は明らかに異常な件数が返っていたものが、修正後は正常な件数に収束することを確かめました。同時に、正常な検索（英語のカテゴリ名・日本語のカテゴリ名の両方）で、これまでと同じ件数が返ることも確認しました。✅ 本番反映前の攻撃再現テストという規律が、ここで機能しています。
最後に、同じ手順を本番環境でも実施し、エラーログに新しい異常が出ていないことを確認して、この件を完了としました。台帳の記録も「完了」に更新しています。この5段階──発見・記録・委任・横展開・検証──のどれか一つでも抜けていたら、私たちは「1箇所直したつもりで残り2箇所を見逃す」ことになっていたはずです。
明日からWEBディレクターが変えられること
この経験から、私が明日からでも実践できると考えていることをまとめます。
一つ目は、「動いている」ことと「安全である」ことを、はっきり別の確認項目として扱うことです。OWASP Foundationが公開しているLLMアプリケーションのためのTop 10でも、AI生成コードで最も頻出するパターンの一つとして「機能としては正しいのに、認可のチェックだけが欠落している」ことが指摘されています。機能テストが通ったからといって、それで確認が終わったと考えないことです。
二つ目は、実装する人（またはAIエージェント）と、それを疑う役割を、意識的に分けることです。同じ人が書いて同じ人が確認すると、見落としも同じように繰り返されがちです。当サイトでは、実装の手とは別に、疑う目の役割を明確に分けて運用しています。
三つ目は、経営層と現場のリスク認識のギャップを、意識的に埋めることです。前述の通り、経営層のほうが現場より3倍以上楽観的だというデータがあります。「AIが書いたから大丈夫だろう」という空気が上から流れてくることがあるなら、それを現場の実感と照らし合わせる場を、意図的に作る必要があります。
四つ目は、国内の動向にも目を配ることです。独立行政法人情報処理推進機構（IPA）が公開している「情報セキュリティ10大脅威2026」解説書（組織編）では、AI関連のサイバーリスクが整理されています。海外の統計だけでなく、国内の公式な整理にも目を通しておくことをおすすめします。
そして最後に、正常な入力だけでなく、意図的に「意地悪な入力」を試す習慣を持つことです。私たちが今回行った攻撃再現テストは、特別な専門知識がなくても、実施すること自体は難しくありません。難しいのは「やろうと思い出すこと」であり、それを仕組みとして忘れないようにすることだと感じています。
疑う目を増やす選択肢 ── 人力レビューと自動ツール、それぞれの向き不向き
AI生成コードを疑う「目」を増やす方法は、一つではありません。大きく分けると「人力によるコードレビュー」「静的解析・自動セキュリティスキャンツール」「攻撃再現テスト（実際に悪意のある入力を試す）」の3つのアプローチがあり、それぞれに向き不向きがあります。
人力レビューは、「この絞り込み条件は本当にこの値だけを許可すべきか」といった業務ロジックの妥当性、つまり文脈判断に強い一方で、大量のコード変更のすべてを毎回人力で見るのは現実的ではありません。静的解析・自動セキュリティスキャンツールは、SQLインジェクションや認可チェックの欠落のように「型」が決まったパターンを機械的・網羅的に検出するのに強い一方、業務固有の文脈判断はできません。攻撃再現テスト（実際にペイロードを投げて確認する）は、修正が本当に効いているかを実証する最後の砦になりますが、対象を絞らないと網羅性に欠けます。
今回の当サイトの対応は、「人力レビュー（総点検での発見）＋攻撃再現テスト（修正後の検証）」の組み合わせでした。静的解析・自動スキャンツールの層は、まだありませんでした。理想は3つを組み合わせて弱点を補い合うことで、どれか一つに頼らないことが重要だと考えています。当サイトの現在地は次の通りです。
自動スキャンツール層の追加: 🔧 自動スキャンツール層は導入検討中
当サイトのこれから（正直な自己開示）
この記事で紹介した規律について、当サイトの現在地を正直にお伝えします。実装する手と疑う目の役割分離、そして本番反映前の攻撃再現テストは、✅ 当サイト実施済です。今回の修正でも、この2つが実際に機能しました。
一方で、AIエージェントが生成したコード全体を対象にした自動セキュリティスキャンツールの導入は、まだ🔧 導入着手中です。今回のように「総点検で見つかって初めて気づく」のではなく、変更のたびに自動で網羅的に確認できる仕組みを作ることが、次の課題だと考えています。見つけてから直すサイクルの精度と速さを、これからも上げていきます。
AIエージェントが書くコードは、これからますます私たちの仕事の中心になっていくはずです。だからこそ、「動く」ことに安心せず、「疑う目」を手放さないことを、これからも当サイトの運用として続けていきます。
関連 archives（連載軸として読む）
- archives/91「Verified AI Agent 37体を個別allowした実装ログ」 ── 警告した側が次の責任を自ら実装で完結させた回
- archives/93「Cloudflareが『検証』の定義を変えた日」 ── 業界標準が変わる瞬間を扱った回
- archives/86「Cloudflareのデフォルト『AI botsブロック』」 ── 気づかれにくい設定の落とし穴を扱った回
- archives/89「機械が人間を超えた日」 ── 「半歩先で警告した側には、半歩先で対応する責任がある」を扱った回
- archives/94「Cloudflareが『価値』を可視化し始めた日」 ── AIエージェントとの向き合い方の続報
一次情報出典
- Veracode: Spring 2026 GenAI Code Security Update
- Veracode: 2025 GenAI Code Security Report
- Cloud Wars: Snyk's AI Code Security Report
- CIO Dive: AI-generated code security (Snyk調査報道)
- MetaMindz: The Lovable Incident
- Towards Data Science: The Reality of Vibe Coding
- OWASP: Top 10 for Large Language Model Applications
- IPA: 情報セキュリティ10大脅威2026 解説書［組織編］
- TechCrunch: Stanford大学 Neil Perry氏らの研究報道
