Gorgiasレビュー【2026年】EC向けヘルプデスクの課金設計を読む

Gorgiasは、ECサイトの顧客対応に特化したヘルプデスクです。2026年時点で最大の特徴は、AIエージェントが全プランに同梱され、「解決した会話にだけ課金する」という従量設計を採っている点にあります。ヘルプデスク本体は月50〜5,000チケットの帯で選ぶ方式で、担当者の人数では課金しません。公式の料金ページはプラン名と構成は確認できるものの、金額はページ上で描画される形式のため今回の実査では取得できませんでした。以下は公開情報にもとづく整理で、動作の実機テストは行っていないため、その部分は未検証とお考えください。

Gorgiasとは？EC特化の受信箱が「解決課金」へ移った意味

Gorgiasは、ECサイトの顧客対応に特化したヘルプデスクです。メール、チャット、SNS経由の問い合わせを一つの受信箱に集め、注文データと結びつけて処理する設計が基本になります。2026年時点の公式ページは、ヘルプデスクとAIエージェントを一つの受信箱に統合した体制を打ち出しています。提供形態はクラウド型のサービスで、ショップ系プラットフォームとの連携を前提にした設計です。

規模の印象を示す数字として、公式ページには「Shopifyブランドの4割」を顧客に持つという表示があります。これは公式自身の訴求であり、第三者調査で裏取りした数字ではない点に留意してください。それでも、ECの受信箱という市場で一定の位置にいる製品だと読む材料にはなります。導入検討では、この種の自己申告の数字と、自店の条件が合うかを分けて考えます。

注目すべきは課金の軸です。従来型のヘルプデスクは、担当者一人あたりのシート料金で課金するのが一般的でした。Gorgiasは、ヘルプデスク本体を月50〜5,000チケットの帯で課金し、AIが解決した会話にだけ別途課金する。人を課金の単位から外し、処理量と解決に置き換えた点が、2026年時点のこの製品を最も特徴づけています。

なぜ担当者数ではない課金がECに向くのか

ECの顧客対応は波が大きいのが常です。セールや配送シーズンには問い合わせが集中し、それ以外の月は閑散とします。シート課金の世界では、繁忙期に増えた人員がそのまま月額に乗り、閑散期になっても下がりにくいという構造的な不満がありました。チケット帯の課金は、この波をある程度吸収します。人を減らさずに済む月と、人を足しても費用が跳ねにくい月の両方を作れるからです。ECの運用の実態に合った課金設計だと考えます。

だからといって万能ではありません。チケット数そのものも繁忙期には増えるため、選んだ帯を超えると費用が上振れます。つまりこの設計は「人件費の心配」を「チケット数の心配」に置き換えるものです。どちらの心配のほうが管理しやすいかは、店舗の運用体制次第で変わります。この点は後の節で改めて扱います。

補足として、比較の起点として押さえておきたい三つの点を先に並べておきます。課金の軸が人数か処理数か。AIの費用が成果に連動するか。そして、自店のプラットフォームとの連携がどの深さまであるか。この三点は、機能の多さの比較よりも先に確定させるべき事項です。どれか一つでも自店の運用とぶつかるなら、他の項目がどれだけ揃っていても候補から外す判断が必要になります。

言い方を替えれば、ECの顧客対応では費用を人数ではなく処理量と解決に連動させる設計が、2026年の選び方の一つの基準になりつつある、ということです。Gorgiasはその方向に最も踏み込んだ構成の製品として、比較の起点になります。

Gorgiasの料金プラン（2026年10月時点）

料金の読み方に入る前に、一つ正直に書いておきます。公式の料金ページはプラン名と構成が確認できる一方、金額はページ上で描画される形式のため、今回の実査では取得できませんでした。したがって具体的な月額の数字は書けません。金額そのものは、必ず公式サイトの料金表を確認してください。この記事で提供できるのは、金額の周りにある「課金の決まり方」の読み方です。

