tamboとは｜LLMがReactのUIを組み立てる『生成UI』SDKの仕組みと使い方を実機解説

tambo（tambo-ai/tambo）は、LLMがあなたのReactコンポーネントを選び、propsを流し込んで動くUIを組み立てる「生成UI（Generative UI）」のためのReact向けSDKです（GitHubスター11,155・MIT）。ここ数年、私たちがLLMに作らせてきたのは、ほとんどが「文章」でした。チャットボックスに質問を打ち、返ってくるのはテキスト。せいぜいMarkdownの表やコードブロックが混ざる程度です。tamboが挑むのはその一段先——「LLMの出力そのものを、ユーザーが操作できる本物のUIにする」という発想です。「地域別の売上を見せて」と言えば、テキストの代わりにあなたの <Chart> が描かれ、「タスクを追加」と言えば <TaskBoard> が更新される。

まず、tamboが実際に何をするのかを1本のデモで見てください。ユーザーの発話に応じて、チャットの返答ではなくインタラクティブなUIそのものが組み上がっていく様子です。

なお、「AIにUIを一貫して作らせる」という営みの全体像——デザイントークン・コンポーネント・ガイドラインの3層構造やClaude Design連携までは、当サイトのデザインシステムとは？仕組み・構成要素・有名事例をエンジニア向けに完全解説にまとめています。本記事はその中でも「LLMが実行時にUIを組み立てる」という一角を、tamboという具体的な実装で深掘りする位置づけです。

tamboとは — LLMがReactコンポーネントを選んで組み立てる「生成UI」SDK

tamboを一言でいえば、「エージェントに、あなたのUIを喋らせる」ツールです。公式のタグライン “Build agents that speak your UI” がそれを端的に表しています。もう少し噛み砕くと、tamboはあなたが用意したReactコンポーネント群を、LLMが状況に応じて選び・描画するための橋渡しをします。

仕組みの核心はシンプルです。あなたはコンポーネントを Zodスキーマ（そのコンポーネントが受け取るpropsの型定義）と一緒に登録します。tamboはこのスキーマを LLMのツール定義（tool definition） に変換します。するとLLMは、ユーザーの発話に対して「このツール（＝コンポーネント）を、この引数（＝props）で呼ぶ」と判断できるようになる。tamboはその判断を受け取り、対応するReactコンポーネントをpropsをストリームしながら画面に描画します。つまりLLMにとってコンポーネントは「呼べる関数」であり、その戻り値が「画面に現れるUI」になる、という構図です。

ここで押さえておきたいのは、tamboはエージェント本体を置き換えるものでも、UIを自動デザインするツールでもないという点です。tamboは「LLMの意思決定」と「あなたのReact部品」を接続する層で、描かれるUIの見た目・使い勝手・アクセシビリティは、あくまであなたが書いたコンポーネントそのものが決めます。tamboが自動化するのは選択と配線であって、デザインではありません。この線引きは後で詳しく扱います。

tamboは単なるフロントエンドのラッパーではなく、SDK＋バックエンドのフルスタックとして設計されています。Reactの@tambo-ai/react SDKに加えて、会話の状態管理とエージェント実行を担うバックエンドが付き、これをTambo Cloud（ホスティング版・無料枠あり）で使うか、同じものをDockerでセルフホストするかを選べます。LLMは自前のAPIキーを持ち込む方式（BYOK）で、OpenAI・Anthropic・Google Gemini・Mistral・Cerebras、そしてOpenAI互換の任意のプロバイダーに対応します。

「生成UI（Generative UI）」は何が新しいのか — チャットUI・フォーム生成との違い

日本語では「生成UI」という言葉自体がまだ耳慣れないので、ここを丁寧に整理します。結論から言うと、生成UIが新しいのは「LLMの出力の“型”が、テキストからUIコンポーネントへ変わる」点にあります。

これまでのAIアプリを大きく3世代で捉えると分かりやすくなります。第1世代は「チャットUI」。LLMが返すのは文章で、画面はそれをそのまま（あるいはMarkdownとして）流すだけでした。ChatGPT風のUIがこれにあたります。表現力はテキストの範囲に閉じ、ユーザーは「読む」ことしかできません。第2世代は「AIフォーム生成／テンプレート生成」。LLMにフォームやページの“設計図”を一度出力させ、それをレンダリングする方式です。動的ではありますが、多くは一度作って終わりで、生成後のインタラクションや状態はLLMの外側にあります。

