レジリエンスとは｜意味・使い方をわかりやすく（ビジネス・IT・防災での違い）

この記事で実際に動かしたものは、稼働率・停止時間・MTTR・RTO・RPO の計算（Python）と、止まった相手を呼び続けたときの待ち時間の計測（127.0.0.1 の小さなサーバー）です。

レジリエンスは、どの分野でも「打撃を受ける → 持ちこたえる → 戻る → 次に備えて変わる」という同じ流れを指しています。

flowchart TD
    A[ふだんの状態] --> B[打撃を受ける<br>災害・障害・変化]
    B --> C[持ちこたえる<br>働きを落としても続ける]
    C --> D[戻る<br>早く元の働きへ]
    D --> E[変わる<br>学んで次に備える]
    E --> A

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、Python 3.13.18 の標準ライブラリだけを使い、稼働率から停止時間への換算、直列・並列の稼働率、MTBF と MTTR からの稼働率、障害記録からの MTTR、バックアップ間隔と失うデータ量、リトライの成功率を計算しました（本文の表の数字はすべてこの出力です）。リトライとサーキットブレーカーの比較は、同じ Python で 127.0.0.1 の空きポートに小さな HTTP サーバーを起動し、12秒のうち4秒だけ 503 を返すようにして計測しています（外部には接続していません）。言葉の定義は、Merriam-Webster（語源と語義）、APA（アメリカ心理学会）、NIST の用語集、UNDRR（国連防災機関）、内閣官房、中小企業庁、経済産業省の通商白書、AWS Well-Architected Framework、Microsoft Learn、Google の SRE 本、国際連合のそれぞれ公式ページで確かめました。ISO 22316 は ISO の公式ページで題名と発行年までを確かめており、規格の本文は引用していません。図は mermaid-cli 11.16.0 で描画を確かめています（確認日 2026年11月10日）。

レジリエンスとは（意味・語源・日本語訳）

この節では、レジリエンスという言葉のもとの意味と語源、日本語での言い方が分かります。

レジリエンスは英語の resilience で、「形を変えられても元に戻る性質」と「不運や変化から立ち直る力」の2つの意味を持つ言葉です。 英語辞書の Merriam-Webster は、次の2つの語義を載せています（訳は本記事によるもの）。

• 語源：ラテン語の動詞 resilire（跳ね返る・はね戻る）の現在分詞から来ています。resilire は re-（もとへ）＋ salire（跳ぶ）です（Merriam-Webster）。
• 初出：Merriam-Webster は、resilience の初出を1807年（物の性質の意味）、形容詞 resilient の初出を1674年としています。
• 日本語訳：回復力・復元力・弾力（性）と訳されます。行政の文書では「強靱（きょうじん）」が当てられ、内閣官房は国土強靱化に「ナショナル・レジリエンス」と添えています。
• 形容詞：resilient（レジリエント）。「レジリエントな組織」「レジリエントなシステム」のように使います。
• つづりの違い：resilience と resiliency（レジリエンシー）は同じ意味で使われます。AWS の文書は resiliency を使っています。

ばねを押して手を離すと、元の長さに戻ります。この「押されても折れずに、元へ戻る」という物の性質が、人・組織・社会・コンピューターのシステムへと広がって使われるようになりました。

レジリエンスの分野別の意味（一覧表）

この節では、同じ「レジリエンス」が、分野ごとに何を指しているのかが一覧で分かります。

分野が変わると、「何が」「何から」戻るのかが変わります。 会話や資料でこの言葉が出てきたら、まずどの分野の話かを確かめると、意味を取り違えません。

IT の仕事をしている人と、そうでない人とでは、最初に思い浮かべる意味が違います。2つを並べると次のとおりです。

心理学でのレジリエンス（定義と由来）

この節では、心理学でレジリエンスがどう定義されているかが分かります。

APA（アメリカ心理学会）は、レジリエンスを「困難な、あるいは厳しい人生経験に、うまく適応していく過程と、その結果」と説明しています。 続けて、その適応は、考え方・感情・行動の柔軟さと、外と内からの求めに合わせた調整を通じて行われる、としています（APA の公式ページ。訳は本記事によるもの）。

• 「性格」ではなく、過程（プロセス）と結果として定義されている点が特徴です。
• 物の「元に戻る性質」を表していた言葉が、人が困難な経験に適応していく様子を表す言葉として、心理学に取り入れられました。

