🔖 キーワード索引

🔖 キーワード索引 (拡張)

🎨 直感で掴む

ATM に行ったら「メンテナンス中」だと困る。 ネットバンクが DDoS でアクセス不能でも困る。 これらが 可用性 (Availability) が損なわれた状態。 情報セキュリティの三大要素は Confidentiality (機密)・Integrity (完全)・Availability (可用) で、 鍵の管理だけでなく「使いたいときに使える」も同じくらい重要。

🎨 直感で掴む: 可用性を「電車の運休率」で理解する

可用性は抽象的に感じられがちですが、 「電車・郵便・水道」のような日常インフラの安定性に置き換えるとイメージしやすくなります。

数字が 1 桁増えるごとに、 達成のためのコストは 3〜10 倍に跳ね上がる ── これが可用性設計の核心。

🎨 可用性 × データガバナンス: SSDSE-B-2026 API の SLA 文書テンプレ

SSDSE-B-2026 (47 県統計) を社外配信する API の SLA 文書を実例として示します。

🎨 可用性向上 5 つの王道パターン (アーキテクチャ例)

「99.999% のために 2 クラウド契約するか?」は経営判断。 ほとんどの SaaS は 99.9 〜 99.95% が経済合理ライン。

📐 定義・数式

MTBF (平均故障間隔, Mean Time Between Failures) と MTTR (平均復旧時間, Mean Time To Repair) で稼働率 $A$ を表す。 99.9% を維持するには「壊れにくさ」と「直すスピード」の両立が必要。

📐 数式を言葉で読み解く: 可用性の全方程式

可用性 (Availability) を表す中心式は次の 4 つです。 用語コンペ・SLA 設計・SRE 実務でこの 4 つを区別できるかどうかが鍵になります。

① 定常可用性 (Steady-State Availability)

🔬 数式を言葉で読み解く：分子の MTBF (Mean Time Between Failures) は「障害から障害までの平均稼働時間」、 分母には MTBF に MTTR (Mean Time To Repair)「平均復旧時間」を加える。 つまり「稼働時間 ÷ (稼働時間+停止時間)」を時間平均した値。

② 瞬時可用性 (Instantaneous Availability)

🔬 数式を言葉で読み解く：時刻 t でシステムが稼働している確率。 起動直後は 1 から始まり、 やがて定常値 \\(A_{\\mathrm{steady}}\\) に近づく。

③ 直列構成の可用性

🔬 数式を言葉で読み解く：直列接続では「全コンポーネントが同時に稼働」が条件。 99.9% を 5 段直列すると \\(0.999^5 \\approx 0.995\\) に低下する。

④ 並列冗長構成の可用性

🔬 数式を言葉で読み解く：並列冗長は「全コンポーネントが同時に停止」しないと止まらない。 99.9% を 2 重化すると \\(1 - 0.001^2 = 0.999999\\) (six 9s) に跳ね上がる。

📐 可用性の高度トピック: 部分稼働 (Graceful Degradation) と Brownout

「Up か Down か」の 2 値だけでは現代システムは表現しきれません。 機能の一部のみ停止する Graceful Degradation と、 容量を絞って稼働させる Brownout が現代的可用性の概念。

🔬 数式を言葉で読み解く: 機能別重み付き可用性

機能 \\(i\\) (例: 検索・購入・推薦) の重要度を \\(w_i\\)、 各機能の可用性を \\(A_i\\) とし、 加重平均で全体可用性を定義。 「全機能 = 等価」ではなく、 「収益直結機能 = 重み大」と扱う現代的アプローチ。

🎯 このコードでやること：SSDSE-B-2026 配信 API の機能 (一覧/詳細/集計/比較) ごとに重み付き可用性を計算。

📥 入力データ (機能別 SLO):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

import pandas as pd

functions = pd.DataFrame([
    {'name': 'list',      'weight': 0.40, 'availability': 0.9995},
    {'name': 'detail',    'weight': 0.30, 'availability': 0.9990},
    {'name': 'aggregate', 'weight': 0.20, 'availability': 0.9970},
    {'name': 'compare',   'weight': 0.10, 'availability': 0.9950},
])
assert abs(functions['weight'].sum() - 1.0) < 1e-9
A_w = (functions['weight'] * functions['availability']).sum()
A_min = functions['availability'].min()
print(functions)
print(f'\\n重み付き可用性: {A_w:.6f} ({A_w*100:.4f}%)')
print(f'最弱機能可用性: {A_min:.6f} ({A_min*100:.4f}%)')
print(f'差分 (SLA 緩和効果): {(A_w - A_min)*100:.4f} %pt')

📤 実行結果:

💬 結果の読み方：最弱機能 (compare) は 99.5% だが、 重要度が低い (重み 0.10) ので全体 SLA は 99.84%。 「最弱機能 = 全体 SLA」と扱うと過剰投資になる。 機能別重み付けで現実的な SLA を約束できる。

🔬 数式を言葉で読み解く

数式に出てくる記号の意味を 1 つずつ確認しましょう。

MTBF

故障と故障の間隔。 長いほど壊れにくい。

MTTR

故障から復旧までの平均時間。 短いほど復旧が速い。

$A$

稼働率 (Availability)。 通常 99.9% 〜 99.999% で議論。

SLA

Service Level Agreement。 稼働率の契約上の保証。

🔬 数式を言葉で読み解く（500字+ narration）

可用性 (Availability) は、 システムが「使えるべき時に使える」割合を時間で表す指標で、 古典的な数式は $A = \dfrac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$ です。 ここで MTBF (Mean Time Between Failures) は故障間の平均稼働時間、 MTTR (Mean Time To Repair) は故障から復旧までの平均時間。 たとえば MTBF = 720 時間 (30 日)、 MTTR = 1 時間なら $A = 720/(720+1) \approx 0.9986$ で、 これは 99.86% の可用性に相当します。 業界では「9 の数」で表現する慣例があり、 99.9% (Three Nines)、 99.99% (Four Nines)、 99.999% (Five Nines / 銀行・通信レベル) と上がるごとに年間許容停止時間が 1/10 に減ります。 99.999% は年 5 分強、 99% は年 87.6 時間 ── 設計コストは 9 が 1 つ増えるたびに指数的に膨らむため、 SLA (Service Level Agreement) では「何 9 を目指すか」が経営判断になります。 セキュリティの観点から見ると、 可用性は CIA トライアド (機密性 Confidentiality、 完全性 Integrity、 可用性 Availability) の 1 角で、 DDoS 攻撃、 ランサムウェア、 物理的災害、 電源障害、 設定ミス、 ソフトウェアバグなど多様な脅威にさらされます。 確率的には「並列冗長」が可用性を引き上げます ── 単体可用性 $A$ の機器を $n$ 個並列に並べると、 システム可用性は $1 - (1-A)^n$ となり、 99% を 2 機並列にすれば 99.99% に。 反面、 直列構成 (相互依存) では $A^n$ に落ち、 弱い構成要素が全体を律します。 SSDSE-B-2026 のようなオープンデータの可用性は、 統計センターの公開サーバー稼働率に依存しますが、 ユーザー側でも GitHub Mirror、 Internet Archive スナップショットを保持することで「データ可用性」を高められます。 結局、 可用性は単なる稼働率の話ではなく、 「冗長化 × 監視 × 自動復旧 × 災害対策」の総合芸術です。

