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

OpenID Connectのシステム開発は、範囲と責任分界を決め、RFPで要件をそろえてから委託先を選ぶのが基本です。

PoCや段階移行を経てリリースすれば、認証と会員運用の行き違いを抑えやすくなります。全体像は、下記のOpenID Connectのシステム開発の完全ガイドもご覧ください。

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

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

OpenID Connectのシステムを発注する前に知るべき全体像

外注では、認証サーバーの用意と、各サービスを認証基盤へ接続する作業を分けて考えます。OpenID Provider（OP）とRelying Party（RP）の責任も分け、EC、アプリ、店舗端末、CRMのうちどこまでを対象にするかを決めます。

OIDCとOAuthの役割の分け方

OAuth 2.0は、APIなどのリソースへアクセスする権限を委譲する仕組みです。OpenID Connectは、その上に認証の層を加え、ログインしたユーザーを確認するIDトークンやClaimsを扱います。

発注書に「OAuth対応」とだけ書くと、ログイン認証、API認可、ユーザー属性、セッション管理の範囲が曖昧になります。そこで、IDトークンは認証結果、アクセストークンはAPIアクセス権として、要件に分けて記載します。

OP・RP・会員データの境界

OIDCを導入しても、ECと店舗で分かれた顧客マスターが自動で統合されるわけではありません。そこで、メールアドレスを主キーにせず、発行者のissとユーザー識別子subの組み合わせを外部識別子として扱います。

まず、顧客ID、ポイント、注文の正となるシステムを決めておきます。同意と権限についても、正となるシステムを明確にします。さらに、退会、アカウント統合、メールアドレス変更は、誰が担うかをRFPに明記します。本人確認とパスワードリセットも、担当を書いておきます。

OpenID Connectの発注形態の選び方

発注形態は、社内に認証・クラウド・アプリの担当者がいるか、会員移行をどの速さで進めるか、認証障害が業務にどれだけ響くかで決まります。初期費用だけでなく、設計判断や設定、運用ノウハウを社内に残せるかも比べます。

クラウド型ID基盤とSIを組み合わせる形態

発注形態を比べるときは、ID基盤の提供元と、SI会社がそれぞれどこまでを担当するかを確認します。

• Amazon Cognito、Microsoft Entra External ID、Okta/Auth0が候補です。
• Google Cloud Identity Platformも利用できます。
• SI会社には、要件定義、RP改修、会員移行、テスト、運用設計を依頼します。

認証サーバーのパッチや可用性を自社で抱えにくく、利用量に応じた費用へ変えやすい点が利点です。一方で、ベンダー固有の設定や料金に依存するため、データ出力、設定の引き渡し、解約時の移行方法を確認しておきます。

商用製品やOSSを自社環境で運用する形態

KeycloakやRed Hat build of Keycloakを自社クラウドやOpenShiftで運用し、設計と構築、更新、監視は委託先に任せられます。そのぶん、データの保管場所やカスタマイズを、管理しやすい形にできます。

可用性設計と脆弱性対応は、継続して必要です。署名鍵のローテーションやバックアップ復元も、欠かせません。特にOSSでは、誰がセキュリティ情報を確認し、何時間以内に修正するかを保守条件に入れておく必要があります。

PoCから段階的に発注する形態

会員パスワードの移行や複数IdPの統合、アプリSDKとの適合性が不明なら、PoCを先に発注します。

PoCでは、対象をEC画面かアプリ1つに絞ります。そのうえで、認可コードフローとPKCE、IDトークン検証を確かめます。ログアウトや監視、代表的な会員移行も検証します。

PoCの成功条件、本番移行の判断者、検証後に再利用できる成果物を、先に決めておきます。そうしておくと、実験だけが長期化するのを防ぎやすくなります。

RFPと要件整理の決めどころ

RFPは、委託先が同じ前提で提案と見積を作るための資料です。そのため、OIDCの専門用語を並べるよりも、前提となる条件をそろえて書くことが大切です。

業務目的と現状の制約を先に書き、そのうえで対象範囲、必須条件、比較したい方式を分けて記載します。技術方式を一つに絞りすぎると、適したIDaaSや段階移行の提案が出にくくなります。

業務目的と対象チャネルの具体化

「ログインを統合する」だけでなく、改善したい内容を数値と業務条件で整理して書きます。例として、ECとアプリの会員統合や、店舗での会員照会があります。ほかにも、ログイン失敗時の問い合わせ削減、購入途中の再ログイン抑制が挙げられます。

