スポンサーリンク

Zendesk対応のどこまでをAIに任せられるか

ZendeskとAIの連携と聞くと「問い合わせに全自動で返信する」イメージを持つかもしれませんが、実務では自動化のレベルを段階的に考えるのが安全です。

この記事で目指すのはレベル3までです。AIが下書きを作り、人間が最終確認する形なら、品質リスクを抑えつつ返信作成時間を大幅に短縮できます。レベル4はよほど定型的な問い合わせ（パスワードリセット案内など）に限定しない限りおすすめしません。

連携方法は3ルート：MCP・REST API・Webhook

ZendeskをClaude CodeやCodexから扱う方法は、大きく3つに分けられます。

最初は①で「AIにZendeskを触らせる感覚」を掴み、繰り返し行う処理が見えてきたら②でスクリプト化、運用が固まったら③でイベント駆動化する、という順番が現実的です。

事前準備：Zendesk APIトークンの発行

どのルートでも、まずZendeskのAPIトークンが必要です。

1. Zendeskの管理センター（Admin Center）を開く
2. 「アプリおよびインテグレーション」→「API」→「Zendesk API」に進む
3. 「トークンアクセス」を有効にして、APIトークンを追加・コピーする

認証は、メールアドレスに/tokenを付けた文字列をユーザー名、APIトークンをパスワードとするBasic認証です。

# 認証形式：{メールアドレス}/token:{APIトークン}
curl "https://あなたのサブドメイン.zendesk.com/api/v2/tickets.json" \
  -u "you@example.com/token:YOUR_API_TOKEN"

実践①：MCPサーバーでClaude Code・Codexから対話操作

Zendesk用のMCPサーバーはコミュニティ製のものが複数公開されており、チケットの検索・取得・コメント追加・タグ更新などをAIエージェントのツールとして使えるようになります。導入すると、Claude CodeやCodexにこんな依頼がそのままできます。

• 「未対応のオープンチケットを一覧して、緊急度順に並べて」
• 「チケット#1234のやり取りを要約して、論点を整理して」
• 「この1週間で『請求』に関するチケットが何件あったか調べて」

Claude Codeへの登録はclaude mcp addコマンド、Codexは~/.codex/config.tomlの[mcp_servers]セクションで行います。

MCPルートの弱点は、あくまで「会話の中」でしか動かないことです。「新しいチケットが来たら自動で下書きを作る」といったイベント駆動の処理はできないため、そこは次のREST APIルートとWebhookルートの出番になります。

実践②：REST APIで「チケット取得→AI下書き→内部メモ投稿」を自動化

ここが本記事のメインです。Zendesk REST APIとClaude APIを組み合わせ、返信の下書きを内部メモ（顧客には見えないコメント）として自動投稿するスクリプトを作ります。この程度のスクリプトなら、Claude CodeやCodexに「この仕様で書いて」と頼めば数分で生成してくれます。

ステップ1：チケットのスレッド全体を取得する

チケットのコメント（やり取り）一覧はGET /api/v2/tickets/{id}/comments.jsonで取得できます。

import os
import requests

SUBDOMAIN = "あなたのサブドメイン"
AUTH = (f"{os.environ['ZENDESK_EMAIL']}/token", os.environ["ZENDESK_API_TOKEN"])

def get_ticket_thread(ticket_id: int) -> str:
    """チケットの全コメントを時系列テキストに整形して返す"""
    url = f"https://{SUBDOMAIN}.zendesk.com/api/v2/tickets/{ticket_id}/comments.json"
    comments = requests.get(url, auth=AUTH).json()["comments"]
    lines = []
    for c in comments:
        role = "顧客" if c["public"] else "内部メモ"
        lines.append(f"[{role}] {c['created_at']}\n{c['plain_body']}\n")
    return "\n".join(lines)

ステップ2：AIに返信下書きを書かせる

取得したスレッドをClaude APIに渡して下書きを生成します（品質を上げるプロンプト設計は後述します）。

import anthropic

client = anthropic.Anthropic()  # ANTHROPIC_API_KEY を環境変数に設定

def draft_reply(thread_text: str, knowledge: str) -> str:
    message = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1500,
        system=SUPPORT_SYSTEM_PROMPT,  # スタイルガイド＋制約（後述）
        messages=[{
            "role": "user",
            "content": (
                f"## 参考ナレッジ\n{knowledge}\n\n"
                f"## チケットのやり取り（時系列）\n{thread_text}\n\n"
                "上記を踏まえて、最新の顧客メッセージへの返信下書きを書いてください。"
            ),
        }],
    )
    return message.content[0].text

ステップ3：下書きを「内部メモ」として投稿する

ここが安全運用のポイントです。PUT /api/v2/tickets/{id}.jsonでコメントを追加するとき、"public": falseを指定すると顧客には見えない内部メモになります。担当者はZendesk上で下書きを確認し、必要な修正をしてから自分の名前で送信します。

def post_internal_note(ticket_id: int, draft: str):
    url = f"https://{SUBDOMAIN}.zendesk.com/api/v2/tickets/{ticket_id}.json"
    payload = {
        "ticket": {
            "comment": {
                "body": f"【AI下書き】以下を確認・修正のうえ返信してください。\n\n{draft}",
                "public": False,  # ← 内部メモ。顧客には見えない
            }
        }
    }
    requests.put(url, json=payload, auth=AUTH).raise_for_status()

実践③：Webhook＋トリガーで新着チケット駆動にする

スクリプトを手動実行する運用が回り始めたら、Zendeskのトリガー＋Webhookでイベント駆動にできます。仕組みはシンプルです。

