Oktaのシステム開発の完全ガイド - ブログ

Oktaのシステム開発とは、認証・認可、ユーザー管理、アプリ連携を組み合わせて、従業員と外部利用者のアクセスを安全に統制する基盤を組み立てることです。

主要機能、導入の進め方、費用、運用上の注意を順に取り上げます。自社で決める判断軸は、従業員向けか外部利用者向けか（Workforce IdentityかCustomer Identityか）と、最初に対象とするアプリの範囲の2つです。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Oktaのシステムの概要

OktaはクラウドIAM（アイデンティティ・アクセス管理）で、誰がどのアプリへどんな条件で入れるかを統制する業務基盤です。

ログインのほか、登録、退職時の停止、権限の見直し、監査ログも扱います。

認証基盤の設計という位置づけ

「Oktaのシステム開発」は、認証サービスそのものを自社で作ることを指すとは限りません。

一般には、Oktaの標準機能を組織情報やアプリ、権限、利用者の使い勝手に合わせて設定・連携し、必要に応じて追加開発します。

認証の安全性はクラウドサービスに任せ、業務固有の画面や認可ロジックは自社アプリ側に実装する分担が現実的です。

Workforce IdentityとCustomer Identityの使い分け

従業員向けと外部ユーザー向けでは、管理する対象と必要な機能が異なります。社内向けは人事情報を起点に、社外向けは利用者本人の操作を起点に、設計を分けて考えます。

業務利用者：従業員、派遣社員、協力会社などを、Workforce Identityを中心に管理します。
業務アプリ：人事情報やディレクトリを起点に、SSO・MFAと入社・異動・退職時の制御を組み合わせる設計です。
外部利用者：会員、患者、購入者、サービス利用者が対象で、Customer Identity（Auth0）の検討対象です。
外部向け機能：登録、ソーシャルログイン、同意、パスワード再設定、顧客データの扱いを押さえます。

Oktaの主要機能とシステム構成の全体像

情報が認証からアプリ利用、権限管理へつながる構成です。

Oktaの機能は、ユーザー情報から認証、接続アプリ、権限・ログまでの流れで把握すると、設計を進めやすくなります。

発注側では、自社の課題を機能に対応づけ、そのうえで、ログインの改善をアクセス管理の業務改革へつなげます。

SSOとMFAによる利便性と安全性の両立

ログインの簡便さと認証の強さを両立するには、SSOとMFAの役割を分けて設計します。どこまでを一度のログインで通し、どこから追加の認証を求めるかで、手間と安全性のバランスが決まります。

SSO：一度の認証で、許可された複数のアプリを個別のパスワード入力なしで使えます。
アプリ接続：SAMLやOpenID Connect（OIDC）でログインを集中管理し、パスワードの使い回しを抑えます。
MFA：パスワードに加えて、端末、プッシュ通知、生体認証、セキュリティキーなどを組み合わせます。
追加認証：ネットワーク、端末、場所、時間、アプリの重要度に応じて、認証の条件を変えます。
段階適用：パスキーや端末ベースの認証を、どの業務から適用するかを決めます。

Oktaの2025年調査では、日本の利用企業のMFA導入率が53%から62%へ9ポイント上昇しました（出典: Okta「The Secure Sign-In Trends Report 2025」、2025年）。

フィッシング耐性のあるOkta FastPassは前年比81%増の25.0%でした（出典: Okta「The Secure Sign-In Trends Report 2025」、2025年）。

Universal Directoryとライフサイクル管理によるIDの整備

ID属性をそろえ、入社から退職までの変更を追える管理方法を決めておきます。人事の情報を基点にすると、変更のたびに手作業で直す場面を減らせます。

属性管理：氏名、所属、役職、雇用区分、勤務地などを、Universal Directoryでまとめて管理します。
マスター選定：人事システム、Active Directory、LDAPなどを基準にし、重複や表記の揺れを減らします。
Lifecycle Management：入社時にアカウントを作成し、異動時のグループ変更と退職時の停止・削除を連動させます。
残存アカウント対策：退職後の不正利用を防ぐため、手作業の申請だけに頼らない仕組みを用意します。

ガバナンスとレガシー連携を含む構成

権限管理と、標準方式に対応しないアプリへの接続は、あわせて検討します。どちらも、利用者が使える範囲と運用の手間に直結する部分です。

Identity Governance：アクセス申請、承認、定期的な権限の見直し、不要な権限の削除を、ワークフローで進めます。
特権管理：管理者権限を分離し、特権アカウントの利用履歴と承認記録を残します。
古いアプリとの接続：SAML・OIDC非対応の場合は、Access Gateway、代理認証、API連携を検討します。
廃止計画：古い方式は障害時の切り分けや将来の移行を難しくするため、接続方式ごとに目標を定めます。

