モダナイゼーションとは？5つの手法と自社に合う選び方をわかりやすく解説

「開発会社から聞いた『モダナイゼーション』の意味も、マイグレーションとの違いも分からない」。
長年使ってきたシステムを、このまま使い続けてよいのか、作り替えるべきか判断できずにいる方も多いのではないでしょうか。

この記事では、言葉の意味とマイグレーション・リプレイス・DX（デジタル技術で事業や業務を変えること）との違い、古いシステムを放置するリスク（後回しにした手直しが膨らむ「技術的負債」を含む）と見直しのサインを解説します。
あわせて、5つの手法の違い、自社に合う手法を選ぶ3つの基準、失敗しやすいパターンも紹介。
使い続けるか、置き換えるか、作り替えるかを判断する目安が持てるはずです。

運営会社のEPICsは、250件以上の開発実績を持つアプリ・システムの受託開発会社。
業務システムでは現場の業務診断から始め、SaaS（インターネット経由で使うサービス）で足りる場合は作らない選択肢も含めて、中立に提案しています。

モダナイゼーションとは？古いシステムを作り替えること

モダナイゼーションとは、長く使ってきた既存のシステムを、今の技術と業務に合う形に作り替えて、これからも使い続けられる状態にすることです。
この章では、言葉の意味と対象、似た言葉との違いを説明します。

意味は「近代化」。今の技術で作り替えて使い続けること

モダナイゼーションは英語の「modernization（近代化）」から来た言葉で、IT分野では既存のシステムを今の技術に合わせて作り替えることを指します。
野村総合研究所の用語解説での説明は、「老朽化したシステムや古いプロセスなどのIT資産を、ビジネス的な視点から、近代化もしくは最適化する考え方」です（出典：モダナイゼーション｜用語解説｜野村総合研究所（NRI））。
動詞の「モダナイズ」もほぼ同じ意味で使われ、日本語では「システムの刷新」「作り替え」と言い換えられます。
ポイントは、一から新しく作るのではなく、今のシステムが担っている業務やデータを生かしながら作り替える点です。

対象は、直しにくく高くつく「レガシーシステム」

モダナイゼーションの対象は、古いだけでなく、直しにくく維持に費用がかかり、事業の足かせになっている「レガシーシステム」です。
経済産業省・IPAの『レガシーシステムモダン化委員会総括レポート』（2025年5月公表）では、レガシーシステムを「単に古いだけではなく、維持保守や機能改良が困難な状態に陥り高コストの原因となり、経営・事業の足枷となっているシステム」と定義しています。
特徴として挙げられているのは、次の5つです（出典：レガシーシステムモダン化委員会総括レポート）。

• 技術の老朽化
• 肥大化・複雑化
• ブラックボックス化（中身を分かる人がいない状態）
• IT投資がされていない
• 古い制度としがらみ

レガシーかどうかを決めるのは、機械の大きさや古さではなく、直しにくさです。
『レガシーシステムモダン化委員会総括レポート』では、大型のコンピューターであるメインフレームについても、「メインフレームが必ずしもレガシーシステムであるとは限らない」とされています。

中小企業で身近なのは、長年使っている販売・在庫・会計などの基幹システム、開発元のサポートが終わったパッケージ（市販のソフト）、社員が作ったAccessの管理システムやExcelのマクロなどです。
基幹システムの役割や種類は、「基幹システムとは」の記事で解説しています。

マイグレーションは「移す」、リプレイスは「入れ替える」

マイグレーションは今のシステムを新しい環境へ「移す」こと、リプレイスは別のシステムに「入れ替える」こと、モダナイゼーションは今の技術で「作り替える」ことです。
変える範囲で比べると、違いは次のとおり。

言葉	何をするか	変わるもの	たとえ
マイグレーション	今のシステムを新しい環境へ移す	動かす場所 （中身はほぼ変えない）	引っ越し
リプレイス	別のシステムやSaaSに入れ替える	システムそのもの	買い替え
モダナイゼーション	業務とデータを生かしながら、今の技術で作り替える	作りと使い勝手	リフォーム

ただし、3つの言葉の境目ははっきりしていません。
野村総合研究所の用語解説では、レガシーマイグレーション（既存資産の移行）もモダナイゼーションに含まれるとされ、移す・入れ替えるは、作り替えを進める手段の1つとして使われます（出典：モダナイゼーション｜用語解説｜野村総合研究所（NRI））。
提案を受けたときは、言葉よりも「何をどこまで変えるのか」を確かめることが大切です。

