リフレッシュとは｜F5・リフレッシュレート・トークンの意味を場面別に実測

この記事で実際に動かしたもの：127.0.0.1 の 8713 番に立てた自作の Web サーバーと Chromium 153（初回表示・通常の再読み込み・強制再読み込み・キャッシュ消去・フォーム送信後の再読み込み・meta refresh・Refresh ヘッダー・requestAnimationFrame の回数）、8714 番に立てた自作の認証サーバー（アクセストークンとリフレッシュトークンの発行・期限切れ・取り直し・ログアウト）、作業用に起動した PostgreSQL 16 のマテリアライズドビュー（100万行の集計と REFRESH）です。

「リフレッシュ」は、休日の過ごし方の話にも、パソコンの画面の話にも、ログインの仕組みの話にも出てくる言葉です。困りごとの多くは、いま読んでいる文章がどの「リフレッシュ」の話なのかを取り違えるところから始まります。最初に全体の地図を示します。

flowchart LR
    A[リフレッシュ<br>新しくし直す] --> B[ブラウザー<br>ページの再読み込み]
    A --> C[画面<br>1秒に何回書き換えるか]
    A --> D[ログイン<br>トークンの取り直し]
    A --> E[データベース<br>集計結果の作り直し]
    A --> F[メモリ<br>記憶の書き直し]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、Python 3.13.18 の http.server で作った自作の Web サーバーを 127.0.0.1 の 8713 番で起動し、HTML（Cache-Control: no-cache と ETag 付き）・CSS（max-age=3600）・JavaScript（Cache-Control なし・Last-Modified のみ）・SVG 画像（max-age=3600）を返して、届いたリクエストの Cache-Control・Pragma・If-None-Match・If-Modified-Since と応答コードをすべて記録しました。ブラウザーは Chromium 153.0.8010.12（Chrome for Testing）を playwright 1.63.0 から作業用のプロファイルで動かし、通常の再読み込みは page.reload() と location.reload()、強制再読み込みは開発者ツールの通信路（Chrome DevTools Protocol）の Page.reload に ignoreCache: true を付けて起こしました。ページの読み込み方は performance.getEntriesByType('navigation') の type で確かめています。リフレッシュトークンは、標準ライブラリだけで書いた自作の認証サーバー（8714番。アクセストークンの有効期限3秒、リフレッシュトークン60秒）と Python のクライアントで確かめました。マテリアライズドビューは PostgreSQL 16.15 を作業用のフォルダーに initdb して 127.0.0.1 だけで起動し、100万行の表で確かめたあとデータベースを削除しています。キーボードのショートカットとスマホの操作は、Google・Mozilla・MDN の公式の説明で確かめました。外部のサービスには接続していません。図は mermaid-cli 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

リフレッシュとは（場面別の意味：ふだんの意味とITの意味）

この節では、「リフレッシュ」という言葉が、ふだんの言葉と IT の各分野でそれぞれ何を指すのかが分かります。

リフレッシュは英語の refresh で、re（再び）と fresh（新鮮な）を組み合わせた言葉です。もとの意味は「新鮮な状態に戻す・元気を取り戻させる」です。日本語のふだんの会話では「気分転換して元気を取り戻す」の意味でよく使い、「リフレッシュ休暇」（勤続年数の節目などに取る休暇）のような言い方もあります。IT の言葉としてのリフレッシュも、どれも「中身を最新・元の状態にし直す」という意味から来ています。違うのは、何をし直すかです。

ふだんの言葉としての「リフレッシュ」には似た言葉がいくつかあります。リラックスは緊張をほどいて落ち着くこと（動きが少ない）、気分転換は気持ちを切り替えること、息抜きは短い休み、リフレッシュは動いてでも元気を取り戻すこと、という違いで使い分けられます。例文では「週末に山を歩いてリフレッシュした」「コーヒーを飲んで頭をリフレッシュする」のように使います。

以下では、検索されることの多いブラウザー・画面・トークン・データベースを中心に、実際に動かした結果で説明します。

ブラウザーのリフレッシュ（再読み込み・F5）とは

この節では、ブラウザーで「リフレッシュする」と言われたときに何をすればよいかと、OS・ブラウザーごとの操作が分かります。

