設計要件とセキュリティ品質担保

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

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

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

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

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

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

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

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

① 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

① SECURITY

対策の型② 出すものは必ず処理する
入力された文字を、そのまま画面に出すと「命令」として実行されます。
function escXml(s){
return esc(s)
.replace(/[\u0000-\u0008\u000B\u000C\u000E-\u001F]/g, "")

// 制御文字を除去

.replace(/&/g,"&amp;").replace(/</g,"&lt;").replace(/>/g,"&gt;").replace(/"/g,"&quot;");

置換の順序が命です
順序

処理の流れ

結果

✕ & を最後に

「<」→「&lt;」→「&amp;lt;」

画面に &lt; という文字が出る

○ & を最初に

「&」を先に処理 →「<」→「&lt;」

正しく記号として表示される

同じ話がYAMLの引用符処理にも出てきます。「置換は順序が命」。実務で最も多い文字列処理のバグです。

10

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

① SECURITY

対策の型④ 言語の落とし穴を知る
辞書に登録していないのに、値が返ってくることがあります。
✕ 危険な書き方
return EN[key];

// EN["toString"] → 関数が返る
// EN["__proto__"] → 親が返る

○ 安全な書き方
return Object.prototype
.hasOwnProperty.call(EN, key)
? EN[key] : key;

// 自分が持つものだけ返す

何が起きるか
利用者が入力欄に「constructor」と打ち込むだけで、画面に function Object() { [native code] } と表示されます。表示崩れで済む場合もあれば、内部構造を推測され
る手がかりになる場合もあります。

使う言語の「よく知られた落とし穴」は、設計段階で一覧にしておきます。実装者が各自で気づくのを期待しないでください。

12

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

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

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

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

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

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

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

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

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

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

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