MENU
  1. ホーム
  2. テクノロジー
  3. 【HTML5】ローカルストレージとは？使い方・Cookie比較・セキュリティ対策まで徹底解説！

【HTML5】ローカルストレージとは？使い方・Cookie比較・セキュリティ対策まで徹底解説！

テクノロジー
2025年6月4日
目次

はじめに：ローカルストレージとは？HTML5がもたらしたブラウザーストレージの革新

ローカルストレージ（localStorage）は、ウェブブラウザにデータを永続的に保存するための仕組みであり、HTML5で導入された画期的なクライアントサイドストレージ技術の一つです 1。これにより、ウェブアプリケーションはユーザーのコンピュータ上に直接データを保存し、後でアクセスできるようになります。HTML5で標準化されたWeb Storage APIの一部として提供され、ウェブサイトのパフォーマンス向上、オフライン機能の実現、そしてより豊かなユーザーエクスペリエンスの提供に大きく貢献しています 3。従来のCookie（クッキー）が抱えていたいくつかの制約を克服するために設計されたこの技術は、現代のウェブ開発において不可欠な要素となっています 5。

この記事では、ローカルストレージの基本的な概念から、その登場背景、Cookieやセッションストレージ（sessionStorage）との詳細な比較、具体的な使い方とコード例、メリット・デメリット、そして最も重要なセキュリティ上の注意点と対策、さらにはIndexedDBのような代替技術やクライアントサイドストレージの将来展望に至るまで、国内外の信頼できる情報源を参照しながら、網羅的かつ分かりやすく解説します。ローカルストレージを初めて学ぶ方から、より深く理解したい経験豊富な開発者まで、幅広い読者にとって有益な情報を提供することを目指します。ローカルストレージの登場は、単に新しい技術仕様が追加されたというだけではなく、ウェブアプリケーションのあり方そのものを変える可能性を秘めていました。それまでのウェブが基本的にサーバー中心のステート（状態）管理に依存していたのに対し、クライアント側での高度なデータ保持を可能にすることで、よりリッチでインタラクティブな、そしてオフラインでも機能するアプリケーションへの道が開かれたのです。これは、ウェブが静的な情報表示の媒体から、動的なアプリケーションプラットフォームへと進化する上での重要な一歩と言えるでしょう。

あわせて読みたい
フロントエンド開発の要件定義について徹底解説！成果物と進め方を一挙ご紹介！ 【】 本記事では、フロントエンド開発における要件定義の重要性、具体的な進め方、主要な成果物、そして国内外でのアプローチの違いに至るまで、初学者の方にもわかりや…
あわせて読みたい
Figmaとは？使い方・料金・競合ツール(Adobe XD・Sketch等)も比較し一挙解説【2025年最新版・UIデザイン… 【】 現代のデジタルプロダクト開発において、ユーザーインターフェース（UI）およびユーザーエクスペリエンス（UX）デザインの重要性はかつてないほど高まっています。…

ローカルストレージ登場の背景：なぜCookieでは限界だったのか？

HTML5でローカルストレージが導入される以前、クライアントサイドでデータを永続化する主要な手段はCookieでした。しかし、Cookieにはいくつかの根本的な課題があり、ウェブアプリケーションが高度化・複雑化するにつれて、その限界が顕著になっていました。

従来のCookieが抱えていた課題

Cookieが抱えていた主な課題は以下の通りです。

  • 容量制限: Cookieが保存できるデータ量は、1ドメインあたり通常4KB程度と非常に小さいものでした 6。これは、ユーザー設定や一時的な情報など、ごく少量のデータを扱うには十分でしたが、アプリケーションの状態やオフライン用のコンテンツなど、より大きなデータを保存するには全く不向きでした。
  • HTTPリクエストへの自動添付: Cookieの最も大きな問題点の一つは、そのドメインに対するすべてのHTTPリクエストヘッダーに、保存されているCookieデータが自動的に含まれて送信されることでした 8。データ量がわずかであっても、リクエストのたびにこのオーバーヘッドが発生するため、通信帯域を圧迫し、特にモバイル環境のような通信速度が限られる状況ではパフォーマンスの低下を招きました。また、サーバー側にとっても不要なデータを受信することになり、負荷増加の一因となっていました。
  • セキュリティ: Cookieデータはリクエストごとにサーバーへ送信されるため、通信経路が暗号化されていない場合（HTTP通信）、盗聴されるリスクがありました。また、HttpOnly属性が設定されていないCookieはJavaScriptからアクセス可能であり、クロスサイトスクリプティング（XSS）攻撃によってセッション情報などが窃取される危険性がありました。さらに、CSRF（クロスサイトリクエストフォージェリ）攻撃の踏み台にされることもありました。
  • APIの使いにくさ: CookieをJavaScriptから操作するためのAPIは document.cookie のような文字列ベースのもので、データの読み書きや解析が煩雑で直感的ではありませんでした。キーと値のペアを扱うにも、複雑な文字列処理が必要となる場合がありました。

これらの課題は、ウェブアプリケーションがよりリッチなユーザーエクスペリエンスやオフライン機能を提供しようとする上で、大きな制約となっていました 9。

Web Storage (ローカルストレージとセッションストレージ) の標準化経緯と目的 (W3C/WHATWG)

Cookieが抱えるこれらの問題を解決し、より効率的で大容量のデータをクライアントサイドに保存する仕組みを提供するため、World Wide Web Consortium (W3C) と Web Hypertext Application Technology Working Group (WHATWG) は、HTML5の仕様策定の一環としてWeb Storage APIを標準化しました 10。この標準化プロセスは、2009年頃から具体的な草案として議論が進められていました 9。

Web Storage APIの主な設計目的は以下の通りです 8:

  1. 大容量ストレージの提供: Cookieの数KBという制限に対し、メガバイト単位（通常5MBから10MB）のストレージ容量を提供すること 8。
  2. HTTPリクエストからの分離: 保存されたデータをHTTPリクエストヘッダーに自動的に含めないことで、ネットワーク帯域の圧迫やサーバー負荷を軽減すること 8。
  3. シンプルなAPIの提供: JavaScriptから直感的かつ容易にデータを操作できるAPIを提供すること。
  4. 明確なスコープ分離: 用途に応じて使い分けられるように、永続的なデータ保存のための「ローカルストレージ (localStorage)」と、セッション期間中の一時的なデータ保存のための「セッションストレージ (sessionStorage)」という2種類のストレージメカニズムを提供すること 9。localStorageは、ユーザーがブラウザを閉じてもデータが残り続けるのに対し、sessionStorageはタブやウィンドウが閉じられるとデータが消去されるという明確な違いがあります。

W3Cの2009年のワーキングドラフト 9 では、Cookieではうまく扱えなかったシナリオ、例えば「ユーザーが同じサイトで複数の航空券を異なるウィンドウで購入しようとすると情報が混同する問題」をsessionStorageで解決し、「ユーザー作成ドキュメントやメールボックスのような大量データをクライアントに保存したい要求」をlocalStorageで満たすという具体的な動機が述べられています。

Web Storageの標準化は、ウェブが単なる情報閲覧の場から、複雑な機能を持つ「アプリケーションプラットフォーム」へと進化する過程で不可欠なステップでした。Cookieの制約は、この進化の大きな足かせとなっていたため、Web Storageの登場は開発者コミュニティから歓迎されました。この標準化の背景には、W3CとWHATWGという二つの主要な標準化団体間の協力、そして時には競合するアプローチが存在しましたが、最終的には開発者にとってより使いやすく強力な技術仕様へと結実しました。このプロセス自体が、ウェブ技術の健全な発展において標準化団体が果たす重要な役割を示しています。