対象チャネル、利用者区分、月間アクティブユーザー数（MAU）は、一覧にして示します。ピーク時の同時利用や国と言語も、同じ一覧に入れます。既存会員DBと外部IdP、MFAやパスキーの要否も、あわせて書いておきます。

プロトコルとセキュリティ要件の明文化

接続仕様と安全要件は、接続先の情報と、認証処理の検証項目に分けて書きます。

接続仕様には、Discoveryのwell-known URLとissuerを記載します。authorization endpointとtoken endpoint、UserInfo、JWKSも仕様に含めます。

• 接続先：認証基盤の接続先情報を仕様書に明記します。
• 連携条件：scope、Claims、redirect URI、client authenticationを仕様で定めます。
• フローと検証：認可コードフローとPKCEを基本に、state、nonce、IDトークンのissuer・audience・署名・期限を確認します。
• 運用・通信：TLS、セッション、ログアウト、トークン失効、鍵ローテーションを受入れ条件として扱います。

IETFのRFC 9700は、2025年1月に公開されたOAuth 2.0のセキュリティベストプラクティスです。Implicit Grantは原則として避け、認可コード方式を推奨しています（出典: IETF「RFC 9700」、2025年）。

決済、金融、本人確認など、高い安全性が求められるAPIでは、FAPI 2.0 Security Profileの適用も検討します。このProfileは、OpenID Foundationが2025年2月にFinal仕様として承認した、高セキュリティAPI向けのものです（出典: OpenID Foundation「FAPI 2.0 Security Profile」、2025年）。

FAPI 2.0は、脅威、規制、接続先の要求に応じて対象を決めます。ただし、すべてのECログインへ一律に適用するものではありません。

会員移行・運用・納品物の記載範囲

RFPでは、移行対象の扱いと、委託後に引き継ぐ成果物をはっきり示します。

• パスワード移行：再認証とメール認証、本人確認、旧IDと新IDの紐付けを、委託先に設計してもらいます。
• 会員データ：重複・退会済み・メール未登録会員、同意情報、購買履歴の扱いを定めます。
• 移行管理：件数、エラー時の再実行、個人情報の保管場所・削除期限・閲覧範囲を明記します。
• 設計・設定の納品：構成図、接続仕様書、Claims一覧、設定値、Infrastructure as Codeやスクリプト。
• 運用の納品：テスト仕様と結果、移行結果、監視設計、障害対応手順、アカウント一覧、引き継ぎ資料。

他社へ保守を移すときに困らないよう、設定を画面の中だけに残さず、エクスポートできる形式で受け取っておきます。

OpenID Connectの外注で選ぶ契約形態と進め方

OIDC案件には、検証しながら進める作業と、仕様を固定する作業が混在します。調査から保守まで一つの契約にまとめず、要件定義・PoC、開発・移行、保守に分けると、成果物と責任の境界を管理しやすくなります。

準委任契約が向く調査・設計・PoC

準委任契約は、専門家の知見や作業時間を提供してもらう形態です。現行調査や認証方式の比較、PoCに向いています。RFP作成支援や技術アドバイザリーも、対象になります。

完成システムの引き渡しを約束する契約とは違うため、担当者と稼働時間、定例会を定めておきます。報告内容と作業記録、秘密情報も決めます。

また、再委託の可否も定めます。検証後は、構築部分だけを請負契約へ切り替える方法もあります。

請負契約の使いどころ：仕様と受入れ条件が固定できる範囲

請負契約は、完成物と検収条件を明確にできる範囲に向いています。たとえば、OIDC接続や画面改修、移行プログラムがこれに当たります。テストや設計書も、完成物として検収条件を決めやすい範囲です。

作業範囲と対象外、前提を仕様書に含めます。納期と検収期間を書き、不具合の扱いと再実施の範囲も入れます。

発注者側のアカウントやデータの提供期限も、仕様書に書き添えます。さらに、認証基盤の制約による仕様変更の管理手順も必要です。

保守契約での認証基盤と業務アプリの責任の分担

保守では、認証基盤の更新やJWKS・証明書の扱いを、別々に記載します。脆弱性対応、監視、ログ調査は、誰が受け持つかを明確にします。会員移行の再実行やアプリ側の不具合も、担当を分けて書きます。