DXは事業や業務の変革、モダナイゼーションはその土台づくり

DXはデータとデジタル技術で事業や業務のあり方を変えることで、モダナイゼーションは、そのために古いシステムを作り替える土台づくりという関係です。
経済産業省の『デジタルガバナンス・コード3.0』（2024年9月改訂）にも、DXの定義があります。
要約すると、データとデジタル技術を活用して、製品・サービス・ビジネスモデルや、業務・組織・プロセス・企業文化を変革し、競争上の優位性を確立することです（出典：デジタルガバナンス・コード3.0）。

『レガシーシステムモダン化委員会総括レポート』の整理でも、DXは「単なるレガシーなシステムの刷新・高度化」ではありません。
一方で、同じレポートは「システムの作りやデータ形式が古いと、最新のツールやサービスでデータの利活用ができない」とも指摘しており、古いシステムの作り替えはDXを進める前提といえます（出典：レガシーシステムモダン化委員会総括レポート）。

なぜモダナイゼーションが必要なのか？古いシステムを放置するリスク

古いシステムは今は動いていても、放置するほど、次の4つの面でリスクが大きくなります。

• 維持費がかさむ
• 技術的負債が膨らむ
• 直せる人がいなくなる
• 2025年を過ぎても課題が残る

維持費がかさみ、新しい取り組みに予算を回せなくなる

古いシステムは年数がたつほど維持費がかさみ、新しい取り組みに使えるはずの予算を圧迫します。
経済産業省の『DXレポート（サマリー）』（2018年9月）では、約8割の企業がレガシーシステムを抱え、約7割の企業がレガシーシステムをDXの足かせと感じていると示されました。
いずれも、日本情報システム・ユーザー協会の「企業IT動向調査報告書 2017」と「デジタル化の進展に対する意識調査」（平成29年）を引用した、2018年時点の値です。
同じレポートは、対策しないままではシステムの維持管理費が高額化し、IT予算の9割以上を占めるおそれがあるとも指摘しています（出典：DXレポート（サマリー））。

維持費を削減できないまま予算を取られるほど、新しい業務の仕組みやデータの活用に投資する余地がなくなるわけです。

技術的負債は、後回しにした手直しが利息のように膨らむ状態

技術的負債とは、急ぎの修正や後回しにした手直しが積み重なり、後から直すための手間と費用が、借金の利息のように膨らんでいく状態です。
IBMの解説では「ソフトウェア開発中に行った近道や最適ではない判断によって将来的に発生するコスト」と定義され、ソフトウェア技術者のウォード・カニンガム氏が、お金の借金にたとえて説明した考え方とされています（出典：技術的負債とは｜IBM）。
英語では「technical debt」。

原因になりやすいのは、急ぎの継ぎはぎの修正や、資料が残っていないこと、古い部品を使い続けていることなどです。
負債がたまると、改修のたびに時間と費用がかかり、不具合も起きやすくなって、直せる人は限られていく一方。

経済産業省の『DXレポート（サマリー）』も、技術的負債を「短期的な観点でシステムを開発し、結果として、長期的に保守費や運用費が高騰している状態」とし、維持管理費がIT予算の9割以上になる状態をこの言葉で表しています（出典：DXレポート（サマリー））。

解消の基本は、一度に返そうとせず、影響の大きい部分から計画的に返すことです。
まずは、改修のたびに時間や費用がかかっている機能や、止まると業務への影響が大きい機能から手を付けるのが現実的。
改修のたびに中の作りを整理し、作り替えるときには資料を残すと、負債を増やさずに済みます。

作った人がいなくなると、直せないシステムになる

中身を知る人が作った本人や一部の会社しかいないシステムは、その人がいなくなった時点で、直すことも止めることもできなくなります。
仕様書がなく、作った社員や開発会社しか中身が分からない状態が、いわゆる「ブラックボックス化」です。
担当者の退職や開発会社の廃業をきっかけに、業務に欠かせないシステムが、手を付けられないまま残ってしまいます。