ブラウザーのリフレッシュは、いま表示しているページをサーバーから読み込み直すことです。「リロード」「更新」「再読み込み」も同じ意味で使われます。サーバー側の内容が変わったときに最新の表示にする、表示が崩れたときにやり直す、といった目的で使います。

操作は、公式の一覧で確かめた範囲では次のとおりです。

ページの中からも再読み込みは起こせます。JavaScript の location.reload()、HTML の <meta http-equiv="refresh">、HTTP の Refresh ヘッダーの3つです。手元で確かめたところ、どれもページの読み込み方（performance.getEntriesByType('navigation')[0].type）が reload になりました。アドレスバーで同じ URL を開き直したときや、リンクで同じページに移ったときは navigate で、再読み込みとは別の扱いです。

通常の再読み込みと強制再読み込みの違い（Chromiumで実測）

この節では、F5（通常の再読み込み）と Ctrl+Shift+R（強制再読み込み）で、サーバーに届くリクエストが実際にどう違うかが分かります。

通常の再読み込みは「HTML だけをサーバーに確かめ、期限内の CSS・JS・画像は手元のキャッシュを使う」、強制再読み込みは「キャッシュを使わず、全部をサーバーから取り直す」です。自作のサーバーに4つのファイル（HTML・CSS・JS・SVG）を置き、Chromium で読み込み方を変えて、サーバーに届いたリクエストを記録しました。

通常の再読み込みでサーバーに届いたのは HTML の1本だけでした。その1本には Cache-Control: max-age=0 と If-None-Match（手元にある版の目印）が付いていて、サーバーは「変わっていない」という意味の 304 を返しています。CSS（max-age=3600）と SVG（max-age=3600）は期限内なので、そもそもサーバーに問い合わせが来ません。Cache-Control の無い JavaScript も届きませんでした。Last-Modified が3日前なので、ブラウザーが「しばらくは新しいとみなしてよい」と推定したためです（ヒューリスティックなキャッシュ）。

### 4 page.reload()(通常の再読み込み) navtype=reload
 server: [{"p":"/","code":304,"cc":"max-age=0","pragma":"","inm":"INM"}]

### 8 CDP Page.reload ignoreCache(強制再読み込み) navtype=reload
 server: [{"p":"/","code":200,"cc":"no-cache","pragma":"no-cache","inm":""},
          {"p":"/style.css","code":200,"cc":"no-cache","pragma":"no-cache","inm":""},
          {"p":"/logo.svg","code":200,"cc":"no-cache","pragma":"no-cache","inm":""},
          {"p":"/app.js","code":200,"cc":"no-cache","pragma":"no-cache","inm":""}]

強制再読み込みでは、4本すべてに Cache-Control: no-cache と Pragma: no-cache が付き、If-None-Match も付かないので、サーバーは全部を 200 で返し直しました。「F5 で直らないのに Ctrl+Shift+R で直る」のは、この差があるからです。

3つめの数字は、自動操作のつまずきとして記録しておきます。Playwright の page.keyboard.press('F5') と press('Control+Shift+R') をそれぞれ送っても、サーバーには1本も届きませんでした。自動操作のキー入力はページの中に届くだけで、ブラウザー本体のショートカットとしては働かなかったためです。テストで再読み込みを起こすときは、page.reload() や location.reload() を使います。

サーバー側でキャッシュの期限をどう書くか（no-cache と no-store の違いなど）は、関連記事「Cache-Control no-cacheとno-storeの違い｜実測表つき」で扱っています。この記事では「リフレッシュの操作ごとに何が起きるか」に絞ります。

再読み込みしても変更が反映されないとき（CSSの実測と直し方）

この節では、Web サイトを更新したのにリフレッシュしても見た目が変わらない理由と、作る側・見る側それぞれの直し方が分かります。

原因はほとんどの場合、CSS や JS が手元のキャッシュから出ていることです。手元のサーバーで、ページを一度表示したあとに CSS の文字色を赤から青に書き換え、読み込み方を変えて文字色を getComputedStyle で読み取りました。

初回 色 rgb(204, 51, 51)
CSS変更後 通常の再読み込み 色 rgb(204, 51, 51) [ 'GET / 304' ]
強制再読み込み 色 rgb(0, 0, 170) [ 'GET / 200', 'GET /style.css 200', 'GET /logo.svg 200', 'GET /app.js 200' ]
その後の通常の再読み込み 色 rgb(0, 0, 170) [ 'GET / 304' ]

