サービス間AIエージェント: サポートチームのための実践ガイド

サービス間AIエージェントとは実際には何か

バズワードを取り除けば、この考え方自体は古くからあります。「サービス間(service to service)」とは、単に一つのソフトウェアが人間を介さずネットワーク越しに別のソフトウェアを呼び出すことを意味し、すでに決済Webhookや請求同期を動かしているのと同じサーバー間、マシン対マシンのパターンです。S2S AIエージェントとは、このパターンにAIエージェントが参加者の一人として加わったものです。

つまり定義づける特徴はインターフェースであり、知性ではありません。チャットボットにはUIがあり、その反対側には人間がいます。サービス間エージェントにはAPI契約があり、その反対側には別のサービスがいます。内部の推論は一言一句同じであってもかまいません。変わるのは、誰が、あるいは何が、話しかけているかです。

実際には、このループは上の図のように動きます。サービスイベントが発火します、通常はWebhookです。チケットが作成される、注文ステータスが変わる、Slackメッセージが届く、などです。エージェントは画面もセッションもなく起動します。必要なAPIを呼び出します、注文システム、CRM、配送業者など、コンテキストを集めアクションを実行するためです。そして構造化された結果を返します。返信の下書き、タグ、ステータス変更、別サービスが消費するペイロードなどです。

この「構造化された結果を返す」というステップはじっくり考える価値があります。人間のエージェントがチケットを終えるとき、出力は人が読む文章です。サービス間エージェントが終えるとき、出力はしばしば別のプログラムが処理するデータであり、チャットメッセージのようにではなく、APIレスポンスのように整形・検証される必要があります。これがチームをつまずかせる転換点です。もはやより良い答えを作っているのではなく、たまたま言語モデルによって動かされている、信頼できる関数呼び出しを作っているのです。

このパターンをより深く知りたい場合は、いくつかの角度から書いています。カスタマーサポートエージェントAPIの視点(構築ルート)、AIヘルプデスクAPIの視点(APIが果たす2つの役割)、そしてヘッドレスAIカスタマーサポートの視点(ダッシュボードなしでサポートを運用する)です。この記事は、エージェントをアーキテクチャの中のサービスとして扱うことについてのものです。

サービス間がチャットボットとは異なる問題である理由

チャットに人間がいるとき、多くの罪は許されます。ボットが止まれば、人は待ちます。答えが少しずれていれば、人は言い換えます。ログインが必要なら、人がログインします。人間はあらゆるやり取りの内側に座る、生きたエラーハンドラーなのです。

人間を取り除くと、そのすべてがあなたの仕事になります。呼び出しを再試行する人もいなければ、タイムアウトに気づく人もいない、エージェントが間違ったアカウントを使ったことに気づく人もいません。エージェントは今や他のコンポーネントが依存するコンポーネントとなり、そのように振る舞わなければなりません。予測可能なインターフェース、定義された障害モード、それ自身の認証情報です。

そして、ここにこそ本当の価値が現れます。それは誇大宣伝の中で見失いやすいものです。あるHacker Newsのコメント投稿者は、エージェントをツールに接続することについてのスレッドでこう述べました。

"The 'system integration' benefits only matter when you have an LLM in the loop making decisions about which tools to use."

belter, Hacker News

これが正直な捉え方です。もしあなたの自動化が判断を伴わない固定的なAPI呼び出しの連続であれば、エージェントは必要ありません。必要なのはスクリプトであり、単純なスクリプトの方がよりシンプルで信頼できます。エージェントがその存在価値を発揮するのは、まさに次の呼び出しが雑然とした入力についての推論に依存する場合です。苛立った顧客のメッセージを読む、返金なのか保証の案件なのかを判断する、5つの社内システムのうちどれに問い合わせるかを選ぶ、といった場合です。サービス間ラッパーがその複雑さに見合うのは、その途中に本物の意思決定がある場合だけです。

落とし穴: 決定的なメッシュの中の非決定的なサービス

これは、最初のエージェントをサービスメッシュに組み込む前に誰かに教えてほしかったことです。アーキテクチャの中の他のすべてのサービスは決定的です。同じリクエストが入れば、毎回同じレスポンスが出ます。キャッシュもできるし、リプレイもできるし、完全一致のテストも書けます。AIエージェントは、その契約を破る唯一の存在です。

