Copilot appキャンバス、agent作業の見える化

GitHubは2026年6月2日、GitHub Copilot appのtechnical previewを既存のCopilot Pro、Pro+、Business、Enterprise利用者へ広げた。あわせて、canvases、cloud sessions、cloud automations、Copilot CLI sessionの統合、agentic browsing、voice conversations、rubber duck、/chronicle など、agent作業を見て、直し、引き継ぐための機能群を発表した。

これは、5月のGitHub Copilot app technical previewで示された「IssueやPRからagent sessionを始めるデスクトップ作業面」の続編だ。さらにCopilot cloud agent automationsやCopilot CLI刷新と並べると、GitHubがCopilotを補完ツールから、agent作業を管理する運用基盤へ寄せていることが見える。

日本の開発チームが見るべき焦点は、新しいUIの派手さではない。agentが何をしているかをchat transcriptだけで追うのではなく、plan、pull request、browser session、terminal、release checklist、incident boardのような「作業物」上で確認できるか。誰がcanvasを編集し、誰がagentの実行権限を許し、どのsessionをcloudで走らせ、費用をどう追うかである。

事実: 6月2日の更新はpreview拡大とcanvases

GitHub Changelogによると、今回の更新でGitHub Copilot app technical previewは、既存のCopilot Pro、Pro+、Business、Enterprise利用者が利用できる対象になった。Copilot Free利用者や未契約ユーザーはwaitlist扱いであり、BusinessとEnterpriseでは引き続き組織またはenterprise側のpreview機能とCopilot CLIの有効化が前提になる。

機能面で中心に置かれたのがcanvasesだ。GitHubはcanvasesを、人間とagentが同じ作業物を見ながら操作する双方向の作業面として説明している。agentはcanvasを更新し、人間はその同じ面で編集、並べ替え、承認、方向転換を行う。GitHub Docsでも、canvas extensionはplan、triage board、browser session、release checklist、dashboard、incident、spreadsheetのような作業成果物を扱う共有インタラクティブ面だと説明されている。

同じ発表では、cloud sessionsもapp UIから選べるようになった。Docsでは、session開始時に新しいworking tree、local repository、cloud sandboxのどこで動かすかを選べるとされている。cloud sandboxはGitHubがホストする分離環境であり、ローカル端末のリソース制約や端末の起動状態から一部切り離せる。

さらに、agentic browsingも入った。発表では、統合browserをagentが操作し、click、type、screenshot取得を通じてUI変更をend-to-endで検証できると説明されている。これはfrontendを持つ日本のSaaS、社内ポータル、EC、管理画面開発ではかなり実務的な意味を持つ。コード差分だけでなく、画面上の結果をagent sessionの作業面に近づけられるからだ。

canvasesはchatの代替ではなく作業面

ここからは分析だ。

canvasesを「Copilotにホワイトボードが付いた」と見ると誤る。GitHubの説明では、chatは曖昧な指示や議論の場であり、canvasは意図が見える作業へ落ちる場所だ。つまり、agentに「このPRを直して」と言うだけでなく、PR、checklist、browser、terminal、issue triage boardの状態を人間とagentが同じ面で扱うことが狙いである。

日本企業でagent導入が詰まりやすいのは、agentの出力がchatの長いログに埋もれることだ。誰が何を承認したのか、どのテストが通ったのか、どの差分が本当にレビュー対象なのか、どのissueが残っているのかが散らばる。canvasesは、少なくともその散らばりを「見える作業物」に寄せる方向の更新だ。

たとえば、migration作業ならcanvasは移行ステップ、対象テーブル、テスト結果、未解決リスクを持つboardになる。incident対応なら、症状、調査ログ、仮説、修正PR、rollback条件が一つの面に並ぶ。release checklistなら、必要なPR、CI、QA、feature flag、deploy approvalが見える。agentはそこを読んで次の行動を提案し、人間は直接修正できる。

ただし、canvasは統制そのものではない。canvasに見えるから安全になるわけではない。むしろ、作業面が増えるほど、どのcanvasをrepositoryに共有するか、個人のlocal extensionに留めるか、.github/extensions へ入れてteam共有するかを決める必要がある。Docsではproject scopeとuser scopeが分かれており、team共有canvasはrepository内の拡張として扱う道が示されている。これは、便利機能ではなく設定資産としてレビュー対象にすべきという意味だ。

cloud session、browser、voiceを一つの運用面で見る

今回の更新はcanvasesだけではない。cloud sessions、cloud automations、Copilot CLI sessionsのapp表示、agentic browsing、voice conversations、rubber duck、/chronicle が同時に並んでいる点が重要だ。

cloud sessionsは、作業実行場所を個人端末だけに閉じない。これはCopilot cloud agent automationsと近い運用論点を持つ。人間がappから始めるsessionでも、cloudで動かせるなら、どのrepositoryでcloud sandboxを許可するか、secretやnetwork accessをどう絞るか、実行結果を誰がレビューするかを先に決める必要がある。

agentic browsingは、UI検証をagent作業の中に入れる。これは便利だが、ブラウザでどのURLへ行けるか、認証済みsessionを渡すのか、社内管理画面や顧客データが見える環境で使うのかを確認しなければならない。画面操作は「読む」だけではなく、clickやtypeを伴う。検証環境、seed data、test account、監査ログを分けるべきだ。

