ホワイトハッカーを目指す人が最初に学ぶべきは、攻撃テクニックではありません。法律です。
なぜなら、**ホワイトハッカーとブラックハッカーを分けるのは技術力ではなく「許可」**だからです。同じポートスキャン、同じSQLインジェクションの試行でも、対象が「自分の資産」か「許可された対象」なら正当な業務、そうでなければ犯罪になります。この一線を体に入れないまま手を動かすと、善意の学習が一発で前科になります。
本記事は、日本でホワイトハッカーとして活動するために必要な法律を、公式の一次情報（e-Gov法令検索／警察庁／内閣官房／IPA／JPCERT/CC）に忠実にまとめた“保存版”です。条文の引用だけでなく、**「で、結局どう動けば合法なのか」**まで、実装コード付きで具体的に示します。
これはホワイトハッカーになるには【完全ロードマップ】の法律パートを単独で深掘りするスポークです。
1. 不正アクセス禁止法 — ホワイトハッカーの“地図の外周”
不正アクセス行為の禁止等に関する法律（平成11年法律第128号、通称「不正アクセス禁止法」）が、活動範囲の外周を定義します。警察庁の解説に基づき、禁止行為と罰則を正確に整理します。
| 禁止される行為（条） | 具体例 | 罰則（公式） |
|---|---|---|
| 不正アクセス行為（第3条） | 他人のID/PWでログイン／プログラムの不備を突いてアクセス制御を回避 | 3年以下の拘禁刑 又は 100万円以下の罰金 |
| 識別符号の不正取得（第4条） | 不正アクセス目的で他人のID/PWを取得 | 1年以下の拘禁刑 又は 50万円以下の罰金 |
| 不正アクセスを助長する行為（第5条） | 他人のID/PWを第三者に提供 | 同上（情を知らない場合は罰金） |
| 識別符号の不正保管（第6条） | 不正アクセス目的で他人のID/PWを保管 | 1年以下の拘禁刑 又は 50万円以下の罰金 |
| フィッシング行為（第7条） | 管理者を装い識別符号の入力を求めるサイト等を作る・送る | 1年以下の拘禁刑 又は 50万円以下の罰金 |
最重要のポイント：「アクセス制御を破ること自体」が罪
この法律の核心は、被害の有無を問わない点です。データを見ていなくても、改ざんしていなくても、「本来制限されているコンピュータに、アクセス制御を回避してアクセスした」その瞬間に既遂になります。
- 「無害だと思った」「動作確認のつもり」——通用しません。
- 「ログイン画面が表示されただけ」——画面表示は適法ですが、そこから先（認証回避・総当たり・脆弱性悪用）に踏み込めば違法です。
日本では、この線引きが厳格に運用されます。無許可の対象には、公開されている範囲を普通に閲覧する以上のことをしない——これが絶対のルールです。
2026年時点の最新点： 2025年6月施行の刑法改正で、従来の「懲役・禁錮」は**「拘禁刑」に一本化**されました。古い解説記事は「3年以下の懲役」と書いていますが、現行条文は「拘禁刑」です。条文は必ずe-Gov法令検索で最新版を確認してください。
2. ツールを作る側の法律 — 刑法のウイルス罪
ホワイトハッカーは、診断スクリプトやPoC（概念実証コード）を書きます。ここで関わるのが、刑法の不正指令電磁的記録に関する罪（刑法168条の2・168条の3、通称「ウイルス罪」）です。
ポイントは条文の 「正当な理由がないのに」 という文言です。マルウェアや攻撃コードを正当な理由なく作成・提供・取得・保管する行為が処罰対象になります。
同じ「攻撃コード」でも……
┌─ 許可された診断・教育・研究の文脈で書く → 正当な理由あり → 合法
└─ 文脈を欠いて作成・配布・保管する → 正当な理由なし → ウイルス罪のリスク
つまり、**違法/合法を分けるのは「何を書いたか（コード）」ではなく「なぜ・どこで使うか（文脈）」**です。診断ツールが合法なのは、許可された対象に対して使うという文脈があるから。その文脈を失った瞬間、同じコードが違法になります。自作ツールは安易に不特定多数へ公開しない——これは技術倫理であると同時に、法的リスク管理です。
3. 合法に活動する「3つの安全地帯」
では、どこでなら自由に手を動かせるのか。練習・研究が許されるのは、原則この3つだけです。この“柵”の外に出ない限り、あなたの活動は完全に合法です。
- 自分が管理する資産 — 自分のPC、自分が借りたVPS、自分が作ったアプリ。（→ 環境構築は独学ロードマップ：自宅に合法ラボを作る）
- 意図的に脆弱に作られた学習環境・CTF — OWASP Juice Shop、DVWA、picoCTF、Hack The Box、TryHackMe など「攻撃してよい」と明示された対象。
- 正式なバグバウンティ／脆弱性開示プログラム（VDP）の許可スコープ — 企業が「この範囲なら調べてよい」と公開し、**safe harbor（セーフハーバー）**を提供した対象。（→ バグバウンティの始め方）
安全地帯③の「safe harbor」は、disclose.io のような枠組みで標準化が進んでいます。**「ルールとスコープを守る限り、法的措置を取らない」**という企業側の約束です。逆に言えば、この約束がない／スコープ外の行為は、不正アクセス禁止法の保護を一切受けません。
4. 最新動向：能動的サイバー防御（2025年公布・2026年施行）
2025年、日本のサイバーセキュリティ法制は大きく動きました。「能動的サイバー防御（Active Cyber Defense）」を実現するための新法、通称サイバー対処能力強化法（正式名：重要電子計算機に対する不正な行為による被害の防止に関する法律）等が2025年5月23日に公布され、2026年中に段階施行されます（一次情報は内閣官房 サイバー安全保障・サイバーセキュリティ戦略（令和7年））。
3つの柱があります。
- 官民連携の強化 — 重要インフラ事業者の情報共有・届出義務など。
- 通信情報の利用 — 攻撃の予兆を捉えるための、機械的・限定的な情報の選別（憲法の「通信の秘密」を侵害しないよう厳格に運用）。
- 攻撃サーバーの無害化措置 — 国（警察・自衛隊）が、一定の手続のもとで攻撃インフラを無害化できる。
ホワイトハッカーにとっての含意
「国が攻撃インフラを無害化できる」というのは、裏を返せば社会全体がサイバー攻撃に対して“受け身”から“能動”へ転換したということです。この潮流の中で、
- 個人の無許可ハッキングのリスクは、むしろ上がります。 監視・調査の網は厳格化の方向にあります。
- 一方で、正規のセキュリティ人材への需要は確実に高まります。 企業も国も、守れる人を必要としています。
つまり、いまホワイトハッカーを正しく目指すことは、追い風の中にいるということです。**「合法の側で、確かな実力を持つ人材」**の価値が、制度的に押し上げられています。
5. 脆弱性を発見したら — 正しい「出口」は3つだけ
学習やサービス利用の過程で、本物の脆弱性に気づくことがあります。このときの行動が、ホワイトかどうかを決定づけます。 出口は3つです。
発見した脆弱性は誰のもの？
├─ 自社/自分の資産 → 直す（必要なら本記事のコードで通報窓口も整える）
├─ 他社：バグバウンティ対象 → プラットフォーム経由で報告（HackerOne / Bugcrowd）
└─ 他社：報奨制度なし → 日本の「脆弱性届出制度」へ（IPA受付・JPCERT/CC調整）
絶対にやってはいけないのは、**「勝手に深掘りする」「SNSで暴露する」「相手に直接“脆弱性あります、報酬を”と迫る」**こと。最後は脅迫と受け取られかねません。
日本の正規ルート：脆弱性関連情報の届出制度
報奨プログラムを持たない日本のサービス・製品に脆弱性を見つけたら、国が整備した正規ルートがあります。**情報セキュリティ早期警戒パートナーシップ**です。
- IPA が届出を受け付け、JPCERT/CC が開発者との調整（コーディネーテッド・ディスクロージャ）を担います。
- ソフトウェア製品の脆弱性も、Webサイトの脆弱性も、ここに届け出られます。
- これは“通報”であって“攻撃”ではありません。 発見の経緯が安全地帯内（通常利用の範囲）であることが前提です。深掘り検証は無許可では行いません。
6. 【実装】通報を受ける側になる — security.txt を正しく置く
ホワイトハッカーとして成熟すると、自社サービスの“通報窓口”を整える側にも回ります。その世界標準が、RFC 9116 で定義された security.txt です。https://example.com/.well-known/security.txt に置くことで、善意の報告者が「どこに連絡すればいいか」を機械可読で見つけられます。
通報窓口を明示すること自体が、攻撃者より先に脆弱性を回収する仕組みになります。以下は、Next.js（App Router）の Route Handler で security.txt を型安全・キャッシュ可能・有効期限を自動計算して配信する、本番品質の実装です。
// app/.well-known/security.txt/route.ts
// RFC 9116 準拠の security.txt を配信する Route Handler。
// 設計: 単一の真実源（CONTACT 等）を定数化し、Expires は配信時に未来日付へ自動更新する。
import { NextResponse } from "next/server";
// 連絡先などの“真実源”。環境ごとに変わる値は env 経由で注入し、ハードコードを避ける。
const SECURITY_CONTACT = process.env.SECURITY_CONTACT_URL ?? "mailto:security@example.com";
const CANONICAL = "https://example.com/.well-known/security.txt";
const POLICY = "https://example.com/security-policy";
const PREFERRED_LANGUAGES = "ja, en";
// RFC 9116: Expires は必須。1年以内が推奨。配信時刻から1年後を機械的に算出する。
const oneYearFromNow = (): string => {
const expires = new Date();
expires.setUTCFullYear(expires.getUTCFullYear() + 1);
return expires.toISOString();
};
const buildSecurityTxt = (): string =>
[
`Contact: ${SECURITY_CONTACT}`,
`Expires: ${oneYearFromNow()}`,
`Preferred-Languages: ${PREFERRED_LANGUAGES}`,
`Canonical: ${CANONICAL}`,
`Policy: ${POLICY}`,
"", // 末尾改行
].join("\n");
export function GET(): NextResponse {
return new NextResponse(buildSecurityTxt(), {
status: 200,
headers: {
"Content-Type": "text/plain; charset=utf-8",
// 1日キャッシュ＋再検証。配信のたびに Expires が動くが、内容は安定するため安全。
"Cache-Control": "public, max-age=86400, must-revalidate",
},
});
}
この実装の勘所は、Expires を配信時に未来日付へ自動更新する点です。security.txt は Expires が必須で、切れると無効になります。手書きの固定日付は“期限切れ放置”という典型的な運用事故を生むため、機械が常に未来日付を返す設計にしてあります（冪等・回復性・運用容易性）。
7. よくある誤解（FAQ）
Q. 自分のアカウントで、自分のデータに対してSQLインジェクションを試すのは合法？ A. 対象が自分の管理するアプリ／ローカル環境なら合法です。他社の本番サービスは、たとえ自分のアカウント内でも、サーバ側のアクセス制御を破る行為は違法になり得ます。迷ったら安全地帯①（自分のlab）で再現してから考えます。
Q. 公開されているWebサイトを“見る”のは？ A. 通常の閲覧（ブラウザでの表示、公開APIの仕様どおりの利用）は適法です。違法になるのは、アクセス制御の回避・認証突破・脆弱性の悪用に踏み込んだ瞬間からです。
Q. 海外のサーバーが相手なら日本の法律は関係ない？ A. 危険な誤解です。国内から行えば日本法の適用があり得るうえ、相手国の法律にも触れます。**「どこの誰のものでも、無許可ならやらない」**が唯一安全な指針です。
Q. バグバウンティのスコープ内なら何をしてもいい？ A. いいえ。スコープ内でも、DoS・ソーシャルエンジニアリング・他ユーザーのデータ持ち出しなどは多くのプログラムで禁止です。スコープとルールの“両方”を守って初めて safe harbor が効きます。
8. まとめ — 法律は“制約”ではなく“免許証”
法律を「面倒な制約」と捉えるうちは、ホワイトハッカーになれません。**法律と倫理の境界線を正確に知ることこそ、堂々と技術に没頭できる“免許証”**です。
- アクセス制御を破ること自体が罪（被害の有無を問わない・不正アクセス禁止法）。
- ツールは文脈が線引き（ウイルス罪・「正当な理由」）。
- 活動は3つの安全地帯に限定（自分の資産／CTF／許可スコープ）。
- 発見の出口は“修正と合意”（バグバウンティ／日本の届出制度／security.txt）。無断公表はしない。
この4点を体に入れたら、あとは安心して実力を磨くだけです。手を動かす環境の作り方は独学ロードマップへ、報奨を得る正規ルートはバグバウンティの始め方へ進んでください。
企業の方へ： 能動的サイバー防御の時代、「うちのアプリは大丈夫か」を確かめたいなら、無許可テストを待つのではなく、正規の脆弱性診断・監査で先回りするのが最も安全です。本番リリース前の認可・RLS・テナント分離の確認は、設計を理解した専門家でなければ判定できません。