すべての記事
ワードカテゴリ
新着記事
バウンダリースパナーとは。語源や事例、デメリットをわかりやす...
HR・採用・人事・教育
戦略・フレームワーク
マネジメント
経営
配当割引モデルをわかりやすく解説。ゼロ成長・定率成長モデルの...
ファイナンス
経営
評価
売却損によるキャッシュフローの節税効果を解説。なぜプラスにな...
ファイナンス
経営
評価
データ分析
記事カテゴリ
INSIGHT
応用情報技術者テキスト
2026.01.19
2026/2/3 06:08
技術

応用情報技術者試験対策ができる単語を中心とした学習テキストです。
復習や単語帳としてご利用ください。
- 離散数学
- 基数
- 補数
- 固定小数点数表現
- 浮動小数点数表現
- 基数変換
- 有限小数
- 無限小数
- 循環小数
- 桁落ち
- 情報落ち
- システム構成
- デュアルシステム
- デュプレックスシステム
- クライアントサーバシステム
- アムダールの法則
- RAID(レイド)
- RAID0
- RAID1
- RAID0+1、RAID1+0
- RAID3
- RAID4
- RAID5
- RAID6
- 信頼性設計
- フォールトレランス
- フォールトアボイダンス
- フォールトマスキング
- フェールセーフ
- フェールソフト
- フールプルーフ
- システム構成2
- クラスタ・クラスタリング
- シンクライアンt
- ピアツーピア・P2P
- 分散処理システム
- オーバーヘッド
- 有機ELディスプレイ(OLED)
- ジョブの多重度
- LRUアルゴリズム
- 稼働率の計算方法
- ウォッチドッグタイマ
- Web開発から考えるデータベースの3層スキーマについて
離散数学
離散数学とはとびとびの数字を扱う数学のことです。
基数
基数とは数を表現するときに桁上がりの基準になる数です。10進数なら基数は10、2進数なら2です。
補数
補数とはコンピュータ上で負の数を示すときに用いるもので、ある自然数に足した時に桁が1つ上がる最も小さい数です。
固定小数点数表現
あらかじめ小数点の位置を決めておき、その位置に合わせてデータを表現する方法です。例えば8桁分の場所を確保しておき、4桁目の後に小数点を固定する、といったものです。データの解釈は簡単ですが、表現できる数値の範囲が限られます。
浮動小数点数表現
指数部と仮数部を使って数値を表現します。16ビットの浮動小数点数形式では、仮数部の符号:1ビット(0:正, 1:負)、指数部:4ビット、仮数部11ビット、のように分けられ、10進数0.25を表現する場合、0 1111 100000000000、となります。
基数変換
10進数から2進数に置き換えるなど、基数の異なるものへ表現を変えることを基数変換といいます。基数変換をすると誤差が発生します。
有限小数
例えば、10進数の0.4といった、有限の桁で表現されている数のことを有限小数といいます。0.4を2進数に基数変換すると割り切れず、循環小数になります。
無限小数
有限小数で表せない小数のことを無限小数といいます。
循環小数
無限小数のうち、部分的にくりかえして表現されるようなものを循環小数といいます。10進数の0.4を2進数に基数変換した場合、0.011001100110... となり、0110が繰り返し表示される循環小数となります。逆に2進数から10進数に変換すると必ず有限小数になります。
桁落ち
桁落ちとは値がほぼ等しい2つの数値の差を求めた時、有効数字の桁数である有効桁数が減ることで発生する誤差です。
情報落ち
絶対値が非常に大きな数と小さな数の和や差を求めた時、小さい数値が計算結果に反映されないことによる誤差です。例えば、248.569 + 0.000011 = 248.569(有効桁数関係で無視)という結果になります。
システム構成
デュアルシステム
2つのシステムを並列して処理させ、結果を比較する方式。 ・比較するので信頼性が高い ・1つに障害が発生しても、もう1つで処理を続行できる
デュプレックスシステム
1つを稼働させて、もう1つを待機させておく方式 稼働させるシステムを主系(現用系)、待機させるシステムを従系(待機系)と呼ぶ。
デュプレックスシステム
└ホットスタンバイ→常時稼働可能な状態
└ウォームスタンバイ→本番と同じような状態ではあるがすぐには稼働できない状態、サーバーは立ち上がっているがアプリケーションが稼働していない
└コールドスタンバイ→機器の用意をしているだけの状態、電源を入れて稼働させる
クライアントサーバシステム
クライアントとサーバで役割分担して処理を行うシステム。 一般的なWebシステムの場合、
ユーザー
│
プレゼンテーション層(PR):Webブラウザ
│
ファンクション層(FN):Webサーバ
│
データベースアクセス層(DB):DBサーバ
という役割分担になる。クライアントとはWebブラウザを指すことが多い。
アムダールの法則
コンピュータの並列処理の性能向上を定量的に表すときの原則のこと。 システムの一部を高速化しても、全体としての向上はその高速化部分の占める比率に依存する。
RAID(レイド)
複数台のディスクを接続して全体で一つの記憶装置として扱う仕組みのこと。 NASを複数台設置して構成したりする。社内基幹システムをNASでRAIDを組んで構築している会社もある。
RAID0
複数台のディスクにデータを分散し高速化させる(ストライピングという)。 データが分散するので信頼性は低下する。
RAID1
複数台のディスクに同時にデータを書き込む(ミラーリングという) 信頼性が上がるが、特に速くはならない。
RAID0+1、RAID1+0
それぞれ、ストライピングとミラーリングを両方行う。 順番の違いで構成が変わるが、どちらも最低4つのディスクが必要になる。
RAID3
複数台のうち1台を誤り訂正用のパリティディスクにし、復元できるようにしたもの。 ディスク故障時の復元をビット単位で行う。 最低でもディスクが3枚必要。
RAID4
RAID3と同じだが、ディスク故障時の復元をブロックごとにまとめて行う。 最低でもディスクが3枚必要。
RAID5
RAID3、RAID4のようにディスクの1つをパリティ専用とせず、全てのディスクにブロックごとにパリティを分散したもの。 故障のない通常時も全てのディスクを使用できる。分散したことによりアクセス効率が上がっている。 最低でもディスクが3枚必要。 ディスクが2枚同時に故障すると復元できない。
RAID6
RAID5の2枚同時故障時に対応するため、冗長データを2種類用意したもの。 最低でもディスクが4枚必要。
信頼性設計
システム全体の信頼性を設計する際は、全体の視点が必要。 フォールトレランス、フォールトアボイダンス、フェールセーフなどの方法がある。 またこうした方法を用いて、信頼性を高める。
フォールトレランス
一部で障害が起こっても、全体でカバーし機能停止を防ぐ考え方
フォールトアボイダンス
個々の機器の障害発生確率を下げることで、全体の信頼性を向上する考え方
フォールトマスキング
機器の故障時、影響が外部に出ないようにする方法。 装置の冗長化などで1台故障しても影響がでないようにする、など。
フェールセーフ
障害発生時、安全側に制御する方法。信号機が故障したときにとりあえず赤にする、など。
フェールソフト
障害発生時、最低限のシステムの稼働を続ける方法。障害部分を切り離すなどする。 機能を限定して稼働させる方法をフォールバックという。
フールプルーフ
利用者が誤った操作をしても危険な状態にならないようにする、間違った操作ができないようにする設計手法。 押してはいけないボタンを押せないようにする、人間をセンサで感知し機械を停止させるインタロック、など。
システム構成2
クラスタ・クラスタリング
複数のコンピュータと結合してひとまとまりにしたシステム。 負荷分散や高性能計算機(HPC)などで使用。
シンクライアンt
クライアント端末に必要最低限の処理を行わせ、ほとんどの処理をサーバ側で行う方式。
ピアツーピア・P2P
サーバを介さず、クライアント端末同士で通信を行う形式。 NFC、IP電話、Skypeなど。
分散処理システム
複数のプログラムが並列的に複数台のコンピュータで実行され、それらが通信しあって一つの処理を行うシステム。 アクセス透過性(利用者にシステムの場所を意識させないように利用できるようにすること)が必要。
オーバーヘッド
処理を行うためにシステムの管理や制御に消費されるリソースのこと。
リソースにあたるものとして、CPUの使用率、メモリ、通信時間などがある。
例として、ネットワークではデータ送信時、データ本体だけでなく、ヘッダー情報も送信するが、このヘッダー情報はオーバーヘッドといえる。
仮想化における別のOSを動かすための管理ソフトを動作させるリソースも、仮想化によるオーバヘッドといえる。
有機ELディスプレイ(OLED)
Organic LED(オーガニックLED)を略してOLEDと呼んでいる。
画素1つが自分で発光する仕組み。従来のLCDディスプレイはバックライトが必要だが有機ELは不要。
有機ELディスプレイは以下5層からなる。この5層は一方方向に進むのではなく、カソードからプラス、アノードからマイナスが注入され、両方から中心に向かっていく。
(+)正孔
↓
・カソード/電子を送り出す層
↓(+)
・電子輸送層/電子を有機発行層へ運ぶ層
↓(+)
・有機発光層/実際に光を放つ層、正孔と電子が合体、高エネルギー物質になり、元の安定した状態に戻ろうとする際、余ったエネルギーを光として放出。
↑(-)
・正孔輸送層/電子が足りない穴(正孔)を運ぶ層
↑(-)
・アノード/正孔を送り出す層
↑
(-)電子
有機ELの特徴
・バックライト不要なため、黒が完全な黒になる。LCDの場合はバックライトでわずかに明るくなってしまう。
・バックライト不要なため、薄く、ディスプレイ自体を曲げることも可能。
・応答速度がLCDより速い。
有機ELのデメリット
・寿命が短い
・焼き付きが起こる
ジョブの多重度
CPUやリソースが同時に実行状態にできる仕事の数のこと。
例えばジョブの多重度が1の場合は、1つのジョブが実行中に別のジョブが到着しても、1つ目のジョブが完了するまで2つ目のジョブは待機状態になる。
いくつかのジョブを処理するまでの時間のことをターンアラウンドタイムともよぶ。
ジョブの多重度により待機時間が発生するため、いかに空き時間を減らし、効率よく処理するかが問題になるが、このときの全体的な処理効率をスループットと言い、効率を挙げることをスループットを上げるなどと言う。
LRUアルゴリズム
まず、仮想記憶におけるページ管理について説明する。仮想記憶のアドレス直行でアクセスするのではなく、一定の範囲を分割した単位で保持しておく。
この分割単位を「ページ」と呼んでいる。そして、メモリに保持できるページは限られているので、保持しているページにないアドレスのデータを求められた場合はページを入れ替える必要がある。
このとき、保持しているどのページを追い出すべきかを決める必要があるが、このアルゴリズムにLRUがあるということである。
LRUアルゴリズムは、時系列で管理し「最も長く使われていないページをページアウト(追い出す)」するアルゴリズムである。
そして新しいページを読み込むことをページインと言う。LRUではページインされたページは、時系列的に最も新しいページとして記憶される。
また、ページインする際は、ページアウトされたアドレスに入るので、ページインするアドレスは必ずしも同じ場所とは限らない。
例えば、
ページの保持用のアドレスを2000番地、3000番地、4000番地、とする。
このときの番地はそれぞれ、ページが1つずつ入る単位で、今回は3つページを保持できるということである。
ページ番号として1ページ,2ページ,3ページ,の順番でページを読み込むと以下のように保持される。
2000:1
3000:2
4000:3
そしてこれを時系列的に表すと
要求ページ
----:123
メモリ
2000:111
3000:-22
4000:--3
このようになり、最も長く使われていないものが1ページ、最も新しいものが3ページとなる。
ここから、メモリ上にない4ページを求められた場合、最も長く使われていないていないページである1ページを追い出し、同じアドレスへ4ページをページインする。
要求ページ
----:1234
メモリ
2000:1114
3000:-222
4000:--33
すでに保持されているページである2ページを要求する場合は、ページアウトは発生しない。
要求ページ
----:12342
メモリ
2000:11144
3000:-2222
4000:--333
この状態から1ページを要求された場合、ページアウトが必要である。一見2ページをページアウトするかと思うが、直前で2ページは要求されたため「最も長く使われていないていないページ」ではなくなっている。
現在最も長く使われていないていないページは3ページである。
要求ページ
----:123421
メモリ
2000:111444
3000:-22222
4000:--3331
このようにページの入れ替えを行うアルゴリズムがLRUである。
稼働率の計算方法
システムの稼働率の計算は並列か直列かによって以下の式で算出することができる。
ここでいう直列、並列は電気の流れの直列つなぎと並列つなぎと同じような考え方である。
<直列>
-[a]-[b]-
【式】※覚えましょう
a×b
<並列>
┌[a]┐
─┤ ├─
└[b]┘
【式】※覚えましょう
1-(1-a)(1-b)
例えば、aが30%、bが40%の場合を考える。この時、1-aなどとしなければならないため、%ではなく小数で考える。
<直列>
0.3 × 0.4 = 0.12
稼働率は12%
<並列>
1-(1-0.3)(1-0.4)
=1-(0.7)(0.6)
=1-0.42
=0.58
稼働率は58%
では並列の方が良いのか、と言われると、必ずしもそうではなくシステムによると考えられる。
aとbは同じシステムではないため、aの実行が確実になされた場合にのみbを実行する必要があるとすれば、必然的に直列の構成になるだろう。
あくまで、a、bなど複数のシステムを各接続方法で稼働させた場合の、全体としての稼働率を求めている。
とはいえ、1つでも実行させられればOK、ということであれば稼働率が高い構成を選択することになるであろう。
また、直列と並列が組み合わせて使われている場合もあるが、順番に計算していけば同じように算出できる。
例えば、aの後にbを実行する必要がある場合で、単なる直列より稼働率を高めたい場合は、並列を直列でつなぐ方法が考えられる。
aが30%、bが40%の場合
<並列と直列>
┌[a]┐┌[b]┐
─┤ ├┤ ├─
└[a]┘└[b]┘
(1-(1-0.3)(1-0.3))×(1-(1-0.4)(1-0.4))
=(1-(0.7)(0.7))×(1-(0.6)(0.6))
=(1-(0.49))×(1-(0.36))
=0.51 × 0.64
=0.3264
稼働率は32.64%
(直列のみの場合は12%であった)
このように、a→bで必ず実行しなければならない場合でも、それぞれを並列化することで、全体の稼働率を向上させられることがわかる。
おおむね、並列化は稼働率の向上、直列化は稼働率の低下、に影響していると覚えておくことも可能であろう。
ウォッチドッグタイマ
システムがフリーズ、暴走していないか監視し、異常があればシステムを再起動させる仕組みのことである。
何がタイマーなのかというと、システム開始時にカウントダウンを開始する仕組みだからである。
このカウントダウンがセロになるとシステムをリセットする。
システムが正常に動いている間は、ゼロになる前にカウントダウンを定期的にリセットするので、正常な間はゼロになることはない。
この定期的なリセットが、犬にエサをあげるのに似ているため、ウォッチ「ドッグ」タイマと呼ばれている(番犬)。
Web開発から考えるデータベースの3層スキーマについて
大規模システムや厳密なシステム構築の場合、データベースのスキーマを意識する必要がある。
例えば、Mysqlで1テーブルのレコードが1000万件を超えそうな場合はスキーマを意識して設計する必要がある。
とはいえ、サービス開始して1000万件にもうすぐ届きそうだから改修しよう!では遅い可能性が高く、予め意識できると本来はよいのであろう。
では3層スキーマの概要を解説する。
普段ライトな開発(特に社内システムなど、アクセスの上限があらかじめ決まっているようなサービス)などを取り扱うことが多い開発者はほとんど意識したことがないであろう。
3つのスキーマは以下のようなものである。
①外部スキーマ
・ビューと呼ばれる。実際のテーブル構造を知らなくても必要なデータだけを特定の形で表示させたもの。
②概念スキーマ
・DB全体の論理的な構造。テーブル、リレーションと呼ばれる。一般的にDB設計というとこの部分のことを指す。
③内部スキーマ
・物理的なディスク上の保存形式。インデックス、ストレージエンジンと呼ばれる。データをどう圧縮するのか、どうインデックスするかといった管理部分。
ビュー、テーブル、リレーション、インデックス、など個別の単語はよく耳にするかもしれないが、実際にスキーマとして考えるとそれぞれ別の部分の話をしていることがわかる。
Mysqlの場合、InnoDBなどストレージエンジンと呼ばれるものを選択できる。
ストレージエンジンは内部スキーマを管理してくれている。
SQLは概念スキーマへの命令となるが、裏側でInnoDBなどストレージエンジンが、データをどうファイルに書き出すかをうまく制御してくれるため、物理的な配置を意識しなくて済むということである。
各階層で関係する用語には以下のようなものがある。
①外部スキーマ
・APIレスポンス、ビュー、権限管理
②概念スキーマ
・ER図、正規化、テーブル、リレーション
③内部スキーマ
・インデックス、パーティショニング、スロークエリ、バッファプール
実務的な話として、どのくらいの規模から上記の構成を気にする必要がありそうか、参考程度に考えてみよう。
規模の例として、レコード数をで考えてみる。
レコード数
~10万件:
ほぼ意識する必要がない。設計が多少荒かったとしてもメモリ上で処理が可能な範囲と考えられる。
100万件~:
インデックスが必須と考えられる。フルスキャンを行うと数秒待たされる可能性がある。
1000万件~:
主キーの選び方で速度が数倍変わる状態。内部スキーマに極めて配慮が必要と考えられる。
1億件~:
パーティショニング、シャーディングが必要。単一のテーブルではそもそもバックアップやインデックスの再構築すら終わらなくなる可能性。
このような実際の状況が考えられる。
社内システムの開発なのか、不特定多数に向けたサービスなのかによって、バランスを取りながら構築する必要があるだろう。
もちろん、全スキーマに配慮しつつ構築できることが望ましいが、それでは開発に着手するまでに多大な時間がかかる場合もある。
共通フレーム2013では、経営視点からシステム投資に対するリターン、利益にも目を向けることが、明確に示されており、リリース後の数年~数十年を見越して大規模ではない、と判断できる場合はスキーマに対する配慮はやむ負えずお行わない、という選択肢も十分にあり得ると考えられる。
上記はあくまで、たいした利益を生まない、かつ負債にもならなそうなシステムにあえてリソースを割くわけにはいかない、というビジネス上の観点での判断の話である。
システム開発者の心得としては、DBについて詳しくなるべきであるし、リソース的に配慮が可能であるなら実行すべきであろう。
当記事の執筆者
CIT経営開発事務所 代表
井上 隆寛(いのうえ・たかひろ)
IT・事業コンサルタント
IT・開発エンジニア
行政書士R6合格者未登録
大手システム開発会社にてフルスタックSE兼Webデザイナーとして従事。2021年にコンサルタントとして独立し、企業に対するITコンサルティング・ソリューション導入支援事業を開始。2023年にはイベント企画・運営事業を新たに展開、2024年には行政書士試験に合格。現在はIT・AIコンサルティング、システム開発、エンターテイメントの3事業を柱に、企業の技術顧問や講師としてICT教育やプログラミング授業も手がける。


