---
title: "ファジングとは？未知の脆弱性を見つける検査手法【SG試験】"
description: "ファジングは、問題を起こしそうなデータを大量に入力し、ソフトウェアの応答から未知の脆弱性を見つける検査手法です。検疫ネットワーク、ソースコード検査、チェックリスト確認との違いをSG試験向けに整理します。"
last_modified_at: "2026-07-09"
canonical_url: "https://stemtazoo.github.io/sg/fuzzing/"
section: "sg"
---

## まず結論

- **ファジング**とは、ソフトウェアに問題を起こしそうなデータを大量に入力し、その応答や異常終了から未知の脆弱性を見つける検査手法です。
- SG試験では、**「多様な入力データを与える」「応答や挙動を見る」「未知の脆弱性を探す」**の3点で判断します。

## このページで切り分けること（先にここだけ）

このページは、**ファジングと似た脆弱性検査手法の違い**を中心に整理します。

- ファジング：多様な入力データを与えて、応答や異常動作を見る
- ソースコード検査：ソースコードを静的に解析し、危険な書き方を探す
- 検疫ネットワーク：端末の状態を確認し、接続可否を制御する

> 迷ったら、**「ソフトウェアに大量の入力データを与えて挙動を見る話か」**を見ます。
> それならファジングの論点です。

## SG試験で選択肢を切る判断軸（ファジング編）

- 「問題を起こしそうなデータ」「大量に入力」「応答や挙動を監視」
  → ファジング
- 「ソースコードの構文や危険なパターンを機械的に確認」
  → SASTやソースコード脆弱性検査
- 「端末のマルウェア感染やパッチ適用状況を確認して接続許可」
  → 検疫ネットワーク

## 関連記事との役割分担（混同防止）

