先週、開発部門との定例ミーティングでこの話題が出ました。GitHub Copilotが、VS Code内でブラウザを直接操作できるようになったという話です。コードを書いた後のウェブアプリ確認作業、つまり「ページを開いてクリックして、ログインして画面遷移を確かめる」あの作業を、AIエージェントが肩代わりするというものです。
正直、最初に聞いたときは「またリリースが増えたか」くらいの感覚でした。ところが若手のエンジニア担当が「これ、動作確認の工数が相当減ります」と言い出して、少し真剣に調べることにしました。
具体的に何ができるようになったのか
今回、GitHubが一般提供（GA）に移行したブラウザ操作ツールでできることは、私が調べた範囲でこういう内容です。
- ページを開く・リンクをクリックする・文字を入力する
- マウスオーバー・ドラッグ・ダイアログの処理
- コンソールエラーの取得・スクリーンショットの撮影
手順が決まった確認作業ならスクリプト化して繰り返し実行できるとのことで、リグレッションテスト的な使い方もできるようです。これ、開発現場ではかなり刺さる話だと感じました。
一方で、私が気になったのはセキュリティの部分です。「AIがブラウザを操作できるなら、社内の業務システムに勝手にアクセスされないか」というのは、営業DX推進の立場として見過ごせないポイントです。この点については、GitHubが明確に説明していて、ユーザーが自分で開いたタブはデフォルトではAIエージェントから見えない仕様になっているとのことです。「Share with Agent」を選んで初めて操作対象になる。AIエージェントが自分で開くタブは、通常のブラウジング環境とは別の新しいセッションで動作し、保存済みCookieにもアクセスできない。この設計は、社内のセキュリティ担当に説明するときにそのまま使えそうだと感じました。
さらに企業向けには管理者がアクセスできるドメインを許可リスト・拒否リストで制限できる管理機能も用意されているとのことです。この一文は稟議書に引用するつもりです。
経営陣への説明をどう組み立てるか
私の部門では現在、開発ベンダー2社と営業支援システムの改修を進めています。従業員1500名規模の製造業となると、基幹システムとの連携確認や画面テストの工数は馬鹿になりません。改修のたびに確認工数が発生し、ベンダーへの委託費用がかさむというのは、ここ数年ずっと経営陣から指摘されてきた課題です。
GitHub Copilotの今回の機能拡充を投資対効果の文脈に乗せるとすれば、「テスト・確認工数の削減」が一番わかりやすい切り口になります。経営陣は具体的な数字を求めますから、現行の確認工数を月次で集計して、削減可能な部分を定量化する必要があります。うちの開発担当に確認したところ、ルーティンの動作確認だけで月15〜20時間は使っているということでした。この数字を叩き台にして試算する方向で話を進めようと考えています。
もう一点、私が慎重に見ているのはAIクレジットのコスト管理です。同日にGitHubは、Copilot CLIとCopilot SDKでAIクレジットのセッション上限を設定できる機能も発表しています。自動化された作業でAIエージェントが想定外に動き続けるのを防ぐ仕組みで、`--max-ai-credits`というオプションで上限を指定できるとのことです。コスト管理の仕組みが明示されているのは、稟議を通す上でも安心感があります。経営陣から「使いすぎたらどうなる」と聞かれたときの答えになります。
先日、同じような話を社内で進めたときに「セキュリティ要件をどう担保するか」と情報システム部門から差し戻しを受けた経験があります。あのときは準備不足で1ヶ月以上遅れました。今回は管理機能の仕様とセキュリティ設計の説明を先に整理してから、情報システム部門に持ち込むつもりです。稟議のルートを先に塞いでおく、というのが大きな組織で物事を動かすときの基本だと改めて感じています。
来月の経営会議の資料に、今回の内容を一項目入れようと考えています。現場で使えるかどうかの検証を、開発担当の部下に先行で動いてもらうのが先決です。