忍者ブログ
情報処理技術者試験の合格を目指す全受験者のための、1問1問「徹底解説」ブログです。単なる過去問の暗記ではなく、なぜその答えになるのかを本質的に理解できるよう解説します。書籍などでは学べない最新用語やトレンドを踏まえてご紹介します。

【データベース】元通りに復元できる!「無損失分解」の定義|情報処理問題1000本ノック

テーブルの正規化などで表を分割する際、ただ分ければいいというわけではありません。元の情報を完全に保持したまま分割できているか。それが「無損失分解」のポイントです。

1. 問題:情報が損なわれない分割の条件

【 問題 】 関係データベースにおいて、一つの表を二つ以上の表に分割(分解)した後、それらを自然結合させた結果が、元の表と完全に一致するような分割のことを何と呼ぶでしょうか?

① 垂直分解   ② 無損失分解   ③ 直積分解   ④ 正規化分解

2. 正解:正規化理論に関する正解

正解: ② 無損失分解

3. 解説:自然結合で元に戻せるか

テーブルを分割する際、適切なキー(共通の列)を残さずに分けると、後で結合したときに元の情報が復元できなくなったり、余計な行(偽のタプル)が発生したりします。「無損失分解」とは、分解しても情報の損失がなく、自然結合によって元の表を一意に再現できる性質を指します。

[ 無損失分解のポイント ]
定義:分解された表を自然結合すると、元の表と等しくなること。
条件:分解する際の共通属性が、少なくとも一方の表の主キー(または候補キー)である場合に成立します。

[ 関連用語の整理 ]
正規化:冗長性を排除し、更新異常を防ぐために表を分割するプロセス。
関数従属性:ある属性の値が決まれば、他の属性の値も一意に決まる関係。
結合従属性:表をいくつかの部分に分解し、それらを再結合しても元の表を再現できる性質。

1. 理解のコツ: 「無損失」という言葉から、単純に「データが消えない」ことだと思われがちですが、実際には「結合したときに余計なデータが増えない(元の関係が壊れない)」ことも含まれます。パズルをバラバラにしても、正しく組み直せる仕組みが備わっている状態です。
2. 試験対策の視点: 第2正規形や第3正規形への分解は、すべてこの「無損失分解」であることが前提です。高度試験では、「表R(A, B, C)をR1(A, B)とR2(A, C)に分解したとき、無損失分解となる条件は?」といった形式で、関数従属性と絡めて問われることが多いです。


4. まとめ

「分割した表をくっつけたら、元通りになる」。これが無損失分解の核となる定義です。データベースの整合性を保ちながら、正しく正規化を行うための必須条件であることを押さえておきましょう!



PR

【開発管理】上流から下流へ!ウォーターフォールモデルの欠点と特徴|情報処理問題1000本ノック

滝が上から下へ流れるように、工程を一つずつ完結させて進める「ウォーターフォールモデル」。計画の立てやすさという大きなメリットの反面、現代のスピード感ある開発では課題となる「欠点」についても正しく理解しておきましょう。

1. 問題:開発モデルの特性と欠点

【 問題 】 システム開発におけるウォーターフォールモデルの欠点や性質として、不適切な(誤っている)ものはどれでしょうか?

① プロジェクトの後半にならないと、実際のソフトウェアが確認できない。
② 開発後半での仕様変更や手戻りに対して、柔軟に対応できないことがある。
③ 各工程で分業を前提とするため、工程間でのコミュニケーションロスが発生する可能性がある。
④ 開発の初期段階で、全体の期間や金額を固定的に見積もることができない。

2. 正解:開発モデルの比較に関する正解

正解: ④ 開発の初期段階で、全体の期間や金額を固定的に見積もることができない。

3. 解説:計画性と柔軟性のトレードオフ

ウォーターフォールモデルは、最初に全ての要件を決め、それに沿ってスケジュールを引き、工数を見積もります。そのため、「期間や金額を最初に見積もりやすい(固定しやすい)」のが最大の特徴であり、選択肢④はメリットの説明となっているため、欠点としては不適切です。

[ ウォーターフォールモデルの欠点 ]
実機確認の遅れ:テスト工程(後半)まで動くものが見えないため、最後に「イメージと違う」というリスクがある。
変更への弱さ:前の工程に戻る「手戻り」のコストが非常に高く、仕様変更に柔軟に対応しづらい。
分業の弊害:設計者と開発者が異なる場合など、ドキュメントを通じた伝達ミスが起きやすい。

