この変なサイト

とりあえず10秒だけ見てください。

架空の会社「株式会社バグダラケ」のコーポレートサイトです。社名でだいたい察していただけると思いますが。

実績、取引者数、創業年数の数字が止まりません。永遠に増え続けます。ボタンの文字は背景に溶けて読めません。フォームに入力して送信を押しても、うんともすんとも言いません。

このサイト、18個の不具合を意図的に仕込んで作りました。

見た瞬間にわかるものもあれば、HTMLの中を覗かないと絶対に分からないものも混ぜてあります。

で、この18個。AIは何個見つけられるんでしょうか。

2026年7月に出たばかりのClaude Codeの新機能「アプリ内ブラウザ」を使って、検証しました。

「アプリ内ブラウザ」って何？

2026年7月10日、Claude Codeのデスクトップアプリに追加された機能です。正式名称は Browser pane（ブラウザペイン）。

ひとことで言うと、AIが自分でWebサイトを開いて、見て、触れるようになった。それだけです。

……前からできたのでは？

正直に言うと、AIにブラウザを見せる方法は前からありました。Chrome拡張を入れる、Playwrightを繋ぐ、MCPを設定する。やろうと思えばできた。

ただ、そのたびにセットアップが要りました。

「ちょっとこのページ見てほしいだけなんやけどな……」というときに、環境構築から始めるのはダルい。だから結局、自分でブラウザを開いてスクショを撮ってAIに貼る、という往復をしていたわけです。

今回の変化は、この往復が標準機能として消えたこと。インストールも設定も要りません。Claude Codeを開いたら、もうそこにブラウザがある。

派手な新技術というより、摩擦がゼロになったという話です。そして摩擦がゼロになると、人は実際にやるようになります。

検証方法

架空の会社のコーポレートサイトを1ファイルのHTMLで作り、18個の不具合を仕込みました。

正解リストは別フォルダに隔離。AIに渡したのはHTMLファイル1個だけです。（最初、ファイル内に <!-- BUG: viewport の meta タグが無い --> みたいなコメントを親切に書き残していて、危うく全部バレるところでした）

順番はこうです。①コードだけ読ませる → ②ブラウザで見せる → ③実際に触らせる。

【第1ラウンド】コードだけ読ませてみた

ブラウザは封印。コードだけ渡します。

プロンプト 「index.html をコードだけ読んで、問題点を洗い出して。ブラウザは開かんといて。」

白状すると、こう踏んでいました。

「レイアウト崩れとか動作バグは、画面を見んと分からんやろ。まあ7個くらいちゃう？」

結果、17個。

おぉ…….。

レイアウトの崩れも、JavaScriptのバグも、コードを読んだだけでほぼ全部言い当ててきました。しかも何行目まで特定して。

あげく、仕込んでないバグまで見つけてきた

ナビゲーションの #news・#blog に対応するセクションが存在しない（リンク切れ）

これ、意図せずやらかしていたバグでした。メニュー項目だけ作って、中身を作り忘れてたんです。

正解リストにすら載ってない不具合を、勝手に拾ってきました。

この時点で仮説は崩壊。「コードを読むだけでは見つからないバグがある」という前提が、そもそも間違ってたわけです。

【第2ラウンド】じゃあブラウザ要らんのでは？

当然、こう思いますよね。「コード読むだけで17個出るなら、ブラウザいらんくない？」

同じことを思いました。で、見せてみたら認識が変わりました。

ブラウザが加えたのは「発見」じゃない。実証と、定量化と、体感でした。

最後の行が決定打でした。

数字が止まらないバグ。コードレビューでは「まあ表示のバグやな」で片付きます。優先度、そんなに高くない。

ところが実際に動かしたら、裏で処理が回り続けてページ全体が重くなり、スクロールがカクついていました。

「見た目がちょっと変」じゃないです。来た人が、まともにスクロールできないという話です。コードを読んでるだけでは出てこない指摘でした。

スマホで版は見れたもんじゃない

スマホで開いたとき、このサイトは**「崩れて」いません**。「縮んで」います。

• まともなサイト：スマホの幅に合わせてレイアウトが組み直される。文字は読めるサイズのまま

• このサイト：パソコン版をそのまま縮小コピーしただけ。文字が米粒サイズ

パッと見きれいに収まってるように見えるんですよ。だから気づかない。

でも実際にスマホで開いた人は、指で拡大しないと何ひとつ読めません。アクセスの6〜7割はスマホからです。

【第3ラウンド】AIにフォームを触らせてみた

今回の山場です。

プロンプト 「お問い合わせフォームに適当な内容を入れて、送信ボタンを押してみて。」

AIは自分でフォームに文字を打ち込み、送信ボタンをクリックし、こう報告してきました。

送信ボタンを押した結果 → 何も起きません

そして続く一文。

ユーザーからは「押しても壊れているのか送れたのか分からない」状態です。

この一文の何がすごいか

第1ラウンドでも、AIは「送信ボタンが機能しない」と予測していました。予測はできてたんです。

でも実際に押してみて初めて、**「ユーザーは何が起きたか分からないまま放置される」**という、体験としての被害が言葉になりました。

問い合わせフォームが動いてない、ということは、問い合わせが1件も来ないということです。

しかも恐ろしいのは、社内の誰も気づかないという点。エラーも出ない。管理画面に「失敗」と記録されるわけでもない。ただ静かに、見込み客が去っていくだけ。

「最近、問い合わせ減ったなあ」で終わってしまう。これが一番怖いパターンです。

AIが、ツールの限界を自力で回避した

AIはコンソール（エラーの記録）を読もうとしました。ところがツールの仕様上、一部のエラーが取れないことが判明します。

