Oktaのシステム開発の発注/外注/依頼/委託方法について

Oktaのシステムを発注・外注するなら、Oktaを導入するだけでなく、ユーザー情報、認証ポリシー、業務アプリ連携、移行、運用までを含めて設計し、要件と責任範囲を明確にすることが重要です。

Oktaは、企業が認証基盤をゼロから開発するための製品ではなく、クラウド型のアイデンティティ・アクセス管理サービスです。そのため、発注先を探すときは「Oktaを扱える会社」だけでなく、Workforce IdentityとCustomer Identityの切り分け、RFP・要件整理、SAML・OIDC・SCIMなどの連携、既存IDからの移行、契約後の運用まで支援できるかを確認する必要があります。本記事では、Oktaのシステム開発を発注・外注する担当者に向けて、発注形態、要件定義、契約形態、2026年時点の費用相場、委託先選定と見積比較のポイントを順番に解説します。

▼全体ガイドの記事
・Oktaのシステム開発の完全ガイド

Oktaのシステムを発注・外注する前に知る全体像

Oktaのシステムは、ユーザーの認証だけでなく、誰にどのアプリへのアクセスを許可し、異動や退職のときにどの権限をいつ変更するかまでを管理する仕組みです。発注時に「SSOを導入したい」とだけ伝えると、ログイン画面の設定は完成しても、入社・異動・退職処理や管理者権限、監査ログ、障害時の復旧が残ってしまいます。最初に導入対象と成果物を分解することが必要です。

従業員、契約社員、取引先担当者などが社内SaaSや業務アプリを使う場合は、Okta Workforce Identityが中心になります。一方、会員、患者、購入者など社外のユーザーがWebサービスやスマートフォンアプリへログインする場合は、Customer Identity、一般にAuth0を含む顧客向けの構成を検討します。両者はユーザーのライフサイクル、認証画面、利用規模、求められる開発体制が異なるため、RFPの冒頭で対象者を明記します。

たとえば、従業員のMicrosoft 365やSalesforceへのSSOはWorkforce、顧客向けの注文サイトの会員ログインはCustomer Identityという整理です。セイコーエプソンがグローバルで展開する顧客向けサービスの認証基盤にAuth0を採用した事例もあり、顧客IDを複数のサービスへつなぐ目的で使われています（出典：Okta「セイコーエプソンがグローバルで展開する顧客向けサービスの認証基盤にOktaのAuth0を採用」、2025年）。

Oktaのシステムでは、認証にSAMLまたはOIDC、ユーザーや所属情報の同期にSCIM、細かな業務連携にREST APIやWorkflowsを使う構成が基本です。オンプレミスの古いアプリケーションにはAccess Gatewayなどを検討します。標準プロトコルを選べば、アプリ側の実装とOkta側の設定を分けやすくなり、将来の改修や委託先変更にも対応しやすくなります。

認証画面、ユーザー属性、権限判定、ログ監視をすべて独自開発すると、脆弱性対応や仕様変更の負担が増えます。Oktaに任せる範囲は認証・認可・ライフサイクル管理とし、アプリ固有の業務ロジックや画面だけを自社開発するハイブリッド構成が現実的です。委託先には、なぜ標準機能で足りないのか、独自実装の保守費はいくらかを説明してもらいます。

Oktaの導入後には、アプリ追加、認証ポリシー変更、証明書更新、ユーザー属性の修正、アクセス権の棚卸し、ログの確認、ライセンス増減が発生します。構築だけを納品物にすると、社内担当者が設定を変更できず、毎回スポット費用がかかることがあります。発注時点で、運用手順書、管理者教育、問い合わせ窓口、障害時の切り分け、月次レビューを含めるか決めます。

Oktaの発注形態はどれを選べばよいですか？

発注形態は、社内に認証基盤の担当者がいるか、対象アプリとユーザー数が固まっているか、移行を安全に進めたいか、稼働後の運用を誰が担うかで決めます。結論として、対象が少なく社内に専門人材がいる場合はライセンス契約と初期設定支援、複数の業務システムや既存IDをまたぐ場合はSIerへの段階的な導入委託が向いています。