📖 4 要素 narration — 可用性を 4 つの視点で再読する

① 直感の narration

ATM が「停止中」と表示された経験はありますか？ 緊急時に病院の電子カルテが繋がらないと命に関わります。 可用性は「必要な時に動く」という当たり前を支える概念。 機密性・完全性が満たされていても、 使えなければサービスは存在しないも同然です。

② 数式の narration

$A = \dfrac{\text{MTBF}}{\text{MTBF}+\text{MTTR}}$ は「全時間の中で稼働していた割合」を表します。 MTBF を伸ばす方向 (信頼性向上)、 MTTR を縮める方向 (復旧自動化) の 2 軸で改善できます。 99.99% を目指すなら MTBF/MTTR の比を 10,000 以上にする必要があります。

③ 計算の narration（SSDSE データ可用性）

SSDSE-B-2026 の CSV は統計センターから公開されています。 仮にこのサーバーが MTBF=720h, MTTR=2h なら $A = 720/722 \approx 0.9972$、 つまり年間で約 24 時間程度のダウンが見込まれる計算。 これを補うため、 ローカルキャッシュ・ミラーリング・バックアップを併用するのが教育用ハンズオン教材としての可用性確保策です。

④ Python の narration

監視には requests.get(url, timeout=5) でレスポンス時間を計測、 schedule ライブラリで定期実行。 Prometheus / Grafana への送信は prometheus_client ライブラリ。 SLA 違反検知は単純な閾値ベースで十分機能します。

🔬 数式を言葉で読み解く: Error Budget の計算根拠

記号一覧:

• \\(T_{\\mathrm{month}}\\) — 月間総時間 (30 × 24 × 60 = 43,200 分)
• \\(\\mathrm{SLO}\\) — Service Level Objective (例 0.999)
• \\(\\mathrm{ErrorBudget}_{\\mathrm{month}}\\) — 月次で「使ってよい」許容停止時間

SLO 99.9% なら月次 43.2 分の予算が「攻めの開発」と「事故対応」の両方に使える。 これが Error Budget Policy の数学的根拠。

🔬 数式を言葉で読み解く（追補: 可用性係数の SSDSE-B-2026 47 県スコア化）

本節では「可用性 $A = \mathrm{MTBF}/(\mathrm{MTBF}+\mathrm{MTTR})$」を SSDSE-B-2026 の 47 都道府県データソースに当てはめ、 各県のデータ更新頻度・欠測復旧時間から「県別可用性スコア」を導出する手順を、 記号→意味→数値の三段階で読み解く。 $\mathrm{MTBF}$ は平均故障間隔（県データが連続して出続けた期間）、 $\mathrm{MTTR}$ は平均復旧時間（欠測→次の値が出るまでの日数）と読み替える。 つまり「県の指標が信頼できる期間 ÷ 全観測期間」が、 そのままその県の SSDSE 可用性係数になる。

記号の対応表を作ると次のようになる: MTBF = 連続正常観測日数の平均、 MTTR = 欠測検知から代替値補完までの平均日数、 A = 0 から 1 の無次元値、 1-A = 不可用率（ダウンタイム比）、 SLO = ステークホルダー合意の最低保証 $A$。 SSDSE-B-2026 を月次更新と仮定すると、 1 ヶ月欠測すれば MTTR = 30 日、 過去 5 年欠測なしなら MTBF = 1,825 日、 $A = 1825/(1825+30) \approx 0.9838$（98.38%、 約 1.8 nines）となる。 これを 47 県すべてに対して計算すれば、 県ランキング表が描ける。

このコードでやること: SSDSE-B-2026 の 47 県 × 複数年データから、 各県の擬似欠測パターン（最新年が NaN になる頻度）を集計し、 県別可用性係数 $A_i = \mathrm{MTBF}_i/(\mathrm{MTBF}_i+\mathrm{MTTR}_i)$ を計算する。 真の欠測ログが存在しない場合は、 各列の欠測率を不可用率 $1-A$ に見立てる近似版で代用する。

📥 入力データ (SSDSE-B-2026 抜粋・47 県 × 数値カラム):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', skiprows=[1], encoding='cp932')
num_df = df.select_dtypes(include='number')
miss_rate_by_pref = num_df.isna().mean(axis=1)
A_by_pref = 1.0 - miss_rate_by_pref
pref_names = df['Prefecture'] if 'Prefecture' in df.columns else df.iloc[:, 1]
result = pd.DataFrame({'Prefecture': pref_names, '可用性A': A_by_pref.round(4)})
print(result.sort_values('可用性A', ascending=False).head(10).to_string(index=False))
print('全国平均 A =', round(A_by_pref.mean(), 4))

📤 実行すると次の出力が得られる（イメージ値、 SSDSE-B-2026 の構造に依存）:

💬 結果の読み方: 全国平均 $A \approx 0.9923$ は約 2 nines（年間 67 時間ダウンタイム相当）。 4 nines を目指すには、 中小県のデータ補完体制（代替指標・線形補間・前年値リサイクル）を組み込んで $1-A$ を 100 倍小さくする必要がある。 つまり 1 県あたり「年に数行の補完」がベースライン。 SSDSE データソースに対する SLO 文書を書く際の出発点として、 この近似 $A$ は十分実用的である。

補足: 実欠測がほとんど無い場合、 上記近似 $A$ は 1.0 に貼り付いてしまう。 そのときは「最新年の更新遅延（出版から N ヶ月）」を MTTR として使い、 $A = T/(T+\mathrm{delay})$ で代用する。 これにより「データの鮮度」を可用性に取り込める。 SSDSE-B-2026 の公開タイミングが年 1 回 (T=365 日) で、 観測年から公開まで遅延 90 日なら $A = 365/(365+90) \approx 0.802$、 これは「データ鮮度の可用性」として SLO 設計に直結する数値となる。

補講: 可用性 $A$ の定義は単純だが、 「どのイベントを故障とみなすか」「どの状態を復旧とみなすか」の境界次第で値が大きく変わる点に注意。 SSDSE-B のような公的統計においては「欠測」「遅延公開」「分類変更による不整合」の 3 つすべてが事実上の故障に該当しうる。 用途別に MTBF/MTTR の定義を 1 ページ文書として固定するのが運用上の鉄則であり、 これを決めないまま $A$ を比較すると同じ県の数値が利用者ごとに違ってくる。 可用性指標は「定義の明文化」とセットでしか意味を持たない、 という設計者向けの教訓を残しておく。

🔬 数式を言葉で読み解く（補講・可用性指標の運用視点での再解釈）

これまで本ページでは可用性 A = MTBF / (MTBF + MTTR) という定常解、 直列構成 A_serial = ∏ A_i、 並列構成 A_parallel = 1 - ∏ (1 - A_i) の 3 種類の数式を扱ってきた。 ここでは、 これらの数式を「実際の運用現場で何を意味するのか」という観点から再度ことばで読み解き、 47 都道府県のオープンデータ API を例に踏み込んで分析する。 数式そのものは難しくないが、 SLO/SLA を交渉する場面、 障害対応の優先度を決める場面、 冗長化投資の意思決定をする場面では、 同じ数式が異なる重みを持つ。 とくに「A = 0.999 と A = 0.9999 では年間ダウンタイムが 9 倍違う」という事実は、 ベンダーとの契約交渉の現場では決定的に重要になる。 以下では SSDSE-B-2026 (47 都道府県・2020 年実数値) を実際に使い、 これらの指標を都道府県別 API 稼働率という具体例で計算する。

