AIが、​自分で​画面を​触って​直す​時代 ──​「コードを​書く​AI」から​「動かして​確かめる​AI」へ

気になるAIの話を、分かりやすく ｜ 最新動向を、現場目線で

これまでAIにコードを頼むと、返ってくるのは「たぶん動くはずのコード」だった。実際にブラウザで開いて、ボタンを押して、崩れていないか、エラーが出ていないか——それを確かめるのは、いつも人間の仕事だった。「書く」のはAI、「動かして確かめる」のは人。その間には、地味だけど深い谷があった。

2026年、その谷が埋まり始めた。GitHubは2026-07-01、VS CodeのCopilotエージェントが実際のブラウザを操作できる「browser tools」を正式提供（GA）にした。AIが自分でページを開き、クリックし、入力し、スクリーンショットを撮り、コンソールのエラーを読む。そして「壊れ方」を見つけて、自分で直す。

つまりAIが、自分でQA（動作確認）をし始めた。今日はこの変化を、GitHubとVS Codeの公式情報をもとに分かりやすく整理してみる。私たち電脳技巧集団（AI職人ギルド）も、毎日ブラウザ検証を回しながら開発している側なので、その現場目線で見ていく。

01何が​変わった？​ ──AIが​実ブラウザを​操作できるようになった

いちばんの変化は、AIエージェントが"実際に動いているアプリ"を触れるようになったことだ。GitHubの発表によると、Copilotのbrowser toolsは、エージェントに次のような操作をさせられる^[1]。

• ページを開いて移動（navigate）する
• クリック・入力・ホバー・ドラッグ、ダイアログの処理
• ページの内容を読む
• コンソールのエラーを取得する
• スクリーンショットを撮る

しかもこの機能は、Webテスト自動化で定番の Playwright をベースにしている（Playwright MCP経由）^[2]。今までは「AIが書いたコードが本当に動くか」はブラックボックスだったが、これからはAI自身が開いて、触って、目で見て確かめられる。VS Codeのツール表示も「Run Playwright Code」のような無味乾燥なものから、何をしているか分かる説明つきラベルに改善された^[1]（※機能はすべてGitHub/VS Codeの公式情報による。CAGが検証したものではない）。

02な​ぜ​これが​大きいのか ──​「書く」と​「動く」の​間の​谷

コードは、書けても動くとは限らない。ボタンの位置がずれる、押しても反応しない、コンソールに赤いエラーが出る、スマホで崩れる——こういう「動かしてみないと分からない壊れ方」は、山ほどある。

これまでのAIは、この谷を越えられなかった。コードは書けても、それが実際のブラウザでどう見えて、どう壊れるかは"見えて"いなかったからだ。だから最後は人間が開いて確認するしかなかった。「AIが8割書いて、人間が動作確認して手直しする」——これがAI開発の実際のボトルネックだった。

browser toolsは、この谷に橋をかける。AIが自分で実アプリを開き、壊れ方を自分の目（スクリーンショット）と耳（コンソールエラー）で捉えられる。「書く」と「動く」がつながって初めて、AIは"作業を最後まで回せる"ようになる。

03AIが​自分で​QAする​流れ

具体的には、こういう一周が人手なしで回るようになる^[3]。

1. 作る：HTML・CSS・JavaScriptを書く。
2. 開く：統合ブラウザでそのアプリを開く。
3. 触る：クリック・入力して、機能が動くか試す。
4. 見つける：コンソールのエラーや、見た目の崩れから問題を特定する。
5. 直す：原因を直して、また開いて確かめる。

この「作る→開く→触る→見つける→直す」のループを、AIが自分で回す。長めの操作（5秒を超えるスクリプト）も、タイムアウトで失敗せず結果を後から受け取れる仕組みが入った^[1]。人間が毎回「動かして、スクショ撮って、エラー見て、報告して」を挟まなくても、AIが自分で一周できる範囲が広がった。

04現場の​リアル ──​「確認だけ​人間」が​減る

