Instagramフィードウィジェット比較｜8つを同じページに設置して実機検証しました【2026年版】

この記事は Englishと 한국어でもお読みいただけます。

比較対象は、Instagramフィードウィジェットを探すときに繰り返し名前が 挙がる8つです。CollectSocials、Elfsight、Curator.io、Taggbox (Tagembed)、EmbedSocial、Flockler、Juicer.io、Walls.ioです。Webサイトへの 設置を目的に作られた製品だけを対象にし、ウィジェット機能が付随的に 付いているソーシャル運用ツールは除いています。

はじめに確認すべきは「公式APIかどうか」です

日本語でツールを探すと、比較記事の多くが最初に同じ注意点を挙げています。 非公式な方法でInstagramの投稿を取得するツールは、アカウント側の リスクを伴う可能性がある、という指摘です。長く運用する前提であれば、 Metaが提供する公式APIを使っているツールを選ぶ、というのが出発点に なります。

これは比較表の見た目からは判断できない項目です。レイアウト数や価格は 紹介ページに書いてありますが、投稿をどこから取得しているかは書かれて いないことがあります。したがって、導入前に「投稿の取得に公式APIを使っていますか」と直接確認するのが確実です。

CollectSocialsについては、Metaの公式Graph APIのエンドポイントのみを 使用しており、スクレイピングは行っていません。これは社内の方針として 明文化しており、Meta関連のコードに触れるたびに自動チェックを走らせて います。他社の実装について私は断定できる情報を持っていないので、 ここでは自社側のことだけを申し上げます。確認は各社にお願いします。

ここから先は、導入したあとで効いてくる項目です。いずれも一度選ぶと あとから変えにくいものばかりです。

実際に見るべき項目

描画方式。 比較記事ではほとんど触れられませんが、ウィジェットがサイト上でどう 振る舞うかを最も大きく左右します。クロスオリジンのiframeは閉じた箱で、 こちらのCSSは中に届かず、中身もページ側からは見えず、サイトの フォントも継承しません。スクリプト設置方式はページ内に直接描画される ため、代わりにCSSの分離が重要になります。

CSSの分離。 購入前に確認する方はほとんどいませんが、問題が起きてから気づく項目です。 分離がないと、サイト側のCSSがウィジェットを壊し、ウィジェット側のCSSが サイトに漏れ出します。ブラウザが正式に用意している分離の仕組みが Shadow DOMで、iframeでも分離はできますが高さの固定やフォントを 継承できないという代償があります。

複数のプラットフォームを1つにまとめられるか。 Instagramだけを載せて終わるサイトはあまりありません。Googleの口コミや Facebookの投稿、YouTubeの動画も並べたくなることが多く、そのときに プラットフォームごとにウィジェットを買って別々に貼る製品と、1つの フィードにまとめられる製品とでは運用の手間がまったく違います。

投稿を選び、文言を直せるか。 投稿したものが全部自動で流れ込むのは、選別とは言いません。どの投稿を 出すかを選べること、そしてInstagram向けに付けたハッシュタグの束を Webサイト側では外せることが、実運用では効いてきます。

ファイル数。 描画が始まる前にいくつのファイルを取りに行くかです。フィードの中身に よって変動しないため、ページ速度スコアよりもはるかに安定した比較軸に なります。

表示回数の上限。 最後に気づく費用です。たいていは、ページが初めてよく見られた月に 判明します。後述します。

描画方式とファイル数

この節にはもともとページ速度スコアも載せていましたが、取り下げました。 理由をお伝えするほうが、スコアそのものより役に立つと思います。8つのうち 2つはクロスオリジンのiframe内で描画され、残る6つはページにスクリプトを 設置します。iframeは処理をページのメインスレッドの外に出すため、 ページ速度の計測では構造的に有利に出ます。この2つを同じスコアで 並べても、どちらがiframeかが分かるだけで、どちらが自分のサイトに 適しているかは分かりません。

再現性の問題もあります。自社のウィジェットだけをレイアウトと配置位置を 変えて測り直したところ、中身がまったく同じページのスコアが大きく振れました。 フィードの画像の1枚が最初の画面で最大の要素になるかどうかで決まっていた からです。当社が何らかの数字を載せても、皆さまのページでは再現しません。 再現しない数字を信用しないのは、正しい判断です。

