インプレースアップグレードとは？意味・リスクとWindows Server・RHEL・DBの対応経路

インプレースアップグレード（in-place upgrade）は、いま動いているサーバーやPCの上に新しいバージョンを上書きして更新する方式です。英語の「in place」は「その場で」という意味で、新しいマシンを用意せず、同じディスク・同じインスタンスのままOSやミドルウェアを入れ替えます。設定・役割・データを引き継げる一方、更新中はそのマシンが止まり、失敗したときの戻し方は製品と方式ごとに決まっています。この記事では、対義語のクリーンインストール・並行アップグレードとの違いを整理したうえで、Windows Server・Windows 11・RHEL・PostgreSQL・MySQLそれぞれの公式の対応経路と、旧バージョンへ戻せなくなる条件を一次情報と実測で示します。

まとめ：インプレースアップグレードは「同じ場所で上書き」、戻し方を先に決める

インプレースアップグレードは環境を増やさない更新方式です。追加のサーバー費用も切り替え設計も要らず、手順は「バックアップ→事前チェック→上書き→動作確認」と一直線です。対義語は、環境を消して入れ直すクリーンインストールと、別のマシンに新版を作って移す並行アップグレード（マイグレーション）です。

リスクは製品ごとに具体的に決まっています。Windows Serverは公式表に載った経路しか上げられず（2025へは2012 R2から直接上げられる一方、2012 R2から2022へは上げられない）、Microsoftはドメインコントローラーにインプレースアップグレードを使わないよう明記しています。RHELはLeappで1メジャーずつしか上げられません。PostgreSQLのpg_upgradeは--linkで新クラスタを起動した時点で旧クラスタが使えなくなります。

停止できる時間帯があり、公式の対応経路に収まるならインプレースで上げます。無停止が必須なら、冗長構成を前提にローリングアップデートやブルーグリーンデプロイメントを検討し、採用前に切り戻しにかかる時間を検証環境で測ります。

インプレースアップグレードの意味と仕組み

「in place」の語義と上書きインストールという別名

「in place」は英語で「その場所で・元の位置のまま」を表す熟語です。IT用語としては、稼働中のシステムに直接新しいバージョンを入れる方式を指し、「上書きインストール」「アップグレードインストール」とも呼ばれます。「インプレースアップデート」「インプレース更新」「インプレースバージョンアップ」も同じ考え方の言い換えで、対象がOSならアップグレード、アプリの配備ならデプロイと呼び分けられる程度の違いです。

複数台のシステムでは、全台を止めて一括で入れ替える進め方と、AWS CodeDeployのIn-Placeデプロイのように1台ずつ順に入れ替える進め方があります。一括の場合は新旧のバージョンが同時に動かない代わりに、その間サービスが止まります。データ形式の変換が正しく済んだかは、どちらの進め方でも別に検証が必要です。

インプレースアップグレードで引き継がれるものと残ってしまうもの

Microsoft LearnのWindows Serverのインプレースアップグレード手順は、この方式を「設定、サーバーの役割、およびデータをそのまま維持したまま」新しいバージョンへ移すものと説明しています。新バージョンが対応しているアプリや役割、カスタマイズした構成ファイルを入れ直さずに済むのが利点です。ただしWindows Serverは更新先のバージョン用の有効なプロダクトキーが別途必要で、アプリはベンダーの対応状況を事前に確認します。

裏返すと、長年の運用で溜まった不要な設定や古いドライバー、原因不明の不調も一緒に引き継ぎます。クリーンな状態から作り直したいなら、インプレースは向きません。戻し方は製品ごとに異なり、Windows 10・11はアップグレード後10日間なら以前のバージョンへ戻せる一方、Windows ServerやRHELは事前のバックアップから復元するのが基本です。PostgreSQLのpg_upgradeのように、モードによって旧環境が残るかどうかが変わるものもあります。

インプレースアップグレードと対義語・他の更新方式の違い

更新方式は「環境をいくつ持つか」と「一度に入れ替えるか段階的に入れ替えるか」で分けると整理できます。

「インプレースアップグレードの対義語」を1つに絞るなら、PC・単体サーバーの文脈ではクリーンインストール、システム更新の文脈では並行アップグレード（マイグレーション）です。

クリーンインストール・並行アップグレードとの違い

