比較テクノロジー

2026年 Reels・Threads・IG ストーリー画質実測：4 アップロード経路の SSIM 差

公開日2026/4/1116 min read

まず結論から：数値で見る画質差

1本の動画（1080×1920、30fps、12Mbps）を4つの経路でMetaにアップロードしました。iPhone直接投稿、デスクトップWeb、Meta Business Suite、Bufferスケジュール投稿の4パターンです。

ダウンロードしてprobeをかけた結果、ビットレートは3.4 Mbpsから8.1 Mbpsまで。SSIMは0.912から0.967まで。

これは誤差ではなく、各経路の実装方針の違いです。

「高画質アップロードをオンにしましょう」というアドバイスはよく見かけますが、オンにしても経路によっては再エンコードが1回、2回、場合によっては3回かかります。40組のテストを実施して、この記事にまとめました。

テスト方法と素材仕様

数値の前提条件を明確にしておきます。

ソース素材

解像度：1080×1920（9:16縦型）
フレームレート：30fps（CFR、VFRではない）
コーデック：H.264 High Profile Level 4.2
ビットレート：12 Mbps CBR
音声：AAC 128kbps 44.1kHz ステレオ
長さ：30秒
内容：グラデーション空、テキスト、高速移動する人物（圧縮感度が異なる3種類のシーン）

素材はProResマスターからFFmpegで再エンコードしたもので、全経路に同一ファイルを使用。MD5で一致を確認済みです。

Probeコマンド

ダウンロードしたファイルに最初に実行するコマンドです：

ffprobe -v error \
  -select_streams v:0 \
  -show_entries stream=codec_name,width,height,r_frame_rate,bit_rate,profile,level,pix_fmt \
  -show_entries format=duration,bit_rate,size \
  -of default=noprint_wrappers=1 \
  sample.mp4

出力例：

codec_name=h264
profile=High
level=40
width=1080
height=1920
r_frame_rate=30/1
pix_fmt=yuv420p
bit_rate=4238912
duration=30.033000
size=15912104

SSIM計算コマンド

ダウンロードファイルとソース素材のSSIMを算出します（解像度の一致が必要）：

ffmpeg -i downloaded.mp4 -i source.mp4 \
  -lavfi "[0:v]scale=1080:1920:flags=lanczos[a];[1:v]scale=1080:1920:flags=lanczos[b];[a][b]ssim=stats_file=ssim.log" \
  -f null -

SSIMが1.0なら原本と完全一致、0.95を下回ると圧縮アーティファクトが目視で確認できるレベルです。注意点として、フレームレートを揃えずにSSIMを計算するとスコアが崩壊します。必要に応じてfps=30フィルタを追加してください。

4経路のビットレート実測結果

4経路、3製品、計12パターン。テストして分かった重要な発見は、Metaのトランスコード目標は「製品」単位で決まっていて「経路」単位ではないということです。ただし経路は「何回圧縮されるか」に影響します。

Reels：4経路の比較

アップロード経路	出力ビットレート	SSIM	pix_fmt	備考
iPhoneアプリ直接投稿	5.8 Mbps	0.951	yuv420p	1回のトランスコード
デスクトップWeb (instagram.com)	4.6 Mbps	0.937	yuv420p	ブラウザのWebCodecsで事前圧縮
Meta Business Suite	5.4 Mbps	0.948	yuv420p	やや保守的なトランスコード
Bufferスケジュール	3.4 Mbps	0.912	yuv420p	Buffer側で圧縮→Meta側で再圧縮

最良と最悪で2.4 Mbpsの差。これは測定誤差ではありません。

Bufferの結果が大幅に劣化する原因は、アップロード前にBuffer自身がH.264圧縮（約6 Mbps）を1回実行し、Metaが受け取った後にさらにトランスコードするためです。2回のロッシーエンコードが重なると、ディテールが確実に失われます。

Threads：4経路の比較

Threadsは少し特殊です。テキスト主体のプラットフォームという設計上、動画圧縮がそこまで厳しくありません。

アップロード経路	出力ビットレート	SSIM	備考
Threadsアプリ直接投稿	8.1 Mbps	0.967	最も多くのディテールを保持
デスクトップWeb (threads.net)	6.3 Mbps	0.955
Meta Business Suite	6.8 Mbps	0.958	2026年Q1以降対応
Bufferスケジュール	4.2 Mbps	0.925	二重圧縮の問題あり

Threadsアプリ直接投稿の8.1 Mbpsは正直驚きました。ReelsとThreadsが同じトランスコードパイプラインを使用していると想定していましたが、実測結果は違いました。

IGストーリーズ：4経路の比較

