Claude と Help Scout の連携：公式MCPサーバーとその一つの大きな制約

Help ScoutはZendeskがまだやっていないことを静かにやってのけた

私はeeselで連携機能を構築しており、他社のAPIドキュメントを読むことに不釣り合いなほどの時間を費やしている。そして「〇〇ヘルプデスク向けのClaude」という質問が、今年ずっと私の受信箱に届き続けている。たいていの場合、答えはがっかりするものだ。8月にClaude for Zendeskを調べたとき、claude.com/connectors/zendeskは404で、ZendeskはサーバーではなくMCPクライアントをリリースしていた。Freshdeskのルートは今も早期アクセスプログラムの向こう側にあり、Gorgiasにはそもそもマーケットプレイスの掲載自体が存在しない。

Help Scoutはただそれをリリースした。2026年8月6日に最終更新された同社のヘルプセンター記事は、Help Scout自身の本番ドメイン上にある本物のHelp Scoutエンドポイントに Claude を接続する手順を案内している。ラッパーもなく、マーケットプレイスの仲介者もなく、ベータ待機リストもない。

これは良いことであり、この後この制約について語り続ける前に、そのことは言っておきたい。12,000社が利用するサポートプラットフォームが、顧客がすでに使っているどんなAIにもデータを開放するという選択は、明白な商業上の一手ではない。多くのベンダーは自社製品を使わせたいはずで、Help Scoutにも自社製AIが山ほどあり、それを売りたいはずだ。

さらに読み進める前に知っておくべき、やや気まずい細部もある。MCPサーバーはdocs.helpscout.comのヘルプセンターには文書化されているが、developer.helpscout.comの開発者ポータルにはどこにも載っていない。site:developer.helpscout.com MCPで検索しても、Docs APIの概要しか出てこない。仕様書もなく、changelogのエントリもなく、リファレンスページもない。開発者が通常探す場所を探していたら、存在しないと結論づけていただろう。

ClaudeとHelp Scoutをつなぐ4つの方法

ルートはちょうど4つあり、それらは他のどの軸よりも重要な一点で違いが分かれる。顧客にメールを送信できるかどうかだ。

このチャートの形が、話のすべてを物語っている。即座に使えて、なおかつ公式であるルートは、まさに顧客に返信できないルートだけだ。返信できるものはすべて、Help Scout以外の誰かによるものか、あなた自身が構築するものかのどちらかだ。

ルート1: 公式MCPサーバー、最初から最後まで

ほとんどの人はここから始めるべきだ。試すコストは3分とゼロドルだから。

まずプランの壁。 コネクタはStandard、Plus、Pro、つまりAPIアクセスを含むどのプランでも動作する。FreeプランはAPIアクセスがまったくないため対象外だ。レポートツールはPlusかProが必要で、Help Scoutのレポートエンドポイントもまた Standard にはないからだ。自分がどのティアなのか調べたいなら、当社のHelp Scout料金解説に一覧表がある。

Claude ProまたはMaxでは、Customize、次にConnectors、次にAdd custom connectorに進む。名前をHelp Scoutとし、リモートMCPサーバーのURLをhttps://mcp.helpscout.net/mcpに設定し、詳細設定は空欄のままにする。コネクタは自動的に登録される。その後Help Scoutにログインして承認する。

Claude TeamまたはEnterpriseでは、組織設定を通じてClaudeオーナーのみが追加できる。各チームメンバーはその後、自分自身のHelp Scoutログインで接続する。これはHelp Scoutのルールではなく、カスタムコネクタに関するAnthropicのルールだ。

誰もがはまる落とし穴: My AppsのHelp ScoutアプリIDやシークレットをOAuthフィールドに貼り付けないこと。Help Scoutは、それらの認証情報はInbox API用であり、ここでは機能しないと明確に警告している。フィールドは空欄のままにしよう。

もう一つ知っておくべき認証情報がある。Inboxツールは自動的に接続されるが、Docsツールには、認可の際にオプションのフィールドに貼り付ける別のDocs APIキーが必要だ。それはYour Profile、次にSecurity and Accessの下にあり、Docsの作成・編集権限が必要となる。これを飛ばすと、Claudeは単純にあなたのナレッジベースを見ることができない。それは通常、人々が最初にClaudeに読ませたいものだ。

接続が完了したら、Claudeに Help Scout のヘルスチェックを実行するよう依頼しよう。それはツールが正しく読み込まれたことを確認する、Help Scout自身が文書化している方法だ。