Oktaのシステム開発・導入の進め方

対象範囲の確認から運用引き継ぎまでを順につなげています。

Okta導入は、契約と接続設定の後に、運用の引き継ぎまで含めた工程が続きます。対象範囲を見定めて、その順序で進めます。

現在のIDと権限を洗い出し、対象範囲を決める
代表的なアプリで検証し、設定と復旧手順を確かめる
段階的に移行し、運用担当者へ引き継ぐ

最初から全社・全アプリを対象にすると、要件が固まらないまま作業が広がり、現場への影響も大きくなります。

▶ 詳細はこちら：Oktaのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

現状調査と要件定義による対象範囲の決定

要件定義では、現行の運用を把握し、管理対象やライセンスの前提を明確にします。ここを先に決めておくと、後の設計で話が食い違いにくくなります。

現状の洗い出し：ユーザー台帳、組織、雇用区分、対象アプリ、認証方式、特権IDを一覧にします。
運用情報：退職・異動の手順、監査ログ、障害時の連絡先も調べます。
ユーザー定義：共有アカウントや休職者の扱いを決めておかないと、ライセンス数と権限設計がずれます。
対象範囲：Workforce IdentityかCustomer Identityかを決め、対象外のアプリと将来連携するアプリを明記します。

標準機能を前提としたPoCと基本設計

PoCでは例外時の動作も確かめ、その結果を基本設計と運用に反映します。PoCで試す範囲を決めておくと、基本設計で話が広がりすぎるのを防げます。

PoC対象：SSOとMFAを使う主要アプリを1〜3個選びます。
例外テスト：正常ログインに加えて、端末紛失、属性不一致、連携元の停止、証明書切れ、Okta接続不可も試します。
PoCの確認点：利用者の分かりやすさ、管理者の運用、復旧手順の実行を確かめます。
設計記録：ポリシー、グループと属性、割り当て、SCIM同期、ログ先、管理者、緊急時の手段を文書に残します。
標準機能を優先：独自開発の前に、標準設定、Workflows、SAML、OIDC、SCIM、APIを確認します。

標準機能に寄せるほど、製品のアップデートや担当者の交代に対応しやすくなります。

段階移行と運用引き継ぎによる定着

移行後も安定して使えるよう、展開の準備、効果の測定、運用の引き継ぎを進めます。一度に切り替えず段階を踏むのは、問題が見つかったときに戻せる範囲を小さく保つためです。

展開順：パイロット部門、主要SaaS、複雑な業務アプリ、全社の順に移行します。
移行準備：旧基盤との並行期間、切り戻しの条件、告知、問い合わせ窓口、管理者の当番を決めます。
効果測定：移行対象のアカウント数、SSO成功率、MFA登録率、プロビジョニング失敗件数、問い合わせ件数を追い、感覚ではなくデータで判断します。
運用手順：アクセス申請、権限変更、定期的な見直し、証明書更新、アプリ追加、ライセンス増減、ログ監視、インシデント対応を記載します。
引き継ぎ情報：ポリシーの理由、例外の承認者と見直し時期を残し、担当が代わっても方針を共有します。

ポイント

対象範囲を決めないまま設定を始めると、要件が固まらず、現場への影響も広がります。最初は一部の業務で検証し、結果を見てから全社へ広げるかを判断します。

アプリ連携方式と認証設計の選び方

ログイン、アカウント同期、旧式アプリの扱いを分けて整理できます。

ログイン連携と、アカウントの作成・停止では適した方式が異なります。そのため、アプリの仕様を見て組み合わせます。あわせて、属性の正確さ、最小権限、ログの追跡も評価します。

新しいアプリのSSOに使うSAMLとOIDC

SAMLは、企業向けWebアプリで広く使われてきた認証連携の方式です。既存のアプリが対応していれば、パスワードをアプリに渡さずにSSOを構成できます。

OIDCは、OAuth 2.0を基盤にした認証方式で、Web・モバイルアプリやAPIを含む新規開発と相性がよいものです。

新規開発では、用途に応じてOIDCを第一候補にし、トークンの有効期限、リダイレクトURI、スコープ、ログアウトの挙動を設計します。

ユーザー・権限同期に使うSCIMとAPI

同期の方式や権限の決め方はアプリごとに異なります。このため、自動化する範囲と承認を要する範囲を分けて考えます。

