IAM（認証・認可）システム開発の発注/外注/依頼/委託方法について

IAM（認証・認可）システムの発注・外注を成功させるには、RFPに対象ID数・連携アプリ数・認証方式・監査要件を具体的に書き、請負と準委任を業務の確定度で使い分けることが重要です。

「どこに発注すればよいか分からない」「相見積もりを取っても金額の前提がバラバラで比較できない」という悩みは、発注側が要件を曖昧なまま提示していることが原因であるケースが少なくありません。IAMは認証・認可・ID連携・監査という複数の専門領域にまたがるため、発注前の整理が甘いと、各社の提案内容も見積もりも大きくばらつきます。本記事では、IAM（認証・認可）システムの発注・外注・依頼・委託方法について、発注形態の選び方、RFPの整理方法、契約形態、費用相場、委託先選定のポイントを順に解説します。

▼全体ガイドの記事
・IAM（認証・認可）システム開発の完全ガイド

IAM（認証・認可）システムの発注・外注の全体像

IAMの発注先は、大きく分けて「クラウドIDaaSの導入支援を専門とする会社」「大規模SIとして基幹統合まで担う会社」「コンサルティングから開発まで一気通貫で支援する会社」の3タイプに分かれます。自社がどのフェーズにいるか（現状把握が済んでいないのか、方式は決まっているが実装パートナーを探しているのか）によって、適した発注先のタイプが変わります。

発注を検討し始めた段階で多いのが、「まず何を発注すればよいか自体が分からない」という悩みです。この場合は、いきなり本開発を一括発注するのではなく、現状調査と要件定義だけを小さく発注し、そこで見えてきた対象範囲をもとに本開発の相見積もりを取る二段階の進め方が現実的です。特に部門横断のプロジェクトでは、最初の要件整理に想定以上の時間がかかることが多いため、スケジュールにも余裕を持たせておくことをおすすめします。

発注形態には、現状調査・要件定義だけを先行発注する方法、要件定義から設計・開発・移行までを一括発注する方法、PoCの成果を踏まえて段階的に契約を積み重ねる方法があります。IAMのように業務要件が部門ごとに異なりやすい領域では、いきなり一括発注するのではなく、まず現状調査・要件定義を先行させ、対象範囲を確定させてから本開発を発注する進め方がリスクを抑えやすくなります。

また、クラウドIDaaSを主軸に据える場合は、製品ベンダーの認定パートナーに設定・連携作業を依頼する形態と、SI会社が製品を問わず要件定義から一貫して担う形態のどちらを選ぶかも検討事項になります。

IAMのような専門領域は、SAML・OpenID Connect・OAuth 2.0・SCIMなどのプロトコル知識や、認可モデル（RBAC/ABAC）の設計経験が必要になるため、外部の専門会社へ外注するケースが多くなります。特に、複数のSaaSやレガシーシステムとの連携、監査ログの設計、非人間ID（NHI）の管理方針の策定は、経験豊富な会社に相談する方が手戻りを減らせます。

一方で、社内の業務ルールやロール設計の意思決定、退職・異動時の運用フローの最終判断は、外部に丸投げせず自社で担う体制を維持することが望ましい領域です。外注する範囲と内製で残す範囲を発注前に切り分けておくと、運用開始後の責任の所在が明確になります。

RFP・要件整理の進め方

RFP（提案依頼書）の完成度が、見積もりの精度と提案内容の質を大きく左右します。IAM特有の項目を漏らさず記載することが、発注後のトラブルを避ける最大のポイントです。

RFPには、対象ID、対象アプリ一覧、プロトコル、属性マッピング、MFA方式、ロール/属性認可、ログ・保存期間を必ず含めます。対象IDは人間のユーザーだけでなく、サービスアカウントやAPIキーなどの非人間IDも棚卸しし、人間/機械IDの内訳を明記します。対象アプリ一覧では、標準プロトコルに対応済みのアプリと、非標準の独自API連携が必要なレガシーアプリを分けて記載することで、各社の提案がそろいやすくなります。

