話題 2026年9月17日

「稼働率99%」表示はもう古い? 海外エンジニアの間で議論に

姉妹サイトの新着

即まとch5ch/2chの話題まとめ

Xbox Game Passのデイワン配信廃止、マイクロソフトが明確に否定せず新作ラーメン経営ゲーム、9月28日に早期アクセス　5ch「元祖はチャルメラ」

日本尋寶圖日本旅行を繁体字で

酎Hi到底是什麼?日本罐裝調酒文化與必喝清單 Onitsuka Tiger與日系球鞋品牌購買指南：老虎鞋迷的日本血拚地圖

JapanReacts日本の話題を英語で

5,116 Apply for National Civil Servant Exam Aimed at Japan’s ‘Employment Ice Age’ Generation — 5ch: ‘Even 3,000 Would Be Brutally Competitive’Country Girls gathered cute members but still couldn’t break through — 5ch: ‘They were just ahead of their time’

他サイトの新着

Hacker Newsで、サービスの稼働率をパーセントで示す慣習に疑問を投げかけるブログ記事が話題になった。投稿は「GitHub Actions稼働率98.31%」ではなく「過去30日で12時間影響」と表記すべきだと提案する内容。これに対しコメント欄では、パーセント表記の分かりやすさを支持する声と、言い換えても本質的な情報量は変わらないという反論が交錯した。さらに実際のSLA契約で「99.9999%(6ナイン)」を求められた事例も紹介され、契約上の稼働率要求が妥当かどうかをめぐっても意見が分かれた。

アップタイムのパーセント表示、もうやめないか?

出典: blog.jim-nielsen.com / 元記事はこちら

5 海外の名無しさん 2026-09-16 16:08

パーセント自体はどうでもいいと思う。でも業界によっては『99%』と『99.999%』の差が数百万ドル単位の話になるから、顧客向けにはこの形式で公表されている。

11 海外の名無しさん 2026-09-16 16:14

『30日中12時間』って言い方は、問題を薄めて見せてるだけな気がする。パーセント表記もそのままでいいから、それよりGitHubは稼働率そのものを直してほしい。

12 海外の名無しさん 2026-09-16 16:14

今のサービスはどんどん相互接続が進んでるから、ダウンタイムがちゃんと計測できてるのかも怪しい。細かく計測してるところもあれば、自社より上流・下流のプロバイダの障害時間を合算してないところもある。

14 海外の名無しさん 2026-09-16 16:18

業界全体で『障害』や『性能低下』の定義が統一されない限り、この手の議論はそもそも意味がない。

29 海外の名無しさん 2026-09-16 16:30

銀行や通信みたいな一部の業界では、少なくとも自分の国では規制上の定義がちゃんとある。

15 海外の名無しさん 2026-09-16 16:13

これはいつも面白いよね。ダウンタイムを対数グラフで見せてほしいもんだ。

16 海外の名無しさん 2026-09-16 16:15

この手の指標って契約書の中じゃほぼ意味をなさないことが多い。うちは顧客から『3〜6ヶ月間で99.9999%(6ナイン)』を要求されたことがある。違反したら(こちらのクラウド側の障害でない限り)返金する契約で、これは約7.5秒しか許されない計算、しかも150万ドル規模の契約だった。これを法外だと思うのは自分だけか?

30 海外の名無しさん 2026-09-16 16:22

契約なんだから交渉すればいい話では?非現実的だと分かってて合意したなら、それはサービスをタダで提供すると約束したのと同じ。

31 海外の名無しさん 2026-09-16 16:21

リアルタイム取引の業界で働いてたけど、全然法外じゃない。むしろ妥当だと思う。その条件で合意して信頼性を求めるなら、信頼性が守られなかった分は請求して当然。SLAには喜んで割増料金を払うけど、その分きちんと守ってもらわないと意味がない。

19 海外の名無しさん 2026-09-16 16:15

『-log10(1 – 稼働率)』で計算すればいいのでは。