本記事は言葉の意味を扱う記事のため、心理学の意味は定義と由来の紹介までとします。

ビジネス・組織でのレジリエンス（組織・サプライチェーン）

この節では、ビジネスの文脈でレジリエンスと言うときに、何を指しているかが分かります。

ビジネスでのレジリエンスは、会社やチームが、環境の変化や事業の中断に適応し、事業を続ける力です。 個人の気持ちの話ではなく、仕組み・体制・備えの話として使われることが多い言葉です。

• 組織レジリエンス：NIST の用語集は、レジリエンスを「複雑で変化する環境における、組織の適応能力」とも定義できる、と紹介しています（ASIS SPC.1-2009 を出典とする項目）。国際規格では ISO 22316:2017（Security and resilience ― Organizational resilience ― Principles and attributes）が、組織の大きさや業種を問わない指針として発行されています。
• サプライチェーンのレジリエンス：経済産業省の通商白書2021は、供給網の強靱化の取り組みとして、仕入れ調達先の分散・多様化、同じ製品の複数の生産拠点の確保、デジタル技術による弱点の可視化・モニタリングなどを挙げています。
• 事業の続け方の計画（BCP）：レジリエンスを高める手段の1つです。違いは「似た言葉との違い」の節で扱います。

上の4つは、ビジネスでレジリエンスを話題にするときによく出てくる観点を、本記事で整理したものです。会社の例を挙げるときは、売上・問い合わせ件数・納期・品質のように、数字で確かめられるものを選ぶと話がかみ合います。

防災でのレジリエンス（国土強靱化・BCP）

この節では、防災の分野でレジリエンスがどう定義され、どんな言葉と一緒に使われるかが分かります。

防災でのレジリエンスは、災害にさらされた地域や社会が、耐え、吸収し、適応し、早く立ち直る力です。 UNDRR（国連防災機関）の用語集は、次のように定義しています（訳は本記事によるもの）。

ハザードにさらされたシステム・コミュニティ・社会が、リスク管理を通じた基本的な構造と機能の維持・回復を含め、ハザードの影響に対して、適時かつ効率的に、抵抗し、吸収し、受け入れ、適応し、変革し、回復する能力。

• 国土強靱化（ナショナル・レジリエンス）：内閣官房は「国土強靱化（ナショナル・レジリエンス）、防災・減災の取組みは、国家のリスクマネジメントであり、強くてしなやかな国をつくることです。」と説明しています。
• 根拠となる法律：「強くしなやかな国民生活の実現を図るための防災・減災等に資する国土強靱化基本法」（平成25年12月11日法律第95号）です。法律の名前にも「強くしなやかな」が入っています。
• BCP（事業継続計画）：中小企業庁は、BCP を、緊急事態に遭遇した場合に、事業資産の損害を最小限にとどめつつ、中核となる事業の継続あるいは早期復旧を可能とするために、平常時に行うべき活動や緊急時の事業継続の方法・手段を取り決めておく計画、と説明しています。

「強い」だけでなく「しなやか」が並んでいる点が、レジリエンスという言葉の特徴をよく表しています。壊れないように固めるだけでなく、被害を受けたあとに早く戻ることまでを含みます。

ITでのレジリエンスとは（障害から早く戻るシステム）

この節では、IT・システムの分野でのレジリエンスの定義と、信頼性・可用性との関係が分かります。

IT でのレジリエンスは、障害や過負荷が起きても、システムが働きを保ち、早く復旧できる性質です。 「障害を起こさない」ではなく、「障害は起きるものとして、起きたあとにどう振る舞うか」に目を向ける考え方です。公式の定義を3つ並べます（訳は本記事によるもの）。

Microsoft の Azure Well-Architected Framework は、信頼できるワークロードの条件として、障害を検知して耐えながら動き続ける「レジリエント」であること、耐えきれない中断のあとに合意した目標のうちに戻せる「リカバリー可能」であること、約束した時間に使える「可用」であることを挙げています。

2つはどちらか一方を選ぶものではなく、両方を組み合わせます。Google の SRE 本は「100% は、おそらくどんな場合も正しい信頼性の目標ではない」と述べています。止まらない前提で作るより、止まったときの戻り方まで決めておくほうが、利用者への影響を小さくできます。

なお、攻撃を受けることを前提に、予測し、耐え、回復し、適応する能力を指す「サイバーレジリエンス」という言葉もあります（NIST SP 800-160 Vol. 2 Rev. 1 の定義）。本記事では言葉の紹介にとどめます。