監査、可用性/DR、移行、教育、運用分界、検収条件、契約終了時のデータ返却をRFPに含めます。特に、SaaS事業者に本人情報や認証ログを預ける場合は、データ保管場所、可用性、障害時の代替認証、監査対応の可否を明記し、各社に同じ条件で回答してもらいます。これらの項目が曖昧なまま発注すると、稼働後に「想定していた監査対応ができない」といった食い違いが起きやすくなります。

提案評価は価格だけでなく、PoCで連携可否を実証できるか、追加費用の単価表と変更管理ルールが明示されているかを確認します。特に、レガシーシステムとの連携可否は、提案書の記載だけでは判断できないことが多いため、実際のデータを使ったPoCや、匿名化データでの接続確認を評価プロセスに含めることをおすすめします。

RFPには、希望する開始時期、マイルストーンごとの完了目標、検収の判定基準も記載します。検収条件が曖昧なままだと、成果物の完成度をめぐって発注者と開発会社の認識がずれ、追加対応の要否で交渉が長引く原因になります。特に、PoCから本開発への移行タイミング、段階導入の各フェーズの完了基準は、契約前に文書化しておくことが望ましいです。

未確定の項目がある場合でも、すべてを埋めようとせず、未確定項目と決定期限、仮定条件をRFPに明記する方法が有効です。各社が同じ前提で提案を作成できれば、後から仕様変更が発生しても、当初の見積もり条件との差分を説明しやすくなります。

契約形態と費用相場

契約形態の選び方と費用感を事前に把握しておくことで、発注後の交渉がスムーズになります。

要件と成果物が明確な設計・開発・テストは、完成条件と検収条件を定めた請負契約が適する場合があります。一方で、現状調査、要件整理、既存データの分析のように、発注時点で成果の形を固定しにくい業務は、作業範囲と体制を定めた準委任契約が進めやすい場合があります。IAMのように、着手前には権限モデルの全体像が見えにくいプロジェクトでは、要件定義フェーズを準委任、設計・開発フェーズを請負とする段階契約も有効な選択肢です。

段階契約を選ぶ場合は、要件定義の成果物が次工程の見積もりにどう使われるか、途中で中止する場合の引き継ぎ、知的財産、データ返却、再委託、責任分界を契約書に明記しておくことが重要です。

発注規模別の目安は、小規模PoC・最小構成で100万〜300万円・1〜2か月、部門導入・中小規模で300万〜800万円・2〜4か月、中規模・複数部門で800万〜2,000万円・3〜6か月、大規模・全社/複数法人で3,000万〜1億円程度・6〜12か月以上です。ライセンス費とは別枠で計上し、導入・連携開発・移行・教育・運用の費用を分けて見積もってもらうことで、発注後の予算管理がしやすくなります。

これらの金額は、対象ID数・連携数・レガシー比率から組み立てた記事用の推定であり、国内IAMの一律公定価格ではありません。発注前に自社の対象範囲を確定させ、個別見積もりで最終的な金額を確認してください。特に、複数部門にまたがる発注では、部門ごとの予算取得のタイミングがずれることがあるため、全体スケジュールと予算確保のタイミングをあわせて計画しておくことも重要です。

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

委託先を選定する際は、価格の比較だけでなく、実績・体制・稼働後の運用まで含めて評価することが重要です。

実際の発注時は、同規模・同業種の実績、製品認定を持つ担当技術者、SLA、運用窓口、契約終了時のデータ返却をRFPで確認します。「大手なら安全」という選び方ではなく、実際に担当するエンジニアの経験と、稼働後に誰が保守するのかまで確認することが重要です。

ベンダー名だけでなく、連携1本あたりの費用、標準コネクタの範囲、権限設計の支援範囲、障害時の責任分界を確認するのが、見積比較における差別化ポイントです。特に連携アプリ数が多い企業では、1本あたりの単価の差が総額に大きく影響するため、単価表を必ず提示してもらいます。

