🛡️ 月20ドルで、セキュリティはどこまでできるか — 第三の会社とAIと自分の3者で自動運用する

前作（/wiki/vercel-ai-ops-2026）で、開発から本番監視までを8段階に分けた。その続きとして、今回は2つの問いに答える。

① 月20ドルのVercel Proだけで、セキュリティは全部できるのか。② 客観的な第三者による、AIでのセキュリティチェックと報告書は、どう作るのか。

顧客が1万人になると、報告書の作り方そのものが変わる。顧客ごとにチェックシートへ手で回答していたら破綻する。回答の版がずれ、証跡が期限切れになり、他社向けの情報を誤って送る。

答えは、トラストセンターを1本作って、全顧客をそこへ向けることである。週次で検査を回し、そのページが自動で更新される形にする。実在例は Vercel 自身の security.vercel.com である。

「$20で足りるか」を判定するには、先に理想の姿を決めておく必要がある。理想が無いまま機能一覧を見ても、多いのか少ないのか判断できない。

ここでは、既に公開されている3つの物差しから理想を借りてくる。そのうえで、この記事だけの「理想10項目」を定義し、どこまでを誰が埋めるかを先に固定する。第3章以降は、すべてこの10項目に対する進捗として読める。

この記事の背骨は1文で言える。AIは「第三者」にはなれない。作れるのは「客観性」——誰が何度やっても同じ結果に到達できることだけである。第三者性とは、実施者が依頼者から独立し、利害関係と責任を持つという立場の性質だ。AIには利害も契約責任も無い。依頼者が選び、入力・範囲・採否を依頼者側が支配する補助者にすぎない。

だから設計はこうなる。第三者性は外の会社から買う。客観性は自分で作る。AIはその間の作業――読む・要約する・PRを出す――をする。下の表は、それを守る項目ごとに割った分担である。

Vercel Pro（$20）が守るのは、Vercelのエッジで止められる公開面の攻撃までである。テナント分離・認可・Neon側の守り・監査・人の対応・従量課金はこの$20には含まれない。買えないのは、止めたあとの統制と可視性にあたる4系統である。1つずつ、代わりになるものがあるかを確定する。

章題は「買えない6つ」としたが、正確に数えると4系統・8項目である（Passport・SCIM・Trusted IPs・Audit Logs・Secure Compute・レート制限の高度化・専任DDoS支援・Private Production）。

Trusted IPsの代わりは、Deployment Protection層ではなくWAFのカスタムルールで作る。「指定IP以外をdeny」というルールを1本追加すれば近い効果は出せるが、これは公式のTrusted IPs機能そのものではない。本番デプロイの入口を守る仕組みが2層（WAFとDeployment Protection）のうち片方にしか無い、という限界を残したままの代替である。

「第三者」という言葉には、公的な定義がある。経済産業省「情報セキュリティ監査基準（令和7年改正版）」は、独立性を外観上の独立性と精神上の独立性の2要素で定義している。要約すると、監査対象と身分上・経済上の利害関係を持たず、偏向を排して公正に判断すること、である。

報告書で「第三者性」とひとくくりにしている手段も、実は独立性の水準が揃っていない。3つに分けて扱う。

対照として、PCI DSSのASV（Approved Scanning Vendor）を見ると、独立性を要求する制度がどう作られているかが分かる。

下の8種のうち7種はドメインやURLを入力するだけで実行できる。残る1種（CSP Evaluator）はCSPヘッダーの文字列そのものを貼り付けて調べる、URL入力型ではないツールである。対象URL・実行時刻・ツールの版を固定して記録すれば、あなたが実行しても顧客が自分で実行しても同じ基準で再評価できる。

これらが「客観的」である理由は1つしかない。対象URL・実行時刻・ツールの版を固定して記録すれば、顧客自身が同じ基準で再評価できるからだ。あなたが「安全です」と主張しているのではなく、相手が自分の手で確かめられる手順になっている。ただし、外部ツールのデータ・判定規則・対象サイト自体は時点によって変わるため、常に「同じ結果」になるとは限らない。同じ基準で追試できることが客観性であって、結果の恒久的な一致を意味しない。これが第5章で分けた「客観性」の実体である。

