配信の検証をAIに任せました — 7回・204項目で分かった線引き

配信機能の動作確認を、ブラウザを直接操作できるAIに任せるようにしました。使っているのは Claude in Chrome です。検証項目を書いた手順書をそのまま渡すと、AI自身が検証環境を開き、画面を操作し、スクリーンショットを撮って結果を判定します。

直近の開発では、7回の検証でのべ204項目を確かめ、55件のNGが出ました。

ただし、AIに判断させていないことがあります。 音が鳴っているか、映像が乱れていないか。この2つは人の耳と目で確かめます。AIが結果を確かめる手段はスクリーンショット、つまり静止画だけだからです。動いている映像の滑らかさも、鳴っている音も、静止画には写りません。

仕組みと、その線引きについて書きます。

検証項目は、端末の数だけ増えます

配信の機能は、組み合わせで検証項目が増えます。

ひとつの質疑応答を確かめるだけでも、こうなります。配信の方式（エンコーダからの送信か、ブラウザからの送出か）。待機室のONとOFF。画面を開く人の役割（テナント管理者、システム管理者、視聴者、質問者）。そして端末とブラウザ。

掛け算なので、機能をひとつ足すたびに項目は跳ね上がります。

さらに厄介なのが、1台のPCでは検証できないことです。質疑応答は、送る側と受ける側が同時に動いて初めて成立します。同じPCで両方の画面を開くと、いま鳴っている音がどちらの画面から出ているのかが分からなくなります。 マイクも1本を取り合うので、片方が掴んだ時点でもう片方は使えません。

この「端末を並べて、順番に同じ操作を繰り返す」作業が、検証時間の大半を占めていました。

AIがブラウザを直接操作するようになりました

変わったのは、AIが画面を触れるようになったことです。

これまでのAIの使い方は、コードを書かせることでした。テストを自動化したければ、テストコードを書き、実行環境を用意し、壊れたら直す。その保守自体が仕事になります。 画面の文言やボタンの位置が変わるたびに書き直すことになるので、開発中の画面には割が合いませんでした。

Claude in Chrome は、ブラウザそのものを操作します。 手元のChromeでページを開き、クリックし、文字を入力し、スクロールします。人が画面を触るのと同じ経路です。

なので、渡すものはテストコードではなく、日本語で書いた検証手順書になります。

F-2 視聴ページで自分の映像が映るか
手順: 視聴ページで「質問する」→ カメラとマイクを選んで挙手する
期待値: 自分のカメラ映像が映る／帯に「担当者と接続中です」と出る

この形の項目を並べて渡すと、AIが検証環境を開き、ログインし、イベントを作り、視聴ページを開いて挙手し、スクリーンショットを撮って期待値と突き合わせます。 結果は F-2 | OK | 見えた値: … の形で記録されて戻ってきます。

権限の使い分けもさせています。テナント管理者は通常のウィンドウ、システム管理者はシークレットウィンドウ。ログインし直しながらでは検証が途切れるので、2つのウィンドウを開いたまま行き来してもらいます。

もちろん、AIが操作できるのはそのPCのブラウザだけです。スマートフォンやタブレットを並べて確かめる部分は、いまも人が持っています。

7回まわして、のべ204項目・NG 55件でした

実際の数字を出します。配信オペレーション画面の刷新と、それに続く機能追加の期間の記録です。

回	対象	項目数	NG
1〜3	配信オペレーション画面の刷新	44 / 47 / 43	28 / 21 / 0
4	公開後の確認	5	0
5〜7	続く機能追加	32 / 19 / 14	4 / 1 / 1

合計でのべ204項目、NG 55件、差し戻しは6回です。同じ期間に開発側でマージした変更は、5本のPRで182ファイル・約17,000行でした（いずれも自社の記録です）。

この表で言いたいことは、1回で通ることはないという一点です。1回目は44項目中28件がNGでした。3回目でようやく0になります。3回前後で収束するというのが、いまのところの体感です。

検証項目を作る工程も変わりました。以前は、直した内容を見ながら「どこを確かめるべきか」を自分で書き出していました。修正が10か所あれば10か所ぶん考えます。いまは直したコードから項目を起こしてもらうので、ここが2日から1日になりました。

前回の結果を引き継げるのも効いています。手順書は「前回NGだった項目の再確認」「前回NGのまま残っている項目」「前回OKだった線が壊れていないかの確認」に分かれていて、どこで落ちたかが次の手順書に残ります。

もうひとつ、人がやらない検証をやってくれます。 ある回では、視聴ページを開いたまま21分22秒放置してもらいました。そこで、視聴者が15分ほどで切断されるという重い不具合が見つかりました。リロードすれば元に戻るので、短い確認では出てきません。 人が20分ただ待つ検証は、正直なところ後回しにしがちです。

手順書の書き方で、結果が変わりました

同じAIでも、渡す文章によって結果の質が変わります。 効いた書き方が2つあります。

ひとつめは、この一行です。

期待値と違う場合は、推測で直したり再試行を繰り返したりせず、見えた値をそのまま記録して次へ進む。

これを書かないと、AIは自力で回避しようとします。読み込みが遅いのだろうと再試行し、別の手順で迂回し、最後は「動きました」で終わります。 不具合はそのまま残ります。検証で欲しいのは解釈ではなく、画面に出ていた文言そのものです。