ストーリーズは「なぜかぼやける」という不満が最も多い領域です。データを見れば理由が分かります。

アップロード経路	出力ビットレート	SSIM	備考
iPhoneアプリ（高画質ON）	4.8 Mbps	0.942	設定で手動有効化が必要
iPhoneアプリ（デフォルト）	3.1 Mbps	0.918	大多数のユーザーがこの状態
デスクトップWeb	3.9 Mbps	0.928
Meta Business Suite	4.1 Mbps	0.932	インタラクティブスタンプ非対応
Bufferスケジュール	2.7 Mbps	0.905	最も低品質

デフォルトモードは高画質モードに比べてビットレートが35%低下します。iPhone 16 Proで4K撮影してもストーリーズがぼやける理由がこれです。撮影側がどれだけ高性能でも、アップロード側の設定が低ければ意味がありません。

設定方法はIGストーリーズ高画質シェアガイドに書いてあります。

なぜ経路で差が出るのか：技術的な仕組み

Metaのトランスコード処理は大きく3段階に分かれます。

1. クライアント側の事前エンコード

iPhoneのネイティブアプリはハードウェアアクセラレーションのVideoToolboxを使用し、最もディテールを保持します。ブラウザはWebCodecsを使いますが、多くの実装は保守的です。Chromium 130以降はH.264のハードウェアエンコードに対応していますが、Firefoxは現在もソフトウェアエンコードです。

具体的には：

ネイティブアプリ：ハードウェアH.264エンコード、ソースファイルのビットレートに追従
Web：ソフトウェアエンコード、アップロード速度のため5-6 Mbpsに圧縮
スケジューリングツール：自社の帯域コスト節約のためさらに低く圧縮

日本のモバイル環境では、docomo・au・SoftBankの5G回線なら帯域に余裕がありますが、混雑時にはアップロード自体が遅くなるため、スケジューリングツールの事前圧縮がさらに影響する場合があります。

2. サーバー側トランスコード

Metaはファイル受信後、製品ごとに異なる目標ビットレートを適用します：

Reels：フィード再生が主用途、目標4-6 Mbps
Threads：動画は主機能ではない、目標6-8 Mbps（余裕が大きい）
ストーリーズ：24時間限定コンテンツ、目標3-5 Mbps（最も厳しい）

つまり、同じ動画でもThreadsの方がストーリーズより画質が良いということです。直感に反しますが、実測データがそう示しています。

3. 再生時のアダプティブビットレート（ABR）

再生時にはネットワーク状況に応じてレンディションが切り替わります。高画質レンディションが常に存在するとは限らず、低トラフィックのアカウントではストーリーズに単一レンディションしかない場合もあります。

Buffer / Later等のスケジューリングツールは使うべきか

結論から言います：画質を重視するなら使わないでください。

スケジューリングツールはビジネスモデル上、アップロード帯域を節約する必要があるため、ほぼ全てがクライアント側で事前圧縮を行います。Buffer、Later、Hootsuite、SocialBeeの4社をテストしました：

ツール	事前圧縮ビットレート	無効化可能か
Buffer	約6 Mbps	不可
Later	約5 Mbps	不可
Hootsuite	約7 Mbps	Enterprise有料プランのみ可
SocialBee	約5.5 Mbps	不可

Hootsuiteは料金が高いぶん圧縮しないと予想していましたが、標準プランでは他社と同様に圧縮されていました。

スケジュール投稿が必要な場合、妥協案としてはMeta Business Suiteの内蔵スケジューラを使うことです。クライアント側の事前圧縮がありません。2025年Q4以降Threadsにも対応し、2026年は全製品のスケジュール投稿が揃った最初の年です。

実践的な推奨：製品別の最適経路

テストデータを意思決定表にまとめました：

投稿先	最適経路	次善	避けるべき
Reels（ブランドクリエイティブ）	iPhoneアプリ直接投稿	Meta Business Suite	Buffer / Later
Reels（日常投稿）	iPhoneアプリ直接投稿	デスクトップWeb	サードパーティスケジューラ
Threadsショート動画	Threadsアプリ直接投稿	Meta Business Suite	サードパーティスケジューラ
IGストーリーズ	iPhone高画質モードON	Meta Business Suite	デフォルトモード、Buffer

もう1つ知っておくべき点：iPhoneからストーリーズに直接投稿する際、素材がSDRではなくHDR10の場合、Metaは追加のトーンマッピング処理を行い、さらに画質が低下します。撮影時はSDR Rec.709を推奨します。パイプライン全体がHDR対応でない限り、HDRは避けてください。

自分でアップロード結果を検証する方法

私のデータを鵜呑みにする必要はありません。3ステップで自分で検証できます：

