AIとの対話は、なぜチャットに固定されているのか
大規模言語モデル（LLM）を使うとき、私たちは多くの場合、テキストエリアに指示を書き、返答を読み、さらに指示を返すというチャット形式を利用します。
チャットは、用途が決まっていない段階では非常に汎用的です。文章作成、調査、コード生成、データ分析など、何に使うか分からないユーザーにも提供できます。しかし、目的が明確になった後もチャットを使い続けると、操作効率や安全性に課題が生じます。
たとえば、Git操作のたびに「変更を確認してステージングし、コミットして」とエージェントへ依頼するより、状態を一覧できる画面で対象を選択し、必要な操作だけを実行する方が分かりやすいケースがあります。SQLiteのデータを扱う場合も、毎回自然言語で検索や更新を依頼するより、クエリエディターや結果表示を備えた専用画面の方が作業に適しています。
ニュースでは、この問題に対するアプローチとして、GitHub Copilotアプリ内で動作する「Canvas」が紹介されています。
Canvasは「AIを使う画面」ではなく「AIが作る専用ツール」
Canvasは、ブラウザーの一般的な画面とは異なる、目的に合わせた小規模なフルスタックアプリケーションとして説明されています。ユーザーが操作する画面と、AIエージェントが動作するサーバー側が連携し、相互に情報をやり取りできます。
重要なのは、AIにすべての操作を依頼するのではなく、AIに作業用の道具を生成させ、その後は人間が道具を使うという発想です。
紹介されている例には、次のようなものがあります。
- エージェントと対戦できるConnect Fourゲーム
- Windowsのパッケージ管理を行うWinget向けUI
- SQLiteデータベースを操作する画面
- SQL入力支援やIntelliSenseを備えたデータ操作画面
- 開発ワークフローの進行やレビューを支援する画面
この構成では、チャットを何度も往復して同じ操作を依頼する必要が減ります。たとえば、パッケージの検索やインストール、データベースの参照といった反復作業は、専用UIを一度用意すれば、以降は通常のアプリケーション操作として実行できます。
トークン削減だけが価値ではない
専用UIの利点は、LLMのトークン消費を抑えられる可能性だけではありません。開発現場では、次のような効果がより重要になります。
操作の意図を固定できる
自然言語の指示は柔軟である一方、解釈の幅があります。専用画面では、実行可能な操作や入力項目を限定できます。ユーザーが選択できる範囲を設計することで、誤解釈や不要な指示を減らせます。
状態を視覚的に把握できる
Gitの変更ファイル、データベースの検索結果、ワークフローの進捗などは、会話履歴より一覧画面の方が把握しやすい情報です。AIの返答を読むだけでなく、現在の状態を見ながら次の操作を選べます。
人間の介入点を設計できる
AIエージェントにすべてを任せるか、すべてを人間が確認するかの二択にする必要はありません。Canvasを中間層として使えば、調査やプロトタイプ作成は自動化し、設計レビューや本番反映だけを人間が承認するといった分業が可能になります。
開発ワークフローにどう組み込むか
ニュースでは、開発作業を次のような段階に分けています。
- 調査
- プロトタイプ作成
- 計画
- 実装
- 改善
- 最終化
従来のチャット中心の運用では、各段階で人間がエージェントに指示を出し、出力を読み、次の指示を考える必要があります。Canvasを使う場合は、これらの段階を状態管理された画面として表現できます。
たとえば、次のような構成が考えられます。
- 調査結果と参照資料を一覧表示する
- プロトタイプの候補を比較できるようにする
- 実装前に計画と変更範囲を確認する
- エージェントに実装を依頼し、差分を画面上でレビューする
- テスト結果を集約し、失敗した項目だけを再実行する
- 最終承認後にリリース準備へ進める
ここで重要なのは、自動化の量ではなく、どの状態で人間の判断を求めるかです。作業を完全に無人化するよりも、確認すべきポイントを明確にして、人間が効率よくレビューできるようにする方が実務では導入しやすいでしょう。
ローカル実行と権限管理には注意が必要
一方で、Canvasがフルスタックアプリケーションとして動作し、ローカルコードの実行や外部APIとの接続を扱える点には注意が必要です。便利さが増すほど、AIが操作できる範囲も広がるためです。
業務で導入する場合は、少なくとも次の観点を設計に含めるべきです。
- ファイル、データベース、パッケージ管理などへのアクセス範囲
- 読み取り専用操作と変更操作の分離
- インストール、削除、コミットなど高リスク操作の承認
- 実行ログと変更履歴の保存
- 外部APIへ送信されるデータの範囲
- 失敗時や誤操作時に元へ戻せる仕組み
- 開発環境と本番環境の権限分離
特に、自然言語で生成された画面をそのまま社内業務へ投入するのは危険です。Canvasは「AIが作ったから安全なツール」ではなく、通常のアプリケーションと同様に、入力検証、認可、監査、エラー処理を評価する必要があります。
チャットとCanvasは競合しない
チャットが不要になるわけではありません。用途がまだ決まっていない相談、複数の可能性を比較する作業、画面を作る前の要件整理には、チャットが適しています。
一方、操作対象や手順が定まった後は、専用UIの方が適しています。両者の役割は次のように整理できます。
| 状況 | 適したインターフェース |
|---|---|
| 目的や要件を探索する | チャット |
| 文章やコードの初稿を作る | チャット |
| 状態を一覧しながら反復操作する | Canvasなどの専用UI |
| 承認やレビューを行う | 差分・一覧・ワークフロー画面 |
| 定型処理を繰り返す | 自動化されたツール |
AIエージェントの価値は、会話の巧みさだけで決まるものではありません。人間が何を確認し、何を操作し、どこから先を自動化するのかを、インターフェースとして表現できるかが重要です。
「チャットの外側」を設計する
今回のニュースが示しているのは、AIエージェントの進化がモデル性能だけでなく、操作面の設計にもかかっているということです。
チャットは、AIを使い始めるための優れた入口です。しかし、実務で継続的に使うには、目的に合わせた画面、明確な状態表示、承認ポイント、権限管理が必要になります。
まずは、頻繁にチャットへ依頼している作業を一つ選び、その作業専用の画面に置き換えられないか考えてみるとよいでしょう。Git操作、データベース参照、テスト結果の確認、定型的なリリース準備などは候補になります。
AIに作業を依頼するだけでなく、AIに「作業を安全かつ繰り返し行える道具」を作らせる。これが、チャットUIの先にあるエージェント活用の一つの方向性です。
出典： GitHub Blog