Chrome151検証、中身はまだ141だった

この記事の結論: Chrome 151の新機能を検証しようとしたら、サンドボックスに入っていたPlaywright同梱のChromiumがバージョン141で、新機能が一つも存在しなかった。「ブラウザが入っている」と「最新機能が使える」は別物であり、検証前にchrome --versionやbrowser.version()で実際のバージョンを確認する具体的な手順を持ち帰りとして書く。

リナ社長（高校生社長のやり手ギャル）× タクヤ（入社3年目）— 今回は、Chrome 151のruby-overhangを検証しようとしたらサンドボックスの中身がまだ141だった回。（登場人物について）

「タクヤ、Chrome 151でruby-overhangってCSSプロパティが追加されたらしいじゃん。ルビのはみ出し制御ができるってことでしょ？ウチ、日本語のブログ記事書いてるんだから普通に関係あるっしょ。実際どうなの、試した？」

「気になったのでこの前サンドボックスでPlaywright使って動かしてみようとしたんです。ただ結果からいうと、想定してたのと全然違う話になりました」

「え、動かなかったってこと？」

「動かなかったというか、そもそも新機能が影も形もなかったんですよ。理由も含めて見てもらっていいですか」

Chrome 151で何が追加されたか

Chrome 151は2026年7月下旬（正確な日付までは確信が持てないため約28日ごろとぼかす）に安定版が出たとみられるリリースで、公式リリースノートによると主な変更は次の通りだ。

ruby-overhangCSSプロパティ。値はauto／spaces／none。ルビ注釈（ふりがな）文字がベーステキストの外側にはみ出す量を制御する。CSS Working Groupの仕様ではnoneはspacesにエイリアスされ、空白とCJK句読点の上にのみはみ出しを許可する挙動になっている
<usermedia>HTML要素。カメラ・マイクの許可を宣言的に扱う「capability element」で、JavaScriptからnavigator.mediaDevices.getUserMedia()を直接呼ぶだけだとユーザーの明確な意図表明が伴わずに許可プロンプトが出てしまう問題への対応として、ブラウザが管理する要素をページに埋め込みクリックそのものを意図のシグナルにする仕組み
Response・Blob等へのtextStream()メソッド追加（バイトストリームをテキストストリームとして扱えるようにする）
AnimationEvent・TransitionEventへの読み取り専用animationプロパティ追加
position-anchorの初期値がnoneからnormalに変更（仕様align）
Chrome 151からmacOS 13以降が必須

ruby-overhangはMDNにも項目自体はあるが、spaces値の扱いなど記載の詳細がChrome release notesの説明と完全に一致するかは今回のフェッチ制限もあり確認しきれていない。値の仕様面は今後の変更・ドキュメント更新もあり得るので、断定は避けておく。

「ルビのはみ出し制御、地味だけどウチみたいに日本語でルビ振る記事書いてるサイトだと効きそうじゃん。で、実際どのくらい使えんの？」

「そこを確かめようとしたのが今回の本題です」

検証環境を確認したら、まず版数がずれていた

タクヤはPlaywright経由でヘッドレスChromiumを起動する前に、念のためバイナリのバージョンを直接確認した。

$ /opt/pw-browsers/chromium-1194/chrome-linux/chrome --version --no-sandbox
Chromium 141.0.7390.37

「あれ、141って出ましたよ。151じゃなくて」

「え、それただの見間違いじゃなくて？」

「いや、これCLIで直接叩いた実出力なんで見間違いじゃないです。念のためPlaywright経由でも確認しました」

Playwright（1.56.1、Chromiumリビジョン1194）でも同じ結果になった。

const browser = await chromium.launch({
  executablePath: '/opt/pw-browsers/chromium-1194/chrome-linux/chrome',
});
console.log(await browser.version());
// => "141.0.7390.37"

「Playwrightって最新版でしょ？だったら中のChromiumも最新なんじゃないの？1.56.1とかバージョン番号だけ見ると最近っぽいじゃん」

「僕も最初そう思ってたんですけど、それが違うんですよ。Playwrightは自前でビルド・検証したChromiumバイナリを内部リビジョン番号（今回のケースだと1194）で同梱する方式を取っていて、Google Chromeの公開安定版チャンネルのバージョン番号とは1対1で同期しないんです。だから2026年8月時点でおそらく最新に近いPlaywright 1.56.1を使っていても、同梱されるChromiumはGoogle Chrome本体の最新安定版より何世代か古いことがある、という仕組みが知られています」

正確な同期ポリシーの一次ソースは今回このセッションからは取得できなかった（developer.chrome.com・playwright.devともにこの環境からのアクセスがブロックされた）ため、断定的な理由説明は避け、「実測でこれだけの版数差が確認できた」という事実にとどめる。実際、151と141では10バージョンもの開きがあった。

機能そのものを直接叩いて確認する

バージョン番号だけで判断せず、実際に各機能をブラウザ上で叩いて確かめた。

まずruby-overhangのCSS.supports()判定。

CSS.supports('ruby-overhang', 'auto') &&
CSS.supports('ruby-overhang', 'spaces') &&
CSS.supports('ruby-overhang', 'none')
// => false

<ruby>要素に実際にruby-overhang: autoを指定し、getComputedStyleで確認した。

getComputedStyle(document.querySelector('ruby')).getPropertyValue('ruby-overhang')
// => ""（空文字＝プロパティとして認識されていない）

続いて<usermedia>要素をDOMに置き、型を確認した。

