Cloudflare on Keyuki Blog

Xのリンクカードに画像が出ない原因を調べたら、featured_imageだけでは足りなかった

Wed, 06 May 2026 19:00:00 +0900

こんなブログでも流入数を多少は増やしていきたいなという、気持ちで、試しに記事をXに投稿したとき、リンクカードに画像が出ませんでした。

リンクカードというのは、XにURLを貼ったときに自動で表示される、タイトルと画像がセットになったあのプレビューのことです。ちゃんと出ると見栄えがいいし、クリックされやすくなる気がして、できれば表示させたいやつです。

記事ページ自体を開くとアイキャッチ画像はちゃんと表示されていました。なのにXのカードには画像がない。「またX側の気まぐれか？」とも思ったのですが、せっかくなので原因をちゃんと調べることにしました。

まずHTMLのソースを確認しました

Webページの裏側にはHTMLというファイルがあって、その中に「この記事のSNSカード用画像はこれです」という情報を埋め込む仕組みがあります。og:image や twitter:image といった「メタタグ」と呼ばれる記述がそれにあたります。

まずそのメタタグが正しく出力されているかを確認しました。Hugo（このブログで使っている静的サイトジェネレーター）でサイトを一時的にビルドして、出力されたHTMLを調べました。

hugo --destination /private/tmp/keyuki-og-check --environment production
rg -n "og:image|twitter:image|twitter:card" /private/tmp/keyuki-og-check/posts

結果を見て、最初は「あ、タグ自体は出てる」と思いました。必要なメタタグは全部ありました。

ところがよく見ると、どの記事もまったく同じURLを指していました。

<meta property="og:image" content="https://blog.keyuki.net/images/default-og.jpg" />
<meta name="twitter:image" content="https://blog.keyuki.net/images/default-og.jpg" />

記事ごとの画像ではなく、全記事共通の default-og.jpg という1枚の画像を指していました。

「メタタグがない」のではなく、「メタタグはあるけど、指している画像が全部同じ共通画像だった」という状態でした。

原因は `featured_image` と `images` の役割の違い

このブログはHugo + Anankeというテーマで動いています。記事を書くとき、ファイルの先頭に設定を書く欄（「フロントマター」と呼びます）があって、そこにアイキャッチ画像のURLを指定していました。

featured_image: https://images.keyuki.net/uploads/2026/05/example-eyecatch.png

これで記事ページにはちゃんと画像が表示されます。ところがXのリンクカードはここを見ていませんでした。

Hugoには featured_image とは別に、SNSカード用のメタタグを生成するための images という設定項目があります。HugoのOGP（Open Graph Protocolの略で、SNSにURLを貼ったときの見え方を制御する仕組みです）は、featured_image ではなく images を参照して動きます。

featured_image → 記事ページ上のアイキャッチ表示に使われる（Anankeテーマ固有の機能）
images → SNSカード用メタタグの生成に使われる（Hugo本体の機能）

images を設定していなければ、Hugoはサイト全体のデフォルト画像（default-og.jpg）で埋めます。今回まさにその状態でした。

画像サイズにも落とし穴がありました

共通の default-og.jpg を確認してみたら、解像度が 7200x4800、ファイルサイズが約7.6MBもありました。

Xのリンクカードには画像のサイズ制限があります。大きすぎる画像はカードに表示されません。共通画像はその条件を超えていたため、仮にフォールバックとして読み込まれていたとしても表示されなかった可能性が高いです。

SNSカード用の画像は 1200x630（横1200px × 縦630px）のJPEGで、ファイルサイズは数百KB以内に抑えるのが安全とされています。

修正した内容

各記事のフロントマターに `images` を追加しました

公開済みの記事のフロントマター（ファイル先頭の設定欄）に images を追加しました。SNSカード用の画像はアイキャッチとは別に、1200x630で作り直したものを使っています。

個人ブログに Google Analytics と Microsoft Clarity を入れた理由

Wed, 06 May 2026 10:00:00 +0900

ブログを整え直している流れで、アクセス解析まわりも見直しました。

もともと Cloudflare Web Analytics は使っていましたが、今回は Google Analytics 4 と Microsoft Clarity も追加しました。アクセス数を細かく追いかけたいというより、どの記事が読まれているのか、どこから来ているのか、読者がページ内でどう動いているのかを見られるようにしたかったからです。まあ、そもそも誰も見にきてないんですけどね。やってみたいだけですね。

もともと使っていた Cloudflare Web Analytics

Cloudflare Web Analytics は、個人ブログにはかなり相性がいいと思っています。軽くて、Cookie に依存せず、プライバシー寄りの設計です。まず全体のページビューや訪問傾向をざっくり見るだけなら、これで十分な場面も多いです。

