【応用情報技術者】第4章システム構成要素について

白川秋

1日前

4つめの応用情報技術者の科目A暗記用のブログです。

今日も気合を入れて作成してまります。作成だけ先に行って、実際の暗記作業は全11章を終えてからにする予定を組んでいます。

にしても、覚える単語が多い。応用情報技術者の試験が「国語」と言われる理由がわかります。科目Bなんかもう、「The・国語」ですよね。

正直こんなに勉強しなくても、過去問道場を解いていれば受かるとは思いますが、科目Bの基礎知識をつけるために必要であると僕は考えています。

まぁ、来年から試験区分が刷新されるということで、専門的にそして今よりは簡単になるのではと思っています。

でも、勉強したことは無駄になりません。

頑張って今日もいってみよー！

第4章システム構成要素
みんなで使おう！Ankiアプリで暗記しよう
参考図書
合わせて読みたい
最後に

第4章システム構成要素

システムの処理形態

単語	意味
集中処理システム	集中処理システムとは、すべてのデータや処理を1台の強力なコンピュータ（ホストコンピュータやメインフレーム）で行う方式です。ユーザーは端末からこの中心コンピュータにアクセスして処理を依頼します。昔の銀行や役所のシステムによく使われていて、管理が簡単でセキュリティも高いのがメリットです。ただし、ホストがダウンするとすべての処理が止まってしまう弱点もあります。
オンライントランザクション処理	オンライントランザクション処理（OLTP）は、リアルタイムでデータのやりとりを行う仕組みです。たとえば、コンビニで商品を買うときのレジ処理や、ネットバンキングでの振込がこれにあたります。処理は瞬時に完了し、データの整合性（矛盾がない状態）を保つために「ACID特性（Atomicity, Consistency, Isolation, Durability）」が重要です。集中処理システムと組み合わせて使われることも多いです。
シンクライアント端末	シンクライアント端末は、「処理能力が小さく、サーバに依存して動作する端末」です。自力ではほぼ何もできず、サーバから画面やアプリをストリーミングして利用します。セキュリティが高く、端末が壊れてもデータはサーバにあるので安心。最近ではクラウド環境やVDI（後述）と組み合わせて、企業や学校でよく使われています。逆にオフラインではほぼ使えないのがデメリット。
分散処理システム	分散処理システムは、複数のコンピュータがネットワークでつながり、協力して処理を行う方式です。処理やデータを分散させることで、1台が壊れても全体が止まらない「耐障害性」や、負荷を分散させる「スケーラビリティ（拡張性）」が得られます。現代のWebサービスやクラウドコンピューティングはこの考え方がベース。GoogleやAmazonのサービスも、膨大なサーバ群で分散処理しています。
集中処理システムと分散処理システムの比較	集中処理は「1点集中型」で管理・保守が楽ですが、障害に弱くスケールしにくい。一方、分散処理は「多数協調型」で、障害に強く拡張しやすいですが、管理が複雑で同期（タイミング合わせ）が難しいです。現代では、クラウドやモバイルの普及により、分散処理が主流ですが、金融機関などセキュリティ重視の場面では集中処理がまだ使われています。
水平機能分散	水平機能分散とは、同じ種類の処理を複数のサーバに分散させる方法です。たとえば、Webサーバが10台あって、どれも同じ「ホームページを表示する」仕事を担当します。これにより、1台が忙しくても他のサーバがカバーできて、全体のレスポンスが速くなります。水平「機能」分散は、実際には「水平負荷分散」とほぼ同じ意味で使われることが多いです。
水平負荷分散	水平負荷分散は、同じ役割を持つ複数のサーバに処理負荷を均等に割り振る技術です。たとえば、大量のユーザーがアクセスするECサイトでは、ロードバランサという装置が各Webサーバに「順番に」「または負荷が少ない方へ」リクエストを振り分けます。これにより、1台のサーバが過負荷になるのを防ぎ、サービスの安定性が向上します。クラウド環境では自動でスケールアップ・ダウンも可能。
垂直機能分散	垂直機能分散は、処理の「役割ごと」に異なるサーバに分ける方式です。たとえば、Webサーバ（画面表示）、アプリケーションサーバ（処理ロジック）、DBサーバ（データ保存）のように、機能を縦（階層的に）に分けてそれぞれ専用サーバに任せる方法。これにより、セキュリティや保守性が高まり、各サーバの負荷も最適化できます。現代のシステム設計では非常に一般的です。
VDI	VDI（Virtual Desktop Infrastructure：仮想デスクトップ基盤）は、サーバ上にユーザーごとのデスクトップ環境を仮想的に作り、ネットワーク経由で端末から利用する仕組みです。端末はシンクライアントでもOK。自宅や外出先からでも、会社と同じデスクトップが使えるため、リモートワークに最適。データはすべてサーバにあるので、端末紛失でも情報漏洩リスクが低い。2020年代後半の働き方改革で急速に普及しています。

クライアントサーバシステム

単語	意味
クライアントサーバシステム	クライアントサーバシステムとは、「頼む側（クライアント）」と「応える側（サーバ）」に役割を分けて動作するコンピュータシステムです。たとえば、スマホでYouTubeを見るとき、スマホがクライアント、YouTubeのサーバが動画を送ってくれるサーバです。この方式は、処理を分担できるので効率的で、現在のインターネットや企業システムの基本です。
クライアントサーバアーキテクチャ	クライアントサーバアーキテクチャとは、クライアントとサーバの間で「どんな処理を誰がやるか」を設計する考え方のこと。クライアントが画面表示や操作を受け持ち、サーバがデータ保存や計算を担当します。この分担により、システム全体がスムーズに動き、保守や拡張もしやすくなります。
2層クライアントサーバシステム	2層（ツー・ティア）クライアントサーバシステムは、クライアントとサーバの2つで構成されるシンプルな方式です。クライアントがユーザー入力と画面表示を、サーバがデータベース処理を一手に引き受けます。たとえば、昔の業務用アプリで「PCが直接DBサーバにアクセス」する形です。構造は簡単ですが、クライアントに負荷がかかりやすく、大規模なシステムでは使いづらい欠点があります。
3層クライアントサーバシステム	3層（スリー・ティア）システムは、クライアント、アプリケーションサーバ、データベースサーバの3つに役割を分けます。クライアントは画面表示だけ、アプリケーションサーバが「注文の計算」や「在庫チェック」などのロジックを処理し、DBサーバがデータ保存を担当。これにより、変更が楽になり、セキュリティも向上。現代の大規模システムでは標準的な設計です。
Webシステムの3層構造	Webシステムでも、3層構造が広く使われています。具体的には、①ブラウザ（プレゼンテーション層）、②Webアプリケーション（ロジック層）、③データベース（データ層）の3つ。たとえば、楽天で商品を検索すると、ブラウザが画面を表示し、アプリサーバが検索処理を行い、DBが商品情報を返します。この分離により、開発・保守・スケーリングが非常に効率的になります。
ストアドプロシージャ	ストアドプロシージャとは、データベース内にあらかじめ保存されたプログラムのことです。SQLの命令をまとめた「サブルーチン」のようなもので、アプリケーションから呼び出すと、DB内で直接処理が実行されます。たとえば「顧客のポイントを更新する処理」を1つのプロシージャとして登録できます。呼び出しは簡単で、`CALL update_point(12345);` のように書きます。
ストアドプロシージャの利点	ストアドプロシージャの主な利点は3つあります。①ネットワーク通信量が減る（複数のSQLを1回で実行）、②処理が高速（DB内で完結する）、③セキュリティが高い（テーブル直接アクセスを防げる）。ただし、移植性（他のDBに移すとき）が低くなる欠点もあるため、使いどころが重要です。2026年現在も、金融・医療系システムでよく利用されています。
RPC	RPC（Remote Procedure Call：リモート・プロシージャ・コール）は、「遠く離れたコンピュータ上のプログラムを、まるで自分のマシンにあるように呼び出せる」仕組みです。たとえば、ローカルで `calculateTax(amount)` と書くと、裏でサーバにリクエストが送られ、結果が返ってきます。開発者は通信の複雑さを意識せずに済むため、分散システムの構築が楽になります。
NFS	NFS（Network File System）は、ネットワーク越しに他のコンピュータのファイルを「まるで自分のディスクにあるように」使える仕組みです。たとえば、サーバAにある `/data` フォルダを、クライアントBが `/mnt/server_data` としてマウントして読めます。主にLinux/Unix系で使われ、2026年現在もクラウドバックアップや共有ストレージの基盤技術として活躍しています。
MVCモデル	MVC（Model-View-Controller）モデルは、ソフトウェアの構造を「データ（Model）」「画面（View）」「処理の流れ（Controller）」の3つに分ける設計パターンです。たとえば、SNSで「いいね」を押すと、Controllerが「いいね」を処理し、Modelがデータベースを更新、Viewが画面を再描画します。この分離により、チーム開発がしやすく、変更もしやすくなります。Webフレームワーク（例：Django、Ruby on Rails）の根幹をなす考え方です。