voice conversationsは、prompt入力の摩擦を下げる。Docsではapp内のvoice dictationについて、ローカルtranscription modelをdownloadし、microphone accessを許可し、送信前に入力欄で確認または編集できる流れが説明されている。これはCopilot CLI刷新で扱った音声入力と同じく、端末管理、会議室、客先常駐、録音禁止ルールと一緒に見るべき領域だ。

/chronicle はsession履歴から情報を引き出す機能として説明されている。sessionが増えるほど、過去の作業からstandup、引き継ぎ、未解決事項を取り出せる価値は上がる。一方で、session履歴に何が残るか、社内情報や顧客名が混じるか、退職者や委託先のsessionをどう扱うかという管理論点も増える。

日本企業での導入論点

最初に確認すべきは、有効化範囲だ。BusinessとEnterpriseではpreview機能とCopilot CLIのpolicyが関係する。全社一括でpreviewを開くより、Platform Engineering、SRE、QA自動化、開発基盤、社内ツールチームのように、agent作業の検証価値が高く、運用ログも見られるチームから始めるほうがよい。

次に、canvasの共有範囲を決める。個人の便利canvasと、チーム標準canvasを混ぜてはいけない。release checklist、incident board、migration board、security review boardのようにチームの判断に関わるcanvasは、repository内の設定資産としてレビューし、誰が変更できるかを制限する。個人の一時メモやdaily planning canvasとは扱いを分ける。

三つ目は、cloudとlocalの使い分けだ。local sessionは手元の環境や社内networkに近い。一方、cloud sandboxは端末から切り離せるが、アクセスできる資源を明示的に設計する必要がある。production secret、顧客DB、社内VPNが絡む作業をcloud sessionへ安易に渡すべきではない。逆に、OSS依存更新、テスト追加、ドキュメント整備、軽いbug修正はcloudに向く可能性がある。

四つ目は、browser検証の対象環境だ。agentic browsingを使うなら、dev/staging専用のtest account、書き込み可能範囲、外部送信の禁止、スクリーンショット保存ルールを用意したい。日本の業務アプリでは、画面に個人情報や取引先名が出ることが多い。画面検証をagentに任せるなら、表示データの匿名化もセットになる。

五つ目は、費用とレビューだ。Copilot appが使いやすくなるほどsession数は増えやすい。Copilot AI Credits課金開始以降、agentic workflowの利用はseat数だけでは読めない。canvas、cloud session、browser検証、rubber duck、voice入力は、いずれもagent利用を増やす方向に働く。導入後は、利用量、PR作成数、CI再実行回数、レビュー指摘数、手戻り削減を一緒に見るべきだ。

既存Copilot運用とのつなぎ方

今回のCopilot app更新は、単体の新機能ではなく、既存のCopilot運用へ接続される。すでにGitHubはcloud agent、REST API、automations、CLI、app、code review、Memory、metricsを次々に広げている。日本企業では、それぞれを別々の新機能として試すと運用が散らばる。

まず、標準タスクを決めるのがよい。たとえば「失敗したUI testの一次調査」「依存関係更新PRの確認」「release note下書き」「軽微なissue triage」「docs更新」「security patchの影響確認」のように、canvas化しやすいタスクを選ぶ。そこに、どのsession mode、どの実行場所、どのmodel、どのtool、どのreview条件を使うかを紐づける。

次に、監査APIや管理者設定と合わせる。Copilot cloud agent設定監査APIで扱ったように、agentが使うMCP、firewall、Actions承認、検証toolを棚卸しできるなら、Copilot appのcanvasやcloud sessionもその棚卸し表へ入れるべきだ。appだけを現場任せにすると、どのagent surfaceで何が許されているか説明できなくなる。

最後に、human reviewの位置を下げないことだ。canvasesは作業を見える化する。Agent Mergeやbrowser検証は進行を速くする。しかし、出荷判断、security-sensitiveな変更、個人情報を扱う処理、課金や権限に触れる差分は、人間のreviewと承認を残す必要がある。見える化は承認を省くためではなく、承認の材料を増やすために使うべきだ。

まとめ

GitHub Copilot appの6月2日更新は、preview対象の拡大に加えて、canvasesを中心にagent作業を「見える作業物」へ移すものだ。cloud sessions、agentic browsing、voice、rubber duck、/chronicle が並んだことで、Copilot appは単なるデスクトップアプリではなく、agent作業の運用面としての色を強めた。

日本の開発チームにとって重要なのは、機能を全部試すことではない。どのagent作業をcanvasに載せるか、cloudで動かすか、browser検証をどの環境で許すか、voiceとsession履歴をどう管理するか、AI Creditsとreview負荷をどう測るかを決めることだ。Copilot appの価値は、agentに仕事を投げる入口を増やすことではなく、agentが進めた仕事をチームが検査し、修正し、引き継げる形へ寄せるところにある。

出典

• Expanded technical preview availability for the GitHub Copilot app - GitHub Changelog, 2026-06-02
• Working with canvas extensions in the GitHub Copilot app - GitHub Docs
• Working with agent sessions in the GitHub Copilot app - GitHub Docs
• GitHub Copilot app: The agent-native desktop experience - GitHub Blog