SCIM：ユーザーやグループを同期し、人事情報から対象アプリのアカウントを自動で作成・停止する場合に適します。
最小権限：SCIMの項目と独自の権限は異なる場合があり、部署だけでなく職務、承認者、利用目的も組み合わせます。
API・Workflows：SCIM非対応のアプリでは、キーの保管、レート制限、再実行、重複防止、処理結果の監視を実装します。
承認範囲：自動化する作業と、人が承認する作業を分けます。

同期の範囲や承認の区分が抜けると、自動化そのものが新たな運用障害の原因になるおそれがあります。

レガシーアプリとログ連携のリスク評価

旧式アプリの接続とログ監視は、利用期間や検知後の対応まで決めておきます。旧式の接続は残す期間を先に決めておくと、改修と移行の優先順位を立てられます。

接続方式：SAML・OIDC非対応の古いアプリには、Access Gatewayや代理認証を検討します。
継続リスク：古い方式はMFAの範囲や障害時の対応を複雑にします。改修の可否、利用期限、代替サービス、移行費を確かめ、暫定か長期かを決めます。
ログ転送：認証、管理者操作、プロビジョニングの記録を、目的と必要な保存期間に応じて監視基盤やSIEMへ送ります。
検知と対応：異常な場所からのログイン、短時間の大量失敗、特権の付与、退職後の試行を検知した際の対応と担当者を定めます。

ポイント

既存アプリが対応していればSAML、新規開発ならOIDCを第一候補にし、自動化する範囲と承認が要る範囲はアプリごとに分けて決めます。

Oktaの費用相場と開発期間

Oktaの総額は、ライセンス費と作業費に分けて考えます。作業費には、要件定義から運用保守までの工程が含まれます。ただし、ライセンス価格には、ID整理、権限設計、既存認証からの移行、現場教育の費用が含まれていません。

次に示すのは、公開価格と一般的な導入工数から算出した参考値です。契約条件や対象範囲によって変わります。

▶ 詳細はこちら：Oktaのシステム開発の見積相場や費用/コスト/値段について

公開ライセンス価格からの概算

Okta日本語版ではStarterが1ユーザーあたり月額940円、Essentialsが月額2,670円です（出典: Okta「プランと価格」、2026年8月確認）。年間契約の最低額は24万円です。人数ごとに掛け算すると、年額のおおよその幅を出せます。

Starterの概算：50人は年56万4,000円、100人は年112万8,000円です。
Essentialsの概算：500人では年1,602万円です。
価格の変動要因：上位プラン、追加機能、契約期間、対象ユーザーの定義で変わります。
Customer Identity・Auth0：Workforce Identityの単価は当てはめられません。

Customer IdentityやAuth0では、外部ユーザー数、月間アクティブユーザー数、認証方式、必要な機能が料金の条件になります。

公開価格は初期検討に使い、対象ユーザー数と機能一覧を添えて見積もりを取ります。

初期導入費と運用費の切り分け

導入規模と運用範囲に応じて、初期費と継続費を切り分けます。規模ごとの目安は、人数やアプリ数、連携の範囲によって大きく変わります。

小規模PoC：50〜100人、SSO・MFAとSaaS数個なら100万〜300万円程度、1〜3か月が目安です。
中規模導入：300〜500人、人事・ディレクトリ、10〜30アプリ、SCIM連携なら300万〜800万円程度、2〜6か月です。
大規模導入：1,000人以上で複数拠点、旧式アプリ、API、ガバナンス、SIEM連携を含む場合、800万〜3,000万円以上、4〜12か月の例があります。
運用費：アプリ追加、ポリシー変更、証明書更新、アクセスの見直し、障害対応、ログ監視、ライセンス管理、監査対応が含まれます。
保守費の参考：初期費の年15〜25%とする方法があります。24時間監視や緊急対応は、別途高くなります。

示した金額は、Okta公式の導入料金ではなく、一般的な業務システムの要件定義・設計・テスト工数からの推定です。また、見積もりでは、月次の定型作業と、都度発生する変更作業を分けて記載してもらいます。

期間と金額を左右する要因

費用と期間は、ユーザー数に加えて、構成や移行の条件によって決まります。どの要因が自社に当てはまるかで、費用と期間の見通しが変わります。見積額を比べるときは、構成、移行の条件、成果物の範囲をそろえて見ると、金額の差の理由が分かります。

構成要因：ユーザー数、アプリ数と認証方式、属性の品質、共有アカウント、既存IDの重複を見ます。
移行・運用要因：権限の複雑さ、旧基盤との並行期間、テスト環境、利用者教育の規模も関係します。
データ整備：人事システムとディレクトリの組織情報が一致しない場合は、連携設定より先に不一致を解消します。
設計資料：要件定義書、接続一覧、属性マッピング、認証ポリシー、移行計画、テスト仕様書を確認します。
運用資料：運用手順、復旧手順、管理者向けの教育資料の有無から、作業の抜けを見分けます。

