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

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

リリース

別名Release · ソフトウェアリリース · バージョン公開 · 機能リリース

定義

リリースとは、識別可能なソフトウェアのバージョン、機能または設定を、指定時刻に所定の経路で明確な対象者が取得・閲覧・利用できる状態にすることを組織が承認し、その影響を確認する統制された過程です。変わるのは利用可能性と公開範囲であり、Traffic Route、Feature Flag、利用権限、Download Channel、Store配信などで実施できます。デプロイと同時である必要はありません。

リリースが変えるのは、誰が何を使えるか

VersionがBuild、Testされ、本番Resourceへデプロイされても、利用者へリリース済みとは限りません。新CodeをZero Trafficのまま保持する、機能を既定Offにする、DownloadをDraftにする、Accountへ利用権限をまだ付けない、といった状態があります。予定した利用者が所定経路で取得または利用できて初めて公開状態が変わります。

逆に、リリース時点でCodeをデプロイしない場合もあります。非公開機能を先に配備し、承認時にはFlagやRouteだけを変えられます。Client ApplicationはPackとStore審査を先に終え、指定日にDownloadを開始できます。APIの新機能も、承認済み顧客だけへ有効化できます。

したがって記録には対象物と公開状態の両方が必要です。`v2.3.0 リリース済み`だけでは、Source Tag、Installer、本番機能、特定Tenant、全利用者のどれを指すか分からず、Support、Incident判定、公開停止に使えません。

対象単位・利用者・経路・状態を先に定義する

Release Unit

製品全体のVersion、単一機能、API Version、設定、Model機能、Knowledge Batch、Client Packageのどれを公開するかを明記し、不変Version、Artifact Digestまたは設定Snapshotへ結びます。

対象者

社内利用者、Pilot User、指定Tenant、地域、Device種別、Opt-in User、Traffic比率、全利用者のいずれかを定めます。選択Ruleは実行・再現できる必要があります。

公開経路

Web Traffic、Feature Flag、Entitlement、API Gateway、Package Repository、Download Page、App Store、Device Update、手動開通のどれで利用可能にするかを示します。

時刻と進行

開始時刻、各段階の長さ、観測Window、Pause Point、全面公開条件、Support要員の対応時間を決め、技術操作と通知の時間をそろえます。

利用可能状態

Draft、Candidate、承認済み、社内限定、限定公開、拡大中、全面公開、Pause、Withdraw、Support終了を区別します。Pipeline成功だけを状態にしません。

責任と権限

準備者、業務・Risk承認者、公開操作担当、監視担当、Pause・Withdraw決定者、緊急時の最終権限者を記録します。

公開前に満たす開始条件

  1. 対象を追跡できる

    Release Version、構成Artifact、設定、依存関係がFreezeされ、再取得できます。

    Version Manifest、Digest、署名、Provenance記録

  2. 必要な検証が完了している

    合意したTest、検収、Defect処置、Security確認、Target環境検証が終わり、未解決事項には受入者と影響説明があります。

    Test・検収結果、Risk受入記録

  3. 公開仕組みを確認している

    Traffic、Flag、権限、Channel、Store設定が対象者だけへ適用され、Cache、Session、地域伝播、失敗時動作を確認しています。

    対象Account確認、設定Preview、演習記録

  4. 指標と閾値がある

    技術、業務、Security、利用者影響のBaseline、成功範囲、観測時間、Hard Stop条件を公開前に合意します。

    Release Dashboard、Alert、判定Rule

  5. 復旧経路を実行できる

    拡大停止、機能Off、旧Route復帰、Package撤去、技術Rollbackが可能です。不可逆Dataや外部Actionは別に扱います。

    Withdraw・Rollback手順、復旧演習

  6. Supportと連絡を準備している

    運用、Support、業務責任者、対象利用者へ、変更点、既知制約、問題窓口、緊急連絡先を提供し、必要なRelease Noteを準備します。

    Release Note、当番表、通知記録

代表的なリリース方式が制御する範囲

方式公開範囲と主な注意点
一括公開対象者全員へ同時に公開します。単純ですが未知の問題が最大範囲へ直ちに及ぶため、影響が限定され、検証が十分で、短時間で復旧できる変更に適します。
社内・Pilot公開社員、Test Tenant、実業務Pilotへ先に公開します。対象者、Data権限、Feedback責任を明確にし、Pilot成功を全面承認と同一視しません。
Ring・Wave公開Risk層、組織、地域、Device、時刻Groupごとに対象を広げます。各Ringに観測時間と継続・Pause・Withdraw条件が必要です。
割合・Canary公開代表性のある少数UserまたはRequestに新Versionを先に割り当てます。User体験の割当を安定させ、指標を新旧Groupへ帰属できるようにします。
Feature Flag公開Codeは配備済みでも既定では隠し、指定対象へFlagをOnにします。Flagにも権限、監査、安全なDefault、障害時動作、廃止期限が必要です。
利用者Opt-in利用者がPreviewや新体験を選びます。Opt-out方法、互換性、Data影響、Support範囲を説明します。
Channel・Store公開Repository、Download Page、App Storeから提供します。審査承認、掲載、Download可能、自動Update、実際の採用は別状態であり、Cache、地域、Client方針の影響を受けます。

