なぜ危ないのか
httpとhttpsが混在するページでは、暗号化されていないhttp通信が「安全な」https接続の中に紛れ込みます。公共Wi-Fiや同一ネットワーク上の攻撃者がARPスプーフィングを使って中間者として割り込むと、http経由で読み込まれているJavaScriptを書き換え、フォームの送信先を変更したりキーロガーを注入したりできます。
ブラウザはMixed Contentを検出するとアドレスバーの鍵マークに警告アイコンを表示します。社外クライアントや取引先がこの警告を見て「このサイトは安全でない」と判断してしまうと、サービスや会社への信頼低下につながります。デザインや機能が完璧でも、セキュリティ警告一つで提案が却下されるケースも実際にあります。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
特にAI生成HTMLでMixed Contentが混入しやすいのは、Googleフォント、外部フォントアイコン（Font Awesome旧バージョン）、jQueryなどのCDN参照、OGP画像タグの4箇所です。これらはAIがサンプルとして学習したコードに古いhttp://のURLが含まれている場合があります。HTMLをテキスト検索して4箇所を重点的に確認してください。
インラインのCSSに`background-image: url('http://...')`が記述されているケースも多いです。特にAIが生成するヒーローセクションやカードコンポーネントのデモ用画像URLがhttpになっている場合があります。VSCodeなら「ファイル内検索（Ctrl+F）」で`url('http`と入力すれば一覧できます。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
http://のリソースを使い続けなければならない事情がある場合（参照先がHTTPS非対応の古いサーバーなど）は、一時的にContent-Security-PolicyのUpgrade-Insecure-Requestsディレクティブを設定します。`Content-Security-Policy: upgrade-insecure-requests`をレスポンスヘッダーに追加すると、ブラウザがhttpリクエストを自動でhttpsに昇格させます。ただしこれはあくまでも応急処置で、参照先がHTTPS対応していない場合はリソースのロードが失敗します。
社外共有用のURLには有効期限と閲覧者制限を設定してください。Mixed Contentの問題を修正した改訂版を再公開する際、旧URLが引き続き有効なままだと受け取った相手が古いバージョンを見続ける可能性があります。バージョン管理と合わせてURLを切り替え、旧URLは期限切れまたは無効化する運用フローを確立してください。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
チームのHTMLテンプレートをGitリポジトリで管理し、テンプレート内の外部リソース参照をすべてhttps://に統一しておきます。AIへの指示でこのテンプレートをベースに使うよう指定すれば、外部リソース起点のMixed Contentを大幅に削減できます。
プロジェクトのリリースチェックリストに「Mixed Contentスキャン実施」の項目を追加します。`npx lighthouse --chrome-flags='--headless' https://example.com --output json | jq '.audits["is-crawlable"]'` のようなLighthouseコマンドで自動検出し、スコアが基準を下回ったらデプロイをブロックするCIルールを設けると効果的です。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
すでに共有してしまったhhttp混在HTMLへのアクセスを即座に遮断できますか？
認証付き共有サービスを使っていればURLを無効化するだけで遮断できます。認証なしで公開していた場合はホスティング先のアクセス制限設定を変更し、修正版を別URLで再共有するのが確実です。
Safariはhttpリソースの扱いがChromeと違いますか？
SafariもMixed Contentをブロックしますが、ブロック対象のリソース種別や警告表示の仕方が微妙に異なります。主要ブラウザで一通り表示確認することを強く推奨します。
メール本文にHTMLを貼り付けて共有する場合もMixed Contentは問題になりますか？
メールクライアントの表示エンジンによります。多くの場合HTTPSの概念が適用されないため警告は出ませんが、画像などが外部参照の場合はトラッキングピクセルとして扱われブロックされることがあります。