『DXレポート（サマリー）』では、レガシーシステムの保守・運用が属人的（特定の人に頼りきり）になり、継承が難しいと考える事業者は6割以上とされました。
これは経済産業省委託の「情報システム開発課題アンケート結果」（平成30年2月）を引用した、2018年時点の値です（出典：DXレポート（サマリー））。
『レガシーシステムモダン化委員会総括レポート』も、「中小企業は、投資体力やITリテラシー、人材リソースの問題が顕著」と指摘しています（出典：レガシーシステムモダン化委員会総括レポート）。

「2025年の崖」を過ぎた今も、課題は残っている

「2025年の崖」は2018年に経済産業省が示した警告で、2025年を過ぎた今も、古いシステムの課題は解決していません。
『DXレポート（サマリー）』で、古いシステムなどの課題を克服できなければ、2025年以降に大きな経済損失が生じる可能性があるとして使われた言葉です。
経済産業省は2025年5月の『レガシーシステムモダン化委員会総括レポート』でも、「未だ多くの企業がレガシーシステムを保有しDXを阻害」していると指摘しました。
（出典：DXレポート（サマリー）、総括レポートの公表（経済産業省）、レガシーシステムモダン化委員会総括レポート）
2025年を過ぎたから終わった話ではなく、今も向き合うべき課題といえます。

自社のシステムは見直すべき？モダナイゼーションを考える4つのサイン

次の4つのうち1つでも当てはまるなら、今のシステムを見直す時期に来ています。

• 直せる人が社内にも開発元にもいない
• OS（パソコンやサーバーを動かす基本のソフト）やソフトのサポート終了が迫っている、または終わっている
• システムの外で、Excelへの転記や二重入力が増えている
• 小さな改修でも、見積もりが高く時間がかかる

『レガシーシステムモダン化委員会総括レポート』によると、モダン化（モダナイゼーションと同じ意味）を決める要因は受動的なものがトップで、「痛い目にあって初めて自覚する」状態です。
上位に挙がったのは、基幹システムの障害の頻発や、保守サポート要員を確保できない・保守料が上がるといった保守の限界でした（出典：レガシーシステムモダン化委員会総括レポート）。
問題が起きる前に、次のようなサインに気付くことが大切です。

サイン	起きていること	放置した場合
①直せる人が社内にも開発元にもいない	・作った担当者が退職した ・開発会社と連絡が取れない、廃業した ・Excelのマクロ・Accessを分かる人がいない	不具合が起きても直せず、業務が止まる
②OSやソフトのサポート終了が迫っている、または終わっている	古いOSでしか動かないシステムがある	セキュリティの更新が届かなくなる
③システムの外で、Excelへの転記や二重入力が増えている	システムが今の業務に合っていない	業務の効率が落ち、手作業のミスと手間が増え続ける
④小さな改修でも、見積もりが高く時間がかかる	技術的負債がたまっている	業務の変化に追いつけなくなる

①の直せる人がいない状態は、ブラックボックス化がすでに進んでいる表れです。
担当者が社内にいるうちに、仕様や操作の手順を資料に残しておくだけでも、後で見直すときの手間を小さくできます。

②の例として、Windows 10のサポートは2025年10月14日に終了（出典：Windows 10、Windows 8.1、Windows 7 のサポート終了｜Microsoft Windows）。
古いOSでしか動かないシステムは、移行しない限りセキュリティの更新を受けられず、情報漏えいなどの危険を抱えたまま使い続けることになります。

③の転記や二重入力は、システムと業務がずれてきた表れで、手作業が増えるほどミスも起きやすい状態です。
データがシステムとExcelに分かれると、どれが正しい数字か分からなくなることもあります。

④の小さな改修でも見積もりが膨らむのは、技術的負債がたまり、どこを直すにも手間がかかるようになっているためです。
改修のたびに費用がかさむなら、部分的に直し続けるより、作り替える範囲を決めて見直したほうが、長い目で見て費用を抑えられる場合があります。

モダナイゼーションの手法は？変える範囲で5つに分かれる

モダナイゼーションの手法の種類は、今のシステムをどこまで変えるかによって、大きく5つに分かれます。
変える範囲が広いほど、費用・期間・社内の負担は大きくなる一方、使い勝手や業務の改善の効果も大きくなるという関係です。
費用と期間は、システムの規模（画面や機能の数、データの量）によっても変わります。

