Claude for Freshdesk:2026年に両者をつなぐすべての方法

要点まとめ

Freshdesk向けの公式Claudeアプリは存在しない。AnthropicはFreshworks Marketplaceにアプリを公開しておらず、同社自身のリモートMCPディレクトリにはZoho Desk、Pylon、Linear、HubSpotが載っているが、Freshdeskのエントリーはまったくない。

実際に存在するのは4つのルートで、そのうち公式なものはひとつだけだ。FreshworksはClaude DesktopとClaude Codeを対応クライアントとして挙げる独自のMCPサーバーを構築したが、それをEnterpriseプランとアーリーアクセス申請の壁の向こうに閉じ込めてしまった。残る3つは、自前のキーを使うサードパーティ製マーケットプレイスアプリ、66スターのコミュニティ製MCPサーバー、そしてFreshdesk APIの上に自分で構築する方法だ。この4つのどれも、Claudeを顧客の前に立たせることはない。どれも人間のエージェントの隣に座っているにすぎない。

Freddyの背後にClaudeを差し込むこともできない。Freshworksは、Freddyの生成側はAzure OpenAIモデル上で動くとしており、AI Agent Studioのどこにもモデル選択の項目はない。

コストの計算は人々を驚かせる部分だ。根拠に基づく1返信あたり約0.015ドルのSonnet 5のトークン代に対して、Freddy AI Agentセッション1回は0.49ドル、これはおよそ33倍の差であり、それでもまだ間違った比較だ。なぜなら、トークンが高くつく部分だったことは一度もないからだ。プラミング(配管部分)を自分で持たずに回答の質だけが欲しいなら、eeselは30分足らずでネイティブAIエージェントとしてFreshdeskに参加し、処理したチケット1件あたり0.40ドルを課金する。Anthropicはそのモデルプロバイダーの1つとして名前を連ねている。

これが失敗するところを見てきたので、そこから話そう

私はeeselでインテグレーションを構築しており、つまりまさにこの問題に多くの時間を費やしてきた。片側には優れたモデル、反対側には本物の顧客でいっぱいのヘルプデスク、そしてその間には驚くほど多くの「何もない」空間がある。

もしあなたの立場だったら知っておきたいと思う部分をここで話そう。初期の頃、私たち自身のエージェントは、ナレッジ検索が空で返ってきた場合の強制フォールバックなしにリリースされてしまった。だから何も言わない代わりに、言語モデルが空のコンテキストに対してやることをやった。つまり、学習データから何かをでっち上げたのだ。ある有料顧客のボットは太陽電池パネルのサブスクリプション条件をでっち上げ、実際の顧客に送りつけた。別のケースでは、サポートの質問に周期表からそのまま取った「酸素(Oxygen)」と答えてしまった。

これらはどれもモデルの失敗ではなかった。SonnetもOpusも、チケットを読んで返信を書くことに関しては優れている。失敗はモデルを取り巻く10個の地味な意思決定にあり、その10個の意思決定こそが仕事のすべてだ。

そしてこれは珍しい失敗の形ではない。これがそのものの形だ。ここに、Hacker Newsで私と同じ週を、別の製品で経験した見知らぬ人の投稿がある。

"LLM chatbots are a step forward for customer support. Well, ours started hallucinating a support phone number that while is a real number is not our number. Lots of people started calling which was a bad time for everyone. Especially the person's number it actually is. So maybe two steps forward and occasionally one back."

treis, Hacker News

これが、この先を読むときに持っておいてほしい枠組みだ。以下の各ルートは左側の箱を与えてくれる。違いは、右側の山のうちどれだけを渡してくれるかだ。詳細に入る前にもっと広いカテゴリー全体を見たいなら、AIヘルプデスクソフトウェアのまとめで、すでにその山を構築済みの企業を確認できる。

顧客の一人が、この「買うか作るか」の話を私よりうまく言い表してくれた。

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

まず、多くの人が誤解している点

「Claude for Freshdesk」という検索意図は通常、そういう設定が存在すると想定している。Freddyを開き、モデルを選び、Claudeを選択して終わり、というものだ。