ビットレートが既知のソースファイルをアップロード
Web版から右クリックで保存（またはyt-dlpで取得）
本記事冒頭のffprobeコマンドとSSIMコマンドで検証

注意点：ストーリーズのダウンロードパスはMetaが意図的に複雑にしています。Chrome DevToolsのNetworkパネルで.mp4をフィルタリングすると見つかります。ReelsとThreadsは比較的簡単です。

より厳密な客観的画質評価（VMAF）を行いたい場合は、画像圧縮品質SSIM実測でVMAFの手順を解説しています。動画版も同じロジックで、psnrフィルタをlibvmafに置き換えるだけです。

lpic.ccの活用シーン

クリエイターやSNS担当者が、SlackやDiscordで「未圧縮のオリジナルファイル」を共有する場面は多いはずです。IGやThreadsに一度上げたものを共有すると圧縮後のファイルになってしまいます。そんなとき、オリジナルファイルをlpic.cc無料アップロードに上げて直リンクを共有すれば、元のビットレートを保持したまま共有できます。Metaの再エンコードを介しません。

制約も明記しておきます：lpic.ccにはファイルサイズ上限と保存期間があります（詳細は機能ガイド参照）。長期保存には向きませんが、「中間的な受け渡し」には最適です。

よくある質問

Q1：iPhone 4K HDRで撮影したのに、IGストーリーズがぼやけるのはなぜ？

3つの要因が重なっています。ストーリーズのデフォルト設定が高画質モードではないこと、Metaのストーリーズ向け目標ビットレートが元々低いこと、HDR10がSDRにトーンマッピングされてから再圧縮されること。対処法：高画質アップロードを手動で有効化＋撮影時にSDR Rec.709を使用。

Q2：Androidのアップロード画質はiPhoneより劣りますか？

実測では差は5%以内ですが、Androidはばらつきが大きいです。Pixel 8+やGalaxy S24+はハードウェアエンコードを使用し、iPhoneに近い結果が出ます。ミドルレンジ以下のAndroidはソフトウェアエンコードになるため、さらに10-15%低下します。

Q3：デスクトップでドラッグ＆ドロップと「ファイルを選択」で差はありますか？

差はありません。どちらも同じfetch APIを使用し、エンコード戦略は同一です。

Q4：ダウンロードしたReelsが9:16じゃないのはなぜ？

Reelsページで取得できるのはフィード版（1080×1350）で、オリジナルの9:16（1080×1920）ではありません。オリジナルのアスペクト比で取得するには、共有リンクに?utm_source=ig_embedを付けてダウンロードしてください。

Q5：SSIM 0.95と0.92の差は肉眼で分かりますか？

静止画キャプチャでは分かりにくいですが、再生中のグラデーション領域（空、肌のトーン）ではバンディングやブロックノイズが0.92では明確に見えます。テスト時の確認順序：まず空のグラデーション、次に顔の肌テクスチャ、最後に高速移動のエッジ。

Q6：なぜThreadsの方が画質が良いのですか？

推測ですが、プロダクト戦略の違いだと考えています。Threadsはまだユーザー獲得フェーズにあり、品質維持のためにCDNコストを多く投下する方針。ReelsとストーリーズはMetaの主要収益化プロダクトであり、CDN帯域コストがより厳しく管理されています。これは私の推測であり、Metaは具体的なビットレートポリシーを公開していません。

参考情報

テストデータ：2026年3月26日〜4月8日、東京（KDDI 1Gbps）・台北（ISP 1Gbps）の2拠点で各経路3回テストし中央値を使用。
FFmpeg公式ドキュメント libvmaf・ssimフィルタ：https://ffmpeg.org/ffmpeg-filters.html
Instagram Help Center：Video quality requirements（2026年2月版）
Meta for Developers：Reels API specs（2026年Q1更新）
Buffer、Later、Hootsuite、SocialBeeの動画圧縮に関する技術ドキュメント
関連テスト：IGストーリーズ高画質シェアガイド、画像圧縮品質SSIM実測

免責事項：本記事のデータは2026年4月時点の実測抽出です。Metaのトランスコードパイプラインはアップデートで変更される可能性があります。アカウント種別（個人/ビジネス/認証済み）、地域のCDNノード、アカウントのエンゲージメント履歴によっても実際のレンディションは異なります。必ずご自身のprobe結果で確認してください。

#Instagram Reels#Threads#IGストーリーズ#動画画質#SSIM#FFmpeg#Meta Business Suite#動画圧縮

著者

Brian Lee

技術アナリスト

画像フォーマット・圧縮技術・API 連携に特化し、データに基づいた分析を提供します。