あわせて読みたい
cookieとは-サードパーティcookieの廃止は結局何にどう影響を与えるの？- 【】 インターネットを利用する上で、私たちは日々「Cookie（クッキー）」という言葉に触れています。ウェブサイトを閲覧する際に表示されるCookieに関する同意画面や、…

ローカルストレージの仕組みと特徴を徹底解剖

ローカルストレージは、HTML5のWeb Storage APIの一部として提供されるクライアントサイドのデータ保存技術です。その仕組みは比較的シンプルでありながら、ウェブアプリケーションに強力な永続性をもたらします。

基本的な使い方：キーと値のペア、APIメソッド (setItem, getItem, removeItem, clear)

ローカルストレージは、データを「キー (key)」と「値 (value)」のペアとして保存します。このキーと値は、どちらも文字列として扱われるのが基本です 6。JavaScriptを通じて、グローバルオブジェクトである window.localStorage (または単に localStorage) を介して簡単に操作できます。

主要なAPIメソッドは以下の通りです 5:

  • localStorage.setItem(key, value): 指定された key (文字列) に value (文字列) を保存します。もし同じ key が既に存在する場合は、値が上書きされます。
    JavaScript
    localStorage.setItem(‘username’, ‘山田太郎’);
    localStorage.setItem(‘theme’, ‘dark’);
  • localStorage.getItem(key): 指定された key に関連付けられた値を取得します。もし key が存在しない場合は null を返します。
    JavaScript
    let username = localStorage.getItem(‘username’); // “山田太郎”
    let preferredColor = localStorage.getItem(‘color’); // 存在しない場合、null
  • localStorage.removeItem(key): 指定された key とそれに対応する値をローカルストレージから削除します。
    JavaScript
    localStorage.removeItem(‘theme’);
  • localStorage.clear(): そのオリジン（ドメイン）に保存されているすべてのキーと値のペアを削除します。
    JavaScript
    localStorage.clear();
  • localStorage.length: 現在ローカルストレージに保存されているアイテム（キーと値のペア）の数を返します。
    JavaScript
    let itemCount = localStorage.length;
  • localStorage.key(index): 指定されたインデックス（0から始まる整数）に対応するキーの名前を返します。アイテムの順序は保証されませんが、すべてのキーを列挙する際に利用できます。
    JavaScript
    for (let i = 0; i < localStorage.length; i++) {
      let keyName = localStorage.key(i);
      let value = localStorage.getItem(keyName);
      console.log(`キー: ${keyName}, 値: ${value}`);
    }

これらのAPIは非常にシンプルで直感的であるため、開発者は容易にローカルストレージを利用し始めることができます。

あわせて読みたい
APIってなに？ -仕組みと歴史を徹底解説- 「API」という言葉を聞いたことはあっても、「具体的にはよく分からない」という方は多いのではないでしょうか。実は、APIはさまざまなサービスを便利につなげる「橋渡…
あわせて読みたい
APIのエンドポイントとは？初学者にもわかりやすく徹底解説 【】 現代のデジタル社会では、様々なソフトウェアやサービスが互いに連携し、私たちの生活や仕事を便利にしています。その連携の中心的な役割を担っているのが「API」…

主要な特徴

ローカルストレージは、他のクライアントサイドストレージ技術と比較して、いくつかの際立った特徴を持っています。

  • 永続性 (Persistence): ローカルストレージに保存されたデータは、ユーザーがブラウザを閉じても消えません。データは、JavaScriptコードによって明示的に removeItem() や clear() が呼び出されるか、ユーザーがブラウザの設定からキャッシュやサイトデータをクリアしない限り、永続的に保持されます 1。ただし、ブラウザのプライベートブラウジングモード（シークレットモードなど）では、通常、最後のプライベートウィンドウが閉じられるとローカルストレージのデータも消去されます 10。
  • 容量 (Capacity): ローカルストレージは、Cookieと比較してはるかに大きなデータ容量を提供します。通常、1つのオリジン（ドメイン）あたり5MBから10MB程度のデータを保存できます 6。これは、ユーザー設定、オフライン用の小規模なデータセット、アプリケーションの状態などを保存するのに十分な容量です。ただし、具体的な上限値はブラウザの実装によって異なる場合があり、上限を超えてデータを保存しようとするとエラー（通常は QuotaExceededError）が発生します 7。
  • スコープ (Scope): ローカルストレージのデータは、同一オリジンポリシーに基づいてスコープが決定されます。つまり、プロトコル（http/https）、ホスト名（ドメイン）、ポート番号の組み合わせが完全に一致するオリジン内でのみデータが共有されます 6。同じオリジンであれば、異なるタブやウィンドウ間でローカルストレージのデータを共有できます。重要な点として、http://example.com と https://example.com は異なるオリジンとして扱われ、それぞれのローカルストレージは独立しています 11。この「オリジン」というスコープ概念はウェブセキュリティの基本ですが、ローカルストレージの文脈では、開発者が意図しないデータ共有やキーの衝突を避けるために、特に大規模なサイトや複数のアプリケーションが同一ドメイン（異なるサブドメインではなく）で運用されている場合、サブドメインの活用戦略やキーの命名規則などを慎重に検討する必要があります。OWASPのチートシートでも、同一オリジンでの複数アプリケーションのホスティングを避け、サブドメインを使用することが推奨されています 14。
  • データ型 (Data Type – 文字列限定とJSON): ローカルストレージAPIは、キーも値も文字列としてのみ保存します 6。数値や真偽値、オブジェクト、配列などの非文字列データを保存したい場合は、まず JSON.stringify() メソッドを使ってJSON形式の文字列に変換し、ローカルストレージに保存する必要があります。そして、データを取り出す際には JSON.parse() メソッドを使って元のデータ型（オブジェクトや配列など）に復元します 12。
    JavaScript
    // オブジェクトを保存
    const userPrefs = { notifications: true, itemsPerPage: 20 };
    localStorage.setItem(‘preferences’, JSON.stringify(userPrefs));

    // オブジェクトを取得・パース
    const storedPrefsString = localStorage.getItem(‘preferences’);
    const loadedPrefs = storedPrefsString? JSON.parse(storedPrefsString) : null;

    if (loadedPrefs) {
      console.log(loadedPrefs.notifications); // true
      console.log(loadedPrefs.itemsPerPage);  // 20
    }
    ローカルストレージのAPI設計は、このシンプルさと使いやすさを優先した結果、文字列限定という制約が生まれました。これは初期のウェブ開発者にとっては直感的で導入しやすいものでしたが、アプリケーションが複雑化し、JSONのような構造化データを頻繁に扱うようになると、この JSON.stringify() / parse() の変換処理が、特に大量のデータや頻繁なアクセスがある場合には無視できないパフォーマンスのオーバーヘッドとして認識されるようになりました 15。このシンプルさのトレードオフは、後にIndexedDBのようなより高機能だがAPIが複雑なストレージ技術の必要性を生んだ一因とも考えられます。

【徹底比較】ローカルストレージ vs セッションストレージ vs Cookie

ウェブ開発においてクライアントサイドでデータを保存する手段として、ローカルストレージ、セッションストレージ、そして伝統的なCookieが存在します。これらはそれぞれ異なる特性を持ち、用途に応じて適切に使い分けることが重要です。

それぞれの特徴と違いを表で分かりやすく解説

以下に、ローカルストレージ、セッションストレージ、Cookieの主な特徴と違いをまとめた比較表を示します。

