静的化の結果がおかしいときは...

名称変更について

2025年3月に espar から espar vault (エスパーボルト)へ名称が変更されました。サービスの機能・仕様・価格に変更はありません。詳しくはこちらをご覧下さい。

静的化したページの表示や動作が期待通りでない場合、その原因は espar vault ではなくCMS側に起因していることが多くございます。主に以下の2パターンです。

(1) CMS側の表示が正しくない(アプリケーション層)
(2) CMS側の応答が正しくない(HTTP層)

以下に詳細を示します。静的化の結果以外のトラブルは困ったときは…をご覧下さい。

(1) CMS側の表示が正しくない

(1)-1. CMS側の確認

静的化の結果に問題を感じる場合、まず最初にCMS側を確認して下さい。確認の際は「espar vault がそもそも存在しないとして、CMS単体で正しく機能しているのか？」という視点で確認して下さい。そもそも。CMS側で正しくないことが多いためです。espar vaultはその正しくない状態を忠実に再現します。

CMS単体で正しい状態を確保した後に改めてespar vaultで静的化を実施して下さい。導入時に、テスト環境と本番環境の2系統をご案内していますので、まずはテスト環境でご確認ください。本番環境を使って確認することもできますが、推奨はしていません。

CMS側の改修を行ってもおかしな表示が改善されない場合、つまりCMS上は正しいのにespar vaultで静的化した結果だけがおかしい場合、(1)-2. 反映結果の確認に進んでください。

(1)-2. 静的化結果の漏れの確認

CMS側単体で正常である確認がとれたら、次に静的化した結果に対して「ページに必要なものは全て揃っているか？」の視点で確認します。

espar vault の静的化エンジンは、ページに必要なもの(css/js/画像…等)を自動検出して全て取り込みます。しかし、自動検出ができない実装になっている場合、明示的に指定して手動で取り込む必要があります。自動検出されない例は以下をご覧下さい。

自動検出できていないものは、Developer Tools から確認することができます。Developer Tools の [Network] タブを開き Status が200系や300系以外のファイルやパスを探して下さい。

faq_10_developertools

心当たりがある場合、それらが静的化の際に自動検出されていない可能性が高いです。裏付けを得るため、指定パスの静的化で明示的な静的化を手動で行ってから再確認して下さい。

(1)-3 正しく表示された場合

指定パスの静的化は一時的な対応でしかありません。指定パスの静的化で取り込まれたものは、サイト全体の静的化で削除されてしまいますので、以下2つのいずれかで対応することが推奨されます。

(a) 制作の留意点についてページを参考に、静的化エンジンが自動で取り込める実装にする
(b) 追加取得パスに追加して、静的化エンジンが追加で取り込んでくれるようにする

対応を完了したら、サイト全体の静的化を行なっても正しく表示されることを確認して下さい。

(1)-4 正しく表示されない場合

詳細な調査が必要となります。弊社担当者に状況をお知らせ下さい。なお、状況をお知らせ頂く場合は以下の情報を必ずご提供ください。

CMS側で正しく表示されている様子がわかるブラウザ画面キャプチャ(URLが認識できる状態)
espar vault 公開サーバ側でおかしく表示されている様子が分かるブラウザ画面キャプチャ(URLが認識できる状態)
上記2つの画面キャプチャの差異について何がおかしいかが分かるコメント

1-3の情報がない場合は調査ができませんのでご協力をお願いします。まれに「表示がおかしいです。確認して下さい」というご連絡のみ、または上記の1,3のみをお送り頂き2が不足している例がございます。その場合、調査ができませんので、必ず1-3を揃えてお問い合わせ下さい。

弊社はCMS側の制作には関与致しませんので、「どのように表示されるのが正しいのか」を適切に判断することができません。したがって、弊社が調査を開始するためには以下が必要です。

正常情報 : 何が正しいのか
異常情報 : 何が間違っているのか

両方が必要となります。例外はありません。調査を開始するには、弊社側で「正しい状態と誤った状態の差分の認知」がまず必要になることをご理解下さい。

