[Zendesk+Slack] Slack スラッシュコマンドから Zendesk チケットを起票する仕組みを構築する [1/3]

• 第 2 回：Lambda 関数と SQS を使った非同期処理の実装
• 第 3 回：Slack アプリの設定と動作確認

対象読者

• Slack から問い合わせを起票する仕組みを自前で構築したい方
• AWS Lambda や Amazon SQS を使って非同期処理を実装したい方
• Zendesk の API を活用したカスタム連携を検討している方

参考記事

• Twilio + Slack + Lambda + SQS 構成で音声通話を自動発信する仕組み
• Zendesk 公式：API リファレンス

node: 22.13.1  
npm: 10.9.2  

概要

本シリーズでは、Slack のスラッシュコマンドをトリガーとして Zendesk にチケットを起票する仕組みを構築します。Slack 側の即時応答要件と Zendesk API の非同期処理を両立させるため、AWS Lambda と Amazon SQS を組み合わせた構成を採用しています。

この構成は、シンプルながら拡張性と安定性を兼ね備えており、社内ヘルプデスクや営業・CS 部門のフィードバック受付など、さまざまな用途に対応できます。

全体構成図

本シリーズで構築するシステム全体の構成は以下のとおりです。Slack からのリクエストは API Gateway と Lambda を経由して SQS に一時保存され、別の Lambda 関数で非同期的に Zendesk API を呼び出します。

第 1 回では、初期設定として行う Zendesk 側の API トークンの取得手順などについて紹介します。

なぜこの構成なのか？

Slack と Zendesk を連携させるにはいくつかの方法がありますが、以下の理由により、今回は AWS 上に中継処理を構築する構成を採用しました。

• Slack の制約
  Slack のスラッシュコマンドは、コマンド送信後 3 秒以内に HTTP 200 レスポンスを返す必要があります。これを超えるとエラー扱いとなり、ユーザー側に「失敗」と表示されてしまいます。
  一方で、Zendesk API のチケット起票は認証やネットワーク状況により数秒以上かかる可能性があります。したがって、同期的に Zendesk API を呼び出す構成では、Slack 側の制限を満たせない可能性が高くなります。

• Zendesk 側に受信機構は存在しない
  Zendesk には Webhook を送信する仕組みはありますが、外部からの HTTP リクエストを直接受け付けるエンドポイント（＝受信機構）は提供されていません。また、Zendesk 上に処理ロジックを埋め込むサーバーレス関数のような仕組みも存在しません。
  そのため、Slack のスラッシュコマンドからのリクエストを受け取るには、自前で受信用のエンドポイント（API Gateway + Lambda）を用意する必要があります。

• なぜ SQS を挟むのか
  Slack の 3 秒制限と Zendesk API の遅延可能性を両立するために、Lambda で受け取ったリクエストを即座に SQS に格納し、非同期で処理する構成を採用します。

この構成によって得られるメリットは以下のとおりです：

• Slack 側には即時レスポンス（"受付完了"）を返せる
• Zendesk API の処理に時間がかかっても影響しない
• 処理失敗時のリトライや DLQ（死活監視）が可能
• 後続処理（通知やDB保存など）の拡張がしやすい

想定ユースケースと導入メリット

この仕組みは、次のようなシーンで活用できます：

また、Slack コマンド経由で起票されたチケットは、Zendesk のカスタムフィールドと連携することで分類や優先度管理を行うことも可能です。

初期設定：Zendesk コンソールでの操作

Slack コマンドから Zendesk にチケットを起票するには、Zendesk 側で API トークンを取得しておく必要があります。本記事では、トークン認証を使用した構成とします。

1. 管理者アカウントでログイン

まず、Zendesk に管理者アカウントでログインします。

2. API トークンを有効化する

1. 右上のアイコンから「管理センター」を開きます
2. 「アプリおよびインテグレーション」 > 「Zendesk API」 を選択
3. 「トークンアクセスを有効にする」を ON にします
4. 「API トークンを追加」をクリックして新しいトークンを発行します

トークンは一度しか表示されないため、忘れずにコピーして安全な場所に保存しておきます。

3. メールアドレス形式のユーザー識別子を控える

Zendesk API にアクセスする際には、以下のような形式のユーザー識別子が必要です：

you@example.com/token

これは後ほど Lambda 関数側で認証ヘッダーとして使用します。

4. 検証用のテストチケットを 1 件作成しておく（任意）

動作確認の際に差分を把握しやすくするため、Zendesk 側に手動で 1 件チケットを作っておくと便利です。

まとめ

本記事では、Slack スラッシュコマンドから Zendesk にチケットを起票するための全体構成と、Zendesk 側での初期設定（API トークンの取得方法など）について解説しました。

Slack の 3 秒制限を回避し、安定したチケット作成フローを実現するためには、非同期処理を前提とした構成が重要です。Zendesk API は高機能ですが、受信エンドポイントを自前で用意する必要があるため、AWS を組み合わせた柔軟な設計が有効です。

次回は、Slack コマンドをトリガーとしてリクエストを受け取り、SQS にメッセージを投入するまでの構成をステップごとに実装していきます。

• 第 2 回：Lambda 関数と SQS を使った非同期処理の実装
• 第 3 回：Slack アプリの設定と動作確認