自社サービスに「パスキー」を導入すべきかどうか、経営層やユーザーサポート部門から問われて悩んでいませんか。競合が「パスキー対応しました」と発表するたびに、「うちも検討しないと」という声は大きくなる一方で、実際に何をどこまで発注すればよいのかは判断がつかない、という状況は少なくありません。
パスキーは 2022 年に FIDO アライアンスが正式にブランド化した、公開鍵暗号方式ベースのパスワードレス認証です。技術としては新しくありませんが、意思決定者にとっての難しさは技術そのものではなく、「自社サービスにどれくらいの優先度で導入すべきか」「開発会社に何を伝えれば見積を取れるか」といったビジネス判断の部分にあります。ところが検索して出てくる記事の多くは仕組みの解説に紙面を割いており、この意思決定の壁を越えるための材料がなかなか揃いません。
本記事は、開発を外部のシステム開発会社に委託しているプロダクトマネージャーや情報システム部の担当者を主読者として、パスキーの基本を短時間で押さえたうえで、次の 3 点を持ち帰れる状態を目標に構成しました。(1) 自社サービスにパスキー導入が「必要／不要／時期尚早」のどれに当たるかを判断できる、(2) その判断根拠を経営層に説明できる、(3) 発注時の RFP や相談時に何を書けばよいかがイメージできる、の 3 点です。
技術寄りの深掘りは公式仕様書や FIDO アライアンスの資料に譲り、本記事は「発注検討者の意思決定支援」に絞ってお伝えします。導入すべき理由だけでなく、「今は見送るべきケース」も同じ重みで扱いますので、社内での是非判断や経営層への提案書ドラフトにそのまま使えるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
パスキーとは何か：パスワードに代わる認証方式の要点
パスキー（Passkey）とは、ID とパスワードの入力を、生体認証や PIN による「秘密鍵の解錠」に置き換えるパスワードレス認証方式です。FIDO アライアンスが提唱・普及を推進しており、Apple / Google / Microsoft の主要プラットフォームが標準対応しています（FIDO アライアンス パスキー公式ページ）。
一言で言うと：ID とパスワードの入力が「生体認証によるロック解除」に置き換わる仕組み
経営層に一言で説明するときは、「パスワードを覚えない・打たない・漏らさない認証方式」と伝えるとイメージが揃います。ユーザーはサービスにログインする際、パスワードを打つ代わりに、スマートフォンの指紋・顔認証や PC のロック解除操作を行うだけで本人確認が完了します。
実装の裏側では公開鍵暗号方式が使われており、秘密鍵はユーザーの手元のデバイスに、公開鍵はサービス側のサーバーに保管されます。パスワードのようにサーバー側に「本人しか知らない秘密」が保存されないため、サーバーから漏洩しても認証情報の使い回しに直結しないという性質があります。
実際のログイン体験の変化（スマホのロック解除と同じ操作で完結）
ユーザー体験としては「毎日スマホのロックを解除しているのと同じ操作」でログインが完結します。ID の入力すら省略できるサービスも増えており、認証にかかる時間が数秒短縮されるだけでなく、パスワードを忘れて再設定するというストレスからも解放されます。ここが「セキュリティが上がって、しかも便利になる」と言われる根拠です。
一方で、初回にパスキーを登録する動線や、機種変更・デバイス紛失時のリカバリ動線は、既存のパスワード認証にはなかった新しい設計が必要になります。この点は導入判断の重要な論点になるため、のちほど詳しく扱います。
なぜ今パスワードレス認証（パスキー）が注目されるのか
「他社が対応した」という表面的な理由だけではなく、いくつかの構造変化がパスキー普及の背景にあります。経営層に社内提案を通す場面では、これらの背景を押さえておくと「なぜ今か」の説明が通りやすくなります。
第一に、フィッシング詐欺と不正ログインの被害が拡大している点です。フィッシング対策協議会が公表した フィッシングレポート 2026 によれば、2025 年のフィッシング報告件数は過去最多水準で推移し、手口の巧妙化も加速しています。IPA の情報セキュリティ安心相談窓口 2026 年第 2 四半期の集計 でも、不正ログインに関する相談が四半期の相談区分の一角を占め続けています。パスワードや SMS OTP を狙うフィッシングは技術的にほぼ確実に成立してしまうため、パスワード自体を排除しようという動きが強まっています。
第二に、大手プラットフォームの全面対応が完了した点です。iOS / Android / Windows / macOS の主要 OS でパスキーの生成と同期がネイティブサポートされ、主要ブラウザも WebAuthn API に対応しています。数年前までは「先進的な仕組みだが対応環境が限定的で本番導入は時期尚早」という評価でしたが、この前提はすでに崩れています。
第三に、金融業界を中心にパスキー対応が事実上のスタンダードになりつつある点です。銀行アプリ、証券口座、キャッシュレス決済アカウントなど、被害額の大きな領域から順にパスキー対応が進んでおり、業界内の相場観として「パスキー未対応＝セキュリティ投資が遅れている」と見なされるフェーズに入りつつあります。BtoC サービスでは、ユーザーからの要望として直接届くケースも増えています。
これらの背景を踏まえると、パスキーは「新技術としての注目」というより「認証手段の世代交代」に位置づけて捉えるほうが実態に近くなっています。
パスキーの仕組み：公開鍵暗号と生体認証で「盗まれない」を成立させる構造
技術詳細に立ち入りすぎず、発注検討者が経営層に「なぜセキュリティが上がるのか」を説明できる粒度で仕組みを整理します。
秘密鍵はデバイス、公開鍵はサーバー：漏洩リスクの根本的な違い
パスキーは公開鍵暗号方式を使って認証を行います。ユーザーが初めてサービスにパスキーを登録するとき、デバイス内部で「秘密鍵」と「公開鍵」のペアが生成されます。秘密鍵はユーザーのデバイスから外に出ることがなく、公開鍵だけがサービスのサーバーに登録されます。
ログイン時は、サーバーが送るチャレンジ（乱数）に対して、デバイス側で秘密鍵を使って署名を返す、というやりとりが行われます。サーバーは登録済みの公開鍵で署名を検証し、正しく検証できれば本人と判定します。
この構造の重要な帰結は、サーバー側に「盗まれると本人になりすませる秘密」が保存されない ことです。従来のパスワード方式では、たとえハッシュ化していてもサーバーから流出した認証データが解析・使い回しの標的になっていましたが、公開鍵が漏れても攻撃者は署名を生成できないため、サーバー漏洩を認証情報の漏洩と直結させない設計になっています。フィッシング耐性も同じ原理から生まれます。偽サイトに対してデバイスは「登録されたドメインではない」と判定して署名を返さないため、ユーザーがだまされても認証情報の窃取が成立しにくくなります。
生体認証はパスキー本体ではなく「秘密鍵の解錠手段」
ここでよく誤解されるのが「パスキー＝生体認証」という見方です。正確には、生体認証（指紋・顔）は デバイス内に保管された秘密鍵を解錠するための手段 であり、パスキーそのものではありません。指紋データや顔データがサーバーに送られることはありません。
この分離を理解しておくと、社内の質問対応でも「生体情報がサービス側に登録されるのですか？」といった懸念に落ち着いて答えられます。生体認証が使えないデバイスでは、代わりに PIN やパスコードで秘密鍵を解錠する構成もサポートされており、生体認証は必須要件ではありません。
補足：FIDO2・WebAuthn とパスキーの関係を発注者目線で理解する
開発会社との会話で用語が混ざりやすいので、簡単に整理しておきます。技術仕様の詳細を追う必要はなく、以下の位置づけを押さえておけば十分です。
- FIDO2: FIDO アライアンスが策定した、パスワードレス認証の標準規格の総称です。「WebAuthn」と「CTAP」という 2 つの仕様から構成されています。
- WebAuthn: Web ブラウザから認証器（デバイス）を呼び出すための W3C 標準 API です。開発会社が「WebAuthn 実装」と言うときは、この API を使ったサーバー・クライアント両側の実装を指します。
- パスキー: 上記 FIDO2 / WebAuthn の仕組みをベースに、「クラウド同期を前提とした、ユーザーに使いやすい形」で普及ブランド化した認証方式の呼称です。
つまり、パスキーは新しい技術体系ではなく、FIDO2 / WebAuthn という既存標準の上に「ユーザー体験を洗練させた運用形態」を乗せたものと理解しておけば、発注時のズレは防げます。開発会社が見積を出すとき、実装ライブラリや IDaaS 側では「WebAuthn 対応」「FIDO2 対応」と表記されていることが多いですが、これはパスキー対応と実質的に同じ意味です。用語ゆらぎのために別工数として見積が積まれていないか、確認するポイントになります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
パスキーの導入メリットと、あえて挙げるデメリット・注意点
判断材料として、良い面と難しい面を同じ重みで整理します。導入を推す記事ばかり読んでいると、後述の運用リスクに気づくのが遅れがちです。
導入メリット：セキュリティ・運用・UX の 3 側面
- セキュリティ: フィッシング耐性・パスワード使い回しリスクの排除・サーバー漏洩による認証情報流出リスクの低減、の 3 点が本質的な利点です。SMS OTP を突破する SIM スワップ詐欺や、リアルタイムに OTP を中継するフィッシングにも構造的に強い設計になっています。
- 運用: パスワードリセット問い合わせがサポート業務の相当割合を占めるサービスでは、削減効果が期待できます。パスワードポリシー（複雑度・有効期限・履歴管理）の運用・監査コストも軽減できます。
- UX: ログイン時間の短縮、パスワード入力エラーの解消、パスワード忘れによる離脱の低下。BtoC サービスでは購入前ログインの離脱抑制につながる可能性があります。
これらを合わせると、パスキーは「セキュリティ強化施策」ではなく「セキュリティ・運用・UX を同時に改善しうる施策」として位置づけられるのが、単なる 2 段階認証追加との違いです。
デメリット・注意点：ここを軽視すると導入後に炎上する
- デバイス紛失時のアカウント復旧フロー設計が必須: 秘密鍵はデバイス内に保管されるため、機種変更や紛失時に適切なリカバリ手段を用意しておかないと、ユーザーが自分のアカウントに戻れなくなります。クラウド同期・別デバイスでの再登録・管理者リセット・バックアップ認証など、複数の手段を組み合わせて設計する必要があります。
- 対応環境の限界: 主要 OS・ブラウザは対応済みですが、社内で古い端末・古いブラウザを使い続けているユーザー層が多いサービスでは、フォールバック（ID+パスワード維持）を長期間並走させる必要があります。この間、セキュリティ効果は「移行済みユーザーの割合」に比例します。
- 既存ユーザーの移行負担: 既存のパスワード認証ユーザーをパスキーへ切り替えるには、登録動線の案内・FAQ 整備・サポート窓口の準備が必要になります。移行が進まないと、二系統の認証を保守し続けるコストだけが残ります。
- 社内サポート体制の準備: リリース直後は「パスキーってどうやって使うのか」「機種変したら消えた」といった問い合わせが集中しがちです。カスタマーサポート・情報システム部門に事前教育が必要です。
デメリットを重く受け止めすぎる必要はありませんが、これらの設計と体制準備を発注仕様に組み込まないと、リリース後に運用側で問題が噴出するリスクがあります。
パスキーの対応状況：デバイス・OS・ブラウザ・IDaaS の現在地
導入是非を判断する際、自社ユーザー層がどれだけパスキーを利用できる環境にいるかが直接効いてきます。2026 年時点での大まかな対応状況を整理します。
エンドユーザー環境：スマホ・PC・ブラウザの対応状況
- iOS: iOS 16 以降で iCloud キーチェーン経由のパスキー同期に標準対応しています。iPhone / iPad で相互利用が可能です。
- Android: Android 9 以降で Google パスワードマネージャー経由のパスキー生成・同期が普及しています。
- Windows: Windows 11 の Windows Hello はパスキーに標準対応しています。Windows 10 でもブラウザ経由で利用できます。
- macOS: iOS と同じ iCloud キーチェーン経由でパスキー同期が可能です。
- 主要ブラウザ: Chrome / Safari / Edge / Firefox はいずれも WebAuthn API に対応しています。ブラウザ間でのパスキー同期は、パスワードマネージャー（1Password / Bitwarden / Dashlane 等）を経由する形が広がっています。
BtoC サービスの場合、上記対応環境を持たない古いスマートフォン・ガラケーからのアクセスがどの程度残っているかを、アクセス解析で事前に確認してください。BtoB SaaS で会社支給端末のみを対象とする場合は、対応環境の割合が高く、導入判断のハードルは下がる傾向にあります。
サーバー側の実装選択肢：自前実装 vs IDaaS 活用
サーバー側の実装は大きく 2 系統に分かれます。
- 自前実装: WebAuthn 対応のライブラリ（各言語向けに提供されています）を使って、認証フローとパスキー管理を自社で実装する形です。既存の認証基盤との統合自由度は高いものの、仕様変更への追随・監査対応・アカウント復旧フロー設計まで自社の責任範囲となります。
- IDaaS 活用: Microsoft Entra ID（旧 Azure AD）、Okta、Auth0、AWS Cognito、および国内 IDaaS など、多くの ID プラットフォームがパスキー / WebAuthn をネイティブサポートしています。既に IDaaS を利用している場合は、機能追加＋設定変更で対応できるケースが多く、実装工数は自前実装より大幅に小さくなる傾向があります。
現状の認証基盤がどちらかによって、想定される見積レンジが大きく変わります。RFP 段階で「現行認証基盤が IDaaS か自社実装か」「IDaaS を利用している場合はどの製品か」を明示することが、初回の見積精度を上げる近道になります。
自社サービスにパスキーは必要か：導入是非を決める3つの判断軸
ここが本記事の中核です。競合の動きだけを理由に発注を判断するのではなく、3 つの軸で自社の立ち位置を評価すると、「今すぐ導入」「段階的に導入」「今は見送り」のいずれに当たるかが見えてきます。
軸1：保護対象アカウントの価値（不正ログイン被害の想定インパクト）
アカウント乗っ取りが起きた場合の被害の大きさを見積もる軸です。以下に当てはまるほど、パスキー導入の優先度は上がります。
- 決済・金融取引に直結する（EC・銀行・証券・キャッシュレス）
- ユーザーの個人情報・機微情報を保持する（医療・人事・行政）
- 管理者権限で他ユーザーのデータや設定を操作できる（SaaS の管理者アカウント）
- なりすまし投稿・送信が第三者に被害を与えうる（SNS・メッセージング・業務通知）
「1 件の不正ログインでいくらの実損や信用損失が発生しうるか」を試算し、それがパスワード + SMS OTP で許容できる規模かを問い直します。金融・EC・管理者権限を持つ SaaS は、パスキー導入の優先度が高いカテゴリと考えて差し支えありません。
軸2：ユーザー層の対応環境割合
想定ユーザーの何割が、パスキーを快適に使える環境にいるかを見積もる軸です。
- BtoB SaaS で会社支給の新しめの PC / スマホを使うユーザーが中心 → 対応環境割合は高い
- BtoC の若年層向けアプリ → 対応環境割合は比較的高い
- BtoC の幅広い年齢層向けサービス → 対応環境と、リテラシー面での説明コストの両方に注意が必要
- 業務用途で古い端末が現場に残っているケース → フォールバックの長期並走を前提にした設計が必要
「フォールバックを何年並走させる想定か」を初期から折り込むことが、現実的な計画につながります。パスキー移行済みユーザーが 8 割を超えるまでは、二系統の運用コストが残る前提で総コストを試算してください。
軸3：既存認証基盤との統合可能性（IDaaS 有無・独自実装の状態）
現状の認証基盤の状態が、初期実装コストを大きく左右する軸です。
- IDaaS を利用中 → 設定変更＋管理画面での機能有効化中心で対応でき、実装コストは比較的抑えられます
- 自社実装の認証基盤（数年前に開発、以降大規模改修なし） → WebAuthn 対応の追加改修と、既存 DB スキーマとの整合確認が必要になり、初期工数は大きめに見積もっておくのが安全です
- 独自実装で認証まわりの技術負債が大きい → パスキー対応をきっかけに認証基盤のリニューアルを検討する選択肢もあります
現行基盤の情報は開発会社への相談時に必ず求められる項目です。事前に「利用中の IDaaS 製品名」「自社実装の場合は使用言語・フレームワーク・改修履歴」を整理しておくと、初回相談から具体的な議論に入れます。
判断結果パターン：即時導入／段階的導入／今は見送り
3 軸の評価を組み合わせると、大まかに次の 3 パターンに分かれます。
- 即時導入: 軸1が高（金融・EC・管理者権限）× 軸2が高（対応環境十分）× 軸3が良好（IDaaS 利用中）→ 費用対効果が明確で、意思決定を急ぐ価値が高い
- 段階的導入: 軸1が中～高 × 軸2が中程度（フォールバック並走前提） × 軸3が中～重い → PoC → 一部ユーザー先行導入 → 全体展開のロードマップで進める
- 今は見送り: 軸1が低（金銭・個人情報リスクが小さい情報提供サービス等） × 軸2が低（対応環境の少ないユーザー層） × 軸3が重い（大規模改修が必要） → 認証基盤リニューアル・IDaaS 導入とセットで再検討するタイミングを待つ
「今は見送り」も正当な判断です。競合の動きだけを理由に無理な導入を進めると、運用・サポートコストが投資回収を上回るリスクがあります。経営層への説明では、この 3 パターンのどれに該当し、その根拠が 3 軸のどこから来ているかをセットで示すと、判断の透明性が上がります。
導入ステップと、発注時に押さえるべき要件
「即時導入」または「段階的導入」の判断に至ったら、発注の準備に入ります。ここでは開発会社への RFP や相談時に押さえておきたい実務項目を整理します。
導入プロジェクトの標準ステップ
大まかな流れは以下のようになります。企画から本格展開まで、規模にもよりますが数ヶ月単位の期間を見込んでおくと現実的です。
- 現状分析: 現行認証基盤の構成整理、ユーザー層の対応環境の把握、被害リスクの洗い出し
- PoC: 一部の内部ユーザー・限定機能でパスキー登録・ログインを試験実装し、UX と実装難度を確認
- 対応範囲・移行方針の設計: 対象ユーザー、既存パスワードとの併存方式、フォールバック期間、UI 導線
- アカウント復旧フローの設計: デバイス紛失・機種変更・パスキー削除時の復旧手段を複数用意
- 開発・段階リリース: 内部 → 一部ユーザー → 全体、と段階を分けたリリース計画
- 監視・運用: 登録率・利用率・失敗率・問い合わせ件数のモニタリング体制構築
各ステップで発注側が判断を求められる項目は、事前に社内で議論しておくと開発会社との会話がスムーズになります。特に「フォールバック期間」「アカウント復旧の手段選定」は事業側の意思決定が必要な領域で、開発会社に丸投げできない部分です。
RFP・相談時に含めるべき要件チェックリスト
初回相談から精度の高い見積を得るために、以下の項目を書面で伝えられる状態を目指します。
- 対応範囲: どのサービス・どの機能・どのユーザー層を対象にするか（全社／特定サービスのみ／管理者権限アカウントのみ、等）
- 既存認証との併存方式: パスキー単独 / パスキー + パスワード / パスキー + SMS OTP、等の組み合わせ方針
- フォールバック方針: パスキー未対応環境・パスキー未登録ユーザーへの対応（従来認証を維持する期間・条件）
- アカウント復旧手段: バックアップ認証（別デバイス、メール、SMS 等）、管理者リセット、本人確認プロセス
- 対応デバイスの下限: サポート対象とする OS・ブラウザのバージョン下限（アクセス解析データを添付できると精度が上がる）
- 監査ログ要件: パスキー登録・利用・削除の記録項目、保管期間、参照権限
- UX 検証範囲: 登録動線・ログイン動線・機種変更動線・紛失時動線について、UI デザインとテストケースの範囲
- 既存 IDaaS / 認証基盤の情報: 利用中の IDaaS 製品名、自社実装の場合は言語・フレームワーク・DB 構成の概要
- セキュリティ要件: 準拠する社内セキュリティポリシー・業界ガイドライン（金融・医療・行政などは業種特有の要件あり）
- リリース時期・段階リリース計画: 希望する本番リリース時期、段階リリースの区切り
これらを整理して伝えることで、開発会社側の見積・提案の質が大きく変わります。特に「フォールバック方針」「アカウント復旧手段」「対応デバイス下限」の 3 点は、要件が曖昧なまま進むと後工程で仕様変更が発生しやすい領域です。開発を外部に委託する際のセキュリティ要件の整理観点は、外注時のセキュリティ要件 の解説も参考にしてください。
企業導入で注意すべき「ユーザー移行」と「アカウント復旧」の設計
導入プロジェクトで最も炎上しやすい領域が、「既存ユーザーのパスキー登録への誘導設計」と「デバイス紛失時のアカウント復旧フロー」の 2 つです。ここは開発会社に任せきりにできない部分なので、社内で並行して検討する体制が必要です。
ユーザー移行の設計 では、以下のような論点を整理します。まず、既存ユーザーへの案内動線をどうするか。ログイン後にモーダルで案内する、メール・アプリ内通知で告知する、次回ログイン時に半強制的に登録画面を挟むなど、選択肢は複数あります。強制度が上がるほど登録率は上がりますが、離脱リスクも増えます。次に、FAQ ページとサポート窓口の準備。パスキーが「なぜ便利か」「何が変わるのか」を非技術者向けに説明した資料が用意されていないと、問い合わせ対応の工数が跳ね上がります。導入前に事前告知・使い方紹介の動画やヘルプ記事を用意し、リリース直後の 1〜2 週間はカスタマーサポートの人員を増強しておく計画が望ましいでしょう。BtoC の高年齢層向けサービスでは、対面窓口や電話サポートの体制強化も検討対象になります。
アカウント復旧フローの設計 は、ユーザーが機種変更・デバイス紛失・OS 移行などで既存パスキーを使えなくなった場合の道筋を用意する作業です。以下の組み合わせで多層設計するのが定石です。
- クラウド同期による自動復旧: iCloud キーチェーン、Google パスワードマネージャー、パスワードマネージャー製品を利用している場合、機種変後の自動復旧が期待できます
- 別デバイスからの承認: 登録済みの別デバイスで新デバイスを承認するフロー
- バックアップ認証: メール・SMS・電話番号による本人確認と、そのうえでのパスキー再登録
- 管理者リセット: BtoB SaaS では、テナント管理者やサポート窓口からのリセット手段
どの手段を採用するかは、軸1（保護対象の価値）に依存します。金融サービスでは本人確認の厳格性を高める必要があり、来店・書面手続きを組み合わせるケースもあります。一方、影響の小さいサービスではメール認証で十分な場合もあります。復旧フロー自体がフィッシングの標的になる可能性もあるため、復旧手段の設計とセキュリティ検証はセットで進める必要があります。
参考として、業界ごとに「復旧フローで想定すべきユースケース」の重みが違います。BtoC EC では季節性のあるアクセス集中期（セール等）にサポート窓口が逼迫しやすく、BtoB SaaS では退職・異動時のアカウント移管手続きが復旧フローに絡んできます。自社サービスのユースケースに沿った復旧設計を、要件段階から開発会社と共有することが「導入後の炎上」を防ぐ最大のポイントです。認証・認可・SSO の位置づけを含めて全体像を整理したい場合は、認証と認可の基礎 も併せてご覧ください。
まとめ：発注前チェックリストと次のアクション
本記事で扱った要点を、発注前チェックリストの形で再整理します。経営層への提案書ドラフトや、開発会社への相談メモとしてそのままお使いいただけます。
社内での判断チェックリスト
- 保護対象アカウントの価値評価は完了しているか（1 件あたりの被害インパクト試算）
- 想定ユーザー層のパスキー対応環境割合を把握しているか（アクセス解析データで裏付け）
- 現行認証基盤の状態を整理しているか（IDaaS 名 or 自社実装の詳細）
- 3 軸から見て、「即時導入 / 段階的導入 / 今は見送り」のどれに該当するかを言語化できているか
- 経営層に説明できる形の根拠（軸の評価結果）が揃っているか
発注時に伝えるべき要件チェックリスト
- 対応範囲（対象サービス・機能・ユーザー層）
- 既存認証との併存方式
- フォールバック方針と並走期間
- アカウント復旧手段の多層設計
- 対応デバイス下限（アクセス解析データ添付が望ましい）
- 監査ログ要件・セキュリティ要件・業界ガイドラインの適用
- UX 検証範囲（登録・ログイン・機種変更・紛失時の各動線）
- 現行認証基盤の情報（IDaaS or 自社実装）
- リリース時期と段階リリース計画
パスキーは「導入すればセキュリティが上がる魔法の技術」ではなく、「意思決定・要件整理・移行設計・運用体制準備の 4 点セットを丁寧に進めれば、セキュリティ・運用・UX を同時に改善できる施策」です。逆に、この 4 点のいずれかを省くと、リリース後の炎上リスクが高まります。今回の判断軸と要件チェックリストが、社内議論と発注準備の起点になれば幸いです。
関連情報：外部人材活用・システム開発のご検討に
パスキー対応を含む認証基盤の刷新・セキュリティ強化施策の実務ポイントをまとめた資料をご用意しています。発注前の社内検討・要件整理にお役立ていただけます。詳しくは お役立ち資料一覧 をご覧ください。
パスキー導入の要件整理や、既存認証基盤との統合可否の初期相談をご希望の方は、お問い合わせフォーム からご相談ください。要件が固まりきる前の段階から、判断軸の整理・実装可否の検討をご一緒します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- パスキー導入は今すぐ急ぐべきですか？
保護対象アカウントの価値が高く（決済・個人情報・管理者権限を含む）、ユーザーの対応環境が整い、IDaaSを利用中であれば「即時導入」の優先度が高いといえます。3条件のいずれかが弱い場合は段階的導入で十分です。
- 既存のパスワード認証は完全に廃止する必要がありますか？
いいえ、廃止は必須ではありません。パスキー未対応の環境や未登録ユーザーが一定数残る間は、フォールバックとして従来のパスワード認証を一定期間並走させる設計が一般的です。目安として、パスキー移行率が8割を超えるまでは二系統の運用コストが残る前提で計画し、社内提案では「即時廃止」ではなく「移行率に応じた段階的縮小」として説明すると合意を得やすくなります。
- 発注前に自社で最低限準備しておくべき情報は何ですか？
現行認証基盤がIDaaSか自社実装かの情報、対応デバイス下限を示すアクセス解析データ、フォールバック方針の3点です。特にIDaaSか自社実装かによって想定される見積レンジが大きく変わるため、この情報が曖昧なまま相談すると初回提示の見積に幅が出やすくなります。3点を整理したうえで相談すると、初回打ち合わせから具体的な要件・費用感の議論に入りやすくなります。
- パスキー導入にかかる費用感はどう決まりますか？
明確な相場はなく、現行認証基盤の状態（IDaaS利用か自社実装か）とアカウント復旧フローの複雑さによって大きく変動します。IDaaSを利用中で設定変更中心の対応が可能な場合は費用を抑えやすく、自社実装で大規模改修が必要な場合は初期工数が大きくなる傾向があります。RFP段階で現行基盤の状態とアカウント復旧の想定方式を明示すると、初回提示時点での見積精度が上がります。
- 生体情報がサービス側に保存されるのではないかと心配です。大丈夫ですか？
指紋や顔のデータはデバイス内で秘密鍵を解錠するためだけに使われ、サーバーへ送信・保存されることはありません。サーバー側に登録されるのは公開鍵のみで、生体情報そのものは一切外部に出ない設計です。社内で懸念の声が出た際は、「生体認証はロック解除の手段であり、パスキー自体は公開鍵暗号の仕組みで守られている」という2点を切り分けて説明すると、非技術者にも伝わりやすくなります。
