--- title: "ファーストパーティークッキー（1st Party Cookie）とは？違いと有効期限の上限" url: "https://www.issoh.co.jp/column/details/4806/" published: 2025-01-14 updated: 2026-10-12 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ファーストパーティークッキー（1st Party Cookie）とは？違いと有効期限の上限 ## まとめ：ファーストパーティークッキーの要点 - ファーストパーティークッキーとは、ブラウザのアドレスバーに表示されているサイト自身が発行し、そのサイトに送り返されるCookieです。ログイン状態の保持やカートの中身の保存など、サイトを成立させるために使われます。 - ファーストパーティーかサードパーティーかは、Cookieに付いている属性ではなく、読み書きされるときの文脈で決まります。同じCookieが、直接訪問されたときはファーストパーティー、他サイトに埋め込まれたときはサードパーティーとして扱われます。 - ファーストパーティーであれば規制の外側にある、という理解は誤りです。SafariはJavaScriptで作られた永続Cookieの有効期限を7日に切り詰め、Chromeは有効期限の指定そのものを400日で頭打ちにします。 - 設計上の分かれ目は、Set-Cookieヘッダでサーバーが発行するか、document.cookieでJavaScriptが発行するかです。7日の上限を受けるのはJavaScript発行の永続Cookieなので、認証用のCookieはサーバー発行にしてHttpOnlyで保護します。ただしCNAMEクローキングと判定される構成では、サーバー発行でも7日に切り詰められます。 - 日本の外部送信規律は、電気通信事業を営む者だけを対象とします。自社商品の情報発信や販売だけを行うサイトには適用されません。 ## ファーストパーティークッキーの定義 ファーストパーティークッキーとは、利用者が実際に訪れているサイト自身が発行し、同じサイトへのリクエストにだけ送り返されるCookieのことです。1st Party Cookieとも表記されます。オンラインショップのカートに入れた商品が別のページへ移動しても残っている、ログインし直さなくても会員ページが開ける、といった挙動を支えているのがこのCookieです。 ここでいう「同じサイト」の範囲は、オリジン（スキーム・ホスト・ポートの組み合わせ）ではなく、登録可能ドメインで決まります。WebKitはこれを次のように定義しています。 > `A registrable domain is a website's eTLD+1 or effective top-level domain plus one label.`（登録可能ドメインとは、サイトのeTLD+1、すなわち実効トップレベルドメインにラベルを1つ加えたものである） > `A website is a registrable domain including all of its subdomains.`（サイトとは、すべてのサブドメインを含む登録可能ドメインである） > 出典：[WebKit「Tracking Prevention in WebKit」](https://webkit.org/tracking-prevention/) つまり `news.example` の配下で `sub.news.example` が読み込まれても、両者は同一サイトと見なされるためファーストパーティーです。 なお、この定義はWebKitの追跡防止文書のなかでの整理であり、同文書はその範囲に限ってhttpとhttpsを同一サイトとして扱うと断っています。SameSite属性の判定はこれとは別で、Cookieの仕様改訂版はスキームと登録済みドメインの組み合わせで同一サイトかどうかを決めると定めています。SameSiteの文脈では、httpとhttpsは別サイトです。 ### ファーストパーティーとサードパーティーを分けるのは文脈 ここは混同されやすい点です。Cookieには「ファーストパーティー用」「サードパーティー用」という種別のフラグは存在しません。WebKitは明確にこう書いています。 > `There is no special kind of cookie that constitutes a third-party cookie. Instead, it's about content having access to its cookies when it's loaded from a third-party.`（サードパーティーCookieという特別な種類のCookieが存在するわけではない。それは、コンテンツがサードパーティーとして読み込まれたときに自分のCookieへアクセスできるかどうかの話である） > 出典：[WebKit「Tracking Prevention in WebKit」](https://webkit.org/tracking-prevention/) 自社ドメインが発行したCookieであっても、そのドメインのiframeや画像が他社サイトに埋め込まれて読み込まれれば、その場面ではサードパーティーCookieとして扱われ、ブラウザの制限を受けます。逆に広告事業者のドメインであっても、利用者がそのドメインを直接訪れていればファーストパーティーです。 一方、外部ドメインから配信されるJavaScriptファイルは、読み込んだページの文脈で実行されるため、そこで `document.cookie` に書かれるCookieはファーストパーティーです。分かれ目はスクリプトの配信元ではなく、Cookieを読み書きする文脈にあります。 ### Set-Cookieヘッダとdocument.cookieという2つの発行経路 ファーストパーティークッキーの発行経路は2つあります。1つはサーバーがHTTPレスポンスにSet-Cookieヘッダを付けて返す方法、もう1つはページ上のJavaScriptが `document.cookie` に代入する方法です。後者はクライアントサイドCookieとも呼ばれます。 ``` HTTP/1.1 200 OK Set-Cookie: __Host-sid=8f2c1b...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=2592000 ``` 上はサーバー発行の例です。`Max-Age=2592000` は30日を秒で表したもので、この指定があるCookieはブラウザを閉じても残る永続Cookieになります。Max-AgeとExpiresのどちらも指定しなければセッションCookieとなり、ブラウジングセッションの終了時に消えます（ブラウザのセッション復元機能が働く場合は、再起動後も残ることがあります）。後述するとおり、この2つの発行経路は有効期限の扱いが大きく異なるため、設計段階で意識して使い分ける必要があります。 ### Domain属性とPath属性で決まる送信範囲 Cookieがどのホストへ送り返されるかは、Domain属性の有無で変わります。MDNの記述は次のとおりです。 > `If omitted, the cookie is returned only to the host that sent it (i.e., it becomes a "host-only cookie"). This is more restrictive than setting the host name, as the cookie is not made available to subdomains of the host.`（省略された場合、Cookieはそれを送信したホストにのみ返される。すなわちホスト限定Cookieになる。これはホスト名を指定するよりも制限的であり、Cookieはそのホストのサブドメインには提供されない） > 出典：[MDN「Set-Cookie」](https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Set-Cookie) | 属性の指定 | 送信される範囲 | 主な用途 | | ------------------ | ------------------------- | ---------------------- | | Domain属性なし（ホスト限定） | 発行したホストのみ。サブドメインには送られない | 認証セッション。漏えい範囲を最小化したい場合 | | Domain=example.com | example.com とそのすべてのサブドメイン | 複数サブドメインをまたぐ会員基盤や計測ID | | Path=/ | そのホストの全パス | サイト全体で使うCookieの既定 | | Path=/mypage | /mypage 配下のみ | 特定機能だけで使うCookie | Domain属性には、`com` や `co.uk` のような公開サフィックスを指定できません。誰でも取得できるレベルのドメインにCookieを置けてしまうと、無関係な第三者が同じCookieを読めてしまうためです。また、Domain属性を広く取るほど、サブドメインで稼働している別システムからも同じCookieが読めるようになります。社内の別部署が立てたサブドメインを経由して認証Cookieが漏れる事故はここから起きるため、認証用のCookieはDomain属性を付けないホスト限定が原則です。 ## サードパーティークッキーとの違い 両者の違いは、Cookieを読み書きする主体が、アドレスバーに表示されているサイトと同一サイトかどうかです。同一サイトであればファーストパーティー、別サイトであればサードパーティーとして扱われます。サブドメインは同一サイトに含まれるため、ホスト名が完全に一致している必要はありません。 | 観点 | ファーストパーティークッキー | サードパーティークッキー | | ----------- | ---------------------------- | -------------------------------- | | 読み書きされる文脈 | そのサイトを直接訪れている場面 | 他サイトに埋め込まれて読み込まれる場面 | | 主な用途 | ログイン状態、カート、言語設定、自社サイトのアクセス解析 | サイトをまたいだ広告配信、リターゲティング、フリークエンシー制御 | | Safariでの既定 | 利用できる（有効期限に制限あり） | 非区画化のものは原則ブロック | | Firefoxでの既定 | 利用できる | 最上位サイトごとに隔離・既知トラッカーはブロック | | Chromeでの既定 | 利用できる | 利用者の設定に委ねる方針を維持 | ブラウザごとのサードパーティーCookieの扱いや、廃止方針が撤回された経緯は、[サードパーティCookieとは？仕組みとブラウザ別の扱いを解説【2026年最新】](/column/details/4787/)と[サードパーティCookie廃止の現在地と企業がとるべき対策【2026年最新】](/column/details/3142/)で詳しく扱っています。 ## ファーストパーティーデータとの用語の違い ファーストパーティークッキーとファーストパーティーデータは、名前が似ているだけの別概念です。混同したまま社内で議論すると、施策の前提がずれます。 - ファーストパーティークッキー：自社サイトが利用者の端末に書き込む、ブラウザの保存領域にある識別子。ブラウザの仕様変更で消えたり期限が切れたりします。 - ファーストパーティーデータ：自社が自社の接点で集めた顧客データ全般。会員情報、購買履歴、問い合わせ履歴などが該当し、自社のデータベースに保管されます。Cookieはその収集手段のひとつにすぎません。 - ゼロパーティデータ：利用者が意図的に自ら提供したデータ。アンケートの回答や設定した好みなどが該当します。 ファーストパーティークッキーが消えてもファーストパーティーデータが消えるわけではありません。逆に、Cookieだけに依存した計測設計では、ブラウザの制限がそのまま自社データの欠落になります。データ側の分類と集め方は[ゼロパーティデータとは？ファーストパーティとの違いと集め方・マーケでの使い方を解説](/column/details/13593/)で整理しています。 ## ファーストパーティークッキーの主な用途 - ログイン状態の保持：セッションIDを格納し、ページを移動しても同一の利用者だと識別します。 - 買い物かごの保持：会員登録前の利用者が選んだ商品を、次の操作まで保持します。 - 表示設定の記憶：言語、通貨、ダークモードなど、利用者が選んだ表示条件を保存します。 - 入力途中のフォームの保持：長い申込フォームで、離脱と再訪のあいだの入力内容を保ちます。 - 自社サイト内のアクセス解析：初回訪問か再訪かを区別し、セッションをまとめるために使われます。 - CSRF対策トークンの保持：ダブルサブミットクッキー方式などで、Cookieの値とフォームから送られた値が一致するかをサーバー側で検証します。Cookieに入れるだけでは対策になりません。 このうちログイン状態とCSRF対策は、Cookieが期限切れになると利用者に見える形で壊れます。アクセス解析は壊れたことが画面に出ないため、期限の切り詰めに気づかないまま数字だけがずれていく点に注意が必要です。 ## ファーストパーティークッキーの有効期限とブラウザ別の上限 「サードパーティーCookieは規制されるが、ファーストパーティーCookieなら好きな期間保持できる」という説明を見かけますが、現行のブラウザ仕様とは一致しません。ファーストパーティーにも複数の上限がかかります。 ### Safariにおけるdocument.cookie発行分の7日上限 WebKitは2019年2月21日公開の記事で、ITP 2.1としてJavaScriptが作った永続Cookieの有効期限に上限を設けたと発表しました。日付は記事の公開日であり、Safari正式版への搭載時期とは別です。 > `With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.`（ITP 2.1により、すべての永続的なクライアントサイドCookie、すなわちdocument.cookieを通じて作られた永続Cookieは、7日の有効期限に制限される） > 出典：[WebKit「Intelligent Tracking Prevention 2.1」](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/) 重要なのは適用範囲です。同じ記事は `Only cookies created through document.cookie are affected by this change.`（この変更の影響を受けるのはdocument.cookieを通じて作られたCookieだけである）と明記しており、さらに `Session cookies are not affected, they remain session cookies.`（セッションCookieは影響を受けず、セッションCookieのままである）、`Persistent cookies that have an expiry shorter than seven days keep their shorter expiry.`（7日より短い有効期限を持つ永続Cookieは、その短い期限を保つ）と続けています。 この制限はサーバーがSet-Cookieヘッダで発行したCookieには及びません。計測タグの多くはJavaScriptでCookieを書くため、7日上限を受けるのは主に解析系のIDです。 ### Safariの操作履歴による削除とCNAME・IPアドレスクローキング対策 有効期限の上限とは別に、利用者の操作がない状態が続いたときの削除も行われます。 > `ITP deletes all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction with the website.`（ITPは、サイトに対する利用者の操作がない状態が7日続いた後、JavaScriptで作られたすべてのCookieとその他のスクリプト書き込み可能なストレージを削除する） > 出典：[WebKit「Tracking Prevention in WebKit」](https://webkit.org/tracking-prevention/) この7日は暦日ではなく、Safariを使用した日数で数えます。ここでいう操作の定義も同ページに示されており、`User interaction is a user click, tap, or keyboard entry on a website.`（利用者の操作とは、サイト上でのクリック、タップ、キーボード入力である）とされています。さらに `Scrolling is not considered user interaction.`（スクロールは利用者の操作とは見なされない）と明記されている点は見落とされがちです。記事を最後まで読んだ読者でも、クリックもタップもしていなければ操作なしと判定されます。 加えて、サーバー発行に切り替えれば無条件に安全というわけでもありません。計測ドメインを自社サブドメインに見せかけるCNAME構成には、別の制限がかかります。 > `ITP detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days.`（ITPはサードパーティーのCNAMEクローキングおよびIPアドレスクローキングのリクエストを検出し、そのHTTPレスポンスで設定されたあらゆるCookieの有効期限を7日に制限する） > 出典：[WebKit「Tracking Prevention in WebKit」](https://webkit.org/tracking-prevention/) 同ページはCNAMEクローキングを、サイト本体とは異なり、かつトップフレームのCNAMEとも異なるCNAMEを経由して名前解決されるファーストパーティーのサブリソース、と定義しています。CNAMEを使っていれば一律に対象になるわけではなく、サードパーティーのクローキングと判定された場合に限られます。計測ベンダーが提供するサブドメインを別の参照先へ向ける構成は、見た目はファーストパーティーでもこの判定に該当しうるため、サーバー発行にしたはずのCookieが7日で切れることがあります。 ### Chromeにおける400日の上限 ChromeはSafariとは別の観点から、有効期限そのものに天井を設けています。 > `As of Chrome release M104 (August 2022) cookies can no longer set an expiration date more than 400 days in the future.`（Chrome M104、2022年8月のリリース以降、Cookieは400日より先の有効期限を設定できなくなった） > 出典：[Chrome for Developers「Cookie Expires and Max-Age attributes now have upper limit」](https://developer.chrome.com/blog/cookie-max-age-expires) この上限は発行のたびに再計算されるため、再訪時にサーバーやタグが同じ名前でCookieを発行し直せば、そこから改めて400日が始まります。再訪しただけで自動的に延びるわけではなく、上書きの発行が必要です。また400日は上限であって保存の保証ではありません。利用者による削除やブラウザ側の整理で、期限前に失われることもあります。なお同記事は `This change does not impact session cookies`（この変更はセッションCookieには影響しない）としており、有効期限を明示しないCookieはこれまでどおりブラウジングセッションの終了時に消えます。 背景にあるのは仕様側の変更です。IETFで策定が進むCookieの仕様改訂版（draft-ietf-httpbis-rfc6265bis）は、有効期限の上限について `which SHOULD be 400 days in the future or sooner`（400日以内であるべきである）と記述しており、Chromeの挙動はこれに沿ったものです。同じ仕様は保存数の目安として `At least 50 cookies per domain.`（ドメインあたり少なくとも50個）と `At least 3000 cookies total.`（合計で少なくとも3000個）も挙げています。 ### 計測データに出る影響 これらの制限は解析ツールの数字に直接現れます。Googleはアナリティクスのヘルプで、ファーストパーティーCookieの扱いを次のように説明しています。 > ブラウザには、ファーストパーティの Cookie の有効期限が設定されています（Chrome の場合は最大 400 日間、Safari の場合は最大 7 日間）。ユーザーが有効期間中にサイトを再度訪問しない限り、ファーストパーティの Cookie の有効期限は延長されません。 > 出典：[Google アナリティクス ヘルプ「\[GA4\] ウェブサイトでの Cookie の使用」](https://support.google.com/analytics/answer/11397207?hl=ja) 同じヘルプページでは、利用者を区別するCookieである `_ga` と、セッション状態を保持する `_ga_` のデフォルトの有効期限がいずれも2年間と示されています。設定上は2年でも、ブラウザ側の上限が優先されるため、Safariでは7日を超えて同一の利用者だと識別できるとは限りません。Cookieが失効した状態で再訪し、ログインなどで同一の利用者だと結び付けられなければ、その訪問は新規ユーザーとして計上されます。新規率が実態より高く出る形で数字に効いてきます。 対策は、期限に依存しない指標を併用することです。会員IDを持つサイトであればログイン後の自社IDで接続し、Cookieはセッション内の紐づけに限って使う設計にすると、ブラウザの制限を受ける範囲を限定できます。検索順位とCookieの関係を切り分けた整理は[CookieレスはSEOに影響するのか｜順位と計測を切り分けて解説](/column/details/3142/)にまとめています。 ## 属性設定とCookie名プレフィックスによる防御 ファーストパーティークッキーのうち、認証セッションを預かるものは盗まれたときの被害が大きい領域です。認証用のCookieには次の属性を指定します。SameSiteはStrictとLaxのどちらかを用途に応じて選ぶものであり、両方を同時に指定することはありません。 | 属性 | 効果 | 付けないときのリスク | | --------------- | ---------------------------- | --------------------------------- | | Secure | HTTPS接続のときだけ送信する | 平文通信の経路でCookieを傍受される | | HttpOnly | document.cookieから読み書きできなくする | XSSでセッションIDを盗まれる | | SameSite=Lax | 別サイトからは安全なメソッドのトップレベル遷移でのみ送信 | 別サイトからの送信にCookieが付き、CSRFが成立しやすくなる | | SameSite=Strict | 別サイトからのリクエストには送信しない | 外部リンク経由の訪問がログアウト状態に見える | HttpOnlyはJavaScriptから値を読む必要があるCookieには使えないため、対象は認証セッションなどサーバー側だけで完結するCookieに限られます。SameSite=Laxはiframe内での読み込みにはCookieを送りません。Strictは外部リンクから来た利用者に一時的にログアウト状態を見せるため、決済など被害の大きい画面に絞って使うのが実用的です。 さらに、Cookieの名前そのものに制約を課すプレフィックスが利用できます。MDNによれば、`__Secure-` で始まる名前のCookieはHTTPSページからSecure属性付きで設定されている必要があり、`__Host-` で始まるCookieはそれに加えてDomain属性を持たず、Path属性が `/` である必要があります。条件を満たさないCookieはブラウザ側が受け付けません。このうちサブドメインから認証Cookieを上書きされる攻撃を防げるのは `__Host-` のほうです。Domain属性を持てないためホスト限定になり、別のサブドメインから同じ名前のCookieを設定できなくなります。 2026年時点では、HttpOnly属性まで要求する `__Http-` と `__Host-Http-` も加わっています。MDNのブラウザ互換性データによる対応状況は次のとおりです。 | 機能 | Chrome | Firefox | Safari | | -------------------------------- | ------ | ------- | ------ | | HttpOnly属性 | 1 | 3 | 5 | | SameSite属性 | 51 | 60 | 13 | | `__Secure-`・`__Host-` プレフィックス | 49 | 50 | 13 | | `__Http-`・`__Host-Http-` プレフィックス | 140 | 143 | 未対応 | | Partitioned属性（CHIPS） | 114 | 141 | 26.2 | 上表は2026年9月23日時点のMDNブラウザ互換性データによる値です。`__Host-Http-` はFirefox 142で `__HostHttp-` という旧名称により先行実装され、143で現行の名前になりました。Safariは `__Http-` と `__Host-Http-` のいずれも未対応です。 プレフィックスは対応していないブラウザでは単なる名前として扱われるため、ブラウザ側の互換性は問題になりません。ただしCookie名そのものが変わるので、読み取り側のアプリケーションを合わせて改修し、移行期間中は新旧どちらの名前も読める状態にしておく必要があります。新規に発行するセッションCookieから `__Host-` を付けていくのが現実的な進め方です。なお表の最下段にあるPartitioned属性は、サードパーティー文脈のCookieをトップレベルサイトごとに区画化する仕組みで、ファーストパーティーの用途では使いません。詳細は[サードパーティCookieとは？仕組みとブラウザ別の扱いを解説【2026年最新】](/column/details/4787/)で扱っています。 ## 日本の法規制における扱い ### 外部送信規律の対象は電気通信事業を営む者 電気通信事業法の外部送信規律は2023年6月16日に施行されましたが、対象範囲を広く取りすぎた解説が多い領域です。総務省のFAQは、対象事業者を次のように限定しています。 > 外部送信規律に従わなければならない事業者はどのような事業者ですか。 > 答：電気通信事業者又は第三号事業を営む者（いずれも電気通信事業を営む者）で、「利用者の利益に及ぼす影響が少なくない電気通信役務」を提供している電気通信事業者です。（中略）なお、「電気通信事業（電気通信事業法（以下「法」という。）第2条第4号）」を営んでいない場合は、法の適用を受けないので、仮に情報の外部送信が行われていたとしても、外部送信規律の対象にはなりません。 > 出典：[総務省「外部送信規律FAQ」](https://www.soumu.go.jp/main%5Fsosiki/joho%5Ftsusin/d%5Fsyohi/gaibusoushin%5Fkiritsu%5F00002.html)問1-8 判定はサイト単位ではなくページの性質で行われます。同FAQは、ニュース配信のページは規律の対象になる一方、同じサイト内の会社案内のページについては「自己の情報発信のために運営していると考えられ、『電気通信事業』には該当しないため、同じウェブサイト内の当該ページにおいて外部送信が行われていたとしても、外部送信規律に対応いただく必要はありません」と答えています。自社商品の販売だけを行う小売業者についても、「本来業務である小売業の遂行の手段として電気通信を用いているに過ぎず、自己の需要のために電気通信サービスを提供しているため、『電気通信事業』に該当せず、外部送信規律も適用されません」とされています。 ただし対象になる場合は、Cookieを使っているかどうかは関係ありません。同FAQ問1-7は「外部送信規律は、利用者の端末から外部に情報を送信するよう指令するプログラム等を利用者の端末に送信する行為全般を規制するものです。このような行為を行っていれば、Cookieを利用していなかったとしても規律対象となります」と述べています。Cookieを廃したから規律の外側、という整理は成り立ちません。 ### ファーストパーティークッキーのIDは除外、一緒に送る情報は別 対象事業者に当たる場合でも、ファーストパーティークッキーには固有の取り扱いがあります。同FAQには、まさにFirst Party Cookieを名指しした設問が並んでいます。 - 問6-1：通知等の対象から除外される識別符号について、「そういった場合のFirst Party Cookieに保存されたIDなどのことをいいます」と説明されています。 - 問6-3：そのIDと一緒に自社へ送信される利用者情報も除外されるかという問いには、「除外されません。ただし、6-2にあるとおり、当該電気通信事業者に送信される情報は、原則として『真に必要な情報』に該当すると考えられますので、この原則の範囲内では除外されます」と答えています。 - 問6-4：そのIDを使って自社以外の第三者へ利用者情報が送信される場合については、「除外されません。ただし、6-2にあるとおり、当該電気通信事業者以外の第三者に送信される情報が、利用者が利用を希望している電気通信役務を提供するに当たり必要不可欠な情報の場合は、除外されます」としています。 除外されるのは、その電気通信役務を提供する事業者が利用者を識別するために送った識別符号そのものであって、そのIDに紐づけて送る情報まで自動的に外れるわけではない、という構造です。自社の解析基盤にファーストパーティークッキーのIDを送っているだけなら原則の範囲に収まりますが、同じIDをキーに外部の広告事業者へ閲覧履歴を送っている場合は、その送信について法定の対応が必要になります。外部送信規律が求めるのは、通知、利用者が容易に知り得る状態に置くこと、オプトアウト措置、同意取得のいずれかであり、同意取得だけが方法ではありません。 個人情報保護法の側では、Cookieなどの端末識別子は原則として個人関連情報として扱われます。自社で個人情報と結び付けて管理していれば個人データになり、第三者提供の場面では提供先で個人データになることが想定されるかどうかが論点になります。 ## よくある質問 ### ファーストパーティークッキーとサードパーティークッキーの違いは何ですか？ アドレスバーに表示されているサイトと同じサイトが読み書きするCookieがファーストパーティー、他社サイトに埋め込まれた状態で読み書きされるCookieがサードパーティーです。Cookie自体に種別があるのではなく、読み書きされるときの文脈で決まります。同じCookieが場面によってどちらにもなります。 ### ファーストパーティークッキーならブラウザの規制を受けませんか？ 受けます。SafariはJavaScriptで作られた永続Cookieの有効期限を7日に制限し、さらにJavaScriptで作られたCookieなどを、Safariを使用した日数で7日ぶん操作がない状態が続いた時点で削除します。Chromeは有効期限の指定を400日で頭打ちにします。サードパーティーCookieのような一律ブロックはされませんが、無制限に保持できるわけではありません。 ### Cookieを許可しないほうがよいですか？ 利用者の立場では、サイトの動作に必要なファーストパーティークッキーまで拒否すると、ログインやカートが機能しなくなります。サイトをまたいだ広告の追跡が気になる場合は、Cookie全体を拒否するのではなく、ブラウザの設定でサードパーティーCookieだけをブロックするのが実用的です。Safariでは既定で無効になっています。 ### ファーストパーティークッキーの有効期限はどこまで延ばせますか？ Chromeでは、発行のたびに最大400日までです。利用者が再訪して発行し直されれば、そこから改めて400日になります。Safariではdocument.cookieで発行した永続Cookieは7日が上限となるため、長い期間を狙う場合はSet-Cookieヘッダによるサーバー発行が前提になります。ただし計測ドメインをCNAMEで別の参照先へ向け、サードパーティーのクローキングと判定される構成では、サーバー発行でも7日に切り詰められます。 ### ファーストパーティークッキーとファーストパーティーデータは同じものですか？ 別のものです。ファーストパーティークッキーは利用者の端末側に置かれる識別子で、ブラウザの仕様変更で消えます。ファーストパーティーデータは会員情報や購買履歴など自社が自社の接点で集めて保管するデータ全般を指し、Cookieはその収集手段のひとつにすぎません。 ### ファーストパーティークッキーだけを使えば同意取得は不要ですか？ Cookieの種別だけで決まるものではありません。日本の外部送信規律は、そもそも電気通信事業を営む者だけを対象としており、自社商品の情報発信や販売のみのサイトには適用されません。対象となる場合でも、求められるのは通知または容易に知り得る状態に置くこと、オプトアウト措置、同意取得のいずれかであり、同意取得が唯一の方法ではありません。欧州の利用者を対象とする場合は、端末への情報の保存やアクセスに同意を求めるePrivacy指令の各国実装法と、その後の個人データの取り扱いを定めるGDPRを分けて検討する必要があります。 ## 関連記事 - [サードパーティCookieとは？仕組みとブラウザ別の扱いを解説【2026年最新】](/column/details/4787/) - [サードパーティCookie廃止の現在地と企業がとるべき対策【2026年最新】](/column/details/3142/) - [ITPとは？Safariの制限仕様と広告計測への影響・対策【2026年最新】](/column/details/5114/) - [ゼロパーティデータとは？ファーストパーティとの違いと集め方・マーケでの使い方を解説](/column/details/13593/) - [CookieレスはSEOに影響するのか｜順位と計測を切り分けて解説](/column/details/3142/) --- 出典: [ファーストパーティークッキー（1st Party Cookie）とは？違いと有効期限の上限]()（株式会社一創）