はじめに
GitHubは2026年8月17日、GitHub Copilot appのCanvasを使い、エージェント作業を持続的な画面で管理する実践例を公開しました。本稿では、チャットで失われやすい状態や承認点をCanvasへ移し、反復業務の再作業とコストを抑える設計を解説します。
参考記事
- タイトル: How canvases make agentic workflows visible, steerable, and cost-efficient
- 著者: Ayan Gupta
- 発行元: GitHub Blog
- 発行日: 2026年08月17日
- URL: https://github.blog/ai-and-ml/github-copilot/how-canvases-make-agentic-workflows-visible-steerable-and-cost-efficient/
関連記事


要点
- Canvasは開発者とエージェントが同じ持続的な画面で状態、判断、承認を共有するGitHub Copilot appの機能である
- チャットだけの運用で埋もれる計画、検証、変更、承認点を明示し、履歴の再構築を減らす
- Java Modernization StudioとSite Studioは異なる業務でも共通の状態管理パターンを採用している
- 反復可能な設計は状態定義、重要判断の表示、進捗と下書きの即時保存、人の明示的承認で構成される
- 作成者の事例ではSite Studioに約2,000、Java Modernization Studioに約3,000のAIクレジットを使用した
詳細解説
チャットだけでは作業状態が埋もれる
Ayan Gupta氏は、チャットを意図の整理や曖昧な課題の検討に優れた入口と評価しています。しかし、エージェントが実作業を始めると、指示、ログ、方向転換、修正が長い履歴へ積み重なります。計画、重要な判断、検証結果、人が承認すべき箇所は存在していても、再び探して組み立て直す必要があります。
複数のエージェントが人より速く変更を作る環境では、生成速度よりレビュー可能性が制約になります。何が実行され、何が変わり、何を検証し、どこに人の判断が残っているかを会話から推測すると、確認漏れと重複作業が増えます。Canvasはこの状態を履歴ではなく、更新される作業画面として持たせます。
Java Modernization Studioの例
Java Modernization Studioでは、現状評価、計画、移行作業、検証ゲート、出荷準備を段階として可視化します。チャットだけでは複数参加者が現在地を見失い、「どの段階か」「何を決めたか」「何が止まっているか」「誰の承認が必要か」を繰り返し確認します。Studioでは各段階の運用状態を直接確認できます。
Javaの近代化は、依存関係、実行環境、テスト、性能、互換性をまたぐため、途中成果を保持する必要があります。人は高い判断価値を持つ承認へ集中し、エージェントは承認点の間で作業を進めます。これはエージェントへ全面委任する方式ではなく、人が止め、直し、再開できる制御面を作る方式です。
Site Studioにも共通する設計
Site Studioは個人サイトのコンテンツ作成と管理を対象にします。移行作業とは異なりますが、セクションごとの進捗、繰り返し編集、レビュー、状態遷移が必要です。チャット内で改稿を重ねると、どの文章が最新版か分からなくなり、フィードバックと下書きが散らばります。
Canvasではセクション状態と下書き値を作業中に保存し、人の確認点を表示します。エージェントは次の作業を進め、人は現在の成果物を見て承認または修正できます。GitHub Copilotのコンテキスト設計を扱った記事と合わせると、モデルへ毎回長い履歴を再送するのではなく、必要な状態を構造化して渡す利点が分かります。
四つの反復可能なパターン
Gupta氏は二つの事例から、四つの共通点を挙げています。第一に作業状態を明確に定義します。第二に人が判断すべき事項を画面へ出します。第三に進捗と下書きを即時保存します。第四に人の承認点を明示します。これにより、各プロンプトを新しい開始点として扱わず、記憶、構造、制御を持つ業務システムとして扱えます。
実務では、状態名だけでなく、開始条件、完了条件、必須証拠、失敗時の戻り先、承認者を定義すると安定します。例えば「検証中」なら、テスト結果、未解決項目、対象コミットを表示します。状態が動くたびに根拠を残すことで、人は会話全体を読み直さずに判断できます。
初期コストと回収の考え方
Site Studioの作成には約2,000、Java Modernization Studioには約3,000のAIクレジットがかかりました。Canvasは設計と調整に費用を要しますが、反復業務では再プロンプト、文脈の喪失、不要な往復、やり直しを減らせます。したがって、一度しか行わない小さな作業より、同じ状態遷移を繰り返す業務に向いています。
導入時は、まず一つの頻出業務を選び、/create-canvasで最小のCanvasを作ります。処理時間だけでなく、レビュー時間、差し戻し回数、文脈再説明の回数、AIクレジット、完了率を導入前後で比較します。画面が美しいかではなく、再作業と判断時間を減らせたかで投資効果を測ります。
まとめ
Canvasの価値は、エージェントの出力を増やすことより、作業状態と人の判断を同じ画面に残すことです。繰り返し業務を一つ選び、状態、証拠、承認、戻り先を最小構成で設計し、レビュー時間と再作業が減るかを測ると導入効果を判断できます。
