あまねけ！交通量調査（2026年6月）

最近、Firebase Hosting¹で運用しているこの個人サイト「あまねけ！」のデータ転送²が急増しています。2026年5月に至っては毎月数円から数十円程度で済んでいたホスティング費用が790円まで跳ね上がってしまい、そろそろ調査が必要かなと思ったところです。

1ヶ月に790円ともなると、無料枠と合わせて40GBくらいのデータ転送があったという計算になります。もし仮に、本当に訪問者が爆増してたくさん記事を読んでくれたならありがたいことですし、それに対して数百円払うなら安いものです。しかし、あまねけ！はアクセス解析³やインターネットの反応を見ている限り日々だいたい無風であり、来るのは顔見知りと観光案内所⁴経由のニッチな観光客くらい。データ転送量だけが右肩上がりというのは説明が付きません。

Firebase Hostingの料金プランには、脚注で触れたとおりSparkプランとBlazeプランがあります。

SparkプランのFirebase Hostingでは、 月に 10GBの無料枠が割り当てられます。ドキュメントの記載がまちまちなのですが、実際はさらに 1日に 360MBの制限がかかります。そのため、例えば平日のアクセスが360MBを下回っても、使わなかった分を休日のアクセスに充てるような使い方はできません。比較的アクセスが多いサイトや画像メインのサイトではギリギリという印象です。

ここでBlazeプランに切り替えると、1日に360MBの無料枠は残ったまま、無料枠を使い切った後のデータ転送に0.15ドル/GBかかるようになります。Sparkプランと同様に、360MB/日を使い切った日ごとにそれぞれ料金がかかり、余った無料枠を別の日に回すことはできません。

さて、これらの情報を踏まえて、今からあまねけ！交通量調査を進めていきます。もし以下の技術的観点に詳しくなければ、先に調べておくとよいかもしれません。

• User-Agent
• HTTPキャッシュ
• クローラー
• CDN
• HTTP条件付きリクエスト
• 304 Not Modified
• たまごポケット

では、始めましょう！

仮説

まず、これまでに得てきた情報を元に仮説を立ててみます。ここ数ヶ月は定期的に最終的なホスティング費用とアクセス解析を眺めていたので、ぼんやりと原因の予想もしていました。

最近のホスティング費用の動向は以下の通りです。2025年10月から急増し、2025年12月から2026年2月あたりは180円前後で安定したと思ったら、それ以降は急激に増加したという、3つのトレンドが読み取れます。2025年10月から2026年3月までは長期的な原因①で200円前後の増加があり、それ以降は新たな原因②が重なって600円前後の増加が重なった、と考えられるかもしれません。

アクセス解析の情報については、詳細なログの紹介は避けますがここ数ヶ月ほどは中国・香港・台湾からのアクセスログが多く、他にもUser-Agentがクローラーっぽいもの、あとはiCloudのプライベートリレーに包まれたアクセスなどが多かったです。滞在時間も少なく、多くのページを機械的に辿るアクセスも頻発していました。

あまねけ！はほとんどが日本語の文章のコンテンツですし、知らない人が翻訳して読むほどの使いやすい情報はないはずです。ここ最近、海外からのアクセスが増えているとなると――AIの学習データ収集ボットが、あちこちの帯域を占有して回っているという話が頭をよぎります。これらの情報をまとめて、「AIの学習データ収集クローラーに狙い撃ちされており、アクセスが頻発してデータ転送量を押し上げている 」という仮説を立てて調査を始めました。

調査

ホスティング費用とアクセス解析の傾向だけでは、まだ情報が足りません。Firebase HostingではHTTPアクセスログをCloud Logging⁵にエクスポートでき、Cloud Logging側では直近の30日間分のログを無料で保持できます。2025年10月頃からのトレンドを確認するのには足りませんが、ここ数日も続く大量のデータ転送を分析するには十分です。

ログの分析には、ブラウザから利用できるログエクスプローラを使うのが手っ取り早いですが、User-AgentやIPアドレスごとに集計したり、過去のデータを手軽に保持したい場合は、対象期間のログを丸ごとダウンロードしてしまうのがおすすめです。

今回は gcloud コマンドで落とせる分を落としてみました:

