AIエージェントを自社の業務スタックに統合する方法(2026年版ガイド)

要点

AIエージェントを業務スタックに統合するときは、1つの大きな接続ではなく、3つの役割で考えます。何を読むか(ヘルプセンター、過去のチケット、Confluence、Notion、Google Drive)、何が起動させるか(新規チケット、Slackでのメンション、自社システムからのWebhook)、何を実行できるか(タグ付け、返信、注文の確認、返金)です。この順に、まず読み取り専用で接続し、お金が動く操作はすべて人間の承認の後ろに置きます。

多くの導入が失敗するのは権限です。エージェントが見られるのは、接続したユーザーが見られるもの、スコープが許可するもの、そして明示的に共有したものだけです。ZendeskのAPIトークンは管理者になりすませますし、FreshdeskのAPIキーは1人のロールをそのまま引き継ぎ、Shopifyのread_ordersスコープは直近60日分しかカバーせず、Notionの新しい接続はページに追加するまで何も見えません。個人トークンではなくOAuthを選び、エージェントには専用の狭いアイデンティティを与え、顧客が返信を目にする前に過去のチケットでテストしてください。

eeselのAIヘルプデスクチームメイトは、まさにこの分け方を軸に作られています。既存のヘルプデスクに参加し、ナレッジツールを読み、許可リスト経由で自社APIを呼び出し、すべての操作を「自動」「先に確認」「オフ」から選べます。設定はダッシュボード、eesel CLI、MCPクライアントのいずれからでも行え、1チケットは、いくつのシステムに触れても1クレジットです。

AIエージェントをスタックに統合するとは、実際にどういうことか

私はeeselのプロダクトを担当していて、主な仕事は、AIチームメイトが他社のツールの中で働けるようにするコネクターを作ることです。そこで学んだ最も役に立つことは、AIが弱点になることはめったにないということです。弱点は配管です。ZendeskとShopifyを使うEコマースの受信トレイ(月に約1,000チケット)での実トラフィックの試験では、担当者がAIの下書きに加えた修正のおよそ65%はトーンと長さに関するもので、AIの事実誤認が原因だったのは約5%にすぎませんでした。修正の約20%は、ERPや物流事業者のように、エージェントがまだ接続されていないシステムのデータが回答に必要だったことが原因でした。プロンプトを改善しても、その20%は解決しません。解決するのは、統合を増やすことです。

そのため、サポートリーダーから「スタックにAIをつなぐ方法」を聞かれたら、質問を3つに分けます。eeselのドキュメントはどの統合も同じ形、つまりソース、トリガー、アクションの組み合わせとして説明しており、このモデルは評価するどのベンダーにも当てはまります。

• 読む。 回答の根拠になるナレッジ。ヘルプセンターの記事、過去のチケットとマクロ、社内Wiki、製品ドキュメント、ポリシー。
• 起動する。 作業を始めるきっかけになるイベント。新規チケット、顧客のメッセージ、Slackの@メンション、倉庫システムからのWebhook、スケジュール。
• 実行する。 変更できること。チケットのタグ付けと振り分け、内部メモの追加、返信の送信、注文の確認、返品の開始、返金。

3つすべてをこなすツールもあります。Zendeskのようなヘルプデスクは、ソース(チケット、マクロ、ヘルプセンター)であり、トリガー(新規チケット)であり、アクションの場(返信、タグ付け、割り当て)でもあります。ConfluenceやNotion、Google Driveのようにソースのみのものもあり、読むだけで書き込みはしません。自社の注文データベースは、多くの場合アクション専用です。スタックをこのように仕分けると、どの接続がリスクの低いもの(読み取り)で、どれに本格的なガードレールが必要か(書き込み)が見えてきます。

先にAIエージェントとビジネスツール全体の概要を知りたい方には、同僚が書いたAIエージェントとビジネスツールの入門記事があります。この記事は、サポートや運用のリーダー向けの実践編です。

ステップ1:何かを接続する前に、スタックを洗い出す

設定画面を開く前に、エージェントが必要とするシステムごとに1行ずつ書き出します。20分で終わりますし、私がよく目にする失敗を避けられます。ヘルプデスクを接続してそこそこの回答が出るようになった後で、顧客が最も多く尋ねる質問(「注文はどこ?」「なぜ二重に請求されたの?」)に、別の場所にあるデータが必要だと気づく、という失敗です。