そんなものは存在しない。Freshworks自身のFreddy AI信頼性FAQは、生成機能はエンタープライズグレードのAzure OpenAIモデルによって動いていると明記している。そして、Freddyエージェントに関するすべてを設定するAI Agent Studioは、ペルソナ、トーン、カスタム指示、エスカレーション動作、チャネル、セッション会計を提供する。しかし、モデルのドロップダウンやAPIキーの入力欄は提供していない。多くのプラットフォームがこの1年でひっそりと追加していたため、私は特に探してみたのだが、Freshdeskにはなかった。

これはFreddyへの批判ではない。1つのモデルを選び、それに徹底的にチューニングするのは十分に妥当な製品判断であり、Freddy AI Copilotはエージェントの作業スペースで役立っている。ただし、それによって問いの形が変わる。あなたが問うべきは「どうやってFreddyにClaudeを使わせるか」ではない。「どうやってClaudeに自分のFreshdeskデータを見せるか」であり、これは4つの異なる答えを持つ別の問題だ。

ルート1:Freshworksが自ら橋を架けた

これは本当に興味深いルートで、公開された形としてはまだ6週間ほどしか経っていない。

Freshworksは独自のMCPサーバーをリリースした。サポート記事FreshdeskにおけるMCP連携は2026年8月10日に最終更新されており、冒頭で対応クライアントとしてCursorやClaudeなどのAIツールを挙げている。さらに下を見ると、記載されているクライアントリストはClaude Code、Claude Desktop、Cursor、Microsoft Copilot Studio、Visual Studio Codeだ。

Claude Codeの場合、セットアップはコマンド1つで済む。

claude mcp add my-remote-server --transport http https://<your-freshdesk-domain>/mcp --header "Authorization: <api-key>"

Claude Desktopの場合は、設定ファイル内で同じエンドポイントを指すmcp-remoteのエントリーになる。以前にClaude CodeでMCPツールを設定したことがあれば、これには4分ほどしかかからないだろう。

次に制約事項だ。すべて同じ記事からのものだ。

アクションとは、成功したツール呼び出し1回と定義される。これは見た目以上に重要だ。なぜなら「この顧客は先四半期に何を不満に思っていたか」というような1つの有用な質問は、たいてい1回ではなく複数回のツール呼び出しになるからだ。FreshworksはFreshdesk OmniのページでもMCPを宣伝しており、これは横道の実験ではなく本物のロードマップ項目だ。

問題は、どの表面に対応しているかだ。このルートはあなたのFreshdeskデータをClaudeの中に、あなたのデスクトップに、あなたのために持ち込む。キューについて質問したり、難しい返信を下書きしたり、先月のエスカレーションからパターンを引き出したりするには最高の方法だ。しかし、顧客向けのエージェントではなく、そうあるべきだとドキュメントのどこにも示唆されていない。

私の見解: Enterpriseプランなら、今日にでもアクセスをリクエストしてほしい。これは現在利用可能な最もクリーンなClaude+Freshdeskの体験で、Freshworksがサポートしている。ただし、チケットの回避としてではなく、あくまでチームのためのツールとして予算組みしてほしい。

ルート2:あなたのAnthropicキーを使うマーケットプレイスアプリ

Freshworks MarketplaceにはFreshdesk向けのAIアプリが約10個ある。ほとんどはOpenAIベースで、独立系開発者によって公開されている。そのうち2つがClaudeに触れている。

PRAVAR PROによるSupport Assist AIは、今日インストールできるものの中で「FreshdeskでClaudeを使う」に最も近いものだ。自身の掲載ページでは、OpenAI、Anthropic Claude、Google Gemini、Azure OpenAIに接続するBring-your-own-key型のアシスタントと説明されており、プロバイダーとモデルを選び、クラウドプロバイダーの料金を直接支払う形になっている。セットアップにはFreshdeskのAPIキーに加えて自分のAnthropicキーが必要だ。21日間の試用後は有料と表示されており、バージョン4.0、インストール数8件だ。

autosolve.aiによるKnowledge Builderがもう一つだ。そのプライバシー開示にはAnthropic APIが直接名指しされている。チケットの件名、説明、関連するナレッジベースのコンテンツがClaudeモデルに送られ、チケット品質の評価、検索キーワードの生成、記事の下書き作成に使われる。

