結論から言うと、固有IDは「誰のデータかをシステム内部で特定する番号」、トークンは「その人に一時的に渡す入場券のようなもの」です。役割がまったく違うこの2つを混同すると、URLにIDをそのまま出してしまうような設計ミスにつながります。
「トークン」という言葉、よく見かけるけど何のことかよくわからない——そんな声をよく聞きます。実は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 ＝ 部屋番号
マンションの部屋番号を思い浮かべてください。
- 301号室
- 302号室
- 303号室
部屋番号は「どの部屋か」を特定するための番号です。でも、部屋番号を知っているだけでは入れませんし、知っていれば誰でも入れてしまうような設計は危険です。
トークン ＝ その部屋を開けるカードキー
一方でカードキーは、こんな性質を持っています。
- 今日だけ使える
- この人だけ使える
- 期限が切れたら無効になる
- 紛失・不正使用が疑われたらすぐ止められる
整理するとこうなります。
| 役割 | |
|---|---|
| 固有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の認証に関するガイドラインでも言及されています）。
トークンはランダムな長い文字列のため、推測がほぼ不可能です。これがIDとの大きな違いです。
トークンはどうやって使われる？ステップで見る
実際にシステムでトークンがどう使われるか、採用管理システムを例に流れを見てみましょう。
Step 1 — システムの中に候補者Aさんのデータがある。内部では CAND-001 というIDで管理されている。
Step 2 — システムが、Aさん専用のランダムなトークンを発行する。例：abX93kLmPq8Rz...
Step 3 — システムは裏側でこの対応関係を保存しておく。
| 項目 | 値 |
|---|---|
| トークン | abX93kLmPq8Rz... |
| 紐づく候補者ID | CAND-001 |
| 有効期限 | 2026-07-10 23:59 |
| 状態 | 有効 |
Step 4 — Aさんにメールでリンクを送る。URLにはトークンだけが含まれており、IDは含まれない。
https://example.com/status?t=abX93kLmPq8Rz...Step 5 — Aさんがリンクを開く。
Step 6 — システムはトークンを受け取り、以下を確認する。
- このトークンは本物か
- 有効期限が切れていないか
- どの候補者IDに紐づくか
- 失効処理がされていないか
Step 7 — 問題なければ CAND-001 のデータだけを表示する。
つまり候補者は、IDを直接指定して情報を見るのではなく、トークンを通じて”本人専用の表示”を出してもらっているわけです。
「1つの画面で全員分を表示できる」仕組み
ここで1つ疑問が生まれることがあります。「候補者が1000人いたら、1000枚のページが必要なの？」
答えはノーです。
実際には、共通の画面テンプレートが1つあるだけです。たとえば /status という画面が1つだけ用意されている。
アクセスが来たとき、URLについているトークンを見て——
- AさんならAさんのデータ
- BさんならBさんのデータ
を動的に取り出して表示します。つまり、画面は1つ、中身だけ人ごとに違うという仕組みです。
映画館の電子チケットに似ている
映画館の入場画面は1つです。でも、お客さんごとに違うQRコードを持っていて、読み取ると座席や上映回が判定されます。
| 映画館の電子チケット | Webシステム |
|---|---|
| 入場画面（共通） | 候補者閲覧ページ（共通） |
| QRコード | トークン |
| 座席情報 | 候補者IDに紐づくデータ |
トークンはなぜ安全と言えるのか？
トークンが安全とされる理由は、以下の性質を持てるからです。
- 十分長いランダム文字列：推測がほぼ不可能
- 有効期限がある：万が一漏れても時間が経てば使えなくなる
- 失効できる：不正使用の疑いがあればすぐ止められる
- ログを残せる：誰がいつ使ったかを記録できる
トークンの有効期間はどう決めればいい？
「ワンタイムURLは毎回変わるの？」という疑問もよく出ます。これは設計次第です。よく使われるパターンを紹介します。
パターンA：一定期間有効 24時間・72時間・7日間など、期限付きのリンクにする方法です。再アクセスでも同じリンクが使えるため、ユーザーの利便性が高いです。
パターンB：使ったら失効 1回開いたら無効になる方法です。セキュリティは高いですが、候補者が再度確認したいときに不便になります。
候補者向けの進捗確認のような用途では、パターンAの「短期間有効のリンク」が使いやすいと編集部では考えています。完全ワンタイムは利便性とのバランスを慎重に検討するとよいでしょう。
トークンが漏れたら？追加の防御策
「URLが誰かに転送されてしまったら？」という懸念はもっともです。だからこそ、トークン単体で終わらせず、必要に応じて追加の対策を入れます。
- トークンの有効期限を短く設定する
- 一定回数以上アクセスがあったら自動失効させる
- 再送信時に古いリンクを無効化する
- アクセスログを残す（OWASP Logging Cheat Sheet参照）
要件に応じてこれらを組み合わせることで、リスクを大きく下げられます。
まとめ：3行で理解するトークンとID
最後に、いちばん簡単に整理します。
- 固有ID = 社内の台帳でその人を探すための番号（外部に見せるものではない）
- トークン = その人だけに渡す、期限付きの閲覧パス（推測困難・失効可能）
- 共通画面 = 実際には1つのページで、トークンに応じて中身を動的に変えている
IDとトークンの役割を分けることで、「推測されにくく、万が一漏れても被害を限定できる」設計になります。編集部としては、この考え方はWebシステムに限らず、IT資格の学習全般で出てくる「認証」と「認可」の基礎にもつながる重要な概念だと感じています。実務でもよく出てくる話なので、ここで一度整理しておいて損はありません。
よくある質問
Q. トークンとセッションIDは同じですか？ A. 似ていますが、使われる文脈が異なります。セッションIDはログイン中のブラウザセッションを管理するためのもので、トークン（特にJWTなど）は認証情報そのものを含む場合もあります。どちらも「ランダムで推測しにくい文字列」という設計思想は共通です。
Q. JWTというのはトークンの一種ですか？ A. はい。JWT（JSON Web Token）は、署名付きのトークン形式の一つです。ユーザーIDや権限情報などをトークン自体に含められるため、サーバー側でDBを参照せずに検証できるメリットがあります。
Q. APIキーとトークンの違いは何ですか？ A. APIキーは主に「どのアプリケーションからのリクエストか」を識別するために使います。トークンは「どのユーザーのリクエストか」を識別する目的で使われることが多いです。用途と管理方法が異なります。
他のIT用語もあわせて確認したい方は、IT用語ミニ辞典もあわせてどうぞ。IT資格の学習方法を比較したい方は、IT資格の通信講座比較記事も参考にしてみてください。
コメント