クラウド用語のLift & ShiftがRehost以外の意味で使われる状況の調査

クラウド用語に「Lift & Shift（リフト＆シフト）」という言葉があります。既存オンプレミスのシステムのアーキテクチャやアプリケーションをそのままの状態でクラウド環境に移行し、それ以上は変更しないで使う、というクラウド移行手法を指し、「Rehost（リホスト）」と同義だと言われています。

しかし、IT用語辞典e-Wordsの「リフト＆シフト」の用語説明（2023年9月6日更新版）には以下のような記述があり、本来の意味とは異なり「アプリケーションの作り替えなどを伴うものである」と説明する「誤用」が日本では見られる状況が説明されています。

日本では英語圏での本来の意味とは異なり、クラウド環境への移行後にクラウドならではの機能の導入やクラウドネイティブなアプリケーションへの作り替えなど、クラウド利用を前提とした最適化を漸進的に進める手法を指すことがある。本来は誤用だが、この意味で捉えている人が多いため、この用語を用いる際は意図の周知や確認を行ったほうがよい。

私も、他のITエンジニアの発言やSNSでの投稿、書籍等で、こちらの「誤用」と呼ばれている方の使用例を散見することがあります。それと同時に、こちらの「誤用」を嘆いているITエンジニアを見かけることがあります。私も近しい同僚が「誤用」と言われる使い方をしていると、e-Wordsの説明を紹介して、意図的に使っているのか確認することがあります。

言葉の意味は時と共に変わりうるので、これが常に誤用というべきは議論の余地があると思います。ただし、説明のわかりやすさのために、このエントリーでは、Lift & Shiftにアプリケーション変更（最適化）まで含むものをいったんは「誤用」と表現します。そして、2025年8月現在^[1]、この「Lift & Shift」がどのように使われているのかを調べて、誰がどちらの意味で使っているかをまとめてみました。

主要な海外系ITベンダー

AWS

AWS Prescriptive Guidanceの「About the migration strategies」（2022年5月2日）には、「RehostはLift & Shiftとしても知られる」という記載があり、同義の扱いです。そしてRehostはクラウド移行はしても、アプリケーションの変更は伴わないという説明がされています。

Rehost
This strategy is also known as lift and shift. Using this strategy, you move your applications from your source environment to the AWS Cloud without making any changes to the application.

また、AWSブログの「リフトアンドシフト：クラウドトランスフォーメーション中にサーバーを AWS にリホストする」（2022年4月28日）は、英語記事の翻訳エントリーなのですが、丁寧に以下の訳注が付けられています。翻訳担当されたSolutions Architectの佐藤さんは、このエントリーのような議論を意識されていたのかと思います。

訳注：本ブログにおいての「リフトアンドシフト」はリホストと同義としています。AWSではリフトとシフトは別のステップではなく、現行の物理サーバーや仮想サーバーの構成をそのままクラウドに移行することをリホストとしています。

その他、Lift & Shiftについて語っているドキュメントやプレゼンテーションスライド等を見る限り、AWSは「誤用」と呼ばれる使い方はしていないように見受けられます。

Microsoft

App Modernization Guidance for Azrueの「The 6 Rs of application modernization」（最終更新日2025年5月14日）には、AWSと同様にRehostとLift & Shiftは同義と扱われ、アプリケーションコードの変更は伴うものではないと書かれています。

Rehost. Often referred to as lift and shift, this strategy is a cost-effective way to take advantage of a modern cloud infrastructure without modifying an application’s code.

DevOpsラボの「On Prem To The Cloud: Lift and Shift (Ep 2)」（2021年2月24日）のビデオで、JayさんがLift & Shiftについて手振り付きで説明していますが、（オンプレミスのVMwareやHyper-Vなどの仮想マシンを）上の方に持ち上げて、それをそのまま横の方にスライドして、そのまま下ろす、という感じです。この説明をLiftとShiftで段階分けするのであれば、Liftは単純に移動可能なように持ち上げることであり、Shiftはオンプレミスからクラウドへ持ち上がったものを移動させる（そして移動させたものを目的地に下ろす）というイメージのようです。

It's mainly because you're just going to have to pick up what you got, move it along, put it down.

その他、Lift & Shiftについて語っているドキュメントやプレゼンテーションスライド等を見る限り、Microsoftも「誤用」と呼ばれる使い方はしていないように見受けられます。

Google Cloud

Migrate to Google Cloudの「Migrate to Google Cloud: Get started」（最終更新日2024年11月20日）では、見出しの段階から「Rehost: lift & shift」ですので、Lift & ShiftはRehostと同義です。Rehost自体の定義ですが、Google Cloudのものは「ターゲット環境で稼働させるための最低限の変更は許容する」というニュアンスを感じさせる多少は柔らかい説明に感じます。いずれにせよ、「誤用」と呼ばれる使い方ほどアプリケーションの大幅な変更を伴うものではないようです。

Rehost: lift and shift
In a rehost migration, you move workloads from a source environment to a target environment with minor or no modifications or refactoring. The modifications you apply to the workloads to migrate are only the minimum changes you need to make in order for the workloads to operate in the target environment.

Googleブログの「クラウドへの移行: リフト＆シフトがとても簡単な理由」（2021年8月13日）を見ると、価値の高いワークロードのモダナイゼーションを伴うものの方が、Google Cloudの本来のおすすめではあることが書かれています。一方、モダナイゼーションには時間と労力がかかる事情があることにも言及し、アプリケーションをそのままクラウドに移行すること（＝Lift & Shift）であってもそれなりのメリットがあることをこのエントリーでは説明しています。つまり、Lift & Shiftにはモダナイゼーションは含まない、ということをここでも意味していると解釈しました。

