---
title: 設計要件とセキュリティ品質担保
tags: 
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/2JVVKDZNJQ.jpg?width=480
description: 設計要件とセキュリティ品質担保 by Yukiko
published: August 22, 26
canonical: https://image.docswell.com/s/yukiko_it/K3J412-2026-08-22-222424
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/2JVVKDZNJQ.jpg)

DESIGN / SECURITY / QUALITY
設計の要件と、品質の守り方
セキュリティ対策と品質担保を、設計段階で決める
設計の要件
セキュリティ対策
品質担保
第三者が同じものを作れるか
入力・出力・保存の3つの入口
測れる形にして、機械に確かめさせる
うさうさ研修工房 法人研修教材 ／ 『システム開発の三大要件』の続編


# Page. 2

![Page Image](https://bcdn.docswell.com/page/5EGLQY45JL.jpg)

PURPOSE
この資料のねらい
1
設計で何を決めるべきかが分かる
「作れる形」になっているかを自分で判定できる
2
セキュリティを設計段階で織り込める
後付けが高くつく理由と、4つの対策の型を知る
3
品質を数字で担保できる
テストの4層と、壊しに行く試験の書き方を身につける
実例は、実際に配布されている業務ツール『うさうさLINEスタンプ工房 PRO』の設計と試験から引用します。
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4JQYKMGL7P.jpg)

WHY
設計とは、何をする工程か
決めたこと（要件）を、そのまま作れる形に翻訳する工程。
設計を飛ばすと
設計があると
•
実装者ごとに解釈が違う
•
誰が作っても同じものになる
•
同じ処理が何か所にも散らばる
•
同じ事実が1か所にまとまる
•
直す場所が特定できない
•
壊れた場所が特定できる
•
テストの観点が決まらない
•
テストが先に書ける
設計書は「作る人のため」だけではありません。半年後に直す人、引き継ぐ人、検収する人のために書きます。
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/K74WPV55E1.jpg)

WHAT
基本設計と詳細設計の違い
観点
基本設計（外部設計）
詳細設計（内部設計）
立場
使う人から見た姿を決める
作る人から見た中身を決める
決めること
画面、帳票、操作の流れ、データの持ち方
処理の手順、関数の分割、内部の型
読む人
業務部門・発注者も読む
実装者・保守担当が読む
完了条件
画面1枚で承認が取れている
第三者が同じものを作れる粒度である
対になる検証
結合テスト
単体テスト
境目は「見える／見えない」です。利用者に見えるものは基本設計、見えないものは詳細設計。迷ったらこの線で切ります。
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/LJ1Y93W2EG.jpg)

WHAT
設計で決める6つのこと
構造
1
データ
2
何を単位に分けるか。責務の境界をどこに置くか
何を持ち、何を持たないか。どこを唯一の情報源にするか
画面
処理
3
4
何が見え、何が操作できるか。状態がどう伝わるか
入力から出力までの手順。順序に意味があるならそれも
制約
異常時
5
6
守るべき外部仕様。寸法・形式・禁止事項
想定外の入力が来たとき、どう振る舞うか
6番目の「異常時」が最も忘れられます。正常系だけの設計書は、実装者が各自の判断で穴を埋めることになります。
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GJWGQP6272.jpg)

CRITERIA
設計書が書けているかの判定
第三者が読んで、同じものを作れるか。これだけです。
項目
✕ 作れない書き方
○ 作れる書き方
値の根拠
サイズは適切に決める
370×320px以内（外部仕様）。理由をコメントで残す
順序
割増を計算して合計する
特急30%増を先に、その額に対して譲渡50%増（順序が金額を変える）
異常時
エラー処理を行う
非有限・負値は0に丸める。上限でクランプし、例外は投げない
境界
個数を検証する
8/16/24/32/40のみ許可。0・7・9・41の挙動を明記
「適切に」「必要に応じて」「考慮する」は、設計書では判断の放棄です。読んだ人が迷うなら、まだ設計ではありません。
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4EZLWKY473.jpg)

