Kubernetesの運用案件では、参画してすぐに聞かれることが一つあります。止まったときに、どこまで自分が対応するのかという線引きです。線引きが曖昧なまま稼働を始めると、深夜の連絡や範囲外の作業まで抱え込みやすくなります。この記事では、公的な方針文書が示す運用の観点をもとに、持ち場の決め方を順番に整理します。

1. 「止まった」と分かる仕組みがあるか

気づきの基準を先に持っておく

案件に参画する前に確かめておきたいのは、止まったことに気づく仕組みがあるかどうかです。定量的な計測とダッシュボードによる状況の可視化が、運用の土台として挙げられています¹。数字で見える状態がなければ、気づきそのものが遅れてしまいます。

気づきの基準が無いまま稼働を始めると、連絡を受けてから初めて状況を把握する流れになりがちです。ダッシュボードで平常時の値を把握しておけば、変化が起きた瞬間を先に捉えられます。参画時にこの土台があるかを確かめておくと、対応の負担を見通しやすくなります。

参画前の面談では、気づく仕組みがどこまで整っているかが話題になる場面があります。ダッシュボードの有無だけでなく、どの数値を基準にしているかまで確かめておくと、稼働後の認識のずれを防ぎやすくなります。

監視や運用の経験がある場合は、平常時の値を把握してきた経験をそのまま気づきの基準の確認に使えます。経験がまだ少ない場合でも、確認する項目を先に決めておくことが土台になります。

確認する基準が言語化されている案件では、日々の稼働の中でその基準に沿って状況を追うだけで済みます。基準が無い案件では、都度何を確認するかを相談しながら進めることになります。

気づいてからの流れを分けておく

気づいたあとの流れも、あらかじめ分けておく価値があります。気づく・切り分ける・戻す・直すという順番で捉えると、今どの段階にいるかが分かりやすくなります。

図の作成：Remogu編集部。止まったときに追う対応の順番を整理したもので、統計データではありません

切り分けの段階で確かめるのは、自分の持ち場で起きていることなのか、それとも別の要因なのかという点です。ここを飛ばして戻す作業に入ると、同じ状態を繰り返すことにつながります。

戻す段階は、通常の状態へ動かす作業です。直す段階は、原因を確かめて再発を防ぐ作業で、戻すこととは分けて考えます。二つを同じ作業として扱うと、原因が残ったまま稼働を続けることになります。

気づく仕組みと、気づいてからの順番。この二つが揃っているかどうかで、止まったときの負担の感じ方は変わります。次の章では、負荷そのものの跳ね方が構成によってどう変わるかを見ていきます。

2. 負荷の跳ね方は構成で決まる

ピーク時を想定した構成の特徴

負荷の跳ね方は、構成そのもので決まります。当初からピーク時を想定する構成から、オートスケールで綿密な見積りが要らない無駄のない構成へと変わってきています²。始める前提が変わりつつあります。

ピーク時を想定した構成では、上限に合わせた大きな枠を常に確保しておく考え方になります。ピーク時を想定した大きなリソースを、通常時にも使い続けることになりやすい構成です³。

オートスケールで整える構成の特徴

オートスケールで整える構成では、需要に応じて枠を増やしたり減らしたりします。常に大きな枠を確保しておく必要が薄れ、綿密な当初見積りに時間をかけずに済む構成に近づきます²。

出典：デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」をもとに作成

二つの構成では、確認する範囲そのものも変わります。上限に達していないかを見る運用から、増減の挙動が正しく動くかを見る運用へと重心が移ります。持ち場を決めるときは、どちらの構成を前提にしているかを最初に確かめておくと見通しが立ちます。

参画前には、現在の構成がどちらに近いのかを確認しておく場面があります。ピーク時を想定した構成のまま稼働しているのか、オートスケールへ移行している途中なのかで、日々の確認作業の量は変わります。

構成を変える途中の案件では、両方の考え方が混在する期間があります。上限を見る確認と、増減の挙動を見る確認を並行して進める必要があるため、どちらの段階にあるかを最初に共有しておくと動きやすくなります。

構成の違いは、稼働中に発生する連絡の量にも表れます。上限に近づいたときに連絡が来る運用と、増減の挙動そのものを定期的に確認する運用とでは、日々の確認の頻度が変わります。