CSS を書き換えたあとに通常の再読み込みをしても、文字は赤（rgb(204, 51, 51)）のままでした。サーバーに届いたのは HTML の1本だけで、CSS は問い合わせすらされていません。強制再読み込みをすると青（rgb(0, 0, 170)）に変わり、その後は通常の再読み込みでも青のままです。強制再読み込みで、手元のキャッシュが新しい版に入れ替わったためです。

なお、HTML 自体が変わっていないのに表示が変わらない場合は、サーバーの前にある CDN やプロキシのキャッシュが原因のこともあります。この場合はブラウザーのリフレッシュでは直らず、CDN 側のキャッシュ削除（パージ）が要ります。

フォーム送信後のリフレッシュと自動リフレッシュ（meta refresh・Refreshヘッダー）

この節では、フォームを送ったあとにリフレッシュすると何が起きるかと、ページを自動でリフレッシュする仕組みの動きが分かります。

POST で送ったあとのページを再読み込みすると、同じ内容がもう一度サーバーに送られます。手元で、フォームを POST で送った直後に page.reload() を行ったところ、サーバーには POST が2回届きました。自動操作の環境では確認の表示も出ず、そのまま再送されています。

POST後の再読み込み server [ 'POST /post 200', 'POST /post 200' ]

PRG: 送信→再読み込み2回 [ 'POST /prg 303', 'GET /done 200', 'GET /done 200', 'GET /done 200' ]

注文や登録のフォームでこれが起きると、同じ注文が2回入る原因になります。作る側の定番の対策は、POST を受けたら 303 See Other で完了ページへ移らせる PRG（Post/Redirect/Get）です。手元でも、POST に 303 を返して /done に移らせると、そのあと2回再読み込みしても届くのは GET /done だけで、POST は1回で済みました。

ページを自動でリフレッシュする方法には、HTML の <meta http-equiv="refresh" content="2"> と、HTTP の Refresh: 2 ヘッダーがあります。MDN では、この2つは同等の機能と説明されています。手元で両方を試し、サーバーに届いた時刻の差を測りました。

どちらも約2秒ごとに繰り返し読み込まれ、2回目以降は通常の再読み込みと同じ Cache-Control: max-age=0 が付いていました。自動リフレッシュは、読んでいる途中や入力の途中で画面が変わってしまうため、使う場合は止める手段を用意します。株価や在庫のように中身だけを更新したい画面では、ページ全体をリフレッシュせず、JavaScript で必要なデータだけを取り直す方法が向いています。

リフレッシュレートとは（Hz・fpsとの違い）

この節では、モニターやスマホの「リフレッシュレート」の意味と、fps（フレームレート）との違い、Web ページの動きとの関係が分かります。

リフレッシュレートは、画面が1秒間に表示を書き換える回数で、単位は Hz（ヘルツ）です。60Hz なら1秒に60回、約16.7ミリ秒ごとに書き換わります。数字が大きいほど、スクロールやゲームの動きがなめらかに見えます。

よく混同されるのが fps（フレームレート）です。リフレッシュレートは「画面（モニター）が書き換える回数」、fps は「パソコンやゲーム機が1秒に作る絵の枚数」です。144Hz のモニターでも、パソコンが1秒に60枚しか作れなければ、見える動きは60枚分です。逆に、パソコンが200枚作っても、60Hz の画面では1秒に60回しか表示されません。

Web ページの動きも、リフレッシュレートに合わせて動きます。ブラウザーの requestAnimationFrame は「次に画面を書き換える直前」に呼ばれる仕組みで、手元の Chromium（画面のない動かし方。仮想の画面は60Hz）で3秒間数えると、次のとおりでした。

rAF { frames: 182, ms: 3017, median: '16.70' } 60.3 fps

1回あたりの間隔の中央値は16.70ミリ秒で、60Hz の書き換え間隔とほぼ一致しました。アニメーションを setInterval(fn, 16) で作ると画面の書き換えとずれることがあるため、動きは requestAnimationFrame か CSS のアニメーションで作るのが基本です。モニターのリフレッシュレートの設定場所は OS やメーカーごとに違うため、各メーカーの説明書で確かめます。

リフレッシュトークンとは（アクセストークンとの違い）

この節では、ログインの仕組みに出てくる「リフレッシュトークン」が何のためにあり、アクセストークンと何が違うのかが分かります。

