Zendesk Open Service Directory：仕組み、使い方、現在公開されている内容

Zendesk Open Service Directoryとは？

Open Service Directoryは、新しいタイプのサポートリクエストに対するZendeskの答えです。顧客本人ではなく、顧客の個人向けAIアシスタントから届くリクエストです。Jad Chamoun（Senior Director of Applied AI）とWill Poon（Messaging and AIのDirector of Product Management）によるZendeskのローンチ記事では、「a specification and public directory of verified support destinations」と説明されています。

私は仕事で連携を作っているので、このローンチもAPIの発表と同じ読み方をしました。契約は何か、誰が何をホストするのか、何が提供済みで何が約束にとどまるのか。要点は次のとおりです。

リストにあるアシスタントに馴染みがなければ、OpenAI Dots、Instinct AI、Grok Botを個別に書いています。OSDは、ヘルプデスクのベンダーがそれらすべてに共通の入口を用意しようとした最初の試みです。

AIアシスタントがサポートを見つけるのに、なぜディレクトリが必要なのか？

現状では推測しているからです。Zendesk自身が挙げる例は、顧客がアシスタントに「Can you move my air conditioner repair appointment to Monday?」と頼む場面です。アシスタントは企業のヘルプ記事までは見つけられますが、予約を動かすには企業の本物のサポートにたどり着く必要があります。しかも、見つけた「サポート」がそのブランドのもので、偽物でないことを確かめる共通の信頼できる方法がありません。

これは遠い将来の問題ではありません。すでにアシスタントが実際の購入者を誘導する例を見ています。あるリード顧客は営業の通話で、前夜に友人から勧められたことに加えて、AIアシスタントが直接勧めたからeeselを知ったと話しました。アシスタントがすでに購入者に代わってベンダーを選んでいるなら、顧客に代わってサポート窓口も選ぶようになります。そこで選択を誤れば、顧客が注文情報を偽のヘルプデスクに渡すことになります。

得るものが生まれたときにどうなるかについて、懐疑派の指摘はもっともです。OSDの土台であるGoogleのARD仕様がHacker Newsに載ったとき、最上位のコメントは次のように述べました。

"This seems useful as a standard interface, but, again, doesn't solve the harder discovery problem. Once there is value in appearing in the top results, the system inherits the same adversarial dynamics as SEO/app stores, spam, scams, etc."

wslh, Hacker News

これに対するOSDの答えが次のセクションの承認ルールで、仕様全体で最も重要な設計判断だと私は考えています。

Open Service Directoryの仕組み

Zendeskは3つのステップで説明しています。承認済みサポートを掲載し、適切な事業者を見つけ、公式サポートに接続する。OSD開発者向けドキュメントが仕組みを詳しく説明しており、驚くほど小さくまとまっています。

ステップ1：ブランドが自社ドメインに掲載情報を公開する

ブランドは、アシスタントに見つけてほしい各サポートエージェントを、https://{brand-domain}/.well-known/ard.json のJSONマニフェストに記述します。各エントリは通常のARDエントリ（識別子、表示名、説明、サンプルクエリ、エージェントのMCP Server CardまたはA2A Agent Cardへのリンク）に、OSD固有の2つのフィールド osd:brandName と osd:brandDomain を加えたものです。架空の航空会社を使ったOSDとARDのページの例を簡略化して示します。

{
  "identifier": "urn:air:airline.example:support:assistant",
  "displayName": "Example Air Support",
  "description": "Support for cancelled flights and rebooking.",
  "type": "application/mcp-server-card+json",
  "url": "https://support.airline.example/server-card.json",
  "osd:brandName": "Example Air",
  "osd:brandDomain": "airline.example"
}

エージェント自体はどこにあってもかまいません。Zendeskや他のプラットフォームのサーバー上でも構いません。重要なのは、承認がブランド自身のドメインから提供されることです。ブランドはファイルを自分で管理することも、サポートプラットフォームに管理を任せることもできます。

ステップ2：アシスタントが候補を見つける

アシスタントがブランドのドメインをすでに知っている場合（たとえば航空券の旅程から）、マニフェストを直接読みます。ブランド名や問題しか知らない場合は、ARDの POST /search を使ってOSDレジストリを検索し、関連度スコア付きの完全なエントリを受け取ります。ドキュメントは、このスコアは「measures query match, not trust」だと念を押しています。

ステップ3：アシスタントが承認を確認して接続する

スパムへの懸念に答えるのがこのステップです。レジストリの結果はあくまで候補です。完全なエントリが、ブランド自身のマニフェストに公開されたものと一致した場合にのみ、承認済みとみなされます。

