デプロイの意味やビルド・リリースとの違いを詳しく解説

システム開発における重要な工程の一つが、テスト済みのアプリケーションをサーバー上に配置し、利用可能な状態にする「デプロイ（deploy）」という作業です。

デプロイは、一部の例外を除いてサーバーを一時的に停止して行う必要があるため、素早く確実に行う必要があります。デプロイにはいくつかの手法があるので、状況に応じて適したものを選びましょう。

本記事ではデプロイという言葉の意味や関連する「ビルド」「リリース」などの用語との違い、代表的な手法、実施すべきタイミングについて、初心者の方にも分かりやすく解説します。

デプロイとは

デプロイとは、“テスト済みのアプリケーション等のソフトウェアを実際の運用環境に導入・設定して利用可能にするプロセス”を意味する言葉です（※）。また開発したアプリケーションが利用可能な状態にある場合、そのファイルを「デプロイ済み」と表現します。

navigate_next※出典：経済産業省.「サイバーセキュリティ体制構築・人材確保の手引き 第2版」

英語のデプロイ（deploy）には、元々「展開する」や「配置する」といった意味があります。そのためシステム開発において、アプリケーションを実行するためのファイル（＝実行ファイル）をサーバー上に展開・配置する作業を指し、デプロイと呼ぶようになりました。

通常のシステム開発では、開発中またはテストが完了していないプログラムを誤って一般公開しないよう、開発環境・テスト環境・本番環境という3つの環境を用意します。

システム開発の環境	目的
開発環境	開発者が使用するパソコン（ローカル環境）に構築し、アプリケーションを構成するプログラムを開発するための環境
テスト環境	個々のプログラムを検証する単体テストや、複数のプログラムを組み合わせた状態で検証する結合テストを実施し、アプリケーションの動作確認を行うための環境
本番環境	検証を終えたアプリケーションをテスト環境から移行（デプロイ）し、サービスとして一般公開した後、ユーザーが利用可能な状態にするための環境

テスト環境において問題がなければ、検証を終えたアプリケーションを本番環境へ移行（デプロイ）し、サービスとしてユーザーに公開します。開発したアプリケーションをいきなり公開するのではなく、テストを経てから本番環境へデプロイすることで、サービスの品質を保つことが可能です。

なおテスト環境は実際の運用環境を再現するため、できるだけ本番環境に近い状態になっています。そのため、開発環境からテスト環境へアプリケーションを移行する作業をテストデプロイと呼ぶこともあります。

デプロイという用語は、アプリケーションの開発・運用に直接関わるエンジニアだけでなく、企業の情報システム担当者であれば知っておいて損のない言葉です。

ビルドとは

デプロイに関連した作業の一つに、ビルド（build）があります。ビルドとは、複数のプログラムを一つにまとめ、実行可能なファイルを作成する作業のことです。

プログラムは、人間が理解できるプログラミング言語で書かれたソースコード（テキストファイル）が元になっています。しかし、ソースコードはそのままでは実行できません。

システム開発では、まずソースコードのコンパイル（compile）という作業を行い、ソースコードに書かれたプログラミング言語を、コンピューターが理解できる機械語（アセンブリ言語）に変換します。このコンパイルが完了したファイルを正しく組み合わせ、実行可能な形式にする作業がビルドです。

つまりデプロイとは、ビルドが完了したファイルを本番環境に移し、正しく動作するように配置・設定する作業と言い換えられます。

リリース（ローンチ）とは

システム開発の現場では、リリース（ローンチ）という用語も使われます。デプロイは、このリリースと呼ばれる作業の一部です。

本番環境にデプロイされたアプリケーションは、そのままの状態では特定のユーザーしか利用できません。デプロイを行った後にアプリケーションをサービスとして一般公開し、顧客やユーザーが利用できるようにする作業をリリース（release）またはローンチ（launch）といます。

リリースを行うのは、一般的にアプリケーションのデプロイが完了し、問題がないか検証・テストを行った後です。ただし、デプロイと同時にリリースを行うケースもあります。

デプロイの目的

デプロイを行う目的は、大きく分けて2つあります。

• ユーザーに最新のサービスを提供する
• サービスの品質を繰り返し改善する

ユーザーに最新のサービスを提供する