そこで現在は、動かないものだけを載せています。どう描画されるか、 いくつファイルを読み込むか、スタイルが分離されているかの3点です。

ファイル数はフィードの中身で揺れる測定値ではなく、設計上の決定です。 22個と1個の差は、何かが描画される前に往復が21回多いということであり、 回線が速くなってもその差は縮みません。2026年5月の観測で、今回の更新で 再確認しています。

契約前に確認しておきたい機能の差

価格やプランと違い、以下は製品がその機能を持っているかどうかの問題なので、 あとからプランを上げても解決しません。とくに1行目は、Googleの口コミも 併せて表示するご予定があるなら契約前に必ずご確認ください。

Curator.ioとFlocklerはGoogleの口コミに対応していません。どちらも別の 用途では良い選択ですが、InstagramとGoogleの口コミを同じページに並べる ご計画であれば、この2製品は最初から候補から外れます。Taggboxは試用の 開始時にカードの登録を求められます。

CSS分離テスト

ホストページ側に次のCSSをあてて、各ウィジェットが耐えるかを確認しました。

* { font-family: "Comic Sans MS", cursive !important; }
img { border: 5px solid red !important; border-radius: 0 !important; }
a { color: magenta !important; text-decoration: line-through !important; }
div { background-color: yellow !important; }

このCSSをあてても通常どおり描画されれば分離ができており、黄色い背景の Comic Sansだらけになれば分離がない、ということになります。

この表で最も重要なのは次の点です。 Flockler、Taggbox、Juicer.io、EmbedSocialの4社は、設置コードを2種類 用意しています。JavaScriptのコードとiframeのコードです。4社とも iframeのコードなら完全に分離されます。ところが既定として案内されるコードは、はじめの3社では分離が一切ありません。つまり同じ製品を使っていても、どちらのコードを貼ったかで結果が まったく変わります。この3製品をお使いの場合は、必ずiframeのコードを お使いください。

EmbedSocialのJavaScriptコードは、残りの3社よりは良好です。中身自体は iframe内で描画されるためです。ただしスクリプトの読み込み中は embedsocial-hashtag クラスのラッパー要素がページのDOMに露出しており、その間はサイト側のCSSが その領域に影響します。EmbedSocial側のスタイルシートがそのラッパーに position: relative を設定してもいて、これは小さいながら外側に漏れる側の例です。最初から きれいに分離したい場合は、iframeのコードを直接お使いください。

以前の版で誤っていた点を訂正します。 私は以前、ElfsightがCSS分離のためにiframeを使っていると書いていましたが、 実際に検証したところ誤りでした。Elfsightは eapps-instagram-feed-container のようなクラス名を持つ通常の要素としてページのDOMに直接描画され、 shadow rootもiframeもありません。テストCSSをあてるとウィジェット全体が 黄色い背景のComic Sansになりました。これをあえて書くのは、Elfsightが この分野で最も広く使われている製品のひとつでありながら、iframeを使うと いう記述が複数のレビュー記事にそのまま載っているからです。検証せずに 書き写されたものと思われます。

CollectSocials

向いている場合: デザインをある程度サイトに合わせたい、複数の プラットフォームを1つのフィードにまとめたい、サイトのCSSと衝突させたく ない、という場合。

私が作っている製品なので、この節は検証で確認できた事実だけを書きます。 8つの中で唯一Shadow DOMを使っており、その内側には継承される各プロパティを すべて initial に戻すリセットが入っています。テストCSSをあてたとき、ページの他の部分が 黄色くなる中でウィジェットだけが通常どおり描画されました。iframeを使わずに この結果になったのはこの製品だけです。

読み込むファイルは1つで、その後に追加で読み込むものはありません。Cookieを 設定せず、localStorage と sessionStorage にも何も書き込みません。この3点はフィードの中身にも設置場所にも左右されない ため、書面で明言できる項目でもあります。Cookieを置かないことは近年とくに 意味があります。ウィジェットがCookieを置いた時点で、そのサイトの同意 バナーの対象範囲に入るからです。

