「Vercel自体が危険」
営業的な単純化Vercelはプラットフォーム全体でDDoS対策やFirewallを提供しています。危険なのはVercelを使うことではなく、公開したアプリの認証・入力検証・権限設定を決めないことです。Vercel自身も、アプリ・ユーザーアクセス・環境変数の管理は顧客側の責任だと説明しています。
営業トークを、事実と条件に分ける
提示された説明には、正しい注意喚起と、サービス契約へ誘導しやすい言い切りが混ざっています。分けて読むと、必要な対策が見えてきます。
「URLを誰も知らないから大丈夫」
誤りインターネットに公開された時点で、発見・スキャンされる前提に変わります。CISAも、公開状態の資産や古いソフトウェア、初期パスワードなどが攻撃対象になりやすいとして、外部から見える資産の棚卸しを勧めています。秘密のURLは、認証ではありません。
「APIキーをクライアント側に置くと抜かれる」
事実ブラウザへ送った値は、利用者が開発者ツールで読めます。Next.jsでは NEXT_PUBLIC_ で始まる環境変数がブラウザ用JavaScriptへ埋め込まれます。公開してよい識別子もありますが、LLM・決済・データベースの秘密鍵を同じ場所へ置いてはいけません。「環境変数にした」だけでは十分ではありません。
「認証・利用制限がないAPIは、高額請求につながる」
条件付きで事実誰でも呼べるAPIが毎回有料のLLMを呼ぶなら、第三者の連続利用やバグによって料金が増える可能性があります。OWASPも、APIには回数・入力サイズ・処理量の制限と、外部サービスの支出上限を設けるよう勧めています。VercelのWAFにもレート制限はありますが、プロジェクト側で設定して初めて働く対策です。
「ライブラリは常に最新にしないと危険」
方向は正しいが言い過ぎ古い・サポート切れ・脆弱性のある依存関係を放置するのは危険です。OWASPは、使用中のバージョンを把握し、脆弱性情報を監視し、リスクに応じて更新する継続的な運用を求めています。ただし「最新なら無条件に安全」ではありません。更新前後の動作確認と、戻せる手順も必要です。
「企業のSaaSは保守しているから安心」
半分は事実、半分は営業企業SaaSは通常、基盤の更新・監視・障害対応を運用します。しかし、契約だけで自作アプリの認証やデータの扱いまで安全になるわけではありません。「誰が、どの範囲を、何時間以内に直すのか」を確認せず、保守という言葉だけで判断しないことが大切です。
Vercelが守るもの、守らないもの
クラウドでは、サービス提供者と利用者が分担して守ります。ここを一つの「安全／危険」にまとめると、見落としが起きます。
Vercelの基盤
DDoS緩和、ネットワーク、実行基盤、プラットフォームのアップデートなど。
設定で使う保護
Deployment Protection、Firewallのルール、レート制限、支出アラートなど。設定しない機能は効きません。
作り手のアプリ
ログイン、ユーザーごとの権限、入力検証、データベースの公開範囲、APIの処理量。
運用の仕事
秘密鍵のローテーション、依存関係の更新、ログ確認、障害時の停止・復旧、担当者の引き継ぎ。
社内向けの意味
「社内向け」は、社員だけが見られるように認証と権限を設計した状態です。会社名を画面に書くこと、URLを共有しないこと、検索に出ないようにすることは、アクセス制御の代わりになりません。
Vercel公式のShared Responsibility Model ↗では、アプリ、環境変数、アクセス管理、悪意あるトラフィックに伴うコスト、支出管理を顧客側の責任として整理しています。
公開前に確認する最低ライン
全部を完璧にする必要はありません。ただし、次の項目を「誰が確認したか」まで決められないなら、公開はまだ早い状態です。
- 01公開範囲を一文で書く例：「○○部の社員だけが、テストデータを閲覧する」。不特定多数が使う必要がなければ、公開URLではなく認証付きの入口を選びます。
- 02ログイン後も、毎回権限を確認する画面を隠すだけでなく、APIやデータ取得側でもユーザーと権限を確認します。ログインしている人なら全員が全データを読める状態にしません。
- 03秘密はサーバー側だけで使うLLM・データベース・決済の鍵をブラウザやGitへ出しません。Next.jsなら
NEXT_PUBLIC_は公開値専用。漏えいした鍵は削除・再発行します。 - 04APIに上限を置くユーザーごとの回数、入力文字数・ファイルサイズ、同時実行数、1日あたりの予算を決めます。VercelのFirewallや利用サービス側の上限も組み合わせます。
- 05依存関係の持ち主を決める使っているフレームワークとライブラリの一覧、更新を知らせる場所、緊急時の判断者、更新後の動作確認方法を残します。無条件に最新版へ上げるのではなく、脆弱性の深刻度で優先します。
- 06ログ・停止・復旧を一度試す失敗したリクエストを見つけられるか、APIを止める方法があるか、前のデプロイへ戻せるかを、公開前にテストします。ログへ秘密情報や個人情報を記録しません。
- 07実データなしで最初の公開をするまずは架空データで動作と権限を確認し、社内の責任者が「このデータをこの人たちへ見せてよい」と確認してから本番データをつなぎます。
Vercelの保護機能にも範囲があります
Deployment Protectionは、設定した保護範囲にだけ効きます。Vercelの公式説明では、HobbyプランのStandard ProtectionはプレビューやデプロイURLを保護しますが、本番ドメインは公開のままです。本番まで閉じる設定やプラン条件は、公開前に公式ドキュメントで確認してください。
公開を止める判断も用意する
「作れる」ことと「公開してよい」ことは別です。次のどれに当たるかを、作った本人だけでなくデータの持ち主と決めます。
公開してよい可能性がある
公開して問題のないデータだけを扱い、認証・入力制限・ログ・依存関係の更新担当が決まっている。料金上限も確認済み。
条件を足してから公開する
社内限定なのに認証がない、LLMを呼ぶのに回数制限がない、プレビューURLが誰でも開けるなど、対策が一つ欠けている。
いったん公開しない
個人情報・顧客情報・機密資料を扱うのに権限設計がない、漏れた秘密を無効化できない、停止・復旧の担当者がいない。
Claude Codeへ最初に渡す指示の例
このアプリを公開する前に、次を調べて表にしてください。
1. 公開されるページとAPIの一覧
2. ログイン・ユーザーごとの権限チェックの場所
3. ブラウザへ送られる環境変数と、秘密情報の候補
4. 回数・入力サイズ・同時実行数・外部API料金の上限
5. 依存関係のバージョンと、既知の脆弱性を確認する方法
6. ログに個人情報や秘密が残らないか
7. 停止・再デプロイ・前の版へ戻す手順
不足があればコードを変更せず、先にリスクと確認事項を説明してください。AIは公開の責任者ではありません
Claude Codeはコードの候補を作れますが、「この社員にこのデータを見せてよいか」「月いくらまで使ってよいか」「事故時に誰が止めるか」は決めません。そこを人が決めて初めて、社内向けアプリになります。