tambo

生成コンポーネントは、メッセージへの応答として一度レンダリングし、その後はそこに留まる。名前、説明、propsスキーマとともにコンポーネントを登録すると、エージェントがいつ表示するかを決める。グラフ、データ可視化、サマリーカードがこのパターンに当てはまる。propsはエージェントが書くので、既存のスタイルとロジックはそのまま生きる。ユーザーが前四半期の数字の内訳を求めれば、読み解く必要のあるテキストの壁ではなく、自社ブランドカラーの本物のグラフが返る。

インタラクティブコンポーネントはページに残り、会話をまたいでIDで更新される。ショッピングカート、タスクボード、スプレッドシートは、ユーザーがチャットを続ける間も状態を保つ。AIは答えを吐き出すのをやめ、自分のインターフェースの生きた一部分を編集し始める。このパターンがTamboを素のテキストチャットボットと分ける。大きな違いだ。

Tamboは独自のエージェントを同梱するので、外部フレームワークを継ぎ足す必要はない。応答が届くそばから、段階的なprops更新、メッセージスレッド履歴、エラー処理を担う。ユーザーはデータが流れるにつれてコンポーネントが埋まっていくのを見る。これは完全な応答を待つより速く感じられる。AI体験の退屈な部分を無料で手に入る。そこが要点だ。キャンセル処理を5度も作り直したい者はいない。

SDKはModel Context Protocolを通じてデータベース、API、外部システムに接続する。これでエージェントは実データに手が届き、でっち上げずに済む。クライアント側でもサーバー側でも動く。すでにMCPサーバーを動かすチームにとって、エージェントに手を与える最もすっきりした方法だ。既存のデータベースをチャット駆動のインターフェースにつなぐには、以前はソースごとに専用の連携が要った。これがその作業を単一の接続点に畳み込む。

バックエンドの動かし方は自分で選ぶ。完全な制御のためにセルフホストするか、管理されたキーで素早く始めるためにTambo Cloudを使う。スターターCLIがAPIキーをenvファイルに直接書き込むので、最初のリクエストはほとんど手間なく動く。設定を探し回る必要はない。データ規則の厳しいチームはすべてを自社の壁の内側に置け、ただ出荷したいチームはホスト型の選択肢に頼ってサーバー設定に一切触れずに済む。

登録は宣言的だ。コンポーネントを記述し、Zodで組み立てたpropsスキーマを渡すと、エージェントがその取り決めを使って有効なpropsをストリーミングする。このパターンはZodに頼るので、多くのReactチームがすでに使う作業の流れにそのまま馴染む。手動のルーティングなしでコンポーネントが正しい場所に現れることも意味する。つなぎのコードは不要。switch文も不要だ。