本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第2弾として、認証設計について解説する記事です。
本記事の問いは「どうやって本人と確かめるか」です。認証の3要素・パスワード/MFA/Passkey・SSO・ソーシャルログイン・IDaaSといった認証方式の選定を扱い、確かめたあとのセッション管理はソフトウェア章、ブラウザ側の防御はフロントエンド章に委ねます。
本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』・『安全なWebアプリケーションの作り方 第2版』も参考にしてみてください。
この記事の結論
- 認証は自作せずIDaaSに委譲する
- MFAを標準にし、新規はPasskey対応を前提にする（SMSは避ける）
- B2BはSSO+OIDCを最初から組み込む
- AIエージェント用の認証は短命トークン・最小スコープ・操作ログの3点セット
この記事を読む前に
本記事は認証・認可・暗号化といったセキュリティ用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「セキュリティと認証の基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそも認証とは何か
認証とは、ざっくり言えば「この人は本当に本人か？を確かめる仕組み」です。
オフィスビルの入口を想像してください。受付で社員証を見せて本人確認し、ゲートが開く──これが認証です。社員証だけでなく、顔認証や暗証番号を組み合わせれば、他人が社員証を拾っても入れません。デジタルの世界でも同じで、パスワード（知識）・スマホ（所持）・指紋（生体）を組み合わせて本人確認の精度を上げるのが現代の認証設計です。
なぜ認証設計が重要なのか
認証が突破されると、その先のアクセス制御は一切機能しません。攻撃者は正規ユーザーとして振る舞えるため、データ流出・金銭被害・他システムへの踏み台化まで一直線です。認証の強度がシステム全体のセキュリティ上限を決めるため、最も入念に設計すべき領域です。
そしてパスワード単独で守る時代は終わりました。フィッシング・情報漏洩・他サイト漏洩リストの使い回し（Credential Stuffing）が日常化し、MFAなしは事実上無防備という状況です。2022年のLastPass流出やOktaサプライチェーン侵害は、認証基盤そのものが狙われる現実を示しました。
もう1つの難しさは、強い認証はユーザーの手間を増やすことです。セキュリティと使い勝手のバランスを外すと、ユーザーが回避策を使い始めて、かえって穴が開きます。
認証の3要素
認証は「何を根拠に本人と確認するか」で3つの要素に分類されます。
| 要素 | 意味 | 例 |
|---|---|---|
| Something you know | 知識 | パスワード・PIN・秘密の質問 |
| Something you have | 所持 | スマホ・セキュリティキー・ICカード |
| Something you are | 生体 | 指紋・顔認証・虹彩 |
MFA（多要素認証）は、異なる要素を2つ以上組み合わせることで、1つが漏れても他が守る仕組みです。Microsoftの研究データでは、MFAを有効化するだけで99.9%の自動化攻撃をブロックできることが示されています。なお同じ要素2つ（パスワード+秘密の質問）はMFAではない点に注意してください。
認証方式の全体像
パスワード ― 単独利用は終わった
パスワード認証の弱点は技術ではなく人間です。ユーザーは弱いパスワードを使い、使い回し、フィッシングに入力してしまいます。NIST（米国のセキュリティ標準を作る組織）のガイドライン（SP 800-63B）でも方針が変わり、定期変更の強制は非推奨、「長さ重視・漏洩時のみ変更」が現在の推奨です。パスワードを使うなら「長さ・漏洩検知・MFA併用」が基本線になります。
MFAの手段 ― SMSは避け、TOTPかPushを標準に
MFAの手段には強度差があります。SMSコードはSIM乗っ取り（SIMスワップ）で突破されるため企業向けでは避けるべきです。標準になるのはTOTP（Google Authenticator等のアプリでコード生成）とPush通知（Okta Verify等でタップ承認）です。本気で守る領域は、公開鍵暗号でフィッシング自体が成立しないFIDO2 / WebAuthnとハードウェアキー（YubiKey等）が最強です。
Passkey ― 新規構築の前提
PasskeyはFIDO2ベースのパスワードレス認証で、Windows Hello・Face ID・Googleパスキーとして普及しています。パスワードが存在しないためフィッシングも漏洩リスト攻撃も成立しない、という根本的な改善です。対応デバイスの要件と復旧手順（デバイス紛失時）の設計が残る課題ですが、2024年以降は主要サービスで標準化しており、新規構築では最初からPasskey対応を前提にするのが現実解です。
SSOとソーシャルログイン ― 入口を1つにまとめる
SSO（シングルサインオン）は1回の認証で複数サービスにログインできる仕組みです。組織ではOkta・Entra ID・Google WorkspaceなどのIdPを中心に据え、各サービスへ連携させるのが定石で、退職者のアカウント停止もIdP側の1箇所で済みます。プロトコルは現代の主流がOpenID Connect（OIDC）、エンタープライズの古参がSAML 2.0です。OAuth 2.0は認可のプロトコルであって認証ではない、という区別も押さえておきたいポイントです。
B2C向けには、Google・Apple・LINE等のアカウントでログインさせるソーシャルログインが事実上の標準です。新規登録が不要になりコンバージョン率が大きく上がります。iOSアプリで他のソーシャルログインを提供する場合は「Sign in with Apple」の併設が必須というApp Storeルールにも注意が必要です。
IDaaS ― 認証は買うもの
IDaaSは認証機能をSaaSとして提供するサービスです。パスワード保存・MFA・ソーシャルログイン・SSO・Passkey対応を自社実装すると数人月かかりますが、IDaaSなら数日で導入できます。認証の自作は現代ではほぼ非推奨です。セキュリティ専門家以外が作ると穴だらけになります。
主役は3つです。個人開発〜スタートアップならSupabase Auth / Firebase Auth（安価でスタックに統合済み）、B2B SaaSならAuth0 / Clerk（機能が厚くSSO対応が容易）、大企業のSSO中心ならOkta / Entra ID（業界標準）。ほかにAWS中心の環境ならCognito、Microsoft系B2CならAzure AD B2Cも選択肢になります。
どう選べばいいのか ― 規模別の3シナリオ
認証の厳しさは扱うデータの機微度×ユーザー層で決まります。典型的な3つのケースで考えてみます。
個人開発・スタートアップなら ― スタックに付いてくる認証を使う
1〜5人でB2Cサービスを立ち上げるなら、Supabase AuthやFirebase Auth、Clerkのようなスタック付属の認証を使って、ソーシャルログイン（Google+Apple）とPasskey対応で始めるのが良いと思います。実装は数十行で済んでしまいますし、無料枠にも収まります。この規模で認証を自作するのは、時間の浪費とセキュリティリスクの両取りになる最悪の選択と言えるでしょう。
中小SaaS（B2B）なら ― SSO対応が商談の必須要件になる
B2B SaaSでは、顧客企業の情シスから「自社IdP（Entra ID等）とSSO連携できるか」が商談条件として飛んできます。Auth0 / ClerkのようなSAML/OIDC対応のIDaaSを最初から使っておくと、この要件に設定だけで応えられます。全社員MFA必須・管理画面はさらに強い認証、という段階設計もIDaaS側の機能で済みます。
大企業・エンタープライズなら ― IdP中心の統制と最強認証
Okta / Entra IDをIdPの中心に据え、全システムをSSO配下に置きます。一般社員はTOTP / Push、管理者アカウントと特権操作はFIDO2+ハードウェアキーまで引き上げ、退職処理はIdPの1箇所停止で完結する状態を作ります。金融・医療・政府系では監査要件から多層認証が必須です。
認証強度の実務段階表
※ 2026年4月時点の業界相場値です。
| サービス種別 | 推奨認証 | MFA |
|---|---|---|
| B2C・無料サービス | パスワード+ソーシャルログイン | オプション |
| B2C・金銭を扱う（EC・銀行） | MFA必須+Passkey推奨 | TOTP / Push |
| B2B業務SaaS | SSO+MFA必須 | TOTP / Push / FIDO2 |
| 金融・医療・政府系 | FIDO2+ハードウェアキー | FIDO2必須 |
| 管理者アカウント | FIDO2+ハードウェアキー | 必須 |
ユーザー層の考慮も忘れてはいけません。高齢者向けサービスでFIDO2を強制すると誰もログインできなくなります。非IT層向けにはSMS+手厚いサポートという妥協が現実的な場面もあり、その場合は他の防御層でカバーします。
AI判断軸 ― AIエージェントという新しいアクター
AI時代の認証設計で最も大きな変化は、人間だけでなくAIエージェントが正規のアクターとしてAPIを叩くようになったことです。GitHub Copilotがコードを書き、エージェントがPRを出し、Slack経由で社内システムを操作する──こうしたエージェントに「どの権限で、どこまで許すか」は従来の認証設計になかった課題です。
従来のMachine-to-Machine認証（バッチ処理・マイクロサービス間通信）は決まった処理を繰り返すだけでした。AIエージェントは自律的に判断して異なるAPIを叩くため、固定スコープでは権限が広すぎるか狭すぎるかのどちらかになります。
エージェント認証の設計パターン
基本形はOAuth 2.0 Client Credentials+短命トークンです。エージェントにclient_id/secretを発行して都度トークンを取得させ、スコープで権限を絞ります。金融・医療のような高セキュリティ要件では、トークンと秘密鍵を紐付けて窃取時の悪用を防ぐDPoP（OAuth 2.1）を重ねます。エージェントが「ユーザーの代わりに」作業する場合は人間のトークンを受けて代理操作するOn-behalf-of型を使い、破壊的操作・費用発生・外部送信にはHuman-in-the-loop承認（実行前に人間の承認を要求）を挟みます。
「エージェントに永続API Keyを渡して終わり」は非常に危険です。永続キーは漏洩リスクが時間とともに蓄積し、行動範囲も制限できません。短命トークン+最小スコープ+操作ログの3点は必須です。
エージェント操作の監査証跡
エージェントの操作は「誰の指示で、何の目的で、いつ実行されたか」を完全にトレースできる必要があります。人間の操作はログインユーザーIDで追えますが、エージェントの場合はそれだけでは足りません。エージェントID・委譲元ユーザー（誰の代理か）・トリガー（Slackメッセージ・スケジュール等、何がきっかけか）・実行コンテキスト（プロンプト要約・判断根拠）まで記録します。EU AI Act等で将来必須になる見込みですが、運用開始後にログ構造を変えるのは現実的ではないため、設計段階で組み込んでおく必要があります。
やってはいけないこと
認証領域の事故はなりすまし・企業存続レベルの損害に直結します。特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 認証を自作する | リセット経路・セッション固定・タイミング攻撃など10以上の観点が漏れる → IDaaSに委譲する |
| SMSだけをMFAにする | SIMスワップで突破される（2019年のTwitter CEO事件では10分で突破） → TOTP / Push / FIDO2にする |
| パスワード定期変更を強制する | 弱いパスワードを生むだけでNISTも非推奨 → 長さ重視+漏洩時のみ変更にする |
| SHA-256単独でパスワードをハッシュ | GPUで総当たり突破される → Argon2id / bcryptを使う |
| 永続API Keyをアプリに埋め込む | Git誤コミットで即漏洩し、被害が長期化する → 短命トークン+Service Accountにする |
| AIエージェントに人間と同じ権限を渡す | 高速大量操作で被害が拡大する → 専用アカウントで人間より厳しく絞る |
そして「MFAを入れたから安心」という過信も禁物です。2022年のUber社内侵害は、MFA通知を大量に送りつけてユーザーの根負けを狙う「MFA疲れ攻撃」で突破されました。この種の攻撃に対する真の解が、フィッシング耐性を持つFIDO2 / Passkeyです。
筆者メモ — 「認証くらい自作できる」の罠
認証の自作で痛い目を見た話は、業界でよく語り草になっています。ある社内ツールで「認証くらい自分で書けた方が勉強になる」という動機でbcrypt+Cookieセッションを素朴に組んだところ、リリース直前のセキュリティレビューで、パスワードリセット経路・ブルートフォース対策・セッション固定攻撃・タイミング攻撃・アカウントロックアウト…と思いつきもしなかった観点を10個以上指摘され、丸ごと書き直す羽目になった、という事例は少なくありません。
筆者も新人時代に「認証くらい書けそう」と思って一度手を出しかけて、先輩に「絶対に自作するな」と止められた記憶があります。「自作で学べるのは、自作してはいけないという教訓だけ」と言われる所以です。自作認証は「動く」と「守れる」の間に大きな溝がある──溝に気づいた頃には本番が動いています。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 認証方式（パスワード / MFA / パスキー / SSO）
- MFA手段（SMS / TOTP / Push / FIDO2）
- IDaaSの採用（Auth0 / Okta / Firebase / Supabase）
- ソーシャルログイン（対応範囲）
- パスワードポリシー（長さ・漏洩検知）
- エージェント認証（Service Account・トークン寿命・監査ログ）
決定理由の残し方
認証基盤はセキュリティとユーザー体験の両方に影響するため、なぜその方式・製品を選んだかをADRとして残すことが重要です。以下に具体例を示します。
| 項目 | 内容 |
|---|---|
| タイトル | 認証基盤にAuth0（IDaaS）を採用 |
| ステータス | 承認済み |
| コンテキスト | BtoC向けSaaSの認証基盤を選定する。ソーシャルログイン（Google/Apple）対応とMFA必須が要件 |
| 決定 | Auth0をIDaaSとして採用し、認証機能を外部委譲する |
| 理由 | ・パスワード管理・MFA・ソーシャルログイン・Passkey対応を自前実装せずに実現できる ・OIDC/SAMLに標準対応しており、将来のSSO拡張が容易 ・漏洩パスワード検知（Breached Password Detection）が組み込まれている |
| 却下した代替案 | Firebase Authentication：カスタムクレーム管理が限定的で、複雑な権限モデルに対応しづらい。自前実装：パスワードハッシュ・セッション管理・脆弱性対応の運用負荷が高すぎる |
| 結果 | 無料枠（7,500MAU）で立ち上げ、有料プランへの移行閾値を月次モニタリングする |
認証方式の変更は全ユーザーに影響するため、後任者が「なぜ自前実装ではなくIDaaSなのか」を理解できる状態にしておく必要があります。
この記事に関連する記事
まとめ
本記事は認証設計について、認証3要素・MFA・Passkey・SSO・IDaaS選定・AIエージェントの認証まで含めて解説しました。如何だったでしょうか。
IDaaSに委譲し、MFA標準+Passkey対応、SSO+OIDCを採用し、エージェント用認証は短命・限定にする。これが2026年の認証設計の現実解です。
次回は認可とIAM（RBAC・ABAC・ReBAC・最小権限）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS Amazon Cognito も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（53/95）