クリーンインストールは環境を一度消して新規に入れ直すため、古い設定のゴミが残りません。代わりにアプリの再導入と再設定が必要です。並行アップグレードは別のマシンやインスタンスに新バージョンをまっさらな状態で作り、データと設定を移してから切り替えます。切り替え前にじっくり検証できますが、2環境ぶんの費用と移行作業がかかります。旧環境を残しておいても、切り替え後に新環境へ書き込まれたデータをどう戻すかを決めていなければ切り戻せません。

ハードウェアの更改を兼ねる場合や、メジャーバージョンを何段も飛ばす場合は、並行アップグレードが定石です。

ローリングアップデート・ブルーグリーンデプロイメントとの違い

ローリングアップデートは、複数台を稼働させたまま1台ずつ新バージョンへ入れ替えます。EC2のように同じサーバーを順に上書きする形もあれば、Kubernetesのように新しいPodを立てて古いPodと置き換える形もあり、上書きかどうかは基盤によって異なります。更新中の台数分の余裕があれば全体は止まりません。その代わり、新旧のバージョンが同時に動く期間ができるため、DBスキーマやAPIの後方互換を設計で担保する必要があります。少数から広げるカナリアリリースも同じ系統です。

ブルーグリーンデプロイメントは新旧2環境を用意してルーティングを切り替えるので、旧環境を残し、DBスキーマとデータの互換が保たれていれば、経路を戻すことで切り戻せます。1台構成のサーバーでは段階的な入れ替えの余地が無く、インプレースか並行アップグレードの二択になります。

Windows Serverのインプレースアップグレード：対応経路とリスク

「インプレースアップグレードとは」の検索結果では、Microsoft LearnのWindows Serverの手順ページが上位に表示されます。経路と制限はアップグレードパスの計画ページ（2026年4月時点）が定めています。

Windows Server 2025・2022へ上げられるアップグレード元

インストールメディアを使う場合の対応経路は次のとおりです。Windows Server 2025以降は非クラスター構成なら一度に最大4バージョン、2022以前は最大2バージョンまで上げられます。

見落としやすいのは2012 R2の行です。2012 R2から2022へは上げられないのに、2025へは直接上げられます。2012 R2を2022へ上げる計画は、2016か2019を経由するか、目標を2025に変えるかのどちらかに組み直してください。Windows Updateの機能更新プログラムで上げられるのは、2019と2022から2025への経路だけです。

Windows Serverのインプレースアップグレードで避けるべき構成

Windows Serverのインプレースアップグレードのリスクは、構成の制限、役割とアプリの互換性、失敗時の復元にかかる時間の3つで見積もります。このうち構成の制限としてMicrosoft Learnが挙げる主なものは次のとおりです。

• Active Directory ドメインサービス（AD DS）を動かすドメインコントローラー：技術的には可能でも使わない。新しいOSをクリーンインストールして昇格し、古いドメインコントローラーを降格する
• フェールオーバークラスター：インプレースではなく、クラスターOSのローリングアップグレードかクラスター対応更新を使う（ローリングは1バージョンずつ）
• 言語の変更、32ビットから64ビットへの変更、Server Coreとデスクトップエクスペリエンスの切り替え：アップグレードでは不可
• 評価版へのアップグレード、プレビュー版からのアップグレード、VHDから起動する構成、Windows Storage Server：非対応
• NICチーミング：アップグレード前に無効化し、完了後に再度有効にする

エディションはStandardからDatacenterへの変更はできますが、DatacenterからStandardへは下げられません。AWSのWindows Serverのアップグレード方法の説明も「Microsoftは従来、インプレースより新しいバージョンへの移行を推奨してきた」と書き、インプレースは速い代わりにソフトウェアの非互換でエラーが出うると整理しています。それでも現行のMicrosoft Learnは、上の制限に当たらない単体サーバーならインプレースを正規の手段として手順を載せています。

Windows Serverをインストールメディアで上書きする手順と事前の記録

アップグレード前に、失敗したときの調査材料として構成情報をファイルに残します。Microsoft Learnが示すコマンドは次のとおりです（管理者のPowerShellで実行し、出力はUSBメモリなどサーバーの外へ移す）。Get-ComputerInfoはPowerShell 5.1以降が必要で、5.1が入っていない版ではレジストリのHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersionにあるBuildLabExとEditionIDを確認します。

Get-ComputerInfo -Property WindowsBuildLabEx,WindowsEditionID | Out-File -FilePath .\computerinfo.txt
systeminfo.exe | Out-File -FilePath systeminfo.txt
ipconfig /all | Out-File -FilePath ipconfig.txt

