LASSIC Media らしくメディア

システムを開発する際、外部の決済サービスや推奨表示機能など、一部が停止しただけでサイト全体やアプリ全体が使えなくなってしまうケースがあります。発注担当者やプロジェクトマネージャーにとって悩ましいのは、「一部の不具合が、なぜ全体停止につながるのか」という点でしょう。どこまでの機能を止めてよいかを整理しないまま開発を進めると、思わぬ形で事業影響が広がりかねません。障害はゼロにできない前提に立ち、止まったときにどう振る舞うかを設計しておく発想が求められています。

縮退運転は、こうした一部障害の影響を切り離し、中核機能を動かし続けるための設計の考え方です。この記事では、その定義や必要性、実現の進め方、発注・レビューで押さえておきたい点を整理します。なお、これを支える個別の技術手段であるサーキットブレーカーやフォールバックの詳細は、別記事で扱う範囲です。開発会社に依頼する前に、発注者側として押さえておきたい判断軸を中心にまとめました。

縮退運転とは、機能を絞って動き続ける設計

縮退運転とは、システムの一部で障害が起きても、全体を止めずに、機能を絞った状態で動き続けられるようにする設計の考え方です。

対義になるのが、部品が一つでも壊れるとシステム全体が停止してしまう、オールオアナッシング（全か無か）型の設計です。この型では、周辺機能の不具合が中核機能まで巻き込み、サービス全体が止まってしまいます。

たとえば、アクセスログの記録処理が失敗しただけで、ログ出力の完了を待つ実装のせいで画面表示自体がエラーになる、という設計はオールオアナッシング型の典型です。ログの記録は本来、購入や申し込みといった中核機能の成否を左右するものではありません。

フォールトトレランス（耐障害性）という近い言葉もありますが、意味合いは異なります。Wikipediaの解説では、フォールトトレランスは性能低下を伴わずに障害へ対応する能力とされています^*1。そのうえで、性能の低下を受け入れながら動作を続けるレジリエンス（回復力）の一形態として、縮退運転が位置づけられています^*1。

Wikipediaの縮退運転の項目でも、いくつかの例が挙げられています。電力供給が絶たれた建物が、照明を弱めた状態で稼働し続ける例です。通信帯域が不足した際に、動画配信を低解像度へ切り替える例も紹介されています^*2。いずれも、部分的な機能低下と引き換えに、全体の停止を避けているところが共通点です。

これらの例に共通するのは、「性能や見た目の質を落としてでも、機能そのものは提供し続ける」という優先順位です。システム開発における縮退運転も、根っこにある考え方は同じといえるでしょう。

実務でよくある誤解は、「システムを堅牢にする」ことと「一つも壊れないようにする」ことを同じ意味で捉えてしまう点です。単一の処理の中に中核機能と非中核機能を分けずに詰め込んだ設計では、片方の不具合がもう片方にそのまま波及します。あらかじめ処理を分け、境界を引いておくことが、縮退運転を成り立たせる前提になります。

発注担当者やプロジェクトマネージャーが、実装の細部まで把握する必要はありません。ただ、「この機能が止まったとき、他の機能も道連れになるのか」を要件定義やレビューの場で確認する視点を持っておくと、開発会社との会話の質が変わってきます。

クラウド上の複数サービスを組み合わせてシステムを組む構成が一般的になった今、外部依存を一切持たないシステムはほとんど見当たりません。だからこそ、外部依存が壊れることを前提に、どこまで動き続けられるようにするかを、企画・要件定義の段階から織り込んでおく発想が要ります。

全停止型との比較で見る縮退運転の必要性

システム開発の発注では、外部の決済サービスや推奨表示API、在庫連携サービスなど、複数の外部依存を組み合わせる場面が増えています。これらの一部が停止しただけで購入処理まで止まってしまうと、事業への影響は小さくありません。

外部依存には、決済代行・配送状況照会・チャットサポート・レコメンドエンジン・地図表示など、種類がいくつもあります。これらを同列に扱い、一つでも不調になった時点でシステム全体をエラー画面に切り替える設計は、実装としては単純です。ただし、その単純さの代償として、事業の中核である受発注や問い合わせの受付までが止まってしまう恐れがあります。

