ZendeskとFreshdeskでAIを使う:課題と解決策

そもそもなぜチームはZendeskとFreshdeskでAIを求めるのか

両ベンダーとも同じ売り文句を掲げています:より多くの解決件数、より少ない人員、より速いCSAT。Zendeskは80%超の自動化率、Copilotによる82%の生産性向上、週5.5時間の管理業務削減を謳っています。FreshdeskのFreddy AIページは、最大80%の問い合わせを自律的に解決し、2分未満での会話型解決、チケット解決時間を75%削減すると主張しています。条件さえ整えば、これらの数字はそれなりに現実的です—そして、その「条件」こそが、どのチームもつまずくポイントなのです。

見出しの数字を超えて見ると、両スタックは今や同じ大枠のAI構成を提供しています:顧客対応の自律型エージェント、人間の担当者向けのエージェントサイドコパイロット、そしてルーティングのためのインテリジェントトリアージです。ZendeskのAI Agents(旧称Answer Bot、買収後はUltimate.ai)とFreshdeskのFreddy AI Agentは直接の対応物です。Zendesk CopilotとFreddy AI Copilotはエージェントサイドの対応物です。両社とも、ヘルプセンターの記事、過去のチケット、連携ドキュメントから情報を引き出す統合ナレッジレイヤーに依存しています。

この売り文句は、最良の条件下でツールが「できること」の説明としては嘘ではありません。抜け落ちているのは「デモ」と「本番運用」の間にあるすべてです。この先の内容は、そこにフォーカスしています。

課題1:隠れたコストの積み重ね

どちらのベンダーも、まず親しみやすい座席料金を提示し、その上に本当のAI料金を重ねてきます。

Zendeskのコストが積み重なる仕組み

Suiteの料金は年間契約で1エージェントあたり月額19ドルから115ドルまで、Support TeamからSuite Enterpriseへと段階的に上がっていきます。Copilotは Enterpriseにバンドルされており、それ未満のプランでは1エージェントあたり月額50ドルのアドオンとして販売されています。AIの課金単位は「自動解決(automated resolution)」で、コミット量を超えた分は複数のサードパーティによる分析とARモデルに関する定番のRedditスレッドによれば、1件あたりおよそ1.20〜1.50ドルで課金されます。緩やかな支出上限は存在しません。唯一の非常ブレーキは、AIを完全に停止することだけです。

実際の運用量でAIをオンにすると、この積み重ねは基本料金の2〜3倍に達する傾向があり、だからこそチームはRedditで計算をし始めるのです:

"From what I can see in regards to this new 'Automated Resolution' pricing model, we'll be paying about $1.50-$1.20 per resolution."

r/ZendeskのARプライシングに関するスレッド、元の投稿

そして、その計算が割に合わないとき:

"No, it's just terrible and a rip off. You can't even export the data on like what people ask the bot so you can sort it or manipulate it how you want. We stopped using it because ARs are a rip off, and it's a rushed product to get into the AI hype."

u/OGShakey、r/Zendeskスレッド「Zendesk & AI Agents - After thought?」

2026年5月の3段階の解決モデルは、これを少し緩和しました:現在では Verified Resolutions のみが割り当て枠を消費し、Assisted EscalationとContained Resolutionは無料に戻っています。改善ではありますが、解決件数ごとに賭けるレイヤーは依然として存在し、上限は今も二択のままです。

Freshdeskのコストが積み重なる仕組み

Freshdeskの料金プランは年間契約で1エージェントあたり月額19ドルから89ドル(Growth、Pro、Enterprise)です。Freddy AI Copilotは座席単位のアドオンで1エージェントあたり月額およそ35ドル、顧客対応ボットであるFreddy AI Agentは無料セッションを500件提供し、それ以降は追加セッションごとにおよそ0.10〜0.12ドルを課金します—約1,000セッションのパックが100ドルで販売されており、セッションは請求サイクルごとに失効します。1セッションとは、72時間以内の顧客とのやり取り1本を指します。このセッションモデルにも、同じ罠の独自バージョンがあります:

"I do like the UI of Freshservice seems easy to use. The freddy AI is an add on so expensive for what it can do and only available at enterprise."

r/sysadmin、"IT ticketing system with strong KB for small team"

