Microsoft Teamsの開発者は、すべての拡張機能を「ボット」と呼ぶことが、本番環境レベルの障害を引き起こす可能性があるという警告を受けています。2026年には、プラットフォーム自体の制限（メッセージへの応答時間は10〜15秒）により、設計ミスのあるボットがタイムアウトの嵐（timeout storms）を引き起こし、チームはパイプラインの再設計を余儀なくされることになります。

なぜこの区別が重要なのか

Teamsは3つの拡張機能タイプを提供しており、それぞれ異なるインタラクションパターン向けに構築されています。これらを混同すると、不適切なランタイム、不適切なSDK、そして不適切なスケーリングモデルを強制することになります。

Teams apps、bots、agentsとは何か

  • Teams apps – Teamsクライアント内のサーフェスタブ、静的ページ、またはシンプルなUIコンポーネントです。これらは本質的にWebアプリであり、ステートレスで、オンデマンドでレンダリングされ、他のHTTPサービスと同様にホストされます。会話の流れ（conversational flow）は想定されていません。
  • Bots – Bot Framework SDKを使用して構築され、スクリプト化されたダイアログに従います。そのロジックは、受信したアクティビティのみに基づいて次の返信を決定する、決定論的なif/elseツリーです。決定パスが事前にわかっているため、応答はプラットフォームの短いタイムアウトウィンドウ内に収まります。
  • Agents – 高レベルの目標、一連のツール、およびLLM（大規模言語モデル）を受け取る目標駆動型のエンティティです。Agents SDKまたはSemantic Kernelを使用すると、LLMはどのツールを、どの順序で呼び出すか、そしていつユーザーに確認を求めるかを決定します。フローは動的であり、多くの場合、複数の外部呼び出しや重い推論処理を必要とします。

この違いは明確です。ボットは決定論的（deterministic）であり、エージェントは確率論的（probabilistic）で、実行時にツールの呼び出しをオーケストレーションします。

タイムアウトの罠

開発者が重い推論処理（LLMプロンプト、データベース検索、または外部API呼び出し）をボットのメッセージハンドラー内に直接埋め込むと、Teamsはリクエストが10〜15秒のウィンドウを超えて停滞していると判断します。プラットフォームは応答を中断してリトライを行うため、これが重複作業やスロットリングの連鎖を引き起こす可能性があります。症状としては、断続的な「ボットが応答していません」というエラーとして現れますが、根本的な原因はアーキテクチャにあります。

本番環境に対応した非同期パイプラインの構築

  1. Webhookのエントリポイント – ボットのHTTPエンドポイントがTeamsのアクティビティを受け取り、即座に受信を確認（acknowledge）します。
  2. イベントをキューに入れる – ハンドラーがペイロードをAzure Service Busなどの耐久性のあるキューにプッシュします。
  3. バックグラウンドワーカー – Azure Durable Function、Service Busトリガー、またはその他の長時間実行されるワーカーがメッセージを取り出し、LLMの推論またはツールのオーケストレーションを実行し、Bot Frameworkのプロアクティブ メッセージング APIを通じて最終的な返信をTeamsに投稿します。

最初のWebhookが即座にレスポンスを返すため、Teamsがタイムアウトに達することはありません。重い処理は独自のペースで進行します。キューがスパイクをバッファリングし、ワーカーはバックログの長さに応じて自動的にスケーリングします。

クイック意思決定ガイド（ホワイトボード・テスト）

  • コードを書く前に、決定ツリー全体を描けますか？ はい → ボットを構築してください。決定論的なフローはBot Frameworkのモデルに適合し、応答ウィンドウ内に収まります。
  • 問題が、高レベルの目標と利用可能なツールのリストによって定義されていますか？ はい → エージェントを構築してください。LLMに計画とツールの呼び出しを任せ、計画処理はバックグラウンドワーカーにオフロードしてください。

次回予告

このガイダンスは、Azure上でインテリジェントなTeamsソリューションを構築する.NET 9開発者向けのシリーズの第1回です。

Teamsのログですでに「Bot timed out」エラーが発生している場合、解決策は簡単です。Webhookを重い処理から切り離し（decouple）、キュー駆動型のワーカーを採用し、最初から正しい拡張機能タイプを選択することです。プラットフォームにはタイムアウト制限がありますが、アーキテクチャによってそれを回避することは可能です。

まとめ: Teamsの拡張機能をボットと誤って分類すると、Teamsが維持できない同期的な設計を強制することになります。リクエストと推論を分離し、適切なSDKを選択すれば、その背後にある「脳」がLLM搭載のエージェントであっても、Teamsソリューションの応答性を維持できます。