ワークロードをクラウド向けにモダナイゼーションしていない理由がいかなるものであっても、これらのアプリケーションをそのままクラウドに移行することは、不必要で面倒な作業にも思えます。本当にこれは、ハードウェアの所有からハードウェアのレンタルに移行するだけのことでしょうか？実際には、まったくそうではありません。これら旧来のアプリケーションをクラウドに移行することで、以下の多くのメリットが得られます

その他、Lift & Shiftについて語っているドキュメントやプレゼンテーションスライド等を見る限り、Google Cloudも「誤用」と呼ばれる使い方はしていないように見受けられます。

IBM

三大クラウドベンダーは、Lift & Shiftを本来の意味で使っていることを確認しました。一方、X（Twitter）を見ると、「『誤用』の方の使い方はIBMやOracleが言い出した結果として普及した」という趣旨のことを書いている方もいらっしゃいました。そこで、IBMとOracleについても確認してみます。

IBMは公式ウェブサイト上の「What is lift and shift?」（最終更新日不明）の中で、Lift & ShiftはRehost(ing)と同じ意味だと説明しています。定義的にはIBMがハイブリッドクラウドベンダーというところも影響しているのか、移行先のクラウドはパブリッククラウド以外にプライベートクラウドもあり得る、と説明しているのが少し特徴的だなと思いました。ただ、アプリケーションアーキテクチャーは変更せず、アプリケーションコードの変更はわずかである、という前提である点は三大クラウドベンダーと変わらないようです。

“Lift and shift,” also known as “rehosting,” is the process of migrating an exact copy of an application or workload, together with its data store and operating system (OS), from IT one environment to another—usually from on-premises to public or private cloud.
Because it involves no change to application architecture and little or no change to application code, the lift and shift strategy enables a faster, less labor-intensive and initially less costly migration compared to other processes.

他にはIBM Developer Learning Pathsの「コンテナへの移行のメリット」（最終更新日不明。日本語翻訳されたのは2021年12月以降だと思われる）のLift & Shiftの記述は本来の意味だと思われます。

ほとんどの企業は、自社のIT資産の一部をコンテナに移行する戦略を持っているか、あるいは持ちたいと考えています。これは、「クラウドへの移行」戦略の重要なサブセットです。主な課題は、コンテナ化を単なるインフラのアップグレードと捉え、過去のハードウェアのアップグレードになぞらえたり、過去10年ほどの間に行われた仮想マシンへの移行になぞらえたりすることが多いことです。このような見方をすると、「リフト＆シフト」というアプローチになってしまい、コンテナがもたらすものの前提を見失ってしまいます。

一方で、ある特定の時期に、日本IBMが主体となる説明になると内容が異なる場合があるようです。例えば、2017年4月6日に当時IBMクラウド事業本部長だった三澤さんは、以下のようにITニュースメディア向けに説明しているようです（企業のクラウド活用を「Lift & Shift」で支援――IBMクラウドならではの強みとは）。これは「誤用」と呼ばれる方の使い方のように感じます。ちなみに上述した「IBMとOracleが〜」の話で言うと、三澤さんはこのメディア説明の前年の2016年まで日本オラクルの副社長で、その後の2020年に再び日本オラクルに戻られて今は日本オラクルの社長をされています。同様の説明は、2018年10月15日の「DX実現に欠かせない「正しいクラウドの使い方」～スピード、コスト効率、柔軟性を確実に獲得する方法～」あたりまでは確認できました。

既存のシステムの中で作り替えた方がいいものは、クラウドに上げ（Liftし）て、アーキテクチャーを新しいものに変え（Shiftし）、動かすようにする。パブリッククラウドを活用するなら、アプリケーションアーキテクチャはマイクロサービスをベースにしたものの方が適合性は高いので、IBMはマイクロサービスベースのものへの置き換えを推奨する。

なお、この時期の日本IBMの説明も一貫して「誤用」の方を使っているということもなく、例えばクラウド・サービス事業本部長の田口さんは、2017年10月26日の「日本IBM、ベアメタルでも活用できる「VMware on IBM Cloud」のメリットを解説」という中で、本来の用法でLift & Shiftを使っています。田口さんは2020年7月29日の「IBM Cloudのメリットを活用したフルマネージドのOpenShift――、Red Hat OpenShift 4.3 on IBM Cloudの特長を見る」でも本来の用法でした。

リフト・シフト（Lift Shift）とは、文字通り荷物を一度持ち上げてから降ろすという意味で、ここでは既存のVMware環境を変更することなく、インフラ部分だけをIBM Cloudのベアメタルに移行することを指す。

以上のように、IBMのウェブサイト上の説明では、Rehostと同様に「誤用」でない方の説明を使っています。一方、「誤用」の方の使い方をしている例が2017〜2018年頃の日本IBM関連のニュース記事や社員のイベント登壇スライド資料等では発見できました（スライドは三澤さんのスライドと同じ）。ただし、当時も一貫してそちらの意味で使っているということでもないようです。2017〜2018年頃に限定されて日本IBMに主流だった使い方なのかもしれません。

Oracle

続いてOracleです。Oracle公式ドキュメントを見る限りは、Lift & Shiftは、アプリケーションの変更を伴わずにそのままクラウドに移行するという手法のように見えます。例えば、「What Is Lift and Shift?」（2022年9月2日）では以下のように記載があります。

Lift and shift is a cost-effective way of migrating an application from onsite servers to cloud servers as lift and shift doesn't require the modification of the applications being migrated.

あるいは「What Is Cloud Migration? Importance, Benefits, and Strategy」（2023年3月16日）でも、アプリケーションはそのままでの移行と説明されています。