SSOとMFAを数個のSaaSへ導入するだけで、ユーザー台帳やActive Directoryの状態も整っているなら、Oktaのライセンスを契約し、初期設定や管理者教育だけを外注できます。費用と責任範囲を小さく始められますが、既存IDの重複、退職者の残存アカウント、アプリごとの権限設計は発注者側で確認しなければなりません。

この形態を選ぶ場合は、外注先に依頼する作業を「テナント初期設定」「認証ポリシー作成」「SAML/OIDC連携」「MFA登録支援」「テスト」「操作説明」のように細分化します。設定後の問い合わせ、障害時の一次切り分け、Oktaサポートへの連絡代行、アプリ追加の単価も見積書へ記載してもらいます。

人事システム、Active Directory、複数のSaaS、オンプレミスアプリ、SIEMなどを一つにつなぐ場合は、要件定義から移行・運用までをSIerへ委託する方法が適しています。認証基盤だけでなく、ネットワーク、アプリ開発、セキュリティ監視、利用者教育も関係するため、各社の責任分界を一つの計画にまとめやすくなります。

ただし、一括委託でも丸投げにはしません。現状調査報告書、構成図、属性設計書、アプリ連携一覧、テスト仕様書、移行計画、切り戻し手順、運用手順書、管理者アカウントの引き渡しを成果物として明記します。業務部門が承認する権限設計や、退職者をいつ無効化するかという業務ルールは、発注者が最終決定する必要があります。

Oktaの導入経験が少ない、古い業務アプリが多い、MFAを全社へ一度に展開するのが不安という場合は、PoC、基本設計、本番展開、運用引き継ぎを分けて発注します。最初のPoCでは、代表的なSaaSを1〜3個、対象ユーザーを限定し、ログイン、MFA登録、属性同期、権限変更、アカウント無効化、障害時の代替手段を確認します。

PoCの合格条件は「ログインできた」だけにしません。利用者が迷わず登録できるか、退職処理が想定時間内に反映されるか、アプリ側の認可が正しく動くか、ログが監査に使えるか、Oktaや連携先が一時停止した場合に業務をどう復旧するかまで確認します。PoC結果を次工程のRFPへ反映すると、本番見積の精度が上がります。

RFPと要件整理はどこまで準備してから発注しますか？

RFPは完成した設計書である必要はありません。複数社が同じ前提で提案・見積できるように、現状、目的、対象範囲、制約、期待する成果、希望スケジュール、選定基準を整理します。特にユーザー数だけを伝えると、アプリ連携や移行、運用が含まれない安い見積が出やすいため、作業範囲と受入条件まで書くことが大切です。

現状調査では、従業員、契約社員、派遣社員、取引先などのユーザー区分、所属、役職、勤務地、雇用状態を一覧化します。人事システム、Active Directory、LDAP、Google Workspaceなど、どのシステムがマスターかも決めます。氏名やメールアドレスが一致しない場合の名寄せルール、重複アカウント、共有ID、特権ID、退職後も残っているアカウントを洗い出します。

アプリ側は、名称、利用部門、利用者数、認証方式、SAML・OIDC対応の有無、プロビジョニング方式、権限の持ち方、管理者、停止可能時間、監査ログの要件を記載します。連携先が30個ある場合でも、最初からすべてを同じ優先度にせず、重要度、利用者数、移行難度、停止リスクで段階を分けると、現実的な計画になります。

認証要件には、パスワードポリシー、MFAの対象、認証器、端末条件、社外アクセス、管理者の追加認証、緊急時のブレークグラスアカウントを記載します。認可要件には、誰がどのアプリのどの機能を使えるか、職務変更時に権限をどう剥奪するか、申請・承認・棚卸しを誰が行うかを記載します。認証できることと、適切な権限で操作できることは別の要件です。

2025年のOkta調査では、日本のOktaユーザー企業のMFA導入率が53%から62%へ9ポイント上昇し、Okta FastPassの導入率も13.8%から25.0%へ増加しました（出典：Okta「The Secure Sign-In Trends Report 2025」、2025年）。RFPではMFAを付けるかどうかだけでなく、フィッシング耐性、利用者登録、端末紛失、スマートフォン変更、ヘルプデスク対応まで要件化すると、導入後の混乱を抑えられます。