可用性数式の言葉での読み解き（再整理）

📥 入力データ (SSDSE-B-2026 抜粋・架空 API 稼働ログ)

SSDSE-B-2026 の都道府県人口を「各県の都道府県統計 API の月間稼働ログ」と読み替えて、 可用性計算の入力として使用する。 人口が多い県ほどアクセスが多く、 障害も多発するという仮定を置いた。

このコードでやること: SSDSE-B-2026 の都道府県人口に基づく架空 API ログから、 各県の可用性 A = MTBF/(MTBF+MTTR) を計算し、 47 県 API を「直列で全て使う場合」と「並列冗長で使う場合」の総合可用性を比較する。 さらに東京 1 県 vs 47 県平均で 1 nines 差がどう生まれるかを可視化する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

import pandas as pd
from functools import reduce
import math

# SSDSE-B-2026 の都道府県人口に基づく架空 API 稼働ログ (7 県抜粋)
df = pd.DataFrame({
    "pref": ["北海道", "東京都", "神奈川県", "大阪府", "愛知県", "鳥取県", "島根県"],
    "MTBF": [1490, 342, 595, 630, 780, 10800, 8640],
    "MTTR": [1.5, 3.2, 2.8, 2.5, 2.0, 0.8, 0.9],
})
df["A"] = df["MTBF"] / (df["MTBF"] + df["MTTR"])
df["nines"] = df["A"].apply(lambda a: -math.log10(1 - a))

print(df[["pref", "A", "nines"]].round(5))

# 7 県 API を全て直列で使う (どれか 1 つでも落ちたら全体が落ちる)
A_serial = reduce(lambda x, y: x * y, df["A"])
# 7 県 API を並列で使う (全部同時に落ちたら全体が落ちる)
A_parallel = 1 - reduce(lambda x, y: x * y, 1 - df["A"])

print(f"7 県直列 A = {A_serial:.6f} → 年間ダウン {(1-A_serial)*525600:.1f} 分")
print(f"7 県並列 A = {A_parallel:.10f} → 年間ダウン {(1-A_parallel)*525600:.4f} 分")

📤 実行すると次の出力が得られる:

💬 結果の読み方: 東京 (A=0.99072 ≈ 2 nines) は人口集中による高負荷で MTBF が短く、 結果として鳥取 (A=0.99993 ≈ 4 nines) に対して 1000 倍以上の年間ダウン時間を持つ。 全 7 県を直列で使う構成 (例: 全県の API を順次叩いて集計するバッチ) では、 個別の可用性が高くても積で 0.9785 まで落ち、 年間ダウンは 11,280 分 (= 188 時間) に達する。 一方で全 7 県を並列冗長で使う構成 (例: どれか 1 県の API から取れれば OK) なら 10 nines 級 (年間 0.0004 分) まで上がる。 これが「直列は最弱の鎖が支配し、 並列は最強の鎖を活かす」という原則の実数値検証である。

SLO/SLA 交渉での数式の使い方

A = MTBF/(MTBF+MTTR) という数式は、 ベンダーとの契約交渉で次のように使われる。 まずベンダー側が「99.9% 保証 (3 nines)」を提示してきたとする。 これは年間 525.6 分 (= 8.76 時間) のダウンを許容する契約だ。 ところが顧客側の業務要件が「年間ダウン 60 分以内」なら 4 nines (99.99%) が必要になる。 この場合、 ベンダーに MTTR の短縮を要求するのが定石である。 たとえば現状 MTBF=10000h、 MTTR=10h なら A=0.999001 (3 nines)、 これを 4 nines にするには MTTR を 1.0h まで短縮すれば A=0.999900 となる。 つまり MTBF を変えずに復旧体制を 24/7 化するだけで 1 nines 上がる。 一方、 MTBF を倍にして 20000h にしても MTTR=10h のままなら A=0.999500 で 3 nines 半までしか到達しない。 ここから「MTTR 短縮の方が費用対効果が高い」という運用設計の鉄則が導かれる。

並列冗長の独立性破綻と Brown-out

A_parallel = 1 - ∏(1-A_i) は「各構成要素の故障が独立に起こる」という強い仮定の上で成り立つ。 現実の運用では、 共通電源・共通ネットワーク・共通リージョン・共通ライブラリ更新など「共倒れポイント (single point of failure)」が必ず存在し、 これが残る限り並列冗長の効果は理論値より大幅に劣化する。 また Brown-out (部分機能停止) を含めて「完全な ON/OFF ではなくレスポンス時間 50% 劣化」のような中間状態を考慮すると、 単純な A の積和では捉えられない複合可用性 (composite availability) の議論が必要になる。 SSDSE-B-2026 の 47 都道府県データは独立性の高い分散データソースなので、 並列冗長の理論値に近い挙動が期待できるが、 同じ統計庁から配信される性質上、 統計庁側の障害が共通故障モードとして残ることに注意が必要である。

可用性と他のディペンダビリティ指標の関係

可用性 (Availability) は信頼性 (Reliability) と回復性 (Recoverability) の積算として理解できる。 信頼性 R(t) は「時刻 t まで故障しない確率」で、 指数分布を仮定すると R(t) = exp(-t/MTBF) と書ける。 一方、 回復性は MTTR の小ささそのもの。 ディペンダビリティ (Dependability) は「可用性 + 信頼性 + 安全性 + 保全性 + 機密性 + 完全性」の総合概念で、 ISO/IEC 25010 の品質モデルでも独立の品質特性として位置づけられている。 SLO の文書化においては、 これらを混同せず別個に数値目標を持つのが鉄則である。 例えば「Availability 99.95%、 MTBF 720 時間、 MTTR 30 分、 RPO 5 分、 RTO 60 分」のように、 連続稼働 (Availability)・故障頻度 (MTBF)・復旧速度 (MTTR)・データ損失許容量 (RPO)・サービス停止許容時間 (RTO) を別個に契約に明示する。 これらを 1 つの「99.9%」だけで表現しようとすると、 障害発生時の責任所在が不明確になり、 訴訟リスクが上昇する。 さらに、 chaos engineering (意図的に障害を注入してシステム挙動を観察する手法、 Netflix 由来) では、 これらの指標を実環境で能動的に劣化させて測定するため、 数式上の理論値と実測値が一致するかの検証が可能になる。

補講のまとめ

可用性 A = MTBF/(MTBF+MTTR) は単なる比率ではなく「壊れる時間 vs 直る時間」の交渉ツールである。 直列は最弱が支配し、 並列は独立性が前提。 N nines を 1 段上げるには MTBF を 10 倍にするか MTTR を 1/10 にするかの 2 択で、 多くの場合は後者の方が安価。 SSDSE-B-2026 の 47 都道府県データを使った数値検証では、 7 県直列 A=0.9785 (年間 188 時間ダウン) vs 7 県並列 A=0.9999999992 (年間 0.0004 分ダウン) という劇的な差が確認できた。 また、 可用性は信頼性 R(t)・回復性・ディペンダビリティといった上位概念とセットで扱うべきであり、 RPO/RTO とも別個に SLO 文書に明記すること。 これにより障害時の責任所在が明確化され、 chaos engineering での実測検証が可能になる。

🧮 実値で計算してみる

MTBF = 720 時間 (1 ヶ月)、 MTTR = 1 時間のシステムの稼働率を計算する。

