Decagonが実際に発表したもの
Decagonは、Dialogues 2026イベントでこのゲートウェイを4つの発表のひとつとして公開しました。ほかはDecagon Voice 3、Agent Modules、Duet Apprenticeです。
共同創業者のJesse ZhangとAshwin Sreenivasが書いた発表記事は、その理由から始まります。わずか1か月の間に、MetaがMuseを発表し、OpenAIがdotsを発表し、Instinctがユーザーの代わりに電話をかけ始めました。
これらは個人用エージェントです。企業ではなく消費者のために働き、持ち主の代わりに「予約し、購入し、キャンセルし、交渉」します。サポートのキューに届くと、たいていはブランド自身のカスタマーサービス向けAIエージェントにつながります。つまり、会話の両端にエージェントがいる状態です。しかも、すでに実際の電話回線で起きています。
"This week, Muse called customer service on my behalf. It navigated the phone tree, waited on hold, spoke with a human rep, and resolved the issue (worked great!)."
ゲートウェイは、2つの機能と1つのプロトコルでできています。
| 要素 | 役割 | 対象 |
|---|---|---|
| 個人用エージェントの検知 | ライブチャットと音声で個人用エージェントの可能性が高いものにフラグを立てる | エージェントだと名乗らないエージェント |
| 個人用エージェントチャネル | チャット、メール、音声と並ぶ専用チャネル。独自のAgent Operating Procedures（AOP）を持つ | 自ら名乗るエージェント |
| PACT（Personal Agent Consent & Trust） | エージェントが誰を代理し、その人が何を許可したかを証明するプロトコル | 個人用エージェントのプロバイダーと企業 |
私はeeselで仕事として連携機能を作っていますが、最初の印象は、これは検知の衣をまとった認可の製品だということでした。これは褒め言葉です。検知は見出しを飾りますが、実際に出荷するのはスコープです。
個人用エージェントがサポートポリシーを壊す理由
Decagonの記事で私が何度も戻ってくる一節があります。返金を断られた人は「might ask once more and let it go」。個人用エージェントは「might ask for a refund once, or keep trying different approaches to maximize the concession」。
これが問題のすべてです。返金や例外のポリシーの多くは、人間の忍耐に静かに頼っています。例外を通すのに4回かかる顧客は、たいてい2回でやめます。エージェントは疲れず、気まずさも感じず、ほかに行く場所もありません。Xで最も共有された見方は、経済性をはっきり言い切っています。
"AI agents reduce the cost of complaints/requests to ~ zero. Anything free is consumed at much higher rates, so we should expect the total volume of this category to explode."
私が関わるeeselのキューでも、反対側から同じパターンが見えます。あるeeselのサポート管理者は、eeselのZendeskエージェントにルールをひとつ教えるのにセッションを丸ごと使い、私よりうまく言い表しました。
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
A digital-media support admin encoding a "troubleshoot before you cancel" policy into a Zendesk AI agent
このルールが人間に通用するのは、人間がトラブルシューティングを受け入れるからです。「返金を取ってこい」と指示された個人用エージェントは、それを迂回しようとします。AIサポートエージェントが5回目の依頼でルールを曲げてしまうなら、そもそもそのルールは持っていなかったのと同じです。だから返金リクエスト向けAIは、断り方の丁寧さではなく、エージェントが何をしてよいかで決まります。
Decagonは第2の問題も挙げています。権限です。「Permission to check a balance doesn't necessarily mean permission to move money.」今日、誰かのエージェントが正しいアカウント情報で連絡してきても、顧客が実際に何を承認したのかを判別できるサポートスタックはほとんどありません。
Personal Agent Gatewayの仕組み
Decagonは、企業が正しく行うべき4つの要素、識別、アクセス、認可、解決を軸に設計を説明しています。それぞれが製品にどう対応するかを見ていきます。
識別：検知と自己申告
現在のエージェントの多くは、ほかの誰とも同じように電話をかけたりチャットを開いたりします。Decagonによると、検知は企業側のシグナル（デバイスのフィンガープリントやアカウント履歴）と、サポートプラットフォーム側のシグナル（会話パターンやリクエストの頻度）を組み合わせます。フラグ付けはライブチャットと音声で働きます。その後どうするかは企業の判断です。
注目したいニュアンスがあります。Decagonは検知を主要な関門としては売り込んでいません。検知は「works best alongside an easy way for agents to identify themselves upfront」と述べており、名乗らないものだけを捕まえればよい設計です。検知は保険で、計画の中心はチャネルです。私の見方では、チェックアウトがエージェント型コマースプロトコルへ向かったのと同じ論理です。エージェント向けの正面玄関のほうが、誰がボットかを推測するよりスケールします。
アクセス：エージェント専用チャネル
自ら名乗るエージェントは、個人用エージェントチャネルに入ります。チャット、メール、音声と並ぶチャネルで、AOPは別になっています。AOPはDecagonのAIエージェント向けワークフローで、Decagonレビューでより詳しく取り上げました。
実際には、依頼者が誰かによって、同じリクエストが別のロジックをたどれるということです。人からの返金依頼はひとつの経路、エージェントからのものは別の経路にできます。機微の低いリクエストは追加設定なしで既存のワークフローを再利用でき、これは重要です。すべてのポリシーを2部ずつ保守したい人はいないからです。Decagonのもうひとつの点は見落とされがちです。すべてのエージェントプロバイダーに対して1つのチャネルなので、Muse用、dots用、Instinct用と別々に連携を作らなくて済みます。
認可：AOP内のスコープ
ここは2回読む価値があります。DecagonはAOPの中に権限を置きます。企業はエージェントが要求できるスコープを定義し、どのセクションがどのスコープを必要とするかを示します。スコープがなければ「those sections are never exposed to the agent」です。GoogleアカウントにアプリをつなぐときにおなじみのOAuthモデルを、サポートの会話に当てはめたものです。ZendeskのAPIスコープを設定したことがあれば、形は見慣れているはずです。
Decagon自身の例は航空会社です。
旅行者は閲覧を許可しますが、変更は許可しません。航空会社のエージェントは早い便の候補を共有できますが変更はできないので、個人用エージェントは足りない権限を求めて持ち主のもとに戻ります。Decagonは、この付与が「creates a record of what the customer authorized」であり、企業があとで証明できるとも述べています。争いになった変更を解きほぐした経験のあるサポートリーダーにとって、この監査証跡こそが本当の機能です。
消費者側の不安にも答えています。Redditで、あるMuseユーザーは、保険会社や通信会社がいつも先に個人情報を求めてくるのにどうやって成り立つのかと尋ねていました。
"...for that to all I have to hand those info (social, address, DOB, etc.) directly into Muse memory as plain text without a secure credential layer, or the customer service might just hand off knowing it's an AI calling?"
顧客が付与する範囲限定の権限こそが、このユーザーが求めている「secure credential layer」です。
解決：2つのエージェントのループを止める
「Two agents can loop forever if neither is built to stop.」Decagonの答えは、企業側のエージェントが役に立ちながらもポリシーでは立場を守ることです。エスカレーションは双方向に働きます。企業側のエージェントには人間が必要になることがあり、個人用エージェントには持ち主が必要になることがあります。AIエスカレーションのルールを調整した経験があれば、出口がもうひとつ増えただけの同じ筋肉です。測り方も変わります。封じ込め率とエスカレーションの質には、他人のエージェントにリクエストを返すことも含まれるようになります。
PACTがA2Aに加えるもの
PACTはPersonal Agent Consent & Trustの略です。Decagonによると、エージェント同士が互いを見つけてメッセージをやり取りする方法を扱うAgent2Agentプロトコルの上に「builds on」し、「delegated authorization built on OAuth 2.0」を加えます。平たく言えば、A2Aが2つのエージェントを会話させ、PACTが個人用エージェントに、誰の顧客か、何をしてよいかを証明させます。AIをほかのエージェントではなくツールにつなぐカスタマーサポート向けMCPとは別の役目です。
A2Aの仕様を読むと、この分担に納得がいきます。エージェントは /.well-known/agent-card.json のエージェントカードで自分を公開しますが、A2Aの仕様は認可を各実装に委ねています。消費者から企業へのリクエストでは、この隙間を何かが埋める必要があり、PACTはDecagonによるその提案です。A2A自体には確かな後ろ盾があります。2026年8月27日にAgentic AI FoundationのGrowth Stageプロジェクトとなり、150を超える組織が支えています。
ドキュメントを探しに行く前に、押さえておきたい点が2つあります。
- PACTという名前はすでに2つあります。 Cloudflareは2026年6月に、Mozilla、Google、Microsoft、Shopifyとともに別のPACT、Private Access Control Tokensを発表しました。こちらはウェブ上で人間であることを証明するもので、サポートの同意とは関係ありません。
- 仕様は簡単には見つかりません。 DecagonのDialoguesまとめには「the specification is available today」とありますが、10月6日時点でどちらの発表記事にもリンクはなく、公開されたコピーは見つかりませんでした。そのため、フィールド名、エンドポイント、付与記録の保存方法はお伝えできません。Decagonは「working with personal agent providers」して形を整えているとしています。
この分野にいるのはDecagonだけではありません。9月30日には、Mastercardが発表した、支払いがAIエージェントによって開始された可能性を示すスコアが米国でテスト中です。これは決済層での検知です。同じ発想をサポートの会話そのものに向けたのは、私が見る限りDecagonが最初です。Sierraのような競合は、この記事の執筆時点で同等の発表をしておらず、DecagonとSierraの比較での本当の差別化点になっています。
まだ分かっていないこと
Decagonは設計については明確ですが、購入者が尋ねる細部については口が重いままです。2026年10月6日時点の正直な状況は次のとおりです。
| 質問 | Decagonが公開した内容 |
|---|---|
| 価格 | なし。Decagonの /pricing ページは404で、すべての経路がデモ経由 |
| 提供状況 | GA、ベータ、プランの表記なし。行動喚起は「Talk to our team」 |
| 検知のチャネル | ライブチャットと音声 |
| メール | エージェントチャネルはメールと並ぶが、検知はチャットと音声についてのみ説明されている |
| 仕様 | 利用可能と説明されているが、公開リンクなし |
| 参加済みのエージェントプロバイダー | PACTの採用者として名前が挙がったものはなし。Instinct、Muse、dotsは、すでにサポートに連絡してくるエージェントの例として挙げられている |
| 検知の精度 | 数値なし。Decagonは検知が「will keep improving as personal agents evolve」と述べている |
どれも、エンタープライズベンダーの発表当日の機能としては珍しくなく、Decagonの料金の話も昔から営業主導です。ただし、これは今のところゲートウェイが規模を見積もれる製品ではなく、方向性であることを意味し、より大きなDecagonは価値があるのかという問いに直結します。特に、自ら名乗るエージェント向けのチャネルは、エージェントの作り手がプロトコルを採用して初めて効果を発揮しますが、公に採用すると言った作り手はまだありません。
人々の反応
ゲートウェイ自体への公の反応は今のところ薄く、発表から5日であることを考えれば当然です。一方、これが入り込むより大きな議論は賑やかです。Hacker Newsでは、OpenAI dotsの発表スレッドがまさにこの点をめぐる議論になりました。
"All this outsourcing of human interaction to agents is going to get locked down. Customer service relies on people not overabusing it, and that trust is getting abused by agents."
そして、それでも消費者がエージェントを送り込む理由に迫る返信がこちらです。
"The solution for both sides is for the companies to implement support bots that have more power to address my problem than the humans they replaced were ever given. I have a feeling it's not going to work out that way, though."
ブロックはもうひとつの本能ですが、代償があります。AmazonがMuseを小売サイトから締め出した後、Ryan Sarverはこう述べました。「Nobody asked the person whose agent stopped working」（Ryan Sarver, X）。
これらのコメントを合わせたものが、ゲートウェイの設計要件のすべてです。企業は不正利用を止める必要があり、顧客はエージェントに実際に物事を片づけてほしい。範囲を限定した権限は、双方が何かを得られる唯一の形です。企業側のエージェントがより多くのことに安全に「はい」と言えるなら、顧客のエージェントが粘る理由は減ります。
Decagonの有無にかかわらず、サポートチームが備える方法
これを読んでいるサポートチームの大半はDecagonを使っておらず、2026年度の予算でも使わないでしょう。良いニュースは、ゲートウェイの難しい部分が、どのスタックでもできる権限の整理だということです。InstinctやMeta Museのようなエージェントは、何かを購入したかどうかにかかわらず、人間が使うのと同じメール、チャット、電話の回線からキューに届きます。WhatsAppやMessengerでサポートを行っている場合は、カスタマーサポート向けMeta Museで、Meta自身のビジネスツールができることが分かります。
下からリクエストの種類を選ぶと、私ならどう制限するかが見られます。
要点をチェックリストにまとめると次のとおりです。
- 操作を棚卸しする。 AIカスタマーサービスのワークフローにあるすべての操作を書き出し、読み取り、元に戻せる書き込み、お金が動く操作、アカウント管理のいずれかに分類します。これを書き出したことのあるチームはほとんどありません。
- チャネルではなく区分で制限する。 返金は、人からでも、ボットからでも、電話からでも返金です。まずお金が動く区分に承認を置きます。ZendeskのAI高度なアクションとGorgiasのAIアクションのガイドで、標準で設定できる内容が分かります。
- 繰り返しに耐えるポリシーを書く。 例外ルールを読み、5回目の依頼でも通用するかを自問してください。正直な答えが「誰が頼むかによる」なら、引き締めます。
- エスカレーションに出口を2つ用意する。 AIは人にきれいに引き継ぎ、エージェントに権限がないときは顧客に何が必要かをはっきり伝えるべきです。人間側については人への引き継ぎのベストプラクティスを参照してください。
- 公開前に過去のチケットでテストする。 実際の返金やキャンセルのチケットを再生し、AIがどこで折れるかを確認します。引き下がらないエージェントから教えられるより安上がりです。
4つ目のポイントには、私にとって苦い経験があります。デジタルメディアのお客様で、自律的な下書きの仕組みが自らのエスカレーション経路を壊すのを見たことがあります。エスカレーションのメールが自動でクローズされ、誰も目にしませんでした。何もエスカレーションされず、誰も気づきませんでした。互いに話すエージェント同士は、どんな顧客よりも速くこうした隙間を見つけます。だからeeselの導入は今では必ず、まず過去のチケットでシミュレーションします。
eeselの立ち位置
まず限界を率直にお伝えします。eeselは個人用エージェントを検知せず、Agent2AgentもPACTも実装していません。顧客が付与するスコープを備えたエンタープライズ向けのエージェント間チャネルが今必要なら、それを作っているのはDecagonであり、ほかに近い選択肢はDecagonの代替の比較記事で扱っています。
eeselが担うのは、すでにお使いのヘルプデスクの下にある権限のレイヤーです。AIヘルプデスクチームメイトは、標準のZendesk AIと併用、または代わりに、新人のようにZendesk、Freshdesk、Gorgiasに加わります。タグの追加から返金の実行まで、実行できるすべての操作は、読み取りと書き込みにグループ化され、自動、承認が必要、無効のいずれかに設定されます。詳しくはeeselのアクションのドキュメントをご覧ください。
これはDecagonのスコープが強制するのと同じ読み取りと書き込みの区別を、顧客のAIではなく自社のAIに向けたものです。チケットの向こうにいるのが人でもそのエージェントでも、eeselに注文を自動で調べさせつつ、お金が動く前には人の確認を待たせることができます。「自分で調べていいけど、返金の前には必ず聞いて」といった平易な言葉で設定でき、保留中のアクションはダッシュボード、Slack、または eesel approvals を使うeesel CLIから承認できます。
eeselを試す
個人用エージェントがまもなくキューに返金を求めてくるなら、最初の仕事は、自社のAIに何まで「はい」と言わせるかを決めることです。eeselのAIヘルプデスクチームメイトは、Zendesk、Freshdesk、Gorgiasにつながり、過去のチケットとヘルプセンターから学び、線を守れることを確認できるまで、返金とキャンセルを承認の背後に置きます。顧客に触れる前に、過去のチケットを使ったシミュレーションで実行できます。
無料プランには100クレジットとすべての連携が含まれ、有料プランはeeselの料金ページにあるとおり、500クレジットで月額$299からです。ご自身のキューでeeselを試してみてください。