特徴項目ローカルストレージ (localStorage)セッションストレージ (sessionStorage)クッキー (Cookie)
主な目的クライアント側での永続的なデータ保存セッション期間中の一時的なデータ保存サーバーとクライアント間での状態管理、トラッキング
容量通常 5MB～10MB/オリジン 6通常 5MB～10MB/オリジン 6約 4KB/ドメイン (全体でも制限あり) 6
永続性ユーザーが削除するまで永続 12ブラウザのタブ/ウィンドウが閉じられると消滅 1設定された有効期限まで (またはセッション終了まで) 6
スコープ同一オリジン内の全ウィンドウ/タブで共有 6同一オリジン内の同一タブ/ウィンドウ内のみ 6ドメインおよび指定パス。サブドメインへの共有も設定可能 6
サーバーとの通信自動的には送信されない 8自動的には送信されない 8全てのHTTPリクエストに自動的に添付される 8
アクセス元クライアントサイドJavaScriptのみ 8クライアントサイドJavaScriptのみ 8サーバーサイドおよびクライアントサイドJavaScript (HttpOnly属性なしの場合) 12
データ型文字列 (オブジェクトはJSON化して保存) 6文字列 (オブジェクトはJSON化して保存) 6文字列 6
APIの使いやすさシンプルで直感的 (setItem, getItem等) 1ローカルストレージと同様にシンプル 5文字列操作が中心でやや煩雑 9
主な用途例ユーザー設定、オフラインデータ、UI状態の永続化 12フォーム入力の一時保存、ショッピングカート、タブ固有の状態 12セッションID、ユーザー認証、トラッキング、パーソナライズ 12
セキュリティ懸念XSSによる情報窃取のリスク。機密情報の保存は非推奨 14。ローカルストレージと同様のXSSリスク。機密情報は非推奨 12。CSRF、XSS、セッションハイジャックのリスク。HttpOnly, Secure, SameSite属性で対策 12。

この表からもわかるように、これら3つの技術は競合するものではなく、それぞれが異なる課題を解決するために設計された補完的な関係にあります。開発者は、アプリケーションの要件、データの性質、セキュリティ要件などを総合的に評価し、これらの特性を深く理解した上で戦略的に使い分ける必要があります。

使い分けのシナリオと具体例

それぞれのストレージ技術がどのような場面で活用されるか、具体的なシナリオを見ていきましょう。

  • ローカルストレージ (localStorage) の利用シナリオ:
  • ユーザー設定の永続化: ウェブサイトのテーマ（ダークモード/ライトモード）、表示言語、フォントサイズなど、ユーザーが一度設定したら次回訪問時にも保持したい情報 12。例えば、ニュースサイトで文字の大きさを変更した場合、その設定をローカルストレージに保存しておけば、次に同じブラウザでアクセスした際に同じ文字サイズで表示できます。
  • オフライン機能のサポート: ネットワーク接続がない状態でも利用できるアプリケーションデータ（例: TODOリストのアイテム、メモ帳の内容、PWAのキャッシュコンテンツの一部）の保存 3。
  • アプリケーション状態の記憶: ユーザーが最後に開いていたページ、アコーディオンメニューの開閉状態など、UIの状態を記憶しておき、再訪時に復元する。
  • 閲覧履歴: 楽天市場のようなECサイトで、ユーザーが最近見た商品のリストを表示するのに利用されます 12。
  • セッションストレージ (sessionStorage) の利用シナリオ:
  • フォーム入力内容の一時保存: 複数ステップにわたる会員登録フォームやアンケートなどで、ユーザーが入力途中の情報を一時的に保存し、ページ遷移や誤ったリロードがあっても内容が失われないようにする 12。タブを閉じると消えるため、機密性の高い入力情報の一時保管にも比較的向いています。
  • ショッピングカートの一時情報: ECサイトで、ユーザーがログインせずに商品をカートに入れた場合、そのカート情報をセッションストレージに保存し、タブを閉じるまで保持する 12。
  • シングルページアプリケーション (SPA) での一時的な状態: SPA内でページ遷移のような動作をする際に、一時的に保持したいフィルター条件やソート順などを保存する。
  • 検索履歴（セッション内）: 検索結果ページで、ユーザーがそのセッション内で行った検索の履歴を一時的に保持するのに使われることがあります 12。
  • クッキー (Cookie) の利用シナリオ:
  • セッション管理とユーザー認証: ユーザーのログイン状態を維持するためのセッショントークンや認証情報を保存する。これはサーバーサイドとの連携が必須であり、Cookieの最も代表的な用途です 12。
  • ユーザー行動のトラッキングと分析: ユーザーがどのページを訪れたか、どのくらいの頻度でサイトを利用しているかなどの行動データを記録し、ウェブサイト改善やマーケティング分析に活用する。
  • パーソナライズされたコンテンツや広告の表示: ユーザーの過去の閲覧履歴や興味に基づいて、関連性の高いコンテンツや広告を表示する。
  • サーバーサイドで参照が必要な設定: 言語設定や地域設定など、サーバー側でも認識して処理を分岐させたい小さな設定情報の保存 12。

HttpOnly属性、Secure属性、SameSite属性といったCookieのセキュリティ機能の進化は、ローカルストレージやセッションストレージにはない、サーバー連携時における強みを示しています。これらの属性を適切に設定することで、XSSによるセッショントークンの窃取リスクを軽減したり、CSRF攻撃を防いだりすることが可能です 12。このため、特に認証情報のような機密性の高いデータを扱う場合は、依然としてCookieが重要な役割を担っており、ローカルストレージよりも安全な選択肢となり得ます。ローカルストレージはその利便性から多用されがちですが、このようなサーバー連携を前提とした高度なセキュリティ機構を持たない点を十分に理解しておく必要があります。

ローカルストレージの具体的な活用事例とコード例

ローカルストレージは、そのシンプルさと永続性から、ウェブアプリケーションの様々な場面でユーザー体験の向上や機能の実現に役立てられています。ここでは、代表的な活用事例と、それを実現するための基本的なJavaScriptコード例を紹介します。

ユーザー設定の保存 (UIカスタマイズなど)

多くのウェブサイトやアプリケーションでは、ユーザーが自身の好みに合わせてUIをカスタマイズできる機能を提供しています。例えば、ダークモード/ライトモードの切り替え、フォントサイズの変更、表示言語の選択などが挙げられます。これらの設定をローカルストレージに保存することで、ユーザーが次回サイトを訪問した際にも同じ設定が自動的に適用され、一貫した利用体験を提供できます 12。

コード例:

JavaScript

// ダークモード設定を保存
function enableDarkMode() {
  document.body.classList.add(‘dark-mode’);
  localStorage.setItem(‘theme’, ‘dark’);
}

// ライトモード設定を保存
function enableLightMode() {
  document.body.classList.remove(‘dark-mode’);
  localStorage.setItem(‘theme’, ‘light’);
}

// ページ読み込み時に設定を適用
function applyTheme() {
  const savedTheme = localStorage.getItem(‘theme’);
  if (savedTheme === ‘dark’) {
    enableDarkMode();
  } else {
    enableLightMode(); // デフォルトはライトモード
  }
}

applyTheme(); // ページロード時に実行

// ボタンクリックなどでテーマを切り替えるイベントリスナーを設定
// document.getElementById(‘darkModeButton’).addEventListener(‘click’, enableDarkMode);
// document.getElementById(‘lightModeButton’).addEventListener(‘click’, enableLightMode);

オフライン機能の実現 (PWAなど)