投稿の文言をその場で編集できるのも、この比較ではこの製品だけでした。 Instagram向けに付けたハッシュタグの束をWebサイト側では外したり、終了した キャンペーンの文言を消したり、Webサイトの読み手向けに書き直したりできます。 実際のInstagramの投稿には手を加えません。他の製品はInstagramに投稿された 文言をそのまま表示します。

現在対応しているのはInstagram、X（旧Twitter）、TikTok、YouTube、Googleの 口コミ、Pinterest、Vimeo、Tumblr、RSS、Facebookです。これらを1つの ウィジェットにまとめられるため、プラットフォームごとに埋め込みを縦に 積んでいく代わりに1か所に収まります。レイアウトもグリッド1種類ではなく、 メイソンリーやカルーセル、マーキーのように性格の異なるものから選べるので、 フィードをページのどこに置くかに合わせられます。テーマは無料プランでも すべて開放されています。

限界もお伝えします。 連携できるソース数にはプランごとの上限があり、多数のアカウントを運用されて いる場合は最下位の有料プランでは足りません。SSOやSAMLには対応しておらず、 データ処理に関する契約書もご用意していないため、企業の導入審査の基準に よっては候補から外れます。LinkedInにはまだ対応していません。そして ファイルを1つしか読み込まないことは、軽いという意味ではありません。動画の 多いフィードは写真のフィードより負荷が大きく、これは8製品のどれでも同じです。

Elfsight

向いている場合: 初期費用を最優先し、1つのサイトにInstagramだけを載せれば よく、CSS分離がないことを許容できる場合。

ElfsightはInstagram専用のツールではなく、ウィジェットのマーケットプレイスです。 数百種類のWebサイト用ウィジェットを提供しており、Instagramフィードはその ひとつです。この構造が強みであり、この文脈での限界でもあります。

利点ははっきりしています。この中では入口の料金が最も安く、設置も速いです。 Instagramを連携し、レイアウトを選び、コードをコピーすれば終わりです。 レイアウトはグリッド、メイソンリー、リスト、スライダー、カルーセルの5種類で、 配色の選択肢も用意されており、基本的なデザイン要件は満たせます。無料プランも ありますが、ウィジェット1つで月間の表示回数が非常に小さく制限され、Elfsightの ブランド表示も入るため、実運用のプランというよりデモに近いものです。

検証で通説と違った点がここです。 Elfsightはiframeを使っていません。DOMを開くと、ウィジェットは eapps-instagram-feed-container のようなクラスを持つ通常の要素としてページに直接入っており、shadow rootも iframeの境界もありません。テストCSSをあてると、ウィジェット全体が黄色い 背景のComic Sansになり、画像ごとに赤い枠線が付きました。カスタムCSSが 少しでもあるサイト、つまり事実上すべてのサイトでは、原因の特定が難しい スタイルの衝突が起こりえます。

構造としてはファイル2個のスクリプト設置方式で、問題になるのはファイル数 よりも分離がないことのほうです。InstagramとGoogleの口コミを併用する場合は ウィジェットをそれぞれ購入してそれぞれ貼る必要があり、1つのフィードには まとまりません。複数のアプリをまとめたバンドルのプランがあるので費用は 整理できますが、バンドルにしてもフィードが1つに統合されるわけではなく、 設置コードが複数になりデザインも揃わないという問題はそのまま残ります。 表示回数の上限も要注意で、上限を超えると ウィジェットが表示されなくなります。徐々に劣化するような挙動ではありません。

Curator.io

向いている場合: 開発者が自分で組み込み、CSSのスコープを自分で管理できる場合。

Curator.ioはこの分野に長くいて、安定性ときれいなコードで評価されています。 15以上のプラットフォームに対応し、無料プランも比較的手厚く、カスタムCSSと APIアクセスを提供していて開発者向きです。

ファイル4個のスクリプト設置方式で、画像の処理はこの中のスクリプト設置型では 最もしっかりしています。WebPで積極的に圧縮して配信するため、画像の多い アカウントでは実際に差が出ます。

ただしCSS分離の検証では問題が出ました。ウィジェットがグローバルなDOMに 通常の要素として描画され、Shadow DOMもiframeもないため、テストCSSでそのまま 崩れました。さらにCurator.ioは自身のスタイルシートで :root に独自のCSS変数を宣言します。つまり漏れる向きが双方向です。サイトのCSSがウィジェットを壊すだけでなく、ウィジェット側の変数が サイトに影響することもありえます。