次に、各行にエージェントが間違えたときに何が壊れるかを書き添えます。Wikiからの誤った回答なら、修正の手間で済みます。誤った注文への返金は、お金の損失になります。接続する順序は、この重さの順です。

下に、プランナーを作りました。自社のスタックにあるものをチェックすると、私なら接続する順序と、各システムの権限上の落とし穴(そのベンダー自身のドキュメントに基づく)が表示されます。

ステップ2:読ませるナレッジを接続する。信頼できるものだけを

ナレッジは、ここでの接続がすべて読み取り専用なので、最も安全に始められるレイヤーです。同時に、品質が決まる場所でもあります。AIは与えたものを、人間にはできない速さで繰り返します。

「ナレッジベースが8か月更新されていなかったせいで、ボットが自信満々に間違った回答をするのを見たことがあります。顧客は悪い回答を受け取っただけではありません。悪い回答を即座に受け取ったのです。」

u/Agile_Plankton_543, r/salesforce, Reddit

ほかより重要な情報源が3つあります。

1. 過去のチケットとマクロ。 記事が書かれていないエッジケースも含め、チームが実際にどう回答しているかがわかります。ベンダーのエージェントが解決済みチケットから学べないなら、理想的なケースを書いたドキュメントだけで動いていることになります。詳しくは、同僚のナレッジベースでの学習のガイドをご覧ください。
2. ヘルプセンター。 公開されていて構造化されており、通常は最も新しい情報です。出発点としては十分ですが、それだけでは薄いです。
3. 社内Wikiとドキュメント。 Confluence、Notion、Google Drive、SharePoint。返金の例外やエスカレーションのルールはここにあります。

Wikiツールごとに権限モデルが異なり、どれも「思っているより少ない」がデフォルトです。

• Notionは、統合を現在「接続」と呼んでいます。接続が見られるのは、共有されたページだけです。「ページが共有されていない場合、APIリクエストはすべてエラーを返します」(Notionの認可ドキュメント)。読み取り、更新、挿入は別々の権限なので、読み取りだけを付与できます。
• Confluence Cloudのアプリはユーザーに代わって動作し、「アプリが代理を務めるユーザーの権限は、アプリのスコープにかかわらず、常にアプリを制約します」(AtlassianのOAuthドキュメント)。制限付きスペースには、アプリを明示的に追加する必要があります。
• Google Driveには広範なdrive.readonlyスコープがあり、Googleは制限付きと分類しています。そのデータをサーバーに保存すると、セキュリティ評価の対象になります(Driveのスコープに関するドキュメント)。多くのツールがファイルやフォルダーを選ぶ方式にしているのはそのためです。

eesel側では、Confluenceコネクターは設計上、読み取り専用です。Notionコネクターは、汎用の書き込みアクションを1つだけ備えていますが、デフォルトではオフで、オンにしない限り読み取りのみです。

2つ目の教訓は同期についてです。ナレッジコネクターは多くの場合、ライブフィードではなく、ある時点のコピーであり、気づかないうちに失敗します。これが原因で解約した顧客を見たことがあります。その顧客の主要なデータソースは、毎日変わるGoogle Drive上の注文ステータスのスプレッドシートでしたが、同期が3回、気づかれないまま失敗し、より安いツールに乗り換えました。新しいファイルがどう反映されるのか、同期が壊れたらどうやって気づけるのかを、どのベンダーにも尋ねてください。eeselの場合は、ツールによって答えが異なり、ドキュメントでもはっきり書いています。Confluenceのページは編集すると再インデックスされ、アプリは約1時間に1回突き合わせを行います(Confluenceのドキュメント)。一方、Google Driveの新しいファイルはピッカーで選び直す必要があり、1つのワークスペースで1日に最大2,500ファイルまで同期できます(Google Driveのドキュメント)。

