QA と Browse：AI に目を与えて、アプリを本当に「見せる」

プログラミングには長らく見逃されてきたブラインドスポットがあります：AI はコードを書けるが、コードが動いている様子を見ることができない。

Claude にログインフローを書かせると、書いてくれます。問題ないように見えます。「ログインページは正しく表示されているか？」と聞いても——答えられません。なぜなら、ブラウザを開いたことがなく、コードしか見えていないからです。

このブラインドスポットは、フロントエンドの変更、UI リグレッション、auth フローのような問題では特に致命的です——問題はロジックではなく視覚状態にあり、コードではなく実際の実行結果にあるからです。

Gstack の /browse と /qa は、このブラインドスポットを修正するためのものです。

`/browse`：AI に本物の目を与える

/browse の背後には、Playwright でコントロールされる永続化された Chromium daemon があります：

初回起動：約 3 秒
その後の各コマンド：100-200ms で完了（クリック、ナビゲーション、スクリーンショット、フォーム入力）
永続化状態：cookies、localStorage、開いているタブはコマンド間で保持
自動シャットダウン：30 分間アイドル後に自動でシャットダウン

Claude for Chrome MCP と比較して、Gstack 公式は 20 倍速いと主張しています——アーキテクチャが異なるからです：Gstack の browse は独立したコンパイル済みバイナリ（58MB、Bun でコンパイル）で、Chromium と直接通信し、MCP のラウンドトリップを経由しません。

できること

/browse https://your-app.com

AI がアプリを開き、以下のことを指示できます：

特定のページに移動し、フォームに入力し、スクリーンショットを撮る
ある要素が表示されているかを確認する
コンソールエラーを読む
ネットワークリクエストを確認する

CSS セレクターではなく accessibility-tree refs（@e1、@e2）を使って要素を特定します——クラス名を変更しても壊れず、一般的な Playwright スクリプトより robust です。

ログイン後のページをテストする

多くの重要な機能はログイン壁の後ろにあり、一般的な自動化テストではアカウントとパスワードの設定、セッション管理が必要で、とても面倒です。Gstack の解決策は：

/setup-browser-cookies

このコマンドはインタラクティブな picker を開き、どの本物のブラウザ（Chrome、Arc、Brave、Edge、Comet）のどのドメインの cookies をインポートするかを選べます。インポート後、/browse と /qa でログイン状態を直接テストでき、アカウント設定を再度行う必要がありません。

Cookie の値はプロセス全体を通して画面に表示されません——Keychain へのアクセスには明示的な同意が必要で、データベースは読み取り専用モードで開かれます。

`/qa`：見るだけでなく、問題を見つけ、修正し、再検証する

/browse は「AI に目を与える」もので、/qa は「AI が目を使って完全な QA フローを行う」もの——違いは自動化の程度と深さにあります。

Diff-Aware テストモード（デフォルト）

/qa のデフォルトは diff-aware モードです：まず git diff を分析して今回の変更がどのページや機能に影響するかを特定し、影響を受けた部分だけをテストします。

これは重要です——アプリに 50 のページがある場合、ボタンを 1 つ変えるたびに完全な E2E スイートを実行したくはありません。diff-aware によりテスト範囲が変更範囲に比例し、速くなり、より的を絞ったものになります。

4 つのテストモード

Diff-aware（デフォルト）：git diff を分析し、影響を受けたページだけをテスト
Full exploration：アプリ全体を実行、メジャーリリース前の全体確認に適している
Quick smoke test：コアフローがまだ動作することを素早く確認
Regression baseline comparison：前のベースラインと比較し、リグレッションを見つける

問題を見つけたら自分で修正する

/qa の完全なサイクルは：

diff を分析して、どのページをテストするかを決定
ブラウザを開き、各ページを実際にテスト
問題を発見し、自動的にバグ修正（atomic commits）
修正後、再テストして修正されたことを確認
ヘルススコア（0-100）とテストレポートを出力

この「問題を見つけて自分で修正する」部分についてもう少し詳しく——でたらめに変更するわけではありません。/review と同様の diff-aware 分析を行い、問題と直接関連するコードを変更し、各変更は独立した atomic commit で、レビューしやすくなっています。

/qa 実行後に git log を確認すれば、何をしたかがわかります。各コミットには明確な説明があります。

`/qa-only`：レポートだけ見て、コードには手を加えない

純粋なバグレポートが欲しい場合——AI がテストを完了して問題を教えてくれるが、自動修正はしてほしくない——/qa-only を使ってください。

適した場面：

バグレポートを整理してチームメンバーに割り当てたい場合
自動バグ修正にまだ十分な信頼を置けず、まず何が見つかるかを確認したい場合

2 つの skill は同じテストロジックを使い、違いは最後に自動修正するかどうかだけです。

ヘルススコアの見方

/qa が出力する 0-100 のヘルススコアは、今回のテストでカバーしたページと機能を加重計算したものです。

大まかな参考：

90+：主要フローはすべて問題なし、せいぜい小さな UX issue がいくつか
70-89：注意が必要な問題がいくつかあるが、コア機能はまだ動作している
50-69：ブロッキングイシューがあり、リリース前に修正することを推奨
50 以下：クリティカルな問題があり、リリース非推奨

スコアは絶対的なものではありません——「Gstack がテストした範囲内での健康状態」を反映するものであり、Gstack がテストしていない部分に問題がないことを意味しません。参考指標として使い、最終判断にはしないでください。

なぜ `/browse` + `/qa` の設定に時間をかける価値があるか

ブラウザの cookies の設定、コマンド構文に慣れること——確かに初期投資が必要です。でも得られるものは：

手動でブラウザを開き、十数ページをクリックして、リグレッションがないかを確認していた QA フローが、今やコマンド 1 つで完了し、コーヒーを取りに行って帰ってきてレポートを確認するだけになります。

独立開発者にとってこのメリットは特に大きいです——毎回完全な手動テストをする時間は取れませんが、/qa はコードをプッシュするたびに基本的なサニティチェックを実行できます。

5 つの記事のコンセプトをすべて説明しました。最後の記事では、すべてをつなげて、実際の開発シナリオで Gstack の完全なワークフローをデモします。

→ 実際の開発シナリオ：新機能から production までの Gstack 完全ワークフロー

シリーズ総覧に戻る

この記事は Gstack シリーズの第 5 回で、/qa と /browse に焦点を当てています。完全な読書ルートと他の記事のトピックは Gstack 入門コース に戻って確認してください。

/browse：AI に本物の目を与える