Migration Service Models
Infrastructure as a service (IaaS)
IaaS migration is often referred to as “lift-and-shift” migration. This migration model takes an application from your own data center and moves it—largely as is, ideally—onto compute, storage, and networking infrastructure in a cloud provider’s data center.

なお、Oracleはクラウド移行サービスにOracle Cloud Lift Servicesというブランド名を付けているので、グローバルレベルでのブランドネーミングにおいては「Cloud Lift」でRehostまで行うという考え方があるのかもしれません。Oracle Cloudへのマイグレーションサービスを提供しているCognizantも「Oracle Cloud Migration Consulting」の中で「Cloud Lift」に関して「Cognizant's Cloud Lift offering ... helps you move your existing applications to the cloud in their current state」という表現を使っており、ここでのCloud Liftは定義的にはRehostです。

そのため、OracleのLift & Shiftという言葉のグローバルレベルでの技術的用語定義だと、他の海外ITベンダーと同様にアプリケーションの変更は伴わないものですが、Oracleのブランドネーミングに関しては、グローバルレベルであっても本来の定義に必ずしも沿わない独自の用語定義としてのClouf Liftが使われることがあるようです。

日本オラクルの説明では「誤用」に近い表現が使われる事例が直近でもあるようです。前述しました日本オラクル社長の三澤さんは2025年7月9日の「日本オラクル・三澤智光社長が会見、「2026年度はモダナイゼーションビジネスをより加速」」では以下のように説明しています。これはShiftにモダナイゼーションの意味を含んでいると考えられます。

さらに、日本オラクルの三澤社長が強調したのが、ミッションクリティカルシステムにおけるモダナイゼーションで、顧客の懸念点を払拭する実績が積み重なっているという点だ。
　「AWSのアーキテクチャにあわせて全面的にアプリケーションを書き換え、インフラ構成を見直すプロジェクトがあるが、成功例はほとんど聞かない。また、オンプレミスからオンプレミスへの移行でも、スケジュール通りに進まないとか、赤字プロジェクトになっているケースが数多くみられる。いまでは、クラウドリフトから、クラウドシフトした方がいいということが世間の常識になってきた」と発言。

あるいは、2021年11月5日の「日本オラクル・三澤社長が話す、「OCIがミッションクリティカルに適している4つの理由」」の以下説明でも、Liftにクラウドへの移行の意味を含んでいると考えられます。

「日本オラクルが提案しているのは、まずはオンプレミス上で稼働しているミッションクリティカルシステムをOCIにリフトしてもらうことである。リフトするだけでも、インフラの拡張性や柔軟性が確保でき、従量課金での活用が可能になり、運用コストの大幅な削減など、多くのベネフィットが生まれる」

ただし、これらではLift & Shiftという表現は必ずしも登場しておらず、Cloud Lift（クラウドリフト）とCloud Shift（クラウドシフト）という用語のみを使っています。「誤用」ベースの意味だと思いますが、Lift & Shiftからはすでに独立した（紐づけが外れた）別の意味の用語（「Cloud Lift」と「Cloud Shift」という用語）としての使い方ともとらえられます。なお、三澤さんのメディア向け会見の記事含めて、日本オラクルが明確に「Lift & Shift」の意味を説明している記事は見つけられませんでした。

以上のように、Oracleのウェブサイト上の技術的な用語説明では、Lift & Shiftについては、アプリケーションの変更を伴わない「誤用」でない方の説明を使っています。一方、「誤用」の方の使い方をしている例が、Oracleのグローバルレベルのブランド名設定や、2021年11月から2025年7月まで日本オラクル社長の三澤さんのメディア向け説明では確認できました。Twitter（X）で「IBMやOracleが言い出した結果として普及した」という趣旨のポストがあったと書きました。それが普及の原因だったかはともかく、IBMやOracleが言っていたことがあるという部分は確認できました。

Accenture

Accentureは2022年に発行した『Succeeding through the cloud ultimatum』の中で、Lift & ShiftをRehostと同じ意味で、オンプレミスからパブリッククラウドにデータとアプリケーションを転送する、という本来の意味で使っています。

Re-host (lift and shift)
Transferring data and applications from a local on-premises datacenter to the public cloud.

あるいは、「Accenture creates a cloud-native ecosystem with Google Cloud as part of scaled enterprise transformation」（時期不明）でも、Lift & Shiftは単純なクラウド移行を意味していると解釈されます。

Turning a traditional IT infrastructure into a cloud-powered innovation engine requires more than migration. While the "lift and shift" approach—simply moving existing systems to the cloud—offers a quick fix, it fails to unlock its full potential.

ところで、2018年9月6日の「変わる「リフト＆シフト」の意味――既存システムのクラウド移行、成功のポイント」というニュース記事の中で、アクセンチュア テクノロジーの福垣内さんが以下のように語っています。これ自体はアクセンチュアの用語定義に関する見解というよりは、この2018年9月頃にはLift & Shiftの意味として受容されているものが変わりつつあるという状況の変化について見解を述べている、と言えます。

リフト＆シフトという言葉は、当初は「オンプレミスからアプリケーションをリフトして、クラウドにシフトする」といった意味合いで理解されていましたが、最近は「クラウドにリフトして、クラウドネイティブな仕組みにシフトする」という意味に解釈されています。前者の意味合いでは「単純にクラウド上に移すだけ」ですから、運用コストはそれほど変わりませんし、その先の「新しいこと」にもつながりません。クラウドに移したことで目的を果たし、そこで取り組みが終わってしまうのです。