既存の認証基盤から移行する場合は、ユーザーID、メールアドレス、属性、グループ、アプリの設定、パスワードを移せるかを確認します。パスワードを移行できない場合の再登録方法、旧認証基盤との並行期間、利用者への告知、切り替え時間、切り戻し条件を計画に入れます。移行順序は、影響が小さい検証環境から始め、パイロット部門、主要SaaS、レガシーアプリ、全社展開へ進めると安全です。

受入条件は「Oktaの設定が完了した」ではなく、「対象ユーザーが指定アプリへログインできる」「異動で不要な権限が外れる」「退職処理後に指定時間内で無効化される」「監査担当者がログを検索できる」のように業務シナリオで表現します。PoC・移行リハーサル・本番切り替えのそれぞれに合格条件を置くと、未解決の例外を本番へ持ち込まずに済みます。

Oktaの契約形態はどう組み合わせますか？

Oktaの発注では、製品ライセンスのサブスクリプション契約、導入・開発の委託契約、稼働後の保守・運用契約を分けて考えます。要件が固まっていない調査段階から本番構築までを一つの固定価格にすると、対象アプリの追加や属性設計のやり直しが変更扱いになりやすいため、工程ごとに契約と検収を設定する方法が適しています。

請負契約は、要件定義書、設計書、連携設定、管理画面、移行作業、テスト報告書、運用手順書など、完成させる成果物と受入条件を合意できる工程に向いています。固定価格で予算を管理しやすい一方、想定外のアプリ仕様、古い認証方式、データ不整合、追加のMFA支援が発生すると、追加見積になりやすい点に注意が必要です。

契約書や仕様書には、対象ユーザー数、アプリ数、環境数、連携方式、作業時間帯、納品物、試験範囲、瑕疵への対応、変更管理、再委託、秘密情報の扱いを記載します。特に「アプリ連携一式」のような表現は、対象数や方式が曖昧です。1アプリごとの設定・試験・ドキュメントを単位にした方が、追加費用の判断がしやすくなります。

準委任契約は、現状調査、要件整理、製品比較、PoC支援、移行計画、運用設計、定例会、アラート分析など、専門家が業務を遂行することを委託する場合に向いています。成果物の完成を保証する契約ではないため、稼働時間、担当者、会議体、報告書、対応時間、発注者が提供する情報を具体的に定義します。

認証基盤の調査では、既存アプリの仕様が分からない、ユーザー台帳の品質が低い、部門ごとに権限ルールが異なるといった不確実性があります。調査とPoCを準委任で進め、結果をもとに本番構築を請負で契約する組み合わせなら、発注者と受託者がリスクを把握しながら次の金額を決められます。

Oktaはサブスクリプション型のため、契約期間、最低契約額、ユーザー数の増減、プラン変更、アドオン、価格改定、請求条件を確認します。保守・運用を外注する場合は、問い合わせ窓口、対応時間、重大障害の通知時間、設定変更の回数、アプリ追加の単価、月次レポート、定期的なアクセスレビューを分けて記載します。

契約終了時のデータエクスポート、ログの保存、設定情報の引き渡し、連携先の切り替え、アカウント削除、削除証明の扱いも確認します。ログやユーザー属性に個人情報が含まれる場合は、データの保管場所、管理者権限、再委託先、事故時の報告、契約終了後の削除期限を法務・情報システム・委託先で確認します。

Oktaの費用相場はいくらですか？

Oktaの総費用は、ライセンス、初期導入・連携、移行、教育、保守・運用に分けて考えます。2026年8月時点でOkta公式のWorkforce Identity価格ページには、Starterが1ユーザー月額940円、Core Essentialsが2,020円、Essentialsが2,670円と掲載されています。ProfessionalとEnterpriseは個別見積もりで、年間契約最低額は240,000円です（出典：Okta「プランと価格」、2026年8月確認）。

公開価格を単純計算すると、Starterは50ユーザーで月額4万7,000円、年額56万4,000円程度、100ユーザーで月額9万4,000円、年額112万8,000円程度です。Essentialsは300ユーザーで月額80万1,000円、年額960万1,200円程度、500ユーザーで月額133万5,000円、年額1,602万円程度になります。これは公開単価を人数に掛けた参考値であり、契約条件、対象ユーザー、プラン改定、アドオン、為替を含む最終見積もりではありません。