前章の8種は「外部から見える形」を確かめる検査だった。ここからは自分で回す自動診断。週次で3本を回すが、束ね方は1本ずつ違う。SemgrepのSARIFだけをGitHub Code Scanningへ送る。ZAPとNucleiは個別形式（JSON/HTML、TXT）のまま、実行ログをArtifactとして保存して証跡にする。

SARIF（Static Analysis Results Interchange Format）は、静的解析ツールの出力を統一するための、OASISが策定した正式標準（現行バージョン2.1.0）。Semgrep・Trivy・OSV-Scanner・CodeQLなど多数のツールが対応しており、異なるツールの結果を1つの形式で束ねられる。GitHub Code Scanningへアップロードすれば、Securityタブに集約表示できる。ただしツールごとにルールIDや重大度の付け方が異なるため、複数ツールの結果を単純合算すると重複・粒度不一致が起きる点には注意する。

第7章で自分で回す無料ツール（ZAP・Nuclei・Semgrep）を組んだ。ここでは外部の会社に金を払って回してもらうものを整理する。外に出す検査は2種類に分かれる。判定列の予算はVercel Pro $20＋その他10万円くらいまで（第15章と同じ前提）とする。

PTaaS・バグバウンティは3種とも「料金は見積・報奨金次第で不明」という点で共通する。これは公式が価格を隠しているのではなく、スコープ（対象範囲）と期間で見積が変わる契約形態だからである。金額を知りたい段階になったら、テスト専用tenantとルール・オブ・エンゲージメントを用意したうえで営業窓口に相談する。

ここまでの検査結果・報告書・改ざん検知の証跡は、1件ずつ顧客へ渡していては1万人には配れない。顧客ごとにExcelやチェックシートへ手で回答する運用は、1万人という規模の前で必ず壊れる。回答の版ずれ（去年の回答のまま放置される）、期限切れ証跡の気づかない送付、個人情報の誤送信が起きる。だから正本を1本にし、そこから配る形に変える。

もう1つ、時間が壊す弱点がある。Artifactの保存期間、署名IDの失効、TSAの検証可能期間、テスト用アカウントの期限を保守し続けなければ、数年後にはこの束を追試できなくなる。署名・attestation・タイムスタンプは「今それが正しく存在した」ことしか証明しない。保守を止めた瞬間から、過去の証跡は少しずつ検証不能に近づいていく。

報告書の表題は「自社実施・再現可能なセキュリティ検証報告書」にする。第三者診断ではないと最初に書く。この章の章立ては、Codex（GPT-5.6）の叩き台をそのまま骨として使い、各章に何を書くかだけをここで固定する。

言ってよいことと言ってはいけないことの境目は、実施した事実の範囲を超えるかどうかである。範囲を超えた瞬間に、報告書は誇大表示になる。

主張だけを書いて根拠を省くと、報告書は宣言文になる。根拠だけを並べて確認者を書かないと、誰も責任を負っていない書類になる。3点をいつも同じ順番で並べる。「検出事項なし」は範囲と時点を書かないと、顧客には「脆弱性が無い」という主張として読まれる。対象範囲と実行時点で、Critical/Highの未解決検出事項は0件のように、範囲・時点・重大度を必ず添える。

運用者が1人の場合、実施者と承認者は同一人物になる。その場合は「実施者・承認者とも同一（本人）」と明記し、独立した第三者によるレビューは実施していないと書く。これを省略すると、独立したレビューがあるように読まれる。

第6章で挙げた、URLを渡せば誰でも追試できる無料検査8種は、この報告書の第7章「検査方法と再現手順」に付録として貼る。列はURL・コマンド、期待される結果、限界の3つに絞る。認証が必要な検査まで無制限に公開してはならない。