リフレッシュトークンは、有効期限が切れたアクセストークンを、ログインし直さずに取り直すための券です。OAuth 2.0 の仕様（RFC 6749）では「アクセストークンを得るために使う資格情報」と定義され、発行するかどうかは認可サーバーが決める、リソースサーバー（API）には送らない、とされています。

flowchart TB
    L[ログイン] --> T[アクセストークン<br>短い期限]
    L --> R[リフレッシュトークン<br>長い期限]
    T --> API[APIを呼ぶ]
    API -->|期限切れ 401| X[認可サーバーに<br>リフレッシュトークン]
    R --> X
    X --> T2[新しい<br>アクセストークン]
    T2 --> API

期限を2つに分けるのは、毎回 API に付けて持ち歩くアクセストークンを短命にしつつ、利用者に何度もログインさせないためです。OAuth 2.0 と OpenID Connect の全体像は、関連記事「OAuth 2.0とOpenID Connectの違いをわかりやすく解説」で扱っています。

リフレッシュトークンの流れを自作サーバーで動かす

この節では、アクセストークンの期限切れからリフレッシュ、ログアウトまでの流れが、実際の応答の原文で分かります。

自作の認証サーバーは、アクセストークン（署名付きの JWT。有効期限3秒）とリフレッシュトークン（ランダムな文字列。サーバー側で記録し、一度使うと使えなくなる）を発行します。実験のために期限をとても短くしています。クライアントから順に呼んだ結果がこちらです。

  0.0s 1 ログイン               200 {"access_token": "eyJhbGciOiJIUzI1NiIsInR5…", "token_type": "Bearer", "expires_in": 3, "refresh_token": "-CBHPsgMnejyvEnjRf68OtJk…"}
   access_token 145 文字 / refresh_token 43 文字
  0.0s 2 APIを呼ぶ              200 {"user": "demo", "exp_in": 2.6}
  3.5s 3 3.5秒後にAPI           401 {"error": "invalid_token", "error_description": "The access token expired"}  WWW-Authenticate: Bearer error="invalid_token", error_description="The access token expired"
  3.5s 4 リフレッシュ             200 {"access_token": "eyJhbGciOiJIUzI1NiIsInR5…", "token_type": "Bearer", "expires_in": 3, "refresh_token": "35FNkDWYNG6gta1R6fS7Wn3g…"}
  3.5s 5 新しい券でAPI          200 {"user": "demo", "exp_in": 2.1}
  3.5s 6 使用済みの券でリフレッシュ   400 {"error": "invalid_grant", "error_description": "refresh token already used"}
  3.5s 7 ログアウト              200 {"ok": true}
  3.5s 8 ログアウト直後にAPI       200 {"user": "demo", "exp_in": 2.1}
  3.5s 9 ログアウト後にリフレッシュ   400 {"error": "invalid_grant", "error_description": "unknown refresh token"}
  6.7s 10 さらに3秒後にAPI        401 {"error": "invalid_token", "error_description": "The access token expired"}

リフレッシュの要求は、OAuth 2.0 の形どおり grant_type=refresh_token と refresh_token=… をフォームの形で送っています。読み取れることは4つです。

4つめは、ログアウトの設計で必ず出てくる点です。署名付きのアクセストークンは API のサーバーが署名と期限だけで確かめるため、ログアウトでリフレッシュトークンを消しても、すでに渡したアクセストークンは期限まで通ります。ログアウト時の無効化の考え方は、関連記事「JWTでログアウトを実装する方法｜トークン無効化の考え方」で扱っています。

もう1つ、作る側がつまずきやすいのが「同時にリフレッシュしてしまう」問題です。画面を開いた直後に API を2本同時に呼び、両方が 401 になって、両方が同じリフレッシュトークンで取り直しに行くと、次のようになりました。

  3.2s 同時リフレッシュ1          200 {"access_token": "eyJhbGciOiJIUzI1NiIsInR5…", "token_type": "Bearer", "expires_in": 3, "refresh_token": "NVDLXC9G1xCV8jQ7JFVMWKTH…"}
  3.2s 同時リフレッシュ2          400 {"error": "invalid_grant", "error_description": "refresh token already used"}

