第01章　システムアーキテクトが扱う「境界」

業務上の問題とシステム上の問題

店舗の発注ミスが増えたという依頼が来たとする。画面の入力チェックを増やせば改善するかもしれない。しかし、入力者が何を見て数量を決めるべきか、納品日程と在庫情報は更新されているか、異常注文を誰が承認するかが曖昧なら、チェックを増やしてもミスの発生源は残る。業務要求をソフトウェア機能に変換する前に、業務目的、利害関係者、処理、情報、制約を分けて確かめる必要がある。

業務要件は業務として達成すること、システム要件は情報システムに担わせる振る舞いや品質である。「発注ミスを減らす」は業務目標、「発注時に在庫と入荷予定を表示する」は機能要件、「営業時間中の応答は一定の時間内」は非機能要件になり得る。目的と手段、評価尺度と実装方法を同一視すると、正しく実装したのに効果が出ない状態が生じる。

業務分析で扱うのは現行業務の模倣ではない。不要な承認、二重入力、例外処理の属人化を可視化し、デジタル化によってどの処理をなくせるか判断する。業務の手順をそのままプログラムの処理フローと読み替えるのは、現行の非効率を固定する危険がある。

ビジネス・情報・アプリケーション・技術を重ねる

エンタープライズアーキテクチャ（EA）では、何を事業として行うか、どの情報を持つか、どのアプリケーションが扱うか、どの技術基盤で動かすかを分けて捉える。BA（ビジネスアーキテクチャ）は業務機能と業務プロセス、DAはデータの構造や流れ、AAはアプリケーションと相互関係、TAは基盤技術を主として扱う。

ここで混同されやすいのは「図の種類」と「何を表すか」である。DFDはデータの流れを可視化するため、EAの業務分析でも利用できる。一方、ネットワーク構成図やサーバ台数の一覧は、同じEA成果物であっても技術基盤の観点が中心になる。DFDを見た瞬間にデータベース設計図だと決めつけるのは誤りである。

システム全体の境界は、責務の境界でもある。業務上の承認はシステムが自動化してよいか。外部サービスが不応答でも注文受付を継続すべきか。個人情報が事業者間を移動するか。境界を誤ると、個々のプログラムは正しくてもシステムとして矛盾する。

選択肢を読むときの立場

システムアーキテクトに求められる知識は、製品の名称を列挙する力ではなく、設計目的に応じて方式を選び、トレードオフを説明する力である。午前Ⅱでも、同じ技術が異なる文脈で正解にも不正解にもなり得る。「障害時に常に停止すべき」は、危険動作を防ぐ装置なら妥当な場合があるが、利用可能な機能だけ継続する業務システムでは過剰な一般化である。

境界を決めると、設計の責任も決まる

ある自治体が住民向け予約システムを作る。予約画面とデータベースを設計するだけなら難しくない。ところが、予約枠を公開する責任が担当課にあるのか、施設にあるのか、利用者の本人確認を既存の共通基盤へ任せられるのか、災害時の停止を誰が宣言するのかによって、同じ「予約する」機能でも構成は変わる。ここで必要なのは、処理の入口・出口を線で囲むことにとどまらない。線の内側で制御できることと、外側に依存することを区別する仕事である。

設計上の重要な境界は四つある。業務目的とシステム機能の境界、組織と組織の契約境界、アプリケーション同士のインタフェース境界、障害・セキュリティの信頼境界である。外部ID基盤が利用できないときにも予約済みの内容を確認できるか、という質問は機能の話であると同時に可用性と依存関係の話になる。システムアーキテクトは、一つの要求を複数の境界から読む。

「外部サービスを使えば自社で運用しなくてよい」という説明には落とし穴がある。設備の運用責任は外部へ移せても、個人情報の取扱い、利用者への説明、事業継続上の判断がすべて消えるとは限らない。逆に、内部実装にこだわるあまり、認証・監視・監査といった横断機能を各システムへ重複して持たせれば、整合が失われる。問題が何の境界を尋ねているかを定めれば、「分離」や「統合」のどちらが正しいかは条件から決められる。

要求から運用まで、設計を逆向きにたどる

本番で障害が起きたとしよう。復旧目標を満たせない原因がストレージの故障だったとして、答えをディスクの冗長化だけに求めると誤る。復旧手順の訓練、バックアップ時点、アプリケーションの整合、クラウドリージョンの選択、復旧の責任者と承認経路まで一つの連鎖として追わなければならない。障害は運用で発生するが、対応可能性の多くは設計時に決まっている。

午前Ⅱの選択肢は、テスト手法や契約方式、暗号方式など個別の名詞を答えさせるように見える。しかし、どの技術が何を保証し、何を保証しないかを尋ねている点では一貫している。保証対象を特定すること。これが午前Ⅱ全体を通じる判断手順となる。

第02章　要求は誰のものか――ライフサイクル、合意、トレーサビリティ

要求を作る人と承認する人

システム開発では、ヒアリングをした受注側が要求仕様書を作成することがある。しかし、文書の作成担当が変わっても、事業上の妥当性を承認する権限まで自動的に移るわけではない。要求の提出、分析、妥当性確認、承認は異なる行為である。2016年、2018年などには共通フレームやライフサイクルプロセスの成果物と責任主体を区別する設問がある。

利害関係者要求は、利用者・発注者・運用者・法規制などから生じる期待を表す。それを、システムが検証可能な要件へ落とす。要求を「速くする」と書いただけではテストできない。「ピーク時300リクエスト/秒で95パーセンタイル応答時間2秒以内」とすれば、条件と合否が定まる。もっとも、数値目標が測定環境と業務負荷から独立していると、達成しても実利用で役に立たない。

要件の完全性は必要な要求が落ちていないこと、一貫性は相互矛盾がないこと、実現可能性は技術・予算・期間に収まること、検証可能性は合否が判定できることを指す。曖昧さを残したまま基本設計へ進むと、仕様変更の責任をめぐる問題が生じやすい。要件の「優先順位」と「必須か任意か」も一致するとは限らない。法令遵守は価値が目立たなくても必須である。

JIS X 0160とJIS X 0170を混同しない

ソフトウェアライフサイクルとシステムライフサイクルは近接するが、対応規格を逆に覚えてはいけない。JIS X 0160（ISO/IEC 12207／ISO/IEC/IEEE 12207）はソフトウェアライフサイクルプロセス、JIS X 0170（ISO/IEC 15288／ISO/IEC/IEEE 15288）はシステムライフサイクルプロセスである。JIS X 0160:2012はISO/IEC 12207:2008に、JIS X 0160:2021はISO/IEC/IEEE 12207:2017に対応する。JIS X 0170:2020はISO/IEC/IEEE 15288:2015に対応する。両規格は相互に整合するよう改訂されており、ソフトウェア向け規格のJIS X 0160にも「システム要求事項分析」のようなテクニカルプロセスが含まれる。工程の名称だけで適用規格を推測せず、問題が指定する規格番号と版を確認する。出典：IPA「国際規格/JIS改訂に対応する『共通フレーム』の利用について」。

「システム要求事項分析」の成果と「システム方式設計」の成果を区別するには、作業の前後関係を考える。要求分析は利害関係者の意図を技術システムへ要求として定義し、合意し、検証基準へつなぐ。方式設計は、その要求を満たすためにシステム構成要素へ責務を割り当てる。何を満たすかが前者、どこがどう担うかが後者の中心である。試験で似た表現が並ぶときは、この境界に注目する。

ライフサイクルの「テーラリング」は、適用するプロセスをプロジェクトや組織の特性に合わせて修正・選定することだ。要求が不明確な小規模開発と、安全性の証拠を厳格に管理するシステムで同じ文書量を課す必要はない。しかし、テーラリングは品質保証を免除する魔法ではなく、目的と成果を保ちながらプロセスを調整する行為である。

ベースラインと変更管理

要件が一度承認された状態をベースラインとして管理すると、以降の変更について「何が変わったか」「なぜ必要か」「どの設計・テストが影響を受けるか」を追跡できる。ベースラインは「変更禁止」ではない。合意なく書き換わらないようにする基準点である。

要求から設計、実装、テストまでを結ぶのがトレーサビリティである。双方向にたどれれば、実装機能がどの要求に対応するか、逆に要求を検証するテストが存在するかを確認できる。トレーサビリティの欠落は、要件漏れだけでなく、根拠のない機能が増殖する原因にもなる。

検証と妥当性確認

Verificationは一般に「指定された要求や仕様に従って作ったか」を確かめ、Validationは「意図した用途・利用者の必要を満たすか」を確かめる。両者を単純に「開発者テストとユーザテスト」に置き換えて覚えるのは危険である。ソフトウェア結合テスト、システム適格性確認、受入支援などは対象と責任と評価基準が異なる。

例えば、仕様どおり出荷数を計算するプログラムであっても、倉庫担当者が使うには検索条件が複雑すぎるなら、仕様への適合だけでは業務目的を達成できない。要件定義時の利用シナリオを残しておけば、仕様にない使いにくさを妥当性の観点で検出できる。

移行・保守・廃棄も設計である

新システム稼働の瞬間だけを設計対象にすると、旧システムの参照停止、データ移行後の照合、ロールバック、利用者教育、長期保存データの廃棄が取り残される。移行ではデータの件数だけでなく、意味と制約、文字コード、参照整合性、時点整合性まで確かめる。保守はバグ修正だけでなく環境・業務変更への適応や改善を含む。廃棄は電源を切ることではなく、利用者への通知、データの移管・消去、契約上の記録保持などを扱う。

要求の種類を、承認と検証の場面で見分ける

「月末の請求処理を翌営業日午前までに終える」は業務上の期限である。この要求から、毎時何件を処理するか、特定バッチとオンライン照会を並行動作させるか、障害時にどこから再開するか、といったシステム要件が導かれる。「夜間バッチを採用する」は設計方式の候補であり、業務側が夜間バッチ自体を必要と明示していない限り、要求そのものではない。手段を要求として固定すると、よりよい方式を後から採用しにくくなる。

仕様の検証（verification）は記述された要求を満たしたかを問う。妥当性確認（validation）は、その要求自体や出来上がったものが意図された用途に合うかを問う。例えば「50人まで同時予約できる」という仕様をテストで満たしても、イベント開始時には500人が同時にアクセスするなら、業務の目的は満たせない。両方の試験を計画に持つべき理由がここにある。どちらの活動も、特定の工程や担当者の名前だけで一対一に分類できるわけではない。

要求を承認する人、仕様を作成する人、検証する人も区別する。供給者がシステム要件をまとめることはあるが、事業価値や調達条件の受諾は取得者の責任に属する場面がある。プロセス規格の問題では「システム要求事項がベースラインとなる」と「システム要素へ要求事項を割り当てる」の間に工程差がある。前者は何を満たすかを確定する行為、後者はどの構成要素が満たすかを設計する行為である。

変更管理の経路を具体化する

出荷日の計算規則が変更されたとする。要求ID R-12「休日を考慮した出荷日を算出する」に対し、業務ルール BR-07、API設計 IF-03、テスト T-22/T-29が関連付いていれば、変更影響をたどれる。要求が100件あっても対応するテストが存在しないものは見つかるし、反対にどの要求にも対応しない実装が混入すれば説明できる。

ベースラインがあるからといって変更が禁止になるのではない。変更を申請し、影響を評価し、承認された状態を新しい基準として保持する。試験で「承認済み＝変更不可」という表現が出たら疑うべきである。「変更可能」と「追跡可能」も異なる。変更できる仕組みだけでは、変更した理由やテストへの波及は保存されない。

第03章　聞き出した言葉を「要件」にする

構造化インタビューの強みと弱み

「必要な機能を教えてください」とだけ質問すると、回答者が思いつく機能の寄せ集めになりやすい。構造化インタビューは事前に質問項目と順序を設計し、複数の回答を比較しやすくする。一方、あらかじめ設けた問いに収まらない発見や、その場での深掘りには制約がある。半構造化インタビューは核となる質問を用意しながら、回答に応じて追加質問を行う。

選択問題では、標準化された回答の比較に優れることと、予期しない問題の探索に優れることが入れ替えられやすい。技法の優劣は調査目的に依存する。業務横断で共通の処理時間を比較したいなら構造化が便利だが、初めて扱う業務で暗黙知を発掘したいなら観察や非構造化面接も必要になる。

ユースケースは画面遷移図ではない

顧客が「商品を返品する」という目標を持つ場合、利用者は本人確認、返品条件の確認、受付、返金の結果を得る。これをユースケースとすると、システムが外部のアクターとどう協働して価値を提供するかを表せる。ユースケース図の楕円は機能単位の目標、アクターは役割、システム境界は内外の責務を表す。UIのボタンを一つずつ楕円に描くものではない。

ユースケース駆動開発では、シナリオを要求獲得、分析、設計、検証にわたる共通の軸として利用できる。例外フローを早めに明らかにできる点も大きい。「ユースケースを作れば画面設計が自動的に完成する」「ユースケースはDBのテーブル構成を定義する」は誤りである。

プロトタイピング――横に広く、縦に深く

水平型プロトタイプは広い範囲の画面や操作を浅い実装で示す。メニューやナビゲーションの理解、利用者間の共通イメージ形成に向く。垂直型プロトタイプは一つの機能をUIから業務ロジック、データアクセスまで深く作り、技術的な実現性や応答時間を確かめる。どちらも「早期にフィードバックを得る」という目的を持つが、検証できるリスクは違う。

作った画面が動いたから実運用に耐えるとは限らない。浅いプロトタイプが保証できないのは統合・性能・移行のような内側の性質であり、深いプロトタイプが保証しにくいのは業務全体の使い勝手や機能の網羅性である。試験では「何を確かめたいか」からプロトタイプの型を逆算する。

機能要求と非機能要求の交点

パスワードの有効期限や、決済前の本人認証は画面上の機能として見えるため機能要件に感じられる。一方、セキュリティ特性の実現手段としては非機能要求から導かれる場合もある。分類名だけで断定せず、要求が記述する対象と粒度で判断する。機能要件はシステムの振る舞い、非機能要件は性能・安全性・信頼性・運用性などの品質や制約を主として示すが、その境界には相互作用がある。

非機能要求を品質特性名だけで放置してはいけない。「可用性が高い」では評価できない。計画停止を含めるか、観測時間帯は何か、依存先停止時の許容業務は何かを定義する必要がある。非機能の要求を作る仕事は、数値を決めるだけでなく、測定方法と障害の想定を決めることである。

インタビューの回答が一致しても、業務が一致するとは限らない

複数拠点に「注文キャンセルは誰が承認しますか」と尋ね、全員が「課長」と答えたとする。回答は揃っている。しかし、ある拠点では紙の承認印を押し、別の拠点では担当者が口頭で了解を得てから管理画面を操作しているかもしれない。構造化インタビューは比較に強いが、暗黙の行動を直接観察したわけではない。現場観察、業務ログ分析、例外ケースのウォークスルーを組み合わせる理由はそこにある。

観察では、標準手順書に書かれていない迂回路が見える。担当者がシステムAからエクスポートしたCSVを加工し、システムBへ手入力しているなら、その手作業は新システムの連携要件になる可能性がある。ただし、手順を自動化する前に、その作業が本当に必要なのかを確認する。存在する手順が、あるべき手順とは限らない。

ユースケースに例外を追加すると、要求の穴が見える

利用者が予約するユースケースの基本フローは「日時を選ぶ→空き枠を確認→予約を確定→通知する」で書ける。では、確定直前に他の利用者が同じ枠を取得したらどうするか。通知に失敗したら予約を取り消すべきか。取消料はいつから発生するか。例外を具体化すると、トランザクション境界、非同期通知、冪等性、業務ルールが表に出る。

ユースケース図のincludeは共通動作を含める関係、extendは基本フローに条件付きで拡張を追加する関係を表す。両者を「処理が先に起きるか後に起きるか」で区別しない。アクターも単なる人間ではなく、役割や外部システムを含む。画面一枚をユースケース一つとみなすのは、目標をUI実装へ矮小化する誤りである。

第04章　業務を可視化する――DFD、CRUD、EA、BMC

DFDの矢印は命令の順序ではない

注文データを受け取って在庫を照会し、請求データを作る業務を考える。DFD（Data Flow Diagram）の中心は、処理（プロセス）、データフロー、データストア、外部実体（源泉・吸収）という四つである。矢印は情報の受渡しを示すが、処理の実行順序や制御条件を完全に表すものではない。

一つのプロセスを下位DFDへ分割するときは、親プロセスに入る／親プロセスから出るデータフローと、子プロセス群の外部インタフェースが整合しなければならない。これをバランシングという。子にしか現れない外部入力や、親にあるのに子で消える出力があれば、階層間でシステムの振る舞いが変わってしまう。2019年、2023年などの図表問題の本質はこの整合性である。

DFDとER図は対象が違う。DFDはデータがどこで動き変換されるか、ER図はデータがどう構成され相互に関係するかを扱う。「実体」「関連」という言葉を見てDFDの四要素に含める誤答は、二つの図の境界を混同している。

CRUDマトリクス――機能とデータを縦横に置く

CRUDマトリクスでは行に業務機能、列にデータ実体を置き、Create・Read・Update・Deleteのどの操作があるかを整理する。例えば「受注確定」は注文をCし、在庫をR/Uする。データを作る機能が存在しない、更新する機能が異常に多い、重要なデータがどの業務からも参照されないという設計上の違和感が見える。

CRUDはデータフローそのものではない。機能がデータを読む／書く関係を示すが、時系列や承認経路は別の図で補う必要がある。また、CとUを「データが変わること」で一括りにすると、初回登録と既存レコードの訂正という異なる操作が区別できなくなる。

ビジネスモデルキャンバスとKPIの接続

ビジネスモデルキャンバスは顧客セグメント、価値提案、チャネル、顧客との関係、収益、主要資源、主要活動、主要パートナー、コスト構造という九つの観点で事業を描く。BMCは直接的なシステム設計図ではなく、「誰のために何を価値として提供するか」の整理を助ける。価値提案が不明確なまま大量の機能を設計しても、技術投資の優先順位を決められない。

EAが組織・情報・アプリケーション・技術の全体整合を見せるのに対し、BMCは事業の価値創出・収益の構造を俯瞰する。BSC（バランススコアカード）は戦略を指標へ展開して管理する枠組みであり、役割が違う。表形式の道具という外見だけで同じ目的だと判断しない。

業務フロー図、DFD、ER図、CRUD表が答える問い

注文受付が二重になる原因を調べる。担当者の作業順を知りたいなら業務フロー、どの外部実体からどのデータが来てどこに保存されるかを知りたいならDFDが役立つ。注文と注文明細の属性・関連を明らかにするならER図、各業務機能が注文テーブルを生成・参照・更新・削除のどれで扱うかを知りたいならCRUDマトリックスが向く。四つは同じ業務を異なる情報へ投影した図であり、互いに排他的ではない。

DFDの矢印を「担当者が次に実行する処理」と読んではならない。データフローは何が移動するかを表し、順序制御を完全には表現しない。同様にER図の関連を「業務でデータが移動する方向」と読むこともできない。設問文が「処理と情報の出入り」「実体間の関連」「データの操作主体」のどれを強調しているかが図の選択を決める。

DFDのバランシングを紙の上で確かめる