チームが実際に使っているフォーマットも確認してください。eeselの営業通話に参加したDTCのサプリメントブランド(月に約7,000件のGorgiasチケット)は、実際の手順をClickUpのSOPとLoomの動画に置き、その上に古いマクロが山積みになっていました。誰かが文章に書き起こさない限り、テキストのコネクターにはどれも読めません。心当たりがあるなら、統合作業の前にAIナレッジベースの整備を行ってください。

ステップ3:チケットがすでにあるヘルプデスクに接続する

ヘルプデスクは、3つの役割を同時に担うので、最も重要な統合です。私の強い意見は、チケットを別のAI受信トレイに送るのではなく、チームがすでに使っているヘルプデスクの中にエージェントを置くことです。担当者はビュー、マクロ、SLAをそのまま使え、AIの作業は同じチケット上のメモや返信として表示されます。AIヘルプデスク統合は、こうあるべきです。

ヘルプデスクごとに違うのは、外部アプリがどう認証するか、誰のアイデンティティで動作するか、どれだけ呼び出せるかです。各ベンダーの開発者向けドキュメントの内容は次のとおりです。

この表から、設定の仕方が変わる点が3つあります。

• 個人のAPIトークンではなく、OAuthを使う。 Zendeskは、多くの顧客にサービスを提供するベンダーは「グローバルなOAuthアクセストークンを使用しなければならない」と述べています(Zendeskの認証ドキュメント)。個人に紐づくトークンは、その人が退職した日に使えなくなります。ヘルプデスクが個人キーしか提供しない場合は、AI専用に権限の狭いエージェント席を作り、その席からキーを生成してください。
• レート制限は共有される。 ZendeskのTeamプランでは、1分あたり200リクエストをAI、CRMの同期、ほかのすべてのアプリで分け合います。Zendeskは、1つのチケットへの更新も、ユーザーあたり10分で30回までに制限しています(レート制限)。タグ付け、メモ、返信を別々の呼び出しで行うエージェントは、思った以上に早く使い切ります。同僚のZendeskのAPIレート制限の解説で、さらに詳しく扱っています。
• 内部メモから始める。 上のヘルプデスクはどれも、非公開メモを投稿できます。最初の1週間として最も安全です。AIが下書きし、人間が読んで送信するので、顧客に誤って届くことはありません。

また、ヘルプデスク組み込みのAIと、そこに接続するレイヤーのどちらにするかも決める必要があります。Zendesk AI、Freddy AI Agent、Agentforceのような組み込み型のエージェントは、セットアップが最も少なくて済みますが、ヘルプデスク外への到達範囲は、デモが示すより狭いことがよくあります。あるレビュアーはGorgiasについてこう述べています。

「AIエージェントも同じパターンで、フル機能はShopifyでしか使えず、ストアごとにメールを設定する面倒な仕組みが必要で、すべてのビジネスに合うわけではありません。」

Frank A., Capterra

星5つのレビュアーの指摘として妥当で、どのベンダーにも向けるべき問いです。そのアクションは、デモのスタックではなく、自社のスタックで動くのか。私も負けた側に立ったことがあります。今年の初め、eeselはSalesforceやHubSpotのネイティブなヘルプデスクコネクターがなかったために、ミッドマーケットの案件を失いました。現在は両方あります(Salesforce、HubSpot)が、教訓は変わりません。コネクターの一覧は厳格なフィルターなので、最初に確認してください。

eesel側でZendeskを完全に接続した状態は、こうなります。ヘルプセンター、マクロ、過去のチケットが3つの別々のソースとして、それぞれ個別のトグルを持つので、1つを外すこともできます。

eeselのヘルプデスクのドキュメントには、すべてのベンダーに言ってほしい一文があります。「接続しただけでは、エージェントはヘルプデスクを読めるようになるだけです。オートメーションを作成するまで、チケットには何もしません。」(ヘルプデスクのドキュメント)。接続と本番稼働は別のステップで、分けておきたいものです。

ステップ4:ストア、請求、社内システムにアクションをつなぐ

ここは、回答するだけのボットを、チケットを解決するものに変えるレイヤーです。ミスがお金の損失につながる場所でもあります。「注文はどこ」「住所を変更したい」「返金して」といったチケットの多くは、ヘルプデスクではないシステムでの照会や書き込みを必要とします。

Shopifyなどのストア

私が最もよく見るのはShopifyで、アクセススコープには、接続前に知っておきたい落とし穴が2つあります。