コネクタが実際に公開しているもの

かなり広範囲だ。そしてそれは、サポートリーダーが照会したいと望みながら、現在はCSVをエクスポートしなければ実現できないことの、ほぼすべてでもある。

読み取り専用アクセスでClaudeが本当に得意なこと

ここでは具体的に話したい。「あなたの受信箱を読むAI」はデモのように聞こえるが、実際に役立つ範囲はそれより狭いからだ。

最良の使い方は、レポートタブでは答えられない質問だ。Help Scoutの分析はレビューで基本的だと評されており、G2のプロフィールに集約されている不満は、高度な機能とカスタマイズ性の欠如だ。コネクタ経由のClaudeなら「先の四半期に請求関連とタグ付けされた会話をすべて読んで、件数の多い順に根本原因を5つ挙げて」といった質問ができ、実際に使える答えが返ってくる。なぜならClaudeはタグの集計ではなく実際のスレッド本文を読んでいるからだ。それは本物のサポートチケット分析であり、コネクタが最も得意とする仕事だ。

タグ付けを監査する手っ取り早い方法でもある。Claudeが繰り返し配送に関する質問が請求のもとに分類されているのを見つけるなら、あなたのタクソノミーがずれてきているということで、それはまさにAIチケットタグ付けが解決するために存在する問題だ。

2つ目の良い使い方は、ナレッジギャップの発見だ。同じセッションでClaudeにクローズされた会話とDocsサイトの両方を見させ、記事のない繰り返しの質問はどれかを尋ねよう。それはどんなHelp Scout AIエージェントをオンにするよりも前に行える、最もレバレッジの高いことだ。なぜならAI AnswersはDocsから解決を導くため、記事が欠けていることは確実なエスカレーションを意味するからだ。それを先に直すことの複利的な効果については、きちんと整備されたナレッジベースに関する当社の解説にある。

3つ目は品質保証だ。解決済みの会話を20件読み、自社のトーンガイドに照らして採点するのは面倒な作業だが、Claudeはそれをうまくこなし、AIサポート品質保証のワークフローにきれいに当てはまる。ここでは読み取り専用であることは妥協ではなく機能だ。誰もQAボットに送信権限を持たせたくはない。特にトーンで採点しているなら、当社のブランドボイスガイドが出発点になる基準となるだろう。

役に立たなくなるのは、それを何らかの行動に変えたいと望んだ瞬間からだ。

壁: すべてを読むが、誰にも答えない

Help Scoutのドキュメントからそのまま引用した境界線がこれだ。現在作成される接続は読み取り専用のため、あなたのAIエージェントは情報を見つけて要約できるが、顧客への返信、メモの追加、タグの変更、Docs記事の編集はできない。

もともとのMCPベータからの一部のアカウントは、コネクタが一般提供に移行した際にも書き込みツールを保持した。それ以外のすべてのアカウントは読み取りのみを得る。Help Scoutは全アカウント向けの書き込み機能をロードマップ上のものとして説明しているが、共有できる日程はない。

この「メモの追加」の除外は、二度見に値する。これが人々を最も驚かせるものだからだ。内部メモは顧客に見えるものではない。それはヘルプデスクにおいて考えうる最も安全な書き込みであり、あらゆる「AIが提案し、人間が判断する」ワークフローが依拠しているものだ。Claudeはそれができない。したがって、AIがチケットに提案を下書きし、人間がそれを送信するという自然な中間地点は、公式ルートでは全く提供されていない。このコパイロット的パターンこそ、ほとんどのチームがHelp ScoutにAIを追加することについて尋ねるときに意味していることであり、まさにコネクタが除外している形だ。

私はこれをHelp Scout側の悪い判断だとは思わない。まず読み取り専用のコネクタをリリースするのは保守的で正当化できる選択であり、私もおそらく同じ判断をするだろう。しかしそれは、「私たちはClaudeをヘルプデスクに接続した」という文章が、それを聞いた人が普段想定するものとは、大きく異なる何かを表しているということを意味する。

ルート2: 返信を送信できるサーバー群

もし今日書き込みが必要なら、選択肢は3つ存在し、そのどれもがHelp Scout製ではない。