システムの構成と信頼性設計

単語	意味
デュアルシステム	デュアルシステムとは、同じ処理を2台のコンピュータで同時に並行して行い、結果を照合する高信頼性の方式です。たとえば、航空機の制御システムでは、2つのコンピュータが同じ計算をし、結果が一致しなければエラーと判断します。この方式は「クロスチェック」とセットで使われ、誤り検出に強いのが特徴ですが、ハードウェアが2倍必要でコストが高いです。
クロスチェック	クロスチェックとは、複数のシステムや処理結果を互いに比較して、正しいかどうかを検証する仕組みです。デュアルシステムでは、2台のコンピュータが同じ入力で処理し、出力が一致するかをチェックします。もしズレがあれば、どちらかが故障していると判断。この技術は、鉄道信号や原子力プラントなど、人命に関わるシステムで使われ、2026年でも安全性の要です。
デュプレックスシステム	デュプレックスシステムは、「主系（プライマリ）」と「待機系（スタンバイ）」の2台で構成され、普段は主系だけが稼働し、故障時に待機系が引き継ぐ方式です。デュアルシステムと違い、待機系は普段は処理を行わないため、コスト効率が良いです。銀行のATMや通信基地局などで使われ、信頼性と経済性のバランスをとる代表的な構成です。
ホットスタンバイ方式	ホットスタンバイ方式は、待機系のシステムが常に電源ONで、リアルタイムにデータ同期も行っている状態です。主系がダウンすると、数秒以内に自動で切り替わり、サービス停止をほぼゼロにできます。たとえば、クラウド上の重要なWebサービスでは、この方式で99.999%の稼働率（「5つの9」）を実現しています。
ウォームスタンバイ方式	ウォームスタンバイ方式では、待機系は電源は入っているが、リアルタイム同期はしていない状態です。主系が故障すると、最新バックアップから復旧するため、数分～数十分の停止時間が発生します。コストと信頼性の中間的な選択肢で、中小企業の業務システムなどで2026年もよく採用されています。
コールドスタンバイ方式	コールドスタンバイ方式は、待機系が完全に電源OFFの状態で、必要になるまで使われません。故障が起きたら手動で電源を入れ、バックアップデータをリストアします。復旧に数時間かかるため、緊急性の低いシステム（例：社内資料サーバ）に使われます。最も安価ですが、可用性は低いのが特徴です。
ホットサイト	ホットサイトとは、災害発生時に即座に業務を継続できるよう、常時稼働している代替拠点です。サーバ、ネットワーク、データがリアルタイムで同期されており、東京で災害が起きても大阪のホットサイトですぐに業務再開が可能。大手金融機関やクラウドプロバイダーが2026年も運用しています。
ウォームサイト	ウォームサイトは、基本的なインフラはあるが、データは定期バックアップのみで、即時切り替えはできません。災害時に数時間～1日かけてシステムを立ち上げます。ホットサイトより安価で、中堅企業のBCP（事業継続計画）で現実的な選択肢として使われています。
コールドサイト	コールドサイトは、建物と電気・ネット回線だけ用意されており、サーバやソフトは自分で持ち込む代替拠点です。復旧には数日かかるため、緊急性の低い業務や予算が限られる組織向け。2026年でも、地方自治体や教育機関で採用例があります。
フォールトトレランス	フォールトトレランス（fault tolerance）とは、「故障が起きてもシステム全体が停止せず、正常に動き続ける能力」のこと。ハードやソフトの一部が壊れても、別の部品が代わりを務める仕組みです。この考え方が、デュプレックスシステムやフェールオーバの根幹をなしています。
フォールトトレラント	「フォールトトレラント」とは、フォールトトレランスの性質を持つシステムや装置を指す形容詞です。たとえば、「このサーバはフォールトトレラント設計だ」と言えば、「故障しても止まらない作りになっている」という意味。英語の "tolerant"（許容する）が語源で、「故障を許容する」というニュアンスです。
フォールトトレラントシステム	フォールトトレラントシステムは、ハードウェアやソフトウェアの一部が故障しても、サービスを継続できるシステムです。例えば、データセンターのサーバが複数台で構成され、1台が落ちても他の台が処理を引き継ぐような構成。2026年では、AIクラスタや自動運転車の制御システムにもこの思想が応用されています。
フォールトアボイダンス	フォールトアボイダンス（fault avoidance）は、「故障をそもそも起こさない」ことを目指す考え方です。高品質部品の使用、厳格なテスト、設計ミスの排除などが該当します。対照的に、フォールトトレランスは「故障を前提に設計する」ため、両者は補完関係にあります。宇宙開発や医療機器では、この両方が求められます。
フェールソフト	フェールソフト（fail-soft）とは、故障が起きても、最低限の機能を維持して安全に停止・縮退する仕組みです。たとえば、エレベーターがセンサー故障を検出したら、最寄り階に停めてドアを開け、運転を停止します。完全には動かないが、人を閉じ込めないのがポイント。2026年では、自動運転車の緊急停止モードもこれに該当します。
フェールセーフ	フェールセーフ（fail-safe）は、「故障時にシステムが安全な状態になる」設計です。鉄道の信号機が故障すると「赤（停止）」になるのが代表例。電気が切れても止まる方向に設計されているのです。原子力発電所の非常停止バルブや、工場のロボットアームの緊急停止もこれにあたり、人命保護の基本原則です。
フェールオーバ	フェールオーバ（failover）は、「主系が故障したとき、自動的に待機系に処理を切り替える」仕組みです。たとえば、オンラインゲームのサーバがダウンすると、プレイヤーは気づかないうちに別のサーバに移されます。この切り替えは、ホットスタンバイ方式と組み合わせて、クラウドサービスの高可用性を支えています（2026年現在も主流）。
フェールバック	フェールバック（failback）は、フェールオーバ後に、元の主系が復旧したら処理を再びそちらに戻す操作です。たとえば、メインDBサーバが修理されて戻ってきたら、待機系から主系へと処理を「戻す」ことです。ただし、データの同期漏れがあると不整合が起きるため、慎重な運用が必要です。自動化も進んでいますが、2026年では手動確認が推奨されるケースも多いです。
フォールトマスキング	フォールトマスキング（fault masking）は、「内部でエラーが発生しても、外部からは正常に見えるように隠す」技術です。たとえば、RAID1（ディスクミラーリング）では、1台のハードディスクが壊れても、もう1台が同じデータを持っているため、ユーザーは「何も起きていない」と感じます。透明性を保ちながら信頼性を高める、洗練されたアプローチです。
フールプルーフ	フールプルーフ（foolproof）は、「人間のミスをしても、重大な事故やエラーが起きない」ように設計することです。例：USB端子は上下逆でも挿せないように形が工夫されている（USB-Cは両面挿せる設計自体がフールプルーフ）。工場の機械では、「安全カバーが開いていたら動かない」なども該当。2026年では、AI入力の誤字訂正や、アプリの「元に戻す」機能もフールプルーフの一形態とされます。

