先に結論
AI にログイン機能を頼んだら JWT 認証を提案されたけど、本当にそれでよいのか という場面はかなり増えています。
特に SPA っぽく作るなら JWT API なら JWT のように一段飛ばしで勧められることが多いですが、実務ではそこまで単純ではありません。
この話で大事なのは、JWT が良い悪いではなく、その構成で本当に必要な複雑さか を見極めることです。
2026年4月19日時点で OWASP の JWT Cheat Sheet、Laravel 公式ドキュメントの認証説明、OpenID Connect Core 1.0 を確認しながら、AI に JWT を提案されたときの実務的な判断基準を整理します。
アプリ全体の依頼文の組み方から見直したい場合は、生成AIにアプリ作成を頼むプロンプトのコツ｜要件・画面・制約の伝え方 も先に読むとつながりやすいです。
まず答え: 単純なWebアプリならJWTが不要なことは多い
結論から言うと、社内ツール、会員サイト、管理画面、問い合わせ管理、予約管理のような 普通の Web アプリ なら、最初から JWT を入れなくても十分なことがかなりあります。
サーバー側でセッションを管理し、ブラウザには Cookie を持たせる方式の方が、ログアウト、失効、権限変更、監査の扱いが分かりやすいからです。
特に Laravel のように認証基盤がそろっているフレームワークでは、まずセッション認証で組んだ方が実装も運用も素直です。
AI が JWT の方がモダンです と言っていても、そこは設計理由にはなりません。
なぜAIはJWTを勧めやすいのか
AI が JWT を提案しやすいのにはそれなりの理由があります。
つまり、AI が見てきた一般的な説明では正しくても、あなたの案件に合うとは限りません。
管理画面 1 つ、ブラウザ利用のみ、同一ドメイン、少人数運用のアプリなら、JWT まで持ち込まない方が保守しやすいことは珍しくないです。
JWTが向くケース
JWT が向いているのは、たとえば次のような場面です。
1. ブラウザ以外のクライアントが複数ある
Web 画面だけでなく、スマホアプリ、外部クライアント、CLI ツール、他社システム連携など、複数のクライアントから同じ API を使うなら、トークンベースの認証設計が自然になることがあります。
2. 認証基盤や外部IdPと連携する
OpenID Connect や OAuth 2.0 を使い、外部の IdP や認証サービスとつなぐ構成では、JWT 形式の ID トークンやアクセストークンが出てきやすいです。
3. BFFなしの別ドメインAPIを強く意識している
フロントエンドと API を完全に分け、別ドメインで配信し、クライアント側で API 認証をはっきり扱いたいなら、JWT を含むトークン設計を検討する意味があります。
4. サービス境界が最初から分かれている
単一のアプリではなく、複数サービスやマイクロサービス的な境界があり、認証結果の受け渡しを整理したいなら、JWT が噛み合うことがあります。
Cookieセッションで足りるケース
逆に、次のような条件なら Cookie セッションの方が素直なことが多いです。
| 状況 | まず考えたい方式 | 理由 |
|---|---|---|
| 同一ドメインのWebアプリ | Cookie セッション | ログイン状態、ログアウト、権限変更をサーバー側で追いやすい |
| 管理画面や社内ツール | Cookie セッション | 失効や強制ログアウトの運用がしやすい |
| 少人数で保守する案件 | Cookie セッション | トークン再発行や保管設計まで抱えずに済む |
| Laravel の標準認証で十分な構成 | Cookie セッション | 既存の仕組みに乗せた方が実装差分が少ない |
ここで大事なのは、JWT でないと安全ではない わけではないことです。
安全性は、形式よりも 保管場所 期限 失効 CSRF 対策 XSS への耐性 権限変更時の整合 の方に強く左右されます。
JWTで逆に面倒になりやすいポイント
1. ログアウトや強制失効がきれいに済まない
サーバーセッションなら、サーバー側で無効化すれば比較的素直です。
JWT は 配ったあとどう失効させるか を別途考える必要があり、ブラックリスト、短命トークン、リフレッシュトークン運用などが入ってきます。
2. 保存場所の設計で事故りやすい
localStorage に入れるのか、HttpOnly Cookie にするのか、メモリ保持にするのかでリスクが変わります。
JWT を使う より どこに置く の方が現実の事故に効く場面は多いです。
3. アクセストークンとリフレッシュトークンの設計が増える
期限を短くすると再発行設計が必要になり、長くすると漏えい時の影響が重くなります。
この調整を雑にすると、入れたけど運用が苦しい認証 になりやすいです。
4. 権限変更との整合が取りにくい
たとえば管理者権限を外したのに、既存トークン内の情報ではまだ通ってしまう、といった設計ミスが起きやすいです。
トークンの中に何を入れるか は意外と慎重さが要ります。
よくある失敗例
AIに言われたまま「SPAだからJWT」にした
実際には SPA でも同一ドメイン構成で BFF 的に組めることがあります。
画面がSPAっぽい だけで JWT 必須とは限りません。
JWTを入れたのに、結局サーバー側で状態を持っている
失効管理や端末制御の都合で結局サーバー側の保存が増え、セッションより複雑で、でも利点は少ない 状態になることがあります。
localStorage に置いて満足した
形式を JWT にしただけでは守りは強くなりません。
XSS、権限、再発行、期限、ログアウト運用まで見ないと意味が薄いです。
AIに認証実装を頼むときの伝え方
AI に依頼するときは、JWT で作って から入るより、前提条件を渡した方が精度が上がります。
ブラウザだけで使う管理画面です。
同一ドメインで運用し、Laravel を使います。
スマホアプリや外部公開 API はありません。
管理者がユーザー停止や強制ログアウトをしたいです。
この条件で、JWT と Cookie セッションのどちらが適切か、
理由と運用上の違いを説明したうえで提案してください。
こう聞くと、AI が JWT 前提 で暴走しにくくなります。
アプリ依頼全体の整理は、生成AIにアプリ作成を頼むプロンプトのコツ｜要件・画面・制約の伝え方 もあわせて使うと実務に落とし込みやすいです。
判断に迷ったときの実務メモ
- Web ブラウザだけなら、まず Cookie セッションを候補にする
- 外部公開 API やモバイルアプリがあるなら、JWT を含むトークン設計を検討する
失効強制ログアウト権限変更をどう扱うか先に決める- 形式より、保管場所と運用を優先して見る
- AI の提案は
なぜ必要かを言語化できるまで採用しない
まとめ
JWT は便利ですが、いつでも入れるべき標準ではありません。
特に単純な Web アプリ、同一ドメインの管理画面、少人数保守の案件では、Cookie セッション認証の方が分かりやすく、実装も運用も安定しやすいです。
一方で、複数クライアント、外部認証基盤、別ドメイン API、サービス境界の分離があるなら、JWT が合う場面はあります。
大事なのは AI が提案したから採用する ではなく、JWT でないと困る理由があるか を先に見ることです。
認証方式の前に、AI へどこまで仕様を渡すかを整理したい場合は、AIに渡すプロンプトや入力情報で気を付けること｜機密情報・個人情報・著作権・プロンプトインジェクション や、AIツールを使うときに気を付けるセキュリティリスクは？情報漏えい・権限・拡張機能・プロンプトインジェクションを整理 も役立ちます。
参考リンク
- OWASP: JSON Web Token Cheat Sheet for Java
- Laravel Docs: Authentication
- RFC 7519: JSON Web Token (JWT)
- OpenID Foundation: OpenID Connect Core 1.0