発注時には見落とされがちですが、稼働後の運用引き継ぎ体制も重要な評価項目です。担当者の異動・退職時の引き継ぎ方法、追加改修時の見積もり方法、ドキュメントの整備範囲、契約終了時のデータ返却・アカウント削除の手順を、契約前に確認しておくことで、長期運用時のトラブルを未然に防げます。

IAMは本人情報や認証ログといった機微な情報を扱うため、開発会社が作業の一部を再委託している場合は、再委託先の範囲、アクセス可能なデータ、監査権限まで確認します。あわせて、開発環境や運用端末のセキュリティ管理、脆弱性対応の体制、インシデント発生時の報告フローも、発注前のチェック項目に含めておくと安心です。委託先が複数階層にわたる場合は、事故時の連絡経路と責任分界を明確にしておく必要があります。

よくある質問（FAQ）

ここでは、IAMの発注・外注に関して企画段階でよく寄せられる質問をまとめます。

初回の相談自体はRFPがなくても可能ですが、正式な見積もり比較の前には、対象ID数、連携アプリ数、認証方式、権限モデルなどを整理したRFPを用意することをおすすめします。RFPがないまま複数社に依頼すると、各社が異なる前提で提案するため、金額や内容を公正に比較できなくなります。

可能ですが、認証基盤と認可設計を別々の会社に発注すると、責任分界が曖昧になり、障害発生時にどちらの責任か切り分けにくくなるリスクがあります。分割発注する場合は、システム間の連携仕様とエラー時の対応フローを事前に明確にし、両社が同じ情報を共有できる体制を作ることが重要です。

開発フェーズは対象範囲によって1〜12か月以上と幅がありますが、運用保守契約は1年単位で更新するケースが一般的です。IAMは制度改定やSaaS側の仕様変更に継続的に対応する必要があるため、単発の開発契約だけでなく、運用保守を含めた長期的な体制を前提に契約条件を検討することをおすすめします。

契約終了時のデータ返却・消去の方法は、契約前に必ず確認すべき項目です。ID・権限データ、監査ログ、設定情報をどの形式で返却するか、返却後にベンダー側のデータをいつまでに消去するかを契約書に明記しておくことで、ベンダー変更時の混乱を防げます。

発注前には、対象ユーザー・アプリ・サービスアカウントの一覧、現行の権限管理ルール、既存のディレクトリやIDソースの構成図を可能な範囲で整理しておくことをおすすめします。これらの資料が揃っているほど、開発会社側の現状調査にかかる時間を短縮でき、結果として費用と期間の両方を抑えられます。

まとめ

IAM（認証・認可）システムの発注・外注では、対象範囲を明確にしたRFPを用意し、業務の確定度に応じて請負と準委任を使い分け、価格だけでなく実績・体制・稼働後の運用まで含めて委託先を評価することが成功の条件です。

第一に、対象ID数、連携アプリ数、認証方式、権限モデル、監査要件をRFPに具体的に書き込むことです。第二に、要件の確定度に応じて請負と準委任を使い分け、段階契約も選択肢に入れることです。第三に、価格だけでなく実績、担当技術者、稼働後の運用体制、契約終了時のデータ返却まで含めて委託先を評価することです。

次の一歩は、対象ID・アプリ一覧、プロトコル、権限モデル、監査・可用性要件を一枚のRFPたたき台にまとめることです。この資料をもとに、まずは現状調査・要件定義だけを先行発注する方法も有効です。複数社から同じ条件で提案を受け、PoCでの連携検証、契約形態、稼働後の運用体制まで確認すると、発注後の手戻りを抑えやすくなります。焦って一社に絞り込むのではなく、比較検討にかける時間を惜しまないことが、長期的な運用コストの削減につながります。

▼全体ガイドの記事
・IAM（認証・認可）システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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