高信頼性・高性能システム

単語	意味
クラスタリング	クラスタリングとは、複数のコンピュータをネットワークでつないで、1台の強力なシステムのように見せる技術です。個々のコンピュータ（ノード）は「クラスタ」を構成し、協力して処理を分担します。これにより、処理能力の向上や一部が壊れてもシステム全体が止まらない高可用性が実現できます。現代のクラウドサービスや大規模Webサイトの基盤技術です。
クラスタシステム	クラスタシステムは、クラスタリングの考え方に基づいて構築された実際のシステム全体を指します。たとえば、AmazonやGoogleのデータセンターでは、数千台のサーバがクラスタシステムを形成し、ユーザーのリクエストに応えています。このシステムは、可用性（HA）、処理性能（HPC）、負荷分散などの目的に応じて、異なる構成（後述）が採用されます。
HAクラスタ構成	HA（High Availability：高可用性）クラスタ構成は、システムが24時間365日止まらないように設計されたクラスタです。主に「フェールオーバ」機能を備えており、1台が故障しても他のノードが即座に代わります。金融システムや病院の電子カルテなど、ダウンしてはいけないサービスで使われ、2026年現在も企業の信頼性の要です。
フェールオーバクラスタ構成	フェールオーバクラスタ構成は、HAクラスタの具体的な実現方式で、アクティブ（稼働中）とスタンバイ（待機中）のノードが連携します。アクティブノードがダウンすると、スタンバイが自動でその役割を引き継ぎます。たとえば、メールサーバが落ちても、ユーザーは気づかないうちに別のサーバに切り替わっています。ホットスタンバイと密接に関係しています。
負荷分散クラスタ構成	負荷分散クラスタ構成（ロードバランシングクラスタともいう）は、多数のユーザーからのアクセスを複数のサーバに均等に振り分けるクラスタです。これにより、1台のサーバが過負荷になるのを防ぎ、レスポンスの高速化と安定稼働を実現します。AmazonやYouTubeなどの巨大サービスは、この方式で毎秒数百万のリクエストを処理しています。
シェアードエブリシング	シェアードエブリシング（Shared Everything）とは、すべてのリソース（CPU、メモリ、ディスクなど）を全ノードが共有するクラスタ構成です。データベースクラスタでよく使われ、どのノードも同じデータにアクセスできます。しかし、共有部分がボトルネックや単一障害点になるリスクがあり、大規模化には向きません。
シェアードナッシング	シェアードナッシング（Shared Nothing）は、各ノードが独自のCPU、メモリ、ディスクを持ち、リソースを一切共有しない構成です。ノード間の干渉がなく、スケーラビリティ（拡張性）が非常に高いため、現代のクラウドやHPCで主流です。たとえば、Googleの検索エンジンはこの方式で、何万台ものサーバを効率的に運用しています。
HPC	HPC（High Performance Computing：ハイパフォーマンスコンピューティング）は、超高速な計算処理を行うための技術・システムの総称です。天気予報、宇宙シミュレーション、新薬開発などで使われ、多数のコンピュータをクラスタで接続し、並列処理で計算を高速化します。2026年時点で、日本の「富岳（Fugaku）」はHPCの代表例です。シェアードナッシング構成が主流です。
ロードバランサ	ロードバランサ（負荷分散装置）は、複数のサーバにアクセスをうまく振り分ける中間装置です。Webリクエストが来ると、どのサーバが空いているかを見て、最適な1台に送ります。これにより、全体の処理がスムーズになり、サーバの過負荷やダウンを防ぎます。クラウド環境では「ソフトウェア型ロードバランサ（例：HAProxy、NGINX）」が広く使われています。
ラウンドロビン方式	ラウンドロビン方式は、ロードバランサが使う最もシンプルな負荷分散アルゴリズムで、サーバを順番に回してリクエストを割り当てます。たとえば、サーバA→B→C→A→B…と循環。設定が簡単で高速ですが、各サーバの性能や負荷状況を考慮しないため、実際の負荷が偏る可能性があります。
加重ラウンドロビン方式	加重ラウンドロビン方式は、ラウンドロビンの改良版で、各サーバの性能に応じて「重み（ウェイト）」を設定します。たとえば、高性能サーバに重み「2」、普通のサーバに「1」を付けると、2:1の割合でリクエストが割り当てられます。これにより、実際の処理能力に見合った負荷分散が可能になり、2026年でも多くのクラウド環境で採用されています。
最小クライアント数方式	最小クライアント数方式は、現在接続しているクライアント（ユーザー）数が最も少ないサーバに次を割り当てる方式です。たとえば、サーバAが3人、Bが1人なら、次はBに。直感的で効果的ですが、クライアント数＝負荷とは限らない（重い処理をしている可能性がある）ため、完璧ではありません。
最小負荷方式	最小負荷方式は、CPU使用率やメモリ使用量など、サーバの実際の「負荷」が最も低いノードにリクエストを割り当てる高度な方式です。ロードバランサが各サーバの状態を定期的に監視し、リアルタイムで判断します。最も効率的ですが、監視のオーバーヘッドが大きいため、小規模システムでは使われにくい傾向があります。

ストレージ関連技術