したがって、詐欺師が偽の掲載情報をレジストリに入れることはできても、航空会社のドメインを管理していなければ airline.example/.well-known/ard.json に入れることはできません。これはウェブがすでにTLS証明書で使っているのと同じ信頼の拠り所で、妥当な選択です。ドキュメントはさらに率直な注意点を加えています。osd:brandDomain は主張にすぎず、そのドメインが顧客の意図した事業者のものかどうかを判断するのは、依然としてアシスタントの役目です。

一致が確認されたら、アシスタントはエージェントのカードを読み、そのネイティブプロトコル（通常はMCPまたはA2A）で接続します。カスタマーサポート向けMCPや、優れたAIエージェントMCPサーバーの条件を追ってきた方なら、これらのサーバーがつながるのはここです。

OSDの終わりとサポートエージェントの始まり

ローンチ記事を読むサポートリーダーに、私が下線を引いておきたいのがこの部分です。Zendeskははっきり述べています。「The directory does not access private customer data or carry out support actions.」ドキュメントはさらに踏み込み、OSDは「defines discovery and endorsement only」としています。

ハンドシェイクの後はすべて別のレイヤーの領分です。Zendeskは、その部分のために採用を予定している3つのプロトコルを挙げています。

• Personal Agent Protocol（PAP）（Sierra提供）は、サインイン不要の「search rooms」からユーザーの承認が要る「book a room」まで、エージェントに何を許すかを企業がどう決めるかを扱います。私のPersonal Agent Protocolの記事で取り上げました。
• PACT（Personal Agent Consent and Trust、Decagon提供）は、A2AとOAuthの上に構築され、企業がどのエージェントが呼び出していて、顧客が何を許可したかを検証できるようにします。Decagonのパーソナルエージェントゲートウェイと組み合わせて使われます。
• UCP（Universal Commerce Protocol）は、探索からチェックアウトまでのエージェント型コマースの共通言語で、agentic commerce protocolの取り組みと同じ系統です。

プロトコルという考え方そのものに納得していない人もいます。PAPのローンチスレッドでは、あるコメント投稿者が反論しました。

"As a human directing my personal agent, why does it need a protocol? It has that with the websites and APIs businesses expose."

dividedcomet, Hacker News

多くのヘルプデスクAPIをつないできた者としての私の見方はこうです。ウェブサイトとAPIという経路は、操作がアカウント、お金、本人確認に関わるまでは機能します。そこからは、誰が誰の代理で動いているかを証明する方法が両者に必要です。これらのプロトコルが狙うのはまさにその部分で、OSDはその前に来る単なる検索です。

全体を重ねるとスタックはこうなり、あなたが良くすべきなのは1つのレイヤーだけです。

現時点で実際に公開されているのは？

見出しが示唆するより少ないですが、仕様の発表としては普通のことです。2026年10月14日に私が確認できた内容は次のとおりです。

これは批判ではありません。ブランドは「to help shape the Directory」ために参加すると説明されており、まず正しく作るべき難所は承認モデルです。ただ、サポートリーダーとして今週何かしなければならないのかと考えているなら、正直な答えはノーです。数か月の猶予があります。

ドキュメントには、探索、検証、MCPコマンドの直接実行のためのOSD CLIも出てきますが、「intended for internal developer workflows only」とされているため、今はそれを前提に計画しないほうがよいでしょう。

Open Service Directoryはあなたにとって何を意味するか？

接続のどちら側にいるかで、答えは大きく変わります。自分の立場を選んでください。

Zendeskのサポートチームにとっての意味

サポートをZendeskで運用しているなら、ディレクトリ自体は簡単な部分です。それが突きつける問いは別にあります。顧客のアシスタントがあなたのサポートに接続したとき、実際に何に到達するのか？

費用はディレクトリではなくエージェントにかかる

ディレクトリは無料です。その先のエージェントは無料ではありません。アシスタントからのリクエストをZendesk自身のAIエージェントが処理するなら、他の会話と同じように課金されます。Zendeskの料金ページによると、Suite Teamはエージェント1人あたり月55ドル、Suite Professionalは115ドル（年払い）で、それぞれ少量の自動解決が含まれ（Suite Teamはエージェント1人あたり月5件、Suite Professionalは10件）、追加の自動解決は1件ごとにコミット契約で1.50ドル、従量課金で2.00ドルです。詳しくは、私のZendesk AI料金と自動解決の解説をご覧ください。

