外部サービスの1つが遅くなっただけで、サービス全体のレスポンスが悪化して実質的に止まってしまった。障害の振り返り会でベンダーから「サーキットブレーカーを入れましょう」と提案され、追加見積もりを渡された。けれども、その仕組みが何をするものなのか、そして自社に本当に必要な投資なのかを判断できない。そんな状況に置かれている発注者の方は少なくありません。
難しいのは、この判断が「技術の話」と「お金の話」の両方にまたがっている点です。ベンダーの説明は Resilience4j や Istio といった製品名と設定パラメータの話に流れがちで、事業側が知りたい「どのくらいの効果があるのか」「入れなかったら何が起きるのか」には直接答えていないことがあります。かといって金額だけを見て値切っても、次の障害を防げるかどうかは分かりません。
この状況を抜け出す近道は、サーキットブレーカーの仕組みを完璧に理解することではありません。「自社のシステムはこの対策の効果が出る構成なのか」を判断する物差しを持ち、そのうえで要件定義・契約・受入テスト・運用報告という発注プロセスの各段階で何を確認すればよいかを知ることです。物差しさえあれば、提案の妥当性は自分で検証できます。
本記事では、サーキットブレーカーが何を遮断する仕組みなのかを整理したうえで、3つの状態と設定値が利用者の体験にどう影響するか、リトライやフォールバックとの関係、導入効果が大きい構成と過剰投資になりやすい構成の見分け方、そして発注時に確認すべきポイントを解説します。実装コードには踏み込まず、発注者が上長やベンダーに対して自分の言葉で説明できる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
サーキットブレーカーとは？マイクロサービスの障害連鎖を止める仕組み
ソフトウェア設計におけるサーキットブレーカーとは、外部のサービスやシステムへの呼び出しが繰り返し失敗しているときに、その呼び出しを一時的に遮断して、即座にエラーや代替の応答を返す仕組みのことです。呼び出し先が復旧する見込みが立つまで通信を止めることで、応答を待ち続けるリクエストがシステムの資源を食いつぶし、無関係な機能まで巻き込んで停止する事態を防ぎます。
Microsoft の Azure Architecture Center では、このパターンを「障害がしきい値に達した後、失敗する可能性のある操作を繰り返し再試行するのではなく、リモートサービスまたはリソースへのアクセスを一時的にブロックする」設計と定義しています（サーキット ブレーカー パターン - Azure Architecture Center）。ポイントは「一時的にブロックする」という部分です。永久に切り離すのではなく、相手が回復したら自動的に通信を再開するところまでが仕組みに含まれています。
サーキットブレーカーが遮断するのは「電気」ではなく「呼び出し」
サーキットブレーカーという言葉は、少なくとも3つの分野で使われています。1つ目は住宅や工場の分電盤に付いている電気設備の遮断器、2つ目は株式市場で価格が急変したときに取引を一時停止させる制度、そして3つ目が本記事で扱うソフトウェア設計のパターンです。検索したときにまったく違う分野の解説が混ざって出てくるのは、この同名性が理由です。
3つに共通しているのは「過負荷や異常を検知したら、いったん回路を切って全体を守る」という考え方です。分電盤のブレーカーは、1つの部屋でショートが起きたときに家全体が焼けないよう、その系統だけを落とします。ソフトウェアのサーキットブレーカーも同じで、特定の外部連携が不調になったとき、その呼び出しだけを落として他の機能を生かします。守る対象が電気配線ではなく「システム間の呼び出し」に置き換わっただけだと考えると理解しやすくなります。
カスケード障害とは？外部連携の遅延がシステム全体の停止に広がる流れ
外部 API が1つ遅くなっただけで、なぜサービス全体が重くなるのでしょうか。この連鎖のことをカスケード障害と呼びます。仕組みはおおむね次の順に進みます。
- 外部サービスが応答しなくなる、または極端に遅くなる
- 自社システムはタイムアウトになるまで応答を待ち続ける（例: 30 秒）
- 待っている間、そのリクエストはメモリ・スレッド・データベース接続といった資源を握り続ける
- 同じ外部サービスを呼ぶリクエストが次々と積み上がり、待機中のリクエストが資源を占有する
- 資源が枯渇し、外部サービスとまったく関係のない画面や機能まで応答できなくなる
Azure Architecture Center も、タイムアウト期間が経過するまで同じ操作への同時要求がブロックされ、これらのブロックされた要求がメモリ・スレッド・データベース接続といった重要なシステム資源を保持し続けること、そしてそれがリソースを使い果たして無関係な部分の障害につながることを、このパターンが解決すべき問題として挙げています。
つまり「先日の障害は外部サービスのせいなのか、自社システムの作りの問題なのか」という問いへの答えは、多くの場合その両方です。きっかけは外部サービスの不調でも、それがサービス全体の停止にまで広がるかどうかは自社システムの作りに左右されます。逆に言えば、外部サービスの品質をコントロールできなくても、被害の広がり方は設計で緩和できるということです。
フェイルファストという考え方
サーキットブレーカーの背後にあるのは、フェイルファスト（早く失敗させる）という原則です。直感的には「エラーを返すより、粘って成功させたほうが親切」に思えます。しかし復旧の見込みがない相手を待ち続けると、待機中のリクエストが資源を占有し、被害が拡大していきます。
30 秒待たされた末にエラー画面が出るのと、1 秒で「この機能は現在ご利用いただけません」と表示されるのとでは、利用者の体験も、システムへの負荷もまったく異なります。前者は他の機能まで巻き込みますが、後者はその機能だけの停止で済みます。「早く諦める」ことは手抜きではなく、全体を守り、復旧を早めるための積極的な設計判断だと捉えてください。
サーキットブレーカーの3つの状態（Closed・Open・Half-Open）と切り替わる条件
サーキットブレーカーは、Closed・Open・Half-Open という3つの状態を行き来する仕組みとして実装されます。この3つは技術者どうしの会話に頻出しますが、発注者にとっても「どのくらいの時間、どの機能が使えなくなるのか」を理解するために押さえておく価値があります。
3つの状態の役割と、状態が切り替わる条件
状態 | 何が起きているか | 次の状態へ切り替わる条件 |
|---|---|---|
Closed（通常） | 呼び出しは普段どおり外部サービスへ届く。裏側で失敗回数を数えている | 一定時間内の失敗回数・失敗率がしきい値を超えると Open へ |
Open（遮断中） | 呼び出しは外部サービスに届かず、即座にエラーまたは代替応答を返す | 待機時間（タイムアウト）が経過すると Half-Open へ |
Half-Open（試験再開） | 限られた数のリクエストだけを外部サービスに通し、様子を見る | 成功が続けば Closed へ復帰。失敗すれば Open へ戻り、待機時間を再スタート |
Half-Open という中間状態が存在する理由は、復旧しかけた相手に一気にリクエストが押し寄せて再び倒れることを防ぐためです。Azure Architecture Center も、サービスが復旧した直後は限られた量の要求しか処理できない場合があり、大量の作業が発生するとサービスが再び失敗する可能性があると説明しています。「様子を見ながら少しずつ戻す」という段階を挟むことで、復旧の失敗を減らしています。
しきい値・待機時間の設定がユーザー体験に与える影響
3つの状態の動きを決めるのは、大きく2つの設定値です。1つは「何回、あるいは何％失敗したら遮断するか」というしきい値、もう1つは「遮断してから何秒後に試験再開するか」という待機時間です。
この2つは技術パラメータの顔をしていますが、実際に決めているのは利用者の体験です。
- しきい値が緩すぎる場合: なかなか遮断されず、外部サービスの不調がそのままシステム全体に伝わります。せっかく導入しても、障害時にほとんど効きません
- しきい値が厳しすぎる場合: 一時的な失敗が数回あっただけで遮断され、外部サービスが正常なのに機能が使えない時間が発生します
- 待機時間が短すぎる場合: 復旧していない相手に何度も試験的なリクエストが飛び、遮断と再開を短周期で繰り返します
- 待機時間が長すぎる場合: 外部サービスがすでに回復しているのに、機能が停止したままの時間が延びます
どの値が正解かは、その機能が止まったときの業務影響によって変わります。たとえば決済機能なら数十秒の停止も重大ですが、レコメンド表示なら数分止まっても事業インパクトは限定的です。設定値はベンダーが技術的な相場観で仮置きしたうえで、事業側が「この機能はこのくらいまでなら止まってよい」という許容度を伝えて擦り合わせるべき論点だと考えてください。打ち合わせでは「しきい値と待機時間はどう設定する想定ですか」「その設定だと利用者から見て最大何秒くらい機能が止まりますか」と質問すると、会話が具体的になります。
遮断が起きたことを誰がどう知るか
見落とされやすいのが、遮断が発生したことを人間が知る手段です。サーキットブレーカーは自動で遮断し、自動で復帰します。うまく機能していれば大きな障害にはならないため、通知の仕組みがなければ「今日、決済連携が5分間遮断されていた」という事実が誰にも共有されないまま流れていきます。
Azure Architecture Center も、サーキットブレーカーが状態を変更するたびにイベントを発生させることで、保護対象コンポーネントの健全性を監視したり、Open 状態に切り替わったときに管理者へ警告したりできると述べています。導入を検討する段階から「遮断が起きたら誰にどう通知されるのか」をセットで確認しておくことが、後述する運用フェーズの確認点にもつながります。
リトライ・タイムアウト・フォールバックとの違いと組み合わせ方
サーキットブレーカーの説明を受けたとき、「失敗したらもう一度試せばよいのでは」と感じる方は多いはずです。この疑問に答えるには、周辺の対策との役割分担を整理する必要があります。ここを理解しておくと、見積書に並ぶ複数の項目が「何のセットなのか」を読み解けるようになります。
リトライとサーキットブレーカーの違い
リトライ（再試行）とサーキットブレーカーは、目的が異なります。
項目 | リトライ | サーキットブレーカー |
|---|---|---|
想定する障害 | 一時的で、すぐ直る障害（瞬間的なネットワークの揺らぎなど） | すぐには直らない障害（相手サービスの停止・過負荷など） |
動作 | もう一度呼び出して成功を狙う | 呼び出し自体をやめて即座に応答を返す |
効果が出る場面 | 数回試せば成功する見込みがあるとき | 何度試しても当面成功しないとき |
Azure Architecture Center も、再試行パターンは「最終的に成功することを期待して操作を再試行する」ものであるのに対し、サーキットブレーカーパターンは「失敗する可能性のある操作を実行できなくする」ものであり、目的が異なると明記しています。そのうえで、両者は組み合わせて使えるとしています。実際の設計では「まずリトライで一時的な障害を吸収し、それでも失敗が続くならサーキットブレーカーで遮断する」という二段構えが一般的です。したがって見積書にリトライ処理とサーキットブレーカーが並んでいても、それは重複ではありません。
リトライだけに頼ると障害が長引く理由
リトライだけで対処しようとすると、かえって障害を長引かせることがあります。過負荷で倒れかけているサービスに対して、多数の利用者からのリクエストが一斉に再試行されると、相手に届く負荷は通常時の何倍にもなります。復旧しかけたところへ再び大量のリクエストが押し寄せ、また倒れる。この悪循環はリトライストームと呼ばれます。
Azure Architecture Center も、サーキットブレーカーを使うことで「エラー時の再試行アプローチが回避され、依存関係の復旧中にリソースが過剰に使用される」事態を防げると整理しています。相手の復旧を邪魔しないという観点は、外部の SaaS や決済代行など、自社でコントロールできないサービスに依存している場合ほど重要になります。
なお、タイムアウトの設定も無関係ではありません。外部サービスへのタイムアウトが極端に長いと、失敗と判定されるまでの間にスレッドが長時間ブロックされ、サーキットブレーカーが遮断を判断する前に資源が枯渇する可能性があります。「サーキットブレーカーを入れたのでタイムアウトはこのままでよい」とはならない点に注意してください。
フォールバックで「何を返すか」は業務側が決める
遮断している間、利用者には何を見せるのでしょうか。この代替応答をフォールバックと呼びます。ここは技術判断のように見えて、実際には事業判断が求められる領域です。主な選択肢は次のとおりです。
フォールバックの内容 | 向いている機能の例 | 注意点 |
|---|---|---|
直前に取得したデータ（キャッシュ）を表示する | 商品一覧、店舗情報、記事のレコメンド | 情報の鮮度が落ちる。価格・在庫・残高など、古い値を見せると実害が出る情報には使えない |
その機能だけを一時的に隠す・無効化する | 関連商品の表示、外部レビューの埋め込み | 利用者が「壊れている」と誤解しないよう、表示上の配慮が必要 |
お詫びメッセージを出して再操作を促す | 決済、予約確定、外部システムへの申込 | 文面と、問い合わせ導線の有無を事前に決めておく必要がある |
代替の手段を案内する | 地図表示、外部認証ログイン | 代替手段側の負荷も考慮する |
たとえば決済画面でキャッシュを表示することは、事業上あってはならない選択です。一方で商品レコメンドなら、多少古いデータでも表示されるほうが利用者にとって自然です。この線引きはシステムを作る側だけでは決められません。要件定義の段階で、機能ごとに「遮断中に何を見せるか」を業務側が決めて伝えることが、実効性のある設計につながります。
バルクヘッドで依存先ごとに影響範囲を隔てる
もう1つ押さえておきたいのがバルクヘッド（隔壁）という考え方です。船の船体を隔壁で区切り、浸水を一区画に留める構造から来ています。システムでは、依存先ごとに使える資源（同時接続数やスレッド数）をあらかじめ分けておき、1つの外部サービスの不調が他の処理の資源を食いつぶさないようにします。
Azure Architecture Center も、複数の独立したプロバイダーが存在しうる場合に1種類のリソースへ単一のサーキットブレーカーを使うことへの注意を促しています。健全な依存先まで巻き込んで遮断してしまう設計は、かえって可用性を下げるためです。
こうして並べると分かるとおり、実務では「サーキットブレーカー単体を入れる」のではなく、タイムアウトの見直し・リトライ・フォールバック・バルクヘッド・監視をセットで設計します。見積書に複数の項目が並ぶのは、多くの場合この構造を反映しているためです。
サーキットブレーカーの実装方式（ライブラリ型・インフラ型）と見積もりの読み方
実装の方式は、大きく2つに分けられます。どちらを選ぶかによって、改修の範囲・費用の性質・運用の担い手が変わります。金額の妥当性を判断する際は、まず「どちらの方式を前提とした見積もりなのか」を確認してください。
アプリケーションに組み込む方式（Resilience4j などのライブラリ型）
アプリケーションのプログラム内にライブラリを組み込み、外部サービスを呼び出す処理をサーキットブレーカーで包む方式です。Java では Resilience4j がよく使われ、他の言語にも同種のライブラリが存在します。
かつて広く使われていた Netflix の Hystrix は、現在は新規開発が行われないメンテナンスモードに入っており、公式リポジトリでも積極的な開発は終了したことが案内されています（Netflix/Hystrix）。既存システムで Hystrix が使われている場合、そのまま使い続けるか移行するかは検討事項になります。ベンダー提案に古いライブラリ名が出てきたときは、「現在も保守されているものですか」と確認しておくと安心です。
- 向いている場面: 呼び出しごとに細かく挙動を変えたい、フォールバックの内容を機能ごとに作り込みたい
- 費用の性質: 対象となる呼び出し箇所の数に応じてコードの改修工数が増える。テストも呼び出し箇所ごとに必要
- 運用の担い手: 設定値がアプリケーションの構成に含まれるため、変更のたびにリリース作業が発生する場合がある
インフラ側で挟む方式（Istio・Envoy・API Gateway・マネージドサービス）
アプリケーションのコードを変更せず、通信経路の途中で遮断を行う方式です。Kubernetes 環境で使われるサービスメッシュ（Istio や Envoy）、API Gateway、クラウド事業者が提供するマネージド機能などが該当します。Azure Architecture Center も、サービスメッシュではアプリケーションコードを変更せずにサーキットブレーキングをサポートすることが多いと述べています。
- 向いている場面: 複数のサービスにまとめて適用したい、アプリケーションの改修を最小限にしたい
- 費用の性質: 個々のコード改修は少ない一方、基盤の構築・設定・検証に費用がかかる。すでにサービスメッシュを導入済みなら追加費用は小さい
- 運用の担い手: 設定変更がインフラ側の作業になるため、インフラ運用の体制が必要
前提となる基盤がない状態でインフラ型を選ぶと、サーキットブレーカーのためだけに大がかりな基盤導入が必要になることがあります。提案がインフラ型の場合は、「その基盤は今回のためだけに導入するのか、他の目的にも使うのか」を確認してください。他の目的（トラフィック制御、可観測性の向上など）と共用できるなら、費用の見方も変わります。
見積もりの内訳として確認したい項目
金額の相場観を持たなくても、内訳の構造を見れば提案の質はある程度判断できます。次の項目が漏れていないか、あるいは説明できる形で含まれているかを確認してください。
内訳項目 | 確認したいこと |
|---|---|
対象範囲の設計 | どの外部連携に適用するのか。対象の数が明示されているか |
設定値の設計 | しきい値・待機時間・タイムアウトを誰がどう決めるのか |
フォールバックの実装 | 遮断中に何を返すのか。機能ごとに設計されているか |
テスト | 外部連携を止めた状態での動作確認が工数に含まれているか |
監視・通知の設定 | 遮断の発生をどこで検知し、誰に通知するのか |
ドキュメント・運用手順 | 設定値の変更手順、障害時の対応手順が残るのか |
このうちテストと監視・通知が見積もりから抜けているケースは珍しくありません。この2つが欠けると「入れたはずなのに効いているか分からない」状態に直結するため、内訳に見当たらない場合は必ず確認してください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
サーキットブレーカーが必要なシステム・過剰になるシステムの判断基準
ここが本記事の中心です。サーキットブレーカーは有用な設計パターンですが、あらゆるシステムに必要なわけではありません。導入を見送る判断も、根拠があれば正当な意思決定です。
導入効果が大きい構成の条件
次の項目に多く当てはまるほど、導入効果は大きくなります。自社の構成に照らして数えてみてください。
- 決済・地図・認証・生成 AI・SaaS など、自社でコントロールできない外部サービスへの依存が複数ある
- サービスどうしが相互に呼び出し合う構成になっている（マイクロサービスとモノリスの違いでいうマイクロサービス寄りの構成）
- 依存先の1つが止まっても、他の機能は使えるようにしておきたい業務要件がある（例: レコメンドが止まっても購入はできてほしい）
- 依存先の復旧に時間がかかる、または復旧時間が読めない
- 過去に、特定の連携先の不調がサービス全体の遅延・停止につながった経験がある
- 利用者数が多く、障害時に大量のリクエストが同じ依存先へ集中する
Azure Architecture Center も、このパターンを使う場面として「操作が失敗する可能性が高い場合に、過剰なリモートサービス呼び出しを停止することで連鎖障害を防ぐ必要がある」「低速の依存関係から保護してサービスレベル目標を維持する必要がある」といった状況を挙げています。冒頭で触れた「外部 API の遅延がサービス全体に波及した」という経験は、まさにこの条件に該当します。
過剰設計になりやすい構成の条件
一方、次のような場合は、投資に見合う効果が出にくくなります。
- 外部への依存がほとんどない、あるいは依存先が1つだけの小規模な単一構成のシステム
- 対象がアプリケーション内部の処理（メモリ上のデータ操作など）である。Azure Architecture Center も、ローカルのプライベートリソースへのアクセス管理に使うとオーバーヘッドが増えるだけだとしています
- 既知のリトライで十分で、依存先自体が再試行を前提に設計されている。この場合はサーキットブレーカーが不要な複雑さを持ち込むと指摘されています
- 遮断が解除されるまでの待ち時間が業務上まったく許容できない
- メッセージキューやイベント駆動の仕組みを使っており、失敗したメッセージを後から処理する仕組み（デッドレターキュー等）が既にある
- 障害からの復旧が、ロードバランサーやサービスメッシュのヘルスチェックなどインフラ側で既に管理されている
これらは Azure Architecture Center の「このパターンが適さない場合」の記述に沿った整理です。該当する項目が多い場合、「今回は見送り、まずはタイムアウトの見直しと監視の整備から進めたい」と提案することは、費用を抑えつつ実効性を確保する現実的な判断になります。ベンダーに対しても、この根拠を示せば議論は建設的に進みます。
まず依存先を棚卸しする
判断を自社に当てはめるには、外部依存の一覧が必要です。次の形式で表を作り、ベンダーと一緒に埋めてみてください。
依存先 | 用途 | 停止したときの業務影響 | 影響ランク | 代替手段の有無 |
|---|---|---|---|---|
（例）決済代行サービス | 商品購入時の決済 | 売上が完全に止まる | 高 | なし |
（例）地図 API | 店舗検索の地図表示 | 地図が見られないが検索自体は可能 | 中 | 住所テキスト表示 |
（例）レコメンドエンジン | トップページの関連商品 | 表示が減るだけ | 低 | 固定の人気商品リスト |
この表ができると、議論の質が変わります。影響ランクが「高」の依存先には手厚い対策を、「低」の依存先には遮断とシンプルな非表示で十分、といった濃淡を付けられるようになるためです。すべての依存先に同じ作り込みをする必要はありません。この濃淡こそが、必要と過剰の線引きそのものです。
発注時に確認すべきポイント｜非機能要件・契約・受入テスト・監視
導入を進めると決めた場合、発注プロセスの各段階で確認すべきことがあります。理解して終わりにせず、次のベンダー打ち合わせで使える形に落とし込んでいきます。
要件定義で書くべき非機能要件の表現
要件定義書に「サーキットブレーカーを導入すること」と書くのは、実はあまり良い書き方ではありません。手段を指定してしまうと、より適切な手段があった場合に選べなくなりますし、導入されたかどうかは確認できても、期待した効果が出たかどうかは確認できないためです。
発注者が書くべきなのは、実現したい状態です。
- 「特定の外部連携が停止した場合でも、当該機能以外は継続して利用できること」
- 「外部連携の応答遅延が発生した場合でも、利用者の画面応答は◯秒以内を維持すること」
- 「外部連携が利用できない間は、機能ごとに定めた代替表示を行うこと（代替表示の内容は別紙に定める）」
- 「外部連携の遮断が発生した場合、運用担当者に通知されること」
このように書けば、実現手段はベンダーが提案し、達成できたかどうかは受入テストで確認できます。前の章で作った依存先の棚卸し表を「別紙」として添付すれば、機能ごとの濃淡もそのまま要件に反映できます。
見積もり・保守契約で確認すること
障害に強い作りを入れるという話は、必ず保守・運用の話とセットになります。契約面では次の点を確認しておくと、後の認識違いを避けられます。
- 外部サービス起因の障害が、保守の対応範囲に含まれるか。「外部サービスの障害は免責」とだけ書かれていると、遮断が正しく動いたかどうかの調査も対象外になりかねません
- 設定値の変更が保守の範囲か、都度見積もりか。しきい値や待機時間は運用しながら調整するものです。毎回追加費用が発生する契約だと、実質的に調整されなくなります
- 障害発生時の報告の範囲と期限。遮断が発生した事実の報告が含まれるかを明示します
- 監視・通知の運用を誰が担うのか。仕組みを作るのはベンダーでも、通知を受け取って判断するのは自社という分担になることがあります
このあたりの整理は保守契約の形態そのものと不可分です。準委任と請負でどこまで責任範囲が変わるかを含め、システム保守契約の種類の考え方を押さえたうえで条項を確認すると、抜け漏れを減らせます。
受入テストで動作を確認する方法
サーキットブレーカーは、平常時にはまったく動きません。通常の受入テストでは「何も起きない」ため、実装されているかどうかを確認できないという特性があります。そのため、意図的に障害を起こした状態でのテストを受入項目に含める必要があります。
確認したい項目は次のとおりです。
- 対象の外部連携を止めた（またはエラーを返す）状態で、その機能がすぐにエラーまたは代替表示になること（待たされないこと）
- その間、他の機能が通常どおり利用できること
- 遮断中の画面表示が、事前に決めたフォールバックの内容と一致していること
- 遮断が発生したことが、想定した宛先に通知されること
- 外部連携を復旧させた後、一定時間内に自動的に通常状態へ戻ること
特に3番目は、業務側の担当者が自分の目で確認すべき項目です。技術的には正しく遮断されていても、表示されるメッセージが業務実態と合っていなければ、問い合わせの増加という形で跳ね返ってきます。テストの立ち会いを依頼し、実際の画面を確認させてもらうことをおすすめします。
運用開始後に報告してもらう指標
導入して終わりにしないために、定例報告に含めてもらう項目を決めておきます。
報告項目 | 見えること |
|---|---|
遮断の発生回数（依存先ごと・月次） | どの外部連携が不安定なのか |
1回あたりの遮断継続時間 | 待機時間の設定が実態に合っているか |
遮断の原因（相手側の障害／自社側のタイムアウト設定など） | 対処すべき相手が誰か |
遮断中に影響を受けた利用者数・リクエスト数 | 事業インパクトの大きさ |
設定値の変更履歴 | いつ誰が何を変えたか |
これらは監視の仕組みが整っていて初めて取得できる情報です。導入時に監視・通知の設定が見積もりに含まれているかを確認すべきなのは、この報告を成立させるためでもあります。何をどこまで記録しておくべきかは、ログ管理・モニタリングの設計と地続きの話になります。
なお、遮断の発生回数がゼロで推移している場合、「効果が出ていない」のではなく「そもそも外部連携が安定している」可能性があります。その場合は導入範囲が過剰だった可能性も含めて、次の更改時に見直しの議論をするとよいでしょう。
導入後によくある失敗と、発注者が気づけるサイン
最後に、「入れたのに効かなかった」に陥りやすいパターンと、発注者側から気づけるサインを整理します。技術的な中身を見なくても、報告や問い合わせの内容から異常に気づける観点があります。
設定値が実態と合っていない（緩すぎ・厳しすぎ）
しきい値が緩すぎると、外部サービスがかなり不調になるまで遮断されず、導入前とほとんど変わらない障害が発生します。逆に厳しすぎると、わずかな失敗で遮断され、外部サービスが正常なのに機能が使えない時間が生まれます。
気づけるサインは次のとおりです。障害報告書に「外部サービスの応答遅延によりシステム全体のレスポンスが低下した」という記述が導入後も繰り返し現れる場合は、しきい値が緩すぎる、あるいはタイムアウト設定が長すぎる可能性があります。反対に、利用者から「時々この機能だけが使えなくなる」という問い合わせが増え、ベンダー側の調査で「外部サービスは正常だった」と回答される場合は、厳しすぎる設定を疑ってください。いずれの場合も、設定値の調整で改善できる余地があります。
遮断に誰も気づかない（監視・通知の欠落）
サーキットブレーカーは自動で遮断・復帰するため、通知がなければ発生自体が記録に残りません。結果として、外部サービスが慢性的に不安定であるという事実が誰にも共有されず、契約更新や乗り換えの検討材料にもなりません。
気づけるサインは、定例報告に遮断に関する記述がまったく登場しないことです。導入から数か月経っても発生回数の報告が一度もない場合、本当に発生していないのか、記録されていないだけなのかを確認してください。「遮断の発生回数はどこで確認できますか」という質問に即答できない場合、監視が設定されていない可能性があります。
フォールバックの内容が業務と噛み合っていない
技術的には正しく遮断されていても、遮断中に表示される内容が業務実態と合っていないケースがあります。在庫数を古いキャッシュで表示してしまい注文を受けてしまう、決済エラーの文面が不親切で問い合わせが集中する、機能が消えているだけで利用者が不具合だと誤解する、といった形で表面化します。
気づけるサインは、障害時の問い合わせ内容です。「システムが壊れている」「注文したのに在庫がないと言われた」といった問い合わせが障害のたびに発生している場合、フォールバックの設計を見直す価値があります。これは技術の不具合ではなく、業務側で決めるべき内容が詰められていなかったことによる不整合です。だからこそ、要件定義の段階で機能ごとの代替表示を業務側が決めておく必要があります。
依存先をまとめすぎて健全な連携まで巻き込む
複数の外部連携を1つのサーキットブレーカーでまとめて管理していると、1つの連携先が不調になっただけで、正常に動いている別の連携先まで遮断されることがあります。Azure Architecture Center も、複数の独立したプロバイダーが存在しうる場面で単一のサーキットブレーカーを使うことへの注意を促しています。
気づけるサインは、障害の影響範囲の広さです。「A社の API が停止した」という原因に対して、A社とは無関係の機能まで停止していた場合、遮断の単位が粗い可能性があります。障害報告を受け取ったときに「今回止まった機能と、原因となった連携先の対応関係」を確認する習慣を持つと、この種の設計上の粗さに気づけます。
まとめ｜サーキットブレーカーの導入是非を自社の言葉で判断する
サーキットブレーカーは、外部サービスの不調が自社システム全体に連鎖することを防ぐための設計パターンです。呼び出しを一時的に遮断して即座に応答を返すことで、待機中のリクエストが資源を食いつぶす事態を避け、相手の復旧も妨げません。Closed・Open・Half-Open の3状態を行き来し、しきい値と待機時間という2つの設定値が、利用者から見た「どの機能がどれだけ止まるか」を決めています。
導入すべきかどうかは、システムの構成で判断できます。自社でコントロールできない外部サービスへの依存が複数あり、1つが止まっても他の機能は生かしたい業務要件があるなら、効果が出やすい構成です。逆に、外部依存がほとんどない、既知のリトライで十分、インフラ側で復旧が管理されているといった場合は、過剰投資になりやすくなります。見送る判断も、根拠があれば正当です。
導入を進める場合、発注者が押さえるべきは4つの段階です。要件定義では手段ではなく「特定の外部連携が止まっても他機能は継続利用できること」という状態を書く。契約では外部サービス起因の障害の扱いと設定値変更の範囲を確認する。受入テストでは連携を止めた状態で動作とフォールバック表示を確認する。運用開始後は遮断の発生回数と継続時間を定例報告に含めてもらう。この4点があれば、導入後も効果を確認し続けられます。
次の一歩としておすすめしたいのは、自社の外部依存の棚卸しです。連携先を一覧にし、それぞれが止まったときの業務影響をランク付けするだけで、どこに手厚い対策が必要でどこは軽く済ませてよいかが見えてきます。その表を持って打ち合わせに臨めば、提案の妥当性は自分の言葉で検証できるようになります。
見積もりの内訳をどう読み解くか、費用の妥当性をどう判断するかについては、システム開発の費用を正しく理解するガイドブック で相場の考え方と見積チェックリストを整理しています。予算策定のテンプレートも収録していますので、社内説明の資料づくりにお役立てください。
外部連携が多いシステムの可用性設計について、要件の整理段階からご相談いただけます。ご検討中の方は お問い合わせフォーム からお気軽にお声がけください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- サーキットブレーカーを導入するかどうか、結局何を基準に決めればよいですか？
外部依存先を棚卸しし、決済や認証など停止時の業務影響ランクが「高」の依存先が複数あるかどうかで判断します。該当が1件だけなら、まずはタイムアウト見直しや監視強化から着手し、依存先が増えた段階で導入を再検討するのが費用対効果の高い進め方です。
- 外部依存が少ない小規模なシステムでも導入すべきですか？
外部への依存がほとんどない、既知のリトライで十分、インフラ側で既に復旧管理されているといった条件に多く当てはまる場合は過剰投資になりやすいです。まずは自社の依存先を棚卸しし、該当条件の数を数えたうえで、タイムアウト見直しや監視強化から着手するかを判断してください。
- 見積もりが高いと感じたら、どこを削るべきですか？
削るべきはテストや監視・通知ではなく、適用対象の範囲です。依存先の棚卸し表で影響ランクを「高・中・低」に分け、まず「高」だけに絞って導入し、効果を確認できてから対象を広げれば、品質を落とさず初期費用だけを抑えられます。
- 要件定義書に「サーキットブレーカーを導入すること」と書くのはなぜ避けるべきですか？
「サーキットブレーカーを導入すること」のように手段を指定すると、導入の有無しか確認できず効果検証ができません。「特定の連携が停止しても他機能は継続利用できること」「応答遅延時も画面応答は◯秒以内を維持すること」のように、実現したい状態を要件として書くことが重要です。
- 導入後、遮断が一度も発生していない場合はどう判断すればよいですか？
遮断回数がゼロなのは、効果が出ていないのではなく外部連携が安定している可能性があります。判断に迷う場合は、決済など影響の大きい依存先だけに絞り込んで導入範囲を見直し、次回のシステム更改のタイミングで縮小や継続を検討するとよいでしょう。
