なぜ商品ページのSEO最適化は「やりきれない」のか

商品点数×モール数×更新頻度で作業量が膨張する

単品・単モールであれば、商品タイトルをじっくり見直す時間は作れます。しかし複数モールに出店し、商品が数十〜数百SKUになった時点で、状況は一変します。

たとえば商品数が100SKUで3モール展開している場合、各モールに合わせた商品ページを管理するだけで300ページ分のコンテンツが存在することになります。さらにモールのアルゴリズム変動・季節需要の変化・競合の動きに応じて定期的な見直しが必要になるため、「一度整えたら終わり」にはなりません。

「タイトルを直す」だけでも手間が積み重なる

楽天の商品名は最大127文字まで使えますが、最適な文字数や構成はカテゴリ・価格帯・競合の出品状況によって変わります。Yahoo!ショッピングとAmazonではタイトル規則やアルゴリズムの特性が異なるため、同じ商品でも最適な書き方は一致しません。

この「モールごとの調整」を全商品に繰り返す作業は、人手だけで続けようとすると運用コストが売上対比で割に合わなくなる局面が来ます。relmeaがモール運営の中でこの課題に直面し、段階的な仕組み化に取り組み始めたのも、まさにこの理由からです。

「検索順位を測る」ことと「ページを直す」ことは別の問題

検索順位を自動で記録するツールや、広告のCVRを集計する仕組みはすでに整備されている事業者も多いと思います。しかし「測定した結果をもとに、実際にページの文言を直す作業」は、多くの場合まだ手作業のままです。本記事はこの「文言を直す作業そのもの」を仕組み化することに焦点を絞ります。

自動化は「人手→AI→仕組み」の3段階で考える

いきなり全自動を目指すのは現実的ではありません。段階を踏んで仕組みの適用範囲を広げていくことが、失敗しにくい設計です。relmeaでも以下の3段階を順番に進めてきました。

第1段階：人が手作業で改善する

SEOのロジックを人が理解しながら、商品タイトルや説明文を直します。この段階で、どのような観点で文言を変えると検索流入や購買率が変化するかを、データとセットで蓄積します。「なぜこの言葉を選んだか」という判断基準を自分で言語化できていないと、第2段階以降でAIに正確な指示が出せません。

第2段階：AIに下書きを作らせ、人が判断する

生成AIを使って商品ごとの改善候補を素早く生成し、最終的な採否判断は人が行います。AIは大量の候補を短時間で出せますが、モールのガイドライン遵守・ブランドトーンの一貫性・季節施策との整合性といった文脈の判断は、まだ人が担うべき領域です。

第3段階：GASで一連のフローを仕組み化する

第2段階で手作業になっていた「情報収集→AIへの入力→候補のまとめ→承認」という流れを、GASで自動的に処理できるパーツに置き換えます。ここでも「承認ゲート」は人が持ち続けます。完全自動化ではなく、人の判断が必要な部分だけを残して他を仕組みに任せる設計です。

第2段階：生成AIに改善案を作らせるときの考え方

AIに渡す「入力情報」を設計する

生成AIに商品ページの改善案を作らせる際は、AIへの入力情報（プロンプト）の質が出力の質を決めます。最低限、以下の情報をセットで渡すことをおすすめします。

  • 現在の商品タイトル（モールごと）
  • 商品カテゴリと主な仕様・特徴
  • 狙っている検索キーワード（自社で調査済みのもの）
  • そのモールのタイトル文字数上限・禁止語句などのルール
  • 競合の代表的な商品タイトル（比較用・任意）

これらをプロンプトに構造化して渡すことで、AIは「このモールのこのカテゴリでこのキーワードを含めて、最大◯文字以内でタイトルを改善してください」という具体的な指示を受けられます。逆に情報が少ないと、AIは一般的すぎる提案しか返せません。

AIに丸投げせず、人が最終判断する理由

生成AIはタイトルや説明文の「それらしい候補」を出すことは得意ですが、以下の点は人が確認する必要があります。

  • モールの最新ガイドライン・禁止表現への準拠（AIの学習データに最新情報が含まれない場合があります）
  • 自社のブランドトーンや価格帯に合ったトーンか
  • 競合の動きや季節タイミングとの整合性
  • 過去に同じような表現を試して効果がなかった場合の知見

これらはAIが自動で判断するのが難しい領域です。AIを「改善候補の量産機」として使い、人がその中から採用可否を判断するという役割分担が、安定して機能します。

AI利用にかかる費用について