レジリエンスを高める設計（冗長化・自動復旧・リトライ・バックアップ）

この節では、IT のシステムでレジリエンスを高めるために使われる代表的な手段と、それぞれの役割が分かります。

手段は「止まらないようにする」「広げない」「早く戻す」「確かめる」の4つに分けると整理できます。

Azure Well-Architected Framework は、冗長化について「単一障害点を最小限にするのに役立つ」と述べ、復旧については、定期的な復旧訓練でコンポーネントやデータの復旧、切り替えと切り戻しの手順を試すことを勧めています。

リトライとサーキットブレーカーを127.0.0.1で比べた結果

リトライは「やり直せば成功する」ことを期待する手段、サーキットブレーカーは「失敗しそうな呼び出しを行わない」手段です（Microsoft Learn の説明）。違いを数字で見るため、127.0.0.1 に小さなサーバーを起動し、12秒のうち3〜7秒の4秒間だけ、0.3秒待たせてから 503 を返すようにしました。呼び出す側は0.1秒ごとに1件（12秒で120件ぶんの枠）を順に送ります。

Python 3.13.18 port 37825 停止 3.0〜7.0秒（4秒間）・計測 12秒・0.1秒ごとに1件
A 何もしない: 依頼 92 成功 78 失敗 14 | 失敗1件の平均待ち 302ms 最長 302ms | 停止中に相手へ届いた呼び出し 14 | 復旧から最初の成功まで 224ms
B すぐ3回リトライ: 依頼 83 成功 79 失敗 4 | 失敗1件の平均待ち 906ms 最長 906ms | 停止中に相手へ届いた呼び出し 14 | 復旧から最初の成功まで 232ms
C サーキットブレーカー: 依頼 110 成功 72 失敗 38 | 失敗1件の平均待ち 40ms 最長 302ms | 停止中に相手へ届いた呼び出し 5 | 復旧から最初の成功まで 802ms | 呼ばずに返した 33

• 相手が止まっている間は、すぐにリトライしても成功は増えませんでした（78件と79件）。失敗1件の待ちは3倍の906msになり、そのぶん送れた依頼が92件から83件に減りました。
• サーキットブレーカーは、成功を増やす仕組みではありませんでした（成功は72件）。失敗を平均40msで返して呼び出す側を待たせず、止まっている相手に届く呼び出しを14回から5回に減らしました。
• 引き換えに、復旧に気づくのが0.8秒遅れました。呼び出しを止めておく時間（ここでは1秒）を長くするほど、相手は休めますが、復旧に気づくのは遅くなります。

C は「3回続けて失敗したら1秒のあいだ呼ばずに失敗を返す」という最小の作りです。3つの状態（Closed・Open・Half-Open）の実装としきい値の決め方は、関連記事「サーキットブレーカーとは｜3状態の実装とリトライ可否の一覧表」で扱っています。リトライの間隔のあけ方は、関連記事「指数バックオフとは？リトライ間隔の決め方とジッターの実装」で扱っています。

リトライが効くのは「一時的な失敗」のとき

1回の呼び出しが、互いに関係なく一定の割合で失敗する場合、n 回までに1回でも成功する確率は「1 −（失敗率の n 乗）」です。Python で計算した結果は次のとおりです。

この計算は「失敗が互いに関係なく起きる」ときだけ成り立ちます。相手が止まっている間は、何回やり直しても失敗します（上の実測の B）。一時的な失敗にはリトライ、続く失敗にはサーキットブレーカー、と使い分けます。

MTTR・RTO・RPOの意味（レジリエンスを数字で表す）

この節では、IT のレジリエンスを数字で表すときに使う MTTR・RTO・RPO の意味と、計算のしかたが分かります。

MTTR は「戻るまでにかかった時間の平均」、RTO は「ここまでに戻すという目標の時間」、RPO は「ここまでのデータは戻すという目標の時点」です。 MTTR は過去の記録から出す値、RTO と RPO は先に決める目標です。

AWS Well-Architected Framework は、RTO を「サービスの中断から復旧までの、許容できる最大の遅れ」、RPO を「最後のデータ復旧ポイントからの、許容できる最大の時間」と定義し、どちらも組織が決めるものとしています。

障害の記録からMTTRを計算する

4か月（2026年7月1日〜10月31日）に4回止まった、という架空の記録で計算します。