[ アジャイルモデルとの違い ]
アジャイル:短いサイクルでリリースを繰り返し、変更に柔軟。ただし、全体の最終的な期間や金額を最初から固定するのは苦手。

1. 理解のコツ: ウォーターフォールは「建築(ビルを建てる)」、アジャイルは「料理(味見しながら作る)」に例えられます。ビルを建てる前に予算と工期が決まっていないと困るように、大規模な基幹システムなどでは今でもウォーターフォールが主流です。
2. 試験対策の視点: 試験では「手戻りコストの増大」や「利用者の確認が遅れる」といった欠点と、他の開発モデル(アジャイル、スパイラル、プロトタイピング)との比較が頻出します。それぞれの強みと弱みを表裏一体で覚えましょう。


4. まとめ

「最初に計画を固め、順序良く進める」。これがウォーターフォールモデルの核となる性質です。計画を固定しやすいというメリットが、変化の激しい現代では「柔軟性の欠如」という欠点にもなり得ることを押さえておきましょう!

【コンピュータ構成要素】先読みで加速する!分岐予測の仕組み|情報処理問題1000本ノック

CPUが命令を処理する際、次にどの道に進むかを「予測」して動く。プロセッサの処理効率を極限まで高めるための知的な制御手法「分岐予測」の概念を整理しましょう。

1. 問題:パイプラインの停止を防ぐ先回り実行

【 問題 】 CPUの高速化手法の一つで、条件分岐命令(if文など)の実行結果をあらかじめ予測し、その分岐先の命令を先行的に実行することで、パイプラインの乱れや停止(ハザード)を防ぐ技術を何と呼ぶでしょうか?

① スーパスカラ   ② 分岐予測   ③ アウトオブオーダ実行   ④ キャッシュメモリ

2. 正解:CPUの制御手法に関する正解

正解: ② 分岐予測

3. 解説:結果を待たずに「投機的」に実行する

CPUは複数の命令を段階的に並行実行する「パイプライン処理」を行っています。しかし、条件分岐があると「どちらに進むか」が確定するまで次の命令を読み込めません。そこで、過去の履歴などから分岐先を予測し、先に計算を進めてしまうのが「分岐予測」です。

[ 分岐予測のポイント ]
目的:条件が決まるまでCPUが待機してしまう「パイプラインハザード」を回避し、スループットを向上させる。
投機的実行:予測に基づいて「たぶんこうなるだろう」と先行して実行することを指します。予測が外れた場合は、実行結果を破棄して正しい分岐先からやり直します。

[ 他の選択肢との違い ]
スーパスカラ:複数のパイプラインを持ち、複数の命令を同時に実行する物理的な仕組み。
アウトオブオーダ実行:命令の記述順序に縛られず、データが揃った命令から実行する仕組み。
キャッシュメモリ:CPUと主記憶(メモリ)の速度差を埋めるための高速な記憶装置。

1. 理解のコツ: 「もしAならこちら、Bならあちら」という結果を待たずに、過去の傾向から「次はAだろう!」と決め打ちして作業を進めておくイメージです。当たれば大幅な時短になり、外れても元の場所からやり直すだけという、リスクを取ってリターンを得る攻めの技術です。
2. 試験対策の視点: 「制御フロー」「先行的に実行」「パイプラインの効率化」といったキーワードがセットで登場します。高度試験では、予測が外れた際の損失(分岐ペナルティ)についても触れられることがあります。


4. まとめ

「条件分岐の結果を予測して、先行的に命令を実行する」。これが分岐予測の核となる定義です。ハードウェアがソフトの動きを先読みして、処理の「空白」を作らないようにする高度な工夫であることを押さえておきましょう!


【今日現場で出た!IT用語実戦解説】権限の範囲を定義する「Scope」の正体|情報処理問題1000本ノック

今日の現場でも一日中議論の的になった「Scope(スコープ)」。OIDC(OpenID Connect)などの認証・認可基盤を設計する上で、避けては通れない最重要キーワードです。試験上の定義と、現場での「あるある」をセットで整理しましょう。

1. 問題:アクセス範囲を要求する仕組み

【 問題 】 OIDCやOAuth 2.0において、アプリケーションが認証サーバーに対して、「ユーザーのメールアドレス」や「プロフィール情報」など、どのリソースへのアクセス権限を必要としているかを指定するための識別子を何と呼ぶでしょうか?

