こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。
GitHub Copilot appの「Canvas」を見て、チャットと何が違うのか、どう作ればいいのか気になっていませんか。Canvasは、かんばん、チェックリスト、ダッシュボードなどの作業面を、人とAIエージェントが同じ画面で更新するための機能です。便利そうですが、保存範囲や権限を曖昧にしたまま共有するのは避けたいところ。
この記事では、2026年9月26日にGitHub公式Docsと、9月25日公開の公式初心者向け記事を再確認し、/create-canvasで作る手順からチーム共有前の点検までを順番に解説します。私は今回、実機でCanvasを生成・共有する操作は行っていません。画面名や仕様は公式情報として紹介し、実際に試したような表現はしません。
- Canvasと通常のチャットの違い
- /create-canvasで作成する手順
- 個人用とチーム共有の保存先
- 機能・権限・公開前の確認点
GitHub Copilot Canvasの使い方
GitHub公式のCanvas日本語Docsによると、GitHubがCanvasと呼んでいるのは、文章を描く白い板ではなく、作業成果を表示・編集・確認できる対話型の作業面です。セッション内で目的を伝えると、使う人の操作とAgentから呼び出す操作を持つ拡張機能が作られ、アプリの右側パネルに開きます。まず概念をつかんでから、小さな個人用Canvasで試すのがわかりやすい順番です。
Canvasでできること
最新の英語表現も確かめたい場合は、Canvas extensionsの英語公式Docsも併記で読めます。
公式Docsでは、Canvas拡張機能を「共有された対話型の作業面」と説明しています。例として上げられているのは、プラン、issue triageボード、リリースチェックリスト、ダッシュボード、インシデント画面、スプレッドシートなど。文章を返すだけのチャットより、状態を目で追いたい仕事に向いています。
特徴は双方向の共有状態です。人がボタンやカードを操作し、Agentも用意された機能を呼び出して同じデータを更新します。たとえばかんばんなら、人がカードを移動し、Agentがadd_cardやmove_cardのような機能を使う構成が例示されています。会話ログを読み返さなくても、現在の状態を画面で確かめられるのが利点です。
ただし、Canvasが作業の正しさを自動で保証するわけではありません。画面で確認しやすくなっても、入力データ、更新範囲、外部サービスへの操作は人が確かめる必要があります。チャットを置き換えるのではなく、作業の進み具合を共に見る場所を足す機能と考えると理解しやすいでしょう。
向いている仕事：進捗が変わる、複数の項目を比べる、人が途中で修正する、最後に目視確認する仕事です。一度だけの短い質問なら通常のチャットのほうが簡単です。
利用前に確認する条件
公式Docsには、GitHub Copilot appはすべてのCopilotプランで利用可能と記載されています。ここで言う「すべて」はアプリの提供対象を示す表現であり、あらゆるモデル、プラグイン、組織機能が同じ条件で使える意味ではありません。契約中のプラン、AI credits、組織ポリシーは別に確認します。
会社や学校のリポジトリでは、管理者がCopilot appやプラグインの利用を制限している可能性があります。Canvasを個人のマシンで作れても、社内データを入れてよいか、チーム用フォルダへコミットしてよいかは別問題です。業務利用なら、対象リポジトリ、データの取扱区分、レビュー担当を先に決めておきましょう。
続けて、GitHub Copilot appが現在のバージョンか、CustomizeのCanvas画面が表示されるかを見ます。公式のおすすめCanvasにはプラグインが必要なものがあり、利用前にインストールが求められることもあります。「Canvasという機能がある」と「そのテンプレートをすぐ使える」を分けるのがポイントです。
機密情報で試さないでください。最初は公開しても困らないサンプルデータで、個人用のCanvasを作ります。アクセストークン、顧客名、社内URL、未公開のissueを入れずに動きを確かめましょう。
/create-canvasの始め方
自分用のCanvasを作るときは、GitHub Copilot appでエージェントセッションを開き、プロンプト欄に/create-canvasと入力します。その後ろに、どんな作業面が必要か、人が何をできるようにするか、Agentに何を任せるかを書きます。公式Docsでは、カードの作成・担当・移動をできるかんばんが例示されています。
GitHubの2026年9月25日の初心者向け公式記事でも、ワークフローを具体的に言葉にする流れが紹介されています。最初の練習には、一日の作業チェックリストが向いています。「人は項目の追加、完了切り替え、メモ編集ができる。Agentは未完了項目の取得と、新しい項目の追加ができる。外部サービスへは送信しない」と書けば、境界が分かりやすくなります。
Agentが構築を終えると、Canvasが右側のパネルに開くと公式Docsにあります。そこで終了とせず、ボタン、カード、フィルターなどを操作し、更新内容が残るかを確かめます。次にAgentへ「未完了の項目を教えて」と依頼し、人の操作とAgentの読み取りが同じ状態を見ているか検算しましょう。
プロンプトの書き方
良いプロンプトは、見た目の希望だけでなく、操作とデータの関係を説明しています。「かんばんを作って」だけでも構築は進むかもしれませんが、担当者を設定するのか、完了カードを削除するのか、Agentがカードを動かしてよいのかが残ります。画面、状態、人の操作、Agentの機能、禁止事項の5つを分けて書くと伝わりやすいです。
たとえば「リリース準備のチェックリスト。人は項目の追加、担当者、期限、完了を編集できる。Agentは未完了項目の一覧、期限超過の検出、メモ追加をできる。削除と外部送信はできない」と書けば、合否判定もしやすくなります。その上で「期限超過をオレンジで表示」など、見た目を追加します。
一度で完璧なCanvasを求める必要はありません。公式Docsにも、作成後にインターフェース、共有状態、機能の追加・削除・変更をAgentへ依頼できるとあります。まず必要最低限を作り、一つ操作するたびに「何が変わったか」を確かめるほうが、意図しない機能を減らせます。
◆もっちゃんのワンポイント
最初の成功条件は「すごいダッシュボードができる」ではありません。人が一項目を追加し、Agentがそれを読めて、余計な外部操作をしないことを確かめられたら十分です。
共有範囲を選ぶ方法
Canvasの保存範囲は、個人用とプロジェクト用に分かれます。個人用は~/.copilot/extensions、チームと共有するプロジェクト用はリポジトリ内の.github/extensionsです。パスの違いは単なる保存場所ではなく、誰に配布するかを決める選択です。
作成中の試作、個人のメモ、機密性のない練習なら、まず個人用が無難です。チーム共有にするなら、リポジトリに差分として追加される内容をレビューし、名前、依存関係、使うデータ、呼び出せる機能をチームで確認します。共有フォルダへ入れた瞬間に安全になるわけではありません。
試作は個人用、レビュー後にプロジェクト共有という二段階にすると、試行錯誤のファイルをリポジトリへ混ぜにくくなります。個人用から共有用へ移す際は、ただコピーするのではなく、データの初期値、ローカルパス、個人名、認証情報が残っていないかも見てください。
作成されるファイル
公式Docsによると、Canvas拡張機能の実装は様々ですが、一般的にはメタデータと依存関係を持つpackage.json、動作と機能を定義するextension.mjsなどのエントリファイル、永続化した状態を持つ任意のJSONアーティファクトが含まれます。「画面が作られた」という結果の裏で、実行可能なコードと依存関係が増える可能性を忘れないでください。
チーム共有前は、どのファイルが追加されたかをGitの差分で見ます。依存パッケージは目的に必要か、バージョンが固定されているか、スクリプトが意図しないネットワークアクセスやシェル実行をしないかを確かめます。JSONにデータを保存するなら、サンプルと実データの分離も必要です。
Agentが使う機能名もレビュー対象です。get_boardのような読み取りと、move_cardのような更新では影響が異なります。名前だけで判断せず、入力、更新する状態、失敗したときの扱いを読みましょう。不要な機能は削除するようAgentへ依頼し、差分をもう一度確かめます。
| 確認対象 | 主な役割 | レビュー点 |
|---|---|---|
| package.json | メタデータと依存関係 | パッケージと実行コマンド |
| extension.mjs | 画面と機能の動作 | 読み取り・更新・外部操作 |
| artifacts | 永続化する状態 | 機密値と実データの有無 |
GitHub Copilot Canvasの注意点
Canvasが開いた後は、見た目の確認だけでなく、人とAgentがどの操作を持ち、どのデータを更新するかを検証します。公式のおすすめCanvasを入れる場合も、個人の試作をチームで使う場合も、「何が見えるか」と「何を実行できるか」を分けて見るのが大切です。
人とAgentの操作を分ける
Canvasには、人がボタンや入力欄で使うUI操作と、Agentが呼び出す機能があります。両方が同じ状態を扱えることがCanvasの価値ですが、全く同じ権限を持たせる必要はありません。例えばカードの削除は人だけ、Agentは追加と状態変更だけという設計もできます。
機能を追加する前に、その操作が取り消せるかを考えます。タグの変更は戻しやすい一方、カードの完全削除、外部への通知、issueのクローズは影響が大きくなります。最初は読み取りと下書き作成までに限り、外部への確定操作は人の承認後にすると安心です。
Copilotにコードを確認させる流れを深く知りたい方は、GitHub Copilotコードレビューの使い方も参考になります。Canvasとコードレビューは別機能ですが、AIの提案を人の確認なしに確定しない原則は共通します。
共有状態を検証する
共有状態の検証では、「人が更新した内容をAgentが読めるか」と「Agentの更新が画面に正しく反映されるか」を両方向で試します。一方だけでは、表示は変わったのに保存されていない、Agentは古い状態を読んでいるといった行き違いを見落とすかもしれません。
テストデータには、変化が分かる値を使います。例えば「試作A」というカードを人が追加し、Agentに未完了項目を読ませます。次にAgentが「試作B」を追加し、画面を開き直しても残るかを見ます。同時編集が想定されるなら、2つの操作が競合したときの扱いも確かめます。
継続性もCanvasの利点として公式Docsに示されています。セッションや引き継ぎをまたいで作業するなら、アプリを閉じて再度開いたときの状態、別のセッションからの参照、担当者が変わったときの説明をテストしてください。画面が再現されるだけでなく、データと権限が意図どおりかが合格条件です。
プラグイン要件を確認
Customize全体の構成は、GitHub Copilot appのカスタマイズ公式Docsで確認できます。
CustomizeのCanvas画面には、GitHubが選んだおすすめCanvasが表示されます。その中には、別のプラグインを入れてから使うものがあります。公式Docsの例では、Azure DevOps向けCanvasにAzure DevOpsプラグインが必要と説明されています。インストール画面では、開発元、接続先、要求される権限を読んでから進みます。
プラグインは、Canvasだけでなく、スキル、フック、カスタムAgent、MCPサーバーを含む場合があります。そのため、「ボードを表示したいだけ」のつもりでも、追加される能力はより広いかもしれません。インストール後はInstalledで追加されたカスタマイズを確認し、不要なものは無理に残さないようにしましょう。
GitHubはカスタマイズ用の公式ギャラリーも公開しています。ギャラリーは発見の入り口として便利ですが、各拡張のページで要件を見ることが大切です。人気や表示順を安全性の証明にせず、目的に必要な機能だけを選びます。
導入前の順番：Canvasの目的、必要プラグイン、開発元、要求権限、外部接続、チームポリシーを見てからインストールします。
公開前に権限を見直す
個人用の試作からプロジェクト共有へ移す前に、Canvasが読めるデータと実行できる操作を一覧にします。特に、issue・pull requestの更新、外部チケットの作成、通知、ファイル書き込みは、表示だけより影響が大きい操作です。利用者が画面のボタンで実行できる操作と、Agentが会話から実行できる操作の両方を見ます。
最小権限にするため、読み取りで目的を達成できるなら更新権限を与えず、下書きでよければ直接公開機能を持たせません。状態データにユーザー名、メールアドレス、トークンを直書きしないことも必須です。認証が必要な場合は、対応する正式な接続方法を使い、秘密値をCanvasのデータに混ぜません。
チーム共有は、レビューが終わってからpull requestで行うのがわかりやすいです。差分、依存関係、初期データ、機能名、テスト結果を説明し、担当者が再現できるようにします。マージ後には、別の利用者が新しいセッションから開き、表示と操作が意図どおりかを確かめてください。
画面がきれいに動くことと、権限設計が適切なことは別です。共有前は表示、保存、外部操作、取り消しの4面を確かめます。
表示されない時の確認
Canvasタブや/create-canvasが表示されない場合は、アプリの入手先とバージョン、ログインしているGitHubアカウント、Copilotプラン、組織ポリシーを順に見ます。ブラウザー版やIDEのCopilot ChatとGitHub Copilot appを混同していないかも確かめましょう。同じCopilotという名前でも、すべての画面にCanvasがあるわけではありません。
おすすめCanvasが開けないときは、必要なプラグインが入っているか、Installedに表示されるか、新しいセッションを開いたかを見ます。自作Canvasが開かない場合は、保存先、ファイル構成、依存関係、起動時の出力を確かめます。認証エラーと拡張機能の実装エラーを分けることが大切です。
GitHub Issue #2073には、2026年7月、特定のWindows環境でマーケットを発見できないという一件の利用者報告があります。これは個別の第三者報告であり、現在の全Windows利用者に起きる仕様ではありません。似た症状を報告するなら、OS、アプリ版、アカウント種別、組織ポリシー、再現手順を分けて記録します。
Copilot側のモデルや提供条件が関係している可能性を確かめたい場合は、GitHub Copilotのモデル移行情報も利用できます。ただし、モデルの表示とCanvasの表示は同じ問題と決めつけず、切り分けてください。
切り分けの順番：正式なCopilot appか、最新版か、対象アカウントか、組織ポリシーで許可されているか、必要プラグインがあるかの順で見ます。
GitHub Copilot CanvasのFAQ
Q1. Canvasは通常のチャットと何が違いますか？
A. チャットは意図を伝え、説明を受けるのに向きます。Canvasは、かんばん、チェックリスト、文書、表などの共有作業面で、人とAgentが同じ状態を更新・確認できる点が違います。
Q2. /create-canvasで何を書けばいいですか？
A. 作りたい作業面、人ができる操作、Agentが呼び出せる機能、保存する状態、禁止する操作を書きます。最初は小さなチェックリストにし、人からAgent、Agentから画面の両方向を確かめるのが安心です。
Q3. 個人用とチーム共有はどう選びますか？
A. 試作や自分だけの作業は~/.copilot/extensionsの個人用、レビュー済みでリポジトリの成員と使うものは.github/extensionsのプロジェクト用が目安です。共有前に依存関係、権限、初期データをレビューします。
Q4. Canvasは全Copilotプランで使えますか？
A. GitHub公式Docsは、GitHub Copilot appがすべてのCopilotプランで利用可能と記しています。ただし、プラグイン、モデル、AI credits、組織ポリシーの条件は別です。実際のアカウントと組織設定を確かめてください。
Q5. Canvasが表示されない時はどうしますか？
A. 正式なGitHub Copilot appか、アプリが最新か、対象アカウントへログインしているか、組織ポリシーで許可されているか、必要プラグインがあるかの順で確認します。個別の報告を全員の仕様と決めつけないことも大切です。
GitHub Copilot Canvasの使い方
GitHub Copilot Canvasは、人とAIエージェントが、かんばん、チェックリスト、文書、表などを同じ画面で操作するための共有作業面です。通常のチャットで意図を伝え、Canvasで見える状態を直接確認・修正できることが特徴です。
作り方は、GitHub Copilot appのセッションで/create-canvasを入力し、人にできることとAgentにできることを伝えるのが基本です。完成後は右側パネルで、人からの更新をAgentが読めるか、Agentの更新が画面へ反映されるかを両方向で確かめます。
保存範囲は、個人用の~/.copilot/extensionsと、チーム共有用の.github/extensionsに分かれます。まず機密情報を含まない小さな個人用Canvasで試し、生成されたpackage.json、エントリファイル、JSONデータ、依存関係、機能をレビューしてから共有へ進みます。
公式DocsはGitHub Copilot appを全Copilotプラン向けとしていますが、プラグイン、モデル、AI credits、組織ポリシーの条件は別です。利用量や追加費用が気になる方は、Copilot AI Creditsの料金と上限も併せて確認できます。記事中の数値だけで決めず、実際の契約画面と管理ポリシーを見てください。
最初は「一項目を追加し、人とAgentが同じ状態を見られる」ところまでで十分です。外部送信や削除を含まない練習用のCanvasから始め、差分と権限を自分の目で確かめてから、次の機能を足していきましょう。