StarterにはSSO、MFA、Universal Directory、5個のWorkflowsが含まれ、EssentialsではAdaptive MFA、Privileged Access、Lifecycle Management、Access Governance、50個のWorkflowsなどが追加されます。アプリ数だけでなく、退職・異動の自動化、特権アクセス、アクセス申請、監査要件があるかでプランを選びます。顧客向けAuth0はMAUや機能構成によって料金体系が変わるため、Workforceの単価をそのまま当てはめません。

初期費用は、ユーザー数よりも連携先の数、既存IDの状態、レガシーアプリの有無、移行方式、テスト量、運用設計の深さで大きく変わります。目安として、50〜100人でSSO・MFAとSaaS数個を導入するPoCや小規模構築は100万〜300万円程度、300〜500人で人事・AD連携とSaaS10〜30個を含む中規模導入は300万〜800万円程度、複数拠点・レガシー・API・ガバナンス・SIEM連携を伴う大規模導入は800万〜3,000万円以上のレンジで考えます。

これらはOkta公式の導入料金ではありません。要件定義、設計、設定、アプリ連携、移行、テスト、教育、運用設計を含む一般的な業務システム開発の工数と人月単価から作った推定レンジです（出典：NotebookLM「業務システム全般_16」の開発費・人月単価に関する調査メモ、2026年）。50〜100人なら1〜3か月、300〜500人なら2〜6か月、複雑な大規模案件なら4〜12か月程度が期間の目安ですが、アプリ側の改修や社内承認の期間は別に見込む必要があります。

運用費の参考レンジは、初期導入費の年15〜25%程度です。ただし、この割合は一般的な業務システム保守の目安であり、Oktaの公式料金ではありません。アプリ追加、ポリシー変更、証明書更新、ユーザー属性の修正、アクセスレビュー、ログ監視、ヘルプデスク、障害対応、監査対応のどこまで含むかで金額は変わります。

見積書では、月額の固定運用と、作業ごとの従量費を分けます。たとえば、月次レビューは固定、アプリ追加は1件ごと、緊急対応は時間単価、全社MFA再登録は別プロジェクトという整理です。契約更新前にユーザー数を見直し、使っていないライセンス、退職者の残存、過剰な管理者権限を点検すると、料金とリスクを同時に抑えられます。

委託先選定と見積比較で何を確認しますか？

委託先は、製品を販売できるかだけでなく、認証要件と業務要件をつなげられるかで選びます。2026年5月にOkta Japanが発表したFY26 Partner Award Japanでは、Okta Platform Partner of the YearにIIJとIIJグローバルソリューションズ、Auth0 Platform Partner of the YearにNTTデータ、New-logo Partner of the YearにJBCCなどが選ばれました（出典：Okta Japan「FY26 Partner Award Japan」、2026年5月19日）。表彰は選定材料の一つですが、自社の対象アプリや運用条件への適合を優先します。

候補会社には、Workforce IdentityとAuth0のどちらを多く扱っているか、SAML・OIDC・SCIM・REST APIの実装経験、Active Directoryや人事システムとの連携実績、Access Gatewayを使ったレガシーアプリ対応、SIEMへのログ連携を確認します。BeeXはOktaとのパートナー契約と導入支援サービスを公表し、SCSKもOktaの導入支援を案内しています（出典：BeeX「Oktaとのパートナー契約を締結」、SCSK「Okta」、各社公式情報、2026年8月確認）。

実績を聞くときは、社名や導入件数だけで判断しません。ユーザー数、アプリ数、移行元、プロジェクト期間、担当範囲、障害時の対応、運用開始後の体制、発注者側に残った作業を確認します。可能なら、同じ規模・同じ認証方式の事例について、提案担当者ではなく構築・運用担当者にも説明してもらいます。

見積書は総額の安さではなく、現状調査、要件定義、基本設計、詳細設計、テナント設定、アプリ連携、属性・権限設計、移行、テスト、教育、ドキュメント、運用引き継ぎに分かれているかを見ます。各工程に担当ロール、工数、単価、期間、成果物、検収条件があると、会社間の比較がしやすくなります。

