ひとことで言うと
Secure属性はCookieを設定する際のオプションで、Set-Cookieヘッダーに`Secure;`と追記するだけで有効になります。このフラグが付いたCookieはHTTPS（暗号化通信）でのリクエスト時にのみサーバーへ送られ、HTTPのリクエストでは送信されません。万が一通信を傍受されてもCookieの値が漏れないようにするためのネットワーク層の保護です。
ローカル開発環境（localhost）はHTTPSでなくてもSecure Cookieが機能するブラウザが多いですが、本番や共有URL環境ではHTTPSが必須です。AI生成HTMLをHTTPのURLで共有するとSecure Cookieが送信されず、ログイン状態が維持されないなどの問題が発生します。プレビューURLが`https://`から始まるかどうかを最初に確認しましょう。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
HTML共有で関係する場面
ギガサイト便はCloudflareを通じてHTTPS配信を自動で行うため、Secure属性付きのCookieを扱うHTMLでも正常に機能します。一方、会社内のHTTPサーバーや簡易的なローカルサーバーでHTMLを共有している場合、Secure Cookieが送信されずに認証フローが壊れることがあります。共有前にURLプロトコルを必ず確認してください。
AIで生成したHTMLがフォーム送信後にCookieをセットし、次のページで認証状態を確認する設計になっている場合、共有URLがHTTPだと動作しません。この場合は動作確認用に認証をスキップするモードを作るか、HTTPSで配信できるサービス（ギガサイト便・Netlify・Vercelなど）を利用してから共有するとスムーズです。
よくある誤解
「Secure属性があればCookieは安全」と思われがちですが、Secure属性が保護するのはネットワーク伝送中のみです。Cookieの値が推測されやすい・セッション固定攻撃に脆弱などの問題はSecure属性では防げません。HttpOnly属性との併用でJavaScriptからの盗難も防ぎ、SameSite属性でCSRFも防ぐ、という三層構造で考えることが重要です。
「localhostはHTTPでもSecure Cookieが動くから本番も大丈夫」という発想は危険です。ブラウザはlocalhostを例外扱いしているだけで、本番環境のHTTP URLではSecure Cookieは送信されません。開発中にlocalhost動作を確認したからといって、HTTP URLの本番共有でも同様に動くとは限りません。
安全に使うための注意点
共有用のプレビューURLが必ずHTTPSになっているか確認することが第一歩です。ギガサイト便のような専用サービスはHTTPS必須のため安心ですが、自前でNginxやApacheを立ててHTTP共有している場合はSSL証明書の設定が必要です。Let's Encryptを使えば無料でHTTPS化できます。
AI生成HTMLのコードレビュー時に、CookieのSet-Cookie記述にSecure属性が付いているかをチェックします。特にセッションIDや認証トークンを格納するCookieには必須です。AIは属性を省略して生成することが多いため、生成後に正規表現`Set-Cookie[^;]*(?!;\s*Secure)`などで属性漏れを検出するスクリプトを用意しておくと見落としを防げます。
よくある質問
Secure属性なしのCookieはHTTPSでも送信されますか？
はい、送信されます。Secure属性はHTTPSのみへの送信を強制するものですが、付いていない場合はHTTPでもHTTPSでも送られます。セキュリティのためにはHTTPSでも明示的にSecure属性を付けることを推奨します。
ギガサイト便でHTMLを共有した場合、Secure Cookieは問題なく動作しますか？
はい、ギガサイト便はHTTPS配信を行うため、Secure属性付きのCookieも正常にブラウザへ送信されます。ただし静的HTMLからはサーバーヘッダーを操作できないため、Set-CookieヘッダーをJavaScript以外で設定することはできません。
開発環境ではSecure CookieをHTTPで動かす方法はありますか？
localhostはブラウザが例外扱いするためHTTPでもSecure Cookieが動作します。localhostでない場合はmkcertで自己署名証明書を作成し、ローカルHTTPS環境を構築するのが標準的な方法です。