対応時間は、平日日中のみか、夜間・休日も含むかを決めます。一次応答時間と復旧目標、連絡方法も、あらかじめ定めます。さらに、追加作業単価と、クラウド利用料の負担者も決めておきます。

全チャネル停止時に誰が指揮を執るかを、事前に明確にします。候補は、認証会社とSI会社、社内運用、クラウド事業者です。

OpenID Connectの発注からリリースまでの進め方

発注後は、プロトコルの実装に加えて、業務、データ、運用を一つの計画にまとめることが重要です。

小規模な接続なら、短期間で進められます。一方で、チャネルや既存会員が増えるほど、移行リハーサルと障害時の代替手段に時間をかけることになります。

現行調査でのチャネル・IdP・会員DBの洗い出し

対象はECとアプリ、店舗端末です。コールセンターや管理画面も含めます。チャネルごとに、ログイン方式、会員ID、パスワードポリシーを確認します。

外部連携、利用者区分、障害時の業務も、あわせて見ます。顧客、従業員、取引先のIDを同じテナントで扱うかどうかも、確かめます。ソーシャルログインや企業IdPを接続するかどうか、個人情報をClaimsに含めるかも整理します。

メールアドレスを一意キーにしている既存システムは、変更や重複に弱いため、移行前にデータ品質を調べます。

設計・接続・会員移行の段階的な進め方

設計では、OPとRPの配置を決め、redirect URIやscope、Claimsの扱いも定めます。セッションとログアウトに加え、MFAやレート制限も設計の段階で定めます。監査ログと障害時の代替ログインも、あわせて決めておきます。

1. 開発環境でRPを1つ接続して、IDトークンの検証と認可を確認する段階。
2. 旧ログインとの並行期間、初回ログイン時の再認証、移行エラーの再処理を用意します。
3. 問い合わせ窓口を設けたうえで、チャネル単位に段階導入する形です。

既存会員は一度に移さず、移行時の問い合わせにも対応できる体制を整えます。

試験・切替・運用引き継ぎの完了

試験では、ログインが成功するかだけでなく、異常時の動きも確かめます。issuerやaudienceの不一致、期限切れ、鍵更新が対象です。nonceやstateの不一致、PKCE失敗、redirect URIの誤りも試します。

アカウント重複や退会、パスワードリセットも試します。MFA失敗やIdP障害、ネットワーク断も、試験の対象になります。ログへのトークンや個人情報の混入、監視通知も、検証の対象です。

加えて、負荷試験と脆弱性診断、バックアップ復元を受入れ条件に含めます。リリース前に、ロールバックの条件と意思決定者を決めておきます。切替後は、問い合わせの状況と認証失敗率を監視します。

OpenID Connectのシステム開発費用相場と内訳

OIDC専用の国内受託開発費を横断して比べられる公的統計は、確認できません。

この概算レンジは、リサーチノートで整理した業務システム一般の期間と規模感に、OIDC固有の認証連携とセキュリティ試験を加えたものです。既存会員移行や運用設計も加味しています。

実際の見積では、RP数、MAU、会員数を分けて確認します。IdPの数やMFA、店舗端末も、個別に見ておきます。データ移行と可用性、監視時間についても、見積を分けて確認します。

規模別の開発費の幅

費用は対象範囲の広がりに応じて変わるため、規模別の目安を確認します。

• 1アプリPoC：簡易画面、認可コードフロー、PKCE、IDトークン検証、開発環境の監視を確かめる範囲なら、100万〜300万円程度、1〜2か月が一つの目安です。
• EC本番：会員登録、ログイン、メール認証、パスワードリセット、既存会員連携、基本ログを含むなら、300万〜800万円程度、2〜4か月程度で検討します。
• 標準CIAM：EC、スマートフォンアプリ、店舗会員、CRMやポイントをつなぐ場合、800万〜2,000万円程度、4〜8か月程度が概算レンジです。
• 大規模移行：2,000万〜5,000万円以上、6〜12か月程度の場合があります。
• 全社共通ID基盤：周辺基幹の統合を含めると5,000万円〜1.5億円以上もあり得ますが、OIDC単体の価格ではありません。

この目安は、複数ブランド、数百万会員、レガシー認証からの段階移行に加えて、24時間監視、冗長化、セキュリティ診断まで含む場合のものです。

製品料金と受託開発費の分け方

