YouTube・ケーススタディ

ケーススタディ：MetaMaskのレビューボット

元の資料：Case Study: MetaMask — How a Modern Web Guidance review bot helps MetaMask ship accessible, modern UI
2026年11月10日（Chrome for Developers ブログ）

このページには実際に動く作例があります。

全プルリクエストをModern Web Guidanceでレビューするボットを、たった3行の指示で運用した事例です。指摘が何を直し、何がノイズだったかまで数字で公開されています。

現場

MetaMaskは、約190か国で1億回超ダウンロードされた自己管理型の金融プラットフォームです。ブラウザ拡張は公開開発で、社内外からプルリクエスト（PR）が絶えず来ます。UXエンジニアのFrancis Nepomucenoが、アクセシビリティのベストプラクティスと現代的なWeb機能の使い方を、PRを出す全員に一貫して届ける方法を探していました。金融を扱うため依存の審査が厳しく、ライブラリよりブラウザ標準の機能のほうが取り入れやすい、という事情も後押ししています。

仕組み：3行の指示

ボットはCursor Automationで動き、設定はこの3行だけです。

- Run /modern-web-guidance for any client-facing changes
- Run /chrome-extensions for any relevant extension changes
- Comment on the PR only when there are issues to address. Keep the comment focused on actionable items

• 助言に徹します。最初の2日は変更要求の形でしたが、9月18日以降はコメントのみで、マージは止めません。最終判断は出す側に残ります。
• 指摘には、根拠のガイド名と、リポジトリ内に既にある推奨パターンのファイルへの参照が付きます。
• UIに触れないPRでは静かです。5週間で約480件のPRのうち、UIやクライアントのコードに触れたのは少なくとも100件でした。

代表例：FAQのアコーディオン

「How it works」ページのFAQが、Reactの状態で中身をDOMから出し入れする普通の作りで出てきました。約5分後、ボットが search-hidden-content ガイドを引いて3点を指摘しました。閉じた答えがDOMから消えるとページ内検索で見つからず、支援技術からも見つけにくいこと。標準の <details>／<summary>（Baseline 2020年〜）なら中身がDOMに残り、意味も正しくなること。排他に開きたい場合は name 属性の共有（Baseline Newly available、2024年〜）で自動で他が閉じること。既存のDisclosure部品を使うなら、答えを hidden="until-found" でDOMに残し、beforematch で状態を同期すること。

13分後、出す側が修正を push しました。部品は標準の <details> になり、閉じた答えもページ内検索に残り、ついでにナビゲーションのボタン2つがリンクになりました。

作例：そのFAQの形

下が実際に動く形です。ブラウザのページ内検索で、閉じた答えの言葉（例：「検索」）を探すと、対応ブラウザでは該当の欄が開きます。

ほかに捕まえたもの

• 編集できそうに見えて入力を捨てる欄。取引手数料の上限の欄が、見積もりの読み込み中や失敗時に、見た目は編集可能なのに入力を無視していました。欄を使えなくし、状態の文を欄と結んで支援技術に読ませ、保存ボタンが使えない理由も同じ文に結び、数字入力モードに替える、という3点が直りました。
• ボタンで作られたリンク。新しいタブをJavaScriptで開くボタンは、支援技術にはボタンと読まれ、URLのコピーや新しいタブで開く操作も使えません。リポジトリ内に既にあるリンク版のバナー部品を指して指摘し、12分でリンクに替わりました。
• ラベルが別の場所にある入力。複数ステップのフォームで、見出しと説明が親のレイアウト側にあり、入力欄のラベルがプレースホルダだけになっていました。静的なリンタでは親子をまたいで見られません。15分で3点とも直り、その後の見た目の作り直しでも配線が保たれました。
• ほかにも、入力の途中で値が丸め込まれる問題、読み込み中であることが支援技術に伝わらない問題、非同期ボタンの二重押し、フォーム要素なしのキー入力ごとの検証、などが数分〜十数分で直っています。

5週間の数字（2026年10月21日まで）

直らなかったものと、ノイズ

機能・修正のPRの102件のうち、範囲外・設計どおり・実施済みとして見送られたものや誤検出が16件、対応されなかったものが20件、不明が20件でした。傾向として、1つの部品の中で閉じる修正はよく直り、横断的なアクセシビリティの修正は、PRの範囲外だったり、土台の部品がまだなかったりして直りにくい、と分析されています。誤検出は、静的なリンタではなく差分を読むエージェントであることから来ていて、周囲の読み違いと、ガイドより厳しく規則を当てることが原因でした。次の調整は、リリースや同期のブランチを対象から外すことと、プロンプトを締めてガイドに明記された規則だけに絞ることです。

「レビューは本当に役に立っています。Interest invokersやPopover APIのような現代的なAPIに、エンジニアが触れて慣れるきっかけにもなりました。PRのレビュー時間が増えた様子はなく、むしろ減ったように思います。」— Francis Nepomuceno（UX Engineer, MetaMask）※発言の要旨