たとえば、アシスタント経由のリクエストが月1,000件あり、すべてが含まれる枠を超えてZendesk AIエージェントで解決されるなら、シート費用に加えて1,500〜2,000ドルが上乗せされます。だからOSDを見送るべきだという話ではありません。到達しやすくなる前に、リクエストあたりのコストを把握し、成果ベース課金がその請求をどこへ動かすかを見ておくべきだということです。

ポリシーがそのまま製品になる

Zendeskは、アシスタントが接続した後は「the brand decides what customer information can be accessed, which actions are permitted and when a human needs to step in」と明言しています。実際には、機械が従える形でどこかに次の3つを書き出しておく必要があります。

1. 回答。 エージェントは、実際のポリシーや過去のチケットから答えますか、それとも薄いヘルプセンターから答えますか。アシスタントは顧客と同じ質問を、より正確な言葉で投げてきます。
2. 操作。 自動で実行される書き込み、人を待つもの、無効にするものはどれですか。日程変更と、返金やキャンセルは別物です。その線引きは、私の承認ワークフローガイドと返金承認マトリクスで扱っています。
3. 引き継ぎ。 エージェントに確信がないとき、人は完全な履歴を受け取れますか。Zendesk自身の例では、リクエストは「can move to the support team with the conversation history and actions already taken」とされています。実際にそうなる設定については、引き継ぎコンテキストとZendeskのAIエージェントのエスカレーションをご覧ください。

2つ目の点は、サポートリーダーから最もよく聞く話です。月に約7,000件のチケットを扱うDTCサプリメントブランドのCXリーダーは、eeselチームにこう語りました。

"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. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

検証済みディレクトリ経由で届くアシスタントは、この基準を下げるのではなく引き上げます。顧客は接続をより信頼するので、誤った回答のコストも大きくなります。出発点としては、私の信頼度しきい値のガイドと、Zendesk自身のインテント信頼度設定がよいでしょう。

eeselの立ち位置

eeselは、特定の仕事のために採用するAIチームメイトで、Zendeskではその仕事がヘルプデスクです。アカウントにエージェントとして参加し、過去のZendeskチケット、ヘルプセンター記事、マクロから学びます。操作ごとに、自動で実行するか、承認を待つか、無効にするかを設定できます。

誤解のないように言うと、eeselはOpen Service Directoryに掲載されていませんし、現時点で誰の掲載情報も公開されていません。eeselが担うのは、OSDが引き継ぐ先のレイヤー、つまり電話に出るエージェントと、その権限のルールです。リクエストが人から来ても、チャットの吹き出しから来ても、将来誰かのアシスタントから来ても同じように動きます。

OSDは開発者向けのローンチなので、eeselにも開発者向けの窓口があることも知っておく価値があります。eesel CLI（npm install -g @eesel/cli）は、ダッシュボードと同じエージェントをターミナルから動かし、すべてのコマンドがJSONを出力するので、スクリプトやClaude Code、Codex、Cursorのようなコーディングエージェントから操作できます。アシスタントからのトラフィックに備えるZendeskチームにとって役立つのは、上の3点に対応するコマンドです。

eesel integrations connect zendesk     # a Zendesk admin approves the connection
eesel integrations zendesk actions     # every Zendesk action and its approval setting
eesel instructions                     # read or edit the agent's standing rules
eesel approvals list                   # held actions waiting on a person
eesel activity                         # what the agent did, newest first

CLIからの書き込みもダッシュボードと同じ承認ルールに従い、--dry-run を付けると、書き込みが行うはずのサーバー呼び出しを送信せずに正確に出力します。ポリシー変更を反映前に確認するなら、私はこの方法を使います。また、すべてのワークスペースはMCPサーバーでもあり、Claude Codeから eesel mcp token コマンド1つで接続できます。このサーバーは、あなたが自分のエージェントを操作するためのもので、顧客のアシスタント向けではないので、OSDの掲載と混同しないでください。この端末アクセスがサポートチームにとってなぜ重要かは、私のAIエージェントCLIの記事で解説しています。

Zendeskのキューでeeselを試す

Open Service Directoryを機に、アシスタントが訪ねてきたとき誰が応答するのかを考え始めたなら、掲載よりもまずエージェントから始めてください。eeselは約30分でZendeskに接続し、チームがすでに回答したチケットから学び、誰かに返信する前に過去の会話で再生して試せます。人が必要な操作はあなたが設定し、すべての実行は監査できるアクティビティログに残ります。

無料プランには100クレジットとすべての機能が含まれ、有料プランは月299ドルで500クレジットから始まります。チケット1件は、どれだけ長くかかっても1クレジットです（eesel料金）。先に比較したい場合は、eesel vs Zendesk AIをどうぞ。そうでなければ、ご自身のZendeskチケットでeeselを試してみてください。