デプロイという作業は、アプリケーションの開発（開発環境・テスト環境）と運用（本番環境）をつなぐプロセスとも言い換えられます。デプロイを実施しなければ、開発しテストを行ったアプリケーションが、ユーザーにとって利用可能な状態になりません。

デプロイを素早く小まめに行うことで、常に最新のバージョンにアップデートされたサービスをユーザーに提供できます。デプロイは、開発やテストといった作業と比べて後回しにされる場合もありますが、同じくらい重要なプロセスの一つです。

サービスの品質を改善する

デプロイを行うことは、サービスの品質を向上させる上でも大切です。

デプロイを後回しにすると、アプリケーションが開発環境やテスト環境に依存したものになる可能性があります。そのためデプロイは、開発プロセスのなるべく早い段階から実施することが大切です。

また小まめにデプロイを実施することで、実際の運用環境におけるフィードバックに基づき、開発者とは別の視点からアプリケーションの課題や問題点を発見できます。このサイクルの繰り返しによって、サービスの品質を絶えず向上させていくことが可能です。

デプロイの代表的な手法は4つ

デプロイを実施する場合、テスト環境からファイルを安全に移行するため、本番環境のサーバーを一時的に停止させる必要があります。その間、ユーザーはサービスを利用できません。

こうした問題点から、デプロイ中のダウンタイム（サーバーの停止期間）をできるだけ短縮するための手法が模索されてきました。ダウンタイムが比較的短いデプロイの手法として、代表的なものは4つあります。

1. ブルーグリーンデプロイメント（blue/green deployment）
2. イミュータブルデプロイメント（immutable deployment）
3. マスターイメージの抽出
4. シンボリックデプロイメント（symbolic deployment）
5. ローリングデプロイメント（rolling deployment）

ブルーグリーンデプロイメント

ブルーグリーンデプロイメント（blue/green deployment）とは、ブルー・グリーンの2種類のサーバーを用意し、デプロイを行っている間、サービスが停止しないようにする手法です。

現行の運用環境をブルー、新規の運用環境をグリーンとして、アプリケーションを更新する場合は、まずグリーンの環境でデプロイを行います。問題がなければ、すみやかにグリーンからブルーへと運用環境を切り替えます。

デプロイ中もサービスを継続できるだけでなく、問題があった場合はすぐに設定を戻せる（＝ロールバック）のが、ブルーグリーンデプロイメントの強みです。

イミュータブルデプロイメント

イミュータブルデプロイメント（immutable deployment）は、ブルーグリーンデプロイメントと同様に、ブルーとグリーンの2つのサーバーを用いる手法です。ただし、デプロイの完了後、古い環境（ブルー）を抹消するという点が異なります。

ブルーグリーンデプロイメントの欠点は、サービスの運営に伴い、2つのサーバーを維持管理する必要があるという点です。イミュータブルデプロイメントでは、サーバーを2つ同時に運用する必要がないため、ランニングコストがより少なく、サーバーのリソースも節約できます。

ただしデプロイ後に問題が生じた場合、ブルーグリーンデプロイメントと比べてロールバックに時間が掛かるのがデメリットです。

シンボリックデプロイメント

シンボリックデプロイメント（symbolic deployment）とは、1つのサーバーに2つの仮想環境を用意する手法です。一方の仮想環境でデプロイの作業をテストし、問題がなければもう一方の仮想環境を本番環境としてデプロイを行います。稼働するサーバーが1つしかないため、コスト削減が可能です。

シンボリックデプロイメントの特徴は、デプロイの際にシンボリックリンク（※ファイルがある本来の位置とは別の場所からアクセスすること）という仕組みを使う点です。そのため、サービスの運営に必要なサーバーを停止させずにデプロイを実行できます。

ただしバックアップとなる運用環境がないため、サーバーに物理的な障害が発生した場合、サービスへの影響が避けられないのが欠点です。

ローリングデプロイメント

ローリングデプロイメント（rolling deployment）とは、一度に全てのアプリケーションを更新するのではなく、いくつかに分割し、少しずつデプロイしていく手法です。

ローリングデプロイメントのメリットは、デプロイによる影響範囲が小さいという点です。一部の機能が利用できなくなっても、全体のサービス運営に支障が出ないようなアプリケーションで採用されます。

