CopilotKit とは｜AIエージェントをアプリに組み込むGenerative UIフレームワーク

「AI を組み込んだアプリを作ってほしい」と言われたとき、最初につまずくのが「フロントエンドをどう作るか」ではないでしょうか。LLM の API を呼ぶこと自体は経験があっても、チャット UI、エージェントの状態に応じて変化する画面、実行前にユーザーの承認を挟む仕組みまで含めると、自前で作る範囲が一気に膨らみます。

選択肢を調べ始めると、CopilotKit・Vercel AI SDK・assistant-ui といった名前が次々に出てきます。ところが、これらが「どの層を担当するツールなのか」が整理されていないと、比較のしようがありません。CopilotKit を「チャット UI ライブラリ」と捉えてしまうと、その実力を見誤ります。

CopilotKit は、AI エージェントを React や Next.js などのアプリに組み込み、Generative UI（生成 UI）や人間の承認フロー（human-in-the-loop）まで含めて実現するフロントエンドフレームワークです。元は React ライブラリとして始まりましたが、現在はモバイルや Slack まで対応するマルチプラットフォームのエージェントフレームワークへと拡張しています。

この記事では、CopilotKit の主要機能と仕組み、対応スタック、そして Vercel AI SDK や assistant-ui との層の違いを、公式 README とドキュメントをもとに整理します。最終的に「自分のプロジェクトに CopilotKit を採用すべきか」を判断するための軸を持ち帰れることをゴールにしています。

なお本記事は、リポジトリの動作検証は行わず、公式 README・公式ドキュメント・公式サイトの記載をもとに構成しています。数値・事実は調査時点（2026年6月）の公開情報に基づきます。

CopilotKit とは｜AIエージェント時代のフロントエンドスタック

CopilotKit は、一文で言えば「エージェントネイティブなアプリケーションを、任意のフレームワーク・任意のサーフェス（Web/モバイル/Slack など）で構築するためのフロントエンドスタック」です。公式 README では「The Frontend Stack for Agents & Generative UI」と位置づけられています（出典: CopilotKit 公式 README）。

ここで重要なのは、CopilotKit が単なるチャット画面の部品集ではないという点です。もともとは React ライブラリとして始まったものの、現在は同じエージェントロジックを Web アプリ・モバイルアプリ・Slack ワークスペースで動かせるマルチプラットフォームのエージェントフレームワークへと発展しています。さらに CopilotKit は、エージェントと UI のあいだのやり取りを標準化する AG-UI Protocol の開発元でもあり、このプロトコルは Google・LangChain・AWS・Microsoft・Mastra・PydanticAI などに採用されています。

まずは採用判断の土台として、リポジトリの基本情報を確認しておきましょう。

スター数 35,236 は OSS としては大きな支持を集めている水準で、最終更新も新しく、アーカイブされたプロジェクトでもフォーク版でもありません。つまり、現在進行形でメンテナンスされている本家リポジトリです。ライセンスは MIT のため、商用プロダクトへの組み込みも比較的扱いやすい条件と言えます（実際の適用にあたっては各自でライセンス条項を確認してください）。

これらの客観情報は、後述する採用判断において「メンテナンスが止まっていないか」「ライセンス上の懸念はないか」というチェック項目に直接効いてきます。

CopilotKit の主要機能と仕組み

CopilotKit を採用するかどうかを考えるうえで最も実利的な問いは、「これを使うことで、何を自前実装せずに済むのか」です。公式 README の Features を、その観点で整理します（出典: CopilotKit 公式 README）。

Chat UI と Generative UI

1つ目が、チャット UI と Generative UI です。CopilotKit はメッセージのストリーミング、ツールコール、エージェント応答に対応したカスタマイズ可能なチャット UI を提供します。自動スクロールやストリーミング表示といった、自前で作ると地味に手間のかかる部分を肩代わりしてくれます。

Generative UI はもう一歩踏み込んだ機能です。エージェントがバックエンドのツールを呼び出すと、その戻り値を固定のテキストではなく、React コンポーネントとして画面に描画できます。ユーザーの意図とエージェントの状態に応じて、UI コンポーネントを実行時に動的生成・更新する、という考え方です。たとえば「在庫を調べて」という指示に対し、エージェントの応答を表やカードのコンポーネントとして表示する、といった使い方が想定されます。

Shared State と Human-in-the-Loop

2つ目が、Shared State と Human-in-the-Loop です。Shared State は、エージェントと UI コンポーネントの双方がリアルタイムに読み書きできる同期状態レイヤです。エージェントが持っている状態と画面の状態を別々に管理して同期処理を書く、という煩雑さを避けられます。