これは espar vault に限った話ではありません。もし制作担当者の方であれば、以下のようなシチュエーションで、エンドユーザ様の課題を迅速に解決するには何が必要であるかを考えてみて頂くと良いでしょう。

エンドユーザ様から、「プレスリリースページの内容がおかしいです。確認して下さい。よろしくお願いします」とだけ連絡を受ける
エンドユーザ様からは、正しいとされる原稿や見え方の情報は提供されない

この例で、迅速な解決に必要なものは以下2点である筈です。

どのように修正すべきかの文言や見え方のイメージ情報(正常情報)
おかしいとされる箇所の指摘や何がおかしいのかの説明(異常情報)

正誤の差分を認知できてこそ課題の解決が図れます。調査を依頼頂く場合も同様です。正常情報・異常情報をセットで提供頂けない場合は、調査の開始にも必要以上の時間を要することがございます。迅速な課題解決のために、ご協力の程をお願い致します。

(2) CMS側の応答が正しくない

CMS側の表示が正しいように見えても、CMS側が正しく応答しないことが時々あるという観測しにくい状況に陥っている場合があります。この状態と静的化のタイミングと重なった場合、ページが欠損したり画像の漏れが発生したり、再び静的化したら直ったり…と不安定な振る舞いになります。

主な原因は以下の通りです。

HTTPサーバの設定を誤っている
キャッシュプラグインやCDN等、静的化と相性の悪い機構を併用している
セキュリティプラグインやWAF等、静的化と相性の悪い機構を併用している

静的化が不安定な場合(正しく反映される時とそうでない時がある)は、後述の技術仕様を確認の上、CMS側を調査し適切な対応を行なってください。

CMS側の応答要件と epsar vault の挙動

CMSが動作するサーバは、必ずHTTPサーバプログラム(Apache/NGiNX等)が動作しています。

espar vault の静的化エンジンは、CMS側に都度「このページのHTMLをください」とHTTPリクエストを送ります。その応答を解釈して、HTMLファイル化や画像/css 等の保存を行います。これが静的化(ファイル化)です。そのため、CMS側は常に安定した正しい応答を返す必要があります。

安定した正しい応答とは、以下2点を常に満たす状態をいいます。

HTMLレスポンスヘッダのステータスコードが200(または200番台)であること
HTTPレスポンスボディのサイズが0バイトではないこと

正しく設定されたHTTPサーバは、常に1と2の両方を満たします。例えば、本マニュアルのトップページ https://doc.espar.biz/vault/ は、1.のステータスコードは200で、2.のサイズは数キロバイトとなります。以下に developer tools での表示を示します。

faq_10_httpstatus_normal_marked

curl コマンドでは以下のようになります。

% curl -I 'https://doc.espar.biz/vault/'
HTTP/2 200
date: Sat, 01 Aug 2026 01:54:50 GMT
content-type: text/html; charset=UTF-8
content-length: 37566
last-modified: Mon, 01 Jun 2026 04:20:36 GMT
vary: Accept-Encoding
etag: "6a1d0894-92be"
strict-transport-security: max-age=15768000
accept-ranges: bytes

ステータスコードは HTTP/2 200 で200であり、サイズは content-length: 37566 となっていることが分かります。(curl でのサイズ表示が developer tools でのサイズが違うように見えるのは、gzip 圧縮の差異に起因。curl で —compressed を指定することで一致する)

このように、

HTMLレスポンスヘッダのステータスコードが200(または200番台)であること
HTTPレスポンスボディのサイズが0バイトではないこと

の2つを満たすことが、CMS側には常に求められます。

静的化の結果に「あるときは正しくて別のときにはおかしい」という不安定さが見られる場合、CMS側が上記2つの要件を満たせていない可能性が高いです。この場合、以下のような現象が不規則に発生します。

現象	原因
画像や動画が欠損する	画像や動画のファイル保存漏れ
レイアウトが崩れる	cssの保存漏れ
意図した動作にならない	JavaScriptの保存漏れ
ページが存在しない	HTML化の漏れ

