Jamstackのセキュリティ — 静的サイトで減るリスク・残るリスク

「WordPressの保守で、毎月の更新確認に時間を取られている」。制作会社の保守担当から、よく聞く話です。プラグインが増えるほど、更新と動作確認の手間は積み上がります。

負担の減らし方には、WordPressの運用を整える方法と、構成そのものを変える方法の2通りがあり、後者の代表がJamstack（静的サイト）です。ただし「静的だから絶対安全」ではありませんし、失うものもあります。この記事では、静的サイトで減るリスクと残るリスク、WordPressのままで取れる対策を、実装者の視点で並べます。

静的サイトで攻撃対象が減る理由

WordPressは、閲覧のたびにサーバーでPHPが動き、データベースから記事を組み立ててHTMLを返します。データベース、PHPの実行環境、プラグイン、テーマ、管理画面と、動く部分が多いぶん、守る範囲も広くなります。

静的サイト（Jamstack）は、仕組みが異なります。ページはあらかじめHTMLとして書き出しておき、配信時はそのファイルを返すだけで、閲覧のたびにサーバーでコードが動くわけではなく、データベースへの接続も発生しません。攻撃対象領域が減るのは、この構造から来ています。

WordPressの改ざん被害でよく見られる経路は、更新が遅れたプラグインの既知の脆弱性、弱い管理者パスワード、非公式な配布元から入れたテーマです。静的サイトは、プラグインや管理画面を公開側に置かない構成が多く、これらの経路の多くが最初から閉じています。

WordPressのままで取れる対策

構成を変えなくても、同じ経路の多くは運用で塞げます。保守の体制が回っているなら、まずここから。

• 自動更新を有効にして、本体・プラグイン・テーマの更新漏れを減らす
• 使っていないプラグインとテーマは削除し、入れるものは公式ディレクトリから選ぶ
• 管理画面のログインを2段階認証にし、できればIPアドレスで制限する
• WAF（不正な通信を止める仕組み）を、サーバー会社やCloudflareで有効にする
• ステージング環境で更新を試してから、本番へ反映する

全体の手順は、WordPress公式のセキュリティを固めるガイドにまとまっています。サーバーの管理や更新まで任せられる、マネージドWordPressのホスティングを選ぶ方法もあります。

静的でも残るリスクと、その対策

とはいえ、静的にすればリスクがゼロになるわけではありません。攻撃の面が別の場所に移るだけ、と考えるのが正確です。ここは正直に書きます。

• クライアント側のJavaScript：ブラウザで動く処理は、誰でも開発者ツールで中身を読めるので、ここに秘密の値やロジックを埋め込まない、が原則です。
• 公開リポジトリのAPIキー流出：ソースコードをGitHubなどで公開する場合、鍵をコードに直書きすると危険です。公開リポジトリの秘密情報は自動化されたスキャンにすぐ拾われるとされており、鍵はコードから分離して環境変数などで管理します。
• フォーム送信API：問い合わせフォームの送信先や、外部サービスの鍵は、ブラウザ側に置けば丸見えなので、ここは後述のとおりサーバー側に隠します。
• 依存パッケージの脆弱性：ビルドに使うライブラリに脆弱性が見つかることはあり、定期的な更新で塞ぐ運用は、静的サイトでも必要です。

鍵はブラウザに出さない

「フォームの送信先APIをどう守るか」は、静的サイトで必ず出てくる論点で、静的ページ自体にサーバー処理はありませんが、送信の受け口だけは動く部分が要ります。

原則は、送信を受け取る小さなサーバー（Cloudflare Workersなど）を挟み、メール送信や通知に使う鍵はそちらの環境変数（シークレット）に置いて、ブラウザには渡さないことです。閲覧者に見えるのは「受け口に送る」ところまでで、その先の鍵は隠れたままです。

// Worker側（擬似コード）：鍵はここにあり、ブラウザには出さない
export default {
  async fetch(request, env) {
    const data = await request.json();
    // env.MAIL_API_KEY はブラウザから見えない
    await sendMail(data, env.MAIL_API_KEY);
    return new Response("ok");
  },
};

tsudzuri.com でも、以前はこの形でフォームを自作し、入力欄を装った罠（ハニーポット）と送信までの時間の確認で、機械的な連投をはじいていました。いまは自社で作っている業務ツールPipeliaのフォームを埋め込み、送信とbot対策をそちらに任せていますが、自作か既製かを問わず、鍵がブラウザに出ていないかは確かめておきたい点です。

静的サイトで失うものと、向くサイト

静的サイトにすると守る範囲は狭くなります。失うものもあります。

• 記事を書き換えるたびに、ページを書き出し直す手間がかかる。管理画面から更新するには、ヘッドレスCMS（管理画面だけのCMS）を組み合わせる
• WordPressのようにプラグインを入れて機能を足すことはできず、機能は開発で作る
• 会員機能や予約のように、見る人ごとに中身が変わる処理は苦手

EmDashは静的サイトではない

このサイトが使っているEmDashは、Cloudflare Workersの上でページを組み立てて返す、動的なCMSです。管理画面もデータベースもあるので、静的サイトのように「動く部分がない」わけではありませんが、PHPを使わないことや、プラグインを隔離して動かせることなど、別の仕組みで守る範囲を絞っています。違いはEmDashのサイトがPHP脆弱性の対象外である理由を書いた記事にまとめました。

更新が少なければ静的、頻繁ならCMS、会員・ECならWordPress

内容の更新が少なく、動的な処理が要らないサイトなら、静的サイトは有力です。管理画面から頻繁に更新したいならEmDashのようなCMSを、会員・ECなどプラグインが要の機能ならWordPressを選びます。更新の体制が回っているなら、WordPressのまま上の対策を回すのが、いちばん手堅い選び方です。続けるか移るかはWordPressを続けるか移るかの判断軸をまとめた記事で整理しています。

「うちのサイトはどの構成が合うか」「今の保守で足りているか」を、現状を見ながら一緒に整理します。WordPressのまま対策を整える案も含めてご提案できるので、お問い合わせからご相談ください。

本記事は2026年10月時点の情報です。各サービスの仕様やセキュリティの前提は変わることがあります。