プランの金額は2026年10月24日時点の実査では取得できていません。この表は課金の構造だけを整理したものであり、金額の判断は公式料金ページと契約画面の表示、および問い合わせ窓口の見積りで行ってください。

この構造表から読めるのは、総額が三つの部品の合計になるということです。チケット帯の固定費、解決課金の従量費、アドオンの追加分。この三つを分けて見積もると、「この店なら月にどれだけかかるか」の検討が立体的になります。金額が一つの数字で表示されない契約ほど、部品分解の習慣が重要になります。

金額が表示されない契約で確認すべき項目

稟議や予算申請の前に確認したいのは、五つです。チケット帯を超えた場合の扱い。解決した会話1件あたりの費用の扱い。VoiceとSMSの各段階の起点。年払いの有無と割引。そして日本語でのサポート体制。特に最初の三つは、運用の揺らぎが費用に直結する部分です。書面で確認せずに契約すると、繁忙期の請求額を説明できない恐れがあります。

確認の際には、自店の実データを手元に置くのが効果的です。直近半年の月次チケット数、そのうちAIに任せられそうな問い合わせの割合、電話とSMSの発信量。この三つの数字があれば、営業担当との話が抽象論になりにくくなります。料金の確認は「いくらですか」と聞くだけではなく、自店の数字を当てはめてもらう作業だと考えています。

見積りの比較では、三社程度に同じ質問を同じ形式で送るのが効率的です。質問の形式は、月次チケット数の想定、AIで解決する件数の想定、通話とSMSの想定を並べた一行の表にします。返ってきた見積りを同じ形式の表に写せば、金額の差だけでなく、条件の差も同じ視線で読めます。営業担当の説明を記録として残す意味でも、書面でのやり取りを基本にしてください。

「解決した会話にだけ課金」は何を変えるか

AI Agentの課金は、解決した会話にだけ発生します。AIが回答しても顧客の問題が解決しなければ課金されない、というのが公式の説明の読み方です。これは従来のAI課金と大きく違う点です。一般的なAI機能は「使ったこと」に課金するため、精度が低ければ利用者側が損をします。Gorgiasの設計は、成果そのものに費用を連動させており、ベンダー側が精度のリスクを引き受ける形に近い。ECの顧客対応という、成果の判定が比較的はっきりした領域だから成立する仕組みだと考えます。

ただし冷静に読むべき点もあります。「解決」の判定は、結局のところ運用側の設定とベンダー側の仕組みの組み合わせで決まります。どこまでを解決と数えるのか。会話を閉じた時点なのか、一定期間返信がない時点なのか。この定義が曖昧なまま運用すると、実態に合わない課金が積み上がる恐れがあります。契約時に解決の判定条件を確認し、運用側でも受信箱の閉じ方のルールを整えることが、この課金モデルの前提になります。

解決課金が向く店舗・向かない店舗

向くのは、問い合わせの種類が定型的な店舗です。配送状況の確認、返品や交換の手続き、サイズや在庫の標準的な質問。この種の問い合わせはAIの成果が判定しやすく、解決課金の恩恵が受けられます。反対に向きにくいのは、商材が複雑で回答そのものに人の判断が要るケースが多い店です。BtoB的な商材や高額品、受注生産の店では、AIが回答を用意しても最終的な解決に人間の承認が挟まりやすく、「解決」の判定が運用に依存しすぎます。これは公開情報から読み取れる構造の話であり、実際の判定精度は未検証です。

導入を考えるなら、最初に自店の問い合わせを分類して、定型がどれだけあるかを数えるのが最初の一歩になります。直近のチケットを件名で仕分けるだけで構いません。定型が過半を占めるなら解決課金の相性は良いはずですし、個別対応が過半ならAIの役割は下書きと補助にとどまるので、課金の期待値も小さく設定すべきです。

ここで引用しておきたいのが、AI課金の総額はモデルの性能そのものではなく、受信箱の閉じ方の設計で決まる、という点です。同じ製品を入れても、会話の閉じ方の運用が曖昧な店と、閉じ方のルールが明確な店では、解決課金の額も判定の信頼性も変わります。道具の選定と同じくらい、受信箱の運用設計に手を入れる覚悟が要る契約だと考えます。

