メインコンテンツにスキップ
自媒科技企業向けAI・開発から導入まで
日本語JA
プロジェクト相談
プロジェクト相談

企業AIプロジェクトWiki · 環境・バージョン・リリース

デプロイ

別名Deployment · ソフトウェア配備 · Application Deployment · 本番配備

定義

デプロイとは、識別可能なSoftware／System Versionを、管理された手順で指定対象環境へ導入、設定、更新し、依存、DB、権限、起動、Health、記録を確認して期待する実行状態を作る過程です。完全なデプロイは入力Artifact、Target、実行手順、変更結果、検証証拠、失敗時の停止・復旧を説明でき、「FileをUploadした」だけでは完了しません。

デプロイが変えるもの

BuildはArtifactを作り、デプロイはArtifactと対象環境を結び付けます。同じImageでも設定、ID、DB、Networkが違えば実行結果は変わるため、Softwareだけでなく関連する環境状態も変更対象です。

Command成功や画面表示だけでは完了しません。新InstanceのReady、依存接続、DB版、主要業務Smoke、Log・Metric、環境記録を確認します。

デプロイと利用者公開は分けられます。Zero TrafficやFeature Flagの後、Release判断で公開すれば、技術導入と業務公開を一つの高Risk Eventにせずに済みます。

開始前に確定する入力・条件

危険なデプロイでは、作業時間に入ってから、どのArtifactをどのAccountへ入れるのか、DBをどう変えるのか、失敗時に誰が止めるのかを確認し始めます。これらは現場で補う細部ではなく、変更を実行可能にする入力です。未確定のまま自動化しても、不確実な変更を誤ったTargetへ速く適用するだけです。

  1. どの不変Artifactか

    製品・Component版、Build、保管先、Digestを指定し、Branch、Working Directory、可動`latest`を正式入力にしません。

    入力：Release Manifest、署名、Digest。

  2. どのTargetか

    環境、Account、Region、Cluster、Namespace、Host、SlotとTarget IDを確認し、似た名称の手選択に依存しません。

    入力：Target ID、環境一覧、Pipeline Binding。

  3. 同時に何を変えるか

    設定、Secret参照、証明書、DB Migration、Cache、Queue、Schedule、Flag、外部Endpointを列挙します。

    入力：Change Set、変更前後状態。

  4. どのEntry Gateか

    前段Test、Artifact Scan、承認、時間帯、Backup／Restore Point、Capacity、依存可用性を確認します。

    入力：Gate結果、承認者、Window。

  5. 成功をどう判断するか

    Health、主要業務Smoke、Data確認、性能傾向、Error率、Alert、観測時間を事前定義します。

    入力：Check、Threshold、証拠先。

  6. いつ停止・復旧するか

    Migration、Readiness、Error、Data、依存障害の停止点とRollback、Roll-forward、Restore担当を決めます。

    入力：停止条件、復旧計画、連絡先。

Pipeline成功だけでデプロイ完了と言えない理由

Pipelineの成功は通常、予定したCommandが終了したことを示すだけで、Targetが正しい状態になった証明ではありません。Artifact、設定、DB、Health Check、主要業務、可観測性、最終環境記録が一致して初めて完了です。一つでも未達なら、検証、復旧または観測中のデプロイとして扱います。

  1. Window・TargetをLock

    権限、Target、現版、並行変更、担当を照合し、複数配備や手修正の衝突を防ぎます。

  2. Artifact取得・検証

    信頼済みRepositoryからDigest指定で取得し、署名、Provenance、依存、Scanを確認してTargetで再Buildしません。

  3. 現状態を保存

    Application、設定、DB、Traffic、Instance、Healthを記録し、Riskに応じBackup、Snapshot、旧Planeを保持します。

  4. 基盤・設定を適用

    IaCと設定管理でResource、ID、Network、Secret参照、Runtime Parameterを適用します。

  5. 互換Data変更

    Schema・Data Migrationを順序実行し、Lock、Batch、Timeoutを制御し、不可逆処理前に停止・復旧条件を再確認します。

  6. 配備・起動

    In-place、Rolling、Blue-green、段階方式で更新し、Warm-up、Startup、Readiness、Livenessを通します。

  7. 技術・業務を検証

    自動検証、主要Smoke、Log、Metric、Trace、Queue、DB、外部連携を観測WindowでBaseline比較します。

  8. 確定・記録・復旧

    完了条件を満たせば状態を確定し、未達なら影響拡大を止め、Traffic復元、Rollback、Roll-forward、Restoreを実行します。

主なデプロイ方式

方式の名称だけで安全になるわけではありません。新旧Versionが共存する時間、追加Resource、最初に公開するTraffic、停止や切戻しの速さを組み替える選択です。Data互換性、Session、非同期処理、観測可能なTraffic、許容中断を見て選び、慣れた名称だけで固定しません。

方式使い方と主な代償
In-place現Instanceを直接更新しResourceは少ない一方、失敗時の停止、旧状態上書き、再配備／復元Riskがあります。
Recreate旧Instance停止後に新規作成し状態は明確ですが、容量低下や中断が生じます。
Rolling一部容量を維持して順次交換します。新旧版の短期共存互換性とBatch観測・停止が重要です。
Blue-green別Planeへ配備・検証後にTraffic切替し、旧Planeへ早く戻せます。追加ResourceとDB、Session、非同期整合が課題です。
Canary／Wave少数Instance、Region、RequestからMetricにより拡大します。Routing、代表Traffic、成功条件、自動停止が必要です。
Shadow実Requestを複製して結果を返さず比較します。Write、通知、課金Callなど実副作用を遮断します。

Data・設定・Trafficを別に扱う理由

