ADR 0003: コンテナ内処理 + 分析系のみ Queue + Consumer
この ADR は置換されました
コンテナ + Queue + Consumer の 2〜3 デプロイ構成は、ADR 0006 の単一 Worker 構成（AI 応答は Agent/DO、保存系は ctx.waitUntil、cron は scheduled）に置き換えた。
Context
Inngest 廃止（ADR 0001）後、tied-bot の 12 の Inngest 関数を別の方式に振り分ける必要がある。これらは性質が二分される。
- AI 応答系（app_mention / DM への返信、slash command）: 低レイテンシで返したい。Mastra 非採用後も AI SDK を使うため Node/Bun ランタイムが前提（→ コンテナ向き）。
- 分析・保存系（メッセージ/リアクション/添付の保存、埋め込み生成、master-data 同期）: 即時性は不要で、リトライ・バッチ処理・スケールアウトが欲しい（→ Queue + Consumer 向き）。
bot は Socket Mode コンテナとして常駐しており、WebSocket を維持したまま同一プロセス内で AI 応答を処理できる。
Decision
- AI 応答系は Socket Mode コンテナ内で処理する（同期 / コンテナ内非同期）。AI Gateway 経由で LLM を呼ぶ。
- 分析・保存系のみ Cloudflare Queue + Consumer に分離する。bot は
slack-data-fanout相当の分類を行い、分析イベントを REST 経由で Queue に投入（noisy-crow-appのrest-queue-producer.tsパターン）。 - Consumer の振り分け: reactions→D1 / 埋め込み→Vectorize / parquet・files・master-data→R2（ADR 0004）。
Consequences
- 良い点: ユーザー応答は常駐コンテナで低レイテンシ。重い分析処理は Queue で疎結合化され、リトライ・DLQ・バックプレッシャを Cloudflare 側に委譲できる。
noisy-crow-appの既存パターンを再利用。 - 悪い点 / 注意: bot コンテナと Consumer の 2 デプロイ単位になる。コンテナからは Queue バインド不可のため REST producer が必要（
CLOUDFLARE_API_TOKEN等）。Consumer での parquet 書き出しは Workers ランタイムでの動作が不確実なため、Consumer も Bun コンテナにする案を既定とする（ADR 0004 と移行計画 §2-3 参照）。 - フォローアップ: Queue 名 /
max_batch_size/ DLQ を確定。fanout の分類ロジックを usecase 化。
Alternatives
- 全処理をコンテナ内で完結（Queue なし）: 構成は最小だがリトライ/スケール/疎結合の利点を失い、重い分析が応答処理と同居して安定性に影響。却下（ただし分析系の負荷が小さいと判明した場合は将来再検討余地あり）。
- 全処理を Queue + Consumer に寄せる（
noisy-crow-appと完全同型）: AI 応答まで Queue 経由だと往復レイテンシが増え、Mastra 非採用でも AI SDK が Node 前提のため Consumer を Worker にできない。AI 応答はコンテナ内が妥当。却下。