第3世代が「生成UI」です。LLMが返すのは文章でも静的な設計図でもなく、「どのコンポーネントを、どんなpropsで、今この瞬間に描くか」という指示です。その結果、テキストではなくあなたの本物のReactコンポーネント——チャート、カート、タスクボード、地図——が画面に現れ、ユーザーはそれをクリックし、編集し、操作できます。しかもtamboでは、propsが生成されるそばからストリーミングで流れ込むため、UIは「一気に出る」のではなく「LLMが考えながら描いていく」ように立ち上がります。

もう一つの新しさは、生成UIがアプリの“主UI”になりうることです。従来の「チャットは画面の隅のウィジェット」という発想を超えて、tamboは「アプリのUI全体を対話で制御する」用途まで想定しています（後述の比較表で “Best for: Full app UI control” と位置づけられているのはこのためです）。ユーザーが自然言語で意図を伝え、アプリがそれに応じて必要な部品を組み替えていく——これが生成UIの目指す体験像です。

tamboはどう動くのか — Zodで登録し、LLMが選び、propsがストリームする

では実際の流れを見ましょう。tamboの動作は、大きく「①登録 → ②選択 → ③ストリーム描画」の3ステップに分けられます。

①登録：まず、LLMに使わせたいコンポーネントを、名前・説明・Zodスキーマ付きで配列に登録します。説明（description）はLLMが「いつこの部品を使うべきか」を判断する手がかりになり、propsSchema はそのまま「LLMが埋めるべき引数の型」になります。下は公式READMEの例で、Rechartsで折れ線／棒／円グラフを描く Graph コンポーネントを登録しています。

const components: TamboComponent[] = [
  {
    name: "Graph",
    description: "Displays data as charts using Recharts library",
    component: Graph,
    propsSchema: z.object({
      data: z.array(z.object({ name: z.string(), value: z.number() })),
      type: z.enum(["line", "bar", "pie"]),
    }),
  },
];

②選択：登録されたスキーマは、tamboによってLLMのツール定義へ変換されます。ユーザーが「地域別の売上を棒グラフで」と言えば、LLMは Graph ツールを type: "bar"、data: [...] という引数で呼ぶと決めます。ここは通常のツール呼び出し（function calling）と同じ仕組みですが、戻り値が「実行結果のテキスト」ではなく「画面に描かれるReactコンポーネント」である点がtamboならではです。

③ストリーム描画：tamboはLLMが生成したpropsを受け取り、Graph コンポーネントを描画します。このとき、propsは生成と同時にストリーミングで流れ込み、キャンセル・エラー復帰・再接続はtamboが面倒を見ます。アプリ側はコンポーネントを TamboProvider で包み、useTambo() などのフックでメッセージやストリーミング状態を受け取るだけです。

<TamboProvider
  apiKey={process.env.NEXT_PUBLIC_TAMBO_API_KEY}
  userKey={currentUserId}
  components={components}
>
  <Chat />
</TamboProvider>

この一連の流れを図にすると、こうなります。

主要なフックも押さえておきましょう。useTambo() が中心で、messages（会話履歴）や isStreaming（生成中フラグ）、スレッド管理を返します。ユーザー入力の受け付けは useTamboThreadInput() が担い、入力値の管理と送信（submit）を扱います。UIコンポーネント側は、これらのフックから状態を受け取って描画するだけで、LLMとの通信そのものを意識する必要はありません。

何が同梱され、どこからが自分の担当か — tamboの守備範囲

読者が最も知りたいのは、たぶんここでしょう——「結局、tamboを入れると何が省けて、何は自分で書くのか」。生成UIは魔法のように聞こえますが、tamboが自動化するのは明確に「配線」の部分だけで、UIの中身は依然としてあなたの仕事です。境界を正直に引きます。

tamboが同梱・肩代わりするもの（＝配線）は、公式が挙げる3本柱で整理できます。ひとつ目はエージェント（会話ループ）。LLMとのやり取りのループをtambo側で回してくれるので、リクエスト整形やツール呼び出しの往復を自前で書かずに済みます（LangChainやMastraと併用も可能ですが必須ではありません）。ふたつ目はストリーミング基盤。propsが生成されるそばからコンポーネントへ流れ込み、キャンセル・エラー復帰・再接続まで面倒を見ます。みっつ目はバックエンド。会話の状態管理とエージェント実行を担うサーバーが付き、Tambo Cloud（ホスティング）かDockerセルフホストで動かせます。加えて、スレッド（会話）の永続化、コンポーネント選択、MCPサーバーとの接続もtambo側の担当です。