• read_ordersとwrite_ordersは「直近60日以内に作成された注文をカバーします。それより古い注文にはread_all_ordersを追加します。これはアクセスを申請する必要があります」(Shopifyのアクセススコープ)。3か月前の注文を見つけられないエージェントは、顧客にその注文は存在しないと伝えてしまいます。
• キャンセルにはwrite_ordersが必要で、Shopify自身のドキュメントはorderCancelについて「このアクションは取り消せません」と記しています(orderCancel)。顧客の名前、メール、電話番号、住所は、レベル2の保護対象データでもあり、アプリには追加の審査が必要です(保護対象の顧客データ)。

eeselのShopify統合は、アクションを、読み取りグループ(注文の取得、注文履歴、フルフィルメントと配送追跡)と書き込みグループ(返品の作成、配送先住所の更新、返金、キャンセル)に分けています。ドキュメントには、現在はShopifyの全注文読み取りの権限を要求するものの、この変更前に接続されたストアは、誰かが再接続するまで60日の上限のままである、という注記もあります(eeselのShopifyドキュメント)。これこそ、自社の設定で確認すべき細部です。さらに詳しい手順は、サポートエージェントへのShopifyの注文データの接続をご覧ください。

請求と決済

AIエージェントに、決済のシークレットキーを渡してはいけません。Stripe自身のガイダンスは明快です。「RAKは、AIエージェントに渡すAPIキーとして推奨されるキーの種類です」(Stripeの制限付きキー)。制限付きキーはリソースごとに読み取り、書き込み、なしを設定するため、サポートエージェントは、支払い履歴や請求書を読めても、入金には触れません。Stripeではキーにエージェント用のタグを付けることもでき、タグ付きキーには、入金、返金、アカウント変更に承認ルールがデフォルトで適用されます(StripeのAPIキー)。

自社システム(注文データベース、倉庫、ERP)

既製のコネクターがないものについては、許可リスト方式のAPI呼び出しが定番です。エージェントに、呼び出してよいドメインと、送信する認証ヘッダーを伝えると、プラットフォームが認証情報をサーバー側で付与するため、モデルには見えません。eeselではNetwork Accessがこれにあたります。追加していないドメインへのリクエストは拒否され、GET、POST、PATCH、DELETEに対応し、「認証情報は設定内に保管され、eeselが各リクエストに付与するため、AIにはまったく見えません。」

どのツールを使うにしても、エージェントがアクションについて話す前に、そのアクションが実際に動くことをテストしてください。返金ポリシーを読んだモデルは、処理する手段のない返金を喜んで提案します。G2のAdaのレビュアーは、まさにこれを目にしました。エージェントが、キャンセルできない注文のキャンセルを申し出たのです。

「Adaが、元のトレーニングに含まれていなかった回答や約束をすることがありました ... 幸い、これらの問題は追加のコーチングとアップデートで簡単に修正でき、精度も時間とともに向上し続けています。」

認証済みレビュアー, G2

対処は、統合だけでなく指示にもあります。どのアクションが存在するか、そして存在しないアクションを顧客が求めたときに何と言うかを、エージェントに伝えてください。同僚のAIによる返金の自動化のガイドで、ポリシー面を扱っています。

ステップ5:トリガーを設定する前に、権限を設定する

私が使っている考え方を紹介します。AIエージェントに「あなたのスタック」は見えません。見えるのは、4つの制限が重なる部分で、それぞれ設定する人が違います。

1. 接続したユーザー。 Confluenceのアプリは認可したユーザーによって、Freshdeskのキーはそのエージェントのロールによって、Salesforceの接続アプリはRun Asユーザーによって上限が決まります。「許可」をクリックした人が、天井を決めます。
2. スコープ。 アプリがインストール時に要求したもの。HubSpotのスコープ画面にもはっきり書かれています。スコープは必要最小限にします。
3. 共有または選択したもの。 接続に追加したNotionのページ、ピッカーで選んだDriveのフォルダー、参加したSlackのチャンネル。
4. それをエージェントが何に使ってよいか。 AIツール自体の、アクションごとの設定。