クラウド（インターネット経由で使うサーバーなどの環境）への移行の方針として、AWS（アマゾン ウェブ サービス）が示すのは「7R」と呼ばれる7つ。
Retire・Retain・Rehost・Relocate・Repurchase・Replatform・Refactorです（出典：About the migration strategies – AWS Prescriptive Guidance）。
この記事では、発注する側が判断しやすいよう、変える範囲の小さい順に5つに整理しました。
手法の呼び方や範囲は、会社や資料によって異なる点に注意してください。

手法	変えるもの	向くケース	注意点
リホスト	動かす場所 （社内のサーバーからクラウドなどへ）	早く移したい	作りと使い勝手は変わらず、技術的負債は残る
リライト	プログラムの言語	直せる技術者を確保したい	・業務の流れは今のまま ・今の仕様が分かることが前提
リファクタリング	プログラムの中の作り	少しずつ直しやすくしたい	使う人から見た変化がなく、効果を説明しにくい
リプレイス	システムそのもの （SaaSや新しいシステムへ）	どの会社でも手順が近い業務を置き換えたい	・業務のやり方を合わせる必要が出ることがある ・データの移行が必要
リビルド	業務のやり方と機能	業務そのものを改善したい	費用・期間・社内の負担が最も大きい

リホスト：中身はそのまま、動かす場所だけ移す

リホストは、プログラムの中身は変えずに、システムを動かす場所だけを社内のサーバーからクラウドなどへ移す方法です。
AWSの7Rの「Rehost（リフト＆シフト）」にあたり、比較的早く移れます。
ただし、作りや使い勝手は変わらず、技術的負債は残ったまま。
AWSのガイドでは、大規模な移行では先にリホストなどで移し、移行の後に作り替える進め方が勧められています（出典：About the migration strategies – AWS Prescriptive Guidance）。
まず移して、後から段階的に作り替えるのも1つの選択肢です。

リライト：機能はそのまま、新しい言語で書き直す

リライトは、画面や機能は今のまま、古いプログラム言語で書かれたシステムを今の言語で書き直す方法です。
今よく使われる言語に移すことで、直せる技術者を確保しやすくなります。
ただし、業務の流れは変わらず、今の仕様が分からないと書き直せないため、ブラックボックスの解消が前提です。
生成AI（文章やプログラムを作るAI）で古いプログラムの解析や書き換えを補助する方法も出てきましたが、正しく動くかは人が確かめる必要があります。

リファクタリング：動きは変えず、中の作りを整理する

リファクタリングは、画面や機能は変えずに、プログラムの中の作りを整理して、直しやすい状態にする方法です。
技術的負債を少しずつ返す方法にあたり、改修のたびに進めることもできます。
注意したいのは、使う人から見た変化がないため、効果を社内に説明しにくい点。
なお、AWSの7Rの「Refactor」は、クラウドの機能を生かすために作りを大きく変える意味で使われており、言葉の範囲は資料によって異なります。

リプレイス：SaaSや新しいシステムに置き換える

リプレイスは、今のシステムの利用をやめて、SaaSや新しいシステムに置き換える方法です。
AWSの7Rでは「Repurchase」にあたる手法。
既製のSaaSやパッケージに置き換える場合は、業務のやり方を新しい仕組みに合わせる必要が出ることがあります。
どの置き換え先でも、今のデータを新しいシステムへ移す作業が必要です。
置き換えの具体的な進め方は、「システムリプレイス」の記事で解説しています。

リビルド：業務から見直して作り直す

リビルドは、今の業務のやり方から見直し、必要な機能を選び直して、システムを作り直す方法で、「再構築」とも呼ばれます。
業務の改善の効果は5つの中で最も大きい一方、費用・期間・社内の負担も最も大きいのが難点です。
そのため、一部の業務から段階的に進める方法もあり、その注意点は失敗しやすいパターンの章で説明します。

どの手法を選べばいい？自社に合う手法を決める3つの基準

どの手法が合うかは、技術の新しさではなく、「何のために変えるか」「その業務が自社独自か」「その機能が今も使われているか」の3つで決まります。
モダナイゼーションの計画を立てる前に、次の3つを機能ごとに確かめておきましょう。

• 目的：業務を変えたいのか、システムだけ新しくしたいのか
• 業務の独自性：自社独自の業務か、どの会社でも同じ業務か
• 機能の使われ方：今も使われているか、困りごとがあるか