あるいは、それよりさらに以前の2018年4月27日の「移行方法は7パターン　段階的にレガシーを解体」に以下のように記載があります（原文ママ）。記事執筆者は上述した福垣内さん他2名のアクセンチュア社員です。

従来、「リフト＆シフト」というと、オンプレミス環境にある仮想サーバー上で稼働していシステムを現行踏襲でクラウド上で稼働させる方式のことを指していたが、最近では、一度クラウド環境に移行し（＝リフト）そこからクラウドネイティブなサービスを活用してさらにアプリを高度化する（＝シフト）ことを指すことのほうが増えてきた

以上のように、AccentureのLift & Shiftに関する定義は本来の用途です。一方で、2018年には「誤用」の方の用途が広まっている状況がある、とアクセンチュア社員の方が語っている内容は、いつからこの「誤用」が一般的に受容されたかを確認するのに重要な内容だと感じます。

日本の官公庁・独立行政法人

以上のように、「誤用」と呼ばれる方のLift & Shiftの使い方を一部の時期の日本IBMや日本オラクルが使用していることは確認できました。一方、日本のIT業界で言葉の定義としてそれ以上に尊重されるのは、官公庁やIPA情報処理推進機構の出しているガイドライン等であると私は理解をしています。そこで、それらの調査も行いました。

総務省

総務省は、ガバメントクラウド（ガバクラ）を地方自治体が推進する際の標準化・共通化の推進を目的として、『自治体情報システムの標準化・共通化に係る手順書【第4.0版】』（2024年9月9日）という手順書を発行しています。こちらのp.78以降の説明を参照すると、リフトとシフトを別の意味の移行ステップとして扱っていることがわかります。また、「ガバクラへリフト」「ガバクラ上で標準準拠システムへシフト」という表現が図表48にあるように、用法としては「誤用」の方の使い方をしているようです。

標準準拠システムへの移行方法としては、図表 48 のパターンがあると考えられる。リフト・シフトを同時に実施しない場合は、連携先の変更、動作確認等利用環境の変更による作業が、リフト・シフト同時実施と比較して多くなる可能性があることに留意が必要である。

上記は第4.0版の記述ですが、過去に遡って2021年7月7日発行の『自治体情報システムの標準化・共通化に係る手順書【第1.0版】』ではリフトとシフトに対する言及が見つけられず、2023年1月20日発行の『自治体情報システムの標準化・共通化に係る手順書【第2.0版】』からこのような説明が登場したようです。ただし、この手順書の「第0.8版への地方公共団体への意見」（時期不明）では、「リフト→シフトを認めてほしい」という意見が見られ、それ以前から「誤用」の方の用法が主流だったことがうかがえます。

デジタル庁

デジタル庁もガバメントクラウドに関わる省庁ですので、ガバメントクラウドに関する報告書では、「誤用」の方の使い方のようです。例えば、2023年4月の『標準準拠システム移行方法（比較）の検証 ― 検証結果』では、総務省発行の上述の手順書と同じ移行手法分類をしています。

移行パターンA：現行環境からガバメントクラウドにリフトした後、標準準拠システムへシフトする
移行パターンB：現行環境からガバメントクラウドへリフトすると同時に標準準拠システムへシフトする

リフト：ガバメントクラウドに移行すること。
シフト：標準仕様に準拠したシステムに移行すること。移行時にはReplatform以上の移行パターンに対応してシステムを改修する。

デジタル庁が、ガバメントクラウド以外でLift & Shiftに言及しているドキュメントは発見できませんでした。

経済産業省 / IPA情報処理推進機構

ガバメントクラウドに関わる方ならば、上記の総務省の手順書が重要な根拠になると思いますが、日本のIT業界全体で言うと、IPA情報処理推進機構の定義の方が広く扱われると思います。IPAは、経済産業省が所管する独立行政法人です。

IPAが発行しているドキュメントを調べますと、例えば『DX白書2021』（2021年12月1日）のp.218には以下のように記述があります。これは「誤用」の方の定義を指しています。ただし、白書というのは現状分析結果を報告しているドキュメントであり、「誤用」の方の定義が一般的に受容されていることを示しているだけで、IPAがこのように定義しているとは言えないと思います。

そのため、まずはオンプレミスで稼働しているITシステムを、ITシステムの作りを大きく変えず、主にクラウド活用を中心にインフラのみを変革する対応を行う（リフト）。その後、DXに最適化されたITシステムへ、クラウドネイティブ化を軸にアプリケーションの作りも含めて変革していく（シフト）という方法が一般的である。
「リフト」は、オンプレミスで稼働しているITシステムに対して、クラウド上のIaaSやCaaSを活用したり、オンプレミス環境にコンテナを導入したりするものである。アプリケーションの構成が大きく変わらないため短期間に移行可能で、クラウド活用によるオンプレミスからの脱却や、コンテナ活用によるサーバー集約などにより、データセンターやサーバーの費用削減を見込むことができる。
「シフト」は、クラウド上で提供されるソフトウェア資源を活用し、実装部分を軽量化しながら、よりDXに最適化した構成へとITシステムを作り変えていくものである。この段階で、マイクロサービスアーキテクチャーやFaaSを取り入れ、アプリケーションの抜本的な作り直しも含めた変革を行い、あわせてアプリケーションの開発方式も変革していく。これにより、より変化に強いITシステムを実現することが可能となる。

次に、2023年10月13日の『「IPA-Cloud導入のためのタスクフォース活動支援」に係る一般競争入札 入札説明書』を見ていきます。これはIPA自体が受注者として、オンプレミスシステムをクラウドシステムへ移行するための活動支援に、競争入札した際の文書なので一般向けに何かを説明してるものではない、という理解です。ただし、こちらの資料のp.19にある用語の定義では、以下のように記載があります。このため、IPAの組織内の定義では、「誤用」の方が一般的（用語定義で共通認識を持たせている）だと推察できます。