1本目は成功し、2本目は「使用済み」で断られています。2本目の失敗を「ログインが切れた」と扱うと、利用者は突然ログイン画面に戻されます。クライアント側では、リフレッシュ中は1本だけに絞り、ほかの要求はその結果を待って新しいアクセストークンで呼び直す作りにします。

マテリアライズドビューのREFRESHとは（PostgreSQLで実測）

この節では、データベースで「リフレッシュ」と言われたときの意味と、REFRESH をしないと何が起きるかが分かります。

マテリアライズドビューは、集計などの SELECT の結果を表のように保存しておく仕組みで、REFRESH はその保存結果を元の表から作り直す命令です。元の表が変わっても、REFRESH するまで保存結果は変わりません。100万行の注文表から店ごとの件数と売上合計を集計し、確かめました。

CREATE MATERIALIZED VIEW shop_sales AS
  SELECT shop, count(*) AS n, sum(amount) AS total FROM orders GROUP BY shop;

-- 店1に5万円の注文を1件追加
INSERT INTO orders(shop,amount,created) VALUES (1,50000,'2026-10-29');
SELECT shop,n,total FROM shop_sales WHERE shop=1;   -- まだ変わらない
REFRESH MATERIALIZED VIEW shop_sales;
SELECT shop,n,total FROM shop_sales WHERE shop=1;   -- 変わる

 shop |   n   |   total            ← INSERT の後、REFRESH の前
------+-------+-----------
    1 | 55953 | 306502491

REFRESH MATERIALIZED VIEW
Time: 259.699 ms

 shop |   n   |   total            ← REFRESH の後
------+-------+-----------
    1 | 55954 | 306552491

読むのは約300倍速くなる代わりに、REFRESH するまで値が作った時点のままになる、というのがマテリアライズドビューの性質です。REFRESH の途中も読み取りを止めたくないときは CONCURRENTLY を付けますが、一意インデックスが無いと次のエラーになりました。

ERROR:  cannot refresh materialized view "public.shop_sales" concurrently
HINT:  Create a unique index with no WHERE clause on one or more columns of the materialized view.

CREATE UNIQUE INDEX ON shop_sales(shop); を作ると通りました。また、WITH NO DATA で作っただけのマテリアライズドビューを読むと ERROR: materialized view "empty_mv" has not been populated（ヒントは Use the REFRESH MATERIALIZED VIEW command.）になります。普通のビューとの違いや、REFRESH の頻度の決め方は、関連記事「SQLビューとマテリアライズドビュー｜違い・REFRESH・使い分け」で扱っています。

DRAMのリフレッシュ・ソフトウェアのリフレッシュ・その他の「リフレッシュ」

この節では、メモリ（DRAM）のリフレッシュや、ソフトウェア・機器・開発ツールで使われる「リフレッシュ」の意味が分かります。

DRAM のリフレッシュは、記憶が消える前に、決まった間隔で中身を読み出して書き直す動作です。DRAM は小さなコンデンサーにためた電荷で 0 と 1 を記憶しますが、電荷は時間とともに自然に抜けていきます。そこで、メモリの制御回路がミリ秒単位の決まった間隔で全体を書き直します。この間はその部分を読み書きできないため、性能にも少し影響します。SRAM はリフレッシュが要らない点が DRAM との違いで、基本情報技術者試験などでもよく問われます。

ソフトウェアや機器では、次のような使い方があります。

Terraform の公式ドキュメントでは、terraform refresh は確認なしで state に反映してしまうため非推奨とされ、確認の画面が出る terraform apply -refresh-only が勧められています。同じ「リフレッシュ」でも、表示を変えるだけのものと、記録を書き換えるものがある点に注意が要ります。

「リフレッシュ」の言い換えと使い分け（リロード・更新・リセット・再起動）

この節では、仕様書や手順書で「リフレッシュ」と書くときに、どの言葉に言い換えると誤解が少ないかが分かります。

「リフレッシュ」は意味が広いため、手順書では何をし直すのかが分かる言葉に言い換えると、読み違いが減ります。

例えば問い合わせ対応で「画面をリフレッシュしてみてください」と伝えると、相手によって再読み込み・ログアウト・再起動と受け取り方が分かれます。キーの名前（F5）や、何が消えるかまで書くと、やり直しの往復が減ります。

リフレッシュでよくあるエラーとつまずき（原文つき）

