IAM(認証・認可)システム開発の進め方/やり方/流れや方法/手法/工程/手順

IAM開発は、ID・権限の棚卸し、要件定義、PoC、段階導入、運用改善の順に進めると、退職者に権限が残る事態を防げます。

各工程で決めることと、費用や見積もりへの影響を順に見ていきます。全体像を先に知りたい場合は、IAM開発の完全ガイドもご覧ください。

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

IAM(認証・認可)システムの全体像

IAMを中心に、ID・属性管理、認証、認可、ID連携、アクセス管理を配置した図。
5つの機能領域を分けると、管理対象を整理しやすくなります。

IAM(Identity and Access Management)は、利用者・端末・サービスなどのデジタルIDを管理する仕組みです。

誰が、どの資産へ、どの条件で、どの操作を許可されるかを統制するのがIAMです。ID登録から権限付与、アクセス、監査、退職時の権限剥奪までを、一貫して設計します。

認証と認可の違い

IAM設計では、本人かどうかの確認と、許可する操作の範囲を分けて考えます。役割の違いを押さえておくと、必要な権限管理を整理しやすくなります。

  • 認証(Authentication):本人や機械が名乗ったとおりの存在かどうかの確認
  • 認可(Authorization):認証後に、許可するデータや操作の範囲の判定

認証にはパスワード、多要素認証、パスワードレス認証などの方法があります。ログインできれば安全だと考えると、認可の設計が甘くなりがちです。その結果、退職者や委託先に不要な権限が残る失敗につながります。

そのため、開発の初期には、認証要件と認可要件を別々の表で管理します。ロール、属性、例外条件の責任者も決めておくと、後工程の仕様調整が円滑に進みます。

IAMが対象にする機能範囲

IAMの主要機能は、役割の異なる領域に分けて整理できます。

  • ID・属性管理:IDの登録・変更・削除、組織や役職などの属性の設定
  • 認証:SSO、MFA、パスワードレス、FIDO2/WebAuthn
  • 認可:RBAC(ロールベース)やABAC(属性ベース)による制御
  • ID連携:SAML、OpenID Connect、OAuth 2.0、SCIM、LDAP/Active Directory
  • アクセス管理:申請・承認・定期レビュー・監査ログ

サービスアカウントやAPIキー、AIエージェントなど、人間以外のID(NHI)の秘密情報管理も対象に含めます。

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

認証結果に加えて、ユーザー属性、端末状態、場所、時刻、リスクスコアを認可判断に渡せる設計にします。こうしておくと、条件付きアクセスやゼロトラストの要件も後から追加できます。

ポイント

ログインできるかどうかより、ログイン後に誰が何を許可されるかを先に決めておくことが判断の基準になります。認証と認可を分けて考えると、退職者や委託先の権限漏れを防ぎやすくなります。

IAM(認証・認可)システムの進め方

IAM開発の5工程を、ID・権限の棚卸しから運用改善まで順に示した図。
棚卸しと要件定義を先に行い、試行後に導入範囲を広げます。

IAM開発は5工程で進みます。ID・権限の棚卸し、要件定義、PoC、段階導入、運用改善の順です。棚卸しと要件定義は要件定義・企画フェーズ、PoCは設計・開発フェーズ、段階導入と運用改善はテスト・リリースフェーズに当たります。現状診断や方式比較の中身は各フェーズの箇条書きで、運用・改善の中身はテスト・リリースフェーズの段落で順に示します。

製品を選ぶ前に、事業課題とID・権限の現状を把握しておくと、手戻りを防げます。

要件定義・企画フェーズ

要件定義では、事業課題、対象範囲、現状環境、責任分担を固めます。後から仕様の食い違いが起きないよう、各項目の中身を具体的に確かめておきます。

  • 課題とKPI:退職者の即時無効化、SaaSログイン統合、顧客認証強化、特権操作の承認整備
  • 対象範囲:ユーザー、アプリ、API、端末、サービスアカウントを台帳にまとめる
  • 現状と運用:IDソース、重複・共有ID、権限、接続プロトコル、ログ、データ所在地、可用性、障害時運用
  • 責任分担:認証・認可要件を分け、ロール・属性・例外の責任者を決定
  • 基盤環境:Microsoft 365、AWS/GCP、オンプレミスAD、顧客向けサービスから選ぶ

どの環境を中心に据えるかによって、適切な製品や連携方式が変わります。

非標準接続のレガシーシステムがどれだけあるかも洗い出しておくと、見積もりの精度を高められます。

設計・開発フェーズ

要件定義のあとは、方式を比べ、中核機能を小さく試して判断材料をそろえます。

  • PoC:最重要の5〜10アプリでMFA、プロビジョニング、退職処理、ログ、復旧を試験
  • 方式比較:性能より先に、連携可否、属性マッピング、ユーザー体験、運用負担を確認
  • 接続設計:接続先ごとのプロトコル、属性、ログアウト仕様を整理