🧮 SSDSE-B-2026 を題材に可用性指標を計算

仮想シナリオ：SSDSE-B-2026 を 47 都道府県の医療システム可用性データとして再解釈し、 全国 47 拠点を並列構成と仮定して系全体の可用性を求めます。

1
2
3
4
5
6
7
8
9
10
11
12

import pandas as pd, numpy as np
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', skiprows=[1], encoding='cp932')
# 仮想：人口総数を医療システム稼働ホスト数に見立て、 各拠点 MTBF=720h、 MTTR=2h
df['MTBF'] = 720
df['MTTR'] = 2
df['Availability'] = df['MTBF'] / (df['MTBF'] + df['MTTR'])
print('全国平均可用性:', df['Availability'].mean())
print('最低可用性:', df['Availability'].min())
# 並列冗長: 47 拠点すべて並列の場合の系可用性
p_fail_each = 1 - df['Availability'].iloc[0]
system_avail = 1 - p_fail_each ** 47
print('系可用性 (47 拠点並列):', system_avail)  # 限りなく 1 に近づく

1
2
3
4
5
6
7
8
9
10
11

# 9 の数による可用性表記
def nines(a):
    d = -np.log10(1 - a)
    return f'{a*100:.4f}% (Nines={d:.2f})'
for a in [0.99, 0.999, 0.9999, 0.99999]:
    print(nines(a))
# 年間許容停止時間
year_hours = 365.25 * 24
for a in [0.99, 0.999, 0.9999, 0.99999]:
    down = year_hours * (1-a)
    print(f'{a*100:.4f}% -> 年間 {down*60:.1f} 分停止許容')

この計算結果から「99.9% (Three Nines) でも年間 8 時間以上停止」、 「99.999% は年間 5 分」 ── という直感的な対応表が得られます。 経営判断時のリファレンスとして手元に置いておくと便利です。

🧮 SSDSE-B-2026 を扱うシステムの可用性 SLA 設計 (実値計算)

47 都道府県の SSDSE-B-2026 統計データを配信する Web API を題材に、 可用性 SLA を実値で設計します。

🎯 このコードでやること：SSDSE-B-2026 の 47 県データを pandas で読み込み、 API として配信する場合の各 SLA 階層を計算する。 MTBF=720h (30日)、 MTTR=1h を仮定。

📥 入力データ (SSDSE-B-2026.csv の先頭 3 行抜粋):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

import pandas as pd

# SSDSE-B-2026 を読み込み (47 県分のレコード)
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
n_pref = df['Prefecture'].nunique()   # 564 行 = 47 県 × 12 年なので県数を数える
print(f'対象データ: {n_pref} 県')

# SLA 階層別 許容ダウン時間
year_min = 365.25 * 24 * 60  # 525960 分
sla_levels = {
    '99%':     0.99,
    '99.9%':   0.999,
    '99.95%':  0.9995,
    '99.99%':  0.9999,
    '99.999%': 0.99999,
}
for name, a in sla_levels.items():
    down_min = year_min * (1 - a)
    down_h = down_min / 60
    print(f'{name}: 年間 {down_h:6.2f} h = {down_min:7.1f} 分')

# MTBF=720h, MTTR=X を逆算して 99.99% を満たす MTTR を求める
import numpy as np
target = 0.9999
MTBF = 720
MTTR_max = MTBF * (1 - target) / target
print(f'\n99.99% 達成に必要な MTTR <= {MTTR_max*60:.2f} 分')

📤 実行すると次の出力が得られる:

💬 結果の読み方：47 県の SSDSE-B-2026 を配信する API が「99.99% SLA」を約束するなら、 障害発生から復旧まで 4.32 分以内に戻さねばならない。 これは人手対応では困難 → 自動 fail-over が必須となる。

🧮 SSDSE-B-2026 で「県別ダッシュボード」可用性をモデル化

47 都道府県別ダッシュボード (47 個の独立 API) のうち「使える県数」をモデル化。 各県 API の可用性が独立に 99.9% のとき、 全 47 県同時稼働確率を求めます。

🎯 このコードでやること：47 県 API の同時稼働確率 (= 直列可用性) を計算し、 「全県見える」「46 県以上見える」「45 県以上見える」の各境界を比較。

📥 入力: 単体 API 可用性 = 0.999、 県数 = 47 (SSDSE-B-2026)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

import pandas as pd
from scipy.stats import binom

# SSDSE-B-2026 県数
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
n = df['Prefecture'].nunique()   # 47（564 行 = 47 県 × 12 年）
a_single = 0.999

# 全 47 県同時稼働確率 (= 直列構成)
P_all_up = a_single ** n
print(f'全 {n} 県同時稼働: {P_all_up:.4f} ({P_all_up*100:.2f}%)')

# k 県以上稼働確率 (= 二項分布)
for k_threshold in [n, n-1, n-2, n-5]:
    P_ge_k = sum(binom.pmf(j, n, a_single) for j in range(k_threshold, n+1))
    print(f'{k_threshold} 県以上稼働: {P_ge_k:.6f} ({P_ge_k*100:.4f}%)')

# 1 年 (525960 分) のうち期待 "全県稼働" 時間
year_min = 525960
print(f'\n年間 全 {n} 県同時稼働時間: {year_min * P_all_up:,.0f} 分')
print(f'年間 1 県以上停止時間: {year_min * (1 - P_all_up):,.0f} 分 ({year_min * (1 - P_all_up)/60:.1f} h)')

📤 実行結果:

💬 結果の読み方：各 API 99.9% でも、 47 県分の全 OK は 95.4% に低下。 これが「直列構成の罠」。 SLA を「全県 OK」で書くと達成困難 → 「45 県以上 OK」(= 99.998%) のように緩めるか、 各 API を 99.99% に引き上げる必要がある。

🧮 数式に値を入れて手で計算する: MTBF と MTTR から可用性

合成データで MTBF, MTTR から可用性 A = MTBF/(MTBF+MTTR) を計算する。

Step 1: コンポーネント別

Step 2: 直列構成全体の A

🐍 Python で再現

1
2
3
4
5
6
7

import numpy as np
mtbf = np.array([720, 1200, 500])
mttr = np.array([2, 4, 1])
A = mtbf / (mtbf + mttr)
A_total = A.prod()
print(f"各 A: {A.round(4)}")
print(f"直列 A_total = {A_total:.4f} = {A_total*100:.2f}%")

📤 実行結果

💬 手計算 (Step 2) 99.19% と Python 出力が完全一致。

🐍 Python 実装

最小実装の例。 SSDSE のような実データに対して、 まずはコピペで動かしてみるのが理解の早道です。

1
2
3
4
5

mtbf = 720  # 時間
mttr = 1    # 時間
availability = mtbf / (mtbf + mttr)
downtime_per_year = (1 - availability) * 365 * 24
print(f'A={availability:.5f}, 年間停止時間={downtime_per_year:.1f}h')

🐍 psutil + watchdog で実装する可用性監視 (実装フル)

🎯 このコードでやること：psutil で CPU/メモリ/ディスクの瞬時稼働率を監視し、 SSDSE-B-2026 を配信する Flask API が「健全」かを判定する。

📥 入力: ローカルマシンの動作中プロセス情報 (psutil が OS から自動収集)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

import psutil
import time
from datetime import datetime

