IAM（認証・認可）システムの発注は、まず発注形態を選び、RFPで対象範囲を整理してから、契約と委託先を決める流れで進めます。
工程ごとの全体像は、IAM（認証・認可）システム開発の完全ガイドでも確認できます。
▼全体ガイドの記事
・IAM（認証・認可）システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
IAM（認証・認可）システムの発注・外注の全体像
IAMの発注先は、支援領域によって大きく3タイプに分かれます。
- IDaaS支援会社：クラウドIDaaSの導入支援を専門に扱います。
- 大規模SI会社：基幹システムとの統合まで含めて担います。
- 一気通貫の支援会社：コンサルティングから開発まで一貫して支援します。
現状把握がまだ済んでいない段階か、方式を決めたあとに実装を任せる会社を探す段階かで、適した発注先は変わります。
何を発注すべきか分からないときは、現状調査と要件定義だけを小さく先行発注する方法があります。そのうえで対象範囲を定め、本開発の相見積もりを取る二段階の方式が現実的です。
部門横断の案件では、最初の要件整理に想定以上の時間がかかることが多いため、スケジュールに余裕を持たせてください。
発注形態の種類
発注の進め方は、要件の確定度や導入する製品に合わせて選びます。
- 先行発注：現状調査と要件定義を先に依頼します。
- 一括発注：要件定義から設計、開発、移行までを、まとめて任せる形です。
- 段階契約：PoCの結果を踏まえて、次の契約に進む方式です。
IAMは部門ごとに業務要件が異なりやすいため、いきなり一括発注せず、要件定義を先に行って対象範囲を確定させてから発注すると、リスクを抑えられます。
クラウドIDaaSを使う場合は、製品ベンダーの認定パートナーに設定や連携を依頼する方法があります。
一方で、製品を限定せず、SI会社に要件定義から一貫して任せる方法もあります。
外注が向くケースと内製が向くケース
専門知識が要る作業は外注し、業務ルールや運用の判断は自社に残しておくと、責任の所在がはっきりします。
- 外注に向く作業：プロトコル連携や認可モデルの設計
- 自社に残す判断：業務ルールとロール設計
- 自社に残す運用：退職・異動時の運用フローの最終判断
IAMでは、SAML・OpenID Connect・OAuth 2.0・SCIMなどの知識に加えて、RBAC/ABACの設計経験も求められます。そのため、外部の専門会社に外注するケースが多くなります。
複数のSaaSやレガシーシステムとの連携、監査ログの設計、非人間ID（NHI）の管理方針は、経験のある会社に相談すると、手戻りを減らせます。
RFP・要件整理の進め方
RFP（提案依頼書）の完成度は、見積もりの精度と提案の質を左右します。そのため、IAM特有の項目を書き込み、発注後の食い違いを防いでおくことが大切です。
対象範囲とデータ項目の明記
RFPには、対象範囲が分かる項目を必ず入れます。
- 対象ID：人間と非人間IDの内訳を示します。
- 連携アプリ：標準プロトコル対応済みのアプリと、独自APIでの連携が要るレガシーアプリを分けます。
- 認証・認可：プロトコル、属性マッピング、MFA方式、ロール/属性認可の内容。
- ログ：監査ログと保存期間を記載します。
対象IDは、ユーザーだけでなく、たとえばサービスアカウントやAPIキーも含めて洗い出します。さらに、連携アプリを標準対応と個別連携に分けて示しておくと、各社の提案条件をそろえやすくなります。
非機能要件と監査・可用性の記載
運用条件や終了時の扱いまでRFPに書いておくと、提案内容をそろえて比べられます。
- 運用・移行：移行、教育、運用分界、検収条件を記載します。
- 可用性・監査：可用性、DR、監査対応の条件を示します。
- データ：契約終了時のデータ返却を定めます。
- SaaS利用：保管場所と、障害時の代替認証の扱い。
本人情報や認証ログをSaaS事業者に預ける場合は、各社に同じ条件で回答してもらうと、稼働後の食い違いを防げます。
価格だけに頼らない提案評価
価格に加えて、接続の実証方法と変更時の条件を評価します。
- PoC：連携可否を実証できるかを見ます。
- 追加費用：単価表が提示されているかどうか。
- 変更管理：変更時のルールが明示されているか。
レガシーシステムとの接続は、提案書だけでは可否を判断しにくいことがあります。そのため、実データや匿名化したデータでの接続確認を、評価に含めておきます。
スケジュールと検収条件の具体化
提案の前提がそろわないと、各社の見積もりを比べられません。
- 日程：希望する開始時期を記載します。
- マイルストーン：各段階の完了目標を示します。
- 検収：成果物の判定基準を定めます。
- 移行条件：PoCから本開発への移行時期と、段階導入の各フェーズの完了基準を文書にまとめます。
検収条件が曖昧だと、成果物の完成度や追加対応をめぐる交渉が長引く原因になります。
未確定の項目をすべて埋めず、決定期限と仮定条件をRFPに記載します。そうすると、各社が同じ前提で提案でき、仕様変更時にも見積もりとの差分を説明しやすくなります。
契約形態と費用相場
契約形態と費用感をつかんでおくと、発注後の交渉を進めやすくなります。
請負と準委任の使い分け
成果物を定めやすい工程と、作業の形を固定しにくい工程とで、契約を使い分けます。
- 請負：設計・開発・テストなど、成果物と完成・検収条件が明確な業務に適します。
- 準委任：作業範囲と体制を定め、成果を固定しにくい現状調査や要件整理などに使います。
- 段階契約：要件定義を準委任、設計・開発を請負に分ける方法です。
権限モデルは着手前には見えにくいため、IAMでは要件定義を準委任、設計・開発を請負とする段階契約も有効です。そのうえで、要件定義の成果物を次の工程の見積もりにどう使うかも決めておきます。
契約書には、中止時の引き継ぎとデータ返却を明記します。知的財産や再委託、責任分界も、同じ契約書で決めておきます。
発注規模別の費用感
IAMの発注費用は導入範囲によって変わるため、規模ごとの費用と期間を見比べて予算を考えます。
- 小規模PoC・最小構成：100万〜300万円、1〜2か月です。
- 部門導入・中小規模：300万〜800万円、2〜4か月です。
- 中規模・複数部門：800万〜2,000万円、3〜6か月です。
- 大規模・全社/複数法人：3,000万〜1億円程度、6〜12か月以上です。
この金額は、対象ID数や連携数、レガシー比率から組み立てた記事用の推定です。国内IAMに一律の公定価格があるわけではありません。
ライセンス費とは別枠にし、導入・連携開発・移行・教育・運用を分けて見積もると、発注後も予算の内訳を把握できます。
発注前に対象範囲を確定し、個別見積もりで金額を確認してください。
複数部門で発注する場合は、予算を取る時期がずれることがあります。そのため、全体の日程と予算の確保をあわせて計画します。
委託先選定と見積比較のポイント
委託先は価格だけでなく、実績や体制、稼働後の運用まで評価します。
実績と担当技術者の確認
「大手なら安心」と知名度で決める前に、実際に担当する技術者の経験と、稼働後の保守体制を確かめておきます。
- 実績：同規模・同業種の事例があるかを確かめます。
- 技術者：製品認定の有無と、担当者の経験。
- 運用：SLA、窓口、契約終了時のデータ返却の取り決め。
稼働後に誰が保守を担当するのかも、発注前に聞いておきます。
見積比較と連携単価の確認
ベンダー名で比べるのではなく、見積もりの中身を項目ごとにそろえて見ます。
- 連携単価：アプリ連携1本あたりの費用。
- 作業範囲：標準コネクタと権限設計の支援範囲。
- 責任分界：障害時の対応責任の所在。
特に、連携アプリが多い企業では、単価の差が総額に大きく響きます。そのため、単価表の提示をあらかじめ求めます。
稼働後の運用引き継ぎ体制の確認
長く運用することを考えると、引き継ぎや契約終了時の手順は、事前に決めておく必要があります。
- 担当交代：異動・退職時の引き継ぎ方法。
- 追加改修：追加見積もりの方法。
- 成果物：ドキュメントの整備範囲。
- 契約終了：データ返却とアカウント削除の手順。
これらを契約前に確認すると、長期運用でのトラブルを防ぎやすくなります。
再委託構造とセキュリティ体制の確認
本人情報や認証ログを扱うため、作業の一部を再委託している場合は、再委託先を含めて管理の状況を確かめます。
- 再委託：委託先の範囲と、データへのアクセス権を確かめます。
- 監査：監査権限と実施方法。
- セキュリティ：開発環境、運用端末、脆弱性対応の状況。
- 事故対応：報告フローと責任分界を明確にします。
委託先が複数の階層にわたる場合は、事故時の連絡経路も明確にしておきます。
よくある質問（FAQ）
IAMの発注や外注について、企画段階でよくある質問を紹介します。
RFPを作らずに相談してもよいですか？
初回相談はRFPがなくても可能です。正式な見積もり比較の前には、対象ID数と連携アプリ数を整理したRFPを用意することをおすすめします。認証方式や権限モデルも、同じRFPに含めておきます。
RFPなしで複数社に依頼すると、提案の前提が異なり、公正な比較が難しくなります。
複数の会社に分けて発注することはできますか？
分割発注は可能ですが、認証基盤と認可設計の責任分界が曖昧になり、障害時にどちらの責任か切り分けにくくなるおそれがあります。
分けて発注する場合は、連携仕様とエラー時の対応フローを先に決めておきます。また、両社が同じ情報を共有できる体制も整えておくと安心です。
契約期間はどのくらいを想定すればよいですか？
開発期間は対象範囲により1〜12か月以上と幅があります。
運用保守契約は1年単位で更新するケースが一般的です。
IAMは制度改定やSaaSの仕様変更に、継続して対応する必要があります。そのため、開発だけでなく運用保守を含めた契約を検討するとよいでしょう。
契約終了時にデータはどう扱われますか？
データの返却と消去の方法は、契約前に確かめておきます。返却の形式とベンダー側の消去期限は、契約書に明記してください。
ID・権限データ、監査ログ、設定情報の扱いを決めておくと、ベンダー変更時の混乱を防げます。
発注前に自社で何を準備しておくべきですか？
対象ユーザー、アプリ、サービスアカウントの一覧を準備します。現行の権限管理ルールも整理しておきます。
既存ディレクトリやIDソースの構成図も、可能な範囲で用意します。資料がそろえば調査にかかる時間を短くでき、費用と期間を抑えることにつながります。
まとめ
IAMシステムの発注では、対象範囲を示すRFPを用意し、要件の確定度に応じて請負と準委任を使い分けます。委託先は価格だけでなく、実績や運用体制も見て評価しましょう。
発注で優先する三つのポイント
発注前にそろえる要件と、選定で確認する項目を整理します。
- 要件整理：対象ID・アプリの範囲、認証方式と権限モデル、監査要件をRFPに記載します。
- 契約選択：要件の確定度に応じて請負と準委任を使い分け、段階契約も選択肢に入れます。
- 委託先評価：委託先の実績や担当技術者、運用体制を確認し、終了時のデータ返却も見ます。
RFPのたたき台作成の進め方
RFP案を起点にすると、IAMの発注は順を追って進められます。
- RFP案：対象IDとアプリの一覧、権限モデルを一枚にまとめた案。
- 先行発注の検討：現状調査と要件定義を先行発注する方法を検討したうえで、複数社への同条件の提案依頼。
- PoCと契約：PoCでの連携検証、契約形態、稼働後の運用体制の確認。
RFP案には、プロトコルと監査・可用性の要件も含めます。また、一社に急いで絞らず比較に時間をかけることが、長期の運用コスト削減につながります。
▼全体ガイドの記事
・IAM（認証・認可）システム開発の完全ガイド
▼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を創業。