閉じ方のルールの一例を挙げます。問い合わせを、ワンタッチで完結する類型、手続きの完了を待つ類型、人の判断を要する類型の三つに分けます。一つ目はAIに任せて閉じる。二つ目は進行中のまま放置せず、期限を決めて見る。三つ目は最初から人に振る。この仕分けが受信箱の運用として定着すれば、解決の判定も安定します。仕分けの基準は、最初の月に一度だけ時間を取って決めれば十分です。

なお、解決課金の具体的な単価は公開情報の範囲では確認できていません。料金の総額を試算するときは、公式サイトの料金表の確認に加え、月次の問い合わせ件数のうちAIで解決できそうな件数を自店で見積もった上で、見積りを取るのが堅実です。この部分の数字は実査でも取得できていないため、推測で埋めないようにします。

チケット数課金で担当者数では課金しない設計の読み方

ヘルプデスク本体が担当者数ではなくチケット数で課金されることには、実務上の意味が二つあります。一つは、人を増やしても月額が変わらないことです。繁忙期にパートや臨時の担当者を足す、アルバイトの研修のために管理権限を広く配る、といった運用が費用に直結しません。もう一つは、部署間の費用配分がしやすくなることです。シート課金だと「誰のアカウントか」で予算の帰属を決める論争が起きますが、チケット基準なら処理量で配分できます。

一方で、チケット数は業務の性質次第で簡単に増えます。注文単価の低い店舗は一件あたりの利益が薄いのに問い合わせは多くなりがちですし、キャンペーンのたびに確認の連絡が増えます。つまりこの課金設計は「人件費の心配を処理数の心配に置き換える」ものであり、処理数の管理が甘い運用では費用が読めなくなります。帯の選び方が実質的な予算設計です。

判断の分かれ目。繁忙期の上振れに帯で備えるか従量で受けるか

分かれ目は、年間のチケット数の季節変動をどう読むかです。公開情報の範囲では、帯を超えた場合の具体的な扱いまで確認できていません。そのため実務的な進め方としては、直近一年の月次チケット数を並べて、最も多い月の数字で帯を選ぶのが安全側の発想になります。逆に、繁忙期以外の月が圧倒的に少ない店舗では、下位の帯で始めて上振れの対応を従量で受けるほうが総額が下がる可能性もあります。どちらが得かは、上振れの頻度と超過時の扱い次第なので、ここは見積りの段階で確定させるべき論点です。

VoiceとSMSの扱いも整理しておきます。どちらも本体プランとは別のアドオンで、通話や送信の量に応じた段階制になっています。電話対応を含めるかどうかで費用の形が変わるため、検討時には本体とアドオンを分けて見積もるのが読みやすいでしょう。

担当者数で課金しないヘルプデスクは、人員の増減を予算案から切り離せる、というのがこの設計への要約になります。ただし切り離せるのは予算の議論であって、業務量そのものの管理は残ります。むしろ人ではなく処理数が予算の言語になるため、受信箱の運用データを月次で見る習慣が、この製品との相性を決めると考えます。

月次の記録の見方も決めておきます。見るのは三つの数字で足ります。総チケット数、AIに任せた件数、そのうち解決に至った件数。この三つが揃うと、解決課金の部分の費用も、後から説明できる形で残ります。記録の担当を決めずに始めると、二か月目から途切れがちなので、受信箱の管理者に役割として渡すのが確実です。

運用データを持っていない店舗は、導入前の二か月間だけでもチケット数を記録することを勧めます。月曜とセール明けで数がどう動くか、どの曜日に電話が増えるか。この記録があるだけで、帯の選択もアドオンの要否も、感覚ではなく数字で議論できます。課金の単位が変わった時代には、予算の言語も処理数に寄せるのが自然です。

評価できる点（公開情報からの判断）