最上位の「受注処理」プロセスに、顧客からの「注文情報」が入り、顧客へ「受注結果」が出て、倉庫へ「出荷指示」が出るとする。下位図では「注文登録」「在庫引当」「出荷指示作成」に分解されるが、外との境界に現れる入出力は親と対応していなければならない。もし下位図にだけ「顧客認証情報」という外部入力が追加されていれば、親図に書き漏れがないか、下位の外部入力が内部データとして表現されるべきかを確認する。

バランシングはプロセスの個数が等しいことではない。親の一つを子の三つへ分割してよいし、子の中だけを流れる内部データが増えてよい。整合を要求されるのは外部とのデータ流である。この違いが図表問題での選択肢の核になる。

CRUD表は改修範囲の発見にも使える

あるデータ項目を削除したいとき、誰が書き込み、誰が参照し、誰が削除するかを横断的に並べると影響を受ける業務が見える。CRUD表の空白は「操作がない」ことを示す。ただし、業務担当への確認が漏れた結果の空白かもしれない。例えば売上確定の後に在庫を引き当てる設計なら、更新処理の依存関係を更に確認する必要がある。CRUD表だけからタイミングやトランザクション境界まで結論してはいけない。

第05章　モデルは何を捨て、何を残すか――UML、SysML、ペトリネット

クラス図は「もの」の関係、シーケンス図は「やりとり」

「一人の顧客が複数の商品を注文できる」という文章だけでは、商品を何個買ったかが分からない。顧客、注文、注文明細、商品をクラスとして分け、注文1件に複数の注文明細が属する関係を置く。注文明細には数量・単価・割引の情報を持たせられる。商品のマスタと取引時点の価格の責務を切り分けることも重要だ。

UMLクラス図の多重度は、相手側のインスタンスが幾つ対応するかを示す。1、0..1、0..*、1..*を読み違えると、任意か必須かが逆になる。集約（白ひし形）とコンポジション（黒ひし形）は同じではない。コンポジションは強い全体・部分関係を表し、部品が同時に複数の全体へ属するようなモデルには通常向かない。

クラス図は静的な構造である。メッセージの順序を知りたいならシーケンス図、業務や処理の分岐・並行・同期を知りたいならアクティビティ図、状態の遷移条件を知りたいならステートマシン図を使う。どれか一つが「最も優秀な図」なのではない。問いが変われば図も変わる。

並行性を扱う三つの図

アクティビティ図ではフォークで一つの流れを並行処理へ分岐し、ジョインで待ち合わせを表現できる。ステートマシン図ではイベント（トリガ）、ガード条件、遷移、状態内動作を使う。ペトリネットではプレース、トランジション、トークンの動きを用い、同時に起きる事象の同期や資源競合を表現できる。

例えば二人の作業者が共通の検査装置を使うとする。作業者ごとの状態遷移図だけでは、検査装置を同時に占有できない制約を直感的に表しにくい。ペトリネットの「装置が空いている」というプレースにトークンを一つ置けば、そのトークンを消費するトランジションだけが実行できる。制御フローではなく資源と同時性が問題の核心となる。

SysMLはUML由来の概念を使いながら、ハードウェア・ソフトウェア・人・設備を含むシステム工学のモデル化を支える。特に要求、構造、振る舞い、パラメトリックな制約を関連付けたい場合に有用である。SysMLを「UMLの単なる別名」としたり、「プログラムのクラス設計専用」と捉えたりするのは誤りだ。

モデルが正しくても要求が間違うことがある

「どの図を使うか」という問題では、図の記号を思い出すだけでなく、観測したい性質を言語化すると解ける。対象が時系列ならシーケンス、状態ならステート、データの移動ならDFD、構造ならクラス、同期する資源ならペトリネット。複数の図が少しずつ対象を表現できる場合でも、設問が中心に置く性質に最も適したものを選ぶ。

UMLの図は実行時の視点を変える

注文クラスと注文明細クラスの間に「注文1件に対して注文明細が1件以上ある」という多重度を付けたとする。注文明細は注文がなければ意味を持たない。この場面で集約とコンポジションの違いが問題になる。通常の関連はオブジェクト間のつながり、集約は全体部分の弱い関係、コンポジションは所有とライフサイクル上の強い包含を表す。コンポジションなら部分は同時に二つの合成全体へ属さない。物理DBの外部キーと記法上の関係は関連するが、等号で結べない。

同じ予約システムを、状態遷移図で表すと「仮予約→確定→取消」「確定→利用済み」といった状態変化が中心になる。アクティビティ図で表すと、「本人確認と空席検索の並列実行」「決済成功なら通知」のように処理の流れと分岐が中心になる。シーケンス図は呼出しの時間的順序を示し、クラス図は静的な構造を示す。図の違いは記号を覚えるより、何が視野に入り、何を捨てているかで理解する。

並行・排他・同期を区別する

ペトリネットでは、プレース（状態や条件）、トランジション（発火する事象）、トークン（成立している状態の印）を使う。二つの処理が同時に走れることと、両方が終わるまで次へ進めないことは違う。並行を表す分岐でトークンが複数経路へ進み、同期のための合流トランジションが必要なトークンを待つ、という形でその違いを表せる。

状態遷移図の分岐を描いただけで、並行動作を表したとは限らない。イベント、状態、トークン、実行順序のどれを問いにしているか確認する。SysMLは複雑なシステムの要求・構造・振る舞い・パラメトリックな制約を扱うため、ソフトウェアだけに限定したクラス図の読み方で全体を理解しようとすると不足する。

第06章　変更に強い設計――凝集度、結合度、SOLID、デザインパターン

変更の波及を止める境界を作る

二つのモジュールが同じグローバル変数を書き換えると、片方の内部を直しただけで他方の振る舞いが変わる。モジュールの結合度が高い状態である。対照的に、必要なデータを引数として渡し、返り値で結果を受け取るなら、依存が明示される。データ結合は一般に疎な結合として好まれ、共通結合（共有の大域データ）や内容結合（他モジュールの内部へ直接依存）は変更影響が大きい。

一方、モジュール内の機能が密接に一つの目的へまとまるほど、凝集度は高い。無関係な関数を「便利だから」と一か所に集めれば、結合度を減らせたように見えても、モジュールの責任が曖昧になる。低結合・高凝集は暗記句ではなく、「ある仕様変更がどこまで伝わるか」を最小化する方針だ。

開放・閉鎖原則は変更を禁止しない

新しい決済手段を追加するたびに既存の注文クラスへif分岐を足す設計を考える。決済手段という変わりやすい部分を抽象的なインタフェースへ切り出し、個別の実装を追加できれば、共通処理に触れる回数を減らせる。これがOCP（Open/Closed Principle）の発想、拡張に開き修正に閉じるである。

「既存コードを絶対に変更しない」は誤解だ。既存コードの変更を必要以上に誘発しない依存関係を設計する原則であって、欠陥修正や設計改善まで禁じるものではない。SRPは変更理由を一つにする、LSPは置換可能性、ISPは利用者ごとに不要なインタフェース依存を避ける、DIPは高水準と低水準の両方を抽象へ依存させる考え方だ。

Strategy、Observer、MVC――よく似た「切り離す」の違い

帳票をPDFとCSVとXMLで出力する場合、形式ごとの処理を差し替えるStrategyパターンが有用になる。注文確定後にメールやポイント付与など複数の処理へ状態変化を通知したいならObserverが候補になる。UIとビジネスロジックの結び付きを弱めるならMVCのような役割分離が考えられる。どれも柔軟にするが、差し替えたいものがアルゴリズムなのか、通知先なのか、画面責務なのかが異なる。

GoFのデザインパターンは主としてオブジェクト間の生成・構造・振る舞いを扱う再利用可能な設計知識である。アーキテクチャパターンはシステムの大きな構造や責務分割、イディオムは特定言語の小さな表現技法を扱う。出題された名称が同じ「パターン」でも適用粒度は違う。

Reflection、AOP、オーバーライド

POSAのReflectionパターンは、システム構造を表すメタレベルと実際の処理を担うベースレベルを分け、構造の変更に対する柔軟性を高める。AOP（アスペクト指向）は、ログ・認可・トランザクションなど複数箇所に横断する関心事を分離する。オーバーライドは、継承したメソッドを同じシグネチャで再定義して振る舞いを変える。オーバーロード（同じ名前で引数が異なるメソッドを定義する）とは違う。

AOPとObserverは、ともに既存処理へ後続動作を付けられそうに見えるが、前者は横断的な関心事の適用、後者はオブジェクトの状態変化通知という目的が中心だ。試験の文章で「実装を直接書き換えず後から処理を差し込む」と言われたとき、どの単位へ何を適用するかを丁寧に読む。

値渡し、参照渡し、参照透過性

値渡しでは呼び出し側の値をコピーして渡すため、呼び出された関数で仮引数を代入しても、元の変数へ直接反映されない。ただし、参照値（オブジェクトへの参照）を値渡しする言語では、同じオブジェクトの内部状態が変更される場合がある。引数変数への代入と指しているオブジェクトの変更は異なる。参照渡しは呼び出し側の変数自体へ作用し得る。

純粋関数の参照透過性は、同じ式をその評価結果で置き換えてもプログラムの意味が変わらない性質である。副作用や外部状態への依存がないと推論・並列化・テストが容易になる。論理型プログラミングでは事実と規則から解を導く推論（単一化やバックトラッキングなど）を利用する。命令型の「どの順に代入するか」と発想が異なる。

SOLIDは五つの標語ではなく、変更の伝播を抑える手段である

売上の割引計算を追加したら、注文保存や監査ログにまで変更が必要になった。問題は割引式が難しいことより、異なる変更理由を一つのモジュールへ詰め込んでいることである。単一責任原則（SRP）は、変更の理由が混ざりにくい責務のまとまりを考える。開放・閉鎖原則（OCP）は、既存コードを書き換えることに頼らず新しい振る舞いを拡張できる設計を狙う。リスコフ置換原則（LSP）は、基底型が満たす約束を派生型が破らず代入可能であることを求める。

一方、インタフェース分離原則（ISP）は利用側に不要なメソッドへの依存を強いない。依存性逆転原則（DIP）は高水準の方針が低水準の具体実装へ直接依存する状態を避け、両者を抽象に依存させる。これらの名前が選択肢へ同時に現れると、どれも良い設計に見える。変更理由、拡張方法、置換の契約、利用インタフェース、依存方向のうち何が説明されているかで決着する。

GoFの分類と代表例をひとまとまりで理解する

GoFの生成パターンはオブジェクト生成の方式を扱い、Factory Method、Abstract Factory、Builder、Prototype、Singletonが属する。構造パターンは既存の要素をどう組み合わせるかを扱い、Adapter、Bridge、Composite、Decorator、Facade、Flyweight、Proxyがある。振る舞いパターンは責務の委譲や相互作用を扱い、Strategy、Observer、Command、State、Template Methodなどが代表的だ。これらの分類は試験で繰り返し問われている。

AdapterとFacadeは共に間に入るが、目的が異なる。Adapterは既存の不適合なインタフェースを期待される形へ変換する。Facadeは複雑なサブシステムへ単純な窓口を提供する。Proxyは代理オブジェクトを通じてアクセスを制御し、Decoratorはオブジェクトの振る舞いを追加する。StrategyとStateはどちらも内部のオブジェクトを切り替える実装に見えるが、Strategyは交換可能なアルゴリズム、Stateは状態に応じた振る舞いの切替を主な意図とする。Observerは通知対象を疎結合に保持し、被観測側の変更を複数の購読者へ伝える。どの場所に変更を閉じ込めたいかを比較する。

凝集度と結合度の直観を数式より先に持つ

「顧客を登録する」モジュールが顧客登録・帳票印刷・メール送信・DB物理設定まで担っていたら、名前に一つの目的があっても凝集しているとは言い難い。異なる理由で変更される仕事が同居するからだ。結合度はモジュール間でどのような情報を渡し、どの内部構造に依存するかを評価する。必要な値を引数で渡すデータ結合と、呼出し先の振る舞いをフラグで操作する制御結合、相手の内部領域を直接参照する内容結合では、変更の伝わり方が異なる。データの量が少ないだけで疎結合と判断しない。内部構造を知る必要があるかが鍵である。

第07章　疎結合でも障害は伝わる――分散アーキテクチャ

マイクロサービス化すると何が独立するのか

巨大な業務アプリケーションを注文、在庫、請求のサービスへ分けると、それぞれを独立に変更・配備・スケールしやすくなる。しかしネットワーク呼出しは失敗する。単一プロセス内の関数呼出しと違い、応答がないとき「相手が実行しなかった」のか「実行したが応答が消えた」のか判断できない。独立性を得る代わりに分散障害・データ整合性・観測の難しさを引き受ける。

SOAは再利用可能な業務サービスの契約や統合を重視する設計思想であり、マイクロサービスは比較的小さな責務と自律的な配備に重点を置くアプローチである。両者は同じではないが完全に排他的でもない。SoS（System of Systems）は独立運用される複数システムが連携して全体能力を生む構造であり、単一システムの内部モジュール分割とは統制や責任の前提が異なる。

再試行が障害を増幅する瞬間

外部の決済APIが遅くなったとき、クライアント全台が無制限に再試行すると相手への負荷がさらに増える。Retryは一時的な失敗を時間を置いて再実行する仕組み、Circuit Breakerは失敗回数などがしきい値へ達すると呼出し自体を遮断する仕組みだ。サーキットブレーカーには通常Closed（通す）、Open（遮断）、Half-Open（試験的に通す）の状態がある。タイムアウト、指数バックオフ、ジッタ、最大試行回数と組み合わせて設計する。

冪等性も重要だ。同じリクエストを二度送っても結果が二重にならない操作が冪等である。銀行振込を「送金する」APIに無条件で再試行をかけると二重送金の危険がある。冪等キーや一意性制約などで重複処理を避ける設計が必要になる。応答がなかったことは、処理がなかったことの証拠ではない。

Bulkhead、Queue、Event――失敗の波及先を制限する

Bulkhead（隔壁）はリソースのプールや実行の単位を分け、ある機能の過負荷が他機能を巻き込むのを抑える。Queueは送受信を時間的に切り離し、短時間の負荷変動を吸収する。イベント駆動は状態変化を発行側が通知し、受信側が独立して処理する方式だ。いずれも万能ではなく、キューの滞留、順序保証、再処理、処理遅延、二重配送を考慮する必要がある。

分散処理の「透明性」にはアクセス透明性、位置透明性、障害透明性、複製透明性など異なるものがある。障害透明性は障害を利用者から隠して可能な範囲でサービスを継続する性質であり、障害そのものを絶対に発生させないことではない。隠蔽しすぎれば業務上の誤認が生じるため、部分失敗を明示すべき場面もある。

分散システムでは「呼び出した」と「実行された」が離れる

支払APIへ注文確定を依頼した直後、通信がタイムアウトした。呼出し元から見えるのは「結果が届かなかった」事実だけであり、決済が失敗したとは限らない。相手側では処理が成功し、応答だけが失われたかもしれない。ここで無条件に再送すると二重決済が起きる。冪等キーを利用して同じ業務操作の重複実行を識別する仕組みや、処理結果を照会する設計が必要になる。

再試行（Retry）は一時的な失敗から回復するための手段だが、混雑している相手へ多数のクライアントが同時に再試行すれば、負荷を増幅する。指数バックオフとジッターは再試行間隔を広げ、集中を避ける。タイムアウトは待ち時間に上限を与える。サーキットブレーカーは失敗が一定条件に達した依存先への呼出しを一時遮断し、半開状態で回復を探る。再試行はもう一度呼ぶ。ブレーカーは今は呼ばない。方向が逆なので、混同すると設問の答えを取り違える。

同期・非同期・整合性の問題はつながっている

商品を発注したとき、利用者へ受付番号だけを即時返し、出荷予約や通知をキューで後続処理することがある。応答時間を短くし依存先の停止を吸収できる反面、後続処理の失敗をどう検知するか、重複メッセージにどう耐えるか、処理順序をどう守るかを設計しなければならない。メッセージ配送のat-least-onceは重複を許容するため、受信側の冪等化が重要になる。exactly-onceという保証は、何を一回と数えるか、メッセージ処理と外部副作用の原子性まで含むかで意味が変わる。

CQRSは更新を担うモデルと読取りを担うモデルを分ける設計であり、サーキットブレーカーの代用品ではない。サービスディスカバリーは呼び出す先のインスタンスを見つける機構、RPCは遠隔の手続きを呼び出す通信方式を抽象化した概念だ。どれもマイクロサービスで使えるが、障害遮断、モデル分離、所在発見、呼出し方式という異なる仕事をしている。

第08章　開発モデルはスケジュール表ではない

ウォーターフォール、反復、増分、スパイラル

要求が安定し、手続や承認が厳格に定まる環境では、工程ごとの成果物とレビューを明確にするウォーターフォール型が扱いやすい。しかし、最後まで利用者が本物に触れられないと、要求の誤解が後期に見つかることがある。増分開発は機能を段階的に追加して稼働可能な成果物を増やす。反復開発は同じシステムを繰り返し改良して成熟させる。実務では両者を組み合わせることも多い。

スパイラルモデルはリスクの識別・評価とその低減をサイクルへ織り込み、未知が大きい開発に向く。プロトタイプは設計・技術・利用者理解の不確実性を下げるために作る。小さく作ること自体が目的ではなく、不確実な仮説に早く答えを得ることが目的だ。

V字モデルは上流の要求・設計と、それらを確かめる下流のテストを対応させる考え方を視覚化する。単体テストはモジュール設計、結合テストは構成要素間の設計、システムテストはシステム要求と対応付けやすい。ただしテスト名称や適格性確認の位置付けは、採用規格・対象物・組織によって異なる。単に「左側が作成、右側が品質保証」と記憶するだけでは選択肢の微妙な違いに対応できない。

レビューで発見できる欠陥と、実行して初めて出る欠陥

ウォークスルーは、作成者などが成果物を説明しながら参加者と確認するレビュー技法である。インスペクションは役割・手順・記録などがより形式化されたレビューとして用いられる。レビューは実行を伴わなくても要求漏れや記述矛盾を発見できるが、実機負荷による遅延や実際の競合タイミングまでは十分に確認できない。

コードを読むだけの静的解析、テストケースを与えて実行する動的テスト、生成物の挙動を検証する形式手法は、互いに排他的ではない。早期に安価に見つかる欠陥と、実環境で初めて露呈する欠陥は違う。レビュー件数が多いから品質が高いとも、レビューで欠陥がゼロだから完全ともいえない。

移行方式の選択は停止時間と復旧可能性の取引

一斉切替は期間を短くしやすいが、問題が生じた場合の影響が一度に広がる。段階移行は業務や拠点ごとに移すため影響を限定しやすい一方、新旧システムの同期・運用費用が増える。並行稼働では結果比較や切戻しが容易になり得るが、データ二重入力や処理の整合性が課題になる。

「停止時間が短い方式が常に優れる」という選択肢には注意する。複雑な双方向同期で整合性を破壊するくらいなら、計画停止を許容して一貫性を保つ方が安全な場合がある。決めるべきなのは事業上の許容停止時間、データ損失、切戻し可能性、運用体制である。

開発モデルは要求が変わるときに真価が分かる