私たち自身の営業電話でも、同じ摩擦を耳にしてきました。年間およそ2万件のチケットに達しつつあったFreshdesk利用のメールセキュリティ企業は、テスト1日だけで200回のAPI呼び出しを消費し、すぐにやり取り単位の料金計算に走りました—その商談は二度と持ち直しませんでした。月間7,000〜8,000件のエスカレーションチケットを扱うZendesk利用のフィンテック企業は、1日500件のチケットから換算した1日あたり約2,000件のやり取りという計算結果を見て、やり取り単位の課金を即座に却下しました。やり取り単位の料金体系は、最も多くの量を処理する顧客—つまり本来自動化から最も恩恵を受けるはずの顧客—を体系的に罰しているのです。

このコスト構造全体をより深く読み解くと:両スタックのAI課金は、成功すればアップサイドを取り込む(チケット処理が増える=ベンダーの収益が増える)一方で、成功しなかった場合の下振れ保護は一切用意されていません(閑散月でも座席料金はそのまま発生します)。これはベンダーにとって都合の良い契約の形です。買い手にとってはそうではなく、だからこそ「デモの後に料金が高すぎた」という理由が、失注メモの中でこれほど頻繁に見られるのです。

Zendeskの詳しい計算については、Zendesk AI料金ガイドで解説しています。Freshdeskについては、Freshdesk AI料金の内訳で同様に解説しています。

課題2:ナレッジベースの整備状況こそが本当の天井

どちらのヘルプデスクでもAIがどれだけうまく機能するかを最も確実に予測するのは、LLMでもオーケストレーションでもチャネルでもなく、ナレッジベースがどれだけ整理されているかです。整備され、タグ付けされたヘルプセンターを持たないチームは、最初の1か月はおよそ20%の自動化率で頭打ちになり、継続的なKBの整理を経て初めて70%に近づきます。私たち自身の顧客側で見てきた数字もこの範囲に近く、Redditの総意もこれについては率直です:

"The Co-Pilot stuff is decent, but we found its effectiveness really depends on having a perfectly curated Zendesk knowledge base, which... ours isn't, lol."

u/ToastBix、r/Zendesk thread on AI Agents

両プラットフォームのAIエージェントは、接続されたナレッジソースから、そしてそのソースからのみ読み込みます。オープンなウェブを閲覧したり、外部リンクをたどったり、Notionに保管している奥まったFAQを参照したりすることはできません。そのため、古くなった記事や矛盾する回答、抜け落ちたトピックを含むナレッジベースは、AIを単に制限するだけでなく、積極的に誤らせることになります。さらに厄介なのは、その誤りが顧客が失敗パターンに遭遇するまで見えず、1週間後に監査ログで悪い返信を発見することになる点です。

どちらのベンダーも「AIをオンにする前にナレッジベースを整備してください」と言うでしょう。そのアドバイスは正しくもあり、役に立たなくもあります。どの記事が不足しているかを事前に知る術はなく、AIが回答を始めてどこでつまずくかを見て初めて分かるのです。実際に20%のデフレクション率を超えるチームは、KBを「生きた成果物」として扱っています:低確信度のAI回答を毎週レビューし、書くべき記事のバックログを常に稼働させ、その穴を埋めることを仕事の一部とする担当者を置いているのです。

これは本物の運用規律であり、ほとんどの「ZendeskやFreshdeskにおけるAI」コンテンツで欠けている章です。

課題3:設定作業はデモが示唆するよりもはるかに時間がかかる

デモは20分で終わります。しかし本番導入はどちらのプラットフォームでも3か月未満で済むことはめったになく、ボトルネックとなるのはAIそのものではなく、周辺の設定作業です。

Zendeskの場合、Copilot、Intelligent Triage、Advanced AI Agentsのダイアログビルダーはそれぞれ独自の管理画面と独自の設定を持っています。ダイアログビルダーに対するRedditの総意は手厳しいものです:

"The most annoying interface in the world."

r/Zendesk、Ultimate.ai由来のフロービルダーに関するコメントスレッド

管理者側の設定に関するG2でのレビューも似たような調子です:「負担が大きい」「専門知識が必要」「バックエンドがフルタイムの仕事のように感じられる」—複数のレビューで繰り返し使われている表現です。チームがエージェント側のUXを評価している場合でも、管理者側の設定こそが勢いを失わせる瞬間なのです。

