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

IAM（認証・認可）システムは、IDの対象範囲、認証・認可の要件、連携先と運用体制を整理してから段階導入すると、継続的な権限管理につながります。

全体像から運用までを順に見ていきます。各テーマの詳細は関連記事もご覧ください。

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

IAM（認証・認可）システムの概要

ログイン確認と操作許可は、別々の判断として並びます。

IAM（Identity and Access Management）は、利用者、端末、サービスアカウントなどのデジタルIDを登録・管理する仕組みです。IDがどの資産に、どの条件で、何をできるかを統制します。

対象は従業員だけでなく、顧客、代理店、協力会社、AIエージェントも含まれる場合があります。そのため、導入ではまず対象範囲を定めることが出発点になります。

認証と認可の違い

認証と認可は役割が違うため、分けて考えるとIAMの仕組みを整理しやすくなります。

認証方式には、パスワードや多要素認証（MFA）があります。ほかにも、パスワードレス認証やFIDO2/WebAuthnなどがあります。

認証（Authentication）：本人や機械が名乗るとおりの存在かを確かめること。
認可（Authorization）：認証済みの相手に許可するデータや操作を判定します。
注意点：「ログインできれば安全」と考えると、退職者や委託先が不要な権限を持ち続ける典型的な失敗を招きます。
要件管理：認証要件と認可要件は別の表で管理します。ロール・属性・例外の責任者を分けておくと、後工程の手戻りを防げます。

認可の設計では、RBAC（ロールベース）やABAC（属性ベース）のモデルを使います。

IAMの対象範囲

IAMは、ID登録・変更・削除や属性管理から、認証、認可、ID連携までを扱います。さらに、アクセス申請・承認、定期レビュー、監査ログも含まれます。

SSOツールの導入は、その一部にすぎません。

連携には、次の方式を使います。

SAML：SSOで使う連携方式の一つ
OpenID Connect：SAMLと同じく、接続先との連携に使う方式
OAuth 2.0：アクセスの許可を連携させる方式
SCIM：ユーザー情報の登録や更新を自動で連携する方式
LDAP/Active Directory：社内のディレクトリと連携する仕組み

サービスアカウント、APIキー、AIエージェントなど、人間以外のID（NHI）も対象です。

今後のIAM開発では、欠かせない領域になりつつあります。

ポイント

IAMの対象は従業員だけでなく、顧客や協力会社、AIエージェントまで広がる場合があります。認証と認可を分けて考え、対象範囲を先に決めてから要件を書き出すと、後の判断で迷いにくくなります。

IAM（認証・認可）システムの主要機能と構成

5領域を並べると、IAMの担当範囲を俯瞰できます。

主要機能は、ID管理・認証・認可・ID連携・アクセス監査の5領域で整理できます。

IDは、人事システムや顧客DB、ADなどのIDソースから、ディレクトリやIDプロバイダーを経由します。その後、認証・認可のポリシーエンジンが判断し、SaaS・社内業務システム・API・クラウド資源へのアクセスを許可する構成です。

ID管理・ライフサイクル機能

ID管理では、登録・変更・削除に加えて、組織、役職、雇用区分などの属性を扱います。

人事システムと連携し、入社・異動・退職に伴うプロビジョニング（権限付与）とデプロビジョニング（権限剥奪）を自動化します。

人事システムとの連携により、次の問題を防げます。

退職者アカウントの放置：退職時に権限を外し、アカウントを残さないようにします
異動後の旧部署の権限：異動に伴い、旧部署で持っていた権限を外します

委託先や派遣社員の期間限定アクセスも、対象に含めます。

認証機能（SSO・MFA・パスワードレス）

必要な認証機能は対象ユーザーによって異なるため、IAMの要件を対象ごとに整理します。

認証機能：SSO、MFA、パスワードレス/FIDO2・WebAuthn、リスクベース認証
対象者：顧客・代理店・協力会社も対象に含むなら、Workforce IdentityとCIAM/EIAMの要件を分けます。

NIST SP 800-63 Revision 4は2025年に最終版が公開されました（出典: NIST SP 800-63 Revision 4 Digital Identity Guidelines、2025年7月）。

同ガイドラインは、同期可能なパスキー、継続的なリスク評価、詐欺・ディープフェイク対策を扱っています。

今後の認証設計では、重要な参照先になります。

認可機能・ID連携（RBAC/ABAC・SAML/OIDC）

IAMでは、権限の決め方とシステム間の連携の両方を設計します。

認可設計：RBAC、ABAC、ポリシーエンジン、特権ID管理、期限付き・承認付きアクセスを設計し、最小権限を実装します。
ID連携：接続先ごとのプロトコル、属性、ログアウト仕様を整理します。
条件付きアクセス：認証結果だけでなく、ユーザー属性、端末状態、場所、時刻、リスクスコアを認可判断へ渡すと、後から要件を追加しやすくなります。