クラウド型ID基盤は、利用条件と料金の根拠を確かめたうえで、受託開発費とは分けて見積もります。

AWS公式料金は2026年8月時点の条件で、次のとおりです（出典: AWS「Amazon Cognito 料金」、2026年確認）。

AWSの事例では、Purinaが14のデジタルサービスと200万人超のペットオーナーを対象に、CIAMを構築しました。

• 料金要因：MAU、方式、フェデレーション、MFA、リスク検知、SMS・メール、ログ保管で変わります。
• 連携料金：50 MAUまで無料、超過分は1 MAUあたり0.015米ドルです。
• 直接ログイン：ユーザー向けには10,000 MAUまでの無料枠など別条件があります。
• 個別事例：導入規模や期間の条件も、あわせて確かめます。

為替やリージョン、追加機能で料金が変わるため、固定の円換算額として予算化はしません。

この事例では、1つのアプリへ4か月で適用されています（出典: AWS「Purina Builds a Strategic Consumer IAM Solution Using Amazon Cognito」、確認日2026年）。AWS資産、対象範囲、体制が異なるため、一般的な納期や費用を保証するものではありません。

製品利用料と送信料、クラウド費用は、開発費や保守費とは分けて見積もります。

運用費と上振れ要因の3年単位の確認

運用費は、保守の目安だけでなく、別枠費用と3年間の利用総額を見て判断します。

• 保守目安：初期開発費の年15〜25％程度を仮置きする方法があり、リサーチノートでの業務システム一般の目安です（OIDC専門の公表統計ではありません）。
• 別枠費用：基盤、WAF、監視、ログ、SMS・メール、脆弱性、鍵管理、障害待機、復元訓練を計上します。
• 上振れ要因：24時間365日、厳格なSLA、複数リージョン、数百万会員の移行で増えがちです。
• 3年総額：製品・クラウド、保守、追加ユーザー、移行再実行、監査、将来のRP追加を合計します。

見積の「一式」に含まれる作業は分けてもらい、MAUの増加時、外部IdP追加時、保守時間外の単価も確かめます。そうしておくと、導入後の予算のずれを抑えやすくなります。

OpenID Connectの委託先選定と見積比較のポイント

委託先は、OIDC接続だけでなく、会員データや業務アプリ、インフラ、保守まで横断して設計できる会社から選びます。会員移行や障害の切り分け、運用担当について、具体的に説明してもらいます。

実績の確認は技術名より担当範囲

委託先の実績は、移行や運用を含む担当範囲に沿って確認します。

• 導入実績：画面の実装数ではなく、複数RPのSSOや会員の段階移行・統合の実績を見ます。
• MFA・パスキー、CRM・ポイント連携、切戻し、監査ログ、24時間運用も確認します。
• 事例の範囲：対象チャネル、会員規模、移行方法、期間、委託範囲、保守体制を匿名化事例で確認します。
• 技術と試験：認可コードフロー、PKCE、state・nonce、issuer・audience、JWKS更新、トークン保管、セッションの確認。
• 個人情報：Claims最小化、アクセス制御、ログのマスキング、再委託、データ所在地を確認します。異常系試験や設定変更手順も見ます。

見積の工程・成果物・前提条件のそろえ方

同じRFPを渡し、各社に工程ごとの見積を出してもらいます。中心になるのは、要件定義、RP改修、会員移行です。

現行調査と基本設計、基盤設定は、同じ区分で含めてもらいます。テストやリリース、文書、保守も含めてもらいます。

見積は、人月だけで比べず、人数と作業週数、外部サービス料金の有無、発注者の作業もそろえます。特に、会員移行や監視が別費用なら、安い提案でも総額は高くなる場合があります。

• 評価軸：価格、要件理解、移行計画、セキュリティ試験、担当経験、納品物、保守、契約条件。
• 配点例：価格25％、技術・セキュリティ25％、実績20％、移行・運用計画20％、提案体制10％。

配点は案件のリスクに合わせて変え、関係部門で合意しておきます。

安価さより責任分界と撤退条件

障害対応が切り離されないよう、責任の境界と契約終了時の条件を確かめます。

• 認証基盤停止：委託先が製品の範囲外として対応しない恐れがあります。
• 外部IdP障害：障害の切り分けと復旧の担当を決めます。
• 鍵更新失敗・移行不整合：復旧指揮と再発防止の責任を明確にします。
• 個人情報の誤表示：調査権限と社内報告の担当を決めます。