完全バックアップを取り、復元テストまで済ませたら、インストールメディアのsetup.exeを実行し、エディションを選んでから「ファイル、設定、アプリを保持」を選びます。途中で何度か再起動します。Windows Update経由で2025へ上げる場合は、2019・2022に2026年3月以降の累積更新を入れたうえで、次のレジストリ値を設定すると機能更新プログラムとして表示されます。

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AllowWindowsServerFeatureUpdate"
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AllowWindowsServerFeatureUpdate" -Name "AllowWindowsServerFeatureUpdate" -PropertyType DWord -Value 1

完了後はGet-ComputerInfo -Property WindowsProductNameでバージョンを確かめ、想定どおり動かなければC:\Windows\PantherのセットアップログをSetupDiagで解析します。

EC2・Azure上のWindows Server：AMIによる事前バックアップと所要時間

AWSのEC2 Windowsインスタンスのインプレースアップグレード手順は、事前にAMIを作ってバックアップとテストに使うこと、2 vCPU・4GB RAM以上のインスタンスで行うことを推奨しています。所要時間は「短くて40分、長くて数時間」で、途中でステータスチェックに失敗することがあるとも書かれています。2012・2012 R2から2016以降へ上げる場合は、EC2ConfigからEC2Launchへの入れ替えも必要です。Azure上のVMはインストールメディア方式の対象外で、Azure向けの手順かWindows Update方式を使います。

Windows 11・10のインプレースアップグレードと修復インストール

PCでは、Windows 10からWindows 11への移行と、調子の悪いWindows 11を同じバージョンのまま入れ直す修復の2つの場面でインプレースアップグレードが使われます。Windows 10は2025年10月14日にサポートが終了しており、TPM 2.0などWindows 11の要件を満たすPCは、アプリとデータを残したまま上書きで移るのが一般的です。版ごとの違いはWindows 11 25H2の解説で扱っています。

setup.exeで「個人用ファイルとアプリを引き継ぐ」を選ぶ手順

Microsoftサポートのインストールメディアによる再インストール手順では、Windowsにサインインした状態でメディアのルートにあるsetup.exeを開き、「保持する項目を変更する」で残すものを選びます。

Microsoftはサインインした状態でのこの手順全体をインプレースアップグレードと呼んでおり、3つの選択肢は何を残すかの違いです。アプリと設定を残したまま直したいなら1行目を選びます。再インストール中にPCは何度か再起動し、入れるエディションはそのPCのライセンスと一致させる必要があります。

Windows Updateで同じ版を入れ直す「今すぐ再インストール」

Windows 11には、メディアを用意せずに現在のバージョンを上書きで入れ直す回復機能があります。Microsoftサポートの説明では、［設定］→［システム］→［回復］の「Windows Updateを使用して問題を解決する」で「今すぐ再インストール」を選ぶと、アプリ・ファイル・設定を保持したまま再インストールされます。検索でよく見かける「インプレース修復アップグレード」は、この同じ版での上書き再インストールを指します。

この項目は、Windows 11 2022年の更新プログラムより前のバージョンや職場・学校が管理するPCでは表示されない場合があり、2024年2月のオプション更新プログラム以降が入っている必要があります。表示されなければ、上のsetup.exeの方法を使います。

RHELのインプレースアップグレード：Leappで1メジャーずつ

Red Hat Enterprise LinuxはLeappというツールでインプレースアップグレードを提供しています。公式文書の対応経路は次のとおりで、どの経路も「元のマイナー版」が決まっている点に注意が要ります。

RHEL 9から10への手順書は「連続する次のメジャーバージョンへのみ」上げられると定めており、RHEL 8から10へは8→9→10の2回に分けます。RHEL 8から9への手順書も、RHEL 7から9へ直接は上げられないと明記しています。いずれの表もRed Hat Subscription Managerで登録したシステムに限って保証される経路です。

バックアップの取り方にも公式の注意があります。LVMスナップショットはシステム全体のバックアップにならず、失敗の内容によっては復旧できないため、ReaR（Relax-and-Recover）で完全バックアップを取るほうが安全だとしています。CentOSやAmazon Linux 2のようにインプレースの経路が用意されていない系統では、Amazon Linux 2からAL2023への移行のように新しいインスタンスへ移す並行アップグレードが前提になります。

データベースのインプレースアップグレード：PostgreSQLとMySQLで戻せなくなる条件