4つ目の制限は、日々コントロールできるもので、私が最も気を配る部分です。eeselでは、すべてのアクションをエージェントごとに自動、承認が必要、無効のいずれかに設定します。オンにしていないアクションは「何を頼まれても、モデルにはまったく利用できません」(eeselのセキュリティドキュメント)。アクションと承認のドキュメントのガイダンスは、どこでも真似したい設定です。最初は返信と元に戻せないものすべてを承認の対象にし、「返金、キャンセル、お金がかかるすべてのものは承認の後ろ」に置いておきます。

最も恐ろしい統合のバグは、間違った回答ではありません。正しく見える回答が、別の顧客のデータに基づいていることです。

「私が見た最大の失敗は、セッショントークンがAPI呼び出しに正しく渡されていなかったせいで、別のユーザーのアカウントからデータを取得し続けていたエージェントでした。テキストの回答は完璧に見えたので、顧客が他人の残高を見たと苦情を言うまで誰も気づきませんでした」

u/properwomanhood_292, r/AI_Agents, Reddit

Salesforceも、Agentforceのセキュリティガイドで同じリスクを指摘しています。サービスエージェントがアクションを呼び出すとき「エージェントのアイデンティティが使われる」ため、そのデータがどの顧客のものかは、自社のコードで確認する必要があります(Salesforceのドキュメント)。どのプラットフォームでも、注文とアカウントのデータはチケット上のアイデンティティで照会し、名前の似た2人の顧客でテストしてください。規制対象のデータを扱う場合は、サポートAIにおけるSOC 2とGDPRについても調べておきましょう。

ステップ6:何がエージェントを起動させるかを決める

読み取りと実行ができるようになったら、エージェントには動き出す理由が必要です。トリガーには3種類あり、ほとんどのスタックはすべてを使います。

ヘルプデスクのイベント。 新規チケット、顧客の返信、内部メモでの@メンション。ヘルプデスク統合から届きます。配信のルールに注意してください。GorgiasのHTTP統合は5秒でタイムアウトし、429や500は再試行せず、500回連続で失敗すると無効になります(GorgiasのHTTP統合)。詳しくはGorgiasのwebhookのガイドをご覧ください。HubSpotのWebhookも5秒、Zendeskのカスタムアクションは10秒でタイムアウトします。処理の遅いAIバックエンドは、まず受信を確認して応答し、作業はその後に行う必要があります。そうしないとイベントが失われます。自作する場合は、Zendeskのwebhookの詳しいガイドがあります。

チャットでのメンション。 承認や社内の質問が届きやすいのはSlackで、eeselのSlack統合は、チャンネルに参加する前に確認します。自前のボットを作る場合に知っておくべき制限があります。2025年5月29日以降、Slack Marketplaceにない、商用配布の新しいアプリは、conversations.historyとconversations.repliesで「1分あたり1リクエスト」「1リクエストあたり最大15オブジェクト」になります(Slackの変更履歴)。社内向けのカスタムアプリは、引き続き1分あたり50件以上です。Slackが挙げた理由は、大量のデータ流出の防止だったので、Slackの履歴全体をAIにコピーするような設計は避けてください。

自社システムからのWebhook。 忘れられがちなトリガーです。倉庫の遅延、決済の失敗、新規サインアップが、データ付きでエージェントを起動できます。eeselでは、WebhookオートメーションがプライベートURLを発行し、あらゆるシステム(Zapier、Make、自社バックエンド)がJSONをPOSTできます。X-Eesel-Event-Idヘッダーを送れば、再試行はちょうど1回だけ処理されます。ワークスペースは1分あたり60件の配信を受け付け、指示によってフィルターされた配信は課金されません。

ドキュメントの例では、出荷遅延のペイロードが届き、エージェントが対応するShopifyの注文を探し、見つからないため、タグ付きのGorgiasチケットをチームのために作成します。1回の実行で3つのシステムにまたがり、人間がタブ間でデータをコピーする必要はありません。

ステップ7:本番稼働の前に、自社の過去のチケットでテストする

AIエージェントの統合テストは、「APIが200を返すか」ではありません。「今アクセスできるデータを使って、チームが出したはずの回答をエージェントが出せるか」です。最良のテストデータは、先月の解決済みチケットです。完全な方法はここでは繰り返しません。AIサポートエージェントの選び方の記事がまるごと扱っているからです。ただし、統合に固有の確認が3つあります。