単語	意味
RAID	RAID（Redundant Arrays of Independent Disks）とは、複数のハードディスクを組み合わせて、信頼性や性能を高める技術です。単一のディスクでは故障でデータが消失しますが、RAIDを使うと「冗長性」（余分な情報で復旧可能）や「高速化」が実現できます。RAID0～6まであり、目的に応じて使い分けます。現代のサーバーやNASの根幹をなす技術です。
RAID0	RAID0は「ストライピング」と呼ばれる方式で、データを複数ディスクに細かく分割して並列に書き込みます。これにより読み書きが高速になりますが、冗長性がゼロで、1台のディスクが壊れると全データが失われます。高速処理が優先される動画編集ワークステーションなどで使われますが、バックアップは必須です。
RAID1	RAID1は「ミラーリング」と呼ばれる方式で、同じデータを2台のディスクに同時に書き込み、完全にコピーします。1台が壊れてももう1台で動作継続が可能で、信頼性が非常に高いです。ただし、ディスク容量は半分しか使えない（例：2TB×2台で利用可能は2TB）ため、コスト効率はやや劣ります。重要なシステムの起動ディスクに使われます。
RAID2	RAID2は、データをビット単位に分割し、エラーチェック用のハミング符号を別ディスクに保存する方式です。1970年代に提案されましたが、現代のディスクは内蔵ECC（誤り訂正）を持っているため実用されず、歴史的なRAIDレベルとされています。2026年現在、実際のシステムで使われることはほぼありません。
RAID3	RAID3は、データをバイト単位で複数ディスクに分割し、専用のパリティディスクで冗長性を実現します。大容量ファイルの連続読み書きに適していましたが、小規模なアクセスでは性能が悪く、専用パリティディスクがボトルネックに。現在はほぼ使われず、後継のRAID5が主流です。
RAID4	RAID4もRAID3と同様、専用のパリティディスクを持つ点が特徴ですが、データをブロック単位で分割します。これによりランダムアクセス性能は向上しますが、書き込みのたびにパリティディスクが更新されるため、そこが負荷の集中点になります。RAID5が登場して以降、実用されることは稀です。
RAID5	RAID5は、パリティ情報（冗長データ）を全ディスクに分散して保存する方式です。これにより、どの1台が壊れても復旧可能で、かつ専用パリティディスクのボトルネックが解消されます。3台以上のディスクで構成され、コスト・性能・信頼性のバランスが良いため、最も広く使われるRAIDです。ただし、大容量ディスク増加により再構築時間が長くなる課題も。
RAID6	RAID6はRAID5の拡張で、2つの独立したパリティ情報を分散保存します。これにより、2台のディスクが同時に壊れてもデータを復旧可能です。大容量ディスクが主流の2026年では、RAID5の再構築中に2台目が故障するリスクが高いため、信頼性重視の環境（例：クラウドストレージ）ではRAID6が推奨されています。
RAIDの組合せ	RAIDは組み合わせることで、さらに高度な特性を実現できます。代表例が「RAID10（1+0）」で、ミラーリング（RAID1）とストライピング（RAID0）を組み合わせ、高速性と高信頼性を両立します。4台以上必要でコストは高いですが、データベースサーバなど性能と安全の両方が必要な場面で使われます。他にRAID50（5+0）などもあります。
ファイルストレージ	ファイルストレージは、「フォルダ→ファイル」の階層構造でデータを管理する方式です。OSのファイルシステム（例：NTFS、ext4）と同じ感覚で使え、ユーザーやアプリが直接ファイル名でアクセスできます。代表例がNAS。文書、画像、動画の共有に最適で、2026年でもオフィスや家庭で広く使われています。
ブロックストレージ	ブロックストレージは、ディスクを「固定サイズのブロック（例：512Bや4KB）」単位で管理し、OSが自由にファイルシステムを構築できる方式です。データベースや仮想マシンのストレージに最適で、低レイテンシ・高スループットが特徴。SANが代表的で、アプリから見ると「ローカルディスクのように」扱えます。
オブジェクトストレージ	オブジェクトストレージは、データ（オブジェクト）に一意のID（URLのようなもの）を付けて管理する方式です。階層構造がなく、メタデータも豊富に持てます。大規模・非構造化データ（例：SNSの画像、動画）の保存に最適で、Amazon S3やGoogle Cloud Storageが代表です。2026年ではAI・ビッグデータの基盤としても不可欠です。
NAS	NAS（Network Attached Storage）は、ネットワーク経由でファイル単位のデータを提供する専用装置です。家庭用の「どこでもアクセスできるハードディスク」と思えばOK。ファイルストレージを実現し、NFSやCIFSを使ってPCやスマホと接続されます。中小企業の共有フォルダや、自宅のメディアサーバに広く使われています。
CIFS	CIFS（Common Internet File System）は、Windows環境で使われるファイル共有プロトコル（SMBの一種）です。NASやファイルサーバに「\server\data」とアクセスすると、CIFSが裏で動いています。ユーザ認証やアクセス制御が強力で、社内ネットワークでの共有フォルダに最適。2026年も企業の標準プロトコルの一つです。
SAN	SAN（Storage Area Network）は、専用ネットワークでサーバとストレージを接続し、ブロック単位で高速アクセスを実現する仕組みです。NASが「ファイルを送る」のに対し、SANは「ディスクそのものを提供」するイメージ。低遅延・高スループットが特徴で、大規模データベースやVDI環境で不可欠です。
ファイバチャネル	ファイバチャネル（Fibre Channel）は、SANで使われる高速・専用の通信規格で、最大128Gbps（2026年現在）の帯域を持ちます。TCP/IPを使わず、ストレージ専用の信頼性と低遅延を実現。ただし、専用ケーブルやスイッチが必要でコスト高。金融機関や大企業の基幹システムで使われ続けています。
FC-SAN	FC-SANは、ファイバチャネルを使ったSAN構成です。サーバとストレージがファイバチャネルで直接つながり、ブロックストレージを超高速で提供します。信頼性・性能は最高クラスですが、導入・運用が複雑。2026年では、ミッションクリティカルなシステム（例：証券取引、電子カルテ）で主力です。
IP-SAN	IP-SANは、イーサネットとTCP/IPを使ってSANを構築する方式で、代表プロトコルはiSCSIです。FC-SANよりコストが低く、既存ネットワークと統合しやすいのが利点。ただし、遅延やパケットロスのリスクがあるため、FC-SANほどの性能は出ません。中小企業や仮想化環境で2026年も広く使われています。
Hadoop	Hadoopは、大量のデータを複数サーバに分散して処理・保存するオープンソースのフレームワークです。主に2つの技術で構成されます。・HDFS（Hadoop Distributed File System）：データを複数ノードに分散保存するファイルシステム。・MapReduce：処理を「Map（分割処理）」と「Reduce（集計）」に分けて並列実行するプログラミングモデル。　2026年では、ビッグデータ分析やAI学習の基盤として、クラウド環境でも広く活用されています。

仮想化技術

単語	意味
仮想化技術	仮想化技術とは、物理的なコンピュータ資源（CPU、メモリ、ディスクなど）をソフトウェアで分割・抽象化し、複数の「見せかけの（仮想の）システム」を動かす技術です。たとえば、1台のサーバで複数のOSを同時に動かすことができます。これにより、ハードウェアの効率的利用、運用コスト削減、柔軟なシステム構成が可能になり、現代のクラウドやデータセンターの根幹を支えています。
ストレージ仮想化	ストレージ仮想化は、複数の物理ディスクやストレージ装置をソフトウェアで1つの大きなプールとして扱い、論理的に自由に分割・管理する技術です。ユーザーは「どこにデータがあるか」を気にせず、必要な容量だけ利用できます。これにより、容量の無駄を減らし、バックアップや拡張も簡単になります。企業のストレージ管理やクラウドストレージの基盤技術です。
シンプロビジョニング	シンプロビジョニング（Thin Provisioning）は、ストレージを「必要なときだけ実際に割り当てる」方式です。たとえば、「1TBの仮想ディスクを作成」と指示しても、最初は10GBしか使わなければ、物理ディスクも10GBしか消費しません。これにより、ストレージの無駄を劇的に削減できます。ただし、全ユーザーが同時に容量を使い始めると不足するリスクもあるため、監視が必要です。
ストレージ自動階層化	ストレージ自動階層化（Automated Tiered Storage）は、データのアクセス頻度に応じて、高速SSDと低速HDDの間で自動的に移動させる技術です。よく使うデータはSSDに、使わないデータはHDDに置くことで、コストと性能の最適化を実現します。2026年現在、企業のストレージシステムやハイブリッドクラウドで広く採用されています。
サーバ仮想化	サーバ仮想化は、1台の物理サーバ上に複数の「仮想サーバ（仮想マシン）」を立ち上げる技術です。各仮想サーバは独立したOSとアプリを持ち、まるで別々のマシンのように動作します。これにより、サーバ統合（10台→1台）、省電力、迅速な復旧が可能に。VMwareやHyper-Vなどが代表的で、クラウドの基本技術です。
ホスト型仮想化	ホスト型仮想化は、通常のOS（ホストOS）の上に仮想化ソフト（例：VirtualBox、VMware Workstation）をインストールし、その上で仮想マシンを動かす方式です。個人のPCで簡単に試せるのがメリットですが、ホストOSを経由するためオーバーヘッドが大きく、性能はやや劣ります。開発・テスト用途や学習に適しています。
ハイパバイザ型仮想化	ハイパバイザ型仮想化は、物理ハードウェアの直上に「ハイパバイザ（VMM：仮想マシンモニタ）」をインストールし、その上で直接仮想マシンを動かす方式です。ホストOSが不要で、リソース効率・性能・信頼性が非常に高いため、企業やデータセンターの主流です。代表例はVMware ESXi、Microsoft Hyper-V（スタンドアロン版）です。
仮想OS	「仮想OS」とは、仮想マシン上で動作するゲストOS（例：Windows、Linux）を指します。物理マシンではなく、ソフトウェアで模擬された環境で動いていますが、アプリケーションからは「普通のOS」に見えます。この仕組みにより、異なるOSを1台のPCで同時に利用でき、開発・検証・教育に非常に便利です。
コンテナ型仮想化	コンテナ型仮想化（例：Docker、Kubernetes）は、OSのカーネルを共有しながら、アプリとその依存関係を「コンテナ」という単位で分離・実行する技術です。仮想マシンより軽量で起動が速く、リソース消費も少ないのが特徴。2026年では、マイクロサービスアーキテクチャやクラウドネイティブ開発の標準となっており、サーバ仮想化と併用されることも多いです。
ライブマイグレーション	ライブマイグレーションは、仮想マシンを稼働中のまま、別の物理サーバに移動させる技術です。ユーザーは接続を切られず、ダウンタイムゼロでハードウェアの保守・負荷分散が可能になります。たとえば、サーバのメモリが逼迫したら、自動で空いているサーバへ移動。VMware vMotionやHyper-V Live Migrationなどが該当し、2026年もデータセンターの必須機能です。
クラスタソフトウェア	クラスタソフトウェアは、複数のサーバを1つのシステムとして管理し、高可用性や負荷分散を実現するソフトウェアです。たとえば、1台がダウンしても別のサーバが自動で引き継ぐ「フェールオーバ」機能を提供します。代表例にWindows Server Failover Clustering（WSFC）、LinuxのPacemakerなどがあり、仮想化環境と組み合わせて、より堅牢なシステムを構築します。