① SECURITY
セキュリティを、なぜ設計段階で決めるのか
×100
後から足すと、直す範囲が全体に広がるからです。
×30
×10
×1
×3
要件定義
設計
実装
テスト
運用開始後
見つかる工程が遅いほど、修正コストは跳ね上がる（相対値の目安）
設計段階の対策は「どこで防ぐか」を決めるだけ。実装後の対策は、全ての呼び出し箇所を調べ直す作業になります。
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/Y76WGQDG7V.jpg)

① SECURITY
脅威の入口は、3つしかない
入力
出力
保存
利用者・外部から入ってくるところ
画面や文書へ出していくところ
どこかに残すところ
例
例
例
入力欄、URL、ファイル、API応答
HTML、SVG、YAML、Markdown、CSV
ブラウザ保存、ログ、ファイル、通信
この3つに対して「入るものを信じない」「出すものを必ず処理する」「そもそも持たない」を当てはめると、対策の大半が整理できます。
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/G75MVR3X74.jpg)

① SECURITY
対策の型① 入力を信じない
実務のコードは、呼ばれ方を選べません。誰がどんな値を渡すか分からない前提で書きます。
function num(v, max){
var n = Number(v);
何を防いでいるか
•
NaN・Infinity の混入
if(n < 0) n = 0;
•
負の金額・負の個数
var M = (max === undefined) ? 1e12 : max;
•
桁あふれによる計算破綻
•
例外による処理の停止
if(!isFinite(n)) return 0;
return n > M ? M : n;
}
実際に起きたこと
単価欄に 1e400 を入れたところ、Infinity × 0 が NaN になり、見積総額が「¥NaN」と表示されました。エラーは出ません。気づかず送付する事故が理論上あり得まし
た。
どこで防ぐかを決めます。画面／計算関数の入口／出力直前。このツールは計算関数の入口を選びました。テストから直接呼ばれても素通りしないためです。
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/9J293DZQER.jpg)

① SECURITY
対策の型② 出すものは必ず処理する
入力された文字を、そのまま画面に出すと「命令」として実行されます。
function escXml(s){
return esc(s)
.replace(/[\u0000-\u0008\u000B\u000C\u000E-\u001F]/g, "")
// 制御文字を除去
.replace(/&/g,"&").replace(/</g,"<").replace(/>/g,">").replace(/"/g,""");
置換の順序が命です
順序
処理の流れ
結果
✕ & を最後に
「<」→「<」→「<」
画面に < という文字が出る
○ & を最初に
「&」を先に処理 →「<」→「<」
正しく記号として表示される
同じ話がYAMLの引用符処理にも出てきます。「置換は順序が命」。実務で最も多い文字列処理のバグです。
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/DEY412RYJM.jpg)

① SECURITY
対策の型③ そもそも持たない
最も強い対策は、守るべきものを持たないこと。攻撃対象がなければ、守り方を間違えようがありません。
方針
実装
それによって不要になる論点
外部通信ゼロ
fetch・XHR・WebSocket を含めない
通信の暗号化、送信先の検証、情報漏えい経路
保存ゼロ
localStorage・Cookie を使わない
個人情報の保管、保存期間、削除要求への対応
依存ゼロ
外部ライブラリを読み込まない
供給網の脆弱性、バージョン追随、CDN遮断
この方針が合わない案件もあります。多人数の同時編集や大量データが要るなら不向きです。そのときは正直に別の構成を選びます。
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/VJNY28DR78.jpg)

① SECURITY
対策の型④ 言語の落とし穴を知る
辞書に登録していないのに、値が返ってくることがあります。
✕ 危険な書き方
return EN[key];
// EN["toString"] → 関数が返る
// EN["__proto__"] → 親が返る
○ 安全な書き方
return Object.prototype
.hasOwnProperty.call(EN, key)
? EN[key] : key;
// 自分が持つものだけ返す
何が起きるか
利用者が入力欄に「constructor」と打ち込むだけで、画面に function Object() { [native code] } と表示されます。表示崩れで済む場合もあれば、内部構造を推測され
る手がかりになる場合もあります。
使う言語の「よく知られた落とし穴」は、設計段階で一覧にしておきます。実装者が各自で気づくのを期待しないでください。
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/YE9P1KGZJ3.jpg)

