WEBサイトChrome 154で、iframeの高さを中身に合わせる指定が入った。ただし親のCSSと子のmetaの2か所が要る ── 自社の埋め込みを「両側を持つもの」と「提供元に頼むもの」に分ける13項目（2026年10月時点）
Chrome 154で、iframeの高さを中身に合わせる指定が入った。ただし親のCSSと子のmetaの2か所が要る ── 自社の埋め込みを「両側を持つもの」と「提供元に頼むもの」に分ける13項目（2026年10月時点）
目次
01 何が起きたか — Chrome 154で、iframeの高さを中の内容に合わせる指定が入った。ただし、親と子の2か所に書く必要がある
Chrome 154のリリースノートに載った1項目
Chromeの開発者向けのリリースノート「Chrome 154」を、2026年10月5日に開いた。冒頭には、安定版のリリース日が2026年9月22日と書かれている。ページの中の「Responsively-sized <iframe>」という項目は、次のように説明されている。
"Lets sites opt into responsive sizing for iframes. This sizes the <iframe> element in the parent document to the embedded document's layout overflow sizing, avoiding scrolling in the child document."
（訳: サイトが、iframeの高さを中身に応じて変える仕組みに参加できるようにする。これは、親のページにあるiframe要素の大きさを、埋め込まれたページの内容の大きさに合わせ、子のページの中でスクロールが起きないようにする。）
仕様は、CSS Box Sizing Module Level 4という文書の中にあり、この文書は「Editor's Draft」（訳: 編集者の草案）で、日付は2026年9月6日と表示されている。
書く場所は、親のCSSと、子のmetaの2か所
同じ日に出た「New in Chrome 154」は、使い方を次のように書いている。
"Chrome 154 adds support for responsively-sized iframes, letting an <iframe> element in a parent document size itself to the embedded document's layout overflow sizing so that scrolling in the child document is avoided."
（訳: Chrome 154は、中身に応じて大きさが変わるiframeに対応した。親のページにあるiframe要素が、埋め込まれたページの内容の大きさに合わせて自分の大きさを決められるようになり、子のページの中のスクロールが避けられる。）
手順は2つに分かれる。1つ目は、埋め込む側のページのCSSに、frame-sizing: content-height;と書く。2つ目は、埋め込まれる側のページのheadに、<meta name="responsive-embedded-sizing" content="allow-origins=*">という要素を書く。どちらか片方だけでは、高さは中身に合わない。
従来の方法を置き換える、と公式は書いている
"This replaces the pattern where you manually measure iframe content, send dimensions with postMessage(), and update the iframe size in the embedding page."
（訳: これは、iframeの中身を自分で測り、postMessage()で大きさを送り、埋め込む側のページでiframeの大きさを更新する、という従来のやり方を置き換える。）
子の側の宣言には、書く場所の決まりがある
公式のブログ「Responsive iframes in Chrome 154」（2026年9月16日公開）には、こういう注意書きがある。
"Note: For responsive sizing to work, the meta tag can't be added dynamically after the embedded document has loaded."
（訳: 注意: 中身に応じた大きさの変更を働かせるには、埋め込まれたページの読み込みが終わったあとに、JavaScriptでmetaタグを足してはいけない。）
CSSの仕様の文書は、もう少し詳しく書いている。ページを読み込む途中で、このmetaが先に見つかれば有効、本文（body）が開く方が先なら無効と決まり、いったん決まると、そのページでは変わらない。また、同じ文書の注記には、HTMLでこの宣言ができるのは、今のところhead内のmeta要素だけと書かれている。
"Currently, the HTML meta element appearing in the head of an HTML document is the only way for an embedded document to opt into this feature in HTML. This means that SVG documents in iframe cannot do so."
（訳: 今のところ、HTML文書のheadに置くHTMLのmeta要素が、埋め込まれた文書がHTMLの中でこの機能に参加する唯一の方法である。つまり、iframeの中のSVG文書は、参加できない。）
frame-sizingには、5つの値がある
公式のブログは、値として次の5つを挙げている。autoは従来どおりの大きさ。content-widthとcontent-heightは、中身の幅と高さに合わせる。content-inline-sizeとcontent-block-sizeは、書字方向に応じた幅と高さである。
この記事が書くことと、書かないこと
この記事は、自社の埋め込みを棚卸しして、「両側を持つもの」と「提供元に頼むもの」に分ける手順を書く。外部の提供元が、自分のページにこのmetaを入れるかどうかは、確かめていない。
02 なぜ・背景 — 既定のiframeは中身の大きさを外に見せないので、自分で測って送る作りが必要だった
既定のiframeは、中身が高いとスクロールバーが出る
公式のブログは、既定の動きを次のように書いている。
"By default, an iframe has its own viewport. If the embedded document is taller than that viewport, users may get an additional scrollbar."
（訳: 既定では、iframeは独自の表示領域を持つ。埋め込まれたページがその表示領域より高い場合、利用者には追加のスクロールバーが出ることがある。）
地図・予約・フォームなどをiframeで埋め込んだページで、枠の中に縦のスクロールバーが出て、ページ全体のスクロールと二重になることがある。
仕様は、既定では中身の大きさを外に見せない、と決めている
CSSの仕様の文書は、その理由を、プライバシーと安全のためと書いている。
"For privacy and security reasons, these elements do not, by default, expose any information about their internal contents' sizing to the outside page, instead just using a static, predetermined intrinsic size, and making their contents scrollable."
（訳: プライバシーと安全のために、これらの要素は、既定では、内部の内容の大きさに関する情報を、外側のページに見せない。代わりに、あらかじめ決められた固定の大きさを使い、中身をスクロールできるようにする。）
だから、親のCSSだけでは中身の高さが分からない。子のページが「見せてよい」と宣言するのが、metaの役目である。
従来は、子が高さを測って親に送っていた
従来の方法では、子のページが、自分の高さをJavaScriptで測り、postMessage()で親に送り、親がiframeの高さを書き換えていた。公式の説明によれば、今回の仕組みはこのやり方の置き換えである。自分で両側のコードを書いていた場合は、そのコードを減らせる可能性がある。
公式が挙げる、使う場面
"This is perfect for seamlessly embedding third-party comment widgets, varying-height social media embeds, or any other type of embed that uses an <iframe>."
（訳: これは、第三者のコメント欄の部品、高さが変わるSNSの埋め込み、そのほかiframeを使うあらゆる埋め込みを、違和感なく埋め込むのに最適である。）
公式が書く、表示のずれの注意
"Note: Responsive iframes might cause content shifts as the embedded document is loaded after the host document and might shift content on your page. This can negatively affect your Core Web Vitals, in particular, when displaying responsive iframes in the first viewport."
（訳: 注意: 中身に応じて大きさが変わるiframeは、埋め込まれたページが親のページのあとに読み込まれるため、ページの内容をずらすことがある。これは、とくに最初の画面にそのiframeを表示するときに、Core Web Vitalsに悪い影響を与えうる。）
高さの変化が、読み込みのあとに起きるので、その下にある文章が押し下げられる。Core Web VitalsのCLSは、当サイトのCore Web VitalsのLCP・INP・CLSは「良好・改善が必要・不良」の3段階で判定される ── 自分のサイトで確認する14項目（2026年9月時点）で扱っている。
03 用語 — 親・子・提供元が入り交じるので、先に呼び名をそろえる
iframeと、親・子
用語
iframe：あるページの中に、別のページを枠の中に表示するHTMLの要素である。親（埋め込む側）：iframeを置いているページ。子（埋め込まれる側）：iframeの中に表示されるページ。この記事では、親のCSSと、子のmetaという呼び方で書く。
CLS
用語
CLS（Cumulative Layout Shift）：ページの読み込み中や操作中に、画面の内容が予期せずずれた量を表す指標である。iframeの高さが読み込みのあとに変わると、その下の内容がずれて、数字が悪くなる場合がある。
postMessage
用語
postMessage：別のページや別のiframeの間で、JavaScriptがメッセージをやりとりする仕組みである。従来は、子が測った高さを親に伝えるために使われていた。
allow-originsとframe-ancestors
用語
allow-origins：子のmetaのcontent属性に書く、高さの情報を見せてよい相手（オリジン）の指定である。「*」は全員を意味する。frame-ancestors：Content Security Policyの指示の1つで、そのページを、どのサイトのiframeに入れてよいかを決める。
04 型別 — 自社の埋め込みを、書ける側で3つに分ける
🅰 埋め込みには、3つの型がある
親のCSSと、子のmeta。どちらを自社が書けるかで、次の3つに分けられる。
| 型 | 例 | 親のCSS | 子のmeta | 次にすること |
|---|---|---|---|---|
| A 両側を持つ | 自社の別のページを、iframeで埋め込んでいる | 自社で書ける | 自社で書ける | 自社で試す |
| B 提供元の埋め込み | 地図・予約・フォーム・動画・コメント欄など | 多くの場合、自社で書ける | 提供元だけが書ける | 提供元に問い合わせる |
| C 埋め込まれる側 | 他社のページが、自社のページをiframeで表示している | 相手だけが書ける | 自社で書ける | 許可する相手を決める |
🅱 この記事が測っていないこと
- Edge・Firefox・Safariの実機で、この指定が実際にどう動くか（08章の表は、MDNとChromeStatusの記載を写したものである）
- 地図・予約・フォームなどの提供元が、子のmetaを入れる予定があるか
- この指定を入れたとき、実際のページのCLSがどう変わるか
- 後から外部のスクリプトが作る、iframeの中身の大きさ
注意
提供元の埋め込みの高さを、自社のCSSだけで中身に合わせる方法は、公式の説明には書かれていない。子のページが宣言していなければ、親にframe-sizingを書いても、高さは従来のままと読める（確かめてはいない）。
🅲 確かめる手順
手順1 — 埋め込みの一覧を作る
主要な5ページのソースで「<iframe」を探し、見つかったiframeごとに、srcの先のドメイン・種類（地図・予約・フォームなど）・高さの決め方を、1行ずつ表にする。ここまでは、1ページ5分ほどで終わる。
手順2 — 型A・B・Cに分ける
表の各行に、上の表のA・B・Cを書く。型Cは、アクセスの記録の参照元や、レスポンスヘッダーから、自社のページがどこに埋め込まれうるかを見る。
手順3 — 型Aを1つ、試す
自社が両側を持つ埋め込みがあれば、1つだけ選び、Chrome 154以降のブラウザで、親にframe-sizing、子にmetaを書いて試す。スクロールバーが消えるか、下の内容がずれないかを見る。
実務のヒント
試すときは、元の高さの指定を消さずに残し、@supportsの中でframe-sizingを足す。公式のブログも、この書き方を例にしている。対応していないブラウザでは、従来のままの高さで動く。
手順4 — 型Bの提供元に問い合わせる
提供元ごとに、「埋め込むページに、responsive-embedded-sizingのmetaを入れる予定はあるか」「allow-originsに自社のドメインを指定できるか」の2問を送る。
手順5 — 返事を記録し、3か月後に見直す
返事の日付と内容を表に書く。返事の無い提供元には、「未回答」と書く。仕様はEditor's Draftで、変わりうるので、3か月後に公式の更新日を開き直す。
05 明日、自社で確認するチェックリスト
次の13項目は、1項目あたり5分ほどでできる作業である。項目1〜5が手順1、項目6と7が手順1と2の補足、項目8〜10が手順3、項目11と12が手順4と5、項目13が型Cに対応している。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- 自社の主要な5ページを選び、ページのソースを表示して「<iframe」を検索し、見つかった数をページごとに書く
- 見つかったiframeごとに、srcの先のドメインを書き出し、自社のドメインか外部かに分ける
- 外部のiframeに、種類（地図・予約・フォーム・動画・コメント欄・SNS）を1語で書き添え、1行ずつの表にする
- 表の各行に、高さの決め方を「height属性」「CSS」「JavaScript」「指定なし」のどれかで書く
- 各iframeを、画面幅375px・768px・1280pxの3つで開き、iframeの中に縦のスクロールバーが出るかを、出る・出ないで書く
- iframeを含むページで、開発者ツールのLighthouseを実行し、CLSの数字を記録して、iframeの行の隣に書く
- 自社のスクリプトのソースで「postMessage」「contentWindow」「resize」を検索し、見つかったファイル名を書く
- 自社が親と子の両方を持つiframeの数を数える。0なら、項目11へ進む
- 1以上なら1つだけ選び、親にframe-sizing: content-height;、子のheadにmetaを書き、Chrome 154以降のブラウザでスクロールバーが消えるかを確かめて、結果を書く
- 項目9で試したiframeに、元の高さの指定を残し、@supportsの中でframe-sizingを足した形に書き換えて、古いブラウザでも元の高さで表示されることを確認する
- 外部の提供元ごとに、「子のmetaを入れる予定はあるか」と「allow-originsに自社のドメインを指定できるか」の2問の問い合わせ文を1通ずつ書き、送る
- 提供元の返事の日付と内容を表に書き、返事の無い提供元には「未回答」と書く
- 自社のトップページのレスポンスヘッダーを開発者ツールのNetworkで開き、X-Frame-OptionsとContent-Security-Policyのframe-ancestorsが、設定されているかを書く
06 代替・他の選択肢 — 従来の方法と併用して、使い分ける
iframeの高さの決め方を、4つ並べる
| 方法 | 親の変更 | 子の変更 | 向く場面 | 注意 |
|---|---|---|---|---|
| 高さを固定する | heightを数字で指定する | なし | 中身の高さが変わらないとき | 中身のほうが高いと、iframeの中にスクロールバーが出る |
| postMessageで送る | メッセージを受けて高さを更新するJavaScript | 高さを測って送るJavaScript | 子も自社で、仕組みが既に動いているとき | 公式は、今回の仕組みが置き換える対象と説明している |
| frame-sizing | CSSに1行 | headにmetaを1行 | 親と子の両方を書けるとき | 子のmetaは、読み込み後に足しても効かない。最初の画面に置くとCLSに響きうる |
| 併用する | 元の高さを残し、@supportsの中でframe-sizingを足す | headにmetaを1行 | 新旧のブラウザが混ざるとき | 公式のブログが示している書き方 |
中身が後から変わるときは、requestResize()を使う
公式のブログは、次のように書いている。
"The browser doesn't continuously observe every layout change inside the embedded document."
（訳: ブラウザは、埋め込まれたページの中のレイアウトの変化を、すべて継続して観察するわけではない。）
コメントの追加や、パネルの開閉のように、あとから内容が変わる場合は、子のページがwindow.requestResize()を呼んで、大きさの再計算を頼む。呼ぶのは「レイアウトの前で、変更がすべて終わったあと」がよい、とも書かれている。
allow-originsは、「*」のままにしない選択がある
子のmetaは、allow-origins=*で全員に許可する書き方と、特定のオリジンに限る書き方の両方ができる。公式のブログは、第三者の部品について、こう書いている。
"For third-party widgets, restrict access to the origins that need it."
（訳: 第三者の部品では、必要とするオリジンだけにアクセスを限る。）
自社のページが型Cの立場になる場合は、どの相手に許可するかを、先に決めておく。
当サイトの無料ツールで、確認の入口を作る
手順1と手順3のあと、埋め込みのあるページを複数の画面幅で見比べたいときは、当サイトの無料ツール🔧 WEBページのスクリーンショット、表示デバイスの比較をまとめて撮っちゃおツールが使える。iframeの中のスクロールバーが、どの幅で出るかを見る入口になる。
CLSの数字を、PageSpeed Insightsで見たいときは、🔧 WEBサイトの 最大３ページ Lighthouse監査・チェックツールが手がかりになる（利用には無料の会員登録が必要です）。どちらも、iframeの高さを中身に合わせられるかを判定するツールではない。
07 当サイトで確かめたこと
サイトマップの332ページのソースに、iframeは1件も無かった
2026年10月5日に、当サイトのサイトマップに載っている332ページを、すべて取得した。全ページがステータス200だった。HTMLのコメントの中を除いて、次のタグと語を数えた。
- iframe・embed・objectのタグ：どのページにも0件
- frame-sizingとresponsive-embedded-sizing：ページのソースに0件
- ページに直接書かれたpostMessage・iframeを作る処理：0件
当サイトが配信するスクリプト26本とCSS27本のうち、iframeの語があったのは、スクリプト1本の中の13件だけだった
332ページのソースから、<script src>と<link rel="stylesheet">を（コメントを除いて）集めた。当サイトのドメインのものは、スクリプト26本とCSS27本だった。それぞれを取得して、iframe・contentWindow・contentDocument・ResizeObserver・requestResizeの語と、frame-sizing・responsive-embedded-sizingの語を探した。
- iframeの語：スクリプト26本のうち1本の中に13件、残り25本とCSS27本は0件
- ほかの語（frame-sizingを含む）：スクリプト26本にも、CSS27本にも0件。ただしpostMessageは、ダイアログ用の部品1本の中に4件
iframeの語があった1本は、22ページが読み込む画面部品のライブラリで、語はドラッグ操作の設定名と、すでにあるiframeを探す記述の中にあった。語が在ることと、iframeを作ることは別で、動かして確かめてはいない。
後から外部のスクリプトが画面部品を足す可能性は、確かめていない
外部のスクリプトが、読み込んだあとに画面の部品を作る場合がある。当サイトでは、reCAPTCHAのスクリプトを読むページが21、Googleのログイン用のスクリプトを読むページが22あった。これらが実行後に何を作るかは、ブラウザで開いて確かめていない。この記事で言えるのは、ページのソースにiframeのタグが無いことと、当サイトのスクリプト26本の中のiframeの語の数までである。
当サイトのページが、他のサイトに埋め込まれることは、制限している
トップページと記事のページのレスポンスヘッダーを見ると、他のサイトのiframeに自分のページを表示されることを、制限する設定が入っていた。
08 このテーマの、これまで
仕組みが公開されるまでの、日付つきの記録
| 日付 | 出来事 |
|---|---|
| 2026年9月6日 | CSS Box Sizing Module Level 4（Editor's Draft）の日付。frame-sizingの節を含む |
| 2026年9月16日 | 公式のブログ「Responsive iframes in Chrome 154」が公開された（ページの表示より） |
| 2026年9月22日 | Chrome 154が安定版になった。リリースノートと「New in Chrome 154」が公開された |
| 2026年10月5日 | この記事のために、公式のページと仕様を開き、当サイトの332ページを確かめた |
ほかのブラウザが対応した日付は、この表のどの行にも含まれていない。MDNとChromeStatusに、Chrome以外のブラウザが対応した日付の記載が無かったためである（MDNの互換性データでは、EdgeなどはChromeの値を引き継ぐ形になっている）。
MDNの互換性データでは、Chromeは154。EdgeなどはChromeの値を引き継ぐ形で、Firefoxは未対応、Safariも未対応
2026年10月5日に、MDNの2ページと、互換性データ（browser-compat-data）、ChromeStatusを開いた。MDNのframe-sizingのページには、次の表示がある（最終更新は2026年8月11日と表示されている）。
"This feature is not Baseline because it does not work in some of the most widely-used browsers."
（訳: この機能は、広く使われているブラウザの一部で動かないため、Baselineではない。）
MDNの対応表はJavaScriptで描かれ、取得した本文には出なかった。そこで、表の元のデータを、GitHubから直接取得した。frame-sizingとmetaの2項目があり、どちらも同じ値だった。
| ブラウザ | 原典の記載 | 出典（取得日はすべて2026年10月5日） |
|---|---|---|
| Chrome | version_added: 154。ChromeStatusも154 | MDNの互換性データ、ChromeStatus |
| Edge | 「mirror」と書かれている。MDNの互換性データの説明文書によると、mirrorは、元になるブラウザ（Edgeの場合はChrome）の値を引き継ぐ書き方である。Edgeの具体的な版は、確かめていない。ChromeStatusには、Edgeの項目の記載なし | MDNの互換性データ、ChromeStatus |
| Firefox | version_added: false（対応した版は無い）。ChromeStatusの標準化への立場は「No signal」（訳: 賛否の表明なし） | MDNの互換性データ、ChromeStatus |
| Safari | version_added: false（対応した版は無い）。ChromeStatusの標準化への立場は「No signal」（訳: 賛否の表明なし） | MDNの互換性データ、ChromeStatus |
この表は、MDNとChromeStatusに書かれていることを写したもので、実機で動かして確かめたものではない。Operaなど、ほかのブラウザは入れていない。
記載どおりなら、FirefoxとSafariでは、frame-sizingを書いても高さは変わらない。だから04章のとおり、元の高さの指定を残したまま、@supportsの中でframe-sizingを足す形が、いまのところ使いやすい。
同じChromeの版を扱った、当サイトの記事
Chrome 154では、HTTPのページの扱いも変わった。Chrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）で扱っている。Chrome 153の廃止予定のAPIは、Chrome 153のリリースノートで、広告とクッキーに関わるAPI 5つが「廃止予定」になった ── 自社のタグと埋め込みの提供元に確認する14項目（2026年10月時点）で扱っている。
当サイトの、関連する過去の記事
画面の表示や、測った画面が読者の見ている画面と同じかどうかについては、当サイトのブログでも書いてきた。
- 「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数） — 自動で撮った画面が、読者の見る画面と違った場合の記録。
- 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面が、目当ての画面とは限らなかった記録。
- 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった — 記事に書いた確認項目を、自社のサイトに当てた記録。
- 警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かった — 点検の警告の中身を、種類別に数え直した記録。
- 毎朝の「警告1,415件」を、初めて種類別に数えた ── 96.7%は見なくていいもので、唯一の「本物」は自分で叩くまで分からなかった — 報告された遅さを、自分で叩いて確かめた記録。
現在の貴方のIPアドレス
このサイトで書いている人