この節では、場面ごとに「リフレッシュ」で出るエラーと、つまずきの原因・直し方が分かります。

ブラウザーで不具合を調べるときは、開発者ツールの Network タブで「どのファイルがキャッシュから出たか」を見ると、リフレッシュで直るかどうかの見当がつきます。開発者ツールの使い方は、関連記事「Chrome DevToolsの使い方｜デバッグ手順と便利機能一覧」で扱っています。

判断表：どの「リフレッシュ」かを見分ける

この節では、文章やエラーの中の「リフレッシュ」がどの意味かを、手がかりの言葉から判断する方法が分かります。

1. 1F5・ページ・キャッシュ・表示と一緒に出る → ブラウザーの再読み込み「リフレッシュしても変わらない」「ページをリフレッシュ」
2. 2Hz・モニター・fps と一緒に出る → リフレッシュレート「144Hz のリフレッシュレート」「可変リフレッシュレート」
3. 3トークン・401・認証・OAuth と一緒に出る → リフレッシュトークンrefresh_token・grant_type=refresh_token
4. 4SQL・マテビュー・集計と一緒に出る → REFRESH MATERIALIZED VIEW「夜間にマテビューをリフレッシュ」
5. 5DRAM・メモリ・半導体と一緒に出る → メモリのリフレッシュ動作「リフレッシュが必要なのは DRAM、不要なのは SRAM」
6. 6人・休み・気分と一緒に出る → ふだんの意味「リフレッシュ休暇」「散歩でリフレッシュ」

作る側で「リフレッシュの仕組みをどう選ぶか」は、次の表が目安です。

• 1どの「リフレッシュ」の話かを先に決めるページ・画面・トークン・集計・メモリのどれか
• 2リフレッシュで何が取り直されるかを確かめるNetwork タブ・サーバーのログ・SQL の結果
• 3リフレッシュで消えるものを確かめる入力途中の内容・キャッシュ・使用済みのトークン
• 4手順書には操作の名前まで書く「F5 で再読み込み」「Ctrl+Shift+R で強制再読み込み」

よくある質問

Q. リフレッシュとリロードは同じ意味ですか？ A. ブラウザーの話では同じ意味です。どちらも表示中のページを読み込み直すことで、「更新」「再読み込み」とも呼ばれます。ただし「リフレッシュ」は画面・トークン・データベースなどにも使う広い言葉で、「リロード」はほぼページの再読み込みにしか使いません。

Q. F5 と Ctrl+F5（Ctrl+Shift+R）は何が違いますか？ A. F5 は手元のキャッシュを使い、HTML だけをサーバーに確かめます。Ctrl+Shift+R はキャッシュを無視して全部を取り直します。手元の計測では、F5 にあたる通常の再読み込みでサーバーに届いたのは4本中1本、強制再読み込みでは4本全部でした。Ctrl+F5 は Firefox の公式の一覧に載っている操作です。

Q. リフレッシュするとログイン状態は消えますか？ A. 通常の再読み込みでも強制再読み込みでも、Cookie は消えないため、多くのサイトではログインしたままです。消えるのは、入力途中のフォームの内容や、ページの中だけで持っていた状態です。キャッシュの削除で Cookie まで選ぶと、ログアウトされます。

Q. 何度リフレッシュしても画面が変わりません。 A. まず強制再読み込みを試します。それでも変わらない場合は、サーバーの前にある CDN のキャッシュ、サービスワーカーのキャッシュ、そもそもサーバー側の更新が終わっていない、のどれかを疑います。手元の実験では、CSS を変えたあと通常の再読み込みでは色が変わらず、強制再読み込みで変わりました。

Q. リフレッシュレートは高いほどよいですか？ A. 動きのなめらかさは上がりますが、パソコンやゲーム機がその枚数の絵を作れないと効果は出ません。また、高いリフレッシュレートは消費電力が増える傾向があるため、ノートパソコンやスマホでは用途で選びます。文章の作業が中心なら60Hz でも困ることは少ないです。

Q. リフレッシュトークンの有効期限はどれくらいにしますか？ A. 決まった値はなく、サービスの性質で決めます。アクセストークンは数分〜1時間、リフレッシュトークンは数日〜数週間とする例が多く見られます。重要な操作が多いサービスほど短めにし、ローテーション（使うたびに新しい券に替える）を組み合わせます。

