結論：認証・ログイン機能は「Claude Codeに書かせて速く済ませる」より先に「既知の安全な方法を選び、人がレビューする」が9割です。Claude Codeはセッション/トークン/OAuthといった方式の整理、既存コードの把握、実績ある標準ライブラリを使った実装の下書きやテストの草案づくりを得意としますが、認証はアプリのセキュリティの要であり、生成されたコードを鵜呑みにせず必ず人がレビューし、機密情報をハードコード/ログ出力しない運用とセットでなければ事故ります。情報は2026年6月時点のものです。
- 要点1：まず「どの方式を採るか」を決める。セッション（サーバ側でログイン状態を保持）／トークン（JWT等を発行）／OAuth・OIDC（外部IdPに委譲）の向き不向きを、Claude Codeに整理させてから選ぶ。
- 要点2：自前でハッシュ化や署名検証を書かない。パスワード保存・トークン署名・セッション管理は、言語標準やデファクトの認証ライブラリ（実績ある既知の安全な方式）に寄せる。
- 要点3：生成コードはそのまま流さず、認証境界・有効期限・失効・エラー時の挙動を人がレビューし、テストとセキュリティ確認（OWASP等の公式資料での突合）を必ず通す。
対象読者：Webアプリ・SaaSのバックエンド/フロントを触る開発者、テックリード、SRE。今日できること：手元のリポジトリで「現状の認証フローを言語化させる」プロンプトを1回流し、いま使っている方式が要件に合っているかをClaude Codeと一緒に棚卸ししてみることです。
正直に言うと、自分が一番ヒヤッとしたのは、昔つくった社内ツールでパスワードのハッシュ化を「とりあえず動くから」と雑に自前実装していたのを、あとからレビューで指摘されたときです。ソルトの付け方が甘く、ライブラリを使えば一行で済むことを、わざわざ脆く書いていた。認証まわりは「動いているから正しい」が一番危ない領域なんですよね。
Claude Codeを使い始めてから、この「方式の選定」と「既存コードの把握」がかなり楽になりました。既存のミドルウェアやルーティングを読み込ませて「いまの認証はどう動いている？」「このエンドポイントは誰が通れる？」と聞くと、フローを言語化してくれる。新規実装でも「セッションとJWT、この要件だとどっちが向いている？」と相談すると、トレードオフを表で出してくれます。ただし——ここが本題なんですが——Claude Codeが出した認証コードをそのまま本番に入れるのは絶対にやめたほうがいい。認証はセキュリティの要で、ミスが即「不正ログイン」「情報漏えい」に直結します。この記事では「速く書く」より「安全に組む」に振った、Claude Codeでの認証・ログイン実装の進め方を、指示例とコード例つきで書きます。
認証の方式を理解して選ぶ（セッション/トークン/OAuth）
認証実装でまず詰まるのは「どの方式にするか」です。ここを曖昧なまま書き始めると、あとから作り直しになりがち。Claude Codeに方式そのものを発明させるのではなく、既知の確立した方式の中から要件に合うものを選ぶために整理させる、という使い方が安全です。代表的な3つを押さえておきます。
- セッションベース認証：ログイン後、サーバ側にセッションを保持し、ブラウザにはセッションIDのCookieを渡す方式。失効（ログアウト・強制ログアウト）をサーバ側で確実に効かせやすいのが利点。同一ドメインのWebアプリと相性が良い。
- トークンベース認証（JWT等）：ログイン時に署名付きトークンを発行し、以降のリクエストで提示させる方式。サーバが状態を持たずに検証できるためAPIやマイクロサービスと相性が良い。一方で「発行したトークンを途中で失効させにくい」課題があり、短い有効期限＋リフレッシュトークンの設計が前提になります。
- OAuth 2.0 / OIDC（外部IdPに委譲）：「Googleでログイン」のように、認証を外部のIDプロバイダに任せる方式。自前でパスワードを預からなくて済むのが大きな利点。ただしフロー（認可コードフロー等）の取り違えは脆弱性に直結するため、RFCや公式の解説に沿って組む必要があります。
方式選定をClaude Codeに手伝わせるときの指示例です。あくまで「整理させて、最終判断は自分でする」のがポイント。
あなたはWebアプリのセキュリティに詳しいエンジニアです。
次の要件に対して、セッション認証 / トークン認証(JWT) / OAuth2(OIDC)の
3方式を比較し、向き不向きを表にしてください。
# 要件
- 構成: SPA(React) + REST API(別ドメイン)
- ユーザー: 社内利用 + 一部の外部パートナー
- 既存: まだ認証は未実装
- 制約: ログアウトや強制失効を確実に効かせたい
# 出力してほしいこと
1. 各方式のメリット/デメリット(特に失効のしやすさ)
2. この要件での推奨と、その理由
3. 採用した場合に注意すべきセキュリティ上の落とし穴
不足している情報があれば、最初に質問してから回答してください。
仮定した点は必ず「仮定」と明記してください。
ここで大事なのは、出てきた比較表をOWASPなどの公式資料と突き合わせて裏取りすることです。方式の説明がもっともらしくても、細部（Cookie属性、トークンの保存場所など）はあとのセクションで人が詰める前提にしておきます。
既存コードの認証フローを把握する
既存アプリに手を入れる場合、いきなり実装させると既存のミドルウェアと二重になったり、認証境界がずれたりします。先に「いまどうなっているか」をClaude Codeに言語化させるのが安全です。新人が大規模コードベースを読むのと同じで、まず全体像を掴むフェーズを挟みます。
このリポジトリの認証まわりを調べて、次を日本語で説明してください。
- ログイン処理がどのファイル・関数で行われているか
- セッション or トークンのどちらを使っているか(根拠も)
- 認証が必須なエンドポイントと、未認証で通れるエンドポイントの一覧
- パスワードや秘密鍵がどこで扱われているか
推測した箇所は「推測」と明記し、確認に使ったファイルパスを添えてください。
この棚卸しで「実は一部のAPIが認証チェック漏れだった」といった既存の穴が見つかることもあります。Claude Codeのコード把握の使い方は、Claude Codeでコードレビューを効率化する実践ガイドの進め方とも相性が良いので、認証フローのレビューと合わせて読むと流れが掴みやすいはずです。
実装を進める（標準ライブラリを使い、段階的に）
方式が決まったら実装ですが、ここで一番やってはいけないのがハッシュ化・署名検証・セッション管理の自前実装です。認証の要素は「実績があり、広くレビューされた既知の安全なライブラリ」に寄せます。Claude Codeにも明示的にそう指示しておきます。
このプロジェクトにメール+パスワードのログインを追加してください。
# 守ってほしい方針(重要)
- パスワードのハッシュ化は自前実装せず、実績ある標準ライブラリを使う
(例: bcrypt / argon2 系。アルゴリズムやコスト設定は推奨値を提示)
- セッション or トークンの管理も、フレームワーク標準/定番ライブラリに寄せる
- 秘密鍵・APIキーはコードに直書きせず、環境変数から読む
- まず最小構成で実装し、テストを書いてから機能を足す段階的な進め方にする
実装前に、使うライブラリ候補とその選定理由を先に提示してください。
パスワード保存の実装例として、Node.js + bcrypt の最小コードを挙げます。ポイントは「ソルトはライブラリに任せる」「平文を絶対に保存・ログ出力しない」ことです。
// 依存: npm install bcrypt
const bcrypt = require("bcrypt");
const SALT_ROUNDS = 12; // コスト係数。負荷とのトレードオフで調整
// 登録時: パスワードをハッシュ化して保存(平文は保存しない)
async function hashPassword(plain) {
return bcrypt.hash(plain, SALT_ROUNDS);
}
// ログイン時: 保存済みハッシュと突き合わせる
async function verifyPassword(plain, storedHash) {
return bcrypt.compare(plain, storedHash);
}
// NG例: console.log(plain) のように平文をログに出さない
トークン方式を採る場合も、署名・検証は専用ライブラリに任せます。JWTの最小例です。秘密鍵は環境変数から読み、有効期限を必ず付けるのが基本形になります。
// 依存: npm install jsonwebtoken
const jwt = require("jsonwebtoken");
const SECRET = process.env.JWT_SECRET; // コードに直書きしない
if (!SECRET) {
throw new Error("JWT_SECRET が未設定です");
}
// 発行: 有効期限を必ず付ける(短め + リフレッシュ前提)
function issueToken(userId) {
return jwt.sign({ sub: userId }, SECRET, {
algorithm: "HS256",
expiresIn: "15m",
});
}
// 検証: 改ざん・期限切れは例外で弾く
function verifyToken(token) {
return jwt.verify(token, SECRET); // 失敗時は throw される
}
実装は一度に全部書かせるより、「登録 → ログイン → 保護されたエンドポイント1つ」のように小さく区切って進めると、各段階でレビューしやすくなります。大きな変更をまとめて入れたいときは、Plan Modeのような「先に計画を立てさせて承認してから実装する」進め方も有効です。
テストと動作確認をする
認証は「正常にログインできる」だけでなく、「通ってはいけないケースで弾けるか」のテストが本命です。ここはClaude Codeにテストを下書きさせると効率が上がりますが、観点の抜けがないかは人が確認します。
- 正常系：正しいメール＋パスワードでログインでき、保護リソースにアクセスできる。
- 異常系：間違ったパスワード、存在しないユーザー、空入力で適切に拒否される。
- トークン系：期限切れトークン・改ざんトークン・署名違いのトークンが拒否される。
- 認可境界：未認証で保護エンドポイントに入れない／他人のリソースを取得できない。
- 失効：ログアウト後（またはトークン失効後）にアクセスが拒否される。
このログイン機能のテストを書いてください。
正常系だけでなく、次の「拒否されるべきケース」を必ず含めてください。
- 間違ったパスワード / 存在しないユーザー
- 期限切れトークン / 改ざんされたトークン
- 未認証での保護エンドポイントへのアクセス
- 他ユーザーのリソースへのアクセス(認可境界)
各テストに「何を保証するためのテストか」をコメントで添えてください。
テスト自動化の組み方そのものは、Claude CodeでQA・テスト自動化を加速する実践ガイドに手順をまとめています。認証テストは回帰しやすい箇所なので、CIで毎回回す仕組みに乗せておくと安心です。
セキュリティを確認する（公式・専門資料で突合）
動いたあとに、必ずセキュリティ観点での確認を挟みます。Claude Codeに「OWASPの観点でレビューして」と頼むのは有効ですが、AIのレビュー結果も鵜呑みにせず、最終的にはOWASPのチートシートなどの公式資料や、必要に応じて専門家のレビューで裏を取ります。最低限見ておきたいポイントです。
- パスワード保存：実績あるハッシュ方式（bcrypt/argon2等）か。平文・可逆暗号で保存していないか。
- セッション/Cookie：Cookieに
HttpOnly/Secure/ 適切なSameSiteが付いているか。ログイン後にセッションIDを再生成しているか。 - トークン：有効期限が適切か。失効の仕組みがあるか。トークンをログやURLに残していないか。
- 機密情報：秘密鍵・APIキーをハードコード／コミットしていないか。エラーメッセージやログに機密が漏れていないか。
- 総当たり対策：ログイン試行のレート制限・アカウントロックを検討したか。
このログイン実装を、OWASPの認証・セッション管理の観点でレビューしてください。
特に次を確認してください。
- パスワード保存方式は妥当か
- Cookie属性(HttpOnly/Secure/SameSite)は適切か
- トークンの有効期限・失効の扱い
- 秘密情報のハードコード/ログ出力の有無
指摘ごとに「該当箇所」「リスク」「修正案」をセットで出してください。
ただし、この結果は最終確認ではなく、公式資料(OWASP)と人のレビューで
裏取りする前提だと明記してください。
セキュリティ全般のレビューフローは、Claude Codeで脆弱性対応を効率化する実践ガイドやClaude Code法人導入セキュリティ完全チェックリストも合わせて確認しておくと、認証以外の穴も拾えます。
【要注意】認証実装でよくある落とし穴と回避策
認証はミスが致命傷になりやすい領域です。Claude Codeを使う/使わないに関わらず、現場でやりがちな失敗を挙げておきます。
失敗1：ハッシュ化や署名検証を自前実装する
❌ 「自分でソルトを付けてSHA-256で」と独自実装する
⭕ 実績ある標準ライブラリ（bcrypt/argon2、定番のJWTライブラリ）に任せる
なぜ重要か：認証の暗号処理は微妙な実装ミスが致命的な脆弱性になります。「広くレビューされた既知の安全な方法を使う」が鉄則で、ここは独自性を出す場所ではありません。
失敗2：生成されたコードを鵜呑みにして本番投入する
❌ Claude Codeが出した認証コードをそのままマージ
⭕ 認証境界・有効期限・失効・エラー時の挙動を人がレビューしてからマージ
なぜ重要か：AIはもっともらしいコードを出しますが、認証はセキュリティの要であり、最終判断は人間の責任です。生成コードは「下書き」と捉えてレビュー前提で扱います。
失敗3：秘密情報をハードコード／ログ出力する
❌ 秘密鍵やAPIキーをコードに直書き、デバッグでパスワードやトークンを console.log
⭕ 環境変数やシークレット管理から読み込み、機密はログに出さない
なぜ重要か：ハードコードした鍵はリポジトリに残り続け、ログに出た認証情報はそのまま漏えい経路になります。「直書きしない・ログに残さない」を最初のルールにします。
関連して、生成AIに機密情報を含むコードを扱わせる際の注意は、Anthropic公式のセキュリティ資料でも整理されています。社内ルールがある場合は、所属組織の規程・コンプライアンスに従ってください。
著者プロフィール
参考・出典
- Claude Code overview｜Anthropic 公式ドキュメント
- Claude Code security｜Anthropic 公式ドキュメント
- Claude Code Best Practices｜Anthropic Engineering
- Authentication Cheat Sheet｜OWASP Cheat Sheet Series
- Session Management Cheat Sheet｜OWASP Cheat Sheet Series
- Password Storage Cheat Sheet｜OWASP Cheat Sheet Series
- RFC 6749: The OAuth 2.0 Authorization Framework｜IETF