表で見る二つの構成の違い

ここまでの内容を、構成ごとの観点で整理します。リソースの持ち方、見積りの手間、確認する範囲という三つの観点で並べると、ピーク時を想定した構成とオートスケールで整える構成の違いが見えやすくなります。参画前にどちらの構成かを確かめておくと、稼働後に確認する範囲の見通しが立てやすくなります。

観点	ピーク時を想定した構成	オートスケールで整える構成
リソースの持ち方	上限に合わせた大きな枠を常に確保する	需要に応じて枠を増やしたり減らしたりする
見積りの手間	想定される最大値を綿密に見積もっておく	綿密な当初見積りが不要になり、枠が無駄なく整う
確認する範囲	上限に達していないかを見ている	増減の挙動そのものが正しく動くかを見ている

どちらの構成であっても、確認する範囲を事前に把握しておくことが、稼働後の負担を左右します。次の章では、更新のたびに確かめる範囲について見ていきます。

3. 更新のたびに確かめる範囲

提供側の確認テストが最適化されていく範囲

更新の場面でまず押さえておきたいのは、マネージドサービスの更新時に、確認テストを最適化することが挙げられている点です⁴。提供側の仕組みが整うほど、確認にかける手間の質が変わっていきます。

とはいえ、確認テストが最適化されるからといって、確認そのものが不要になるわけではありません。最適化は、確認の手間を減らす方向の変化として捉えておくと実感に近くなります。

継続的に対応が必要になる範囲

更新への向き合い方としては、継続的なアップデートへの対応が挙げられています⁵。一度対応して終わりではなく、繰り返し発生する作業として位置づけられている点が特徴です。

継続的な対応が前提になると、更新のたびに確かめる範囲を毎回一から洗い出す必要は薄れます。あらかじめ確認する項目を決めておけば、更新のたびに同じ手順で進められます。

参画時には、確認テストの範囲がどこまで提供側で完結しているかを尋ねられる場面があります。提供側の範囲と、運用として確かめる範囲の境目を把握しておくと、更新のたびに何を担うかがはっきりします。

確認する範囲があらかじめ言語化されていない案件では、更新のたびに毎回相談が必要になります。過去に確認項目を整理した経験があれば、その進め方をそのまま持ち場の整理に使えます。

確認する範囲を最初にリスト化しておく案件では、更新のたびに同じチェックを繰り返すだけで進められます。リスト化されていない案件では、更新のたびに範囲を相談する時間が必要になります。

確認する範囲を共有する際は、更新の連絡が来るタイミングも合わせて確認しておくと、対応の準備がしやすくなります。

表で見る更新の位置づけ

更新に関わる二つの要素を、位置づけ・頻度・求められる姿勢という観点で並べます。マネージドサービス側の確認テストと、運用として継続的に対応する範囲は役割が異なるため、分けて捉えておくと更新のたびに確かめる範囲が整理しやすくなります。

観点	マネージドサービス側の更新	運用として確かめる範囲
位置づけ	提供側の確認テストが最適化されていく対象	継続的なアップデートへの対応が求められる対象
頻度	更新のたびに発生する	日常的に発生する
求められる姿勢	更新の内容を把握しておく	通常業務の一部として組み込む

更新は、単発のイベントではなく繰り返し発生する作業です。次の章では、この継続的な対応が日常の作業としてどのように位置づけられるかを見ていきます。

4. 更新は日常の作業になる

通常のアップデートとして扱う

更新への対応は、特別なイベントではなく、通常のアップデートと捉えて日常的に対応していく必要があります⁶。身構え方を変えるだけで、更新の受け止め方は変わります。

日常の作業として位置づけると、更新のたびに大きく構えずに済みます。継続的なアップデートへの対応という考え方⁵と合わせると、更新は稼働の中に組み込まれた作業として見えてきます。

日常に組み込むための考え方

日常に組み込むためには、更新の連絡を受けてから動くのではなく、更新が来る前提で稼働の予定を組んでおく考え方が助けになります。確認する範囲があらかじめ決まっていれば、更新のたびに動きやすくなります。