gcloud logging read 'resource.type="firebase_domain"' --project=YOUR_PROJECT --format=json > YOUR_PROJECT_$(date -Id).json

実行日が6月9日だったので、5月10日頃からのデータが含まれていました。以降はここで得られた amanejp_2026-06-09.json に対して分析を進めていきます。

まず、どんなファイルにアクセスがあるかを集計します:

cat amanejp_2026-06-09.json \
| jq -r '.[] | [.httpRequest.requestUrl, (.httpRequest.responseSize // 0 | tostring)] | @tsv' \
| awk -F'\t' '{size[$1]+=$2; count[$1]++} END {for(u in size) printf "%10.2f MB  %6d reqs  %s\n", size[u]/1000000, count[u], u}' \
| sort -rn | head -n10

ここで分かったのは、ほとんどのアクセスが全体フィードとトップページに対するものだということ。あまねけ！には動画や画像などの大きめのファイル、さらに大きなZIPアーカイブも含まれていますが、アクセス数が桁違いなのでデータ転送量では無視できるレベルになっています。

フィードへのリクエストはブラウザ前提のアクセス解析には出ないので、海外からのアクセスが急増したという印象は見当違いだったようです。一方で、トップページならアクセス解析に出るはずですが、月に10万件以上のアクセスがあったという記録は見つかりません。ちょっと観点を変えて掘り下げる必要がありそうです。

そこで、次にどんなUser-AgentでどんなURLにアクセスしている傾向があるかを集計してみます:

cat amanejp_2026-06-09.json \
| jq -r '.[] | [.httpRequest.requestUrl, .httpRequest.userAgent, (.httpRequest.responseSize // 0 | tostring)] | @tsv' \
| awk -F'\t' '{key=$1"\t"$2; size[key]+=$3; count[key]++} END {for(k in size) printf "%10.2f MB  %6d reqs  %s\n", size[k]/1000000, count[k], k}' \
| sort -rn | head -n5

上位2件が21GB・15GBと合わせて36GBほどあり、飛び抜けて多いですね。しかし全体フィードへのアクセスのUser-Agentは空っぽで、もしかしたら複数のクローラーからのアクセスがまとめられて大きく見えているのかもしれません。

トップページに対するアクセスの Uptime-Kuma というUser-Agentは、Uptime Kumaというサーバーの死活監視サービスからの定期的なアクセスです。実はこのサービスは私自身が設置したもので、意外と無駄な転送量を消費していることが分かりました。 なんてこった！

ただ、Uptime Kumaを設置したのは2025年10月よりかなり前なので、ここ数ヶ月で急に増え始めたというトレンドを綺麗に説明できません。トップページに記事の冒頭を含めるなどの変更でサイズが大きくなった影響を受けたとか、この時期にバージョンアップしたUptime Kumaの監視戦略が変わったとか、CDNのキャッシュ戦略が変わったのかもしれない、と予想しておきます。

全体フィードの話に戻りましょう。最後にアクセス元IPアドレス別に集計してみます:

cat amanejp_2026-06-09.json \
| jq -r '.[] | [.httpRequest.remoteIp, (.httpRequest.responseSize // 0 | tostring)] | @tsv' \
| awk -F'\t' '{size[$1]+=$2; count[$1]++} END {for(u in size) printf "%10.2f MB  %6d reqs  %s\n", size[u]/1000000, count[u], u}' \
| sort -rn | head -n1

結局、21GBほどのアクセスが同一のIPアドレスから行われているログが確認できました。このIPアドレスを whois コマンドで調べると、とある日本国内のレンタルサーバー会社に属するもののようです。おそらくは、あまねけ！をセルフホストのフィードリーダーに登録した読者がいて（これはすごくありがたいことです！）、しかしフィード取得の実装が少し甘いのだと思います。

このフィードリーダーがどういうアクセスをしているのかを確認してみましょう。アクセス日時とステータスコードを抜き出してみます:

cat amanejp_2026-06-09.json \
| jq -r '.[] | select(.httpRequest.remoteIp == "xxx.xxx.xxx.xxx") | [.timestamp, .httpRequest.status] | @tsv' \
| sort | head -10