① Claim (クレーム)   ② Scope (スコープ)   ③ Grant (グラント)   ④ Audience (オーディエンス)

2. 正解:認可の範囲設定に関する正解

正解: ② Scope (スコープ)

3. 解説:メニュー(Scope)と中身(Claim)の関係

Scopeは、アプリが「この範囲の情報を見せてほしい」と頼むための「注文票(メニュー)」のようなものです。サーバー側でそのScopeが承認されると、発行されるトークンの中に、具体的なデータ値である「Claim(クレーム:属性情報)」が格納されて戻ってきます。

[ Scopeの代表例 ]
openid:OIDCを利用するための必須スコープ。これがないとIDトークンが発行されません。
profile:氏名、性別、誕生日などの基本情報へのアクセスを要求します。
email:メールアドレスの取得を要求します。

[ 混同しやすい用語との違い ]
Claim:Scopeの結果として返ってくる、ユーザーIDや名前などの「具体的なデータ項目(中身)」のこと。
Audience:そのトークンが「どのアプリ(宛先)向けに発行されたか」を示す識別子のこと。

1. 理解のコツ: Scopeはあくまで「範囲の要求」です。例えば `scope=email` と要求しても、ユーザーが認可画面で拒否したり、サーバー側にデータがなかったりすれば、結果のトークンにメールアドレス(Claim)は含まれません。
2. 最新トレンドの視点: セキュリティ設計では「最小権限の原則」が鉄則です。不必要に広いScopeを要求すると、万が一トークンが漏洩した際の被害が大きくなるため、実務では「本当にそのアプリにその権限が必要か?」が厳しくレビューされます。


4. まとめ

「アプリが欲しがっている情報の範囲」。これがScopeです。ユーザーが「どの情報を渡してよいか」を判断する境界線となる、ID連携の要(かなめ)といえる概念です。

---

【今日現場で出た!エンジニアの裏話】

今日は一日中、このScopeの設計に頭を悩ませていました。現場で最もハマりやすいのが、「指定したScopeに対して、どのClaim(属性)が返ってくるかはIdP(認証サーバー)製品によって微妙に違う」という問題です。

標準的な `profile` スコープを投げても、ある製品は「氏名」しか返さないのに、別の製品は「住所」まで返してくることがあります。

このような細かい項目を、一つ一つ潰していくのが、エンジニアの仕事だな。


【セキュリティ】文字を入れ替える古典暗号の王道!換字式暗号の定義|情報処理問題1000本ノック

暗号の歴史は「文字の置き換え」から始まりました。現代の高度な暗号の基礎要素でもある「換字(かんじ)式暗号」の仕組みを正しく理解しましょう。

1. 問題:対応表を用いた文字の変換

【 問題 】 暗号化の方式のうち、アルファベットなどの各文字を、あらかじめ決められた対応表に従って別の文字に置き換える方式を何と呼ぶでしょうか?(例:AをDに、BをEに変換する、など)

① 転置式暗号   ② 換字式暗号   ③ ストリーム暗号   ④ 公開鍵暗号

2. 正解:暗号化方式の分類に関する正解

正解: ② 換字式暗号

3. 解説:文字の「置き換え」による秘匿

換字(かんじ)とは「字を換える」という意味です。文字の並び順はそのままで、文字そのものを別の文字に変換します。有名な「シーザー暗号」も、アルファベットを3文字ずらすというルールに基づいた換字式暗号の一種です。

[ 換字式暗号のポイント ]
仕組み:特定の文字を、対応表(アルファベットの変換表など)に基づいて別の文字へ変換します。
特徴:文字の「種類」が変わりますが、出現する場所や頻度の傾向が残りやすい性質があります。

[ 他の選択肢との違い ]
転置式暗号:文字そのものは変えず、並べ替える(順番を入れ替える)方式。
ストリーム暗号:データを通信単位(ビットやバイト)ごとに逐次暗号化する方式。
公開鍵暗号:暗号化と復号に異なる鍵を用いる、現代の主要な暗号方式。

1. 理解のコツ: 換字式暗号は、1対1で文字を置き換える「単一換字」の場合、言語ごとの文字の出現確率を調べる「頻度分析」によって、比較的容易に解読されてしまうという弱点があります。
2. 最新トレンドの視点: 現代のブロック暗号(AESなど)の内部処理でも、Sボックスと呼ばれる「換字」の工程が含まれています。古典的な技術ですが、現代暗号においても「攪拌(かくはん)」を実現するための重要なパーツとして生き続けています。