報告書は作った後に差し替えられたら意味がない。evidence-manifest.jsonを作るのはそのためである。コミットSHA・対象URL・検査時刻（JST/UTC）・ツールの版・全生ログのSHA-256を1枚に固定する。ただしmanifest単体は差し替えを防がない。成果物とmanifestは同時に差し替えられるからである。cosignの透明性ログやRFC 3161のタイムスタンプなど、外部にアンカーして初めて、後日の改変を検知しやすくなる。

GitHub Artifact Attestationsは、GitHub公式ドキュメントで「repository, organization, environment, commit SHA, and triggering event」を暗号学的に署名された形で証明する仕組みと説明されている。基盤はSigstoreで、パブリックリポジトリでの生成・検証はSigstore Public Good Instanceにより無料である。第三者はgh attestation verifyで検証できる。

ただし正本で確認できる検証対象はバイナリ・コンテナイメージ・SBOMまでである。PDFや報告書のZIP束を同じ仕組みでattest/verifyできるかどうかは未確認である。報告書PDFとmanifestの完全性は、cosignの署名かRFC 3161のタイムスタンプで扱う。

総務省は「時刻認証業務の認定に関する規程」に基づき、総務大臣による認定制度を整備している。総務省の説明では、タイムスタンプは「ある時刻にその電子データが存在していたことと、それ以降改ざんされていないことを証明する技術」とされている。総務大臣の認定を受けた時刻認証事業者は複数ある（一覧は折りたたみ）。

認定事業者を実地に調査・確認する「指定調査機関」は、一般財団法人日本データ通信協会（東京都豊島区）である。総務省の説明にある通り、認定ロゴマークは「品質を保証・担保するかのように用いるもの」としては使用できないと定められている。報告書に付ける場合は、認定制度に基づくものである旨を正確に書く。

署名を1回付けて終わりにすると、数年後に顧客が検証しようとしたときに、鍵は失効し、テストアカウントは消え、保存していたはずの生ログが残っていない、という状態になりやすい。証跡は作る作業と同じだけ、保守する担当と期限の一覧が要る。

この章の主タスクは、顧客へ渡す3点を決めることだ。①報告書（安全管理措置の実施状況を示す）②契約に盛り込む条項（委託元が把握できる内容）③継続的な把握の材料（定期的な検査結果）——この3点は、個人情報保護法25条のガイドラインが示す3つの観点に対応させると整理しやすい。ただし自社の提供が委託に該当するかの判断が先に必要で、②③はガイドライン上「望ましい」とされる措置にとどまる。根拠となる条文・制度の原文は下の各アコーディオンで確認できる。

1万人は、Vercelの席数ではない。顧客をVercel Teamへ招待しない限り、Proの$20/席・月は運用者1人分のままである。詰まるのは利用者数そのものではなく、①顧客別の境界制御 ②ピーク時のAPI/DB処理 ③証跡運用 ④従量費用の4系統だ。顧客組織数（社）と利用者数（人）は別の軸であることに注意して、以下の目安を読んでほしい。数値の一部はVercel/Neonの容量上限そのものではなく、負荷試験を始めるための試算例である。

合格基準の例: 各シナリオでp95応答時間が3秒以内、エラー率1%未満、Neon接続がプール上限に達しない。観測する指標: Vercelのファンクション実行時間・同時実行数・帯域使用量（Usage画面）、Neonのアクティブ接続数・CPU使用率・ストレージ（Neon Monitoring）。これらを毎月のPricing Calculator試算と突き合わせて更新する。

ここまでの13章で、$20で買えるものと、外の会社に頼るしかないものを分けてきた。この章はその境界線を、言ってよい言葉といけない言葉として固定する。AIは「第三者」にはなれない。作れるのは「客観性」——誰が何度やっても同じ結果に到達できることだけである。この一線を越えた瞬間、報告書全体の信頼性が崩れる。