公共性の高い業務システムで、法規制と受入条件が明確なら、工程と成果物を追跡しやすい進め方が有効な場合がある。一方、新しい体験の有用性を確かめたいサービスで要件を半年固定すれば、仕様どおり完成しても需要から外れかねない。ウォーターフォールと反復型の優劣ではなく、要求の不確実性、技術リスク、変更費用、契約上の制約を先に読むべきである。

ウォーターフォールは段階的に工程を進める枠組み、インクリメンタル開発は機能の部分集合を段階的に完成させる枠組み、反復型開発は同じ対象を繰り返し精緻化する枠組みである。スパイラルモデルは反復の節目でリスク分析を明示的に扱う。プロトタイピングは不確実な要求や技術を早期に試す方法で、開発モデルの中へ組み込める。モデルを一つ選ぶことと、個別の技法を禁じることは同義ではない。

レビューはテストの代わりにならないが、テストだけでも足りない

設計書でインタフェースの不整合を見つけるレビューと、実装へ入力して結果を観察する動的テストは異なる。レビューは動かさずに要件の矛盾や不足を発見できる。テストは実際の振る舞いを示すが、実行した入力以外まで完全に証明したわけではない。要求分析・アーキテクチャ設計・詳細設計・実装の各段階で、不確実性に合った検証手段を選ぶことが品質と工数の両方を左右する。

第09章　アジャイルを儀式で覚えない――INVEST、Scrum、Lean

ユーザーストーリーが大きすぎる問題

「会員として、すべての購入手続きを改善したい」は、何を完成と判断すべきか曖昧である。INVESTはユーザーストーリーを点検する六つの観点、Independent（独立）、Negotiable（交渉可能）、Valuable（価値がある）、Estimable（見積可能）、Small（小さい）、Testable（試験可能）の頭文字だ。ストーリーが開発順序に過度に依存したり、価値のない実装作業だけを指していたりするなら、分割や再定義を検討する。

INVESTは「個人を評価する指標」でも「工程進捗を測る指標」でもない。ストーリーの性質を改善するためのチェックである。ユーザーの目的を理解しないまま文字数だけを短くしても、SmallにはなってもValuableにならない。

Scrumの四つのイベントを混ぜない

Sprint Planningはスプリントで何をなぜ達成しどう進めるかを考える。Daily Scrumは開発者がスプリントゴールへの進捗を点検し計画を調整する。Sprint Reviewはステークホルダーと成果を検査し、今後の適応を考える。Sprint Retrospectiveはチームの仕事の進め方、人、関係、道具などを点検して品質・有効性の改善を計画する。

「顧客へ完成した成果を披露して要求を見直す」のは主としてReview、「開発中に何がうまくいかなかったか振り返る」のはRetrospectiveに対応する。レトロスペクティブは責任追及の会議ではなく、プロセスの改善を具体化する機会である。KPTのKeepは継続したいこと、Problemは困ったこと、Tryは次の改善案を指す。Keep／Problem／Tryを過去・現在・未来の予定としてだけ覚えると意味を取り違える。

アジャイル開発とペアプログラミング

ペアプログラミングではDriverが入力・実装を進め、Navigatorが設計意図・見落とし・改善案を考える。役割は固定的な上下関係ではなく交代可能だ。経験豊富な人がキーボードを独占して未経験者に見せ続けることは、必ずしも両者の知識共有を最大化しない。レビューを実装と同時進行に近づけ、知識を分散させるのが価値である。

リーン開発は価値に寄与しない待ち時間、手戻り、過剰な作り込み、未使用機能などの無駄を取り除き、流れを改善する。スクラムは計画・点検・適応のための枠組み、XPはプログラミング実践を含む開発手法、DevOpsは開発と運用の協働・自動化・継続的改善を重視する文化と技術の組合せである。三者を同義とする説明は正確ではない。

デザイン思考とインセプションデッキ

デザイン思考では利用者へ共感し、問題を定義し、解決案を発想し、プロトタイプで試す。多くの表現があるが、人間中心で仮説を検証しながら学ぶ点が共通する。「先進技術を採用する」ことそのものがデザイン思考ではない。

インセプションデッキはプロジェクト開始時に目的や範囲、やること・やらないこと、リスク、関係者の認識を揃えるための問いの集合である。新規開発の見積精度を必ず高める魔法の文書ではない。何が分かっていて何が未確定かを共有する効果が中心だ。

INVESTを作業分解の視点から読む

「商品管理機能を完成させる」は大きすぎて、一度の反復で価値を検証しにくい。「店員として、欠品中の商品を検索結果から除外したい」は、利用者の目的が明確で受入条件を考えやすい。INVESTのIはIndependent（独立性）、NはNegotiable（交渉可能性）、VはValuable（価値）、EはEstimable（見積可能）、SはSmall（小さい）、TはTestable（テスト可能）を表す。Iは他の仕事への依存を完全にゼロにすることではなく、独立して価値を届けたり順序を選んだりしやすい粒度を目指す。

Nを「詳細を決めないままでよい」と読むのも誤りである。要求の実現方法について対話の余地を保つことと、受入条件が曖昧であることは違う。TとEは特に混同される。何時間かかるか見積もれなくても、合格条件が明確なストーリーはある。反対に実装工数を見積もれても、価値を検証する条件が未定義ならTestableとは言い難い。

Scrumの成果物とイベントは同じ層にない

プロダクトバックログはプロダクトに必要な作業を順序づけた一覧、スプリントバックログはスプリントゴール・選んだ項目・実現計画を含む。インクリメントはDefinition of Doneを満たした利用可能な成果物である。スプリントレビューは成果を利害関係者と検査し、方向を調整する。スプリントレトロスペクティブはチームの進め方や関係性、品質を改善する機会になる。レビューは「成果と今後の価値」、レトロスペクティブは「働き方の改善」という違いで識別する。

ペアプログラミングのドライバーは主にコードを操作し、ナビゲーターは全体の方向、欠陥、代替案を見渡す。役割を交替するのは疲労対策だけでなく、知識と観点の共有にも資する。KPT（Keep・Problem・Try）はふりかえりに利用する整理法であり、Scrum Guideが必須のイベント内容として規定する技法ではない。

第10章　ソフトウェア品質を「よいもの」で終わらせない

製品の品質と利用時の品質

利用者が目的を達成できたか、間違えずに効率よく作業できたかは、内部実装の構造だけからは分からない。ISO/IEC 25010の旧版における製品品質モデルには機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性などがあり、利用時の品質には有効性、効率性、満足性、リスク回避性、利用状況網羅性などがある。試験が特定版を指定している場合、現在版と用語が違っても問題指定版を優先する。

例えば、タスクを完了できることは有効性の観点、必要な時間や手間が少ないことは利用時の効率性の観点、停止までの時間や復旧の確実性は製品の信頼性に関わる。システム応答時間の短縮と、利用者の作業効率向上は相関することがあっても同義ではない。画面が速くても手順が複雑なら作業効率は悪い。

使用性を増やす施策にも副作用がある

操作ミスを防ぐため確認画面をすべての処理へ追加すると、致命的な誤操作は減るかもしれないが、頻繁に使う画面では効率が低下する。重要度や取り消し可能性によって確認の強さを変える設計が必要だ。使いやすさはボタンの大きさだけではなく、理解しやすさ、学習しやすさ、操作のしやすさ、誤操作からの回復、アクセシビリティなどの組合せで決まる。

アフォーダンスは操作の可能性についての手掛かり、フィードバックは操作結果を把握させる応答、制約は不適切な操作を防ぐ手段となる。これらは認知負荷を減らす。誤入力を赤色で表示するだけでは、色覚の違いがある利用者に情報が伝わらない可能性がある。色と文章・形など複数の手掛かりを用いるべき理由がここにある。

アシュアランスケースは「証拠付きの主張」

安全である、信頼できる、といった主張を文書化するだけでは証拠にならない。アシュアランスケースは主張（Claim）を根拠となる論証（Argument）と証拠（Evidence）によって裏付ける考え方だ。例えば「障害時に危険動作をしない」という主張を「故障検知時に制御出力を安全状態へ遷移させる設計」「故障注入試験の結果」「解析記録」などで支える。

主張と証拠が存在しても、論証のつながりが弱ければ説明は成立しない。単なる品質文書の収集フォルダ、未検証のチェックリスト、プログラムの全行カバレッジをアシュアランスケースそのものと混同してはいけない。出題では「何を導入する目的か」と問われるため、文書形式よりも、納得できる論拠を組み立てる働きを押さえる。

CMMIと成熟度を取り違えない

CMMIはプロセス改善のためのモデル群であり、開発能力の評価や改善に用いられる。成熟度が高いと名乗れば製品の欠陥率が必ずゼロになるわけではない。プロセス領域は要求の開発・管理、技術的解決、検証・妥当性確認などに関連する活動を整理する。試験で版が指定される場合、現行版の名称だけを記憶して旧版の問題を読むと混乱するため、文中の版とプロセスの目的を照合する。

品質モデルを、発生した問題から逆算する

アプリは速く応答するが、新規利用者には操作が分からない。ここで「品質が高い」と一括して評価すると判断を誤る。JIS X 25010:2013の製品品質モデルは、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性の八特性を用いて評価観点を分ける。例えばCPU時間と応答時間は性能効率性、利用者が目標を達成する際の効率や満足は利用時品質という別の観点と関係する。

信頼性の副特性には成熟性、可用性、障害許容性、回復性などがある。障害が起きても機能を保つのが障害許容性、故障・中断後にデータやサービスを回復する性質が回復性だ。ユーザーがエラーから操作をやり直しやすい画面は、同じ「回復」という言葉でも使用性の文脈を含み得る。まず主体がシステムか利用者かを決める。

品質属性は互いに相殺し合う

入力欄を簡略化すれば操作時間は短くなるが、誤入力を防ぐ確認機会が減るかもしれない。暗号化を強化すれば機密性は増すが、鍵管理が複雑になり、処理負荷が増えることがある。全要求について「最高レベル」を選ぶ設計は、予算や応答時間と両立しない。品質要求の衝突を見つけ、どの利用状況を基準として評価するかを決める。

CMMIは製品品質の副特性一覧ではなく、組織のプロセス能力や改善を扱う枠組みである。Common Criteriaは情報技術製品のセキュリティ評価に関係する。名称が似ているからと同じ「品質規格」にまとめると誤る。評価対象が製品の特性か、組織のプロセスか、セキュリティ機能の保証かを確認する。

第11章　テストは何を保証し、何を保証しないか

同じ入力を繰り返しても欠陥は減らない

入力値を1、2、3と順番に増やして試すだけでは、条件の境目に潜む欠陥を見逃す。同値分割は同じ結果が期待される入力群をまとめ、その代表値を選ぶ。境界値分析は区分の端と前後を確認する。年齢が18〜65歳なら17、18、65、66のような値が重要になる。ブラックボックステストはプログラム内部の構造を使わず、仕様からケースを導く考え方である。

一方、ホワイトボックステストでは制御フローや条件に着目する。命令網羅は各命令を少なくとも一度、分岐網羅は各分岐の真と偽を少なくとも一度通す。条件網羅は複合条件の各単純条件が真偽をとること、複合条件網羅は組合せを確認する。分岐網羅を達成しても条件網羅が自動的に達成されるとは限らない。短絡評価や到達不能な組合せにも注意する。

探索的テストは無計画ではない

探索的テストは、対象を調べて学びながら、次にどこを試すかを動的に決める。事前のケースを逐語的に実行するスクリプトテストとは異なるが、目標も観察記録もない場当たり的な操作とは違う。テストチャーターや時間枠を設定して、気付きを次の検証へつなげる。

例えば購買システムで割引とクーポンの併用に違和感があったら、まず同時利用を試し、さらに取消し後にクーポンが戻るか、タイムアウト直後の再送で二重計上されないかを追う。仕様書が想定しなかった振る舞いを発見できるが、探索だけでは繰返し確認の網羅性を保証しにくい。

ミューテーションテスト――テスト集合そのものを試す

テスト対象の演算子や比較式をわずかに変更した多数の変異体（mutant）を作る。元のテスト集合を変異体に適用し、元のプログラムと異なる結果を検出できたら、その変異体は「殺された」と表現する。検出できた変異体の割合は、テスト集合が細かな不具合に敏感かを見る一つの指標となる。

変異体を生成することは「試験用の誤りを埋める」点でエラー埋込み法に似るが、目的が異なる。ミューテーションテストはテストケースの検出能力の評価、エラー埋込み法は潜在する欠陥数の推定に使われることがある。変異体には元と意味が同じ等価ミュータントがあり、単純な生存数をそのままテスト品質の欠陥数へ読み替えられない。

エラー埋込み法を数式で理解する

テスト対象に既知の人工欠陥100件を埋め、そのうち20件を見つけたとする。見つかった自然欠陥が10件なら、人工欠陥の検出率20％を自然欠陥にも仮定し、自然欠陥総数を10÷0.2＝50件と推定できる。見つかっていない自然欠陥は50−10＝40件である。自然欠陥の残存数と自然欠陥の推定総数、埋込んだ欠陥の残りは別物だ。

この推定は人工欠陥と自然欠陥の検出されやすさが十分に近いという仮定に依存する。人工欠陥が極端に見つけやすければ、自然欠陥の残存数を過少に見積もる。2016年と2017年に出題されたが、公式の表と選択肢の配置は年度で異なる。公式を覚えるより、何を推定する式かを理解する方が確実だ。

バグ管理図の曲線の形を読む

テスト時間と累積検出欠陥数を描くと、序盤は発見が増え、成熟につれて傾きが緩やかになる場合がある。ただし欠陥発見数だけで完成を証明できない。そもそもテスト投入量が減った、重大な機能が未着手、修正が別の欠陥を生んだという場合にも曲線は鈍化する。検出数の推移、未解決欠陥、重大度、テスト消化状況を合わせて判断する。

回帰テストと適格性確認

リグレッションテストは修正によって既存の機能が壊れていないかを確かめる。新機能の正常動作確認とは目的が違う。ソフトウェア結合テスト、システムテスト、受入テストは対象レベルと合格基準に違いがある。受入テストが「最後に利用者が実行するテスト」とだけ理解されると、契約上の合意や業務目的への適合という観点が失われる。

テストの網羅率は「何を数えたか」で意味が変わる

次のような条件を考える。if (A && B) { 割引を適用 }。真偽二つの分岐を一度ずつ実行すれば分岐網羅は満たせる。しかしAだけが偽の場合、Bだけが偽の場合を検査したとは限らない。条件網羅は個々の条件が真偽の双方を取ったかに注目する。判定条件網羅やMC/DC（Modified Condition/Decision Coverage）は、条件と判定結果の関係についてさらに要求が異なる。名前に「網羅」が含まれていても、保証している実行の集合は違う。

同値分割は入力空間を同じ振る舞いを期待する区画へまとめる。年齢条件が18歳以上65歳未満なら、無効な低年齢、正常範囲、無効な高年齢などに分けられる。境界値分析は17、18、64、65のような境目を狙う。無数の値を無作為に試すのではなく、仕様の不連続点や誤りやすい境界を探す。分岐網羅が高いから同値分割を不要にできるわけではない。前者はコード内部の構造、後者は仕様に対する入力選択に注目する。

エラー埋込み法は、何を推定しているのか

テスト前に人工的な欠陥を20件埋め込み、テストでそのうち16件と自然に存在していた欠陥40件を見つけたとする。人工欠陥と自然欠陥が同じ確率で検出されるという近似を置くと、自然欠陥総数をNとして 16/20 ≈ 40/N、よって N ≈ 50。まだ見つかっていない自然欠陥は約10件となる。ここで計算したのは潜在欠陥の推計であって、埋め込んだ欠陥の数そのものではない。

この方法は埋め込む欠陥の種類や難度が自然欠陥を代表している、検出確率が比較できる、といった前提に依存する。埋込み欠陥だけが非常に見つけやすければ、自然欠陥の残存量を過小評価する恐れがある。数式だけを暗記すると、条件が変わった問題に弱くなる。

ミューテーションテストとアサーション

ミューテーションテストは、実装に意図的に小さな変更を加え、既存テストがそれを検出できるかを測る。例えば > を >= へ変えた変異体をテストが失敗させられれば、その変異体を「殺した」と数える。変異体が生き残ったときは、テストに不足があるか、実際には動作に影響しない等価変異体なのかを調べる必要がある。変更した後に通常のテストを実行するという意味で、回帰テストと近接するが目的は異なる。

アサーションは、プログラム内で不変条件や前提条件を検査し、違反したら異常を顕在化させる仕組みである。外部利用者による不正入力への正式なエラー処理を、全てアサーションへ置き換えるのは危険だ。アサーションが無効化される実行環境もあり、検査が残る保証は言語や設定に依存する。「テスト技法」「プログラム内の条件検査」「静的解析」を区別する。

第12章　プログラムの正しさを読む――静的解析と形式的な条件

実行しないからこそ見つかる欠陥

静的解析はソースコードや中間表現を実行せずに分析し、未初期化変数、到達不能コード、型やデータフローの異常、脆弱なAPI利用などを検出する。実行時の入力がなくても広い範囲を確認できるが、実行時の環境条件まで完全に再現するわけではなく、偽陽性や偽陰性もあり得る。動的解析は実行中のメモリ操作、性能、競合などを観測する。どちらも「コードをチェックする」だけで同一視してはいけない。

MISRA Cのようなコーディング規約は、特定領域で危険になりやすい記述を抑え、レビューと静的検査の基準を与える。規約遵守は安全性の一条件であって、要求が正しいことやシステムが意図どおり動くことの証明にはならない。

アサーションは推論をコードに刻む

配列を処理するループで「処理済み領域は昇順である」という条件を保つなら、その条件を不変条件（invariant）として推論できる。アサーションは実行の特定時点で成立すべき条件を明示し、違反を検出する。事前条件（precondition）は処理開始前の約束、事後条件（postcondition）は処理終了時の約束、不変条件は一連の状態変化を通じて維持すべき性質を扱う。

アサーションは入力検証そのものとは違う。不正な外部入力は想定される業務事象であり、適切なエラー処理が必要だ。プログラム内部の「ここでは必ず成り立つはず」を検査する用途と区別する。

サイクロマティック複雑度を計算する

McCabeのサイクロマティック複雑度は、単一連結の制御フローグラフでV(G)＝E−N＋2（Eは辺数、Nはノード数）で求める。入口から出口までの独立経路数の目安として使われる。条件分岐が増えると複雑度が増し、必要なテスト設計や理解の負担が高くなりやすい。

例えば、節点Nが9、辺Eが12なら、V＝12−9＋2＝5。単にif文の個数を数えるより確実だ。ただしswitchや論理演算子をどこまで独立条件として数えるかは採用する計測規則に依存する。試験で式が明示されたなら、式と図の数え方を優先する。

参照透過性と宣言的記述の意外な近さ

同じ入力なら同じ出力を返し、副作用を持たない処理は、テストや再計算、並列化に有利だ。純粋関数型プログラミングの参照透過性はその核になる。論理型プログラミングでは「AならB」のような規則と事実から証明・探索を行い、手続そのものではなく成り立つ条件を記述する。

どちらも命令型と違うが、純粋関数と論理推論は同じ技術ではない。純粋関数の数学的な置換可能性と、論理式から答えを導く統一化・探索を正確に分けよう。

