TikTokカタログ広告のフィード設計｜EC・サービス商材で確認すべき項目

この記事の要点

• TikTokのカタログはEC商品だけでなく、2026年8月時点でサービス志向・非EC向けのGeneric Catalogも用意されています。
• Generic Catalogの必須項目はitem_id、title、image_linkです。
• price、sale_price、availability、video_link、住所、カスタムラベルなどを任意項目として追加できます。
• ウェブサイトやアプリのイベントソースを使う場合、content_idsとカタログitem IDを一致させます。

TikTokカタログフィードは用途で設計を分ける

TikTokのカタログを「EC商品用の一覧」とだけ考えると、サービス商材の設計で迷います。2026年8月更新のTikTok for Business公式ヘルプでは、Generic Catalogをサービス志向・非EC広告主向けに設計されたカタログとして案内しています。

求人、旅行、店舗サービス、不動産、講座など、物販以外でも「1件をIDで識別し、タイトルと画像を持つ」データであればカタログ化の検討対象になります。

Generic Catalogの必須項目

2026年8月の公式ヘルプでは、Generic Catalogの必須項目は次の3つです。

項目	意味	広告表示
item_id	案件を識別する一意ID	表示されない
title	案件名	表示される
image_link	メイン画像URL	表示される

サービス案件に社内IDがない場合、TikTok公式ヘルプはitem_idを作成できると説明しています。ただし一度決めたIDはイベント連携や更新で使うため、後から変更しない規則にします。

任意項目を目的別に追加する

Generic Catalogでは、次のような任意項目が案内されています。

• description
• rating
• link
• additional_image_link
• video_link
• availability
• price
• sale_price
• address_region
• address_city
• address_street
• address_postal_code
• address_latitude
• address_longitude
• custom_label系
• custom_number系

すべて埋める必要はありません。広告や配信判断で使う情報を選びます。

EC商品で確認する項目

ECでは商品ID、商品名、価格、セール価格、在庫、画像、商品URLが中心です。

商品IDはSKU単位で価格や在庫と一致させます。色やサイズごとに在庫が違うなら、子SKU単位でカタログを持つ設計を検討します。

価格はサイトと同期し、セール終了後にsale_priceが残らないよう更新します。欠品商品もavailabilityを正しく反映します。

サービス商材で確認する項目

サービス商材では「在庫」の意味を事業側で定義します。旅行なら空席、求人なら募集状態、不動産なら掲載中/成約、店舗サービスなら予約可否などです。

Generic Catalogのavailabilityを使う場合、自社状態からTikTok側の許可値へどう変換するかを決めます。

住所項目があるため、店舗、物件、施設など所在地が広告価値を持つ案件では活用を検討できます。公式ヘルプは、item location availability情報を提供すると配信ロジックに使う可能性があると説明しています。

item_idとcontent_idsを一致させる

TikTok公式ヘルプは、ウェブサイトやアプリのイベントソースを使う場合、content_idsとカタログitem IDを一致させるよう案内しています。

これは動的広告の基礎です。ユーザーが見た案件IDと、カタログに登録された案件IDが一致しなければ、正しい案件を広告候補にできません。

ECではSKU、求人では求人ID、不動産では物件IDなどを使い、サイトイベントとカタログの両方で同じ値を送ります。

titleは案件を識別できる名称にする

Generic Catalogではtitleが広告に表示されます。求人なら「職種 + 勤務地 + 雇用形態」、不動産なら「物件種別 + エリア + 間取り」、旅行なら「行き先 + 日数 + 出発地」など、案件を識別できる情報を含めます。

内部管理名やコードだけをtitleへ入れると、広告上でユーザーが内容を判断できません。

image_linkは用途に合う画像を使う

TikTok公式ヘルプは明確なタイトルと高品質画像を使うよう案内しています。

ECなら商品を明確に見せる画像、旅行なら施設や行き先、求人なら職場や職種を表すビジュアルなど、案件との一致を優先します。

同じ汎用画像を数千案件へ使うと、案件ごとの差が伝わりません。画像が用意できないカテゴリは、生成やテンプレート化の運用を検討しますが、実際の商品や施設と誤認させる画像は避けます。

video_linkを使う場合

Generic Catalogではvideo_linkが任意項目として案内され、広告表示に使われる可能性があります。

商品レベルの動画がすでにある場合、静止画だけでは伝わらない利用シーンや施設情報を補えます。動画URLの形式、品質、配信条件は実装時の公式ヘルプで確認します。

カスタムラベルをどう使うか

Generic Catalogではcustom_label_0〜6、custom_number_0〜4などが案内されています。表示に使えるものと商品管理用途のものがあります。

例えば次のように使えます。

• custom_label_0: エリア
• custom_label_1: 案件カテゴリ
• custom_label_2: 価格帯
• custom_label_3: 粗利帯
• custom_number_0: 在庫数/残席数

実際に広告作成や管理で利用できる範囲はアカウントや機能の仕様を確認します。

更新頻度は商材の変動速度で決める

求人の募集終了、不動産の成約、旅行の空席、ECの欠品など、掲載可否が変わる商材は高頻度更新が必要です。

一方、住所や説明文のように変化が少ない項目は低頻度でも構いません。全項目を同じ頻度で再生成する必要はありません。