ただしデプロイが完了するまで、新しい環境と古い環境が一時的に混在するという欠点もあります。特にデプロイによって問題が発生した場合、元に戻す作業に手間が掛かるのがデメリットです。

デプロイタイミングはリリースの直前！

一般的なシステム開発の流れは、計画→設計→開発→テスト→デプロイ→運用（リリース）といった手順で進んでいきます（※）。デプロイを行うのは、アプリケーションやソフトウェアをリリースする直前のタイミングです。

デプロイは、一連のテストを通じて、アプリケーションの動作に問題がないことをしっかりと確認してから行います。デプロイを行った後に問題が発覚した場合、再度やり直す手間が掛かるからです。

デプロイ中は、一時的に運用環境を停止する必要があります。そのためユーザーへの影響が少ない、深夜から早朝にかけての時間帯に実施することが一般的です。

navigate_next※参考：経済産業省.「サイバーセキュリティ体制構築・人材確保の手引き 第2版」

デプロイのやり方

デプロイのやり方は、エンジニアが手動でデプロイを実施する方法（手動デプロイ）と、アプリケーションを更新するタイミングでデプロイを自動化する方法（自動デプロイ）の2つに分けられます。

複手動デプロイ

手動デプロイとは、開発者が使用するローカル環境を通じて、手動でデプロイを行う方法です。手動といっても、デプロイに必要なファイルのやり取りには、FTP（File Transfer Protocol）という通信プロトコルを利用したツール（FTPツール）を使います。

手動デプロイは、人の手による作業が多いため、ミスや手戻りが発生しやすいというデメリットがあります。そのため現在では可能な限りデプロイにかかる作業を自動化し、どうしても必要な部分のみ手動デプロイを行うのが一般的です。

なお手動デプロイには、細かい問題やトラブルに気が付きやすく、臨機応変に対処できるという強みもあります。

自動デプロイ

自動デプロイとは、アプリケーションの更新を行うタイミングで、該当部分のファイルが順次デプロイされるように自動化する方法です。必要な設定（デプロイ先の指定など）を事前に行っておくことで、手間や労力をかけずにデプロイを実行できるというメリットがあります。

自動デプロイを行うには、CI／CD（継続的インテグレーションおよび継続的デリバリー）と呼ばれるツールを使用します。自動デプロイを実現することによって、デプロイを素早く小まめに行うことができ、システム開発のサイクルを短縮することが可能です。

デプロイを実施する上で大切なこと

デプロイを実施する上で大切なことは2つあります。

1. なるべく早く終わらせる
2. 失敗しないように作業する

できるだけ早く終わらせる

1つ目のポイントは、デプロイをなるべく早く終わらせるという点です。

前述のとおり、デプロイ中は一時的に運用環境を停止させる必要があります。デプロイが長引くと、その間サービスを利用できなくなるため、ユーザーの満足度が低下するリスクがあります。

ブルーグリーンデプロイメントなど、サービスを中断せずにデプロイを行う手法を採用しても、デプロイが完了するまでは新しいアプリケーションをリリースできません。デプロイを効率化し、サービスへの影響を最小化することが大切です。

失敗しないように作業する

2つ目のポイントは、デプロイが失敗しないように確実に作業するという点です。

デプロイが失敗した場合、サーバーの設定をリセットして再度やり直す（再デプロイ）手間が掛かります。サービス再開までのダウンタイムも長引くため、デプロイは確実に行うことが大切です。

また万が一デプロイが失敗したときに元に戻せるようにするには、ロールバックしやすい手法でデプロイを実施しましょう。

なおユーザーがいつ利用するか・どのような環境で利用するかによって、システムの質が変わらないようにすることも重要です。

デプロイができる代表的なツール

デプロイの代表的なツールには、Amazon Web Services（AWS）が提供するツール（Elastic BeanstalkやCloudFormationなど）や、Microsoftが提供するAzure App Serviceなどがあります。

ここでは、AWSとAzureの環境におけるデプロイの流れを簡単に解説します。

AWS環境でのデプロイのやり方

AWS環境でアプリケーションを提供する場合は、Elastic BeanstalkやCloudFormation、CodeDeployなどの標準的なツールを用いて、デプロイを行うことが可能です。