Q. リフレッシュトークンはどこに保存しますか？ A. ブラウザーで動くアプリでは、JavaScript から読めない HttpOnly 属性付きの Cookie に入れる方法がよく使われます。スマホアプリでは OS が用意している安全な保存領域を使います。いずれも、アクセストークンより長く使える券なので、扱いはより慎重にします。

Q. マテリアライズドビューはどれくらいの頻度で REFRESH しますか？ A. 「どれだけ前の値まで許せるか」で決めます。前日までの集計でよければ夜間に1回、数分前まででよければ数分ごと、と決めます。手元の100万行では1回の REFRESH が約0.26秒でしたが、元の表が大きくなるほど時間が延びるため、実際のデータ量で測って決めます。

Q. 「画面をリフレッシュして」と言われたら何をすればよいですか？ A. Web のサービスなら、まず F5（Mac は再読み込みボタン）でページを再読み込みします。直らなければ Ctrl+Shift+R（Mac は ⌘+Shift+R）を試します。アプリの場合は、アプリ内の更新ボタンか、アプリの再起動を指していることが多いため、相手に確かめると確実です。

Q. リフレッシュ休暇は IT 用語ですか？ A. いいえ。リフレッシュ休暇は、勤続年数の節目などに心身を休めるために取る休暇で、ふだんの「リフレッシュ」の意味から来た言葉です。IT の「リフレッシュ」とは関係ありません。

まとめ

• リフレッシュは「新しくし直す・元の状態に戻す」という意味。IT では、ページの再読み込み・リフレッシュレート・リフレッシュトークン・マテリアライズドビューの REFRESH・DRAM のリフレッシュがよく出てくる。
• 通常の再読み込みは HTML だけをサーバーに確かめ、CSS・JS・画像は手元のキャッシュを使う。手元では4本中1本しか届かず、強制再読み込みでは4本全部が 200 で取り直された。
• CSS の変更が出ないのはキャッシュが原因のことが多い。見る側は強制再読み込み、作る側は URL に版を付ける。POST の後の再読み込みは再送になるため PRG で防ぐ。
• リフレッシュトークンは、期限切れのアクセストークンをログインし直さずに取り直す券。使用済みの券は invalid_grant で断られ、ログアウト後もアクセストークンは期限まで通った。
• マテリアライズドビューは REFRESH するまで値が変わらない。読むのは約300倍速くなった代わりに、CONCURRENTLY には一意インデックスが要った。

参考・出典

確認日はいずれも 2026年10月29日です。

• Google Chrome ヘルプ「Chrome のキーボード ショートカット」：https://support.google.com/chrome/answer/157179?hl=ja
• Mozilla サポート「キーボードショートカット - よく使う Firefox の操作を素早く行う」：https://support.mozilla.org/ja/kb/keyboard-shortcuts-perform-firefox-tasks-quickly
• Apple「Mac 用 Safari ユーザガイド」キーボードショートカット：https://support.apple.com/ja-jp/guide/safari/cpsh003/mac
• MDN「Refresh」（HTTP ヘッダー）：https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Refresh
• MDN「overscroll-behavior」：https://developer.mozilla.org/ja/docs/Web/CSS/overscroll-behavior
• MDN「Window: requestAnimationFrame() メソッド」：https://developer.mozilla.org/ja/docs/Web/API/Window/requestAnimationFrame
• IETF「RFC 6749 The OAuth 2.0 Authorization Framework」（1.5 Refresh Token・6 Refreshing an Access Token・5.2 Error Response）：https://www.rfc-editor.org/rfc/rfc6749
• IETF「RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage」（WWW-Authenticate の invalid_token）：https://www.rfc-editor.org/rfc/rfc6750
• PostgreSQL 16 文書「REFRESH MATERIALIZED VIEW」：https://www.postgresql.org/docs/16/sql-refreshmaterializedview.html
• HashiCorp「Command: refresh」（Terraform）：https://developer.hashicorp.com/terraform/cli/commands/refresh
• React Native「Fast Refresh」：https://reactnative.dev/docs/fast-refresh
• Microsoft サポート「Windows の回復オプション」：https://support.microsoft.com/ja-jp/windows/windows-の回復オプション-31ce2444-7de3-818c-d626-e3b5a3024da5
• IT用語辞典 e-Words「リフレッシュ」：https://e-words.jp/w/リフレッシュ.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。