2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Cursorの新しいCanvas、正直かなり効く。AIの返答が「文章」から「使う画面」に変わり始めた話

2
Posted at

アップロード容量が月の制限(100MB)を超えました。設定 -> アップロードしたファイル から、当月にアップロードされた不要なファイルの削除を行ってください。

正直、最初はスルーしかけた。

「AIがインタラクティブなキャンバスを作れます」と言われても、見た目がちょっと派手になっただけじゃないの、と思ったからです。

でも読み返して、使いどころを想像したら印象が変わりました。

これ、AIの出力形式が変わったという話なんですよね。コードを書くか、文章で説明するか、その二択だったものが、「その場で使える画面を返す」方向に一段進んだ。 ## これ、何が起きたのか

今回のポイントはシンプルです。

Cursorは、情報を文章やMarkdownで返すだけでなく、操作できるUIとして返せるようになった。

しかも単なる画像じゃありません。表、図、チャート、差分表示、ToDoのような部品を組み合わせて、依頼に合わせたカスタム画面を出せる。しかもそれがAgents Windowの中で、ターミナルやブラウザ、ソース管理と並ぶ“道具”として残る。ここがかなり大きいです。 Cursor

たとえば障害対応なら、ログや時系列データを読ませて、スパイクや異常値を見やすい形にまとめる。

PRレビューなら、変更をただ上から順に読むんじゃなくて、重要な差分をまとめて、どこから見るべきかを整理してくれる。Cursor自身がそういう使い方を例として挙げています。 Cursor

これ、レストランで言えば「厨房から料理だけ出てくる」状態から、「食べやすく盛り付けて、必要なら取り分けまでして出してくれる」状態に近いです。

素材は同じでも、理解にかかる体力がぜんぜん違う


なぜ今、この話が刺さるのか

ここが面白いところで、半年前ならここまで刺さらなかったと思うんです。

理由は、AIがまだ「一発でコードを書くやつ」として見られがちだったから。

でも今のCursorは、Agents Windowで複数エージェントを並行に走らせたり、ローカルとクラウドを行き来させたり、ブラウザやプラグインとつなげたりと、エージェント中心の作業場に寄ってきています。つまり、AIはもう補助ツールではなく、仕事を受け持つ作業者として扱われ始めている。そこにCanvasが来ると、文章で進捗報告させるより、画面で状況を見せた方が自然になるんですよね。これは最近のCursor 3の流れを見ればかなり筋が通っています。 個人的には、ここで一番大きい変化は**「読む仕事」が減る**ことだと思っています。

AI駆動開発って、コード生成そのものより、実は「AIの返答を人間が読んで理解するコスト」が重かった。PR説明、ログ分析、調査結果、構成把握。全部、最後は人間の読解力に寄っていた。

Canvasはそこを崩しにきている。

言い換えると、AIが“答え”を出すだけじゃなくて、人間が判断しやすい形に整形する責任まで持ち始めた、ということです。 ---

Claude Artifactsに似ている。でも同じではない

この話を聞いて、「それってArtifactsっぽいよね」と思った人も多いはず。

その感覚はかなり合っています。

Artifactsも、会話の横で独立したコンテンツやツールを生成して、あとで編集したり再利用したりできる仕組みです。文書、図、単一ページのHTML、インタラクティブなReactコンポーネントまで扱える。だから発想としてはかなり近い。 ただ、違いもはっきりあります。

Artifactsは「会話から切り出された、再利用しやすい成果物」の色が強い。

一方でCursorのCanvasは、IDEの中に住む作業用インターフェースという感じです。ターミナルやブラウザ、差分確認と並んで存在して、エージェントの調査や実装と地続きで使える。 この差は地味に大きいです。

前者は“作ったものを見せる”寄り。後者は“仕事を進めるために使う”寄り。

だからCursorのCanvasは、見栄えよりもワークフローに刺さる可能性が高い。


個人開発者にとって、本当はどこがうまいのか

僕みたいに複数プロダクトを回している人間からすると、これの価値は「ちょっとした内製ツールを作る手間」が減ることです。

今までは、

「このCSVを見やすくしたい」

「この10件のコミットを優先度順にレビューしたい」

「このリポジトリの構成を新人向けに図解したい」

となると、雑に済ませるか、別で小さなダッシュボードを作るか、どちらかでした。

でもCanvasが効いてくると、その中間が埋まる。

つまり、わざわざアプリを作るほどではないけど、文章では厳しいという仕事を、AIがその場で引き取ってくれる。

しかもMarketplaceには、ドキュメントをセクションや目次、図つきで読める形にするDocs Canvasもあります。ここまで来ると、開発者は「コードを書く人」だけじゃなくて、AIに何の画面を作らせると判断が速くなるかを設計する人になっていくんだと思います。 ---

明日からどう変えるか

ここで大事なのは、いきなり大作を作らせないことです。

まずは**“読むのがしんどいもの”を1つCanvas化する**のがいい。

たとえばこんな感じです。

「直近10件のgit commitを、危険度・影響範囲・次アクションつきでレビュー用Canvasにして」

「このログファイルを、時間軸と異常イベントの関係が分かるCanvasにして」

「このリポジトリを、新人向けのアーキテクチャ図つきで説明するCanvasにして」

ここでのコツは、正解を聞くことじゃなく、判断しやすい画面を作らせること。

この発想に切り替わると、AIの使い方がかなり変わります。

ただ、ひとつ冷静に見ておきたいのは、見た目が整うほど人は安心してしまうことです。

Canvasがきれいでも、中のロジックやデータの結びつけ方が間違っていたら普通に危ない。これはArtifacts系全般にも言える話で、生成物が立派になるほど、人間の検証が雑になりやすい。そこは正直、今後の落とし穴だと思います。 でも、それを差し引いても、個人的にはかなり本命です。

なぜならこれは「AIが何を知っているか」の競争じゃなくて、AIが人間の理解速度をどれだけ上げられるかの競争に入ってきた合図だから。

3年後に振り返ると、「AIの出力がテキスト中心だった時代って、意外と長かったよね」と言われる気がします。

その境目のひとつが、こういうCanvasなんじゃないかな、と今は思っています。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?