システムの性能特性と評価

単語	意味
システムの性能指標	システムの性能指標とは、コンピュータやネットワークの「どれくらい速く、どれくらいたくさん処理できるか」を数値で表す基準です。代表的なものにスループット（処理量）などがあります。これらの指標を使うことで、システムの改善点を見つけたり、新しい機器の比較ができます。性能評価の出発点であり、すべてのITエンジニアが理解すべき基礎です。
スループット	スループットは「単位時間あたりに処理できる仕事の量」を指します。たとえば、「1秒間に1,000トランザクション処理可能（TPS）」や「1秒間に100MBのデータ転送」など。数字が大きいほど高性能です。ネットワークやデータベース、Webサーバなどでよく使われ、システム全体の処理能力の目安になります。
レスポンスタイム	レスポンスタイムは、「ユーザーが操作してから結果が返ってくるまでの時間」です。たとえば、Webページをクリックしてから画面が表示されるまでの時間。短いほど快適で、一般的に1秒未満が理想とされます。スループットとトレードオフになることもあり、バランスが重要です。
ターンアラウンドタイム	ターンアラウンドタイムは、「ジョブ（処理依頼）を投入してから、結果が完全に出力されるまでの総時間」です。バッチ処理（例：給与計算）で使われる指標で、待ち時間＋実行時間＋出力時間を含みます。対話型のレスポンスタイムとは異なり、非リアルタイム処理の効率性を測るのに使われます。
MIPS	MIPS（Million Instructions Per Second）は、「1秒間に何百万個の命令を実行できるか」というCPU性能の指標です。たとえば、100 MIPSなら1秒に1億命令。ただし、命令の複雑さがCPUごとに違うため、実際の性能とはズレることがあります。2026年では歴史的な指標として学ぶ価値がありますが、実用評価には不向きです。
FLOPS	FLOPS（Floating Point Operations Per Second）は、「1秒間に何回の浮動小数点演算（小数の計算）ができるか」を示す指標で、科学技術計算やAIで重要です。1テラFLOPS（10¹²回／秒）や、富岳の442ペタFLOPS（10¹⁵）など。HPC（ハイパフォーマンスコンピューティング）の世界では最も信頼される性能指標です。
命令ミックス	命令ミックスとは、「実際のプログラムで使われる命令の種類と割合」をまとめたものです。たとえば、「加算命令が30％、メモリアクセスが50％…」など。MIPSなどの単純指標の代わりに、より現実に近い性能評価に使われます。ギブソンミックスなどが代表例です。
コマーシャルミックス	コマーシャルミックスは、事務処理系（ビジネスアプリ）を想定した命令ミックスです。データベース操作やファイル処理などが多く含まれ、企業システムの性能評価に適しています。実際の業務アプリの動きを模擬するため、汎用コンピュータのベンチマークに使われてきました。
ギブソンミックス	ギブソンミックスは、1970年代に提唱された、科学技術計算と事務処理をバランスよく含む命令ミックスです。命令の種類と出現頻度を統計的にまとめたもので、当時の汎用コンピュータ評価で広く使われました。現代では古くなりましたが、命令ミックスの考え方の基礎として教科書に登場します。
命令ミックス値の求め方	命令ミックス値は、各命令の出現割合を基に平均CPIを求める。例：加算50％（CPI=1）、ロード30％（CPI=2）、分岐20％（CPI=3）なら、平均CPI ＝ (0.5×1)＋(0.3×2)＋(0.2×3) ＝ 1.7 これで実行クロック数（＝命令数×平均CPI）が現実的に見積もれる。
ベンチマーク	ベンチマークとは、コンピュータの性能を客観的に比較・評価するための標準化されたテストプログラムです。実際のアプリに近い処理を模擬し、スループットやレスポンスタイムを計測します。代表例にSPEC、TPCなどがあり、購入判断やシステム設計の根拠として2026年も広く使われています。
SPEC	SPEC（Standard Performance Evaluation Corporation）は、CPUやシステム全体の性能を評価する国際的なベンチマーク団体です。多数の企業が参加し、公平なテストを開発しています。主にSPECint（整数演算）とSPECfp（浮動小数点演算）の2種類があり、高性能コンピュータの比較に欠かせません。
SPECint	SPECintは、整数演算性能を測るSPECベンチマークで、2種類ある。・SPECint_base：コンパイラ最適化に制限を設けた、公平性重視のスコア・SPECint_rate：複数ジョブの並列処理性能を測るスコアどちらも実際の業務アプリに近い処理でCPU性能を評価し、2026年でもサーバ選定の重要な指標だ。
SPECfp	SPECfpは、浮動小数点演算性能を測るSPECベンチマークで、科学技術計算系アプリを対象としている。代表的な処理には、流体解析・気象シミュレーション・3Dレンダリングなどがある。2種類のスコアが定義されている。・SPECfp_base：コンパイラ最適化に制限を設けた、公平性重視のスコア・SPECfp_rate：複数ジョブの並列実行性能を測るスコアどちらもFLOPSと強く関連し、HPC（High Performance Computing）環境の性能評価で重要な指標となる。
Dhrystone	Dhrystoneは、整数演算のみを使った古いベンチマークプログラムで、1980年代に開発されました。MIPS値を求めるために使われましたが、最適化コンパイラに弱く、現実離れした結果になりやすいため、現在では推奨されません。ただし、組込みシステムの簡易評価でまれに使われることもあります。
Whetstone	Whetstoneは、浮動小数点演算中心の古典的ベンチマークで、1970年代に登場。科学技術計算の性能を測るために使われ、KWIPS（Kilo Whetstone Instructions Per Second）という単位も生まれました。現代ではSPECfpに置き換えられていますが、歴史的意義は大きいです。
TPC	TPC（Transaction Processing Performance Council）は、データベースやトランザクション処理の性能を測る国際団体です。実際の業務シナリオを模擬したベンチマーク（TPC-C、TPC-Eなど）を公開し、結果にはハード・ソフト・価格の全情報が公開されるため、非常に信頼性が高いです。
TPC-C	TPC-Cは、卸売業の在庫・注文管理を模擬したOLTP（オンライントランザクション処理）です。1秒あたりのトランザクション数（tpmC）で性能を評価します。2026年でもデータベースの基本性能比較に広く使われ、OracleやSQL Serverの宣伝でも登場します。
TPC-E	TPC-Eは、TPC-Cの後継で、より現実的な証券取引システムを模擬したベンチマークです。複雑なクエリや参照トランザクションを含み、現代的なDB性能をより正確に反映します。ただし、実行が複雑なため、TPC-Cより採用例は少ないのが現状です。
TPC-App	TPC-Appは、BI（ビジネスインテリジェンス）の性能を測るベンチマークで、ユーザーの操作とバックエンド処理の両方を評価します。レスポンスタイムとスループットを組み合わせたスコア（QphH@App）で表現され、2026年では分析基盤の選定に活用されています。
TPC-H	TPC-Hは、意思決定支援（DSS）で、複雑なSQLクエリを多数実行します。大量データ（GB～TB級）を対象とし、スループット（QphH）で性能を評価。ビッグデータ分析やデータウェアハウスの評価に使われ、HadoopやSparkの性能比較にも応用されています。
シミュレーション	シミュレーションは、実際のシステムを動かさずに、モデルを使って性能や挙動を予測する手法です。ハードが高価だった時代に重宝されましたが、2026年では「デジタルツイン」や「AIシミュレータ」として進化。設計段階での検証やリスク回避に役立ちます。
カーネルプログラム法	カーネルプログラム法は、実際のアプリの中から性能に影響の大きい「代表的な処理」（カーネル）を抽出し、それをベンチマークとして使う方法です。全体を動かすより軽量で、開発中のプロセッサ評価に適しています。ただし、カーネルの選定が難しいのが課題です。
カタログ性能	カタログ性能は、製品カタログに記載された理論的・最良時の性能値（例：最大クロック周波数、理論FLOPS）です。実際のアプリでは達成できないことが多く、「上限」の目安と捉えるべきです。購入時はベンチマーク結果と照らし合わせるのが賢明です。
モニタリング	モニタリングは、システムの動作中に性能やリソース使用状況を継続的に観測・記録する活動です。CPU使用率、メモリ、ディスクI/Oなどを計測し、ボトルネックの発見や障害予測に役立ちます。2026年ではAIによる異常検知と組み合わされるのがトレンドです。
ソフトウェアモニタ	ソフトウェアモニタは、OSやアプリケーションの機能を使って性能を計測する仕組みです。例：Linuxのtop、Windowsのパフォーマンスモニタ。導入が簡単でコストゼロですが、計測自体がシステム負荷になる（オーバーヘッド）という欠点があります。
ハードウェアモニタ	ハードウェアモニタは、専用の計測チップやボードを使って、システムに影響を与えずに性能を計測する装置です。正確でリアルタイム性が高いですが、高価で設置が難しいため、主に研究機関や大規模データセンターで使われます。
ソフトウェアモニタの測定対象	ソフトウェアモニタは、CPU使用率、メモリ使用量、プロセス数、ディスク転送量、ネットワークトラフィックなどを計測します。OSのカーネルが提供するカウンタ（例：/proc/stat）を基にしています。日常的な運用監視やトラブルシューティングに最適です。
ハードウェアモニタの測定対象	ハードウェアモニタは、命令実行数、キャッシュヒット率、バス転送回数、パイプラインの停止サイクルなど、ハードウェア内部の詳細な動作を計測できます。ソフトウェアモニタでは見えない「マイクロアーキテクチャレベル」の情報を得られ、性能チューニングに強力です。
キャパシティプランニング	キャパシティプランニングは、将来の業務増加に備えて、必要なITリソース（CPU、メモリ、ストレージなど）を予測・計画する活動です。過去のモニタリングデータやビジネス計画をもとにシミュレーションし、過不足のない投資を実現します。クラウド時代でもコスト最適化の要です。
キャパシティ管理	キャパシティ管理は、日々の運用の中でリソース使用状況を監視・調整し、計画通りにシステムが動くように維持するプロセスです。プランニングが「設計」なら、管理は「運用」に相当。2026年では、自動化ツール（例：KubernetesのHPA）との連携が主流です。
サーバの性能向上策	サーバの性能を向上させる主な方法は3つ。 ① スケールアップ（1台を高性能化） ② スケールアウト（台数を増やす） ③ オートスケール（需要に応じ自動増減）他にも、アプリのチューニング、キャッシュ活用、負荷分散などがあります。目的と予算に応じて選択します。
スケールアウト	スケールアウトは、同じ性能のサーバを複数台並べて処理能力を向上させる方式です。ロードバランサで負荷分散し、柔軟性・耐障害性が高いのが特徴。Webサービスやクラウドで主流で、「水平方向への拡張」とも呼ばれます。台数増でコストは増えますが、安価なサーバで構成可能です。
スケールアップ	スケールアップは、1台のサーバのCPUやメモリを強化して性能を上げる方式です。設定が簡単で、アプリ変更が不要なのが利点ですが、上限があり、単一障害点のリスクがあります。「垂直方向への拡張」とも言い、データベースサーバなどに使われます。
オートスケール	オートスケールは、クラウド環境で、CPU使用率やトラフィックに応じて自動的にサーバ台数を増減させる仕組みです。例：昼間にアクセスが増えると自動でインスタンスを追加、夜は減らす。これにより、コスト削減と性能維持を両立できます。AWS Auto Scaling、Azure Scale Setsなどが代表で、2026年では標準機能です。

