ConoHa WING の microcache 罠で開発デプロイが反映されない問題 — 一晩溶かした実体験と 3 つの解決策
個人開発者が共用ホスティングで頻繁に踏む microcache 罠の全貌
あなたが ConoHa WING で個人サイトや SaaS ダッシュボードを運用していて、「デプロイしたのにブラウザで変更が反映されない」「シークレットウィンドウでも古いまま」「.htaccess で no-cache 設定したのに効かない」という症状に遭遇しているなら、原因はほぼ確実に ConoHa WING の microcache (Nginx 上流キャッシュ) です。私は 2026 年 5 月に一晩溶かして気づいた経験を、原因究明プロセスと解決策込みで共有します。
本記事の結論を先出しすると、以下の3点です。
- ConoHa WING には「コンテンツキャッシュ」という Nginx microcache レイヤーがあり、URL ベースで HTML を 1 時間 (max-age=3600) キャッシュする。.htaccess の
Cache-Control: no-cacheは Nginx 上流に上書きされて効かない場合がある - 開発・更新頻度が高いサイトは 「コンテンツキャッシュ OFF」 に設定するのが最も確実、コンパネ → サイト管理 → 高速化 → キャッシュ から 1 分で切替可能
- 本番のままで運用するなら、デプロイ後に必ず「キャッシュクリア」ボタンを押す習慣と、CSS / JS への URL バスタクエリ
?v=mtimeの組み合わせが定石
以下、当夜の状況、原因究明プロセス、microcache のしくみ、3 つの解決策、他の類似罠を時系列で残します。
その夜の状況 — 何時間デプロイしても反映されない
2026 年 5 月 15 日の深夜、ai-pick.tech に CSS の微調整と著者名表記の修正をデプロイしました。FTPS で 5 ファイル更新、ブラウザでリロード、Ctrl+F5 でハードリロード、シークレットウィンドウで開き直し ── すべて古い表示のままでした。
最初は自分のデプロイミスを疑いました。FTPS 接続を再確認、リモートファイルのタイムスタンプを確認、別 PC でアクセス、別のネットワーク (スマホテザリング) からアクセス ── すべての環境で同じ古い表示。タイムスタンプは新しいのにブラウザには古いものが返り続けるという、明らかに「ブラウザ側ではなくサーバー側のキャッシュ」の症状でした。
結論にたどり着くまで 3 時間溶かしました。同じ罠に他の個人開発者が踏まないよう、原因究明プロセスを順番に共有します。
原因究明プロセス — 5 つの仮説と検証
「サーバー側のキャッシュ」と仮説を立てた後、原因の可能性を 5 つに絞って 1 つずつ検証しました。
| 仮説 | 検証方法 | 結果 |
|---|---|---|
| 1. FTPS で実は古いファイルがアップされている | FTPS で再ダウンロード → ローカル diff | ❌ 違う、リモートは新しいファイル |
| 2. CDN (Cloudflare 等) のキャッシュ | DNS 確認 → ConoHa の IP 直接アクセス、CDN なし | ❌ 違う、CDN は経由していない |
| 3. ブラウザキャッシュ | シークレットウィンドウ + Ctrl+F5 + 別 PC + 別ネットワーク | ❌ 違う、全環境で古い |
4. .htaccess の Cache-Control が効いていない | curl -I で HTTP ヘッダー直接確認 | ⚠️ Cache-Control: max-age=3600 が返る (設定したはずの no-cache ではない) |
| 5. ConoHa WING の Nginx microcache | 同じ URL + 違うクエリ ?nocache=1 でアクセス | ✅ 確定、クエリありだと最新が返る |
仮説 4 で「Cache-Control: max-age=3600 が返る」と判明した時点で、Nginx 上流のキャッシュ層が no-cache ヘッダーを上書きしていると確信しました。仮説 5 の検証 (同 URL + クエリで挙動が変わる) で確定。「サーバー設定上は no-cache、実際は max-age=3600 でキャッシュされる」という現象は、共用ホスティング系で頻繁に起きる罠です。
ConoHa WING の microcache のしくみ
ConoHa WING の管理画面では「コンテンツキャッシュ」という名前で機能が公開されていますが、技術的にはNginx の microcache (proxy_cache) レイヤーが動作しています。動作原理は以下です。
- 初回アクセス時、Nginx が WordPress / 静的 HTML / Apache のレスポンスを取得
- レスポンスを URL ベース (Query String 含む) で Nginx 内部にキャッシュ
- キャッシュ TTL は通常 1 時間 (max-age=3600)
- 同じ URL への次回以降のアクセスは、上流に問い合わせず Nginx 内部キャッシュから直接返す
- 1 時間経過 or 明示的にクリアされるまで、上流のファイル変更は反映されない
この設計自体は表示速度向上に強力で、トラフィックの多いサイトでは大きな効果があります。問題は「開発フェーズで頻繁にデプロイするサイトには向かない」点と、「.htaccess の Cache-Control が Nginx 上流に上書きされる場合がある」点です。Apache の HTTP ヘッダー出力は Nginx microcache の前段で処理されるため、レスポンスヘッダーには Nginx 側の max-age=3600 が乗ります。
検証方法 — 自分のサイトでも同じ罠か確認する
あなたのサイトが同じ罠にハマっているか確認するには、以下のコマンドを実行するのが最速です。
# 1. レスポンスヘッダー確認
curl -I https://your-site.example.com/
# 期待値 (no-cache 設定済の場合):
# Cache-Control: no-cache, must-revalidate
# 実際の値 (microcache が効いている場合):
# Cache-Control: max-age=3600
# 2. 同 URL + 違うクエリでキャッシュ回避テスト
curl -s https://your-site.example.com/some-page/ | md5sum
curl -s "https://your-site.example.com/some-page/?cb=$(date +%s)" | md5sum
# 期待値: 両方とも同じ MD5 (キャッシュ無効化が効いている)
# 実際: MD5 が違う場合 → microcache 確定2 つのコマンドで 10 秒以内に診断可能です。MD5 が異なる場合、microcache レイヤーで古い HTML が返されていることが確定します。
解決策 1: コンテンツキャッシュを OFF にする (最も確実)
開発・更新頻度が高いサイトなら、ConoHa WING の管理画面でコンテンツキャッシュを OFF にするのが最も確実です。手順は以下の通り。
- ConoHa コンパネにログイン
- 「サイト管理」→ 該当ドメインを選択
- 「高速化」タブ → 「コンテンツキャッシュ」を見つける
- 鉛筆アイコンをクリック → 「OFF」を選択 → 保存
- 1-2 分で反映、以降は HTML が毎回上流から取得される
所要時間 1 分の本人作業。表示速度はわずかに低下 (1 ページあたり 50-200ms 増) しますが、個人サイト規模ならユーザー体験への影響はほぼゼロです。私は ai-pick.tech / lab.ai-pick.tech / saas-diary.com / host.ai-pick.tech のすべてで OFF 設定にしており、デプロイ反映の遅延に悩むことが完全になくなりました。
解決策 2: ON のままで「キャッシュクリア」ボタン運用
表示速度を優先したい場合、コンテンツキャッシュ ON のままで運用するのも 1 つの選択肢です。その場合、デプロイのたびに ConoHa コンパネからキャッシュクリアボタンを押す運用ルールが必須になります。
- サイト管理 → 該当ドメイン → 高速化 → キャッシュ
- 「キャッシュをクリア」ボタンをクリック → 確認 → 実行
- 5-10 秒で全 URL のキャッシュが消える
- 次回アクセス時に上流から最新を取得 + 新たにキャッシュ
この運用のデメリットは「本人の手作業が増える」点です。FTPS 自動デプロイ + Windows Task Scheduler の組み合わせで自動化していても、最後にキャッシュクリアだけは本人がコンパネを開いて押す必要があります。クリア忘れによる「反映されない事故」が起きやすいので、開発頻度が高いサイトには推奨しません。
解決策 3: .htaccess + URL バスタクエリ + キャッシュ OFF の組み合わせ
本番運用を意識した「ガッチリ防御」のフルセット構成です。私が ai-pick.tech / saas-diary.com / lab.ai-pick.tech / host.ai-pick.tech で実運用している構成を共有します。
(1) コンテンツキャッシュ OFF (解決策 1)
(2) .htaccess で HTML キャッシュ制御
# .htaccess の例
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 0 seconds"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType image/svg+xml "access plus 30 days"
ExpiresByType image/png "access plus 30 days"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.html$">
Header set Cache-Control "no-cache, must-revalidate"
</FilesMatch>
</IfModule>(3) CSS / JS には URL バスタクエリで強制更新
<!-- HTML テンプレート側 (静的サイトジェネレータで自動化) -->
<link rel="stylesheet" href="/styles.css?v=1748234567">
<script src="/main.js?v=1748234567"></script>v= の値はビルド時に file.mtime を Unix タイムスタンプで取得すれば、変更があったときだけ値が変わります。ブラウザは「URL が変わった = 新しいリソース」と判断して再取得します。CSS / JS は 1 年キャッシュ + URL バスタクエリの組み合わせで、ファイル変更時だけ確実に更新されます。
この (1) + (2) + (3) のフルセット構成が、個人開発で運用するメディアサイトの定石です。私は 5 サイトすべてでこの構成を採用しており、デプロイ反映の遅延問題は完全にゼロになりました。
他のホスティングで遭遇する類似の罠
microcache / 上流キャッシュの罠は ConoHa WING 固有ではなく、共用ホスティング系で頻繁に起きます。他社の状況も整理しました (各社公式情報 + コミュニティ報告、2026 年時点)。
| ホスティング | microcache / 上流キャッシュ | OFF 可能 | デフォルト |
|---|---|---|---|
| ConoHa WING | Nginx microcache (コンテンツキャッシュ) | ○ | ON (要 OFF 設定) |
| Xserver スタンダード | Xアクセラレータ Ver.2 (Nginx 系) | ○ | ON (オプション) |
| さくらレンタル | 静的サイト向けキャッシュなし | - | OFF |
| ロリポップ | 独自キャッシュ機構 | ○ (プランによる) | プラン依存 |
| Cloudflare Pages | CDN レベルキャッシュ | ○ (Cache Rule) | ON (CDN 標準) |
| Netlify | CDN レベルキャッシュ | ○ (_headers / netlify.toml) | ON |
| Vercel | Edge Cache | ○ (vercel.json) | ON |
共用ホスティング系 (ConoHa WING / Xserver / ロリポップ) は ON デフォルトのため、開発・更新頻度が高いサイトでは初期設定で OFF にしておくのが安全です。Jamstack 系 (Cloudflare Pages / Netlify / Vercel) も CDN レイヤーで同じ罠が起きるため、デプロイ時にキャッシュパージする運用が必須です。
ConoHa WING を選ぶべきか避けるべきか
microcache 罠を踏んだ経験から、ConoHa WING を選ぶ判断軸を整理しました。
ConoHa WING が向いているケース:
- 静的サイト (Astro / Eleventy / 自前 HTML エンジン) を複数並走運用したい
- マルチドメイン無制限プランで個人開発のメディア群を 1 つの契約に集約したい
- WordPress も一部で使う (5 サイトまでは余裕で並走可能)
- 国内 DC + 日本語サポート + UI の使いやすさを重視
- 月額 1,452 円 (ベーシック) の固定コストでサイト数を増やしたい
ConoHa WING を避けるべきケース:
- Node.js 常駐プロセス (Express / Fastify / Next.js SSR) を動かしたい → VPS が必要
- WordPress を 5 サイト以上同時並走 → 上位プランに移行か VPS に分散
- サイトごとに大規模 (10 万 PV / 月以上) → 専用サーバーや Vercel Pro 等を検討
- microcache 罠への対応が煩わしい → 静的ホスティング (Cloudflare Pages / Netlify) も検討
個人開発で 4-10 サイト並走を考えるなら、ConoHa WING は依然としてコスパ優位です。月額 1,452 円で 10 サイトまで載せられる構造は、Jamstack 系 (Netlify / Vercel) の有料プラン (1 プロジェクト月 $19-20) と比較して 10 分の 1 以下のコスト。microcache 罠だけ事前に知っていれば、長期運用の選択肢として優秀です。
結論 — microcache を理解した上で ConoHa WING を使う
ConoHa WING の microcache は「悪」ではなく、適切に理解して使えば表示速度向上の強力な機能です。ただし開発・更新頻度が高いサイトでは事前に OFF にするのが現代的な運用です。私は 5 サイトすべてで OFF 設定 + .htaccess no-cache + URL バスタクエリのフルセット構成を採用し、デプロイ反映の遅延問題ゼロを実現しています。
初契約は ConoHa WING 公式ページ から、マルチドメイン無制限プラン (ベーシック 月¥1,452 税込) でスタートできます。本記事で紹介した microcache 設定とフルセット運用構成は契約後 30 分以内に整えられるので、最初に設定してしまえば後悔ゼロです。
ConoHa WING と VPS の使い分け判断はVPS 実運用記録、Netlify からの緊急移管経験はサーバー移管記録、他のホスティング比較は比較記事を参照ください。
筆者: GRAMSHIFT — Instagram 自動運用 SaaS『GramShift』開発者、saas-diary.com / ai-pick.tech / lab.ai-pick.tech / host.ai-pick.tech 等 複数メディア運営。ConoHa VPS 2GB プランで GramShift Web/API を 1 年以上 24/7 運用中、ConoHa WING マルチドメイン無制限プランで 4 メディアサイトを合計月額 約 ¥5,000 で並行運用している。本記事内の microcache 検証手順 + 解決策は私の 5 サイト運用で実証済みのものです。 ※ アフィリエイトプログラム参加中 (ステマ法対応 [PR] 表記) デフォルトの TTL (Time To Live) は 1 時間 (max-age=3600 秒) です。1 時間経過するか、コンパネから明示的にキャッシュクリアボタンを押すまで、Nginx 内部に古い HTML がキャッシュされ続けます。開発フェーズで頻繁にデプロイするサイトでは、最初からコンテンツキャッシュを OFF にする運用が推奨です。 ConoHa WING の Nginx microcache レイヤーは、Apache の処理より上流で動作するためです。Apache の HTTP ヘッダー設定 (.htaccess の <code>Cache-Control: no-cache</code>) は、初回アクセス時に Nginx 内部にキャッシュされる HTML には反映されますが、Nginx 側のキャッシュ制御 (max-age=3600) が外側にあり、ブラウザにはそちらの値が優先されることがあります。確実に no-cache を効かせるには、ConoHa コンパネでコンテンツキャッシュ自体を OFF にするのが最も確実です。 1 ページあたり 50-200ms 程度の表示時間増加が見込まれます。ただし個人サイト規模 (月 10 万 PV 未満) ではユーザー体験への影響はほぼゼロです。私は 5 サイト (saas-diary.com / ai-pick.tech / lab.ai-pick.tech / host.ai-pick.tech / prompts.ai-pick.tech) すべてで OFF に設定していますが、Google PageSpeed Insights のスコアも変化なしで、検索順位への影響も観測されていません。 はい、CDN レベルで類似の罠が発生します。Cloudflare Pages では Cache Rule で対応、Netlify は <code>_headers</code> ファイルか <code>netlify.toml</code> でキャッシュ制御、Vercel は <code>vercel.json</code> で設定します。本記事の解決策 3 (.htaccess + URL バスタクエリ) はホスティングを問わず有効な定石なので、共用ホスティング / Jamstack 系どちらでも応用できます。📚 WordPress 高速化関連書籍 (楽天市場)
よくある質問
ConoHa WING のコンテンツキャッシュは何分でクリアされますか?
.htaccess の <code>Cache-Control: no-cache</code> はなぜ効かないのですか?
コンテンツキャッシュを OFF にすると表示速度はどれくらい遅くなりますか?
Cloudflare Pages / Netlify でも同じ罠は発生しますか?