ポイント

公開ライセンス価格だけで予算を決めると、ID整理や移行、現場教育の費用が抜けてしまいます。見積もりは、人数と作業範囲をそろえて比べます。

Oktaの開発会社/ベンダーの選び方

支援先は、知名度や価格だけでなく、設計から移行後の運用までの対応力と、自社の構成・期限・体制との適合で選びます。初回の提案が製品機能の説明に偏る場合は、要件定義をどこまで深く扱うかも確かめます。

対応実績と支援範囲の確認

支援先の経験は、対象領域と担当工程が自社の条件に合うかで確認します。製品の経験と工程ごとの担当範囲は、別々に見ておくと抜けが減ります。

製品経験：設定件数だけでなく、Workforce IdentityとCustomer Identityの経験を確認します。
技術範囲：SSO・MFA、ユーザー同期、権限管理、旧式連携、ログ監視の支援実績を見ます。
工程と担当範囲：要件定義、PoC、設計、構築、移行、教育、運用保守のどこを担当するかを示してもらいます。
類似案件：社名や件数だけでなく、従業員・協力会社、複数拠点、方式の違い、短期移行、監査ログの長期保存を比べます。

自社と同じ難所を経験した支援先は、見落としやすいリスクを早く指摘できます。

提案内容と運用体制の比較

提案を比べる際は、設計方針や費用だけでなく、導入後の支援体制も見ます。提案書の記載は会社ごとに粒度が違うため、同じ項目で並べ直してから比べます。

提案の前提：課題、対象範囲、前提、連携方式、移行、テスト、リスク、日程、費用を確認します。
実装方針：標準機能と追加開発を分け、例外を増やす将来の負担も確認します。
費用比較：ライセンス費と作業費を分け、アプリ追加やユーザー増加時の費用も比べます。
導入後の支援：窓口、対応時間、障害時の連絡方法、設定変更の承認、証明書更新、アクセスの見直し、定期報告を確認します。
運用体制：自社で管理するか、外部に委託するか、共同で運用するかを選び、休暇や異動後も止まらない体制を求めます。

▶ 詳細はこちら：Oktaのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Oktaのシステム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、知名度や価格より、対象領域と担当工程が自社の条件に合うかで選びます。提案を比べるときは、導入後の支援体制も見ます。

セキュリティ・個人情報保護・運用の確認事項

不正アクセスや情報漏えいへの備えは、Oktaに加えて、業務アプリ側の対策と運用の両面で組み立てます。

認証後のアプリ権限は業務アプリ側で確認し、Okta任せにしません。そのうえで、認証強度、最小権限、管理者の分離、端末管理、ログ監視、復旧手順を組み合わせます。

認証強度と特権アクセスの設計

利用者と管理者のリスクに応じて、認証ポリシーから特権管理まで対策を決めます。管理者の権限は、一般の利用者より強く守る必要があります。

ポリシー条件：情報の重要度、端末の状態、ネットワーク、場所、異常な挙動に応じて、認証を分けます。
MFAの適用：管理者には強いMFAを必須にし、一般の利用者にも耐フィッシング方式を段階的に広げます。
登録支援：端末の変更・紛失時の集中を避けるため、予備の手段、本人確認、再登録の手順を用意します。
特権の記録：通常のアカウントとは分けて、管理者の変更、ポリシーの変更、APIキーの発行を記録します。
ブレークグラスアカウント：平常時は使えない状態で保管し、利用時には複数人の承認と事後レビューを求めます。

海外クラウドと個人情報の扱いの確認

個人情報保護委員会は、外国事業者のクラウドでサーバが国内にある場合でも、事業者が保存データを扱うかなどを踏まえた整理が必要だと示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」、2025年改訂版）。

海外のクラウドを使うときは、データの中身と、それを扱う先の範囲から確かめます。

データの確認：氏名、メール、所属、認証ログの種類、保存場所、アクセスする事業者を調べます。
委託先の確認：再委託先、保管期間、削除の方法を見ます。
契約条件：処理の目的、所在国、開示要求への対応、委託先の監督、漏えい時の報告を確認します。
終了・監査：監査の権限と、サービス終了時のデータの返却・消去を押さえます。

法的な該当性はデータ、契約、提供先の実態で変わるため、法務・個人情報保護の担当者と判断します。

障害対応と出口戦略の決定

認証基盤が使えなくなると、多くの業務アプリに入れなくなるおそれがあります。そのため、障害時に誰が何を判断するかを、業務が止まる前に決めておきます。