たとえば、推奨表示のAPIが応答遅延を起こしているだけだとします。その遅延が購入ボタンの表示処理まで巻き込んでしまう実装では、外部要因ひとつでカートに商品を入れられなくなるでしょう。中核機能と非中核機能の呼び出しを分離しておけば、推奨表示側の不調が購入導線まで波及することを防げます。

Microsoft Learnのアーキテクチャガイドは、信頼性を高める設計原則の一つを挙げています。ワークロードをフォールトトレラントにし、緩やかに縮退させることです^*3。同ガイドは具体例も示しています。決済ゲートウェイが停止していても、キャッシュしたデータを使えばカートの保存や、後日の購入完了までは実現できるという内容です^*3。

全停止型と縮退運転型では、利用者への影響・復旧までの時間・設計や実装のコストに差が出ます。下の表で整理します。

全停止型は実装がシンプルに済む一方、障害の影響範囲を絞れません。縮退運転型は設計・実装の手間が増えますが、事業影響を機能単位で抑えられる点が利点になります。どちらを選ぶかは、対象システムが止まった場合の事業影響の大きさをもとに判断するのが現実的でしょう。

受注のピーク時間帯に決済サービスが不調になった場合を考えてみます。全停止型であれば、その時間帯の注文をまるごと取りこぼしてしまいます。縮退運転型であれば、カートの保存や後払いへの案内など、代替の導線を残せるかどうかで、機会損失の規模は変わってくるでしょう。

すべての機能に縮退運転を用意する必要はありません。売上や契約に直結せず、代替の導線も用意しにくい機能から優先的に検討し、投資に見合う範囲を見極めることが実務上の落としどころになります。

機能の重要度分けとフォールバックで縮退運転を組み立てる

縮退運転を組み立てる出発点は、機能を重要度で仕分けることです。購入や申し込みなど事業の根幹に関わる中核機能と、推奨表示やレビュー欄のような、止まっても事業を継続できる非中核機能を分けて考えます。

中核機能と非中核機能の線引きを先に決める

線引きの基準は、「その機能が止まったときに、売上や契約締結そのものが止まるかどうか」です。購入・決済・申し込みフォームの送信などは中核機能に、レコメンド・レビュー・アクセスランキングなどは非中核機能に分類されることが多いでしょう。

この分類は開発チームだけで決めきれるものではありません。業務側の担当者を交え、機能ごとに「止まったときの影響」を洗い出したうえで線を引くことが、後々の手戻りを防ぐ近道なのです。分類の結果は一覧表にまとめ、開発の途中で機能が追加されるたびに更新していく運用にしておくと、線引きが形骸化しません。

フォールバックの実装パターンをそろえる

非中核機能に障害が起きた場合は、一時的に非表示にするか、簡易な表示へ切り替えます。中核機能については、フォールバック（呼び出し先が使えないときに、代わりの処理や表示に切り替える仕組み）を用意します。キャッシュや既定値で代替し、依存先が止まっていても処理を続けられるようにするのがねらいです。

フォールバックの中身は機能によってさまざまです。直近のキャッシュ値を表示する、あらかじめ決めた既定値に切り替える、処理を一時的にキューへ積んで後から再実行する、といった手段が組み合わせて使われます。どの手段を選ぶかは、多少古いデータでも表示してよいか、常に最新の値でなければ意味がないかという、データの性質によって変わってきます。

負荷が急増した場面でも機能を絞る

負荷が急増した場面でも、同じ考え方が使えます。Googleが公開しているSRE（サイト信頼性エンジニアリング）の解説書は、負荷が高まった際に処理量を減らすロードシェディング（負荷遮断）を紹介しています。縮退運転は、これを一段進めた対応です^*4。検索機能を例に、ディスク上の全データではなく、メモリ上のキャッシュだけを検索対象にする、という縮退のさせ方を紹介しています^*4。同書は、縮退運転が発動する頻度は低く抑えるべきだと述べています。発動条件となる指標（CPU使用率・遅延・キューの長さなど）をあらかじめ決めておく重要性にも触れています^*4。

下の表は、発動条件の指標と縮退運転での対応の組み合わせ例です。

呼び出し先の障害を検知して、呼び出し自体を一時的に遮断するサーキットブレーカーは、この仕組みを支える代表的な実装手段の一つです。仕組みの詳細は個別記事に譲りますが、縮退運転を組み立てる際の部品の一つとして押さえておくとよいでしょう。