どちらかをインストールする前に知っておくべきことがある。マーケットプレイス自身の検索エンドポイントはClaudeで検索すると「App Not Found」を返すため、検索では見つからない。そしてどちらのアプリもサーバー側で数値の価格を表示しないため、実際のコストはインストールフローに入って初めて分かる。すでにテスト済みの選択肢を見たいなら、Freshdesk向けのAI自動化アプリのリストをまとめている。

私の見解: Support Assist AIのインストール数8件という数字こそ、私がじっくり考えたい数字だ。これは開発者への批判ではなく、そのツールがどれだけ本番環境での鍛錬を経てきたかを示す指標だ。社内実験なら問題ない。しかし、有料顧客がいるキューには、先に厳しい局面にぶつかった人がもっと多くいてほしい。

ルート3:コミュニティ製MCPサーバー

Enterpriseプランなしでmcpの体験が欲しいなら、オープンソースエコシステムはすでにそこに到達している。名前を挙げられるほど活発なサーバーが3つある。スター数と最終プッシュ日は2026年8月12日にGitHub APIから取得したものだ。

effytechのサーバーは、スター数、フォーク数、更新の新しさの点で事実上のデフォルトであり、その名の通りのことを行う。モデルがFreshdeskのモジュールと対話し、サポート業務を実行できるようにする。MITライセンスで、活発にメンテナンスされている。

セキュリティ上の姿勢については声を大にして言っておく価値がある。公式のアーリーアクセスサーバーとまったく同じだからだ。あなたはFreshdeskのAPIキーをローカルで動くプロセスに渡すことになる。FreshdeskのAPIキーは、それが属するエージェントの権限を持つため、管理者アカウントに紐づいたキーは管理者としてのことができてしまう。この道を選ぶなら、必要な情報を読み取れる範囲で最も限定的なロールと権限のセットを持つ専用エージェントを作成してほしい。

私の見解: これは今日の午後にひとりで評価するには正しいルートだ。しかし顧客が目にするものには誤ったルートであり、私ならソースコードを先に読まずにサードパーティのサーバーを共有マシンに置くことはしない。

ルート4:Freshdesk API上に自分で構築する

これは大半のエンジニアが選ぶ道であり、私が最も役に立ちたいと思う部分だ。なぜなら、APIの実際の形はマーケティングページが示唆するものとは違うからだ。この記事のためにFreshdesk API v2のドキュメントをしっかり読み込んだ。

認証は、APIキーをHTTP Basicのユーザー名として、任意のダミーパスワードとともにAuthorizationヘッダーにBase64エンコードする形だ。文書化されたOAuthフローはなく、カスタムCNAMEもサポートされていないため、*.freshdesk.comのホストに直接アクセスすることになる。シンプルなのは良い点だが、同時にローテーションしなければならないベアラー相当のシークレットでもあり、そこは良くない点だ。

レート制限は分単位、アカウント全体で適用される。古いドキュメントが時間単位の数値を公開していたため、ここでつまずく人が多い。

購入可能なアドオン階層は1,000と2,000に達する。「アカウント全体」ということは、あなたのAIが実行する他のすべてのインテグレーションとその予算を共有するという意味であり、Growthプランでおしゃべりなエージェントを動かせば、Shopifyの同期を飢えさせかねない。FreshdeskのAPIレート制限についての記事で、注意すべきヘッダーをさらに詳しく解説している。

そして、設計全体を形づくる3つの制約がある。

チケット履歴は思ったよりも手が届きにくい

チケット一覧のエンドポイントはデフォルトで過去30日分のみをカバーし、上限は300ページ、つまり30,000チケットだ。検索エンドポイントは512文字のクエリ、1ページ30件、10ページまでという上限があり、合計でおよそ300件だ。つまり「Claudeをうちのチケット履歴に向けるだけ」は週末のスクリプトではなく、ページネーションと差分同期を伴うデータエンジニアリングのプロジェクトになる。