ローカルストレージは、Progressive Web Apps (PWA) のような、オフラインでも動作するウェブアプリケーションを構築する際に重要な役割を果たします。記事のコンテンツ、TODOリストのアイテム、小規模な設定データなどをローカルに保存しておくことで、ユーザーがネットワークに接続していない状態でも、これらの情報にアクセスしたり、基本的な操作を行ったりすることが可能になります 3。

コード例 (TODOリストのアイテムを保存・表示する簡単な例):

JavaScript

const todoInput = document.getElementById(‘todo-input’);
const addTodoButton = document.getElementById(‘add-todo-button’);
const todoListElement = document.getElementById(‘todo-list’);

// ローカルストレージからTODOアイテムを読み込む
function loadTodos() {
  const todosString = localStorage.getItem(‘todos’);
  return todosString? JSON.parse(todosString) :;
}

// TODOアイテムをローカルストレージに保存する
function saveTodos(todos) {
  localStorage.setItem(‘todos’, JSON.stringify(todos));
}

// TODOリストを表示する
function renderTodos() {
  const todos = loadTodos();
  todoListElement.innerHTML = ”; // リストをクリア
  todos.forEach((todoText, index) => {
    const listItem = document.createElement(‘li’);
    listItem.textContent = todoText;
    // (ここに削除ボタンなどの処理を追加可能)
    todoListElement.appendChild(listItem);
  });
}

// TODOアイテムを追加する
addTodoButton.addEventListener(‘click’, () => {
  const newTodo = todoInput.value.trim();
  if (newTodo) {
    const todos = loadTodos();
    todos.push(newTodo);
    saveTodos(todos);
    renderTodos();
    todoInput.value = ”; // 入力欄をクリア
  }
});

renderTodos(); // 初期表示

この例では、JSON.stringify() と JSON.parse() を使用してTODOアイテムの配列を文字列として保存・復元しています 12。

フォーム入力内容の一時保存

ユーザーが長いブログ記事を作成したり、複雑なアンケートフォームに入力したりしている途中で、誤ってブラウザを閉じてしまったり、ネットワークエラーが発生したりすると、それまでの入力内容が全て失われてしまう可能性があります。このような事態を防ぐため、入力中のデータを定期的にローカルストレージに自動保存する機能が役立ちます 7。ユーザーがページに戻ってきた際に、保存された内容を復元できます。

コード例 (テキストエリアの内容を自動保存・復元):

JavaScript

const textarea = document.getElementById(‘blog-post-textarea’);
const saveKey = ‘draftBlogPost’;

// 1秒ごとに入力内容をローカルストレージに保存
textarea.addEventListener(‘input’, () => {
  localStorage.setItem(saveKey, textarea.value);
});

// ページ読み込み時に保存された下書きを復元
window.addEventListener(‘load’, () => {
  const savedDraft = localStorage.getItem(saveKey);
  if (savedDraft) {
    textarea.value = savedDraft;
  }
});

ウェブアプリケーションのパフォーマンス向上

頻繁にアクセスするものの、更新頻度は低いデータ（例: 商品カテゴリの一覧、グローバルな設定情報、ユーザープロファイルの基本情報など）を毎回サーバーから取得するのは非効率です。これらのデータを一度取得した後、ローカルストレージにキャッシュしておくことで、次回以降のアクセス時にはサーバーへのリクエストを行わずにローカルからデータを読み込み、表示速度を向上させることができます 3。これは、ユーザー体験を向上させるだけでなく、サーバーの負荷軽減にも繋がります。

コード例 (APIから取得したデータをキャッシュ):

JavaScript

const cacheKey = ‘productCategories’;
const cacheExpiryMs = 60 * 60 * 1000; // 1時間

async function getProductCategories() {
  const cachedDataString = localStorage.getItem(cacheKey);
  if (cachedDataString) {
    const cachedData = JSON.parse(cachedDataString);
    // キャッシュの有効期限を確認
    if (Date.now() – cachedData.timestamp < cacheExpiryMs) {
      console.log(‘カテゴリをキャッシュから読み込みました’);
      return cachedData.data;
    }
  }

  // キャッシュがないか期限切れの場合、サーバーから取得
  console.log(‘カテゴリをサーバーから読み込み中…’);
  // const response = await fetch(‘/api/categories’); // 実際のAPIエンドポイント
  // const data = await response.json();
  const data =; // ダミーデータ

  localStorage.setItem(cacheKey, JSON.stringify({ data: data, timestamp: Date.now() }));
  return data;
}

// 利用例
// getProductCategories().then(categories => {
//   console.log(categories);
// });

これらの活用事例は、ローカルストレージが単にデータを「保存する」だけでなく、ウェブサイトを「静的なページの集まり」から「動的なアプリケーション」へと進化させ、ユーザー体験の向上とパーソナライゼーションを実現する具体的な手段であることを示しています。特に「パフォーマンス向上」の観点では、ローカルストレージがウェブサイトの応答性を高めるための「クライアントサイドキャッシュ」としても機能し、データ取得に時間のかかるAPI連携などで有効な戦略となり得ます。

ローカルストレージのメリット・デメリットと注意点

ローカルストレージは非常に便利な機能ですが、その特性を理解し、メリットとデメリットを把握した上で利用することが重要です。

メリット

  • 大容量: Cookieが約4KBの容量制限を持つのに対し、ローカルストレージは通常、1オリジンあたり5MBから10MBという格段に大きなデータを保存できます 1。これにより、より多くの情報をクライアントサイドに保持できます。
  • 永続性: ローカルストレージに保存されたデータは、ユーザーがブラウザを閉じても消えません。開発者が明示的に削除するか、ユーザーがブラウザのデータをクリアするまで永続的に保持されます 12。
  • サーバー負荷軽減: Cookieとは異なり、ローカルストレージのデータはHTTPリクエストヘッダーに自動的に添付されません 8。これにより、不要なデータ転送が削減され、サーバーの負荷軽減とネットワーク帯域の節約に繋がります。
  • オフラインアクセス: ネットワーク接続がない状態でも、ローカルストレージに保存されたデータにJavaScriptからアクセスできます。これは、オフライン対応のウェブアプリケーション（PWAなど）を開発する上で非常に有利です 3。
  • シンプルなAPI: setItem(), getItem(), removeItem(), clear() といった直感的でシンプルなAPIが提供されており、学習コストが低く、容易に操作できます 1。小規模なキーバリューの割り当てにおいては、IndexedDBなど他のストレージソリューションと比較しても高速に動作することがあります 15。