① SECURITY
設計段階のセキュリティ確認項目
□ 受け取る値の型と範囲を明記したか
入力
□ 非有限・負値・空・巨大値の扱いを決めたか
□ どこで防ぐか（画面／関数／出力前）を決めたか
□ 画面へ出す値をすべてエスケープする設計か
出力
□ 置換の順序を明記したか
□ ログに秘密情報が出ない設計か
□ 保存するものを最小限にしたか
保存・通信
□ 通信先と目的を明記したか
□ 権限と認証の範囲を決めたか
設計レビューでこの3群を通すだけで、実装後に見つかる指摘がはっきり減ります。
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GE8D4R8YED.jpg)

② QUALITY
品質は、測れる形にしないと守れない
✕ 守れない報告
○ 守れる報告
「実装しました。動いています」
「単体21件、境界値8件すべて合格。
境界値は0・上限・上限+1・負値・空文字を含む」
何をどこまで確かめたかが伝わらない。受け取った側は結局、自分で確かめ直す
ことになります。
確かめた範囲と、確かめていない範囲の両方が伝わります。
測れる形にするための5点
対象
条件
統計値
閾値
測定方法
定義しただけで検証しない品質要件は、存在しないのと同じです。書いたら必ず、確かめる手段まで決めます。
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/LELM6KR97R.jpg)

② QUALITY
品質を担保する4つの層
関数ひとつが正しく動くか
単体
91件
代表値・境界値・異常系・冪等性
組み合わせて意図どおりか
結合
72件
画面と処理、言語切替、状態遷移
全体として成立しているか
総合
28件
全画面の出力、外部通信ゼロ、版の整合
壊しに行っても耐えるか
破壊
37件
注入・巨大値・非有限数・DOM破壊
件数は『うさうさLINEスタンプ工房 PRO v5.7』の実績。合計314件、全件合格を出荷条件にしています。
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4JMY52RVJW.jpg)

② QUALITY
バグは境界に住んでいる
条件の切り替わり目を外すと、実務で最も多い不具合を見逃します。
例：セット個数は 8 / 16 / 24 / 32 / 40 のみ許可する
0
7
8
40
41
下限の外側
ぎりぎり外
ぎりぎり内
上限
上限の外側
異常系で必ず渡す値
種類
渡す値
数値
NaN／Infinity／-0／1e400／負値／全角数字／桁区切りつき文字列
文字
空文字／空白のみ／制御文字／絵文字／結合文字／10万字
型
null／undefined／数値のつもりの文字列／配列／オブジェクト
判定は「正しい値を返すか」ではなく「形の整った答えを返すか」。実務のコードは呼ばれ方を選べません。
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/PJR93MRW79.jpg)

② QUALITY
壊しに行く試験：10の観点
注入
スクリプトタグ、イベント属性
構造破壊
引用符、改行、バッククォート
数値
1e400、NaN、Infinity
文字
制御文字、絵文字、右書き言語
汚染
__proto__、constructor
巨大
10万字の入力
DOM破壊
表示要素を削除して呼ぶ
環境欠落
API未定義、権限拒否
連打
50往復、初期化5回
事後確認
攻撃後に正常動作するか
判定基準は「落ちないこと」ではなく「黙って壊れないこと」。例外で止まるより、金額欄に NaN と出て気づかれないほうが危険です。
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/PEXQ4VRVJX.jpg)