Freshdeskのセットアップは最初は軽く感じられますが、同じように積み重なっていきます。Freddy AI Agentのノーコードスタジオは、最初のエージェント型ワークフローには十分です。しかし、実際の顧客シナリオごとに1つずつ、それを50個構築するとなると、AIの設定というよりソフトウェアのオンボーディングに近くなります。そして、プランごとの機能制限のせいで、必要な機能がEnterpriseにしかないと構築の途中で気づくことになります—これは「デモがこの部分を省略していた」ことの価格差別バージョンです。

より深い問題は、「ヘルプデスクにAIを導入する」ことが3つの別々の作業を必要とする点です:

• AIが何を処理すべきかを決める(どのチケット種別、どのチャネル、どの言語か)。
• ナレッジを接続する(ヘルプセンター、過去のチケット、外部ドキュメント、製品データ)。
• エスカレーション、トーン、エッジケースを設定する(いつ引き継ぐか、どう表現するか、何を絶対に言わないか)。

ネイティブのAI製品では、この3つ目の作業がセットアップ時間の大半を占める傾向があります。その多くがルールエンジンのUIに依存しているためです。「このエージェントにこうしてほしい」という自然言語での設定こそが習熟曲線を短くするものであり、ツールを比較する際に過小評価されがちな機能です。

課題4:自信満々だが間違った回答

ヘルプデスクにおけるAIの最も破壊的な失敗パターンは、返信の遅さでも劣悪なUXでもなく、人間がチェックする機会を得る前に送信されてしまう「自信満々だが実は間違っている回答」です。このパターンはあまりに一般的で、Reddit上のほぼすべての「AIを試してみた」スレッドで、話の要となる一文として登場します:

"Auto-replies sounded great in theory, but once real tickets came in, it started giving confident but wrong answers. CSAT dipped quick. What worked better for us was using it as an agent assist, draft replies, summaries, tagging, not full auto mode."

Responsible_Rub_4491、r/AiAutomations thread on integrating AI into helpdesks

同じスレッドには、Freshdeskで運用している人からの、さらに辛辣なバージョンの声もあります:

"We tested an ai integration in freshdesk and had almost the exact same experience. it worked for very simple tickets but anything slightly complex got misclassified. agents ended up spending more time fixing errors than before, so we had to rethink our approach."

Timely_Aside_2383、r/AiAutomations comment

そして、同じスレッドの投稿者本人が、Zendeskで運用した際のコメントです:

"The ai kept misclassifying things like warranty claims as general inquiries... customers complained the responses felt too robotic and sometimes gave wrong info on returns. we rolled it back partially and now our agents are using it as an assist."

Fun-Training9232、r/AiAutomations OP

パターンは一貫しています:両プラットフォームのAIは、パスワードリセット、注文状況の確認、FAQのデフレクション、単純なマクロ風の返信をうまく処理します。しかし、解釈を必要とするものになると破綻します—購入日や製品カテゴリーに左右される保証請求、実は3つの問題が絡み合った返金依頼、ヘルプセンターの記事よりも顧客のアカウント履歴の方が重要になるポリシーに関する質問などです。

この失敗パターンのより微妙なバージョンは、プラットフォームレベルでも現れます。私たち自身の顧客トランスクリプトの一つから:

"We have kicked the tires in zendesk AI solutions and found it largely inadequate and overpriced. So we're looking for other options that we might have to bring some automation to to that whole process that I just described."

米国のヘルスケア/理学療法プラットフォームのCX責任者、営業電話のトランスクリプトから匿名化

「不十分」と「割高」はここで異なる意味を持っています。不十分さは保証請求の失敗パターンを指します。割高さは、AIが実際に処理するチケットに対して解決件数ごとに料金を払いながら、処理できなかったチケットを修正する人間にも料金を払い続けることになる、という状況を指します。

課題5:無料プランはAIらしさがない

どちらのプラットフォームも、アドオンなしでバンドルされたAIプランを提供しています。しかし、どちらも買い手が「ヘルプデスクのAI」と聞いて思い描くものとは違います。

Zendesk AI Agents Essential(2026年12月31日に終了予定のレガシーなバンドルプラン)は、実質的には旧Answer Botに生成AIの化粧を施しただけのものです。ダイアログもなく、認可されたアクションもなく、API呼び出しもありません。r/Zendeskでの評価は:

"Doesn't feel like AI at all."

r/Zendesk thread on AI for chat and email