Human-in-the-Loop は、エージェントが実行を一時停止し、ユーザーの入力・確認・編集を求めてから処理を続行する仕組みです。AI に任せきりにせず「実行前に人間が承認する」フローは、業務システムでは特に求められやすいポイントで、これを枠組みとして提供している点は採用検討時の判断材料になります。

このほか、ユーザーフィードバックから継続的に改善する Self-Learning（CLHF: Continuous Learning from Human Feedback）が early access として挙げられています。

CopilotKit Runtime と useAgent フック

3つ目が、バックエンド側とフロントエンド側をつなぐ仕組みです。公式ドキュメントでは、バックエンド実装に対応したプロセス内エージェント実行環境として CopilotKit Runtime が、エージェント機能へのヘッドレスアクセスを提供するフックとして useAgent が紹介されています（出典: CopilotKit 公式ドキュメント）。

useAgent は AG-UI の上に直接乗っており、エージェント接続をプログラム的に制御できます。README には次のコード例が掲載されています。

// Programmatically access and control your agents
const { agent } = useAgent({ agentId: "my_agent" });

// Render and update your agent's state
return <div>
  <h1>{agent.state.city}</h1>
  <button onClick={() => agent.setState({ city: "NYC" })}>
    Set City
  </button>
</div>

（出典: CopilotKit 公式 README）

このコードからは、エージェントの状態（agent.state）を React の値として参照し、agent.setState で更新できることが読み取れます。チャット画面に縛られず、ボタンや任意の UI からエージェント状態を制御できるヘッドレスな設計になっている、という点が要点です。useAgent の詳細はuseAgent 公式ドキュメントで確認できます。

CopilotKit は、このように UI・エージェント・ツールを単一のインタラクションループに接続することで、ステップやセッションをまたぐステートフルなワークフローを、1つのエージェントとして Web・モバイル・チャットプラットフォームに横展開できるよう設計されています。

対応フレームワークとマルチサーフェス展開

採用判断で次に気になるのは「自分のスタックで使えるのか」「将来モバイルや Slack に広げられるのか」でしょう。CopilotKit の README には対応スタックの一覧が掲載されています（出典: CopilotKit 公式 README）。

React/Next.js は GA（正式提供）で、Angular・Vue・React Native もサポート対象に入っています。Slack・Microsoft Teams・Discord・Google Chat といったチャットプラットフォームへの展開は Beta（early access）段階です。React/Next.js が主戦場のエンジニアにとっては、まず安定して使える層が揃っているという見方ができます。

このマルチサーフェス展開を支えているのが、先ほど触れた AG-UI Protocol です。README では「エージェントロジックは同じまま、AG-UI がワイヤープロトコルを、CopilotKit が各フレームワーク向け UI レイヤを担当する」と説明されています。つまり、エージェント本体のロジックを書き換えずに、表示先のサーフェスだけを増やしていける設計思想です。AG-UI Protocol 自体はAG-UI Protocol リポジトリで公開されており、CopilotKit が策定した、エージェントとユーザーインターフェース間の標準プロトコルとして独立して管理されています。

バックエンド側の対応も幅広く、公式ドキュメントによれば LangGraph（Python/TypeScript）、Google ADK、AWS Strands、Mastra、PydanticAI、Microsoft Agent Framework、LlamaIndex、CrewAI など 12 種以上のエージェントフレームワークと連携できます（出典: CopilotKit 公式ドキュメント）。すでに特定のエージェントフレームワークでバックエンドを組んでいる場合でも、フロントエンド層として CopilotKit を後付けできる余地がある、という点は確認しておきたいところです。

なお、デプロイ形態としてはセルフホスティングと、CopilotKit が提供する Cloud 版の2通りが用意されています。

類似OSSとの違い｜Vercel AI SDK・assistant-uiとの使い分け

ここが、検索者にとって最大の関心事ではないでしょうか。CopilotKit・Vercel AI SDK・assistant-ui は、いずれも「AI をアプリに組み込む」文脈で名前が挙がりますが、担当している層が異なります。混同したまま比較すると判断を誤るため、まず層の違いを押さえます。

（各スター数は調査時点の各リポジトリ公開値。出典: CopilotKit / assistant-ui / Vercel AI SDK）

Vercel AI SDK はロジック層

Vercel AI SDK（vercel/ai）は、モデル呼び出し・ストリーミング・ツールコールを抽象化する TypeScript の AI ツールキットです。位置づけとしては「モデルと話すための配管」にあたり、チャット UI は自前で構築するか、別途 AI Elements などを利用する前提です。AI SDK 3.0 以降は RSC（React Server Components）ベースの Generative UI に対応していますが、中心はあくまでロジック層です。

「モデル呼び出しの抽象化さえあればよく、UI は完全に自分でコントロールしたい」というケースでは Vercel AI SDK が向きます。

assistant-ui はチャット UI レイヤ