連携方式には、SAML、OpenID Connect、OAuth 2.0、SCIM、LDAP/Active Directoryなどがあり、接続先ごとに使い分けます。

クラウドIDaaS・CIAM・オンプレミス・スクラッチの方式選定

方式は、既存SaaSとの接続数やレガシー資産、データ保管要件、対象が従業員か顧客かで変わります。

初期費用だけでなく、5年程度の運用・改修費を含む総保有コストで比べます。

クラウドIDaaSとCIAMが向くケース

従業員向けか顧客向けかで、IDaaSとCIAMの向き不向きや確認事項が変わります。

クラウドIDaaS：SSO/MFA、ディレクトリ、条件付きアクセスを短期間で導入しやすく、SaaS接続が多い企業に向く
CIAM：顧客向け認証基盤の候補で、ソーシャルログインやB2B組織管理を組み込みやすい

IDaaSでは、カスタム属性や国産レガシー連携、データ保管場所を事前に確認します。障害時の代替策も、導入前に確かめておきます。

CIAM（顧客向け認証基盤サービス）は、API認可もアプリに組み込めます。

MAU（月間アクティブユーザー）課金、SMS/メール送信費は費用に直結します。Bot対策、テナント分離、退会時のデータ削除も、要件に関わります。

パッケージ/オンプレミスとスクラッチが向くケース

方式ごとに適用条件が異なり、導入後に自社が担う運用範囲も変わります。

パッケージ/オンプレミス：閉域・厳格なデータ保管やレガシー統合に適します。
スクラッチ：規制、独自業務、既存資産上の理由がある場合に限定するのが一般的です。
標準製品/API：継続的な運用負担から、組み合わせる方が安全なケースも多くあります。

AD/LDAP、WebSSO、統合認証製品を自社環境で運用する場合は、認証サーバーの運用を自社が担います。可用性の維持、パッチ適用、証明書更新も、自社の作業になります。

スクラッチでは、パスワード保管、MFA、リカバリを継続して自社で担います。さらに、セッションとトークン、鍵管理、監査、脆弱性対応も、自社で続けることになります。

ハイブリッド構成という現実解

クラウドIDaaSを中心に、AD/LDAPや古いWebアプリを連携させるハイブリッド構成が、多くの企業で採用されています。特権管理やSIEMも、同じ構成に組み合わせて使われます。

認証基盤のどこまでを誰が受け持つかと、プロトコル変換用ゲートウェイの保守費を明確にしておくと、長期運用の安定につながります。

ポイント

IDaaS、CIAM、オンプレミス、スクラッチのどれが合うかは、SaaS接続の数と既存資産、対象が従業員か顧客かで決まります。比べる際は、初期費用だけでなく運用・改修の負担まで見込みます。

IAM（認証・認可）システム開発の進め方

前段で整理した条件を次の工程の判断につなげます。

開発は製品選定から始めず、目的と対象範囲の明確化から運用・改善まで、一連の工程で進めます。IDと権限の現状把握を先に済ませておくと、後工程での手戻りを防げます。その工程は、下の3つの節で順に説明します。

現状診断・要件定義

まず、対象ユーザー、アプリ、API、端末、サービスアカウントを台帳にまとめます。IDソースや重複・共有ID、権限、接続プロトコルを確認します。ほかにも、ログやデータ所在地、可用性、障害時の運用を見ておきます。

中心になるのは、認証要件と認可要件を分けたうえで、ロール・属性・例外それぞれの責任者を決めることです。

方式比較とPoC

最重要の5〜10アプリで、MFAやプロビジョニング、退職処理、ログ、復旧を試験します。性能を見るのは後回しにし、まず連携可否や属性マッピングを検証します。ユーザー体験と運用負担も、あわせて確かめます。

検証結果をもとに、クラウドIDaaS、CIAM、オンプレミス、ハイブリッドのどの方式を採用するかを決めます。

段階導入と運用改善

低リスクのSaaSから始め、管理者・特権ID、基幹系、外部委託先へと広げていきます。あわせて、旧認証との併用期間、ロールバック、問い合わせ対応、利用者教育を準備しておきます。

運用後は月次で孤立ID・過剰権限・失敗ログを確認し、四半期から半期ごとにアクセスレビューを行います。KPIには、MFA適用率や退職処理の所要時間、SSO対象率などがあります。ほかに、不要権限の削減数や認証障害の復旧時間も指標になります。

▶ 詳細はこちら：IAM（認証・認可）システム開発の進め方