静的化結果がおかしいと認知した箇所以外でも、様々なものが欠損している可能性があります。原因は、CMS側の応答が要件を満たさないことにあります。

応答要件を満たさない時の espar vault の挙動

1. ステータスコードが200番台以外になってしまっている

CMS側のHTTPレスポンスヘッダのステータスコードが200でない場合、espar vault の静的化エンジンは、HTTPプロトコルの仕様に従って以下のように挙動します。

コード	挙動
301,302	リダイレクト先に指定されたURLにアクセスし直します
404	存在しないものとみなします。ページであれば当該URLのページは静的化されず、画像/css等であればファイルを取り込みません
500番台	CMS側で不具合が発生しているとみなします。一定回数以上にわたり連続した場合、静的化処理そのものを中断します

CMS側は常に HTTPプロトコルに従って振る舞う必要があります。

存在するページやリソースへのアクセスには必ずステータスコード200で応答し、それ以外のステータスコードで応答してはなりません。HTTPプロトコル的にチグハグな応答は、期待通りに静的化されない現象を生む要因になります。

以下はその例です。

(例1) ページや画像が存在するのに、HTTPレスポンスコードを400で返す
(例2) 静的化対象としたいページのレスポンスコードを301で返す

この例では、200応答するようCMSやHTTPサーバの設定等を調整する必要があります。

2. レスポンスボディのサイズが0になってしまっている

CMS側のHTTPレスポンスボディは、常に0バイト以外でなければなりません。従って、以下のような組み合わせのレスポンスでは、期待通りに静的化されません。


HTTPレスポンスヘッダのステータスコード	200
HTTPレスポンスボディのボディサイズ	0 byte

アクセスしたCMS側のURLがこの組み合わせで応答する場合、espar vault の静的化エンジンは対象を静的化しません。URLがページならHTML化せず、画像やcssであればファイルとして保存しません。その結果、ページや画像等が欠損することになります。もし仮に、サイト内リンクを多数含むページがこの状態になった場合には、リンク先も巻き込まれて全て欠損しますのでご留意下さい。

当該事象は、CMS側の振る舞い通りの結果です。正常だが(200)中身は何もない(0byte)とCMS自身が応答しているのを受け、それに従って何も保存しない、結果として欠損するというわけです。

CMS側が応答要件を満たしているかを調べる方法

静的化結果が不安定な場合、CMS側が応答要件を常に満たしているか調べることが有用です。まず、HTTPサーバ(ApacheやNGiNX等)のログファイルから、以下のアクセスログを抽出してください。

静的化の結果がおかしいと思われるパスへのアクセス
UserAgent 文字列に espar を含む

抽出したログから、全てのアクセスについて

日時
ステータスコード
ボディサイズ

を抽出し、ステータスコードが200以外だったり、ボディサイズが0になっているアクセスが存在したかどうかを確認します。

存在しない場合

espar vault の静的化エンジンや公開サーバに問題がある可能性があります。担当者に状況をお知らせください。

存在する場合

存在する場合、日時を確認します。「静的化がおかしい」と認知した日時周辺なら、問題の原因は、CMS側がHTTPプロトコルとして正しい応答をしていなかった瞬間に、espar vault の静的化エンジンがアクセスしたことが原因である、と断定できます。

解決策は以下の三択です。

(A) CMS側を調査し、常に正しく応答するよう調整する
(B) 再び静的化を試みる
(C) オプションのリンク切れしたページや画像等を削除しないをONにする運用に切り替える

原則的に、(A)が推奨されます。静的化と相性が悪いCDNやWAF、キャッシュやセキュリティ関連のプラグイン等を外すところからお試しください。(静的化サイトにおける導入意義は低いです)

(B)の場合、運悪く再び同じ状況が発生する可能性があります。再び発生した場合は解消するまで(B)を続けてください。

(C)の場合、リンク切れしたページや画像等を削除しないの説明をご覧頂き、今後削除したいページが公開され続けるリスクがある前提で運用フローを検討してください。