追記: 2026年6月13日の最新情報
2026年6月13日時点でMeta for DevelopersのPage Insightsリファレンスを確認すると、複数のPage Insights指標が2026年6月15日までに全APIバージョンで非推奨になり、対象指標を呼び出すとinvalid metric errorになると案内されています。Graph API v25.0発表ブログでは「2026年6月末までにPage Viewer Metricを導入予定」と説明されているため、実務では6月15日を前倒しの確認期限として扱うのが安全です。
まず、レポート基盤やSNS管理ツールで旧Reach、Impressions、unique系のmetric名を直接呼んでいないかを棚卸ししてください。置き換え候補としては、公式リファレンスに掲載されているpage_total_media_view_unique、post_total_media_view_unique、page_media_view、post_media_viewなどを確認します。ただし、期間、breakdown、過去比較の扱いは指標ごとに異なるため、Deprecated Metricsページだけで判断せず、実際のAPIレスポンスと公式ドキュメントを合わせて確認してください。
このテーマをもう少し広げて見るなら、Meta広告のComscore Markets移行とは？自動車モデル広告のDMA廃止で確認すること と Meta公式ニュースの読み方：提供開始、対象ユーザー、価格・仕様変更を確認する手順 も合わせて確認してください。Marketing APIや広告レポート側でも、地域指定や仕様変更の棚卸しが必要になります。
Meta for DevelopersはGraph API v25.0とMarketing API v25.0の発表の中で、2026年6月末までにGraph APIへPage Viewer Metricを導入する予定を示しています。あわせて、従来のページ、投稿、動画関連のReachやImpressions系指標の一部は、2026年6月に廃止予定とされています。
この記事では、Facebookページ、投稿、ストーリーズ、動画のInsightsをAPIや外部ツールで取得している読者向けに、どのmetric名を棚卸しすべきか、過去比較をどう扱うべきか、Meta公式資料と外部ツール側の告知をどう切り分けるべきかを整理します。Meta Watch JapanはMeta Platformsおよび関係会社とは非提携です。
3行まとめ: Reachの単なる名前変更ではなく、レポート定義の見直しが必要
`page_total_media_view_unique`、`post_total_media_view_unique`、Stories Insightsの追加metricを確認します。
ページ、投稿、動画のReach/Impressions系やunique系指標が残っていないかを探します。
Meta公式情報、changelog、reference、外部ツールの対応表を分けて読みます。
metric名の置き換えだけでなく、保存先、表示名、過去比較の説明まで一緒に見直します。
- Meta公式ブログでは、2026年6月末までにPage Viewer MetricをGraph APIへ導入する予定と説明されています。中心になる確認対象は
page_total_media_view_unique、post_total_media_view_unique、Stories InsightsのPAGE_STORY_TOTAL_MEDIA_VIEW_UNIQUEです。 - 2026年6月に廃止予定とされる旧指標には、ページや投稿のReach/Impressions系、3秒以上視聴した人のunique系指標が含まれます。古いAPIバージョンに固定していても、旧metric名を呼んでいる場合は確認が必要です。
- 外部SNS管理ツールの対応記事は、現場の需要シグナルとして有用です。ただし、日付、表示名、再マッピングの扱いはツールごとに違うため、Meta公式の仕様としてはMeta for Developersのブログ、changelog、referenceを優先して確認します。
2026年6月に何が変わるのか
- 2026年2月18日
Meta for DevelopersがGraph API v25.0とMarketing API v25.0を発表しました。
- 2026年6月
旧来のページ、投稿、動画関連のReach/Impressions系metricが廃止予定とされています。
- 2026年6月末まで
Page Viewer MetricをGraph APIへ導入する予定として説明されています。
- 公開前確認
Graph API changelogとInsights referenceで、実際の追加状況と廃止対象を確認します。
発表日、導入予定、廃止予定を混同せず、実装直前は最新の開発者向け情報で確認します。
今回の変更は、Graph APIを使う開発者だけの小さな仕様変更ではありません。FacebookページやInstagramを含むレポート基盤で、Reach、Impressions、動画のユニーク視聴者数を使っているチームに影響します。
Meta for Developersの公式ブログは、2026年2月18日にGraph API v25.0とMarketing API v25.0を発表しました。その中で、Graph APIにPage Viewer Metricを導入する予定と、旧来のページ、投稿、動画関連指標を2026年6月に廃止する予定が示されています。
ここで大切なのは、発表日、導入予定、廃止予定を分けて読むことです。2026年6月10日JST時点では、この記事では公式ブログの予定情報を軸にしつつ、運用前にはGraph API changelogとInsights referenceで最新状態を再確認する前提で書きます。
Page Viewer MetricがGraph APIに追加される
根拠として見ること
Metaの説明では、Page Viewer Metricは従来のReach指標を置き換え、FacebookとInstagramの間で、コンテンツを見た利用者数をより一貫して測るための指標として位置づけられています。
確認するmetric名
公式ブログで示されている中心的なmetric名は、ページ単位のpage_total_media_view_unique、投稿単位のpost_total_media_view_unique、Stories InsightsのPAGE_STORY_TOTAL_MEDIA_VIEW_UNIQUEです。いずれも「見た人」に近い概念を持ちますが、旧Reachや旧Impressions uniqueと完全に同じ定義として扱うのは危険です。
旧Reach/Impressions系指標が廃止対象になる
同じ公式ブログでは、ページや投稿のReach/Impressions系指標、動画の3秒以上視聴した人のunique系指標について、2026年6月に廃止予定と説明されています。廃止後は、media viewsやmedia viewers系の新しい指標へ移行する整理です。
このため、記事や社内資料で「Reachが消える」と大きく言い切るより、Graph APIで取得している旧metric名が廃止対象に入っているかを確認するほうが実務的です。管理画面や外部ツール上の表示名は残る場合があり、裏側で新しい指標へ再マッピングされる可能性もあります。
古いAPIバージョンに固定していても確認が必要
Graph APIにはバージョン管理があります。通常は、呼び出しパスにv25.0のようなバージョン番号を入れることで、どのバージョンの挙動を使うかを指定できます。
評価基準
ただし今回の旧metric廃止について、公式ブログは「すべてのAPIバージョン」で2026年6月に廃止される予定と説明しています。つまり、古いバージョンに固定しているから大丈夫、とは読めません。自社コード、ETL、外部ツール連携、ダッシュボードで旧metric名を使っていないかを確認する必要があります。
Page Viewer Metricは何を置き換えるのか
`unique`という語だけで旧Reachと同じと判断せず、集計対象、期間、粒度を確認します。
Page Viewer Metricは、旧Reach/Impressions系指標の単なる日本語名変更ではありません。名称が近くても、集計対象、期間、粒度、過去比較の扱いが変わる可能性があります。
特に、uniqueという語だけで「旧Reachと同じ」と判断しないことが大切です。旧指標と新指標を同じ折れ線グラフにつなげると、実績が変わったのか、指標定義が変わったのか、後から説明できなくなることがあります。
ページと投稿はtotal media view uniqueへ寄る
確認項目
ページ単位ではpage_total_media_view_unique、投稿単位ではpost_total_media_view_uniqueが中心的な確認対象になります。これらは、ページや投稿のコンテンツを見た利用者数を扱う新しい指標として説明されています。
注意点
ただし、旧page_impressions_uniqueや旧post_impressions_uniqueを、そのまま新metricへ置き換えて前年比を続けるのは避けたほうが安全です。新旧の定義が完全に一致するとは限らないため、切り替え月には「指標定義変更」の注記を残すべきです。
ストーリーズはStories Insightsの追加metricを見る
Stories Insightsでは、PAGE_STORY_TOTAL_MEDIA_VIEW_UNIQUEが追加予定のmetricとして示されています。ページ投稿とストーリーズでは、取得エンドポイント、保存期間、集計粒度が異なる場合があります。
そのため、ページ、投稿、ストーリーズをまとめて「ReachからViewerへ移行」と一括処理するより、利用しているエンドポイントごとに棚卸しするほうが現実的です。特にストーリーズは、短期保存や期間指定の扱いが通常投稿と違うことがあるため、レポート基盤では別枠で確認してください。
media viewsとmedia viewersを分けて読む
Metaの説明では、廃止後の移行先としてmedia viewsとmedia viewers系の新しい指標が示されています。大まかには、media viewsは表示回数寄り、media viewersは見た人の数寄りとして読み分けると理解しやすくなります。
ただし、実装や公式リファレンス上の定義は必ず確認が必要です。「view」という語があるから動画再生だけの話、「viewer」という語があるからページプロフィール訪問者数、とは読みません。この記事では、コンテンツを見た利用者数を一貫して扱う指標という文脈で整理します。
どのレポート基盤が影響を受けるか
- 1Graph API
`/insights`のmetric配列、SDKラッパー、環境変数を確認します。
- 2ETL/バッチ
取得ジョブ、再試行処理、欠損時の補完処理を確認します。
- 3DWH
保存先カラム、SQLビュー、集計テーブルに旧metric名がないかを見ます。
- 4BI/ダッシュボード
計算フィールド、列名、アラート、月次グラフの表示名を確認します。
- 5SNS管理ツール
ベンダー側の再マッピング、CSV出力、API連携の扱いを確認します。
- 6クライアント報告
PDFテンプレート、説明文、前年比コメントに旧Reach前提が残っていないかを見ます。
コードだけでなく、設定、SQL、ダッシュボード、説明資料まで同じ棚卸し対象です。
影響を受けるのは、Graph APIを直接叩いているコードだけではありません。APIから取り込んだデータをDWHに保存し、BIツールや月次レポートで表示し、クライアント向けに説明している場合、変更点は複数の層に広がります。
まずは、/insightsを呼んでいる場所と、旧metric名が残っている場所を分けて探すのが近道です。コードの中だけでなく、JSON設定、SQLビュー、スプレッドシート、ダッシュボードの計算フィールド、PDFテンプレートにも残っていることがあります。
Graph APIを直接呼んでいるコード
確認項目
最初に見るべき場所は、Graph APIの/insightsエンドポイントを呼んでいるコードです。metric配列、クエリパラメータ、SDKのラッパー関数、環境変数、バッチジョブの設定を確認します。
注意点
たとえば、page_impressions_unique、page_posts_impressions、post_impressions_unique、page_video_views_uniqueのような旧metric名が定数や設定ファイルに入っている場合、廃止時にエラー、空値、欠損、列の消失が起こる可能性があります。実際の挙動は公開時点のchangelogと検証環境で確認してください。
SNS管理ツールやレポートSaaS
Sprout Socialなどの外部ツールも、2026年6月のFacebook metric deprecationsに関するヘルプを出しています。これは、運用現場で影響が出ることを示す需要シグナルとして重要です。
ただし、外部ツールの記事に書かれた日付や表示名を、そのままMeta公式仕様として扱ってはいけません。ツール側では、旧Reach表示を新しいTotal Unique Media Viewsへ再マッピングする、特定プランの指標を非対応にする、CSVエクスポートの列名を変える、といった独自の対応が起こり得ます。
自社ダッシュボードとクライアント報告
API取得だけを直しても、ダッシュボードや報告文が古いままだと、利用者には「数字が急に変わった」と見えます。Looker Studio、Tableau、Power BI、BigQuery、Snowflake、社内管理画面、Slack通知、月次PDFの凡例まで確認したほうが安全です。
特に、前月比、前年比、キャンペーン比較、投稿ランキングに旧Reachや旧Impressions uniqueを使っている場合は、切り替え月の扱いを決めておく必要があります。旧指標と新指標を同じKPI名で出し続けると、後から説明が難しくなります。
移行前に棚卸しするmetric名
metric名、保存先カラム、表示名、集計SQL、説明文を同時に棚卸しします。
公式ブログには廃止予定のmetric名が多数並んでいます。この記事ではすべてを再掲するのではなく、代表例と確認観点に絞ります。完全なリストはMeta for Developersの公式ブログとGraph API changelogで確認してください。
棚卸しでは、metric名そのもの、保存先カラム、レポート上の表示名、集計SQL、説明文の4つを同時に見ます。metricだけ置き換えても、表示名が旧Reachのままだと読者や顧客に誤解を残します。
Page InsightsのReach/Impressions系
Page Insightsでは、page_impressions_unique、page_impressions_paid_unique、page_impressions_viral_unique、page_posts_impressions、page_posts_impressions_uniqueなどが代表的な確認対象です。
注意したいのは、paid、organic、viral、nonviralのような内訳です。旧metricでは細かく分けられていた指標が、新しいmedia viewers系でも同じ粒度で取れるとは限りません。広告運用レポートやオーガニック分析では、内訳が必要かどうかを先に決めておく必要があります。
Post InsightsのReach/Impressions系
Post Insightsでは、post_impressions_unique、post_impressions_paid_unique、post_impressions_fan_unique、post_impressions_organic_uniqueなどが確認対象になります。
投稿別ランキング、キャンペーン別集計、クリエイティブ比較でこれらを使っている場合、切り替え後のKPI名をどうするかを決めます。旧Reachと新しいmedia viewersを同じ「到達人数」として見せる場合でも、レポート脚注には定義変更を残したほうがよいです。
3秒以上視聴した人のunique系指標
動画レポートでは、page_video_views_unique、post_video_views_unique、total_video_views_unique系の指標を確認します。これらは「3秒以上視聴した人」の文脈で使われてきたため、media view系への移行時に、再生開始、表示、視聴継続のどれをKPIにするのかを見直す必要があります。
「動画の見られ方」は、再生回数、視聴者数、完了率、平均視聴時間で意味が変わります。旧unique video viewer系を新しいmedia viewersへ置き換えるときは、動画の成果説明まで合わせて更新してください。
数値の見え方はどう変わるか
切り替え前後で同じ期間を見ていても、指標定義が変われば比較条件が変わります。
ページ、投稿、ストーリーズ、動画で取得粒度が同じかを確認します。
旧Reach、旧Impressions、media views、media viewersを分けて読みます。
前月比や前年比を続ける場合は、2026年6月の指標定義変更を明記します。
グラフの段差は実績変化ではなく、指標定義の変更で起きることがあります。
この変更で一番起こりやすい問題は、APIエラーよりも、ダッシュボード上の数字の段差です。旧指標と新指標の定義が違う場合、切り替え月だけ急に数字が増減して見えることがあります。
数字が変わったときに、コンテンツの実績が変わったのか、指標定義が変わったのかを切り分けられるようにしておくことが重要です。半年後にグラフを見返した人が、なぜ段差があるのかを追える状態にしておきます。
過去比較は注記なしでつなげない
評価基準
旧post_impressions_uniqueから新post_total_media_view_uniqueへ移る場合、同じ投稿別の「見た人」らしい指標に見えても、定義が完全に一致するとは限りません。
レポート上の注意点
前月比や前年比を続けるなら、切り替え日をグラフ上に入れ、レポート本文にも「2026年6月に指標定義を変更」と明記します。過去データを新指標で再取得できない場合は、旧系列と新系列を分けて表示する判断も必要です。
paid、organic、viral、nonviralの内訳に注意する
旧metricでは、paid、organic、viral、nonviralの内訳を使って、広告配信、自然拡散、シェア経由の反応を分けて説明していたチームもあります。
新しい指標で同じ内訳が取れない、または定義が変わる場合、レポート列を減らす、別指標で補う、広告側のデータソースと組み合わせる、といった対応が必要です。特に広告運用レポートでは、「organicが落ちた」「paidが伸びた」といった説明を旧定義のまま続けないよう注意してください。
ツール側のTotal Reach表示は公式metric名と照合する
外部ツールが「Total Reach」や「Page Reach」のような表示名を残していても、裏側でどのMeta metricに再マッピングされているかはツールごとに異なります。CSVエクスポート、API連携、レポートテンプレートでは、表示名だけではなく計算元を確認してください。
Sprout Socialのヘルプは、外部ツール利用者がどのような影響を受けるかを知る材料になります。ただし、Sprout内のプラン名、日付、列名はSprout利用者向けの説明です。Meta公式の廃止対象や新metric定義は、Meta for Developersで確認します。
今月中に開発者が確認すること
急いでコードだけを書き換えるより、取得、保存、表示、説明を分けて確認します。
2026年6月中にやるべきことは、急いでコードを書き換えることだけではありません。まず旧metricの使用場所を棚卸しし、次に移行先の定義を確認し、最後にレポート上の説明を変える流れが安全です。
API、DWH、BI、外部ツール、顧客説明を別々に見ると、作業の抜けが減ります。特に、API側の修正を担当する人と、月次レポートを説明する人が違う組織では、定義変更の共有が遅れやすいです。
APIリクエストとバッチ処理を棚卸しする
まず、/insightsを含むAPIリクエストを探します。metric配列、保存先カラム、NULL許容、再試行処理、ジョブ失敗時のアラート、データ欠損時の補完処理を確認してください。
旧metric廃止後の挙動がエラーになるのか、空値になるのか、レスポンスから消えるのかは、実際の公開状況と検証結果で確認する必要があります。この記事では、公式ブログの予定だけを根拠に実装済みの挙動までは断定しません。
DWHとBIのスキーマを更新する
次に、保存先のスキーマを見ます。旧metric列を残して新metric列を追加するのか、ビューで吸収するのか、過去データを別系列として持つのかを決めます。
おすすめは、過去データを上書きしないことです。旧Reach系列は旧Reach系列として残し、新しいmedia viewers系列は新しい列として保存し、切り替え日をメタデータとして持たせると、あとから説明しやすくなります。
外部ツール利用者はベンダーの対応表を見る
SNS管理ツールやレポートSaaSを使っている場合は、ベンダー側の対応表を確認します。どの指標が廃止、置換、再マッピング、非対応になるのか、CSVエクスポートやAPI連携では列名が変わるのかを見てください。
ここでも、外部ツールの説明をMeta公式仕様として扱わないことが重要です。ツールが表示を維持していても、過去値と新値の連続性、集計粒度、対象プランは別問題です。
検証手順と更新履歴の残し方
未来の担当者が、数字の段差と定義変更を後から追える状態にします。
今回の変更は、公開直前や公開後に追加情報が出る可能性があります。公式ブログだけで作業を完了扱いにせず、Graph API changelogとInsights referenceを定期的に確認してください。
社内では、指標を切り替えた日、変更したmetric名、レポート上の表示名、影響したダッシュボードを残します。未来の自分や別チームが、数字の段差を説明できるようにするためです。
changelogで日付と対象metricを再確認する
Graph API changelogでは、利用可能なバージョン、導入日、廃止予定、バージョン別の注記を確認できます。v25.0は2026年2月18日に導入されたバージョンとして掲載されています。
公開時点で、旧metric廃止日や新metric追加の詳細がブログから変わっている場合は、changelogやreferenceのほうを優先してください。ブログは発表時点の予定を示す入口であり、実装直前の細部は更新履歴やリファレンスで補う必要があります。
Insights referenceで取得可否を確認する
取得条件
Page Insights referenceでは、Page Insightsデータは100 likes以上のページで利用できること、ほとんどの指標は24時間に一度更新されること、取得できるInsightsデータは過去2年分であること、sinceとuntilを使う場合は一度に90日分までであることなどが説明されています。
権限とタスク
また、必要な権限として、Page access token、read_insights、pages_read_engagement、PageのANALYZEタスクが示されています。新metricを使う場合も、実際の対象ノード、period、戻り値、必要権限をreferenceで確認してから運用へ入れてください。
自社の更新履歴に切り替え日を残す
社内Wiki、データカタログ、BI定義、顧客向けレポートの注記に、旧指標から新指標へ切り替えた日付を残します。たとえば、「2026年6月以降、Facebook Page Reach相当の指標はMetaの新しいmedia viewers系指標へ変更」といった説明です。
ただし、説明文でも「相当」という語に頼りすぎないほうが安全です。旧指標と新指標が完全に同じものではない場合、前後比較の解釈には注意が必要だと明記してください。
よくある誤解と短い答え
この記事では、ページ、投稿、ストーリーズのmedia view unique系の文脈として確認します。
Graph API上の旧Reach/Impressions系metricの廃止予定として読みます。
APIバージョンだけでなく、旧metric名、保存先列、表示名、説明文の更新が必要です。
外部ツールは運用影響の参考にし、公式仕様はMetaの開発者向け情報で確認します。
広い断定ではなく、どのmetric名、どの画面、どのツールの話かを分けて確認します。
この変更は、名前が似た指標や外部ツールの表示名が絡むため、誤解しやすいところがあります。実務では、広い断定よりも「どのmetric名の話か」「どの画面やツールの話か」を分けるほうが安全です。
Page Viewer Metricはページプロフィールの訪問者数なのか
この記事では、Page Viewer Metricをページプロフィール訪問者数の分析機能として扱いません。Meta公式ブログの説明では、コンテンツを見た利用者数について、FacebookとInstagramの間で一貫した測定値を提供する文脈です。
「viewer」という語だけを見ると、ページを訪れた人の数のように読めます。実際には、ページ、投稿、ストーリーズのInsightsで示されるmedia view unique系の文脈として確認してください。
Reachはもう一切使えなくなるのか
そうは書けません。今回の記事で扱っているのは、Graph API上の旧Reach/Impressions系metricの廃止予定です。管理画面、外部ツール、広告レポート上の表示名がどうなるかは、それぞれ別に確認が必要です。
特に外部ツールでは、見慣れた表示名を残したまま、裏側の計算元を新しい指標へ変えることがあります。表示名だけで判断せず、データソースと定義を見てください。
Graph API v25.0に上げれば対応完了なのか
バージョンを上げるだけでは完了ではありません。旧metric名を使っているAPIリクエスト、保存先カラム、BIの計算式、レポート名、説明文、アラートまで確認する必要があります。
また、公式ブログでは旧指標がすべてのAPIバージョンで廃止予定とされています。古いバージョンに固定している場合も、旧metric名を使っていれば影響対象として扱ってください。
Sprout Socialなどの記事の日付をMeta公式期限として書いてよいか
書かないほうが安全です。Sprout Socialなどのヘルプは、そのツールの利用者にとって重要な運用情報ですが、Meta全体の公式仕様ではありません。
外部ツール記事は、現場で何が問題になっているかを知る手がかりとして使います。廃止対象、導入予定、metric名、公式期限はMeta for Developersの公式ブログ、Graph API changelog、Graph API referenceで確認してください。
次に読むなら
参照した主な情報源
- Meta for Developers Blog: Introducing Graph API v25.0 and Marketing API v25.0
https://developers.facebook.com/blog/post/2026/02/18/introducing-graph-api-v25-and-marketing-api-v25/
- Graph API changelog
https://developers.facebook.com/docs/graph-api/changelog/
- Graph API Insights reference
https://developers.facebook.com/docs/graph-api/reference/insights/
- Graph API overview
https://developers.facebook.com/docs/graph-api/overview/
- Social Media Today: Meta Updates Marketing API To Align With Latest Ad Shifts
https://www.socialmediatoday.com/news/meta-updates-marketing-api-to-align-with-latest-ad-shifts/812648/
- Sprout Social Support: Facebook Metric Deprecations June 2026
https://support.sproutsocial.com/hc/en-us/articles/45863997056397-Facebook-Metric-Deprecations-June-2026
確認日: 2026年6月10日JST。Meta公式資料を事実確認の中心にし、Social Media TodayとSprout Socialは需要シグナルおよび外部ツール利用者の影響確認として扱いました。
更新履歴
- 2026年6月10日
Meta for DevelopersのGraph API v25.0告知、Graph API changelog、Insights reference、Graph API overviewを確認して初回作成しました。
- 次回確認
旧metric廃止予定、Page Viewer Metricのreference反映、外部ツール側の再マッピング状況に追加情報が出た場合に更新します。
予定情報を扱う記事では、確認日と次回確認ポイントを残して読み返せるようにします。
- 2026年6月10日: Meta for DevelopersのGraph API v25.0告知、Graph API changelog、Insights reference、Graph API overviewを確認して初回作成しました。
- 次回確認: 2026年6月中の旧metric廃止予定、Page Viewer Metricのreference反映、外部ツール側の再マッピング状況に追加情報が出た場合、該当セクションを更新します。