ステートレスって何？わかりやすく解説

「さっき話したこと、もう一回説明しなきゃいけないの？」って思ったことない？友だちに「この前も言ったじゃん」って言えるのに、システムやサーバーは毎回「はじめまして」みたいな顔してくることがある。それって実は「ステートレス」っていう考え方が使われてるからなんだ。なんか難しそうな言葉だけど、実はめちゃくちゃ身近な話で、この記事を読めばちゃんとわかるよ。

いい質問！「ステートレス」は英語で書くと stateless、つまり「状態（ステート）を持たない」ってこと。コンピューターやサーバーが「前回のことを何も覚えていない」状態で動く仕組みのことだよ。コンビニのセルフレジを思い浮かべて。レジって、さっきあなたが何を買ったか覚えてないよね？毎回「いらっしゃいませ」ってゼロからスタートする。それがステートレスのイメージにすごく近いんだ。

あるよ！それを ステートフル（stateful） って言う。たとえば、ゲームのオンライン対戦。サーバーがずっと「今のHPは〇〇、今の位置はここ」って状態を覚え続けてるよね。あれがステートフルな仕組み。ステートレスとステートフル、この2つはセットで覚えておくとわかりやすいよ。

めちゃくちゃ使われてるよ！たとえばインターネットの通信（HTTP）はステートレスが基本。それに、アプリとサーバーがやり取りする REST API という仕組みもステートレスで設計されることが多い。メリットは「シンプルで、たくさんの人が同時に使っても壊れにくい」こと。サーバーが前の情報を覚えなくていい分、軽くてスケールしやすいんだ。

鋭い！実はあれ、サーバーが覚えてるんじゃなくて、毎回あなたのブラウザが「私はログイン済みです」という証明書（トークン や クッキー）を一緒に送ってるんだよ。サーバーは受け取るたびにその証明書を確認するだけ。「状態はブラウザ側が持って、毎回送ってくる」ってイメージ。だからサーバー自体はステートレスのままでいられるんだ。

もうちょっと詳しく

ステートレスという言葉が生まれた背景には、インターネットの設計思想がある。インターネットはもともと、世界中のたくさんのコンピューターが分散して通信できるように作られた。その中心にある HTTP という通信ルールは「1回のリクエストと1回のレスポンスで完結する」というシンプルな設計になっている。サーバーが全員の状態を覚え続けると、ユーザーが増えるほどメモリが圧迫されて重くなる。でもステートレスなら、どのサーバーが対応しても同じ結果を返せるから、サーバーを増やしてもスムーズに動く。これを「スケールしやすい」という。現代のクラウドサービスやWebアプリの多くがステートレス設計を採用しているのは、この「シンプルさと拡張性」が理由なんだ。

⚠️ よくある勘違い

[toc]

ステートレスとは？まず「状態」ってなんだろう

「状態」を覚えるってどういうこと？

まず「状態（ステート）」という言葉から整理しよう。プログラムやシステムの世界で「状態」というのは、つまり「今どういう状況か、前に何があったかという情報」のことだよ。

たとえば、ゲームのRPGを考えてみて。キャラクターのHP、持ってるアイテム、今どこのマップにいるか——これ全部が「状態」だよね。ゲームを中断してまた再開したとき、ちゃんとさっきの続きからできるのは、サーバーやセーブデータが「状態を保存してた」からなんだ。

人間同士の会話でも同じ。「この前話した件なんだけど」って言えるのは、お互いが「前に話した内容＝状態」を覚えてるからだよね。

「状態を持たない」ってどういう感じ？

ステートレスは逆に「状態を持たない」、つまり「前のことを何も覚えていない」ということ。毎回ゼロからスタートするイメージだ。

わかりやすい例が「自動販売機」。自販機に100円入れてジュースを買っても、次に100円入れたとき自販機は「さっきも来てくれたね」とは言わない。毎回「100円受け取りました、ボタン押してください」ってゼロから処理する。これがステートレスな動きそのもの。

もっと極端な例で言うと、コールセンターに電話したとき、毎回別の担当者につながって、前の会話内容が引き継がれてないとき「また最初から説明しなきゃ……」って思うよね。あの状態がシステム的には「ステートレス」ということになる。

HTTP通信はステートレスが基本——インターネットの仕組みを覗いてみよう

Webページを開くとき何が起きてる？

ブラウザでWebページを開くとき、裏側では「HTTP（HyperText Transfer Protocol）」つまり「インターネットでデータをやり取りするためのルール」が使われてる。このHTTPが、もともとステートレスな設計になってるんだ。

流れはこんな感じ：

• あなたのブラウザ → サーバーに「このページをください」とリクエストを送る
• サーバー → 「はい、どうぞ」とページのデータを返す（レスポンス）
• やり取り終了。サーバーはあなたのことをもう覚えていない

「1回リクエストして1回レスポンスをもらったら、それで完結」というのがHTTPの基本ルールだよ。次にまた同じページを開いたとき、サーバーは「あ、さっきも来た人だ」とは思わない。完全に別の人として扱われる。

なぜインターネットはステートレスで作られたの？

