LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

古いシステムの刷新を検討していたら、提案書に「リホスト」「リライト」「リビルド」と並んでいて違いが分からない。費用も期間もばらばらで、どれを選べばよいのか判断がつかない——。長く使ってきたシステムの刷新を任された情報システムの担当者の間では、こうした戸惑いが起こりがちです。リホスト・リライト・リビルドは、いまのシステムを作り直すときの代表的な3つの方式で、いまのシステムのどこまでを残し、どこからを作り直すかが違います。

早く移せる方式もあれば、移した後の変えやすさを取る方式もあります。ただし万能な方式はなく、業務によって向き不向きが分かれます。本記事では、システムの刷新を検討している情報システムの担当者に向けて、3つの方式の違い、選び方の手順、つまずきやすい点、そして外部に頼むときに確認したい点を整理します。

リホスト・リライト・リビルドとは

IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド 第2版」は、再構築の手法を、いまのシステムのどの層の設計情報を残すかで分類しています。判断の材料になるのは、業務仕様（業務のルールや画面・帳票の決まりごと）、基盤（ハードウェアやOS、ミドルウェア）、開発言語の3つです。この3つのうち何を変えるかで、方式が分かれます。^*1

• リホスト：業務仕様と開発言語はそのままにして、基盤を新しくする方式。プログラムにはなるべく手を加えません
• リライト：業務仕様はそのままにして、基盤と開発言語を変える方式。いまのプログラムを別の言語に書き換えます
• リビルド：業務仕様から見直し、基盤も含めてシステムを一から作り直す方式

同じガイドは、ハードウェアだけを替える「ハードウェア更改」も手法の一つに数え、市販のパッケージ製品を使う場合は別に扱っています。また、これらの言葉の定義は企業や書籍によって異なるとも断っています。^*1 提案書に同じ言葉が書かれていても、中身は相手に確かめる必要があります。

3つの方式の違い

3つの方式は、変える範囲が広がるほど、いまのプログラムを使える部分が減り、品質の確かめ方も新規開発に近づきます。ガイドの記述をもとに、違いを表にまとめました。^*1

費用と効果の関係について、ガイドはこう整理しています。リビルドは保守のしやすさや業務の変化への対応力をリホスト・リライトより高められる一方、費用と、業務に詳しい人の関与はより多く求められます。リホストとリライトは、いまの資産を使うぶん業務の仕様を再現しやすいものの、保守のしやすさは今のシステムと変わりません。^*1 早く安く移すことと、移した後に変えやすくすることは、両立しにくい関係にあるといえます。

どの方式を選ぶか

ガイドは、方式を選ぶ手順も示しています。新しいシステムに求めること（要求事項）を1つずつ取り上げ、業務仕様・基盤・開発言語のそれぞれを変える必要があるかを判定し、多いほうをもとに候補を絞ります。^*1 判定の流れを図にすると次のとおりです。

• ステップ1：いまのシステムを調べ、新しいシステムに求めることを一覧にする
• ステップ2：求めることごとに、業務仕様・基盤・開発言語を変える必要があるかを判定する
• ステップ3：変える・変えないの多いほうから方式の候補を選ぶ（優先度の高い要求に重みを付ける）
• ステップ4：候補のメリット・デメリットとリスクを関係者で共有して決め、決めた理由を記録に残す

方式はシステム全体で1つに決める必要はありません。ガイドの例では、新しいサービスに合わせて仕様を見直したいオンライン業務はリビルド、仕様を変えないバッチ業務（夜間などにまとめて動かす処理）はリライトかリホスト、と業務の単位で分けています。^*1 方式ごとの費用の考え方はレガシーシステム刷新の費用相場で扱っています。

つまずきやすい点

IPAのポイント集は、現行の仕様の全容が捉えられていない場合は「新規開発よりも再構築の方が難易度が高い」と指摘しています。^*2 動いているシステムがあるから簡単だと考えがちですが、方式ごとにつまずく場所があります。

• リホスト・リライト：使っていないプログラムを残したまま移すと、すべての工程で余分な費用がかかり、テストでは正解の分からない確認をすることになります^*1
• リライト：言語の変換で動きが変わった箇所を見つける確認が、リホストより増えます
• リビルド：業務の要件を決め直して設計し直すため、いまの業務に詳しい人の時間が多く要ります
• 共通：要件を「今と同じ」とだけ決めると、部署ごとに受け止め方が違い、後から抜けや漏れが見つかります^*2

新旧の結果を比べるテストにも注意が要ります。ガイドは、このテストは網羅性を保証できないとしたうえで、完了の基準を前もって決めて関係者と合意しておかないと、テストがいつまでも終わらない事態になりやすいと述べています。^*1

外部に頼むときに確認しておきたい点

方式の名前だけで提案を比べると、同じ「リライト」でも作業の範囲が会社ごとに違うことがあります。見積もりを比べる前に、次の点を確かめておきます。

• 方式の中身：業務仕様・基盤・開発言語のうち、どれを変える提案なのか
• 現行の調査：使っていないプログラムやデータを、誰がどう見つけて外すのか
• テストの完了基準：新旧の結果を比べるテストを、どの範囲とどの条件で終えるのか
• 業務部門の関わり方：要件の確認やテストに、業務に詳しい人がいつどれだけ加わるのか
• 移行後の保守：刷新した後の保守を誰が受け持ち、設計書や手順書をどの形で引き継ぐのか

メインフレームからの移行では、文字コードや夜間の処理など固有の論点が加わります。詳しくはメインフレーム脱却の移行方式の選び方を参照してください。クラウドへの移行で使われる分類についてはクラウド移行戦略と移行方式の選び方で扱っています。

まとめ：移行方式で確かめておきたい3つの点

リホスト・リライト・リビルドから方式を選ぶうえで、確かめておきたい点は3つに整理できます。第一に、新しいシステムに求めることごとに、業務仕様・基盤・開発言語のどれを変える必要があるかを判定すること。第二に、方式をシステム全体で1つに絞らず、業務の単位で分けて考えること。第三に、使っていないプログラムの整理と、新旧の結果を比べるテストの完了基準を、着手の前に決めておくことです。この3点を踏まえておけば、「安く早く移したはずが、テストが終わらず稼働が延びた」という事態を避けやすくなります。方式の選び方や現行の調査の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：独立行政法人情報処理推進機構（IPA）「システム再構築を成功に導くユーザガイド 第2版」（2018年）（https://www.ipa.go.jp/archive/publish/qv6pgp000000117x-att/000057294.pdf）。出典：1.4節の再構築手法の分類、2.4節の再構築手法選択基本パターンと業務単位の選択例、2.5節の再構築手法の特徴、3章の資産活用方針・テストの特徴・現新比較テストの留意点を参照（2026年10月確認）
2. *2　参考：独立行政法人情報処理推進機構（IPA）「デジタル変革に向けたITモダナイゼーション企画のポイント集」（https://www.ipa.go.jp/archive/publish/qv6pgp000000117x-att/000063997.pdf）。出典：「モダナイゼーション」と「再構築」の使い分け、落とし穴1（再構築の難しさ）、落とし穴2（「今と同じ」という要件定義）の記述を参照（2026年10月確認）
3. *3　参考：Google Cloud「レガシー モダナイゼーションとは」（https://cloud.google.com/discover/what-is-legacy-modernization?hl=ja）。出典：リホスト（リフト＆シフト）の説明を参照（2026年10月確認）

Tweet