ブログがSNSでバズった時に備える基礎知識【アクセス集中対策】
⚪ この記事について
このブログでは、実際に導入・契約していないサービスについて書いた記事に「調査ベース」のバッジを付けています。この記事もそのひとつで、公式情報をもとに整理した比較です。 バッジの説明を見る →
まだ経験したことはありませんが、ブログを続けていく以上「もしSNSでバズったら」という状況は一度は想定しておきたいものです。この記事では、個人ブログ運営者として知っておきたいアクセス集中対策の基礎知識を整理します。
💭 調べてみて感じたこと
正直、今のアクセス数からすると「バズる」のはまだ先の話に感じます。ただ調べてみると、Next.js+Vercelという構成自体が、実はこの手のアクセス集中にもともと強い作り方だと分かって少し安心しました。備えていなくても最低限の耐性はあるけれど、知っておけばより安心、というくらいの温度感で整理しておきます。
Next.js/Vercel構成がアクセス集中に強い理由
このブログの記事ページは静的生成(SSG)されているため、アクセスが増えても都度サーバー側で重い処理が走るわけではありません。あらかじめ生成されたHTMLがCDN経由で配信される仕組みのため、従来型のレンタルサーバーでWordPressを動かす場合と比べて、アクセス集中に強い構成になっています。詳しくはNext.js高速化Tipsの記事でも触れています。
ISR(Incremental Static Regeneration)のキャッシュ挙動を理解しておく
このブログはrevalidate = 3600(1時間)のISRを使っています。アクセス集中対策として理解しておきたいのは、ISRが「1時間経ったら即座に再生成される」わけではないという点です。実際の挙動は次の通りです。
- キャッシュされたページは、
revalidateの秒数が経過するまでそのまま配信され続ける - 経過後、最初にそのページへアクセスしたリクエストが来た時点で、古いキャッシュをそのまま返しつつ、裏側で新しいバージョンの生成を開始する(stale-while-revalidate)
- 生成が完了すると、次回以降のリクエストから新しいバージョンに切り替わる
つまり、バズって一時的にアクセスが急増している間は、キャッシュが有効な限り同じ静的HTMLが配信され続けるだけなので、アクセス数が増えたからといってサーバー側の処理負荷が比例して増えるわけではありません。むしろrevalidateの秒数を短くしすぎると、その分オリジンでの再生成が頻繁に走ることになるため、アクセス集中が予想される記事ほどrevalidateは長め、あるいは後述のオンデマンド再検証と組み合わせる方が安定します。
オンデマンド再検証(On-Demand Revalidation)という選択肢
Next.jsには、revalidateの秒数を待たずに、任意のタイミングでキャッシュを明示的に再生成させるrevalidatePath/revalidateTagというAPIも用意されています。このブログでは今のところ使っていませんが、「記事を修正したら即座に反映したい」「バズった直後にアクセス数の表示を最新化したい」といった要件が出てきた場合の選択肢として押さえておく価値があります。ただし、これを外部から呼び出せるAPI Routeとして公開する場合は、誰でも叩けてしまわないよう認証(シークレットトークンの検証など)を必ず組み込む必要があります。
それでも確認しておきたいこと
- Vercelの利用プランの上限: 無料プランの記事でも触れた通り、無料プランには帯域幅などの上限があります。急激なアクセス増加時にどうなるか、事前にVercelのドキュメントで確認しておくと安心です
- 画像・外部リソースの重さ: 記事内に重い画像や外部埋め込みが多いと、アクセス集中時の表示速度に影響します。このブログのようにSVGの軽量なアイキャッチにしておくと、この点でも有利です
- コメント欄・問い合わせフォームの負荷: 問い合わせフォームの記事で紹介したような外部サービスに任せている場合、その外部サービス側の対応力にも影響されます
- セキュリティ面の基本対策も合わせて確認する: アクセス集中時は問い合わせフォームのスパムなども増えやすいため、個人ブログのセキュリティ対策の基本もあわせて確認しておくと安心です
バズった後にやっておきたいこと
- アクセス解析で流入元を確認する: どのSNS・どの投稿がきっかけになったかを把握しておくと、次に活かせます
- 関連記事への導線を強化する: せっかく増えた訪問者に、他の記事も読んでもらえるよう内部リンクを意識します
- 一時的な話題性に頼らない記事を並行して育てる: バズは一過性であることが多いため、検索流入のような継続的な流入源も並行して育てておくのが安心です
よくある質問
Q. 無料プランのままでもバズに耐えられますか? A. ある程度は耐えられる設計ですが、上限に達する可能性はあります。心配な場合は、有料プランへの切り替えをあらかじめ検討しておくと安心です。
Q. バズった記事はその後も検索流入が続きますか? A. 記事の内容次第です。話題性だけでなく、検索されやすいキーワードを含んだ実用的な内容であれば、バズ後も継続的な流入が期待できます。
Q. サーバーがダウンしたらどうすればいいですか? A. Vercelのステータスページやダッシュボードで状況を確認し、必要であればサポートに問い合わせるのが基本の対応です。
Q. revalidateの時間を短くすればアクセスが増えたときに困りますか?
A. むしろ逆で、ISRはrevalidateの秒数を過ぎた後の最初のリクエストが来るまでは古いキャッシュを配信し続ける(stale-while-revalidate)ため、アクセスが急増している間はキャッシュがそのまま使われやすくなります。revalidateを短くするとオリジンでの再生成回数が増えるため、バズ対策としてはむしろ長めに保つ方が無難です。
まとめ
Next.js/Vercelという構成自体が、もともとアクセス集中にある程度強い作りになっています。今はまだ起きていない話ですが、仕組みを理解しておくことで、いざという時に落ち着いて対応できると思います。