ポイント

製品選定より先に、目的と対象範囲、IDと権限の現状を整理しておくと、手戻りを減らせます。PoCでは性能より連携可否と属性マッピングを優先して検証します。

IAM（認証・認可）システムの費用相場と内訳

IAMの国内SI費用について、一律に示す公的な価格表は多くありません。そのため、公開されているライセンス価格と、一般的な人月単価・連携工数から組み立てた推定レンジを示します。

推定レンジは、ライセンス費だけを指すものではありません。

規模別の費用レンジ

規模別の推定費用と期間には、次のような幅があります。

小規模PoC・最小構成：100万〜300万円、1〜2か月
部門導入・中小規模：300万〜800万円、2〜4か月
中規模・複数部門：800万〜2,000万円、3〜6か月
大規模・全社/複数法人：3,000万〜1億円程度、6〜12か月以上
基幹再構築・複数法人統合：1億〜数億円以上になる可能性

クラウド型IDaaSの代表的な料金体系では、月額数百〜数千円/ユーザーの価格帯が公式に示されています。

たとえば、100ユーザー規模であれば、年間で百万円台の水準になる製品もあります（出典: 主要IDaaSベンダー公式サイトの料金表示、2026年8月確認）。

費用の内訳（5項目）

見積もりは、次の5項目で確認すると、抜け漏れを防げます。

ライセンス：製品・ユーザー利用料
設計：要件と認証・認可方式の設計
連携・移行：接続先との実装・調整、既存ID・権限の移行
テスト・教育：接続・権限・運用の検証、管理者・利用者への説明
運用：監視・レビュー・改定・脆弱性対応

SAML/OIDC非対応のレガシー業務システムでは、連携費が想定より膨らむことがあります。

導入後には、監視やアクセスレビュー、ヘルプデスクの運用費が発生します。ポリシー改定や脆弱性対応の費用も、あわせて見込んでおきます。

年間の運用費として、初期費の15〜25%程度を仮置きするのが一般的です。

この割合は、公開されている一律の料金ではありません。保守体制を含むSI見積もりでの仮置きです。

▶ 詳細はこちら：IAM（認証・認可）システム開発の見積相場・費用

ポイント

費用は対象ID数や連携数、既存システムの状態で大きく変わります。ライセンス費とは別に、設計・連携・移行・運用の費用を分けて見積もると、比較しやすくなります。

発注・外注・委託するときの進め方

発注前には、RFPに対象IDやアプリ、プロトコル、属性マッピング、MFAを記載します。さらに、権限モデル、ログ・保存期間、監査、可用性/DRも盛り込みます。移行と教育、運用の分界、検収条件、契約終了時のデータ返却も、あわせて整理しておきます。

未確定の項目には、決定期限と仮定条件を添えておきます。そうすると、各社の見積もり条件をそろえやすくなります。

請負と準委任の使い分け

設計・開発・テストの要件と成果物が明確であれば、完成と検収の条件を定める請負契約が適する場合があります。一方、現状調査や要件整理のように成果を固定しにくい業務では、準委任契約が進めやすい場合があります。

要件定義だけを先に発注し、成果物と概算を確かめてから設計・開発へ進む段階契約も、選択肢になります。

▶ 詳細はこちら：IAM（認証・認可）システム開発の発注・外注・委託方法

開発会社・サービスの選び方

発注先は、知名度や初期見積もりだけでなく、認証・認可・ID連携・監査まで一貫して支援できる体制で比べます。

「大手なら安全」と決めつけず、同規模・同業種・同じ連携数の実績を確かめます。

さらに、担当技術者の継続性や、稼働後の保守体制も見ておきます。

実績確認は「電力に強い」レベルの説明で終わらせないこと

会社名や導入件数だけで判断せず、実績は匿名化した事例で示してもらいます。事例には、対象ID数や連携アプリ数、権限モデル、監査対応、稼働後の保守範囲を含めてもらいます。

可能であれば、匿名化データのデモや、退職処理・権限変更のテストシナリオを提案段階で見ておきます。そうすると、実装担当者の理解度を見極めやすくなります。

技術力・セキュリティ・運用体制の評価

開発会社は、技術、セキュリティ、運用の3つの側面から評価します。

技術：標準プロトコルへの対応範囲、標準コネクタで対応できるSaaSの範囲、レガシー連携方法を確認します。
セキュリティ：ネットワーク分離、暗号化、脆弱性管理、監査ログ、再委託先の管理体制を評価します。
運用：24時間監視の要否、担当者の継続配置、追加改修時の単価表、契約終了時のデータ返却方法を、契約前に必ず確かめます。

▶ 詳細はこちら：IAM（認証・認可）システム開発でおすすめの開発会社6選と選び方

