ImageMintのロゴ
ImageMint

Open Graph画像：サイズ、形式、表示されない理由

リンクを共有すると、選んだ画像ではなく空のカード、引き伸ばされた切り抜き、3回前のデプロイの画像が出ます。この問題のほぼすべては、確認できる少数の原因に行き着きます。寸法の誤り、非対応形式、相対URL、ファイル変更に気づいていないキャッシュです。

画像形式Dev.SWL作読了時間：9分

1200×630という標準と、その理由

事実上の標準 og:image サイズは 1200×630ピクセル、アスペクト比は約1.91:1です。この数値は単なる慣習ではありません。Facebook、LinkedIn、Slack、Discordで表示されるリンクプレビューカードの多くで使われる、最も横長のアスペクト比に近いためです。そのため1200×630の画像なら、プラットフォームが上下に余白を加えたり、大きく切り抜いたりせずにカードを埋められます。

小さな画像でも技術的には使えますが、プラットフォームがカード全体に合わせて拡大するため、細部がぼやけ、専用に用意した画像より明らかに悪く見えることがあります。多くのプラットフォームは、プレビューとして受け付ける最低寸法をおよそ200×200としていますが、これは目標ではなく下限です。1200×630より大幅に小さくすると、何の利点もなく画質を犠牲にします。

Twitter/Xの summary_large_image カードは同じ1200×630画像と同じ比率を使うため、通常は1画像で両方に対応できます og:image および twitter:image 別の書き出しを必要とせず。

安全領域：切り抜き後に実際に残る部分

アスペクト比が正しくても、表示場所によって各プラットフォームはカードを少し違う形で切り抜きます。フィード投稿、DMのリンクプレビュー、サイドバーの「共有リンク」欄は、同じ画像でも同じ切り抜きとは限りません。端にぴったり置いた文字やロゴは、ご自身のブラウザーのタブプレビューでは問題なくても、別の表示場所では切れる場合があります。

安全な方法は、見出し、ロゴ、顔などの重要な内容を枠の内側約90%に収め、各辺に約5〜10%の余白を残すことです。背景画像、グラデーション、装飾要素は端まで広げて問題ありません。すべての閲覧者に見てほしい内容だけを内側に置きます。デザインツールが対応するなら、1200×630のキャンバスの各辺から約60px内側にガイド矩形を描くと、実用的な安全領域になります。

1200×630のカードに破線で内側の安全領域が示され、その周囲にはSlack、X/Twitter、Facebookとラベル付けされた3つのプレビュー模型があり、それぞれ異なる切り抜きでカードを表示している
1画像、3つの切り抜き。破線の外側が残る保証はないため、見出しは端でなく、その十分内側に置くべきです。

形式：JPGかPNG、WebPを使わない理由

実際の画像ファイルにはJPGとPNGが安全な選択です。次におけるWebPの対応は og:image は、リンクプレビューを生成するクローラーや展開ボットで対応が不統一です。対応するものもあれば、WebPで警告なくプレビューを一切描かないものもあります。失敗が無言なので、指摘されるまで壊れたプレビューを公開しても気づきにくくなります。

これは、現在のほぼすべてのブラウザーが問題なく表示するWebPをブラウザーへ配信する場合より厳しい互換性条件です。詳しくは WebP・PNG・JPGの比較 一般の場合です。リンクプレビューのクローラーは利用者のブラウザーとは異なる保守的な集団で、WebP対応が遅れています。写真プレビューには同等の見た目で小さいJPG、単色、文字、一部の状況で透明度を保持したい画像にはPNGを使います。ただしOG画像は常にカードの背景上に描かれるので、透明度自体は実質的に問題ではありません。

GIFは技術的には大半のプラットフォームで静止画として受け付けられますが、写真やデザイン要素の多いプレビュー画像には有意義な選択ではありません。ここでJPGやPNGよりGIFを選ぶ実用的な理由はありません。

URLは絶対URLでなければならない

<meta property="og:image" content="/og-image.jpg" /> ブラウザーが相対パスを現在のページURLに対して解決するので、直接閲覧すると妥当で正常に動きます。リンク展開のクローラーは同じ解決を確実に行わないか、誤った基準で解決することがよくあります。その結果、一部では動くのに他では画像が壊れたり消えたりし、利用者報告だけでは診断が難しくなります。

スキームとドメインを含め、常に完全な絶対URLを書いてください。

<meta property="og:image" content="https://example.com/og-image.jpg" />

Next.jsのMetadata APIでは、これは次の設定にあたります metadataBase ルートレイアウトに設定すると、ページごとのメタデータの相対画像パスはビルド時に絶対URLへ自動解決されます。または各ページの次へ完全なURLを直接書きます： openGraph.images このサイトと同じ項目です。

キャッシュ：修正した画像でも古いプレビューが出る理由

「直したのにまだ違う表示になる」最も一般的な原因です。プラットフォームは画像を含む取得済みOpen GraphデータをURLごとにキャッシュし、新しいファイルをデプロイしても、そのキャッシュは失効しません。プライベートウィンドウであっても自分でページを再読み込みするだけでは、プラットフォームが何を保持しているかはわかりません。

主要な各プラットフォームには、再取得を強制するための独自のツールがあります。

  • Facebook / Meta： Sharing Debugger（developers.facebook.com/tools/debug/）へURLを貼り付け、「Scrape Again」を押します。Metaのクローラーを共有するInstagramとWhatsAppのリンクプレビューのキャッシュも消えます。
  • X/Twitter： 従来はCard Validatorがこの用途を担っていましたが、利用可否は変化してきました。到達できない場合は、下記のようにURLへ無害なバージョン用クエリ文字列を追加する方が確実です。
  • LinkedIn： Post Inspector（linkedin.com/post-inspector/）へURLを貼り付けて再取得を強制します。
  • Slack、Discord、iMessage： 公開デバッガーはありません。通常、独自の期間後にキャッシュが失効するか、URLが少しでも変わると更新されます。

