ホーム自己紹介ブログ
NO.262
DATE2026. 02. 18

iframeの難しさ

最近、iframe を使っています。
クライアントサイドで埋め込む想定で、iframe を使おうとしています。
色々と苦労したことがあったので、書いて残しておこうと思います。

レスポンスヘッダー

前提として、ウェブアプリケーションをプロダクションとして提供済みとします。
そのため、iframe だと ウェブサイトのURLを指定するだけで使えるので、比較的楽にできると見込んでいました。
提供するURLのレスポンスヘッダーに、X-Frame-Options や Content-Security-Policy などの調整が必要です。

  • X-Frame-Options ヘッダー - HTTP | MDN - developer.mozilla.org
  • Content-Security-Policy (CSP) ヘッダー - HTTP | MDN - developer.mozilla.org

埋め込み先対象が複数存在する場合は、CSPで許可するオリジンを追加します。
埋め込み先対象が運用として増えていく場合は、この手間は面倒になるかもしれません 。

iframeの高さ

例えば、ノーコードツールなどでWeb制作したLPサイトに iframe を埋め込むとします。
この際、多くの場合 iframe に対してスタイルを適用します。

.iframe {
  width: 100%;
  height: 600px;
}

iframe の高さは、要素のサイズは読み込まないと不明なため px や vh などの単位で書くことが多いです。
この height を超える場合は、iframe の枠から見切れる状態になります。

Speaker Deck のような埋め込むコンテンツが スライドのみのようなサイズが固定の場合は問題なさそうです。
しかし、埋め込むコンテンツが「本文の長さ」や「コメント数」のように、
閲覧時点のデータによって高さが変わる場合は話が変わります。
この場合、 見切れてしまうと埋め込んでいる感が浮き彫りになってしまいます。

システム設計や運用としてコンテンツの最大値を設けれる場合は、
iframe の height の値をその最大値より大きめにすることで、見切れることを阻止できます。

メディアクエリ

ある一定の横幅になれば、表示するコンテンツの構造を変えるレスポンシブな振る舞いを実現したい時があります。
それの代表的な手段の一つに、メディアクエリがあります。

  • メディアクエリーの基本 - ウェブ開発の学習 | MDN - developer.mozilla.org

iframe の中でメディアクエリを使用すると、
メディアクエリのビューポートは埋め込み先のビューポートではなく iframe 自身になります。
そのため埋め込み先側がラップトップ並のビューポートを確保していても、
iframe の中がモバイル並の横幅だった場合、埋め込みコンテンツはモバイルの表示デザインとなります。
これが良くないというわけではなく、そういう振る舞いを理解して UI のレスポンシブ対応をする必要があります。

メディアクエリのように画面全体の中の1つとして捉える方法よりも、
1つのウィジェットとしてコンテナクエリを使用する方法も悪くないかもしれません。
埋め込みコンテンツの親要素をコンテナと指定し、そのコンテナのサイズに基づいて子要素たちのサイズなどを調整するのです。

  • CSS コンテナークエリー - CSS | MDN - developer.mozilla.org

ダイアログ

ボタンクリックしたら前面にダイアログを表示する。
そんな機能を埋め込みコンテンツに含める場合は、どうでしょうか。

ダイアログを表示している最中は、背面は灰色などで隠しつつスクロール移動させたくありません。
iframe の中の場合、背面を制御できるのは iframe の中だけです。
iframe から埋め込み先に対して何もできません。(イベント送信してホスト側に対応するなどなら別ですが)

また、ダイアログというのはできれば画面中央に表示されてほしいものです。
しかし、iframe の高さのところで述べたような height の大きさを大きめ(1000pxなど)の取る方針にすると、
ダイアログの表示位置を埋め込み先画面上の中央に表示するのが難しいのです。

代案としてはクリックイベントからx,y座標を取得できるため、
それらの情報からクリックした近くにダイアログを出すという方法は実現できそうです。
埋め込み先の情報を iframe 側から知る術 がないため、それを使った設計(例えばスクロール量)も厳しそうです。

