--- title: "ハイパーケアとは？本番稼働直後の体制・期間・終了基準と運用保守への引継ぎ" url: "https://www.issoh.co.jp/column/details/19792/" published: 2026-11-15 updated: 2026-11-15 categories: ["Webシステム"] publisher: "株式会社一創" --- # ハイパーケアとは？本番稼働直後の体制・期間・終了基準と運用保守への引継ぎ ハイパーケア（hypercare）は、システムの本番稼働直後に、支援の人員と対応速度を一時的に引き上げる期間を指します。テストでは見つからなかった不具合や、操作に慣れない利用者からの問い合わせが集中する数週間を、通常の運用保守より厚い体制で乗り切るための仕組みです。本記事では、保証期間や運用保守との違い、期間の決め方、体制と問い合わせ窓口の作り方を整理します。後半では、終了基準を数値で置く方法と、運用保守チームへの引継ぎ手順、発注者が陥りやすい失敗まで解説します。 ## まとめ：ハイパーケアは終了基準と終了日を稼働前に決め引継ぎまで計画する期間 ハイパーケアの成否は、稼働当日ではなく稼働前の取り決めで決まります。いつまで続けるのか。何が満たされたら終えるのか。終えた後は誰が引き受けるのか。この3点が決まっていないと、支援は惰性で延びるか、逆に次の工程へ要員が引き抜かれて手薄になります。 実務の順番は、①期間を月次締めなど業務の周期を1回通す長さで置く、②一次窓口・二次対応・開発会社の待機を体制表に書く、③重大障害の件数・新規問い合わせの件数・SLAの達成状況で終了基準を数値化する、④受入テストの段階から運用保守チームに起票と対応を担わせる、です。終了判定は「落ち着いたから」ではなく、合意した基準を満たしたかで行ってください。 ## ハイパーケアとは何か｜本番稼働直後に支援を厚くする期間の意味と位置づけ ハイパーケアは、システム開発の工程でいえばカットオーバーの直後、通常の運用保守が始まる手前に置かれます。ERPや基幹システムの刷新、クラウド移行など、業務への影響が大きい案件で計画に入れられることの多い期間です。 ### ハイパーケアの意味｜稼働直後に要員と対応速度を一時的に引き上げる期間 Microsoft LearnのDynamics 365導入ガイド「[Plan your support operations](https://learn.microsoft.com/ja-jp/dynamics365/guidance/implementation-guide/transition-to-support-operations)」（2026年7月更新時点）は、ハイパーケアを「稼働後の短い期間に、利用者と業務プロセスを支えるために追加の人員と注意を割く期間」と説明しています。目的は、新システムの初期の問題に対処しながら、業務を止めずに回すことです。 具体的には、開発会社のエンジニアが常駐またはすぐ連絡が取れる状態で待機し、問い合わせ窓口の受付時間を延ばし、不具合の対応優先度を引き上げます。利用者向けの操作説明を並行して行うことも、現場での対応の一つです。いずれも「通常より速く、通常より多くの人で」対応する点が共通しています。 ### 保証期間・瑕疵対応・通常の運用保守との違いと契約での書き分け方 似た言葉が多く、発注書で混ぜて使うと費用と責任の範囲がずれます。違いを整理すると次のとおりです。 | 用語 | 主に指すもの | 費用の扱いの例 | | -------- | ----------------- | ----------- | | ハイパーケア | 稼働直後に体制を厚くする期間 | 開発費の一部か別見積り | | 保証期間 | 移行チームが問題対応を約束する期間 | 移行作業の費用に含む | | 契約不適合の修補 | 仕様と合わない不具合の無償修正 | 請負契約の条文で決まる | | 運用保守 | 稼働後の監視・問い合わせ・改修 | 月額の保守契約 | ハイパーケアは「体制の厚さ」の話で、契約不適合の修補は「誰が費用を負担するか」の話です。ハイパーケア中に見つかった不具合でも、仕様にない要望なら追加開発になります。契約書では、ハイパーケアの期間と体制、その間の対応範囲、終了後に引き受ける保守契約の開始日を分けて書いてください。 ## ハイパーケアが必要になる理由｜本番稼働直後に問い合わせと不具合が集中する構造 受入テストを通ったシステムでも、稼働直後には問題が出ます。テストと本番では、データの量と種類、利用者の人数と習熟度、連携先の状態が違うためです。 ### テストで出ない不具合が本番の実データと実利用者で表面化する経路 本番で初めて出る問題は、出どころで分けると対処の担当が決めやすくなります。発生しやすい順に並べます。 - 操作の問い合わせ：画面や手順の変更に利用者が慣れておらず、件数が最も多い - データ起因の不具合：移行データの欠損や、テストデータに無かった例外値で処理が止まる - 連携先との不整合：取引先や他システムとの接続が、本番の条件で初めて失敗する - 性能の問題：利用者が一斉にログインする朝や、月末の集計で応答が遅くなる 件数で大半を占めるのは、操作に関する問い合わせです。ここを開発会社のエンジニアが直接受けると、本当に直すべき不具合への対応が遅れます。ハイパーケアの体制は、この件数の差を前提に組み立てます。 ### ハイパーケアを省くと起きること｜Microsoftの事例に見るSLA未達と延長 Microsoft Learnの「[Case study in transitioning to support](https://learn.microsoft.com/ja-jp/dynamics365/guidance/implementation-guide/transition-to-support-case-study)」は、従業員1,000人未満の企業がERPとCRMを刷新した事例を紹介しています。この企業では、サポートチームへの研修と引継ぎが当初の1週間から2日に縮められました。プロジェクトチームはハイパーケア2週間で次の工程に移る予定で、導入パートナーの支援時間は4〜6週間分の予算だったものが2週間で尽きています。 結果として、稼働後の数週間はSLAを守れない状態が続き、会社はハイパーケアを正式に延長しました。一方、6か月後の次の展開では、利用者数がより多いにもかかわらず、ハイパーケアは短く、費用も低く済んでいます。違いは、サポートチームを開発中から関与させ、引継ぎを計画に組み込んだことでした。 ## ハイパーケア期間の決め方｜業務の周期と稼働規模から終了日を先に置く ハイパーケアの長さに公的な基準はありません。数日から数か月まで幅があり、数週間とする例が多く見られます。長さは「何を一度通せば安心できるか」で決めます。 ### 期間の目安｜保証期間1日〜1週間では足りない業務周期の見分け方 AWSの移行ガイダンス「[カットオーバー後の段階](https://docs.aws.amazon.com/ja%5Fjp/prescriptive-guidance/latest/best-practices-migration-cutover/post-cutover-stage.html)」は、移行チームが問題に対応する保証期間を通常1日から1週間としつつ、四半期ごとのバッチで動くアプリケーションでは1週間では不十分な場合があると注記しています。 ハイパーケアも同じ考え方で決めます。日次の処理しかない受付システムなら、必要な期間は2週間程度です。月次締めのある販売管理や会計なら、最初の月次締めと翌月の初日を通すまで、つまり稼働から4〜6週間を本記事では目安として勧めます。切替当日から数日間の監視項目は[カットオーバーの計画と保証期間を解説した記事](https://www.issoh.co.jp/column/details/19420/)で扱っています。 ### 期間を延ばす要素｜繁忙期・利用者数・拠点ごとの段階展開の扱い 業務の周期に加えて、次の条件があれば期間を延ばすか、区切りを分けて設定します。 - 稼働から1か月以内に繁忙期や決算がある - 利用者が数百人を超え、操作説明が一度で行き渡らない - 拠点や部門ごとに順に稼働させる段階展開をとる - 取引先との連携が、相手方の締め日でしか確認できない 段階展開の場合は、拠点ごとにハイパーケアを置き、最初の拠点で得た問い合わせ傾向を次の拠点の操作説明に反映させます。前述のMicrosoftの事例で2回目のハイパーケアが短く済んだのは、この学習が効いた結果です。 ## ハイパーケアの体制｜開発会社・情報システム部門・業務部門の役割分担と窓口 体制は、問い合わせを受ける層と直す層を分けて組みます。Microsoft Learnの「[Prepare to go live](https://learn.microsoft.com/ja-jp/dynamics365/guidance/implementation-guide/prepare-to-go-live)」（2026年10月更新時点）は、稼働準備の項目として本番サポート計画の作成と承認を挙げ、一次・二次・三次のサポートの責任とエスカレーションの経路を一覧にすること、重大な場面に備えて時間外と週末の対応を確保することを求めています。 ### 体制表に書く役割｜一次窓口・二次対応・開発会社の待機と判断者 体制表には、役割ごとに担当者の名前と連絡手段、対応時間を書きます。組織名ではなく個人名で書き、不在時の代理も決めます。 | 役割 | 担う作業 | 担当の例 | | ---- | -------------- | ------------------- | | 一次窓口 | 受付・切り分け・操作の回答 | 情報システム部門・各部門のキーユーザー | | 二次対応 | 設定やデータの調査・修正 | 運用保守チーム | | 三次対応 | プログラムの修正・連携の調査 | 開発会社のエンジニア | | 判断者 | 優先度・回避策・延長の決定 | 発注者のプロジェクト責任者 | ハイパーケアの間は、三次対応の開発会社が二次対応に入り込み、運用保守チームと並んで調査します。この並走が引継ぎの訓練を兼ねます。 ### 問い合わせの受け方｜キーユーザーと共有チャネルで操作の質問を現場で返す 操作の問い合わせを現場で答えられる仕組みがあると、二次・三次の負荷が大きく下がります。Microsoftの事例でも、稼働後の振り返りで、Microsoft Teamsのチャネルにスーパーユーザー（各部門で操作に詳しい利用者）を置き、簡単な質問はそこで答える運用が提案されていました。 キーユーザーは各部門に1人以上置き、稼働前の操作説明を先に受けてもらいます。問い合わせは個人宛ての電話やメールで受けず、必ず管理表かチケットに起票させてください。個人宛ての対応は件数が見えず、終了判定の材料が残りません。 ### 対応優先度とSLAの置き方｜重大度別の初動時間を期間中だけ短くする ハイパーケアの間は、重大度ごとの初動時間を通常の保守契約より短く設定します。本記事では、業務が止まる障害は30分以内に初動、回避策のある不具合は当日中、操作の問い合わせは翌営業日までを目安として勧めます。 重大度の定義は「業務が止まるか」「回避策があるか」の2つの軸で決めると、受付担当が迷いません。期間中に数えた初動時間の達成率は、そのまま終了判定の材料になります。 ## ハイパーケアの終了基準｜重大障害ゼロ・問い合わせ件数・SLA達成率で判定する 終了基準が無いハイパーケアは、終われないか、終わってはいけない時期に終わります。前述のMicrosoftのガイドは、特定の基準を満たすことに基づいた明確な終了戦略を定め、終了日とその基準を満たすための行動計画を持つよう勧めています。 ### 終了基準の例｜Microsoftが挙げる4条件を数値の合格ラインに置き換える 同ガイドは終了の判断例として、重大な問題が無いこと、主要な業務プロセスが効率よく回っていること、SLAを満たしていること、サポートチームが追加の支援なしで大半の問題を解決できることを挙げています。これを数えられる形にしたひな型が次の表です。数値は案件ごとに業務部門と合意して決めます。 | 判定項目 | 終了条件の例 | | -------- | ------------------ | | 重大な障害 | 直近2週間で発生0件・未解決0件 | | 主要業務 | 月次締めを期日どおり1回完了 | | 新規の問い合わせ | 週あたり件数が稼働初週の2割以下 | | SLA | 重大度別の初動時間を2週連続で達成 | | 自力解決率 | 運用保守チームだけで8割以上を解決 | | 引継ぎ資料 | 運用手順書と既知の問題一覧を受領済み | 「直近2週間」のように期間で区切るのは、たまたま静かな数日を根拠に終了するのを防ぐためです。自力解決率は、運用保守チームが受けた件数のうち開発会社へ回さずに閉じた割合で数えます。 ### 終了判定会議の運び方と延長を決める場合の条件と費用負担の扱い 終了判定は、予定終了日の1週間前に会議を開いて行います。出席者は発注者のプロジェクト責任者、業務部門の責任者、運用保守チームの責任者、開発会社の責任者です。基準を満たしていれば終了し、翌日から通常の保守契約へ移ります。 満たさない項目がある場合は、項目を限って延長します。たとえば重大障害が残るなら、その障害の解決までを延長範囲とし、操作の問い合わせ対応は予定どおり運用保守チームへ移します。延長の費用負担は、原因が開発側の不具合なら開発会社、業務側の準備不足なら発注者と、契約時に決めておくと揉めません。 ## 運用保守への引継ぎ｜ハイパーケア中に資料・訓練・未解決課題を渡し切る手順 ハイパーケアは、開発チームから運用保守チームへ責任を移す期間でもあります。Microsoftのガイドは、ハイパーケアの間に、プロジェクトチームと導入パートナーからサポートチームへ必要な資料と研修が渡るようにすることを求めています。 ### 引継ぎ資料の範囲｜運用手順書・既知の問題一覧・問い合わせ履歴・設定記録 引継ぎで渡すものは、優先度の高い順に次のとおりです。 1. 既知の問題一覧：未解決の不具合、回避策、修正予定日 2. 問い合わせ履歴：ハイパーケア中のチケットと回答内容 3. 運用手順書：日次・月次の作業、バッチの再実行、障害時の連絡経路 4. 設定変更の記録：稼働後に変えたパラメータやマスタの内容と理由 5. 設計書と構成図：連携先の一覧と接続情報の保管場所 最初の2つはハイパーケア中にしか作れない資料です。稼働後に何が起き、どう答えたかの記録は、そのまま運用保守チームの回答集になります。資料を更新し続ける仕組みは[運用保守ドキュメントの整備手順を解説した記事](https://www.issoh.co.jp/column/details/16404/)で詳しく扱っています。 ### 引継ぎは稼働前から始める｜受入テストで運用チームに起票と対応を担わせる 資料を渡すだけの引継ぎは、ほぼ確実に足りません。Microsoftのガイドは、移行の練習として、受入テストなどテストの後半で正式なサポート手順を使い、見つかった問題を実際の窓口とツールで起票・切り分け・解決させる方法を挙げています。 受入テストで出た指摘を、開発会社に直接送らず運用保守チーム経由で起票させるだけでも、稼働時点で窓口が一度回った状態になります。受入テストの進め方は[受入テストの進め方と合否基準を解説した記事](https://www.issoh.co.jp/column/details/19414/)で整理しています。 ### 未解決課題と改善要望の振り分け｜不具合と変更要求と次期開発の区別 ハイパーケアの終盤には、未解決の項目を性質で振り分けます。仕様と合わない不具合は、期日を決めて開発会社が修正する対象です。設定やマスタの変更で済む要望は運用保守チームの変更管理へ回します。新しい機能の要望は次期開発の候補として一覧にまとめ、ハイパーケアの中では手を付けません。 この振り分けをしないと、要望の対応がハイパーケアに紛れ込み、終了基準の問い合わせ件数がいつまでも下がりません。 ## ハイパーケアで失敗する発注者の判断パターンと開発会社に任せる範囲 失敗の多くは、技術よりも段取りの抜けから起きます。起きやすい順に挙げます。 ### 次の工程に要員を移して稼働直後の支援が手薄になる失敗パターン 最も多いのは、プロジェクトチームが稼働直後から次の開発や別拠点の展開に移り、ハイパーケアに手が回らなくなるケースです。Microsoftのガイドも、ハイパーケア中のプロジェクトチームとパートナーの役割を事前に決めておかないと、次の工程で忙しくなり支援への関与を拒むおそれがあると注意しています。 対策は、ハイパーケア中に誰が何時間を割くかを体制表と見積りに書き、次の工程の開始日を終了判定会議の後に置くことです。 ### 終了基準が無く惰性で延長し費用と責任の範囲が曖昧になる失敗パターン 支援を終えられなくなるのが、逆の失敗です。終了基準を決めないまま始めると、開発会社が常駐した状態に現場が慣れ、終わりの判断ができなくなります。費用は延び、どこまでが保証でどこからが保守かも曖昧になります。 開始時に終了日を仮置きし、その日に向けて前章の基準で判定する、と決めておけば防げます。 ### 開発会社に任せてよい作業と発注者が手放してはいけない判断の線引き 問い合わせの受付と切り分け、不具合の調査と修正、引継ぎ資料の作成は開発会社や保守会社に任せて構いません。一方で、重大度の定義、終了基準の数値、延長の可否、運用保守チームの体制と予算は、業務の責任を負う発注者が決めます。 社内に運用保守の担い手がいない場合は、ハイパーケアの段階から保守を担う会社を入れ、開発会社と並走させる方法があります。一創の[保守運用 / 内製化支援](https://www.issoh.co.jp/service/system/maintenance/)では、稼働後の保守運用の受託に加えて、社内チームへの引継ぎと内製化の支援まで対応しています。 ## よくある質問 ハイパーケアについて、発注者からよく寄せられる質問をまとめました。 ### ハイパーケアの費用は開発費に含まれますか？ 契約の書き方によります。開発の見積りに「稼働後2週間の支援」のような形で含まれている場合もあれば、別の見積りになる場合もあります。含まれている場合でも、体制の厚さ（常駐か待機か、対応時間帯）が想定と違うことがあるため、期間・体制・対応範囲を見積りの段階で文書にしてもらってください。延長が必要になったときの単価も、あわせて確認しておくと後で揉めません。 ### 小規模なシステムでもハイパーケアは必要ですか？ 期間と体制を小さくしても、置いたほうが安全です。利用者が数十人の社内システムなら、稼働後1〜2週間、開発会社の担当者が当日中に連絡を受けられる状態にし、問い合わせを1つの管理表に集めるだけでも効果があります。小規模な案件ほど運用の担当者が1人に集中しやすいため、終了時に引き継ぐ資料の範囲だけは規模に関係なく決めておいてください。 ### ハイパーケア中に見つかった不具合は無償で直してもらえますか？ 仕様と合わない不具合であれば、請負契約では契約不適合として修補を求められるのが一般的です。ただし通知の期限や範囲は契約書の条文で決まります。ハイパーケアは体制の取り決めであって、無償修正の範囲を広げるものではありません。仕様にない要望や業務手順の変更は、ハイパーケア中でも追加開発として扱われる点に注意してください。 ### アジャイル開発やSaaS導入でもハイパーケアは置きますか？ 置く例は多くあります。アジャイル開発でも、利用者に初めて公開するリリースや、旧システムから切り替えるリリースでは問い合わせが集中するためです。SaaSの導入では、製品の不具合は提供元の窓口、設定や運用の問い合わせは導入パートナーと社内と、受付先が分かれます。どの問い合わせを誰が受けるかを体制表に書いておくことが、自社開発以上に効いてきます。 ### ハイパーケアと運用テストはどう違いますか？ 運用テストは稼働前に、本番に近い環境で運用手順やバッチ、障害時の連絡体制が回るかを確かめる工程です。ハイパーケアは稼働後に、本番の業務で起きた問題へ厚い体制で対応する期間です。運用テストで体制表と問い合わせの起票手順を一度回しておくと、ハイパーケアの初日から窓口が機能します。順番は、受入テスト、運用テスト、カットオーバー、ハイパーケア、運用保守です。 ## 関連記事 - [システム運用保守の会社はどう選ぶ？相見積りを比較できる形に揃える手順と契約前の確認点](https://www.issoh.co.jp/column/details/16402/)：ハイパーケア後に保守を引き受ける会社の選び方を整理しています。 - [基幹システムの運用保守：業務カレンダー・法改正・EOLから決める体制と委託範囲](https://www.issoh.co.jp/column/details/19492/)：引継ぎ後の運用保守の体制と委託範囲を基幹系の例で解説しています。 - [システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準を解説](https://www.issoh.co.jp/column/details/15261/)：ハイパーケアの前段にあたる移行全体の進め方を確認できます。 - [総合テスト（システムテスト）とは？結合テストとの境目と観点・発注者が見る成果物](https://www.issoh.co.jp/column/details/19778/)：稼働後の不具合を減らすために稼働前のテストで確認する観点です。 - [システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説](https://www.issoh.co.jp/column/details/13132/)：ハイパーケアが開発工程全体のどこに位置するかを確認できます。 --- 出典: [ハイパーケアとは？本番稼働直後の体制・期間・終了基準と運用保守への引継ぎ]()（株式会社一創）