複数のネットショップを運営していると、商品の説明文を直すだけでも店舗の数だけ作業が発生します。セール価格の戻し忘れや、売れた商品の在庫更新の遅れは、売上だけでなく購入者への対応にも影響します。TEMPOSTARは、こうした商品・在庫・受注の情報を複数店舗にまたがって管理するサービスです。
導入を判断する際は、対応店舗の数よりも、自社が使いたい処理まで連携できるかを見る必要があります。本記事では、TEMPOSTARの機能、スターターとスタンダードの料金条件、商品連携の注意点を整理し、試用から本番運用へ移るまでの進め方を紹介します。料金・機能は2026年10月16日に確認した公開情報を基にしています。
複数のEC店舗の運営を見直したい方は、FORCE-Rへご相談ください。
| 確認したいポイント | 結論 | 詳細 |
| TEMPOSTARとは？ | 商品・在庫・受注の一元管理サービス | 複数のEC店舗の情報を集め、店舗ごとの更新や確認を効率化します。 |
| 料金を確認するポイントは？ | プランの上限と課金条件を区別 | スターターの利用上限と、スタンダードの商品・受注課金、最低月額を確認します。 |
| 導入前に試すことは？ | 自社の商品と例外注文を検証 | 商品コードと連携範囲を確認し、少数の商品・注文で実際の手順を試します。 |
Contents
TEMPOSTARとは？複数店舗の商品・在庫・受注を管理するサービス
TEMPOSTARは、複数のEC店舗の商品情報、在庫、注文を一つのシステムで扱うためのサービスです。SAVAWAY株式会社が提供しています。ネットショップそのものを新設するカートとは役割が異なり、すでに利用しているモールやカートと情報をつなぎ、日々の更新や確認の手間を減らす用途が中心です。
例えば、楽天市場とYahoo!ショッピングで同じ商品を販売している場合、店舗ごとに説明文や販売価格を管理しながら、実物の在庫を共通で使うことがあります。店舗別の表示と共通の商品情報を分けて管理できれば、同じ説明を何度も入力する作業を減らせます。注文情報も集めることで、各管理画面を巡回する時間を短くできます。
サービスの対象範囲は、TEMPOSTARの公式サービス案内で確認できます。商品管理、在庫管理、受注管理という機能名だけで判断せず、自社で何を入力し、どの店舗へ反映し、その後に何を確認するのかを順に照らし合わせると、導入後の使い方を具体化しやすくなります。
ASP型の仕組みとカート・倉庫システムとの役割分担
ASP型とは、提供元が用意するシステムをインターネット経由で利用する仕組みです。自社で一から一元管理システムを開発する場合と比べ、既存の機能を利用して業務を整えやすい点が特徴です。ただし、既存機能に業務を合わせる範囲と、個別の対応が必要な範囲を分ける必要があります。
購入者が商品を選び、決済する画面は、通常は各モールやカートが担います。TEMPOSTAR側では、その先の注文確認や在庫・商品情報の更新を扱います。物流倉庫での棚入れ、商品の取り出し、梱包といった実作業は別に残るため、一元管理を入れるだけで物流全体が完了するわけではありません。
すでに倉庫システムや基幹システムがある場合は、同じ情報を両方で更新しないようにします。例えば、入荷実績は倉庫側、販売用の説明文は商品管理側というように、情報ごとの更新元を決めます。更新元が曖昧なままだと、担当者が正しく直した値が、別のシステムから古い値に戻される原因になります。
ハイブリッドカスタマイズで調整できる範囲を確認する
個別の業務に合わせた拡張を相談できることが、TEMPOSTARの特徴の一つです。公式サイトではハイブリッドカスタマイズとして案内されています。標準機能で運用する部分と、自社の条件に合わせる部分を組み合わせる考え方ですが、希望した処理がすべて標準料金に含まれると考えるのは避けましょう。
相談する際は「今の作業を全部再現したい」だけでなく、どの条件で、何を判定し、どのデータを変えたいのかを伝えます。特定の配送条件に当てはまる注文を別の担当者へ回すのであれば、対象地域、商品区分、確認者、確定後の出力先までを説明すると、標準設定で足りるかを判断しやすくなります。
既存手順をそのまま残すより、手順を見直した方が費用を抑えられることもあります。例外処理の件数と作業時間を計測し、個別対応の費用に見合うかを検討してください。拡張を依頼する場合は、完成条件、保守、将来の仕様変更時の対応も含めて確認しておくと、導入後の認識のずれを減らせます。
商品管理でできることと店舗別の調整
商品管理では、共通の商品情報を基に、店舗に合わせた情報を扱いながら更新できます。複数の店舗へ同じ商品を展開する際に役立ちますが、各店舗の入力項目や掲載条件は同じではありません。共通化してよい内容と、その店舗だけで持つ内容を分けることが、更新ミスを防ぐ出発点になります。
例えば、素材や寸法は共通の商品情報にできます。一方、商品名の長さ、カテゴリ、販売価格、画像の見せ方は販路に応じた調整が必要です。全店舗で同一の説明文を使うことを目的にせず、商品の事実は共通に保ち、購入者に伝える方法は店舗に合わせると考えると整理しやすくなります。
一括登録・更新は商品コードの対応関係から整える
一括更新を正しく使うには、各店舗の商品と管理元の商品が対応していることが前提です。見た目が同じ商品でも、色やサイズの組み合わせが違えば別の在庫として扱う必要があります。商品番号、選択肢の値、セット構成などを確認し、別の商品へ更新がかからない状態を先に作ります。
最初に全商品を移すより、通常商品、複数の選択肢がある商品、セット商品などを少数ずつ選んで確認する方法が現実的です。商品名だけでは区別できない場合は、社内の商品コードと各店舗の商品コードを対応表にします。長年使っていない重複コードがあれば、この段階で扱いを決めます。
画像や説明文の更新では、管理画面の登録結果だけでなく、販売ページの表示も確認します。画像の順番、選択肢の名称、改行、カテゴリの所属が想定どおりかを見てください。TEMPOSTARの公式商品管理機能案内に記載された処理であっても、利用先の仕様によって反映できる項目が変わるため、店舗ごとの確認が必要です。
予約反映はセール終了後まで含めて設計する
予約反映は、更新する内容と反映する時点を決めて、公開作業を準備するために使います。セールの開始に合わせた価格や説明の変更を計画しやすくなります。ただし、開始時の作業だけを設定し、終了後に通常表示へ戻すことを忘れると、販売条件の誤りにつながります。
セール用の価格、対象期間、通常価格に戻す内容、担当者を一組で記録します。予約を登録した人とは別の人が内容を見られる体制にすると、日付や対象商品の取り違えを発見しやすくなります。予約した時刻と購入者に見える時刻が常に完全一致するとは限らないため、公開直後の確認時間も確保します。
複数店舗で同時に施策を行う場合も、モール側のイベント期間や価格表示のルールを個別に確認してください。一括更新ができることと、各店舗で同じ販売条件を採用できることは別の問題です。更新対象を一覧にし、開始と終了の両方で確認担当を決めておくと、作業が特定の担当者に集中しにくくなります。
商品更新や注文対応の課題を整理したい方は、FORCE-Rへお問い合わせください。
在庫連携と受注管理は例外処理を決めて使う
在庫と注文を連携するときは、通常の処理と、人が確認する処理を分けることが大切です。複数店舗の在庫を共有しても、キャンセル、返品、入荷待ち、住所変更などの判断は残ります。日常的に起きる例外を事前に把握し、どの段階で止めるかを決めると運用を安定させやすくなります。
在庫の数字が合っていても、すでに別の注文へ引き当てた分を販売してしまえば出荷できません。受注管理では、注文を集めることに加えて、支払い確認や出荷可能な状態までを見ます。商品、在庫、受注を別々の担当者が扱う場合は、どの状態になったら次の担当へ渡すのかをそろえてください。
共通在庫・セット商品・複数拠点の数量を区別する
販売可能数は、実際にある数から、すでに確保した分や販売を止める分を考慮して決めます。倉庫に十個ある商品でも、出荷待ちの注文に八個確保されていれば、新規注文に使える数は十個ではありません。不良品、検品待ち、展示用の商品も、販売用と分ける必要があります。
セット商品では、構成する単品がそれぞれどれだけ必要かを登録します。同じ単品を単独でもセットでも販売する場合、セットの販売によって単品の数量も動く関係を確認してください。構成変更を行う際は、古いセットの注文が残っているかも確認し、注文時点の内容を取り違えないようにします。
複数拠点を利用する場合は、拠点別の数量と、どこから出荷するかの条件を確認します。実店舗との連携も考えるなら、O2OとOMOの違いの解説を参考に、顧客への案内と在庫の持ち方を整理できます。在庫を共通表示するだけで、取り置きや店舗受け取りの手順まで成立するとは限りません。
在庫の更新には、店舗側の処理や通信を含む時間差が生じます。販売が集中する商品では、表示する数に余裕を持たせるなど、自社の運用条件に合わせた対策を検討します。TEMPOSTARの公式在庫管理機能案内を基に、どの数量がどの処理で動くかを確認し、売り越しが発生しないと一律に保証しないことが重要です。
受注タグを使い確認が必要な注文を見つける
受注タグは、条件に当てはまる注文を区別し、担当者が優先して確認するために使えます。ギフト、初回購入、高額な代引注文など、確認したい条件を整理すると役立ちます。タグを増やすだけでは処理は速くならないため、タグごとに確認する内容と担当者を決めておきます。
例えば、住所に不足がある注文は出荷を保留し、購入者への確認が終わるまで進めないようにします。別の商品を追加する依頼や配送方法の変更は、決済金額や送料に影響することもあります。タグを付けることと、注文の内容を自動で書き換えることを区別し、変更後に再確認が必要な項目も定めます。
TEMPOSTARの公式受注管理機能案内と料金ページでは、機能とオプションの条件を合わせて確認してください。受注タグの利用から、条件に応じた配送方法・送料・商品の自動更新まで、すべてが同じ提供条件とは限りません。受注自動更新機能のように有料オプションとなる処理は、見積もりと試用時の対象に含めます。
TEMPOSTARの料金はプランと利用件数で確認する
料金は、スターターとスタンダードの条件を分けて確認する必要があります。TEMPOSTARの公式料金ページに掲載された金額は税込です。月額の表示だけを比較すると、使える店舗数や登録件数、サポート、追加機能の違いを見落としやすくなるため、現在と半年後の利用規模を並べて検討しましょう。
料金の確認では、商品登録数、月間の受注数、利用する店舗数をそれぞれ集計します。繁忙月だけ注文が増える場合は、平均月と繁忙月を分けると予算を組みやすくなります。システムの利用料金とは別に、商品データの整理や担当者の教育にかかる時間も導入時の負担として見込んでおきます。
スターターは月額1,650円で利用上限がある
スターターは月額1,650円で、受注月200件以下、商品登録2,000点以下、連携2店舗という条件があります。小規模な運営で検討しやすい金額ですが、件数の条件と必要な機能の両方に収まるかを確認します。単に最も安いプランという理由だけで選ぶと、運用開始後に足りない条件が出てきます。
公開料金表では、スターターのサポートはメール、支払いは事前のクレジットカード登録が必要とされています。オプションの利用と30日間の無料デモは対象外です。無料デモがあるサービスだからといって、スターターも同じ条件で試せると考えないようにしてください。
注文が増えた場合の対応も、契約前に確認しておきます。たとえば、通常月は百五十件でも、年末だけ三百件になる見込みなら、上位プランへの移行条件を把握する必要があります。商品数が少なくても、必要な処理がオプションでしか使えない場合は、スターターが適しているとは限りません。
スタンダードは最低月額と商品・受注の課金を区別する
スタンダードは、商品課金と受注課金を基に計算し、最低月額11,000円が適用される料金体系です。最低月額にすべての課金を上乗せする方式と読み違えないことが大切です。利用条件によって月額が変わるため、料金ページの計算条件と自社の件数を照らし合わせます。
商品登録数が1〜2,000点の区分では、商品課金は月額2,200円です。受注の従量課金は、1〜600件の部分が1件27.5円、601〜2,000件の部分が1件22円と、件数の区分ごとに計算します。1,500件だから全件が22円になる、という計算ではありません。
公式の例では、商品1,000点、受注1,500件の場合、商品課金2,200円に、600件分16,500円と残り900件分19,800円を加え、月額38,500円になります。一方、商品1,000点、受注200件で計算した合計は7,700円となるため、最低月額の11,000円が適用される考え方です。
受注課金には定額の選択肢もあり、商品の登録区分が上がれば商品課金も変わります。受注管理と在庫管理を両方使う場合の課金件数は、取り込んだ件数の多い方を基にする旨が案内されています。出荷した件数だけで予算を組まず、課金対象の数え方を確認する必要があります。
商品点数についても、公式ではSKUではなくアイテムを基にする説明があります。色・サイズのある商品を何点と数えるかは、社内の集計方法と料金上の定義が一致するかを確かめます。カスタム対応、オプション、大規模な件数の見積もりは個別に確認し、公開料金だけで最終費用を確定しないようにします。
システムの比較と合わせて販路ごとの運営を改善したい方は、FORCE-Rへご相談ください。
対応モールは受注・在庫・商品を分けて確認する
対応先の名称が載っていても、受注・在庫・商品が同じ範囲で連携できるとは限りません。TEMPOSTARの公式連携一覧では、機能別の対応と備考を確認できます。自社が必要とする作業を列挙し、標準で使える処理、追加対応が必要な処理、対象外の処理に分けると比較しやすくなります。
例えば、注文を取り込めても、新商品の登録までできるとは限りません。API、CSV、FTPなどの方法によっても、操作の手順や反映の確認方法が変わります。「連携できる」という説明を、手作業なしですべての情報が即時に動くという意味へ広げず、どの情報がどちら向きに動くかを確認してください。
Amazonの商品連携とShopifyのβ版には条件がある
Amazonの商品連携では、カタログ登録が非対応という備考を確認する必要があります。既存商品への出品や情報の更新を扱うことと、新たな商品カタログを作ることは別の作業です。新商品を頻繁に投入する場合は、TEMPOSTAR以外で残る登録作業を導入後の手順に含めておきます。
Shopifyについては、2026年10月7日の公式案内で、商品API連携機能のβ版提供が発表されています。Shopifyからの商品情報の取り込みやTEMPOSTARからの反映、画像・メタフィールドなどが案内されていますが、β版という提供段階を踏まえ、利用対象や制約を確認してから本番の商品を扱います。
確認には、TEMPOSTARのShopify商品API連携β版のお知らせを使えます。以前の比較記事に商品連携の記載がない場合でも、現在の公式情報を基準にしてください。Shopify在庫管理の解説も参照し、販売場所や在庫の管理方法を整理しておくと、連携時に確認すべき項目を絞り込めます。
新しい販路と既存アプリの組み合わせも点検する
新しい販売先を増やす場合は、商品掲載から受注・出荷まで一連の流れが成立するかを確認します。モール側の設定、外部サービス、個別対応が必要なこともあります。連携一覧の一つの記号だけで導入を決めず、備考と利用条件を合わせて読んでください。
SNSを起点とする販売では、投稿や動画から注文へ至る経路も把握しておきます。ソーシャルコマースの種類と注意点の解説を参考に、どこで注文が確定し、その注文をどこへ集めるかを整理できます。問い合わせだけがSNSへ届く場合は、その連絡を受注情報へ反映する担当も必要です。
カートに独自のアプリを入れている場合は、追加された項目がそのまま連携できるとは限りません。定期購入、名入れ、予約販売、複雑な割引など、自社特有の条件を一覧にします。試用では標準的な注文だけでなく、こうした注文を一件ずつ流し、欠ける項目や手入力が残る箇所を確かめます。
導入は少数の商品と注文で検証してから広げる
導入時は、データを整え、少数の対象で処理を確認し、問題を直してから対象を広げます。最初から全店舗・全商品を一度に切り替えると、誤りの原因が商品情報、店舗設定、注文処理のどこにあるかを調べにくくなります。販売を続けながら変更する場合は、戻し方も先に決めておきましょう。
TEMPOSTARの公式導入手順では、デモ利用から契約へ進む流れを確認できます。30日間の無料デモには対象プランの条件があり、スターターは対象外です。期間中に試したい処理を決め、担当者が使える日を確保してから申し込むと、設定だけで期間が終わることを避けやすくなります。
試用前に現状の手順と確認用データを用意する
試用の準備では、現在の作業手順と、結果が正しいかを判断するためのデータをそろえます。受注件数や商品数だけでなく、商品更新にかかる時間、在庫修正の頻度、確認のために開く画面の数も記録します。導入後に減らしたい作業が明確なら、試用の評価もしやすくなります。
確認用の商品には、通常商品、色・サイズ違い、セット、予約商品など、実際に扱っている種類を選びます。受注では、通常配送、ギフト、キャンセル、住所変更、欠品などを用意します。購入者へ通知が送られる処理は、確認用の注文で安全に試せる方法を提供元へ確認し、実際の顧客へ誤送信しない手順にします。
結果は「動いた」という記録だけでなく、入力値、連携先の表示、所要時間、担当者が修正した箇所を残します。期待した結果と違う場合は、設定の変更で解決できるのか、機能上の制約なのかを切り分けます。個別対応が必要なら、費用と利用開始の時期を確認してから本契約の判断に含めてください。
切り替え時は二重更新と取り込み漏れを防ぐ
本番への切り替えでは、旧システムとTEMPOSTARが同じ情報を同時に更新しないようにします。在庫を両方から送信すると、値が上書きされることがあります。どの時点までの注文を旧手順で扱い、それ以降を新手順へ渡すかを明確にすると、二重処理と取り込み漏れを確認しやすくなります。
切り替え直前には、未出荷注文、保留中の注文、未反映の在庫、更新予約を一覧にします。新しい側へ移す対象と旧手順で完了させる対象を分け、件数や金額を照合します。店舗へ送る在庫や商品情報は少数から確認し、問題があれば連携を止められる担当者を決めておきます。
切り替え後は、受注の取り込み、在庫の減少、送り状向けデータ、追跡番号の戻しまでを通して見ます。発送の通知が送られたことと、実際に荷物が引き渡されたことも区別してください。繁忙日直前を避け、倉庫やカスタマーサポートが連絡を取りやすい日程を選ぶと、異常時に調整しやすくなります。
導入後の業務改善と販促の進め方は、FORCE-Rへお問い合わせください。
導入後は更新時間・例外件数・顧客対応を見直す
導入後の評価では、処理時間が減ったかに加え、ミスや例外への対応が改善したかを見ます。全体の受注件数が増えれば作業時間も増えるため、総時間だけの比較では効果を判断しにくくなります。一件当たりの処理時間、確認が必要な注文の割合、在庫修正の件数を合わせて確認すると、改善箇所を見つけやすくなります。
例えば、受注確認が短くなっても、商品コードの対応ミスで倉庫への問い合わせが増えたなら、その分を含めて評価します。自動処理の対象を広げる前に、人が修正した理由を分類し、繰り返し起きる原因を直します。担当者の確認を減らすこと自体より、正しい処理が安定して進むことを目標にしてください。
集計するときは、注文数、購入者数、アクセス数を混同しないようにします。ユニークユーザーなどの指標の違いの解説を参考に、作業量を見る数値と販促の成果を見る数値を分けておくと、業務改善の効果を説明しやすくなります。件数の定義をそろえることは、利用料金の検証にも役立ちます。
短縮できた時間は、商品情報の改善や、問い合わせへの回答の質を高めることにも使えます。購入後の配送連絡が分かりにくい、返品時の案内が担当者で異なるといった課題があれば、手順の見直しにつなげます。リピート率と向上施策の解説も参照し、効率化が購入者の体験にどう結び付くかを考えてください。
運用が定着した後も、新しい店舗や商品を追加する際は設定を見直します。以前のテストで問題がなかったという理由だけで、異なるアプリや販売条件にも同じ結果を期待しないことが大切です。商品管理、注文処理、倉庫対応の担当者が変更点を共有し、設定を変えた日と理由を記録しておくと、原因調査を進めやすくなります。
まとめ
TEMPOSTARは、複数のEC店舗の商品・在庫・受注を管理し、日常の更新や確認を効率化するための選択肢です。商品情報の共通化と店舗別の調整、在庫の共有、注文の分類を組み合わせることで、複数画面を行き来する作業を見直せます。標準機能と個別対応の境界を確認することが、導入後の使いやすさにつながります。
料金は、スターターの件数・店舗数の上限と、スタンダードの商品・受注課金を分けて比較してください。連携先も、受注・在庫・商品ごとの対応、Amazonのカタログ登録の扱い、Shopifyの商品連携のβ版という条件まで確認します。少数のデータで実際の手順を試し、費用と運用の両面で判断してから対象を広げましょう。
複数店舗のEC運営に課題がある方は、FORCE-Rへご相談ください。TEMPOSTARの個別仕様や契約条件は提供元へ確認し、EC運営支援の範囲は個別にご相談いただけます。