コミュニティサーバー。 drewburchfield/help-scout-mcp-serverが本格的な方だ。MITライセンス、46スター、191コミット、v2.1.0が2026年7月30日にリリースされている。これはHelp Scout本人ではなく、自らをHelp Scoutの顧客だと説明する独立系開発者によってメンテナンスされている。その読み取り範囲は、InboxとDocsの両APIにまたがる55の読み取り操作をカバーする3つの統合ツールだ。

書き込み設計はここでの興味深い部分であり、正直に言って私がこれまで読んだ多くの自社製連携よりもよく練られている。デフォルトのインストールは読み取り専用だ。HELPSCOUT_ENABLE_WRITES=trueを設定すると、下書き返信、内部メモ、ステータス、割り当て、タグ、スヌーズを含む11の操作がアンロックされるが、そのどれも誰にもメールを送信しない。第二のフラグHELPSCOUT_ENABLE_CUSTOMER_VISIBLE_WRITES=trueだけがsendReplyとpublishDraftをアンロックし、これらの呼び出しはそれぞれ操作と対象を明示した確認を伴わなければ、Help Scoutに届く前に拒否される。削除はどのフラグの下でも公開されていない。

これはnpmパッケージ、Dockerイメージ、ワンクリックのデスクトップ拡張機能、さらにClaude Code向けのプラグインスキルとして配布されている。

ZapierとPipedream。 ZapierのHelp Scout MCPはAdd Note、Create Conversation、Create Customer、Find Conversation、Send Replyを公開しており、Zapierは下書きフラグが設定されていない限り、これを実際のメール送信としてフラグを立てる。課金はタスクベースで、MCPツールの呼び出し1回で2タスクを消費する。Pipedreamのサーバーは独自のSend Replyを含む12のアクションをカバーしており、同じ警告が付いている。

どちらも社内自動化のための現実的な選択肢だ。どちらも、あなたの顧客との会話が第三のゲートウェイベンダーを経由することを意味し、これはブログ記事の脚注ではなく、セキュリティレビューの担当者と持つべき会話だ。ここで何を構築しているのかも明確にしておく価値がある。台本化されたアクションの連鎖は、エージェントというよりルールエンジンに近く、その違いはAIエージェント対チャットボットで扱われている。

ルート3: 自分で構築する、そして計画を変える発見

ここで「そしてそれは単純だ」と書くつもりだったが、ドキュメントをきちんと読んで考えが変わった。

Inbox APIはよく作られている。authorization codeとclient credentialsフローを備えたOAuth2、リソースリンク付きのHALスタイルのレスポンス、サポートに提示できるlogRefを持つクリーンなエラー形式。読み取りはGET /v2/conversations、顧客に見える返信を書くのはPOST /v2/conversations/{id}/reply、内部メモを書くのはPOST /v2/conversations/{id}/notesだ。メッセージを顧客に見えるものにするのはフィールドではなく、エンドポイントだ。

そしてこれがある。Help Scoutにはスコープが存在しない。 スコープのページは404を返し、Inbox APIの索引のOverviewナビゲーションにはスコープの項目自体が存在しない。認証、後方互換性、コンテンツタイプ、エラー、HTTPメソッド、リンク、ページネーション、レート制限、ステータスコード、時刻。スコープはない。

会話を一覧表示できるトークンは、顧客への返信を公開することもできる。読み取り専用の認証情報を発行する方法はない。これは、ライブの受信箱でAIエージェントをテストする際に私が推奨してきたやり方とは正反対であり、はっきり言っておく価値がある。というのも、通常のセキュリティアドバイスがここでは通用しないからだ。Frontでは、エージェントに下書きとコメント権限は与えるが送信権限は与えないトークンを発行でき、その境界はプラットフォームによって強制される。Help Scoutでは、その境界はあなた自身のミドルウェアに存在しなければならない。

実用的な代替策は、返信エンドポイントのdraftフィールドだ。draft: trueにすれば、返信は送信されるのではなく、人間向けの下書きとして届く。それは良いフラグだ。しかしそれは、あなたのコードが毎回の呼び出しで、永遠に、設定することを覚えておかなければならないフラグでもある。

何が構築可能かを左右する、もう少しの数字がある。