デメリットと注意点

  • 同期的なブロッキングAPI: ローカルストレージの操作（読み書き）は同期的（ブロッキング）です 15。これは、ローカルストレージへのアクセスが完了するまで、ブラウザのメインスレッド（UIスレッド）が他の処理（UIの描画やユーザーインタラクションの処理など）を停止してしまうことを意味します。特に大量のデータを扱ったり、頻繁にアクセスしたりする場合、UIがフリーズしたように見え、ユーザーエクスペリエンスを著しく低下させる可能性があります。この「同期API」であるというデメリットは、ユーザー操作への即時応答性が求められる現代のウェブアプリケーションにおいて、特に重要な考慮事項となります。
  • JSON文字列化のオーバーヘッド: ローカルストレージは文字列データしか保存できないため、オブジェクトや配列などの複雑なデータ構造を保存するには JSON.stringify() で文字列に変換し、取得時には JSON.parse() で元に戻す必要があります 15。このシリアライズ・デシリアライズ処理は、特にデータサイズが大きい場合やアクセス頻度が高い場合にパフォーマンスのオーバーヘッドとなることがあります 15。
  • データ型は文字列のみ: 数値や真偽値も内部的には文字列として保存されるため、取得後に適切な型に変換する必要が生じることがあります 6。
  • セキュリティリスク: ローカルストレージのデータは、同一オリジン内であればどのJavaScriptコードからでも容易にアクセス可能です。そのため、クロスサイトスクリプティング（XSS）脆弱性が存在する場合、攻撃者によってデータが窃取されたり改ざんされたりするリスクがあります（詳細は次章で解説します）14。
  • 容量制限: 大容量とはいえ無制限ではなく、ブラウザやオリジンごとに上限（通常5MB～10MB）が設定されています 7。この上限を超えてデータを保存しようとするとエラーが発生するため、アプリケーションはこれを適切に処理する必要があります。
  • インデックス機能なし: ローカルストレージには、データベースのようなインデックス機能がありません。そのため、特定の条件に基づいてデータを効率的に検索したり、ソートしたりすることはできません 15。大量のデータの中から特定のアイテムを探すような用途には不向きです。
  • Web Workersからの利用制限の可能性: 一部の情報源では、Web Workersから直接ローカルストレージを利用できない、あるいは利用に制約があると指摘されています 17。メインスレッドをブロックする性質から、Workerでの利用が推奨されないケースも考えられます。Workerで利用する場合は、postMessage を介してメインスレッドと通信するなどの工夫が必要になることがあります。
  • ユーザーによるデータ削除の可能性: ユーザーがブラウザの履歴削除機能やキャッシュクリア機能を利用した際に、ローカルストレージに保存されているデータも意図せず一緒に削除されてしまう可能性があります 7。アプリケーションは、データが存在しないケースも考慮して設計する必要があります。

ローカルストレージの「シンプルさ」は、その最大のメリットであると同時に、パフォーマンスや複雑なデータ操作におけるデメリットの根源でもあります。このトレードオフを理解することが、適切な技術選択に繋がります。手軽に使える永続ストレージとしては優れていますが、その手軽さと引き換えに高度な機能やパフォーマンス最適化の余地が犠牲になっている点を認識しておくべきです。

ローカルストレージのセキュリティ：安全に使うための必須知識

ローカルストレージは手軽で便利な反面、セキュリティ上のリスクも内包しています。特にクロスサイトスクリプティング（XSS）攻撃に対する脆弱性は、開発者が十分に理解し対策を講じる必要があります。

XSS (クロスサイトスクリプティング) のリスクと影響

ローカルストレージのデータは、同一オリジン内のJavaScriptから完全にアクセス可能です 14。これは、もしウェブサイトにXSS脆弱性が存在する場合、攻撃者が挿入した悪意のあるスクリプトによって、ローカルストレージに保存されている情報が簡単に読み取られたり、書き換えられたりする可能性があることを意味します 18。

例えば、以下のような情報が危険にさらされる可能性があります。

  • ユーザーの個人設定（テーマ、言語など）
  • アプリケーションの内部状態を示すフラグやデータ
  • （不適切に保存された場合の）セッショントークンやAPIキーの断片
  • 入力途中のフォームデータ

これらの情報が窃取されればプライバシー侵害に、改ざんされればアプリケーションの誤動作やなりすましにつながる可能性があります。ローカルストレージのセキュリティは、技術的な堅牢性よりも、それをどのように利用するかという開発者の運用とセキュリティ意識に大きく依存します。API自体はシンプルですが、そのシンプルさが故に誤用されやすく、XSSのような古典的な脆弱性の影響を直接受けてしまうのです。

機密情報（パスワード、クレジットカード情報、個人識別情報など）の保存は原則NG

ローカルストレージは、ブラウザの開発者ツールなどを使えば比較的容易に内容を閲覧でき、また暗号化も標準では行われません。そのため、パスワード、クレジットカード番号、マイナンバー、社会保障番号といった極めて機密性の高い情報をローカルストレージに直接保存することは絶対に避けるべきです 14。これらの情報は、万が一XSS攻撃などで漏洩した場合、深刻な被害を引き起こす可能性があります。OWASP (Open Web Application Security Project) も一貫して、認証を前提とするような機密情報をローカルストレージに保存しないよう強く推奨しています 14。

OWASPが推奨する対策とベストプラクティス

OWASPは、ウェブアプリケーションのセキュリティ向上を目指す国際的なコミュニティであり、ローカルストレージの安全な利用に関しても以下のようなガイドラインやベストプラクティスを提示しています 14。

  • 機密情報を保存しない: 最も基本的な原則です。認証トークン、個人情報、財務情報などはローカルストレージに保存すべきではありません。
  • セッション識別子を保存しない: セッションIDのような情報は、JavaScriptからのアクセスを制限できるHttpOnly属性を設定したCookieに保存する方が安全です。ローカルストレージは常にJavaScriptからアクセス可能であるため、XSS攻撃で容易に窃取されます。
  • データの信頼性を仮定しない: ローカルストレージに保存されているデータは、XSS攻撃によって改ざんされている可能性があるため、決して信頼できるものとして扱ってはいけません。利用する前には必ず検証を行うべきです。
  • 入力値のサニタイズと出力時のエスケープ: ユーザーからの入力値や外部から取得したデータをローカルストレージに保存する前には、必ずサニタイズ（無害化）処理を行います。また、ローカルストレージから取得したデータをHTMLに表示する際には、適切にエスケープ処理を行い、スクリプトとして解釈されることを防ぎます 19。
  • 同一オリジンでの複数アプリケーションのホスティング回避: 複数の独立したアプリケーションを同一オリジン（例: example.com/app1, example.com/app2）でホストすると、それらが同じローカルストレージ領域を共有してしまいます。これにより、意図しないデータの衝突や漏洩のリスクが生じます。可能であれば、異なるサブドメイン（例: app1.example.com, app2.example.com）でホストすることを検討してください。
  • Content Security Policy (CSP) の導入: CSPを適切に設定することで、信頼できないソースからのスクリプト実行を制限し、XSS攻撃のリスクを大幅に軽減できます 19。

これらの推奨事項の多くは、「何を保存すべきでないか」「どのように扱うべきか」という開発者の判断と実践に関するものであり、開発者のセキュリティ意識と適切なコーディング規約の遵守が極めて重要です。

入力値のサニタイズ (例: DOMPurify) とエスケープ

XSS攻撃を防ぐためには、ユーザー入力や外部から取得した信頼できないデータを扱う際に、サニタイズとエスケープを徹底することが不可欠です。

  • サニタイズ: HTML、SVG、MathMLなどのコンテンツをローカルストレージに保存する可能性がある場合、DOMPurifyのような信頼できるライブラリを使用して、悪意のあるスクリプトや属性を除去（サニタイズ）します 19。
    JavaScript
    // DOMPurifyの利用例（概念）
    // import DOMPurify from ‘dompurify’; // モジュールとしてインポート

    // const userInputHTML = ‘<img src=”x” onerror=”alert(\’XSS\’)”> malicious script’;
    // const sanitizedHTML = DOMPurify.sanitize(userInputHTML);
    // localStorage.setItem(‘userGeneratedContent’, sanitizedHTML);
  • エスケープ: ローカルストレージから取得したデータをHTML内に表示する場合、そのデータがHTMLタグやJavaScriptとして解釈されないようにエスケープ処理を行います。最も安全な方法は、element.textContent プロパティを使ってテキストとして挿入することです。動的にHTMLを生成するために element.innerHTML を使用する場合は、表示するデータが信頼できるものであるか、あるいは適切にエスケープされていることを確認する必要があります 21。