候補はクラウドIDaaS、CIAM、オンプレミスパッケージ、スクラッチ、ハイブリッドです。PoCの結果を踏まえ、このなかから技術方式を決めます。

連携に使うプロトコルには、SAML、OpenID Connect、OAuth 2.0、SCIM、LDAP/Active Directoryがあります。

NIST SP 800-63 Revision 4の最終版は、2025年に公開されました。本人確認・認証・フェデレーションに加え、継続的評価、詐欺・ディープフェイク対策、同期可能なパスキーを扱います(出典: NIST SP 800-63 Revision 4 Digital Identity Guidelines、2025年7月)。認証方式の設計時に参照できます。

テスト・リリースフェーズ

本番リリースは、切り替えの影響を見ながら慎重に進める必要があります。

  1. 低リスクのSaaSから始め、管理者・特権ID、基幹系、外部委託先へと対象を増やします。
  2. 旧認証方式との並行期間、ロールバック手順、問い合わせ窓口、利用者教育を用意します。
  3. 認可設計と退職処理を確認し、テストに退職・異動時のシナリオを含めます。

事前準備を整えておけば、切り替え時の混乱を最小限にできます。

認証だけを先に導入し、認可設計や退職処理を後回しにすると、運用開始後にアクセスの棚卸しが追いつかなくなる失敗が起きがちです。

運用が始まったら、月次で孤立ID、過剰権限、失敗ログを確認します。アクセスレビューは、四半期から半期に一度行います。

KPIには、MFA適用率、退職処理の所要時間、SSO対象率、不要権限の削減数を設定できます。また、認証障害の復旧時間も指標にすると、導入効果を継続して追えます。

ポイント

製品を選ぶ前に現状を把握し、方式は性能より連携の可否と運用の負担で比べます。この順番を守ると、後の工程での手戻りを減らせます。

費用相場とコストの内訳

IAM開発の4つの規模区分と、それぞれの費用推定レンジを並べた図。
対象範囲が広がるにつれて、推定費用の幅も大きくなります。

ライセンス費だけを見ると割安に見えるIAMも、初期設計、データクレンジング、連携アダプター、移行、教育、24時間運用まで含めると、総額が変わります。

開発の前に、費用の内訳と規模別の目安を把握しておきます。

人件費と工数

国内SI費用には一律の価格表が少ないものの、一般的な人月単価と連携工数から、規模別の推定レンジを組み立てます。

  • 小規模PoC・最小構成:100万〜300万円、1〜2か月
  • 部門導入・中小規模:300万〜800万円、2〜4か月
  • 複数部門を含む中規模:800万〜2,000万円、3〜6か月
  • 全社・複数法人の大規模:3,000万〜1億円程度、6〜12か月以上

特に、基幹再構築や複数法人の統合を伴う場合は、1億〜数億円以上になる可能性もあります。

工数は、対象ID数(人間・機械IDの合計)、連携アプリ数、非標準接続数によって変わります。認証方式の複雑さや権限の細かさ、データ移行・名寄せの規模も影響します。

SAML/OIDCに対応していないレガシー業務システムが多いと、接続用のゲートウェイやアダプターの開発が増えます。その分だけ、人月も積み上がります。

初期費用以外のランニングコスト

ライセンス費は、プランや利用者数によって変わります。そこで、主要サービスの価格と年間額を確かめておきます。

  • Entra P1・P2:1人あたり月899円、月1,349円(2026年8月時点。出典: Microsoft Entra のプランと価格、2026年8月確認)
  • Entra Suite:月1,799円(2026年8月時点の公式表示。出典: Microsoft Entra のプランと価格、2026年8月確認)
  • 100ユーザー:P1は年約107.9万円、P2は年約161.9万円が計算上の目安
  • ライセンス重複:Microsoft 365との重複購入を確認
  • 運用費:監視、アクセスレビュー、ヘルプデスク、ポリシー改定、脆弱性対応が継続してかかる

Okta Workforce IdentityのStarterは月6米ドル/ユーザーから、Essentialsは月17米ドル/ユーザーからです(出典: Okta Plans and Pricing、2026年確認)。

なお、運用費として初期費の年15〜25%程度を仮置きすることがあります。ただし、これは推定値で、保守体制やSLAの範囲によって変わります。公開されている一律の料金ではありません。

ポイント

ライセンス費が安く見えても、設計や連携、移行、教育、運用まで含めた総額で比べないと、実際の負担は判断できません。

見積もりを取る際のポイント

「IAMを導入したい」とだけ伝えると、見積もりの前提がそろいません。対象ID数、連携アプリ数、認証方式、権限モデル、必須ログ、復旧方法を整理してから複数社に依頼すると、見積もりの精度を高められます。

要件明確化と仕様書の準備

見積もり条件をそろえるため、仕様書には対象、機能、移行・運用の範囲を記載します。

  • 対象・接続:ID数と人間・機械IDの内訳、連携アプリ数、非標準接続の有無
  • 認証・認可:SSO、MFA、パスワードレスなどの方式と、RBACかABACか
  • 移行・運用:データ移行・名寄せ、可用性・DR、ログ保管期間、運用引き継ぎの範囲

