🛡️ セキュリティ検査を全部AIに回す — Vercel + Neon + SvelteKit 個人運用の実装手順

「セキュリティはどうやってチェックしていますか」と技術者に聞かれたときに、固有名詞で答えられる状態を作る。それがこの記事の目的である。下の表がその答えそのもので、この表だけで導入判断ができるように書いた。

前提は、SvelteKit のアプリを Vercel に載せ、DB は Neon、リポジトリは非公開、開発者は実質1人という構成。有料の脆弱性診断は受けていない。

費用の数字はすべて各社の公式価格表から取っている（2026-08-09 取得）。価格と無料枠は変わるので、引用するときは必ず取得日を添える。比較まとめサイトの数字は使っていない。実際に1件、まとめブログ由来の誤った数値で判断を誤りかけた。

「○○でチェックしています」と言ったときの相手の反応は、相手の職種で変わる。開発者は使ったことがあるかどうかで判断し、情シス・購買は稟議に書ける名前かどうかで判断する。だから軸を2つに分けた。

数字の扱いを先に断っておく。開発者軸は GitHub の star 実測を根拠にしているが、情シス軸は筆者の判断であって計測値ではない。導入企業数やシェアの公開統計は存在しないため、ここを数字で装うのは嘘になる。

購買・情シスが見ているのはその会社が消えないか、責任を取れるかである。だから資金を持ち、監査に慣れ、営業窓口がある Snyk が強い。OWASP と GitHub が強いのも同じ理由で、個社に依存しないからである。

開発者が見ているのは自分の手が速くなるかである。だから CodeRabbit と Semgrep が強い。この2つの評価軸は交わらない。ひとつの名前で両方を満たそうとすると失敗する。

結論として、相手によって出す名前を変えるのが正しい。嘘ではない。全部実際に動かしているのだから、そのうちどれを先に言うかという話にすぎない。

ツールを何本入れても、技術者は「それで何がカバーされるんですか」と聞いてくる。この質問に答えられないと、入れた本数は評価されない。必要なのは何に照らして見たかという基準名である。

やることは単純で、領域ごとに「何で確認しているか」を1行ずつ書くだけである。下が実際の雛形。章番号は ASVS 5.0 の公式ドキュメントから引き写す（版によって番号が変わるため、本記事では領域名で示す）。

注意点が1つある。対応表を作ったことは、その要件を実装・検証したことを意味しない。対応表には必ず「対象外」「未対応」「代替統制で補っている」の行を残す。全部が埋まった表は、審査する側から見ると検証していない証拠に見える。

無料枠には Secrets 検出（意味解析・エントロピー解析）は含まれない。ただしそこは gitleaks が既にカバーしているので、この構成では穴にならない。無料枠に含まれる AI クレジットは60。使い切ったあとも検知自体は止まらず、AI によるトリアージが止まる。

「すべての変更に検査が走る」と言うためには、検査を通さずに本番へ入れる経路が塞がっている必要がある。ここが抜けていると、CI を何本並べても「回避できる検査」にしかならない。

6種類のヘッダーを実装し、コードを読んでも正しく、レビューでも指摘は出なかった。ところが本番に curl を打つと1つも付いていなかった。

原因は、認証フックの末尾にヘッダー付与を書いていたこと。公開パスは途中で早期に return していたため、そこへ到達していなかった。同じ日に、同じ構造の欠陥を3件踏んでいる。

顧客に対して、健康情報のようなセンシティブなデータを扱う事業者が「影響は無かったと思われる」と答えるのは、審査する側から見ると最も弱い回答である。ログ保持は、平時には何の役にも立たず、事故が起きた日に初めて価値が出る。そのときには買い足せない。

月$20 で埋まるのはレート制限・外部ログ転送・ログ保持1日の3つ。ただし上で書いたとおり、ログ保持は「聞かれたら払う」ものではない。事故が起きた日に遡れないと、その後の説明が全部弱くなる。センシティブなデータを扱っているなら、ここは先に払う側に倒すのが妥当だと考えている。

先にやるべき順序が1つある。共有リンクのトークンが URL パスに露出している場合、外部ログ転送より先にそれを直す。順序を逆にすると、認証情報を外部のログサービスへ送り出すことになる。

顧客への説明で失敗する最大の原因は、自分が担保する部分と、事業者が担保する部分をまぜて話すことである。まぜると、事業者の認証をあたかも自社の認証のように語ってしまう。分けて書けば、そのまま確認票の回答になる。

DB を移設した結果、保管地が東京からシンガポールに変わった。以前の資料に「データは国外に出ない」と書いていたなら、その記述は現在は事実ではない。訂正するかどうかは経営判断だが、放置すると「意図的に古い説明を残していた」という最悪の形になる。

移設のきっかけは、前の DB が認証方式の失効で到達不能になり、しかも通常のダンプが取れない設計だったため、データを退避できなかったことである。バックアップ以前に、そのDBは標準的な方法でデータを取り出せるかを選定時に確認する。これはセキュリティの話に見えないが、可用性と事業継続の話であり、確認票では必ず聞かれる。

ここまでは全部コードの話である。しかし健康情報のようなセンシティブなデータを扱うとき、確認票で最初に聞かれるのはコードではなくアカウントの話である。AI レビューを何本入れても、この欄は1行も埋まらない。

外形チェックで分かるのはレスポンスヘッダーだけである。この記事の冒頭で挙げた「認証不要で全社分の個人データが読めた」という穴は、外形チェックでは1件も検出できない。検出するには、実際にアカウントを分けて叩くしかない。

これは運用上いちばん誤解されやすい点である。同じ差分を2回レビューさせても、同じ指摘が出るとは限らない。だから「AI レビューが通った」を「その差分は検査済み」と記録してはいけない。

記録に書けるのは「AI レビューを実行し、出た指摘に対応した」までである。「AI が見たので問題ない」と書いた瞬間に、その記録は検証に耐えなくなる。機械的なルールベースの検査（gitleaks・依存チェック・自作の認可検査）だけが、再現性のある「通った」を持つ。

この3つをまぜて1本の履歴にすると、どの質問にも部分的にしか答えられない記録になる。分けて書けば、聞かれた種類の列をそのまま出せる。

v1 を本番へ公開したあと、役割を分けた2つの AI にレビューさせた。同じ観点で2回見ても意味がないので、片方には審査する側の役を与えた。

Codex の指摘1は、事故報告書・アクセスログ・影響評価・本人への通知判断までを記事に書くよう求めていた。ここは部分採用にした。この記事は運用手順であって事故報告書ではないため、個別の事案の詳細は載せない。代わりに「この種の事故を記事や資料に書くなら、いつ塞いだか・どう再発を止めたか・影響をどう確認したかの3点をセットにしないと逆効果になる」という一般則として書き直した。

そして、その3点目が自分たちには書けなかったという事実を隠さずに残した。指摘に従って書けないことが分かったなら、書けないことを書くのが正しい。