生成AIを業務に組み込む場合、利用するAIサービスの料金は別途必要になる場合があります。APIを経由して使う場合は処理件数や文章量に応じた従量課金になるケースが多いため、商品数と処理頻度をもとに概算コストを事前に確認することをおすすめします。

第3段階：GASで1本のフローにまとめる設計

フロー全体の設計図

GASを使って構築するフローは、以下のステップで構成します。

  1. キーワード収集：スプレッドシートに商品一覧とターゲットキーワードをまとめ、GASでシートを読み込む準備をします。
  2. AI下書き生成：GASからAIのAPIを呼び出し、商品ごとの改善案をテキストとして取得します。
  3. シート集約：取得した改善案を同じスプレッドシートの別列に書き込み、元の文言と並べて比較できる状態にします。
  4. 承認ゲート：担当者がスプレッドシートを確認し、採用・修正・却下を手動で入力します。この列を確認するまで次のステップには進みません。
  5. モールへの反映：承認済みの内容をもとに、モールの管理画面への入力用CSVを自動生成します（APIが提供されているモールは直接書き込みます）。

このフローの特徴は、4の承認ゲートを人が持ち続けることです。AIが生成した案をそのままモールに自動で反映させる設計にすると、誤った記述や規約違反の表現がそのまま公開されるリスクがあります。「生成→確認→反映」の流れにすることで、リスクを管理しながら作業時間を削減できます。

GASでの実装に必要な準備

GASを使ったこのフローには、一定の手順を踏む必要があります。AIのAPIキーの取得・設定、スプレッドシートとGASの連携、モールのCSV仕様の確認などが主な作業です。コードを一から書く場合はGASとAPIの基礎知識が必要になりますが、手順書通りに進めれば非エンジニアでも運用できる水準に落とし込むことは可能です。relmeaでは、実際にこの種のフローをEC事業者向けの教材・ツールとして設計しています。

完全自動化にしない理由

「承認ゲートをなくして全自動にできないか」という発想は自然ですが、現時点では推奨しません。理由は2つあります。

1つ目は、AIの出力品質は入力情報と指示の精度に依存するため、意図しない文言が生成されることがある点です。商品タイトルに誤った仕様が入ったまま公開されると、購買率の低下や返品・クレームにつながる場合があります。

2つ目は、モールの規約変更・アルゴリズム変動・季節施策への対応は、仕組みだけでは追いかけられない点です。人が定期的にフローの出力を見ることで、これらの変化に気づいて設計を修正する機会が生まれます。半自動化は「人の手を減らす」ためではなく「人の判断を、価値の高い部分に集中させる」ための設計です。

小さく始める順番と、失敗しても戻せる単位

1モール・数商品から始める

いきなり全モール・全商品にフローを適用しようとすると、設計の不備や想定外のエラーが複数重なって、問題の切り分けが難しくなります。最初は1つのモール、商品数も5〜10SKUに絞って試験運用することをおすすめします。始める順番の目安は以下の通りです。

  1. まず1モールで、手作業によるSEO改善フローを言語化する（第1段階の完了）。
  2. 次に同じ商品群に対して、AIを使った改善案生成を試す（第2段階の検証）。
  3. 改善案の質と承認にかかる時間が安定してきたら、GASでフローを半自動化する（第3段階への移行）。
  4. 動作が安定したら、対象商品数・対象モールを順に広げる。

失敗しても戻せる設計を維持する

スプレッドシートに元の文言と改善案を並べて管理する設計にしておくと、採用した変更が期待通りに機能しなかった場合でも元の状態に戻せます。モールによっては変更履歴が残る機能もありますが、自分で管理する記録を持っておくほうが確実です。

また、モールへの反映タイミングも一度に全件を更新するのではなく、少数ずつ試してから横展開するほうが安全です。変更前後の検索流入数や購買率を比較できる期間を確保してから次の変更に進む、という運用サイクルを組むことで、効果の有無を判断しやすくなります。

仕組み化の目的は「改善を継続できる状態を作ること」

商品ページのSEO最適化には、確定した正解がありません。モールのアルゴリズム・競合の動き・消費者の検索行動は常に変化するため、「一度良い状態にしたら終わり」にはならないことが前提です。

仕組み化の本質は、この「継続的な見直し」をコストをかけずに回し続けられる状態を作ることです。人の作業時間を仕組みに置き換えることで生まれた余裕を、「どのキーワードが今伸びているか」「競合はどう変化しているか」という判断業務に充てられるようになれば、仕組み化は機能しています。relmeaは、このフローを自社のモール運営の中で実際に設計・運用しながら、EC事業者向けの教材として整備を続けています。