ツール	目的
AWS Elastic Beanstalk	Webアプリケーションをデプロイする場合
AWS CloudFormation	個Infrastructure as Code（IaC）の手法でデプロイする場合
AWS CodeDeploy	ソフトウェアのデプロイを自動化する場合

ここでは、デプロイの自動化が可能なCodeDeployを用いたやり方を紹介します（※）。

navigate_next※参考：Amazon Web Services.「Getting started with CodeDeploy」

Azure環境でのデプロイのやり方

Azure環境では、Azure App Serviceという標準的なツールを利用することで、GUIを用いた直感的な操作でデプロイを行えます。

Azure App Serviceにおけるデプロイの手順は以下のとおりです（※）。

• デプロイ用のZIPファイルを作成する
• Azure App Serviceに接続し、Webページ上のエクスプローラーにZIPファイルをドラッグしてアップロードする（※Kudu publish APIを使用する場合）
• デプロイが完了すると、Deployment successfulというメッセージが表示される

なお、Azure App Serviceを利用するには、Azure無料アカウントの取得が必要です。

navigate_next※参考：Microsoft.「App Service にファイルをデプロイする」

PCキッティングにおけるデプロイとは？

PCのキッティングにおける「デプロイ（deploy）」は、準備が整ったPCをユーザーや環境に実際に導入・展開するプロセスを指します。
具体的には、PCに対して初期設定やアプリケーションのインストールした状態を展開し、エンドユーザーのもとに配置し、業務で利用できる状態にすることです。

PCキッティングにおけるデプロイの主な手順

1. マスターイメージの作成
   • 標準化されたOSとアプリケーション構成を含むマスターPCのイメージを作成します。
   • ドライバ、セキュリティツール、業務アプリなどを一括設定。
   • イメージにはWindows Updateなどの最新パッチを適用。
2. イメージの展開準備
   • 作成したマスターイメージをUSBメディアやネットワーク経由（PXEブートなど）で利用できるよう準備。
   • Actiphy Rapid Deploy -REのようなツールでUSBを作成する場合、シンプルなUIで展開準備が完了します。
3. 対象PCへのイメージ展開
   • PCをUSBから起動するか、ネットワーク経由でイメージを読み込みます。
   • 自動化されたデプロイにより、初期設定やアプリのインストールが一括適用されます。
   • 必要な場合、PCをドメインに参加させ、セキュリティポリシーを自動適用。
4. 動作確認
   • 展開後、初回ログインを行い、アプリケーションやネットワーク接続の正常性をチェック。
   • セキュリティソフトの更新状況やOSのライセンス認証も確認します。
5. 資産管理登録
   • PCのシリアル番号やMACアドレスを資産管理システムへ登録。
   • 利用者と紐づけることで、管理体制を強化します。
6. 配送・設置と最終確認
   • デプロイが完了したPCをユーザーのもとに配送または現地設置。
   • 最終確認としてユーザーがログインし、業務アプリケーションやファイルサーバーへの接続を確認します。
7. ヘルプデスクとの連携
   • ユーザーがPCを問題なく利用できるよう、初期サポートを提供。
   • トラブルが発生した場合は、キッティング段階で適用した標準イメージに基づき、迅速な対応が可能。

PCキッティングにおけるデプロイの重要性

効率化

セットアップ済みのPCを直接展開するため、ユーザーの初期準備負担を軽減します。

セキュリティ強化

事前設定により、セキュリティリスクを抑制した状態で導入が可能です。

標準化

どのPCにも同じ環境を構築することで、サポートやトラブル対応が容易になります。
このように、デプロイはキッティングの最終段階であり、現場への迅速な導入を支援する重要なプロセスです。

ポイント：効率化のためのTips

【まとめ】デプロイは素早く確実に行うことが大切

PCのキッティング作業を効率化したい方は、Actiphy Rapid Deploy -REがおススメです。
USBメディアを利用し、シンプルなUIで誰でも簡単に操作できるため、現場での作業時間を大幅に短縮。複数台のPCへの一括デプロイにも対応しており、セットアップの手間を減らし、トラブル発生リスクも最小限に抑えます。IT部門の負担を軽減したい方や、標準化された環境を短時間で構築したい企業に最適なソリューションです。