• 各システムを必要とするチケットをサンプリングする。 チケットの30%が注文ステータスなら、テストセットの30%もそうすべきです。そうしないと、ヘルプセンターしかテストしていないことになります。
• 言葉だけでなく、アクションを検証する。 エージェントがどの照会と書き込みを試み、どのレコードに対して行ったかを確認します。誤った注文に基づく完璧な返信は、失敗です。
• トピックごとにギャップを採点する。 eeselでは、シミュレーションスキルが解決済みチケットを再生し、各回答をチームが実際に送ったものと比較します。ドキュメントの実行例では、20件のチケットをサンプリングして17件が一致し、残りには優先順位付きの修正リストが出ました(ヘルプデスクのドキュメント)。外れたものは、たいてい足りない統合を直接指し示しています。

ステップ8:1つのレイヤーずつ展開する

接続したのと同じ順序で有効にし、前のレイヤーがしばらく問題なく動いてから、アクセスを広げてください。

1. ナレッジ、読み取り専用。 社内で質問します。顧客には何も見えません。
2. ヘルプデスク、内部メモとしての下書き。 担当者が読み、編集して送信します。
3. 注文とアカウントの照会。 下書きに、実際の注文ステータスと配送追跡が入ります。
4. 承認付きの返金と変更。 エージェントがアクションを準備し、人間が承認をクリックします。eeselでは、承認はダッシュボード、Slackのスレッド、またはターミナルのeesel approvalsで行えます。
5. 実績のあるトピックでの自動化。 下書きが数週間そのまま送信されているチケットタイプに限ります。

これは、経験豊富な運用担当者が勧めていることと一致します。

「私が見た中で最も安全な展開は、エージェントに下書きさせ、確信度と理由をタグ付けし、返金やアカウント変更には承認を必須にして、最初の1か月は再オープンされた会話をすべてレビューすることです。そのレビューログに、自動化の本当の境界がたいてい表れます。」

u/Calm-Dimension3422, r/CustomerSuccess, Reddit

引き継ぎも同時に計画してください。エージェントがチケットを人間に渡すときは、生の会話記録ではなく、すでに照会した内容の要約を渡すべきです。AIエージェントの引き継ぎガイドにそのパターンがあり、自動化ガイドでは、どのチケットタイプから自動化すべきかを説明しています。

MCP、API、CLIの位置づけ

今は「MCPを使えばいい」とよく言われるので、わかりやすく整理します。MCP(Model Context Protocol)は「AIアプリケーションを外部システムに接続するためのオープンソースの標準」です(modelcontextprotocol.io)。MCPサーバーは、ツール(AIが呼び出せるアクション)とリソース(読めるデータ)を標準的な形で公開するので、MCP対応のクライアントならどれでも使えます。「読む」と「実行する」のレイヤーをつなぐすっきりした方法ですが、上で述べた権限の検討の代わりにはなりません。最新の仕様には「認可はMCP実装において任意である」とまで書かれているため(MCP認可仕様)、接続する各サーバーがどう扱っているかを確認してください。

ベンダーはここで急速に動いています。AtlassianのRovo MCPサーバーはJira、Confluenceなどをカバーし、OAuth 2.1を使い、ユーザーの既存の権限を尊重します(Atlassianのドキュメント)。Shopifyは、ストアフロントのカートとカタログのMCPツールを、新しいUniversal Commerce Protocolのエンドポイントにすでに移行しました(Shopify Storefront MCP)。エンドポイントは今後も変わり続けると考え、1つずつ手で配線するより、それを保守してくれるプラットフォームを選んでください。カスタマーサポート向けMCPには、より詳しい解説があります。

MCPは逆方向にも使えます。サポートエージェント自体が、ほかのAIツールが話しかけるMCPサーバーになることができます。eeselはそのように動いており、eesel CLIが存在する理由でもあります。

ターミナルから統合全体をセットアップする