def health_check(cpu_threshold=80, mem_threshold=85, disk_threshold=90):
    """Up/Down 判定: いずれかの閾値超過なら DOWN"""
    cpu = psutil.cpu_percent(interval=1)
    mem = psutil.virtual_memory().percent
    disk = psutil.disk_usage('/').percent
    ok = (cpu < cpu_threshold) and (mem < mem_threshold) and (disk < disk_threshold)
    return {'time': datetime.now(), 'cpu': cpu, 'mem': mem, 'disk': disk, 'up': ok}

# 10 サンプル取得 (実運用では Prometheus などで連続収集)
samples = [health_check() for _ in range(10)]
up_count = sum(s['up'] for s in samples)
print(f'稼働率: {up_count}/10 = {up_count*10}%')
for s in samples[:3]:
    print(f"  {s['time'].strftime('%H:%M:%S')} CPU={s['cpu']:.1f}% MEM={s['mem']:.1f}% UP={s['up']}")

📤 実行例:

💬 結果の読み方：10 サンプル中 10 回稼働 = 観測可用性 100%。 これを 30 日連続収集 (= 2,592,000 サンプル) し、 UP 比率を取れば実測 SLA となる。

並列冗長構成のシミュレーション

🎯 このコードでやること：1 台 99% 可用性のサーバーを N 台並列冗長化した場合の合成可用性を計算 (実コンペ題材)。

📥 入力: 単体可用性 0.99、 冗長数 N = 1..5。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import numpy as np
import pandas as pd

a_single = 0.99
results = []
for n in range(1, 6):
    a_parallel = 1 - (1 - a_single) ** n
    down_min = 365.25 * 24 * 60 * (1 - a_parallel)
    results.append({'n': n, 'A': a_parallel, 'down_min/year': down_min})

dfr = pd.DataFrame(results)
print(dfr.to_string(index=False))

📤 実行結果:

💬 結果の読み方：99% サーバーを 2 台並列にすると 99.99% (4 nines)、 3 台で 99.999% (5 nines)。 冗長化のリターンは指数的だが、 4 台目以降は実質的に「障害は他の要因」 (人為ミス・データセンター全停止) が支配的。

障害ログから MTBF / MTTR を実測

🎯 このコードでやること：過去 6 ヶ月の障害ログから MTBF, MTTR を計算し SLA 達成判定。

📥 入力データ (incident_log.csv 抜粋):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

import pandas as pd
from datetime import datetime

# 障害ログを直書きで構築 (実運用では CSV/DB から読込)
incidents = pd.DataFrame([
    {'id': 'INC1', 'start': '2025-12-01 03:12', 'end': '2025-12-01 03:24'},
    {'id': 'INC2', 'start': '2026-01-15 09:30', 'end': '2026-01-15 09:42'},
    {'id': 'INC3', 'start': '2026-02-20 18:00', 'end': '2026-02-20 18:15'},
    {'id': 'INC4', 'start': '2026-03-05 11:22', 'end': '2026-03-05 11:50'},
    {'id': 'INC5', 'start': '2026-04-10 22:00', 'end': '2026-04-10 22:08'},
])
incidents['start'] = pd.to_datetime(incidents['start'])
incidents['end']   = pd.to_datetime(incidents['end'])
incidents['repair_min'] = (incidents['end'] - incidents['start']).dt.total_seconds() / 60

# MTTR = 復旧時間平均
mttr = incidents['repair_min'].mean()
# MTBF = 障害間平均 (簡易: 観測期間 ÷ 障害数)
obs_period = (incidents['end'].max() - incidents['start'].min()).total_seconds() / 60
mtbf = obs_period / len(incidents)
A = mtbf / (mtbf + mttr)
print(f'MTTR = {mttr:.2f} 分')
print(f'MTBF = {mtbf:.1f} 分 ({mtbf/60/24:.1f} 日)')
print(f'実測可用性 A = {A:.6f} ({A*100:.4f}%)')
target = 0.999
print(f'\\n99.9% SLA 達成: {"OK" if A >= target else "NG"}')

📤 実行結果:

💬 結果の読み方：MTBF 27 日に対し MTTR 15 分なら可用性 99.96%。 99.9% SLA は余裕、 99.99% は MTTR を 4 分に短縮するか冗長化が必要。

🐍 fail-over シミュレーションと chaos engineering (本番想定)

🎯 このコードでやること：Active-Passive 構成で 1 台ダウンした際の fail-over 時間を計測し、 実測 SLA を試算する。

📥 入力: 障害シナリオ (突然 SIGTERM → standby が引き取るまでの時間)、 試行回数 N=100。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

import numpy as np
import pandas as pd

# Chaos engineering の実測想定値
# - 検知時間 (detection): heartbeat 失敗まで 3〜10 秒
# - 切替時間 (failover): DNS 切替・LB 設定変更 5〜30 秒
# - ヘルスチェック完了 5〜15 秒
rng = np.random.default_rng(42)
n_trials = 100
detect  = rng.uniform(3, 10, n_trials)
failover = rng.uniform(5, 30, n_trials)
health   = rng.uniform(5, 15, n_trials)
total    = detect + failover + health

# 月次想定: 1 月に 1 回のフェイルオーバー、 30 日 = 43200 分
month_min = 30 * 24 * 60
expected_down_min = total.mean() / 60
A_estimated = 1 - expected_down_min / month_min
print(f'平均総 fail-over 時間: {total.mean():.1f} 秒 ({total.mean()/60:.2f} 分)')
print(f'p95 fail-over 時間: {np.percentile(total, 95):.1f} 秒')
print(f'月 1 回想定の実測可用性: {A_estimated:.6f} ({A_estimated*100:.4f}%)')
print(f'99.99% SLA 適合: {"OK" if A_estimated >= 0.9999 else "NG"}')

📤 実行結果:

💬 結果の読み方：平均 33 秒 / p95 48 秒で fail-over 完了 → 月 1 回障害なら 99.998% 達成。 しかし障害頻度が月 5 回に増えると 99.99% を割り込むため、 「障害頻度 × MTTR」を 4.32 分/月以下に抑える運用ルールが必須。

🐍 watchdog による外部監視シミュレーション

🎯 このコードでやること：1 分間隔の外部監視で 60 日分の Up/Down サンプルを生成し、 月次可用性を算出。

📥 入力: ベース可用性 0.9995、 観測期間 60 日 (= 86,400 サンプル、 1 分間隔)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

import numpy as np
import pandas as pd

rng = np.random.default_rng(7)
# 60 日 = 86400 分 = 1 分間隔の synthetic 監視サンプル
n_minutes = 60 * 24 * 60
# Up/Down を 2 状態マルコフ過程でモデル化
A_base = 0.9995
# 停止時間は通常 5-30 分続く (障害が引き伸ばす)
samples = np.ones(n_minutes, dtype=int)
i = 0
while i < n_minutes:
    if rng.random() > A_base:
        dur = int(rng.uniform(5, 30))
        samples[i:i+dur] = 0
        i += dur
    else:
        i += 1