複雑度を数える理由は、分岐の数がテストの難しさを増やすから

McCabeの循環的複雑度は制御フローグラフの V(G)=E−N+2P で計算される。ここでEは辺、Nは節点、Pは連結成分数。単一の連結グラフなら E−N+2 となる。典型的な単一出口のコードでは、独立な判定の数に1を加えた値と一致することが多い。if が三つあるから必ず4と機械的に断定するのではなく、ループや複合条件を制御フローとしてどう数えるか確認する。

複雑度が高いほど、そのコードの独立経路を検査する負担が増える傾向がある。ただし、複雑度が低いから業務仕様が正しいわけではない。一本の直線的な処理でも、誤った税率を掛けていれば欠陥である。品質指標と正しさの証明は別物だ。

静的解析、動的解析、形式手法の守備範囲

型検査、未初期化変数の検出、循環依存の分析、コードスタイルの規則検査は、一般にソースコードを実行せずに行える。実行時にだけ現れる競合状態、利用者の操作順序による不具合、特定のデータ量での遅延は動的な観察が必要になる。形式手法では仕様を論理的・数学的に記述し、モデル検査や証明で性質を調べることがある。だからといって形式検証が行われれば外部連携や運用条件の問題まで自動的に消えるわけではない。

例えば assert(balance >= 0) という検査は負残高が起きないよう設計したつもりであっても、並行処理で読み取りと更新が競合すると破られ得る。検査の有無と、排他制御の実装は独立に確認すべきだ。プログラムの正しさは、入力の前提、内部の不変条件、並行実行、外部副作用の境界にまたがっている。

第13章　壊れることを前提にした信頼性設計

故障、障害、欠陥という三つの層

ソフトウェアの欠陥（fault）が特定条件で実行されると異常状態が生じ、外部から見えるサービス障害（failure）につながる。ハードウェアの場合も物理的な故障がシステム停止へ波及するが、部品故障とサービス不能は一致しない。冗長化や縮退運転によって、部品が故障してもサービスが継続することがある。

フェールセーフは障害時に危険を避ける安全な状態へ移す。フェールソフトは性能や機能を落としてでも一部を継続する。フォールトトレランスは構成要素の故障があってもサービスを維持できる性質を目指す。フェールオーバーは主系の障害時に待機系へ切り替える操作だ。互いに近いが、停止させること、縮退させること、切り替えることを混ぜない。

踏切制御は安全が最優先で、センサ異常時には遮断側へ倒す設計があり得る。一方、ECサイトの商品推薦だけが失敗したとき、注文機能まで停止させる必要はないかもしれない。この場合は推薦なしで継続するフェールソフトの発想が有効だ。安全に止まることと、動き続けることは、システムの目的によって選択が逆転する。

FMEAとFTAを逆に覚えない

FMEA（故障モード影響解析）は、部品・機能の故障モードから出発し、その影響と検知手段などを調べるボトムアップの分析である。FTA（故障の木解析）は、システムの望ましくない頂上事象から出発して原因をAND／ORで分解するトップダウンの分析である。

例えば「決済が二重実行された」から原因を遡り、再送と冪等制御不足の組合せを探すのはFTA的な見方。一方「ネットワークタイムアウトが起きる」という故障モードから、その影響が二重決済へ至る可能性を分析するのはFMEA的な見方となる。試験では故障を調べるという共通点だけで選ばず、起点が故障モードか頂上事象かを見る。

MTBF、MTTR、稼働率

修理可能な系の平均故障間隔をMTBF、平均修復時間をMTTRとすると、単純化した定常モデルの稼働率はA＝MTBF／(MTBF＋MTTR)。MTBFが900時間、MTTRが100時間ならA＝900／1000＝0.9、つまり90％だ。停止率は10％。この計算を、MTBF÷MTTRのように扱うと誤る。

MTTFは修理しない部品が故障するまでの平均時間を示す概念で、修理可能系のMTBFとは使い分ける。可用性が99.9％だから、任意の利用者の1リクエストが99.9％成功するという厳密な等価性はない。稼働率の定義、集計期間、部分障害、計画停止を含むかなどが結果を左右する。

直列と並列の信頼性

独立に動く構成要素AとBの両方が必要な直列系では、信頼度がそれぞれ0.9なら、全体は0.9×0.9＝0.81。一方、どちらか一方が稼働すればよい完全な並列冗長系なら、1−(1−0.9)(1−0.9)＝0.99。独立性が前提であり、共有電源や同じ設計欠陥による共通原因故障があれば、この計算は過大評価になる。

部品が二台あるだけで冗長化が成立するわけではない。切替機構、状態同期、監視、障害検知時間、切替後のデータ整合性まで含めた設計が必要だ。

RTOとRPO

RTOは障害後にいつまでにサービスを復旧するかという時間目標、RPOは障害時点に対してどれだけ前までのデータを失うことを許容するかという目標だ。1時間ごとにバックアップがあってもRPOが必ず1時間に保証されるとは限らない。バックアップ完了・整合性・復元手順・オフサイト保持を含めた検証が必要になる。RTOを小さくすると待機系や自動切替などの費用が増えやすい。

可用性と信頼性は時間軸の取り方が異なる

故障の間隔が長い機械と、すぐ復旧できる機械のどちらが使いやすいかは、故障発生の頻度だけでは決まらない。修復可能なシステムの定常可用性を A=MTBF/(MTBF+MTTR) と置くと、平均故障間隔900時間・平均修復時間100時間なら、 A=900/1000=90% である。MTBFは故障から次の故障までの平均間隔、MTTRは修復にかかる平均時間で、可用性の改善には故障を減らすだけでなく復旧を速める道がある。

ただし「900時間」と「100時間」がどの状態間の時間として測定されるか、MTBFの定義と可用性のモデルを確認する必要がある。部品寿命の問題で平均故障時間MTTFが与えられる場合と、修復可能なシステムでMTBFが与えられる場合は同一ではない。試験では式に当てはめる前に、修復の有無と用語の意味を確かめる。

冗長化で改善できるのは単一障害点だけではないが、全てでもない

それぞれ稼働率が0.9の独立した2台を並列に置き、片方が動けばサービス可能と仮定すると全体稼働率は 1−(1−0.9)²=0.99 になる。二台を直列につなぎ、両方の稼働が必要なら 0.9²=0.81。同じ二台でも接続の論理構造で逆の結論になる。さらに切替装置が共通故障点になったり、同じ電源から給電されていたりすれば、独立性の仮定は崩れる。

冗長化とバックアップは目的が違う。前者は障害時にも処理を継続することを狙い、後者は破損・削除・ランサムウェア等からデータを過去の時点へ復元する手段となる。同じ誤削除が両レプリカへ同期されれば、レプリケーションだけでは取り戻せない。

FMEA・FTA・フェールセーフ

FMEAは構成要素ごとの故障モードを起点に、その影響を分析する。FTAは「サービス全停止」などの望ましくないトップ事象から出発し、その原因を論理的に分解する。前者は部品から影響へ、後者は事象から原因へという分析方向が違う。FMEAの重大度・発生度・検出度などを用いた優先付けは、有効な場合があるものの、数値の掛算だけで対策の是非が確定するわけではない。

危険な動作を避けるフェールセーフ、誤操作を起こしにくくするフールプルーフ、障害時も機能や性能を縮退させて使い続けるフェールソフト、故障を許容して所定のサービスを保つフォールトトレラントは、目的から区別する。非常停止する装置はフェールセーフの実例だが、ECサイトの検索機能だけを停止して注文照会を続けるのはフェールソフトの例になる。どちらが「正解」かは危険の種類によって変わる。

第14章　プロセッサは何に時間を使うか

CPIの単位を消せば式は自然に出る

実行時間は命令数 × 平均CPI ÷ クロック周波数で表せる。CPIは一命令当たりのクロックサイクル数であり、1 GHzは1秒に10億サイクル。100万命令、平均CPIが1.5、1 GHzなら150万サイクル÷10億＝0.0015秒＝1.5ミリ秒となる。命令の種類ごとにCPIが異なる場合は、構成比による加重平均を先に計算する。

命令数・CPI・クロック周波数は独立ではない。クロックを速くしてもメモリ待ちが増えれば実行時間は比例して減らない。ある命令セットでの命令数を減らす最適化が、別の命令セットではCPIを増やすこともある。試験では単位の整合を取れば、公式の丸暗記を避けやすい。

パイプラインとスーパースカラ

一つの命令がフェッチ、デコード、実行、書込みを順に通るとき、各工程を重ねれば複数命令を同時進行できる。深さdのパイプライン、ピッチt、命令n個で、停止や競合がない理想状態なら総時間は(d+n−1)t。最初の一件が完成するまでdピッチ、以降は1ピッチずつ完成するからだ。

パイプラインは工程を段階化して重ねるのに対し、スーパースカラは複数の命令発行・実行を同時に進める構造である。両者は併用できる。スーパーパイプラインは段数をさらに細かくする考え方、SIMDは一つの命令で複数データを処理する方式だ。何が同時なのかを区別する。

アムダールの法則が示す「速くできない部分」

処理全体の割合pが並列化可能で、プロセッサ数をnとすると、理想的な速度向上はS＝1／((1−p)+p/n)で表せる。p＝0.8、n＝4ならS＝1／(0.2+0.2)＝2.5倍。プロセッサを無限に増やしても上限は1／(1−p)＝5倍である。並列化できない20％が必ず残るからだ。

プロセッサ数だけ増やすと無制限に速くなる、という直感は誤りである。実際には同期・通信・メモリ帯域・スケジューリングのオーバーヘッドが加わる。試験でオーバーヘッドを無視すると指定されていれば無視して計算し、指定がある場合はモデルに反映する。

Harvard、von Neumann、キャッシュ

ハーバードアーキテクチャは命令用とデータ用の記憶／アクセス経路を分け、同時にアクセスしやすくする。フォン・ノイマン型は命令とデータが同じ記憶空間・経路を共有する基本構造として理解する。実際のCPUには命令キャッシュとデータキャッシュを分離しながら主記憶は共有する構成も多く、単純な二分類ですべてを説明できるわけではない。

キャッシュメモリは、よく使うデータを高速な小容量記憶へ置いて平均アクセス時間を短縮する。ヒット率h、ヒット時のアクセス時間Th、ミス時の追加コストTmなら、モデルに応じてE[T]=Th+(1−h)Tm、あるいはヒット時／ミス時の全所要時間を使うE[T]=hTh+(1−h)Tmissとなる。ミス時にキャッシュを確認した時間を含むかで式が変わる。

ダイレクトマップはキャッシュの格納位置が一意に決まり、フルアソシアティブは任意位置、セットアソシアティブは所属セット内の複数候補に置ける。セットアソシアティブは任意の全ラインへ置けるわけではない。ウェイ数とセット数を区別する。置換方式にはLRUやFIFOなどがあるが、ヒット率の高低はアクセスパターンに依存する。

ページフォールトが平均を支配する

主記憶アクセス300 ns、ページフォールト確率が100万回に1回、フォールト追加コストが200 msなら、追加コストの期待値は0.000001×0.2秒=0.0000002秒=200 ns。通常アクセスの300 nsと同じ桁になる。非常に低頻度の遅い処理が平均を大きく押し上げるという現象がここに現れる。ナノ秒とミリ秒を混ぜたまま計算するのは危険だ。

CPU時間の式を分解して、何が改善するのかを確かめる

CPU実行時間を概念的に 命令数 × CPI ÷ クロック周波数 と書ける。あるプログラムが10億命令、平均CPIが2、周波数が2GHzなら、CPU時間は 10⁹×2/(2×10⁹)=1秒 になる。ただしこの式が表すのはCPU側の実行時間モデルで、ディスクI/O待ちやネットワーク待ちを含む経過時間と完全に一致するわけではない。命令セットが変われば命令数もCPIも変化し、周波数だけの比較は意味を失いやすい。

パイプラインは命令処理を段階に分け、理想的には複数命令の処理段階を重ねてスループットを高める。単一命令のレイテンシが段階数に応じて短くなるとは限らない。スーパースカラは一サイクルで複数命令を発行・実行することを目指す。SIMDは同じ命令を複数データへ適用する方式であり、命令レベル並列性との違いがある。ハーバードアーキテクチャは命令とデータの記憶系や経路を分離する構成に着目する。いずれも「速くする」技術だが、何を並列にしたのかが違う。

アムダールの法則が示す、並列化の冷たい上限

処理の80%を4倍に高速化でき、残る20%が変わらないとする。全体時間は元の 0.2+0.8/4=0.4 倍になるため、速度向上は2.5倍である。高速化した箇所だけの「4倍」を答えにしてはいけない。並列化率p、並列資源数Nに対して S=1/((1−p)+p/N) という形を使う。Nを無限大にしても、p=0.8なら理想上限は5倍で止まる。上限を決めるのは改善しない部分である。

キャッシュの効果はヒット率ではなく平均で見える

L1キャッシュへのアクセス時間が2ns、ミス時に主記憶まで行く追加ペナルティが80ns、ヒット率が90%なら、平均アクセス時間は 2ns+(1−0.9)×80ns=10ns である。ここで「ミス時時間」がペナルティの追加分か総所要時間かを区別する。後者なら 0.9×2+0.1×80=9.8ns のように条件付き平均で計算することになる。数値が同じでも文章の定義で答えが変わる。

直接写像ではブロックが配置される行が決まっており、フルアソシアティブでは任意の行へ置ける。セットアソシアティブはセットを決め、その中の複数の行を選べる中間方式である。置換政策（LRU等）はどのブロックを追い出すか、書込み方式（write-through/write-back）は更新データをどこへいつ反映するかを扱う。写像方式と置換方式を同じカテゴリとみなしてはいけない。

第15章　ストレージ――冗長化、接続、仮想化は別々の課題

RAIDはバックアップではない

RAID 0はストライピングによって複数ディスクの性能や容量を使えるが冗長性はない。RAID 1は同内容を複製するミラーリング、RAID 5は分散パリティにより通常1台のディスク故障へ耐え、RAID 6は二重パリティで通常2台の故障へ耐える。RAID 10はミラーリングとストライピングを組み合わせる。データが人為的に削除された場合、ミラー上でも削除され得るためバックアップの代わりにはならない。

「RAID 1とRAID 5の違いは何によるか」と問われたら、両方とも冗長性を持つという共通性ではなく、同一データのコピーか、冗長情報をパリティとして持つかという違いを見る。必要ディスク数、書込みコスト、容量効率、再構築時のリスクまでつながる。

SAN、NAS、FC

SAN（Storage Area Network）はサーバとブロックストレージを接続する専用ネットワークを中心とした構成であり、ファイバチャネル（FC）などを利用する。NASはネットワーク越しにファイル共有機能を提供する装置・構成で、NFSやSMBなどを用いることが多い。SANを「高速なLANの別名」、NASを「必ず低速なストレージ」とするのは誤りだ。提供するアクセスの粒度と接続技術を分けて理解する。

FCはストレージ接続向けのプロトコル体系であり、光ファイバーでしか実装できないという理解も正確ではない。FCの用語を、インターネット向けのTCP/IPのアプリケーションプロトコルと安易に同列比較してはいけない。

ストレージ仮想化とシンプロビジョニング

シンプロビジョニングでは論理ボリュームへ大きな容量を提示し、物理容量は実際の書込みに応じて割り当てる。初期の無駄を減らせるが、利用率を過信すると物理容量不足で書込み失敗が生じ得る。シックプロビジョニングでは先に物理容量を確保するため、容量の保証が明瞭な一方で未使用領域が残りやすい。

ストレージ仮想化は複数の装置・領域を統合して管理し、利用者から物理的な配置を隠す技術である。シンプロビジョニングは容量割当の一方式であり、ストレージ仮想化の全体を意味しない。

RAIDの番号だけを覚えても可用性は設計できない

RAID 0はストライピングで性能や容量を目的に使えるが、冗長性は持たない。RAID 1はミラーリングで、データを複数ドライブへ複製する。RAID 5は分散パリティを使い、通常は1台のディスク故障に耐えられる。RAID 6は二重パリティで通常2台の故障を許容する。RAID 10はミラーセットをストライピングする。どの方式も、それぞれの許容故障パターンと必要容量が異なる。

例えば容量2TBのディスク4台をRAID 5にしたとき、単純化した利用可能容量はおおよそ (4−1)×2=6TB。RAID 10なら4TB。もっともホットスペア、ファイルシステム管理領域、実際のディスク表記は別に考える。RAID 5のパリティがあるからデータ消失は絶対に起きない、という結論にはならない。再構築中の追加故障、誤操作、コントローラ不具合、論理破損は別の障害である。

SAN・NAS・DASを接続方式から区別する

DAS（Direct Attached Storage）は特定ホストへ直接接続する構成、NAS（Network Attached Storage）はファイル単位の共有を提供する方式、SAN（Storage Area Network）は一般にブロックストレージへの専用または論理的に分離されたネットワーク接続を扱う。SANはFibre Channelだけに限らず、iSCSIのようにIPネットワークを使う構成もある。「LANを使用しているからNAS」「FCだからファイル共有」という短絡は避けたい。

シンプロビジョニングは、論理的なボリューム容量を先に見せ、実データに応じて物理容量を割り当てる方式である。仮想容量を実物理容量より大きく提供できるが、物理容量が枯渇した場合の障害を監視しなければならない。RAIDは冗長化、SANは接続・共有、シンプロビジョニングは容量割当てという異なる層に属する。

第16章　クラウドとコンテナ――似て見える抽象化の層

仮想マシンとコンテナ

仮想マシンはハイパーバイザ上に仮想ハードウェアを作り、それぞれでゲストOSを動かす構成が典型的である。コンテナはホストOSのカーネルを共有しながら、プロセス・名前空間・資源使用などを分離する。VMと同程度の隔離をコンテナが自動的に提供するとは限らず、カーネル共有や権限設定を考慮する必要がある。

コンテナイメージは配布の単位、コンテナは実行の単位、オーケストレーションは多数の実行単位の配置・監視・再起動・スケール・サービス公開などを管理する仕組みである。Kubernetesを「コンテナを作るためのパッケージ形式」と説明する選択肢は層が違う。OCIイメージの形式とクラスタ運用の仕組みは別だ。

容量計画と性能計画

CPU使用率が50％なら、負荷を2倍にしても安全か。待ち行列や共有資源がボトルネックであれば危険だ。キャパシティプランニングはサービス要求を満たすのに必要な資源量を予測・調整し、需要と供給のずれを管理する。平均CPU使用率だけではなく、ピーク負荷、同時実行、メモリ、I/O、ネットワーク帯域、待ち時間、成長率、余裕度を考える。

ピーク負荷時にリソースを追加するスケールアウトは、状態を外部化できないアプリケーションや共有DBが律速する環境では期待どおりに効かない場合がある。スケールアップとスケールアウトを性能上の上下関係として覚えるのではなく、分割可能な処理と共有ボトルネックの有無から判断する。

キャッシュは一貫性の問題を生む

利用者の検索結果をキャッシュすれば読み込みは速くなる。しかし原本が更新されても古い値を返すことがある。TTLによる期限、更新時の無効化、Write-through、Write-back、Cache-asideなどにはそれぞれ遅延・負荷・整合性のトレードオフがある。キャッシュを設けたから可用性が必ず上がるとは限らない。キャッシュが単一障害点になる可能性もある。