Freshdeskにおける相当品は、ProとEnterpriseで提供される500件の無料Freddy AI Agentセッションです。多くのチームが1回の請求サイクル内でこの上限に達し—月間数千件のチケットを超えるチームならなおさらです—その後、セッション単位のアドオンかEnterpriseへのゲートに直面することになります。

ここにある構造的なパターンはどちらのプラットフォームでも同じです:バンドルプランはお試しであり、使い続けたくなる程度には有用でありながら、本格的な自動化を求めた瞬間に有料アドオンへと誘導されるだけの制約が課されています。それは悪意によるものではありませんが、指摘しておく価値はあります。無料プランをどちらかのプラットフォームのAI提供内容として扱う比較記事は、買い手を不意打ちに遭わせることになるからです。

課題6:多言語・複数ブランドでの導入

複数の言語、あるいは複数のブランドにまたがってサポートを運営している場合、両プラットフォームのネイティブAIレイヤーは、マーケティングページが前面に出さない特有の摩擦を生みます。

Zendeskでは、AI Agents Advancedが80以上の言語をネイティブレベルの流暢さでサポートしていますが、ダイアログビルダー、接続されたナレッジベース、トーン/フォーマリティの設定はすべてエージェントごとに構成されます。複数ブランドを運営するチームは、結局同じエージェントをブランドの数だけN回作り直すことになり、それらを同期させ続けることがメンテナンス業務になります。

FreshdeskのFreddy AIは、言語ごとのエージェントではなくリアルタイム翻訳によって多言語対応を行います。これは軽量な仕組みですが、AI回答の品質という変数の上に翻訳品質という変数が加わることになります。規制の厳しい業界、金融サービス、ヘルスケアなど、リスクの高い業種では、翻訳されたAIの返信は2層のリスクが積み重なっていることになります。

私たち自身の顧客からの実例を挙げます。ドイツのローン比較プラットフォームであるSmavaは、月間10万件以上のサポートチケットをドイツ語で処理する完全自動化されたZendeskエージェントを運用しています。彼らはネイティブのZendesk AIでそこに到達したのではありません—ドイツ語のティア1チケットを専門に処理するよう構築された1つのAIエージェントを、過去のドイツ語チケットに対するシミュレーションと、ドイツ語での継続的なナレッジギャップ検出とともに使うことで到達したのです。教訓は「Zendesk AIはドイツ語ができない」ということではありません。英語圏以外の業種でそのレベルの自動化を達成するには、デモが示唆するよりもずっと多くの検討が必要だ、ということです。

複数ブランドを運営するチームにとって正しい形は、1つの言語ごとに1つのAIをマスター設定に紐づけるのではなく、独自のナレッジ、トーン、エスカレーションルールを持つブランドごとに1つのAIを用意することです。両プラットフォームのネイティブAI製品は、それを本来あるべき姿より難しくしています。

---

以上が課題です。この先は、チームが実際にそれらにどう対処しているかについてです。

解決策1:本番稼働の前に過去のチケットでシミュレーションする

ヘルプデスクでAIの導入に成功するチームと、ロールバックすることになるチームを分ける、最大のワークフロー上の違いは1つです:本番のチケットに向ける前に、過去のチケットに対してAIを実行することです。これをバックテストのように扱いましょう。過去30日分のチケットを選び、まるで本番であるかのようにAIに処理させ、どこでうまく回答できたか、どこでエスカレーションしたか、どこで自信満々に間違った回答をしたかを測定します。

このたった1つのステップで、4つの問題を一度に解決できます:顧客より先にKBの穴を見つけられる、実際のデータに基づいてエスカレーションの閾値を調整できる、実際の支出が発生する前にチケットあたりコストとデフレクション率の信頼できる予測を立てられる、そしてベンダーのスライド資料の数字ではなく、自分のデータから得たAI自身の的中率を手に入れられる、という4つです。

ZendeskのフロービルダーとFreshdeskのFreddy AI Studioはどちらもサンドボックスモードを備えていますが、どちらにも「過去30日分のチケットに対してリプレイする」というワークフローが第一級の機能としては存在しません。それが欠けているピースであり、サードパーティ製のAIレイヤーが優位に立ちやすい部分です—シミュレーションを設定ページに埋もれた機能ではなく、デプロイのステップとして扱うということです。

