デプロイとは?リリース・ビルドとの違い、本番反映の流れとロールバック、発注者が押さえる4点【2026年版】

「見積書に『デプロイ・リリース作業 一式』とありますが、これは何の作業ですか」——システム開発を発注している方から、こうした相談をよく受けます。会議では何度も出てきた言葉で、いまさら聞き返しにくい。しかし金額がついている以上、稟議には書かなければならない。デプロイとリリースは同じものなのか、それとも二重に計上されているのか。そこから分かりません。

結論から言うと、デプロイとは、作ったソフトウェアを実際に動く場所に置いて、使える状態にする作業です。ビルドが「実行できる形にまとめる」作業、リリースが「利用者に使えるようにする」判断だとすれば、デプロイはその間にある置く作業にあたります。3つは連続していますが、同じではありません。ここを分けて理解できると、見積書も進捗報告も急に読めるようになります。

ただ、発注者にとって本当に大事なのは語義ではないと考えています。デプロイという作業の周りには、リリース日をいつにするか、失敗したら誰がどう戻すか、その作業は保守契約のどちらの範囲か、クラウドのアカウントと権限を誰が持つか、という4つの取り決めがあります。これらが空白のまま本番を迎えると、事故が起きた夜に決められなくなります。決めていない取り決めは、その場では決められないのが実情です。

本記事では、デプロイの語義とリリース・ビルド・公開との違い、環境の分け方と本番反映の流れ、切り戻し(ロールバック)、手動デプロイと自動デプロイおよびCI/CDの概要、そして発注者が決めておく4点の順に解説します。保守運用をどこまで外注するかという範囲と費用、テスト工程の設計、開発会社を乗り換えるときの権限移管の手順は、本記事では扱わず、それぞれ既存の記事に譲ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。相談のなかで意外に多いのが、自社のシステムが動いているクラウドのアカウントを、誰の名義で作ったのか分からないという状態です。デプロイは技術の話に見えて、その半分は取り決めの話です。この記事を読み終えるころには、開発会社に何を聞き、何を議事録に残すべきかが決められるはずです。

デプロイとは——作ったソフトウェアを動く場所に置いて、使える状態にする作業

デプロイとは、開発したソフトウェアを実際に動く環境に配置し、使える状態にすることです。プログラムを書き終えただけでは、それは開発者のパソコンの中にあるファイルにすぎません。利用者のブラウザやスマートフォンから使えるようにするには、サーバーという「動く場所」に運んで起動する必要があります。その運んで起動する作業が、デプロイです。

デプロイの語義——「配備する・展開する」。IT分野では運用環境への配置を指す

デプロイ(deploy)は英語で、配備する、配置する、展開する、といった意味を持つ単語です。もとは軍事用語で、部隊を展開させることを指していました。IT分野では、開発したソフトウェアを実際の運用環境に配置・展開して実用に供することを指す場合が多い、と説明されます。日本語にひとことで訳すなら「配備」「展開」ですが、現場では訳さずカタカナのまま使われます。

広い意味では、配置したプログラムの修正・更新・入れ替え、更新のための停止、不要になったソフトウェアの撤去まで含めて語られることがあります。つまりデプロイは一度きりの儀式ではなく、稼働後もずっと繰り返される作業です。ここが発注者にとって重要な点です。

デプロイとデプロイメントの違いは、動詞形か名詞形かだけ

「デプロイメントとは」という検索もありますが、意味の違いを気にする必要はありません。deploy が動詞、deployment がその名詞形で、指しているものは同じです。本記事でも区別せずに扱います。強いて言えば、「ブルーグリーンデプロイメント」のように手法の名前として使うときは名詞形が選ばれ、日々の会話では「デプロイする」と動詞形が使われる、という程度の慣用です。

デプロイ・ビルド・リリース・公開・ローンチはどう違うのか——対比表

この5つは連続した工程の別々の場面を指しています。混ぜて使うと、見積書の重複に気づけません。整理の軸は「何をする作業か」と「終わったときに誰が触れるか」の2つです。