サービス商材では「在庫切れ」に相当する状態を何と定義するかを運用前に決めます。

よくある失敗

EC用項目をサービスへ無理に当てはめる

旅行や求人で商品在庫と同じ概念が使えない場合、事業上の状態を定義してから変換します。

item_idを表示用名称から作る

案件名変更でIDまで変わります。内部で不変の識別子を使います。

content_idsとitem_idが違う

イベントとカタログを結び付けられません。

住所を1つの文字列でしか持っていない

Generic Catalogの住所項目を使うなら、都道府県、市区町村、番地、郵便番号、緯度経度へ分解できるデータ設計を検討します。

実務チェックリスト

• ECかGeneric Catalogか用途を決めた
• item_idが一意で不変
• titleがユーザーに案件内容を伝える
• image_linkが案件と一致する
• content_idsとitem_idが一致する
• price/sale_priceがサイトと一致する
• availabilityの業務定義がある
• サービス商材の住所項目を分解できる
• video_link利用可否を確認した
• custom_labelの用途を決めた
• 更新頻度を価格/在庫/募集状態から決めた
• 仕様変更を公式ヘルプで確認する担当がいる

公式情報と更新時点

最終確認日: 2026年8月29日。

• TikTok for Business「Available fields for Generic Catalog」

同ページは2026年8月更新として公開されています。TikTokのカタログ機能と必須項目は変更される可能性があるため、実装前に公式ヘルプの確認を推奨します。

Generic Catalogでサービス状態を標準化する

求人の「募集中/停止」、不動産の「掲載中/成約」、旅行の「空席あり/満席」は、事業ごとに状態名が違います。

TikTok側へavailabilityを送るなら、自社状態→媒体状態の変換表を作ります。変換不能な状態をどう扱うかも決めます。

住所データを広告用に整える

店舗や物件の住所を1つの文字列だけで持っていると、region/city/street/postal_codeへ分解しにくくなります。

都道府県、市区町村、町名番地、郵便番号、緯度経度を構造化して持つと、TikTok以外の地理配信やローカル在庫にも再利用しやすくなります。

サービス案件の削除・終了を管理する

募集終了求人や成約物件をカタログへ残さないよう、終了日時または掲載状態を商品マスターに持ちます。

日次バッチで終了案件を除外し、高頻度で状態が変わる場合は差分更新を検討します。

Generic Catalogのデータ品質を数値で見る

item_id重複、title空欄、image_link取得エラー、価格空欄、住所欠損、終了案件残存を定期集計します。

サービス商材では募集終了・成約済み案件が残っていないかを重要指標にします。

ECとサービスで同じマスターを無理に共有しない

EC商品と求人案件では必須属性が大きく違います。共通のID、title、image_linkなどは同じ仕組みを使えても、価格、在庫、住所、評価などの意味は別です。

データモデルは商材別に持ち、TikTok出力層で共通項目へ揃える方が管理しやすくなります。

サービス商材のtitleテンプレート

求人なら職種 + 勤務地 + 雇用形態、不動産なら物件種別 + エリア + 間取り、旅行なら行き先 + 日数 + 出発地のように、案件を識別する属性順を決めます。

同じ案件名だけでは差が分かりにくい場合、ユーザーが比較する属性を追加します。

Generic Catalogの画像テンプレート

サービス案件で個別画像がない場合、カテゴリ別のテンプレート画像を使う方法があります。ただし実際の施設、物件、求人内容と誤認させる表現は避けます。

画像生成を自動化する場合も、案件IDと画像URLの対応を固定し、終了案件の画像を使い回さないようにします。

イベント連携の監査

item_id一覧とcontent_ids一覧を定期突合します。

新規案件がカタログには入ったがサイトイベントでは旧IDを送っている、といった差分を検知します。

住所データの品質確認

住所項目を使う場合、都道府県、市区町村、郵便番号の欠損や表記揺れを確認します。

緯度経度を持つ場合は、住所と大きくずれていないかをサンプル確認します。

Generic Catalog導入の最小構成

非EC事業で最初に試すなら、item_id、title、image_linkに加え、link、availability、priceまたは地域情報など事業に必要な項目だけで始めます。

全任意項目を埋める前に、イベントID一致と案件終了の反映が安定しているかを確認します。

終了案件の再掲載

求人再募集や物件再掲載で同じ案件IDを使うか、新IDにするかを業務ルールで決めます。

内容が実質同一で履歴を継続したい場合と、別案件として扱う場合を分けます。

サービス価格の扱い

「月額○円〜」「最低価格」「プラン別価格」など、単一価格にできないサービスは、TikTok側のprice仕様と広告表示を確認します。

誤解を招く代表価格を入れず、ランディングページと整合する値を使います。

Generic Catalogの月次監査

item_id重複、終了案件、画像エラー、価格不一致、住所欠損、イベントID不一致を集計します。

EC商品より案件の入れ替わりが多い事業では、終了案件残存率を重点的に見ます。

実装前の代表案件テスト

EC商品とサービス案件の双方で使う場合は、それぞれ代表案件を選び、item_id、title、image_link、イベントID、終了状態の反映を確認してから全件投入します。