4. まとめ

「対応表を使って文字を別の文字へ置き換える」。これが換字式暗号の核となる定義です。文字の順序を変える「転置」との違いを明確に区別できるようにしておきましょう!


【データベース】構造に縛られない柔軟性!ドキュメント型DBの定義|情報処理問題1000本ノック

あらかじめ厳密な表形式を決めなくていい。データの追加や変更が激しい現代のアプリケーション開発で、圧倒的な支持を得ているのが「ドキュメント型データベース」です。

1. 問題:構造を定義せずにデータを管理する形式

【 問題 】 NoSQLデータベースの分類のうち、XMLやJSON形式といった「ドキュメント」と呼ばれる単位でデータを管理するものはどれでしょうか?この形式では、RDBのレコードに相当するデータごとに異なる構造を持たせることが可能です。

① キーバリューストア型   ② ドキュメント型   ③ グラフ型   ④ カラム指向型

2. 正解:NoSQLの分類に関する正解

正解: ② ドキュメント型

3. 解説:スキーマレスによる開発スピード

ドキュメント型は、RDB(関係データベース)のように「CREATE TABLE」で列をガチガチに定義する必要がありません(スキーマレス)。あるデータには「住所」があるけれど、別のデータにはない、といった不揃いな状態でもそのまま保存できるのが最大の特徴です。

[ ドキュメント型のポイント ]
管理単位:JSONやBSONなどの形式で記述された「ドキュメント」。
柔軟性:構造をあらかじめ決めておく必要がないため、仕様変更に強い。
代表的な製品:MongoDB、CouchDB、Amazon DocumentDBなど。

[ 他の選択肢との違い ]
キーバリューストア型:単純な「鍵」と「値」のセットのみを扱う(中身の検索は苦手)。
グラフ型:ノードとエッジで「つながり」を管理する(SNSなどの関係性重視)。
カラム指向型:列単位でデータを保持し、大量データの集計を高速化する。

1. 理解のコツ: 「リレーショナルDBのレコードに対応するが、構造を決めておく必要はない」という点が、試験で最も狙われる定義です。ドキュメントの中にさらにドキュメントを入れ子にする(ネスト)構造も得意としています。
2. 最新トレンドの視点: Webアプリやモバイルアプリではデータ構造が頻繁に変わるため、開発初期からドキュメント型が選ばれるケースが増えています。高度試験では、RDBとの使い分けや、ACID特性の妥協(結果一貫性)といったトレードオフに関する知識も求められます。


4. まとめ

「ドキュメント単位で、自由な構造で保存する」。これがドキュメント型データベースの核となる定義です。RDBのような厳格さがない分、スピード感のある開発に適したアーキテクチャであることを押さえておきましょう!


【データベース】変更に強い設計の極意!3層スキーマ構造の正体|情報処理問題1000本ノック

データベース設計の基本でありながら、最高の知恵が詰まった「3層スキーマ構造」。なぜわざわざ3つに分けるのか。それは、一部を変更しても他に影響を与えない「データ独立性」を確保するためです。

1. 問題:管理対象を定義するスキーマ

【 問題 】 データベースの3層スキーマ構造において、データの論理的な構造(管理対象の全体像)を定義し、開発者や管理者の視点からデータの本質を表現するスキーマはどれでしょうか?

① 外部スキーマ   ② 概念スキーマ   ③ 内部スキーマ   ④ 物理スキーマ

2. 正解:スキーマの役割に関する正解

正解: ② 概念スキーマ

3. 解説:保守性を高める「3つの境界線」

役割ごとに境界線を引くことで、ある層の変更が他の層へ波及するのを防ぎます。これを「データ独立性」と呼び、システムの保守性を劇的に高めます。

[ 3層スキーマの役割 ]
外部スキーマ(見せ方):ユーザーやアプリが見る窓口。実務では「ビュー(VIEW)」に相当。
概念スキーマ(論理):データの全体像。実務では「テーブル定義(CREATE TABLE)」やER図に相当。
内部スキーマ(持ち方):物理的な保存方法。実務ではインデックスやファイル配置に相当。

[ データ独立性のメリット ]
物理的データ独立性:ストレージの変更やインデックスの追加(内部)を行っても、テーブル定義(概念)やプログラムを直す必要がない。
論理的データ独立性:テーブルを分割(概念)しても、ビュー(外部)を調整すれば、アプリ側のプログラムを一切修正せずに済む。