2026-07-03 02:10 気づくまで 4 分 / 戻るまで 42 分
2026-08-19 13:40 気づくまで 1 分 / 戻るまで 18 分
2026-09-07 21:05 気づくまで 20 分 / 戻るまで 125 分
2026-10-22 09:30 気づくまで 2 分 / 戻るまで 17 分
合計 202 分 MTTR 50.5 分 気づくまでの平均 6.75 分
期間 177120.0 分 稼働率 99.8860% MTBF 737.2時間

• MTTR は 202分 ÷ 4回 ＝ 50.5分です。
• 平均を押し上げているのは、3回目（気づくまで20分・戻るまで125分）です。平均だけでなく、いちばん長かった1回を見ると、直すところが見つかります。
• 稼働率は 1 −（202 ÷ 177,120）＝ 99.8860% です。

バックアップの間隔とRPO、復旧の手順とRTO

11月10日の14時20分にデータが壊れた、という例で、バックアップの取り方ごとに失うデータの量を計算しました。

RPO を「1時間」と決めたら、バックアップの間隔は1時間以下にする、という関係です。RTO のほうは、復旧にかかる時間を工程ごとに足して確かめます。たとえば「気づく6分＋判断9分＋データを戻す35分＋動作を確かめる10分」なら合計60分で、RTO 60分にちょうど収まります。どれか1つが延びると超えるため、訓練で実際の時間を測っておくことが大切です。

データごとの RPO・RTO の決め方は、関連記事「バックアップ設計の書き方｜RPO・RTOの決め方と世代管理の計算例」で扱っています。

稼働率の計算（止まる回数より、戻る早さが効く）

この節では、稼働率と停止時間の関係、直列・並列の計算、MTTR を短くしたときの効果が、実際に計算した数字で分かります。

稼働率（可用性）は「使える時間 ÷ 全体の時間」です。 AWS は可用性を「ワークロードが利用可能な時間の割合」と定義し、レジリエンスを数字で測るときによく使う指標としています。

from fractions import Fraction

for a in ["99", "99.9", "99.99", "99.999"]:
    stop = 1 - Fraction(a) / 100           # 止まってよい割合
    print(a + "%", stop * 365 * 86400, "秒/年")

この値は、AWS Well-Architected Framework の表（99.9% で年8時間45分、99.99% で年52分、99.999% で年5分）と一致しました。

直列は掛け算、並列は「同時に止まる確率」を引く

直列（どれか1つが止まると全体が止まる）は、つなぐほど稼働率が下がります。並列（冗長化。どれか1つが動いていればよい）は、99% の機器を2つ並べるだけで 99.99% になります。ただし、この計算は「互いに関係なく故障する」ことが前提です。同じ電源・同じ設定の誤りで同時に止まる場合は、この数字にはなりません。AWS の例（99.99% の3つ直列で 99.97%、99.9% の2つ並列で 99.9999%）とも一致しました。

MTTRを短くしたときの効果

稼働率は MTBF ÷（MTBF ＋ MTTR）でも求められます（AWS）。MTBF 150日・MTTR 1時間で計算すると 99.9722% で、AWS の例の 99.97% と一致しました。次に、1年に12回止まるシステムで、MTTR だけを変えて計算しました。

止まる回数を半分にすると停止は6時間、回数はそのままで MTTR を60分から10分にすると停止は2時間でした。 自動で切り替わる仕組みで MTTR が分単位になると、回数を減らすより大きく効きます。これが、IT で「障害から早く戻る」レジリエンスが重視される理由です。直列・並列の式と構成ごとの比べ方は、関連記事「可用性設計と稼働率の計算｜直列・並列の計算式と停止時間の早見表」で扱っています。目標の決め方は、関連記事「SREとは｜SLI・SLO・SLAの違いとエラーバジェット計算」で扱っています。

レジリエンスを高める進め方（ITのシステムの場合）

この節では、いまあるシステムのレジリエンスを高めるときに、どの順番で手を付けるかが分かります。

先に「何を、いつまでに戻すか」を決め、次に弱いところを探し、最後に訓練で確かめます。

障害のあとの記録のまとめ方は、関連記事「障害報告書の書き方｜例文つきテンプレートと再発防止策の立て方」で扱っています。