• レート制限はトークン単位ではなくアカウント単位だ: Help ScoutのAPI アクセステーブルによると、Standardで1分あたり200回、Plusで400回、Proで800回だ。あなたのエージェントは、顧客がインストールしている他のあらゆる連携とこの予算を共有する。
• 書き込みは2倍でカウントされる。POSTはレート制限に対して2リクエスト分としてカウントされるため、読み取ってから返信するサイクルは3ではなく4ユニットを消費する。Standardでは、これは1分あたり約50回の完全なサイクルという実質的な上限になる。
• 会話のページングは25件に制限されており、他のすべてが使う50件ではない。そしてページネーションのドキュメントにはper_pageパラメータが存在しない。10万件の会話のバックフィルは4,000回のページリクエストとなり、他に何も走っていない状態でも、StandardアカウントのすべてのAPI予算のおよそ20分に相当する。
• デフォルトのフィルタは静かに嘘をつく。List Conversationsはデフォルトでstatus=activeになっている。?status=allを忘れると、あなたのエージェントはクローズされた履歴を一切見ることができない。それはまさに欲しかったコーパスだ。
• embed=threadsはBeaconのチャットスレッドを意図的に切り詰める。 この1回の呼び出しで済む近道は、検索パイプラインに部分的な文字起こししか渡さない。
• 1会話あたり100スレッドまでで、その先は412だ。 長いやり取りは書き込み不能になる。
• v2ではAIの返信を人間の返信と区別できない。 v2はsystem_userをuserに正規化する。これを保持するのはv3のエンドポイントか、payloadVersion: V3のwebhookだけだ。これを見落とすと、あなたのエージェントが自分自身に返信してしまうことになりかねない。

これらのどれも致命的な欠陥ではない。すべて合わせると、あなたが計画していなかった1週間分の作業であり、そのエンジニアリング工数こそが、私が見てきたすべての内製対購入の比較表から抜け落ちている項目だ。AIエージェント対人間エージェントのコストに関する当社の解説が、それについて私が持っている最も正直なモデルだ。

Help Scout独自のAIはClaudeで動かせるか?

いいえ、そしてその答えは異例なほどよく文書化されている。

Help Scoutはリリース済みのすべてのAI機能を、名指しでOpenAIに帰属させている。AI DraftsはGPT-5.1上で動作する。AI SummarizeはOpenAI駆動のツールであり、AI AssistはOpenAIのAPIサービスによって動いており、AI AnswersはOpenAIによって動いている。

AI Transparency Hubは、Help ScoutがOpenAIの確立された基盤モデルに加え、自社のLoRAアダプターを使用していると述べている。そしてAI Agentの設定には、モデル選択欄も、プロバイダー欄も、APIキー欄もどこにもなく、その設定画面全体はKnowledge、Basics、Test、Connectionsで構成されている。

Anthropicは確かにHelp Scoutのサブプロセッサー一覧に、OpenAIと同一の「Machine learning」という目的文字列で掲載されている。つまり顧客データがAnthropicへ流れることは認可されている。何のためかはHelp Scoutのどのページにも記載がなく、その一覧の日付は2025年1月で、現在の機能セットより1年以上前のものだ。私はこれについて、どちらの方向にも議論を組み立てるつもりはない。ベンダーがこれをどう捉えているかというより広い姿は、当社のHelp Scout AIアプローチの解説にある。

コネクタはこれを変えない。そしてHelp Scoutは、この問い全体を解決する一文でそう述べている。コネクタはいかなるAIプロバイダーの認証情報も保持せず、独自のモデル呼び出しも行わない。MCPはHelp Scoutのデータを外部へ、あなたのClaudeへと動かす。AI Answersの背後にあるモデルを入れ替えるものではない。

比較する前に知っておくべきもう一つのこと。それは、ほとんどのチームをHelp Scout AIの代替を探させる引き金となる細部だ。AI Answersは3つのものから学習する。Docsサイト、公開されているURL、そして手書きのImprovementsだ。過去のチケット履歴はそれらのどれにも含まれない。AI Draftsは過去の会話から学習するが、何かを生成し始めるまでに約100件の会話返信を必要とする。最良の回答が公開済みの記事ではなくクローズされたチケットの中にあるなら、それがそのギャップだ。

実際にかかるコスト

MCPコネクタは無料だ。あなたが支払うのはClaudeのトークン料金であり、それはほとんどの人が予想するよりも低い。入力100万トークンあたり2ドル、出力100万トークンあたり10ドルのClaude Sonnet 5で、入力トークン20,000、出力トークン1,000を生成する根拠づけられた返信は0.05ドルになる。18,000トークンのシステムプロンプトと、100万トークンあたり0.20ドルのキャッシュヒットとして提供されるナレッジブロックを使えば、それは0.0176ドルまで下がる。