セキュアなラッパーライブラリの利用検討

ローカルストレージに保存するデータを自動的に暗号化・復号化する機能を提供するラッパーライブラリも存在します（例: react-secure-storage 22, secure-ls (言及なしだが類似ライブラリとして)）。これらを利用することで、ローカルストレージ内のデータが平文で保存されるのを防ぎ、ある程度の保護レイヤーを追加できます。ライブラリによっては、ブラウザのフィンガープリントなどを利用してデバイスごとに異なる暗号化キーを生成しようと試みるものもあります 22。

しかし、これらのライブラリを利用する際には注意が必要です。暗号化キーの管理が新たな課題となります。キーがクライアントサイドのJavaScriptコード内にハードコーディングされていたり、容易に推測可能であったりする場合、攻撃者によってコードが解析されれば、結局データは復号されてしまいます 22。23では「秘密鍵をコードに含めて配布してはいけない」と明確に警告しています。したがって、ラッパーライブラリによる暗号化は、追加の保護層にはなり得ますが、それ自体が万能のセキュリティソリューションではなく、過信は禁物です。機密情報をローカルストレージに保存することを避けるという原則は、依然として最も重要です。

ローカルストレージの先へ：IndexedDBなどの代替技術

ローカルストレージは手軽で便利な反面、扱えるデータ量や機能には限界があります。より複雑なデータ構造や大量のデータをクライアントサイドで扱いたい場合、あるいは非同期処理が求められる場合には、IndexedDBのようなより高機能なストレージ技術の利用が検討されます。

IndexedDBの概要とローカルストレージとの違い

IndexedDBの概要:

IndexedDBは、ウェブブラウザ内で大量の構造化データを永続的に保存し、効率的に検索するための低レベルAPIです 6。キーバリューストアの一種ですが、オブジェクトストア（リレーショナルデータベースのテーブルに似た概念）とインデックスを利用することで、複雑なデータの管理やクエリが可能です。

ローカルストレージとの主な違い:

特徴ローカルストレージ (localStorage)IndexedDB
データ容量通常5MB～10MB/オリジン 6数百MB以上、場合によってはGB単位も可能（ブラウザと空き容量による） 6
データ型文字列のみ（オブジェクトはJSON化） 6JavaScriptオブジェクト、ファイル、Blobなど多様なデータを直接保存可能 6
APIの性質同期API（メインスレッドをブロック） 15非同期API（Promiseベースまたはイベントベースでメインスレッドをブロックしない） 15
トランザクションなしあり（データの原子性、一貫性、分離性、耐久性(ACID)を保証）
インデックスなし（キーによる検索のみ）あり（キー以外のフィールドにもインデックスを作成し、高速検索や範囲検索が可能） 15
複雑さシンプルで学習コストが低い 1APIが複雑で学習コストが高い 15
クエリ機能限定的豊富（インデックスを利用した複雑なクエリが可能）

IndexedDBは、ローカルストレージが苦手とする大量のデータや複雑なデータ構造の扱いに長けており、オフラインアプリケーションの主要なデータストアとして利用されることが多いです 15。

Web SQL Databaseの廃止経緯

かつて、クライアントサイドでリレーショナルデータベース機能を提供するためにWeb SQL Databaseという仕様が提案されていました。これは、ウェブアプリケーションがSQLを使ってローカルデータベースを操作できるようにするものでした。しかし、W3Cは2010年にWeb SQL Databaseの仕様策定を中止し、非推奨としました 14。

廃止の主な理由は以下の通りです 26:

  1. 単一実装への依存: Web SQL Databaseの仕様は、事実上SQLiteという特定のSQLデータベースエンジンの方言に強く依存していました。これにより、他のブラウザベンダーが異なるSQLエンジンを用いて互換性のある実装を独立して開発することが困難になりました。
  2. 標準化の停滞: 上記の理由から、複数の独立した実装を確保するというW3Cの標準化原則を満たすことができず、仕様の進展が停滞しました。
  3. セキュリティとAPI設計の懸念: APIの形状やセキュリティに関する懸念も指摘されていました。

WHATWGのコミュニティではその後も議論が続けられた時期もありましたが 27、最終的にはIndexedDBがクライアントサイドの構造化データストレージの標準的な選択肢として推奨される形となりました。Web SQL Databaseの廃止とIndexedDBの台頭は、ウェブ標準化プロセスにおいて「実装の多様性」と「将来の拡張性」がいかに重要であるかを示す教訓的な出来事でした。特定の技術や実装に過度に依存する標準は、持続可能性に欠けるということが示されたのです。

使い分けのポイント

ローカルストレージとIndexedDBは、それぞれ得意とする領域が異なります。

  • ローカルストレージが適しているケース:
  • 少量のキーバリューストアとして、ユーザー設定（テーマ、言語など）やアプリケーションの簡単な状態（UIの表示/非表示フラグなど）を保存する場合。
  • APIがシンプルで手軽に導入したい場合。
  • データの永続性が必要だが、複雑なクエリや大量のデータ操作は不要な場合。
  • IndexedDBが適しているケース:
  • 大量の構造化データ（数十MB～数百MB以上）をクライアントサイドで管理する必要がある場合 24。
  • オフラインアプリケーションの主要なデータストアとして、複雑なデータモデルを扱う場合。
  • 特定のフィールドに対するインデックスを作成し、効率的な検索、ソート、範囲クエリを行いたい場合 15。
  • データの整合性を保つためのトランザクション処理が必要な場合。
  • メインスレッドをブロックしない非同期処理がパフォーマンス上不可欠な場合。

ローカルストレージからIndexedDBへの技術選択の移行は、ウェブアプリケーションの要求が「単純なデータ保存」から「高度なデータ管理」へとシフトしていることを反映しています。開発者は、アプリケーションの規模やデータの複雑性、パフォーマンス要件などを総合的に評価し、より適切なストレージ技術を選択する能力が求められます。安易な選択は、将来的にパフォーマンスの問題や開発の困難さを招く可能性があるため、プロジェクトの初期段階での慎重な検討が重要です。

クライアントサイドストレージの未来とHTML5の役割

HTML5によってローカルストレージやIndexedDBといったクライアントサイドストレージの基盤が提供されたことは、ウェブの可能性を大きく広げました。これらの技術は、現代のウェブアプリケーション、特にPWA（Progressive Web Apps）やオフラインファーストの考え方を支える重要な柱となっています。そして、クライアントサイドストレージ技術は今もなお進化を続けています。

PWA (Progressive Web Apps) とオフラインファーストの考え方

PWAは、ウェブアプリケーションにネイティブアプリのような信頼性、高速性、エンゲージメントをもたらすことを目指す一連の技術と設計思想です。その核となる機能の一つがオフライン動作であり、これを実現するためにクライアントサイドストレージが不可欠です 2。Service Workerと連携したCache APIやIndexedDBが主に利用されますが、ローカルストレージもユーザー設定や小規模なデータの永続化に補助的に活用されます。

オフラインファーストという設計アプローチでは、アプリケーションはまずローカルに保存されたデータ（キャッシュやストレージ）からコンテンツや機能を提供し、ネットワーク接続が利用可能な場合にバックグラウンドでサーバーとデータを同期します。これにより、不安定なネットワーク環境やオフライン状態でもユーザーがアプリケーションを利用し続けることができ、より安定したユーザーエクスペリエンスを提供できます。

新しいAPI (File System Access APIなど) の動向