ふたつめは、期待値を「場所・表示項目・期待値」の3点で書くことです。

人に「配信中になること」と言えば、一覧とダッシュボードとコンソールの3か所を勝手に見ます。AIは指定した場所しか見ません。 その代わり、指定した場所は毎回必ず見ます。 見落としが無い代わりに、書き漏らした場所は永久に見られません。この性質は、手順書を書く側が引き受けるしかありません。

結果として、報告に実測値が残るようになりました。「動いています」ではなく、こうなります。

• ボタンの aria-pressed が true から false に変わった
• 3画面とも同じ赤（rgb(185, 28, 28)）で表示されている

後から見返せる形で残るので、次の検証の期待値がそのまま作れます。

判断の根拠は、スクリーンショットしかありません

ここが本題です。操作は任せますが、判断は任せません。

AIが結果を確かめる手段は、画面を撮ったスクリーンショットです。文言が出ているか、ボタンが押せる見た目か、数値がいくつか。ここまでは静止画で確かめられます。

静止画に写らないものが2つあります。 音と、映像の動きです。

音は、そもそも画像になりません。映像は写りますが、写るのはある瞬間の1枚です。カクついているか、ブロックノイズが出ているか、音と口が合っているかは、1枚の絵からは判定できません。配信の品質は、まさにそこにあります。

しかも配信では、画面上は正常なのに音が出ていないということが普通に起こります。「発言中」と表示され、通信状況の数値も出ていて、それでも声が聞こえない。スクリーンショットを見るかぎり、これは合格と判定されます。待機室を作ったのも、まさにそれが理由でした。

そこで、手順書にこう書いてあります。

音が聞こえるかの判定は自分ではできない。その行は【人に依頼】して結果を聞き取る。

該当する行に来たら、AIは作業を止めます。人が聞き、見て、結果を伝え、そこから再開します。確かめられないことを確かめたつもりにさせないのが、この一文の役目です。

触ってよい画面を限定することも、同じ場所に書いています。AIから見れば、本番の画面も同じブラウザで開けます。開いてよいURLを検証環境だけに限り、本番のドメインは開かない。 Stream Keyのような値を記録に含めないことも、あわせて明記しています。

AIの検証結果にも、人のレビューが要ります

ここまで書くと自動化がうまくいった話に見えますが、AI特有の誤判定も5件ありました。

• ブラウザ標準の確認ダイアログを自分で承認してしまい、「確認なしで実行された」と報告した
• 静止画を映すカメラを選んだまま、「映像が出ない」と報告した

どちらも、AI自身の操作が原因で、製品側は正常です。これをそのまま是正指示に回すと、無い不具合を直しにいくことになります。検証結果は読んでから使うのが前提です。

逆に、AIだから見つかったものもあります。画面に出す案内文のうち、存在しない操作へ誘導していた文言が2件見つかりました。書いたのはAIで、見つけたのもAIです。指示を書いた側も、検証の期待値を書いた側も間違えていました。

不具合の直し方も変えました。以前は見つけるたびに修正を依頼していました。いまは検証を最後まで走らせてから、NGをまとめて渡します。 同じ原因の不具合がまとまって見えるので、直し方が変わります。3つの画面で文言が食い違っていたなら、1件ずつではなく「3箇所を揃える」として直せます。読ませる文脈が減るぶん、消費するトークンも減りました。

もうひとつ効いているのが、実装するAIと検証するAIを分けていることです。ある不具合では、実装側の立てた原因の仮説が外れていました。真因を示したのは、検証側が残した実測値のほうです。同じ文脈を持っていない相手に確かめさせることに意味があります。

まとめ

• AIがブラウザを直接操作するようになったので、渡すのはテストコードではなく日本語の手順書です。AI自身が検証環境を開き、操作し、スクリーンショットで期待値と突き合わせます
• 直近の記録は7回・のべ204項目・NG 55件。1回目は44項目中28件がNGでした。1回で通ることはなく、3回前後で収束します
• 手順書の書き方で結果が変わります。 「推測で再試行せず、見えた値をそのまま記録する」と書かないと、AIは自力で回避して「動きました」で終わります
• AIは指定した場所しか見ない代わりに、指定した場所は毎回必ず見ます。 期待値は「場所・表示項目・期待値」の3点で書きます
• 判断の根拠は静止画だけです。音は画像になりませんし、映像のカクつきは1枚の絵には写りません。音と映像の品質は人の耳と目に残します
• AIの検証結果にも人のレビューが要ります。 今回は、AI自身の操作ミスを不具合として報告したものが5件ありました

自動化できたのは、決まった操作を、決めた順番で、間違えずに繰り返す部分です。そこが人にとっていちばん退屈で、いちばん抜けやすいところでした。21分待つ検証も、AIなら嫌がりません。抜けやすい作業を機械に渡し、判断が要るところに人が残る。いまのところ、この形に落ち着いています。

そのうえで、ひとりで開発している立場からは、速くなったこと以上に「目が増えた」ことが大きいと感じています。

この検証で確かめていた機能そのものについては、質疑応答に「待機室」を作りましたに書いています。