② QUALITY
実際に壊れた3件
すべて通常操作では踏まない経路です。それでも直しました。「起きない」のではなく「起きたときに気づけない」からです。
入れたもの
何が起きたか
どう直したか
制御文字
\u0000 \u0007
プレビューが無言で消えた。エラーも出ない
XMLが許可しない制御文字を除去する処理を追加
1e400
（＝Infinity）
見積総額が「¥NaN」と表示された
非有限・負値・巨大値を安全な範囲に丸める関数を新設
```
（3連バッククォート）
Markdown出力の構造が崩れた
内容に応じてフェンス長を決める2パス方式に変更
見つけたものを全部直すのが正解ではありません。発生確率と影響の大きさで判断します。判断した記録を残せば、それも成果です。
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/3EK9ZQR5ED.jpg)

② QUALITY
品質を、数字で残す
納品物に「何をどこまで確かめたか」を記録します。口頭の約束は半年で消えます。
項目
記録の例
版
v5.7（2026-08-21）。画面3か所と生成物6種が同一の定数を参照
試験
314件 全合格（機能277件＋破壊37件）
試験観点
YAML破壊耐性・XMLパース・XSSエスケープ・プロトタイプ汚染・制御文字・巨大入力・非有限数
アクセシビリティ
キーボード操作可・フォーカス可視・動きの抑制設定に対応
取り扱い
入力データは端末外に送信されない。保存もしない
既知の限界
実ブラウザでの目視確認は未実施。文献の書誌情報は原典照合が必要
最後の「既知の限界」を書くと、資料の信頼が上がります。何でもできると書いてある文書を、私たちは信用しないはずです。
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/L73WDP8175.jpg)

CHECKLIST
設計レビューの確認表
この1枚を印刷して、設計レビューの場に持ち込んでください。
□ 値の根拠がコメントか設計書に残っているか
□ 順序に意味がある処理は、順序が明記されているか
設計
□ 異常時の振る舞いが決まっているか
□ 同じ事実が2か所に書かれていないか
□ 入力の型と範囲、どこで防ぐかを決めたか
セキュリティ
□ 出力のエスケープと置換順序を決めたか
□ 保存・通信するものを最小限にしたか
□ 各要件に対応する試験が決まっているか
□ 境界値と異常系の観点を洗い出したか
品質担保
□ 壊しに行く試験の観点を決めたか
□ 確かめた範囲を数字で記録できるか
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/87DKPLMKJG.jpg)

EXERCISE
演習：自分の設計を点検する
個人ワーク
15分
自分の担当機能について、入力・出力・保存の3つの入口を洗い出す。それぞれ「何を受け取り、何を出し、何を残すか」を書く。
個人ワーク
15分
入力の1つを選び、渡されうる異常値を10個書き出す。数値・文字・型の3種類から偏りなく選ぶ。
個人ワーク
15分
その異常値に対して、どう振る舞うべきかを決める。「例外を投げる／0に丸める／既定値を使う」のどれかと、その理由を書く。
相互レビュー
15分
隣の人と交換し、抜けている異常値を1つ以上見つける。見つからなければ「網羅できている」と伝える。
3番目が本番です。「例外を投げる」と「静かに丸める」のどちらが親切かは、場面によって変わります。理由まで書けたら合格です。
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/VJPKN2R3E8.jpg)

SUMMARY
まとめ
設計
第三者が読んで同じものを作れるか。曖昧語は判断の放棄
セキュリティ
入口は入力・出力・保存の3つ。設計段階で「どこで防ぐか」を決める
品質担保
測れる形にして、機械に確かめさせる。単体・結合・総合・破壊の4層
記録
確かめた範囲と、既知の限界を数字で残す
落ちるより、黙って壊れるほうが怖い。
面白きこともなき世を面白く
うさうさ研修工房
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/2EVVKDRNEQ.jpg)

REFERENCE
参考文献・出典
独立行政法人情報処理推進機構（IPA）
1
『安全なウェブサイトの作り方』／『非機能要求グレード2018』
ISO/IEC 25010
2
Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality models
OWASP Foundation
3
Application Security Verification Standard (ASVS)
うさうさ研修工房
4
『うさうさLINEスタンプ工房 PRO v5.7』詳細設計書・試験スイート（本資料の実例の出典）
本資料は上記の公的標準・公式ドキュメントを基に編集した学習教材です。書誌情報と最新版は各発行元の公式サイトでご確認ください。
23