クラウドシフト：クラウド環境に合わせて新たにシステムを開発、導入する手法。
クラウドリフト：オンプレミスに構築された業務システム等をクラウド環境にそのまま移行すること。

一方、IPAの産業サイバーセキュリティセンターの『クラウドにおける脅威検知』（2025年7月31日）という成果報告のスライド38ではクラウド活用状況をクラウドリフト、クラウドシフト、クラウドネイティブで分けているのですが、定義的にはリフトにクラウド移行をほぼ含まないので本来の用法に近い方だと解釈できます。このため、外部向けでは「誤用」でない方で使い分けているのかもしれません。

クラウドリフト：オンプレ中心に活用しており、クラウド活用はあまり進んでおらず、IaaSは一部使い始めたものの、コンテナやサーバレス環境はほとんど利用していない
クラウドシフト：サーバ周り（IaaS）に関してはクラウド活用が徐々に進んでおり、コンテナやサーバレスの活用も一部部署で始まったものの機密情報までは預けていない
クラウドネイティブ：クラウド活用が進んでおり、コンテナやサーバレス環境を活用したサービスを提供しているかつそれらのサービスで機密情報を扱っている

以上のようにIPAのドキュメントでは、Lift & Shiftに関する記述はいくつか発見できたものの、IPAが一般向けに言葉の定義をしていると言い切れる程度に確度の高いものは見つけられませんでした。そのため、IPAの組織内では「誤用」の方が主流だと推測されるもの、積極的に外部に向けて定義を示しているとは感じられませんでした。

総務省、デジタル庁、IPAのドキュメントを見る限り、主にガバメントクラウド関係では「誤用」の方が主流の扱いをされているようです。ただ、ガバメントクラウド関連の検討が2021年以降の時期の話であることから、それ以前に日本にすでに定着している用法をベースに用語定義をしているだけで、「誤用」の普及の原因とは言い切れないと思います。

主要な日系ITベンダー

海外系（ここでは日本国外を本社とする、という程度の意味です）の主要ITベンダーは、Lift & Shiftを本来の用途で使っている一方で、主要な日系ITベンダーはどちらの用法で使っているのか、ここから確認していきます。

NTTデータ

2018年5月30日の「AWSへの既存IT資産移行とクラウドネイティブ化を推進」というニュースリリースでは、Lift & Shiftを「誤用」の方で使用しています。

具体的には、クラウド移行の対象となるシステムやデータを見極めて確実にクラウド移行すること（Lift）や、アプリケーションをクラウドネイティブに作り変えていくこと（Shift）について不安があり、社内の推進体制や技術者も不足しています。

2019年7月17日の「クラウドリフトはDigital Transformation（DX）への“狼煙”」では、Lift & Shiftという表現こそ登場しないものの、技術統括本部の田島さんはLiftにクラウド移行までを含む定義を採用しており、こちらは「誤用」側の使い方と思います。

私たちはクラウド化によるDXの第一歩を、「クラウドリフト」（既存IT資産のクラウド移行・最適化）と定義し、DX実現に向けた重要なポイントであると考えています。

同じく技術統括本部の谷口さんの資料では、AWS Summit Japan 2025の「NTT DATAによる確実なデータベースマイグレーション：実践ガイドと成功事例」（2025年6月26日）でも、クラウドリフトにクラウド移行までを含め、クラウドシフトにモダナイゼーションの意味を込めているようです。

NTTデータではなくNTT系列では、当時のNTTコミュニケーションズ（現社名：NTTドコモビジネス）による「リフトアンドシフトとは？」（日付不明）では、「誤用」の方の説明をしています。Gartnerの「5つのR」やAWSの「7つのR」に言及しながら、Rehost以外の意味でLift & Shiftを定義しているので、分かっていて「誤用」の方の定義をあえて採用しているように感じます（AWSの「7つのR」では「Rehost＝Lift & Shift」です）。

「リフトアンドシフト」とは？
具体的には、既存システムをいきなりPaaSで実行できるように作り替えるのではなく、まずオンプレミスから移行しやすいIaaSを使ってクラウド化する（リフト）。IaaSであればOSやミドルウェアの選択肢が広いため、既存システムにそれほど手を加えずクラウド化できる可能性が高い。このようにIaaSを用いてクラウド化したシステムを、PaaSを用いて再構築する（シフト）するのがリフトアンドシフトの流れだ。もっとわかりやすく説明するなら、オンプレミス環境で稼働する既存のシステムを、ほぼそのままクラウドに移行（リフト）し、その後、徐々にクラウド環境に最適化（シフト）していく。たとえるなら、金庫にある現金をいったん銀行にすべて預け（リフト）、その後、目的に応じてさまざまな運用方法を考えていく（シフト）ようなものかもしれない。

以上のように、NTTデータは一貫してLift & Shiftに対して「誤用」の方の定義を当てはめているようです。

富士通

富士通は「デジタルトランスフォーメーション（DX）を実現する「リフト＆シフト」の5Step」（最終更新日不明ですが、2021年11月25日と推測されます）の中で、Lift & Shiftを「誤用」の方の用法で解説しています。ただし、従来の意味は本来の用途であると説明して、意味が変化してきた点に言及しているので、世の中の普及度合いに合わせた解説をしているようです。

この問題に対する解決策の1つが、本記事で解説する「リフト＆シフト」です。これはオンプレミスのシステムをクラウドに移行（リフト）し、その後、徐々に運用管理のスタイルをより先進的なものへと変えていく（シフト）というクラウド移行の手法です。
従来、この言葉は「オンプレミスからアプリケーションをリフトして、クラウドにシフトする」という意味で使われていました。しかし、最近は「クラウドにリフトして、クラウドネイティブな仕組みにシフトする」という意味で使われることが増えています。