年季が出ている部分もあります。管理画面は機能的ですが古く、レイアウトの 選択肢が少なく、テーマを調整する機能がありません。まとめると、安定した 収集エンジンの上に自分で作り込む開発者には良い選択で、追加作業なしに 分離されたウィジェットが欲しい場合には弱い選択です。

Taggbox (Tagembed)

向いている場合: UGCの利用許諾の管理やコマース連携がどうしても必要で、 22個のファイルと読み込み中のレイアウトのずれを許容できる場合。

Taggboxはこの比較で最も機能が多く、同時に最も複雑です。20以上のプラット フォームに対応し、AIによるモデレーション、UGCの利用許諾管理、投稿に商品をひも付けて 購入につなげる機能、内蔵の分析まで備えています。TaggboxとTagembedは同じ 会社で、埋め込みウィジェットはTagembedが担っています。

構造の面でははっきりした外れ値です。JavaScriptのファイルを22個読み込みます。 他のスクリプト設置型が2個から4個、CollectSocialsが1個であるのと比べると 際立ちます。フィードが描画し終わる前に往復が21回多いということであり、 ページの重さと違ってフィードの中身とは無関係です。投稿を4件表示しても 40件表示しても同じ22個です。

ファイルが22個あるということは、到着のタイミングが22回に分かれるという ことでもあります。Taggboxはその場所をあらかじめ確保しないため、フィードが 組み上がる間ページが目に見えてずれます。後述のJuicer.ioとは原因が違いますが、 起きることは同じです。

CSS分離は2種類のコードが用意されており、差が大きいです。既定のスクリプト コードは分離が一切なくテストCSSで完全に崩れ、iframeのコードは完全に分離されて 通常どおり描画されました。Taggboxをお使いの場合はiframeのコードをお使いください。 既定のコードには保護がありません。

料金の構成も複雑です。デジタルマーケティング向けとイベント向けが分かれており、 UGCの利用許諾管理は上位プランに上がらないと使えません。小規模な事業者には 機能も料金体系も過剰です。逆にUGCを本格的に運用する中堅以上のブランドで あれば、他社が追いつけない機能があります。

EmbedSocial

向いている場合: 口コミの運用が事業の中心で、iframeによる完全な分離を 望む場合。

EmbedSocialは口コミの収集から出発してソーシャルフィードに広げた製品なので、 最も強い領域は口コミ側です。Googleの口コミやFacebookの口コミを含む複数の 情報源を扱い、あらかじめ用意されたテンプレートが多く、AIが口コミへの返信を 書く機能もあります。文章で希望のレイアウトを説明するとAIがウィジェットの デザインを作る機能もあり、これはこの比較の他社にはない機能です。

8つのうちクロスオリジンのiframeで描画される2製品のひとつで、その選択ひとつが 以降のほとんどを決めています。ブラウザがiframeの内部をページのメインスレッドと 分けて処理するため、ウィジェットが中で何をしてもサイト側はほとんど影響を 受けません。ページ速度の計測がiframe方式に有利に出る理由であり、当社が 8つを1つのスコアで並べるのをやめた理由でもあります。代わりにiframeが常に 払う代償があります。サイトのフォントを継承せず、高さがスクリプトで管理されます。

ファイルは10個読み込み、その中にはTailwind CSSのバンドル全体とスライダーの ライブラリが含まれます。Taggboxに次いで多い数ですが、その実行がサイトの ページではなくiframeの中で起きるため、負荷がかかる場所が違います。ファイル数と ページ速度スコアが別のことを語るということを、最もよく示している例です。

分離はコードの種類で分かれます。iframeのコードを直接使えば双方向に完全に 分離され、テストCSSはまったく影響しませんでした。JavaScriptのコードも内部 的にはiframeを使いますが、スクリプトの読み込み中はラッパー要素がページの DOMに露出し、その間はサイトのCSSがその領域に届きます。

多くの購入者が引っかかるのは製品の構成です。ソーシャルフィードと口コミが 別の商品に分かれており、それぞれに料金がかかります。Instagramフィードと Googleの口コミを併用するには2つ契約するか、統合プランに上がる必要があります。 設置方法はJavaScript、iframe、URL、WordPressのショートコード、SPA/Ajaxの 5種類で、この比較では最も多いです。