これは、Webを作る現場にとって地味に大きい。私たちの開発でも、UIの修正は「直す→ブラウザで開く→クリックして確認→スクリーンショットで見比べる→コンソールにエラーがないか見る」の繰り返しで、この"動かして目視"の部分に、けっこうな時間がかかる。

browser toolsが効くのは、まさにここだ。単純な動作確認や、コンソールエラーの拾い出し、見た目の崩れの検出——これまで人間が毎回やっていた確認作業の一部を、AIが自分で回せる。AIの評価軸が「コードを書けるか」から「実アプリを見て、壊れ方を見つけて、直せるか」へ移っている、と言い換えてもいい。

CAG（電脳技巧集団）でも、開発ではブラウザ検証（画面の実測・スクリーンショット・本番での確認）を重視してきた。AIが自分でこの検証を回せるようになるほど、人間は「何を確認すべきか」の設計と、最後の判断に集中できる。道具が増えたというより、"確かめる"という工程がAI側に寄ってきた、という感覚だ。この「AIは道具でなく作業環境で差が出る」という見方は、以前CAGが書いた記事とまっすぐつながっている。

関連記事 ｜ モデルは脳、harnessは職場AI開発の主戦場は、モデル比較から「作業環境」へ移った ──モデルは脳、harnessは職場 →

05でも​丸投げは​禁物 ──注意点

便利だが、いくつか気をつけたい。

• スクリーンショットは万能ではない：AIが撮った画面と、実際の見え方が食い違うことがある（画面幅・遅延読み込み・アニメの途中など）。「AIが確認したから大丈夫」を鵜呑みにしない。
• "直った"の誤判定：エラーが消えても、別の壊れ方が残っていることはある。テストや人の目と併用する。
• 網羅性は人が設計する：AIは指示された範囲を確認するだけ。どの画面・どの条件・どのデバイスを見るべきかは、人が決める。
• 本番影響・重い判断は人間承認：動作確認は任せられても、公開・デプロイ・データ操作のような後戻りしにくい操作は、最後に人が承認する（HITL）。

つまり、AIに「動かして確かめる」を任せられるようになったからこそ、人間の役割は「何を・どこまで確認させ、どこで止めるか」を設計することに移る。丸投げではなく、確認の設計だ。

06まとめ ──AIの​評価軸は​「書ける」から​「確かめられる」へ

「どのAIが賢いコードを書くか」は、これからも話題になる。でも実務で効いてくるのは、もう一段先だ。AIが自分で動かして、壊れ方を見つけて、直せるか。GitHubのbrowser tools GAは、その具体例だった。

コードを書いて終わりのAIから、書いたものを自分で動かして確かめるAIへ。人間が毎回やっていた「動かして目視」の谷に、橋がかかり始めた。AIが確認まで回せるようになるほど、人間は「何を確認させ、どこで止めるか」の設計に集中できる。

派手なモデル発表よりも、こういう「AIが仕事を最後まで回すための地味な部品」が、現場の景色を変えていく。AIの次の差は、書く速さより、確かめる力に出る。

同じ「AIに開発を頼む」でも、書くだけか、動かして確かめるところまでかで、任せられる範囲が変わる。今日の要点を一枚に。

観点	"書くだけ"のAI（旧）	"動かして確かめる"AI（今）
できること	コードを書く	書く＋実ブラウザで操作・確認
バグの見つけ方	人が動かして発見	AIがconsole error・スクショで発見
動作確認（QA）	毎回、人がやる	単純な確認はAIが一周
「書く」と「動く」	間に谷（人が橋渡し）	AIが自分でつなぐ
人間の役割	動かして確認・手直し	何を確認させ・どこで止めるか設計＋承認
評価軸	コードを書けるか	見て・壊れ方を見つけて・直せるか

※ 本記事はGitHub/VS Code/Playwrightの公式情報を、AIを開発に使う側の観点から分かりやすく整理したもの。機能・仕様はすべて公式の引用であり、CAG自身の検証結果ではありません。数値・機能は2026-07時点の公開情報で変動しうる（v0）。