解決策2:ナレッジの穴を継続的に監査し埋める

KBの整備は、リリース前に一度だけ行うタスクではありません。継続的な運用規律であり、明確な担当者を置くべきものです。

実際に機能する仕組み:

• 毎週、AIの低確信度の回答を抽出する(ZendeskとFreshdeskはどちらも監査ログで確信度スコアや「エスカレーション理由」を表示します)。
• 個々のチケットだけでなく、その裏にある不足記事を見つけるために、それらの回答をトピックごとにクラスタリングする。
• 記事を作成してナレッジベースに追加し、同じクラスターのチケットに対して再テストする。
• AIデフレクション率とは別の指標としてKBカバレッジを追跡する。この2つは相関していますが、別々に扱うことでボトルネックが明確になります。

このループを自動化するチームはさらに先へ進みます—AI自身が直近のチケット量からテーマを抽出し、必要だったであろう新しい記事を提案するのです。ここからAIは複利的に効果を発揮し始めます:チケットに答えるだけでなく、自らが参照するナレッジベース自体を改善していくのです。運用面についての詳細は、AIを活用したチケット管理ガイドとAIチケットデフレクションガイドでワークフローの形を詳しく解説しています。

ここでのより深い変化は文化的なものです:整備されたKBはドキュメンテーションプロジェクトではなく、AIトレーニングプロジェクトなのです。実際の予算、実際の担当者、実際のレビュー頻度を伴ってそのように扱うことこそが、デフレクション率20%のチームと70%のチームを分けるものです。

解決策3:量に罰を与えない課金モデルを選ぶ

両プラットフォームの価格の罠は同じです。AIで成功し、より多くのチケットが処理されるほど、請求額は線形に(Zendesk)、あるいは100ドル単位の階段状に(Freshdesk)増えていきます。ある量までは、どちらのモデルも問題なく見えます。その量を超えると、AI税が座席ライセンスの上に積み重なり、静かにビジネスケースを蝕んでいきます。

うまく機能する形はこうです:プラットフォーム料金も座席課金もない、チケット単位の定額料金—「やり取り」「セッション」「解決件数」といった別々の課金単位ではなく、すべてのやり取りをカバーする1つの価格です。eeselの料金モデルはこれを軸に構築されています:処理したチケット1件あたり0.40ドルで、1件のチケットにはすべての返信とフォローアップが含まれ、月額最低料金も別途のAIアドオン税もありません。月間1,000チケットの場合の計算は400ドル、それで終わりです。月間10万チケットの場合の計算は40,000ドルで、AR超過分もセッション失効によるリセットもありません。

これが聞こえる以上に重要な理由:やり取り単位や解決件数単位の料金は、AI自体に歪んだインセンティブを生み出します。ベンダーの収益は、AIがより多くのやり取りを処理するほど最大化されます—本来処理すべきでなかったもの、顧客にとってはエスカレーションした方が安く済んだはずのものも含めてです。チケット単位の定額料金は、AIベンダーと買い手の利害を一致させます:チケットをうまく処理するか、試みるべきでないものをエスカレーションするか、どちらでも価格は同じです。これは単に安いだけでなく、誠実なのです。

横並びの比較については、Freshdesk AI代替ツールとZendesk AI代替ツールのまとめ記事で、業界全体の課金の形を詳しく解説しています。

解決策4:コパイロットモードで始め、自律型へと移行する

ほぼ普遍的に機能するパターン:AIを自動応答者としてではなく、ドラフト作成者として始めることです。AIに返信を書かせ、人間のエージェントが承認または編集してから送信します。数百件のチケットにわたって承認率を観察します。承認率が95%を超えるチケット種別を特定します(通常はパスワードリセット、注文状況確認、FAQデフレクションです)。それらだけを自律型に切り替えます。それ以外はすべてコパイロットモードのままにしておきます。

これにより、簡単なチケットではコスト面のメリットを得られ、難しいチケットでは品質のセーフティネットが働き、人間がドラフトを承認・却下することでAIを日々継続的にトレーニングするフィードバックループが生まれます。また、誰もチェックできないまま「自信満々だが間違った」自動返信が顧客に届いてしまう、という最悪の失敗パターンも回避できます。このアプローチに対するRedditの総意は、単なる意見ではなくパターンとして読めるほど一貫しています:

"Some tools created more work because they escalated too aggressively or hallucinated product-specific answers."