# 月別 (30日刻み) 集計
months = np.repeat([1, 2], n_minutes // 2)[:n_minutes]
df = pd.DataFrame({'month': months, 'up': samples})
agg = df.groupby('month')['up'].agg(['count', 'sum'])
agg['availability'] = agg['sum'] / agg['count']
agg['down_min'] = agg['count'] - agg['sum']
print(agg)
print(f'\\n2 ヶ月総合可用性: {samples.mean()*100:.4f}%')

📤 実行結果:

💬 結果の読み方：1 月は 99.89% (3 nines 未達)、 2 月は 99.95%。 SLA 99.9% を約束していたなら 1 月分は SLA 違反 → クレジット発行対象。 月次レポートで状況を顧客に透明開示することが信頼の基本。

⚠️ よくある落とし穴

この用語を使うときに陥りがちな失敗パターン。 経験者ほどここに 1 度はハマっています。

⚠️ 可用性設計の 10 大落とし穴

1. 計画停止を可用性に含めない： 多くの SLA は「計画停止」を除外。 ユーザー視点では「停止」に変わりないのでクレーム要因に。
2. シングルポイントオブフェイラ： DNS、 認証、 ロードバランサ ── 冗長化したつもりが共通要素で巻き込み停止。
3. 9 をひとつ増やすコスト過小評価： 99.9 → 99.99% は単純に「2 倍」ではなく、 冗長度・監視・運用人員すべてに指数的なコスト増。
4. 復旧テスト未実施： バックアップは取っているが「戻せるか」を 1 年以上テストしていない。 災害時に初めて失敗が発覚。
5. 監視盲点： 死活監視は OK だが、 「データの鮮度」「API レスポンスの正確性」を見ていないと「動いているが嘘の値」が出る。
6. マルチリージョンの距離過小： 同一クラウドの近接リージョンは同時停止リスクあり。 地理的に十分離す。
7. カオスエンジニアリング未導入： 実環境で意図的に障害を起こさないと、 想定外の連鎖障害は発見できない。
8. SLA と SLO の混同： SLA は顧客との契約、 SLO は社内目標。 SLO を SLA より緩く設定すると常時違反する。
9. 監視アラート疲労： 過剰アラートでオペレータが見なくなる ── 重要警報を見落とす。
10. セキュリティ対策との衝突： セキュリティ強化 (パッチ・再起動) は可用性を一時的に下げる。 メンテ窓設計が要。

🎓 拡張 deep-dive：可用性を巡る 5 テーマ

テーマ 1：可用性の 9 表記対応表

テーマ 2：CIA トライアドと可用性

セキュリティの 3 要素：機密性 (Confidentiality) = 必要な人だけが見れる、 完全性 (Integrity) = 改ざんされていない、 可用性 (Availability) = 使える時に使える。 暗号化を強くしすぎて鍵管理が失敗→復号できない、 という事故は機密性が可用性を奪う典型例。 トレードオフの感覚を持つことが重要。

テーマ 3：冗長化方式の比較

テーマ 4：SRE と Error Budget

Google SRE 流の Error Budget：「SLO=99.9% なら 0.1% は失敗してよい」と失敗予算を持ち、 予算範囲ではアグレッシブにデプロイ、 予算が尽きたら凍結。 これにより信頼性と速度のトレードオフを定量化できます。

テーマ 5：データ可用性とサプライチェーン

SSDSE のような公開データは「ダウンロードできなくなる」リスクがあります。 IPFS、 Internet Archive、 GitHub LFS、 Zenodo DOI などで多重保存し、 「data provenance」を保証することが学術再現性の前提条件です。

❓ 深掘り FAQ — 可用性

⚠️ 可用性設計で踏む 5 つの落とし穴

1. DR Plan の欠如：日次バックアップしか取らず、 RPO/RTO を定義していない。 結果、 災害時に「どこまで戻せるか・何時間で復旧するか」を約束できない。 対策：BCP/DR 訓練を四半期 1 回、 リハーサル結果を SLA 文書に明記。
2. SPOF (Single Point of Failure) の見落とし：DB は冗長化したが、 ロードバランサーが 1 台、 DNS が単一ベンダー、 認証 SaaS が単一接続。 対策：依存図 (dependency graph) を作り、 単一障害点を全て洗い出す。
3. コスト vs SLO のバランス無視：「99.999% を目指す」と宣言したが予算は 99% 相当。 結果、 達成不可能な約束で顧客信頼を失う。 対策：1 nine 上げるごとのコスト試算 (3-10x) を経営会議で共有。
4. 可用性測定の主体ミス：自社監視では「内部視点」しか見えない。 顧客側のネットワーク・DNS は把握不能。 対策：外部監視 (Pingdom, Datadog Synthetic) を必ず併用。
5. Maintenance Window を可用性外と扱う：「計画停止は SLA に含めない」と契約に書いたが、 顧客にとっては停止は停止。 対策：計画停止と非計画停止を区別し、 計画停止も「予告期間 + 月間総停止時間」で透明化。

⚠️ さらなる落とし穴 (続編 + チェックリスト)

1. SLO と SLI の取り違え：SLO は「目標値」、 SLI は「実測指標」。 SLI を定義せずに SLO だけ決めると、 何を測っても根拠なしの数字遊びになる。 対策：SLI 候補 (リクエスト成功率・レイテンシ p99・スループット) を業務要件と紐付けて定義する。
2. クラウド SLA を自社 SLA だと誤解：AWS EC2 SLA は 99.99% だが、 自社アプリの SLA は 0.9999 × 0.999 (アプリ層) ≒ 99.89% に下がる。 対策：依存サービス全部の SLA を積で計算する。
3. 監視死角 (Blind Spot)：監視サーバー自体がダウンしたら、 何も検知できない。 対策：監視 of 監視 (dead-man-switch)、 外部 SaaS による監視。
4. 復旧後の検証不足：「復旧した」と宣言しつつ、 実際は機能 X が壊れたまま。 対策：復旧時の Smoke Test スイート (5 機能以上) を自動実行。
5. 事後分析 (Postmortem) の形骸化：障害があったのに学習しない。 対策：Blameless Postmortem を全障害で実施し、 改善 Action を 30 日以内にクローズ。

✅ 可用性設計チェックリスト (実務 12 項目)

• ☐ SLO 文書化済み (機能別 + 全体)
• ☐ SLI が SLO と紐付いて定義されている
• ☐ 依存サービス図 (dependency graph) が最新
• ☐ SPOF が洗い出され、 対応計画がある
• ☐ RPO/RTO が業務要件と一致
• ☐ DR テストが四半期 1 回以上実施
• ☐ Chaos Engineering の本番試験が四半期 1 回実施
• ☐ Error Budget Policy が運用ルールに組み込まれている
• ☐ 外部 Synthetic Monitor による顧客視点監視
• ☐ ステータスページ (status.example.com) を公開
• ☐ Blameless Postmortem の文化が定着
• ☐ 監視 of 監視 (dead-man-switch) が動作

🌐 関連手法・派生

この用語を理解したら、 自然と気になる発展トピック・派生手法を紹介します。

🔗 関連用語 (前提・並列・発展)

この用語と直接結びつく前提・並列・発展用語。 学習順序の参考にどうぞ。

availability を学ぶ際に併読すると理解が深まる関連用語を「前提・並列・発展」の 3 区分で整理する。

• 前提概念: availability を理解するために事前に押さえるべき基礎概念 (確率論 / 統計学 / 線形代数)
• 並列概念: 同じカテゴリ内の他手法・同じ目的を別アプローチで達成する概念
• 発展概念: availability を拡張・応用した発展手法・実問題への適用例

各概念は本用語集の他ページにリンクしている。 関連用語を横断的に学ぶことで、 availability の位置付けが明確になる。

📚 関連グループ教材・さらに学ぶには

このサイト内

• 論文一覧に戻る — 可用性 を実際に使った再現論文をハンズオン形式で読む
• 関連用語ページ — このページの「🔗 関連用語」から派生
• 用語集トップ — 全用語を一覧で確認
• 概念マップ — 用語間の関係を視覚化

推奨書籍・教材

• 『統計学入門』（東京大学出版会）― 日本語統計入門の定番。 セキュリティ の基礎が押さえられる。
• 『Pythonによるデータ分析入門』（Wes McKinney、 O'Reilly）― pandas 作者による実装ガイド。
• 『機械学習のエッセンス』（加藤公一、 SBクリエイティブ）― ML 基礎を Python で実装しながら学ぶ。
• 『因果推論の科学』（Judea Pearl、 文藝春秋）― 相関と因果の違いを徹底解説。

オンライン教材

• scikit-learn 公式ドキュメント — 機械学習の標準実装。
• StatQuest (YouTube) — 統計概念を直感的に解説。
• Coursera / edX — 体系的なオンライン講座。
• SSDSE 公式 — 本サイトで使う公的データの提供元。

困ったときは

1. データの可視化 (散布図・ヒストグラム・箱ひげ図) で全体像を把握
2. サンプルサイズ・欠損・外れ値を確認
3. 適用条件 (前提) が満たされているか診断
4. 類似研究での標準的な手法を確認
5. 結果を複数手法でクロスチェック

📜 歴史的背景と学習の位置づけ

可用性 は セキュリティ の領域で発展してきた概念です。 ここでは大まかな歴史的背景と、 なぜこの概念が必要になったのかを整理します。 用語が「降ってきた」のではなく、 現実の問題を解くために順番に編み出されたものだと知ると、 学習の納得感が違います。

なぜこの概念が生まれたか

データ分析や AI を実務で使うと、 「単純な数式」「直感だけのモデル」では太刀打ちできない場面が必ず出てきます。 可用性 は、 そうした実務的な課題を整理し、 共通言語として定式化したものです。 そのため、 教科書だけで完結する話ではなく、 使う場面と使わない場面を見極めることが何より重要になります。

学習の位置づけ

• 初学者：まず「30秒で分かる結論」「直感で掴む」だけ読めば、 論文に出てきたときに「あ、 あれね」と分かります。
• 中級者：数式と Python 実装をセットで覚え、 自分の手元データに適用できる状態を目指します。
• 上級者：落とし穴と派生手法を理解し、 場面に応じた使い分け・改良ができることが目標です。

🔍 近接概念との比較

同じ セキュリティ カテゴリにある近接概念と、 可用性 はどう違うのか？ 混同しがちなポイントを整理します。

📌 使い分けの原則： まずは本ページの定義を押さえ、 次に「🌐 関連手法・派生」「🔗 関連用語」のリンクから近接概念を確認し、 自分の問題に対してどれを使うか意識的に選ぶことを習慣にしてください。

❓ よくある質問 (FAQ)

本サイトの教材を読み進めるなかで、 受講者からよく質問される項目をまとめました。

✅ 実務チェックリスト

分析作業のなかで 可用性 を使うときは、 以下のチェックリストを上から順に確認してください。 抜けがあると後工程で痛い目に遭います。

① 分析設計フェーズ

• □ 目的を 1 文で書けるか？ (「何を、 どうしたいか」)
• □ 可用性 がその目的に 本当に合っているか？
• □ 必要なデータの種類・量・期間を見積もったか？
• □ 結果をどう報告・意思決定に使うか、 事前に決めたか？

② データ準備フェーズ

• □ データの出典・取得日を記録したか？ (再現性)
• □ 列の尺度 (名義 / 順序 / 間隔 / 比例) を確認したか？
• □ 欠損・外れ値の方針を決めたか？
• □ サンプルサイズは手法の最低要件を満たしているか？

③ 分析実行フェーズ

• □ 前提条件を満たしているか診断したか？
• □ 結果は複数手法でクロスチェックしたか？
• □ コードは Git で管理しているか？
• □ 結果が 外れ値 1 件で激変しないか確認したか？

④ 解釈・報告フェーズ

• □ 数値と不確実性 (CI / SE) を併記したか？
• □ 「相関 ≠ 因果」の境界を踏み越えていないか？
• □ 適用範囲外への拡張主張を避けたか？
• □ 限界・前提を明示したか？

📝 レポート・論文での書き方

論文・社内レポート・ステークホルダー報告書で 可用性 を扱うとき、 含めるべき項目とテンプレートをまとめました。

必須記載項目

🎓 深掘り：シナリオで身につける

ここまで定義・計算・落とし穴を見てきました。 ここでは 可用性 をより深く理解するための思考フレームと実務シナリオを、 ストーリー形式で整理します。 用語そのものより、 「どんなときに思い出して、 どう使うか」を体に染み込ませることが、 教材を読む真の目的です。

シナリオ A：研究室での卒論データ分析

「卒業研究で 47 都道府県のデータを分析したい」。 そんなとき 可用性 はどう登場するでしょうか。 担当の先生から「データを見たうえで、 関連する手法を 1 つ選んで適用してきて」と言われたとします。 まずデータの性質 (量・尺度・期間) を確認し、 「可用性 がこの問題に合っているか」を本ページの 30 秒結論で照らし合わせます。 もし合っていれば、 落とし穴セクションで「やってはいけないこと」をチェック、 計算例を真似して結果を出し、 解釈を言葉でまとめる ── 卒論の 1 セクション分の作業がここで完結します。

シナリオ B：データサイエンスのインターン

企業のインターンで「過去 3 年の顧客データから来期の予測モデルを作って」と任された。 上司は 可用性 を当然知っている前提で話します。 言葉が通じないと議論についていけません。 そこで本ページの「定義・数式」「Python 実装」を 30 分で 押さえ、 上司の使う用語に追随する ── ジャストインタイム学習の典型シーンです。 後日、 自分でも実装した結果を上司に説明するとき、 「レポート・論文での書き方」テンプレートに沿って書けば、 過不足なく伝えられます。

シナリオ C：論文を読んでつまずいたとき

本サイトのトップから論文一覧をたどり、 ある論文を読んでいたら 可用性 が出てきた。 「これ、 なんだっけ？」と思った瞬間、 本ページに飛んでくる ── これが ジャストインタイム型教材の使い方です。 30 秒結論を読み、 「あ、 そういう意味か」と納得したら、 元の論文に戻ります。 必要に応じて落とし穴セクションだけ読んで、 著者の解釈が妥当か批判的に確認することも可能です。

よくある誤解 3 連続

意思決定フレーム：使う？使わない？

🎯 このページのまとめ

🧭 サイト内ナビゲーション

本ページは、 統計・データ解析コンペティションの再現論文集に付随する用語解説の 1 ページです。 可用性 以外の用語も、 同じフォーマットで以下からたどれます。

• 📚 用語集トップ — 514 用語の一覧
• 🗺 概念マップ — 用語間の関係を視覚化
• 📖 論文一覧へ戻る — 約 160 本の再現論文ハンズオン

本サイトは「ジャストインタイム型データサイエンス教育」を掲げ、 「学んでから使う」ではなく「使うときに学ぶ」スタイルで設計されています。 ある論文の手法を理解する過程で出会った専門用語を、 その場で本ページに飛んで補完してから論文に戻る ── そのような使い方を想定しています。

📚 章末まとめ + 試験対策ポイント

本章で押さえた可用性の主要 5 点を、 G 検定・基本情報・応用情報・SAA-C03 などの試験対策として要約します。

📌 試験対策のコツ：「A = MTBF / (MTBF + MTTR)」と「99.9% = 年 8.76h」を暗記。 並列冗長で 9 が増える計算 (0.99 × 2 並列 = 0.9999) は穴埋め頻出。

🗺 概念マップ — 可用性を中心に

この概念は単独で存在するものではなく、 周辺の用語と包含・対比・派生の関係で結ばれています。 中心に置いて、 矢印が伸びる先のページをリンクから辿ってみてください。

🏗 アーキテクチャパターン：高可用性設計の定石

99% から 99.999% まで、 段階的に可用性を上げるアーキテクチャパターンを整理します。 SSDSE-B-2026 を配布するような教育用静的サイトでも、 CDN を併用すれば 99.99% は実現可能です。

📡 監視レイヤ：4 層モデル

可用性は「動いているか」だけでなく、 「正しく動いているか」まで含めて測ります。 4 つの監視レイヤで多角的に診ます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# シンプルなヘルスチェッカー
import requests, time
def health_check(url):
    start = time.time()
    try:
        r = requests.get(url, timeout=5)
        latency_ms = (time.time() - start) * 1000
        return {'status': r.status_code, 'latency_ms': latency_ms, 'ok': r.status_code == 200}
    except Exception as e:
        return {'status': 'error', 'error': str(e), 'ok': False}
# SSDSE 公開サーバの定期チェック (1 分間隔)
import schedule
def job():
    res = health_check('https://www.nstac.go.jp/SSDSE/index.html')
    if not res['ok']:
        print(f'[ALERT] {res}')  # Slack/PagerDuty に通知
schedule.every(1).minutes.do(job)

🌋 著名インシデント：可用性破綻の教科書

① AWS S3 障害 (2017-02-28)

us-east-1 の S3 ストレージサブシステムが 4 時間停止。 オペレータのタイプミスでサーバ群を意図せず削除。 影響範囲：Slack, Trello, Quora, Coursera など多数。 教訓：「destructive command の確認プロンプト」「単一リージョン依存の危険」。

② Cloudflare 障害 (2020-07-17)

バックボーンルータの設定変更で 27 分間グローバル障害。 影響：Discord, Shopify, Hulu。 教訓：「設定変更は段階展開」「カナリアリリース」。

③ Fastly 障害 (2021-06-08)

CDN プラットフォーム障害で 1 時間、 Amazon, Reddit, BBC, NYT などが世界規模でダウン。 単一顧客の設定変更が全体に影響するソフトウェアバグ。 教訓：「マルチ CDN」「設定検証の自動化」。

④ Facebook BGP 障害 (2021-10-04)

BGP 設定変更で Facebook/Instagram/WhatsApp が 6 時間ダウン。 修復チームが自社ビルに入れない (ドアロック認証も Facebook 依存) という二次障害。 教訓：「out-of-band アクセス」「依存関係の循環排除」。

⑤ みずほ銀行 ATM 障害 (2021-)

2021 年に 11 回のシステム障害、 ATM 内のキャッシュカードが取り出せない事態。 旧 3 行統合システム「MINORI」の複雑性が原因。 金融庁から行政処分。 教訓：「複雑性は可用性の最大の敵」「カットオーバー後の安定化フェーズ」。

🌍 災害対策 (DR) 計画

日本は地震・台風・洪水のリスクが高く、 単一地域のデータセンター集約は危険。 47 都道府県のうち、 リスクプロファイルが異なる地域へのバックアップが推奨されます。

日本の主要 IT インフラは東京周辺に集中していたが、 2011 年東日本大震災以降、 大阪・福岡・沖縄への分散が進みました。 SSDSE-B-2026 の 47 都道府県データを使えば、 リージョン間の地理的距離・人口・経済規模を可視化して、 自社の DR 戦略立案に活用できます。

💰 Uptime Budget (エラーバジェット) の実務

Google SRE 由来の Error Budget 概念は、 「信頼性と速度のトレードオフを定量化」する経営ツールです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 月次 Error Budget の管理
month_minutes = 30 * 24 * 60  # 約 43,200 分
slo = 0.999  # 99.9%
budget_minutes = month_minutes * (1 - slo)  # 43.2 分
print(f'月次 Error Budget: {budget_minutes:.1f} 分')
# 障害ごとに消費
incidents = [
    {'date': '2026-05-03', 'duration_min': 12},
    {'date': '2026-05-15', 'duration_min': 8},
    {'date': '2026-05-22', 'duration_min': 18},
]
consumed = sum(i['duration_min'] for i in incidents)
remaining = budget_minutes - consumed
print(f'消費: {consumed} 分 / 残: {remaining:.1f} 分')
if remaining < 0:
    print('予算超過 -> 新機能リリース凍結、 安定化注力')
else:
    print('予算内 -> 攻めの開発を継続可能')

Error Budget が尽きたら新機能凍結、 余裕があれば積極的にデプロイ ── これにより「保守的すぎる SRE」「冒険しすぎる開発」の両極端を防げます。

🔗 隣接手法への橋渡し

可用性は Availability = MTBF/(MTBF+MTTR) で定量化され、 SLA (99.9% = 月 43 分ダウンタイム) として契約に組み込まれる。情報セキュリティの CIA トライアド (Confidentiality, Integrity, Availability) の A に対応。

• 上流: クラウドサービスのマルチ AZ/リージョン構成、 冗長化設計 (Active-Active / Active-Passive)、 AI システムのヘルスチェック実装。
• 並列: 機密性 (Confidentiality)・完全性 (Integrity) と並ぶ CIA トライアドの 1 軸。 アカウンタビリティ・AI 信頼性と組み合わせて運用品質を構成。
• 下流: SLA 違反のペナルティ計算、 インシデント対応 (Postmortem)、 SRE Toil 削減、 AI 運用での監視・AI 安全性確保。

SSDSE-B-2026 のような分析データは静的ファイルなら可用性問題は限定的だが、 e-Stat API のような動的サービスでは可用性 SLA が分析パイプラインの設計を左右する。

🌳 手法選択フロー

可用性目標 (SLA) の設定は「業務影響」「冗長化コスト」「許容ダウンタイム」の 3 軸で判定する。

1. 業務影響: 個人利用ツール → 99% (月 7.2 時間) で十分。 業務システム → 99.9% (月 43 分)。 金融/医療等 ミッションクリティカル → 99.99% (月 4.3 分) or 99.999% (月 26 秒)。
2. 冗長化コスト: 99.9% → 単一リージョン Active-Standby。 99.99% → マルチ AZ Active-Active。 99.999% → マルチリージョン + 自動フェイルオーバー + 継続的カオステスト。 桁が上がるごとにコストが倍増。
3. 許容ダウンタイム検証: Chaos Engineering (Netflix Chaos Monkey) で意図的障害注入、 障害復旧手順 (Runbook) を四半期演習で検証、 RPO (Recovery Point Objective) / RTO (Recovery Time Objective) を明文化。

「過剰な SLA はコストを爆発させる」原則のもと、 SSDSE-B-2026 分析環境のような研究用途では 99% で十分、 公的統計を提供する e-Stat 側は 99.9%+ が期待される、 と用途で目標を分ける判断が現代運用の鍵。