SA 論述で合格に届かない6つのパターン|論文300本の添削から分かった減点と書き直し例
「書けているのに受からない」答案には共通点がある
システムアーキテクト試験の科目B-2は、字数を埋めて設問に答えていても、ランクAに届かない答案がたくさんあります。シカクテックでは、これまでにSAの論文を約300本AI添削してきました(2026年11月時点)。評価がBやCにとどまる答案には、同じ種類の指摘が何度も出てきます。
この記事では、そうした答案に共通する6つのパターンを取り上げます。どれも内容の良し悪しというより書き方の抜けなので、知っていれば本番の見直しの時間で直せます。
例文はすべてこの記事のために作った架空の事例で、数字も説明用の例です。
パターン1:方式を書いただけで、比べた案と捨てた理由がない
もっとも多いのがこれです。「何を作ったか」は書いてあるのに、「なぜその方式にしたか」が書かれていません。
❌ 在庫の照会を高速化するため、キャッシュサーバを導入した。
これでは、採点者には設計の判断が見えません。キャッシュ以外の案を考えたのか、キャッシュにすると何を諦めるのかが分からないからです。
⭕ 照会の応答を2秒以内にする必要があった。DBのインデックス追加
だけでは、ピーク時に5秒を超えることを試験で確認した。キャッシュ
を置くと在庫数が最大1分古くなるが、業務部門と確認し、照会画面
では1分の遅れを許容できること、引当の処理だけはDBを直接読むこと
を決めた。そのうえでキャッシュサーバを導入した。
書き直した文には、要件(2秒以内)、比べた案(インデックス追加)、諦めたもの(1分の鮮度)、そのための手当て(引当はDBを直接読む)が入っています。
見直し方:設問イの「〜を採用した」「〜とした」を探し、その前に「ほかに何を比べ、なぜ採らなかったか」が1文以上あるかを確かめます。
パターン2:判定の基準が「多い」「適切に」で止まる
段階公開の判断、負荷試験の合否、再処理するかどうかの判定など、SAの論文には何かを決める基準がよく出てきます。その基準がぼやけていると、「再現できない設計」と読まれます。
❌ 負荷試験で問題がなければ、全店舗に展開することとした。
「問題がない」とは何か、誰が判断するのかが分かりません。
⭕ 先行の3店舗で2週間運用し、ピーク時の応答3秒以内を95%以上、
受付の取りこぼし0件を満たせば、全店舗に展開することとした。
満たさない場合は、原因を直したうえで先行店舗で1週間延長する。
指標を書くときは、分母と分子も明らかにします。「自己解決率」「離脱率」のような割合は、何を分母にするかで値が大きく変わるからです。
見直し方:「多い」「少ない」「適切に」「問題がなければ」「必要に応じて」を検索し、数値か、条件を満たさないときの扱いに置き換えます。
パターン3:正常に動くときのことしか書いていない
連携、バッチ、移行、通知を設計した論文で、異常時の話が抜けている答案はとても多いです。採点者は、システムアーキテクトなら止まったとき・失敗したときを当然考えるはずだと読んでいます。
❌ 受注データは、夜間バッチで物流システムに連携する。
⭕ 受注データは、夜間バッチで物流システムに連携する。1件の不正
データでバッチ全体を止めないよう、エラーの受注は識別番号と理由
を記録して保留し、残りの処理を続ける。保留分は翌朝、担当者が
修正して再送する。再送で二重に出荷しないよう、物流システム側で
受注番号の重複を弾く。
特に抜けやすいのは次の4つです。
- エラーのデータをどう切り分け、どう再処理するか
- 二重登録・二重実行をどう防ぐか
- 通信断・外部サービスの停止のとき、業務をどう続けるか
- 切替や移行が失敗したとき、どこまで戻すか
全部を書く必要はありません。自分の設計で一番起こりそうな異常を1つ選び、具体的に書けば十分です。
パターン4:データの「つなぎ方」が書かれていない
複数のシステムのデータを集める、移行する、画面に出す。こうした論文では、データ同士を何で結び付けるかが書かれていないことがよくあります。
❌ 店舗の売上データとWebの閲覧履歴を組み合わせて分析した。
会員番号で結ぶのか、日付と商品で結ぶのか。会員でない客はどう扱うのか。ここが分からないと、分析の結果を信じてよいかを判断できません。
⭕ 売上データとWebの閲覧履歴は、会員番号で結び付けた。会員番号の
ない売上は分析の対象外とし、全体に占める件数を毎月報告して、
偏りがないかを業務部門と確かめた。
移行の論文なら、事前に移すデータと当日に移すデータの境目、移した後の確認方法と受入れの基準も同じくらい抜けやすい点です。
パターン5:設問イが現状の説明で埋まっている
字数は足りているのに評価が低い答案を読むと、設問イの半分以上が「もともとの仕組みはこうなっていた」という説明になっていることがあります。
設問イで問われているのは、あなたが何を設計したかです。現状の説明は、設計の理由に必要な分だけで足ります。
見直し方:設問イの各段落の主語を確かめます。「現行システムは〜」「A社では〜」で始まる段落が続いていたら、要注意です。「私は〜と判断した」「〜を設計した」が段落の中心になるよう書き直します。
パターン6:設問ア・イ・ウで数字や定義がずれる
120分で書いていると、設問アで「利用者は約2,000人」と書いたのに、設問ウで「3,000人の利用者」と書いてしまうことがあります。指標の定義が設問アと設問イで違っている答案もよく見かけます。
こうしたずれは、内容が良くても「事例が本当にあったのか」と疑われる原因になります。
見直し方:書き終えたら、設問アに出てくる数字と固有の用語(システム名、指標名)を拾い、設問イ・ウで同じ値・同じ言葉で使っているかを確かめます。
提出前の5分で見直すチェックリスト
| 確認すること | 探す言葉 |
|---|---|
| 採用した方式の前に、比べた案と捨てた理由がある | 「採用した」「とした」 |
| 判定の基準が数値か条件になっている | 「適切に」「問題がなければ」「多い」 |
| 異常時の扱いが1つ以上ある | 「エラー」「障害」「失敗」 |
| データを結び付けるキーが書いてある | 「連携」「組み合わせ」「突合」 |
| 設問イの段落の主語が自分になっている | 「私は」 |
| 設問アの数字・用語が設問イ・ウと一致している | 設問アの数字 |
CBTの解答欄には文字数が表示されますが、上限を超えた分は消えてしまいます。見直しで書き足すときは、字数の残りにも気をつけてください。
論文全体の構成やネタの準備については、SA 科目B-2(論述式)の論文設計で詳しく解説しています。
この記事を書いた人
四角くん|シカクテックの中の人
情報処理技術者試験を中心に、IT・ビジネス系資格の学習法や試験対策についてわかりやすく発信しています。実際の受験経験をもとに、効率的な勉強法をお届けします。
受験の記録を X で発信中 @shikakutech取得資格