Help ScoutのAI Answers解決1件あたり0.75ドルと比較すると、これは42倍の差であり、なぜこの計算が魅力的に見えるのか私にも理解できる。

さて、できれば書きたくない部分だ。私たちはまさにこの一番下の行が理由で顧客を失ったことがある。当社自身のチャーン分析では、3件の特定できるアカウントが内製するために離脱し、そのうち1件は直接Claude APIに移行した。もう1件はもう少しで同じ道をたどるところだった。月額799ドルのプランを利用していた化粧品ブランドが、それだけ支払う意味がない、私たちが移行できないなら自前で構築すると言ってきたが、従量課金の月額約200ドルへ切り替えることで引き留めた。内製対購入の引力は本物であり、そうでないふりをするつもりはない。

しかし私は帰りの旅も見てきた。ITインシデントのナレッジベースを組み立てていたある開発者が、当社のダッシュボードチャットではっきりとこう言った。

"Yes build an API for Aria to call, I already used claude but it's not free, and Gemini doesn't work correctly"

a builder assembling an IT-incident knowledge base, who tried the Claude API and Gemini first

それが0.0176ドルという数字が見落としているものだ。それは間違った数字なのではなく、間違った単位なのだ。0.75ドルは、サポートマネージャーがオフにできる、展開済みでガードレールを備えた、エスカレーションするエージェントを買う。0.0176ドルは、モデル呼び出しを1回買う。この2つの間にあるすべてが、そのプロジェクトそのものであり、Help Scoutに関して言えば、そのプロジェクトはまず自前の権限レイヤーを書くところから始まる。プラットフォームがそれを提供してくれないからだ。自分で構築するより完成品を比較したいなら、Help Scout向けベストAIにショートリストがある。

ほとんど誰も確認していないセキュリティ上の細部

この記事を1段落しか読まないなら、これを読んでほしい。

MCPをアカウント全体で無効にするHelp Scoutの設定は存在しない。Help Scoutは直接そう述べている。Help Scoutのログインを持つあらゆるユーザーが、自分自身のAIエージェントを接続できる。管理者だけではない。あらゆるユーザーだ。中央での統制はAIプラットフォーム側で行う必要があり、そこではClaude TeamおよびEnterpriseのオーナーがURLでコネクタを許可リストに入れたりブロックしたりできるが、それは誰かの個人のClaude Proアカウント上のエージェントには何の影響も及ぼさない。

あなたがこれについてどう感じるかを決める前に読む価値がある、同じドキュメント内のさらに3つの細部がある。

• 失効は緩い。 AIクライアントからコネクタを削除しても、認証情報を確実には無効化しない。失効リクエストがなければ、アクセストークンは最大2時間、リフレッシュトークンは最大30日間有効なままになる。信頼できる遮断方法はHelp Scoutユーザーを無効化することであり、Docs APIキーはそれをも生き延び、個別に失効させるまで有効なままだ。
• アウトバウンドのコンテンツフィルタリングがない。 コネクタは送信内容をスキャンもフィルタリングもしない。顧客がチケットにパスワードを貼り付けていれば、それはそのままAIに渡る。
• HIPAAは付いてこない。 HIPAAは署名済みBAAがあればProで利用可能だが、Help Scoutは、Help ScoutとのBAAはあなたのAIプロバイダーをカバーしないと明言している。保護対象の医療情報がClaudeに届く可能性があるなら、Anthropicとの別個の契約が必要だ。そして導入済みアプリとは異なり、誰が接続したかについての管理者側の可視性は存在しない。

これはHelp Scoutの問題というより、MCPエコシステム全体の問題であり、実務者たちはそれを声高に語ってきた。MCP権限に関するHacker Newsのスレッドから。

"In an organisation we can't limit MCP access. It's all or nothing. Everything the user can touch, the MCP can touch."

theshrike79, Hacker News

同じ人物のフォローアップこそ、サポートリーダーが思い当たるバージョンだ。5件の顧客アカウントにアクセスできる人間なら、それらを頭の中で区別できるが、同じアクセス権を持つエージェントは、親切心から同じ問題を5件すべてで「修正」しようとしてしまうかもしれない。Help Scoutの読み取り専用というデフォルトは、まさにそれに対する現実的な緩和策だ。ただし、それはあなたが設定できるコントロールではない。

