私たちは毎日、いろいろなWebサイトやアプリにログインしています。メールを開くとき、SNSを見るとき、買い物をするとき。IDとパスワードを入れれば、あとは自分専用の画面が出てくる。あまりにも当たり前すぎて、その裏側を考えることはほとんどありません。
でも、いざ自分でサービスを作ろうとすると、この「ログイン機能」は最初の大きな山になります。結論から言うと、Webのログインは「クッキー(Cookie)」と「セッション」という2つの仕組みの組み合わせで作られています。この記事では、なぜログインという仕組みが必要なのか、どういう流れで「あなた」を覚えているのかを、専門用語を噛み砕いて整理します。
結論：ログイン機能はクッキーとセッションの組み合わせで作る
先に答えを言い切ります。Webのログインは、大きく次の2つで成り立っています。
- クッキー(Cookie)：あなたのブラウザ(ChromeやSafari)側に、小さなデータを保存しておく仕組み。
- セッション：サーバー(サービス側のコンピュータ)が「この人はログイン済みの誰々だ」と覚えておく仕組み。
この2つがペアで働くことで、一度ログインすれば、ページを移動しても、しばらく時間が経っても、あなたが「あなた」として扱われ続けます。
なぜわざわざ2つも必要なのか。それを理解するには、まずWebという仕組みそのものが持つ、ある性質を知る必要があります。
掘り下げ①：前提として、Webは「毎回、相手を忘れる」
いちばん大事な前提から始めます。Webの通信は、基本的に「1回やり取りするたびに相手を忘れる」ようにできています。この性質を専門用語で「ステートレス」と呼びます。ステート(状態)がない、という意味です。
イメージとしては、記憶が続かない受付係を思い浮かべてください。あなたが「Aさんです」と名乗って用事を済ませる。ところが数秒後にもう一度その受付に行くと、係の人はあなたのことをすっかり忘れていて、また「どちらさまですか」と聞いてくる。Webのサーバーは、基本的にこの受付係と同じ振る舞いをします。
一見すると不便な設計ですが、これには理由があります。サーバーは同時に何千人、何万人もの相手をさばいています。もし一人ひとりの状態をずっと抱え込んでいたら、サーバーの負担が膨れ上がり、動きも重くなってしまいます。だから「基本は毎回忘れる。覚えておきたいことだけ、別の仕組みで持つ」という割り切った作りになっているのです。
この「毎回忘れる」性質があるからこそ、ログインでは毎回さりげなく本人確認をしています。私たちが意識していないだけで、ページを移動するたびに「この人はさっきの人ですね」という確認が裏で行われているわけです。
ログインの流れ：整理番号で「あなた」を覚える
では、忘れっぽいWebの上で、どうやってあなたを覚え続けているのか。順を追って見ていきましょう。カギになるのは「整理番号」という考え方です。
- あなたがIDとパスワードを入力して送る。サーバーが照合して、認証(本人確認)に成功する。
- サーバーが「整理番号」のようなものを1つ発行し、あなたのブラウザに渡す。
- ブラウザは、その整理番号を「クッキー」という保存場所にしまっておく。
- サーバー側は「この整理番号の持ち主は、Aさんだ」と自分のメモに記録しておく。このサーバー側のメモが「セッション」です。
- 次にあなたが別のページを開くと、ブラウザは自動でクッキー(整理番号)を一緒に送る。
- サーバーは受け取った整理番号を見て、自分のメモと照らし合わせ、「ああ、Aさんだ」と分かる。
たとえるなら、クローク(荷物預かり所)の引換券です。上着を預けると番号札をもらいますね。あなたはその札を持っておくだけでよく、店員さんは番号と上着の対応を控えている。受付で毎回「これ私の上着です、色は紺で…」と説明しなくても、札を見せれば済む。この「番号札」がクッキーの中の整理番号、「対応表を持っている店員」がセッションにあたります。
ここで一点、大事な補足があります。クッキーの中に入っているのは、あくまで「整理番号」であって、パスワードそのものではありません。仮に番号が誰かに見られても、それだけで中身がすべて筒抜けになるわけではない設計を目指します。クッキー自体をもう少し詳しく知りたい方は、Cookieとはもあわせて読んでみてください。
掘り下げ②：パスワードは、そのまま保存しない
ログインを語るうえで、もう一歩だけ踏み込んでおきたい話があります。それは「パスワードの保管のしかた」です。
初心者のうちは、つい「入力されたパスワードを、そのまま台帳に控えておけばいい」と考えがちです。ところが、これは避けたい作り方です。もしその台帳(データベース)が外部に漏れてしまったら、利用者全員のパスワードがそのまま流出してしまうからです。
そこで基本になるのが「ハッシュ化」という考え方です。ハッシュ化とは、パスワードを一定のルールで別の文字列に変換して保管する方法です。ポイントは、この変換が「一方通行」だということ。元のパスワードから変換後の文字列を作ることはできますが、変換後の文字列から元のパスワードを逆算するのはとても難しくなっています。
「パスワードは、預からずに照合する」。この発想が、安全なログインの土台になります。
掘り下げ③：これだけだと弱い。だから2段階認証や新しい方式へ
ここまでで、ログインの基本形は見えました。ただ、IDとパスワードだけでは、どうしても弱さが残ります。パスワードが推測されたり、どこかで流出したりすれば、他人になりすまして入られてしまうからです。
そこで主流になっているのが「2段階認証」です。パスワードという「1つ目の鍵」に加えて、もう1つ別の確認を重ねる考え方です。
- メールやSMSに届いた確認コードを入力する。
- 認証アプリに表示される、数十秒ごとに変わる数字を入力する。
パスワードを知っているだけでは通れず、「あなたのスマホやメールを実際に持っている」ことまで確かめる。鍵を二重にかけるイメージです。
さらに最近は、パスワードそのものを使わない方式も広がってきています。
- パスキー：指紋や顔認証、端末そのものを鍵として使う仕組み。覚える必要のあるパスワードを持たない考え方。
- ソーシャルログイン(OAuthという仕組み):「Googleでログイン」「Appleでログイン」のように、すでに信頼できる別サービスに本人確認を任せる方式。
どの方式を選ぶにせよ、根っこにあるのは「パスワード1本に頼りきらない」という発想です。
掘り下げ④：AIで開発するときに気をつけたいこと
いまはAIに指示すれば、ログイン機能の土台をすばやく形にできる時代です。とても心強い一方で、丸ごと任せきりにすると見落としやすい部分があります。それが、クッキーとセッションの「設定」です。
クッキーやセッションには、地味だけれど大事な設定項目があります。たとえば次のようなものです。
- 有効期限:整理番号がいつまで有効か。長すぎると、盗まれたときの危険が長引きます。
- HttpOnly:クッキーを、ブラウザ上のプログラムから読めないようにする設定。不正なスクリプトに整理番号を盗まれにくくします。
- Secure:暗号化された安全な通信のときだけクッキーを送る設定。通信の途中で盗み見られるのを防ぎます。
これらの設定は、動くかどうかだけを見ていると気づきにくく、初期設定のままでも一見ちゃんとログインできてしまいます。だからこそ、AIに作ってもらったログイン機能でも、「有効期限はどうなっているか」「HttpOnlyやSecureは効いているか」を自分で把握しておく姿勢が大切です。ここは、ログインがうまくいかない原因ともつながる部分で、失敗時のメッセージの読み解き方はログインエラーの理由で触れています。
次の一歩
ログインの全体像がつかめたら、隣り合う仕組みへ視野を広げると理解が立体的になります。
- クッキーの中身や使われ方をもう少し詳しく知りたい方はCookieとは。
- クッキーとセッション以外のログイン方式に興味が出たらトークン認証とは。
- ログインがうまくいかないときのメッセージの意味を知りたい方はログインエラーの理由。
まとめ
- Webの通信は「毎回、相手を忘れる(ステートレス)」性質を持っている。だから覚えておく工夫が別に要る。
- ログインは、クッキー(ブラウザ側に整理番号を保存)とセッション(サーバー側が番号と人の対応を記憶)の組み合わせで作る。
- パスワードはそのまま保管せず、ハッシュ化して「預からずに照合する」のが基本。
- ID・パスワードだけでは弱いので、2段階認証を重ねたり、パスキーやソーシャルログイン(OAuth)といった方式も広がっている。
- AIで作るときも、クッキーやセッションの有効期限・HttpOnly・Secureといった設定を自分で把握しておく。
ログインは、Webの見えない前提を知って初めて「なぜこの作りなのか」が腹落ちする、格好の入り口です。独学でつまずきやすいのは、こうした知識そのものよりも「何を、どの順番で学ぶか」だったりします。ログインひとつを起点に、Web技術やAI活用をどうつなげて学んでいくかも、あなたの目標から逆算して一緒に整理できます。