• AI Agentが全プランに同梱され、AIの入口が上位プランで切り離されていない
• 解決した会話にだけ課金するため、効果が出ない場合の費用リスクをベンダー側が分担する構造
• 担当者数では課金しないため、繁忙期の増員や研修用の権限付与が月額に直結しない
• チケット帯が月50〜5,000と幅広く、小規模な店舗から選べる
• VoiceとSMSをアドオンとして後付けでき、電話・SMSの要否を段階的に決められる
• ECプラットフォームとの連携を前提とした設計で、注文情報を受信箱に引き込む使い方ができる

第一に評価したいのは、課金設計の誠実さです。AI機能を有料オプションとして切り売りするのではなく、全プランに同梱した上で、成果である「解決」にだけ費用を連動させる。AIの精度が問われる時代に、ベンダー側が成果で受ける体制を選んだのは、ECの顧客対応という領域への自信の表れだと読めます。利用者側にとっては、AIに任せた分の費用が成果と無関係に膨らむ心配が減る、という実利があります。

加えて評価したいのは、担当者数の課金からの解放がECの採用事情と噛み合う点です。シーズンごとに人員を増減させる運用はECで一般的であり、そのたびにシートの追加と削除を管理する手間と費用が発生するのは不満としてよく聞く話です（この点は一般論であり、実測ではありません）。チケット基準の課金は、この管理をそもそも不要にします。

三つ目は、チケット帯の幅です。月50から月5,000までの帯が用意されているということは、出品直後の小さな店舗から、規模の大きな運用の店舗まで、同じ製品の上で成長の道筋を描けるということです。プランの乗り換えが予算の再設計になるシート課金の世界では、成長期に予算の議論が何度も発生します。処理数基準なら、成長に合わせた帯の移動だけで済みます。

編集部として付け加えるなら、これらの評価はすべて公開情報にもとづく構造の読み方であり、実際の画面の操作性やAIの回答品質は未検証です。良い点として挙げた項目も、自店での動作確認を経て初めて確定します。この留保を前提に読んでください。

気になった点・条件付きの評価

• プラン金額が公開表示されず、総額の事前試算が立てにくい
• 日本語対応は未確認。管理画面・AIエージェントの日本語品質ともに公開情報の範囲で確認できていない
• 解決した会話の単価の扱いが読めず、AI課金部分の月次予測が難しい
• 繁忙期にチケット帯が上振れると、結果的にシート課金より高くなる局面があり得る
• EC以外の業態では、注文データ連携を前提にした設計の利点が活かしにくい

最大の論点は、やはり金額が取れなかったことです。これは公式ページの描画形式の問題であり、製品の欠点ではありません。しかし検討者側からすれば、総額の概算を記事や資料から拾えないのは事実です。公式サイトの料金表の確認と、問い合わせによる見積りが必須になります。予算の承認を要する組織ほど、この手間を見込んでください。

二つ目は日本語の問題です。ECの顧客対応は、日本語の細やかな敬語や季節の挨拶まで求められる領域です。AIエージェントがこの水準の日本語を出せるか、管理画面の操作が日本語で完結するか。公開情報の範囲では確認できず、ここは完全に未検証です。日本語での問い合わせが主の店舗は、この点が契約可否を分ける論点になると考えます。

判断の分かれ目。日本語対応の未確認をどう扱うか

分かれ目は単純で、日本語対応が絶対条件かどうかです。顧客対応の言語が日本語一色の店舗であれば、契約前に日本語での動作確認を必須条件にすべきです。デモの依頼時に、自店の実問い合わせ文面をそのまま使って日本語での応答を確認する。反対に、対応言語が英語中心の越境ECであれば、このリスクは軽くなります。未確認の要素が判断の中心になる契約は、確認作業を先に済ませるのが唯一の対策です。

