GitHub Blog の How to build interactive experiences with canvases – The GitHub Blog は、GitHub Copilot app の canvas extensions を紹介しています。
要点は、エージェントとのやり取りをチャットだけに閉じず、情報を可視化し、クリックや編集で操作できる共有ワークスペースへ広げるというものです。記事では、Issue トリアージ、コードベース図、worktree 管理、プロンプト改善、社内知識探索といった例が挙げられています。
AI エージェントの導入を考えるとき、多くの現場ではまず「どんなプロンプトを書けばよいか」に目が向きます。もちろん対話の質は重要です。ただ、今回の canvas が示している論点は別にあります。エージェント活用の主戦場は、チャット欄の性能競争から、作業対象をどう画面化するかへ移り始めている、という点です。
チャットは、曖昧な依頼を投げるには便利です。一方で、状態が多い作業には向きません。Issue を1件ずつ判断する、コードベースの依存関係を見る、複数セッションの worktree を整理する、過去のプロンプトを比較する。こうした作業では、テキストの往復よりも、一覧・関係図・カード・フィルタ・操作ボタンのほうが判断しやすい場面があります。
ここで重要なのは、canvas が単なる見た目の改善ではないことです。画面があることで、人間は途中状態を確認し、判断を差し込み、必要なら操作で修正できます。エージェントはその操作を受けて次の処理へ進めます。つまり、AI が自律的に進める領域と、人間が制御すべき領域を、UI の上で分けられるようになります。
これは開発組織にとって実用的な示唆があります。AI ツールを導入するとき、「どのタスクをAIに任せるか」だけを考えると、過剰な自動化か、単なる補助チャットのどちらかに寄りがちです。むしろ設計すべきなのは、AI が処理し、人間が判断し、システムが状態を保持する作業面です。
Issue トリアージの例なら、AI は内容を読み、候補を出し、分類を補助できます。しかし最終判断は、人間がカードを見て操作する形にできます。コードベース図なら、AI は構造を抽出し、人間は関心のある層を探索できます。こうした分担は、AI を「代替する存在」ではなく、「判断を速くする作業環境」として扱う発想に近いです。
今後、生成AIプロダクトの差は、モデルに何を言わせるかだけでは決まりません。業務の状態をどう見せ、どこに人間の介入点を置き、操作結果をどう次のAI処理へ返すか。そこまで含めて設計できるチームほど、AIを日常業務の流れに組み込みやすくなります。
canvas の価値は、会話を置き換えることではありません。会話だけでは扱いにくい作業を、見える・触れる・進められる形に変えることです。AI エージェントの実用化は、プロンプト設計だけでなく、インタラクション設計の問題になりつつあります。
関連記事
- David Vélez and Robin Vince join the boards of the OpenAI Foundation and OpenAI Group PBC
- OpenAI and Hugging Face partner to address security incident during model evaluation
- Introducing the ChatGPT for small business program
参考文献
コメント