20 海外の名無しさん 2026-09-16 16:25

パーセント表示の利点は、単純にわかりやすいということ。

21 海外の名無しさん 2026-09-16 16:22

『GitHub Actionsの稼働率98.31%』の代わりに『過去30日で12時間影響あり(稼働率98.31%)』にしよう、という提案も同じくらい役に立たない。12時間のダウンタイムは、1回12時間止まった場合でも、5分間の障害が144回起きた場合でも同じ数字になるけど、ユーザー体験は全く違う。結局グラフで見せるのが一番わかりやすい。

24 海外の名無しさん 2026-09-16 16:09

この記事の言いたいことは何なんだろう。『みんなナイン表記を使うべき』ってこと?それなら賛成。でも企業は自分たちを悪く見せるようなことをする気はない。あと、この文章、AIが書いた感じがしないか?

34 海外の名無しさん 2026-09-16 16:15

いや、Jimは普通に文章がうまい人だし、むしろ昔からAIには懐疑的なタイプだよ。

他サイトの新着

25 海外の名無しさん 2026-09-16 16:15

『過去30日で12時間影響(稼働率98.31%)』の表現のどこが印象操作なのか分からない。むしろ30日間の影響を見やすくしてるだけ。自分は記事に同意する。

27 海外の名無しさん 2026-09-16 16:19

好意的な言い換え?記事の要点は『月12時間』と言えばコストが一目でわかる、ということで、自分もそれに同意する。

32 海外の名無しさん 2026-09-16 16:16

その通り。定期的なメンテナンス停止自体は何も悪くない。大規模なグローバルクラウドサービスにはさすがに向かないけど、利用パターンを把握できているサービスなら十分アリ。

33 海外の名無しさん 2026-09-16 16:24

いや、カーネルのライブパッチはまだ一般的じゃないから、それを前提にすると1台のサーバの稼働率を上げるために悪いセキュリティ習慣を助長することになる。

37 海外の名無しさん 2026-09-16 16:24

『契約なんだから交渉すればいい』と言うけど、交渉できるのは営業サイドの話であって、エンジニアがその契約の中身(6ナインの契約とか)を営業が結んだ後に初めて知る、なんてことは会社によってはよくある。

38 海外の名無しさん 2026-09-16 16:29

特定の顧客について計算すればそうなるだろうけど、グローバルサービスである以上、どこかの誰かが必ず一番悪い数字を経験してるはず。

41 海外の名無しさん 2026-09-16 16:49

ちゃんとした大規模システムは、単純な稼働時間じゃなくて『リクエストの成功数/総リクエスト数』で重み付けした稼働率を社内SLOとして使ってる。ただこの数字はほぼ公開されない。顧客層の情報が漏れてしまうから。

この話題の背景と論点

「稼働率99%」などのパーセント表記は、IT業界では許容されるダウンタイムの少なさに応じて「ナイン(9)の数」で語られることが多く、99.9%は「スリーナイン」、99.9999%は「シックスナイン」と呼ばれる。パーセントの差はわずかでも許容されるダウンタイムの絶対時間は桁違いで、スレ内では6ナインの契約で許容される停止時間が3〜6ヶ月でわずか7.5秒という実例が挙がった。クラウドサービスのSLAでは、この基準を下回ると利用料の返金(サービスクレジット)が発生する契約が一般的で、金融や通信のように規制で稼働率の定義が決まっている業界がある一方、多くの業界には「障害」の統一定義自体が存在しない。スレで意見が割れたのは、稼働時間を実際の停止時間(例:月12時間)で言い換える提案が本当に有益かという点で、賛成派は影響の大きさが直感的にわかると評価し、反対派は「12時間の停止」が1回の長時間障害か短時間障害の頻発かを区別できないため結局グラフでの可視化が最も有用だと主張した。

※本記事は5ch(Hacker News)スレッド「Can we stop with the uptime percentages?」より抜粋・要約して構成しています。

この記事のリアクション