待ち行列理論の適用

単語	意味
待ち行列	「待ち行列」とは、サービスを受けるために順番待ちしている「人やデータの列」のことを指します。例えば、レストランの予約待ち、ATMでの列、ウェブサイトへのアクセス集中時のサーバー処理待ちなどが該当します。情報システムでは、サーバーがリクエスト（要求）を処理しきれないときに、一時的にキュー（待ち行列）に格納して順次処理します。この理論は、システムの遅延や混雑を定量的に評価・改善するための基礎です。
M/M/1モデル	M/M/1モデルは、待ち行列の最も基本的なモデルです。「M」はMarkovian（マルコフ性＝無記憶性）を意味し、到着がポアソン過程、サービス時間が指数分布に従うことを表します。「1」はサーバーが1台であることを示します。たとえば、1台のプリンターに複数のPCが印刷を依頼するような状況がこれに相当します。このモデルは解析が簡単で、他の複雑なモデルの出発点になります。
平均到着間隔の求め方	平均到着間隔：次の客（または要求）が来るまでの平均時間（単位：秒など）平均到着率：単位時間あたりに到着する客の平均数（単位：人/秒）。これを通常 λ（ラムダ）で表します。関係式：平均到着間隔=1λ,平均到着率=λ 【例】1分間に平均6人が到着する場合 → λ = 6 [人/分] → 平均到着間隔 = 1/6 分 = 10秒。
平均サービス時間の求め方	平均サービス時間：1人（1件）の処理にかかる平均時間（例：レジで会計にかかる時間）平均サービス率：単位時間に処理できる件数で、μ（ミュー）で表します。関係式：平均サービス時間=1μ,平均サービス率=μ 【例】1人の処理に平均12秒かかる → 平均サービス時間 = 12秒 → μ = 1/12 [人/秒] = 5 [人/分]。
利用率の求め方	利用率（ρ：ロー）とは、サーバーが「実際に働いている時間の割合」です。0 ≦ ρ < 1 でないと、永遠に待ちが増え続けてしまいます（系が不安定）。 M/M/1における利用率の公式： ρ=λμ 【例】λ = 4 [人/分]、μ = 5 [人/分] → ρ = 4/5 = 0.8（＝80％）。 → サーバーは80％の時間稼働しており、20％は空いている。
平均待ち時間の求め方	平均待ち時間（Wq）は、到着してからサービス開始までにかかる平均時間（キュー内で待つ時間）。 M/M/1モデルの公式： Wq=ρμ(1−ρ)=λμ(μ−λ) 【例】λ = 4、μ = 5 → Wq=45(5−4)=45=0.8 分=48秒
平均応答時間の求め方	平均応答時間（W）は、到着してからサービス終了までの総時間＝「待ち時間＋サービス時間」です。 M/M/1モデル： W=Wq+1μ=1μ−λ 【例】λ = 4、μ = 5 → W=15−4=1 分 → 48秒待って、12秒サービス → 合計60秒。整合性◎。
平衡状態	平衡状態（定常状態）とは、時間が十分経過して、確率分布が時間変化しなくなった安定した状態です。待ち行列理論のほとんどの公式（例：ρ = λ/μ）は、この平衡状態を仮定して成り立ちます。 ⚠️ 平衡状態になるための条件：ρ < 1（到着が処理能力を超えないこと）。現実のWebサーバーでも、トラフィックが急増してρ ≥ 1になると、レスポンスが無限に遅れ（実質ダウン）→ 負荷試験でこの点をチェックします（2026年でも重要）。
平均回線待ち時間の求め方	回線待ち時間は、通信分野特有の用語で、ネットワークの回線（チャネル）が空くのを待つ時間を指します。本質的には「平均待ち時間（Wq）」と同じですが、主にM/M/1キューを通信回線に適用した文脈で使われます（例：パケットが送信を待つ時間）。 → 求め方は Wq の公式と同一： Wq=λμ(μ−λ) 現代の5G/6GやIoTでは、この遅延（レイテンシ）が自律走行や遠隔手術の安全性に直結するため、ミリ秒単位の厳密な制御が課題です（2026年現在も研究最前線）。
ケンドール記号	ケンドール記号は、待ち行列モデルを短く表す「記法」で、 A / B / c / K / m / D の形式で書きます。応用情報では主に最初の3つまで使います。・A：到着プロセスの分布（M＝メモリレス＝ポアソン到着）・B：サービス時間の分布（M＝指数分布、D＝一定、G＝一般分布）・c：サーバー台数【例】・M/M/1：ポアソン到着・指数サービス・1台・M/D/3：ポアソン到着・一定サービス時間・3台（例：自動券売機）・M/G/1：ポアソン到着・任意分布サービス・1台（汎用性高し） 2020年代以降、クラウドのオートスケーリングなど「動的c」の研究も進んでいますが、試験では基本3項目が中心です。
到着の分布	到着の分布とは、「どれくらいの間隔で要求が来るか」の確率分布です。待ち行列でよく使うのは：・ポアソン過程：無記憶性・独立性があり、単位時間の到着数がポアソン分布に従う。・現実では、Webアクセスは「バースト性」（一気にアクセス集中）があり、純粋なポアソンから外れるため、MAP（Markovian Arrival Process）など高度なモデルも研究されていますが、応用情報ではポアソンが基本です。
ポアソン分布	ポアソン分布は、「単位時間内に稀に起こる事象がk回発生する確率」を表す分布です。到着数のモデルに最適で、パラメータは平均到着率 λ のみ。確率質量関数： P(X=k)=λke−λk! 【例】λ = 3（1分に平均3人到着）→ 「ちょうど2人到着する確率」は、 P(X=2)=32e−32!≈0.224 (22.4%) ✅ 無記憶性（過去の到着が未来に影響しない）は、現実の電話コールやWebリクエストに近いとされます。
指数分布	指数分布は、事象が起こるまでの待ち時間を表す分布で、ポアソン過程と密接に関係（ポアソンの到着間隔は指数分布）。確率密度関数（λ > 0）： f(t)=λe−λt(t≥0) → 平均 = 1/λ、分散 = 1/λ² 特徴：無記憶性（例：「あと10分待てば来そう」が、すでに5分待っても変わらない） ⚠️ 実際のサービス時間（例：人間の作業）は指数分布より分散が小さい（一定に近い）ため、M/D/1の方が現実的な場合も。
サービスの分布	サービス時間の分布は、処理の性質で変わります：・指数分布（M）：処理時間がばらつく（例：カスタマーサポート対応）・一定分布（D）：全員同じ時間（例：自動改札、固定長パケット送信）・一般分布（G）：実測データから推定（例：病院の診察時間）選ぶ分布により、待ち時間のばらつき（分散）が大きく異なります。2026年では、AIで実際のログから最適分布を推定する手法も登場しています。
M/M/Sモデル	M/M/Sは、サーバーがS台並列で動くモデルです（例：銀行の複数窓口、クラウドの複数インスタンス）。到着はポアソン（M）、サービス時間は指数分布（M）。 → 1台より待ち時間が大幅に短縮され、スケーラビリティの基礎理論です。ただし、解析が難しくなり、アーランのC公式が必要です。
M/M/Sモデルの利用率の求め方	M/M/Sでは、1台あたりの平均利用率ρを次のように定義します。 ρ=λSμ ⚠️ 安定条件は ρ < 1（全サーバーの合計処理能力 > 到着率）。【例】λ = 12 [人/分]、μ = 5 [人/分]、S = 3台 → 全処理能力 = 15 [人/分] → ρ = 12 / (3×5) = 0.8（1台あたり平均80％稼働）
M/M/Sモデルの平均待ち時間の求め方	少し複雑ですが、以下の手順で計算します。 ① まず、待ちなしで即サービスを受けられる確率（P₀）を求める。 P0=[∑n=0S−1(λ/μ)nn!+(λ/μ)SS!(1−ρ)]−1 ② 次に、全サーバーが埋まっている確率（待ち発生確率）C(S, λ/μ）＝アーランC公式： C=(λ/μ)SS!(1−ρ)∑n=0S−1(λ/μ)nn!+(λ/μ)SS!(1−ρ)=(Sρ)S/[S!(1−ρ)]∑n=0S−1(Sρ)nn!+(Sρ)SS!(1−ρ) ③ 平均待ち時間： Wq=CSμ−λ 【簡易例】λ=9, μ=5, S=2 → ρ = 9/(2×5)=0.9 → C ≈ 0.85（計算略）→ Wq≈0.8510−9=0.85 分=51秒対照的にM/M/1（1台）なら ρ=9/5=1.8（不安定！）→ 現実不可。→ 多重化の効果が明確。
M/M/Sモデルの平均処理時間の求め方	※「平均処理時間」＝「平均応答時間（W）」と解釈します（待ち＋サービス）。 W=Wq+1μ つまり、M/M/1と同様に、待ち時間に1人の平均サービス時間を足せばOKです。【上記例】W_q = 0.85 分、1/μ = 0.2 分 → W = 1.05 分 → 2台にしたおかげで、無限待ち（M/M/1ではρ > 1で発散）を回避し、1分ちょっとで処理完了。

システムの信頼性特性と評価

単語	意味
システムの信頼特性指標	システムが「どのくらい信頼できるか」を数値で評価する基準のことを信頼特性指標といいます。代表的なものに、MTBF（平均故障間隔）・MTTR（平均修理時間）・稼働率（Availability）があります。たとえば、スマートフォンの「年間1回しか落ちない」はMTBFが長く、「10秒で再起動」はMTTRが短い——ということ。2026年現在、クラウドサービス（例：AWS・Azure）では、SLA（サービスレベル契約）で「月間稼働率99.99％」などと明記され、達成できなければ利用料が返金されます。つまり、信頼性はビジネスの信頼そのものなのです。
RASIS	RASIS（ラシス）は、高信頼システムを設計・評価するための5つのキーワードの頭文字です：・R：Reliability（信頼性） → 故障しにくさ・A：Availability（可用性） → 使いたいときに使える確率・S：Serviceability（保守性） → 修理・点検のしやすさ・I：Integrity（保全性） → データが改ざん・破損しない性質・S：Safety（安全性） → 故障しても人や環境に危害を与えないこのうち、保全性（I）と安全性（S）は、近年のサイバー攻撃やAI誤動作の増加により、従来の「ハード故障」に加えて「ソフトウェア的脅威対策」として極めて重要になっています（2026年ではISO/IEC 27001＋IEC 62443が統合されつつあります）。
信頼性	信頼性（Reliability）とは、「指定された期間・条件で、故障せずに機能し続ける能力」のことです。単位は無次元（確率）で、普通は「R(t)」と書き、時刻tまで故障しない確率を表します。例：某サーバーの信頼性R(8760h)＝0.99 → 1年（8760時間）間で99％の確率で故障しない。 ⚠️ 信頼性は「時間とともに低下」するのが特徴。この減り方はバスタブ曲線（後述）でモデル化されます。2026年では、AIチップの信頼性評価に「故障注入テスト（Fault Injection）」が標準化され、実際の運用前に弱点を洗い出しています。
可用性	可用性（Availability）は、「システムが要求されたときに、ただちに使用可能な状態にある確率」です。信頼性と似ていますが、修理・復旧を含む「全体としての利用可能性」がポイント。例：サーバーが1日1回1分止まる → 年間停止6時間 → 可用性 ≈ 99.93％（「3つの9」）。現代の金融・医療システムでは「5つの9（99.999％＝年間5分未満停止）」が求められ、冗長構成＋自動フェールオーバーで実現します。2026年では、エッジAIデバイスでも可用性向上のため、ローカル・バックアップ処理が組み込まれています。
保守性	保守性（Serviceability）とは、「故障時の修理・点検・部品交換が、どれだけ迅速・容易に行えるか」を表す特性です。高保守性の例：・モジュール設計（故障部分だけ交換可能）・リモート診断機能（現場に行かず原因特定）・拡張ログ出力（エラー発生時の状態を詳細記録）　2026年現在、AI駆動の予知保全（Predictive Maintenance）が主流——センサーで振動・温度を監視し、「あと24時間で故障」と予測して、計画停止中に交換する仕組みです。これにより、MTTRが劇的に短縮されています。
保全性	※ 正確には「完全性（Integrity）」と訳されます。保全性（Integrity）は、「データやシステムが、不正な改ざん・破壊・漏洩から守られ、正確で完全な状態を保てる性質」です。例：・暗号化ハッシュ（SHA-3）で改ざん検知・ブロックチェーンで履歴の不変性確保・アクセス制御リスト（ACL）で不正操作防止　2026年では、AI生成コンテンツの真正性確保のため、「証跡付きトレーサビリティ」が必須——画像1枚にも「誰が・いつ・どんなモデルで生成したか」のメタ情報が埋め込まれています（IEEE P2872標準で策定中）。
安全性	安全性（Safety）は、「システムが故障・誤動作しても、人・環境・社会に危害を与えない性質」です。信頼性が「動くこと」、可用性が「使えること」なら、安全性は「暴走しないこと」。例：・自動運転車：センサー故障→即時減速＋路肩停止・原子力プラント：二重三重の非常停止装置・医療AI：診断AIが「自信なし」と判断→人間医師にエスカレーション　2026年、ISO/SAE 21434（自動車サイバーセキュリティ）とIEC 61508（機能安全）が統合され、「サイバーセーフティ」として一元管理される時代に。
バスタブ曲線	バスタブ曲線は、装置の「故障率λ（ラムダ）の経時変化」を表したグラフで、その形が浴槽（バスタブ）に似ていることから名付けられました。3つの期間に分けられます： 1.初期故障期間：製造欠陥・調整ミスで故障率が高いが、時間とともに急減 2.偶発故障期間：故障率がほぼ一定（ポアソン過程に近い）→ MTBFの主計算対象 3.摩耗故障期間：部品劣化で故障率が再び上昇 2026年では、IoTセンサーでリアルタイムにこの曲線を推定し、「摩耗期に入る前に交換」する戦略が普通です。
初期故障期間	初期故障期間は、製品出荷直後の「慣らし運転期」。原因は、・部品の製造ばらつき・組み立てミス（ネジの締め忘れなど）・ファームウェアの初期バグ　対策として、工場で「バーニンイン（Burn-in）」という過負荷運転テストを行い、弱い個体を事前にふるい落とします。スマホやSSDは、この工程を経て出荷されています。2026年では、AIによる初期異常検知で、バーニンイン時間を50％短縮する事例も。
偶発故障期間	偶発故障期間は、故障率がほぼ一定（λ = const）となる安定期。自然災害・操作ミス・宇宙線によるビット反転（SEU）などが原因で、時間経過とは無関係に発生します。この期間の信頼性関数は、指数分布で表されます。 R(t)=e−λt → これがMTBFの基礎です。クラウドサーバーの「突然の電源落ち」は、この期間の故障とみなされます。
摩耗故障期間	摩耗故障期間は、部品の劣化・疲労・消耗により、故障率が時間とともに指数関数的に増加する期間です。代表例：・HDDのモーター軸受け摩耗・バッテリーの充放電サイクル劣化・半導体の electromigration（電気的移動）　2026年では、デジタルツイン（物理デバイスの仮想モデル）で摩耗シミュレーションを行い、個別最適交換スケジュールを立てています。
稼働率の求め方	稼働率（Availability）は、次式で求められます。 A=稼働時間稼働時間+停止時間=MTBFMTBF+MTTR 【例】MTBF＝1000時間、MTTR＝10時間 → A=10001000+10≈0.9901=99.01% → 「2つの9」。金融系ではMTTRを5分以下（0.083h）にすると、MTBF＝2000hでも「4つの9（99.99％）」達成可能。MTTR短縮がカギです。
MTBFを長くする方法	MTBF（Mean Time Between Failures）は「平均故障間隔」。長くするには、 ✅ 高信頼部品の採用（車載グレードICなど） ✅ 冗長設計（2重化で1台壊れても動く） ✅ 熱設計改善（温度↑10℃→寿命半減！） ✅ 環境ストレス低減（振動対策・防塵） ✅ フェイルセーフ設計（故障→安全状態へ遷移） 2026年トレンド：AIで設計段階から弱点予測（例：FMEA自動生成ツール「ReliaAI」が注目）。
MTTRを短くする方法	MTTR（Mean Time To Repair）は「平均修理時間」。短縮策は、 ✅ モジュール交換式設計（全体交換→部品交換） ✅ リモート診断・自動復旧（再起動スクリプト） ✅ ARゴーグルで作業ナビゲーション ✅ 予備部品の自動発注（IoT在庫管理連携） ✅ フォールトトレラント設計（修理中も動作継続）実例：某データセンターでは、自律走行ロボットが故障ユニットを回収・交換し、MTTRを3分→45秒に短縮（2025年実証）。
故障率の求め方	故障率λ（単位：回/時間）は、 λ=観測期間中の故障総数総運転時間【例】100台の装置を1000時間運転（総10万時間）し、5回故障 → λ=5100,000=5×10−5 [回/時間] ⚠️ 偶発故障期間（一定λ）でのみ有効。初期・摩耗期は時間帯ごとに区切って計算します。
故障率からMTBFを求める	MTBF と故障率λ は、偶発故障期間で次のように関係します。 MTBF=1λ 【例】λ = 5 × 10⁻⁵ 回/時間 → MTBF=15×10−5=20,000 時間≈2.3 年 → 1台なら2.3年に1回故障。100台なら年間約21回故障（100 ÷ 2.3）。スケールすると故障頻度が増す点に注意。
故障してない機器の平均台数の求め方	N台の装置があり、各台の稼働率がAで独立なら、 → 故障していない台数の期待値は、平均稼働台数=N×A 【例】10台サーバー（A＝0.95）→ 平均9.5台が動いている。応用：クラウドの「スケールアウト要件計算」——ピーク時に12台必要なら、A＝0.9のサーバーなら14台（12 ÷ 0.9 ≈ 13.3→切り上げ）を用意。
直列接続の稼働率の求め方	直列接続は「全部が動いていないとシステム全体が動かない」構成（例：電源→基板→CPU→メモリ）。全体の稼働率は、各部品の稼働率の積。 A直列=A1×A2×⋯×An 【例】A₁=0.99, A₂=0.98 → A＝0.99×0.98＝0.9702（97.02％） → 部品が増えれば増えるほど、全体の信頼性は急激に低下します。信頼性設計の最大の敵。
並列接続の稼働率の求め方	並列接続は「どれか1つ動いていればOK」の冗長構成（例：2台の電源、どちらかが動けば供給継続）。 2台のとき、 A並列=1−(1−A)2 N台で同一稼働率Aのとき、 A並列=1−(1−A)N 【例】A＝0.9の部品を2台並列 → A=1−(0.1)2=1−0.01=0.99 (99%) → 直列で90％の部品が、並列で99％に！ただし、切り替え機構の信頼性も考慮が必要（2026年ではソフトウェアSWが主流→信頼性99.999％実現）。
FIT	FIT（Failures In Time）は、10億（10⁹）デバイス時間あたりの故障数を表す単位です。 1 FIT=1 回故障/109 デバイス・時間 → 故障率λとの関係： λ [回/時間]=FIT値109⇒MTBF=109FIT値 [時間] 【例】メモリのFIT＝50 → λ = 5×10⁻⁸ → MTBF = 2000万時間（約2282年！） 💡 注：これは「1個あたり」の理論値。10万個使えば、平均20時間に1回故障します。 2026年現在、宇宙・医療用半導体ではFIT＜1が要求され、Neutron Beam照射試験で宇宙線耐性を検証しています。