OPとRP、API、会員DBの責任分界を図にします。ネットワーク、クラウド、運用窓口も含めます。そのうえで、障害時の一次受付窓口と、調査に必要なログの提供担当も決めておきます。

PoCの中止条件と予算上限、追加費用の承認を確認します。解約時のデータ返却や設定・ソースの引き渡し、再委託の扱いも確かめます。秘密保持と個人情報の削除、保守会社を変える際の支援も確認します。

自社製品だけを前提とする提案なら、代替案を同じ条件で比べます。代替案には、クラウドや商用製品、OSSがあり、段階導入も含みます。最後に、長期的なロックインを判断します。

よくある質問

OpenID Connectの発注では、製品選びや費用、会員の扱い、開発会社の範囲について質問が多くなります。発注前に確かめたい内容に、順に答えます。

OpenID Connectのシステム開発費用はいくらですか？

概算レンジは、1アプリのPoCなら100万〜300万円程度です。EC単体の本番導入なら300万〜800万円程度、複数チャネルのCIAMなら800万〜2,000万円程度です。

会員数やRP数、移行の有無で、金額は大きく変わります。MFAや可用性、24時間保守も、金額を左右します。ただし、公開統計による固定の相場ではなく、要件を分けるための予算の目安です。

既存会員のパスワードはOpenID Connectへ移行できますか？

移行可否は、旧システムのハッシュ方式、ソルト、認証基盤の仕様で決まります。移行できない場合は、初回の再認証やメール認証を組み合わせます。本人確認や、旧IDと新IDの紐付けも加えます。

パスワードを平文で取り出して移す方法は、採用しません。また、移行失敗時の問い合わせ対応と旧ログインの終了時期も、計画に入れます。

Amazon CognitoやAuth0などはどれを選べばよいですか？

選ぶときは、既存のクラウド環境とMAUの変動を基準にします。必要なMFAやソーシャルログイン、データ所在地に加え、運用人材と将来のRP追加も判断材料です。

• AWS中心の環境なら、Cognitoが候補に挙がります。
• Microsoft企業IDやAzure資産と統合するなら、Entra External IDが候補です。
• CIAM専業の機能や契約支援を重視するなら、Okta/Auth0が候補です。
• 自社環境の自由度を重視するなら、Keycloakなどが候補になります。

同じRFPで3年TCO（総所有コスト）と移行・保守体制を比べて、製品を決めます。

OIDCを導入すればセキュリティ対策は十分ですか？

OIDCは認証連携の標準仕様です。ただし、個人情報保護や業務上の認可、端末管理は、導入しただけでは保証されません。監視と脆弱性対応も、自動では含まれません。

PKCEやstate、nonce、署名検証を実装します。TLSやClaimsの最小化も押さえ、認証基盤と各RPを試験します。さらに、鍵ローテーション、レート制限、監査ログを備えます。

個人情報保護委員会のガイドラインを踏まえて、業務設計に組み込みます。対象は、アクセス者の識別と認証、アクセス制御、不正アクセス防止です。通信暗号化やログ分析も含みます。

まとめ

発注では、OIDC接続だけでなく、会員とチャネル、認証基盤、業務認可、運用まで含めた全体像を把握します。

クラウド型ID基盤、商用製品やOSSの自社運用、PoCからの段階発注を比べ、社内体制と障害時の責任に合う方式を選びます。

発注前のRFPと責任分界の整理

RFPには、対象チャネル、MAU、既存会員数を書きます。IdPや会員DB、Claimsも記載します。

PKCEやMFAの扱い、移行方法、監視は、RFPに書いておきます。納品物と受入れ条件も含めます。

見積は、要件定義、接続、会員移行の工程ごとに分けてもらいます。試験、クラウド・製品料金、保守も同じ区分に分け、発注者の作業と追加費用の条件をそろえます。障害時の一次窓口と復旧指揮まで合意し、発注後の行き違いを防ぎます。

最初の一歩は現行調査と小さな検証

全チャネルを一度に切り替えず、RPを1つ選んで検証します。認可コードフロー、トークン検証、ログアウトを確かめ、会員移行と監視も見ます。成功条件を満たしてから、対象を広げます。

製品利用料と開発費を分け、3年TCO、移行の難しさ、保守体制を踏まえて判断すると、目先の安価さだけで選ぶリスクを抑えられます。

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

▼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を創業。