• 1止まると困る機能に、RTO と RPO が書いてある数字が無いと、備えが足りているかを判断できない
• 2バックアップから実際に戻したことがある取っているだけでは、戻せるかどうかは分からない
• 3外部の呼び出しにタイムアウトがある待ち続けると、止まった相手に引きずられて自分も止まる
• 4障害に気づく仕組みがある気づくまでの時間は、そのまま MTTR に足される
• 5復旧の手順を、担当者以外も読んで動かせる夜間や不在のときにも戻せるかを訓練で確かめる

似た言葉との違い（ロバスト・冗長化・可用性・耐障害性・BCP）

この節では、レジリエンスと混同しやすい言葉との違いが、表で分かります。

レジリエンスは「目指す性質」で、冗長化や BCP はそのための「手段」、可用性や MTTR はその「測り方」です。

NIST の用語集は、ロバストの定義に「その範囲の外では、穏やかに失敗する」ことも含めています。実際の設計では、ロバストに作ったうえで、範囲を超えたときの戻り方（レジリエンス）も用意します。

レジリエンスの使い方と例文

この節では、レジリエンスという言葉の文の中での使い方が、場面別の例文で分かります。

「レジリエンスが高い・低い」「レジリエンスを高める・強化する」「レジリエントな〜」の形で使います。

• 数字と一緒に使うと伝わります。「レジリエンスを高める」だけでは何をするのかが伝わりません。「RTO を4時間から1時間にする」「調達先を1社から2社にする」と添えます。
• 相手の分野に合わせて言い換えます。 IT に詳しくない相手には「止まっても早く戻せる作り」、防災の文脈では「強靱化」と言うと伝わります。
• 英語では improve resilience、build resilience、a resilient system のように使います。

レジリエンスのよくある誤解・つまずき・判断表

この節では、レジリエンスという言葉について広まっている誤解と、IT の設計でつまずきやすい点、場面に合う言葉と対策の選び方が分かります。

IT の設計で起きやすいつまずきを、症状から引ける形にまとめます。

判断表：どの言葉を使うか、どの対策から始めるか

場面に合う言葉は次の表で、IT のシステムで困りごとから対策を選ぶ順番はその下の一覧で選べます。

1. 1データを失うと取り返せない → バックアップと復元の訓練RPO を決め、実際に戻して時間を測る
2. 2障害に気づくのが遅い → 監視とヘルスチェック気づくまでの時間は MTTR にそのまま足される
3. 31つ止まると全体が止まる → 冗長化単一障害点から順に。同時に止まる原因が無いかも見る
4. 4一時的な失敗が利用者に見えている → タイムアウトとリトライやり直してよい操作かを確かめてから
5. 5相手の障害に引きずられる → サーキットブレーカーと縮退運転止まった相手を呼ばず、大事な機能だけ続ける
6. 6計画はあるが動くか分からない → 復旧訓練測った時間を RTO と比べ、手順を直す

レジリエンスのよくある質問

この節では、レジリエンスについてよく調べられている疑問の答えが分かります。

Q. レジリエンスとは、簡単に言うと何ですか。
A. 打撃を受けても持ちこたえ、元の働きへ戻る力です。ばねが押されても元の長さに戻る様子を思い浮かべると近い意味になります。

Q. レジリエンスを日本語で言うと何ですか。
A. 回復力・復元力・弾力です。防災や行政の文書では「強靱（きょうじん）」が使われ、内閣官房は国土強靱化に「ナショナル・レジリエンス」と添えています。

Q. レジリエンスの語源は何ですか。
A. ラテン語の resilire（跳ね返る）です。re-（もとへ）と salire（跳ぶ）からできた動詞で、Merriam-Webster は resilience の初出を1807年としています。

Q. レジリエンスとレジリエントの違いは何ですか。
A. レジリエンスは名詞（回復する力）、レジリエントは形容詞（回復する力がある）です。「レジリエンスが高い組織」と「レジリエントな組織」は同じ意味です。

Q. レジリエンスとレジリエンシーは違いますか。
A. 同じ意味です。英語のつづりが resilience と resiliency の2通りあり、AWS の文書は resiliency を使っています。

Q. レジリエンスとロバストの違いは何ですか。
A. ロバストは幅広い条件で崩れずに動き続ける性質、レジリエンスは崩れたあとに戻ることまで含む性質です。両方を組み合わせて設計します。

Q. IT のレジリエンスと可用性の違いは何ですか。
A. 可用性は「使える時間の割合」という数字で、レジリエンスは中断から復旧する能力そのものです。AWS は、可用性をレジリエンスを測るための指標として説明しています。

