最終更新:
OGP テキストの最適化|SNS シェア時の表示を改善する方法
OGP (Open Graph Protocol) は、Web ページが SNS でシェアされた際の表示内容を制御するための仕組みです。Facebook で作られ 2010 年に公開されたこのプロトコルは、2026 年 8 月時点で主要な SNS とメッセージングアプリに広く採用されています。適切に設定されていないと、タイトルが途中で切れたり、意図しない説明文が表示されたりして、リンクの魅力が損なわれます。この記事では、OGP テキストの最適化方法と、公式仕様で確かめられる部分・確かめられない部分の切り分け方を解説します。
Open Graph Protocol の仕様と歴史
OGP はもともと Facebook で作られたメタデータ規格で、2010 年に公開されました。HTML の <head> 内に <meta property="og:..."> タグを記述することで、ページの構造化情報をクローラーに伝えます。仕様は ogp.me で公開されており、すべてのページに必須のプロパティとして og:title、og:type、og:image、og:url の 4 つが定義されています。仕様の初版は RDFa をベースにしているため、記述形式は property 属性を使う形になっています。
ここで押さえておきたいのは、ogp.me の仕様が定めているのは「どのプロパティをどう書くか」だけで、og:title や og:description に文字数の上限は一切定義されていない点です。og:description についても「1 〜 2 文の説明」という記述だけで、字数は示されていません。つまり後述する文字数の目安は、すべて仕様ではなく表示側の都合から逆算した実務値であり、プラットフォームが公式に保証している数字ではありません。
OGP が登場する以前、SNS はページの <title> タグや <meta name="description"> を読み取ってプレビューを生成していました。しかし、これらは検索エンジン向けに最適化されたテキストであり、SNS のフィード上で表示するには冗長だったり文脈が合わなかったりする問題がありました。OGP はこの課題を解決するために、SNS 表示専用のメタデータ層を提供しています。
表示文字数はなぜ「公式の数字」が存在しないのか
OGP テキストが何文字で切れるかは、プラットフォーム別の一覧表で語られがちです。しかし 2026 年 8 月時点で、主要な SNS は og:title や og:description の表示文字数を公式に数値で公開していません。理由は表示の仕組み側にあります。カードの文字は端末の画面幅・フォントサイズ・ユーザーの文字サイズ設定・カードの種類 (小さなサムネイル型か大きな画像型か) によって収まる量が変わるため、そもそも「何文字」という単位で決められないのです。
ここから導ける実務方針は 2 つです。1 つは、切り詰めを異常事態ではなく既定の挙動として設計に組み込むこと。もう 1 つは、切れる位置を当てにいくのではなく、どこで切れても成立する語順にしておくことです。日本語は文末に述語が来るため、「〜する方法を 5 つ紹介します」のような形は末尾が落ちると意味が消えます。「5 つの方法|〜」のように先頭で結論を示す形なら、後半が失われても情報は残ります。
目安としては、og:title は全角 40 文字前後、og:description は 70 〜 100 文字前後に収めておくと、多くの環境で主要な部分が読める状態を保てます。これは公式に保証された上限ではなく、切り詰め前提で余裕を取った実務値として扱ってください。
og:title の最適化
og:title はシェアされたときに最も目立つ要素です。ページの title タグとは別に設定できるため、検索結果向けの表現とタイムライン向けの表現を書き分けられます。
効果的な og:title を書くためのポイントは以下の通りです。
- 全角 40 文字前後に収める: 切り詰められても主題が残る余裕を確保する
- サイト名を省略する: リンクカードには通常ドメイン名が併記されるため、限られた文字数を記事の内容に回す
- 要点を先頭に置く: 数字や対象読者を冒頭に出すと、末尾が切れても何の記事か伝わる
- 疑問形や呼びかけも選択肢にする: ただし本文が答えていない問いを掲げると期待外れになり、逆効果になる
og:title と HTML title の不一致時の挙動
og:title と HTML の <title> タグは独立した要素であり、異なる値を設定できます。各プラットフォームのクローラーは og:title を優先的に読み取りますが、og:title が未設定の場合は <title> タグの値にフォールバックします。
ただし、両者の内容が大きく異なる場合は注意が必要です。Google は検索結果のタイトルリンクを生成する際の材料として、<title> 要素や見出しと並んで og:title の内容も参照することを公式ドキュメントで明示しています。つまり og:title は SNS 専用の設定ではなく、検索結果の見え方にも影響し得る要素です。
あわせて誤解しやすい点を 1 つ整理しておきます。Google がタイトルリンクを書き換えるのは「ページ側に問題を検出したとき」で、公式に挙げられている代表例は、タイトルが半分空 (「|サイト名」だけ等)・内容と合っていない・年号などが古い・複数ページで同一の定型文・主となる見出しが判別できない・タイトルの言語が本文と違う、といったものです。文字数が長いことは書き換えの理由として挙げられていません。長いタイトルは書き換えではなく、画面幅に合わせて切り詰められるだけです。この 2 つは別の現象なので、混同して「長いから書き換えられた」と判断しないようにします。
使い分けの方針としては、title タグは検索意図に沿った語を含めた説明的な形、og:title はタイムラインで目に留まる簡潔な形にし、どちらも主題は一致させておくのが安全です。主題がずれると、どの経路から来た読者にとっても内容と第一印象が食い違います。
og:description の書き方
og:description はタイトルの下に表示される補足テキストです。タイトルだけでは伝えきれない情報を補い、クリックの後押しをする役割を担います。
og:description は 70 〜 100 文字前後を目安にします。冒頭の 40 文字ほどに最も重要な情報を置き、途中で切れても意味が通じる形にしておきます。meta description と同じ内容でも構いませんが、検索結果とタイムラインでは読まれ方が違うため、SNS 側はより口語に寄せた表現にする書き分けも有効です。
og:description 未設定時のフォールバック
og:description を設定しなかった場合、各プラットフォームは独自のロジックでフォールバックテキストを生成します。Facebook は <meta name="description"> の値を使用し、それも未設定の場合はページ本文の冒頭テキストを自動抽出します。X は twitter: 系のタグを優先し、未設定なら og: 系のタグを参照します。いずれも無い場合はページ側の記述から拾われます。
自動抽出されたテキストは、ナビゲーションメニューやサイドバーの文字列が混入することがあり、意図しない表示になるリスクが高いです。og:description は必ず明示的に設定しましょう。文字数カウントスで og:title と og:description (文字数制限の考え方) の文字数を確認し、目安に収まっているかをチェックできます。
OGP 画像 (og:image) の設計
OGP 画像はリンクカードの見た目を決める要素で、テキストだけのリンクよりも占める面積が大きく、目に留まりやすくなります。
OGP 画像に含めるテキストは 20 〜 40 文字程度に絞るのが現実的です。カードはタイムライン内で縮小表示されるため、画像内の文字を詰め込むと小さな画面では判読できなくなります。記事のタイトルをそのまま画像に流し込むのではなく、核心部分だけを抜き出して配置します。
サイズの要件は、Facebook が公式ドキュメントで具体的な数値を示しています。最小で 200 × 200 ピクセル、高解像度端末での表示を考えると 1200 × 630 ピクセル以上、リンク投稿を大きな画像付きで表示させるには 600 × 315 ピクセル以上、縦横比はできるだけ 1.91:1 に近づける、ファイルサイズは 8 MB を超えないこと、と明記されています。以下の表は Facebook 以外の行を含みますが、Facebook 行以外は公式に数値として明記されていない項目もあり、2026 年 8 月時点で広く使われている実務値としてまとめたものです。
| プラットフォーム | 最小サイズ | 推奨サイズ | アスペクト比 |
|---|---|---|---|
| 200×200px | 1200×630px | 1.91:1 | |
| X (Twitter) | 144×144px (summary) / 300×157px (large) | 1200×628px | 1.91:1 |
| LINE | 200×200px | 1200×628px | 1.91:1 |
| Slack | 250×250px | 1200×630px | 1.91:1 |
- 画像サイズ: 1200×630px (横長) を基本とする。公式の上限は 8 MB だが、実務では 1MB 以下に抑えて読み込み速度を確保する
- テキスト配置: 画像の中央〜上部に配置し、下部はプラットフォームの UI と重なる可能性がある
- フォントサイズ: 最低 40px 以上を確保する
- 背景色: テキストとのコントラストを十分に確保する。WCAG AA 基準 (コントラスト比 4.5:1 以上) を目安にする
各プラットフォームのクローラーの挙動
OGP 情報を取得するクローラーは、プラットフォームごとに異なる挙動を示します。Facebook のクローラー (facebookexternalhit) は User-Agent ヘッダーで識別でき、JavaScript を実行しません。そのため、クライアントサイドレンダリング (CSR) で OGP タグを動的に生成しているサイトでは、OGP 情報が正しく取得されない問題が発生します。
X の Twitterbot、LINE のクローラー、Slack の Slackbot も同様に、返ってきた HTML をそのまま解析します。したがって「ブラウザで見ると OGP タグがある」ことは確認になりません。判定の基準は、curl などで取得した生の HTML に og: タグが含まれているかどうかです。
React や Vue.js などの SPA フレームワークを使用している場合、OGP タグはサーバーサイドレンダリング (SSR) または静的サイト生成 (SSG) で出力する必要があります。Next.js の generateMetadata や Nuxt の useHead を活用すると、フレームワークの仕組みの中で OGP タグを適切に出力できます。
OGP キャッシュの仕組みと更新方法
各プラットフォームは OGP 情報をキャッシュしており、ページの OGP タグを更新しても即座には反映されません。キャッシュの保持期間は 2026 年 8 月時点でいずれのプラットフォームも公式に数値を公開していないため、「何時間で切れるか」を前提にした運用は避けるべきです。実務では、期限切れを待つのではなく、明示的にキャッシュを更新する手段があるかどうかで対応を分けます。
- Facebook: シェアデバッガーで URL を入力し「もう一度スクレイピング」を実行すると、その場で再取得される。更新の確認手段が用意されている唯一の経路と考えてよい
- その他のプラットフォーム: 手動でキャッシュを破棄する手段が公式に用意されていない場合が多く、更新が反映されるまで待つことになる
- Slack: URL を再度貼り付けても古い内容が表示される場合がある。URL の末尾にクエリパラメータ (例:
?v=2) を付与することで別の URL として認識させる回避策がある
この非対称性から導かれる実務上の要点は、公開前に確認を済ませることです。公開後に og:title を直すと、直した内容がいつ反映されるか制御できません。特にキャンペーンや告知のように初速が重要なページでは、URL を人に配る前に自分でシェアしてプレビューを見ておくのが安全です。
OGP デバッグツールの使い方
OGP を設定したら、各プラットフォームのデバッグツールで表示を確認することが不可欠です。設定ミスに気づかないまま公開すると、シェアされるたびに意図しない表示が拡散されてしまいます。
主要なデバッグツールとその確認手順は以下の通りです。
- Facebook シェアデバッガー: URL を入力すると、og:title、og:description、og:image のプレビューが表示される。不足しているプロパティや小さすぎる画像が警告として報告されるため、まずここを通すのが基本
- LinkedIn Post Inspector: LinkedIn でのシェア表示と、取得されたメタデータの中身を確認できる
- 下書き投稿によるプレビュー: 検証ツールが用意されていない、または提供状況が変わったプラットフォームでは、投稿画面に URL を貼ってカードの表示を確認し、投稿せずに破棄するのが確実な手段になる
外部ツールに依存しない確認手段も 1 つ持っておくと安全です。curl で自分のページを取得し、返ってきた HTML に og: タグが含まれているかを見る方法は、クローラーが受け取る内容そのものを確認できるため、どのプラットフォームの事情にも左右されません。
公開前のチェックを 1 手順にまとめておくと漏れが減ります。文字数カウントスで og:title と og:description の文字数を確認し、デバッグツールまたは下書き投稿でカードの見え方を見る、という 2 段構えが基本です。
CMS 別の OGP 設定方法
主要な CMS やフレームワークでは、OGP タグの設定方法がそれぞれ異なります。
- WordPress: Yoast SEO や All in One SEO Pack などのプラグインで GUI から設定可能。投稿編集画面の「ソーシャル」タブで og:title と og:description を個別に指定できる
- Next.js:
generateMetadata関数でopenGraphプロパティを返すことで、ページごとに OGP タグを動的に生成できる - Nuxt:
useHeadコンポーザブルまたはnuxt.config.tsのapp.headで OGP メタタグを設定する - 静的 HTML:
<head>内に<meta property="og:...">タグを直接記述する。テンプレートエンジンを使用している場合は変数で動的に値を挿入する
動的 OGP 生成の注意点
ユーザーの入力やデータベースの値に基づいて OGP タグを動的に生成する場合、いくつかの注意点があります。
まず、HTML エスケープの徹底が必要です。og:title や og:description にユーザー入力を含める場合、<、>、&、" を適切にエスケープしないと、HTML インジェクションの脆弱性が生じます。
次に、og:image を動的に生成する場合 (例: Vercel OG Image Generation や Cloudinary の動的変換)、画像の生成に時間がかかるとクローラー側で取得が打ち切られる可能性があります。各社が待機時間を公開しているわけではないため、余裕を見込むという発想ではなく、初回アクセスでも即座に返る構成にしておくのが安全です。生成結果を事前にキャッシュするか、CDN 経由で配信します。
また、URL にクエリパラメータやフラグメントが含まれる場合、og:url には正規化された URL (クエリパラメータなし) を設定するのが推奨されます。これにより、同一コンテンツの異なる URL でシェア数が分散するのを防げます。
変わるのは仕様ではなく表示側
OGP を長く運用していると、「仕様が変わったから作り直しが必要」という話を目にします。しかし実際に変わってきたのは ogp.me の仕様ではなく、各プラットフォームの表示のほうです。og:title、og:type、og:image、og:url という必須プロパティの構成は公開当初から変わっておらず、書き方を書き換える必要が生じたことはありません。一方で、カードのレイアウトや画像の推奨サイズは、端末の解像度向上やアプリの改修に合わせて更新されてきました。
この非対称性は、メンテナンスの優先順位に直結します。タグの記述方法を見直す必要はほとんどなく、定期的に確認すべきなのは画像が意図した比率で表示されているかどうかです。特に古いサイトでは、当時の推奨サイズで作った画像が現在の大きなカードで粗く見えることがあります。タグは正しいのに見栄えが悪いという状態は、この経路で起きます。
OGP と Twitter Card の関係
X (旧 Twitter) は独自の Twitter Card メタタグ (twitter:card、twitter:title など) を持っていますが、Twitter Card タグが未設定の場合は OGP タグにフォールバックします。そのため、OGP タグを適切に設定しておけば、Twitter Card タグを省略しても基本的な表示は確保できます。ただし、twitter:card タグだけは OGP に対応するプロパティがないため、明示的に設定する必要があります。
よくある失敗パターン
- og:title と title タグを完全に同一にしてしまい、SNS 向けの書き分けの機会を使っていない。title タグは検索意図に沿った語を含む説明的な形、og:title はタイムラインで一瞬で内容が伝わる形に整えられます
- og:image を設定せずにシェアされ、プラットフォームが自動選択した画像が表示されてしまう。ロゴやアイコンなど記事内容と無関係な画像が選ばれると、リンクが何の情報なのか伝わりません
- og:url を設定しない、または相対パスで記述してしまう。og:url は必ず
https://から始まる絶対 URL で指定する必要があります。相対パスを指定すると、プラットフォームによっては URL の解決に失敗し、シェア数がページごとに分散する原因になります - og:type を省略する。ogp.me では og:type は必須プロパティとして定義されており、省略するとプラットフォーム側の既定の扱いに委ねることになります。ブログ記事には
articleを指定すると、公開日や著者情報といった種別ごとのプロパティも使えます
プロのテクニック
- og:title の冒頭に最も重要な語を置く。タイムラインは流し読みされ、かつ末尾が切り詰められる前提があるため、先頭に情報を寄せる書き方が両方に効きます
- OGP 画像の文字は面積を抑える。画像を余白なく文字で埋めると縮小表示で読めなくなるうえ、画像そのものが何のカードか伝える役割を果たせなくなります
- og:description はタイトルの繰り返しにしない。タイトルで示した主題の「中身」を 1 つ具体的に足すと、カード全体で伝わる情報量が増えます
- og:title を変えた前後で流入を見比べる。同一記事でも表現を変えると反応が変わるため、シェアが主要な流入経路になっているページでは、変更のたびに結果を記録しておくと判断材料が蓄積します
まとめ
OGP テキストの最適化で押さえるべき点は 2 つです。1 つは、ogp.me の仕様に文字数の上限は定義されておらず、プラットフォームも表示文字数を公式に公開していないという前提です。したがって「何文字までなら切れない」という発想では設計できません。og:title は全角 40 文字前後、og:description は 70 〜 100 文字前後という実務上の目安に収めつつ、どこで切れても主題が残る語順にしておくのが現実的な解になります。もう 1 つは、OGP タグが HTML の title タグや meta description とは独立している点です。検索結果向けとタイムライン向けで表現を書き分けられます。公開後の修正は反映時期を制御できないため、URL を配る前に自分でシェアしてプレビューを確認しておきましょう。文字数カウントスで og:title と og:description の文字数を事前に確認しておくと、想定より大きく超過した状態での公開を避けられます。