Flockler

向いている場合: Webサイトとイベント用スクリーン、メール、デジタル サイネージを1つの契約でまとめて運用する代理店や大規模ブランド。

Flocklerはこの市場の上位価格帯にあり、無料プランはありません。多くの中小 規模の事業者にとっては、そもそも検討の対象に入らない価格帯です。

検証の結果は二面的でした。構造だけを見ればこの中では整っているほうです。 ファイルを2個読み込み、希望すればiframeモードも使えます。エンジニアリングが 問題の製品ではありません。

問題は分離のほうです。既定として案内されるスクリプトのコードにはCSSの分離が一切なく、テストCSSで完全に崩れました。黄色い背景、Comic Sans、画像ごとの赤い枠線まで そのままです。一方でiframeのコードは完全に分離されます。Taggboxで見たのと 同じ構図です。同じ製品、2種類のコード、まったく違う結果です。

価格を正当化するのは対応範囲です。Webサイトとイベント用スクリーン、メールへの 埋め込み、デジタルサイネージを1つの契約でカバーします。複数の顧客のUGCを 複数チャネルにわたって運用する代理店であれば、実質的な価値があります。逆に Webサイトに1つInstagramフィードを置きたいだけの場合、そしてそれが大半ですが、 過剰な支出になります。

Juicer.io

向いている場合: 予算が最優先で、読み込み中にページがずれることを許容 できる場合。

Juicer.ioは2014年から提供されており、Instagram、Facebook、TikTok、YouTube、 LinkedInなど15以上のプラットフォームに対応しています。無料プランに ソーシャルフィードが2つ含まれ、入口は入りやすいほうです。

検証では、再現可能な問題が1つはっきり出ました。レイアウトのずれです。JuicerはHTMXでフィードをページに差し込みますが、その場所をあらかじめ 確保しません。そのためウィジェットが到着した瞬間にページが目に見えて跳ね、 読んでいた内容が物理的に下へ動きます。これは測定値ではなく動作の仕組みなので、 どのフィードでも、どのページでも、場所を確保するよう直されるまで起き続けます。

画像も原寸のJPEGをそのまま配信します。最適化されたサムネイルを使いません。 これも当社のテスト用フィードの特性ではなく設計上の選択で、Curator.ioが しているのとちょうど逆です。画像の多いアカウントで両者がまったく違う挙動に なる理由です。

分離は2種類のコードがあります。既定のスクリプトコードはグローバルなDOMに そのまま描画され、Shadow DOMもiframeもないためテストCSSで完全に崩れました。 さらにJuicerはグローバルなセレクタに独自のTailwindの変数を宣言するため、 Curator.ioと同様に漏れる向きが双方向です。iframeのコードを使えば完全に分離されます。これもFlockler、Taggboxと 同じ構図ですので、Juicerをお使いなら既定のコードではなくiframeのコードを お使いください。

まとめると、性能が重要でない場所、たとえば社内のダッシュボードや検索流入が 重要でないコミュニティページでは、安価な多プラットフォーム収集ツールとして 使えます。逆に検索流入やユーザー体験が重要なページであれば、レイアウトの ずれだけでも避けたほうがよい判断になります。

Walls.io

向いている場合: リアルタイムのモデレーションが必要な大規模イベントのソーシャル ウォールを運用し、それに見合う予算がある場合。

Walls.ioはWebサイトへの設置よりも、イベントとデジタルサイネージを主目的に 作られた製品です。15以上のプラットフォームに対応し、何よりリアルタイム処理が 強みです。WebSocketで新しい投稿を画面に押し出すため、ページを再読み込みしなくても 更新されます。カンファレンスや展示会、店舗の催事でソーシャルウォールを出す 用途であれば、これは実質的な技術的優位です。

CSS分離は良好でした。ブラウザのiframeをそのまま使うため完全に保護され、 テストCSSはまったく影響しませんでした。設置の形もきれいで、iframe要素1つに 高さを合わせるスクリプトが付く程度です。

