---
title: "チャットAIの「3秒ルール」を回避する｜非同期キューで組む汎用エージェント基盤の設計"
excerpt: "Discordで動いていたAIエージェントをSlack・Teams・Chatworkへ横展開するため、「表玄関（受付）→ QStash（非同期キュー）→ 裏口（実行）」の3層アーキテクチャを設計しました。プラットフォームごとのタイムアウト制約への対処と、LangGraphのthread_idによるマルチユーザー混線防止設計をまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2026-01-10T00:00:00+00:00
verified_at: 2026-01-10T00:00:00+00:00
tools: ["Slack", "Discord"]
tasks: ["AIエージェント", "業務プロジェクト"]
domain: "社内基盤・インフラ"
canonical_url: https://ai-katsu.jp/articles/async-agent-platform-design
---
# チャットAIの「3秒ルール」を回避する｜非同期キューで組む汎用エージェント基盤の設計

Discordで動いていたAIエージェントを、Slack・Teams・Chatworkへ横展開する。一見すると「接続先を増やすだけ」に見えますが、実際にはプラットフォームごとに**タイムアウトの制約と認証方式が違います。**

この違いを吸収する共通基盤として、**「表玄関（受付）→ 非同期キュー → 裏口（実行）」というアーキテクチャ**を設計しました。同時に複数人が会話しても混線しない仕組みも標準化しています。

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2026年1月〜2月（1/10〜2/4） |
| 使用ツール | QStash / LangGraph / Slack（HTTPモード）/ Teams（Azure Bot Service） |
| やりたかったこと | Discordで動いていたエージェント機能を、Slack・Teams・Chatworkへ低コストで横展開する |
| 設計 | **「表玄関（受付）→ QStash（非同期キュー）→ 裏口（実行）」**という3層アーキテクチャ |
| 混線対策 | **LangGraphの `thread_id` を用いたマルチユーザー混線防止設計** |
| 状況 | 設計完了・一部実装中（Slack先行） |

> 本記事は自社での検証記録です。実運用に至っていないため、効果の数値はありません。

## 結論：3秒ルールが設計を決める

チャットツールにAIエージェントを組み込む際、最初に突き当たるのがこれです。

**プラットフォームごとに「3秒ルール（タイムアウト）」があります。**受け取ったイベントに対して、決められた時間内に応答を返さないとエラー扱いになります。

しかしAIの処理は数秒では終わりません。**考えている間にタイムアウトする**という構造的な問題が発生します。

### 解決策：受付と実行を分離する

```
表玄関（受付）
  チャットツールからのイベントを受け取り、即座に「受け付けた」と返す
        ↓
QStash（非同期キュー）
  処理の依頼を溜める
        ↓
裏口（実行）
  時間をかけてAIが処理し、結果を後から投稿する
```

**「すぐ返す」と「時間をかけて処理する」を分けることで、タイムアウトの制約を回避します。**受付だけなら3秒で終わります。

この構造は、チャットツールに限らず**応答時間の制約がある連携全般で使えます。**

## 複数人が同時に話しても混線しない設計

もうひとつの重要な論点がこれです。

チャットツールは複数人が同時に使います。AさんとBさんが同時にエージェントへ話しかけたとき、**会話の文脈が混ざらないようにする必要があります。**

対応として、**LangGraphの `thread_id` を用いたマルチユーザー混線防止設計**を採用しました。**2人以上が同時に会話しても混線しない「ID正規化ロジック」を標準化しています。**

## 共通基盤にするための正規化

プラットフォームごとに、ユーザーやチャンネルの識別方法は異なります。これをそのまま扱うと、接続先ごとに別の実装が必要になります。

**すべてのチャットツールからの入力を `thread_id` として正規化し、バックエンドを共通化する**という判断をしました。理由はメンテナンス性です。

| アプローチ | 結果 |
| --- | --- |
| プラットフォームごとに実装 | 接続先が増えるほど保守が重くなる |
| **入口で正規化して共通化** | **バックエンドは1つで済む** |

**違いは入口で吸収し、中は共通にする。**横展開を前提にするなら、この設計が効いてきます。

## 検証の進捗

-   **Slack（HTTPモード）でのイベント受信とQStash連携の検証完了**
-   **Teams（Azure Bot Service経由）の実現可能性確認**

Slackを先行して実装を進めています。認証方式がプラットフォームごとに違うため、**1つずつ確認しながら共通化の範囲を見極める**進め方です。

## よくある質問

### 3秒ルールとは何ですか？

**チャットツールが定めるイベント応答のタイムアウト制約です。**決められた時間内に応答を返さないとエラー扱いになります。AIの処理は数秒では終わらないため、受付と実行を分離する必要があります。

### なぜ非同期キューを挟むのですか？

**「すぐ返す」と「時間をかけて処理する」を分離するためです。**表玄関でイベントを受け取って即座に応答し、実際の処理はキュー経由で裏口が担当します。

### 複数人が同時に使っても大丈夫ですか？

**LangGraphの `thread_id` によるID正規化ロジックで混線を防いでいます。**2人以上が同時に会話しても、文脈が混ざらない設計です。

### なぜ入力を正規化するのですか？

**バックエンドを共通化してメンテナンス性を保つためです。**プラットフォームごとに実装を分けると、接続先が増えるほど保守が重くなります。違いは入口で吸収します。

## まとめ

-   チャットツール連携では**「3秒ルール（タイムアウト）」が設計を決める**
-   対応は**「表玄関（受付）→ 非同期キュー → 裏口（実行）」の3層構造**。すぐ返す処理と時間のかかる処理を分離する
-   複数人の同時利用には**LangGraphの `thread_id` によるID正規化**で混線を防止
-   横展開を前提にするなら**違いは入口で吸収し、バックエンドは共通化する**

複数のプラットフォームに展開する仕組みでは、個別対応を積み上げるほど保守が重くなります。どこで差異を吸収するかを最初に決めておくと、後から増やすのが楽になります。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAI基盤づくりを支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。