公式の説明によると、JavaScript の beacon と Performance API を使ってデータを収集しており、訪問者の個人データは収集・使用しない設計になっています。Core Web Vitals などのパフォーマンス指標の傾向も確認できます。

「何人くらい来ているのか」「どのページが見られているのか」を日々ざっくり把握するには、これで十分です。

それでも GA4 を追加した理由

GA4 は正直、個人ブログには機能が多すぎる面もあります。ただ、流入元やページごとの傾向を後から掘れるのは便利です。SNS に投稿した直後の反応、検索から読まれた記事、内部リンクで回遊された記事などを見たいとき、Cloudflare より細かい分析ができます。

GA4 の主な強みを整理すると:

リアルタイムレポート: 直近 5分 / 30分のアクティブユーザー、閲覧ページ、イベントをざっくり確認できる。正確な流入元の内訳は、通常のトラフィック取得レポートで後から確認する用途に向く
トラフィック・ユーザー分析: どこから来ているか（検索、SNS、直接など）の内訳を見る
探索（Explorations）: 標準レポートより深く、フィルタやセグメントを組み合わせて分析できる

個人ブログでは全部使う必要はないです。「SNS に投稿したあと、どこから何人来たか」「検索から読まれている記事はどれか」といった目的を決めて、必要なところだけ見る使い方で十分だと思っています。まだ書いたブログをSNSに投稿してないですね、やらないといけないですね。

将来的に Search Console と接続してオーガニック検索の傾向を見たり、イベント設計をして内部リンクのクリックを追ったりもできるみたいですね。将来の選択肢は多い方がいいですからね。

Microsoft Clarity を追加した理由

Clarity は、数字というより読者の動きを見るために入れました。他の人のブログで見て、なんだろうこれと思ってとりあえず、調べて、入れてみた感じです。どこでスクロールが止まるのか、どのリンクが押されるのか、スマホで読みづらそうな箇所がないか。こういうことは、ページビューだけを見ていてもわかりません。

Hugoと Cloudflare Pages を組み合わせたブログ運用について

Mon, 05 Jan 2026 00:00:00 +0000

このブログの元となっている「Hugoと Cloudflare Pages」についてまとめます。

Hugo（ヒューゴ）と Cloudflare Pages を組み合わせたブログ運用は、「早い・安い・高セキュリティ」 みたいな感じです。

1. 全体の仕組み

Step 1: 記事の執筆（ローカル環境）

パソコン上で、Markdown（マークダウン）という記法を使って記事を書きます。 Hugoのコマンドを使えば、自分のPC内で瞬時にブログのプレビューを確認できます。

Step 2: 保存と送信（Git Push）

記事を書き終えたら、そのファイルを「Git（ギット）」というバージョン管理ツールを使って、GitHubというインターネット上の「倉庫（リポジトリ）」へアップロード（Push）します。

人間の作業はここまでです。

Step 3: 自動検知とビルド（Cloudflare Pages）

GitHubに新しいファイルが届いたことを、Cloudflare Pagesが自動的に検知します。すると、Cloudflareのサーバー内でHugoが起動し、Markdownファイルを読み込んで、Webブラウザが表示できる「HTMLファイル」へと変換（ビルド）します。

Step 4: ブログの公開（デプロイ）

変換されたHTMLファイルは、Cloudflareにより、公開されます。

2. WordPressとの違い

特徴	WordPress（動的サイト）	Hugo + CF Pages（静的サイト）
仕組み	注文を受けてから都度作成して表示する	あらかじめ作って並べておく
速度	データベースから素材を探して表示するため、少し時間がかかる。	既にある完成品（HTML）を渡すだけなので、早い。
セキュリティ	データベースに侵入されるリスクがある。	HTMLファイルだけなので、ハッキングの余地がほぼない。
コスト	サーバー代や管理費がかかることが多い。	個人のブログ程度なら、ほぼ無料で運用可能。

3. メリット

圧倒的な表示速度: Hugoが生成する静的HTMLは非常に軽く、一瞬で表示されます。
運用コストがほぼ0円: Cloudflare Pagesは無料プランの枠が非常に大きく、独自ドメイン代（年間千円〜数千円）以外は無料で運用できるケースがほとんどです。
サーバー管理が不要: ソフトウェアのアップデートやセキュリティパッチ当てなどの面倒な作業がありません。
バージョン管理: 記事の履歴がGitに残るため、「間違って消した記事を元に戻す」といったことが簡単にできます。

わたしは現在、Obsidianというmd(マークダウン)形式のエディターを利用して、ブログを書いています。Obsidianはプラグインが豊富で、Gitも導入できることから、この構成での相性が良いと考えました。