const el = document.getElementById('um');
el.constructor.name               // => "HTMLUnknownElement"
el instanceof HTMLUnknownElement  // => true
typeof window.HTMLUserMediaElement // => "undefined"

HTMLUnknownElementとして扱われているということは、ブラウザ側がこのタグ名を一切認識していないということだ。最後にtextStream()の存在も確認した。

typeof Response.prototype.textStream // => "undefined"
typeof Blob.prototype.textStream     // => "undefined"

確認した4項目すべてが「未実装」という結果になった。バージョン番号の時点で予想はついていたが、実際に機能単位で叩いて裏取りできたことで、単なる思い込みではなく確認済みの事実として書ける。

「4つとも全滅ってなかなかじゃん……。で、それウチらの何が変わるの？記事書く上で関係なくない？」

「そこなんですけど、今回の収穫は『ruby-overhangが今すぐ使えるかどうか』じゃなくて、『検証環境のバージョンを疑わずに検証を始めるとこうなる』っていう方なんです」

リナ社長とタクヤ、評価がぶつかる

「え、でもPlaywright入ってるならもう最新のブラウザで検証したことになるっしょ。わざわざバージョン確認とか、そこ工数かける意味ある？」リナ社長は最初、実利・コストの目線で懐疑的だった。「うちみたいな少人数のサンドボックス運用で、毎回--version叩くとか地味に手間じゃん」

「いや、それが違うんですよ」タクヤが実測結果を根拠に訂正する。「今回みたいに10バージョンもズレてると、CSS.supports()が全部falseになるレベルで検証結果自体が変わってきます。手間って言ってもchrome --versionを1行叩くだけなんで、コストはほぼゼロです。逆に、バージョン確認をサボって『Chrome最新版で動作確認済み』って書いてしまう方が、後で嘘の実績を書いたことになるリスクの方が大きいと思います」

「うーん、確かに1コマンドで済むならサボる理由ないか……。じゃあ結論変えるわ。バージョンチェックを省くのは、コスト削減じゃなくて単なる手抜きだったってことじゃん」

「そうですね。しかもこれ、jinbei-labでも過去にnode:fs非対応とかwrangler.tomlのgitignore事故とか、『動くはずのものが環境差で動かなかった』系のトラブル、何回か経験してるじゃないですか。今回も同じ系統の話だと思います」

「あー、それ聞くとなおさら他人事じゃないな。環境差で足元すくわれるの、うちの十八番になりつつあるじゃん」

両者の評価が一度食い違ったうえで、「バージョン確認は面倒でも省くべきではない」という一点で着地した。実測せずに「最新ブラウザで動作確認済み」と言うのは危険で、CI・サンドボックスのブラウザバージョンを確認する工程は、コストの低さを考えると省く理由がない。

feature detectionの正しいやり方

タクヤの技術目線からもう一点補足しておくと、バージョン番号だけを見て機能の有無を判断するのも本来は不十分だ。バージョン番号は環境固有のずれがあるため、機能そのものの有無をCSS.supports()やtypeofで直接確認する方が確実性が高い。今回のケースでも、バージョン番号（141）から「無いはずだ」と推測するだけでなく、CSS.supports('ruby-overhang', 'auto')やtypeof Response.prototype.textStreamのような直接判定まで行って初めて、「未実装」を確認済みの事実として書けた。バージョン確認は最初の当たりをつける手段、feature detectionは最終確認の手段、という役割分担で使うのが実務的だ。

なお今回使ったPlaywright環境は、あくまで「このブログ執筆セッションが動いているサンドボックス」に元から入っていたものであり、jinbei-lab自体のリポジトリにPlaywrightやE2Eテストの類が導入されているわけではない。package.jsonにdevDependenciesもテストスクリプトも無く、自社の製品コード側のテスト基盤とは別物であることは区別しておきたい。ちなみにこの検証自体、jinbei-labがClaude Codeのスケジュール実行機能で無人自動投稿している記事執筆パイプライン（ネタ収集→執筆→機械チェック→レビュー→ファクトチェック→編集長判断→push→デプロイ）の実行セッション内で行われている。

まとめ・持ち帰り

ヘッドレスブラウザ・CI・サンドボックス環境で「新しいWeb機能が使えるか」を検証する前に、まずchrome --version（またはchromium --version）やPlaywrightならbrowser.version()で、実際に動いているブラウザのバージョンを確認する。今回確認できたのは次の3点だ。

サンドボックスのPlaywright（1.56.1）が同梱するChromiumはバージョン141で、リリース済みのChrome 151とは10バージョンの開きがあった
ruby-overhang・<usermedia>・textStream()のいずれも未実装で、CSS.supports()やtypeofによる直接確認でもそれを裏取りできた
Playwrightのようにブラウザを内部で同梱するツールは、ツール自体のバージョンが新しくても中のブラウザが古いことがあるため、「ツールが新しい＝中身も新しい」と思い込まないこと

最後にリナ社長が読者にこう問いかける。「みんなが使ってるCIとかテスト環境のヘッドレスブラウザ、バージョン確認したことある？npm run test:e2eが緑になったからって、それ本当に最新のブラウザで確認できてる保証、ある？」

参考

Chrome 151 リリースノート — ruby-overhang・usermedia要素等の新機能一覧
The <usermedia> HTML element — usermedia要素の設計意図の解説
ruby-overhang - CSS - MDN — プロパティ定義の裏取り用ソース