Google の Chrome チームが11月11日、AI のコーディングエージェントが Web 開発でよく間違える10の項目を、Top 10 things AI gets wrong in web development として公開しました。モーダルを自前の JavaScript で作る、ダークモードで画面が一瞬白く光る、頼まれないとセキュリティの設定を付けない、といった一世代前の書き方です。前日の10日には、エージェントに今のブラウザの書き方を教える Modern Web Guidance の v1.0 を出しています。Chrome の評価では、何も入れないエージェントは確認項目の52%しか通らず、入れると91%まで上がりました。
背景と文脈
AI に Web の画面を書かせると、動くけれど古い書き方のコードが返ってくることがよくあります。モデルは学習した時点までのコードをもとに書くので、ネット上に大量に残っている昔のやり方のほうが出やすくなります。
ダイアログがわかりやすい例です。今のブラウザには <dialog> 要素や popover 属性があり、フォーカスの移動や Esc キーで閉じる動きまでブラウザが受け持ってくれます。それでも AI は、position: fixed の div と、外側をクリックしたら閉じる処理を自分で書きがちです。動きはしますが、キーボードだけで操作する人や読み上げソフトを使う人には不便なままになります。
Chrome チームはこのずれを埋めるために Modern Web Guidance を作りました。中身は、エージェントが作業の途中で読みに行く手引き書の集まりです。配り方はスキル（エージェントが必要なときだけ開く、手順や知識をまとめたファイル）の形で、Claude Code、Codex、Cursor、Gemini CLI などで使えます。7月には試せる状態になっていて、11月10日の Modern Web Guidance 1.0 の発表で正式版になりました。この版から Microsoft Edge と Firefox のチームも加わっています。
何を勧めるかは Baseline（主要なブラウザのどれでも使える Web の機能を、使えるようになった時期で分けた一覧）で決まります。設定しなければ、どのブラウザでも使えるようになってから30か月以上たった Widely available の機能だけを勧めます。
技術/ビジネス面
10項目は、アクセシビリティ、使い勝手、速さ、セキュリティの4つの分野に分かれています。記事に挙がっている例から、それぞれ代表的なものを表にしました。
| 項目 | AI がよく書くもの | Chrome が勧める書き方 |
|---|---|---|
| キーボードのフォーカス | モーダルを開いてもフォーカスを移さない。JS で自前の閉じこめ処理 | モーダルの <dialog>、背景に inert |
| 動きを減らす設定 | 全体に scroll-behavior: smooth。全要素のアニメーションを 0.01ms にする一括指定 | prefers-reduced-motion を見て、なくてよい動きだけ止める |
| フォームの入力チェック | blur で JS のチェック。入力例を placeholder だけに書く | :user-invalid、aria-describedby でつないだ消えないヒント |
| スワイプ | pointermove で位置を自前で計算 | CSS Scroll Snap、overscroll-behavior-x |
| ダイアログ・ポップオーバー | setTimeout や transitionend で開閉のアニメーションを管理 | popover、@starting-style、transition-behavior |
| ダークモード | color-scheme の meta がなく、読み込み時に白く光る | color-scheme の meta タグ、light-dark() |
| 操作への反応の速さ | setTimeout で自前の処理待ちの列を作る | scheduler.yield()、content-visibility: auto |
| レイアウトのずれ | <video> に幅と高さを書かない。高さに vh を使う | width と height を書く、dvh・svh |
| DOM の XSS | DOMParser で自前の無害化処理 | ブラウザの setHTML()。DOMPurify は使えないときだけ後から読む |
| パスキー | Base64URL の変換を atob・btoa で自作 | parseCreationOptionsFromJSON()、credential.toJSON() |
どの項目も、ブラウザにすでにある機能を使わずに、同じことを JavaScript で作り直している点が共通しています。自前の処理はコードが長くなり、フォーカスや読み上げの扱いが抜けやすくなります。
差は数字にも出ています。Chrome の評価のグラフでは、何も入れないエージェントが確認項目を通った割合は52%で、Modern Web Guidance を入れると91%でした。確認には Playwright（ブラウザを自動で動かすテストの道具）を使い、作られた画面が決めた条件を満たすかを調べています。ただし、どのモデルで何回試したかは記事に書かれていません。
Chrome によると、評価したどの場面でも、モデルは頼まれないかぎり CSP（Content Security Policy、読み込んでよいスクリプトをブラウザに伝える設定）を付けませんでした。XSS（Web ページに他人のスクリプトを差しこむ攻撃）を防ぐ設定は、こちらから指示しないと入らないと考えておいたほうがよさそうです。
使った企業の報告もあります。note 株式会社の事例では、自社のコードで180回試し、確認項目の合格率が61%から94%に上がりました。MetaMask はプルリクエストの点検に使い、5週間で約480件を見て43件を直しています。どちらも企業自身の報告で、外から確かめた数字ではありません。
開発者として試すなら
入れるのは1行で済みます。プロジェクトのフォルダで次を実行すると、対話式で使っているエージェントを選べます。前の版を入れている場合は install を update に変えます。
npx modern-web-guidance@latest installClaude Code なら、公式の導入ページに次のコマンドも載っています。Codex、Gemini CLI、GitHub CLI 向けのコマンドも同じページにあります。
claude plugin install modern-web-guidance@claude-plugins-official入れる前に中身を見たいときは、検索と取り出しのコマンドを手で打てます。エージェントが裏でしていることを、そのまま確かめられます。
npx modern-web-guidance@latest search "animate a dialog modal backdrop"
npx modern-web-guidance@latest retrieve "animate-to-from-top-layer"入れたら、対応するブラウザの範囲を AGENTS.md か CLAUDE.md に1行書いておきます。書かなければ Widely available の機能しか勧めません。社内ツールのように新しいブラウザだけ相手にすればよいなら、範囲を広げると新しい書き方まで使ってくれます。LogRocket の記事では「This project’s Baseline target is Baseline 2024.」という書き方を例にしています。
今あるコードを直したいときは、v1.0 で入った書きかえの手順を使います。エージェントに次のように頼むと、HTML、CSS、JavaScript、package.json から古い書き方を探します。今の版は、決まった型を静的に調べるだけで、すべての古い書き方を拾うわけではありません。
/modern-web-guidance Modernize the code in this directory公開されている数字を並べると、次のとおりです。
| 出どころ | 条件 | 入れる前 | 入れた後 |
|---|---|---|---|
| Chrome の評価（11月11日の記事） | モデル・回数は書かれていない | 52% | 91% |
| note 株式会社 | 自社のコードで180回 | 61% | 94% |
| Chrome の導入ページ | 初期の結果 | 37ポイントの改善 | |
手引き書を読む分だけ、エージェントの文脈（一度に覚えておける文章の量）を使います。導入ページの検索結果の例では、手引き書1本あたり約1,100〜7,100トークンでした。長い作業で何本も読ませると、そのぶん文脈の残りが減ります。
スキルは動くたびに npx で npm のパッケージを取りに行きます。社内のネットワークから npm に出られない環境や、依存パッケージの版を固定している現場では、入れる前に扱いを決めておく必要があります。
手引き書どおりに書かれたコードも、人の確認はいります。LogRocket のブログの筆者が7月に Gemini CLI と Next.js で同じ指示を出して比べたところ、入れたほうはモーダルを <dialog> と @starting-style で書き、入れないほうは setTimeout で300ミリ秒待つ処理を書きました。一方で、入れたほうのツールチップは CSS Anchor Positioning を使っていて、使えないブラウザ向けの代わりの処理がありませんでした。筆者は、対象のブラウザ、キーボード操作、読み上げソフトでの確認は人がするように勧めています。
これからどうなるか
AI に書かせたコードで、あとから古い書き方を直す手間は減りそうです。表の10項目は、そのままコードレビューの確認表として使えます。AI が書いたモーダルやフォームを見るときに、<dialog> を使っているか、CSP が付いているかを順に確かめるだけでも、見落としが減ります。
React や Next.js で画面を作らせているなら、モーダルやツールチップのためのライブラリが本当に必要かを、1度見直してみてもよいでしょう。ブラウザの機能で足りれば、依存パッケージが減り、バンドルの大きさと更新の手間も減ります。ただし、新しい機能を使うほど古いブラウザで動かないおそれが増えます。Baseline の範囲をどこに置くかは、エージェントではなくチームで決めて、AGENTS.md に書いておくことになります。
v1.0 の発表では、エージェントがブラウザを動かして確かめる Chrome DevTools for agents と組み合わせる使い方も紹介しています。メインスレッドを50ミリ秒以上ふさいでいないか、動きを減らす設定で表示が変わるかを、エージェント自身に確かめさせる例です。Edge と Firefox のチームが加わったので、Chrome だけに寄った手引き書になりにくい点も安心材料です。
まとめ
Chrome チームが、AI が Web 開発で書きがちな古いコードを10項目にまとめ、対策として Modern Web Guidance 1.0 を出しました。入れると Chrome の評価で確認項目の合格率は52%から91%に上がります。npx の1行で試せますが、対応ブラウザの範囲を AGENTS.md に書くことと、CSP や代わりの処理が入っているかを人が確かめることは、入れたあとも必要です。
参考リンク
- Top 10 things AI gets wrong in web development（Chrome for Developers）
- Modern Web Guidance 1.0: The web platform expertise your coding agent is missing（Chrome for Developers）
- Get started with Modern Web Guidance（Chrome for Developers）
- How note inc. boosted modern web guideline adherence from 61% to 94% using Modern Web Guidance（Chrome for Developers）
- GoogleChrome/modern-web-guidance-src（GitHub）
- Chrome’s Modern Web Guidance（LogRocket Blog）
- Baseline（web.dev）
アイキャッチ画像: Photo by Leslie Cross on Unsplash