DBはデータファイルの形式が新しいバージョン用に変わるため、OS以上に「戻せるか」が重要です。PostgreSQLは実際に動かして確かめました。

pg_upgradeの代表的なモードと旧クラスタへ戻せる条件

PostgreSQLのメジャーバージョンアップはpg_upgradeで行います。公式ドキュメント（18系）によると、9.2以降から現行メジャーへ上げられ、ファイルの扱い方でモードが分かれます。代表的なのは次の4つで、ほかにLinuxとFreeBSDで使える--copy-file-rangeもあります。

公式の「Reverting to old cluster」節は、--linkで新クラスタを起動した場合は共有ファイルに書き込まれているため旧クラスタの使用は安全でなく、バックアップから復元する必要があると定めています。容量と時間を節約できる--linkや--swapは、引き換えに戻り道を捨てるモードだと考えてください。

PostgreSQL 17から18へのpg_upgrade実測：チェックサム不一致と旧クラスタの起動不可

2026年10月17日に、macOS上のPostgreSQL 17.11（約181MB・200万行）を18.6へ上げました。最初に引っかかったのは、PostgreSQL 18でinitdbの既定がデータチェックサム有効に変わった点です。既定のまま作った18の新クラスタに対して--checkを実行すると、次のエラーで止まりました。

old cluster does not use data checksums but the new one does
Failure, exiting

PostgreSQL 18のリリースノートも「pg_upgradeはクラスタのチェックサム設定の一致を必要とする」と書き、新オプション--no-data-checksumsを案内しています。新クラスタをこのオプション付きで作り直すと、事前チェックは通りました。以下は実測時のコマンドの抜粋で、新旧どちらのクラスタも停止した状態で、18系のバイナリを指定して実行しています。

/usr/local/opt/postgresql@18/bin/initdb -D new -U postgres --locale=C -E UTF8 --no-data-checksums
/usr/local/opt/postgresql@18/bin/pg_upgrade -b /usr/local/opt/postgresql@17/bin -B /usr/local/opt/postgresql@18/bin -d old -D new -U postgres --link --check
# *Clusters are compatible*
/usr/local/opt/postgresql@18/bin/pg_upgrade -b /usr/local/opt/postgresql@17/bin -B /usr/local/opt/postgresql@18/bin -d old -D new -U postgres --link

--linkでの実行中にはAdding ".old" suffix to old "global/pg_control"と表示され、旧クラスタを起動しようとするとcould not open file ".../global/pg_control"で起動できませんでした。新クラスタは200万行をそのまま持って18.6で起動しています。所要時間は--copyが5.56秒、--linkが5.47秒で、この規模ではほぼ差が出ません。--linkの速さが効いてくるのは、コピーの時間がデータ量に比例して伸びる大きなクラスタです。

チェックサムを無効のまま上げると、18の新しい既定の恩恵は受けられません。有効にしたいなら、上げる前に17の側でpg_checksums --enableをかけて設定を揃えてから上げます。どちらにするかを決めずにinitdbを既定で叩くと、本番のメンテナンス枠の中で今回のエラーに当たります。バージョンの確認とEOLの見方はPostgreSQLのバージョン確認方法にまとめています。

MySQLのインプレースアップグレードとロジカルアップグレード

MySQLは公式に2つの方式を定義しています。MySQL 8.4リファレンスマニュアルによると、インプレースアップグレードは旧サーバーを止めてバイナリを入れ替え、既存のデータディレクトリのまま再起動する方式で、ロジカルアップグレードはmysqldumpなどで書き出したSQLを新サーバーに流し込む方式です。インプレースでは8.4のサーバーが起動時にデータディクショナリとシステム表を自動で更新します。

経路はアップグレードパスの表で決まり、8.0から8.4 LTSへは直接上げられますが、5.7から8.4へはLTS系列を飛ばせないため8.0を経由します。戻す方向はさらに厳しく、ダウングレードの表では8.4から8.0へはダンプとロードかレプリケーションでしか戻せず、新機能をデータに適用していない場合に限ってロールバック目的で認められています。Auroraの場合の手順はAurora MySQL 8.4のアップグレード手順を参照してください。

デプロイでいう「インプレース」：AWS CodeDeployのIn-Placeデプロイ

アプリケーションの配備でも「インプレース」という言葉が使われ、「インプレースアップデート」で検索される意図の一部はこちらです。AWS CodeDeployの公式ガイドは、In-Placeデプロイを「デプロイグループ内の各インスタンスでアプリを止め、最新のリビジョンを入れて新しいバージョンを起動・検証する」方式と定義しています。ロードバランサーを使えば、デプロイ中のインスタンスだけを切り離して戻せます。