日常の作業として組み込む場合、更新の予定をどのタイミングで共有するかも取り決めておく点になります。事前に共有される案件と、都度連絡が来る案件とでは、稼働の組み方が変わります。

更新のたびに新しく手順を考える必要がなければ、稼働の負担は積み重なりにくくなります。確認する項目を一度整理しておく作業は、その後の更新にも使えます。

更新の予定が事前に共有される案件では、稼働の計画に更新作業をあらかじめ組み込めます。都度連絡が来る案件では、通常の作業を止めて対応する場面が増えます。

更新を日常の作業として扱う考え方は、稼働を始めてから急に身につくものではありません。参画前の段階で、更新をどう位置づけている案件かを確かめておくと、稼働開始後の進め方を想像しやすくなります。

更新を日常の作業として扱えるようになると、止まったときに気づく仕組み¹と合わせて、稼働全体の見通しが立てやすくなります。持ち場を決める材料が、少しずつ揃っていきます。

日常の作業として扱う場合と、特別な対応として身構える場合では、更新にかける時間の使い方が変わります。あらかじめ組み込んでおく考え方のほうが、稼働は安定しやすくなります。

更新を日常の作業として位置づけたうえで、次に確かめておきたいのが、使う判断と使わない判断がどこで分かれるかという点です。

5. 使わない判断もある

前提が異なるサービスがある

運用の構成を検討する場面では、使わない判断が出てくるサービスもあります。サーバーの構築を前提とするなど、性質が異なるサービスが挙げられています⁷。

前提が異なるサービスを見分けておくと、構成を決める段階での手戻りを減らせます。使う判断がしやすいサービスと、使わない判断が出てくるサービスを、最初に整理しておく価値があります。

提案が方針に沿っているかを確かめる

事業者からの提案を受け取る場面では、その提案が方針に沿ったものであるかどうかに留意する必要があります⁸。提案の中身をそのまま受け取るのではなく、確かめる姿勢が求められます。

留意する範囲は、導入時だけにとどまりません。使い続ける中でも、提案されている内容が方針に沿っているかを都度確かめておくと、後から前提が崩れる事態を避けやすくなります。

参画前の打ち合わせでは、検討中の構成に、使わない判断が出てくるサービスが含まれていないかを確かめる場面があります。含まれている場合は、代わりにどう構成するかを話し合う必要が出てきます。

提案の確認を都度行う運用では、確認する担当が誰かも取り決めておく点になります。提案を受け取る窓口と、方針への適合を確かめる担当が別であれば、その連携の仕方も持ち場の一部になります。

使わない判断が出てくるサービスを含む提案が出てきた場合、代わりの構成を検討する時間も稼働の一部になります。事前にどちらの構成を選ぶかを共有しておくと、後から手戻りが発生しにくくなります。

表で見る二つの判断の分かれ目

前提となる構成、提案の確認、運用への影響という三つの観点で、使う判断がしやすいサービスと使わない判断が出てくるサービスを並べます。案件で構成を検討する場面では、この分かれ目を先に押さえておくと判断がしやすくなります。

観点	使う判断がしやすいサービス	使わない判断が出てくるサービス
前提となる構成	サーバーの構築を前提としない	サーバーの構築を前提とする
提案の確認	方針に沿っているかを確かめておく	方針に沿っているかを都度確かめる
運用への影響	運用の負担が増えにくい	運用の負担が増えやすい

使う判断と使わない判断の分かれ目が見えてくると、構成そのものへの理解が深まります。次の章では、止まったときの備えがどこまで整っているかを見ていきます。

6. 止まる備えは整っているか

整備の状況を数で見る

止まったときの備えがどこまで整っているかは、調査からも見えてきます。ITのリスク管理と業務継続計画については、全体の5〜6割程度の企業が整備しています¹⁰。

5〜6割程度という水準は、備えが一定程度広がっている一方で、整備の途上にある事業者もあることを示しています。案件に参画する側としても、備えの有無を確かめておく意味があります。

参画前には、業務継続計画がすでに整っている案件なのか、これから整えていく案件なのかを確認しておく場面があります。整っていない案件では、備えを作る作業そのものが持ち場に含まれることがあります。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」、デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」をもとに作成

運用の仕方が備えの効果を左右する

