iframeの埋め込みが表示されないとき｜URL・公開範囲・CSPを切り分ける

動画、予約、地図などをiframeで載せたのに、空白になる、接続を拒否される、操作できない。そんなときは、外部側の公開条件と、自社ページ側の実装・表示条件を分けて調べます。iframeの高さを変えるだけでは解決しない問題もあります。

最初に公式の埋め込み方法とURLを確かめ、次にどの要求が拒否されているかを制作担当が確認します。外部サービスの防御を回避したり、自社のCSPをすべて無効にしたりする方法は採用しません。この記事では、利用者への代替案内も含めて、修正と検収の進め方を説明します。

1. ページが開かないのか、外部の枠だけ使えないのか

自社ページの本文は表示されるか、埋め込み枠は見えるか、枠内にエラーが出るか、操作した後に止まるかを記録します。外部側の通常ページが直接開けるかも比較しますが、直接開けることとiframeへ載せられることは別です。

一人のログイン済み端末で動いても、利用者の環境では違う可能性があります。端末、ブラウザー、ログインの有無、同意の状態をそろえて比較してください。録画や画像を担当へ渡す場合は、個人情報と予約内容を隠します。

2. 公式の埋め込みコードと公開範囲を確認する

外部サービスが案内する埋め込みコードを使っているかを確認します。通常の閲覧URL、共有URL、埋め込み専用URLは同じとは限りません。コピーした後にURLを手作業で変えた場合は、変更前の資料と照合します。

外部側で決めること

コンテンツの公開範囲、埋め込み可否、利用プランや許可する掲載先、アカウントの管理者を確認します。条件はサービスごとに異なります。リンクを知っている人が見られる設定でも、外部埋め込みや予約の実操作まで認めるとは限りません。

自社側で確認すること

コードを入力した場所、公開ページに残ったiframeとURL、独自の変換や追加機能、表示用のCSSを確認します。編集権限や保存時の処理でコードが残らない場合は、管理者へ相談します。全員に強い権限を与える代わりに、誰が埋め込みを管理するかを決めてください。

外部側の担当者に確認しても利用条件が不明な場合は、未確認として残します。通常ページを勝手にiframeへ載せて、表示されない原因を自社の設定だけで解決しようとしません。

3. X-Frame-OptionsとCSPは、どちらの条件かを分ける

ブラウザーが外部ページの表示を拒否している場合は、制作担当が対象応答とエラーを確認します。掲載側と外部側のどちらで止めているかを分ければ、変更できる担当も分かります。

MDNのX-Frame-Options説明では、外部の枠へページを表示してよいかをHTTP応答ヘッダーで制御します。DENYやSAMEORIGINにより載せられない場合があります。自社のHTMLへmetaを足して外部側の拒否を解除する方法ではありません。

CSPのframe-ancestorsは、そのページをどの親ページが埋め込めるかを決めます。一方、掲載側のframe-srcは、枠へどこから読み込めるかを制限します。同じCSPでも見る方向が違います。

CORSの設定を変えれば、すべてのiframe拒否を解消できるわけではありません。自社では変更できない条件なら、公式の埋め込み経路や通常リンクへの切り替えを相談します。拒否を回避して外部ページを転載する対応は行いません。

4. HTTPS、同意、ログイン、枠の操作を確かめる

要求が拒否されていない場合も、通信先やブラウザー条件、枠内の実際の操作を確認します。自社がHTTPSでも、埋め込み先やその内部で使う通信が混在している場合は、MDNの混在コンテンツの説明とブラウザーの記録を担当が照合します。

URLがHTTPSか、公式コードが現在の仕様か、別の接続先へ移動していないかを確認します。警告を消すためにブラウザーの保護機能を無効にするのではなく、外部サービスの対応する経路を選びます。

同意前後、ログイン有無、Cookieの扱いで挙動が違う場合は、その条件を記録します。すべての訪問者へ同意を強制したり、プライバシーの設定を説明なく変えたりしません。iframeのsandboxや許可属性を使用している場合も、必要な操作と外部の公式仕様を照合して担当が判断します。

幅と高さ、スクロール、スマホでのタップ、キーボード操作も確かめてください。枠の下に予約の確定ボタンが隠れているなら、表示成功とは言えません。検証で予約や送信を行う際は、許可された検証先とテスト内容を用意します。

5. 表示できない利用者に、次の行き先を用意する

外部サービスの障害や利用者の環境で、埋め込みが使えない場面は残り得ます。ページの意味が空白の枠だけにならないよう、何をできる枠かと、使えない場合の行き先を本文でも説明します。

予約なら公式の予約ページ、動画なら公開先、地図なら住所とアクセス説明など、目的に合う案内を用意します。単に「エラーです」で終わらず、利用者が自分で次へ進める文言にしてください。リンク先の公開条件と、外部へ移動することも分かるようにします。

別の窓口を案内する場合は、実際に受け付けられる範囲と担当へ一致させます。運用していない電話受付や返信時間を新たに約束しません。閲覧ページと予約の成立、動画再生と相談の成立は、それぞれ別の結果として確かめます。

6. 必要箇所だけ修正し、利用者の操作で検収する

原因が分かったら、URL差し替え、表示枠の調整、自社側の限定的な許可、外部側への確認など、対象と戻し方が分かる修正を選びます。使っていないサービスまで一括で許可する変更は避けます。

変更前にそろえる条件

変更するコードや設定、実行する担当、影響するページ、検証先、戻す原本を残します。CSP等が共有設定なら、この記事の枠以外への影響も確認してください。外部側の条件を変える場合は、権限を持つ担当が内容を承認します。

公開後に確かめること

PC、スマホ、レイアウトが切り替わる幅で、本文、枠、代替リンク、必要な操作を確認します。設定値を保存したことと、実際の公開ページへ反映されたことを分けます。外部サービスに記録される予約や送信の確認は、合意したテスト手順で行い、利用者の実取引と混ぜません。

成功時と使えない場合の案内を両方確かめます。解析のクリックだけでは、外部側で予約や相談が成立した件数は分かりません。

7. Acquaと外部サービスの担当を分ける

企業は、ページで利用者に何をしてほしいか、外部サービスを誰が管理するか、代替受付をどう扱うかを決めます。Acquaへは、Web運用支援として、埋め込み箇所、公開条件の整理、表示調整と検収を相談できます。

制作会社は、WordPress等の実装支援として、コード、制約のある環境、再現条件、外部担当への質問、納品時の確認項目を共有できます。外部サービス側でしか変えられない条件は、その担当へ分けて渡します。

相談窓口には、掲載URL、外部サービス名、止まる操作、時刻、公式の案内の所在をまとめてください。調査と修正、外部側の確認、費用と権限は個別に整理します。接続保証や外部規約の判断を、実装作業だけで約束しません。

8. 枠の表示と、利用者の目的を別々に確認する

完了状態は、利用者が本文から目的を理解し、外部枠で必要な操作ができ、使えない場合も次の行き先が分かることです。担当者はURLと公開条件、変更記録、次の管理先を引き継ぎます。

表示や操作の不具合が減ったか、問い合わせに必要な案内が届いたかは実測します。枠を追加した件数やクリック数を、予約、受注、利益へ置き換えないでください。外部サービスの仕様変更もあるため、定期確認は意味のある操作と現在の案内へ絞ります。

参考にした一次資料：

• MDN：X-Frame-Options
• MDN：frame-ancestors