1. 理解のコツ: 概念スキーマが「本質」であり、それをどう見せるかが「外部」、どう保存するかが「内部」です。真ん中の概念スキーマがしっかりしているからこそ、両サイドの変化を吸収できるのです。
2. 試験対策の視点: 試験では「ビュー=外部スキーマ」「テーブル=概念スキーマ」という対応関係がよく問われます。また、ANSI/X3/SPARC(アンシ・スパーク)という用語と一緒に登場することもあるので、セットで覚えておきましょう。


4. まとめ

「ある層の変更を、その層だけで完結させる」。これが3層スキーマ構造の最大の価値です。この構造を理解しておくことで、保守性が高く、変化に強いデータベース設計の基礎をマスターできます!


【システム構成要素】すべてを共有して処理する!シェアードエブリシングの定義|情報処理問題1000本ノック

複数の処理装置が一つの大きなリソースを分かち合う。並列システムにおける基本的な設計思想の一つである「シェアードエブリシング」の概念を整理しましょう。

1. 問題:同一のリソースを共有するアーキテクチャ

【 問題 】 システム構成において、複数のプロセッサが同一のメインメモリやディスク装置(データベース)を共有し、各プロセッサがすべてのデータに直接アクセスして処理を行うアーキテクチャを何と呼ぶでしょうか?

① シェアードナッシング   ② シェアードエブリシング   ③ マイクロサービス   ④ マルチテナント

2. 正解:システム構成の分類に関する正解

正解: ② シェアードエブリシング

3. 解説:リソースの共有による密な連携

名前の通り、メモリやディスクといったすべてのリソースを「エブリシング(すべて)」共有する仕組みです。どのプロセスからでも同じデータにアクセスできるため、プロセッサ間でのデータ転送が不要であり、複雑なデータ整合性の管理が比較的容易になるという特徴があります。

[ シェアードエブリシングのポイント ]
定義:複数のプロセッサが、単一のメモリや共有ディスクを介して同一のデータベースを操作する構造。
メリット:負荷分散(ロードバランシング)が行いやすく、小中規模の構成では高い効率を発揮します。
課題:プロセッサ数が増えると、共有メモリやディスクへのアクセス競合(渋滞)が発生し、拡張性に限界が生じやすくなります。

[ 他の選択肢との違い ]
シェアードナッシング:各ノードが独自のメモリとディスクを持ち、何も共有しない構成。大規模拡張に向きます。
マイクロサービス:システム全体をビジネス機能単位で小さな独立したサービスに分割する設計思想。
マルチテナント:一つのシステム環境を、論理的に複数の顧客(テナント)で共有して利用する形態。

1. 理解のコツ: 「みんなで一つの机(リソース)を囲んで作業する」のがシェアードエブリシング、「一人一台ずつ専用の机を持つ」のがシェアードナッシングだとイメージすると、違いが明確になります。
2. 試験対策の視点: システムアーキテクチャの設計において、高可用性を実現するクラスタ構成などの文脈で頻出します。特に「共有ディスク(同一のデータベース)を使っているかどうか」が、シェアードナッシングとの判別ポイントです。


4. まとめ

「複数のプロセスで、同一のデータベースを共有する」。これがシェアードエブリシングの核となる定義です。システムを拡張する際の「リソース競合」がボトルネックになりやすいという弱点とセットで覚えておきましょう!



【ネットワーク】ソフトウェアで網を操る!SDNの定義|情報処理問題1000本ノック

物理的な配線や機器の設定に縛られず、プログラムによってネットワークを柔軟に制御する。現代のデータセンターやクラウド基盤を支える「SDN」の概念を整理しましょう。

1. 問題:ソフトウェアによるネットワーク制御

【 問題 】 ネットワーク機器の物理的な構成に依存せず、ソフトウェアを用いてネットワークの構成や通信制御を動的に一括管理する技術の総称を何と呼ぶでしょうか?

① SDN (Software Defined Networking)   ② SD-WAN   ③ VLAN   ④ CDN

2. 正解:ネットワーク技術の総称に関する正解

正解: ① SDN (Software Defined Networking)

3. 解説:制御と転送の分離が鍵