ポイント

知名度や初期見積もりだけでなく、同規模・同業種の実績と稼働後の保守体制を見て比べます。提案段階で退職処理のテストシナリオを示してもらうと、担当者の理解度が分かります。

導入後の運用とガバナンス

IAMは、本番稼働の後も続きます。事業やSaaS構成の変化に合わせ、権限とアクセス状況を継続して見直していきます。

2025年に公開されたNISTのゼロトラスト実装ガイドは、IDガバナンスとICAMを含む複数の実装例を示しています（出典: NIST SP 1800-35 Implementing a Zero Trust Architecture、2025年6月）。

MFAと最小権限の整備で終わらせず、継続的なリスク評価と証跡管理までロードマップに含めることが推奨されています。

アクセスレビューと監査対応

月次で孤立ID・過剰権限・失敗ログを確認し、四半期から半期ごとにアクセスレビューを行います。その過程で、退職者アカウント、野良アカウント、過剰権限を検出し、是正の証跡を残す流れを運用に組み込みます。

監査では、誰がいつ何にアクセスできたかを説明できる状態を保つことが大切です。この役割は、IGA（アイデンティティガバナンス）の中核にあたります。

非人間ID（NHI）の管理という新しい論点

非人間ID（NHI）は、IAM運用で見落とせない論点です。

対象：サービスアカウント、APIキー、証明書、AIエージェントなどの秘密情報の管理も、IAM運用に含まれます。
管理：発行、ローテーション、利用目的、所有者、失効までを扱い、監査時に説明できないアカウントを残さないようにします。
棚卸し：人間のユーザーIDと同じ確認をNHIにも広げることは、2025〜2026年のIAM運用における重要な変化点です。

導入を検討する段階でよく寄せられる質問には、後段のよくある質問（FAQ）で回答します。

金額や期間は、対象ID数や連携数、既存システムの状態によって変わります。そのため、自社の条件に置き換えて考えることが大切です。

よくある質問（FAQ）

SSOとMFAを導入すればIAMは完成しますか？

完成しません。SSOとMFAは認証を強化する機能で、認可設計、退職処理の自動化、アクセスレビュー、監査ログ管理まで含めて、初めてIAMとして機能します。

認証だけを先行し、認可と運用を後回しにすると、退職者の権限が残るなどの問題が起きやすくなります。

IAM導入の費用はいくらですか？

予算検討用の推定では、小規模PoCは100万〜300万円、部門導入は300万〜800万円、中規模は800万〜2,000万円です。大規模・全社基盤は3,000万〜1億円程度です。

ライセンス費とは別に、設計・連携・移行・教育・運用の費用を分けて見積もることをおすすめします。

クラウドIDaaSとオンプレミスはどちらを選ぶべきですか？

SaaS接続が多く短期間で導入したい場合はクラウドIDaaSが向きます。一方、厳格なデータ保管やレガシー統合を優先する場合は、オンプレミスやハイブリッド構成が候補になります。

方式は、対象範囲の現状診断とPoCの結果を踏まえて判断します。

開発会社を選ぶときの最重要ポイントは何ですか？

認証・認可・ID連携・監査を理解し、退職処理、レガシー連携、NHI管理まで説明できることです。

候補先に確かめたいのは、同じ規模・データ量の実績、担当技術者の継続性、追加改修の単価表、契約終了時のデータ返却方法です。

価格だけでなく、運用開始後に自社で判断できる資料と体制が残るかも評価します。

まとめ

IAM（認証・認可）システムは、SSOやMFAといったツールを入れて終わるプロジェクトではありません。

本質は、IDと権限のライフサイクルを継続的に管理する業務プロセスを作り、事業やSaaS構成の変化に合わせて見直し続けることです。

導入前に押さえる要点

まず、ID・権限・接続先を台帳にまとめ、認証要件と認可要件を分けます。次に、対象ID数や連携アプリ数、レガシー接続をもとに、ライセンス費と開発・運用費を分けて把握します。

導入は全社一斉ではなく段階的に進め、稼働後もアクセスレビューとNHI管理を含めて継続的に見直します。

最初に作成する資料

最初に、対象ユーザー、アプリ、APIの一覧を作ります。あわせて、次の資料も集めます。

サービスアカウントの一覧：人間以外のIDも台帳に含めます
現行のID・権限管理ルール：今の運用ルールを把握するための資料
ディレクトリ構成図：IDの保管先と接続先の構成を把握するための資料

資料をもとに、対象範囲や優先順位、段階導入の単位、予算上限、候補先への質問を整理します。そうすると、各社の提案を同じ条件で比べやすくなり、導入後の手戻りも抑えられます。

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