自社のE2Eテストとコードレビューでも、IDORやRLS（行単位アクセス制御）の不備は検出できる。自社の試験は必須の前提であり、免除にはならない。外部への発注が必要になるのは、独立した保証が求められる場合・深い攻撃観点が要る場合・契約やRFPが第三者診断を要求する場合の3つに限る。

この章に書いたことはすべて「今はできない、または誰かに頼むしかない」という宣言である。できないことをできると言わないほうが、できることの価値が正確に伝わる。次の第15章では、ここまでの14章を実際に何週目・何ヶ月目にやるかへ落とし込む。

第1章から第14章までで、$20で買えるもの・買えないもの・外注するしかない線を確定させた。この最終章はそれをいつ・何からやるかに落とす。順番は検査の網羅性ではなく、依頼者が「今週から動ける」ことを優先している。

ここまでの「今月」はGitHub Actionsを前提にしている。しかし依頼者は「Vercel以外は考えない」と言っている。その前提を文字どおり適用すると、Actions・Artifact Attestations・cosignはすべて使えない。2つの経路に分けて書く。

問い④の予算は「Vercel Pro $20＋その他10万円くらいまで」である。ここまでの14章で並べた項目を、この予算の内か外かで仕分ける。年額に換算し、Vercel Proの年$240も合計に含める。

ここに並べる項目は条件を3つ満たす。①あなた自身で確認できる ②顧客側の技術者も同じ方法で追試できる ③費用が0円かごく安い。第6章の8種は外部サービスへURLを渡す検査、第7章は自前で回す自動診断だった。この章はその中間にある——技術者が画面を数秒見た瞬間に「ここは押さえてある」と当たりを付ける、具体的な確認先そのものを並べる。優先度の付け方は章末にまとめる。

残りはDNSとメール、認証、境界と供給。詳細は下の折りたたみに入れた。

あなたの言葉に戻る。「ISMS・Pマーク、また AWS はみんな聞くだけで安心している。そういうセキュリティが欲しい。20ドル、その他10万円くらいまでで」。ここまでの16章は自分で確認する項目と、外部に発注する検査を扱った。この最終章はそれとは別の軸——技術の中身より先に、名前だけで顧客が安心する記号を予算別に並べる。結論を先に言うと、一番効くのは新しく買うことではない。あなたが既に持っているISMSとPマークの見せ方を直すことである。

ここから予算を3段に分ける。0円で増やせる名前が最も数が多く、10万円以内で買える名前はSECURITY ACTIONの二つ星を要件にした助成金の入口くらいしかない。10万円では届かない名前もある。届かないものに手を伸ばさないことも、この章の答えのうちである。

ここがこの章で一番重要な節になる。制度の運営元が公式に「言ってはいけない言い方」を定めている。名前を持っているだけでは足りない。表現を一字一句間違えると、記号そのものが逆にリスクになる。

正しい表現が決まったら、次は置き場所である。第9章で作ったトラストセンターの公開層に、この章で確認した名前を1ページにまとめて置く。バラバラに問い合わせのたびに答えるのではなく、あなたが1人で運用していても顧客がいつでも同じ答えに辿り着けるようにする。

この記事は公開したあと、別系統のAIである Codex（GPT-5.6）に全文を読ませている。指摘だけ書け、同意できる点は書かなくてよいと指示した結果、28件が返ってきた。全部反映した。

直した内容より、どういう種類の間違いが混ざるかのほうが読者には役に立つと思うので、そのまま載せる。

この記事に高校生レビューが入っていないと、依頼者から指摘を受けた。入っていなかった。用語集もなかった。そこで別系統のAIである Codex に、次の人物設定で18章を読ませた。「高校生。プログラミングは授業で少し触った程度。そして文字が多すぎると内容を理解できず、読むのをやめてしまう」。

判定してもらったのは「理解できるか」ではない。最後まで読まれるかである。正しく書けていても、文字の壁があればその時点で離脱とみなした。