Oktaのシステム開発は、対象IDと連携方式を決め、設計・開発とテストを経て段階的に移行する流れで進めます。また、権限レビューを続けることで、認証から退職者の停止までを一つの流れに整えられます。
▼全体ガイドの記事
・Oktaのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Oktaのシステム開発の全体像
Oktaを導入するときは、認証サービスと、業務データやアプリ固有の認可を担うシステムを分けて考えます。
Oktaは、ログインを共通化し、ユーザー情報や認証ポリシーを管理する基盤です。一方で、業務アプリ固有の権限判定は、たとえば商品の閲覧権限や経費精算の承認範囲のように、アプリ側にも残ります。
Workforce IdentityとCustomer Identityの切り分け
従業員や契約社員、取引先担当者の業務アクセスには、基本的にOkta Workforce Identityを使います。
- 人事情報を連携：人事システムやActive Directoryをマスターにし、入社時の作成、異動時の属性・グループ更新、退職時のアクセス停止を行います。
- 外部ユーザーを管理：会員や患者、購入者などのログインを作る場合は、Customer Identity、いわゆるAuth0が候補になります。
Customer Identityは従業員向けとは要件が異なるため、見積もりも別の前提で行います。見積もりの前提になるのは、利用者数や月間アクティブユーザーです。さらに、ソーシャルログインやパスワードリセット、同意管理も確認の対象になります。
認証・ID管理・連携を一つの業務システムとして見る視点
Oktaの代表機能には、SSO、MFA、Universal Directory、Lifecycle Managementがあります。このほか、WorkflowsやIdentity Governanceも含まれます。
- 新規Webアプリ：OIDCで連携します。
- 企業向けSaaS：SAMLが基本になります。
- ユーザーやグループの同期：SCIMで行います。
- APIの保護：API Access Managementで守ります。
- 古いWebアプリ：すぐに改修できない場合は、Access Gatewayや代理認証が使えるかを確認します。
標準コネクタやプロトコルで接続できても、安全性は別の設計で確保する必要があります。そのため、アプリ側の認可チェックや特権管理は、接続とは別に決めておきます。ログ保存期間と障害時の代替ログインの扱いも、あわせて定めます。
Oktaの2025年調査では、日本のユーザー企業のMFA導入率が53％から62％へ上がっています（出典：Okta「The Secure Sign-In Trends Report 2025」）。FastPassの利用率も13.8％から25.0％へ伸びています。こうした動きを受けて、認証の強度を高めるだけでなく、現場が使い続けられる導線まで設計します。
Oktaのシステム開発の進め方と6フェーズ
Oktaの導入は6段階で進めます。要件整理から始め、製品・方式の選定、設計・開発、テストを経て、稼働と定着に至ります。
対象は重要度と連携の難しさで分け、全社のアプリを一度につながず段階的に広げます。
各フェーズの成果物と完了条件を決めておくと、業務要件が固まる前に設定作業だけが先に進む事態を防げます。
フェーズ1：要件整理で対象者・アプリ・権限の洗い出し
まずは、誰がどのシステムにアクセスするのかを整理します。対象者は、属性も含めて洗い出しておきます。
- 対象者：従業員や派遣社員、業務委託のほか、取引先や顧客も分けて考えます。
- 属性：兼務や休職のほか、再雇用や子会社所属かどうかも確かめます。
- システム：人事やAD・LDAP、SaaSのほか、会計・販売管理やオンプレミスアプリも一覧にします。
SaaSには、Google Workspace、Microsoft 365、Salesforceなども含めます。
各アプリについては、認証方式や登録方法、グループと権限の対応を記録します。ログの必要性や担当部署も、あわせて書いておきます。
最低限決めるのは、対象範囲とアプリの優先順位です。退職時の停止期限やMFAの対象と例外も、この段階で決めます。
管理者の分離方法やログ保存期間、障害時の連絡先も確認項目になります。データ保管国も確かめておきます。
対象アプリ一覧には、「標準連携」「個別API」「改修が必要」「対象外」のいずれかの判定を付けます。業務部門と情報システム部門がその判定に合意すれば、このフェーズは完了です。
フェーズ2：選定での製品プランと連携方式の決定
まず、Workforce IdentityかCustomer Identityかを確定します。そのうえで、必要な機能とプランを照らし合わせます。
- 基本機能：SSOとMFAから始めるかを検討します。
- 運用機能：入社・異動・退職の自動化や、アクセス申請の必要性を確認します。
- 統制機能：定期的な権限の見直しや脅威検知まで必要かを判断します。
どのスイートやアドオンが必要になるかは、含める機能によって変わります。
Microsoft 365やEntra IDの契約がある場合は、対応できるアプリの広さや運用統制を比べます。また、グローバル対応や既存スキルも踏まえて、Okta追加の効果を見極めます。
業務SaaSはSAML、モバイルや新規WebアプリはOIDC、アカウント同期はSCIMを第一候補にします。
APIの認証・認可では、OAuth 2.0やAPI Access Managementを確かめます。
各社には、対象アプリでの実績や認定資格者の有無、国内サポートの体制を質問します。SLAやログ出力、設定のバックアップについても確かめておきます。将来の移行方法も確かめ、機能表以外の材料も含めて比べます。
Okta JapanのFY26 Partner Award Japanは、2026年5月に発表されました（出典：Okta Japan「FY26 Partner Award Japan」）。
IIJとIIJグローバルソリューションズはOkta Platformで表彰されています。NTTデータはAuth0、JBCCは新規顧客開拓で、それぞれ表彰を受けています。受賞歴は決め手ではなく、候補を絞るための材料です。
フェーズ3：設計・開発での属性と権限の流れの実装
Universal Directoryに持たせる属性と、その情報を受け取るシステムを決めます。
- 本人を識別するキー：社員番号とメールアドレスのどちらを使うかを選びます。
- 組織属性：組織と役職の情報源を決め、勤務地と雇用区分の扱いも定めます。
- 更新処理：主キー、更新ルール、重複時の処理を定めます。
表示名の変更と本人の同一性の判定を混同すると、異動やメール変更で別アカウントが作られてしまいます。
アプリ連携では、SSOの設定に加えて、アプリのロールとOktaのグループをどう対応させるかも設計します。
SCIMで自動作成したアカウントに過剰な権限が付かないように、初期グループと承認者を決めておきます。例外申請や退職時の削除・停止も、あわせて定めます。
WorkflowsやAPIで人事イベントを連動する場合は、失敗時の再実行や重複登録を確かめます。API停止やレート制限、機密情報のログ出力も確認事項です。
オンプレミスアプリは、SAML・OIDCに対応させる改修を行うか、Access Gatewayなどで中継するかを比べます。
改修を見送る方法は、短期的には安く見えても、認証方式の制約や障害時の切り分けが増えます。
PoCでは、本番の代表アプリを1〜3個に絞って正常なログインを再現します。さらに、権限不足やMFA紛失、属性不一致を試し、証明書期限切れや旧IDとの重複も確かめます。
フェーズ4：テストでの正常系と異常系の検証
テストでは、ログインだけでなく、属性や権限の連携、退職後の停止まで確かめます。
- SAML：署名証明書とNameIDを確かめるほか、時刻のずれやRelayStateも見ます。
- OIDC：redirect URIとissuerを見たうえで、scopeとトークンの有効期限も確認します。
- SCIM：作成と更新、停止を試したうえで、再有効化や削除、エラー時の再送も試します。
人事マスターから属性が届き、グループの変更がアプリの権限に反映されるかを見ます。
退職処理のあとには、すべてのセッションと連携先アカウントが止まるかも確かめます。
利用者向けには、MFAの登録や端末変更を試すほか、認証器紛失とパスワードリセットも確かめます。
ヘルプデスクでの本人確認の手順も検証します。
管理者向けには、特権アカウントの分離や操作ログ、ブレークグラス用の緊急アクセスを確かめます。
Oktaに入れない場合の連絡経路も、決めておく必要があります。
SIEMが停止したときは、認証を止めるか、一定期間ログをキューに保持するかを、セキュリティ責任者と決めます。
フェーズ5：稼働での段階移行と切り戻し条件の実行
全社を一度に切り替えるより、パイロット部門から順に段階移行する方が安全です。
- 移行順：パイロット部門から始め、主要SaaS、重要アプリ、全社展開の順に広げます。
- 計測項目：ログイン成功率、MFA登録率、問い合わせ件数を見ます。
- 切り戻し：旧基盤の保持期間と、データや権限の二重化を防ぐ条件を決めます。
パイロットでは、認証失敗の原因とプロビジョニングの処理時間も計測します。
並行稼働中は、どちらを正とするか、旧認証をいつまで残すかを決めておきます。
稼働の判定では、業務部門とセキュリティ部門の承認を分けて取ります。
稼働前には、必須アプリへのログインや退職者の停止、管理者アクセスを確かめます。ログ監視と問い合わせ対応も確認します。基準を満たし、重大な未解決障害がないことが稼働条件です。
切り替え当日に向けて、利用者案内、ヘルプデスクの増員、認証器の再登録手順を用意します。
担当者だけが知る手順にしないために、障害時のエスカレーションや時間帯をrunbookに残します。確認者と判断者、連絡先も、同じ場所に書いておきます。
フェーズ6：定着での権限レビューと改善の習慣化
定着させるには、システム管理者が設定を触れる状態を作るだけでなく、稼働後も見直しを続ける必要があります。
- アカウント：未使用のもの、退職者や休職者のもの、共有の利用状況を確かめます。
- 権限：過剰に与えられたものや、管理者向けの付与を見ます。
- 認証と承認：MFA未登録の人や、承認者の異動を押さえます。
- 連携：グループとアプリ側ロールの対応関係が合っているかを確かめます。
棚卸しは月次か四半期ごとに行います。
運用のKPIとしては、ログイン成功率、退職処理の完了時間、権限変更の反映時間を置きます。
このほか、MFA再登録の問い合わせ件数や未使用アカウント数、棚卸し未完了件数も追います。重大なログを検知してから対応するまでの時間も、指標として見ます。
新しいアプリを追加するときは、同じ申請書で接続方式や属性、権限を確かめます。ログとテストのほか、費用と運用担当も同じ申請書で確認します。
稼働後も見直しを重ねて、Oktaを、IDを起点に業務システムを整え続ける共通基盤として運用します。
Oktaのシステム開発費用と相場の目安
Okta費用は、ライセンス費のほかに、初期の要件整理・設計・連携、移行・教育、保守運用がかかります。
公開価格はライセンスの目安です。一方で、初期費用は連携アプリ数や既存IDの状態によって大きく変わります。
以下の金額は、リサーチノートと公式価格、一般的な業務システムの人月単価から整理した参考値で、契約前の確定金額ではありません。
公開ライセンス価格のユーザー数とプランによる試算
Workforce Identityの公開価格は、プランごとの単価に人数を掛けると年額の目安が出る形です。
- Starter：1ユーザーあたり月額940円です。
- Core Essentials：1ユーザーあたり月額2,020円です。
- Essentials：1ユーザーあたり月額2,670円です。
- Professional・Enterprise：個別見積もりです。
年間契約の最低額は240,000円です（出典：Okta「プランと価格」、2026年8月確認）。
Starterを50人で単純計算すると、940円×50人×12か月で年額56万4,000円程度になります。100人なら年額112万8,000円程度です。
同じように、Essentialsを300人で単純計算すると年額約961万2,000円です。500人の場合は年額約1,602万円です。
実際の請求額は、契約期間と対象ユーザーの定義によって変わります。税や為替の影響も受けるうえ、プランやアドオン、販売パートナーの条件によっても変わります。
Identity GovernanceやWorkflowsは、ユーザー数と同じ物差しでは比べられません。APIやCustomer Identityも、追加機能と利用量を分けて見積もります。
初期導入・連携費の幅（100万円台から数千万円以上）
初期導入費は、利用規模と連携範囲によって変わります。次の金額は参考レンジです。
- 小規模PoC：初期費用100万〜300万円程度です。
- 中規模：初期費用300万〜800万円程度です。
- 大規模：初期費用800万〜3,000万円以上の可能性があります。
小規模PoCは、50〜100人でSSO・MFAを使い、SaaSを3〜5個つなぐ場合です。
中規模は、300〜500人でADや人事と連携し、SaaSを10〜30個つなぐ場合です。その想定には、SCIMや移行も含みます。
大規模は、1,000人以上で、複数拠点やレガシーアプリ、APIを含む場合です。SIEMやガバナンスも含みます。
金額には要件整理・設定・検証を含む想定で、これらはOkta公式の導入費ではなく、一般的な参考人月単価と工程工数からの推定です。参考単価は、PMが月90万〜150万円、SEが月65万〜110万円、PGが月50万〜90万円です。
費用を左右するのは、画面数よりも、属性変換や権限マッピング、既存ユーザーの重複解消です。さらに、移行リハーサルやヘルプデスク設計も、費用を押し上げる要因になります。
運用費を左右する保守範囲とアプリ追加の頻度
保守運用にどこまで業務を含めるかで、運用費は変わります。
- 日常運用：Oktaの設定変更、アプリ追加、証明書更新を含め、ユーザーやグループからの問い合わせも対象にします。
- 統制業務：ログ監視とアクセスレビュー、監査資料の作成を、どこまで担うかを確かめます。
- 障害対応：対応時間と、休日・海外拠点の範囲を決めます。
一般的な業務システムの保守費を、初期導入費の年15〜25％程度と置く考え方もあります。
ただし、この割合は認証基盤の重要度や対応時間によって増減する参考値です。24時間監視や休日・海外拠点の対応は、別途見積もります。
Customer Identityの料金は、従業員数ではなく、月間アクティブユーザーやログイン方式で変わります。SMSなどの追加要素や企業向けSSO、API利用量も、費用に関わります。
従業員用と顧客用は同じ単価で合算せず、利用シナリオごとに総保有コストを見ます。
Oktaの見積もりを取るときのポイントとチェックリスト
見積書は、ライセンス費とSI費の合計だけでなく、工程ごとに分けて読みます。
見積もりには、対象ユーザーや連携アプリ、移行方式を明示してもらいます。テストや教育、運用の範囲を書いてもらうほか、契約更新と障害対応も示してもらいます。
安さが作業の除外によるものか、実際の効率化によるものかを判断できます。
RFPに書くユーザー・アプリ・権限の情報
発注前の準備では、ユーザー総数だけでなく、対象者の内訳や拠点・子会社・取引先の有無を整理します。
- ID・業務情報：入社・異動・退職のマスターと既存IDの重複を、RFPに示します。
- アプリ・連携：対象アプリごとの利用人数と、SAML・OIDC・SCIM・APIへの対応状況を記します。
- 運用・期限：MFA方式とログ保存先、監査要件を書き、希望稼働日も添えます。
オンプレミスの制約やパスワードレスの希望も記載します。メール変更の履歴は、分かる範囲で示します。
各社には、標準コネクタの対応数や個別開発の範囲を質問します。属性変換と権限マッピングを誰が担当するかも、聞いておきます。
移行リハーサルの回数、MFA紛失時の本人確認、Okta障害時の運用も、具体的に書いてもらうよう求めます。
設定とコードの引き渡し、稼働後の月次作業も確かめておきます。
前提や除外が書かれていない「対応可能です」という回答は、再見積もりのリスクを高めます。
発注先の比較軸は実装と運用の体制
導入会社は、実装の実績と運用体制を合わせて比べます。
- 専門性：Okta資格者の人数や、Workforce・Auth0それぞれの得意分野を確かめます。
- 連携・移行：AD・人事・ERP・SIEMとの連携や、レガシーアプリの実績を見ます。
- 運用体制：PoCや移行の経験、ヘルプデスク、監視の範囲を確かめます。
大規模な社内統合では、複数拠点や子会社をまとめるプロジェクト管理力が問われます。
顧客向けサービスでは、認証画面のUXや会員移行を評価します。ソーシャルログインやAPIの扱いも、比べる項目になります。また、個人情報の同意管理も、顧客向けサービスの評価項目です。
少なくとも2〜3社には、同じRFPを渡して同じ前提で比べます。
比べる観点は、要件整理の深さやリスク指摘、除外範囲です。
テスト計画や文書の品質、稼働後にどこまでを誰が受け持つかも見ておきます。
最安の会社が最適とは限りません。権限設計や移行計画が薄いと、後から追加開発や運用の負荷が生じます。
契約前に確認するセキュリティ・法務・障害時の前提
海外クラウドでは、データの保管場所に加えて、個人データの取扱いや管理者のアクセス国を確かめます。
- 委託先：再委託先の有無と、サービス提供者による個人データの扱いを押さえます。
- 契約終了：契約が終わったあとに、データを削除・返却できるかを確かめます。
- 外国制度：国内サーバでも、特定個人情報の安全管理や外国制度の把握が必要になることがあります。
個人情報保護委員会も、外国事業者のクラウド利用について説明しています。そのため、国内サーバだから法務の確認は不要と決めつけず、個人情報担当者と契約やデータの流れを確かめます。
障害に備えて、Oktaに入れない管理者の連絡先や緊急用アカウントの保管・監視を決めておきます。
既存の認証を一時的に残すかどうか、アプリ側に緊急停止の手段があるかも定めます。
復旧手順は年1回以上訓練し、証明書やAPIトークン、管理者の連絡先も確かめます。
バックアップの設定が古くなっていないかも見直します。
Oktaのシステム開発でよくある質問
導入前によく質問される点を、対象ユーザー、既存環境と合わせて整理します。
運用責任や費用の前提も、押さえておきます。
Oktaは自社で開発するのですか、それとも導入するのですか？
通常はOktaの認証・ID管理機能を使い、自社アプリにSAMLやOIDCなどを組み込んで連携します。Okta本体は作らず、業務固有の画面や権限ロジックを自社で開発する構成が現実的です。
独自実装を広げると、脆弱性対応や監査、法改正への追随を自社で担うことになります。そのため、標準機能を優先します。
Oktaの導入にはどのくらいの期間がかかりますか？
導入期間は規模や既存環境で異なり、次の期間が参考になります。
- 小規模PoC：1〜3か月です。
- 中規模：AD・人事連携と複数SaaS導入で2〜6か月です。
- 大規模：レガシーアプリや複数拠点を含む場合、4〜12か月が目安です。
J:COMの事例では、4つの基幹システムの認証をOktaに統合しました。従来5〜6か月かかっていた認証機能の開発を、2〜3か月で対応できたと紹介されています（出典：Okta「J:COMが基幹システム群の認証をOktaで統合」）。
既存ユーザーの重複解消や利用者教育まで含めると、期間は設定作業だけの場合より長くなります。
Oktaの料金とシステム開発費は別に考えるべきですか？
別々に考えるのが基本です。公開価格で計算できるライセンス費のほかに、要件整理や連携の設定・開発が発生します。さらに、移行とテストの費用がかかります。教育と保守運用の費用も、別に見ておきます。
Starter月額940円やEssentials月額2,670円だけで予算を組まないよう注意してください。ユーザー数やアプリ数、追加機能に加えて、初期工数と年間の運用工数を合算して考えます。
既存ユーザーを止めずにOktaへ移行できますか？
段階移行と並行稼働を設計すれば、一度に利用者を止めずに進められる可能性があります。
- 社員番号などの不変キーで照合して、重複や無効ユーザーを整理し、共有アカウントやメール変更の扱いも決めます。
- パイロット部門でログインと権限を確かめ、切り戻し条件を決めてから範囲を広げます。
- 旧認証の保持期間と、最終的な停止責任者を決めます。
まとめ：Oktaのシステム開発の6フェーズと段階的な進め方
Okta導入は、6つの段階を順に進めます。要件整理から始め、製品・方式の選定と設計・開発を経て、テストに進みます。その後、稼働と定着へと移ります。
まずWorkforce IdentityとCustomer Identityを分け、管理するIDの対象を決めます。
アプリに合わせて、SAMLやOIDC、SCIMを選びます。APIなどの方式も含め、認証と属性・権限を設計します。
退職者停止、監査ログ、障害時の復旧も設計対象です。
重要アプリを絞った6フェーズの一周
重要アプリを1〜3個に絞り、要件整理から定着まで一通り実証してから、全社展開へ進みます。
成功率に加えて、退職者停止やMFA紛失、権限変更を確かめます。ログ監視やヘルプデスク対応も確認したうえで対象を広げると、後戻りの工数を抑えられます。
RFPと現状アプリ一覧の準備
発注前には、RFPの材料をそろえ、予算の見当を付けておきます。
- 現状整理：ユーザー属性のマスターから運用体制までを一覧にします。
- 見積もり依頼：同じ条件で2〜3社に相談し、ライセンス費と導入・移行費、保守・障害対応の費用を分けて出してもらいます。
- 小規模PoC：50〜100人の場合、初期100万〜300万円程度が参考です。
- 中規模導入：300〜500人の場合、300万〜800万円程度が参考です。
- 複雑な大規模案件：800万〜3,000万円以上が参考です。
金額は、対象アプリと既存IDの状態によって変わります。比べるときは、工程と前提をそろえ、除外範囲と運用範囲も同じ条件で確かめてください。
アクセスレビューやMFA再登録を続けます。アプリ追加やログ監視、障害訓練も継続して、認証基盤を定着させます。
まず重要アプリを1〜3個選び、利用者と運用担当者が使えるPoCを行うことが、無理のない全社展開につながります。
▼全体ガイドの記事
・Oktaのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。