Q. レジリエンスと BCP の違いは何ですか。
A. レジリエンスは目指す性質、BCP はそのための計画です。BCP を作って訓練を重ねることが、事業のレジリエンスを高める手段になります。

Q. レジリエンスの反対の言葉は何ですか。
A. 決まった対義語はありませんが、「脆弱（ぜいじゃく）」「もろさ」が対になる言葉として使われます。内閣官房の国土強靱化のページでも、弱いところを調べる取り組みに「脆弱性」という言葉が使われています。

Q. MTTR を短くするには、何から始めますか。
A. 障害の記録から「気づくまで」と「戻るまで」を分けて測るところから始めます。本記事の例では、平均50.5分のうち、1回の長い障害（125分）が平均を押し上げていました。

Q. サイバーレジリエンスとは何ですか。
A. 攻撃を受けることを前提に、予測し、耐え、回復し、適応する能力を指す言葉です。NIST SP 800-160 Vol. 2 Rev. 1 に定義があります。

まとめ

この節では、この記事の要点が5つで分かります。

• レジリエンスは、打撃を受けても持ちこたえ、元の働きへ戻る力です。 語源はラテン語の resilire（跳ね返る）で、日本語では回復力・復元力・弾力・強靱と訳されます。
• 分野で「何が・何から戻るか」が変わります。 心理学は個人、ビジネスは組織、IT はシステム、防災は地域や社会、サプライチェーンは供給網です。
• ロバストは崩れにくさ、レジリエンスは戻る力です。 冗長化や BCP は手段、可用性や MTTR は測り方です。
• IT では MTTR・RTO・RPO・稼働率で数字にできます。 年12回止まる例では、回数を半分にするより、MTTR を60分から10分にするほうが停止時間は短くなりました（6時間と2時間）。
• 手段には向き・不向きがあります。 実測では、止まった相手へのリトライは成功を増やさず、サーキットブレーカーは待ちを302msから40msに縮めた代わりに、復旧に気づくのが0.8秒遅れました。

参考・出典

この節では、本記事で確かめた一次情報の場所が分かります（確認日 2026年11月10日）。

• Merriam-Webster「resilience」：https://www.merriam-webster.com/dictionary/resilience
• Merriam-Webster「resilient」：https://www.merriam-webster.com/dictionary/resilient
• American Psychological Association「Resilience」：https://www.apa.org/topics/resilience
• NIST Computer Security Resource Center「Glossary: resilience」：https://csrc.nist.gov/glossary/term/resilience
• NIST「Glossary: cyber resiliency」：https://csrc.nist.gov/glossary/term/cyber_resiliency
• NIST「Glossary: fault tolerance」：https://csrc.nist.gov/glossary/term/fault_tolerance
• NIST「Glossary: robustness」：https://csrc.nist.gov/glossary/term/robustness
• UNDRR「Resilience」：https://www.undrr.org/terminology/resilience
• 内閣官房「国土強靱化」：https://www.cas.go.jp/jp/seisaku/kokudo_kyoujinka/index.html
• 内閣官房「国土強靱化 関係法令」：https://www.cas.go.jp/jp/seisaku/kokudo_kyoujinka/hourei.html
• 中小企業庁「1.1 BCP（事業継続計画）とは」：https://www.chusho.meti.go.jp/bcp/contents/level_c/bcpgl_01_1.html
• 経済産業省「通商白書2021年版 第2節 サプライチェーンリスクと危機からの復旧」：https://www.meti.go.jp/report/tsuhaku2021/2021honbun/i2120000.html
• ISO「ISO 22316:2017 Security and resilience ― Organizational resilience ― Principles and attributes」：https://www.iso.org/standard/50053.html
• AWS Well-Architected Framework「Resiliency, and the components of reliability」：https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/resiliency-and-the-components-of-reliability.html
• AWS Well-Architected Framework「Availability」：https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html
• AWS Well-Architected Framework「Disaster recovery (DR) objectives」：https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html
• Microsoft Learn「Reliability design principles」：https://learn.microsoft.com/en-us/azure/well-architected/reliability/principles
• Microsoft Learn「Circuit Breaker pattern」：https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker
• Google「Site Reliability Engineering: Embracing Risk」：https://sre.google/sre-book/embracing-risk/
• United Nations「Sustainability」：https://www.un.org/en/academic-impact/sustainability

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。