クライアントサイドストレージの進化は止まらず、より高度な機能を提供する新しいAPIも登場しています。その代表例が File System Access API（旧称 Native File System API）です。このAPIは、ユーザーの明示的な許可を得た上で、ウェブアプリケーションがユーザーのローカルファイルシステム上のファイルやディレクトリに対して直接読み書き操作を行うことを可能にします 28。

これは、従来のブラウザサンドボックス内のストレージ（ローカルストレージやIndexedDB）とは一線を画すものです。例えば、画像編集アプリケーションがローカルの画像ファイルを開いて編集し、保存する、あるいはテキストエディタやIDE（統合開発環境）のようなウェブアプリケーションがプロジェクトファイルを直接扱えるようになるといった、よりデスクトップアプリケーションに近い機能を実現できます。もちろん、セキュリティとプライバシーへの配慮から、ユーザーによる厳格な許可管理が前提となります。

WebAssembly (Wasm) との連携

WebAssemblyは、C++やRustといった高性能言語で書かれたコードを、ウェブブラウザ上でネイティブに近い速度で実行可能にする技術です。これにより、クライアントサイドで従来は難しかった複雑な計算処理、データ分析、ゲームロジックなどが実現可能になります。

WebAssemblyで処理された結果や、処理に必要な大規模なデータセットを効率的にクライアントサイドストレージ（特にIndexedDBやFile System Access API）に保存・活用するケースが増えることが予想されます。例えば、クライアントサイドで機械学習モデルを実行し、その学習済みモデルやユーザーデータをローカルに保存するといった応用が考えられます。

プライバシーとセキュリティの継続的な課題

クライアントサイドストレージ技術が進化し、扱えるデータの種類や量が増えるにつれて、ユーザーデータのプライバシー保護とセキュリティ確保の重要性はますます高まっています 29。ブラウザベンダーは、トラッキング防止技術の強化（例: Intelligent Tracking Prevention）、サードパーティCookieの制限、ストレージアクセスの権限管理の厳格化など、プライバシー保護のための取り組みを継続的に進めています。開発者側も、保存するデータの種類を最小限に留め、適切なセキュリティ対策を講じることが常に求められます。

HTML5の役割の再評価

HTML5は、ローカルストレージ、セッションストレージ、IndexedDBといったクライアントサイドストレージの標準仕様を導入することで、ウェブのあり方を大きく変革しました。これらの技術は、ウェブを単なる「ドキュメントを閲覧するためのプラットフォーム」から、複雑な処理やデータ管理が可能な「アプリケーション実行環境」へと進化させる上で、決定的な役割を果たしました。今日のリッチなウェブアプリケーションやPWAの多くは、HTML5が提供したこれらのストレージ基盤の上に成り立っています。

クライアントサイドストレージ技術の進化は、ウェブがOSに近い機能を持つ汎用的なアプリケーションプラットフォームへと変貌していく大きな流れの一部です。HTML5はその転換点における重要なマイルストーンであり、その遺産は今後もウェブの発展を支え続けるでしょう。一方で、ストレージ技術の多様化は、開発者にとって選択肢が増えるというメリットがある反面、各技術の特性、パフォーマンスへの影響、セキュリティ上の考慮事項を深く理解し、プロジェクトの要件に応じて適切に使い分けるための知識とスキルが一層求められるようになることを意味しています。

まとめ：ローカルストレージを賢く活用するために

本記事では、HTML5で導入された画期的なクライアントサイドストレージ技術であるローカルストレージについて、その基本概念から登場背景、Cookieやセッションストレージとの比較、具体的な使い方、メリット・デメリット、セキュリティ対策、そして代替技術や将来展望に至るまで、詳細に解説してきました。

ローカルストレージは、ユーザーのブラウザに手軽にデータを永続化できる便利な仕組みであり、適切に利用することでウェブアプリケーションのユーザーエクスペリエンスを大幅に向上させることができます。しかし、その特性を正しく理解することが極めて重要です。

ローカルストレージ活用の要点:

  • 特性の理解: ローカルストレージは、約5MB～10MBの容量を持ち、データはオリジン単位で永続的に保存されます。APIはシンプルですが同期的（ブロッキング）であり、文字列データのみを扱います。
  • 適切な利用シーン:
  • ユーザーインターフェースの設定（テーマ、言語など）の保存。
  • 頻繁にアクセスするが更新頻度の低いデータの小規模なキャッシュ。
  • オフライン機能の補助的なデータ保存（例: TODOリストのアイテム）。
  • 入力フォームの一時的な下書き保存。
  • 避けるべき利用シーン:
  • パスワード、クレジットカード情報、個人識別情報などの機密情報の保存。これらはXSS攻撃により容易に窃取されるリスクがあります。
  • 大量のデータ（数十MB以上）の頻繁な読み書き。同期APIであるため、パフォーマンス低下を招きます。
  • 複雑なクエリやリレーショナルなデータ管理が必要な場合。
  • セキュリティ対策の徹底:
  • XSS脆弱性対策（入力サニタイズ、出力エスケープ、CSP導入）は必須です。
  • ローカルストレージに保存するデータは信頼できないものとして扱い、常に検証を行うべきです。
  • 機密性の高い操作には、HttpOnly属性を持つCookieなど、より適切な技術を検討してください。
  • 代替技術の検討: 大量データや複雑なデータ構造、非同期処理が求められる場合は、IndexedDBのようなより高機能なストレージ技術の利用を検討しましょう。

ウェブ技術は絶えず進化しており、ローカルストレージもそのエコシステムの一部です。そのメリットを最大限に活かしつつ、デメリットやセキュリティリスクを最小限に抑えるためには、常に最新の情報をキャッチアップし、アプリケーションの要件に応じて最適な技術を選択する洞察力が求められます。ローカルストレージを賢く、そして安全に活用することで、より堅牢で使いやすいウェブアプリケーションの開発に繋がるでしょう。

参考文献

  • Mozilla Developer Network (MDN). Web Storage API. 3
  • Mozilla Developer Network (MDN). Window: localStorage property. 3
  • W3C. (2009, April 23). Web Storage (W3C Working Draft). 9
  • WHATWG. HTML Living Standard — Web storage. 10
  • Wikipedia. Web storage. 10
  • OWASP. HTML5 Security Cheat Sheet – Local Storage. 14
  • Logitec. ローカルストレージとは？言葉の意味やデバイスごとの確認方法を解説. 31
  • note.com (broccolinlin). ローカルストレージ・セッションストレージ・Cookieの違いまとめ. 12
  • Qiita (GS-AI). ブラウザのStorage機能についてまとめてみた(LocalStorage, SessionStorage, Cookies, IndexedDB). 6
  • DT NAVI. ローカルストレージとは？基本概念から使い方まで徹底解説. 1
  • リステップ. Cookieに変わる後継技術、localStorageを試してみたらいい感じだった件. 5
  • OPEN TONE Labs. 【HTML5】Web Storageを掘り下げてみよう. 4
  • とほほのWWW入門. Web Storage – HTML5. 8
  • 株式会社グローバルゲート. ブラウザにデータを保存する「localStrage」の使い方と実際の使用例. 7
  • RxDB. Using localStorage in Modern Applications – A Comprehensive Guide. 15
  • TinyMCE. JavaScript and localStorage in a nutshell with examples. 13
  • Wallarm. A7：Cross-Site Scripting (XSS). 18
  • WEBデザインMATOME. ローカルストレージとセッションストレージ. 16
  • Fleekdriveブログ. 社内で使うストレージにはどんな種類がある？. 32
  • Zenn (kthatoto). ブラウザストレージ(localStorageとIndexedDB)のパフォーマンスを比較する. 25
  • Qiita (tanimoto-hikari). いつもlocalStorage使ってたけど、IndexedDBを使ってみる. 24
  • IM-DMP. Cookieとローカルストレージの戦略的活用：効果的なユーザーデータ管理術. 29
  • Chrome Developers Blog. Web SQL のサポート終了と今後の対応について. 26
  • TechRacho. localStorageの意外な落とし穴. 17
  • GitHub (sushinpv/react-secure-storage). react-secure-storage. 22
  • GitHub (Mike96Angelo/Secure-Storage). Secure-Storage. 23
  • Portnox. What is Cross-Site Scripting (XSS)? 21
  • WorkOS Blog. How to store JWTs: Best practices for secure JWT storage. 19
  • 情報処理学会. Webブラウザにおけるオフラインストレージ技術の動向と課題. 27 (Web SQLの議論に関する言及)