DevOpsの分野では、デプロイを「指定された環境に指定されたバージョンのソフトウェアをインストールすること」、リリースを「すべての顧客または一部の顧客に対して機能を利用可能な状態にすること」と区別して定義しています。デプロイは技術的な配置、リリースは利用者に対する提供、という分け方です。

デプロイとリリースが同じ日になるとは限らない——機能フラグという考え方

小さなWebサイトなら、デプロイした瞬間に新しい画面が見えます。だから「デプロイ=公開」と覚えてしまいがちです。しかし規模が大きくなると、この2つは意図的に切り離されます。

たとえば新機能のコードを本番環境に置いておきながら、設定のスイッチを切ったままにして誰にも見せない、という運用があります。機能フラグ(フィーチャーフラグ)と呼ばれる手法です。デプロイは済んでいるのに、リリースはまだ。この状態が作れると、リリースの瞬間にコードを触らずに済み、問題があればスイッチを戻すだけで済みます。

進捗会議で「デプロイは終わっています」と報告されたのにサイトが変わっていない、という場合は、たいていステージング環境へのデプロイか、この機能フラグのどちらかです。慌てて指摘する前に、どちらの意味かを聞いてください。では、その「置く場所」はいくつあるのか。次に環境の話をします。

デプロイはどう進むのか——3つの環境、6つのステップ、そして戻し方

デプロイは「本番のサーバーにファイルを上げる」という一手ではありません。どこに置くか(環境)、どういう順で運ぶか(手順)、失敗したらどう戻すか(ロールバック)の3つが組み合わさった一連の作業です。発注者が進捗報告を読めるようになるには、この3つの骨格を知っておけば足ります。

環境は3つに分ける——開発環境・ステージング環境・本番環境

環境とは、ソフトウェアが動く場所のことです。多くのプロジェクトでは、役割の違う環境を3つ用意します。

発注者が押さえるべきなのは真ん中のステージング環境です。ここが用意されていないプロジェクトでは、発注者が自分の目で確かめる場所がないまま、本番へ一発勝負になります。閲覧用のURLと権限をもらい、承認の前に自分で触る運用にしてください。「ステージングにデプロイしました」という報告は、「確認できる状態になりました、見てください」という意味です。

デプロイの6ステップ——ビルドから動作確認まで

実務での流れは、おおむね次の6段階です。会社やツールによって呼び方は変わりますが、骨格は共通しています。

1. ビルド——ソースコードをまとめ、実行できる形にする
2. 自動テストの実行——決められたテストが通るかを機械が確認する
3. ステージング環境へのデプロイと検証——通しで動くか、発注者が確認する
4. リリース判定——本番へ出すかどうかを決める。技術ではなく判断の工程
5. 本番環境への反映——ファイルの配置、設定の反映、必要ならデータベースの変更、起動
6. 動作確認と監視——反映後に主要な画面と処理を確認し、エラーの発生状況を一定時間見る

見積書に「デプロイ・リリース作業 一式」とある場合、この6つのどこからどこまでが含まれるのかを聞いてください。当社では、一式と書かれた見積もりは工程に割ってもらうようお勧めしています。割れない見積もりは、中身が決まっていないことが多いのが実情です。

ロールバック(切り戻し)——戻せるかどうかは当日ではなく設計で決まる

ロールバックとは、新しいバージョンに問題が見つかったときに、ひとつ前の動いていた状態へ戻すことです。切り戻しとも呼ばれます。「何かあっても戻せます」という説明はよく聞きますが、実際には戻せない場合があります。代表的なのは次の3つです。

• データベースの構造を変えた場合——列を削除した、データの形式を変換した。プログラムだけ戻しても、データは戻りません
• 外部サービスへ送信済みの処理がある場合——決済、メール送信、外部システムへの連携。送ったものは取り消せません
• 前のバージョンを残していない場合——上書きでファイルを置き換えた構成では、戻す先がありません

戻せるかどうかは、当日の作業者の頑張りではなく、事前の設計と契約で決まります。発注時に「ロールバックの手順は文書になっているか」「どの変更が戻せない変更にあたるか」を確認してください。