決済サービスに同じリクエストを3回送れば、3回とも同じ答えが返ってきます。エージェントに同じリクエストを3回送ると、回答A、回答B、回答Cが返ってくることがあります。これはパッチで直せるバグではなく、モデルの本質です。そしてこれは通常の直感を逆転させます。エージェントは周囲のサービスよりも予測不能であるがゆえに、通常なら不安定な外部依存のために取っておくガードレールがより多く必要なのであって、より少なくて済むわけではないのです。

具体的に言えば、呼び出しが成功したというだけでエージェントの出力を信頼できるものとして扱うことはできません。通常のサービスからの200 OKは、答えが正しいことを意味します。エージェントからの200 OKは、それが何らかの答えを生成したことを意味するだけです。その答えが正しいかどうかは別の問題であり、出力が下流に流れる前に検証、ガードレール、テストで答える必要があります。私たちは、自信ありげに聞こえるエージェントが実際のキューで誤った答えを出すのを見てきました。だからこそ今では、すべてのロールアウトをまず過去のチケットに対してシミュレーションしています。詳しくは後述します。

あなたが実際に負うサービス間契約

エージェントがサービスであると受け入れれば、チェックリストは自ずと書けます。それは本番のあらゆるサービスに適用するのと同じチェックリストに、エージェント特有の項目が1つ加わったものです。これは地味な作業であり、その地味な作業こそが、デモと一晩中動かし続けられるものとを分けるのです。

サービスIDとトークン。 エージェントは人間のログインを借用するのではなく、スコープを絞ったAPIトークンやサービスアカウントで自分自身として認証します。これは認証スコープと、帰属の両方にとって重要です。エージェントがチケットを更新したとき、監査ログにはエージェントがそれを行ったと記録されるべきです。この分野全体でよくあるギャップは、エージェントが行う接続における認証です。

"Most providers don't support auth in their client implementations yet. Means it's only good for calling into public data. Private enterprise data is where there's huge value."

danjc, Hacker News

サポート自動化における価値のほとんどは、注文、アカウント、チケット履歴といったプライベートなデータの中にあります。だからこそ、サービス認証を正しく行うことは「あれば良い」ものではありません。

冪等性とリトライ。 リトライは必ず発生するので(ネットワークは失敗するものです)、エージェントのアクションには冪等キーが必要です。再試行された「この返金を送る」が二重に返金を送らないようにするためです。これは決済レベルの標準的な規律であり、エージェントが現実世界のアクションを起こせるようになった瞬間から適用されます。

タイムアウトとフォールバック。 モデル呼び出しは遅く、時折ハングします。すべてのS2Sエージェント呼び出しには、タイムアウトと定義されたフォールバックが必要です。人間へのルーティング、後回しのキューイング、安全なデフォルト値の返却などです。他のサービスが待っているときに、沈黙は許容できる応答ではありません。

完全な監査証跡。 すべての実行、すべてのツール呼び出し、すべての判断が記録され、再生可能であること。深夜2時に何かがうまくいかなくなったとき、推測するのではなく、エージェントが何を見て何をしたのかを正確に確認する必要があります。

人間の承認ゲート。 エージェント特有の項目です。返金の発行、アカウントの停止、取り消せないことの送信といったリスクの高いアクションについては、完全自律的な送信ではなく、エージェントがそこで一時停止するヒューマン・イン・ザ・ループのチェックポイントが必要です。全体の考え方を最もよく言い表したのは、別の実務者の言葉でした。

"MCP is just a small, boring protocol that lets agents call tools in a standard way, nothing more... Teams that already handle HTTP APIs safely can apply the same basics here: auth, logging, and isolation."

fxj, Hacker News

それがすべてです。すでにサービスを責任を持って運用しているなら、エージェントを責任を持って運用する方法はすでに知っています。あとはそれを実際に実行することを忘れないだけです。なぜならデモはそれらなしでも問題なく動いてしまうからで、それこそが罠なのです。

カスタマーサポートにおけるサービス間はどのようなものか

サポートはこのパターンに最も適した領域の一つです。なぜならサポートチケットはすでにイベントであり、それが触れるシステムはすでにAPIを持っているからです。具体的なフローを見てみましょう。