Heavy_Plan7527、r/AgentsOfAI on AI customer support agents

逆の失敗パターン—自動解決に前のめりすぎて、エッジケースについて何も言わない—は、CSATを最も速く悪化させるものです。

この4ステップの道筋は、AIベンダーのオンボーディング資料にはめったに書かれていません。なぜなら、ステップ1と2はベンダーにとってのAR課金を生まないからです。それらが生み出すのは、買い手にとっての確信です。この非対称性は注目に値します。

解決策5:両方のヘルプデスクの上で動くAIレイヤーを使う

最後の、そしておそらく最も重要な転換はこうです:「ZendeskにおけるAI」や「FreshdeskにおけるAI」を問いとして考えるのをやめることです。代わりに「自分のヘルプデスクの上に乗るAI」として考えましょう。その理由は構造的なものです。

ネイティブAIは、あなたをそのプラットフォームにロックインするように作られています。ヘルプデスクを乗り換えれば、AIのトレーニングを失います。解決件数ごとに料金を払えば、あなたの収益が伸びるのと同時にベンダーの収益も伸びます。Zendeskのフロービルダー内でエージェントを設定すれば、その設定への投資は他のどのプラットフォームにも持ち出せません。それが、ネイティブAIをオンにするときにあなたが結ぶ契約なのです。

両方のヘルプデスクの上に乗るAIレイヤーは、それぞれを逆転させます:

• 1つのナレッジベースをZendeskとFreshdesk(さらにSlack、Notion、Confluence、Google Docs、過去のチケット)にまたがって使う、プラットフォームごとに1つではなく。
• ブランドごとに1つのAIエージェント、プラットフォームごとではなく。これにより、複数ブランド・複数ヘルプデスクのチームも一度設定すれば済みます。
• 1つの課金関係、並行して動く2つのARメーターではなく。
• 持ち運び可能な学習データ—将来ZendeskからFreshdeskへ(あるいはその逆へ)移行しても、AIが蓄積した学習内容はそのまま持ち運べます。

これは、最良のFreshdesk AI代替ツールや最良のZendesk AI代替ツールを選ぶ判断の、より戦略的なバージョンです:「このプラットフォーム上でどのサードパーティ製AIが最良か」ではなく、「そもそもAIはプラットフォームに縛られるべきなのか」という問いです。

ZendeskとFreshdeskでeeselを試す

eesel AIは、この結論に苦労してたどり着いた買い手—たいていは予想外のAR請求や四半期途中のFreddyセッション上限超過を経験した人たち—のために私たちが構築したAIレイヤーです。ZendeskとFreshdeskに30分以内で接続でき(プロフェッショナルサービスは不要)、過去のチケット、ヘルプセンターの記事、マクロから自動的に学習し、ブランドに沿った返信のドラフトを作成し始めます。それらは手動で承認する(コパイロットモード)か、すでに95%を超える承認率を得ているチケット種別であれば自律的に送信することができます。

知っておくべき差別化ポイント:

• 過去のチケットに対するシミュレーションが第一級のワークフロー—実際の顧客が目にする前に、過去30日分に対してAIを実行できます。
• ナレッジギャップ検出—eeselはKBがカバーしていないトピックを表面化させ、新しい記事のドラフトを作成します。
• 1チケットあたり0.40ドルの定額—プラットフォーム料金も座席ライセンスも、別途の「解決件数」や「セッション」のメーターもありません。何回の返信を要しても、1チケット=1タスクです。
• 1つのAIエージェントで、複数のブランドとヘルプデスク—同じエージェントを複数のZendeskブランド、複数のFreshdeskインスタンス、あるいはその両方で運用できます。

実際に大規模で運用している顧客には、Zendesk上で月間10万件以上のドイツ語チケットを自律的に処理しているSmava、Zendesk・Slack・自社ウェブサイトにまたがって月間1万件以上のチケットを処理しているEcosa、ヘルプデスクと社内Q&Aにまたがって717件のナレッジ項目を運用しているCartonCloudなどがあります。

トライアルではフル機能を対象に50ドル分の利用クレジットが提供され、クレジットカードは不要です。ブランドやチケット種別を1つ選び、まずは過去のチケットに対してシミュレーションを行い、数字が納得できるものになってから本番に切り替えましょう。eeselを試す:無料で始める、または30分のデモを予約する。