ひとことで言うと
sandbox 付き iframe とは、HTMLページの中に別のHTMLを「隔離した窓」として埋め込む仕組みです。sandbox 属性を付けると、その窓の中のコードはフォーム送信・スクリプト実行・同一オリジンアクセスなどが既定で禁止され、許可したい動作だけを `allow-scripts` や `allow-forms` で個別に解除できます。
比喩で言うと「ガラス張りの展示ケース」に近く、外から見えるが中のものが外に触れられない状態です。AI生成のHTMLを信頼できない第三者に見せる場合、この隔離があることでホストページのクッキーや認証情報が漏れるリスクを大幅に下げられます。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
HTML共有で関係する場面
ギガサイト便のようなプレビュー共有サービスでは、アップロードされたHTMLをサービス側のドメインの iframe 内で表示することがあります。この場合、sandbox により埋め込まれたコードがサービス側のセッションクッキーを読み取ったり、別ウィンドウを強制的に開いたりする行為を防げます。
社内レビュー用にAI生成ページをURLで回覧するケースでも同様です。受け取った担当者が「表示はできるが外部へのデータ送信は起きない」と確認できれば、情報管理の観点から安心して閲覧依頼を出せます。共有前にブラウザの開発者ツールでネットワークタブを開き、外部リクエストが飛んでいないかチェックする手順と組み合わせると効果的です。
よくある誤解
「sandbox を付ければ完全に安全」という誤解が多いですが、`allow-same-origin` と `allow-scripts` を同時に付与すると sandbox の保護がほぼ無効化されます。この2つを組み合わせると、スクリプトがフレームの sandbox 属性自体を書き換えて制限を解除できてしまうためです。設定するときは必要な権限だけを最小限に付与するのが原則です。
また「iframe の中だから親ページへの影響はゼロ」と思い込むケースもあります。実際には `allow-top-navigation` を付けると子フレームから親ページをリダイレクトできるため、フィッシング的な誘導が可能になります。AI生成コードをそのまま埋め込む際は、どの allow-* トークンが付いているかを必ず確認してください。
安全に使うための注意点
共有URLを発行する前に、iframe を使ってコンテンツを表示しているサービスであれば「どの sandbox トークンが付与されているか」を運営のドキュメントで確認しましょう。特に `allow-scripts` が付いている場合、埋め込んだAI生成コードの JavaScript が実行される点を念頭に置き、コードレビューを省略しないことが重要です。
外部フォントや外部APIを呼び出すAI生成ページを sandbox iframe で表示すると、`allow-same-origin` なしの環境では外部リクエストがブロックされてレイアウトが崩れることがあります。共有相手に「表示が崩れた」と報告されたら、まず sandbox の制限が原因である可能性を疑い、表示確認はモバイルとデスクトップの両環境で行うよう案内してください。
よくある質問
sandbox 属性のない iframe に比べて、付きの iframe はどれほど安全性が違いますか？
sandbox なしは通常のページと同じ権限でスクリプトが動きますが、sandbox ありで allow-* を何も付けない場合はスクリプト・フォーム・ポップアップなどがすべて禁止され、攻撃面を大幅に削減できます。
AI生成のHTMLをそのまま iframe に貼ったら動かなくなりました。どう対処すればいいですか？
sandbox の制限でスクリプトや外部フォント読み込みがブロックされている可能性があります。開発者ツールのコンソールにエラーが出ていれば、必要な allow-* トークンを追加するか、コードを修正して外部依存を減らしてください。
プレビュー共有サービスを使う場合、sandbox の設定は自分でコントロールできますか？
多くのサービスではサービス側が sandbox を設定するため、ユーザーが直接変更できません。事前にサービスのヘルプページで適用されるポリシーを確認し、許可されていない機能を使うコードは修正してからアップロードする流れが基本です。