備えを整えるだけでは、効果が十分に表れるとは限りません。運用の仕方が従前のままでは、コスト削減の効果は十分に発現しません⁹。

備えとしての計画と、日々の運用の仕方は別のものとして扱う必要があります。計画があっても、運用が変わらなければ、止まったときの対応にも同じ課題が残ります。

止まったときに気づく仕組み¹と、業務継続の備えは、重なり合う部分があります。どちらも、平常時の運用の仕方を変えることで初めて効果が表れます。

備えを作る経験がある場合は、計画の項目を洗い出した経験をそのまま使えます。経験がまだ少ない場合でも、確認する観点を一つずつ言語化していけば、備えの整理は進められます。

備えを作る作業が持ち場に含まれる案件では、計画の項目を洗い出す期間も稼働のスケジュールに含めておく必要があります。含まれない案件では、既存の計画を確認するだけで済みます。

業務継続計画を確認する場合、更新の頻度や見直しのタイミングも合わせて確認しておくと、備えが形だけで終わっていないかが分かります。

備えが整っているかどうかを確かめることは、持ち場を決めるための材料の一つになります。次の章では、持ち場を決める順番そのものを整理します。

7. 持ち場を決める順番

確認する順番を決めておく

ここまでの内容を踏まえると、持ち場を決める順番が見えてきます。まず、事業者からの提案が方針に沿ったものであるかどうかを確かめます⁸。次に、止まったと気づく仕組みとして、定量的な計測とダッシュボードによる可視化があるかを確認します¹。

図の作成：Remogu編集部。持ち場を決めるまでの確認の順番を整理したもので、統計データではありません

順番を決めておくと、確認が漏れにくくなります。提案の中身を確かめないまま構成を受け入れると、後から前提が崩れたときに気づく仕組みまで揃っていない事態になりかねません。

持ち場を決める順番は、案件ごとに細部が変わります。それでも、提案の確認、可視化の確認、合意という三つの段階を踏むことは、どの案件でも共通の土台になります。

順番のどこかを飛ばして稼働を始めると、後から合意を取り直す作業が発生します。三つの段階を稼働開始前に済ませておくと、その手戻りを避けやすくなります。

合意を作ってから稼働を始める

確認が済んだら、対応する範囲についてクライアントと協議し、合意を作ります。持ち場が曖昧なまま稼働を始めると、範囲外の作業を抱え込みやすくなります。

合意を作ってから稼働を始めれば、止まったときに誰がどこまで動くかが、あらかじめ共有された状態になります。気づく・切り分ける・戻す・直すという順番¹も、合意があってはじめて機能します。

Remoguの案件は90%以上がフルリモート可能です。持ち場についての合意ができていれば、場所を問わず落ち着いて稼働を始めやすくなります。

持ち場を決める順番を押さえたうえで、次によく寄せられる質問をまとめます。

止まったときの対応範囲はどうやって取り決めますか

計測とダッシュボードによる可視化があるかを確かめたうえで¹、気づく・切り分ける・戻す・直すのどこまでを担うかをクライアントと事前に協議します。対応する範囲を先に共有しておくと、連絡が来た場合の動き方も具体的に決めやすくなります。

更新の作業はどのくらいの頻度で発生しますか

継続的なアップデートへの対応が挙げられており⁵、通常のアップデートと捉えて日常的に対応していく考え方が示されています⁶。更新の予定をいつ共有するかも、あわせて取り決めておく点になります。

使わない判断をするサービスがあるのはなぜですか

サーバーの構築を前提とするなど、使わない判断が出てくるサービスもあるためです⁷。提案が方針に沿っているかを都度確かめる姿勢が欠かせません⁸。含まれる場合は、代わりの構成をどう組むかを事業者側とすり合わせます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見えるようにする（2026年・2026年8月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見積りの前提（2026年・2026年8月確認）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」常時の余裕（2026年・2026年8月確認）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」テストの費用（2026年・2026年8月確認）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」終わらない作業（2026年・2026年8月確認）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」更新の捉え方（2026年・2026年8月確認）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」選ばない判断（2026年・2026年8月確認）
＊8 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」提案を読む（2026年・2026年8月確認）
＊9 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」刷新の限界（2026年・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」止まる備え（2025年4月・2026年8月確認）