Web Component

iframe のような埋め込み先のドキュメントと独立させた要素は、これまで書いた通りWebデザインの観点で都合が悪い時があります。
そこで、埋め込み先のドキュメントに自然に溶け込めるための方法として、 Web Component が使えるかもしれません。

  • ウェブコンポーネント - Web API | MDN - developer.mozilla.org

Web Component の場合、独自のカスタム要素を定義した (例: <my-super-page />) JavaScript ファイルを用意します。
そのファイルを script タグで読み込んだ後に <my-super-page /> 要素を書くだけで使えます。
要素に属性を渡せることが可能なので、<my-super-page page="2" /> のように文字列をカスタム要素に渡せます。

Web Component を使用する箇所は、JavaScript を有効化する必要があるため注意が必要です。
また、根拠は不明ですが SEO 観点でよろしくない というのは聞いたことがあります。

もし、 Web Component が使えるなら先のWebデザインの都合が悪いポイントはなんとかなるかもしれません。
さらに、 Web Component には Shadow DOM という文書から対象DOMをカプセル化する方法があります。
カプセル化による恩恵としては、スタイルを埋め込み先へ漏洩しないところや Web Component 内部を壊すこともできなくなります。
埋め込みとしては、良い恩恵かと思います。

終わりに

iframe って手軽に使えて便利なんですよね。
今回の学びを、後世に活かしたいかと思います...!

フロントエンド
ブラウザ

-

シェアする

フォローする

次のページ

UR団地は1つの町

前のページ

SVGを書くと数学の知識が必要だった

関連する記事

タグ「フロントエンド」の記事

SVGを書くと数学の知識が必要だった

紙を積んだイラストをSVGで書こうとしていました。 (当たり前ですが)図形を表現するためには数学の知識が必要で、学生の頃の記憶を思い出したので疲れました。 所感について、諸々書こうと思います。 成果物 実際に完成したのは、以下の画像ができま

2026年02月17日

フロントエンド
CSSを、Vitestでテストしてみる

以下の記事で書いた CSSをテストする方法について、試してみました。 https://zenn.dev/silverbirder/articles/df6752b230f04c ソースコードは、以下に置いています。 https://gith

2026年02月10日

フロントエンド
テスト
ヒューマンインターフェース ガイドライン という言葉を知りました。

最近、ヒューマンインターフェース ガイドライン(HIG)という言葉を知りました。 「ヒューマンインターフェイスガイドライン」には、どのAppleプラットフォームでも優れた体験を設計できるようにするためのガイドとベストプラクティスが含まれてい

2026年01月24日

フロントエンド

タグ「ブラウザ」の記事

DuckDB WASMとOPFSでGoogleマイアクティビティをブラウザ完結で可視化してみた

DuckDB WASMとOrigin Private File System (OPFS) を組み合わせ、Google マイアクティビティの履歴をブラウザ内に閉じたまま扱えるようにしたときの設計と学びを整理しました。

2025年09月17日

開発ツール
ブラウザ
マイクロコピー、マイクロインタラクション、そしてリンク

こんにちは、@silverbirderです。最近、湖県に移住してWebフロントエンドのお仕事をしています。お仕事をしていると、ユーザー体験を良くするためには、大きな改善をせずとも小さな改善だけでも十分な効果があると思い始めました。本記事では、その小さな改善となる、3つのことについて書きたいと思います。

2025年08月27日

フロントエンド
ブラウザ
OGPのテキストを任意の行で省略する、lineClampとbudoux

ブログ記事のOGP画像に、ブログタイトルを入れたい場面があります。その際、タイトルが長い場合は複数行に分けたり、省略したりする必要があります。今回は、試してみてよさそうだった2つの方法を紹介します。

2025年02月06日

ブラウザ
← ブログ一覧へ