引用文献

  1. JavaScriptでローカルストレージを使いこなす方法 – デジタルトレンドナビ, 6月 4, 2025にアクセス、 https://dtnavi.tcdigital.jp/cat_system/language_156/
  2. HTML5の「できること」完全ガイド｜進化したWeb技術を徹底解説 – ファーストクリエイト, 6月 4, 2025にアクセス、 https://first-create.com/html5/
  3. クライアント側ストレージ – ウェブ開発の学習 | MDN, 6月 4, 2025にアクセス、 https://developer.mozilla.org/ja/docs/Learn_web_development/Extensions/Client-side_APIs/Client-side_storage
  4. 【HTML5】Web Storageを掘り下げてみよう – OPEN TONE Labs, 6月 4, 2025にアクセス、 https://www.opentone.co.jp/ot-lab/all/web-system/%E3%80%90html5%E3%80%91web-storage%E3%82%92%E6%8E%98%E3%82%8A%E4%B8%8B%E3%81%92%E3%81%A6%E3%81%BF%E3%82%88%E3%81%86
  5. Cookieに変わる後継技術、localStorageを試してみたらいい感じだった件::ブログ, 6月 4, 2025にアクセス、 https://restep.jp/blogs/cookie-localstorage/
  6. ブラウザのStorage機能の種類とそれぞれの特徴 #ブラウザ – Qiita, 6月 4, 2025にアクセス、 https://qiita.com/GS-AI/items/f477d232ad9c93e82f57
  7. ブラウザにデータを保存する「localStrage」の使い方と実際の使用例 – 株式会社グローバルゲート, 6月 4, 2025にアクセス、 https://www.globalgate.co.jp/blog/how-to-use-localstrage
  8. Web Storage – HTML5 – とほほのＷＷＷ入門, 6月 4, 2025にアクセス、 https://www.tohoho-web.com/html5/web_storage.html
  9. Web Storage – W3C, 6月 4, 2025にアクセス、 https://www.w3.org/TR/2009/WD-webstorage-20090423/
  10. Web storage – Wikipedia, 6月 4, 2025にアクセス、 https://en.wikipedia.org/wiki/Web_storage
  11. Window: localStorage property – Web APIs | MDN, 6月 4, 2025にアクセス、 https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
  12. ウェブサイト制作におけるローカルストレージ、セッション … – note, 6月 4, 2025にアクセス、 https://note.com/broccolinlin/n/ne8639d91d2ed
  13. JavaScript and localStorage in a nutshell with examples – TinyMCE, 6月 4, 2025にアクセス、 https://www.tiny.cloud/blog/javascript-localstorage/
  14. HTML5 Security – OWASP Cheat Sheet Series, 6月 4, 2025にアクセス、 https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html
  15. Using localStorage in Modern Applications – A Comprehensive …, 6月 4, 2025にアクセス、 https://rxdb.info/articles/localstorage.html
  16. ローカルストレージとセッションストレージ | WEBデザインMATOME, 6月 4, 2025にアクセス、 https://teach.web-represent.link/local-storage-vs-session-storage/
  17. HTML5のLocal Storageを使ってはいけない（翻訳） – TechRacho – BPS株式会社, 6月 4, 2025にアクセス、 https://techracho.bpsinc.jp/hachi8833/2024_04_05/80851
  18. A7：Cross-Site Scripting (XSS) – Top 10 OWASP 2022 – Wallarm, 6月 4, 2025にアクセス、 https://www.wallarm.com/jp/what/a7-cross-site-scripting-xss-2017-owasp
  19. JWT storage 101: How to keep your tokens secure – WorkOS, 6月 4, 2025にアクセス、 https://workos.com/blog/secure-jwt-storage
  20. M2: Insecure Data Storage | OWASP Foundation, 6月 4, 2025にアクセス、 https://owasp.org/www-project-mobile-top-10/2014-risks/m2-insecure-data-storage
  21. What is Cross-Site Scripting? – Portnox, 6月 4, 2025にアクセス、 https://www.portnox.com/cybersecurity-101/what-is-cross-site-scripting/
  22. sushinpv/react-secure-storage: This is a wrapper written above local storage to write the data securely to local storage – GitHub, 6月 4, 2025にアクセス、 https://github.com/sushinpv/react-secure-storage
  23. Mike96Angelo/Secure-Storage: A simple wrapper for localStorage/sessionStorage that allows one to encrypt/decrypt the data being stored. – GitHub, 6月 4, 2025にアクセス、 https://github.com/Mike96Angelo/Secure-Storage
  24. いつもlocalStorage使ってたけど、IndexedDBを使ってみる（データベースの作成と情報の取得編）, 6月 4, 2025にアクセス、 https://qiita.com/tanimoto-hikari/items/5fd81962153531e8275e
  25. ブラウザストレージ(localStorageとIndexedDB)のパフォーマンスを比較する – Zenn, 6月 4, 2025にアクセス、 https://zenn.dev/kthatoto/articles/ccdb4387b42ba1
  26. Web SQL の非推奨化と削除 | Blog – Chrome for Developers, 6月 4, 2025にアクセス、 https://developer.chrome.com/blog/deprecating-web-sql?hl=ja
  27. ソフトウェアの高い互換性と長い持続性を目指すPOSIX中心主義プログラミング – 情報処理学会, 6月 4, 2025にアクセス、 https://www.ipsj.or.jp/dp/contents/publication/32/S0804-R1601.html
  28. Webシステムにおける情報保存メカニズム #cookie – Qiita, 6月 4, 2025にアクセス、 https://qiita.com/masterpiecehack/items/d5b6df89cd9adc9bf0d3
  29. Cookieとローカルストレージの戦略的活用：効果的なユーザーデータ管理術 – IM-DMP, 6月 4, 2025にアクセス、 https://dmp.intimatemerger.com/media/posts/14205/cookie%E3%81%A8%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%81%AE%E6%88%A6%E7%95%A5%E7%9A%84%E6%B4%BB%E7%94%A8%EF%BC%9A%E5%8A%B9%E6%9E%9C%E7%9A%84%E3%81%AA/
  30. ウェブストレージ API – Web API | MDN, 6月 4, 2025にアクセス、 https://developer.mozilla.org/ja/docs/Web/API/Web_Storage_API
  31. ローカルストレージとは？言葉の意味やデバイスごとの確認方法を解説 – ロジテックダイレクト, 6月 4, 2025にアクセス、 https://www.pro.logitec.co.jp/column/a20210903.html
  32. 社内で使うストレージにはどんな種類がある？ – Fleekdrive, 6月 4, 2025にアクセス、 https://www.fleekdrive.com/blog/archive/filemanagement23/
テクノロジー
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

関連記事

目次