- 静的解析・動的解析の違いを確認したい → [静的解析と動的解析の違いとは？実行するかどうかで整理【SG試験】](https://stemtazoo.github.io/sg/static-dynamic-analysis/)
- 実行中のWebアプリを外部から検査する話を確認したい → [DASTとは？実行中アプリを外部から検査する手法【SG試験】](https://stemtazoo.github.io/sg/dast/)
- 端末の接続可否を制御する話を確認したい → [検疫ネットワークとは？安全な端末だけ接続を許可する仕組み【SG試験】](https://stemtazoo.github.io/sg/quarantine-network/)

## 直感的な説明

ファジングは、ソフトウェアに対して「普通ではない入力」をたくさん試す検査です。

たとえば、入力欄や通信処理に次のようなデータを与えます。

- とても長い文字列
- 想定外の記号
- 不正な形式のデータ
- 境界値に近いデータ

そして、ソフトウェアが次のような動きをしないかを確認します。

- 異常終了する
- 応答しなくなる
- エラー処理が崩れる
- 想定外の動作をする

つまり、ファジングは**「ソフトウェアに変な入力をたくさん投げて、壊れ方から弱点を見つける」**イメージです。

SG試験では、単なるコード確認ではなく、**実際に入力して、その後の反応を見る**点を押さえます。

## 定義・仕組み

ファジングでは、検査対象のソフトウェアに対して、**ファズ**と呼ばれる問題を引き起こしそうなデータを入力します。

基本の流れは次のとおりです。

1. 検査対象のソフトウェアを用意する
2. ファズと呼ばれる多様な入力データを生成する
3. ソフトウェアに大量に入力する
4. 応答・ログ・異常終了などを監視する
5. 不具合や脆弱性の可能性を調べる

ファジングの目的は、仕様書を読むだけでは気づきにくい、**未知の脆弱性や異常動作を早い段階で見つけること**です。

IPAでも、ファジングはソフトウェア製品の開発ライフサイクルにおいて、脆弱性検出に活用できる検査手法として整理されています。詳しくは、IPAの[脆弱性対策：ファジング](https://www.ipa.go.jp/security/vuln/fuzzing/contents.html)が参考になります。

ただし、ファジングは「すべての脆弱性を見つける万能な方法」ではありません。入力データの作り方、検査範囲、監視方法によって、見つかる脆弱性は変わります。

## どんな場面で使う？

ファジングは、主に**ソフトウェアの開発・テスト・品質保証**の場面で使われます。

たとえば、次のような場面です。

- 製品出荷前に未知の脆弱性を見つけたい
- 入力値処理の不具合を確認したい
- 通信プロトコルやファイル読み込み処理の異常を調べたい
- 外部から入力を受けるソフトウェアの安全性を確認したい

特に、外部からデータを受け取るソフトウェアでは、攻撃者が想定外の入力を送ってくる可能性があります。

そのため、開発側が先に異常な入力を試しておくことで、攻撃に悪用される前に問題を見つけやすくなります。

一方で、ファジングは**ネットワーク接続を許可するかどうかを判定する仕組み**ではありません。

選択肢で「接続しようとする端末の安全状態を確認し、条件を満たした端末だけ接続を許可する」とあれば、ファジングではなく検疫ネットワークの説明です。

## よくある誤解・混同

ファジングは、他の脆弱性対策や検査手法と混同しやすいです。

| 混同しやすい用語 | 判断ポイント |
|---|---|
| ファジング | 多様な入力データをソフトウェアに与え、応答や挙動から脆弱性を見つける |
| 検疫ネットワーク | PCの状態を確認し、条件を満たす端末だけネットワーク接続を許可する |
| ソースコード脆弱性検査ツール | ソースコードを機械的に解析し、危険な書き方やパターンを見つける |
| チェックリストによる脆弱性確認 | 人がチェック項目に沿って設定や実装を確認する |

SG試験では、次のような選択肢に注意します。

- **「ソースコードの構文を機械的にチェックする」**
  → ファジングではなく、静的解析やソースコード検査に近い説明です。

- **「チェックリストに従って人が確認する」**
  → ファジングではなく、点検・レビューの説明です。

- **「接続するPCのマルウェア感染有無を確認する」**
  → ファジングではなく、検疫ネットワークの説明です。

- **「多様なデータを自動生成し、入力後の応答や挙動を見る」**
  → ファジングの説明です。

判断基準はシンプルです。

**入力データを大量に与える → ソフトウェアの挙動を見る → 未知の脆弱性を探す**
この流れなら、ファジングです。

## 確認問題（SG試験対策）

ファジングの説明として最も適切なものはどれか。

- ア. 接続要求を出した端末のマルウェア感染やパッチ適用状況を確認し、条件を満たす端末だけ社内ネットワークへ接続させる。
- イ. ソースコードを実行せずに機械的に解析し、危険な関数やコーディングパターンを検出する。
- ウ. 開発者がチェックリストに沿ってソースコードを読み、設計上の問題や実装漏れを確認する。
- エ. 異常値や境界値など多様なデータを生成して入力し、ソフトウェアの応答や異常終了から脆弱性を探す。

<details markdown="1">
<summary>▶ クリックして答えと解説を見る（ここを開く）</summary>

**正解：エ**

### 解説

- ア：検疫ネットワークの説明です。端末の安全状態を確認して接続可否を制御する話です。
- イ：SASTやソースコード脆弱性検査ツールの説明です。ソースコードを静的に解析しています。
- ウ：チェックリストによるレビューや点検の説明です。大量入力と挙動監視がありません。
- エ：正解です。問題を起こしそうな入力データを与え、応答や異常終了から脆弱性を探すため、ファジングです。

👉 判断ポイント
ファジングは、**入力データ・応答監視・未知の脆弱性**の3点で判断します。

</details>

## まとめ（試験直前用）

- ファジングは、**問題を起こしそうな入力データを大量に与える検査手法**です。
- 目的は、**未知の脆弱性や異常動作を見つけること**です。
- 「ソースコードを読む」「チェックリストで確認する」「端末の接続可否を判定する」はファジングではありません。
- SG試験では、**入力データ・応答監視・未知の脆弱性**の3点で判断します。