システムアーキテクト 頻出重要用語集
全 60 語 収録習得済: 0 / 60★ 保存: 0
システムアーキテクト 頻出重要用語解説
要件定義・ドメイン駆動設計(DDD)・マイクロサービス・イベント駆動アーキテクチャ・非機能要件(可用性/性能/移行)等のシステムアーキテクト重要用語を完全網羅。「1行要約」「3行解説」「午後I記述・午後II小論文キーワード」で合格力を高めます。
【索引】50音・英数インデックス:
【カテゴリ】専門分野:
出題フェーズ:
ステータス:
表示:
該当件数: 60 件 / 全 60 語
でーたふろーだいあぐらむ要件定義・分析午前II午後I記述★★★
DFD（データフローダイアグラム）
Data Flow Diagram (DFD)1行解説（要点）
業務やシステム内のデータの流れを「プロセス」「データフロー」「データストア」「源泉と吸収」の4要素で視覚化する構造化分析手法。
3行解説（詳細ポイント）
1業務やシステム内のデータの流れを「プロセス」「データフロー」「データストア」「源泉と吸収」の4要素で視覚化する構造化分析手法。
2業務プロセス間のデータの受け渡しと蓄積箇所を直感的に整理し、現行業務（As-Is）と新業務（To-Be）の差分を明確化します。
3試験対策：午前II第1問クラスで頻出（源泉と吸収・データストアの記号判別）であり、午後Iでも業務フローとファイル設計の整合確認に直...
がいねんでーたもでる要件定義・分析午前II午後I記述午後II小論文★★★
概念データモデル（E-R図）
Entity-Relationship Diagram (ERD)1行解説（要点）
対象業務の実体（エンティティ）と実体間の関連（リレーションシップ）・多重度を定義し、業務ルールをデータ構造として表現するモデル。
3行解説（詳細ポイント）
1対象業務の実体（エンティティ）と実体間の関連（リレーションシップ）・多重度を定義し、業務ルールをデータ構造として表現するモデル。
2業務上の発生単位（1対多・多対多・スーパータイプ/サブタイプ）を正確に捉え、テーブル設計の骨格を固めます。
3試験対策：午後Iでは新機能追加に伴うエンティティ・属性の追加や履歴管理、午後IIでは複数システム統合時のデータモデル標準化の論述で...
ゆーえむえる要件定義・分析午前II午後I記述★★★
UML（統一モデリング言語）
Unified Modeling Language (UML)1行解説（要点）
オブジェクト指向設計において、システムの静的な構造図（クラス図等）と動的な振る舞い図（シーケンス図・状態マシン図等）を標準記法で記述する言語。
3行解説（詳細ポイント）
1オブジェクト指向設計において、システムの静的な構造図（クラス図等）と動的な振る舞い図（シーケンス図・状態マシン図等）を標準記法で記述する言語。
2クラス図（汎化・集約・コンポジション）、シーケンス図（時系列メッセージ順序）、コミュニケーション図、状態マシン図を用途に応じて使い分けます。
3試験対策：午前IIでは毎年2〜3問出題される最頻出分野であり、特にクラス図の多重度・集約とシーケンス図の活性区間・非同期メッセージ...
ゆーすけーすきじゅつ要件定義・分析午前II午後I記述午後II小論文★★★
ユースケース記述・アクタ分析
Use Case Modeling1行解説（要点）
システム外部の利用者や外部システム（アクタ）視点から、システムが提供すべき機能と基本フロー・代替フロー・例外フローを定義する手法。
3行解説（詳細ポイント）
1システム外部の利用者や外部システム（アクタ）視点から、システムが提供すべき機能と基本フロー・代替フロー・例外フローを定義する手法。
2事前条件・事後条件・基本系列・代替系列（例外処理）を漏れなく記述することで、利用部門との認識齟齬を防止します。
3試験対策：午後II小論文では「基本フローだけでなく業務上の例外ケース（返品、取消、通信断時）を代替フローとして網羅的に洗い出した工...
ぎょうむふろーぶんせき要件定義・分析午後I記述午後II小論文★★★
業務フロー分析（As-Is / To-Be）
As-Is / To-Be Business Process Analysis1行解説（要点）
現行業務（As-Is）のボトルネックや属人化課題を可視化し、法規や運用制約を踏まえた理想の新業務プロセス（To-Be）を設計する手法。
3行解説（詳細ポイント）
1現行業務（As-Is）のボトルネックや属人化課題を可視化し、法規や運用制約を踏まえた理想の新業務プロセス（To-Be）を設計する手法。
2単に現行手作業をそのままシステム化するのではなく、業務自体の廃止・統合・標準化（BPR）を伴うシステム化要件を導出します。
3試験対策：SA午後I・午後IIの最最重要概念。「業務改革とシステム導入を同時に進める際、どの業務ルールを見直し、どのシステム機能で...
がいねんじっしょうとぷろとたいぴんぐ要件定義・分析午前II午後I記述午後II小論文★★
PoC（概念実証）とプロトタイピング
Proof of Concept (PoC) & Prototyping1行解説（要点）
新技術導入やUI/UX設計の初期段階で、実現可能性・性能・操作性を実機試作品で早期検証し、手戻りリスクを最小化するアプローチ。
3行解説（詳細ポイント）
1新技術導入やUI/UX設計の初期段階で、実現可能性・性能・操作性を実機試作品で早期検証し、手戻りリスクを最小化するアプローチ。
2使い捨て型（ラピッド）プロトタイプと進化型プロトタイプを区別し、検証目的（アルゴリズム精度、画面遷移の直感性等）を明確に絞って実施します。
3試験対策：AI・IoT活用（令和4年午後I問4等）や新UI構築（午後II）において、本番開発前に予測モデルの精度や現場操作性を検証...
こうぞうかいんたびゅーとようきゅうしゅつ要件定義・分析午前II午後I記述午後II小論文★★
構造化インタビューと要求抽出
Structured Interview & Requirements Elicitation1行解説（要点）
あらかじめ設計した質問項目と評価観点に基づき、多様なステークホルダから潜在的な業務課題や暗黙知の要件を体系的に引き出す手法。
3行解説（詳細ポイント）
1あらかじめ設計した質問項目と評価観点に基づき、多様なステークホルダから潜在的な業務課題や暗黙知の要件を体系的に引き出す手法。
2オープン質問とクローズド質問を組み合わせ、声の大きい一部の利用者の要望だけでなく、例外処理やピーク時の運用実態を掘り下げます。
3試験対策：午後II小論文の設問ア・イで「利用部門へのヒアリングで現場固有の例外運用をどのように抽出し、要件定義へ反映したか」を具体...
ばぼっく要件定義・分析午前II午後II小論文★★
BABOK（ビジネスアナリシス知識体系）
Business Analysis Body of Knowledge (BABOK)1行解説（要点）
業務分析（ビジネスアナリシス）のグローバル標準知識体系であり、要求を「ビジネス要求」「ステークホルダ要求」「ソリューション要求」「移行要求」に分類する枠組み。
3行解説（詳細ポイント）
1業務分析（ビジネスアナリシス）のグローバル標準知識体系であり、要求を「ビジネス要求」「ステークホルダ要求」「ソリューション要求」「移行要求」に分類する枠組み。
2機能要求・非機能要求（ソリューション要求）だけでなく、旧環境から新環境へ移るための一時的な「移行要求」を明確に定義する点が特徴です。
3試験対策：午前IIの知識問題で要求分類が問われるほか、午後II論文で要求のトレーサビリティ（追跡可能性）を論述する際の理論的支柱に...
くらっどまとりくす要件定義・分析午前II午後I記述午後II小論文★★★
CRUDマトリクス（機能・データ相関分析）
CRUD Matrix1行解説（要点）
縦軸に業務機能（プロセス）、横軸にエンティティ（テーブル）を配置し、生成（Create）・参照（Read）・更新（Update）・削除（Delete）の関係を一覧化した検証表。
3行解説（詳細ポイント）
1縦軸に業務機能（プロセス）、横軸にエンティティ（テーブル）を配置し、生成（Create）・参照（Read）・更新（Update）・削除（Delete）の関係を一覧化した検証表。
2「誰もCreateしないのにReadされるテーブル」や「複数システムから無秩序にUpdateされるマスタ」を視覚的に炙り出します。
3試験対策：午後Iのデータ連携・システム刷新問題および午後IIのデータ統合論文で、オーナーシステム（真のデータ源泉）を特定する最強の...
ゆーざーすとーりーまっぴんぐ要件定義・分析午前II午後I記述午後II小論文★★
ユーザーストーリーマッピングと受入基準
User Story Mapping & Acceptance Criteria1行解説（要点）
利用者の業務の時系列に沿ってエピック・ユーザーストーリーを2次元配置し、MVP（実用最小限の製品）とリリース優先順位および受入基準（Given-When-Then）を定義する手法。
3行解説（詳細ポイント）
1利用者の業務の時系列に沿ってエピック・ユーザーストーリーを2次元配置し、MVP（実用最小限の製品）とリリース優先順位および受入基準（Given-When-Then）を定義する手法。
2機能単位の縦割りではなく「利用者が業務目的を達成する一気通貫の体験」としてスコープを切り出すことで、段階的リリースを成功に導きます。
3試験対策：アジャイル開発やDX推進をテーマとする午後II小論文において、機能優先順位付けと受入条件の明確化手法としてそのまま活用で...
まいくろさーびすあーきてくちゃアーキテクチャ設計午前II午後I記述午後II小論文★★★
マイクロサービスアーキテクチャ
Microservices Architecture1行解説（要点）
ビジネスドメイン（業務境界）ごとに独立して開発・デプロイ・スケール可能な小さなサービスの集合体としてシステムを構築するアーキテクチャスタイル。
3行解説（詳細ポイント）
1ビジネスドメイン（業務境界）ごとに独立して開発・デプロイ・スケール可能な小さなサービスの集合体としてシステムを構築するアーキテクチャスタイル。
2各サービスが固有のデータベース（Database per Service）を持ち、REST APIやgRPC、非同期メッセージングで疎結合に連携します。
3試験対策：モノリスとのトレードオフ（分散トランザクションの複雑化、結果整合性、運用監視負荷）と、それを補うSagaやAPIゲートウ...
どめいんくどうせっけいアーキテクチャ設計午前II午後II小論文★★★
ドメイン駆動設計（DDD：Domain-Driven Design）
Domain-Driven Design (DDD)1行解説（要点）
業務領域（ドメイン）の知識に焦点を当て、開発者と業務エキスパートが共通の「ユビキタス言語」を用い、「境界づけられたコンテキスト」ごとにモデルを分離する設計手法。
3行解説（詳細ポイント）
1業務領域（ドメイン）の知識に焦点を当て、開発者と業務エキスパートが共通の「ユビキタス言語」を用い、「境界づけられたコンテキスト」ごとにモデルを分離する設計手法。
2エンティティ、値オブジェクト、集約（Aggregate）、リポジトリを用いて、複雑な業務ルールをドメイン層に凝縮しインフラ層から独立させます。
3試験対策：複数部門・複数システムで同じ用語（例：「顧客」「商品」「契約」）の意味が異なる場合のシステム統合（午後II令和7年問1等...
くりーんあーきてくちゃアーキテクチャ設計午前II午後II小論文★★
クリーンアーキテクチャ・ヘキサゴナルアーキテクチャ
Clean Architecture / Hexagonal Architecture1行解説（要点）
ビジネスロジック（ドメイン層・ユースケース層）を中心に据え、依存関係の向きを常に外側から内側へ向けることで、UIやDB・外部フレームワークの変更から業務ロジックを保護する設計。
3行解説（詳細ポイント）
1ビジネスロジック（ドメイン層・ユースケース層）を中心に据え、依存関係の向きを常に外側から内側へ向けることで、UIやDB・外部フレームワークの変更から業務ロジックを保護する設計。
2依存性逆転の原則（DIP）を活用し、インターフェース（ポート）と実装（アダプタ）を分離することで、単体テスト容易性と保守性を飛躍的に高めます。
3試験対策：外部APIの仕様変更やパッケージ入替えが頻繁に発生するシステムにおいて、「変更に強いソフトウェア構造」を論述する際の核心...
びーえふえふアーキテクチャ設計午前II午後I記述午後II小論文★★★
BFF（Backends For Frontends）
Backends For Frontends (BFF)1行解説（要点）
Webブラウザ、スマートフォンアプリ、店舗端末などフロントエンドの種別ごとに専用のバックエンド層を配置し、画面表示に最適化されたデータ集約・整形を行うパターン。
3行解説（詳細ポイント）
1Webブラウザ、スマートフォンアプリ、店舗端末などフロントエンドの種別ごとに専用のバックエンド層を配置し、画面表示に最適化されたデータ集約・整形を行うパターン。
2複数のマイクロサービスへの細かなAPI呼び出しをBFF側で一括集約（アグリゲーション）することで、モバイル回線での通信往復回数（チャットネス）を削減します。
3試験対策：マルチデバイス対応やオムニチャネル構築（午後I・午後II）において、フロントエンドのUX向上とバックエンドサービスの汎用...
えーぴーあいげーとうぇいアーキテクチャ設計午前II午後I記述午後II小論文★★★
APIゲートウェイ（API Gateway）
API Gateway1行解説（要点）
外部クライアントや他社システムからのAPIリクエストを単一窓口で受け付け、認証・認可、レート制限（スロットリング）、ルーティング、ロギングを一元処理する基盤コンポーネント。
3行解説（詳細ポイント）
1外部クライアントや他社システムからのAPIリクエストを単一窓口で受け付け、認証・認可、レート制限（スロットリング）、ルーティング、ロギングを一元処理する基盤コンポーネント。
2個々のバックエンドサービスに横断的関心事（セキュリティ検証、流量制御、プロトコル変換）を重複実装する無駄と脆弱性を排除します。
3試験対策：FinTechやオープンAPI連携、企業間データ連携基盤の設計において、セキュリティと可用性を担保する必須コンポーネント...
しーきゅーあーるえすアーキテクチャ設計午前II午後II小論文★★
CQRS（コマンドクエリ責務分離）
Command Query Responsibility Segregation (CQRS)1行解説（要点）
データの更新処理（Command：登録・変更・削除）と参照処理（Query：検索・集計・一覧表示）のデータモデルおよびデータストアを分離するアーキテクチャパターン。
3行解説（詳細ポイント）
1データの更新処理（Command：登録・変更・削除）と参照処理（Query：検索・集計・一覧表示）のデータモデルおよびデータストアを分離するアーキテクチャパターン。
2更新系は正規化されたRDBで厳密な整合性を保ち、参照系は画面表示や分析に最適化した非正規化ビューやインメモリDB・検索エンジンへ非同期反映します。
3試験対策：参照トラフィックが更新トラフィックの数十倍に達するECサイトや予約システムで、ロック競合を回避し高スループットを実現する...
いべんとくどうあーきてくちゃアーキテクチャ設計午前II午後I記述午後II小論文★★★
イベントソーシングとイベント駆動アーキテクチャ（EDA）
Event-Driven Architecture (EDA) & Event Sourcing1行解説（要点）
データの現在の状態だけでなく「発生した業務イベント（注文確定、出荷完了等）」を不変の履歴として記録・配信し、サービス間を非同期メッセージブローカで疎結合に連携する方式。
3行解説（詳細ポイント）
1データの現在の状態だけでなく「発生した業務イベント（注文確定、出荷完了等）」を不変の履歴として記録・配信し、サービス間を非同期メッセージブローカで疎結合に連携する方式。
2送信元サービスは受信側サービスの稼働状態や処理完了を待たずに次の処理へ進めるため、ピーク時の負荷平準化（ピークシェービング）と耐障害性が向上します。
3試験対策：午後IIのデータ連携問題で「リアルタイム同期連携」と「メッセージキューを介した非同期イベント連携」の使い分けを論述する際...
さーがぱたーんアーキテクチャ設計午前II午後II小論文★★
Sagaパターン（分散トランザクション補償）
Saga Pattern1行解説（要点）
複数のマイクロサービスや外部システムにまたがる業務処理において、2相コミット（2PC）による長時間ロックを使わず、ローカルトランザクションの連鎖と失敗時の「補償トランザクション」で整合性を保つ設計。
3行解説（詳細ポイント）
1複数のマイクロサービスや外部システムにまたがる業務処理において、2相コミット（2PC）による長時間ロックを使わず、ローカルトランザクションの連鎖と失敗時の「補償トランザクション」で整合性を保つ設計。
2イベント連鎖によるコレオグラフィ方式と、調整役（オーケストレータ）が進行管理するオーケストレーション方式の2種類があります。
3試験対策：複数システム間のデータ連携で「一部システムの更新失敗時にどうやって業務上の整合性を回復するか」という設問に対する模範的な...
さーびすしこうあーきてくちゃアーキテクチャ設計午前II午後I記述★★
SOA（サービス指向アーキテクチャ）とサービスバス
Service-Oriented Architecture (SOA)1行解説（要点）
業務機能単位で標準化されたインターフェースを持つ「サービス」としてソフトウェア部品を構築し、それらを組み合わせて業務プロセス全体のシステムを実現する設計思想。
3行解説（詳細ポイント）
1業務機能単位で標準化されたインターフェースを持つ「サービス」としてソフトウェア部品を構築し、それらを組み合わせて業務プロセス全体のシステムを実現する設計思想。
2レガシーシステムをラッパ（Wrapper）で包んでサービス化することで、既存資産を活かしつつ新業務フローへの迅速な組み替えを可能にします。
3試験対策：午前IIの頻出基礎概念であり、午後I・午後IIでも既存基幹システムの段階的モダナイゼーション（ラッピングによるAPI公開...
べきとうせいせっけいアーキテクチャ設計午前II午後I記述午後II小論文★★★
冪等性（べきとうせい：Idempotency）設計
Idempotency in Distributed Systems1行解説（要点）
通信タイムアウト等によるリトライで同じリクエストやバッチ処理が複数回実行されても、1回実行したときと同じ結果になり二重計上・二重決済を起こさない性質。
3行解説（詳細ポイント）
1通信タイムアウト等によるリトライで同じリクエストやバッチ処理が複数回実行されても、1回実行したときと同じ結果になり二重計上・二重決済を起こさない性質。
2一意なリクエストID（冪等キー / トランザクションID）を採番して処理済みテーブルで重複排除するか、状態遷移チェック付きのUPDATE文で実装します。
3試験対策：午後I・午後IIのオンラインAPI連携・夜間バッチ再実行設計において、「障害復旧・リトライ時のデータ二重登録防止策」とし...
ひきのうようきゅうぐれーど非機能要件・信頼性午前II午後I記述午後II小論文★★★
IPA「非機能要求グレード」と6大カテゴリ
IPA Non-Functional Requirements Grade1行解説（要点）
IPAが策定した、可用性・性能/拡張性・運用/保守性・移行性・セキュリティ・システム環境/エコロジーの6大項目から非機能要件を定量的に合意形成するための体系。
3行解説（詳細ポイント）
1IPAが策定した、可用性・性能/拡張性・運用/保守性・移行性・セキュリティ・システム環境/エコロジーの6大項目から非機能要件を定量的に合意形成するための体系。
2システムを社会的影響度等に応じて3つのモデルシステムに分類し、各メトリクスの目標レベル（レベル0〜5）を段階的に選定します。
3試験対策：午後II小論文で非機能要件を論述する際、「IPA非機能要求グレードの6大観点に基づき、利用部門と目標値とコストのトレード...
ふぉーるととれらんととふぇーるせーふ非機能要件・信頼性午前II午後I記述午後II小論文★★★
フォールトトレラント・フェールセーフ・フェールソフト
Fault Tolerance, Fail-Safe & Fail-Soft1行解説（要点）
障害発生時にもシステムを停止させない耐障害設計（フォールトトレラント）、安全側に制御する設計（フェールセーフ）、機能を縮退して継続する設計（フェールソフト）。
3行解説（詳細ポイント）
1障害発生時にもシステムを停止させない耐障害設計（フォールトトレラント）、安全側に制御する設計（フェールセーフ）、機能を縮退して継続する設計（フェールソフト）。
2人命や金銭被害を防ぐ安全停止（フェールセーフ：遮断機を降ろす、ドローンを着陸させる）と、一部機能を落としてでも業務を継続する縮退運転（フェールソフト）を明確に使い分けます。
3試験対策：午前IIの信頼性設計問題で毎年出題されるほか、午後Iの組込み・IoT問題（令和4年問4のドローン着陸制御等）や業務継続設...
さーきっとぶれーかぱたーん非機能要件・信頼性午前II午後I記述午後II小論文★★★
サーキットブレーカパターン（Circuit Breaker）
Circuit Breaker Pattern1行解説（要点）
外部APIや下流サービスの応答遅延・異常が多発した際、呼び出しを即座に遮断（Open）してフォールバック処理へ切り替え、障害の連鎖（カスケード障害）を防ぐ設計パターン。
3行解説（詳細ポイント）
1外部APIや下流サービスの応答遅延・異常が多発した際、呼び出しを即座に遮断（Open）してフォールバック処理へ切り替え、障害の連鎖（カスケード障害）を防ぐ設計パターン。
2Closed（正常通電）→ Open（遮断・即時エラー/代替応答）→ Half-Open（一部リクエストを通し復旧確認）の3状態遷移で自律制御します。
3試験対策：外部システム連携（決済、信用照会、他社API）を扱う午後I・午後IIにおいて、相手先システム障害に自システムが巻き込まれ...
すろっとりんとれーとせいげん非機能要件・信頼性午前II午後I記述午後II小論文★★
スロットリング・レート制限・バックプレッシャ
Throttling, Rate Limiting & Backpressure1行解説（要点）
過剰なリクエスト流入に対して単位時間あたりの処理量を制限（スロットリング）したり、下流の処理能力に応じて上流の送信速度を抑制（バックプレッシャ）する流量制御技術。
3行解説（詳細ポイント）
1過剰なリクエスト流入に対して単位時間あたりの処理量を制限（スロットリング）したり、下流の処理能力に応じて上流の送信速度を抑制（バックプレッシャ）する流量制御技術。
2トークンバケットやリーキーバケットアルゴリズム、または非同期キューによるバッファリングを用いてデータベースや基幹系の過負荷崩壊を防ぎます。
3試験対策：アクセス集中が見込まれるキャンペーンサイトやIoT大量センサデータ収集基盤の性能・可用性設計で高い評価を得るキーワードで...
すけーるあうととすてーとれすせっけい非機能要件・信頼性午前II午後I記述午後II小論文★★★
スケールアウト（水平拡張）とステートレス設計
Scale-Out & Stateless Architecture1行解説（要点）
サーバ台数を動的に増減させて処理能力を伸縮させる水平拡張（スケールアウト）と、それを可能にするためAPサーバ内にセッション状態を持たせないステートレス設計。
3行解説（詳細ポイント）
1サーバ台数を動的に増減させて処理能力を伸縮させる水平拡張（スケールアウト）と、それを可能にするためAPサーバ内にセッション状態を持たせないステートレス設計。
2セッション情報はインメモリデータグリッド（Redis等）へ外部化するかJWTトークンに保持させ、どのAPサーバに振り分けられても処理継続できるようにします。
3試験対策：クラウド移行やWebサービスの性能改善（午後I・午後II）において、オートスケーリングを成立させるためのアーキテクチャ前...
きゃっしゅせんりゃく非機能要件・信頼性午前II午後I記述午後II小論文★★★
キャッシュ戦略（Cache-Aside / Write-Through / CDN）
Caching Strategies1行解説（要点）
頻繁に参照されるマスタやコンテンツを高速なメモリ層やエッジ（CDN）に保持し、データベース負荷低減とレスポンス高速化を実現する方式設計。
3行解説（詳細ポイント）
1頻繁に参照されるマスタやコンテンツを高速なメモリ層やエッジ（CDN）に保持し、データベース負荷低減とレスポンス高速化を実現する方式設計。
2参照時にキャッシュミスしたらDBから取得して格納するCache-Aside、更新時に同時書込みするWrite-Through、TTL（有効期限）と明示的パージによる鮮度管理を設計します。
3試験対策：「キャッシュの鮮度（整合性）と応答性能のトレードオフ」をどう解決したか（マスタ更新イベント連動でのキャッシュ無効化等）は...
あーるぴーおーとあーるてぃーおー非機能要件・信頼性午前II午後I記述午後II小論文★★★
RPO（目標復旧時点）とRTO（目標復旧時間）
Recovery Point Objective (RPO) & Recovery Time Objective (RTO)1行解説（要点）
災害や重大障害発生時に「過去どの時点のデータまで遡って復元できればよいか（RPO：データ損失許容幅）」と「何時間以内に業務を再開すべきか（RTO：停止許容時間）」の2大指標。
3行解説（詳細ポイント）
1災害や重大障害発生時に「過去どの時点のデータまで遡って復元できればよいか（RPO：データ損失許容幅）」と「何時間以内に業務を再開すべきか（RTO：停止許容時間）」の2大指標。
2RPOはバックアップ頻度や同期/非同期レプリケーション方式を決定し、RTOはホットスタンバイ/コールドスタンバイやマルチリージョン構成を決定します。
3試験対策：午前IIのBCP・DR問題で頻出であるとともに、午後IIでバックアップ・冗長化構成を選定した定量的根拠としてそのまま使え...
えむてぃーびーえふとえむてぃーてぃーあーる非機能要件・信頼性午前II午後I記述★★★
MTBF・MTTRとシステム稼働率（直列・並列冗長計算）
MTBF, MTTR & System Availability1行解説（要点）
平均故障間隔（MTBF）と平均修理時間（MTTR）から単体稼働率 A = MTBF / (MTBF + MTTR) を求め、直列系 A1×A2・並列系 1 - (1-A1)(1-A2) で全体稼働率を算出する信頼性理論。
3行解説（詳細ポイント）
1平均故障間隔（MTBF）と平均修理時間（MTTR）から単体稼働率 A = MTBF / (MTBF + MTTR) を求め、直列系 A1×A2・並列系 1 - (1-A1)(1-A2) で全体稼働率を算出する信頼性理論。
2予防保守や冗長化でMTBFを伸ばし、監視自動化・遠隔切り分け・ホットスワップでMTTRを短縮することで稼働率を高めます。
3試験対策：午前IIの計算問題で毎回のように出題されるため、直列・並列複合システムの稼働率計算式は100%確実に得点できるようにして...
ぶるーぐりーんでぷろいめんととかなりありりーす非機能要件・信頼性午前II午後I記述午後II小論文★★
ブルーグリーンデプロイメントとカナリアリリース
Blue-Green Deployment & Canary Release1行解説（要点）
本番環境と同一構成の新環境（Green）を用意してロードバランサで瞬時に切り替える方式と、一部ユーザー（数%）にのみ新バージョンを公開して安全性を確認後に全面展開する方式。
3行解説（詳細ポイント）
1本番環境と同一構成の新環境（Green）を用意してロードバランサで瞬時に切り替える方式と、一部ユーザー（数%）にのみ新バージョンを公開して安全性を確認後に全面展開する方式。
2万が一新バージョンに重大な不具合や性能劣化が発覚した場合でも、ルーティングを旧環境（Blue）へ戻すだけで数秒で切り戻し（ロールバック）が完了します。
3試験対策：24時間365日無停止が求められるシステムの移行・リリース設計（午後II）において、切り戻しリスクを極小化する方式として...
おぶざーばびりてぃ非機能要件・信頼性午前II午後II小論文★★
オブザーバビリティ（可観測性：Metrics / Logs / Traces）
Observability (Metrics, Logs, Distributed Tracing)1行解説（要点）
分散システム内部の健全性を「メトリクス（数値指標）」「構造化ログ」「分散トレーシング（リクエスト追跡）」の3つの柱（Three Pillars）で可視化し、未知の障害原因を即座に特定する能力。
3行解説（詳細ポイント）
1分散システム内部の健全性を「メトリクス（数値指標）」「構造化ログ」「分散トレーシング（リクエスト追跡）」の3つの柱（Three Pillars）で可視化し、未知の障害原因を即座に特定する能力。
2単一のリクエストに共通のトレースID（Correlation ID）を付与して全サービス間で伝播させることで、ボトルネック箇所をミリ秒単位で特定します。
3試験対策：マイクロサービスや複数システム連携の運用保守性要件（MTTR短縮）を論述する際、分散トレーシングの導入は非常に高い評価を...
おんらいんしょりとばっちしょりのほうしきせっけい方式・バッチ・UI・IoT午前II午後I記述午後II小論文★★★
オンライン処理とバッチ処理の方式設計・時間窓制御
Online & Batch Processing Design1行解説（要点）
即時応答が求められるオンライン処理と、大量データを一括効率処理する夜間/定時バッチ処理の役割分担、およびバッチ突き抜け（オンライン開始時刻超過）を防ぐ設計。
3行解説（詳細ポイント）
1即時応答が求められるオンライン処理と、大量データを一括効率処理する夜間/定時バッチ処理の役割分担、およびバッチ突き抜け（オンライン開始時刻超過）を防ぐ設計。
2マルチスレッド並列分割処理、コミット件数単位のチェックポイント・リスタート設計、オンライン稼働中の追い越し更新とのロック競合回避を組み込みます。
3試験対策：SA午後I・午後IIで最も出題頻度が高い王道テーマ。「締め時刻・バッチ実行順序・抽出条件（ステータス管理）の整合性」は毎...
じょぶねっとせっけいとでーたつきあわせ方式・バッチ・UI・IoT午後I記述午後II小論文★★★
ジョブネット設計とデータ突き合わせ（リコンシリエーション）
Job Network & Data Reconciliation1行解説（要点）
先行ジョブと後続ジョブの依存関係・異常終了時の制御を定義するジョブネットと、システム間の送受信件数・合計金額の一致を検証する突き合わせ（照合）処理。
3行解説（詳細ポイント）
1先行ジョブと後続ジョブの依存関係・異常終了時の制御を定義するジョブネットと、システム間の送受信件数・合計金額の一致を検証する突き合わせ（照合）処理。
2ファイル転送後に「コントロールレコード（件数・ハッシュ合計・金額合計）」を照合し、不一致時は後続の更新ジョブを自動停止して誤反映を防ぎます。
3試験対策：令和7年午後I問1（請求金額と検収済商品合計金額の照合）など、午後Iの記述問題で「何をどの条件で集計・照合するか」として...
しめしょりとすてーたすせんいせっけい方式・バッチ・UI・IoT午後I記述午後II小論文★★★
締め処理（カットオフ）とステータス遷移設計
Cut-off Processing & Status Transition Design1行解説（要点）
日次・月次の締め時刻前後に発生するトランザクションを正確に区分するため、業務日時・計上日・処理ステータス（未処理・処理中・検収済・請求済等）を厳密に制御する設計。
3行解説（詳細ポイント）
1日次・月次の締め時刻前後に発生するトランザクションを正確に区分するため、業務日時・計上日・処理ステータス（未処理・処理中・検収済・請求済等）を厳密に制御する設計。
2単に登録日時だけで抽出すると遅延到着データの漏れや二重計上が生じるため、状態遷移フラグと抽出対象期間を組み合わせて設計します。
3試験対策：午後I（平成29年問1の申告書ステータス、令和7年問1の検収済集計など）で「なぜそのステータス値・日付項目を条件にするの...
ゆーあいゆーえっくすせっけいとゆーざびりてぃ方式・バッチ・UI・IoT午前II午後I記述午後II小論文★★★
UI/UX設計とISO 9241-11（ユーザビリティ3要素）
UI/UX Design & Usability (ISO 9241-11)1行解説（要点）
特定の利用状況において、特定の利用者がシステムを使って目標を達成する際の「有効性（正確さ・完全さ）」「効率（資源・時間の少なさ）」「満足度（不快感のなさ）」を高める設計。
3行解説（詳細ポイント）
1特定の利用状況において、特定の利用者がシステムを使って目標を達成する際の「有効性（正確さ・完全さ）」「効率（資源・時間の少なさ）」「満足度（不快感のなさ）」を高める設計。
2入力補完（オートコンプリート）、エラー箇所のインライン即時検証、段階的開示（プログレッシブディスクロージャ）、レスポンシブデザインなどを適用します。
3試験対策：午前IIでISO 9241-11の定義（有効性・効率・満足度）が頻出であるほか、午後IIでも高齢者・現場作業員・多店舗ス...
えっじこんぴゅーてぃんぐとあいおーてぃー方式・バッチ・UI・IoT午前II午後I記述午後II小論文★★★
エッジコンピューティングとIoTリアルタイム制御
Edge Computing & IoT Real-time Architecture1行解説（要点）
全てのセンサデータをクラウドやセンタサーバへ送って処理するのではなく、現場近くのエッジデバイスや制御装置側で一次処理・リアルタイム制御を行い、クラウドと役割分担する方式。
3行解説（詳細ポイント）
1全てのセンサデータをクラウドやセンタサーバへ送って処理するのではなく、現場近くのエッジデバイスや制御装置側で一次処理・リアルタイム制御を行い、クラウドと役割分担する方式。
2通信遅延（レイテンシ）が許されない障害物回避や緊急停止はエッジ側で自律実行し、時系列傾向分析やAIモデル学習はクラウド側で行います。
3試験対策：令和4年午後I問4（橋梁点検カメラロボットと点検制御装置・診断サーバの役割分担）をはじめ、SAのIoT・組込み選択問題で...
りあるたいむおーえすとゆうせんどぎゃくてん方式・バッチ・UI・IoT午前II午後I記述★★
リアルタイムOS（RTOS）と優先度逆転（プライオリティインバージョン）
RTOS & Priority Inversion / Priority Inheritance1行解説（要点）
定められた制限時間（デッドライン）内に処理を完了させるRTOSにおいて、低優先度タスクが排他資源を保持している間に中優先度タスクにCPUを奪われ、高優先度タスクが待たされる現象とその対策。
3行解説（詳細ポイント）
1定められた制限時間（デッドライン）内に処理を完了させるRTOSにおいて、低優先度タスクが排他資源を保持している間に中優先度タスクにCPUを奪われ、高優先度タスクが待たされる現象とその対策。
2優先度継承（Priority Inheritance）または優先度上限（Priority Ceiling）プロトコルを用いて、資源保持中の低優先度タスクの優先度を一時的に引き上げて解決します。
3試験対策：午前IIの組込み・OS分野で繰り返し出題される定番問題であり、プリエンプティブスケジューリングやセマフォ制御とセットで押...
おーてぃーえーふぁーむうぇあこうしん方式・バッチ・UI・IoT午前II午後I記述午後II小論文★★
OTA（Over-The-Air）ファームウェア更新とA/Bパーティション
OTA (Over-The-Air) Update & Dual-Bank Memory1行解説（要点）
IoT機器や組込みエッジ端末のソフトウェアを無線通信経由で遠隔配信・更新する仕組みと、更新中の電源断でも文鎮化（起動不能）を防ぐデュアルバンク（A/B面）設計。
3行解説（詳細ポイント）
1IoT機器や組込みエッジ端末のソフトウェアを無線通信経由で遠隔配信・更新する仕組みと、更新中の電源断でも文鎮化（起動不能）を防ぐデュアルバンク（A/B面）設計。
2電子署名によるファームウェア改ざん検証、稼働中（A面）の裏でのB面への書き込み、および再起動失敗時のA面への自動ロールバックを組み合わせます。
3試験対策：組込み・IoTシステムの保守運用効率化やセキュリティ脆弱性対応を扱う午後I（令和3年問4等）でそのまま問われる重要設計で...
うぉっちどっぐたいま方式・バッチ・UI・IoT午前II午後I記述★★
ウォッチドッグタイマ（WDT）と異常検知リセット
Watchdog Timer (WDT)1行解説（要点）
組込み機器や制御システムにおいて、ソフトウェアの暴走や無限ループ（ハングアップ）を検知するため、一定周期でクリア（キック）されない場合にハードウェアリセットをかける機構。
3行解説（詳細ポイント）
1組込み機器や制御システムにおいて、ソフトウェアの暴走や無限ループ（ハングアップ）を検知するため、一定周期でクリア（キック）されない場合にハードウェアリセットをかける機構。
2正常稼働中のタスクが周期的にWDTカウンタをリセットし、デッドロックや暴走でクリアが途絶えるとタイムアウトしてシステムを安全状態へ再起動します。
3試験対策：午前IIのハードウェア・組込み制御問題で頻出であり、無人稼働するIoTゲートウェイや産業機器の自律復旧設計の基本要素です...
おふらいんたいおうせっけい方式・バッチ・UI・IoT午後I記述午後II小論文★★
オフライン対応設計（ローカルストレージ同期・競合解決）
Offline-First Architecture & Conflict Resolution1行解説（要点）
電波状況が不安定な点検現場や移動中のモバイル端末において、端末内DBにデータを一時保存して業務を継続させ、通信回復後にサーバと自動同期する方式。
3行解説（詳細ポイント）
1電波状況が不安定な点検現場や移動中のモバイル端末において、端末内DBにデータを一時保存して業務を継続させ、通信回復後にサーバと自動同期する方式。
2通信回復時のアップロード順序制御、差分同期、および複数端末で同一データを更新した場合の楽観的ロック・マージルールを設計します。
3試験対策：フィールドワーク支援、営業支援、物流配送、インフラ点検（令和4年午後I問4のSDカード/モバイル通信等）のモバイル設計で...
ちょうひょうせっけいとでんしちょうぼほぞんほう方式・バッチ・UI・IoT午後I記述午後II小論文★★
帳票設計・電子帳簿保存法・インボイス対応設計
Report Design & Statutory Compliance1行解説（要点）
請求書・支払調書・納品書などの法定帳票や業務帳票において、法制度要件（真実性・可視性の確保、タイムスタンプ、訂正削除履歴、検索要件）と出力制御を満たす設計。
3行解説（詳細ポイント）
1請求書・支払調書・納品書などの法定帳票や業務帳票において、法制度要件（真実性・可視性の確保、タイムスタンプ、訂正削除履歴、検索要件）と出力制御を満たす設計。
2出力条件の制御（マイナンバー記載有無や承認ステータスによる印刷制御）、PDF電子署名、および7年間等の長期法定保存期間に応じたアーカイブ設計を行います。
3試験対策：平成29年午後I問1（マイナンバー申告書と支払調書の7年保存）、令和7年午後I問1（自治体の検収・請求規定）など、制度・...
いーてぃーえるぱいぷらいんせっけいデータ連携・移行・ERP午前II午後I記述午後II小論文★★★
ETL / ELT パイプライン設計
ETL / ELT Data Pipeline1行解説（要点）
複数の業務システムからデータを抽出（Extract）し、コード変換・名寄せ・正規化などの加工（Transform）を行って、DWHや統合DBへ格納（Load）するデータ連携方式。
3行解説（詳細ポイント）
1複数の業務システムからデータを抽出（Extract）し、コード変換・名寄せ・正規化などの加工（Transform）を行って、DWHや統合DBへ格納（Load）するデータ連携方式。
2ステージング領域での変換エラー隔離、再実行時の洗い替え（Truncate & Insert）または差分更新（Upsert）、処理件数ログの記録を標準化します。
3試験対策：午後I・午後IIのデータ分析基盤構築や複数システム統合において、各システムの独自フォーマットを標準データモデルへ揃える中...
いーえーあいとでーたれんけいきばんデータ連携・移行・ERP午前II午後I記述午後II小論文★★★
EAI / ESB（Hub & Spoke型データ連携基盤）
Enterprise Application Integration (EAI) / Hub & Spoke1行解説（要点）
n個のシステム間を1対1（Point-to-Point）で網の目状に接続するスパゲッティ化を防ぐため、中央の連携ハブ（EAI/ESB/変換層）を介してフォーマット変換とルーティングを集約する構成。
3行解説（詳細ポイント）
1n個のシステム間を1対1（Point-to-Point）で網の目状に接続するスパゲッティ化を防ぐため、中央の連携ハブ（EAI/ESB/変換層）を介してフォーマット変換とルーティングを集約する構成。
2接続数を n(n-1)/2 から n へ削減でき、新規システム追加や既存システム改修時のインターフェース変更影響をハブ内の変換定義のみに局所化できます。
3試験対策：令和4年午後I問2（データ連携基盤の導入）や令和7年午後II問1（複数システムのデータ連携）など、SA試験で最も好まれる...
へんこうでーたきゃぷちゃデータ連携・移行・ERP午前II午後I記述午後II小論文★★★
CDC（Change Data Capture：変更データキャプチャ）
Change Data Capture (CDC)1行解説（要点）
データベースのトランザクションログ（WAL/REDOログ）を監視してINSERT・UPDATE・DELETEの変更差分のみをリアルタイムに検知し、他システムやDWH・キャッシュへ配信する技術。
3行解説（詳細ポイント）
1データベースのトランザクションログ（WAL/REDOログ）を監視してINSERT・UPDATE・DELETEの変更差分のみをリアルタイムに検知し、他システムやDWH・キャッシュへ配信する技術。
2業務テーブルへの重い全件SELECTクエリやアプリケーション改修を伴わずに、低負荷かつ準リアルタイムでデータ同期を実現できます。
3試験対策：レガシー基幹DBに手を入れずにクラウド側の新システムや検索基盤へデータをリアルタイム連携したい場合（段階的移行期など）の...
いっかついこうとだんかいてきいこうデータ連携・移行・ERP午前II午後I記述午後II小論文★★★
一括移行（ビッグバン移行）と段階的移行の比較設計
Big-Bang Migration vs. Phased Migration1行解説（要点）
全システム・全拠点を一度に切り替える一括移行と、業務単位や拠点単位で複数回に分けて切り替える段階的移行のトレードオフ分析と方式選定。
3行解説（詳細ポイント）
1全システム・全拠点を一度に切り替える一括移行と、業務単位や拠点単位で複数回に分けて切り替える段階的移行のトレードオフ分析と方式選定。
2一括移行は新旧システムの並行連携プログラムが不要な反面、切替失敗時の業務停止リスクが極大化します。段階的移行はリスクを分散できる反面、移行期間中の新旧データ同期ブリッジ開発が必要です。
3試験対策：午後II小論文で「移行方式の選定理由と、段階的移行に伴って発生する新旧システム間のデータ連携課題への対策」は頻出中の頻出...
へいこうかどうけんしょうとげんしんひかくデータ連携・移行・ERP午前II午後I記述午後II小論文★★★
並行稼働検証（パラレルラン）と現新比較照合
Parallel Run & Legacy-New Output Comparison1行解説（要点）
本番切替前の一定期間、現行システムと新システムの両方に同一の本番トランザクションデータを入力して稼働させ、出力結果（請求金額、在庫数、仕訳データ等）の完全一致を検証する手法。
3行解説（詳細ポイント）
1本番切替前の一定期間、現行システムと新システムの両方に同一の本番トランザクションデータを入力して稼働させ、出力結果（請求金額、在庫数、仕訳データ等）の完全一致を検証する手法。
2単体・結合テストでは見抜けない本番データのエッジケースや端数処理（丸め誤差）の差異を切替前に100%摘出できます。
3試験対策：基幹システム刷新や法制度対応改修において、移行品質と業務部門の安心感を保証する最終防衛ラインとして記述します。...
でーたくれんじんぐとなよせデータ連携・移行・ERP午前II午後I記述午後II小論文★★★
データクレンジングと名寄せ（MDM：マスターデータ管理）
Data Cleansing, Deduplication & Master Data Management (MDM)1行解説（要点）
複数システムに散在する顧客・商品・取引先マスタの表記揺れ（全角/半角、法人格略称、旧住所）、欠損値、重複レコードを正規化・統合して「唯一つの正しいマスタ（Single View）」を構築する工程。
3行解説（詳細ポイント）
1複数システムに散在する顧客・商品・取引先マスタの表記揺れ（全角/半角、法人格略称、旧住所）、欠損値、重複レコードを正規化・統合して「唯一つの正しいマスタ（Single View）」を構築する工程。
2法人番号や電話番号・正規化住所文字列のマッチングルールによる自動名寄せと、同姓同名等のグレーゾーンに対する目視確認ワークフローを組み合わせて設計します。
3試験対策：システム統合やCRM導入（午後I・午後II）において、「移行前にどうやって汚れた既存データを浄化・統合したか」を論述する...
ふぃっとあんどぎゃっぷぶんせきデータ連携・移行・ERP午前II午後I記述午後II小論文★★★
Fit&Gap分析とアドオン（カスタマイズ）抑制設計
Fit & Gap Analysis & Add-on Minimization1行解説（要点）
業務パッケージやSaaS導入時に、業務要件とパッケージ標準機能の適合（Fit）と乖離（Gap）を分析し、本体改造（アドオン）を避けて標準機能への業務合わせ（BPR）や外部連携・運用で解決する手法。
3行解説（詳細ポイント）
1業務パッケージやSaaS導入時に、業務要件とパッケージ標準機能の適合（Fit）と乖離（Gap）を分析し、本体改造（アドオン）を避けて標準機能への業務合わせ（BPR）や外部連携・運用で解決する手法。
2安易にパッケージ本体を改造すると将来のバージョンアップや法改正パッチが適用不能になるため、「標準採用」「パラメータ設定」「外付け開発（Side-by-Side）」「運用代替」の優先順でGapを解消します。
3試験対策：令和7年午後I問1（消耗品集中購買パッケージのFit&Gap）および午後IIのパッケージ導入問題で100%問われる最重要...
すとらんぐらーふぃぐぱたーんデータ連携・移行・ERP午前II午後II小論文★★
ストラングラーフィグパターン（段階的レガシー刷新）
Strangler Fig Pattern1行解説（要点）
巨大なレガシーシステムを一度に全面作り直しするのではなく、前段にルーティング層（ファサード）を置き、機能単位で新システムへ少しずつ置き換えて最終的に旧システムを退役させる移行パターン。
3行解説（詳細ポイント）
1巨大なレガシーシステムを一度に全面作り直しするのではなく、前段にルーティング層（ファサード）を置き、機能単位で新システムへ少しずつ置き換えて最終的に旧システムを退役させる移行パターン。
2利用者や外部連携先からは単一のシステムに見せかけたまま、裏側で高頻度・高価値な機能から順次モダナイズを進めることができます。
3試験対策：大規模基幹システムの再構築（午後II）において、開発期間の長期化リスクと一括切替リスクを同時に回避するモダンな移行設計と...
ふはいぼうしそうとへんかんあだぷたデータ連携・移行・ERP午後I記述午後II小論文★★★
腐敗防止層（ACL：Anti-Corruption Layer）と変換アダプタ
Anti-Corruption Layer (ACL)1行解説（要点）
新システムとレガシーシステム（または外部他社システム）を連携する際、旧側の独自データ構造や歪んだ業務ロジックが新システムのクリーンな設計モデルに浸食しないよう境界に設ける変換層。
3行解説（詳細ポイント）
1新システムとレガシーシステム（または外部他社システム）を連携する際、旧側の独自データ構造や歪んだ業務ロジックが新システムのクリーンな設計モデルに浸食しないよう境界に設ける変換層。
2令和4年午後I問4の設問3(2)「診断サーバ上に開発する変換層の役割（標準化されたデータモデルと現行システムの独自フォーマットデータの相互変換）」そのものの概念です。
3試験対策：午後I・午後IIともに「既存システムのデータ構造を残したまま新アーキテクチャや外部標準APIと連携する仕組み」としてその...
いーでぃーあいこうかいデータ連携・移行・ERP午前II午後I記述午後II小論文★★
EDI更改（流通BMS / Web-EDI / REST API移行）
EDI Modernization (Web-EDI & REST API)1行解説（要点）
従来の電話回線（ISDN）やレガシー手順（JCA手順、全銀ベーシック手順）による企業間電子商取引（EDI）を、インターネット経由の流通BMS、AS2、Web-EDI、REST/JSON APIへ刷新する設計。
3行解説（詳細ポイント）
1従来の電話回線（ISDN）やレガシー手順（JCA手順、全銀ベーシック手順）による企業間電子商取引（EDI）を、インターネット経由の流通BMS、AS2、Web-EDI、REST/JSON APIへ刷新する設計。
2中小取引先向けにはブラウザで受注確認・出荷入力ができるWeb-EDIを提供し、大口取引先向けには自動システム連携APIを提供するハイブリッド設計が定石です。
3試験対策：平成28年午後I問1や令和6年午後I問3（受発注業務の電子化）など、BtoB受発注・サプライチェーン連携の事例問題で頻出...
もじゅーるきょうどともじゅーるけつごうど品質・テスト・設計原則午前II午後I記述午後II小論文★★★
モジュール強度（凝集度）とモジュール結合度
Module Cohesion & Coupling1行解説（要点）
モジュール内部の要素の関連性の強さ（モジュール強度：高いほど良い）と、モジュール間の依存関係の度合い（モジュール結合度：低いほど良い）による構造化設計の評価基準。
3行解説（詳細ポイント）
1モジュール内部の要素の関連性の強さ（モジュール強度：高いほど良い）と、モジュール間の依存関係の度合い（モジュール結合度：低いほど良い）による構造化設計の評価基準。
2強度は「機能的＞情報的＞連絡的＞手順的＞時間的＞論理的＞偶発的」、結合度は「データ＜スタンプ＜制御＜外部＜共通＜内容」の順で評価します。
3試験対策：SA午前IIで最も出題回数が多い超頻出テーマ！7段階の強度と6段階の結合度の名称・定義・具体例は100%即答できるように...
でざいんぱたーん品質・テスト・設計原則午前II午後II小論文★★★
GoFデザインパターン（生成・構造・振る舞いの23パターン）
GoF Design Patterns1行解説（要点）
オブジェクト指向開発における典型的な設計上の課題と解決策をカタログ化した23のパターン（Singleton, Factory Method, Adapter, Composite, Facade, Observer, Strategy, State等）。
3行解説（詳細ポイント）
1オブジェクト指向開発における典型的な設計上の課題と解決策をカタログ化した23のパターン（Singleton, Factory Method, Adapter, Composite, Facade, Observer, Strategy, State等）。
2インターフェース変換にはAdapter、複雑なサブシステム窓口にはFacade、アルゴリズムの動的な切り替えにはStrategy、状態に応じた振る舞い変更にはStateを適用します。
3試験対策：SA午前IIで毎年必ず1〜2問出題される得点源です。特にAdapter・Bridge・Composite・Decorat...
しすてむてきかくせいかくにんてすと品質・テスト・設計原則午前II午後I記述午後II小論文★★★
システム適格性確認テスト・業務シナリオテスト
System Qualification Testing & End-to-End Scenario Test1行解説（要点）
ISO/IEC/IEEE 12207（共通フレーム）に基づき、結合されたシステム全体が機能要件および非機能要件（性能・負荷・障害復旧・セキュリティ）をすべて満たしているかを検証する総合テスト。
3行解説（詳細ポイント）
1ISO/IEC/IEEE 12207（共通フレーム）に基づき、結合されたシステム全体が機能要件および非機能要件（性能・負荷・障害復旧・セキュリティ）をすべて満たしているかを検証する総合テスト。
2単一機能の動作確認だけでなく、受注から出荷・検収・請求・月次締めまで実業務の1ヶ月分の時間経過を模した一気通貫の業務シナリオテストを実施します。
3試験対策：午前IIのプロセス問題および午後IIの品質検証論述において、本番稼働後のトラブルを防ぐ包括的検証アプローチとして重要です...
いこうりはーさるときりもどしけいかく品質・テスト・設計原則午後I記述午後II小論文★★★
移行リハーサルとコンティンジェンシー（切り戻し）計画
Migration Rehearsal & Fallback Plan1行解説（要点）
本番切替当日のタイムチャート（分単位の作業手順）通りに実データ規模でデータ抽出・変換・投入・検証を予行演習し、制限時間内に完遂できるかおよび切り戻し判断基準（Go/No-Go）を確認する工程。
3行解説（詳細ポイント）
1本番切替当日のタイムチャート（分単位の作業手順）通りに実データ規模でデータ抽出・変換・投入・検証を予行演習し、制限時間内に完遂できるかおよび切り戻し判断基準（Go/No-Go）を確認する工程。
2移行処理がタイムリミットを超過した場合や重大な不整合が発覚した場合に、営業開始時刻までに旧環境へ安全に戻す切り戻し手順と判定時刻（デッドライン）を定義します。
3試験対策：午後I・午後IIのシステム移行問題で「確実な本番移行のために何を計画・検証したか」を問われた際の満点解答キーワードです。...
みゅーてーしょんてすと品質・テスト・設計原則午前II★★
ミューテーションテストとテスト網羅性評価
Mutation Testing & Test Coverage1行解説（要点）
テスト対象のプログラムに意図的な小さな誤り（ミュータント：条件式の `>` を `>=` に変える等）を埋め込み、既存のテストケース群がその誤りを検出（Kill）できるかでテストケース自体の品質を測定する手法。
3行解説（詳細ポイント）
1テスト対象のプログラムに意図的な小さな誤り（ミュータント：条件式の `>` を `>=` に変える等）を埋め込み、既存のテストケース群がその誤りを検出（Kill）できるかでテストケース自体の品質を測定する手法。
2命令網羅（C0）・分岐網羅（C1）・条件網羅（C2）だけでは見抜けない「アサーション（検証条件）の甘さ」を定量的に評価できます。
3試験対策：SA午前IIのソフトウェアテスト分野で繰り返し出題される特徴的な用語であり、「プログラムのバグを探すのではなく、テストケ...
さいくろまてぃっくふくざつど品質・テスト・設計原則午前II午後II小論文★★
サイクロマティック複雑度（循環的複雑度）と保守性指標
Cyclomatic Complexity (McCabe)1行解説（要点）
プログラムの制御フローグラフにおける線形独立な経路の数を数値化（E - N + 2P または分岐判定数 + 1）し、構造の複雑さと必要な最小テストケース数を評価するメトリクス。
3行解説（詳細ポイント）
1プログラムの制御フローグラフにおける線形独立な経路の数を数値化（E - N + 2P または分岐判定数 + 1）し、構造の複雑さと必要な最小テストケース数を評価するメトリクス。
2複雑度が10を超えるモジュールはバグ混入率が急増するため、メソッド分割やポリモーフィズム（Strategy/Stateパターン）によるリファクタリング対象とします。
3試験対策：午前IIの計算問題（辺の数E - ノード数N + 2）で頻出であり、午後IIでもコード品質・保守性基準の定量指標として活...
おーおーすとーぷんあいでぃーこねくと品質・テスト・設計原則午前II午後I記述午後II小論文★★★
OAuth 2.0 と OpenID Connect（OIDC / SSO統合認証）
OAuth 2.0 & OpenID Connect (OIDC)1行解説（要点）
外部アプリケーションにパスワードを渡さずにAPIアクセス権限を委譲する認可フレームワーク（OAuth 2.0）と、その拡張としてJWT形式のIDトークンで本人認証・シングルサインオンを実現するプロトコル（OIDC）。
3行解説（詳細ポイント）
1外部アプリケーションにパスワードを渡さずにAPIアクセス権限を委譲する認可フレームワーク（OAuth 2.0）と、その拡張としてJWT形式のIDトークンで本人認証・シングルサインオンを実現するプロトコル（OIDC）。
2認可コードフロー（PKCE付き）を用いることで、フロントエンドやモバイルアプリでも安全にアクセストークンとIDトークンを取得できます。
3試験対策：令和3年午後I問3（会員管理システムとID連携基盤の統合）や平成31年午後I問2（統合認証基盤）など、SAのID統合・外...
ぜろとらすとせきゅりてぃ品質・テスト・設計原則午前II午後I記述午後II小論文★★
ゼロトラストセキュリティとセキュリティ・バイ・デザイン
Zero Trust Security & Security by Design1行解説（要点）
「社内ネットワークだから安全」という境界防御の前提を捨て、すべてのアクセスに対して本人認証・端末健全性・最小権限認可・通信暗号化を都度検証するセキュリティ設計原則。
3行解説（詳細ポイント）
1「社内ネットワークだから安全」という境界防御の前提を捨て、すべてのアクセスに対して本人認証・端末健全性・最小権限認可・通信暗号化を都度検証するセキュリティ設計原則。
2企画・要件定義・アーキテクチャ設計の初期段階からセキュリティ対策を組み込む「Security by Design」により、手戻りのない堅牢なシステムを構築します。
3試験対策：テレワーク対応（令和4年午後I問3）やクラウド移行・医療/金融データ連携において、認証・暗号化・監査ログ設計の根拠として...
あーきてくちゃれびゅー品質・テスト・設計原則午前II午後II小論文★★
アーキテクチャレビュー（ATAM / 設計トレードオフ評価）
Architecture Tradeoff Analysis Method (ATAM)1行解説（要点）
実装に入る前のアーキテクチャ設計段階で、品質特性（性能、可用性、セキュリティ、変更容易性）のシナリオを用いて設計上のリスクや感度点・トレードオフ点を体系的に評価・レビューする手法。
3行解説（詳細ポイント）
1実装に入る前のアーキテクチャ設計段階で、品質特性（性能、可用性、セキュリティ、変更容易性）のシナリオを用いて設計上のリスクや感度点・トレードオフ点を体系的に評価・レビューする手法。
2例えば「暗号化強度や監査ログ詳細度を上げると応答性能が劣化する」といったトレードオフ点を洗い出し、ステークホルダ合意のもとで設計方針を確定します。
3試験対策：午後II小論文で「システムアーキテクトとしてどのように設計品質を検証し、関係者間で合意形成したか」を論述する際の高度な専...
えすえるえーとえすえるおー品質・テスト・設計原則午前II午後I記述午後II小論文★★
SLA / SLO / SLI（サービスレベル目標と指標の設計）
SLA, SLO & SLI (Service Level Management)1行解説（要点）
顧客や利用部門と合意するサービス品質保証契約（SLA）、その達成のためにシステム内部で設定する目標値（SLO：99.9%稼働、95パーセンタイル応答1秒以内等）、および実測指標（SLI）。
3行解説（詳細ポイント）
1顧客や利用部門と合意するサービス品質保証契約（SLA）、その達成のためにシステム内部で設定する目標値（SLO：99.9%稼働、95パーセンタイル応答1秒以内等）、および実測指標（SLI）。
2平均値ではなく「95パーセンタイル／99パーセンタイル応答時間」や「エラーバジェット（許容される障害時間の枠）」で定義することで、実態に即した品質管理を行えます。
3試験対策：午後II小論文の設問ア（非機能目標の設定）および設問ウ（導入後の定量的評価）を論理的に一貫させるための枠組みとして極めて...