Application Artifactは再配備できても、書込み済み業務Data、送信済みMessage、実行済み外部Actionは元に戻せない場合があります。設定とRouteは、同じCodeが何へ接続し、どの権限で、どのRequestへ影響するかを変えます。可逆性、検証方法、責任者が異なるため、計画も分けて明示します。

App RollbackはData Rollbackではない

旧Codeが新Schemaを読めず、書込み済みDataもあります。後方互換のExpand、Backfill、Switch、Contractを優先し、不可逆処理は別承認します。

設定も配備状態

Endpoint、Role、Flag、Limitが違えば同一Artifactでも別Systemです。設定をVersion化、Review、検証、記録し、Secretは管理参照で注入します。

配備とTrafficを分離

Zero Trafficで作成し、Healthと直接Test後に段階Routingします。Traffic変更にもMetric、停止、復旧記録が必要です。

非同期は新旧共存

Message、長Transaction、Job、Consumerが旧Codeを継続するため、Schemaと冪等性は移行期間を許容します。

Healthは層別

Process Liveness、Traffic Readiness、依存、業務Read/Write、End-to-endは別問題です。一つの`200 OK`で代替しません。

戻した後も検証

旧Instanceへ戻すだけでは復旧証明になりません。DB、Message、Cache、外部Action、Error、Backlogを再確認します。

残すべきデプロイ記録

記録の目的は、緑色のPipeline番号が存在したと示すことではありません。担当者が変わり、環境が更新され、後でIncidentが起きても、誰が何をどこへ配備し、何が変わり、どう確認したかを再構成できる必要があります。この証拠鎖がなければ、現状態も復旧起点も記憶頼みになります。

  1. 配備ID

    固有ID、Pipeline Run、人／Workload ID、承認者、開始終了、Target。

  2. 入力・変更

    製品・Component版、Build、Digest、設定、Migration、基盤、依存先。

  3. 実行履歴

    Step状態、Log、Retry、手動介入、差異、方式。

  4. 検証証拠

    Probe、Smoke、Data Check、Metric、Alert、観測時間、実結果。

  5. Traffic・Feature状態

    新旧Traffic比率、Flag、対象利用者、変更時刻。

  6. 最終環境状態

    稼働Version・Digest、Instance、設定、Schema、既知問題、次担当。

  7. 失敗・復旧

    Trigger、影響、停止、Rollback／Roll-forward、復旧検証、Follow-up Issue。

企業AIで追加する配備管理

企業AIは一つの同期Packageとして変わるとは限りません。Model Endpoint、Application、Prompt、Knowledge Index、Guardrail、Tool権限は別々のLifecycleで更新されます。Endpointの`200 OK`はCall経路の応答だけを示し、回答の根拠、検索権限、Tool Actionの安全性は証明しないため、一つの識別可能な配備へ関連付けた上で層別に検証します。

ModelだけがArtifactではない

Model、Inference Code、Runtime Image、System Prompt、Filter、Knowledge Index、Tool定義、評価設定を一つのManifestへ関連付けます。

Model配備とEndpoint Trafficを分離

新ModelをZero Trafficで配備し、直接Call、Mirror、少量Trafficで検証後に拡大します。

Knowledgeは独自Lifecycle

Ingestion、権限同期、Embedding、Index、CacheはApp配備なしに変わります。Batch、追加削除、Retry、可視権限、Rollback Pointerを記録します。

Prompt・Guardrailを整合切替

新Promptと旧Tool／Schemaの混在を避け、関連設定をAtomicに配備するか互換順序と中間状態を定義します。

Agent副作用を先に遮断

Zero Traffic、Shadow、TestはRead-only、Sandbox、Allowlist、最小権限で、引数、承認、冪等、Timeout、人への移管を確認します。

可用性以外の品質を観測

拒否、根拠なし回答、検索、Tool失敗、人移管、Hard Stop、Latency、Error、Resource、Costを追跡します。

托管Model変更を再評価

Aliasや挙動が配備なしに変わる場合、具体版を固定／観測し、Provider更新を監視、再評価、復旧へ含めます。

デプロイと混同しやすい概念

BuildはArtifactを作り、デプロイはTargetで実行状態を作り、Releaseは誰が使えるかを決めます。Go-liveは正式業務利用へ移し、Deliveryは成果と責任を受領側へ渡します。同じWindowで複数を行っても記録と検収は分けなければならず、「本番になった」だけでは技術状態、対象者、責任移転を説明できません。

関連概念違い
BuildSourceと依存からArtifactを作ります。デプロイは既存ArtifactをTargetへ適用し、そこで正式Artifactを再Buildしません。
Release準備済みVersionをTraffic、Flag、Channelで誰へ提供するか決めます。デプロイは実行状態を作ります。
Go-live業務利用開始Eventで、配備、Data Cutover、利用者公開、連絡、運用引継ぎを含み得ます。
Data MigrationData位置、構造、内容を変え、配備Stepにも独立作業にもなります。整合・復旧を別設計します。
Configuration Management継続的に状態を識別・統制し、デプロイはある時点で承認状態をTargetへ適用・検証します。
Delivery成果物、文書、Access、責任を受領側へ移します。デプロイは一部の場合も、受領後に顧客が行う場合もあります。

出典と適用範囲

ここでいうデプロイは、指定Softwareと設定を対象環境で実行・検証できる状態へ変える技術的変更です。Build、Release、Go-live、Traffic切替、Feature公開、Data Migration、Deliveryそのものではありませんが、一回のデプロイに一部を含む場合があります。開発、テスト、UAT、ステージング、本番のどこでも行われ、本番へデプロイしても直ちに全利用者へ公開する必要はありません。