普通なら「取得できませんでした」で終わりです。

が、諦めませんでした。

問題が起きている箇所をページ内で直接実行して、同じエラーを意図的に再現させたんです。

しかも、こんな推論まで添えてきました。

カウンターは動いていた（この行より前で実行される）ので、スクリプトは267行目まで到達 → そこで落ちる、という流れです。

「動いてる部分」から逆算して「どこで死んだか」を特定してます。 ツールが使えないと分かった瞬間、目的を達成する別の道を自分で見つけた。

で、直せるの？

プロンプト 「見つかった問題を全部直して。ただしデザインの方向性は変えんといて。直したらブラウザで開き直して、自分で直ったか確認して。」

（※「デザインは変えるな」を明示するの、地味に大事です。放っとくと勝手にオシャレにリニューアルされて、Before/Afterが成立しなくなります）

数字は 120 / 48 / 12 でピタッと止まりました。ボタンは読めるようになり、フォームは完了メッセージが出るようになりました。

そして、スマホ

「縮んだコピー」だったものが、ちゃんとスマホ用に組み直されました。ハンバーガーメニューが出て、カードは縦に積み上がって、文字は指で拡大しなくても読めます。

冒頭で「アクセスの6〜7割はスマホ」と書きました。その6〜7割が、やっとまともに読める状態になったわけです。

「直りました！」で終わらせなかった

注目してほしいのは、修正そのものより確認の仕方です。

AIは「直りました」で済ませませんでした。ブラウザを開き直し、画面をスマホ幅に変え、要素の座標を実測して「3枚のカードが縦に積み上がっています（上端が 1341→1525→1686、左端は全て24で揃う）」と報告してきました。

「たぶん直った」じゃない。数字で証明してます。

しかも検証の途中で、こんなことも言ってました。

カウンターはブラウザのタイマー抑制でゆっくり進んでいるようです。projects が 120 で止まるか、もう少し待って確認します。

「まだ90やな、もうちょい待つか」って自分で判断して待ってます。

で、AIにできなかったこと

この記事で一番書きたいのは、実はここです。

①「詳しくはこちら」

サービス紹介の3枚のカード、全部「詳しくはこちら」で終わってました。

これ、正直バグではないです。押したらちゃんと飛ぶ。壊れてない。

でも、読み上げソフトで聞くと「こちら、こちら、こちら」としか聞こえません。何のリンクか分からんまま選ばされる。

AIは2回ともスルーしました。壊れてへんからでしょうね。

こういう「動いてるけど、これでええんか？」は、まだ人間の仕事やと思います。

② autocomplete属性の欠落

フォームの自動入力が効かない設定漏れ。これはブラウザ側の警告機能が教えてくれて、こちらがAIに伝えました。

③ そしてAIは、「見えません」と言った

その警告が消えたか確認させようとしたら、こう返ってきました。

「直りました」って言い切ることもできたはずです。 根拠は揃ってたし、実際その通りでした。誰も気づかなかったでしょう。

でも、言い切らなかった。自分に見えないものは、見えないと認めた。

で、こちらが確認して「エラー0件」を確定させました。

……こういうのが、いちばん信用できると思うんですよね。

そしてここから、この機能の射程もはっきりします。Webページそのものは見えるが、ブラウザの開発ツールの中身は見えない。 ここさえ分かってれば、期待値を間違えずに済みます。

まとめ｜「AIに任せる」んじゃなくて「AIと分担する」

AIは「バグを見つける」段階から、「バグを再現して、直して、直ったことを自分で証明する」段階に来ています。

でも、全部を任せられるわけじゃない。人間が見るべき場所は、ちゃんと残ってます。

「AIに任せる」んじゃなくて、「AIと分担する」。

これが、今回いちばん実感したことでした。

おまけ｜AIがフォームを打ち込む様子を、撮り直しました

ここまで読んで「で、AIが実際に操作してる様子は？」と思った方へ。

正直に言うと、最初の検証では映像を残していませんでした。ブラウザペインを閉じたまま動かしていたので、チャット欄に畳まれたログが流れるだけだったんです。

（これ、けっこう大事なポイントです。ブラウザペインを開いておくと、AIが文字を打ち込む様子がそのまま見えます。 閉じてると何も見えない。知らずに損してました）

なので記事のために、修正前の版をもう一度開いて、撮り直しました。

AIが自分でフォームに文字を打ち込んで、ボタンを押して、無反応を確認する。

……これが、今回いちばん「時代が変わったな」と思った瞬間でした。

ちなみに、この撮り直しでも面白いことが起きました

修正前の版を見せたとき、AIがこう言い出したんです。

ライブページは修正前のオリジナルに戻っています。ディスク上のファイルは修正版で正しいです。しかしライブは旧版。 サーバーが別ファイルを配信しているか、キャッシュの可能性があります。サーバーの実際の応答を確認します。

言われてないのに矛盾に気づいて、原因を追いかけ始めました。

「わざと壊れた版を別フォルダに置いてるだけやで」と説明したら、「なるほど、了解しました！」と即座に切り替えて、素直に撮影に協力してくれました。

指示されてないことでも、おかしいと思ったら調べにいく。地味にすごいことやと思いました。

御社のサイトの問い合わせフォーム、最後に押してみたのはいつですか？

VISKでは、Webサイトの健康診断をやっています

• 表示崩れ・フォームの不具合・SEOの取りこぼしを洗い出します

• GA4／Search Console のデータと突き合わせて、「どこで離脱してるか」まで踏み込みます

• ノーコードで作られたサイト（Framer、STUDIO等）にも対応します

今回の検証も、その延長線上でやってることです。

まずは現状のサイトを見せていただくところから。気軽に声かけてください。