assistant-ui（assistant-ui/assistant-ui）は、AI チャット UI を構築するためのヘッドレス React プリミティブです。shadcn/ui と Tailwind をベースにした ChatGPT 風の UI を提供し、ストリーミング・自動スクロール・リトライ・添付・Markdown・コードハイライトといったチャット体験の作り込みを担います。バックエンドは Vercel AI SDK や LangGraph、任意の API を選んで接続する構成です。

「チャット UI の完成度を重視し、バックエンドは別途自由に選びたい」というケースでは assistant-ui が候補になります。

CopilotKit はエージェント↔UI 統合フレームワーク

これらに対し CopilotKit は、チャット UI の提供にとどまらず、Shared State による状態同期、Generative UI、Human-in-the-Loop、さらに Web/モバイル/Slack/Teams へのマルチサーフェス展開までを一体で扱います。AG-UI プロトコルを自社開発し、エージェント連携の標準化を志向している点が、UI レイヤ特化の assistant-ui やロジック層中心の Vercel AI SDK との大きな違いです。

ざっくり整理すると、Vercel AI SDK が「モデルと話す配管」、assistant-ui が「チャット UI の完成品」だとすれば、CopilotKit は「エージェントとアプリ UI を双方向に結ぶ統合層」という位置づけになります。なお、これらは必ずしも排他的な選択肢ではなく、assistant-ui が Vercel AI SDK をバックエンドに接続するように、層が異なるツールを組み合わせる構成もあり得ます。

CopilotKit が向くケース・向かないケース

ここまでの整理を踏まえ、採用判断を後押しする観点をまとめます。

CopilotKit が向くのは、次のようなケースです。

• 生成 UI・状態同期・承認フローが必要: エージェントの応答を React コンポーネントとして描画したい、エージェントと UI の状態をリアルタイムに同期したい、実行前にユーザーの承認を挟みたい、といった要件があるとき。これらを自前で作る工数を肩代わりできます。
• マルチサーフェス展開を見込む: 今は Web だけでも、将来モバイルや Slack にも同じエージェントを広げたいとき。AG-UI を基盤にサーフェスを増やす設計が活きます。
• 完成した UI を早く出したい: CopilotChat などの完成済みコンポーネントを使い、UI 構築の初速を上げたいとき。

一方、次のようなケースでは慎重に検討する余地があります。

• 公開コンテンツの SSR/SEO が最優先: 生成 UI はクライアント側で動的に描画される性質上、サーバーサイドレンダリング（SSR）前提の SEO が最重要な公開ページとは相性を見極める必要があります。
• 単純なストリーミングチャットだけで足りる: 状態同期や承認フロー、マルチサーフェスが不要で、シンプルなチャットだけが目的なら、より軽量な選択肢（チャット UI 特化の assistant-ui や、ロジック層の Vercel AI SDK を自前 UI と組み合わせる構成）の方が過不足ないこともあります。

メンテナンスの健全性という観点では、スター数 35,236、最終更新が新しくアクティブに開発が継続している点、MIT ライセンスである点、そして基盤の AG-UI Protocol が Google・AWS・Microsoft などに採用されている点が、安心材料として挙げられます。アーカイブ済みでもフォーク版でもない本家リポジトリである点も、長期採用を検討するうえでの前提条件を満たしています。

実際にどんなアプリが作れるのかをイメージしたい場合は、ダッシュボードアシスタントや旅行プランナー、フォーム自動入力などを集めたCopilotKit 公式サイトの Examplesが、ユースケースの具体像を掴む手がかりになります。

まとめ｜CopilotKit を採用判断する3つの観点

CopilotKit を「自分のプロジェクトに採用すべきか」を判断するときは、次の3つの観点で整理すると見通しが良くなります。

1. 機能で肩代わりできる範囲: Generative UI・Shared State・Human-in-the-Loop・完成済みチャット UI のうち、自分が自前実装を避けたいものがどれだけ含まれるか。該当が多いほど採用メリットが大きくなります。
2. 自分のスタックとサーフェス要件: React/Next.js は GA、Angular/Vue/React Native はサポート、Slack/Teams 等は Beta という対応状況と、将来のマルチサーフェス展開の見込みが、自分の要件と合っているか。
3. 競合との層の違い: モデル呼び出しのロジック層なら Vercel AI SDK、チャット UI レイヤなら assistant-ui、エージェントと UI を双方向に結ぶ統合層なら CopilotKit、という棲み分けに照らして、自分が本当に必要としている層はどこか。

これらを自分のプロジェクト要件に当てはめれば、CopilotKit を採用するか、より軽量な別ツールにするかの判断軸が見えてくるはずです。具体的な導入手順や API の詳細を確認したい場合は、CopilotKit 公式ドキュメントが次の一歩になります。