チャットAIの「3秒ルール」を回避する｜非同期キューで組む汎用エージェント基盤の設計【AI活用検証vol.54】

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

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

この検証の概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

検証の進捗

• 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基盤づくりを支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。