ファイルは11個読み込みます。リアルタイム更新用のWebSocketライブラリとメインの バンドル、いくつかのユーティリティです。WebSocketが付いていること自体が、 この製品の性格を語っています。リアルタイムに更新されるイベント用ウォールの ために作られた道具であり、マーケティングページにフィードを1つ載せるのとは 別の仕事で、その機能が不要でも一式が付いてきます。動画も自動再生するため、 リールの多いアカウントは写真中心のアカウントより負荷が大きくなります。

多くの方が止まるのは価格です。この比較では最も高い価格帯で、無料プランはなく 試用期間のみです。Webサイトにフィードを1つ置きたいという目的には過剰です。 逆に複数の画面にまたがってリアルタイムのモデレーションが入る企業イベントであれば、 この用途のために作られた製品です。

Instagramフィードウィジェットに表示回数の上限はありますか

ほとんどの製品にあります。当社のホスティング型プランも同様です。 ホスティング型のウィジェットは提供元のサーバーから配信されるため、 訪問者がページを開くたびに提供元へのリクエストが1回発生します。 各社はそれを月間の表示回数の上限として価格に反映しています。無料プランの 上限は思っているより小さいことが多く、上限を超えるとウィジェットが 表示されなくなる製品もあります。

例外は、自分のサイト自身がフィードを配信する場合です。 CollectSocialsのWordPressプラグインは、投稿と公開済みのデザインを WordPressのデータベースに複製し、自分のドメインから直接描画します。 そのため同期が完了したあとは訪問者が当社のサーバーにリクエストを送らず、その表示回数は無料プランを 含むどのプランでも消費されません。アクセスがどれだけ増えても同じです。 私が検証した8つのうち、表示回数という項目そのものが消える構成はこれだけ でした。

ここで効いている言葉は同期が完了したあとはで、この条件は 隠さずに申し上げます。最初の同期がまだ終わっていないフィードや、 サイト側がキャッシュできないフィードは、訪問のたびに当社から読み込まれ、 その表示回数は同期が成功するまでプランの上限に加算されます。

プラグインはWordPressの公式プラグインディレクトリにあるため、管理画面の プラグイン検索からそのまま導入でき、エディタ用のブロックと [collectsocials] ショートコードの両方を利用できます。この比較に登場する他のツールの多くは、 埋め込みコードをHTMLブロックに貼り付ける方式のままです。

UGCの利用許諾は上位プラン限定であることが多い

お客様が投稿した写真をサイトに掲載するには、利用の許諾を得て、その記録を 残しておく必要があります。この機能は、比較対象のいくつかの製品では 上位プランに上がらないと使えません。

CollectSocialsでは無料プランを含むすべてのプランでご利用いただけます。 許諾を依頼し、その回答を記録として残すところまで、一連の流れをご利用いただけます。

イベント用のライブウォールも同様で、上位プランの機能ですが、最初のイベントは無料で本番運用できます。どのプランでも一度だけ、24時間のゴーライブ枠を予約でき、 その間はオーバーレイのないウォールが動きます。支払いの前に実際の イベントを最後まで通してご確認いただけます。

どれを選ぶべきか

Instagramのフィードをサイトにきれいに出したいだけの場合。 まず無料プランで試していただくのがよいと思います。期限が来ると消える 体験版ではなく、そのまま使い続けられるプランで、フィードの下に当社への リンクが表示されます。予算が最優先で、1つのサイトに1つのプラットフォームだけ 載せればよいのであれば、Elfsightの入口の料金のほうが安いです。ただしCSSの 分離がないため、サイトのスタイルと衝突しうる点はご承知おきください。

WordPressをお使いの場合。 プラグインとして導入できるものをおすすめします。埋め込みコードを 貼り付けるのではなく管理画面から導入でき、同期が完了したフィードは 表示回数が消費されません。

InstagramとGoogleの口コミを1つのウィジェットにまとめたい場合。 製品の構成を先にご確認ください。フィードと口コミが別商品に分かれていて 2つ契約が必要な製品もあれば、プラットフォームごとにウィジェットを個別に 購入する製品もあります。1つのフィードに複数の取得元をまとめられるかどうかを、 契約の前に確認しておくと安全です。Elfsightはこの用途には向きません。ウィジェット 単位で販売する構造のため、プラットフォームごとに設置コードが増えます。