5～15分間ほどの間隔でフィードにアクセスしており、全てのリクエストが200で返っています。つまり、毎回キャッシュに当たらずに常に最新のフィードを取得しているということです。

あまねけ！も含め、自前でフィードを提供している多くの個人サイトは1日から数ヶ月に1回ほどの更新が多く、1時間に1回程度のチェックでも十分ですし、 If-Modified-Since や If-None-Match を用いた条件付きリクエストを使えば304レスポンスで転送量を節約できます。

もちろん、せいぜい5分間に一度のフィード取得を攻撃や迷惑行為と評するつもりは一切ないのですが、やはりデータ転送量の観点では無駄な処理と言わざるを得ません。

さて、調査結果をまとめます。ここ最近のあまねけ！ホスティング費用の増加には2つの原因があることを確認できました。

• 自前の死活監視サービスによる定期的なトップページの取得によるデータ転送の増加
• 日本国内のレンタルサーバーに設置されたフィードリーダーからのフィード取得によるデータ転送の増加

やはり、どちらも訪問者が爆増したのが原因というわけではなく、むしろデータ転送量としては節約の余地が大きい事象が2つも見つかりました。ちょっと残念。

対策

さて、今回のデータ転送量急増事件については、2つの観点で対策が必要だと分かりました。1つは自前の死活監視サービスであるUptime Kumaへの転送量を減らす対策、もう1つはフィードへのアクセスによる転送量を減らす対策です。

まず、Uptime Kumaのデータ転送量の削減です。そもそもFirebase HostingはバックエンドのCDNがFastly⁶であり、一個人がわざわざ監視するほど不安定なインフラではありません。それはそれとしてステータスページには緑のバーを出しておきたいので、監視間隔を3倍に延ばして、確認するURLをよりサイズの小さなページ（トップページの5%ほど）にしました。これで、月に15GBのデータ転送量が250MBくらいに減ることが期待できます。

次に、フィードのアクセスによるデータ転送量の削減です。レンタルサーバーの運営元が分かっているのでabuse窓口に連絡してもいいのですが、迷惑行為というには緊急性が低く穏やかな挙動ですし、もしかしたらこの記事を読んで対応してくれるかもしれないので、まずはそれ以外の対策を実施します。

あまねけ！のフィードには全ての記事（現時点で200件以上）が含まれており、しかも本文の内容を最後まで含むかなり大きなものになっています（3～4MB程度）。フィードに本文を入れておくと、フィードリーダーによってはサイトを開かずにプレビューできて便利です。

この利便性は削りたくないので、フィードに含める記事の件数を最新から10件までに絞ることにしました。多くのフィードリーダーは記事の更新に注目しており、数年以上前の古い記事は最初に取得したきり無視するからです。実測サイズベースでは4%以下になったので、月に21GBあったデータ転送量は650MBほどになるでしょう。まだ少し多く感じますが、他のフィードリーダーへのデータ転送も減らせる対策なので、その効果はさらに大きくなるはずです。

これで今回のあまねけ！交通量調査で見つかった事象に対する処置はおわりです。既にこれらの対策がバッチリ効いているようで、ここ数日は無料枠を少し超える程度のデータ転送量まで抑えられています。あとは6月と7月の請求額が出ればひとあんしん。もし今後も長期的な分析が必要なら、アクセスログは定期的に取得しておくとよいでしょう。

結論

昨年からじわじわ増加していたホスティング費用の内訳について調査を行いました。半年以上放置しながら「学習データ収集ボットが押し寄せてるな～」となんとなく考えていたわけですが、よく調べるとその予想は見当違いで、実際もっと地味な原因が潜んでいたのが明らかになりました。やっぱり客観的なデータをきちんと分析するのは重要ですね。

みなさんも、ご自身のWebサイトへのアクセス傾向を改めて分析してみてください。特に、自前で死活監視サービスを持っている方は、定期的なアクセスで意外とデータ転送量がかさんでいるかもしれません。従量課金でなければあまり気にしなくてよいでしょうが、新しい発見もあるのでおすすめです。

なお、ふつうのブラウザで記事を閲覧するときにかかるデータ転送量はほぼ無視できる⁷ので、みなさんには今後もどんどんあまねけ！を読んでほしいなと思います。