Webサイトを作ったりネットショップを運営したりしていると、「外部のカード決済画面から戻ってきたらログインが切れてしまった」「別サイトに埋め込んだパーツがうまく動かない」といったトラブルに遭遇することがあります。その原因としてよく登場するのが、ブラウザのセキュリティ機能である「SameSite（セイムサイト）制限」です。
本記事では、専門用語をできるだけかみ砕きながら、「そもそもSameSite制限とは何なのか」「なぜブラウザが制限をかけているのか」、そして「Strict・Lax・Noneという3つの設定値の違いと対策方法」まで図解とともに分かりやすく解説します。
まずは結論！SameSite制限を一言でいうと？
SameSite制限とは、一言でいうと「あるWebサイトで発行された『ログイン会員証（Cookie）』を、別の無関係なサイトからの通信時に勝手に持ち出させないようにする、ブラウザの防犯ルール」です。
「お店の会員証（Cookie）」でたとえると分かりやすい！
Webサイトにログインしたとき、ブラウザは「〇〇さんがログイン中です」という通行証である「Cookie（クッキー）」を預かります。
同じサイトの中でお買い物カゴを見たりマイページへ移動したりするときに、この会員証を見せるのは自然なことです。しかし、「たまたま開いた別の怪しいサイト」から裏側で勝手に通信が飛ばされたときまで、ブラウザが自動的に会員証を見せてしまったら大変危険ですよね。
そこで、「同じサイト（SameSite）の通信ですか？それとも別サイトからの通信ですか？」をブラウザが関所のようにチェックして制限する仕組みが「SameSite制限」です。
なぜブラウザにSameSite制限が必要なの？
昔のブラウザにはこの制限がなかったため、「あるサイトにログインしたまま、悪意のある罠サイトを開くだけ」で被害に遭う危険がありました。SameSite制限が守ってくれている代表的なリスクを見てみましょう。
成りすまし操作（CSRF攻撃）を水際で防ぐため
たとえば、あなたが「A銀行」や「B通販サイト」にログインしたまま、別のタブで「悪意のある罠サイト」を開いたとします。
もし罠サイトの裏側に「B通販サイトへ『高級品を購入する』という命令をこっそり送るプログラム」が仕込まれていた場合、昔のブラウザは「B通販サイト宛ての通信だから、預かっていたB通販サイトの会員証（Cookie）も一緒に送っておこう」と気を利かせて添付してしまっていました。
その結果、B通販サイトのサーバーは「本人が注文ボタンを押した」と勘違いして処理を実行してしまいます。このような攻撃を専門用語で「CSRF（クロスサイト・リクエスト・フォージェリ＝サイト間リクエスト偽造）」と呼びます。
SameSite制限があれば、ブラウザが「いま開いているのは罠サイトであって、B通販サイトではないから会員証（Cookie）は渡さないぞ！」と入り口で止めてくれるため、不正な操作を水際で防ぐことができます。
別サイトをまたいだ勝手な追跡（トラッキング）を抑えるため
もうひとつの理由はプライバシー保護です。いろいろなWebサイトに貼られている広告バナーや解析パーツが、サイトをまたいでCookieをやり取りし、「どのサイトからどのサイトへ移動したか」を追跡する仕組み（サードパーティCookie）に対して、近年はChrome・Safari・Edge・Firefoxすべての主要ブラウザで制限が強化されています。
SameSite属性の「3つの設定値（Strict・Lax・None）」の違い
Webサイトの開発者は、Cookieを発行するときに「どの範囲までならCookieを送ってよいか」を3段階のルール（属性値）から指定できます。それが「Strict」「Lax」「None」の3つです。
SameSite=Strict（もっとも厳しい設定）
「Strict（ストリクト＝厳格）」は、文字通り「同じサイト内の移動でしか絶対にCookieを送らない」という一番厳しい設定です。
- メリット：外部サイトからの通信には一切Cookieが送られないため、防犯性が非常に高くなります。
- デメリット（注意点）：Google検索の結果や、SNS・メールに貼られたリンクをクリックしてそのサイトへ移動した瞬間も「別サイトからの移動」と判定されるため、最初の1ページ目ではCookieが送られず、「ログインしているはずなのに、リンクから飛ぶと毎回ログアウト状態に見える」という不便さが生じます。
SameSite=Lax（現在のブラウザの標準・バランス型）
「Lax（ラックス＝緩やか・適度）」は、「防犯性を保ちつつ、普段のリンク移動で不便が出ないようにしたバランス型」の設定です。現在の主要ブラウザでは、開発者がSameSiteの指定を省略した場合、自動的にこの「Lax」が適用されます。
- Cookieが送られるケース：検索エンジンや別サイトのリンクを普通にクリックしてページ全体が移動するとき（通常のGETリクエスト）は、ログイン状態が維持されます。
- Cookieがブロックされるケース：別サイトから裏側でデータを送りつける通信（フォームのPOST送信）や、別サイトの中に
iframe（インラインフレーム）で埋め込まれた画面、別サイトからの画像・通信呼び出しではCookieがブロックされます。
SameSite=None（別サイトとの連携を許可する設定）
「None（ナン＝制限なし）」は、「別のサイトをまたいだ通信や、iframe埋め込みの中でもCookieを送ってよい」と明示的に許可する設定です。
- 使う場面：外部のクレジットカード決済会社（3Dセキュア画面など）から自サイトへ戻ってくるときや、外部サイトの画面内にログイン機能付きのウィジェット（
iframe）を埋め込むときなどに使われます。 - 必須条件（Secure属性）：
SameSite=Noneを使う場合は、必ず暗号化通信（HTTPS）でのみ送信する「Secure属性」をセットで指定するルールになっています（SameSite=None; Secureと書かないとブラウザに拒否されます）。
| 通信のパターン | Strict（厳格） | Lax（ブラウザ標準） | None; Secure |
|---|---|---|---|
| 同じサイト内のページ移動 | 送信される（○） | 送信される（○） | 送信される（○） |
| 別サイトのリンクをクリックして移動（GET） | 送られない（×） | 送信される（○） | 送信される（○） |
| 別サイトからのフォーム送信（POST） | 送られない（×） | 送られない（×） | 送信される（○） |
| 別サイト内のiframe（埋め込み画面） | 送られない（×） | 送られない（×） | 送信される（○） |
SameSite制限でよくある2つのトラブルと解決策
Webサイト制作やシステム運用において、「SameSite制限」が原因で実際に起きやすいトラブルと、その直し方を整理しておきましょう。
外部の決済画面（3Dセキュア等）から戻るとログアウトしてしまう
ネットショップ（ECサイト）でクレジットカード決済を行う際、一度カード会社の本人認証画面（別サイト）へ移動し、認証が終わったあとに元のショップへ自動転送（POST送信でリダイレクト）されて戻ってくる仕組みがよく使われます。
このとき、ショップ側のログイン用Cookieが標準の「SameSite=Lax」になっていると、「別サイトからのPOST送信だからCookieを送らない」とブラウザに遮断され、ショップに戻った瞬間にログインが切れてエラーになるという現象が起きます。
解決策のポイント
- 決済完了後の戻り先ページ（コールバック受付用URL）では、セッションCookieに依存せずトークン等で本人確認を行い、そこから通常のGETリダイレクトで完了画面へ移動させる設計にする。
- または、外部決済との往復に必要な一時Cookieに対して
SameSite=None; Secureを設定する。
別サイトにiframeで埋め込んだ予約フォームや管理画面が動かない
「A社のホームページの中に、B社の予約システムを iframe タグで埋め込む」といった構成の場合、ブラウザから見るとB社の予約システムは「別サイト（サードパーティ）」の扱いになります。
そのため、標準の「Lax」のままではCookieが一切保存・送信されず、「予約画面のステップが進めない」「ログインボタンを押してもすぐ弾かれる」といった不具合が発生します。
解決策のポイント
iframe内で動かすシステムでは、SameSite=None; Secure（さらに近年のブラウザ向けにPartitioned属性の併用）を設定します。- ただし、Safari（ITP機能）やシークレットモードなどでは、
SameSite=Noneであっても別ドメインのiframe内Cookie自体がブロックされることがあるため、「サブドメイン（例：reserve.example.com）を割り当てて同一サイト扱いにする」か、「iframe埋め込みではなく別ウィンドウ・画面遷移方式にする」のがもっとも確実な対策です。
【参考】プログラムでのSameSite設定の書き方例
WebサーバーやPHPなどのプログラムでCookieを発行する際に、SameSite属性を指定する基本的な記述例です。
【HTTPレスポンスヘッダーでの指定例】
# 一般的なサイト（標準のバランス型）
Set-Cookie: session_id=xyz123; Path=/; Secure; HttpOnly; SameSite=Lax
# 外部サイト連携・決済リダイレクト等で必要な場合（Secureが必須）
Set-Cookie: cross_token=abc987; Path=/; Secure; HttpOnly; SameSite=None
【PHP（setcookie関数）での指定例】
setcookie('session_id', $value, [
'expires' => time() + 3600,
'path' => '/',
'secure' => true, // HTTPS通信のみに限定
'httponly' => true, // JavaScriptからの読み取りを禁止
'samesite' => 'Lax', // 'Strict', 'Lax', 'None' のいずれかを指定
]);知っておきたい豆知識：「同じサイト（SameSite）」の判定基準
最後に、開発者やサイト運営者がよく迷う「どこまでが同じサイト（SameSite）と判定されるのか？」というルールを整理しておきます。
- サブドメイン違いは「同じサイト（SameSite）」扱い：たとえば「
www.example.co.jp」と「shop.example.co.jp」は、大元のドメイン（example.co.jp）が共通しているため、同じサイト（SameSite）として扱われ、Cookieのやり取りが制限されません。 - 共有ドメインサービスは「別サイト」扱い：「
〇〇.github.io」や「〇〇.herokuapp.com」のように、複数の利用者がサブドメインを分け合って使うサービス（Public Suffix List登録ドメイン）では、隣り合うサブドメイン同士は「別々のサイト」として厳密に区別されます。
まとめ
ブラウザのセキュリティ制限である「SameSite制限」のポイントをまとめます。
- SameSite制限の役割：他サイトから裏側で勝手にCookie（ログイン会員証）が送られるのを止め、成りすまし操作（CSRF攻撃）や不要な追跡から利用者を守るブラウザの防犯機能です。
- 普段は「Lax」が標準：現在のブラウザは、特別な指定がなくても「通常のリンク移動はOK・裏側の不正なPOST通信やiframe埋め込みはブロック」というバランス型の
SameSite=Laxで動いています。 - 外部決済や埋め込みで困ったら：外部サイトからのPOSTリダイレクトや
iframe連携が必要な箇所ではSameSite=None; Secureの設定や、サブドメイン運用・リダイレクト設計の見直しで解決できます。
ブラウザのセキュリティ制限は一見すると「急にログインが切れる厄介な仕組み」に思えることもありますが、その裏側では私たちのアカウントや決済情報を守る大切な関所として働いています。ぜひ「Strict・Lax・None」の3つの役割を押さえて、安全で使いやすいWebサイト運営に役立ててください。