ダウンタイムを減らす4つの手法——ブルーグリーン、ローリング、カナリア、イミュータブル

デプロイの間、サービスが止まることがあります。この停止時間をダウンタイムと呼びます。止めずに入れ替えるために、いくつかの手法が使われています。

手法の名前を覚える必要はありません。発注者が聞くべきなのは「今回の構成では、リリース中にサービスが止まりますか。止まるなら何分ですか」の1問だけです。止まるなら、その時間帯を誰と合意するかという話に進みます。

手動デプロイと自動デプロイ——CI/CDとは何をしている仕組みか

デプロイの作業は、人が手順書を見ながら実行する場合と、仕組みが自動で実行する場合があります。この違いは、費用にも事故率にも、開発会社を乗り換えるときの引き継ぎやすさにも効いてきます。発注者が中身の実装を理解する必要はありませんが、自社の案件がどちらなのかは知っておいてください。

手動デプロイが残る理由と、そこに潜むリスク

手動デプロイは、担当者がサーバーに接続し、ファイルを置き、設定を変え、サービスを再起動する方式です。小さな案件では、いまでも普通に行われています。仕組みを作る初期費用がかからず、回数が少なければ合理的だからです。

問題は回数が増えたときに出ます。手順書に書かれていない暗黙の操作が積み重なり、特定の担当者しか安全に実行できなくなる。環境変数の設定を1つ入れ忘れて本番が動かない、必要なファイルを置き忘れる、キャッシュが残って古い画面が表示され続ける。よく報告される失敗は、どれも派手なバグではなく、こうした単純な取りこぼしです。そして、その担当者が退職したり、契約が終わったりした瞬間に、誰も本番を触れなくなります。

CI/CDとは——自動テストが通ったら、人の手を介さずに運ぶ

CI/CDは、この手作業を仕組みに置き換える考え方です。2つの言葉が組み合わさっています。

• CI(継続的インテグレーション)——開発者がコードを書き上げるたびに、自動でビルドとテストを実行し、壊れていないかを確かめる仕組み
• CD(継続的デリバリー / 継続的デプロイ)——テストを通ったものを、自動でステージングや本番へ運ぶ仕組み。人が承認ボタンを押して進めるものを継続的デリバリー、承認も挟まず本番まで自動で進めるものを継続的デプロイと呼び分けます

実際の構成はシンプルです。開発者がコードを所定の場所に送ると、それを合図にビルドが走り、自動テストが走り、通れば指定の環境へ配置される。この一連の流れをパイプラインと呼びます。人の作業は、コードを送ることと、必要なら承認を押すことだけになります。

なお、ここで走る自動テストは、単体テストなど機械が繰り返せる範囲のものです。どのテストを内製し、どこから外部に委託するかという設計は別の話で、「テスト 外注」の記事にまとめてあります。

自動化しても消えない作業と、DORAの5指標

自動化しても消えない作業があります。本番に出すかどうかの判断、出した後に監視する目、そして戻すかどうかの判断です。これらは事業の判断であり、仕組みには任せられません。当社が品質管理として掲げている3点のうち、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化までは仕組み化できますが、3点目のリリース前ダブルチェックは、最後まで人の目が担当します。

デプロイの良し悪しを感覚で語らないために、業界では共通の物差しが使われています。DevOpsの研究組織であるDORAは、ソフトウェア開発の成果を測る指標を整理しており、変更のリードタイム(コードを書いてから本番で動くまでの時間)、デプロイ頻度、失敗したデプロイからの復旧時間、変更失敗率(対応が必要になったデプロイの割合)、デプロイやり直し率の5つを挙げています。速さと安定は両立しないと思われがちですが、DORAの研究では両者は相関しており、上位のチームは5指標すべてで良い数字を出すと報告されています。

発注者がこの5つをすべて管理する必要はありません。ただ「月に何回リリースできる体制を目指すのか」「失敗したとき何分で戻せるのか」の2つだけは、開発会社と共通の言葉で話せるようにしておくと、見積もりの議論が具体的になります。