あなたが書くもの（＝中身）は、拍子抜けするほど「普通のReact開発」です。表示するReactコンポーネントそのもの、その propsSchema（Zod）、登録リスト、LLMのAPIキー、そしてアプリの残りの部分。tamboはUIをデザインしません。渡された部品の中から選んで組み立てるだけなので、見た目・レスポンシブ・アクセシビリティ・ブランドは、すべてあなたのコンポーネントの品質に依存します。逆に言えば、既存のデザインシステムやコンポーネントライブラリをそのまま活かせる、ということでもあります。

この線引きを理解しておくと、「tamboを入れれば綺麗なUIが自動で出てくる」という誤解を避けられます。tamboの価値はあなたの既存の（あるいはこれから作る）コンポーネントを、対話から呼び出せるようにすることにあり、コンポーネント自体の質は依然としてあなたの実装力にかかっています。

Generative と Interactable — 2種類の生成コンポーネント

tamboのコンポーネントには、性格の異なる2種類があります。この区別は生成UIを設計するうえで重要なので、実機のデモとあわせて見ていきます。

ひとつ目が Generative Components（生成コンポーネント） です。これは「メッセージへの応答として一度だけ描かれる」使い捨てに近い部品で、チャート・サマリー・データ可視化などが典型です。ユーザーが「先月の売上は？」と聞けばグラフが描かれ、それは基本的にその応答のためのもの。下のデモは、発話に応じてチャートやカードがその場で生成される様子です。

ふたつ目が Interactable Components（インタラクタブル・コンポーネント） です。こちらは「会話をまたいで状態を保ち、ユーザーの要求の変化に応じて更新され続ける」永続的な部品で、ショッピングカート・スプレッドシート・タスクボードのように「作って終わり」ではないUIに向いています。既存のReactコンポーネントを withInteractable でラップし、名前・説明・スキーマを与えると、LLMがそのコンポーネントの状態を継続的に更新できるようになります。

const InteractableNote = withInteractable(Note, {
  componentName: "Note",
  description: "A note supporting title, content, and color modifications",
  propsSchema: z.object({
    title: z.string(),
    content: z.string(),
    color: z.enum(["white", "yellow", "blue", "green"]).optional(),
  }),
});

下のデモでは、ノートやボードのような部品が対話のたびに更新され、状態を保ち続ける様子が見て取れます。「タイトルを変えて」「色を黄色に」といった追いリクエストが、同じコンポーネントに反映されていきます。

どちらを使うかは「そのUIが一度きりの回答か、継続的に触り続ける道具か」で決めると自然です。ダッシュボードの単発チャートはGenerative、ユーザーが育てていくタスクボードはInteractable、という具合です。

MCP・ローカルツール・認証 — 生成UIに「手足」を持たせる

生成UIが「見せる」だけで終わらず、実際にデータを取ってきて操作するためには、LLMに“手足”が要ります。tamboはこの部分も内蔵しています。

最も強力なのが MCP（Model Context Protocol）連携 です。tamboは @tambo-ai/react/mcp を通じてMCPサーバーに接続でき、tools・prompts・elicitations・sampling というMCPの主要な機能をフルに扱えます。これによって、Linear・Slack・データベース、あるいは自作のMCPサーバーを、生成UIの背後にそのままつなげられます。「Linearの今週のissueをボードで見せて」といった発話が、MCP経由で実データを取得し、それをInteractableなボードに描く——といった連携が構成できます。当サイトでもMCPサーバーの構築・一元管理は継続的に扱っているテーマで、tamboはその「フロント側の受け皿」に位置づけられます。

MCPサーバーを立てるまでもない「ブラウザ内で動く関数」は、ローカルツールとして登録できます。DOM操作、認証付きのfetch、Reactの状態へのアクセスなど、クライアント側でしか実行できない処理を TamboTool として定義しておくと、LLMがそれを関数として呼べます。たとえば「現在地の天気を取得する」getWeather を登録すれば、ユーザーの発話に応じてLLMがその関数を呼び、結果を生成UIに反映できます。ローカルツールは inputSchema / outputSchema をZodで持つため、ここでも型が一貫して効きます。

