← 制作ノート一覧

AWSでもGCPでもなく、Tencent Cloudで配信している話

2026年8月29日サイト全体

このサイトは、Tencent Cloud の EdgeOne Pages という場所から配信されています。gitのmainブランチに入ったHTMLが、ビルドも何も挟まずそのまま本番になる構成です。白状すると、各社の比較表を作って選んだわけではありません。「静的ファイルをHTTPSで配るだけ」という要件に、いちばん薄く合った場所をそのまま使い続けている、というのが正直なところです。開設からひと月あまり運用して、良さも困りごとも実測が溜まってきたので、この選択の答え合わせを書きます。作りが素のHTML/CSS/JSである理由は別の記事に書きました。

「置くだけ」が、本当に置くだけだった

やっていることはこれだけです。GitHubのリポジトリを一度つなぐと、mainにpushするたび数分で本番に反映されます。TLS証明書もEdgeOne側が持つので、更新作業はありません。サーバは1台も無く、ゲームのセーブデータは全部プレイヤーのブラウザの中にあります。インフラの手入れに使っている時間は、月にほぼゼロ分です。

細かい規約も、静的サイト向けによく出来ていました。ルートに404.htmlを置くと自動でエラーページに使われます。パスの先頭がドットで始まるフォルダは配信されないので、開発メモや検査スクリプトをリポジトリに同居させたまま隠せます。ヘッダやリダイレクトは、edgeone.jsonという1ファイルに書くだけで済みます。

ただしドットの仕組みには、一度足をすくわれています。ブロックされるのはパスの先頭だけで、公開フォルダの中に作ったドット始まりは素通しでした。非公開のつもりの下書きが、実は全部読める状態だったのです。この失敗は長くなるので、いずれ別の記事にします。

実測で分かった良さ

圧縮は文句なしに効いています。本番実測で、37KBあるHTMLは7.3KBに、いちばん大きいゲームのJSは、測った時点で157KBが46KBになって届いていました。Brotliです。面白いのは、手元でBrotli圧縮して立てた見積もりと5割ちがったことでした。エッジの圧縮設定は手元の既定より緩いので、転送量の議論は本番で測るしかありません。ついでに、デプロイ直後のエッジはキャッシュが冷えていて無圧縮のまま返すことも覚えました。目印はContent-Encodingが付いているかどうかです。最初はAgeを目印にしていましたが、冷えた応答にもAge: 0が付くので、見分けには使えませんでした。

キャッシュの既定も、こちらが何も設定していないのに種類ごとに使い分けられていました。フォントと一部のBGMには1年キャッシュが付き、HTMLやJSは毎回サーバ確認が入る形で配られます。うちで実際に重かったフォントとタイトルBGMが最初から長持ちの側にいたので、狙いどおりに動いている限りは正しい既定だと思います。

実測で分かった困りごと

いちばん大きいのはHTTP/2が使えないことです。実測すると、独自ドメインも既定ドメインもALPNはhttp/1.1しか返しません。ドキュメントには対応と書いてあるのに、です。HTTP/1.1は同時6接続までなので、ファイル数がそのまま待ち時間になります。Google Fonts方式の細切れフォントをそのまま持ち込んだときは、フォントだけで17リクエストになり、4巡ぶんの待ちが生まれました。束ね直して2リクエストにしのぎましたが、根本は直せていません。ここは今も納得していません！

「狙いどおりに動いている限りは」と書いたのは、キャッシュの既定に一度殴られたからです。トップレベルの一部のHTMLにだけ、規則が読めない形で1年キャッシュが付くことがありました。HTMLを直したのに訪問者に届かない、という事故になります。いまはedgeone.jsonで該当のHTMLに毎回確認を強制して抑えました。

管理画面が2つの別プロダクトに割れているのにも迷いました。ドメインを管理する「ゾーン」と配信する「Pages」は別物で、ゾーン側の使用量表示は本番が動いているのに0Bのままです。仕様だと分かるまで、自分の設定がどこに効いているのか随分探しました。細かい上限もあります。edgeone.jsonのリダイレクトは100件まで、返せるのは301と302だけで、404は返せません。全ページの末尾スラッシュを素直に列挙すると100件を超えるので、書きかたの工夫が要りました。この手の上限には、実際にぶつかるまで気づけませんでした。

AWSやGCPと比べてどうか

同じ構成を組もうとすると、部品の数がまるで違います。

AWSもGCPも、仕事で使うぶんには真っ当な作りだと思います。ただ「HTMLを置いて配るだけ」の個人サイトには、設定する画面と見張る請求が多すぎました。GCPに至っては、CDNを通すためだけにロードバランサの時間課金が付いてきます。平日の夜の限られた時間で作っているサイトなので、インフラに使う手数がほぼゼロであること自体が選ぶ理由になります。逆に言えば、大手クラウドで得られる細かい制御は手放していて、HTTP/2を自力で有効にできないのもその一部です。

マイナーな置き場は、学習として損か

意外だったのは、これが損になっていないことです。ここで測って覚えたことの大半は、Cache-Controlの読みかた、ALPNの確かめかた、エッジが冷えているときの挙動といったCDNの一般教養で、AWSに持っていってもそのまま通用します。エッジ配信の仕組みは、どの社のものでも根っこが同じだからです。

むしろ情報が少ないぶん、鍛えられた面があります。検索しても答えが出てこないので、curlとopensslで自分のサイトを叩いて確かめる癖が付きました。「ドキュメントには対応と書いてあるが、実測は違う」という経験を先にしてしまうと、どのクラウドの資料を読むときも、で、実際はどうなのか、と手が先に動くようになります。これはたぶん、どこへ行っても使える癖です。

この先オンライン対戦を足すときも、WebSocketの口をTencentのVPS（東京リージョン・月4.2ドル・2026年8月時点の価格）で用意して、同じアカウントと同じ請求の中に閉じる予定でいます。業者を増やさないほうが個人開発では強い、というのがいまの結論です。それでもHTTP/2の件だけは、いつか引っ越しの理由になるかもしれないと半分思いながら使っています。