Copilotが仕事ごとに画面を生成、チャット欄から脱出するCanvases

GitHubの2026年9月25日付チュートリアル は、GitHub Copilot appのCanvasesで仕事に合わせた画面を作る手順と利用例を公開した。自然言語で作業内容を伝えると、エージェントがカンバンやリリースチェックリストなどの画面を組み立てる。利用者とエージェントは、その同じ画面をそれぞれ操作できる。

LavX Newsの同日付記事 も、自然言語による画面作成と、人とエージェントによる双方向の更新を伝えている。今回の具体的な動きは作成手順と利用例の公開であり、Canvasesがこの日に初めて提供されたと確認できたわけではない。チャットで指示し、作業の進行は生成された画面で扱える点が、この機能の核心だ。

作れるのは、作業に合わせて操作を変えられる画面

Canvasesで想定されるのは、カンバン、課題整理ボード、リリースチェックリスト、ダッシュボード、フォーム、表計算などだ。どれも単に情報を表示するための画面ではない。カード、ボタン、入力欄、フィルターといった操作を置き、扱う仕事に合わせて利用者が状態を変えられる。

通常のチャットでは、依頼と返答が会話の順に積み重なる。たとえば課題の優先順位が変わるたびに、前の返答と新しい返答を読み比べて現在の状態を把握する必要がある。Canvasなら、課題をカードとして並べ、移動後の位置を作業面で確認できる。チャットは意図の説明や曖昧な点の相談に使い、継続して扱う対象は画面上に置く、という役割分担になる。

固定された画面を持つツールとの違いは、最初から決められた表示に仕事を合わせる必要がないことだ。同じリリース作業でも、完了した機能を整理する一覧、確認待ちの項目を追うチェックリスト、担当ごとに状況を見るボードでは必要な操作が異なる。Canvasesは、その作業と操作を自然言語で伝えて画面を作り、後から列やフィルターを加えることもできる。ただし、画面を生成できること自体は、チーム固有の業務ルールまで正しく反映されたという保証にはならない。

作成時は人とエージェントの操作を分けて伝える

作成はGitHub Copilot appのエージェントセッションで「/create-canvas」を入力し、必要なワークフローを説明する。説明に含めるのは、画面が扱う仕事、人が画面で直接できること、エージェントに任せることだ。リリースノートの例なら、利用者が完了した機能を確認・整理し、エージェントが項目を追加・更新する、と操作を分けて指定できる。

エージェントは説明に基づいて画面を作り、アプリの右側のパネルに開く。最初の画面が目的とずれていれば、列を増やす、対象のプルリクエストを取り込む、チェックリストに変えるといった修正を会話で依頼できる。自然言語は最初の生成に使うだけでなく、画面の機能や共有状態を調整する入口にもなる。

ここで指定する「できること」は、見た目の部品名より具体的な動作で考えると分かりやすい。課題ボードなら、カードの作成と移動がそれぞれ何を変更するのか。フォームなら、入力内容をどこへ反映するのか。ダッシュボードなら、表示するだけの値と、その場で更新できる値はどれか。これらが曖昧なままでは、使いやすそうな画面ができても、実際の作業状態と一致しない可能性がある。

共有するのは画面だけでなく、更新される状態

Canvasesの双方向性は、人とエージェントが同じ作業状態を扱う点にある。利用者がカードを動かす、ボタンを押す、入力欄を編集すると、その変更をエージェントも把握できる。逆に、エージェントがCanvasの機能を使って項目を追加したりカードを移動したりすれば、利用者は結果を画面で確認できる。変更内容を毎回文章で送り直さずに作業を続けられる。

ただし、同じ状態を扱うことは、人とエージェントに無条件で同じ権限を与えることを意味しない。GitHubのCanvas拡張機能文書 は、人が使う画面上の操作と、エージェントが呼び出せる機能を分けて説明している。カンバンの例では、カードの取得、追加、移動に対応する機能をエージェントへ用意できる。どの変更を実行させるか、その変更先へのアクセスをどう扱うかは、個々のCanvasの実装で確認する必要がある。

再利用とデータの保存も別の話だ。作成したCanvasは拡張機能として保存でき、リポジトリ内の「.github/extensions」に置くプロジェクト用と、利用者の「~/.copilot/extensions」に置く個人用を選べる。一方、画面に表示した作業データをどの形式で残すかは実装によって異なる。文書は状態保存用のJSONファイルを含められると説明するが、すべてのCanvasに同じ保存方法や変更履歴が備わるとはしていない。

チーム用Canvasで確認したい境界

チームで使う場合、最初に確かめたいのは画面の見栄えではなく、操作がどのデータを変えるかだ。次はCanvasesに共通の保証事項ではなく、生成した画面を受け入れる際の確認項目である。特に、カードの移動が画面内の並べ替えにとどまるのか、課題の正式なステータスを更新するのかは区別したい。

• 情報の行き先：画面はどの課題やリリース情報を読み込み、変更をどこへ書き戻すか。表示専用の値と編集可能な値は区別されているか。
• 操作の分担：人が確定する変更とエージェントが実行する変更は明示されているか。追加、移動、削除を一括りにしていないか。
• 状態の継続：画面を閉じて開き直した後も必要な情報が残るか。人とエージェントが続けて変更した場合、最終的にどの状態が残るか。
• 誤操作への対応：カードの誤移動や項目の重複追加を見つけられるか。重要な変更を取り消す方法や、確定前に確認する箇所があるか。
• アクセシビリティ：主要な操作をキーボードで行えるか。フォーカス位置、操作名、状態の変化を支援技術でも把握できるか。進捗を色だけで表していないか。

画面を人とエージェントが同時に更新できるからこそ、意図しない変更も共有状態に反映され得る。公開された説明から確認できるのは、自然言語でCanvasを作成・修正でき、両者が同じ画面で作業できること、そして拡張機能として再利用できることまでだ。個々の画面での保存方法、操作権限、復旧手段、アクセシビリティは、その実装と接続先に応じて確かめる必要がある。

関連記事:

• Runway Solarisは画面を毎フレーム生成、コード不要にはまだ壁
• Slackの会話がそのまま業務画面に、Surfacesはライブ更新が10月
• Roblox分析を20画面まで保存、チームの数字が一つにまとまる