Chat SDKで複数チャット基盤へボットを届ける前に見る設計と境界

共通のbot logicとplatform adapter

vercel/chatは、chatというnpm packageで提供されるTypeScript SDKです。READMEは、Slack、Microsoft Teams、Google Chat、Discord、Telegram、GitHub、Linear、WhatsAppなど複数のchat platformでbotを作るための統一SDKと説明しています。中心となる考えは、bot logicを一度書き、複数のplatformへ展開することです。

platform固有の処理はadapterへ分けられます。READMEには@chat-adapter/slack、@chat-adapter/teams、@chat-adapter/gchatのinstall例があり、adapterはcore packageとは別に導入します。official、vendor-official、communityのadapterをchat-sdk.dev/adaptersで探せると説明されているため、名前が同じでも提供主体と保守範囲を確認します。

同じlogicを使える設計は、イベント処理や業務ルールを共有しやすくする材料です。しかし、各platformのmessage形式、権限、webhook、カード、streaming、DMの制限まで同一になるとは限りません。最初の設計では、共通にしたい判断と、adapterごとに分ける送受信処理を明示し、platform別の差を無理に隠さない構成にします。

npm導入とcreate-chat-sdkの役割

基本のSDKはnpm i chatで導入します。利用するplatformのadapterは個別にinstallし、READMEの例ではSlack、Teams、Google Chat向けの三つをnpm install @chat-adapter/slack @chat-adapter/teams @chat-adapter/gchatで追加します。SDKだけを入れて全platformへ接続できるわけではないため、対象ごとの依存関係をpackage管理へ記録します。

CLIのcreate-chat-sdkをnpx create-chat-sdk@latest my-botとして実行すると、最小構成のNext.js bot appをscaffoldできます。READMEによれば、Chat設定、webhook route、.env.example、依存関係、adapter catalogから選んだ任意のWeb adapter routeが生成されます。雛形は開発開始を早める入口ですが、生成された環境変数、route、権限、secretの扱いを読まずに公開するものではありません。

CLIのoptionとnon-interactive利用はREADMEではなく、chat-sdk.devのCLI文書へ案内されています。導入時には、実行したCLIの版、選択したadapter、生成されたファイル、環境変数の項目、webhook URLを保存します。latestをそのまま採用すると再現条件が曖昧になるため、検証と本番準備でpackageの版を固定し、更新時に生成物の差分を確認します。

Chatインスタンスとthread処理

READMEの使用例は、chatからChat、@chat-adapter/slackからcreateSlackAdapter、@chat-adapter/state-redisからcreateRedisStateをimportするところから始まります。new ChatにはuserName、adapters、stateを渡し、slack adapterとRedis stateを登録します。状態をどこへ保存するかをChatの構成に含めるため、message処理と状態基盤を分けて検討できます。

例ではbot.onNewMentionでthread.subscribeを呼び、Hello!という投稿を行います。bot.onSubscribedMessageではmessage.textを受け取り、You said:という形でthreadへ投稿します。これはmentionを起点に購読し、その後のmessageを処理する基本経路を示す短い例です。実用化するには、同じイベントの再送、bot自身の投稿、購読解除、失敗時の再試行、入力長、個人情報を別に設計します。

READMEは完全なtutorialではなく、詳細なGetting Started guideへ誘導しています。使用例から状態の永続化方法や全adapterの設定を推測せず、採用するadapterのguideと状態実装の説明を読みます。最初の確認では一つのtest channelと一つのthreadを使い、mention、購読、返信、再起動後の状態、権限不足時のエラーを順に記録します。

event、card、fileを共通APIで扱う範囲

Featuresには、mentions、messages、reactions、button clicks、slash commands、modalsを扱うevent handlersが挙げられています。interactive cardはJSXで記述し、Block Kit、Adaptive Cards、Google Chat Cardsを対象にします。actionsではbutton clickとdropdown selectionを処理し、modalsではtext input、dropdown、validationを扱うと説明されています。

AI streamingでは、Slack native streaming、Telegram private chatのdraft preview、投稿後に編集するfallbackが挙げられています。Emojiは型安全なcross-platform形式とcustom emoji、file uploadは添付ファイルの送受信、direct messageはprogrammaticなDM開始、ephemeral messageは本人だけに見える表示とDM fallbackを提供するとされています。これらはREADMEの機能説明であり、各platformで同じ表示や制約になるという測定結果ではありません。

同じthreadにmessageが重なった場合は、burst、queue、debounce、drop、processから扱いを選べるoverlapping messagesも列挙されています。通知botでは、短時間に来る要求を全部処理するのか、最後の要求だけを残すのかで結果が変わります。イベント順序、再送、重複、timeout、platformのrate limitを実際のadapterで確認し、業務上失ってはいけないmessageの扱いを先に決めます。

AI streamingとplatform差分の検証