さらに実用面を支える3つの補助機能があります。Additional context（追加コンテキスト） は、ユーザーの状態・アプリ設定・現在ページといったメタ情報をLLMに渡して回答精度を上げる仕組み。User authentication（ユーザー認証） は、自前の認証プロバイダーのトークンを渡してスレッドの所有者を識別する仕組みで、サーバー環境なら userKey、クライアント環境ならOAuthアクセストークンを含む userToken を使い分けます。Suggestions（提案） は、ユーザーが今やっていることに基づいて「次に打てるプロンプト」を生成し、クリックで実行できるようにする機能です。これらを組み合わせると、単なるチャット窓ではなく「文脈を理解して先回りする」UIに近づきます。

既存の代替と何が違うのか — Vercel AI SDK / CopilotKit / assistant-ui 比較

「生成UIやAIチャットのライブラリなら、すでにVercel AI SDKやCopilotKitがある。何が違うのか」——当然の疑問です。以下はtamboの公式リポジトリが掲げる比較を基に、編集部で各項目を確認しつつ整理したものです（比較はtambo側の視点である点は割り引いて読んでください。最終的には各プロジェクトの最新ドキュメントで確認するのが確実です）。

この表から読み取れるtamboの立ち位置は明確です。Vercel AI SDKは「ストリーミングとツール抽象化」に強い低レベル寄りのツールキットで、どのコンポーネントを描くかは開発者が手動で対応づけます。tamboはその「対応づけ」自体をLLMに委ねる方向です。CopilotKitはLangGraph等のエージェントフレームワークを軸にした「マルチエージェント・ワークフロー」寄りで、tamboよりエージェント基盤の色が濃い。assistant-uiは名前のとおり「チャットUI」に主眼があり、永続的なステートフル部品やクライアント側ツール実行は守備範囲外です。

つまりtamboが際立つのは、「LLMがコンポーネントを選ぶ」＋「永続的なInteractable部品」＋「MCP組み込み」＋「SDKとバックエンドの両方がMITでセルフホスト可能」 という組み合わせです。とはいえ、これらは重なる領域も多く、「チャット窓だけ欲しい」ならassistant-ui、「まずストリーミング配線だけ薄く欲しい」ならVercel AI SDK、というように目的次第で最適解は変わります。tamboが向くのは、「アプリのUIそのものを対話で組み立てたい」という、より踏み込んだユースケースです。

使えるのか — ライセンス・活性度・バス係数・企業サポートの正直な評価

自分のReactアプリに入れる価値があるかを判断するために、良い点と、正直に見ておくべき点を並べます。

良い点は明快です。ライセンスはMIT（一部の apps/api ワークスペースのみApache-2.0）で、著作権表記は Fractal Dynamics Inc.——つまり個人の趣味プロジェクトではなく企業が主導しています。コントリビューターは約60名と一定の広がりがあり、最終pushは2026年7月18日（当日）、npmの @tambo-ai/react は1.3.0系で直近1週間のダウンロードは約9,554件（いずれも2026年7月18日時点の実測）。SDKだけでなくバックエンドもMITでセルフホスト可能なので、ベンダーロックインを避けたいチームでも採用の土台があります。BYOKでモデルを自由に選べる点、MCPと自作ツールをそのまま活かせる点も、既存のAI資産を持つチームには効きます。

一方で、正直に見ておくべき点が3つあります。

① 生成UIという分野自体がまだ新しい。 tamboは2024年6月公開で1.0を迎えていますが、「LLMがUIを組み立てる」というパラダイム自体が黎明期です。ベストプラクティスや設計パターンは各社まだ手探りで、APIやコンセプトが今後変わる可能性はVercelやCopilotKitを含め業界全体で織り込む必要があります。本番の基幹UIに全面採用する前に、限定機能でのPoCから始めるのが無難です。

② UIの品質は結局あなた次第。 前述のとおりtamboはUIをデザインしません。生成UIの体験の良し悪しは、登録するコンポーネントの完成度・アクセシビリティ・レスポンシブ対応にそのまま乗ります。「入れれば綺麗になる」ツールではなく「良い部品を良く使えるようにする」ツールだと理解しておくべきです。

③ LLMの選択ミス・ハルシネーションは前提。 LLMが「どの部品をどのpropsで」を決める以上、時に不適切なコンポーネントを選んだり、propsに妙な値を入れたりします。Zodスキーマによるランタイム検証がある程度の防波堤にはなりますが、ユーザーに見せて良い結果かの最終責任はアプリ側にあります。重要な操作（削除・購入など）は生成UI任せにせず、確認ステップを挟む設計が要ります。

導入と確認 — コピペで動かす5分

最短で体験するなら、公式のスキャフォールドが一番速いです。gitの初期化とtamboのセットアップまで自動で済みます。

npm create tambo-app my-tambo-app  # git初期化＋tamboセットアップまで自動
cd my-tambo-app
npm run dev

バックエンドはTambo Cloud（無料枠あり・ホスティング）を使うか、Dockerでセルフホストするかを選べます。まず動かして感触を掴むならCloudの無料枠が手軽で、本番でデータを外に出したくない要件があればセルフホストに切り替える、という段取りが現実的です。ゼロから組み込むのではなく、既存のテンプレートをフォークして始める道もあります（公式は「AI Chat with Generative UI」「AI Analytics Dashboard」の2テンプレートを用意しています）。あわせて、ui.tambo.co にはメッセージスレッドやフォーム、データ可視化などのプリビルドのコンポーネントライブラリが公開されており、自分でゼロから部品を書かずに生成UIの骨格を組めます。

導入したら、「本当に動いているか」を自分の環境で確認しておきましょう。以下はいずれも破壊的操作を伴わない読み取り系のチェックです。

# 1) SDKが入っているか（バージョン確認）
npm ls @tambo-ai/react

# 2) 環境変数にTamboのAPIキーが設定されているか
grep -n "TAMBO_API_KEY" .env.local

# 3) 開発サーバーを起動し、ブラウザでチャットにコンポーネントを描かせてみる
npm run dev

なお、AIにUIそのものを生成させる隣接ツールとしては、Claude Designとは｜料金・始め方・使い方とFigma・v0比較を実画面つきで解説 も参考になります。tamboが「既存の部品を対話から呼び出して組み立てる」のに対し、Claude Designは「UIをゼロから生成する」側で、担当領域が異なります。既製のレイアウト集を土台にしたい場合は、Square UI解説｜shadcn/uiレイアウト20種を実機デモで全検証｜MITから独自ライセンスへ のようなshadcn/uiベースのコンポーネント群が、tamboに登録する部品の出発点になります。

まとめ — tamboは「LLMにUIを喋らせる」ための配線層

tamboは、「LLMが文章を返す」時代から「LLMがあなたのReactコンポーネントを選び、propsを流し込んで、操作できるUIを組み立てる」時代へ橋を架けるSDKです。Zodスキーマでコンポーネントを登録すれば、選択・ストリーミング・状態管理・MCP連携という、これまで各チームが毎回作り直していた「配線」をtamboが肩代わりしてくれる。あなたが集中すべきは、良いコンポーネントと良いスキーマを書くこと——つまり、いつものReact開発です。

同時に、過大評価は禁物です。tamboはUIをデザインしないし、生成UIという分野自体がまだ黎明期で、APIやベストプラクティスは動いていく。LLMの選択ミスも前提に、重要操作には確認ステップを挟む必要があります。それでも、MIT・企業主導・セルフホスト可・BYOK・MCP組み込みという土台は堅く、「アプリのUIを対話で組み立てる」体験を最短で試せる選択肢として、tamboは有力です。まず1コンポーネントを登録して、LLMがそれを選んで描く瞬間を自分の目で見る——生成UIの手触りは、そこから掴めます。

参照ソース

・tambo（tambo-ai/tambo 公式リポジトリ） — スター・ライセンス・コミット・README・デモ動画の実測
・Tambo 公式ドキュメント（docs.tambo.co） — Provider・フック・コンポーネント・認証の仕様
・Introducing Tambo: Generative UI for React（公式ブログ・1.0アナウンス） — 生成UIの位置づけと1.0の発表
・MCP Integration（公式ドキュメント） — MCP連携（tools/prompts/elicitations/sampling）
・@tambo-ai/react（npm） — バージョン（1.3.0系）・週次ダウンロード数の実測