統制されたリリースの進め方

  1. 現在状態を確認する

    本番Version、有効機能、現対象者、並行中のRelease、Service Health、利用可能なRisk Budgetを確認し、複数変更でSignalを混ぜません。

  2. Release Contractを承認する

    権限者がUnit、対象者、Channel、段階、指標、Hard Stop、Withdraw経路、連絡、担当を確認します。

  3. 比較Baselineを保存する

    公開前の技術、業務、品質、Security、人工処理の指標を保存し、新旧Groupと未公開Groupを識別できるようにします。

  4. 最初の対象へ公開する

    主要Riskを検出できる最小範囲へRoute、Flag、権限、Channel状態を変更し、正確な時刻と設定Versionを記録します。

  5. 割当と動作を検証する

    対象者だけが新機能を得て、非対象者が旧状態を保つことを確認し、Login、権限、重要Flow、Data Write、縮退経路を点検します。

  6. 観測して判定する

    予定時間内にGroup比較と絶対閾値を確認し、AlertとFeedbackを調査します。Sample不足やSignal矛盾時は現範囲を維持し、無Alertを成功証明にしません。

  7. 拡大・Pause・Withdrawを決める

    各判断と理由を残し、継続条件を満たす場合だけ拡大します。Hard Stop時は新規公開を即時停止し、所定の復旧Actionを実行します。

  8. ReleaseをCloseする

    最終対象、機能状態、残課題、Support情報、長期監視を確認し、対象物、Note、証拠、判断をArchiveし、不要Flagの削除を予定します。

観測・停止・公開取消し・証拠

Serverだけでなく利用結果を見る

可用性、Error、Latency、Capacityに加え、Task完了、離脱、Support問合せ、権限異常、Data正確性、業務Guardrailを追跡します。

Hard Stopを優先する

Data漏えい、権限逸脱、不可逆の誤操作、誤課金、重要Data破損、Security Control無効化、追跡不能は、統計判断を待たず拡大を止めます。

Pauseは失敗終了ではない

十分なSample待ち、外部障害の切り分け、調査の間だけ公開範囲を固定します。監視を続け、最長Pause時間を決めます。

Withdrawと配備Rollbackを分ける

Flag Offや旧Route復帰で利用者公開を除いても、新Codeは環境に残る場合があります。Artifact、設定、DB、Modelまで戻すかは影響別に判断します。

実際の公開履歴を残す

Release ID、対象Version、各Audience Rule、設定Snapshot、時刻、承認者、指標、Alert、Feedback、Pause、Withdraw、最終状態を保存します。

Release材料と由来を保管する

正式Artifact、Integrity・Provenance、Release Note、既知制約、Security Advisoryを保管し、後日の脆弱性分析や顧客連絡を可変Tagに依存させません。

企業AIのリリースで追加確認すること

組合せ動作を公開する

Application、Model SnapshotまたはEndpoint Route、System Prompt、Guardrail、Knowledge Index、検索設定、Tool権限、外部Policyが結果を共同で作ります。Model名だけでなく全組合せを記録します。

Model配備とTraffic公開を分ける

新ModelをEndpointへ配備し、Directed・Shadow Requestで検証してから実Trafficを段階公開できます。Route Weight、Session固定、地域、Fallback ModelもAudience Contractに含めます。

Task別の品質Gateを使う

Latency、Error、Costだけでなく、根拠付き回答、適切な拒否、検索命中、Format遵守、Tool成功、人工引継ぎ、重要業務結果を固定Evaluationと現本番Baselineに比較します。

高Risk機能の権限を先に絞る

Message送信、Record更新、Order作成、承認、Code実行を行うAgentは、利用者、Tool、金額、対象、頻度を限定し、人工承認と冪等Controlを保ってから拡大します。

Knowledge権限をHard Gateにする

検索可能にする前に、文書増減、Tenant・Role権限、Index完了、引用先、Cache反映を確認します。権限誤りは関連性の揺れではなくHard Stopです。

非決定性に十分な観測を与える

同じ入力でも出力が変わり、低頻度障害が長い会話だけで現れることがあります。十分なSample、層別Scenario、反復実行を用い、少数Demo成功で代用しません。

Provider変更もRelease Eventとして扱う

Hosted Model Alias、Safety Policy、API動作は自社デプロイなしに変わり得ます。実Versionと品質Driftを監視し、必要ならVersion固定、Route変更、機能停止、再審査を行います。

リリースと混同しやすい概念

関連概念リリースとの違い
デプロイArtifactと設定をTargetへ適用し、検証済み実行状態を作ります。リリースは対象者への利用可能性・公開範囲を変えます。同時にも分離にもできます。
BuildSourceと依存からArtifactを作ります。リリースは識別可能なArtifactまたは機能を選び、利用者への提供を承認します。
バージョン番号対象を識別しますが、公開済みであることは証明しません。同じVersionがDraft、Candidate、限定公開、全面公開、Support終了の状態を進みます。
Go-live正式業務利用への総合移行で、デプロイ、リリース、Data Cutover、Training、連絡、運用引継ぎを含み得ます。リリースは一部利用者だけでも成立します。
Release告知変更を伝える行為であり、機能、Package、権限が実際に利用可能とは限りません。社内限定Releaseには公開告知がない場合もあります。
納品契約成果、文書、Access、責任を受領者へ移します。リリースは利用者への可用状態を変え、所有権や保守責任の移転を必須としません。
ロールバック技術状態を以前のBaselineへ戻します。Release不具合時は、配備全体を戻す前に利用者公開だけをWithdrawすることもできます。

出典と適用範囲

本項は、準備済みのソフトウェアまたはAIのバージョン・機能を、定めた利用者へ公開するリリースを扱います。release の意味は組織や製品によって同一ではありません。テスト済み構成項目の集合、ダウンロード可能なパッケージと記録、または機能を段階的に公開する過程を指す場合があります。そのためプロジェクトでは、リリース対象、利用者、経路、完了状態を明記し、「リリース済み」だけで済ませません。デプロイ、Go-live、App Store審査、告知、納品、ロールバックの完全な定義は本項の対象外です。