インターネットって、世界中の何十億人もの人が同時に使う仕組みだよね。もしサーバーが全員の「前の状態」を覚え続けたら、どうなるか想像してみて。サーバーのメモリがとんでもないことになる。しかも、世界中に分散してあるサーバーが「あの人は今どこにいて、何をしてたか」を全部同期させるなんて、ほぼ不可能だよ。

だからHTTPは「毎回ゼロから」という設計にした。これによって：

• どのサーバーが担当しても同じ結果を返せる
• サーバーを増やすのが簡単になる（スケールしやすい）
• 一部のサーバーが壊れても他で対応できる（耐障害性が上がる）

「シンプルだからこそ強い」という設計思想が、インターネットの土台に組み込まれてるんだよ。

REST APIとステートレス——現代のアプリはこう動いている

REST APIってなに？

スマホアプリやWebサービスは、裏側で「API（Application Programming Interface）」つまり「アプリ同士やアプリとサーバーが会話するための窓口」を使ってデータをやり取りしてる。その中でも特によく使われる設計ルールが「REST（Representational State Transfer）」で、これをRESTful APIとかREST APIって呼ぶんだ。

RESTの大事なルールのひとつが「ステートレスにすること」。つまり、REST APIを使ったやり取りは毎回完結している必要があって、「前のリクエストの続き」として送ることはできない設計になってる。

具体的にどう動くの？

たとえばSNSのタイムラインを読み込む場面を考えよう。スマホアプリがサーバーに「タイムラインのデータをください」と送るとき、そのリクエストには「誰が送ってるか（認証情報）」「何のデータが欲しいか」「何件欲しいか」が全部入ってる必要がある。

サーバーは「前回と同じ人だな」とは判断しない。受け取ったリクエストの中に書いてある情報だけを見て「はい、これを返します」と答える。これがステートレスなやり取りだよ。

このおかげで、世界中に何百台もサーバーを置いて並列処理するような大規模なサービス（TwitterやInstagramを想像して）でも、どのサーバーがリクエストを受け取っても同じ答えを返せる仕組みになってるんだ。

「でもログインしたまま使えるじゃん」——ステートレスと認証の関係

ステートレスなのになぜログインが続くの？

「ステートレスって聞いたけど、ログインしたらずっとログインしたままだよね？矛盾してない？」って思った人、するどい！これはよくある疑問だよ。

答えを先に言うと「サーバーはログイン状態を覚えていない。でもブラウザやアプリが毎回証明書を送ってくるから、ログインが続いてるように見える」んだ。

トークンとクッキーの役割

ログインに成功すると、サーバーは「あなたがログイン済みですよという証明書」を発行する。この証明書のことを「トークン」と呼ぶ。ブラウザはこのトークンを手元に保管しておいて（これを「クッキー」や「セッションストレージ」に保存するという）、次のページを開くたびに「私はこのトークンを持っています＝ログイン済みです」とリクエストと一緒にサーバーへ送り続けるんだ。

サーバーはリクエストを受け取るたびにトークンを確認して「これは正当なユーザーだ」と判断する。でもサーバー自体は「このユーザーがログインしてる」という状態を覚えているわけじゃない。毎回届くトークンをチェックしてるだけ。

図にすると：

• ログイン → サーバーがトークンを発行 → ブラウザが保存
• 次のページへ → ブラウザがトークンを一緒に送る → サーバーがチェックしてOK
• また次のページへ → また送る → またチェック → OK

この繰り返し。サーバーは「前回を覚えてる」んじゃなくて「今届いたトークンを検証してる」だけ。これがステートレスな認証の仕組みだよ。

ステートレスvsステートフル——どっちがいいの？

ステートレスのメリット・デメリット

ステートレスの良いところと悪いところをまとめてみよう。

メリット：

• スケールしやすい：サーバーをどんどん増やせる。ユーザーが急増しても対応できる
• シンプルで壊れにくい：状態を管理する複雑な仕組みが不要なので、設計がすっきりする
• どのサーバーでも対応できる：1台が壊れても他のサーバーがすぐ引き継げる
• キャッシュが使いやすい：同じリクエストには同じ答えを返せるので、途中で保存（キャッシュ）して高速化しやすい

デメリット：

• 毎回情報を送る必要がある：誰が送ってるか・何をしたいかを毎回リクエストに含めないといけない。データ量が増えることがある
• リアルタイム性が必要な場面には向かない：オンラインゲームのように「今この瞬間の状態を全員が共有する」場面はステートフルのほうが適してる

ステートフルが向いている場面

ステートフルが活きる典型例は「リアルタイムの双方向通信」だ。オンラインゲームのバトル、ビデオ通話、チャットアプリのリアルタイムメッセージ——これらは「今の状態をサーバーが把握し続けないといけない」場面だよ。

こういう場合は「WebSocket（ウェブソケット）」という別の通信方式が使われることが多い。これはHTTPと違って「接続を保ち続ける」仕組みで、ステートフルな通信に向いてる。

「ステートレスが正解でステートフルが間違い」じゃなくて、「目的に合わせてどっちを使うか選ぶ」のが正しい考え方。WebサービスのAPIにはステートレス、リアルタイムゲームにはステートフル——という使い分けが現実のサービスでは普通に行われてるんだよ。