SDNは特定の製品名ではなく、ソフトウェアでネットワークを定義・制御する「技術の総称」です。最大の特徴は、データを運ぶ役割(データプレーン)と、どこに運ぶかを判断する制御の役割(コントロールプレーン)を分離し、制御を中央のソフトウェア(コントローラ)で一括して行うことにあります。

[ SDNのポイント ]
定義:ソフトウェアを用いて、ネットワーク構成を動的に制御・設定する技術の総称。
メリット:物理的な作業なしでネットワーク構成を変更でき、運用の自動化や柔軟な拡張が可能。
代表的プロトコル:コントローラとスイッチ間で通信するための「OpenFlow」などが有名。

[ 他の選択肢との違い ]
SD-WAN:SDNの技術を広域ネットワーク(WAN)に応用し、拠点間通信を制御する技術。
VLAN:スイッチ内部で仮想的にネットワークを分割する技術。SDNはより広範で動的な制御を指します。
CDN:コンテンツ配信を高速化するために、世界各地に配置されたキャッシュサーバのネットワーク。

1. 理解のコツ: 「ソフトウェアによって定義される(Defined)」という言葉の通り、これまでハードウェアの中に密結合していた「インテリジェンス」を外に引っ張り出したものがSDNだとイメージしてください。
2. 最新トレンドの視点: 最近ではネットワークだけでなく、ストレージ(SDS)やデータセンター全体(SDDC)など、あらゆるインフラをソフトウェアで制御する流れが主流となっています。高度試験では「インフラストラクチャ・アズ・コード(IaC)」との関連性も問われます。


4. まとめ

「ネットワークをプログラムで制御可能にする」。これがSDNの核となる考え方です。特定のプロトコルを指すのではなく、ネットワークのあり方を変える「技術の総称」であることを押さえておきましょう!

【システム構成要素】ビジネス単位で小さく分ける!マイクロサービスの定義|情報処理問題1000本ノック

巨大な一つの塊(モノリス)としてシステムを作る時代から、小さな独立したサービスを組み合わせる時代へ。現代のシステム設計における基本思想となった「マイクロサービス」の定義を整理しましょう。

1. 問題:小さなアプリケーションを組み合わせる構造

【 問題 】 システム全体を一塊として構築するのではなく、ビジネス上の関心ごとに基づいて独立した「可能な限り小さなアプリケーション」に分割し、それらを連携させて一つの大きなシステムを構成する手法を何と呼ぶでしょうか?

① サービス指向アーキテクチャ (SOA)   ② マイクロサービス   ③ 3層アーキテクチャ   ④ サーバレスアーキテクチャ

2. 正解:アーキテクチャの分類に関する正解

正解: ② マイクロサービス

3. 解説:ビジネスの単位でシステムを切り分ける

「注文管理」「在庫管理」「配送管理」といったビジネス機能ごとに、独立したサービスとして作成します。一つの機能を修正しても他の機能に影響を与えにくいため、特定の機能だけを迅速にアップデートしたり、必要な部分だけを拡張したりすることが可能になります。



[ マイクロサービスのポイント ]
構成単位:ビジネス上の関心ごとに基づき、可能な限り小さく分割されたアプリケーション。
独立性:各サービスは独自のデータベースを持ち、個別にデプロイ(展開)が可能です。
連携:APIなどの軽量な通信手段を用いて、互いにサービスを呼び出し合います。

[ 他の選択肢との違い ]
SOA (Service Oriented Architecture):企業全体の業務プロセスを「サービス」として統合する、より大規模・重厚な連携の考え方。
3層アーキテクチャ:UI・ビジネスロジック・データの「階層」で分ける、垂直的な設計手法。
サーバレス:インフラの存在を意識せずにプログラムを実行する「プラットフォーム」の形態。

1. 理解のコツ: マイクロサービスは、単なる技術的な分割ではなく「ビジネスの柔軟性」を高めるための戦略です。試験では「ビジネス上の関心ごと」「独立性」「小さなアプリケーションの集合」といったキーワードが正解の決め手となります。
2. 最新トレンドの視点: マイクロサービス化を進めると、管理すべきサービス数が膨大になります。そのため、各サービスの健全性を監視する技術や、サービス同士の通信を制御する「サービスメッシュ」といった技術がセットで語られることが多くなっています。


4. まとめ

「ビジネスの関心ごとで、可能な限り小さく作る」。これがマイクロサービスの核となる考え方です。この定義をしっかり押さえておけば、モノリス(一塊)やSOAとの違いを問う問題にも迷わず解答できます!