仕様が曖昧なままだと、各社の見積もりは前提が食い違い、金額だけを単純に比べられません。

部門ごとのアカウントや共有ID、退職者の権限は、要件定義の段階で確認します。委託先や派遣社員については、期間限定のアクセスを洗い出しておきます。

これらが曖昧なまま依頼すると、着手後に想定外の追加工数が生じやすくなります。

複数社比較と発注先の選び方

価格だけで決めず、実績、技術者、運用体制、データ管理を同じ条件で比べます。

  • 実績:同規模・同業種・同じ連携数の案件
  • 技術・運用:製品認定を持つ担当者、SLA、運用窓口の体制
  • データ管理:保管場所、可用性、障害時の代替認証、監査対応、契約終了時の返却

大手であっても安全と言い切れないため、担当エンジニアの経験や保守体制を、具体的に説明できるかどうかで見極めます。

SaaS事業者に本人情報や認証ログを預けるなら、データ管理と障害対応の条件も確認します。

提案書だけでは分かりにくい点は、デモや質疑応答で具体的な運用フローを確かめます。

注意すべきリスクと対策

導入後に管理漏れが出ないよう、認証以外の権限管理や非人間IDも見積もりに含めます。

  • 認可と退職処理:SSO/MFAと並べて、権限設計や退職処理の自動化も検討
  • 周辺領域:IGA(アイデンティティガバナンス)、PAM(特権アクセス管理)、CIEM、ITDRの範囲を決めます。追加範囲によって後工程の費用が変わります。
  • 非人間ID:サービスアカウント、APIキー、AIエージェントを管理対象に含める

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

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

NHIは、発行、ローテーション、利用目的、所有者、失効まで管理します。ここに漏れがあると、監査の際に説明できないアカウントが残ります。

ポイント

各社の見積もりは、前提がそろっているほど金額を公平に比べられます。対象ID数や連携数、認証方式を仕様書で固めてから依頼すると、比較しやすくなります。

よくある質問(FAQ)

企画の段階で寄せられることの多い質問に、答えの目安を添えています。

ここに示す数字は初期計画の目安です。正式な見積もりは、自社の対象範囲を踏まえて依頼してください。

IAM開発はどのくらいの期間がかかりますか?

小規模PoCは1〜2か月、部門導入は2〜4か月が目安です。

複数部門の中規模案件は3〜6か月、全社・複数法人の大規模案件は6〜12か月以上が目安です。

期間は、対象ID数や連携アプリ数、レガシーシステムの割合によって変わります。そのため、対象範囲を確定させることが、期間の短縮につながります。

IAM開発は何から始めればよいですか?

製品を選ぶ前に、対象のユーザー、アプリ、API、端末、サービスアカウントを台帳にまとめ、現行のIDソースと権限も棚卸しします。

現状の把握が不十分なまま製品を決めると、後になって接続できないシステムが見つかります。その場合、追加のアダプター開発が発生しやすくなります。

レガシー業務システムがSAML/OIDCに対応していない場合はどうすればよいですか?

標準プロトコルに対応していないシステムには、変換ゲートウェイやリバースプロキシ型の認証連携を挟む方法が一般的です。ただし、こうした追加開発は工数と保守費用を押し上げます。

要件定義で対象を洗い出し、個別に見積もりに反映します。

社内にどのような体制を用意すればよいですか?

最低限必要なのは、業務要件を判断する事業側の責任者、ID・権限の管理ルールを決める情報システム部門、セキュリティ要件を確認する担当者です。

開発会社に任せきりにせず、自社で認可ロールやアクセス基準を決められる体制を残しておきます。そうすれば、運用開始後のレビューも進めやすくなります。

ポイント

期間や費用の目安は、対象ID数や連携アプリ数が決まって初めて当てはめられます。正式な見積もりは、自社の対象範囲を踏まえて依頼します。

まとめ

IAM開発で目指すのは、IDと権限のライフサイクルを継続して管理する業務プロセスの構築です。製品の選定は、その実現に向けた一つの作業となります。

認証と認可を分けて要件を整理し、現状診断、PoC、段階導入、運用改善と進めることで、退職処理の漏れや過剰権限といった失敗を防ぎやすくなります。

開発で優先する三つのポイント

第一に、製品を選ぶ前に、ID・権限・接続先アプリを台帳にまとめ、現状を見える形にします。

第二に、認証要件と認可要件を分けて整理し、それぞれの責任者をはっきりさせます。

第三に、ライセンス費だけでなく、設計・連携・移行・教育・運用まで含めた総額で費用を比較します。

最初に行う現状棚卸しと概算見積もり

現状を棚卸しするには、対象ユーザー、アプリ、API、サービスアカウントと、現行の権限・接続方式を洗い出します。

そのうえで、資料をもとに複数社へ同じ条件で相談すると、提案と見積もりを公正に比べられます。段階導入を前提にするなら、小規模PoCから始める方法もあります。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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