もし根拠づけの計画が過去のチケットに依存していたなら、それに見合った予算を組むか、代わりにソリューション記事や定型応答から始めるべきだ。これらはずっと引き出しやすく、ほとんどのナレッジベースチャットボットがとにかく最初にインデックスする対象でもある。

ノートと返信は異なるエンドポイントで、一方は取り消せない

POST /api/v2/tickets/[id]/replyは公開返信を送信する。POST /api/v2/tickets/[ticket_id]/notesはノートを追加し、privateはデフォルトでtrueだ。後から編集できるのはノートのみで、conversationsエンドポイント経由で行う。一度送信した返信は編集できない。

最初のバージョンはプライベートノートしか書けないように構築し、公開返信の送信は後から意図的に解放する2番目のステップにすべきだと私は考える。これはまともなAIコパイロットならどれも同じ形であり、悪い回答が社内の恥で済むか、顧客の手元に届くメールになってしまうかの違いを生む。

Webhookは出て行くが、イベントは入って来ない

自動化ルールに対しては完全なCRUDが可能で、アクションのスキーマにはURL、リクエストタイプ、認証ヘッダー、カスタムヘッダーが含まれており、文書化されたドメインの許可リストはない。したがってアウトバウンドWebhookは、チケット作成時、チケット更新時、あるいは毎時、あなたのサービスにヒットしうる。存在しないのは受信側のイベントサブスクリプションAPIだ。トリガーはFreshdesk内で、自動化のルールエンジンを通じて設定するのであって、コードから宣言的に設定するものではない。

これらすべてに関する信頼性についての注記だ。公開されているAPIの変更履歴は2022年6月で止まっており、ドキュメントには今も2つの古びたレート制限表が残っている。何かを設計する前に、個々の数値をライブのX-RateLimit-Totalヘッダーと照らし合わせて確認してほしい。

私の見解: このAPIは良い。ドキュメントもしっかりしており、エンドポイントも理にかなっており、ノートと返信の分離はまさにあなたが欲しいセキュリティ境界そのものだ。これを土台に構築することは十分可能だ。問題は「できるかどうか」ではなく、「作ったものが18か月後にも自分が持ち続けたいものかどうか」だ。

1回の返信に実際にかかるコスト

ここから、数字が直感と一致しなくなってくる。

Claude Sonnet 5は入力100万トークンあたり2ドル、出力100万トークンあたり10ドルだ。根拠に基づくサポート返信は、チケットのスレッド、システムプロンプト、ヘルプセンター記事3〜4件をコンテキストに入れると、入力がおよそ6,000トークン、出力が約250トークンになる。これはおよそ0.015ドルだ。Claude Opus 5は5ドルと25ドルで、同じ返信をほぼ0.036ドルに押し上げる。プロンプトキャッシング(キャッシュされた入力を通常レートの10分の1で読む仕組み)は、両者をさらに押し下げる。

Freddy AI Agentのセッションは1回0.49ドルだ。Freshdeskがこれを100回49ドルのパックで販売しているためだ。

これらはリスト価格なので、実際に本番のキューでこの実験を行った人の話をしよう。あるコンサルタントがHacker Newsで、Opusをクライアントのサポートキューの背後に配置し、その後請求書を再設計した経緯を語っている。

"I was building a customer support AI for a client last year. We started with Claude Opus for everything because it worked great. The bill was $250/month for maybe 10K conversations. Then I looked at the actual queries. 70% were things like 'what are your hours?' and 'how do I return something?' [...] I started manually routing: simple patterns to a cheap model, everything else to Opus. The bill dropped to $40/month with no quality complaints from users."

robinbanner, Hacker News

彼はモデルルーティング製品を売り込むために投稿していたので、その文脈は割り引いて読むべきだが、数字自体は彼自身の構築によるものだ。250ドルで10,000件の会話は1件あたり2.5セントで、これは私のSonnetとOpusの見積もりのちょうど中間に落ち着き、私たちのどちらも得られない独立検証に最も近いものだ。彼が40ドルに到達するために何をしなければならなかったかにも注目してほしい。トリアージ層を構築することだ。この作業はどちらのリスト価格にも含まれていない。

およそ33倍。これは自作にとって圧勝のように見えるが、実際の自分の量と実際のエンジニアリング時間を当てはめるまでの話だ。だから、それをやってみよう。