専用デバッガーが使えないか、うまく動かない場合の共通の回避策は、プラットフォームに見えるURLを変えることです。次のようなバージョン用クエリ文字列を付けます： ?v=2 共有リンクまたは画像URL自体に付けると、全プラットフォームが未取得の資源として扱い、古いキャッシュではなく再取得します。

ブラウザーの表示ではなく、クローラーが実際に受け取るものを調べてください。一般的なユーザーエージェントでcurlを使ってページを取得するか、各プラットフォームの公式デバッガーを使うと、クローラーの見え方を確認できます。ブラウザーはクライアント側の描画や独自のキャッシュを適用するため、実際のサーバー応答を隠すことがあります。

ファイルサイズとその他の制限

大半のプラットフォームは、数MB程度の画像サイズ上限を案内しています。Facebookが記載した上限は従来約8MBで、明確な値を公開しないものも、異常に大きいファイルではタイムアウトしたりプレビューを描画しなかったりしがちです。この種の1200×630のJPGやPNGは、適切に圧縮すれば通常500KBを十分下回るため、実際に上限へ達するのは、ほぼ常に未最適化の書き出しです。大きな写真をマークアップだけで縮小して実際の寸法で再エンコードしていない、写真をJPGでなくPNGに書き出した、といった場合です。当サイトの 画像容量を減らすガイド 見た目の品質を落とさず出力容量を減らす一般的な方法。

サムネイル寸法での文字の読みやすさ

OG画像は通常、元の1200×630ピクセルよりはるかに小さく表示されます。Slackのリンク展開やモバイルのフィードカードでは、幅数百ピクセルになることがあります。画像に焼き込んだ文字は、その縮小に耐える必要があります。実用上の目安として、元画像の幅1200pxで約40px未満の本文文字は、一般的なフィード表示へ縮小するとぼやけて読めなくなりがちです。サムネイルサイズでも読める見出しには、通常はさらに大きい60–80px程度以上の太字と、背景に対する強いコントラストが必要です。

画像自体を簡単にする理由でもあります。複数の文字要素が競合する複雑な構図は、原寸では読めてもカードサイズでは視覚的な雑音になります。高コントラスト背景に1つの明確な見出しを置けば、掲載されるどの表示面でも安定して読めます。

twitter:cardには独自の宣言が必要

設定 og:image だけではX/Twitterの大きい画像プレビューに自動で十分とはなりません。Twitterのカード機構は独自の次を読みます： twitter:card metaタグでカード形式を決めます。これがないと、一部Twitterクライアントは、正常な次があっても小さなサムネイルカードに切り替わります： og:image が存在します。

明示的に宣言してください。

<meta name="twitter:card" content="summary_large_image" />

Twitterは代わりに次を使います： og:image 実際の画像には、次の場合 twitter:image を個別に設定しなければ、通常は画像URLを重複指定する必要はありません。ただし大画像配置が欲しいならカード種類の宣言自体は必須です。

簡単な診断の順序

  1. 画像URLが相対ではなく絶対URLで、ブラウザーで直接読み込めるか確認してください。
  2. 形式がWebPではなくJPGまたはPNGか確認してください。
  3. 寸法が1200×630、またはそれに近いか確認してください。
  4. 確認 twitter:card Twitter/Xだけプレビューが違う場合は、設定されているか確認します。
  5. 修正が失敗したと思う前に、プラットフォームのデバッガーで再取得を強制してください。
  6. デバッガーがない場合は、URLのバージョン用クエリ文字列を更新し、キャッシュを回避してください。

よくある質問

FacebookとTwitter/Xで別々の画像を使えますか？

はい — 設定するのは twitter:image とは異なるURLへ og:image プラットフォーム別の絵柄が欲しい場合です。両方とも同じ1200×630比率で1画像が十分使えるため、多くのサイトは行いません。

Facebookでは画像が使えるのに、WhatsApp共有では使えません。なぜですか？

WhatsAppとInstagramのリンクプレビューはMetaのクローラー基盤を使うため、FacebookのSharing Debuggerで再取得すると通常は両方直ります。WhatsAppだけで失敗が続く場合は、画像より、そのクローラーのユーザーエージェントを遮るrobots.txtやサーバー応答の問題が多くあります。

画像には代替テキストが必要ですか？

一部のプラットフォームは対応しています： og:image:alt アクセシビリティ用です。短く正確な説明を含めるコストはありません。プレビューの表示可否には影響せず、スクリーンリーダーが読み上げる内容だけに作用します。

このサイトのような静的書き出しでも、ページごとのOG画像に対応できますか？

はい。画像URLとメタデータはビルド時に出力する静的タグなので、静的書き出しのサイトでも別のものを設定できます： og:image ページごとに、サーバー描画サイトと同じように設定できます。OG画像に動作中のバックエンドは不要です。

カードがWebPです。まずそこを直してください。

プレビューが空になる最も一般的な理由です。画像変換はWebPカードを、クローラーが実際に受け付けるJPGかPNGに変えます。複数なら一括処理でき、JPGでアルファが黒になる部分は背景を塗ります。すべてブラウザー内で実行し、アップロードはありません。

画像変換を開く

関連チュートリアル