GitHub Copilotが「答えるAI」から「操作する作業環境」へ
GitHub Copilotの活用方法は、コード生成や質問への回答だけではない。今回紹介された「キャンバス（canvas extension）」は、開発チーム独自の作業手順に合わせたUIを、自然言語の指示から作成できる機能だ。
キャンバスは、カンバンボード、Issueトリアージ画面、リリースチェックリスト、ダッシュボード、フォームなどに姿を変える。重要なのは、単に情報を表示する画面ではなく、ユーザーとAIエージェントが同じ状態を共有しながら操作できるインターフェースである点だ。
従来のチャットでは、ユーザーが指示を入力し、AIの返答を待ち、その結果を別のツールへ反映する必要があった。キャンバスでは、カードを移動したり、ボタンを押したり、フィールドを更新したりした変更を、エージェントも同じ画面上の状態として扱える。AIとの対話が「質問と回答」から「共同作業」に近づく仕組みといえる。
キャンバスは自然言語から作成できる
キャンバスを作成する際は、GitHub Copilotアプリのエージェントセッションで/create-canvasスキルを実行し、作りたいワークフローを自然言語で説明する。特に、次の3点を明確にすると、実用的な初期画面を作りやすい。
- キャンバスが支援するワークフロー
- ユーザーが画面上で直接実行したい操作
- エージェントに実行させたい操作
例えば、リリース作業用のキャンバスなら、次のように依頼できる。
/create-canvas
リリースノート作成用のキャンバスを作ってください。
GitHub Copilotのセッションで完了した機能開発を記録し、エントリーを確認・整理できるようにしてください。
ユーザーがステータスを変更でき、エージェントがリリースノートを追加・更新できるようにしてください。
このように、最初から細かなレイアウトやファイル構成を設計するのではなく、業務の流れを記述する。生成された画面を使いながら、必要な列、フィルター、操作を追加していくのが基本的な進め方だ。
実務例1：リリース管理をキャンバス化する
リリース前には、完了した機能、未対応の不具合、レビュー待ちのプルリクエスト、リリースノートの草稿など、複数の情報を整理する必要がある。これらをチャットだけで管理すると、現在の状態と会話の内容が分離しやすい。
リリース管理用キャンバスでは、例えば次のような構成が考えられる。
- 機能や修正内容をカードとして一覧表示する
- ステータスを「候補」「レビュー中」「承認済み」「公開済み」に分ける
- リリース対象だけを表示するフィルターを設ける
- 各項目に概要、関連Issue、担当者、リリースノートを持たせる
- エージェントが作業セッションの内容をもとに項目を追加・更新する
- ユーザーがカードの移動や内容の修正を直接行う
ここでのポイントは、AIに「リリースノートを書いて」と依頼するだけではなく、リリース情報を蓄積し、整理し、確認するための共有状態を持たせることだ。
開発者が画面上で項目を「レビュー中」へ移動し、エージェントに未整理の変更点を追加させる、といった作業を同じキャンバス上で進められる。チャットの履歴を何度も読み返して、別の管理表へ転記する作業を減らせる可能性がある。
実務例2：Issueトリアージを支援する
Issueトリアージでは、報告内容の確認、重複の判定、優先度の設定、担当チームへの振り分けなどを行う。特にIssueが増えると、一覧を読む作業と判断結果の記録が分断され、対応漏れが起きやすい。
トリアージ用のキャンバスには、次のような操作を組み込める。
- 未分類のIssueを一覧表示する
- 優先度や担当チームで絞り込む
- 対応状況をカードの状態として変更する
- エージェントにIssueの要約や分類案を作成させる
- ユーザーが分類結果を確認し、必要に応じて修正する
- 対応済みの項目を別の状態へ移動する
この場合、AIに判断を丸ごと委ねるのではなく、AIが整理案を出し、人間が画面上で承認・修正する流れにすることが重要だ。優先度や担当の決定には、プロダクトの方針や顧客との契約など、コードやIssue本文だけでは判断できない情報が含まれるためである。
GitHub Projectsや専用ツールとの違い
キャンバスは、既存のプロジェクト管理ツールを単純に置き換えるものではない。GitHub Projectsのように、あらかじめ定義されたビューや項目を使ってチームの作業を管理する方法は、標準化された運用や長期的な集計に向いている。一方、キャンバスは、特定のチームや一時的な作業に合わせて、必要な画面を素早く形にする用途と相性がよい。
| 観点 | キャンバス | 既存の管理ツール・標準ビュー |
|---|---|---|
| 初期構築 | 自然言語でワークフローを説明して作成 | 項目やビューを設定する必要がある |
| UIの柔軟性 | 作業内容に合わせて対話的に変更しやすい | 用意された機能や設定の範囲で設計する |
| AIとの連携 | エージェントが画面上の状態を更新できる | AI操作は別途設計や連携が必要になる場合がある |
| 再利用 | 拡張機能として保存・共有できる | 組織の標準設定として管理しやすい |
| 向いている用途 | 試行的な業務、個人の補助、独自フロー | 継続的な運用、標準化、チーム横断の管理 |
実務では、どちらか一方に統一するより、用途を分ける考え方が現実的だ。正式な進捗や長期的な記録は既存の管理基盤に残し、キャンバスは確認・整理・下書き・日々の作業を支援するレイヤーとして使う方法が考えられる。
導入時に押さえたい3つの設計ポイント
1. 画面ではなくワークフローを先に定義する
最初から「カンバンを作る」と考えるより、業務上の判断と操作を洗い出す方がよい。例えばリリース管理なら、次のように分解できる。
- どの変更をリリース候補にするか
- 誰が内容を確認するか
- どの状態を承認済みとみなすか
- リリースノートをいつ確定するか
- 完了後にどこへ記録するか
この手順が曖昧なまま画面だけ作ると、見栄えはよくても運用に定着しない。キャンバスは業務フローを可視化する手段であり、業務ルールそのものを自動的に決めてくれるわけではない。
2. AIに任せる操作と、人間が承認する操作を分ける
AIエージェントに任せやすいのは、情報の収集、要約、分類候補の作成、下書きの更新などだ。一方、公開、優先度の最終決定、顧客影響の判断などは、人間の確認を必須にした方が安全である。
キャンバスの設計では、次のような境界を明示すると運用しやすい。
- エージェントが自動で追加してよい情報
- ユーザーの確認後に更新する情報
- 画面上で変更履歴を確認したい項目
- 誤更新時に人間が戻す必要がある状態
3. 小さな対象から始める
最初から組織全体の開発管理をキャンバス化する必要はない。まずは、次のような限定された作業から試すのがよい。
- 1つのリリースの候補一覧
- チーム内の未分類Issue
- 毎日のレビュー待ち項目
- スプリント終了時の確認事項
- リリースノートの下書き管理
短期間で効果を評価できる範囲に絞れば、必要な列や操作も見つけやすい。生成された初期版を完成品とみなさず、実際の作業を通じて改善していくことが前提になる。
現時点で考えられる制約
キャンバスは柔軟である一方、柔軟さゆえの課題もある。自然言語から作成できることは、要件定義が不要になることを意味しない。入力する説明が曖昧であれば、表示項目や操作も曖昧になりやすい。
また、チームで利用する場合は、次の点を運用ルールとして整理しておきたい。
- キャンバス上の情報を正式な記録とするか
- プロジェクトに保存する拡張機能と個人用拡張機能をどう使い分けるか
- 変更できるユーザーや権限をどう管理するか
- AIが追加・更新した内容を誰が確認するか
- 既存のIssue、プルリクエスト、管理表とどの情報を同期するか
特に、キャンバス上の状態だけを正本にすると、別のメンバーが利用する管理基盤と情報がずれる可能性がある。導入時には「便利な作業画面」と「正式な記録」の役割を分けておくことが重要だ。
エンジニアにとっての意味
キャンバスの本質は、AIが新しい種類のUIを自動生成することだけではない。開発者が自分たちの作業手順を自然言語で表現し、それをAIが操作可能な作業環境へ変換する点にある。
これにより、AIエージェントはコードを提案する存在から、開発プロセスの状態を読み取り、整理し、ユーザーと同じ画面を更新する存在へ広がる。特に、情報収集と人間の判断が交互に発生する作業では、チャット単体よりもキャンバス型のインターフェースが適している。
一方で、導入効果は「AIを使ったか」ではなく、次のような業務指標で評価すべきだ。
- Issueの分類にかかる時間が短くなったか
- リリース候補の確認漏れが減ったか
- チャットから管理画面への転記が減ったか
- AIの提案を人間が確認しやすくなったか
- チーム内で作業状態を共有しやすくなったか
まずは/create-canvasで小さなボードやチェックリストを作り、実際の業務で使いながら改善する。キャンバスは、完成済みの万能ツールを導入するというより、チームのワークフローをAIと共同で設計していくための新しい選択肢である。
出典： GitHub Blog