想定する障害：サービスやネットワーク、設定、証明書の期限、連携元、MFA端末の問題を含めます。
対応の流れ：検知、一次の切り分け、連絡、暫定復旧、本復旧、事後報告を定めます。
業務継続：重要な業務には、代替のログイン手段や緊急用アカウントを安全に用意します。
移行への備え：データの出力方法、標準プロトコル、属性の管理場所、認証ポリシーを記録します。
依存の把握：独自APIや固有機能への依存を確認し、乗り換えの費用と期間を抑えます。

ポイント

認証の強さと権限の範囲は、セットで決めておきます。海外のクラウドに個人情報を置く場合は、データや契約の実態を法務担当と進めます。

Okta導入で起こりやすい失敗と対策

Okta導入は、機能の不足よりも、対象範囲と役割分担を決めないまま設定を始めることで、失敗しやすくなります。そこで、失敗例を要件定義とテスト計画に反映します。

全社一斉展開による現場への影響

全社でSSOとMFAを一斉に強制すると、共有アカウント、古い端末、例外的な勤務形態の問題が同時に表れます。そのため、代表部門でパイロットし、MFA登録、アカウント停止、パスワードリセット、問い合わせ対応を確認します。さらに、利用者には目的、登録方法、端末変更時の手順、問い合わせ窓口を早めに案内します。

認証と認可の混同による権限の広がり

Oktaで認証できても、業務アプリ内のすべての操作が許可されるわけではありません。画面、データ、承認、出力、管理者操作は、アプリ側の認可ルールで制御します。なお、Oktaのグループを強い権限に結びつける場合は、グループ変更の承認者、異動時の反映時期、見直しの方法を決めます。

導入後の運用担当者の不足

リリース後も、自社でアプリの追加や権限の変更が発生します。管理者が一人しかおらず、変更のレビューもログの担当者もいない状態では、例外が増えていきます。対策として、自社の管理者を複数育成し、月次の変更確認、四半期ごとの権限の見直し、年次の復旧訓練を運用予定に登録します。

よくある質問（FAQ）

料金や法務の最終的な判断は、契約条件とデータ・運用の状況で変わります。導入判断に必要な一般的な考え方を、質問ごとに示します。

Oktaのシステム導入にはいくらかかりますか？

Workforce Identityの公開価格は、Starterが1ユーザー月額940円、Essentialsが2,670円です。

導入には、要件定義・連携・移行・テスト・教育の費用もかかるため、総額は人数に加えて、それらの作業でも変わります。

50〜100人の小規模PoCなら初期費100万〜300万円程度、複数アプリと人事連携を含む中規模導入なら300万〜800万円程度が参考値です。

Workforce IdentityとAuth0はどちらを選べばよいですか？

従業員、派遣社員、取引先など社内業務の利用者を管理するなら、Workforce Identityが基本です。

会員、患者、顧客など外部ユーザー向けの登録・ログイン・同意・MFAでは、Customer Identity（Auth0）を中心に検討します。

両方が必要な場合は、ユーザーの種類とデータ管理の責任を分けて、連携の方針を決めます。

Oktaは自社開発できますか？

Okta本体の自社開発は、通常は必要ありません。標準機能やプロトコルで業務固有の画面や認可を内製する方法は、認証・ID管理・セキュリティ運用の知見があり、対象アプリが少ない場合に適します。

移行、監査、障害対応の体制が不足する場合は、導入支援を活用します。

既存の認証基盤から安全に移行できますか？

移行は可能ですが、ユーザーIDの重複、メールアドレスの変更、パスワードの扱い、MFA端末の再登録、旧アプリの例外を事前に確認します。

パイロット、並行稼働、段階切り替え、ロールバック条件を決め、退職者、属性不一致、MFA紛失、連携停止もテストします。

利用者への案内と問い合わせ対応も、移行計画に含めます。

まとめ

Oktaのシステム設計で押さえるポイント

OktaはSSOやMFAだけでなく、ユーザー情報、認証ポリシー、アプリ連携、権限、ログ、運用を横断して管理する基盤です。

従業員向けのWorkforce Identityと外部利用者向けのCustomer Identityを分け、ID・アプリ・権限を一覧にすることから始めます。

導入を始めるときの最初の一歩

費用は、ライセンス費だけでなく、作業の費用も含めて見積もります。作業には、要件定義、データ整理、連携があり、さらに移行、テスト、教育、運用も含まれます。

支援先は、Oktaの設定経験だけでなく、類似のアプリ構成への対応、標準プロトコルの設計、障害からの復旧、導入後の運用体制も確認します。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。