三つ目は、解決課金の裏面です。成果連動の課金は利用者に有利に見えますが、「解決」の判定が運用に依存する以上、閉じ方の運用が甘いと費用と成果の対応が崩れます。受信箱のルールを整えられる運用力がある店には向き、ルール化に手が回らない店では期待通りの効果が出にくい。これは道具ではなく運用の問題ですが、道具選びの段階で見通しておくべき点です。

試用期間の設計も書いておきます。解決課金の性質上、最初の月から全件をAIに預ける必要はありません。定型のうち解決の判定がはっきりした類型だけを預けて一か月、費用と成果の対応を記録してから範囲を広げる。この進め方なら、課金の単価が読めない状態でも、自店の数字で総額の見当が付けられるようになります。

以上を踏まえた条件付きの評価はこうなります。ECに特化した受信箱と、成果連動の課金設計は魅力的であり、比較の筆頭候補になり得ます。ただし金額の確認と日本語対応の確認という二つの宿題が片付くまで、契約の判断は保留が正解です。この留保を外さない範囲で、検討リストの上位に入れてよい製品だと考えます。

IntercomやZendeskとどう住み分けるか

顧客対応ツールの比較で常に並ぶのがIntercomとZendesk Service Suiteです。この二つは業態を問わず使える汎用の受信箱で、機能の幅と連携先の多さが武器です。一方のGorgiasは、ECの注文データを受信箱に引き込む前提の設計です。問い合わせのたびに注文番号を照会する手間を減らしたい店舗では、EC特化の設計が効きます。汎用と特化のどちらを選ぶかは、問い合わせの内容がECの取引にどれだけ紐づくかで決まります。

視野を広げると、営業側のデータ整備にはClay、商談の通話分析にはGong、社内の情報検索にはGlean、大規模な顧客基盤の統合にはSalesforce AIという隣接の選択肢が並びます。顧客対応の現場の道具を決める際は、この外側の道具群との役割分担を先に固めておくと、比較がぶれません。受信箱は顧客との接点の中心ですが、すべてを一つの道具で賄う必要はないと考えます。

移行期の並行運用についても一言添えます。既存の受信箱を止めずに併用する期間は、問い合わせが二箇所に流れる混乱が起きやすいものです。並行期間は問い合わせの入口を一つに保ち、内部での振り分けだけを変えるのが安全です。入口を分けてしまうと、データが割れて比較ができなくなり、移行判断そのものが曖昧になります。

補足として、AIの応答文面の下書きだけを先行して試したい段階では、ChatGPTのような汎用の生成AIで文面の型を作っておく方法もあります。汎用AIで型を作り、受信箱側で運用に乗せる。この二段構えは、本契約の前の検討期間でも役立ちます。

なお、役割分担の設計は契約後にも見直しが効きます。受信箱の運用が三か月も回れば、どの問い合わせが受信箱に来るべきかの実感が生まれます。道具の範囲と運用の範囲は、最初に決めて終わりではなく、運用の実感に合わせて線を引き直すものだと考えてください。

導入の順序

進め方としては、直近半年の月次チケット数と問い合わせの分類を固める。公式サイトの料金表で金額と帯の定義を確認し、日本語での動作確認をデモで済ませる。その上で、定型問い合わせのうちAIで解決できそうな範囲を小さく設定して始める。解決課金の性質上、最初から全件をAIに任せるのではなく、解決の判定がはっきりした問い合わせから預けるのが、費用と信頼の両面で安全だと考えます。

最後に一つだけ繰り返します。この記事の評価は公開情報にもとづく構造の読み解きであり、実機テストは行っていません。金額、解決の判定条件、日本語対応の三つは、契約前に必ず自らの手で確認してください。確認の順序を守れば、この課金設計はECの運用にとって十分に検討する価値のある選択肢だと考えます。

よくある質問

まとめ

主な参照元：Gorgias公式サイトの料金ページおよび機能説明（gorgias.com/pricing）。AI Agentの同梱と解決ベース課金、チケット帯、アドオンの構成は2026年10月24日時点の公開表示にもとづく。プラン金額はページ描画形式のため取得できず、実機検証は未実施。