ヒット時の時間をTh、ミス時をTm、ヒット率をhとすれば平均＝hTh＋(1−h)Tmであり、平均が既知ならヒット率を逆算できる。ヒット時間がミス時間より長いようにOCRされた場合、そのまま「キャッシュは遅い」と結論しない。図や数値がOCRで崩れた可能性があり、必ず問題冊子の画像を確認する。

クラウド派生データと責任分界

クラウドでは利用者がアップロードしたデータ、サービスを利用するための認証・設定情報、運用過程で生成される派生データやメタデータなど、性質の異なる情報が存在する。誰が生成したか、誰に利用権限があるか、サービス終了時に何を返却・消去するかは別問題である。用語が契約・規格に定義されているときは、その文脈の定義に従う必要がある。

コンテナが軽い理由と、それだけでは消えない責任

仮想マシンは一般に仮想化されたハードウェアの上でゲストOSを動かす。OSレベルのコンテナはホストカーネルを共有し、namespacesやcgroupsなどを利用してプロセス・資源の見え方や使用量を制御する。アプリケーションごとにOSカーネル全体を起動する必要がないため、起動やイメージ配布の面で効率がよい場合がある。ただしカーネル共有による隔離境界、特権コンテナの危険、ホスト依存などの条件を無視できない。

コンテナイメージは配布可能なファイルシステムと実行設定の集合であり、起動中のコンテナとは違う。Dockerfileを用いたビルド、レジストリへの保存、実行時のネットワークや永続ボリュームの指定は別の段階にある。オーケストレーションは多数のコンテナの配置・再起動・サービス公開・設定などを調整する。Kubernetesがアプリケーションの業務トランザクションを自動的に整合させるわけではない。ポッドが再起動しても、途中で外部へ送信した決済がなかったことにはならない。

クラウドはサービス責任の分担モデルとして読む

IaaSは仮想サーバ・ストレージ・ネットワークなどを提供し、利用者がOSやアプリケーションを管理する範囲を比較的広く持つ。PaaSはアプリケーションを動かす実行環境・プラットフォームを提供し、OSの直接管理負担を減らす。SaaSはアプリケーション機能をサービスとして利用する。IaaSとPaaSの境界は製品により異なるし、SaaSだから権限設定やデータ保護について利用者責任がなくなるわけではない。

マイクロサービスもコンテナも、クラウドのサービス区分と独立した概念である。マイクロサービスは業務機能を独立したサービスへ分割するアーキテクチャ、コンテナは実行・配布単位、クラウドは資源やプラットフォームの利用形態。三つをセット商品として覚えると、オンプレミスのマイクロサービスやクラウド上のモノリスを説明できなくなる。

第17章　データモデルは現実の写しではない

実体、属性、関連を分ける

販売管理で「顧客が商品を購入した」を一枚の表にすると、顧客名・住所・商品名・単価を各購入明細で繰り返すことになる。顧客、注文、注文明細、商品を適切に分け、キーで関係付けるのは、重複による更新異常を減らし、情報の意味を保つためである。

ERモデルは実体と関連の構造を記述する。論理データモデルをトップダウンで作る場合は業務概念から実体・関係を洗い出し、ボトムアップでは既存のデータ項目や帳票から正規化して統合していくことがある。トップダウンが必ず良く、ボトムアップが必ず間違うという関係ではない。既存情報の粒度や新規業務の不確実性によって併用する。

候補キーとスーパーキー

キーは行を一意に識別するための属性集合である。スーパーキーは行を一意に識別できる属性集合、候補キーはそこから余分な属性を取り除いた極小のスーパーキー。候補キーが複数ある場合、選んだ一つを主キーとする。他の候補キーは代替キーと呼ばれることがある。候補キーの「候補」はまだ一意性が確認されていないという意味ではない。

例えば社員表で社員番号が一意なら{社員番号}は候補キーで、{社員番号, 氏名}は一意にはなるが社員番号だけで足りるため通常は候補キーでない。複合キーが必要な明細表では、{注文番号, 明細番号}が候補キーになり得る。主キーはNULLを許容しない制約などを伴い、外部キーは他表の候補キー等への参照整合性を担う。

関数従属と正規化

A→BはAの値が定まればBが一意に定まる関係を示す。複合キー(注文番号,商品番号)に対して数量が決まるとしても、商品名が商品番号だけで決まるなら、商品名は複合キーの一部に依存する部分関数従属だ。第二正規形ではこうした部分関数従属を排除する方向で分割する。第三正規形では非キー属性を介した推移的な依存を取り除く。

正規化すると結合処理が増えて性能が落ちる場合もある。そこで非正規化を選ぶことはあるが、冗長データの同期責任を負う。正規化は性能を最大化する万能技術ではなく、整合性と更新時の異常を制御するための論理設計の原則である。

SQLのVIEWはデータのコピーとは限らない

VIEWは基礎表をもとに定義した論理的な表であり、一般的な通常のVIEWは参照時に問い合わせが評価される。マテリアライズドビューは結果を保存する方式で、更新に応じた再計算や反映が課題になる。表結合でレコードが増える場合、COUNT(*)とCOUNT(column)、SUMやNULLの扱いによって結果が変わる。

コード体系もデータ設計の一部だ。順序コードは大小や順番を示し、区分コードは種類を分類し、表意コードは値から意味を推測できるよう設計する。何らかの意味を内包したコードは分かりやすい反面、業務区分が変わると意味の再編や欠番が問題になる。単なる一意識別子とは目的が違う。

候補キーと主キーは同じものの別名ではない

従業員テーブルに社員番号とメールアドレスがあり、どちらも一意で欠けないとする。二つはそれぞれ候補キーになり得る。その中から選んだ主キーが社員番号であれば、メールアドレスは代替キーになる。候補キーには一意性と最小性が必要で、必要以上に属性を加えた集合はスーパーキーではあっても候補キーではない。主キーを先に選んで候補キーを後で列挙するのではなく、候補になり得る識別手段から主キーを選ぶ。

関数従属性 社員番号 → 氏名 は、一つの社員番号に対して氏名が一意に定まる関係を表す。逆方向の 氏名 → 社員番号 が成り立つとは限らない。同姓同名の社員があり得るからだ。第2正規形では非キー属性の候補キーに対する部分関数従属を除き、第3正規形では推移的な従属に起因する更新異常を抑える。ただし形式的な定義と、現場での分割設計の狙いを両方理解する必要がある。

正規化しすぎれば、常に高速になるわけではない

注文テーブルに顧客住所を繰り返し保存すれば、同じ顧客の住所変更を多行へ反映する必要がある。住所を顧客テーブルへ分離すれば重複更新を減らせるが、画面表示時に結合が必要になる。読み取り性能を優先する分析用途では、正規化後のスキーマから意図的に非正規化した参照モデルを作ることもある。正規化は論理的整合性のための基本であり、すべての問い合わせに最速な物理配置を保証する魔法ではない。

ビューは問い合わせを仮想的な表として見せる。一般的なビューは元データを都度参照するが、マテリアライズドビューは結果を実体として保持し、更新の方法が重要になる。ビューがあるだけで全てのDB更新が可能になるわけではない。集計・結合を含むビューの更新可能性はDBMSや定義によって制約される。

第18章　トランザクション――整合性と同時実行のせめぎ合い

完了したことと永続化されたこと

送金処理で口座Aから1万円を引き、口座Bへ1万円を加える。前半だけ成功した状態が利用者へ公開されると資金が消えたように見える。トランザクションの原子性（Atomicity）は一連の操作をすべて実行するか、実行されなかった状態に戻す性質である。一貫性（Consistency）は定められた制約を守ること、隔離性（Isolation）は同時実行処理の干渉を制御すること、永続性（Durability）はコミット済みの結果が障害後も残ることを指す。

ACIDの「Consistency」は、任意の業務上の真実がDBMSによって自動検証されるという意味ではない。参照整合性、チェック制約、アプリケーションの業務ルールなど、何を不変条件として定義するかが重要だ。DBMSが整合性を守る仕組みを提供しても、不正な業務ルールを正しく実装すれば業務としては誤る。

WAL――なぜデータ本体より先にログを確定するか

障害直前に更新したデータページがメモリ上にだけあり、ディスクに書かれていなかったとする。復旧時にどうやってコミット済みの変更を再現するのか。WAL（Write-Ahead Logging）では、更新済みページを永続化するより先に、復旧に必要なログを安定記憶へ書く。一般的なログ先行書込みの規則に従ってコミット記録などを永続化することで、クラッシュ後にREDO／UNDOやリカバリ処理を行える。

「SQLのUPDATEが返った瞬間」と「トランザクションのCOMMITが成功を返した瞬間」、さらに「ログが永続化された瞬間」を混同しない。どの時点で永続性を保証するかはDBMSのログ設定・同期書込み方針に依存する。2016年、2023年にこの論点の出題があり、古典的なロギング問題でもアプリケーションの耐障害性へ直結する。

隔離レベルを上げれば何が減り、何が増えるか

ダーティリードは未コミットデータを読むこと、ノンリピータブルリードは同じ行を読み直したとき他トランザクションの確定更新によって値が変わること、ファントムリードは同じ条件で再検索したとき対象行の集合が変わることである。Serializable（直列化可能）は並行トランザクションの結果が何らかの直列実行と同等であることを要求する。

一般には隔離を強くすると異常な読み取りが抑えられる一方、競合待ちや再試行、検出処理などでスループットに影響が出得る。ただし各DBMSの実装は同じではない。PostgreSQLではRepeatable Readでファントムリードを許さず、Serializableでは直列化失敗に対する再試行が必要になる場合がある。SQL標準が許す現象と、特定DBMSが実際に許す現象は同じ表とは限らない。

「隔離レベルを一段上げると必ずTPSが一定割合減る」のような定量的説明は一般法則ではない。データへのアクセス集中、MVCCの実装、インデックス、ロック粒度、トランザクション長によって影響は変わる。試験では「一般的な傾向」か「必ず成り立つ規則」かを読み分けよう。

ロック、MVCC、楽観・悲観

悲観的ロックでは競合を想定して先にロックを取得する。共有ロックは読み取りの共存を許しつつ更新を妨げる場合が多く、排他ロックは競合する読取り・更新などを制限する。楽観的ロックでは競合が少ないと仮定して、更新時にバージョン番号などを比較して更新衝突を検出する。MVCCはデータの複数バージョンを管理し、読み取りと更新の競合を軽減する仕組みである。

MVCCがあるからロックもデッドロックも存在しなくなる、という解釈は誤りだ。更新競合には行ロックや直列化検査などが絡み、DBMS固有の挙動もある。「読み取りは決して待たない」も過度な一般化である。

デッドロックの待ちグラフ

T1が資源AをロックしBを待ち、T2がBをロックしAを待つ。両方が互いの解放を待てば前に進めない。待ちグラフは、トランザクションをノードにし、待っている側から資源を保持している側へ辺を引く。単一資源インスタンスなど適切な前提では循環がデッドロックを示す。2022年と2024年の出題で、グラフの矢印が「誰が誰を待つか」を取り違えると誤る。

予防策にはロック取得順の統一、トランザクションの短縮、適切なインデックスとロック粒度、タイムアウト・リトライ設計がある。循環を見つけた後に一方をロールバックするのは検出・回復であり、事前に循環を生じさせない予防とは異なる。

Shared Everything／Shared Disk／Shared Nothing

Shared Everythingは複数処理系がメモリやディスクなどを強く共有する構成を指す文脈が多く、Shared Diskは記憶装置を共有しながらCPU・メモリを分ける構成、Shared Nothingは各ノードがCPU・メモリ・ディスクを独立して持つ構成を指す。共有度が高いと一貫性を管理しやすい場合がある一方、共有資源の競合が問題になる。Shared Nothingでは水平スケールを図りやすい反面、データ分散と複数ノード更新の整合性を設計する必要がある。

ACIDの四文字を別々の故障へ対応させる

銀行の振込では口座Aから1万円を減らし、口座Bへ1万円を増やす。一方だけ成功してはいけない。原子性（Atomicity）は一連の操作の全体を成功か失敗として扱う。整合性（Consistency）は事前に定義された制約や不変条件を保つ。独立性・隔離性（Isolation）は並行トランザクションが互いに中途半端な状態を見せないようにする。永続性（Durability）は確定した更新を障害後も失わないことを指す。四つは「DBが正しい」という一語では置き換えられない。

コミット済みと回答した直後に停電しても確定データを取り戻せるようにするには、ログの耐久化や適切なレプリケーションなどの仕組みが必要になる。ログ先行書込み（WAL）では、データページより先に更新を再現できるログ記録を永続化することで、障害後の回復を可能にする。ただし具体的な同期書込み設定やストレージ保証によって耐久性は変化する。単にキャッシュにデータを置いたという事実をコミット完了と同一視できない。

分離レベルの異常現象を物語として読む

トランザクションT1が商品在庫10個を読み、T2が在庫を8個へ変更する。T2がまだコミットしていない値をT1が見て、後からT2がロールバックするなら、T1はダーティリードを経験した。T2がコミットした後、同じ行を再読したT1の値が変わるなら非反復読取りが生じる。T1が条件付きで行集合を検索し、T2が条件に合う行を追加すると次の検索で行数が変わる現象はファントムリードである。

それぞれを単語で暗記するより、「未確定値を読んだか」「同じ行の値が変わったか」「条件に合う行の集合が変わったか」を調べる。SQL標準の隔離レベルが許容する異常は定義されているが、実装はMVCCやロック方式によって詳細が異なる。例えばPostgreSQLのRepeatable Readはスナップショット分離に基づき、標準がそのレベルに許す一部の異常を防ぐ。どのDBMSにも同じロック手順を押し付けて覚えるのは危険だ。

ロックの二つの方向とデッドロック

共有ロックは一般に読取り同士の並行性を高め、排他ロックは競合する更新を守る。悲観的ロックは先に競合を想定して操作を制御し、楽観的同時実行制御は更新時にバージョン等を照合して競合を検出することが多い。MVCCはデータの版を保持することで読取りと書込みの干渉を減らす仕組みであり、「楽観的ロック」と同じ名前の実装ではない。これらは一つのDBMS内で併存し得る。

T1が行AをロックしてBを待ち、T2がBをロックしてAを待てば、待ちグラフに循環ができる。この循環はデッドロックの有力な条件である。競合するロックの取得順を統一する、ロック保持時間を短くする、デッドロック検出後に片方をロールバックする、といった対策がある。ロックを長時間保持しないことは有益だが、デッドロックを理論上必ず防ぐとまでは言えない。

第19章　ネットワークはどの層の話をしているか

Ethernetのスイッチとルータ

家庭やオフィスのネットワークで、同じLAN内のフレームを宛先MACアドレスに基づき転送するのはレイヤ2スイッチの仕事である。ブリッジもレイヤ2でフレームを中継する。ルータは通常IPアドレスに基づく経路選択を行い、レイヤ3の働きが中心となる。機器にルーティング機能が統合されていても、説明されている機能と層を分ける必要がある。

CSMA/CDは従来の共有Ethernetで衝突を検出し再送するための方式であり、一般的なフルデュプレックスのスイッチ接続では衝突ドメインの性質が異なる。スイッチの蓄積転送や速度変換能力を理由にレイヤ3へ分類するのは誤りだ。

RPC、Web API、ソケット

ネットワーク越しの関数呼出しのように遠隔処理を要求するのがRPC（Remote Procedure Call）である。クライアントからサーバへ引数を送り、遠隔で処理し、結果を返す。HTTPやWebブラウザを必須とする概念ではない。ネットワークゲームのサーバ側で着手の妥当性を判定する例なら、独自プロトコルでもRPC型の呼出しを設計できる。

ソケットは通信を行うためのOS上のインタフェース・通信端点を提供し、RPCはそれより高い抽象で処理呼出しを扱う。RESTはリソース指向の設計制約を持つアーキテクチャスタイルであり、単なる遠隔メソッド呼出しの別名ではない。

電話交換機のIP移行

既存のPBX（構内交換機）と電話機、IPネットワークをつなぐ場合、音声の符号化・通信、呼制御、プロトコル変換などの役割を分けて考える。VoIPゲートウェイは従来型の電話インタフェースとIP網の接続に用いられ、IP-PBXはIPネットワーク上で内線・呼制御の機能を提供する。SIPはセッションの確立・変更・終了などの信号制御に用いられることが多く、RTPは音声などのメディアデータ伝送に用いられる。

「IP電話だから音声データもSIPで送る」という混同に注意する。呼制御と音声搬送は別の機能だ。障害時の緊急通報や既存FAXの扱い、QoSも移行設計で考える必要がある。

HTTP 2xx、3xx、4xx、5xx

2xxはリクエストが成功したことを表し、204 No Contentは成功したがレスポンス本文を持たない。3xxはリダイレクトなどで別のアクションを促す。301 Moved Permanentlyと308 Permanent Redirectは恒久的な移動に関わるが、リクエストメソッドの扱いに違いがある。302 Foundと307 Temporary Redirectは一時的な移動、303 See Otherは別のURIをGETなどで取得することを促す場面で使われる。

特に303と204の違いが重要だ。本文がないという性質は共通に見えても、204は新しいURLへ移動する指示ではない。HTTPのLocationヘッダ、メソッドを維持すべきか、レスポンスボディの意味まで見る。4xxはクライアント側に関わる状態、5xxはサーバが要求を処理できない状態を一般に示すが、コードごとの意味は異なる。

TCPのポート、SMTPサブミッション

サーバの443番ポートへブラウザが接続するとき、クライアント側にも通常は一時的な送信元ポートが割り当てられる。送信先443を見て「PC側のポートも443」と判断するのは誤りである。TCP接続は送信元IP・送信元ポート・宛先IP・宛先ポートの組を考える。netstatやOSごとのソケット情報コマンドで接続状況を調べられる。

SMTPの587番はメール投稿（サブミッション）で用いられ、認証や送信者管理と組み合わせて不正な送信を抑える意図がある。25番のサーバ間転送、587番の投稿、465番のTLSを前提とした投稿を混同しない。サブミッションポートを設けることだけでスパムが完全に消えるわけではない。

通信装置は、見ている情報の単位が違う

同じLAN内で宛先MACアドレスに従ってフレームを転送するのがL2スイッチであり、古典的なブリッジもデータリンク層の転送を担う。リピータは物理層の信号を再生・整形し、ルータはIPパケットの宛先アドレスに基づいてネットワーク間の経路選択をする。ゲートウェイは文脈により多義的で、プロトコル変換やアプリケーション間の中継装置などに使われる。同じ「データを届ける装置」という説明では識別できない。

OSIの層で整理する場合も、単語と階層を一対一の暗記表にしすぎない。HTTPはアプリケーション層で意味を持ち、TCPは順序や再送などのトランスポート層の機能を担う。IPはネットワーク間の配送、Ethernetは同一リンクのフレーム転送に関係する。実際の製品は複数層を処理することがあるが、設問が指定した機能の階層を答える。

ネットワークのポートは目的まで覚える