業務を変えたいのか、システムだけ新しくしたいのかを決める

まず、システムを止めずに使い続けたいのか、業務のやり方まで変えたいのかを決めると、候補になる手法が絞れます。
サポート終了への対応など「止めずに使い続けること」が目的なら、変える範囲の小さいリホストやリライトが候補です。
業務の効率化やデータの活用が目的なら、リプレイスやリビルドが候補になります。
目的が決まらないまま手法を選ぶと、費用をかけても期待した効果が出ないおそれがあるため、最初に決めておくことが大切です。

独自の業務は作り替え、どの会社も同じ業務はSaaSを検討する

どの会社でも手順が大きく変わらない業務はSaaSで足り、自社の強みになっている独自の業務は作り替えが向いています。
会計や勤怠のような業務ならSaaSで足りる可能性がある一方、独自の受注の流れや料金の計算などをSaaSに合わせると、その強みが失われかねません。
作り替えれば、独自の業務に合わせて柔軟に作り、自社に最適化した仕組みにすることも可能です。
『レガシーシステムモダン化委員会総括レポート』も、「標準的な仕様に寄せる部分と、付加価値を作り込む部分とに明確に分離」するとし、寄せる先にパッケージ・SaaS・業界標準システムを挙げています（出典：レガシーシステムモダン化委員会総括レポート）。
1つのシステムの中でも、機能ごとに分けて考えてよいということです。

使わない機能は「やめる」、問題のない機能は「使い続ける」

すべてを作り替える必要はなく、使われていない機能はやめ、問題のない機能はそのまま使い続けるのも正しい選択です。
AWSの7Rにも、Retire（廃止）とRetain（維持）という、作り替えない方針が含まれています（出典：About the migration strategies – AWS Prescriptive Guidance）。
『DXレポート（サマリー）』でも、使わないシステムは捨てるか手を加えずに残すかを見極めて、必要なものだけを新しくすることや、新しくする前に不要なシステムを減らしておくことが示されました（出典：DXレポート（サマリー））。
機能ごとに、今も使われているか、困りごとがあるかを確かめて、残す・やめる・作り替えるを分ければ、作り替える範囲が小さくなり、費用と期間を抑えられます。

モダナイゼーションで失敗しやすい3つのパターンは？

モダナイゼーションの失敗の多くは、技術の選び方ではなく、進め方で起きています。
避けたいのは、次の3つのパターンです。

• 今と同じ機能のまま作り直す
• 一度に全部を切り替える
• 作り替えた後の資料を残さない

「今と同じ機能のまま」作り直し、使わない機能まで引き継ぐ

今のやり方をそのまま引き継ぐ「現行踏襲」で作り直そうとすると、使われていない機能まで引き継ぎ、費用だけが膨らみます。
『レガシーシステムモダン化委員会総括レポート』が示す方針は、「DXの阻害要因である現行機能保証や現行踏襲の拘りは棄てる。あるべき業務の姿から検討。」です。
同じレポートでは、現場の協力が得られない理由の1つにも「現行踏襲への強いこだわり」が挙がっています（出典：レガシーシステムモダン化委員会総括レポート）。
今の仕様をそのまま再現すると古い業務の手順まで作り直すことになり、費用をかけても業務は良くなりません。

一度に全部を切り替え、現場がついてこられない

すべての業務を一度に切り替えると、不具合や操作の戸惑いで業務が止まり、現場が元のやり方に戻ってしまうことがあります。
たとえば、新しいシステムに慣れないまま、結局Excelでの管理に戻ってしまうといった形です。
一部の業務で試し、効果と使われ方を確かめてから広げると、うまくいかなかったときの影響を小さくできます。

作り替えた後の資料がなく、次の技術的負債を生む

作り替えた後に仕様書などの資料が残っていないと、新しいシステムも数年後には、直せる人が限られた状態に戻ってしまいます。
IBMの解説でも、資料（ドキュメント）の不足は技術的負債の主な原因の1つです（出典：技術的負債とは｜IBM）。
『レガシーシステムモダン化委員会総括レポート』によると、メインフレームから脱却した後でも「再レガシー化する可能性」があります。
『デジタルガバナンス・コード3.0』が求めるのも、ITシステムが技術的負債となるのを防ぐことです（出典：レガシーシステムモダン化委員会総括レポート、デジタルガバナンス・コード3.0）。

