>
>
公開日
最終更新日
ITにおけるプロビジョニングは需要に応じて必要なITリソースを割り当て即座に利用可能にするプロセスです。
中堅・中小企業の情報システム（情シス）担当者にとって、プロビジョニングはサーバー構築だけを指す言葉ではありません。クラウドやネットワークの設定、PCの初期設定、従業員の入社・異動・退職に伴うSaaSアカウント管理まで含みます。英語ではprovisioningと表記し、provisionedは必要なリソースが割り当てられて利用可能になった状態を意味します。
プロビジョニング（Provisioning）とは
この記事でわかること：
プロビジョニングの意味と本質：ITシステムやサービスを使える状態にするために、リソースを割り当てる一連のプロセスが理解できる。
デプロイとの違い：プロビジョニングとデプロイが果たす役割の違いと、構成によって変わる実行順序が理解できる。
デプロビジョニング漏れのリスク：退職者アカウントを停止・削除する際に、アカウント以外にも確認する項目がわかる。
SCIMによるID連携：SCIM対応のIDaaSとSaaSを連携した場合に、アカウント作成・変更・無効化を自動化できる仕組みがわかる。
プロビジョニングとは、ITシステムやサービスをユーザーが利用できるように、サーバー、ネットワーク、ストレージ、アカウント、端末などのリソースを割り当てて準備する一連の仕組みを指す。英語では「provisioning」と表記され、動詞の「provision（供給・準備する）」に由来する。過去分詞形の「provisioned」は、必要なリソースが割り当てられ、利用可能になった状態を表す。
情シスの業務では、入社者へのアカウント発行、異動時の権限変更、端末の初期設定、クラウド環境の作成などがプロビジョニングにあたる。対象となるSaaSや端末が少ない組織では、棚卸し頻度、二者確認、退職通知の連携、チェックリストを運用に組み込むことで手作業のリスクを抑えられる。一方、複数のSaaSや拠点、端末管理製品をまたいで同じ作業を繰り返す場合は、作成・変更・回収の条件を標準化すると運用を整理しやすい。
また、作成と対になるプロセスが「デプロビジョニング（Deprovisioning）」である。利用者の退職、異動、端末廃棄、プロジェクト終了などに応じて、アクセス権、ライセンス、リソースを停止・削除・回収する。IDの停止だけでなく、既存セッション、共有データ、メールやファイルの保持、端末回収、特権IDの有無も対象に含めると、退職・異動時の責任分担を明確にできる。
プロビジョニングとデプロイの違い
プロビジョニングは利用環境やリソースを準備する行為であり、デプロイはアプリケーションや設定済みの成果物を配置・反映して稼働させる行為である。
インフラ構築とアプリケーション配置を分離する構成では、一般的にプロビジョニングで土台を作成した後にデプロイを実行する。ただし、CI/CDやGitOpsでは、環境構築、設定変更、アプリケーションデプロイを反復する場合がある。IDや端末のプロビジョニングも、特定アプリケーションのデプロイと必ずしも前後関係を持つものではない。したがって、実務では「どのリソースを作る処理か」「何を配布・反映する処理か」で区別する。
比較項目 | プロビジョニング（Provisioning） | デプロイ（Deploy） |
|---|---|---|
主な役割 | 利用環境・リソースの準備と割り当て | アプリケーションや設定済み成果物の配置・反映 |
時系列の関係 | インフラ構築を分離する場合はデプロイより先に行うことが多い | 環境準備後に行うことが多いが、CI/CDでは構築処理と反復する場合がある |
対象物 | サーバー、ネットワーク（VPC）、ミドルウェア、データベース、ユーザーアカウント、PCなど | 実行プログラム（バイナリ）、Webアプリケーション、コンテナイメージ、設定ファイルなど |
たとえば、IaCでVPC、仮想マシン、データベースを作成する処理はプロビジョニングにあたる。その環境へコンテナイメージやWebアプリケーションの新しい版を反映する処理がデプロイである。パイプラインを設計する際は、作成するリソース、変更承認の単位、ロールバック方法、監査ログの保存先を分けて定義すると、障害時の切り分けがしやすくなる。
▲ プロビジョニングからデプロイに至るシステム構築の実行手順と役割の違い
プロビジョニングの主な4つの種類と国内導入事例
プロビジョニングの対象はインフラからID管理まで多岐にわたる。情シスでは、対象ごとに担当者、管理コンソール、承認者、例外処理を分けると、導入範囲を段階的に広げやすい。まずは発生頻度が高く、手順を定型化でき、回収条件を定義しやすい領域から着手する。
1. サーバー/クラウドプロビジョニング（AWS等の事例）
AWSやGoogle Cloudなどのクラウド環境では、サーバー・ネットワーク・DBなどのリソース構築をコードで管理するIaC（Infrastructure as Code）が使われる。Amazon EC2インスタンス、VPC、RDSなどをテンプレートや設定ファイルで定義し、同じ構成を再現可能な形で作成する。構築手法には、手順を記述する命令型（Imperative）と、最終状態を定義する宣言型（Declarative）がある。どちらを採用するかは、既存ツール、変更管理、運用チームのスキル、承認フローに応じて決める。
事例：日産自動車株式会社
・業種・規模：自動車製造（グローバル企業）
・導入時期：Microsoft Customer Storiesは2026年5月28日に事例を公開している。
・課題：衝突安全性や空気力学のCAEシミュレーションで、計算資源の制約により待ち時間が生じていた。
・施策：Microsoftは、日産自動車がLinux on AzureとAzure CycleCloudを利用し、仮想マシン環境のプロビジョニング、管理、オートスケーリングを行っていると紹介している。
・成果：Microsoft Customer Storiesでは、CAE処理の30%高速化と、性能向上に伴うソフトウェア総コスト圧縮の可能性が紹介されている。数値は同社事例での条件に基づくため、他環境へそのまま適用するものではない。（出典：Microsoft Customer Stories「Azure により、日産自動車において30% 高速でコスト効率の高いCAEイノベーションへの移行を実現」）
事例：株式会社ディー・エヌ・エー（DeNA）
・業種・規模：ゲーム・ネットサービス
・導入時期：AWSの公開事例では、次世代タクシー配車サービスのデータ収集基盤にAWSを採用した取り組みを紹介している。
・課題：サービスの変化に応じて、インフラを迅速に調達し、安全性を確保する必要があった。
・施策：AWSは、DeNAがAWS IoT、AWS Lambda、Amazon Elasticsearch Service、Amazon Kinesisなどを利用し、AWS Key Management ServiceとAWS CloudTrailも活用したと紹介している。
・成果：同事例ではスピーディーなインフラ調達と、柔軟かつ堅牢なシステム構築が紹介されている。TerraformやItamaeを含む個別の構成は公開事例で確認できないため、選定時は自社のコード管理方針と変更承認の仕組みを基準にする。（出典：AWS 導入事例：株式会社ディー・エヌ・エー）
2. ネットワークプロビジョニング
ネットワークプロビジョニングは、拠点、回線、ルーター、スイッチ、VPN、アクセス制御などの設定を、定義済みのルールに沿って作成・変更する取り組みである。拠点数や変更件数が多い場合は、設定テンプレート、承認済みパラメーター、変更履歴を集中管理することで、属人化や設定差異を把握しやすくなる。
事例：KDDI株式会社
・業種・規模：電気通信事業
・導入時期：株式会社アシストの公開事例は2019年7月の事例として掲載されている。
・課題：法人向けネットワーク開通業務で、RPAだけでは複雑な判断を自動化しにくく、ベテラン担当者への業務知識の集中が課題となっていた。
・施策：株式会社アシストは、KDDIが「AEDAN」、Progress Corticon、DataSpider Servistaを組み合わせ、判断を含む業務自動化に取り組んだと紹介している。
・成果：株式会社アシストは、人為的ミスの抑制と事務処理時間の短縮を導入ポイントとして紹介している。ネットワーク開通の全工程を自動化できるかは、既存回線、申請書式、例外ルール、外部システム連携の範囲によって変わる。（出典：株式会社アシスト「RPAの領域を大幅に拡大！複雑な判断や作業のつなぎまでも含めた自動化で業務スタイルを変革」、株式会社アシスト 導入事例）
3. デバイスプロビジョニング
デバイスプロビジョニングは、PCやスマートフォンなどを業務利用できる状態にするため、OS初期設定、MDM登録、アプリ配布、セキュリティ設定、利用者への割り当てを行う。ゼロタッチ展開はその一手段であり、端末の機種・OS、調達経路、MDMの対応状況、ネットワーク接続条件によって実施方法が変わる。
デバイスプロビジョニングを検討する際は、MDM製品の管理画面でOS登録、アプリ配布、暗号化、端末回収の各工程を自動化できるかを確認する。自動化できる工程が明確であれば限定検証に進み、対応していない工程については手順書と担当者の分担を台帳に残す。
4. ID/ユーザープロビジョニング
IDプロビジョニングとは、従業員の入社、異動、休職、退職に合わせて、アカウントの作成、属性更新、グループ・権限変更、無効化、削除を各システムへ反映するプロセスである。Microsoftの公式ドキュメントでは、Microsoft Entra IDのプロビジョニングサービスはSCIM 2.0エンドポイントを通じ、ユーザーとグループの作成、更新、削除・無効化を自動化すると説明している。（出典：Microsoft Learn「Understand how Application Provisioning in Microsoft Entra ID」）
退職後も残存するアカウントは「退職者アカウント」「孤立アカウント」「ゴーストアカウント」などと呼ばれる。一方で「シャドーアカウント」は、IT管理者が把握していない非公式アカウント全般を指す場合があり、退職者アカウントとは発生原因が異なる。用語を混在させず、台帳では「退職者残存」「未管理アカウント」「共有アカウント」など、対応方法が区別できる分類で記録する。
SCIM対応のIDaaSやSaaS管理ツールは複数あり、対応SaaS、属性マッピング、グループ同期、無効化と削除の挙動は製品ごとに異なる。自社の人事システム、IDaaS、連携先SaaSの各公式ドキュメントでSCIM対応範囲を照合し、3者で必要な属性と停止方法が一致すれば自動連携の対象にし、一致しなければ手動フローまたはAPI連携を残す。
シンプロビジョニングとは
シンプロビジョニングとは、物理ストレージを仮想的に集約し、実際に消費された分だけ物理リソースを割り当てる手法である。
物理的に存在するストレージ容量より大きい仮想容量をサーバーに提示し、データが書き込まれた時点で必要な分だけ物理容量を割り当てる。初期段階で未使用容量をすべて確保せずに済むため、利用量に応じた容量管理ができる。一方、仮想容量の合計が物理容量を上回るオーバーコミット状態では、書き込み増加により物理容量が枯渇する可能性がある。
運用では、ストレージ管理画面で物理使用率、増加傾向、スナップショット容量、重複排除後の実効容量を確認する。容量のしきい値と通知先を設定でき、増設のリードタイムを確保できるならシンプロビジョニングの対象にできる。監視機能や増設手順を用意できない場合は、用途ごとに予約容量を持たせる構成も選択肢となる。
▲ シンプロビジョニングにおける仮想容量と物理容量の割当構造
▲ シンプロビジョニングにおける仮想容量と物理容量の割当構造
プロビジョニング自動化の動向と制度・ガイドラインの整理
プロビジョニング自動化では、IaC、CI/CD、IDライフサイクル管理、端末管理を組み合わせるケースが増えている。ただし、AIによるコード生成や変更案作成を利用する場合でも、権限管理、変更承認、ポリシー検証、ロールバック、監査証跡は運用設計に残す。
生成AI・AIエージェントを利用する場合の統制
生成AIは、IaCテンプレートのたたき台、設定差分の説明、テスト項目の作成、Pull Requestの下書きなどに利用できる。AIエージェントがコード生成からデプロイまでを自律的に実行する運用は、対象システム、権限範囲、承認方式、監査要件で実現性が変わるため、一般化できない。
本番環境に接続する自動化では、読み取り専用の構成確認、検証環境への限定適用、承認済みテンプレートだけを使う実行へと段階を分ける。変更内容をPull Requestで確認でき、ポリシー検証とロールバック手順を記録できるなら、限定した範囲で自動実行を試せる。これらを満たせない場合は、生成結果をレビューする支援用途にとどめる判断ができる。
既存インフラの移行計画とプロビジョニング設計
オンプレミスのサーバーをクラウドへ移行する場合、IaCによるプロビジョニング設計は移行後の環境を再現可能にするうえで有効である。利用中のサーバー製品について保守終了時期を把握し、移行対象のシステム、依存するミドルウェア、接続先の外部システムを整理した後、クラウド側のリソース定義をIaCで作成する順序で進めると、設定差異や作業漏れを把握しやすくなる。
法令、業界ガイドライン、監査上の統制を分けて考える
個人情報保護法は、すべての企業にSCIM連携を義務付けるものではない。金融分野を含む業界別のセキュリティガイドラインや、取引先・監査で求められる統制では、アクセス権限の管理、不要アカウントの削除、ログの保管、定期的な棚卸しが論点になる場合がある。
そのため、IDプロビジョニングの導入判断では、法令上の対象事業者か、業界ガイドラインの適用対象か、監査・契約上の統制要件かを分けて整理する。人事異動・退職の記録、権限付与の承認履歴、アクセスログを取得できるなら、それらを連携設計の要件に含める。取得できない場合は、対象SaaSの棚卸し、月次のアカウント照合、二者確認を手動運用に組み込む。
運用時のよくある失敗パターンと対策
自動化の対象を増やす前に、退職・異動、端末入れ替え、リソース増減の3場面で、誰が何を確認し、例外をどこに記録するかを決める。手動運用でも、台帳、通知、承認、棚卸しを運用できればリスクを抑えられる。
失敗パターン①：退職者の「デプロビジョニング漏れ」による不正アクセス
社員が退職する際、IT部門が個々のSaaS（Slack、Salesforce、Google Workspace等）のアカウントを手動で削除していると、一部の処理が漏れる場合がある。退職後も残存する「孤立アカウント」または「ゴーストアカウント」は、不要なアクセス経路になり得る。なお「シャドーアカウント」はIT管理者が把握していない非公式アカウント全般を指す場合があり、退職者アカウントとは区別する。
対策：退職処理では、①人事担当者が退職日と対象者を確定し、②ID管理担当者がIDaaSでサインイン停止とグループ・特権権限の確認を行い、③各SaaS管理者がデータ保持、共有データの引き継ぎ、ライセンス回収を記録する。Microsoftの公式案内では、Microsoft Entra IDのアプリプロビジョニングはユーザーの削除または無効化を扱える一方、アプリ側の既存セッション失効はアプリの実装・設定に依存すると説明している。（出典：Microsoft Learn「Revoke user access in an emergency in Microsoft Entra ID」）
人事システムとIDaaSを連携する場合は、人事システムの退職ステータス、IDaaSの無効化設定、対象SaaSのSCIM対応状況を各管理画面と公式ドキュメントで照合する。SCIMで無効化・削除、必要な属性、対象アプリが確認できれば自動化の対象にする。SCIM非対応のSaaS、共有アカウント、ローカルIDが残るシステムは、退職チェックリストに手動処理と完了記録を残す。
失敗パターン②：デバイス入れ替え時の「ライセンス競合エラー」
学校やオフィスでChromebookやWindows PCの故障・買い替えを行う際、古いデバイスの登録解除やライセンス回収を完了しないまま新端末を登録すると、管理コンソールでライセンス不足や重複登録のエラーが発生する場合がある。エラーの内容と解消方法は、OS、MDM、ライセンス契約、端末の所有形態によって異なる。
対策：端末の廃棄・譲渡・交換では、資産管理担当者が端末回収または廃棄証跡を記録し、端末管理担当者がMDMの管理画面で登録解除・ワイプ・ライセンス回収を実施し、新端末の割り当てを行う。旧端末の解除状態とライセンス残数が確認できれば新端末のプロビジョニングに進み、確認できなければ旧端末を例外台帳に残してから処理する。
失敗パターン③：オーバープロビジョニングによるクラウドコストの増加
システム負荷に備えるために仮想マシンのスペックやストレージ容量を大きく確保し続けると、実使用量との乖離によってクラウド利用料が増える場合がある。利用率が低いことだけで直ちに過剰と判断せず、繁忙期、可用性要件、バックアップ、復旧時間目標、予約契約も含めて評価する。
対策：CPU、メモリ、ストレージ、ネットワークの利用状況を月次で確認し、オートスケーリングの下限・上限、予約容量、ストレージの増加率を見直す。利用状況と変更履歴を取得できるなら、サービス単位でライトサイジング候補を抽出する。利用状況を取得できないシステムでは、請求明細と構成台帳を突き合わせ、変更前後の費用を記録して判断する。
▲ 退職者発生時におけるデプロビジョニング（アカウント削除）の運用フローとリスク分岐
よくある質問
Q：プロビジョニングとデプロイの違いは何ですか？
A：プロビジョニングは、サーバー、ネットワーク、アカウント、端末などの利用環境を準備・割り当てるプロセスです。デプロイは、準備済みの環境にアプリケーションやコンテナイメージ、設定を配置・反映して稼働させるプロセスです。インフラ構築を分離する構成では前者の後に後者を実行することが多い一方、CI/CDやGitOpsでは構築とデプロイを反復する場合があります。
Q：IDプロビジョニングの導入効果はどのくらいありますか？
A：効果は、連携対象SaaS数、入退社・異動の件数、既存の手順、SCIM対応状況、例外処理の多さによって変わります。自社の月間アカウント作成・変更・削除件数、担当者の作業時間、削除漏れの再確認件数を記録すると、導入前後で比較する基準になります。SCIM対応のIDaaSとSaaSを連携できる場合、ユーザーとグループの作成・更新・無効化を自動化できる機能があります。（出典：Microsoft Learn「What is provisioning with Microsoft Entra ID?」）
Q：デプロビジョニング（プロビジョニング解除）はなぜ重要ですか？
A：不要になったアカウント、権限、端末、クラウドリソースを放置すると、不要なアクセス権やライセンス費用が残るためです。退職時は、アカウント停止・削除だけでなく、既存セッションとトークンの扱い、特権ID、共有データの引き継ぎ、メール・ファイルの保持、端末回収をサービスごとの仕様に沿って処理します。退職者アカウント、孤立アカウント、ゴーストアカウントは残存アカウントを指す表現であり、未管理の非公式アカウントを指すことがあるシャドーアカウントとは区別します。
まとめ
プロビジョニングは、サーバー、ネットワーク、端末、IDなどを利用可能な状態にし、変更・回収までを管理する仕組みです。中堅・中小企業の情シスでは、すべてを一度に自動化するのではなく、入退社に伴うID管理、端末入れ替え、定型的なクラウド構成など、発生頻度と手順の定型度が高い領域から対象を決めると進めやすくなります。
✅ 担当者：情シス責任者が、SaaS・端末・クラウドの管理台帳の担当者と更新期限を決め、未管理のアカウント・端末・リソースを棚卸しする
✅ 期限：人事担当者とID管理担当者が、退職日当日のサインイン停止、特権ID確認、ライセンス回収、共有データ引き継ぎの完了期限を定義する
✅ 確認対象：人事システム、IDaaS、連携先SaaSの公式ドキュメントと管理画面で、SCIM対応、属性同期、無効化・削除、監査ログの取得可否を照合する
これらの確認で、対象SaaSのSCIM連携、退職時の停止手順、監査ログの保存先を定義できれば、少数のSaaSから限定検証に進める。定義できないシステムは、担当者と完了記録を伴う手動フローとして台帳に残す。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