eesel CLIは、同じAIチームメイトをターミナルに持ち込みます。別の製品でもコピーでもありません。「CLIで設定したものはダッシュボードにも表示され、逆も同様です。」これは統合作業では重要です。この記事のセットアップを、レビューでき、再実行でき、コーディングエージェントに渡せるスクリプトにできるからです。ヘルプデスクとストアのセットアップは、次のようになります。

npx @eesel/cli login                       # or: npm install -g @eesel/cli
eesel integrations connect zendesk         # prints an approval link for a Zendesk admin
eesel integrations connect shopify         # a store owner approves the app install
eesel integrations download start          # copy past tickets, macros and pages into knowledge
eesel integrations zendesk actions         # every action, with its auto / ask / off setting
eesel integrations api check               # custom API access for your own systems
eesel automations                          # what wakes the agent, and the instructions it follows
eesel approvals                            # held actions waiting on a human
eesel activity                             # what the agent actually did, newest first

自動化に向いている細部がいくつかあります。すべてのコマンドがJSONを出力します。エラーは、代わりに何を実行すべきかを示すhint付きの1行のJSONで返るため、Claude Code、Cursor、Codexが人間にドキュメントを読ませずにセットアップを実行できます。CLIからの書き込みはダッシュボードと同じ承認設定に従い、--dry-runは書き込みが行う呼び出しを送信せずにそのまま表示し、EESEL_API_TOKENとEESEL_AGENT_IDでCIでも実行できます。省略できない唯一のステップは、各ツール内での人間による承認で、それが正しい姿です。Zendeskの管理者は、今も自分で「許可」をクリックする必要があります。

MCPクライアント向けには、eesel mcp tokenがそのまま貼り付けられるclaude mcp addの行を出力します。トークンの有効期間は30日で、ワークスペースでのあなたのロールを引き継ぐため、閲覧者はチャットとアクティビティの閲覧ができ、指示やオートメーションを変更できるのは編集者だけです(MCPクライアントのドキュメント)。同僚による、CLIからのエージェント操作や、AIエージェントのMCPサーバー全般についての解説もあります。

避けたい失敗

• 自分の管理者ログインで接続する。 エージェントは、あなたが見られるものをすべて引き継ぎます。専用の狭いアイデンティティでOAuthを使ってください。
• Wiki全体を接続する。 顧客の前で自信を持って示せるスペースとフォルダーを選びます。古い下書きは、自信満々の誤答になります。
• 初日から書き込みを有効にする。 まず照会、書き込みは承認付き、自動化は最後です。
• 同期がライブだと思い込む。 各ソースがどう更新されるか、失敗にどう気づくかを確認します。
• 共有のレート制限を忘れる。 AI、CRMの同期、レポートツールは、すべて同じヘルプデスクのAPI枠から消費します。
• エージェントに、実行できないアクションを説明させる。 注文をキャンセルできないなら、指示にそう書いておきます。
• 統合に罰則を課す料金。 注文の照会、CRMの確認、ツール呼び出しが追加の利用としてカウントされるか確認してください。メッセージやアクションごとにカウントするメーターもあります。

すでにあるスタックに、eeselをつなぐ

このリストに取り組んでいて、コネクターを1つずつ手作りしたくないなら、eeselのAIヘルプデスクチームメイトはそのために設計されています。既存のヘルプデスク(Zendesk、Freshdesk、Gorgias、HubSpot、Salesforceなど)に参加し、過去のチケットから学び、Confluence、Notion、Google Driveを読み、Shopifyで実際の注文を調べ、許可リスト経由で自社APIに到達します。すべてのアクションは自動、先に確認、オフのいずれかで、承認はSlack、ダッシュボード、CLIから行えます。Zendeskをお使いなら、Zendesk統合ページに、読み取れるものと実行できることの一覧があります。

料金も、統合の多い作業に向いています。eeselの料金ページでは、チケットは1クレジットで、「やり取りが何往復しても、エージェントがその中で何をしても(注文の照会、ポリシーの確認、別のツールの更新)」同じです。プランは月額299ドル(500クレジット)から、すべての統合が含まれ、無料プランでは100クレジットを使って、支払う前にヘルプデスクを接続し、実際の下書きを確認できます。

自社のスタックでeeselを試すか、私や同僚と一緒にセットアップを見ていきたい場合は、デモを予約してください。