Web画面の作り方にも通じる考え方

Web画面の作り方にも、同じ発想が使われています。MDN Web Docsは、縮退運転という設計方針を説明しています。最新のブラウザでは高度な体験を提供しつつ、古いブラウザでも欠かせない内容と機能を保てるようにする、という考え方です^*5。地図アプリで、詳細な地図タイルを読み込めない場合に簡易な表示へ切り替えるのも、同じ考え方の応用といえるでしょう。

ここまで見てきたように、縮退運転を実現する手段は一つではありません。重要度分け・フォールバック・負荷時の機能制限・サーキットブレーカーといった手段を、対象のシステムに合わせて組み合わせるのが基本です。どの手段をどこまで作り込むかは、次に見る身近な例と、発注段階での優先度づけを通じて具体化していきます。

レコメンド停止でも購入は続く、身近な縮退運転の例

ここまでの整理は、やや抽象的に感じられたかもしれません。日常でよく目にするサービスに置き換えると、縮退運転の考え方はぐっと具体的になります。

ECサイトでレコメンド欄が表示されなくなっても、商品の検索や購入手続きが続けられる、という状態は縮退運転の分かりやすい例です。推奨表示の裏側にある解析基盤が止まっていても、購入という中核機能には影響が及びません。

地図アプリでも、身近な例が見られます。通信状況が悪い場面や、地図タイルの配信元に不調がある場面では、詳細な地図の代わりに簡易な地図やテキストの案内へ切り替わることがあります。

業務システムでも同様の場面があります。検索機能の高度な絞り込み条件が一時的に使えなくても、基本的なキーワード検索だけは続けられる、という状態にしておけば、業務そのものは止まりません。チャットサポートが不調な間だけ問い合わせフォームへ案内する、という切り替えも、考え方は同じです。

問い合わせフォームでも、同じ発想が使えます。添付ファイルのアップロード機能だけが一時的に不調でも、テキストによる問い合わせ自体は送信できれば、窓口としての機能は保たれます。周辺機能ごとに影響を閉じ込める発想は、業種を問わず応用できるでしょう。

動画配信サービスで、回線が混み合っている際に高画質版の代わりに低画質版を配信する挙動も、同じ発想に基づきます^*2。画質を落としてでも視聴を続けられるようにする判断は、配信自体を止めてしまう判断より、利用者にとって受け入れやすいものといえます。

これらの例に共通するのは、「利用者が本来やりたかったこと」だけは最後まで通す、という優先順位の付け方です。周辺の演出や補助的な機能から先に手放していく発想は、次に見る発注段階での優先度づけにも、そのままつながります。

発注・レビューで握るべき優先度と復旧の考え方

縮退運転を前提にした開発では、発注段階での合意事項が、その後の品質を大きく左右します。押さえておきたい観点を四つに分けて整理します。

外部依存を一覧化してから設計に入る

まず、システムがどの外部サービスや外部APIに依存しているかを一覧にすることが出発点です。決済・認証・在庫・配送・分析・通知など、依存先が思いのほか多いことに気付くケースも珍しくありません。一覧がないまま設計を進めると、後から中核機能に紛れ込んでいた外部依存が発覚し、手戻りにつながります。

一覧を作る際は、依存先ごとに「止まったときの影響」と「縮退運転での対応方針」を並べて整理すると、レビューの場でも合意が取りやすくなります。代表的な例を挙げます。

この一覧は、開発が進んでから作るのではなく、要件定義の初期段階で仮のものを作っておくと効果的です。後から依存先が増えるたびに更新していけば、システムの全体像を把握できる状態を保てます。

止めてよい機能と、死守する機能の優先度を合意する

どの機能を止めてよく、どれを止めてはいけないかは、発注者側の事業判断が要る部分です。開発会社に丸投げせず、業務への影響度をもとに機能一覧へ優先度を付け、レビューの場で合意しておくことが土台になります。

劣化時の表示・通知の仕方を決める

Microsoft Learnのガイドも、縮退運転に切り替わった際は、利用者に何が使えて何が変わったかを伝える通知の仕組みを備えるよう勧めています^*3。表示を黙って消すのではなく、「一部機能を停止中です」といった案内を添えるだけで、問い合わせの件数は抑えられるでしょう。