他の資料を見ていくと、2023年9月14日にTechTargetで公開した『クラウド移行を成功に導く、「リフト＆シフト」を効果的に進める5つのステップ』では、「誤用」の用法が使われています。

そこで注目されているのが「リフト＆シフト」というクラウド移行の手法だ。これは、オンプレミスのシステムをクラウドに移行し、その後、徐々に運用管理のスタイルをより先進的なものへと変えていくというものだ。

一方、2019年8月掲載の「「クラウドに移行したいけど自社要件が……」と悩む担当者に知ってほしい解決策」では、本来の用途で使っているように感じます。したがって、2020年代に入って、富士通はLift & Shiftを本来の用途ではなく、一般的な普及度合いに合わせて「誤用」の方に切り替えたのかもしれません。

1つ考えなければならない点がある。最近は「VMware vSphere」などを採用して仮想環境でシステムを運用するケースが珍しくない。問題は、どうすればオンプレミスで運用しているVMware vSphereの環境を“そのまま”クラウドにリフト＆シフトできるかだ。

以上のように、富士通は今はLift & Shiftを「誤用」の方の定義で使用しているようですが、それは2020年代になって世間の普及度に合わせたもので、それ以前は本来の用途で使っていたと思われます。

NEC

2018年5月31日の「リフト＆シフトで実現する 勝ち抜くためのDX戦略」という執行役員の松原さんによるスライドのスライド19を見る限り、Liftにクラウド移行、Shiftにクラウド最適化という意味を含む「誤用」の方の説明を採用しているようです。

既存システムの単純クラウド化にとどまらず、業務や将来設計に合わせてクラウドシステムを最適化していく必要がある

あるいは2019年12月6日の「デジタルビジネスを成功に導く！クラウド活用、次の一手」で、サービスプラットフォーム事業部 事業部長の上坂さんのプレゼンをレポートした記事の注でも、「誤用」の方の定義を採用しています。

リフト＆シフト・・・既存のオンプレミスによる情報システム基盤をまずクラウドに上げて（Lift）、その後、クラウドに適した環境へと進化させていく（Shift）手法のこと。

他にも、官公ソリューション事業部門の堀田さんによる「3　[クラウド関連コラム]クラウド化の手法や考慮点」でも「誤用」の方の定義が採用されています。ただし、そもそも官公庁は「誤用」の方で標準化されているので、官公ソリューション事業本部はそちらの定義に沿うことは不思議ではないと思います。

現在、クラウドリフトによるサーバーの移行、クラウドシフトによるサービスの活用による情報システムのモダン化、それらを組み合わせた移行など、様々な刷新方法の選択肢があります。情報システムの特性を踏まえ、最適な移行方式の選択が今後の情報システム刷新には求められています。

以上のように確認した範囲では、NECは一貫して、Lift & Shiftを「誤用」の方の使い方をしているようです。

日立製作所

2023年11月15日の「ビジネス目的とシステム特性に応じてスマートに使えるハイブリッドクラウドとは」という記事では、クラウドエンジニアリング本部部長の日巻さんの発言で以下の説明がされています。こちらは「誤用」の方の使い方をしています。

「リフト＆シフトという言葉がありますが、シフト（クラウドネイティブ化）まで進むには時間もコストもかかるため、『とにかくクラウドにリフトだけしたい』というご要望を頂くこともあります。しかし、システムによってはシフトする方がメリットが大きい場合もある。よって、リフト後にシフトが必要となる可能性を事前に考慮しておいたり、その後のロードマップと具体的な選択肢を提示しておいたりすることが大きなポイントになります」

あるいは2021年9月1日の「エキスパートの知見で基幹システムのクラウドリフト＆シフトを加速する「仮想マシン移行ソリューション」」でも、「誤用」の方の用法が使われています。

近年、DXを加速させる手法として注目されているのが、オンプレミス環境のシステムをクラウドに最適化されたアーキテクチャーに一気に移し替えるのではなく、既存システムをそのままクラウド上の仮想マシンに移行（リフト）して、その後、段階的にクラウド環境に最適化（シフト）していく「クラウドリフト＆シフト」という計画的で着実なクラウド移行です。

それ以外では、日立ソリューションズの「なぜクラウドシフトがDXに必要なのか？　クラウドリフトとの違いも解説」（最終更新日不明）は「誤用」に近い意味だと思います。ただし、クラウドリフトがRehostで、クラウドシフトに「クラウド移行する際にアプリケーション変更も行う」（いったん移行した後ではない）という定義なので、他社の定義と多少異なるように見えます。

方法②クラウドリフト
二つ目は、オンプレミスのシステムをIaaSに乗せ換える方法です。

方法③クラウドシフト
三つ目は、オンプレミス環境からクラウドへ移行する際に、業務システムを新たに開発、導入する方法です。
クラウドリフトよりさらに本格的なクラウド移行をするための方法で、コンテナやサーバーレスといった最新技術、PaaSを中心とした環境に移行することによって、ミドルウェアやアプリケーションの運用における業務改善につながることがメリットです。

以上のように確認した範囲では、日立製作所は一貫して、Lift & Shiftは「誤用」の方の使い方をしているようです。

主要な日系ITベンダーの使い方を見る限り、現在は「誤用」の方で定着あるいは徹底しているように見えます。一方、2018年以降の使い方しか見られなかったことから、一般的に「誤用」の方が定着した後ぐらいからこの用語を公の場で使うようになった、という時系列の話にも感じました。