1. 管理センターの「アプリおよびインテグレーション」→「Webhook」で、自前のエンドポイント（Cloud Run、AWS Lambda、社内サーバーなど）に向けたWebhookを作成する
2. 「ビジネスルール」→「トリガー」で「チケット作成時」などの条件にそのWebhookを紐付け、チケットIDを含むJSONを送るよう設定する
3. エンドポイント側で実践②のスクリプトを呼び出し、下書きを内部メモとして投稿する

これで「新着チケットが来たら、担当者が開く頃にはAIの下書きと要約が内部メモに付いている」状態が作れます。トリガーの条件で「特定のフォーム・特定のタグのみ」と絞れば、定型的な問い合わせから段階的に適用範囲を広げられます。

【本題】AI返信の品質を上げる6つのノウハウ

仕組みを作ること自体は難しくありません。難しいのは「使える品質の下書き」を安定して出させることです。チケット本文をそのままSonnet 5などに渡して「返信を書いて」と頼むと、丁寧だけど中身のない、そのままでは使えない回答が返ってくることが多いはずです。

原因ははっきりしています。モデルはあなたの製品・料金・仕様・過去の経緯を何も知らないので、知らない部分を一般論と過剰な謝罪で埋めるからです。つまり品質改善の本質は「プロンプトの言い回し」ではなく「渡す情報の設計」にあります。

① スレッド全体と顧客情報を渡す（最新メッセージだけ渡さない）

最新の1通だけを渡すと、AIは経緯を知らないまま返信を書くため「すでに案内済みの内容をもう一度説明する」「顧客が3回目の問い合わせなのに初見の温度感で返す」といった事故が起きます。実践②のようにコメント全件を時系列で渡し、可能なら顧客の契約プラン・利用歴・過去チケットの件数などの属性情報も添えます。「お客様は5年目の有償プラン利用者で、同件で2回目の問い合わせ」と知っているだけで、返信の温度感は大きく変わります。

② ナレッジを検索して渡す（簡易RAG）

最も効果が大きいのがこれです。返信生成の前に、関連する社内ナレッジを検索して一緒に渡します。Zendeskだけでも材料は揃っています。

• ヘルプセンター記事：Help Center APIの記事検索で、問い合わせ内容に関連するFAQ・手順記事を取得
• 過去の解決済みチケット：検索API（/api/v2/search.json）で類似の解決済みチケットを探し、当時の返信を参考として渡す
• マクロ（定型文）：既存のマクロは「会社として承認済みの言い回し」の宝庫。関連マクロを渡して「これをベースに個別事情を反映して」と指示

「知らないから一般論を書く」状態を、「答えの根拠が手元にあるから具体的に書ける」状態に変えるのが狙いです。

③ 優秀な返信の実例をfew-shotで見せる

スタイルガイドを文章で書くより、エースの担当者が実際に書いた返信を2〜3本、例として見せる方が効きます。システムプロンプトに「良い返信の例」として埋め込んでおくと、文体・構成・締め方がその例に寄っていきます。逆に「やってはいけない例」（過剰な謝罪、長すぎる前置き、翻訳調の敬語）を1本添えるのも有効です。

SUPPORT_SYSTEM_PROMPT = """
あなたは当社のカスタマーサポート担当です。以下のルールを厳守してください。

## 文体ルール
- 謝罪は問題が当社起因のときのみ、冒頭に1回だけ
- 前置きは2文以内。3文目までに回答の核心に入る
- 手順説明は番号付きリストを使う
- 顧客の質問に含まれていないことを推測で説明しない

## 禁止事項
- 参考ナレッジにない仕様・料金・日付を書かない。
  不明な点は「確認して折り返す」と書く
- 「ご不便をおかけして〜」の重ね掛け禁止

## 良い返信の例
（実際の優秀な返信をここに2〜3本貼る）
"""

④ 「分類→方針→執筆」に分ける（いきなり書かせない）

1回のプロンプトで完成品を求めると品質が不安定になります。次のように段階を分けると、それぞれの精度が上がり、途中結果を人間が検査することもできます。

1. 分類：問い合わせ種別（不具合報告／使い方質問／解約・請求／要望）と感情の温度を判定させる
2. 方針決定：「何を伝え、何を確認し、何は約束しないか」を箇条書きの返信方針として出させる
3. 執筆：確定した方針とナレッジに基づいて本文を書かせる

分類結果はそのままZendeskのタグ付けや担当グループ振り分けにも使えるので、一石二鳥です。

⑤ 「書かない勇気」を明示的に与える

AI返信が信用を失う最大の原因は、知らないことをそれらしく書いてしまうことです。システムプロンプトに「ナレッジにない情報は書かず、『確認して折り返す』と書く」「返金・補償・対応期日の約束は絶対にしない」という制約を明記します。あわせて「怒っている顧客」「法的な話が出ている」「解約意向」などのエスカレーション条件を定義し、該当する場合は下書きではなく「人間が直接対応すべき」というフラグ付き内部メモを出させると安全です。

⑥ セルフレビューの工程を挟む

下書きを出したあと、別のプロンプト（または上位モデル）で「この返信は顧客の質問すべてに答えているか」「ナレッジにない断定はないか」「約束事項が含まれていないか」をチェックさせ、指摘があれば書き直させます。1回のAPI呼び出しが2〜3回になりコストは増えますが、下書きの「そのまま使える率」が上がれば人間のレビュー時間が減るので、トータルでは十分元が取れます。

よくある質問

まとめ

「AIに返信を書かせてみたけど微妙だった」で止まっている方は、まず過去の優秀な返信2〜3本とヘルプセンター記事をプロンプトに入れるところから試してみてください。それだけで出力の具体性が目に見えて変わるはずです。