TCP/587は通常、メールクライアントからメール提出サーバへ送信するSMTP Submissionで用いられる。SMTPサーバ間の配送に一般に用いられるTCP/25とは役割が違う。TCP/465はTLSを最初から使用するSubmissionの一形態として使われる。587を「暗号化されたメールそのもの」と覚えるのは不正確で、STARTTLSの有無や認証の要否などはサービス設定に依存する。

SSHは通常TCP/22を使う遠隔シェル・トンネル等のプロトコルで、L2TPはトンネル構築、LDAPはディレクトリ照会、RADIUSは認証・認可・アカウンティングの連携に関係する。LDAPのポート389とLDAPSの636はよく目にするが、ポート番号だけから「その通信は必ず安全」と判断してはいけない。TCPかUDPか、暗号化、認証、アプリケーションの役割を別々に確認する。

HTTPリダイレクトの意味

HTTP 3xx系は要求した資源に対し別の場所や手段を案内する応答群である。ただし301は恒久的な移動、302は一時的な移動、303は別URIへのGETによる参照の指示、307と308は元のHTTPメソッドを維持して再要求させる意味を持つ。設問で「転送先へPOST本文を引き継ぐべきか」を聞かれたら、単に3xxかどうかだけでなく、303と307の違いを見なければならない。

第20章　暗号技術――秘匿、本人性、改ざん検出の役割分担

AESは共通鍵暗号

AESは同じ秘密鍵を暗号化と復号に使う共通鍵暗号方式で、鍵長は128、192、256ビットである。RSAや楕円曲線暗号と同じ「暗号」でも、鍵の構造や典型的な用途が違う。AESの鍵長を「128か256だけ」と決めつけたり、鍵長とブロック長を同一視したりすると誤る。AESのブロック長は128ビットである。

公開鍵暗号は公開鍵で暗号化し秘密鍵で復号する典型的な使い方があるが、デジタル署名では通常秘密鍵側で署名を作り公開鍵側で検証する。暗号化は内容の秘匿、署名は署名者との対応と改ざん検出を目的とする。署名しただけでは文書内容は秘密にならないし、暗号化しただけでは誰が作ったかが証明できない。

ハッシュ関数とMACと署名

暗号学的ハッシュ関数は任意長のデータから固定長の要約を計算し、一般に一方向性や衝突耐性が求められる。パスワード保存には通常の高速ハッシュを一回適用するだけでは不十分で、ソルトと適切なパスワードハッシュ関数が必要になる。HMACのようなMACは共有秘密鍵に基づきメッセージの完全性・認証を提供するが、共有鍵を知る双方が生成できるため、公開鍵署名と同じ意味で第三者へ署名者を証明する仕組みではない。

SHA-256はハッシュ関数、AESは共通鍵暗号、RSAやECDSAは公開鍵暗号・署名に関係するアルゴリズムである。名前の末尾の数字がどれも「強さ」を示すわけではなく、関数の出力長、鍵長、曲線名などの意味が異なる。

PKIの信頼は公開鍵を持つだけでは始まらない

公開鍵だけを受け取っても、攻撃者が差し替えた鍵かもしれない。公開鍵証明書は、主体の識別情報などと公開鍵を認証局（CA）の署名によって結び付ける。証明書チェーンを検証するときは、署名だけでなく、有効期限、用途、ホスト名、失効情報、信頼アンカーなどを確認する。

コード署名用の証明書はソフトウェア発行元を確認する用途に関係する。TLSサーバ証明書は接続先サーバの同一性の検証、クライアント証明書は接続者認証などに使われる。用途を表す拡張情報（Extended Key Usageなど）も重要だ。「証明書なら何でも署名元の保証に使える」と解釈しない。

OCSPとCRL

証明書は期限内でも秘密鍵漏えいや発行誤りなどで失効することがある。CRL（Certificate Revocation List）は失効情報の一覧を配布する方式、OCSP（Online Certificate Status Protocol）は証明書の状態をオンラインで照会する方式だ。OCSPを「証明書を発行するプロトコル」とするのは誤りである。

OCSPでgoodが返ることは「その証明書が無条件に信頼できる」という保証ではない。失効状態の確認と、証明書の主体・用途・署名チェーンの検証は別の段階だ。通信先が証明書検証時の外部通信を必ず許可するとも限らないため、OCSP staplingなど運用上の工夫もある。

TPMとeシール

TPM（Trusted Platform Module）は鍵の安全な保管や測定値、プラットフォームの信頼性確保に関わる機能を提供するハードウェア・セキュリティ基盤である。TPMを持つだけで端末がマルウェア感染しなくなるわけではない。測定起動、封印（sealing）、鍵の利用制御などの機能が何を保証するかを分けて考える。

eシールは電子文書等の発行元組織を示すための電子的な仕組みとして位置付けられ、個人の意思を示す電子署名とは目的が異なる。どちらも改ざん検出の技術基盤を利用し得るが、誰の何を証明するかが違う。2017年以降はコード署名、2022年以降はeシールなど、出題に現れる識別対象が広がっている。

SSOとフェデレーション

複数のWebサービスへ毎回別の認証情報を入れる手間を減らすのがSSO（Single Sign-On）である。IdP（Identity Provider）が認証し、複数のRP（Relying Party）がその結果を利用する構成ではフェデレーション技術が関係する。SAML、OpenID Connect、OAuth 2.0は同じ用途の単純な別名ではない。

OpenID ConnectはOAuth 2.0の仕組みの上に認証情報を伝達する層を追加する。OAuth 2.0そのものはアクセス権限の委譲を中心とした枠組みであり、アクセストークンを受け取れたことだけで利用者のログイン認証を完結したとみなすのは危険だ。SSOの製品・OSS名が選択肢に現れたら、「認証基盤を提供するものか」を区別する。

秘匿・完全性・認証を三つの箱へ分ける

AがBへ機密文書を送る。第三者に内容を読まれないようにするには暗号化が必要だ。内容が書き換えられていないことを確認するにはMACや電子署名などの仕組みが使える。送信元の身元を判断するには、公開鍵・証明書の帰属や認証プロトコルを適切に扱う。三つは近接するが別々の目的を持つ。暗号化したから発信者が保証されたという説明は、追加の仕組みがなければ成り立たない。

共通鍵暗号は暗号化と復号に共通の秘密鍵を用い、AESはその代表例である。AESのブロック長は128ビット、鍵長は128/192/256ビットを選択できる。RSAなどの公開鍵暗号は鍵対を利用する。RSAは暗号化にも署名にも使えるが、鍵の使い方・パディング方式・セキュリティ目的が異なる。ECDSAは電子署名方式であり、AESのようなデータ暗号化方式ではない。鍵長の数値を別技術へ転用すると誤答になる。

電子署名とコード署名、eシールの違い

電子署名は、秘密鍵の正当な保有者が署名したことと署名対象の改ざんの有無を、対応する公開鍵で検証する。コード署名はソフトウェアの配布物へ発行元情報や完全性検査を結び付ける用途を持つ。署名付きコードでも、脆弱性が存在しないと保証するわけではない。eシールは法人等の組織が発行する電子文書について、発行元と文書の完全性を確認する利用が中心となる。個人の意思表示の証明と、組織が出した文書の由来の確認では焦点が異なる。

デジタル証明書は、公開鍵とその主体の情報を結び付ける証明を第三者が署名したものとして扱う。OCSPは証明書の失効状態をオンラインで確認する仕組み、CRLは失効した証明書の一覧を配布する仕組みである。どちらも「証明書を発行する技術」ではない。TPMは鍵の保護・プラットフォーム状態の測定などに活用されるハードウェアベースのセキュリティ機能を提供する。TPMが存在するだけでOS全体が安全になるわけではない。

SSOと認証連携の責任

社内ポータルと社内文書システムでログインを一度で済ませるとする。SSOの実現には、利用者を認証するIDプロバイダ、認証結果を利用するサービス、セッションやトークンの有効期限、認証属性の伝達を設計する必要がある。KeycloakはOpenID ConnectやSAML等による認証連携で利用できるOSSのID管理製品だ。一方、OpenSSLは暗号・TLSのライブラリ／ツール群、BINDはDNSサーバソフトウェア、Logstashはログ収集・加工を担う。全て基盤ソフトウェアでも、SSO基盤の役割を持つものは異なる。

IDトークン、アクセストークン、更新トークンは同じ「認証情報」ではない。IDトークンは認証した主体をクライアントへ伝えるOpenID Connectの概念、アクセストークンはリソースへのアクセス権限を提示するOAuthの概念である。用途の違いを無視して受け渡すと、なりすましや権限誤用につながり得る。2025年の製品識別問題はこの技術的役割への入口として読める。

第21章　Web攻撃を原因から防ぐ

SQLインジェクションは入力値の文字種だけの問題ではない

アプリケーションが文字列を連結してSQL文を作ると、利用者入力がSQLの構造として解釈される可能性がある。攻撃の中心はデータと命令の境界を破ることだ。プレースホルダを使ったパラメータ化クエリは、SQL文の構造と値を分離し、値をコードとして解釈させない。SQLの予約語だけを禁止するブラックリストは回避可能で、十分な対策ではない。

入力値の妥当性確認も重要だが、パラメータ化の代わりにしてはいけない。テーブル名やソート方向など、プレースホルダで置換できないSQL構造要素は、安全な候補からの選択（許可リスト）などで制約する。データベース接続ユーザーへ最小権限を与え、侵害時の影響を限定することも設計上の責務だ。

XSSはブラウザで実行されることが本質

掲示板の投稿に悪意あるスクリプトが保存され、他の閲覧者がページを表示したときに実行されれば格納型XSS。URLパラメータなどをサーバが応答に反映して実行されるなら反射型XSS。クライアント側のDOM操作で不適切に埋め込めばDOM-based XSSとなり得る。すべて「ユーザー入力がHTMLやスクリプトの実行文脈へ混入する」という共通の問題を持つ。

対策は出力先の文脈に応じたエンコーディングが中心になる。HTML本文、属性値、JavaScript文字列、URLは安全化の方法が違う。HTMLにタグを許すなら適切なサニタイズを行う。CSPは追加的な防御層になり得るが、危険な文字列結合を許容するための万能な代替策ではない。単に<script>という文字列を禁止するだけでは回避される。

CSRF、セッション固定、認証と認可

CSRFはログイン済み利用者のブラウザに、本人が意図しない状態変更リクエストを送らせる攻撃である。推測困難なCSRFトークン、SameSite Cookie、Origin／Refererの適切な確認などが対策になる。GETメソッドで状態を変更すれば安全ではない。そもそもGETは安全なメソッドであるべきというHTTPの設計と逆行する。

セッション固定攻撃では、攻撃者が事前に知るセッション識別子を被害者へ使わせ、認証後もその識別子が維持される状況を狙う。認証成功時にセッションIDを再生成するなどの対策がある。セッションハイジャックは利用者のセッションを乗っ取る一般的な脅威であり、固定攻撃はその一類型だ。

認証は本人や主体の確認、認可は許可された操作・データの範囲の判断である。ログインした利用者でも他人の注文情報へアクセスできてはならない。認証と認可を分ける境界は、SSO設計でもWebアプリケーションでも繰り返し現れる。

セキュアOSと強制アクセス制御

一般的な任意アクセス制御（DAC）では所有者などがアクセス権限を設定する。強制アクセス制御（MAC）はシステム全体のポリシーにより主体と客体のアクセスを制限し、ユーザープロセスが任意に解除できない仕組みを指す。セキュアOSの機能として、特権分離・最小権限・強制アクセス制御などが挙げられる。

OSにセキュリティ制御があっても、アプリケーションの論理的な権限チェックやSQLインジェクション対策が不要になるわけではない。攻撃面に応じて層を重ねる理由はここにある。

XSSは「悪い文字が入った」だけでは成立を説明できない

掲示板の投稿に <script> に相当するコードが含まれ、別の利用者が投稿一覧を開いたときブラウザがその文字列をスクリプトとして解釈した。ここで起きているのは、信頼できない文字列がHTMLの実行可能な文脈へ組み込まれたことである。Stored XSSでは攻撃用データがアプリケーション側に保存され、後から別の利用者へ配信される。Reflected XSSでは要求パラメータ等が応答へ反映される。DOM-based XSSではブラウザ側のスクリプトが危険なDOM操作を行う。

対策は「入力から山括弧を削除すればよい」と単純化できない。HTMLテキスト、HTML属性、URL、JavaScript、CSSでは安全な出力処理が異なり、文脈に合ったエンコードやサニタイズ、危険なDOM APIの回避が必要になる。CSPは追加の防御層になり得るが、適切な出力処理を不要にする万能策ではない。試験で攻撃名を当てるときは、誰が、どのデータを、どの解釈器に読み込ませたかを追う。

SQLインジェクションは文字列連結をやめるところから始まる

検索語 x' OR '1'='1 がSQL文へ文字列連結されると、意図しない検索条件の一部として解釈される可能性がある。プリペアドステートメントのバインド変数はSQLの構造とデータ値を分離する。値がどれほどSQL構文に見えても、値として取り扱わせるのが本質だ。特殊文字のブラックリストでは、表現やエスケープの複雑さを完全には処理しにくい。

OSコマンドインジェクションではシェルによる解釈、テンプレートインジェクションではテンプレートエンジンによる式評価、パストラバーサルではファイルパスの正規化とアクセス制御が攻撃面になる。同じ「外部入力が悪い」という説明でまとめず、解釈器と権限を分ける。入力バリデーションは必要であっても、出力文脈の保護や権限分離の代わりにはならない。

CSRFとXSS、認証済みかどうかが逆転する場面

CSRFでは、ブラウザが持つCookie等を利用して、利用者が意図しないリクエストを認証済みのサービスへ送らせる。攻撃者が被害者の認証情報を直接読む必要がない場合がある。CSRFトークンやSameSite Cookie、操作内容に応じた再認証などが防御に役立つ。一方、XSSによって対象サイト上で任意のスクリプトを実行できる状況では、CSRFトークンなどを読み取られるおそれもある。独立した攻撃名を覚えるだけでなく、攻撃者がどの権限・文脈を得たかを追う必要がある。

第22章　ネットワーク防御――何を隠せて何を防げないか

WPA2と鍵の長さを混同しない

WPA2ではAESを基礎とするCCMPが一般的な暗号化・認証方式として用いられる。WEPは古く安全性上の問題があり、WPAで使われたTKIPも現在の強い保護として選ぶべきものではない。WPA2を選んだときに何が使われるかを問う場合、暗号アルゴリズム、鍵管理、認証方式を切り分ける。

WPA2-PersonalのPSKとWPA2-Enterpriseの802.1X/EAPは鍵管理・利用者認証の運用が異なる。AESは共通鍵暗号、802.1Xはネットワークアクセス制御に関わる枠組みであり、同じ分類の選択肢として比べない。

DDoSを一つの巨大なパケットだと思わない

DDoSは多数の送信元やリソースを使い、サービス利用を妨げる攻撃を指す。マルチベクトル型ではネットワーク帯域、プロトコル処理、アプリケーション処理など異なる層の攻撃を組み合わせる。大量のHTTP要求だけを想定して対策すると、DNSやUDPの反射・増幅攻撃へ対応できない場合がある。

オープンリゾルバは不特定の送信元から再帰DNS問い合わせを受け付ける設定のDNSサーバであり、送信元IPを偽装した問い合わせへ大きな応答を返すと、第三者を被害先とするDNSリフレクション／アンプ攻撃に悪用される可能性がある。攻撃者が直接被害者へ大きなデータを送る代わりに、公開DNSサーバが応答を送る点が重要だ。

NAT、NAPT、ファイアウォール

NATはIPアドレスの変換、NAPTはIPアドレスとポート番号を用いる変換で、多数のプライベートアドレスを少数のグローバルアドレスで通信させられる。外部から直接到達しにくくなる副次的な効果はあるが、NAPTが通信内容を検査して攻撃を判定するわけではない。通信の許可・拒否をポリシーに基づいて制御するファイアウォールとは役割が異なる。

「IPアドレスが隠れるから完全な匿名化が成立する」「変換するだけでマルウェア通信を阻止できる」といった説明は過大評価だ。ユーザー認証、アプリケーション上の識別子、通信先ログなどから主体が特定される場合もある。

SSHは遠隔ログインのための安全な経路

SSHは暗号化された通信路を確立し、サーバ認証とユーザー認証を行って安全な遠隔ログインやコマンド実行、トンネリングなどを提供する。Telnetは古典的な平文ログイン方式として知られ、TLSは広く通信の保護に使われるが、SSHと役割は同じではない。

SSHのホスト鍵を検証せずに未知のサーバへ接続すると、通信が暗号化されていても中間者攻撃の危険がある。暗号化と正しい相手の識別は不可分に扱うべきである。

DDoSの目的は突破ではなく、使えなくすること

Webサービスへの大量のTCP接続要求は接続資源を圧迫し得る。DNS増幅攻撃では、送信元IPアドレスを被害者に偽装し、応答が要求より大きくなるようオープンリゾルバ等へ問い合わせて被害者へ大量の応答を流す。送信元偽装を難しくするフィルタリング、オープンリゾルバの適切な制限、上流でのトラフィック処理などが対策となる。

マルチベクトル型DDoSは複数の攻撃手法・プロトコルや層を組み合わせる。単一のIPアドレス遮断やアプリケーション認証だけでは十分でない場合がある。認証された利用者を保護する仕組みと、公開Webサイトが利用不能にならないようにする仕組みは評価する攻撃面が異なる。

ファイアウォール、WAF、IDS/IPSが見るもの

ファイアウォールは主としてIPアドレス・ポート・通信状態などで通信を制御する。WAFはHTTPなどWebアプリケーション向け通信の内容を解析し、攻撃パターンへの対策を行う。IDSは侵入の兆候を検知・通知し、IPSは条件に応じて通信を阻止する機能を持つ。実製品の機能は重なり得るが、いずれかを設置すれば入力処理の脆弱性を修正しなくてよいとはならない。

VPNも混同される。IPsecはネットワーク層でのパケット保護を提供する枠組み、TLSは多くのアプリケーション通信の暗号化・認証に使うプロトコル、L2TPはトンネリングに関係するが、それ自体が強い暗号化を提供するわけではない。IPsecとL2TPを組み合わせる構成がある理由はそこにある。「トンネルがあるから暗号化済み」と判断してはいけない。

フィルタリング・認証・暗号の三つを区別する

通信相手が許可されたネットワークから来ているかを判定するアクセス制御と、利用者本人であることを確かめる認証、通信内容を第三者に読まれにくくする暗号化は別々の要求である。LDAPを使うと組織のユーザー情報を照会しやすくなるが、それだけで全システムのSSOやVPNが完成するわけではない。RADIUSはネットワークアクセスに関する認証・認可・アカウンティング等の連携に使われる。用途の層をずらした説明は午前Ⅱの典型的な混同を生む。

第23章　情報セキュリティの制度・プライバシー・リスク

Privacy by Designは最後の同意画面ではない

個人情報を扱うシステムが完成してから「プライバシーポリシーを表示する」だけでは、不要な属性を保存した設計は直らない。Privacy by Designは企画・要件定義・設計・運用の初期からプライバシー保護を組み込む考え方だ。データ最小化、利用目的の制限、アクセス制御、保持期間、本人の理解や選択のしやすさなどを製品の構造に反映する。