READMEはAI streamingを、複数platformへLLM responseを流す機能として紹介しています。Slackではnative streaming、Telegramのprivate chatではdraft preview、共通化できない場合にはpostとeditのfallbackが示されています。この記述から、SDKがplatform差分を吸収しようとしていることは読めますが、応答速度、token単価、途中停止、長文の表示制限は素材だけでは分かりません。

検証では、同じ入力をSlack、Teams、Google Chatなど対象platformへ送り、最初の表示、最終更新、失敗時の文面、途中キャンセルを比較します。streamingが使えない場合に通常投稿へ戻るのか、途中の内容が残るのか、ユーザーへ重複して表示されるのかを記録します。AI responseに秘密情報が含まれないよう、送信前の入力制限とログのマスキングも準備します。

READMEはLLM provider、model、promptの管理方式や、生成内容の安全審査について詳しく説明していません。Chat SDKのadapter機能と、AIサービスの契約、認証、データ保存を同じ責任範囲として扱わないことが重要です。どの層がmessageを保持するのか、streamの再送を誰が行うのかを設計図に書き、platformごとの差分を運用手順へ反映します。

AI coding agent向けskillの位置づけ

READMEには、OpenAI Codex、Claude Code、CursorのようなAI coding agentを使う場合、Chat SDKのskillを入れるよう勧める節があります。例としてnpx skills add vercel/chatが示され、このskillはSDK API、adapter pattern、project conventionを参照できるようにするものです。

skillはnode_modules/chat/docsに同梱された文書、公開packageに含まれるadapter guide、starter templateを参照すると説明されています。Vercel Pluginをnpx plugins add vercel/vercel-pluginで入れる選択肢もあり、Chat SDK skillと他のtoolを含むとされています。機械向けの文書入口としてchat-sdk.dev/llms.txtとchat-sdk.dev/llms-full.txtも列挙されています。

これらはコード生成や調査を補助する文書入口です。skillを入れたからadapterの認証、platformの審査、生成コードの安全性が自動的に決まるわけではありません。agentが作ったroute、環境変数、状態処理、外部送信を人がレビューし、依存packageの版と生成差分を確認してから採用します。READMEが勧める導入方法と、組織のAI利用規程を分けて評価します。

文書、support、securityの確認先

完全なdocumentはchat-sdk.dev/docs、guideはVercel Knowledge BaseにあるとREADMEは案内しています。貢献方法、support、security vulnerabilityの報告は、それぞれリポジトリ内のCONTRIBUTING.md、SUPPORT.md、SECURITY.mdを参照します。機能の一覧だけで実装詳細を判断せず、使うadapterと機能に対応するページへ戻ります。

素材の取得時点は2026年8月29日です。GitHubメタデータにはmainブランチ、2325 stars、294 forks、21 open issuesが記録され、リリースにはchat@4.39.0、@chat-adapter/x@4.39.0、@chat-adapter/whatsapp@4.39.0があります。これらは取得時点の公開情報であり、adapterの品質、supportの応答時間、将来の互換性を保証する数字ではありません。

導入記録には、SDK本体、adapter、CLI、Node.js、Next.js、状態保存の版をそろえて残します。Supportへ相談する場合は、platform、webhook、request ID、再現手順、ログの秘密情報を除いた形で準備します。security問題の報告経路と通常のsupportを混同せず、公開issueへ秘密情報を書かない運用を決めます。

MITライセンスと採用前の小さな実験

Chat SDKのライセンスはMITです。READMEの説明では、利用、複製、変更、結合、公開、配布、sub-license、販売を、著作権表示を含める条件で許可します。ソフトウェアは現状のまま提供され、保証はないとされています。これはpackageの利用条件を確認する入口であり、各platformのAPI規約、adapterの個別条件、LLM providerのデータ規約、botが扱うファイルの権利を省略する根拠ではありません。

採用前には、Slackなど一つのplatform、一つのadapter、一つのthread、一つの状態保存を選び、mentionから返信までを確認します。次に、重複event、短時間の連続message、file upload、権限不足、webhook再送、Redis停止を個別に試します。streamingやcardを導入する場合は、対応platformで表示がどう変わるかを画像とログで残します。

Chat SDKが向くのは、共通のbot logicとplatform別adapterを分け、複数のchat channelへ展開する計画を持つチームです。単一platformだけで、既存の公式SDKが要件を満たす場合は、抽象化の追加コストも比較します。対象機能、adapterの版、状態の保存場所、再送と並行処理、認証、ログ、license確認を一つの採用記録にまとめてから、運用範囲を決めます。

編集部の結論

Chat SDKは、複数のチャット基盤に同じボットの処理方針を展開しつつ、platform固有の送受信をadapterへ分けたいTypeScript開発者向けの候補です。READMEはSlack、Microsoft Teams、Google Chat、Discord、Telegram、GitHub、Linear、WhatsAppなどを挙げていますが、対応範囲、adapterの成熟度、状態保存、認証、各社の制約は個別確認が必要です。導入前に対象platform、adapterの版、webhook、Redisなどの状態基盤、再送と並行処理の方針を固定してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes