2026年10月8日に、GitHub Actionsの基礎資料、GitHub Pagesの説明、npm runの現行リファレンスを再読しました。Actionsはイベントでworkflowを起動し、job・step・actionをrunnerで実行します。PagesはリポジトリのHTML・CSS・JavaScriptを静的サイトとして公開し、必要ならbuild processを通します。npm runはpackageのscriptsをpackage rootで実行し、引数、shell、node_modules/.bin、workspaceの指定が結果に影響します。どれも、配備が終わったこと、公開されたこと、正しく動くこと、承認済みであることを同じ意味にはしません。
デプロイは、作ったプログラムや設定を、動かす先の環境へ配置・反映することです。Webサイトをインターネットで公開するときにも行いますが、社内だけのシステムや、確認用の環境への反映もデプロイです。
本の出版にたとえるなら、原稿を整え、印刷できる形にし、配布先へ届ける工程に近いでしょう。ただし、配置が終わったこと、利用者に公開したこと、正しく動くことは同じではありません。この違いを、ビルド・テスト・承認・公開後の確認まで含めて説明します。
30秒で要点
- デプロイは環境への配置・反映。誰に公開するかは、環境・権限・設定などで別に決まる。
- ビルド、テスト、デプロイ、リリースの役割を分ける。自動化しても、設定していない検査は実行されない。
- 開発・検証・本番は、名前だけでなくデータ・接続先・秘密情報・権限を分けて確認する。
- 不具合時に以前のコードへ戻せても、DBの変更や送信済みの通知まで元に戻るとは限らない。監視と復旧の担当を先に決める。
作ったものが利用者に届くまで
ローカルのパソコンで動くページは、そのまま他の人の端末へ届くわけではありません。配備先で動く形に準備し、必要な設定を渡し、通信やアクセスの条件を整える必要があります。
表が収まらない場合は、横にスクロールできます
| 言葉 | このガイドでの役割 | 終わっても別に確認すること |
|---|---|---|
| ソースコード | 人が変更するプログラムなどの材料 | その変更が正しいか |
| ビルド | 材料を配布・実行できる成果物に変換する工程 | 成果物が目的どおりに動くか |
| テスト | 決めた条件を満たすか確かめる工程 | 未検査の条件や実環境との差 |
| デプロイ | 成果物・設定を対象環境へ配置・反映する工程 | 接続先、操作、公開範囲 |
| リリース | 利用者に機能を提供する判断・切り替え | 利用開始後の状態と影響 |
チームや製品によって、デプロイとリリースを同じ意味で使う場合もあります。用語を正すだけでなく、自分たちの手順で「いつ本番が変わり、誰が使えるようになるか」を確認してください。設定によっては一つの操作で両方が起こり、別の仕組みでは配備後に公開を切り替えます。
静的なページでは、事前に作ったHTMLなどを配る方式があります。サーバーで処理するアプリでは、実行環境、接続するDBや外部サービスも関係します。すべてのサイトで同じビルドや配備手順になるわけではありません。
どんな場面で必要になるか
表が収まらない場合は、横にスクロールできます
| 場面 | 配備するものの例 | 特に確認すること |
|---|---|---|
| 個人ブログ・ポートフォリオ | ページ、画像、設定 | 公開してよい内容、リンク、独自ドメイン |
| 企業サイト | 説明ページ、問い合わせ処理 | 表示だけでなく受付先と権限 |
| ECサイト | 商品画面、注文・決済に関わる処理 | 注文データとの互換性、二重処理、停止時の対応 |
| 社内システム | 社内用画面、業務処理 | 社外公開しない範囲、認証、実データの接続先 |
| 検証環境 | 開発中の変更 | 本番とは別のデータ・通知・権限 |
同じURLが開けても、必要な機能が全部動くとは限りません。トップページの表示と、ログイン、フォーム受付、DB更新などの確認は分けます。公開URLが発行されても、認証やアクセス制限の条件を確認する必要があります。
開発・検証・本番を分ける理由
開発環境は変更を作る場所、検証環境は利用前に確認する場所、本番環境は実際の利用者に提供する場所です。stagingやpreviewなど、確認用環境の名称は製品やチームで異なります。
環境を分けただけで、本番への影響が消えるわけではありません。検証環境が本番DBや本番のメール送信先を使っていれば、確認操作が実データや実顧客に影響する可能性があります。
表が収まらない場合は、横にスクロールできます
| 分ける対象 | 確認する問い |
|---|---|
| データ | 架空の検証データか、本番データを使う許可と管理があるか |
| 外部接続 | 課金・通知・決済などが実際に発生しないか |
| 秘密情報 | その環境に必要な値だけを渡しているか |
| 権限 | 誰が配備・承認・閲覧できるか |
| 設定 | 本番との違いを記録し、検証結果の範囲を説明できるか |
GitHub Actionsのenvironmentには、関連するjobが進む前の保護ルールや承認などを設定できます。ただし、利用できる条件はプランやリポジトリの公開範囲などに依存します。environmentという名前を付けただけで、必要なルールが有効になるとは考えないでください。GitHubの環境と保護設定
手動配備と自動配備は、何が違うか
手動で行う場合
担当者が成果物や設定を確認し、転送や管理画面の操作を行います。小さなサイトの初回公開などで使う場合がありますが、手順の抜け、対象環境の取り違え、誰が何を反映したかの不明確さを防ぐ必要があります。
ファイル転送や管理画面アップロード、接続先によってはSFTP・scpなどの手段が候補になります。これらの名前は方法の例であり、ここに実行するコマンド一式を示しているわけではありません。認証方法、接続先、転送する対象、戻す手順を契約と公式手順で確認します。
自動で行う場合
Git連携やCI/CDの設定により、変更をきっかけに検査や配備を動かします。たとえば、特定のブランチへの変更を検証環境に配備し、承認後に本番へ進む構成が考えられます。すべてのpushが必ず本番を更新するわけではありません。
表が収まらない場合は、横にスクロールできます
| 観点 | 手動中心 | 自動化した手順 |
|---|---|---|
| 開始のきっかけ | 担当者の操作 | 設定したイベントや手動起動 |
| 再現性 | 記録と手順書に左右される | 設定・依存関係・成果物の固定が重要 |
| 確認 | 担当者の確認を手順に入れる | 自動検査と必要な人の判断を組み合わせる |
| 主な注意 | 抜け、取り違え、属人化 | 誤設定、権限の広がり、誤った操作の反復 |
| 維持するもの | 手順、記録、引き継ぎ | 手順に加え、自動化設定と検査自体 |
自動化は手間を減らす助けになりますが、誤った手順を正しく繰り返すこともあります。手動か自動かより、対象と権限、失敗したときの止まり方を説明できることが大切です。
CI/CDを、ビルド・テスト・配備につなぐ
CI（継続的インテグレーション）は、変更を継続的に統合し、ビルドやテストから早くフィードバックを得る実践です。GitHub Actionsは、イベントをきっかけにjobとstepを実行し、ビルド・テスト・配備などを自動化できます。GitHub Actionsの構成
CDには二つの意味があります。継続的デリバリーは、必要なときにリリースできる状態を維持すること。継続的デプロイは、変更を継続して本番へ配備する実践です。DORAはこれらを区別し、ツールを入れるだけでは必要な能力や手順は整わないと説明しています。DORAの継続的デリバリー
たとえばpackage.jsonにbuildという処理が定義されたプロジェクトでは、npm run buildがその処理を実行します。これはデプロイそのものとは限りません。また、git pushは変更をリモートへ送る操作であり、配備が起きるかどうかは連携設定によります。意味を知らずに本番へつながる操作を試さず、プロジェクトの手順で確認してください。npmのrunの説明、Gitのpushの説明
GoogleのSRE教材は、再現可能なビルドや、使用するバージョン・承認・追跡の管理を説明しています。小さなサイトでも、「どの変更から作り、何を検査し、どの成果物を配ったか」を残す考え方は参考になります。Googleの運用体制をそのまま採用する必要があるという意味ではありません。リリースエンジニアリングの教材
時間を測るなら、待ち時間も分ける
次は、すべて順番に進む架空の工程です。製品の性能測定や、自動化による短縮実績ではありません。
表が収まらない場合は、横にスクロールできます
| 工程 | 仮の経過時間 | 種類 |
|---|---|---|
| ビルド | 4分 | 処理 |
| 検査 | 3分 | 処理 |
| 承認待ち | 5分 | 待ち |
| 配備 | 2分 | 処理 |
| 配備後の確認 | 6分 | 確認 |
| 合計 | 20分 | 待ちを含む経過時間 |
承認待ちを除いた工程の経過時間は15分です。並列に実行する工程があるなら、単純な足し算が開始から終了までの時間とは限りません。また、待ち時間を削るために必要な承認を無条件に外す、という判断にはしません。
配備先を選ぶときは、動かすものを説明する
2026年10月4日に確認した公式資料の範囲では、次のような入口があります。料金、容量、利用条件や対応機能は個別に確認してください。
表が収まらない場合は、横にスクロールできます
| 例 | 公式資料で確認する入口 | この比較だけでは決められないこと |
|---|---|---|
| GitHub Pages | HTML・CSS・JavaScriptを公開する静的ホスティング | サーバー側処理やDBをどこで動かすか |
| Vercel | Git連携などの配備方法、previewとproduction | アプリの対応条件、公開・権限・費用の設定 |
| Netlify | Git連携、CLI、手動の成果物アップロードなど | ビルドの実行場所、公開条件、使用機能 |
| GitHub ActionsなどのCI/CD | 検査や配備のworkflowを構成する | 実際の配備先と、その認証・運用責任 |
GitHub Pagesは静的ホスティングという範囲を確認して選びます。GitHub Pagesの公式説明
Vercelでは、Git連携などからdeploymentを作り、用途に応じた環境へ反映します。URLや環境があることと、必要なアクセス制限が設定されていることは別です。Vercelのデプロイの説明
NetlifyにはGit連携による配備と手動配備の入口があり、手動方式ではNetlify側でbuild commandを実行しない場合があります。ソースとビルド済み成果物のどちらを渡すかを確認してください。Netlifyの配備方法
GitLab CI/CDやCircleCIなど、ほかの選択肢もありますが、名称だけで機能・料金・安全性を一括比較はできません。自社の実行環境と権限に合う公式手順を確認します。
失敗したときは、どの段階かを切り分ける
表が収まらない場合は、横にスクロールできます
| 起きたこと | 最初に確認するもの | 避けたい進め方 |
|---|---|---|
| ビルドが失敗 | エラーログ、依存関係、必要な環境変数 | ローカルで動いたことだけを根拠に進める |
| 検査が失敗 | 失敗した条件、再現する入力、期待結果 | 通すためだけに検査を外す |
| 配備が失敗 | 権限、対象環境、成果物、配備先のログ | 違う環境へ何度も送り直す |
| 表示するが機能しない | API・DB接続、入力、受付、設定差 | トップページだけで成功とする |
| 利用後に不具合 | 影響範囲、変更内容、監視、戻す条件 | 原因が不明のまま同じ操作を繰り返す |
ログには秘密情報や個人情報が含まれることもあるため、共有する前に取り扱いを確認します。問題の切り分けは、日時、対象環境、変更の識別子、失敗箇所をそろえるところから始めます。
以前の版へ戻すことと、データの復旧を分ける
ロールバックは、以前の状態へ戻すための対応です。しかし、何が戻るかは仕組みによって異なります。以前のコードが現在のDB構造と互換性を持たなければ、コードを戻しただけでは動かない場合があります。
VercelのInstant Rollbackも、以前のdeploymentへの切り替えに加え、環境変数や外部API・DB・CMSの状態を確認するよう案内しています。外部の状態すべてを自動で巻き戻す機能として理解しないでください。Vercelのロールバックの条件
表が収まらない場合は、横にスクロールできます
| 対象 | 事前に決めること |
|---|---|
| コード・成果物 | 戻す版、互換性、切り替えの権限 |
| DB・保存データ | 変更の戻し方、バックアップ、復元時に失う更新 |
| 外部処理 | 送信済み通知や決済などを調べ、必要な対応を行う担当 |
| 利用者への対応 | 影響を説明する窓口と連絡条件 |
本番で初めて復旧方法を考えないよう、許可された検証環境で手順と担当を確かめます。バックアップの存在、復元を試した結果、実際の障害から復旧した実績は、それぞれ別の証拠です。
初回公開前に、一つの変更を追って確認する
最初は小さな変更について、次を紙や記録に並べます。実際の配備操作は、プロジェクトの権限と公式手順がそろってから行ってください。
- 何を変え、どの環境に反映するか。
- どの処理で成果物を作り、何を検査するか。
- 誰が配備・公開を承認し、誰が実行するか。
- 公開後に、表示・受付・接続・エラーを誰が確認するか。
- 異常なら、何を止め、どの版へ戻し、データをどう扱うか。
この経路が説明できたら、繰り返しの作業から段階的に自動化します。設定と手順を更新し、担当者が代わっても変更内容と確認結果を追えるようにしてください。
サーバー・保存データ・自動化を学ぶ記事
配備する先はサーバーの基礎、保存データの責任はデータベースの基礎、自動検査や承認の構成はCI/CDの入門へ進めます。接続に使う秘密情報の扱いはAPIキーと秘密情報の管理も参照してください。