「個人情報を一切収集しないこと」だけがPrivacy by Designの定義ではない。サービス上必要な情報でも目的・期間・アクセスを限定して扱う。スコアリングや推薦のような推論処理では、入力に個人情報がないように見えても、結果から個人の属性が推測される可能性があり、利用目的と透明性を考える必要がある。

ガバナンスとマネジメントの視点

情報セキュリティガバナンスでは、経営陣が組織の方向付け、実施状況の監視、説明責任などを担う。リスクに対応する個々の対策を実施するマネジメント活動とは焦点が違う。JIS Q 27014などで使われる「評価」「指示」「監視」「コミュニケーション」などは、経営層による統治のサイクルで理解する。

「モニタ」は、特定のサーバログを監視するためのソフトウェアだけを意味するわけではない。組織の情報セキュリティ施策が定めた目的へ向かっているかを監督するという、判断主体と対象の階層を見る必要がある。

CRYPTREC、CC、JISECの関係

CRYPTRECは政府機関等で参照する暗号技術の安全性・利用に関する評価や暗号リスト整備に関係する枠組みである。CC（Common Criteria）はIT製品のセキュリティ評価に関する国際的な共通基準であり、ISO/IEC 15408と関係する。JISECは日本のIT製品のセキュリティ評価・認証制度で、CCの考え方を用いて評価・認証する。

CRYPTRECは暗号方式の選定に関する枠組み、CCは評価基準、JISECは国内の評価・認証制度。名前にセキュリティがあるからといって相互に置き換えられない。CCによる認証は、その製品・バージョン・評価対象構成・保証範囲について成立するのであり、全ての環境で絶対安全という意味ではない。

リスクのORとANDを計算する

独立した事象A、Bのどちらかが起きれば損失が生じる場合、P(A∪B)=1−(1−pA)(1−pB)で求められる。一方、両方が同時に必要なら独立性の下でP(A∩B)=pA×pB。対策で事象Aの発生を抑える割合をdAとした場合、対策後の発生確率はpA(1−dA)。対策の検知率と防止率は違う。検知できても発生自体を防げなければ同じ式を使えない。

例えばマルウェア感染40％、外部侵入10％を独立と仮定し、どちらかで漏えいする場合、漏えい確率は1−0.6×0.9＝0.46、46％になる。感染を50％削減すれば感染確率は20％、漏えい確率は1−0.8×0.9＝0.28となる。二つの確率を単純に足してはいけない（重複がある）。選択肢で「独立とする」という条件を見落とすと計算の根拠が崩れる。

リスクの数値を、何を変えたかで読む

ある事故の発生確率が年10%、発生時損害が1,000万円なら、単純化した年間期待損失額は100万円である。対策後に確率が年2%へ下がり、損害額が同じなら期待損失は20万円になる。確率を下げる予防策と、被害額を減らす軽減策は数値上の効果が違う。さらに費用を支払って第三者へ負担を移すリスク移転や、事業上の理由からリスクを受容する判断がある。リスク対応を「ゼロにすること」と同一視しない。

リスクアセスメントでは資産・脅威・脆弱性・影響・可能性などを評価する。被害後の復旧計画と、事前に攻撃機会を減らす予防策は別である。組織が受容するリスク水準を超えているなら、対策の組合せを決めて再評価する。試験問題で「対策後の事象発生確率」を問われたとき、被害金額や検知件数を混ぜない。

セキュリティ評価とガバナンスの仕組みは別の主体がある

ISO/IEC 15408（Common Criteria）はIT製品やシステムのセキュリティ評価基準として知られ、JISECは日本のITセキュリティ評価・認証制度の文脈で登場する。ISMS（ISO/IEC 27001）は組織の情報セキュリティマネジメントを扱う。どちらも「セキュリティの認証」という語が出てくるが、評価の対象が製品・システムの特性か組織の管理体制かを区別する。

JIS Q 27014は情報セキュリティガバナンスの考え方に関係し、CRYPTRECは電子政府推奨暗号リストなど暗号技術の評価・推奨に関係する。PCI DSSは決済カードデータを扱う組織のセキュリティ要件に関係し、FIPS 140系は暗号モジュールのセキュリティ要求を扱う。目的・制度・対象物を識別すれば、規格番号だけの暗記より安定する。

Privacy by Designは、後から規約を足すことではない

サービスへ個人情報を集める前に、取得目的・必要最小限の情報・保存期間・アクセス権限・利用者への説明・削除可能性を設計へ組み込むことがPrivacy by Designの基本的な発想だ。プライバシー通知を長文化して同意ボタンを配置するだけでは、過剰な収集や権限設計の問題を解決できない。監査ログには運用上の価値がある一方、個人情報を含めれば新しい保護対象にもなる。機能と運用の両方で見直す。

第24章　契約と調達――成果物の責任と指揮命令の境界

RFPは「買いたい機能のリスト」以上のもの

提案依頼書（RFP）は、調達を行う組織が供給者へ事業目的、システム化範囲、要求、制約、評価基準、条件などを示す文書である。単なる要望の一覧では、ベンダー間で提案の前提が揃わない。適切なRFPがあれば、提案を価格だけではなく機能・品質・移行・体制・リスクに沿って比較できる。

RFPの内容をすべて確定仕様として縛れば、提案者の知見を活かせなくなる場合もある。必須条件と希望条件、業務上の問題と提案方式を区別して書くことが重要だ。契約時には受入条件と変更管理、知的財産、秘密保持、再委託、データ取扱いなどを明確にする。

請負と準委任と派遣

請負は仕事の完成を目的とする契約であり、成果物や検収が重要になる。準委任は一定の事務・業務の遂行を委ねる契約で、当然に特定成果物の完成を約束するものではない。労働者派遣では派遣先による指揮命令が法的な構成要素になる。現場で誰が直接の業務指示を出しているかは、契約書の名目だけでなく実態を判断するうえでも重要だ。

「時間単価で支払う」ことと「準委任である」ことは必ずしも同義ではない。また、受託者のメンバーを発注者が直接指揮命令するなら、適切な労働者派遣契約でない限り法令上の問題が生じ得る。契約類型を選択肢で見分ける際は、完成責任、報酬算定、指揮命令の三つを別々に確認する。

実費償還型、固定価格、ラボ契約

固定価格型は合意した範囲と価格を基準に仕事を行う。実費償還型では認められた実費や関連する報酬を支払う方式であり、価格の不確実性の負担関係が変わる。ラボ契約は一定のスキル・人数などの開発リソースを継続的に確保し、発注量の約束などによって安定した体制を維持する構造として説明されることが多い。

ラボ契約は、発注者が要員へ直接指揮命令してよいという意味ではない。2025年度の設問は、ラボ契約の特徴を、派遣、成功報酬、作業時間精算のような別モデルと混同させる構造だった。似ている要素があっても「誰が雇用し」「誰が指示し」「何を保証し」「何へ支払うか」で判別する。

ライセンスのグラントバックとロイヤリティ

グラントバック（grant-back）は、許諾された技術などを利用して改良発明・改良技術が生じた場合に、その成果を元の権利者へライセンスするなどの取り決めを指す。特許権を譲り渡すアサインバックとは異なり、グラントバックには一方的なものや相互的なもの、独占・非独占などの条件があり得る。契約条項の競争法上の評価が必要となる場合もある。

ランニングロイヤリティは売上高、製造数量、利用回数など実際の利用実績に基づく継続的な対価を指すことが多い。契約開始時に一括で支払うイニシャルフィーと区別する。売上連動のロイヤリティを、業務委託における実費償還や成功報酬と同じものと誤認しない。

WTO政府調達協定の狙い

政府調達における透明性、公平性、国際的な競争機会の確保などを目的とする国際協定がWTO政府調達協定である。国内のすべての民間調達へ一律に適用されるわけではなく、対象機関・対象調達・基準額などの適用範囲がある。国内企業だけを優先するための制度と考えるのは、趣旨が逆転している。

グリーン購入法と調達仕様

環境物品等の調達促進に関する制度では、調達対象の環境負荷と国等による調達の方針が重要になる。企業の任意の環境宣言と、法令に基づく調達基準の役割は異なる。システム調達でも消費電力、廃棄、再利用、運用時の資源効率を考えることがある。

契約類型の違いは、何を約束したかにある

「新しい販売管理システムを納入し、完成を約束する」という契約と、「月額で専門チームが開発業務を遂行する」という契約では、リスクの配分が異なる。請負は仕事の完成を中心に据える。準委任は一定の業務の遂行を中心に据え、通常、目的物の完成自体を当然に約束するものではない。派遣は派遣先の指揮命令下で労働が行われる点が異なる。ラボ型契約は一定期間、特定規模・スキルの開発体制を確保する実務上の契約・発注形態を指すが、法的な契約類型や個々の労働者への指揮命令関係は別途確認する必要がある。

言い換えれば「チームを確保する」という商流の説明と「誰が作業者に直接指示できるか」という労働者派遣法上の論点は直交する。試験で名称だけを見て指揮命令権の有無まで決めるのは危険である。契約書の成果物・責任・受入条件・仕様変更手続と、実際の作業指示の運用を分けて読む。

料金体系も履行責任とは別軸

固定価格型契約では、定義した範囲の仕事について総額を事前に決める。実費償還型契約では実際に生じた合理的な費用を対象とし、報酬等を加えることがある。時間単価や人月に基づく契約では、工数や利用時間が費用に結びつきやすい。これらの支払方式だけを見て、完成責任・知的財産の帰属・途中解約条件を断定することはできない。

例えば仕様変更が頻繁な場合、固定価格でも変更管理の契約が明確なら運用できるが、合意なき変更は紛争を生みやすい。RFPは供給者へ提案を求める文書、提案書は供給者側が提案する内容であり、見積書と契約書はそれぞれ異なる法的・実務的な位置づけを持つ。「依頼」「提案」「合意」「検収」を混ぜると業務プロセスの問題で失点しやすい。

知的財産――ライセンスと権利譲渡を別物として扱う

ランニングロイヤリティは売上高や使用量などの基準に応じて支払う継続的なライセンス料として登場する。一括払いの固定額ライセンスとは費用の決定式が違う。グラントバックは、技術のライセンスを受けた側が改良した技術等について、元の権利者へ一定の実施権を与える契約条項を指す。ライセンスを受けた時点で改良技術の所有権が当然に移転する、という説明は誤りである。

OSSは無償という意味ではなく、利用・改変・再配布などに関する許諾条件が定められたソフトウェアの一群である。ライセンスの条件によってソースコードの提供義務等が異なる。第三者のコードを利用するときは配布形態と結合方法、著作権表示やライセンス文書の提供を確認する。契約問題で技術名が出たときも、その名称の法的効果まで機械的に決めつけない。

第25章　IT投資と評価――「安くなる」を数式へ変える

ROI、NPV、TCOの違い

投資の妥当性を考えるとき、初期構築費だけを比較すると運用保守・教育・移行・ライセンス・機器更新などのコストが抜ける。TCO（Total Cost of Ownership）は取得から運用・廃棄まで含む総保有費用の考え方である。ROIは投資に対して得られた利益の割合を見る指標、NPVは将来キャッシュフローを割引率で現在価値へ換算し、投資判断に利用する指標である。

費用削減だけでは業務価値を測れない。新規顧客獲得、リードタイム短縮、顧客満足、品質の改善、コンプライアンスリスク低減なども目的になり得る。何を改善する投資かを定義する前にROIだけを計算しても、意思決定に必要な情報は揃わない。

BSC（バランススコアカード）

BSCでは財務、顧客、内部ビジネスプロセス、学習と成長などの視点で戦略目標と指標を結ぶ。内部プロセスのKPIなら、注文処理に要する時間、不良品率、申請承認のリードタイムなどが考えられる。財務視点なら営業利益率やコスト比率、顧客視点なら顧客維持率・満足度などが候補となる。

指標は名前だけで分類できないこともある。「顧客の苦情件数」は顧客視点の成果であると同時に、内部プロセス改善の入口にもなる。設問がどの戦略目的を評価しているかを確認する。因果関係が説明できないKPIを大量に並べても、BSCの価値は小さい。

ABC（活動基準原価計算）

ABC（Activity-Based Costing）は業務活動へ資源コストを配賦し、活動の消費量に応じて製品・サービスへコストを割り当てる。例えば見積作成業務の総人件費が60万円、総作業時間が300時間なら1時間当たり2千円とみなせる。ある製品の見積作成が50時間なら、その業務に対応する配賦額は10万円だ。業務時間を20％削減できるなら、条件が一定なら2万円相当の時間価値を削減できる。

ただし、時間の削減が直ちに実際の給与支払減へ転じるわけではない。試験では費用削減効果を計算するための仮定が与えられるので、その範囲で答える。配賦する総費用と、どの製品がどれだけ活動を使うかを取り違えない。

戦略的投資と効率化投資

同じIT投資でも、業務効率化投資では処理時間短縮やコスト削減が中心になり、情報活用投資では意思決定の迅速化や情報精度が重要になる。戦略的投資では新規事業、差別化、顧客接点の拡大などの成果を見る。戦略的投資に対して「CPU使用率を10％下げた」を主要なKPIとするなら、事業成果との距離が遠い。

システムの利用時間を測るなら技術KPI、顧客が継続利用するなら事業KPIに近い。先行指標と遅行指標を区別し、測りやすさだけで意思決定基準を作らないことが重要だ。

NRE、カークパトリック、顧客体験

NRE（Non-Recurring Engineering/Expense）は製品やシステムのための初期設計・開発など、通常一度限り発生する費用を指す。量産後の一個当たり部品費や継続ライセンス料とは異なる。組込み製品のASIC設計などではNREが大きい場合があるため、量産数量との関係で技術選択が変わる。

カークパトリックの教育効果評価では、Level 1 Reaction（受講者の反応）、Level 2 Learning（知識・技能の獲得）、Level 3 Behavior（行動への転移）、Level 4 Results（組織成果）の順に見る。受講直後の満足度アンケートはLevel 1、理解度テストはLevel 2、業務で実際に使っているかの確認はLevel 3、業務成果への貢献はLevel 4に対応する。「満足したから学習効果が出た」とみなさない。

CEM（Customer Experience Management）は商品を買った瞬間だけでなく、認知・比較・購入・利用・サポートなど顧客接点を通した経験を考える。CRMが顧客との関係や顧客データの管理を扱うのに対して、CEMは顧客の知覚・体験を重視する。両者は併用可能だが同義ではない。

ROI・NPV・回収期間では「よい投資」の意味が変わる

100万円を投じ、翌年に税引前で110万円の効果が出たから「ROIが10%」と答えたくなる。しかしROIの分子に何を置くかは定義が必要だ。投資による純利益を10万円とするなら ROI=10/100=10% だが、売上増分や費用削減を粗く使えば、運用費や減価償却などの扱いで答えが変わる。NPV（正味現在価値）は将来キャッシュフローを割引率で現在価値へ換算して初期投資と比較する。回収期間法は投下資金が何年で戻るかを重視するが、回収後のキャッシュフローを評価しないという弱点がある。

初期投資100万円、1年後50万円、2年後60万円のキャッシュイン、割引率10%なら、 NPV=−100+50/1.1+60/(1.1²)≈−4.96万円。単純合計では110万円で利益が出ているように見えるが、資金の時間価値を考慮するとNPVは負になる。現在価値に割り引くことと、単純に回収できることは違う。試験では割引率や計上年を読み落とさない。

BSCとKPIは企業活動の因果を追う道具

BSC（バランスト・スコアカード）は財務、顧客、内部ビジネスプロセス、学習と成長の四つの視点から戦略を指標へ落とす。研修受講率が改善し、それにより業務の処理品質が上がり、顧客満足を高め、最終的に収益性へ波及するような因果関係を設計する。単に四つの箱へ数値を均等に配置することではない。

内部プロセスの指標として、受注処理時間、作業手戻り率、在庫回転日数などが使える。財務指標には利益率や売上成長、顧客視点には継続率や満足度、学習と成長にはスキル形成や組織能力の指標が対応する。ただし研修回数は活動量であり、効果の証明とは限らない。Kirkpatrickの教育評価の四段階――反応・学習・行動・結果――で見れば、受講者が満足したことと、業務成果が改善したことの距離が明らかになる。

ABC原価計算で「どこに費用がかかるか」を可視化する

活動基準原価計算（ABC）は活動を単位として費用を把握し、その活動を消費する製品やサービスへ配賦する考え方だ。顧客問い合わせ対応の費用を売上高比率だけで配賦すると、問い合わせの多い商品と少ない商品で実際の負担が見えにくい。問い合わせ件数や対応時間などのコストドライバーを用いれば、業務プロセス改善の対象が見える可能性がある。ただしドライバーの選択自体に仮定があるため、精緻化すれば必ず正しい原価になるわけではない。

第26章　組込みシステムは制約が設計を決める

CPUの速さ以外の制約

家電、車載制御、計測機器では、メモリ容量、消費電力、リアルタイム性、起動時間、温度条件、電磁干渉、長期供給、安全性などに制約がある。サーバ用のアプリケーションをそのまま移しても成立しない。例えば動作の確実性が重要な制御系では、平均処理時間が短いことより、最悪実行時間の上限が見積もれることが重要になる。

ハードウェアとソフトウェアのコデザインでは、機能を両者のどちらに実装するか相互に評価し、性能・電力・費用・変更可能性などを最適化する。ハードで高速化できても、回路の変更費用や製造までの時間が増えることがある。逆に汎用CPUへ載せれば変更容易性が得られる代わりに消費電力が増えるかもしれない。

MISRA C、回帰テスト、故障注入

C言語は低水準の制御へ適する一方、未定義動作、配列境界、ポインタ、暗黙変換などの危険がある。MISRA Cは安全性・信頼性を要求される組込みソフトウェアで利用されるコーディングガイドラインの一つだ。コーディング規約と実行テストの役割は異なり、規約を満たしていても要求の欠落やハードとの統合不具合は起こり得る。

回帰テストは、修正によって以前に成立した機能が壊れていないことを確認する。エミュレータ、HIL（Hardware-in-the-Loop）、実機、故障注入などは検証できる対象が違う。安全性が重視される装置ほど、正常系を通しただけで設計を終えてはいけない。

インプロセスDBとLSIの委託先

組込み機器でインプロセスDBを使うと、アプリケーションと同一プロセス内へDBエンジンを組み込めるため、独立DBサーバへの通信やプロセス間通信を減らし、構成を小さくできる場合がある。SQLiteは典型例の一つだ。しかしプロセス分離の利点が減ることや同時アクセス方式の制約も考える必要がある。単に「ネットワークを使わないからSQLが使えない」という理解は誤りだ。

自社でLSIを設計し、製造工程を外部委託する場合、製造設備を持つファウンドリ（foundry）が委託先候補となる。ファブレス企業は通常、半導体の設計などを行い製造を外部へ委託する側を指す。IDM（Integrated Device Manufacturer）は設計・製造などを垂直統合する企業形態を指す。似た横文字でも、設計する側か、製造する側かで判断する。

リアルタイム性は「平均して速い」ではない

車載制御や医療機器では、平均処理時間が短くても、まれに締切を超える処理が許されない場合がある。ハードリアルタイムシステムでは締切違反が許容できない障害につながることがあり、ソフトリアルタイムでは多少の締切超過を性能劣化として扱う場面がある。最悪実行時間（WCET）、割込み応答時間、タスク優先度、ジッターなどの制約を考える。マルチコア化やキャッシュの最適化で平均を改善しても、最悪時間の上限が保証されるとは限らない。