発注するときは、資料を整えてもらえるか、プログラムとデータを自社のものとして受け取れるか（所有権）を確認しておきましょう。
特定の会社しか直せない状態は「ベンダーロックイン」と呼ばれ、ほかの会社に改修や保守を頼みにくくなります。

業務システムのモダナイゼーションならEPICs

EPICsは、古い業務システムを作り替える前に現場の業務を診断し、作り替えない選択肢も含めて、会社ごとに合う進め方を提案しています。
診断では、SaaSで足りるか、一部の改修で済むかまで含めて中立に手法を選び、一部の業務で試してから広げるのが特徴です。
パイロット（試験導入）の後に「拡げる・作り直す・止める」を判断できるため、総額を一度に負担する必要はありません。

開発では、ノーコード（画面の操作で作る方法）・AI駆動開発（AIの支援を受けて作る方法）・スクラッチ開発（一からプログラムを書く方法）を、業務の領域ごとに使い分けています。
基幹に関わる部分は、スクラッチ開発で堅く作るのが方針です。

作ったシステムは、10年使う前提で保守しやすい構成にし、ドキュメントを整えたうえで、コード（プログラム）とデータの所有権もお渡ししています。
作り替えた後に、次の技術的負債を生まないための進め方です。

開発実績は250件以上。
費用の目安は、業務診断が30万円〜（本開発を依頼した場合は全額充当）、一部業務のパイロット開発が50万円〜です。
まずは見直したいシステムと業務を整理し、どこから手を付けるかを専門家と一緒に決めることから始めてみてください。

出典：EPICs アプリ・システム受託開発サービス／EPICs DX・業務システム開発支援

なぜ古いシステムをクラウドに移すだけでは不十分なのですか？

クラウドに移すだけでは、システムを動かす場所が変わるだけで、プログラムの作りや業務の流れは変わらないためです。社内のサーバーからクラウドへ中身を変えずに移す方法はリホストと呼ばれ、サーバーを管理する手間は減らせます。一方で、急ぎの修正や後回しにした手直しが積み重なって直しにくくなった状態（技術的負債）や、中身を分かる人がいない状態はそのまま残ります。そのため、使い勝手や業務の改善までは期待しにくいといえます。補足：まずクラウドへ移してから、改修に合わせて段階的に作り替えていく進め方もあり、移すこと自体が無駄になるわけではありません。

ExcelのマクロやAccessで作った仕組みも、モダナイゼーションの対象になりますか？

はい、対象になります。業務に欠かせないのに、直せる人がいない、仕様が分からないという状態なら、長年使われてきた基幹システムと同じ課題を抱えているためです。古いシステムが問題になるかどうかは、システムの大きさや古さではなく、直しにくさや維持の負担で決まります。見直すときは、その業務が自社独自のものかどうかで方向を考えるのが基本です。会計や勤怠のように、どの会社でも手順が近い業務ならSaaS（インターネット経由で使うサービス）への置き換えを、自社独自の業務なら業務システムへの作り替えを検討するとよいでしょう。

技術的負債は、どうすれば解消できますか？

一度にすべてを返そうとせず、影響の大きい部分から計画的に返していくのが基本です。技術的負債とは、急ぎの修正や後回しにした手直しが積み重なり、後から直すための手間と費用が借金の利息のように膨らんでいく状態を指します。具体的には、改修のたびにプログラムの中の作りを整理する「リファクタリング」を続けることで、少しずつ返せます。システムを作り替えるときは、仕様書などの資料を残し、プログラムとデータを自社のものとして受け取っておくと、新しいシステムが次の技術的負債になるのを防ぎやすくなります。

モダナイゼーションの費用や期間は、どれくらいかかりますか？

一概には言えず、変える範囲とシステムの規模によって大きく変わります。モダナイゼーションの手法には、動かす場所だけを移すリホストから、業務から見直して作り直すリビルドまであり、変える範囲が広いほど費用も期間も大きくなります。画面や機能の数、データの量といったシステムの規模も、費用と期間を左右する要素です。そのため、まず今のシステムがどの業務でどう使われているかを把握し、残す・やめる・作り替える範囲を決めてから見積もりを取ることが大切です。