「トークン」という言葉、よく見かけるけど何のことかよくわからない——そんな声をよく聞きます。実はWebアプリやAPIの設計を理解するうえで、トークンと固有IDの違いを押さえるだけで、セキュリティの考え方がぐっと整理されます。
この記事では、専門用語をなるべく使わずに「部屋と鍵」のたとえを使いながら解説します。IT資格の学習中の方や、Webシステムの仕組みを初めて学ぶ方に向けた内容です。
まず結論：IDとトークンは「何に使うか」が違う
細かい説明の前に、一言でまとめます。
- 固有ID：データベースの中でその人を識別するための番号
- トークン：その人に一時的に渡す「入場券」や「鍵」
もう少し言い換えると——
- ID は「誰のデータかを内部で特定するためのもの」
- トークン は「そのデータを見てよいかを外部から確認するためのもの」
この2つは役割がまったく別です。以下で順番に説明します。
固有IDとは？――社内の台帳番号のようなもの
固有IDとは、システムの内部でデータを識別するための番号です。
たとえば、ある採用管理システムでは、候補者Aさんに以下のようなIDが付いているとします。
- 候補者ID：
CAND-001 - システム内部ID：
003xxxxxxxxxxxx
これは、住所録でいえば「〇〇市〇〇町〇番地」のようなものです。システムが「このデータはAさんのものだ」と識別するために使います。身近なたとえだと、こうした番号に近いです。
- 社員番号
- 顧客番号
- 伝票番号
- 部屋番号
つまり、内部で整理するためのラベルです。ただし、IDは「内部で使う番号」であって、外部（URLなど）にそのまま出してはいけないのが基本の考え方です。その理由は後で説明します。
トークンとは？――期限付きの「入場キー」
トークンは、もっとシンプルに言えば「この人に今だけ渡す安全な鍵」です。たとえば、候補者Aさんにメールで送るURLがこうだとします。
https://example.com/status?t=abX93kLmPq8Rz...この t=... の部分、長いランダムな文字列がトークンです。トークンには以下の性質があります。
- Aさん専用に発行されている
- 一定期間だけ有効（期限が切れると使えなくなる）
- 推測しにくい（十分に長いランダム文字列）
- 必要なら失効させられる
身近なたとえだと、こういったものに近いです。
- ホテルのカードキー
- 当日限定のイベント入場QR
- 宅配の受け取り認証コード
「IDとトークンの違い」を家でたとえると
この違いをいちばんわかりやすく説明できるたとえが、部屋と鍵です。
固有ID ＝ 部屋番号
マンションの部屋番号を思い浮かべてください。部屋番号は「どの部屋か」を特定するための番号です。でも、部屋番号を知っているだけでは入れませんし、知っていれば誰でも入れてしまうような設計は危険です。
トークン ＝ その部屋を開けるカードキー
一方でカードキーは、今日だけ使える・この人だけ使える・期限が切れたら無効になる・紛失・不正使用が疑われたらすぐ止められる、という性質を持っています。
| 役割 | |
|---|---|
| 固有ID | どの部屋か（識別） |
| トークン | その部屋に入ってよい証明（認証） |
なぜIDだけではダメなのか？
「IDがわかれば本人を特定できるのだから、URLにIDを入れれば十分では？」と思うかもしれません。しかしこれには大きなリスクがあります。たとえば、こういうURLを設計したとします。
- AさんのURL：
https://example.com/status?id=111 - BさんのURL：
https://example.com/status?id=112
このとき、もし誰かが 111 を 112 に書き換えてアクセスしたら、Bさんの情報が見えてしまいます。IDは連番になっていることが多く、推測・総当たりがしやすいという弱点があります。
Webセキュリティの世界では、これを「Insecure Direct Object Reference（安全でないオブジェクト参照）」と呼び、典型的な脆弱性として広く知られています（OWASPの認証に関するガイドラインでも言及されています）。トークンはランダムな長い文字列のため、推測がほぼ不可能です。
トークンの使い方：ステップで見ると
実際にシステムでトークンがどう使われるか、採用管理システムを例に流れを見てみましょう。
Step 1 — システムの中に候補者Aさんのデータがある。内部では候補者IDが CAND-001 として管理されている。
Step 2 — システムが、Aさん専用のランダムなトークンを発行する（例：abX93kLmPq8Rz...）。
Step 3 — システムは裏側でこの対応関係を保存しておく。
| 項目 | 値 |
|---|---|
| トークン | abX93kLmPq8Rz... |
| 紐づく候補者ID | CAND-001 |
| 有効期限 | 2026-07-10 23:59 |
| 状態 | 有効 |
Step 4〜7 — Aさんにリンクを送り、アクセスが来たらトークンの正当性を確認してから CAND-001 のデータだけを表示する。
つまり候補者は、IDを直接指定して情報を見るのではなく、トークンを通じて”本人専用の表示”を出してもらっているわけです。
「1つの画面で全員分を表示できる」仕組み
候補者が1000人いても、1000枚のHTMLページを作る必要はありません。共通の画面テンプレートが1つあるだけで、URLについているトークンを見て、AさんならAさんのデータ、BさんならBさんのデータを動的に差し込んで表示します。
映画館の電子チケットに似ています。入場画面は1つですが、QRコードを読み取るとその人の座席や回が判定される。「共通画面＋トークン＋個別データ」という構造です。
トークンが安全な理由
トークンが安全とされる理由は、以下の性質を持てるからです。
- 十分長いランダム文字列で推測がほぼ不可能
- 有効期限があり、万が一漏れても時間が経てば使えなくなる
- 失効できるので不正使用の疑いがあればすぐ止められる
- 使った履歴を残せる
トークンの有効期間：設計次第で変わる
トークンの有効期間はシステム設計によります。よく使われるパターンは2つです。
パターンA：一定期間有効（24時間・72時間・7日間など）——再アクセスでも同じリンクが使えるため、ユーザーの利便性が高いです。
パターンB：使ったら失効（1回だけ有効）——セキュリティは高いですが、候補者が再度確認したいときに不便になります。
候補者向けの進捗確認のような用途では、パターンAの「短期間有効のリンク」が使いやすいと編集部では考えています。
トークンが漏れたら？追加の防御策
- トークンの有効期限を短く設定する
- 一定回数以上アクセスがあったら自動失効させる
- 再送信時に古いリンクを無効化する
- アクセスログを残す（OWASP Logging Cheat Sheet参照）
まとめ：3行で理解するトークンとID
- 固有ID ＝ 社内の台帳でその人を探すための番号（外部に見せるものではない）
- トークン ＝ その人だけに渡す、期限付きの閲覧パス（推測困難・失効可能）
- 共通画面 ＝ 実際には1つのページで、トークンに応じて中身を動的に変えている
IDとトークンの役割を分けることで、「推測されにくく、万が一漏れても被害を限定できる」設計になります。Webセキュリティの基本として、ぜひ覚えておいてください。
よくある質問
Q. トークンとセッションIDは同じですか？
A. 似ていますが、使われる文脈が異なります。セッションIDはログイン中のブラウザセッションを管理するためのもので、トークン（特にJWTなど）は認証情報そのものを含む場合もあります。どちらも「ランダムで推測しにくい文字列」という設計思想は共通です。
Q. JWTというのはトークンの一種ですか？
A. はい。JWT（JSON Web Token）は署名付きのトークン形式の一つです。ユーザーIDや権限情報などをトークン自体に含められるため、サーバー側でDBを参照せずに検証できるメリットがあります。
Q. APIキーとトークンの違いは何ですか？
A. APIキーは主に「どのアプリケーションからのリクエストか」を識別するために使います。トークンは「どのユーザーのリクエストか」を識別する目的で使われることが多いです。
コメント