日本の主要なITニュースサイト

IT用語の一般的な定着に向けては、IT企業や官公庁のドキュメント等だけでなく、ITニュースサイトなどの解説記事の影響も大きいと思います。そこで、ITニュースサイトの中で、記者が引用ではなく独自に定義を紹介している記事を中心に、どのように説明しているかを調査してみました。

日経BP（日経クロステック）

最近だと2025年6月12日号の日経コンピュータの「英国政府の「脱富士通」本格化　2大顧客の歳入関税庁と郵便局、クラウド移行表明」というタイトルの「北川賢一の乱反射」というシリーズのコラムで、北川記者がLift & Shiftについて説明しています（会員登録後参照可能）。そこでのLift & Shiftの定義は、「クラウドに移行し、後にクラウドネイティブに変更する」までを含むものですので、「誤用」の用法です。

なお、「北川賢一の乱反射」の過去のものを参照すると、2020年4月30日号の「日本企業が好きな「リフト＆シフト」のクラウド移行、本当にそれでいいのか？」では引用として以下のように記載しています。これは解釈が難しい文章ですが、「リフト＆シフト」だとクラウドネイティブ化は実施せず、「リフト」と「シフト」を分けた場合の「リフト」だと、改修あるいは再構築が伴うということでしょうか。この文章の意味はよく分かりませんでした。

クラウドの分析情報を発信しているクラウディットの中井雅也代表はこう指摘するとともに、一気にクラウドネーティブにしない「リフト＆シフト」に懸念を述べる。既存アプリケーションをクラウドに載せ替え（リフト）、その後にクラウドネーティブに改修または再構築する（シフト）やり方を経済産業省はDXリポートで有効としたが「リフトはしてもシフトする企業はごく少数」（中井代表）という。

それ以前の2019年12月26日号の「2020年に「民族大移動」始まる、若手技術者はITベンダーからどこへ行く？」でも取材結果のまとめとして「誤用」の方を採用しています。したがって、北川記者の中での定義は現在まで「誤用」の方かと判断しました。

一方、「リフト&シフト」こそ多くの顧客が望む手法だと考える国内SIerもいる。まず現有システムをクラウドに移行し（リフト）、DX時代にふさわしい機能を付加する（シフト）やり方だ。そうであるなら現有システムを作ってきたSIerが引き続き必要とされる。

他の記者も見てみます。2025年4月10日の「意外と根深い「もう1つのVMware問題」、受け皿に透けるシステムの価値」という「記者の眼」のコラムの中の、森山記者によるLift & Shiftについての解説は「誤用」の用法です（会員登録後参照可能）。Lift & ShiftはITモダナイズまで行うものなのに対して、クラウド移行するだけのものは単なるLift、あるいはLift & Stayであると解説しています。

あるいは2020年7月14日の「オンプレミスに残るシステムを奪え、クラウドベンダーが「地上戦」に注力」では、島田記者が以下のように記載しています。こちらも「誤用」の方の定義です。

これまで主要なパブリッククラウドベンダーは「リフト・アンド・シフト」戦略を強力に推進してきた。オンプレミス環境にある業務システムを「リフト（クラウド移行）」し、その後にクラウド活用を前提に作り替える「シフト」を促す戦略だ。

以上のように2019年以降、日経BPの記者がLift & Shiftに言及する時は常に「誤用」の方を採用していると考えられます。

ITmedia日本語版

ITmediaは海外版が本家としてあり、日本向けでも独自に取材を行っているITニュースサイトなので、翻訳記事もあります。例えば、2023年12月8日の「いまさら聞けない「リフト＆シフト」　なぜ人気でどこが駄目？」は翻訳記事だと思いますが、本来の用途を採用しています。

オンプレミスのシステムをクラウドサービスに移行する方法の一つに、「リフト＆シフト」方式がある。リフト＆シフト方式では、既存のデータやシステム、OSなどを可能な限りそのままクラウドサービスに移行させる。

そのような意味では興味深いのは、2017年9月7日の「「リフト＆シフト」方式のクラウド移行に注意が必要な理由」のおわびと訂正の部分です。翻訳と編集方針で当初は「誤用」の方を採用したものの、後に本来の用途で訂正している、ということです。

おわびと訂正（2018年1月15日13時）
原文の日本語訳および編集内容に誤りがありました。以下の通り訂正しておわびいたします。

【訂正前】
リフト＆シフト方式とは、企業がクラウド移行に当たって、従来システムを大幅に刷新する代わりに“クラウドに乗せられる部分はそのまま移し替え（リフト）、変えた方が賢明な部分はクラウドに合わせて変える（シフト）”ことで移行を効率化するやり方。

【訂正後】
リフト＆シフト方式とは、企業がクラウドへ移行するに当たって、従来システムをできる限りそのまま移し替えるやり方。

最近では、2024年2月9日の「「リフト＆シフト」丸分かり　比較、事例、解説記事を紹介」では、本来の用途でLift & Shiftを使っています。

「リフト＆シフト」は、アプリケーションを元のインフラから別のインフラに移行させる際に、アプリケーションを再設計せずにそのまま複製する手法を指す。リフト＆シフトをするか、インフラの移行を機にアプリケーションを一から再構築するかの選択は、アプリケーションの用途や構造の複雑さに大きく左右される。

全部の記事を確認することは出来ないのですが、おそらくITmediaの日本版の編集部はLift & Shiftを本来の意味で使用しているのではないかと思います。

ZDNet Japan

2023年8月8日の「「リフト＆シフト」、次の課題は運用の一貫性確保」では、以下のような表現がされています。これは執筆時の直近の記事をまとめた記事なのですが、ZDNet Japan編集部は「誤用」の方の定義を採用しているようです。