計算機では値段をつけられない2つのことがあり、どちらも現実だ。

Freddyの無料500セッションはアカウントにつき一度きりであり、毎月のリフィルではない。セッションパックは支払いサイクルとともに失効する。つまり無料枠は試用であり、未使用のパックは繰り越せる残高ではない。1年分をモデル化する前にFreddy AI料金の詳細を読んでおく価値がある。

そしてClaude APIには無料枠もサインアップ時の試用クレジットもない。Anthropicの料金ページも開発者向けドキュメントも、そうしたものを公開していない。新しい組織は制限を絞った評価ティアからスタートする。それ自体は問題ないが、人々が想定するような「無料でとりあえず立ち上げる」出発点ではない。

お金は実際どこに消えるのか

チケットを読み、ヘルプセンターから検索し、プライベートノートとして返信を下書きし、何をしたかを記録する最初のバージョンとして、私の正直な見積もりはエンジニア15日分だ。私はだいたいこの種のものを一度ならず構築してきた。これは難しい部分ではない。

難しい部分は3週目以降のすべてであり、それこそがデモを見せた瞬間に買い手が尋ねてくることそのものだ。私が同席したある技術評価担当者は真っ先にそこを突いてきた。答えが分からないとき何らかの汎用モデルにフォールバックするのか、それをオフにできるのか、と。その同僚はすぐに、ナレッジが自分たちの組織内に閉じたままかどうかを尋ねた。どちらもどのモデルかは聞かなかった。彼らが尋ねたのは検索が失敗したときに何が起きるかであり、それこそが正しい問いであり、私の太陽電池パネルのエピソードがその答えとなっている問いだ。

自作スタックがなぜ失敗するのかについて私が読んだ中で最も鋭い診断は、Hacker Newsの投稿者によるもので、これもモデルの話ではない。

"The first job of any support system—both in terms of importance and chronologically—is triage. This is not a research issue and it's not an interaction issue. It's at root a classification problem and should be trained and implemented as such. [...] What most AI systems (whether LLMs or scripts) do wrong is that they treat WTFs like they're grandmas."

torstenvl, Hacker News

これは上記のコンサルタントがコスト面から到達したのと同じ結論に、品質面から到達したものだ。トリアージは訓練し測定するものであって、プロンプトに追加する指示ではない。だからこそトリアージツールはそれ自体が独立したカテゴリーになっている。

次に信頼性の問題がある。月間7,000件のチケットを扱うCXリーダーが、私が書いたどの仕様書よりもうまく言い表していた。

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer, then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

信頼度ルーティングはプロンプトではない。それは検索スコアリングであり、実際の結果に対して調整する閾値であり、チケットが手つかずに見えるようにする静かな棄権パスだ。これは6週目の話であって、2週目の話ではない。参考までに、私たちはまさにこのギャップが原因である案件を失注しており、これがどれほどの作業量かを私が言っていることを信じてもらえる、それなりに妥当な理由になるだろう。

自作ルートについてのコミュニティの声は、どこで破綻するかについて一貫しており、そしてそれは決してモデルではない。

"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."

Reddit user, r/AiAutomations

誤分類はそれ自体が独立した専門分野であり、だからこそチケットトリアージツールは、誰かが一度書いたプロンプトとしてではなく、1つのカテゴリーとして存在している。

正直な反論も紹介しておこう。私たちから離れていった顧客からのものだ。

"We switched to a system that is working well at half the cost. But long term we will just build our own, which is so possible now with AI. I think you have a decent system for now, but we are probably too large of a customer for this. That being said, we probably would have stayed if support was faster and better."

今それが可能だという点で彼らは間違っていない。これを構築することは、これまでのどの時よりも可能になっている。上の計算機が本当に問うているのは、それがあなたの次の15日分のエンジニアリング時間の最善の使い方かどうかであり、一部のチームにとっては、答えは本当にイエスだ。

私なら実際にどう判断するか

