この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、レビュー導入を任されている担当者
読了時間: 約14分
レビューアプリを入れたのに、半年経っても件数が二桁に届かない。ECの現場でよくある状態です。原因がアプリの選定ミスであることは少なく、たいていは「集まる導線を作っていない」「件数が少ない段階の見せ方を決めていない」の二つに集約されます。
Shopifyのレビュー機能は、入れれば増えるものではありません。誰が、いつ、どの画面で書くのかを設計して初めて動き出します。この記事では、アプリの機能比較ではなく、Shopifyに口コミを載せるときに制作側が実際に判断している論点を扱います。導入の可否、アプリで足りる線とテーマ改修が必要になる線、構造化データとの関係、そして導入後に効いてくるコストまでを順に見ていきます。
Shopifyのレビューアプリを入れる前に決めること
口コミは「機能」ではなく「運用」で決まる
Shopifyアプリストアには、レビュー系のアプリが多数並んでいます。星の表示、写真投稿、レビュー依頼メール、Q&A、インポート機能。どれも似た機能を持っていて、比較表を作っても差がつきにくい領域です。
差がつくのは導入後です。口コミの件数を決めているのは、アプリの性能ではなく次の三つです。
- 購入から何日後に、どんな文面で依頼が飛ぶか
- 依頼を受けた人が、何クリックで投稿を終えられるか
- 集まったレビューを、店側が何日以内に確認・公開するか
この三つが設計されていなければ、どのアプリを入れても結果は変わりません。逆に言えば、三つが設計されていれば、無料枠のあるアプリでも口コミは溜まります。
導入前に答えを出しておく5つの問い
制作側がヒアリングで必ず聞く項目です。ここが埋まらないまま実装に入ると、後から作り直しになります。
| 問い | なぜ聞くか |
|---|---|
| 商材のリピート周期はどれくらいか | 依頼メールを送るタイミングが決まる。消耗品と耐久財で全く違う |
| 写真つきレビューが欲しいか | 必要ならレビュー表示のレイアウトが変わり、テーマ改修の可能性が出る |
| レビューを承認制にするか | 承認制なら誰が毎日見るのかを決める必要がある |
| 既存のレビュー資産があるか | 他モールや旧サイトから移すならインポート対応のアプリに絞られる |
| 多言語・多通貨で展開するか | 対応言語がアプリ選定の第一条件になる |
「写真つきレビューが欲しいか」は特に後戻りが大きい項目です。テキストだけの口コミは商品ページの下部に素直に積めますが、写真つきになるとギャラリー的な見せ方が必要になり、商品画像との視覚的な競合をどう処理するかというデザインの判断が入ってきます。テーマの改修範囲が変わるので、要件定義の段階で確定させます。
「既存のレビュー資産があるか」も同じくらい重い問いです。他のカートやモールから移す場合、移せるのは本文と星の数値だけで、投稿日時・投稿者名・写真は形式が合わずに落ちることがあります。何が移せて何が落ちるかは、アプリのインポート仕様を読まないと分かりません。旧サイトのレビューを全部持ってこられる前提で見積を組むと、移行の段階で足が出ます。
レビューが集まる導線をどう設計するか
依頼メールのタイミングは商材で決める
レビューアプリの中核機能は、実は表示ではなく「依頼メールの自動送信」です。購入者に何もしなければ、口コミを書く人はほぼいません。書くのは、極端に満足したか、極端に不満だったかのどちらかです。中間層の声を集めるには、こちらから依頼するしかありません。
タイミングの目安は、商品を使い始めてから最初の実感が出るまでの期間です。
送るのが早すぎると「まだ使っていないので書けない」で終わり、遅すぎると購入自体の記憶が薄れます。上の幅で一度設定し、開封率と投稿率を見ながら前後にずらすのが実務的な進め方です。
配送遅延がある商材では、注文日起点ではなく配送完了日起点で送れるアプリを選びます。この差は地味ですが、実際の投稿率に効きます。予約商品や受注生産を扱うストアでは、注文日起点だと商品が手元に届く前に依頼メールが飛ぶため、そもそも成立しません。
リマインドを何通まで送るかも先に決めます。1通目で反応がなかった相手に3日〜1週間後にもう1通、そこで止める。この2通構成が実務では扱いやすく、それ以上は配信解除を招きます。既に投稿した人には送らないという除外条件が正しく効いているかは、テスト注文で必ず確認してください。
投稿画面までの摩擦を減らす
依頼メールを開いた人が離脱する場所は、ほぼ決まっています。
- ログインを求められる
- 星の評価だけでなく、本文を必須で求められる
- スマートフォンで写真をアップロードする導線が分かりにくい
メール本文の中に星を並べ、クリックした時点で評価が確定し、コメントは任意、という形が投稿率としては最も高くなります。多くのレビューアプリがこの形式に対応しているので、選定時に必ず確認する項目です。
本文を必須にすると、件数は明確に落ちます。星だけでも数が集まっていれば平均評価は意味を持つので、まず件数を作り、コメントは書きたい人に任せる設計を推奨します。
写真の投稿は、任意にしたうえで動線だけ用意しておきます。スマートフォンからのアップロードは、ファイル選択ダイアログを開いた時点で一定数が抜けます。写真を必須にすると件数が大きく落ちるので、必須にするのは写真そのものが商品価値の核になる商材（アパレル、インテリア、食品の実物写真）に限ります。
依頼以外の集め方も用意する
メールだけに頼ると、メールアドレスを収集できていない層が丸ごと抜け落ちます。補助の導線をいくつか置いておきます。
- 同梱カード: 発送物にQRコード付きのカードを入れる。開封直後という最も熱量が高い瞬間に当たる
- 注文完了ページ・注文状況ページ: Shopifyのチェックアウト後の画面に、レビュー案内を出す
- マイページ・注文履歴: 再訪した既存顧客に、過去購入分のレビュー依頼を出す
- LINE・SNSのフォロワー向け配信: 既存の接点があるなら、そこから商品ページへ流す
同梱カードは制作側から必ず提案する項目です。デジタル施策と違って効果測定はしづらいですが、コストが低く、メール未取得層に届く数少ない手段です。QRコードのリンク先にUTMパラメータを付けておけば、流入量だけは測れます。
カードに書く文面は「レビューをお願いします」ではなく、何を書けばいいかを一つ指定する方が投稿されます。「サイズ感はいかがでしたか」「どんな場面で使っていますか」のように問いの形にすると、書き出しで止まる人が減ります。
件数が少ない段階の口コミをどう見せるか
「0件」の表示は避ける
レビューを導入した直後、全商品が0件からスタートします。ここでよくある失敗が、商品ページに「レビュー（0）」という表示が出てしまうことです。何もない状態より、明示的に「ゼロ」と書かれている方が印象は悪くなります。
対策は単純で、件数が一定に満たない商品ではレビューセクション自体を非表示にします。多くのアプリは設定でこれができますが、できない場合はテーマ側のLiquidで制御します。
{% comment %}
レビュー件数が閾値未満のときはセクションごと出さない。
レビューアプリが商品メタフィールドに件数を書き込む形式を想定。
メタフィールドの名前空間・キーは使用するアプリのドキュメントで確認すること。
{% endcomment %}
{%- assign review_count = product.metafields.reviews.rating_count.value | default: 0 -%}
{%- assign min_reviews = section.settings.min_reviews | default: 3 -%}
{%- if review_count >= min_reviews -%}
<section class="ts-product-reviews" id="ts-reviews">
<h2 class="ts-product-reviews__title">
お客様の声（{{ review_count }}件）
</h2>
<div id="shopify-block-reviews">
{%- comment -%} ここにアプリのブロックを配置 {%- endcomment -%}
</div>
</section>
{%- else -%}
<section class="ts-product-reviews ts-product-reviews--empty">
<p class="ts-product-reviews__prompt">
この商品のレビューはこれから集まります。
ご購入いただいた方には、商品到着後にご感想のお願いをお送りしています。
</p>
</section>
{%- endif -%}
実装のポイント: default: 0 を必ず入れます。メタフィールドが未設定の商品では nil が返り、比較演算がそのまま通ってしまうことがあります。Liquidは nil の扱いが直感的でないので、数値比較の前に必ずデフォルト値を与えてください。
つまずきやすい点: レビュー件数をどこに持つかはアプリごとに違います。product.metafields.reviews.rating_count はShopifyが標準で用意している名前空間ですが、アプリ独自の名前空間を使うものもあります。テーマエディタのプレビューで実際の値を確認してから組んでください。アプリを乗り換えると、ここの参照先が変わって表示が消えます。
対応環境: Shopify Online Store 2.0テーマ全般。Dawnをベースにしたテーマであればセクション単位でそのまま組み込めます。
件数が少ないときは「質」で見せる
3件しかない口コミを、10件あるかのように見せることはできません。できるのは、少ない件数を最大限に活かす配置です。
件数が少ない時期（〜10件）
- 星の平均は出さない、または控えめに
- 本文が充実した1〜2件を大きく見せる
- 写真つきレビューを優先的に上へ
- 購入者の属性（年齢・用途）を添える
件数が溜まった後（30件〜）
- 平均評価と件数を目立たせる
- 星の分布グラフを出す
- 絞り込み・並べ替えを用意する
- 1件あたりの表示は小さくてよい
件数が少ない段階で星の平均だけを大きく出すと、「3件で星5.0」という数字が逆に信頼を落とします。サンプル数が少ないうちは平均そのものが統計的に意味を持たず、読み手も直感的にそれを分かっているので、数字を強調するほど疑われます。本文を読ませる設計に振り、件数が増えてから数値中心に切り替える。この切り替えを最初から想定しておくと、後の改修が軽くなります。
切り替えの実装は、テーマ側で件数の閾値を持たせるのが素直です。件数が閾値未満なら本文中心のレイアウト、超えたら平均評価と分布グラフを出すレイアウト。閾値をセクション設定に出しておけば、店側が管理画面から切り替えられます。
低評価レビューを消さない
承認制にすると、悪い口コミを非公開にしたくなります。実務では、明らかな誹謗中傷や事実誤認を除いて、低評価も公開する方が最終的な転換率は高くなります。星5だけが並んでいる状態は、読み手に「操作されている」と読まれます。
低評価に対しては、店舗からの返信をセットで公開します。「サイズ表記が分かりにくかった」という指摘に対して「ご指摘を受けてサイズ表を更新しました」と返せていれば、それ自体が信頼の材料になります。返信機能があるかどうかは、アプリ選定で見るべき項目のひとつです。
返信の文面は、謝罪だけで終わらせず、何を変えたかを書きます。変えていないなら「現時点では変更していないが検討中」と書く。ここで曖昧な定型文を返すと、返信があること自体が形式的に見えて逆効果になります。
Shopifyのレビューと構造化データの関係
商品ページに口コミを載せる意味の半分は構造化データ
レビューを商品ページに出すと、検索結果に星が表示される可能性があります。これは Product 構造化データの中に aggregateRating や review を持たせることで、Googleが読み取れる状態になっているからです。
ここで押さえておくべき点が二つあります。
一つ目: レビューアプリが構造化データを出力するかどうかは、アプリによって違います。表示は綺麗なのに構造化データを出していないアプリもあります。選定時に「JSON-LDを出力するか」を確認してください。
二つ目: テーマ側とアプリ側の両方が構造化データを出力すると、重複してエラーになります。Shopifyのテーマの多くは商品ページに Product のJSON-LDを持っており、そこにアプリがもう一つ足すと、Search Consoleに警告が出ます。
構造化データの検査手順
導入後に必ず通す手順です。
Product が2つ検出された場合、多くは「テーマ側を残してアプリ側を止める」か「テーマ側の aggregateRating だけをアプリの値で埋める」のどちらかで解決します。後者はテーマ改修の領域です。
テーマ側のJSON-LDにレビュー情報を差し込む場合の例を挙げます。
{%- comment -%}
商品ページのJSON-LD。アプリ側のJSON-LD出力はオフにしておくこと。
レビューが0件のときは aggregateRating を出さない（値なしで出すとエラーになる）。
{%- endcomment -%}
{%- assign r_count = product.metafields.reviews.rating_count.value | default: 0 -%}
{%- assign r_value = product.metafields.reviews.rating.value.rating -%}
<script type="application/ld+json">
{
"@context": "https://schema.org/",
"@type": "Product",
"name": {{ product.title | json }},
"description": {{ product.description | strip_html | truncate: 300 | json }},
"sku": {{ product.selected_or_first_available_variant.sku | json }},
"brand": {
"@type": "Brand",
"name": {{ product.vendor | json }}
},
"offers": {
"@type": "Offer",
"price": {{ product.price | divided_by: 100.0 | json }},
"priceCurrency": {{ cart.currency.iso_code | json }},
"availability": "https://schema.org/{% if product.available %}InStock{% else %}OutOfStock{% endif %}",
"url": {{ request.origin | append: product.url | json }}
}{% if r_count > 0 and r_value %},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": {{ r_value | json }},
"reviewCount": {{ r_count | json }}
}{% endif %}
}
</script>
実装のポイント: 値の出力には必ず | json フィルタを通します。商品名に引用符やバックスラッシュが入っていると、エスケープなしではJSONが壊れます。日本語の商品名でも「”限定”モデル」のような表記は珍しくありません。
つまずきやすい点: aggregateRating を件数0で出力するとGoogleにエラーとして扱われます。上のコードのように r_count > 0 の条件で丸ごと囲ってください。導入直後は全商品が0件なので、ここを忘れると全商品ページがエラーになります。
対応環境: Shopify Online Store 2.0。request.origin はShopifyのLiquidオブジェクトで、テーマ内で利用できます。
なお、構造化データに入れる評価値は、実際に画面に表示されている口コミと一致している必要があります。表示していないレビューを集計値に含める、キャンペーンで集めた社内の評価を混ぜるといった実装は、Googleのポリシー違反として扱われる可能性があります。表示と構造化データを同じデータソースから出す。この原則を外さなければ問題は起きません。
構造化データを含めたShopifyのSEO面の制約は、URL構造の話まで含めて別記事で整理しています。
アプリで足りる線と、テーマ改修が必要になる線
判断の分岐点は「レイアウトに手を入れるか」
レビューアプリの多くは、Online Store 2.0のアプリブロックとして商品ページに差し込む形をとっています。テーマエディタでドラッグして置けるので、実装作業自体は数分です。
問題は、置いた結果が既存のデザインと馴染むかどうかです。
アプリの設定で足りる
- 商品ページ下部にレビュー一覧を置く
- 星の色・サイズの調整
- 依頼メールの文面とタイミング
- 承認フロー・返信
- フォントを既存テーマに合わせる
テーマ改修が必要
- 商品一覧（コレクション）に星を出す
- トップページに横断的なレビュー枠を置く
- レビュー写真をメイン商品画像と混在させる
- 構造化データの重複解消
- レビューの多い順で並べ替える
- アプリの標準デザインを大きく崩す
このうち特に見落とされやすいのが「商品一覧に星を出す」です。商品ページには出ているのに一覧には出ていない、という状態はよくあります。一覧に星が並ぶかどうかで、そのページのクリック率は変わります。アプリによっては一覧用のブロックを提供していますが、テーマのカードコンポーネントを直接触らないと入らない構造のテーマもあります。
見積の段階で「レビューを一覧にも出しますか」と聞いておく。ここが後から出てくると、テーマの card-product.liquid を触る改修になり、想定より工数が増えます。
レビュー並べ替えをテーマ側で持つ場合
コレクションページを「レビューの多い順」で並べたい、という要望はよく出ます。Shopifyの標準ソート順にレビュー件数はないため、実装するならメタフィールドを使った独自ソートになります。
// コレクションページのカードをレビュー件数順に並べ替える。
// 各カードに data-review-count / data-review-rating を出力しておくこと（Liquid側）。
// サーバー側のページネーションとは独立して動くので、
// 「表示中のページ内での並べ替え」であることに注意。
function sortCardsByReviews(container, { key = 'count', order = 'desc' } = {}) {
const cards = Array.from(container.querySelectorAll('[data-review-count]'));
if (cards.length === 0) return;
const attr = key === 'rating' ? 'reviewRating' : 'reviewCount';
const dir = order === 'asc' ? 1 : -1;
cards
.sort((a, b) => {
const av = parseFloat(a.dataset[attr]) || 0;
const bv = parseFloat(b.dataset[attr]) || 0;
// 同値のときは元の並び順を保つ（Array.prototype.sort は安定ソート）
return (av - bv) * dir;
})
.forEach((card) => container.appendChild(card));
}
// 使い方
const grid = document.querySelector('#product-grid');
document.querySelector('#sort-by-reviews')?.addEventListener('change', (e) => {
sortCardsByReviews(grid, { key: e.target.value, order: 'desc' });
});
実装のポイント: appendChild は既存のノードを移動させる挙動になるため、要素を作り直す必要がありません。DOMの再構築を避けられるので、画像の再読み込みも起きません。
つまずきやすい点: これはあくまで「今表示されているページ内での並べ替え」です。100商品あって24件ずつページングしている場合、全体でレビューが最も多い商品が1ページ目に来るわけではありません。全体を並べ替えたいなら Search & Discovery やStorefront APIを使った実装になり、規模が一段上がります。この違いを説明せずに実装すると、納品後に「並べ替えが効いていない」という指摘を受けます。
対応環境: モダンブラウザ全般。Array.prototype.sort の安定ソートはES2019で仕様化され、現行の主要ブラウザはすべて対応しています。?. （オプショナルチェーン）も同様です。
Shopifyのカスタマイズがどこまで届くかという線引きは、レビュー以外でも同じ構造で出てきます。
導入後に効いてくる論点
月額の積み上がり
レビューアプリは、無料枠のあるものから月額課金のものまで幅があります。単体で見れば大きな額ではありませんが、Shopifyの運用では他にもアプリが入ります。配送日時指定、定期購入、ポイント、メール配信、レコメンド。それぞれが月額を持ちます。
最新の料金は各アプリのページで確認してください。 プランも金額も改定されるため、記事に書かれた数字は当てになりません。
見るべきは総額です。アプリの合計月額が、Shopify本体のプラン料金を上回っている店舗は珍しくありません。導入時に「このアプリは月いくらか」ではなく「アプリ全体で月いくらになるか」を一覧にして提示します。
多くのレビューアプリは、レビュー件数や送信メール数で課金段階が上がる料金体系をとっています。無料枠で始めて、伸びてきたら有料に切り替わる。この切り替わりのタイミングを最初に把握しておかないと、想定外の請求が来ます。海外製アプリは米ドル建てで請求されるため、為替次第で円換算額が動く点も、年間予算を組むときには織り込んでおきます。
サブスクリプション型のコストが積み上がる構造は、Web制作全般に共通する論点です。
表示速度への影響
レビューアプリはJavaScriptを商品ページに追加します。多くはレビュー本体を非同期で読み込む作りになっているため、初期表示への影響は限定的ですが、次の点は確認します。
- 商品ページのLCP（最大コンテンツの描画）が悪化していないか
- レビューが読み込まれた瞬間にレイアウトがずれないか（CLS）
- アプリのスクリプトがすべてのページに読み込まれていないか
3つ目が見落とされがちです。商品ページでしか使わないアプリのスクリプトが、トップページやブログページにも読み込まれている状態は珍しくありません。テーマの theme.liquid にスクリプトタグを直接埋める方式のアプリだと起きやすい構造です。
CLSは、レビューセクションの高さをあらかじめ確保することで抑えられます。
/* レビューが読み込まれるまでの高さを確保してレイアウトのずれを防ぐ。
min-height はレビュー2〜3件分の実測値を入れる。 */
.ts-product-reviews {
min-height: 320px;
content-visibility: auto;
contain-intrinsic-size: auto 320px;
}
/* 折りたたみの開閉は max-height ではなく grid で行う。
中身の高さが分からなくてもアニメーションが効く。 */
.ts-review-body {
display: grid;
grid-template-rows: 0fr;
transition: grid-template-rows 240ms ease;
}
.ts-review-body[data-open="true"] {
grid-template-rows: 1fr;
}
.ts-review-body > div {
overflow: hidden;
}
@media (prefers-reduced-motion: reduce) {
.ts-review-body { transition: none; }
}
実装のポイント: grid-template-rows: 0fr → 1fr のアニメーションは、高さが可変のコンテンツを開閉するときの定番です。max-height を大きめの値で決め打ちする方法は、コンテンツが短いときに閉じる速度が不自然になります。レビュー本文は長さがばらつくので、この書き方が向きます。
つまずきやすい点: grid-template-rows の遷移が効くのは、直下の子要素が1つで、その子に overflow: hidden が付いている場合です。子要素を複数並べると動きません。
対応環境: grid-template-rows のアニメーションはChrome 107以降、Safari 16以降、Firefox 127以降。content-visibility は主要ブラウザで利用できます。いずれも未対応環境では単に効果がないだけで、表示は壊れません。
解約時に何が残るか
これが最も重要な確認項目です。レビューアプリを解約すると、集めた口コミはどうなるか。
| 保存先 | 解約時の挙動 |
|---|---|
| アプリ側のサーバーにのみ保存 | データが見えなくなる。移行にはエクスポートが必須 |
| Shopifyのメタフィールドに保存 | ストア側に残るが、表示するには別途実装が要る |
| Shopify標準のレビュー機能 | ストア側に残る |
「エクスポートできるか」「エクスポート形式は何か」を導入前に確認します。CSVで出せるなら、他のアプリへの移行が現実的になります。エクスポート機能がない、あるいは有料プラン限定のアプリは、実質的にロックインされます。
数百件のレビューは資産です。何年も運用したストアの口コミが移行できないという理由だけで、不満のあるアプリを使い続けることになります。契約前に、実際に無料枠の状態でエクスポートボタンが押せるかまで確かめておくと確実です。
管理画面を触る人の負担
承認制にすると、誰かが毎日Shopify管理画面のアプリ画面を開くことになります。この作業を誰がやるのかを決めずに承認制を選ぶと、承認待ちのレビューが溜まったまま放置されます。
現実的な選択肢は三つです。
- 自動公開: 星3以上は自動公開、星2以下のみ承認待ちにする。多くのアプリが対応
- 通知連携: 新規レビューをメールやSlackに飛ばし、管理画面を開かずに把握する
- 週次まとめ: 毎日ではなく週1回まとめて処理する運用に切り替える
自動公開の閾値設定は、運用負荷を最も下げる選択です。低評価だけを人が見る形にすれば、確認作業は週に数件で済みます。
Shopifyのレビューアプリを選ぶときに見る箇所
機能一覧ではなく、次の項目を見ます。アプリストアのページから確認できるものがほとんどです。
最終更新日
アプリストアの詳細ページに更新履歴があります。半年以上更新がないアプリは避けます。ShopifyはAPIとテーマの仕様を継続的に変えており、追随していないアプリはある日動かなくなります。
対応言語
日本語のUIが必要なのは二か所です。購入者が見る投稿フォームと、店側が触る管理画面。前者だけ日本語で後者は英語のみ、というアプリは多くあります。管理画面を触るのが誰かによって、この許容度は変わります。
投稿フォームが英語のままだと投稿率が明確に落ちます。ここは妥協できない項目です。翻訳機能があっても、日本語のラベルを自分で書き換えられるかを確認してください。あわせて、依頼メールのテンプレートを日本語に差し替えられるかも見ます。フォームだけ日本語で、メールが英語のまま届く構成は実際に起こります。
サポート体制
問い合わせから返信までの時間、日本語対応の有無、時差。海外製のアプリは時差の関係で1往復に24時間かかることがあります。トラブル時に丸2日止まる可能性を織り込めるかどうかです。
アプリストアの口コミ欄に「サポートの返信が早い」という書き込みが多いアプリは、実際に早い傾向があります。星の平均より、直近数か月のレビュー本文を読む方が判断材料になります。低評価のレビューに開発元が返信しているかどうかも見ます。放置されているアプリは、導入後の問い合わせも同じ扱いを受けます。
自社テーマとの相性
アプリストアには「このテーマで動作確認済み」という情報が載っていることがあります。ただし網羅的ではないので、最終的には実際に入れて確かめます。
開発ストアかテーマの複製で試すこと。 本番テーマに直接インストールして、表示が崩れたまま公開状態になる事故は実際に起きます。テーマを複製してからアプリブロックを配置し、プレビューで確認してから本番に反映する手順を必ず踏んでください。
商品数とレビュー件数の上限
無料枠に商品数やレビュー件数の上限が設定されているアプリがあります。商品数が多いストアでは、導入初日に上限に当たることもあります。自社の商品数を確認してから選定してください。上限に達したときの挙動も確認します。新規の投稿だけが止まるのか、既存の表示ごと消えるのかで、影響の大きさが違います。
Shopifyをコーポレートサイトと兼用する場合の口コミ
Shopifyを商品販売だけでなく企業サイトとしても使うケースが増えています。この構成では、レビューの扱いに一つ判断が入ります。
企業サイトとしての顔を持つストアでは、商品レビューと「お客様の声」「導入事例」が別物として存在します。前者はレビューアプリが管理する商品単位のデータ、後者はコンテンツとして制作するページです。この二つを混ぜると、どちらも中途半端になります。
- 商品レビュー: 購入者が書く。件数が価値。商品ページに置く
- お客様の声・事例: 店側が構成する。深さが価値。独立したページに置く
BtoB寄りの商材では後者の比重が高くなり、レビューアプリの優先度は下がります。BtoC寄りなら前者が主役です。自社がどちらに寄っているかで、レビュー導入にかける予算配分が変わります。コーポレートサイトとECを一つのShopifyで兼ねる構成の全体像はShopifyをコーポレートサイトと兼用する考え方で整理しているので、サイト設計から検討する場合はそちらを先に読んでください。
会社概要や事例ページの作り方まで含めて考えるなら、こちらも参考になります。
導入の進め方
制作側が実際に踏む順序です。
重要なのは最後の工程です。レビュー導入は設定して終わりではなく、最初の1か月のデータを見て調整する前提で組みます。依頼メールの開封率と、開封から投稿までの転換率。この二つが分かれば、どこを直すべきかが決まります。
開封率が低いなら件名。開封しているのに投稿されないなら、フォームか依頼のタイミングです。数字を見る場所は、多くのアプリが持つメール配信のレポート画面です。ここが見られないアプリは、調整の根拠が持てないので選定から外します。
制作会社に依頼する場合、この最後の工程が見積に入っているかを確認してください。「レビューアプリ導入」とだけ書かれた見積は、設置までで終わっていることがあります。1か月後の調整を誰がやるのかを、契約の段階で決めておく。ここを決めずに納品を迎えると、設定したまま誰も触らない状態で1年が過ぎます。
【画像挿入: レビュー依頼メールの開封率と投稿率をダッシュボードで確認している画面のイメージ】
よくある質問
Shopify標準のレビュー機能とアプリはどちらを使うべきですか
まず標準機能で始めて、足りなくなったらアプリに移るのが安全です。標準機能はデータがストア側に残るため、後から他のアプリへ移行するときの選択肢が広く保てます。写真つきレビュー、自動依頼メール、承認フローの細かい制御が必要になった段階でアプリを検討してください。
口コミが集まらないのですが何を直せばいいですか
依頼メールを送っているかどうかをまず確認してください。送っていないなら、それが最大の原因です。送っているのに集まらない場合は、開封率と投稿ページへの遷移率を分けて見ます。開封率が低ければ件名とタイミング、開封後に投稿されないならフォームの入力項目が多すぎる可能性が高いです。
悪いレビューは非表示にしてもいいですか
誹謗中傷や事実誤認は非表示にして構いませんが、正当な低評価は公開したほうが結果的に転換率は上がります。星5だけが並ぶ状態は不自然に見え、レビュー全体の信頼を下げます。低評価には店舗から返信を付けて、改善したことを併せて示すのが最も効果的です。
Shopifyのレビューアプリを変更すると今までの口コミは消えますか
アプリのデータ保存先によります。アプリ側のサーバーにのみ保存されている場合、解約時に見えなくなります。導入前にCSVエクスポートができるかを必ず確認してください。Shopifyのメタフィールドに保存する形式であれば、アプリを外してもデータはストア側に残ります。
検索結果に星を表示させるには何が必要ですか
商品ページに Product 構造化データがあり、その中に aggregateRating が正しく入っていることが条件です。表示されるかどうかはGoogleの判断なので、条件を満たしても必ず出るとは限りません。まずリッチリザルトテストでエラーなく検出されることを確認し、Product が重複していないかを見てください。
レビュー機能の導入にはどれくらいの期間がかかりますか
アプリを入れて商品ページに表示するだけなら、検証を含めても数日の範囲です。期間が延びるのは、商品一覧への星表示、構造化データの重複解消、既存レビューの移行といったテーマ改修が入る場合です。加えて、投稿率を見て依頼メールを調整する期間として、公開後に1か月を見込んでおきます。
まとめ
Shopifyのレビュー機能で決まるのは、アプリの選択ではなく運用の設計です。
- 集める導線を先に決める — 依頼メールのタイミングと、投稿までのクリック数。ここが投稿率のほぼすべて
- 件数が少ない期間の見せ方を用意する — 0件表示を避け、本文を読ませる配置から始めて、溜まってから数値中心に切り替える
- 構造化データの重複を確認する — テーマ側とアプリ側の二重出力はよくある。導入直後に必ずリッチリザルトテストを通す
- アプリで足りる線を見極める — 商品ページに置くだけならアプリの設定で完結する。一覧への星表示、並べ替え、デザインの作り込みはテーマ改修の領域
- 解約時に何が残るかを先に確認する — エクスポート可否は、数年後の選択肢の幅を決める
口コミは、集まり始めるまでに時間がかかる資産です。導入した月に成果は出ませんが、続けていけばその店舗の商品ページで最も読まれる要素になります。だからこそ、集める仕組みを最初に作っておく価値があります。
Shopifyの構築費用全体の中で、レビュー機能がどの位置にあるかを把握しておくと、優先順位の判断がしやすくなります。