使えるのはEC2とオンプレミスのサーバーだけで、LambdaとECSはブルー/グリーンしか選べません。戻すときは旧バージョンを再デプロイする必要があり、元のインスタンスへ経路を戻すだけで済むブルー/グリーンより遅くなります。CodeDeployの設定と料金はAWS CodeDeployの解説、止めずに配備する設計はゼロダウンタイムデプロイの解説で扱っています。

インプレースアップグレードの採用判断：使う場面と見送る場面

インプレースアップグレードを選んでよい条件

次の3つがそろえば、インプレースを第一候補にできます。第一に、夜間や休日など計画停止の枠があること。第二に、現行と目標の組み合わせが公式の対応表に載っていること（Windows Serverなら上の表、RHELならLeappの経路）。第三に、完全バックアップを取り、検証環境で一度同じアップグレードを通していることです。単体のファイルサーバーやアプリサーバー、開発・検証環境、社内向けの業務システムがこれに当てはまりやすい対象です。

インプレースアップグレードを見送るべき場面と失敗パターン

数分の停止も許されない本番サービスはローリングアップデートかブルーグリーン、旧OSから何世代も飛ばす更新やハードウェア更改を兼ねる更新は並行アップグレードを選びます。ドメインコントローラーとクラスターは前述のとおりMicrosoftが別の方法を指定しています。

典型的な失敗は3つあります。2012 R2から2022のように表に無い経路で計画を組み、メンテナンス枠の当日にセットアップで先へ進めなくなる。LVMスナップショットだけを頼りにRHELを上げ、失敗後に戻せない。PostgreSQLを--linkで上げて新クラスタを起動したあとで不具合に気づき、旧クラスタが使えない。原因はそれぞれ、公式の対応表を着手前に確認していないこと、ReaRなどで完全バックアップを取っていないこと、--linkを選ぶ前に旧クラスタへ戻れなくなる条件を確認していないことです。AWS・Google Cloud・Azureのインフラ構築支援では、アップグレード方式の選定から検証環境の用意、切り戻し手順の設計までを支援しています。

よくある質問

インプレースアップグレードの対義語は何ですか？

PCや単体サーバーの文脈ではクリーンインストール、システム更新の文脈では並行アップグレード（マイグレーション）が対になる言葉です。前者は環境を消して入れ直し、後者は別の環境に新バージョンを作って移します。

Windows Serverのインプレースアップグレードのリスクは何ですか？

公式表に無い経路では上げられないこと、ドメインコントローラーには使わないよう公式が案内し、クラスターには専用のローリングアップグレード手順があること、失敗時は主にバックアップから復元することの3点です。着手前に完全バックアップと復元テストを済ませてください。

インプレースアップグレードはロールバックできますか？

製品と方式で変わります。Windows 10・11はアップグレード後10日間なら以前のバージョンへ戻せ、Windows ServerやRHELは事前に取ったバックアップからの復元が基本です。PostgreSQLの--copyのように旧環境を残すモードなら旧クラスタをそのまま起動できますが、--linkで新クラスタを起動した後は戻せません。

インプレースアップデートやインプレース更新とは違うものですか？

同じ考え方を指す言い換えです。OSやミドルウェアの版を上げる場合はアップグレード、アプリの配備ではAWS CodeDeployのIn-Placeデプロイのようにデプロイやアップデートと呼ばれることが多い、という使い分けです。

Windows 11のインプレースアップグレードで個人用ファイルは消えますか？

setup.exeで「個人用ファイルとアプリを引き継ぐ」を選べば、個人データ・アプリ・設定は残ります。「何も保持しない」を選ぶとすべて削除されます。選び間違いや途中の失敗に備えて、事前にバックアップを取ってください。

関連記事

• ブルーグリーンデプロイメントとは｜仕組み・他方式との違い・AWS/Kubernetes実装をコード例で解説
• ローリングアップデートとは？仕組みとKubernetes・ECSの設定値・採用判断を解説
• AWS CodeDeployとは？In-Place・Blue/Greenデプロイと料金・採用判断を実装者目線で解説
• PostgreSQLのバージョン確認方法｜サーバ・クライアント別コマンドとEOL判定・更新計画
• Amazon Linux 2のサポート終了後の移行手順｜AL2023へ移す棚卸しと詰まる箇所