この一連の設計を内製で担うには、いくつかの専門知識と役割が必要になります。主なものを挙げます。

• 依存先ごとの障害検知（監視・アラートの設計）
• フォールバック処理の実装（キャッシュ・既定値・キュー投入などの選定）
• 縮退時に利用者へ見せる画面・通知文言の設計
• 復旧判定と切り戻しの運用設計

これらを一人の担当者がすべて兼ねる体制では、着手できる範囲がどうしても限られます。専門パートナーに委ねる場合との差は、この一連の設計を最初から役割分担して作り込めるかどうかに表れるでしょう。

復旧の考え方をあらかじめ決めておく

縮退運転から通常運転へどう戻すか、その判断基準や手順もレビューで確認しておきたい点です。自動で復帰させるのか、人が確認してから切り戻すのかによって、監視体制や運用の設計も変わってきます。

復旧を急ぐあまり、依存先の状態を十分に確認しないまま通常運転へ戻すと、同じ障害が再発するおそれがあります。切り戻し前に何を確認するかを運用手順書に落とし込んでおくと、対応する担当者が変わっても手順がぶれません。

外部依存の一覧化、優先度の合意、通知の設計、復旧の判断基準という四項目は、開発が始まる前のレビューで詰めておくほど、後工程での手戻りが小さくなります。仕様書に落とし込む段階で、一つずつ確認しておくとよいでしょう。

まとめ

ここまで、縮退運転の定義から、実現の進め方、発注・レビューで押さえておきたい点までを整理してきました。要点を振り返ります。

• 縮退運転は、一部の障害があっても、機能を絞って動き続けるための設計の考え方である。
• 全か無かで止まるオールオアナッシング型と比べ、利用者への影響と復旧までの負担を小さく抑えられる。
• 機能の重要度分けと、キャッシュや既定値によるフォールバックの用意が、実現の骨格になる。
• 負荷急増時の機能制限やサーキットブレーカーなどの個別の実装手段は、この考え方を支える部品として組み合わせて使う。
• 発注段階では、外部依存の一覧化、止めてよい機能の優先度、劣化時の通知、復旧の判断基準を合意しておくことが欠かせない。

よくある質問

縮退運転とフォールトトレランスは、何が違いますか。

フォールトトレランスは、障害があっても性能を落とさずに動作し続ける能力を指します。一方で縮退運転は、性能や機能の一部低下を受け入れながら動作を続ける考え方です^*1。どちらも障害への備えですが、性能低下を許容するかどうかに違いがあります。フォールトトレランスは実現コストが高くなりやすく、対象を絞って採用されることが多い手段でしょう。

サーキットブレーカーとは、どんな関係にありますか。

サーキットブレーカーは、障害の起きた呼び出し先への通信を一時的に遮断する個別の仕組みです。縮退運転を実現するための部品の一つとして使われますが、仕組み自体は別のテーマになるため、詳細は別記事で扱います。フォールバックの処理と組み合わせて使われることが多い点だけ、ここでは押さえておいてください。

縮退運転を導入すると、開発コストは増えますか。

機能の重要度分けやフォールバックの設計・実装が加わるため、全停止型の設計より工数は増える傾向にあります。ただし、外部サービス障害のたびにシステム全体が止まるリスクや対応コストと比べて、どちらが事業にとって望ましいかを判断材料にするとよいでしょう。すべての機能を対象にする必要はなく、影響の大きい機能から段階的に対応範囲を広げる進め方も現実的です。

どの機能を停止対象にするか、判断基準はありますか。

業務上どれだけ影響が出るかという事業側の判断が中心になります。購入や申し込みのように売上へ直結する機能は、中核機能として死守します。レコメンドや関連コンテンツのような周辺機能は、停止や簡易表示の対象として整理するのが一般的な進め方です。判断に迷う機能は、代替の導線が用意できるかどうかを基準にすると整理しやすいでしょう。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• Wikipedia「Fault tolerance」
• Wikipedia「Graceful degradation」
• Microsoft Learn「Architecture strategies for self-healing and self-preservation」（Azure Well-Architected Framework）
• Google「Addressing Cascading Failures」（Site Reliability Engineering）
• MDN Web Docs「Graceful degradation」