発注者が決めておく4つ——リリース日、切り戻し、保守契約の範囲、権限とアカウント

ここからが本題です。デプロイの手順そのものは開発会社の仕事ですが、その周りには発注者が決めなければ前に進まない事柄が4つあります。どれも技術の知識ではなく、取り決めの問題です。決めていない取り決めは、事故が起きた夜には決められません。

リリース日の決め方——金曜の夕方と、月末月初を避ける

リリース日は開発会社が決めるものだと思われがちですが、本来は事業側が決める事柄です。理由は単純で、問題が起きたときに困るのが事業側だからです。

実務でお勧めしているのは、週の前半、できれば火曜か水曜の午前です。金曜の夕方に本番へ出すと、問題が見つかったときに対応する人が帰り始めています。土日をまたいで放置されると、月曜の朝には被害が広がっています。同じ理由で、祝日の前日も避けてください。

もうひとつは業務カレンダーとの突き合わせです。月末月初は請求や締めの処理が集中します。そこに新しいシステムを重ねると、障害と業務のピークが同時に来ます。ベトナムに開発拠点がある場合は、現地の祝日も確認してください。ベトナムの法定祝日は2026年で年12日(労働法112条の条文上は11日で、2026年からベトナム文化の日が加わります)で、2026年のテト(旧正月)は2月14日から22日までです。この期間をまたぐリリース計画は、要注意です。

障害が出たときの切り戻し——判断者・連絡経路・時限を先に決める

リリース後に問題が見つかったとき、その場で決めることは1つしかありません。「戻すか、直して進むか」です。この判断を誰がするのかを、事前に名前で決めてください。役職名ではなく名前で、そして不在時の代理も含めてです。

あわせて決めるのは、連絡経路と時限です。連絡経路は、誰から誰へ、どの手段で、何分以内に一次連絡を入れるか。時限は、「反映後30分以内に主要な処理が通らなければ切り戻す」といった、分単位の線引きです。時限を決めておくと、その場の議論が要らなくなります。基準がないまま議論を始めると、直せるかもしれないという期待で時間が溶けていきます。

この取り決めは、A4で1枚に収まります。リリース手順書の最後に、判断者、代理、連絡先、時限、戻し方の5行を書き足すだけで足ります。

その作業は保守契約のどちらの範囲か

リリースにまつわる費用でいちばん揉めるのが、ここです。月額の保守契約を結んでいても、そこに含まれるのは監視と障害対応だけで、機能追加に伴うリリース作業は都度見積もり、という契約はよくあります。逆に、リリース作業まで込みの契約もあります。どちらが正しいということはなく、読まないと分からないというだけです。

確認する観点は3つです。稼働後の障害対応とロールバックが月額に含まれるか。定期的な更新作業(ライブラリやOSの更新)が含まれるか。夜間・休日の対応が含まれるか、含まれるなら受付時間と追加料金はどうなるか。保守や改修をどこまで外に出すか、費用の相場をどう読むかという話は本記事の範囲を越えますので、「システム改修 保守 外注」の記事をご覧ください。

権限とアカウントは発注者が持つ——確認する4点

最後がいちばん見落とされます。当社に開発会社の乗り換えのご相談をいただいたとき、必ず聞くのが「クラウドのアカウントとドメインはどちらの名義ですか」という質問です。答えられない発注者は少なくありません。

棚卸しすべきなのは次の4点です。

1. クラウドのルートアカウント——AWSやGoogle Cloudの契約名義と、請求先。開発会社の名義になっていないか
2. ドメインの登録者——自社サービスのドメインを、誰の名前で誰の管理画面で更新しているか
3. ソースコードのリポジトリ——GitHubなどの組織アカウントの所有者は誰か。開発会社の組織の下にぶら下がっていないか
4. デプロイの設定と手順書——パイプラインの定義や手順書が、リポジトリの中に残っているか。担当者の頭の中や個人のPCにしかない状態になっていないか

この4点が自社側にあれば、開発会社を変えても本番は動き続けます。逆に、どれか1つでも相手側にあると、関係が悪化したときに交渉材料にされます。乗り換えの実務、引き継ぎで受け取る資産の一覧、契約で確認する条項については、「開発会社 乗り換え 引き継ぎ」の記事に詳しくまとめてあります。

さて、いまお読みの案件では、この4つは議事録のどこに書かれているでしょうか。

オフショア開発でのデプロイ運用と、当社の体制——向く案件・向かない案件

海外の開発チームに任せると、本番リリースの立ち会いはどうなるのか。深夜に連絡がつかないのではないか。こうした懸念をよくいただきます。結論から言うと、国と時差の選び方で大きく変わります。ここでは当社の体制を例に、実際の運用と、向く案件・向かない案件を率直に書きます。

時差2時間だと、日本時間の午前にリリースできる

ベトナムと日本の時差は2時間で、ベトナムのほうが遅れています。日本の午前9時は現地の午前7時です。つまり、日本時間の午前中にリリースを行っても、現地チームは通常の勤務時間内に入っています。夜間対応を前提にしなくても、双方が起きている時間帯に本番反映と監視ができます。

これは実務上、はっきりした差になります。時差が5時間を超える国では、日本の営業時間と現地の勤務時間が半分しか重ならず、リリース当日の連絡が翌日に持ち越されることがあります。当社の拠点はホーチミンで、ベトナムの法定祝日は2026年で年12日(労働法112条の条文上は11日で、2026年からベトナム文化の日が加わります)、2026年のテトは2月14日から22日です。この期間を外して計画を立てれば、連絡が取れない日をあらかじめ避けられます。

当社の体制——リリース前ダブルチェックと、可否判断はお客様側に残す

当社は品質管理として3つを標準にしています。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、そしてリリース前のダブルチェックです。3つ目が本記事の主題に直結します。本番へ反映する前に、実装した本人以外の目で、対象範囲と戻し方を確認します。

一方で、本番に出すかどうかの判断そのものは、お客様側に残していただく方針です。リリースは技術作業であると同時に事業判断だからです。介護記録SaaS「CareViewer」では、日本語のできるブリッジSE1名とフルスタックエンジニア2名の体制で、週次で優先順位を判断しながら継続開発していますが、何をいつ出すかの決定はお客様が持っています。当社が持つのは、出せる状態を作ることと、戻せる状態を用意しておくことです。

体制は2パターンあります。パターンAは日本人PMまたはブリッジSEをフロントに置き、その後ろにエンジニアを配置する形で、当社の推奨です。パターンBはエンジニアのみの構成です。1名から、最短2週間で開始でき、増員は約1週間、縮小や交代は1か月単位で調整します。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

向く案件・向かない案件と、これから開発を発注する方へ

正直に書きます。当社のようなラボ型の体制が向くのは、リリースが1回で終わらない案件です。作った後に毎月の改善が続き、デプロイが繰り返し発生する。そういう案件では、専属チームが仕組みごと持ち続けるほうが、毎回外注するより速く、安く収まります。実務3年目安のエンジニアで1,500USD(約22.5万円・1USD=150円換算目安)、最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。当社は2,000名以上のIT人財データベースから直接アサインするため、協力会社を経由する仲介マージンが乗りません。

向かないのは、一度作って終わりの小規模なサイトや、稼働後の更新がほとんど発生しない案件です。その場合は国内の会社に一括で発注し、運用は自社の担当者が手動で行うほうが、総額も手間も少なく済みます。合わない案件に無理に体制を組むことは、失敗のもとです。

これから開発を発注する方へ。デプロイという言葉の意味を押さえたら、次にやるべきことは技術の勉強ではありません。見積書の「リリース作業一式」を工程に割ってもらうこと、切り戻しの判断者と時限を議事録に残すこと、保守契約にリリース後の障害対応が含まれるかを読み直すこと、そしてクラウドのアカウントとドメインの名義を確認すること。この4つです。どれも技術者でなくてもでき、どれも後からでは取り返しがつきにくい部分です。契約書に一行足しておくかどうかで、1年後の選択肢の数が変わります。

デプロイに関するよくある質問

デプロイについて、発注者の方から実際によく届く質問を5つ挙げます。いずれも契約や計画の段階で確認しておくと、リリース当日の混乱を減らせるものです。

Q1. デプロイは日本語で何と言えばよいですか

配備、配置、展開が訳語にあたります。ただ実務では訳さずに使われるため、社内資料では「本番環境への反映」と書き換えるのが分かりやすい方法です。稟議書であれば「本番環境への反映作業」と書けば、技術者でない決裁者にも通じます。

Q2. 見積書の「デプロイ・リリース作業 一式」は、どう読めばよいですか

工程に割ってもらってください。ビルド、自動テスト、ステージングへの反映と検証、リリース判定、本番反映、反映後の監視の6つのうち、どこが含まれるかを確認します。監視が含まれていない見積もりは珍しくありません。含まれていないなら、誰がいつまで見るのかを別途決める必要があります。

Q3. リリース当日に発注者が立ち会う必要はありますか

技術作業に立ち会う必要はありませんが、判断できる人が連絡の取れる状態にいてください。切り戻すかどうかは事業判断です。あわせて、反映後に自社の業務担当者が主要な処理を1件ずつ試す時間を、当日の予定に入れておくと安全です。

Q4. デプロイを自動化すると費用は下がりますか

仕組みを作る初期費用がかかるため、短期では上がります。回数が増えるほど1回あたりの作業費が下がり、人為的なミスも減ります。年に1〜2回しかリリースしない案件では投資が回収できないこともあるため、想定するリリース回数から逆算して判断してください。

Q5. デプロイの権限は自社で持つべきですか

操作そのものは開発会社が行って構いません。ただし、クラウドの契約名義、ドメインの登録者、リポジトリの所有者、デプロイ設定の置き場所の4点は自社側で保持してください。開発会社を変えても本番が動き続けるための最低条件。

まとめ: デプロイは「置く作業」——発注者が決めるのは日程・切り戻し・契約範囲・権限の4つ

デプロイとは、作ったソフトウェアを実際に動く場所に配置し、使える状態にする作業です。ソースコードを実行できる形にまとめるのがビルド、置いて動く状態にするのがデプロイ、利用者に使えるようにするのがリリース。3つは連続していますが同じではありません。デプロイメントはデプロイの名詞形で、意味は同じです。機能フラグを使えば「デプロイ済みだが未リリース」という状態も作れます。進捗報告で「デプロイは終わっています」と言われて画面が変わっていないときは、ステージング環境への反映か、この状態のどちらかです。

環境は開発・ステージング・本番の3つに分け、本番へは検証を通してから運びます。流れはビルド、自動テスト、ステージングへの反映と検証、リリース判定、本番反映、動作確認と監視の6段階。失敗したときに戻すことをロールバックと呼びますが、データベースの構造を変えた場合、外部へ送信済みの処理がある場合、前のバージョンを残していない場合は、単純には戻せません。戻せるかどうかは当日の頑張りではなく、事前の設計と契約で決まります。手作業を仕組みに置き換えるのがCI/CDで、自動テストが通ったものを自動で運びます。ただし本番に出す判断と、戻す判断は自動化されません。

そして発注者が決めるのは4つです。リリース日と時間帯(金曜の夕方と月末月初を避ける)、切り戻しの判断者と連絡経路と分単位の時限、保守契約に含まれる作業の範囲、そしてクラウドのルートアカウント・ドメイン・リポジトリ・デプロイ設定という権限4点の名義。この4つが議事録と契約書にあるかを、今週のうちに確認してください。保守や改修をどこまで外に出すか、費用をどう読むかはシステム改修・開発保守の外注に、開発会社を変えるときに受け取る資産と契約の確認項目は開発会社の乗り換えと引き継ぎにまとめてあります。当社はホーチミンを拠点に、日本人PMをフロントに置いたラボ型の開発チームを提供しています。時差2時間なので、日本時間の午前中のリリースに現地チームが同席できます。最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、リリース運用の組み方を含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。