組込みシステムではメモリ容量、消費電力、発熱、量産単価、基板サイズ、保守期間まで設計へ影響する。インプロセスDBはアプリケーションのプロセス内で動作するデータベースエンジンの形態を指すことが多く、別プロセスのDBサーバとの通信や管理が不要になる場合がある。だからといって複数端末からの同時アクセス、障害分離、遠隔バックアップが常に容易になるわけではない。対象機器の制約によって選択が変わる。

MISRA Cとハードウェア・ソフトウェア協調設計

MISRA Cは、C言語を安全性や信頼性が重要な組込み開発で利用するときのコーディング上の制限・指針として知られる。コンパイラが警告しないコードでも、未定義動作に依存したり、処理系差が大きかったりすれば長期運用のリスクになる。一方、MISRA Cへ従ったという事実だけで装置全体の安全性が証明されるわけではない。安全分析・設計・テスト・運用までの証拠が必要になる。

ハードウェア／ソフトウェア協調設計では、機能を専用回路に実装するかソフトウェアで動かすかを性能・コスト・電力・変更容易性などで判断する。高速な信号処理を専用回路へ、変更頻度の高い制御規則をソフトウェアへ、といった分担は一つの例であって固定ルールではない。「組込みだから必ず専用ハードウェア」という選択肢を疑う根拠になる。

第27章　AIとデータ活用――「賢い」の中身を問う

機械学習、深層学習、推論

機械学習はデータから統計的・計算的な規則を獲得して予測や分類などを行う技術群である。深層学習は多層のニューラルネットワークによって複雑な表現を学ぶ方法で、機械学習の一領域である。手続を人が明示するルールベース方式、統計モデル、深層学習モデルは区別されるが、業務システムでは組み合わせることも多い。

分類の精度だけを見て導入すると、データ分布の変化、学習データの偏り、説明可能性、推論遅延、運用費用などが抜ける。モデルが自信を持って出した値と事実が一致することは別だ。初見の問題では、「学習によるパターン獲得」が述べられているか、単純な条件分岐が述べられているかを見分ける。

チューリングテストの問い

対話相手が人間なのか機械なのか、審査者が文章でやりとりして判別できるかを見るのがチューリングテストの代表的な説明である。機械が人間らしい応答を示すかを考える思考実験・評価の枠組みであり、すべての知能能力や安全性を検証する包括的な品質試験ではない。

対話が自然でも知識の正確性、契約上の安全性、個人情報保護は保証されない。試験に登場した「相手が人間か機械かを判定する」という条件を見れば、音声認識の精度テスト、画像認識のベンチマーク、チューリングテストを区別できる。

協調フィルタリングと内容ベース推薦

映画の推薦で、作品のジャンル・出演者・説明文が似ているから薦めるのは内容ベース推薦の考え方だ。一方、「あなたと似た嗜好の利用者が高く評価した作品」を薦めるのは協調フィルタリング（Collaborative Filtering）の典型例である。利用者×商品評価行列から利用者同士またはアイテム同士の近さを求める方法や、潜在因子モデルなどがある。

新規利用者や新規商品に十分な評価履歴がないと、協調フィルタリングはコールドスタート問題に直面する。人気商品へ推薦が偏る、嗜好が近い集団だけで情報が循環するなどの課題もある。「利用者の購買履歴を使う」だけでは協調型と断定できず、誰と誰の関係から薦めたかを確認する。

データサイエンティストの三つの能力

課題を定義して成果へつなぐビジネス力、統計・機械学習などでデータを分析するデータサイエンス力、データの収集・加工・実装・運用を担うデータエンジニアリング力は、相互に関連するが異なる。予測や仮説検定、統計モデルの評価は主にデータサイエンスの領域、パイプラインやデータ基盤の構築はデータエンジニアリングの領域と捉えられる。

分析結果を提出するだけではビジネス上の価値にならない。意思決定や業務改善へ落とす能力が必要であり、試験でも技術を事業価値へ結び付ける文脈が現れる。

MapReduceは二段階の処理モデル

Mapは入力を処理して中間キーと値の組を作る。Shuffle/Sortの段階で同じキーのデータを集め、Reduceがキーごとの集約や加工を行う。大量ログから商品ごとの販売数を集計するなら、Mapで(商品ID, 件数1)を出力し、Reduceで商品IDごとに件数を足す。

MapReduceはDBのSQLやGPUのSIMDと同じ技術ではない。また、どんな計算でも高速化するわけではない。分散処理の通信・同期・再分配のオーバーヘッドがあり、データが小さい場合は単一プロセスの方が速いこともある。設問で中間キーと値、同じキーをまとめるという二段階が出たら、名前がなくてもモデルを特定できる。

AIという言葉だけで、判断方法は特定できない

画像の分類、異常検知、レコメンド、自然言語の生成は、使うデータもモデルも評価方法も違う。教師あり学習では正解ラベル付きの例から入力と出力の関係を学び、教師なし学習ではラベルのないデータから構造を探る。強化学習では環境との相互作用や報酬の観点が中心になる。深層学習は多層のニューラルネットワークを用いる手法であり、すべてのAIを意味するわけではない。

メールを迷惑メールへ分類するベイズ系の手法では、観測した特徴から確率を更新する。ある語を含む確率が迷惑メールと通常メールでどう違うかを扱うのであり、単に禁止語リストに一致したら必ず迷惑メールとする仕組みとは異なる。統計モデルの出力が確率に見えても、それが校正された確率なのか、意思決定の閾値をどこに設定するのかは別途評価する必要がある。

協調フィルタリングの落とし穴

利用者AとBが過去に似た作品を好み、BがまだAの知らない作品Xを高評価したなら、AへXを薦める方式がユーザーベースの協調フィルタリングの例になる。アイテムベースでは、利用者の行動履歴から作品同士の類似性を計算する。一方、コンテンツベースの推薦は作品のジャンル・テキスト・特徴量などを利用する。両者は使う情報の起点が違う。

協調フィルタリングは新規利用者や新規作品で評価履歴が不足するコールドスタート問題、人気の高い作品へ推薦が集中する人気バイアス、似た嗜好ばかり強化される偏りといった課題を持つ。アルゴリズムの名前だけでなく、推薦の根拠を追跡すると、正しい選択肢がどれかを判定しやすい。

MapReduceをキーと値の追跡で理解する

大量の注文ログから商品ごとの売上数量を計算する。Mapで注文を(商品ID, 数量)の組へ変え、Shuffleで同じ商品IDの値を集め、Reduceで数量を合算すれば商品別数量が得られる。重要なのは、Mapの出力が中間キーと値であり、Shuffle/Sortが同じキーの値をまとめ、Reduceが集約・結合などの処理をする点だ。

SQLでもGROUP BYによる集計はできるが、MapReduceは分散処理モデルとして説明され、通信やデータの再配分が必要になる。大量データに適しているからといって、通信量の小さい処理に常に勝つとは限らない。AI処理のフレームワーク、データ処理基盤、業務分析のためのBI製品は同じ「データ活用」でも責務が違う。

第28章　数字に騙されないための計算ドリル

期待値を一枚の式へ戻す

ヒット率、故障率、認証の誤検知率、サービス復旧時間などは確率で表現される。共通するのは、互いに排他的な結果の確率×その結果の値の和を取る考え方だ。キャッシュのヒット時が0.2秒、ミス時が1.2秒、ヒット率が70％なら平均時間は0.7×0.2+0.3×1.2=0.50秒。これを「成功率が高いから平均も0.2秒に近い」と感覚で答えてはいけない。

上限がある関係を見抜く

プロセッサ並列化ではアムダールの法則により、直列部分が残る限り速度向上の上限がある。スループットの上限も、最も容量の小さい工程によって決まる。処理Aが毎秒100件、処理Bが毎秒50件を扱い、直列接続するなら、Aを200件へ高速化しても全体はBによって制約される。

この種の問題の選択肢では、目立つ数字を掛け合わせる誘導が多い。「性能が何倍」「故障率が何％」「処理が何件」は、評価する対象が全体か部分かを明らかにしてから計算する。

単位変換の事故を封じる

1秒は1000ミリ秒、10億ナノ秒に相当する。1 GHzは10億サイクル／秒であり、1サイクルは1ナノ秒だ。200ミリ秒は2億ナノ秒なので、ページフォールト率が100万分の1でも平均へ200ナノ秒相当の寄与を与える。ここで「200ms×10⁻⁶＝200ns」という換算を瞬時に行えることが、問題を落とさないための基礎になる。

メモリ容量はSIのMB（10⁶バイト）と2進のMiB（2²⁰バイト）を区別する。問題文がどちらを採用するかによって計算値が変わる。曖昧な場合は勝手に一方を断定しない。

条件付きの公式を条件なしで使わない

独立な二事象の同時発生は積で計算できるが、独立でない場合はP(A∩B)=P(A)P(B|A)が必要になる。並列系の稼働率が1−(1−A)(1−B)でよいのも、要素の独立性や切替が理想的などの仮定を置いた場合だ。試験文中の「独立」「オーバーヘッドを無視」「各部品は同一」「故障率は一定」のような一文は、計算式を選ぶ鍵である。

数値問題の四手順

問題に数値が並んだら、まず何を求めるかを一語にする（総数、残存数、平均、上限、確率）。次に単位を統一し、イベントが重なり得るか・独立か・処理が直列か並列かを決める。そこで初めて式を立てる。最後に、答えが物理的に妥当か確かめる。ヒット率が上がるほど平均時間が悪化する、冗長化で信頼性が下がるなどの結論が出たら、前提か式を見直す。

計算問題では「何を全体とした割合か」がすべてを決める

キャッシュヒット率90%のときに、ミスの割合は10%である。ここまでは簡単だ。ところがミス時の処理時間80nsが「合計時間」なのか「キャッシュ参照に追加される時間」なのかで、期待値の式は変わる。前者なら0.9×ヒット時間+0.1×ミス総時間。後者ならキャッシュ参照時間+0.1×追加時間。正しい公式を選んでも数値の意味を読み違えれば外れる。

障害率・不良率・偽陽性率も分母が違う。検査陽性者のうち本当に病気である割合は、検査が病気の人を陽性と判定する感度と一致しない。ベイズの定理 P(A|B)=P(B|A)P(A)/P(B) は、条件を「AのもとでB」と読むのか「BのもとでA」と読むのかに注意する。事前確率が低い場合には、検査の特異度が高くても陽性的中率が思ったほど上がらないことがある。

もう一つの計算練習：直列と並列の故障

二つの装置AとBの稼働率がどちらも0.95で、両方必要な直列サービスなら全体稼働率は0.95×0.95=0.9025。片方だけでよい並列サービスなら1−0.05×0.05=0.9975。ただし独立性が前提であり、電源やネットワークを共有する構成なら数字どおりとはならない。

キャッシュでも冗長化でも、独立性や構成条件を先に確定するのが計算の第一歩だ。単位を揃えるのは第二歩。数値から何が妥当かを見積もるのが最後である。平均故障間隔900時間、修復100時間で可用性が99.9%と出たなら、上限や次元を読み違えていないかを見直せるはずだ。

計算式の逆用――選択肢を消す

答えが四つの数値なら、正確に計算する前に物理的な範囲を利用できる。ヒット率が0〜1の確率であれば平均アクセス時間は通常ヒット時とミス時の所要時間の間に収まる。独立な並列冗長化なら各要素の稼働率を下回る答えにはならない。アムダールの法則で高速化されない部分が20%なら改善の理想上限は5倍であり、20倍という選択肢は式を最後まで計算しなくても消せる。これは暗記ではなく、モデルの単調性と上限を理解した結果だ。

第29章　概念を取り違える試験問題の作り方

「本当に正しい文」は、別の問いでは不正解になる

GoFのパターンが生成・構造・振る舞いの三分類をもつのは正しい。一方、LayersやBrokerはPOSAなどで扱うアーキテクチャパターンの例として現れる。GoFを問う設問でLayersを並べた文は、技術的な概念そのものが無意味なのではなく、問われた分類と異なるため不正解になる。

フェールソフトとフェールセーフの対立も同じだ。危険な装置を止める記述はフェールセーフの正しい説明である。しかし「性能が落ちてもサービスを継続する」ことを尋ねた問題ではフェールソフトが対応する。選択肢の真偽ではなく、設問の目的との一致を判断する。

限定詞を疑う

「必ず」「すべて」「唯一」「常に」「だけで」は、規格やアルゴリズムに根拠がない限り警戒が必要だ。例えばRAIDを採用すれば必ずデータを復旧できる、キャッシュを設ければ必ず応答が速い、暗号化すれば送信者を確認できる、という説明はどれも前提を欠く。過度な一般化はよくある誤答構造だ。

ただし絶対表現がいつも誤りというわけでもない。「候補キーはタプルを一意に識別できる」という性質や「AESのブロック長は128ビット」のように定義上の不変事項もある。単に断定文を避けて選ぶ攻略法ではなく、その断定を保証する定義やアルゴリズムの性質があるかを判断する。

「技術の階層」をずらす

ビジネスモデルキャンバスとDFD、IPアドレスの変換とアクセス制御、SMTPサブミッションとメール配送、OCSPと証明書の発行、GoFとPOSA、静的解析と動的テストは、いずれも近い場所で使われるが対象の階層が違う。選択肢が似ているほど、「何のため」「誰が」「どの段階で」「どの単位に」という四つの切り口が効く。

誤答選択肢こそ次の出題候補

ある年の正答でなかった技術が、翌年には別の文脈で正答になることがある。過去問を見て正答記号だけを覚える学習では、この移動に対応できない。選択肢のすべての固有名詞を拾い、「正しい定義は何か」「何の対比として置かれたか」「どういう設問ならその技術が正答になるか」を考えると、問題を一つ解いたときの知識増分は大きくなる。

具体的には、サーキットブレーカーの設問にCQRS、RPC、サービスディスカバリーが並んだら、それぞれを一行で定義できるようにする。CQRSは書込みと読取りモデルの分離、RPCは遠隔手続呼出し、サービスディスカバリーは利用可能なサービスインスタンスの発見を扱う。四つとも分散システムに存在するが、失敗時の呼出し遮断という設問の目的に直接対応するのはサーキットブレーカーである。

正しく読める選択肢ほど危険な理由

「電子署名では秘密鍵を用いる」は文脈によって正しい。しかし設問が「第三者に内容を読まれないようにする方式」を求めているなら、署名は機密性を直接提供しない。「高可用性のためにRAIDを使う」ことが妥当でも、ランサムウェアによるデータの復旧手段を尋ねるならバックアップが必要になる。選択肢を個別に眺めて真偽判定するだけでは、問いへの適合性を見落とす。

選択肢を読むときに用意する三つの枠は、①目的――何を達成するか、②対象――何を操作・測定・保護するか、③時点――事前・実行中・故障時・復旧後のどこか、である。例えばデッドロック防止とデッドロック検出は時点が違う。異常の予防と障害発生後の回復も同じだ。どちらも「障害対策」という語でまとめてしまうと、正答の根拠がぼやける。

誤答の中の技術を、正しい席へ戻す

2024年のサーキットブレーカーの問題でRPC、CQRS、サービス発見のような分散技術が現れたら、知識を四つへ分ける。RPCは遠隔処理を呼び出す、CQRSは参照と更新の責務を分ける、サービス発見は利用可能なインスタンスを探す、ブレーカーは失敗が続く依存先への呼出しを一時停止する。なぜこれらが同じ問題へ並べられるのか。実サービスでは共存するからだ。それでも設問で尋ねられた問題を直接解く機能は一つである。

同じ論理を、契約、セキュリティ、品質、モデリングへ移せる。請負と準委任、暗号化と署名、回復性と使用性、DFDとER図は、近い領域の違う席に座る。人名や略語に気を取られず、技術が果たす仕事を一文で言えれば、未知の四択問題も消去の根拠が明確になる。

第30章　試験前の読書を実力へ変える

丸暗記で抜けない最後の15問を減らす

午前Ⅱは40分で25問に答える。単純平均は1問96秒である。全部を同じ時間で解こうとすると、知らない問題の計算や図の読取りで時間を失う。定義を特定できる問題は速やかに判断し、条件のある計算は式を明記し、図表問題では矢印・多重度・境界の定義を先に固定する。知識問題を解くスピードを上げることが、図表を正確に読む時間を生む。

すぐに選べる問題ほど選択肢の最後まで読む。問われた技術と別技術の正しい説明を取り違える誤答は、時間不足だけでなく反射的なパターン認識からも生じる。一方、手が止まった問題には印を付け、残りを先に見てから戻る。午後に進むには午前Ⅱを通過しなければならないという条件の下では、未知の狭い話題を追うより、頻出の境界と計算を再現できることが重要だ。

一週間の配分例

読めたという感覚よりも、「なぜ似た選択肢は不正解なのか」を説明できることを到達点にする。例えば「フェールソフトは継続し、フェールセーフは安全側」という短い説明に加え、継続させるべき機能、停止させるべき機能、そしてそれぞれの設計根拠を例示できれば、未知の問題にも応用しやすい。

最後に残る一本の軸

要求定義では目的と手段、モデリングでは対象と表現、テストでは仕様適合と業務適合、暗号では秘匿と真正性、契約では完成と遂行、障害対策では安全と継続を切り分けてきた。見かけが似ているものを異なる概念へ分ける判断は、すべてシステムの境界を設計する仕事に通じる。選択肢が迷わせるのは、技術の名前を知らないからだけではない。境界をどこで引くかをまだ決めていないからだ。

最後の一週間で覚えたいのは正答記号ではなく、判定基準だ

25問の四肢択一で合格基準を60%と考えるなら、単純な正答数としては15問相当が境界になる。ただし採点方式や合格判定は必ず公式要綱に従う。安全側に余裕を持つには、既知の定義問題を落とさないことが重要である。過去問の再登場を期待するだけでなく、設問文の主語・対象・目的・時点を見て、選択肢の分類がずれていないかを点検する。

40分で25問なら平均96秒。最初に即答可能な定義問題を確実に処理し、図表・計算へ時間を残す戦略は合理的だ。ただし、マークの見落としや設問番号の取り違えは知識量では防げない。最後に解答欄と問題番号を確認できる時間を残す。CBTでの具体的な操作は、受験案内や練習画面に従って確認する。

読後に残すべき三つの説明

技術名を見たら、三種類の説明を再現できることが望ましい。第一は定義。「サーキットブレーカーは障害の連鎖を防ぐため依存先への呼出しを一時的に遮断する」。第二は境界。「再試行は再び呼ぶ。CQRSは責務を分ける。サービス発見は宛先を探す」。第三は条件。「遮断の閾値、タイムアウト、回復の検査が重要で、ブレーカーだけで冪等性を担保するわけではない」。ここまで理解すれば、設問の文言が変わっても自分の知識から判定できる。

午前Ⅱの後に午後Ⅰと午後Ⅱが控えているなら、この三層の理解は次の試験でも使える。設問を読んで要求を分解する、設計上の判断と根拠を分ける、制約が変われば別案を評価する。その基礎となるのが、午前Ⅱで問われる技術の境界である。