「ユーザー500人」「アプリ20個」だけでは同じ条件に見えても、標準コネクターを使える会社と、独自APIやレガシー連携が必要な会社では工数が変わります。見積の前提に、対象ユーザー数、環境数、アプリごとの認証方式、移行元、社内作業、利用できるテスト環境、作業可能な時間帯、出張の有無、税・ライセンスの扱いが書かれているか確認します。

Oktaは認証を強化するサービスですが、導入すれば自動的に安全になるわけではありません。管理者の分離、最小権限、MFA紛失時の本人確認、ブレークグラスアカウントの監視、監査ログの保存、異常時の連絡、アプリ側の認可不備への対策まで確認します。提案書にセキュリティの前提と、発注者側が実施する作業が明記されていることが重要です。

個人情報を扱う場合は、データ処理の目的、保管場所、アクセスできる委託先、再委託、削除、事故時の報告を確認します。個人情報保護委員会は、外国法人であっても日本国内で個人情報データベース等を事業に用いていると認められる場合は「外国にある第三者」に該当しないことがある一方、法人格やデータの提供先などを個別に判断すると説明しています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」、2026年8月確認）。法的な該当性は自社の法務担当者や専門家へ確認します。

よくある質問

Oktaの発注では、ライセンス価格だけでなく、認証方式、連携、移行、運用、契約終了時の扱いまで確認する必要があります。ここでは、発注前によくある疑問へ直接回答します。

現状調査、RFP作成、要件定義、プラン選定、テナント設定、SAML・OIDC・SCIM連携、ユーザー移行、MFA展開、テスト、教育、運用設計まで外注できます。認証ポリシーや権限ルールの最終承認、個人情報の利用目的、業務上の優先順位は発注者が決め、委託先には設計と実装を任せる分担が適しています。

公開ライセンスの参考価格はStarterが1ユーザー月額940円、Essentialsが月額2,670円ですが、初期導入費は別に必要です。小規模PoCなら導入・連携費100万〜300万円程度、中規模なら300万〜800万円程度、複雑な大規模案件なら800万〜3,000万円以上という推定レンジを、対象アプリや移行条件と合わせて見ます。期間は小規模で1〜3か月、中規模で2〜6か月、大規模で4〜12か月程度が目安ですが、確定額ではありません。

Microsoft 365やAzureを中心に利用し、既存のEntra IDでユーザー・端末・条件付きアクセスを管理している場合は、Entra IDとの役割分担を先に確認します。複数のクラウドや業務アプリを横断した認証・ライフサイクル管理、顧客向けID、Oktaの連携エコシステムが必要ならOktaが候補になります。製品名で先に決めず、対象ユーザー、アプリ、認証方式、運用体制、将来の拡張を同じRFPで比較することが重要です。

完了しません。Oktaは認証やアクセス管理を強化しますが、アプリ側の認可、端末管理、管理者権限、ログ監視、脆弱性対応、利用者教育、障害時の復旧は別途設計が必要です。特に緊急用アカウントを放置したり、退職者の人事連携が遅れたりすると、製品を導入していてもリスクが残ります。

まとめ

Oktaのシステムを発注・外注するときは、Oktaのライセンスを買うことではなく、ユーザー、アプリ、認証、権限、移行、運用を一つの業務システムとして整えることが本質です。Workforce IdentityとCustomer Identityを切り分け、標準プロトコルを優先し、RFPには対象範囲、成果物、受入条件、責任分界を記載します。

発注前には、対象ユーザー、アプリ一覧、認証方式、ユーザー情報のマスター、MFA方針、権限ルール、移行期限、停止可能時間、監査ログ、運用窓口、予算を整理します。費用は公開ライセンス価格、導入・連携費、移行費、運用費を分け、安さだけでなく、見積の前提と将来の変更費まで比較します。

初めから全社・全アプリを固定価格で発注するのではなく、PoCで代表的な連携とMFA、属性同期、退職処理、ログ、障害時の復旧を検証します。その結果をもとに本番の請負範囲と運用の準委任範囲を決め、複数社の提案を同じ条件で比較することが、Oktaのシステム開発を失敗させない進め方です。

▼全体ガイドの記事
・Oktaのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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