「リフト＆シフト」という言葉が、ここ数年のいわゆるエンタープライズIT界隈でのキーワードになっている。
　リフト＆シフトとは、企業が持つ情報システムをそのままクラウドに移行（リフト）し、そこから少しずつクラウド環境にうまく適合するように最適化（シフト）する方法だ。

ただ、Lift & Shiftに言及しているZDNet Japanの記事は多いものの、ZDNet Japanの記事の特徴として取材している企業の定義をそのまま採用することが多いので、本来の用途の場合と「誤用」の場合が記事によってまちまちで、サイト全体としてはどちらの定義も混在しているという印象でした。

インプレス

インプレスもほとんどの記事は取材先の定義をそのまま使っている印象です。そのため、本来の用法と「誤用」の用法がサイト全体ではどちらも採用されている印象でした。

ただ、記者の見解が現れていそうな記事ですと、2018年6月27日の「ぐるなびのOpenShift移行事例に見る「リフト&シフト」のポテンシャル」は以下の記載であり、五味記者の定義は「誤用」の方のようです。

オンプレミスからクラウドへの移行が話題になるとき、ここ最近、必ずといっていいほど登場するキーワードが「リフト&シフト（Lift and Shift）」だ。文字どおり、まずは既存のオンプレミス上で動くアプリケーションやデータをそのままクラウドに載せ（Lift）、その後、徐々にインフラ全体をクラウドに適した環境に作り変えていく（Shift）という手法で、ゼロからクラウドネイティブな環境を構築するよりも、効率やコストの面から現実的な選択肢として評価されることが多い。

以上のように日本の主要なITニュースサイトは、日経BPは「誤用」の方に統一する意図が強く見え、ZDNet Japanとインプレスは通常のニュース記事では取材先の定義を尊重しつつ、編集部としては「誤用」の方を採用しているのかもしれません。一方、ITmediaは一度「誤用」で翻訳した記事を訂正しているように、本来の用法で使う方針としているように見えました。

ITニュースサイトは一般的な使われ方に編集方針が影響される一方で、ITニュースサイト側の使い方で一般的な用語の定着化が促進される側面もあると思います。印象的には、日本のITニュースサイトからIT用語を勉強をされる比重が高い人ほど、「誤用」の方の定義が自然と感じられるのかもしれません。

調査のまとめ

Lift & Shiftという用語の利用状況について調査をした結果、

• 主要な海外系ITベンダーのグローバルサイトでは、調査した範囲では例外なく、Lift & ShiftをRehostと同義として扱っている（本来の用法での利用）
• ただし、日本IBMの2017〜2018年頃、および日本オラクルの2021年以降から現在に至るまで、Liftにクラウド移行、Shiftにクラウド最適化という用法を使用していることが確認できた（「誤用」での利用）
• 官公庁等のドキュメント、特にガバメントクラウド関連のドキュメントでは、Liftをクラウド移行、Shiftをクラウド最適化として扱っている（「誤用」での利用）
• 主要な日系ITベンダーは、2020年代以降はLiftをクラウド移行、Shiftをクラウド最適化として扱う方針で足並みが揃っているように見える（「誤用」での利用）
• 主要なITニュースサイトは、日経BP以外は取材先の説明をほぼそのまま使用することが多く、本来の用法と誤用が記事によって異なるが、日本の記者・編集部は、Liftをクラウド移行、Shiftをクラウド最適化として扱う傾向が見られる（「誤用」での利用）

という現状だと感じました。

2016年以前のLift & Shiftという用語の使われ方について、ITメディアのニュース記事や企業のニュースリリース等がなかなかヒットせず、2016年以前に遡っての調査が難しいと感じました。これがヒットしにくいだけなのか、話題にあまりなっていなかったのかは現時点ではよく分かりません。今回調査した結果だけを見ると、2017年頃から日本IBMが積極的にLift & Shiftの「誤用」の用法を広めた結果、日本ではこの意味の方が定着したのかもしれません（一企業の発信がそんなに影響があるものなのかは定かではありませんが）。

もう一度、IT用語辞典e-Wordsの「リフト＆シフト」の用語説明（2023年9月6日更新版）を確認します。

日本では英語圏での本来の意味とは異なり、クラウド環境への移行後にクラウドならではの機能の導入やクラウドネイティブなアプリケーションへの作り替えなど、クラウド利用を前提とした最適化を漸進的に進める手法を指すことがある。本来は誤用だが、この意味で捉えている人が多いため、この用語を用いる際は意図の周知や確認を行ったほうがよい。

Liftにクラウド移行、Shiftにクラウド最適化をするという意味は、本来は誤用だとe-Wordsは言っています。上記の調査でも英語圏ではこのような使い方はされていない日本独自の傾向であるという点は裏付けられそうです。一方で、日本での実際の普及度合いは「誤用」の方がむしろ主流だと感じさせました。私は、本来の意味の方で統一して使っているのですが、確かにe-Wordsの推奨のように、日本ではどちらの意味で使っているのかを確認した方が良いと感じます。また、海外向けに使用する場合は本来の意味で常に使った方が意思疎通の問題を避けられると思いました。

人力の範囲で色々と調査してみましたが、網羅的に調べ尽くすことはさすがに難しいなとも思いました。この用語がどのように世間に受容されていったのか等に興味がある方は、是非追加調査をして、まとめていただければと思います。

更新履歴

2026-05-09 Oracleの調査結果に出典を追加し、その追加に対応した表現の追記・修正

脚注

1. 一部情報を追記（更新履歴参照）していますが、基本的な内容は2025年8月当時のままです