顧客が「注文はどこですか?」というメールを送ります。ヘルプデスクがWebhookを発火させます。エージェントが起動し、メッセージを読み、注文ステータスが必要だと判断します。コマースプラットフォームのAPIを呼び出して注文を調べ、配送業者のAPIを呼び出して追跡状況を調べ、CRMの顧客レコードで何か関連する情報(VIP、未解決のクレームなど)がないか確認し、それから人間が承認するための返信案を作成するか、許可されていればそのまま回答を送信しチケットを解決済みとタグ付けします。ダッシュボードは一度も開かれていません。すべてのステップは、あるサービスが別のサービスと話す形で行われました。

これは、人間のエージェントが1日に何百回も行っているのと同じWISMO(「注文はどこ」)フローが、マシン対マシンの呼び出しとして表現されたものにすぎません。ほとんどのサポートチームが使うツール、Gorgias、Front、Freshdeskは、いずれもこれを可能にするWebhookとAPIを公開しており、その上に独自のエージェント向けサーフェスをますます提供するようになっています。

ここでS2Sという枠組みを気にする理由は、それがテストする内容を変えるからです。チャットボットは回答品質で評価します。サービス間エージェントは、契約の面でも評価する必要があります。きれいにリトライするか、正しくタイムアウトするか、すべてのアクションをログに記録するか、取り消せないことをする前に止まるか、といった点です。回答だけをテストしているなら、システムの半分しかテストしていません。

自分で構築するか、すでにサービス間を話せるチームメイトを雇うか

正直な選択肢は2つあります。

配線を自分で構築することができます。キューを立て、Webhookを配線し、エージェントが触れる各システムの統合コードを書き、認証、リトライ、冪等性、監査ログ、評価ハーネスを扱います。それらはすべてよく踏み固められたエンジニアリングであり、奇抜なものは何もなく、完全なコントロールを求めるチームにとっては妥当な道です。カスタマーサポートエージェントAPIとコマンドラインからエージェントを運用することについての私たちのガイドが、その構築ルートを説明しています。

あるいは、すでにサービス間のサーフェスを提供しているエージェントを雇い、それを組み立てるのではなく、そこに接続することもできます。それがeeselのアプローチであり、この記事に直接関係するので、売り込みではなく具体的なサーフェスを紹介します。

eeselのAIエージェントは最初から最後までプログラム可能です。各ワークスペースはそれ自体がModel Context Protocolサーバーです。npx @eesel/cli mcp tokenを実行すれば、任意のMCPクライアントに渡せるURLとトークンが得られます。Webhookをリッスンしているので、あなたのどのサービスからでもHTTP呼び出しで起動できます。そしてNetwork Accessを通じて、許可した任意のREST APIを呼び出すことができ、認証情報はモデル自体が決して目にしないリクエストヘッダーとして保存されます。これはまさに、上記の契約におけるサービスIDと認証の規律を、あなたの代わりに処理しているということです。

この仕組み全体はターミナルからも操作できます。CLIはCI向けに環境変数でヘッドレス認証を行い、すべてのコマンドでJSONを出力し、書き込みが実際に行うサーバー呼び出しを送信せずに正確に表示する--dry-runフラグを備えています。これによりパイプラインに組み込み、コードとして管理できます。この日常運用の視点をさらに知りたい場合は、ターミナルからAIエージェントを管理するで別途まとめています。

eeselを試す

サービス間スタックを自分で組み立てるべきか、すでに存在するものから始めるべきか迷っているなら、最も早く確かめる方法は、自分のチケットにeeselを向けて実際に動く様子を見ることです。何かが本番稼働する前に、シミュレーションモードがエージェントを実際の過去のチケット数千件に対して再生し、デモを信じるのではなく、実際のデータに対してエージェントが取ったであろう回答とアクションを確認できます。それが「非決定的なサービスをテストする」ことの正直なやり方です。実際のケースで動かし、それが何をするかを読むのです。

それぞれの実行はその後、ダッシュボードまたはCLIから読めるアクティビティログに記録されます。これが契約が求める監査証跡です。料金は1チケットあたり0.40ドルの従量課金で、開始時には50ドルの無料枠があり、シート課金なし、Enterprise未満はプラットフォーム料金なしです。これは、シートではなくサービスが仕事をしているときに実際に理にかなう課金形態です。クレジットカードも営業電話も不要で無料で始められ、自分のデータに対して数分で動作する様子を確認できます。