その最後の行こそ、これを始めたときに予想していなかった発見だ。Claudeから Freshdeskの顧客へと至る、誰かが所有しなければならないコードを通らないルートは存在しない。公式のオプションはデスクトップツールだ。マーケットプレイスのオプションは下書きアシスタントだ。コミュニティのオプションは、あなたのAPIキーを保持するローカルプロセスだ。そしてAPIのオプションとは、あなた自身が、最初の図にある6つの箱を構築することだ。

もしあなたが本当に望んでいたのがティア1のチケットが自然に解決されることだったなら、モデルが欠けているピースであったことは一度もなかった。それこそがAIエージェントというカテゴリーが埋めるために存在するギャップであり、どちらの問題を抱えているのかを判断する前に、ルールベースのチャットボットと比較してみる価値がある。

Freshdesk向けeesel AI

というわけで、ここまでのすべてを踏まえた正直な提案だ。

eeselはFreshworks Marketplaceからインストールでき、本物のAIエージェントとしてFreshdeskに参加する。ウィジェットもなく、第二の受信箱もない。過去のFreshdeskチケット、ソリューション記事、定型応答を自動的に読み込み、その後は人間のエージェントがすることを行う。返信を下書きして送信し、プライベートノートを追加し、チケットをグループへルーティングし、優先度、ステータス、タグを更新し、既存のディスパッチルール、SLAポリシー、営業時間を尊重する。セットアップは30分足らずで、ページ自体の数字によれば1週間以内にティア1解決率85%以上を平均で達成している。

この記事のテーマを踏まえると、特に重要なことが2つある。

まず、モデルの問題について。eeselはどれか1つを選ばせることはしない。AnthropicはOpenAI、Googleと並んでその名指しされたモデルプロバイダーの1つであり、Enterpriseプランなら自前のモデルを持ち込むこともできる。だから、あなたの直感が「自分のチケットにClaude級の推論が欲しい」というものだったなら、インテグレーションを自分で所有することなくその結果を手に入れられる。

次に、私が冒頭で語った失敗について。すべてのエージェントは本番稼働前に、あなた自身の過去のFreshdeskチケットの履歴に対して実行される。そうすることで、先週23件のチケットが日割り返金について尋ねていたのに、ドキュメントには全額キャンセルしかカバーされていない、といったことが分かる。そして人間が返信を承認するドラフトモードから始め、信頼できるようになったら簡単なチケットから自律モードに切り替える。まずコパイロット、それから完全自動、というのが、私たちが話すほぼすべてのチームが実際に望むパターンだ。

料金は処理したFreshdeskチケット1件あたり0.40ドルで、1チケットとはすべての返信とフォローアップを含む1タスクを指す。プラットフォーム料金なし、席数課金なし、最低利用料金なしで、50ドル分の無料利用枠から始められる。月間1,000件のチケットのうち200件をルーティングすれば、支払うのは200件分だけだ。率直に言えば、結果にかかわらず処理したチケットごとに課金される。なぜなら計算はいずれにせよ実行されるからだ。そして、悪い1週間が悪い請求書にならないよう、デフォルトで月間250ドルの上限があり、それに達するとエージェントが一時停止する。

Freddyの1セッション0.49ドル、あるいはエンジニア15日分プラス無期限の保守と比べれば、これは買い手にしてほしい比較だ。まずネイティブの選択肢を見たいなら、Freddy AIレビューではFreshdesk自身のAIが優れている点についても公平に扱っており、eesel対Freddyでは両者を並べて比較している。

自分のFreshdeskチケットでeeselを無料で試してみるか、より広い選択肢を知りたいならFreshdeskにおすすめのAIを読んでほしい。無料の代替案も含まれている。

計算を左右する最後の実務上の注意点がある。Email AI Agentを含むFreddy AI Agentは、Growthプラン19ドル(1エージェントあたり月額)から利用できるため、ネイティブの道を試すのにProプランは必要ない。Freshdesk CopilotはProプラン以上に限定されているもので、年払いで1エージェントあたり月額29ドルだ。

プランごとの完全な数字はFreshdeskの料金の解説にまとめている。まだSKU間で迷っているなら、Freshdesk対Omniがその違いをカバーしており、これらすべてを試す前にFreddyを試したいならFreshdeskのAIセットアップがネイティブの各種スイッチを案内してくれる。