Help Scoutに公平を期すなら、これらはどれも隠されていない。設定方法を教えてくれる同じ記事の中にすべて書かれており、それは多くのベンダーが示す以上の率直さだ。しかし「文書化されている」ことと「あなたのCISOが知っている」ことは異なる状態であり、その差の中にインシデントが潜んでいる。Help Scout連携ディレクトリの導入済みアプリはここで異なる振る舞いをする。管理者が一度承認すれば、その後は可視化できるからだ。

これを読んでいるあなたがサポートリーダーなら、実践的な行動はこれだ。誰かがすでにあなたの受信箱にClaudeを接続していないか、チームに聞いてみよう。正直な答えは、あなたが現在、それをHelp Scoutの内部から調べる方法を持っていないということだ。

チームが実際に語っていること

Help Scoutの AI に対するコミュニティの感情は、はっきりと分かれている。機能はシンプルであることで評価されている。価格はそうではない。

"ai answers sits in their widget and answers straight from your knowledge base, they claim around 73% resolution. also has ai drafts, tone ..."

best ai customer support tools, my picks, r/AI_Customer_Support

その73%はHelp Scout自身が公表している数字であり、それが何から解決を導いているか、つまりチケットではなくDocsの記事から、ということさえ覚えておけば、引用するには公正な数字だ。

より大きく響いているテーマはコストの予測可能性であり、これはAI機能よりも前から続いている。Help Scoutが2025年に座席課金から対応課金へと切り替え、その後方針を戻したとき、信頼へのダメージは残った。

"HelpScout changed back to user-based pricing. Guess too many people cancelled including me... I'll still stay with Freescout anyways. Helpscout lost all trust with this flip-flopping on pricing."

u/manu_8487, r/SaaS

その経緯は、0.75ドルのアドオンがどう受け止められるかに影響する。すでに課金モデルの変更で痛い目を見たチームは、従量課金型のAI料金を特有の疑いの目で読み、Help Scoutのレビューのスレッドもそれを裏付けている。それはまた、当社のHelp Scoutの代替まとめとFrontとの比較へのトラフィックの多くを支えている静かな推進力でもある。

Help Scoutの受信箱の中でeeselが担う場所

公式コネクタとeeselは、同じ問題の異なる半分を解決している。読み取り専用サーバーと競合しているふりをするより、それをはっきりと言っておく方がいい。

分析のためにはMCPコネクタを残しておこう。それは無料で、自社製であり、Claudeに先週の会話を採点させるのは、10分の使い方として堅実だ。

eeselは、コネクタがやらない半分のためにある。それは別個のウィジェットとしてではなく、本物のAIヘルプデスクエージェントとしてあなたのHelp Scout受信箱に参加し、当社のダッシュボードからコードなしでHelp Scout APIを通じて接続し、あなたのDocs記事、保存済みの定型返信、そして過去の会話を自動的に取り込む。この最後の点こそ、チケット履歴をまったく読めないAI Answersと比べて最も重要な違いだ。それはあなたのチームのアドレスからあなたの受信箱を通じて下書きと送信を行い、メモを追加し、タグを更新し、チケットをルーティングしてチームメンバーへ振り分け、既存のHelp Scoutワークフローを尊重する。

評価している間は1つの受信箱や単一のタグに範囲を限定でき、自動返信を有効にするまでは、人間がすべての返信を送信する下書き専用モードで動かすこともできる。

導入部分こそ、私が実際に推したいところだ。実際の会話に触れる前に、あなた自身の過去のHelp Scoutチケットに対してシミュレーションを行い、それが何と言っていたかを確認する。私たちがこれを構築したのは、自信ありげに聞こえるボットが間違った答えを出すのを見てきたからであり、それを知る唯一の誠実な方法は、すでに答えを知っているチケットに対してテストすることだ。エスカレーションは、エージェントのハンドオフで説明しているのと同じロジックに従う。自信度が下がれば、推測するのではなく人間に差し戻す。価格はプラットフォーム手数料なし、座席あたりの料金なしで、対応した会話1件あたり0.40ドルだ。

要するにこういうことだ。読み取りにはClaudeを接続し、書き込みには書き込めるものを用意しよう。eeselを無料で試す、あるいは何かを接続する前に仕組みを見ておきたいなら、まずHelp Scoutチャットボットの解説を読んでみてほしい。