Claude Codeのデスクトップ版にブラウザが内蔵された。2026年7月6日から10日、バージョン2.1.202から206にかけての更新で、Claudeが自分でウェブページを開き、読み、クリックし、フォームに入力するところまで手を伸ばせるようになった。CLI版には無い、デスクトップアプリだけの機能だ。
コードを書かせた後に「動くか自分で見て」と頼めるようになった、と言い換えてもいい。生成物の確認を人間が全部引き受けていた工程に、Claude自身が画面を見て確かめる手が加わった。
AIにUIを書かせたことがある人なら、あの落ち着かなさを知っているはずだ。「実装しました」と返ってきたコードが、本当に画面で意図通り動くのかは、自分でサーバを立てて開くまで分からない。文法は通っているのにボタンが画面外へはみ出していた、ダークモードだけ文字が背景に沈んでいた。こういうズレは、コードを読んでいるだけでは見つからない。実際に描画された画面を目で見て、初めて気づく。その最後の一手間を、これまでは毎回人間が背負っていた。
何が起きたのか
公式の要旨はシンプルだ。ドキュメント、デザインカンプ、任意のサイトをClaudeが開いて中身を読み、リンクやボタンをクリックし、必要なら入力もする。ローカルで動かしている開発サーバのプレビューも同じ枠組みで扱える。手元のアプリを立ち上げてClaudeに見せれば、画面の状態を読んで次の指示に反映してくれる。
ただし内蔵ブラウザは無防備に外へ繋がるわけではない。サンドボックス化されていて、既定では分離プロファイルで動く。個人のログイン情報も閲覧履歴も持たないまっさらな状態が初期値になっている。ログインやCookieを保持したまま作業を続けるか、毎回クリーンな状態から始めるかは、セッション永続の設定でユーザーが選ぶ。
もう一つ、安全の線引きがある。外部サイトでの書き込み操作、つまり実際にクリックや入力を発生させる動作は、安全分類器のレビューを一度通り、実行前にユーザーの承認を求める。手元のローカルプレビューにはこのゲートがかからない。
この非対称が、機能の使い勝手を決めている。
3つの用途は、はっきり別物だ
内蔵ブラウザの使い道は大きく3つに分かれる。混ぜて考えると承認の挙動に戸惑うので、最初に切り分けておきたい。
1つ目は公式ドキュメントやデザインの参照。ライブラリのドキュメントページや共有されたデザインカンプをClaudeに開かせ、仕様を読み取らせる。人間がタブを行き来してコピペしていた作業を、そのまま任せられる。バージョンが上がって引数が変わった、新しい設定項目が増えた。こうした最新の情報を、記憶に頼らず実際のドキュメントを開いて確認させられるのは大きい。読むだけの操作なので摩擦は少ない。
2つ目がローカルアプリのプレビュー検証。自分の手元で動いている開発サーバを、Claudeがそのまま画面として見る。たとえばフロントの見た目を直させた直後、こう頼める。
npm run dev
# http://localhost:3000 が立ち上がる
# → Claude に「この画面を開いて崩れていないか見て」と頼むボタンの位置がずれていないか、ダークモードで文字が沈んでいないか。人間が目でやっていた確認を、Claudeが画面を読んで報告してくれる。ここにはゲートがかからないので、指示から確認までが途切れない。
従来この目視確認は、別ウィンドウでアプリを開き、スクリーンショットを撮って見比べる手作業だった。崩れを見つけたら指示に戻り、直させて、また撮り直す。この往復の撮る側を、Claudeが画面を読んで肩代わりしてくれる。手元で完結する軽い検証ほど、恩恵が分かりやすい。
3つ目が外部サイトでの操作。手元ではない任意のサイトを開き、リンクをたどり、フォームに値を入れる。ここだけは扱いが変わる。書き込みを伴う動作が安全分類器を通り、実行前に承認を待つ。Claudeが勝手に外部で何かを送信して終わっている、という事故が起きにくいように作られている。
使いどころとしては、社内ツールへの定型入力の下見や、管理画面で設定を変える前の状態確認あたりが浮かぶ。書き込みが走る手前で毎回止まるので、承認画面に出た操作内容を自分で読んでから通す。まとめて雑に承認していくと、ゲートを置いた意味が薄れてしまう。
ゲートとトグルの効きどころ
承認ゲートが外部サイトにだけ効き、ローカルプレビューを素通りする。この設計は、使う側の負担配分をよく考えている。
いちばん頻度が高いのは、自分が今書いているコードの見た目確認だ。ここに毎回「承認しますか」が挟まったら、テンポが死ぬ。手元のプレビューを素通りにしたのは妥当な判断だと筆者は見ている。外へ書き込む操作という、取り返しがつきにくい領域にだけ人間のワンクッションを残した。
セッション永続のトグルが効いてくるのは、認証フローの検証だ。ログイン画面から先の挙動を確かめたいとき、状態を保持しておけば、一度サインインした続きをClaudeに追わせられる。ダッシュボードの表示崩れやログイン後のリダイレクト先を見たい場面で、毎回サインインし直させる無駄が消える。逆に、初回訪問者がどの導線を通るかを見たいなら、毎回クリーンな状態で開かせる。ログインの壁にぶつかった新規ユーザーが、そこで離脱するのか登録へ進むのか。同じログイン周りでも、保持とクリーンで見えるものが変わる。検証したい問いに合わせてトグルを選ぶ、という手順が一つ増えたと考えるといい。
分離プロファイルが既定である点も、地味に効く。自分の本番アカウントでうっかり操作されるのを、初期状態で避けている。認証を試したいときだけ、意図してセッションを持たせる。順序が逆になっていない。
なぜデスクトップ版だけなのか
この機能はCLI版に無い。ターミナルで完結するCLIに、サンドボックス化したブラウザ描画とプロファイル分離を抱えさせるのは筋が悪い。画面を持ち、UIとして状態を見せられるデスクトップアプリだからこそ載る機能だ。
筆者は以前、複数のAIエージェントを1画面に束ねて動かすデスクトップアプリを自作したことがある。エージェントの出力を人間が一望できる画面を用意すると、確認の速度が段違いに上がる。内蔵ブラウザも同じ発想の延長にあると感じた。実行の結果を実際の画面で見せてくれる。ここにデスクトップ版限定の理由がある。
開発者としての実践ポイント
- まずローカルプレビュー検証から使う。 承認ゲートがかからず、指示から目視確認までが一本で繋がる。フロントの見た目直しやレスポンシブ崩れのチェックを、真っ先にここへ寄せる。
- 外部サイト操作は承認ゲート前提で、影響範囲を絞る。 送信や投稿を伴う動作は一度止まる。何を承認したのかを毎回自分で読む癖をつけ、まとめて雑に通さない。
- セッション永続トグルを用途で切り替える。 認証後の画面を追いたいなら保持、初回導線を見たいならクリーン。検証したい対象で明示的に選ぶ。
- 分離プロファイルが既定という前提を忘れない。 開いた直後はログイン情報を持っていない。ログインが要る検証は、意図してセッションを持たせてから始める。
- CLI運用と役割分担する。 バッチ処理やスクリプト実行はCLI、画面の目視確認はデスクトップ、と使い分ける。両方を同じ道具だと思うと機能差でつまずく。
エージェントの出力を1画面で確認する発想を突き詰めたい人は、筆者が複数AIエージェントを1画面に統合するMission Controlを自作した過程も参考になる。実行結果を人間が一望できる環境の作り方を具体的に書いている。
よくある疑問
CLI版でも使えるのか。 使えない。この内蔵ブラウザはデスクトップアプリ専用で、ターミナルで動くCLIには載っていない。画面描画とプロファイル分離を前提にした機能なので、目視確認はデスクトップ、バッチやスクリプト実行はCLI、と住み分けるのが素直だ。
外部サイトでClaudeに勝手に操作されないか。 書き込みを伴う動作は安全分類器のレビューを通り、実行前にユーザーの承認を求める。承認を押すまで送信も投稿も走らない。読むだけの参照や手元のローカルプレビューはこのゲートの対象外で、素通りする。
ログイン状態は保持されるのか。 既定では分離プロファイルで動き、ログイン情報も履歴も持たない。保持するかどうかはセッション永続の設定次第で、認証後の画面を追いたいときだけ意図してオンにする。初期値がクリーンなので、本番アカウントでうっかり操作される心配は小さい。
まとめ
内蔵ブラウザは、生成物を「見た感じ動く」で済ませず実画面で確かめる相棒として効く。外部サイト操作は承認ゲート越しに慎重に、ローカルプレビューの目視検証を主用途に置くのが現実的だ。
筆者は視覚出力や配布物を、スクリーンショットやヘッドレステストで実測してから「動く」と言う主義でやってきた。Claude自身が画面を読んで確かめる手を得たいま、その実測を任せられる範囲が少し広がった。承認ゲートとセッション永続の効きどころを掴んでおけば、確認の工程がまた一段軽くなる。
