Cursor 3.1 Canvas登場、エージェントの出力がテキストからインタラクティブUIへ

この記事のポイント

チャットの返答がチャートになる、という感覚を想像してほしい。「このデプロイで何が壊れたか調べて」と入力したら、テキストの箇条書きではなく、タイムライン付きの障害ダッシュボードが現れる。Cursor 3.1で追加された「Canvas」は、まさにその体験を実現する機能だ。

2026年4月15〜16日にリリースされたCursor 3.1は、見た目の変化こそ地味に見えるが、エージェントとのインタラクションの根本的な形を変えようとしている。

Cursor 3との違いを先に整理する

「Cursor 3.1」と「Cursor 3」は、名前の近さに反して力点が異なる。

4月2日リリースのCursor 3が打ち出したのは、複数エージェントを並列実行するオーケストレーション設計——クラウドエージェントとローカルエージェントを同時に走らせ、「ユーザー認証フローを実装して」という粒度の指示を処理するアーキテクチャだった。開発の「作業量」をスケールさせるアップデートだ。

それに対してCursor 3.1が問うのは、エージェントが返してくる「情報の形」だ。どれだけ精度の高い分析をしても、テキストとマークダウンで返ってきた結果を人間が読んで理解するまでにはコストがかかる。Canvasはその変換コストを減らす試みである。

テキストの壁からビジュアルUIへ

Canvasの仕組みはシンプルだ。エージェントが作業を完了したとき、従来のようにチャットウィンドウへマークダウンを出力するかわりに、Reactベースのインタラクティブなインターフェースをその場で生成する。

使えるコンポーネントは、テーブル・ボックス・ダイアグラム・チャートといったファーストパーティ製のライブラリ群、それに既存のCursorツール（Diffビュー・TODOリスト）だ。エージェントがこれらを自律的に選んで組み合わせ、タスクの性質に合ったUIを返す。

生成されたCanvasは、Agents WindowのサイドパネルにターミナルやブラウザやSource Controlと並んで固定表示される。「durable artifact」と公式が呼ぶように、セッションをまたいでも残り続ける。複数ターンの会話が終わっても、あとから見返せるダッシュボードとして機能する。

実際に何ができるか

Cursorチーム自身が社内で使っている事例が公開されているので、それを軸に具体像を掴んでおく。

インシデント調査では、Datadog・Databricks・Sentryなど複数のデータソースをまたいで原因を調べる作業が想定されている。従来は各ツールを切り替えてログを目で追う必要があった。Canvasでは、エージェントがデータを引き寄せて統合し、障害のタイムライン・原因カテゴリ・影響範囲を一枚のダッシュボードにまとめて返す。Cursorチームは「デバッグ時間が大幅に短縮された」と報告している。

PRレビューでは、変更内容がグループ化されて優先度順に並んだビューが生成される。差分の量が多いPRで全体を把握するのにかかる時間が変わるはずだ。コードを読む前に「何がどう変わったか」の地図を持てる。

ライブラリ学習や評価分析も使途として挙げられている。エラーパターンのクラスタリング、実験進捗のリアルタイム可視化。文書を読むより状況を「見る」ほうが速い場面では、Canvasが力を発揮する。

Claude・Geminiの視覚機能との違い

類似した試みはすでに存在する。ClaudeのArtifacts機能や、各種AIチャットのコードプレビューも、エージェント出力をリッチに表示する方向を向いている。

Canvasとの差は、IDEへの統合深度にある。ClaudeのArtifactsはブラウザ上で動作し、コードエディタとは別のコンテキストになる。Canvasはエディタ内のサイドパネルに常駐しているため、デバッグ中のコードの隣で出力が表示される。コンテキストスイッチが発生しない、という点が決定的に違う。

ただし制約もある。自由形式のホワイトボード的な用途よりも、構造化されたエンジニアリングワークフロー（ダッシュボード生成、診断ビュー）に最適化された設計だ。

Cursor Marketplaceとカスタムスキル

Cursor 3.1と同時にCursor Marketplaceもスタートした。Canvas Skillsと呼ばれるカスタム拡張機能を配布する仕組みで、公開初期にはリポジトリの任意のコードベースに対してインタラクティブなアーキテクチャ図を生成するスキルがデモされている。

VS Code拡張機能がそうだったように、エコシステムが育つにつれCanvasの価値も増す。「自分のワークフローに合ったCanvas Skillを入れる」という使い方が、今後の主な拡張パターンになりそうだ。

残る疑問

気になるのは、このアーキテクチャがどこまで汎用になるかだ。

現状のCanvasはCursor社が定義したコンポーネントライブラリで動いている。エンジニアリングタスクに特化したラインナップとして理にかなっているが、たとえばプロダクトマネージャーが使うロードマップビューや、データサイエンティストが使うJupyter的なノートブック形式に対応できるかは不明だ。Marketplaceがこのギャップを埋める役割を担うのか、あるいはCursor自身がコンポーネントを拡充していくのか。

もう一点、Canvas生成の精度問題だ。エージェントがどのコンポーネントを使うかを自律的に判断する設計である以上、「なぜか表で返ってきた」「グラフより数値のほうが分かりやすかった」というズレが起きる可能性がある。出力の形をどこまでユーザーが制御できるか、まだ情報が少ない。

Canvas自体の方向性は明確だ。テキスト出力の時代から、エージェントが状況に応じたUIを自動生成する時代へ。IDEの中でその変化が起きているのは、開発者にとって一番摩擦の少ない場所からパラダイムが変わっていることを意味する。