外部のフォーム、予約、レビュー、地図を自社サイトに埋め込んだとき、高さの扱いで一度は詰まります。固定値にすると中身が増えたときに内側だけがスクロールし、中身に合わせようとすると、子側で高さを測って postMessage() で親に送り、親が受け取ってリサイズする仕掛けを自作することになります。
Chrome 154に、これをブラウザ側で扱う仕組みが入りました。公式記事は、iframeが埋め込み文書の内在サイズに合わせて自分の寸法を決められるようになったとし、従来の計測して送る手順を置き換えるものだと説明しています。
ただし、これはレイアウトの機能として読むと見落とす点があります。成立させる権限を持っているのは、埋め込む側ではなく埋め込まれた側です。 親のCSSに1行書いて終わる話ではありません。本記事では、その権限の分かれ目と、固定高さと追従のどちらを選ぶかの判断軸を扱います。仕様（W3C/WHATWG）の記述やフラグの具体名は、参照した公式記事には書かれていないため扱いません。
30秒で要点
- 親側は CSS の
frame-sizingで「どの寸法を中身から導出するか」を指定する。公式記事が挙げる値はauto/content-width/content-height/content-inline-size/content-block-size - しかしこれだけでは成立しない。埋め込まれる文書が
<head>にmetaタグを置いてオプトインする必要がある。このmetaタグは読み込み後に動的に追加できない - 自動で追従するわけではない。 ブラウザは埋め込み文書のレイアウト変化をすべて継続監視せず、中身が変わる場合は埋め込み側が
window.requestResize()を呼ぶ - 公式記事は、この仕組みがコンテンツシフトを起こしうること、特にファーストビューのiframeでCore Web Vitalsに悪影響を与えうることを自ら警告している
- 同じ公式記事の中で、表題（Chrome 154）とブラウザ対応表（behind a flag）の記述が食い違っている。 使えるかどうかは手元で確認する前提で読む
親のCSSが決めているのは「どの寸法を中身から導出するか」だけ
公式記事は frame-sizing を、iframeのどの寸法を中身から導出するかを制御するCSSプロパティとして説明しています。挙げられている値は auto、content-width、content-height、content-inline-size、content-block-size です。New in Chrome 154のコード例は、幅を100%にしたまま高さだけを中身から導出する形になっています。
.embed {
width: 100%;
frame-sizing: content-height;
}ここで押さえておきたいのは、この列挙が網羅かどうかは分からないという点です。公式記事の書き方は「サポートされる値には次のものが含まれる」という形で、全部を挙げたとは書いていません。値の一覧を社内資料に転記するなら、「公式記事が挙げている値」と限定して書くほうが安全です。
そして、このプロパティは要求です。要求が通るかどうかは、別の場所で決まります。
成立条件は、埋め込まれた側が置くmetaタグである
公式記事は、埋め込まれる文書の <head> に次のmetaタグを置いてオプトインする必要があると説明しています。
<meta name="responsive-embedded-sizing" content="allow-origins=*">クロスオリジンの場合は、* の代わりに許可する親オリジンを列挙します。複数指定するときは、content値の中を空白で区切ります。
<meta name="responsive-embedded-sizing" content="allow-origins=https://publisher.example">公式記事は、このmetaタグが埋め込み文書の読み込み後に動的に追加できないと明記しています。つまり、JavaScriptで後から足して対応する、という回避ができません。
ここから、立場によって作業がはっきり分かれます。
表が収まらない場合は、横にスクロールできます
| 立場 | できること | できないこと |
|---|---|---|
| 埋め込む側（自社サイトに外部ウィジェットを置く） | 親のCSSに frame-sizing を書く | 配布元の文書にmetaタグを足す。配布元が対応しなければ成立しない |
| 配布する側（自社ウィジェットを顧客サイトへ配る） | metaタグを置き、許可する親オリジンを決める | 顧客側のCSSを書き換える |
この分かれ目を確認せずに「高さが合うようになった」と理解すると、自分では着手できない作業を自分のタスクとして抱えます。 埋め込む側にできるのは、配布元に対応を依頼することまでです。
なお allow-origins を許可制にした理由は、公式記事に書かれていません。記事は、この許可リストが既存のiframeのセキュリティ制御を補完するものだと述べ、CSPの frame-ancestors ディレクティブに1度だけ言及しています。frame-ancestors が「どのサイトが自分を埋め込んでよいか」を制御するのに対し、allow-origins は「どのサイトに自分の寸法を知らせてよいか」を列挙します。向きが違う2つの制御だと整理できますが、なぜ寸法に許可が必要なのかという設計意図は書かれていません。
寸法そのものが中身の状態の手がかりになりうる——たとえばログイン済みかどうかで高さが変わる埋め込みなら、高さを知らせることが状態を知らせることに近づく——というのは本記事の仮説です。公式記事にはこの説明はありません。仮説として扱い、設計意図として社内に説明しないでください。
公式記事の中で、対応状況の記述が食い違っている
この題材で最も注意が必要なのは、機能の内容ではなく、使えるかどうかの記述です。
表が収まらない場合は、横にスクロールできます
| 同じ公式記事の中の記述 | 内容 |
|---|---|
| 表題 | Responsive iframes in Chrome 154（公開 2026年9月16日） |
| ブラウザ対応表 | Chrome: behind a flag / Edge: behind a flag / Firefox: not supported / Safari: not supported |
表題は「Chrome 154で入った」と読めます。対応表は「Chromeではフラグの後ろにある」と書いています。この2つは一致していません。
確かなこと：公式記事がこの2つの記述を同時に載せていること。もう一方の記事（New in Chrome 154、公開 2026年9月22日）は「Chrome 154は現在ロールアウト中」とのみ書き、安定版の具体的なリリース日を示していないこと。
まだ確かではないこと：既定で有効なのか、フラグ越しなのか。フラグの具体名も、参照した2つの記事からは分かりません。本記事では判定しません。
どちらか一方を選んで断定すると、社内で「もう使える」と「まだ使えない」の認識が分かれた状態が固定されます。検証するなら、手元のChromeで実際に動くかを確認してから、確認日と版数を添えて記録してください。なお「New in Chrome」は主要機能の紹介記事で、その版の変更を網羅した一覧ではありません（Chrome 154の回は3つの機能を扱っています）。
「自動で高さが合う」ではなく「呼べば合う」
もう一つ、名前から受ける印象とずれる点があります。この仕組みは、中身の変化を自動で追いかけるものではありません。
公式記事は、ブラウザが埋め込み文書のレイアウト変化をすべて継続的に観測するわけではないと説明し、動的にコンテンツが変わる場合には埋め込み側が window.requestResize() を呼ぶとしています。推奨されている呼び出しのタイミングは、文書への変更をすべて終えたあと、レイアウトの前です。
責任の所在は、ここでも埋め込まれた側にあります。親はいつ中身が変わったかを知らず、子が知らせなければ寸法は古いままです。 フォームのバリデーションメッセージが増えたとき、アコーディオンが開いたとき、画像が遅延読み込みで入ったとき——それぞれで呼ぶ必要があるかどうかは、配布側の実装の問題になります。
呼び出しが過剰になった場合に制限がかかるかどうかは、参照した記事では確認できていません。「毎フレーム呼べばよい」と結論しないでください。
固定高さは「不正確だがずれない」、追従は「正確だがずれうる」
性能の側では、評価が逆転します。
公式記事自身が、このレスポンシブなiframeがコンテンツシフトを起こしうると警告しています。理由は読み込み順です。埋め込み文書は、ホストページより後に読み込まれます。 したがって、ホストページが先に組み上がったあとで埋め込みの寸法が確定し、そこから下のコンテンツが動きます。公式記事は、これがCore Web Vitals（Googleが定義するページ体験の指標群）に悪影響を与えうるとし、ファーストビューのiframeでは特に問題になると述べています。どの指標にどの程度効くかという定量的な記述はありません。
ここから出てくる判断軸は、精度とずれのどちらを受け入れるかです。
表が収まらない場合は、横にスクロールできます
| 選択 | 得られるもの | 代わりに受け入れるもの |
|---|---|---|
| 固定高さ | レイアウトが動かない。読み込み順に依存しない | 中身が増えれば内側がスクロールする。中身が減れば余白が出る |
| 中身への追従 | 内側のスクロールも余白も出ない | 寸法確定までの間、下のコンテンツが動きうる |
どちらが優れているかではなく、どこに置く埋め込みかで決まります。 ファーストビューの埋め込みなら、固定高さの「不正確だがずれない」ほうが合う場面があります。ページ下部の埋め込みで、閲覧者がスクロールして到達する前に寸法が確定するなら、追従の不利は小さくなります。
高さが合っていないことは目に見える不具合で、報告も上がります。読み込み中にコンテンツが動いたことは、報告されないまま指標にだけ出ます。見えやすい問題を直した結果、見えにくい問題を増やす——この形になっていないかを確認してください。
埋め込みを1つ選んで確かめる最小の手順
社内の全部を棚卸しする前に、1つで試すと判断材料が揃います。
- 自社の埋め込みを1つ選び、立場を決める。 自社が埋め込む側なのか、配布する側なのか。埋め込む側なら、metaタグを置けるのは配布元であり、自社の作業は依頼になる
- 配布する側なら、許可するオリジンを限定できるか確認する。
allow-origins=*で済ませるのか、顧客オリジンを列挙するのか。列挙するなら、顧客が増えるたびにmetaタグを更新する運用が成立するかを先に見る - その埋め込みが、ファーストビューに入るかを確認する。 入るなら、追従によるコンテンツシフトの不利を受けやすい位置である
- 固定高さに戻した場合に何が壊れるかを、1行で書き出す。 「中身が増えると内側がスクロールする」まで書ければ、追従が必要な理由が言語化できている。書けないなら、固定高さで足りている可能性がある
- 手元のChromeで実際に動くかを確認し、確認日と版数を記録する。 公式記事の記述が食い違っている以上、動作確認の記録が唯一の根拠になる
手順1と4だけで、この機能を追うべきかどうかの判断はつきます。自社が配布側でなく、かつ固定高さで壊れるものを1行で書けないなら、いま動く理由はありません。
判断の土台として押さえておくこと
- 親のCSSの
frame-sizingは要求であり、成立条件は埋め込まれた側のmetaタグである。metaタグは後から動的に追加できない - したがって、埋め込む側にできるのは配布元への依頼までである。立場を先に決めないと、着手できない作業を抱える
- 自動追従ではない。中身が変わる場合は埋め込み側が
window.requestResize()を呼ぶ - 公式記事の中で、表題（Chrome 154）と対応表（behind a flag）の記述が食い違っている。使えるかは手元で確認し、確認日と版数を記録する
- 固定高さは「不正確だがずれない」、追従は「正確だがずれうる」。ファーストビューに入るかで選び分ける
allow-originsが何を守る設計なのかは公式記事に書かれていない。推測で社内に説明しない
埋め込みの寸法に限らず、「自社で決められること」と「相手の許可が必要なこと」が混ざった状態は、作業の見積もりを狂わせます。どこまでが自社の判断範囲かを言語化するところから始めることができます。
状況を整理する（15分）より深く学ぶ
- 外部スクリプトの棚卸しは、依存関係スキャンでは終わらない：埋め込みを含む外部コードを、出荷物とは別の一覧で扱う
- Chromeが2週間ごとに更新される時代｜「速くなった」ではなく前提が変わった：版数と確認日を記録する習慣の作り方
参考資料・引用元
- Chrome for Developers, Responsive iframes in Chrome 154（2026年9月16日公開）. https://developer.chrome.com/blog/responsive-iframes （2026年10月13日確認）
- Chrome for Developers, New in Chrome 154（2026年9月22日公開）. https://developer.chrome.com/blog/new-in-chrome-154 （2026年10月13日確認）