Vercel Chat SDK `chat/ai` 公開｜tools・approval gate・preset で何が変わったか

先に結論

Vercel Chat SDK の chat/ai で変わったのは、bot に AI SDK tools を載せるまでの距離がかなり短くなったことです。

これまでは、Slack や Teams で使う read / write の道具を自前で組むか、かなり薄い wrapper でつなぐ必要がありました。今回からは createChatTools でまとめて渡せます。

しかも、write 操作は approval 付きが既定です。だから最初の答えはシンプルです。まず messenger preset で始め、書き込み権限は必要になったものだけ広げる のがいちばん安全です。

workflow 全体の置き場所から見たいなら、GitHub Agentic Workflows vs Copilot coding agent vs OpenClaw cron もつながります。会話 UI と workflow engine の境界を見たいなら、ChatGPT apps vs Zapier vs Make vs MCP を先に見ても迷いにくいです。

何が増えたのか

2026 年 5 月 20 日、Vercel は Chat SDK に chat/ai subpath を追加しました。

ここに入ったのは、createChatTools、toAiMessages、関連型です。要するに、会話履歴を agent 向けに整える道具 と agent から chat workspace を操作する道具 が 1 か所にまとまりました。

createChatTools は、Chat SDK が登録済みの adapter を見て、Slack、Teams、Discord、GitHub、Linear などに同じ形で tool を差し込みます。read では messages や thread を読み、write では reply、DM、reaction、edit、delete、subscription 管理まで扱えます。

この設計の良いところは、同じ bot ロジックを複数チャネルへ広げやすいことです。Slack 向けに作った agent の考え方を、Teams や GitHub コメントにも持ち込みやすくなります。

一番大きいのは approval が最初から入っていること

今回いちばん効くのは、write 操作を雑に解放しなくてよくなったことです。

Chat SDK docs では、post、edit、delete、reaction、subscription のような write 操作は approval が既定です。AI SDK 側が tool 実行を止め、アプリ側で承認してから流す前提になっています。

このため、最初から「AI に Slack へ自由投稿させるのは怖い」という壁を越えやすくなりました。返信、DM、reaction を触りたいが、いきなり unattended execution にはしたくない、という現場にかなり合います。

もちろん、人間確認なしで回したい場面もあります。その場合でも requireApproval: false を全体に掛けるか、deleteMessage だけ true のように per-tool で残すかを選べます。

重要なのは、安全側がデフォルト だということです。bot を実務に入れるときの初速がかなり違います。

preset は最初の権限設計をかなり楽にする

reader、messenger、moderator の 3 つの preset があるので、最初から全部開ける必要はありません。

reader は読み取り専用です。thread や channel の状況を読ませるだけならこれで足ります。

messenger は read に加え、reply、channel 投稿、DM、reaction、typing indicator まで入ります。多くの社内 bot は、まずここから始めるのが自然です。

moderator は edit、delete、subscription 管理まで含みます。運用管理 bot や channel 管理 bot に向く一方、最初からここへ行く理由はあまりありません。

docs では preset ごとに返す tool が明示され、不要な tool は lazy loading で構築しないと案内されています。つまり preset は説明用のラベルではなく、権限と初期コストの両方を絞る仕組み になっています。

既存 bot の移行は import 変更から始めればいい

既存の Chat SDK bot があるなら、最初に見るべき移行点は toAiMessages です。

Vercel は toAiMessages と関連型の top-level chat re-export を deprecated にしました。古い bot がすぐ壊れる話ではありませんが、今後は chat/ai に寄せたほうが自然です。

- import { toAiMessages } from "chat";
+ import { toAiMessages } from "chat/ai";

この 1 行変更だけでも、今回の整理に追従できます。

そのうえで、新しい bot なら toAiMessages で thread history を AI SDK 向けの shape に変え、createChatTools で tool を渡す流れに揃えると見通しが良いです。

GitHub や Linear bot でどう効くか

今回の update は、Slack や Teams の chat bot だけの話ではありません。

同日の changelog では、GitHub や Linear の comment mention から親 issue / PR を取れる message.subject も案内されました。comment 本文しか届かない webhook でも、親 resource の title、status、URL を読めます。

これを chat/ai と合わせると、流れはかなり分かりやすいです。親 issue / PR を読み、その thread 履歴を toAiMessages に流し、必要なら reply や reaction を tool 経由で返せます。

さらに adapter の direct SDK access も追加されました。GitHub なら octokit、Linear なら linearClient に触れるので、標準 tool で足りない細い操作だけ provider SDK に降りる形も取りやすくなっています。

ただし、ここで主語を広げすぎないほうが安全です。まず理解すべきなのは、chat/ai が read と write の共通レイヤーを作った ことです。そのうえで GitHub、Linear へ広げると混乱しません。

workflow engine や MCP を置き換える話ではない

便利そうに見えても、chat/ai が workflow engine や MCP を全部不要にするわけではありません。

向いているのは、会話の近くで 1 件ずつ進める bot です。返信、DM、reaction、thread 読み取り、簡単な moderation まではかなり相性がいいです。

一方で、複数 SaaS をまたぐ定期実行、複雑な分岐、再実行管理まで欲しいなら、Zapier、Make、n8n、あるいは独自 runtime がまだ必要です。この整理は ChatGPT apps vs Zapier vs Make vs MCP の切り分けに近いです。

社内独自ツールや認証済みの外部能力を agent へまとめて渡したいなら、MCP や plugin / skills 側の設計も残ります。そこは Codex Plugins vs MCPサーバー vs Composio vs Skills がつながります。

今すぐ始めるならこの順で十分

最初から全部盛りにしなくて大丈夫です。

1. toAiMessages を chat/ai import に寄せる
2. createChatTools({ chat, preset: "messenger" }) を足す
3. write approval は既定のまま残す
4. 実務で必要になった tool だけ override か per-tool approval で緩める
5. GitHub / Linear の親文脈が必要なら message.subject を足す

この順なら、既存 bot を壊しにくく、権限も広げすぎません。

とくに Slack や Teams で bot を運用しているチームは、messenger preset と approval だけでも十分に差を感じやすいはずです。投稿、DM、reaction の全部を自前設計せずに済むからです。

まとめ

Vercel Chat SDK の chat/ai で変わったのは、AI SDK agent に chat workspace の道具を安全に渡しやすくなった ことです。

• createChatTools で read / write actions をまとめて渡せる
• reader、messenger、moderator で権限を絞れる
• write 操作は approval 付きが既定
• toAiMessages は chat/ai へ寄せる移行が始まった
• message.subject と direct SDK access を足すと GitHub / Linear bot まで広げやすい

だから最初の判断は明快です。まず messenger preset と approval 付きで始める。そこが回ってから workflow engine や MCP との役割分担を考えるほうが、実装も運用もブレにくいです。