UGCの利用許諾の管理が必要な場合。 この領域はTaggboxが最も深いです。ただし上位プランに上がる必要があり、22個の ファイルと読み込み中のずれも一緒に受け入れることになります。許諾の記録を 残せれば十分という場合であれば、当社は無料プランでも可能です。

開発者がご自身で組み込む場合。 Curator.ioが適しています。画像の処理がこの中では最もしっかりしており、 開発者向けの機能も充実しています。CSSのスコープはどのみちご自身で 管理されるので、分離がないことの負担も相対的に小さくなります。

イベントやデジタルサイネージも運用される場合。 FlocklerとWalls.ioがこの領域の専用製品です。どちらも分離のためにはiframeの コードを使う必要があります。ただし年に1、2回のイベントであれば、 最初のイベントは無料の24時間ゴーライブ枠で本番運用できますので、 一度動かしてから比較されても遅くはありません。

口コミが中心でInstagramは副次的な場合。 EmbedSocialです。iframeで完全に分離され、口コミの運用機能はこの中で最も 深いです。フィードと口コミが別商品のため費用が増える点はご承知おきください。

導入前に必ず聞いておくこと

投稿の取得に公式APIを使っていますか。 最初に確認すべき項目です。長期運用の前提になります。

アクセストークンの更新はどの方式ですか。 Instagramのトークンには期限があり、期限が切れるとフィードの更新は 止まります。Metaのドキュメントによれば、Instagramに直接ログインして 発行したトークンはサーバー側で自動更新できますが、Facebook経由で連携した トークンにその手段はなく、人が再連携する必要があります。どちらの方式で 連携するのか、更新に失敗したときにどう知らせてくれるのか、再連携後に 既存の設定と選んだ投稿が残るのかを確認しておいてください。契約から 数か月以内に必ず経験する項目です。

表示回数の上限を超えるとどうなりますか。 ウィジェットを非表示にする製品も、追加料金が発生する製品も、次の請求 期間まで描画を止める製品もあります。

CSSの分離はどの方式ですか。 Shadow DOMか、iframeか、なしか、の3択で回答を得てください。そして設置コードが 2種類ある場合、どちらを渡されているのかも併せてご確認ください。この記事で 見たとおり、同じ製品でも結果が分かれます。

契約前に実際の表示を確認できますか。 無料プランも意味のある試用もない製品は、見ずに買ってくださいと言っているのと 同じです。

解約したらデータはどうなりますか。 選んだ投稿、編集したキャプション、デザイン設定が書き出せるのか消えるのかを 先に確認しておくと、あとで乗り換える際に困りません。

まとめ

8つを同じページに設置して確認した結果は、機能一覧を見比べるよりもずっと はっきりしていました。構造の面では、2つはクロスオリジンのiframeで描画されて 処理がサイトのメインスレッドの外で起き、代わりにiframe特有の制約を受けます。 残る6つのうちには1個のファイルしか読み込まないものと22個を読み込むものが 同居しており、TaggboxとJuicer.ioは場所を先に確保しないため読み込み中に ページをずらしました。

分離の面では、Shadow DOMを使っていたのは1つでした。EmbedSocialとWalls.ioは iframeで確実に分離されていました。FlocklerとTaggbox、Juicer.ioはiframeの コードを使えば完全に分離されますが、既定のコードには保護がまったくありません。 ElfsightとCurator.ioはiframeの選択肢自体がなく、既定の設置コードは基本的な CSSの干渉にも耐えられませんでした。

そして日本語で探す際に最初に置かれる問い、つまり公式APIを使っているか どうかは、比較表からは読み取れません。これは各社に直接聞いていただく しかない項目です。

ここに書いた内容は、いずれも開発者ツールでご自身で確認できます。どの 製品のデモページでも1分ほどです。契約の前に一度確認してみてください。

Instagramフィードをサイトに表示する方法全般は Instagramフィード埋め込みガイドにまとめています。Facebookページ、YouTube、X（旧Twitter）、Googleの 口コミも併せて表示される場合は Facebookページの埋め込み、 YouTube再生リストの埋め込み、 X（旧Twitter）フィードの埋め込み、 Googleの口コミの埋め込み をご覧ください。料金は 料金ページ (英語) にあります。