脆弱性診断エンジニアのフリーランスがつまずきやすい点と対策

フリーランスの脆弱性診断エンジニアがつまずきやすいのは、許可の範囲が口頭の依頼で広がること、本番のシステムに影響を出すこと、重大な発見の連絡が遅れること、見積りの前提が崩れたまま作業を続けることです。どれも、会社員のときは営業や管理の担当者、社内のレビューが受け止めていた部分を、外部の立場で一人で抱えることから起きます。

対策の基本は、つまずきの種を作業前の取り決めで小さくしておき、作業中は記録と早めの連絡で守ることです。この記事では、契約・現場・技術・お金の順に、診断の仕事ならではの場面と対策を整理します。許可をめぐる法律の考え方は脆弱性診断エンジニアがフリーランスになるにはで扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

口頭の追加依頼で、診断の範囲が広がる

診断の途中で「このサーバーも見てほしい」「ついでに管理画面も」と頼まれることがあります。相手に悪気はなくても、許可の書面にない対象に手を出すと、自分の作業が許可の範囲内だったと示せなくなります。

対策：範囲を広げる依頼は、対象・期間・手法を書面やメールで取り決め直してから作業します。間に診断の事業者や開発会社が入る場合は、その会社が対象のアクセス管理者から得た許可の範囲に、追加の対象が入っているかも確かめます。業務範囲が変わったときの進め方は業務範囲が変わったときの記事をご覧ください。

見積りの前提が崩れても、そのまま作業を続ける

診断一式を請け負う形では、画面や機能の数、APIの数、テスト用アカウントの種類から見積もります。始めてみると機能が聞いていたより多い、権限の種類が増えていた、という食い違いはよく起きます。

対策：前提にした数と、対象外のものを契約や見積書に書いておき、ずれに気づいた時点で発注元に知らせます。黙って範囲を削ると品質の問題になり、黙って増やすと報酬に反映されません。再診断を何回まで含むかも、最初に決めておきます。

診断事故の責任の範囲を読まずに署名する

診断で本番のシステムに負荷をかけた、データを登録・変更してしまった、といった場面で、どこまでの賠償を負うかは契約の書き方で変わります。

対策：署名の前に、損害賠償の条項に上限があるか、故意・重過失の場合とそれ以外で扱いが分かれているかを読みます。考え方は損害賠償の上限の記事、備えは賠償責任保険の記事で扱っています。判断に迷う場合は弁護士などの専門家にご相談ください。

現場でのつまずき

診断の環境がそろっていない

開始日になっても、テスト用アカウントが発行されていない、診断元のIPアドレスが許可されていない、検証環境が本番と違う版になっている、ということがあります。待っている間も日程は進み、最後の数日に作業が詰まります。

対策：開始前に、アカウント、診断元の許可、対象の版、緊急時の連絡先がそろっているかを一覧にして確かめます。そろわない場合は、日程をずらすか範囲を見直すかを発注元に早めに相談します。最初の1か月の動き方は脆弱性診断エンジニアの参画初月にやることで整理しています。

本番のシステムに影響を出す

自動の診断ツールで大量の通信を送る、問い合わせフォームから試験用のメールを大量に送ってしまう、登録の処理を繰り返して本番のデータを増やす、といった影響は、診断の手法そのものから起きます。

対策：本番を診断する場合は、通信の速さの上限、触ってはいけない機能（決済、メール送信、外部連携）、作業の時間帯を事前に取り決めます。影響が出た、あるいは出たかもしれないと思った時点で作業を止め、決めておいた連絡先にすぐ知らせます。

重大な発見の連絡が報告書まで遅れる

認証を回避できる、他人の個人情報が見える、といった重大な不備を見つけても、報告書の提出まで黙っていると、その間も攻撃される危険が残ります。

対策：「重大な不備は報告書を待たずに速報する」という扱いと、その連絡先・手段を作業前に決めておきます。速報には、対象、再現の要点、影響の見立てを短くまとめ、詳細は報告書で補います。

診断データを手元に残しすぎる

診断の記録や画面の写し、取得した情報には、発注元の機密や個人情報が含まれます。案件が終わった後も端末に残しておくと、紛失や漏えいのもとになります。

対策：データの保管場所、持ち出しの可否、案件終了後の消去の方法を、NDAや契約の取り決めに沿って決めておきます。案件ごとに保管場所を分けておくと、消去の漏れを防げます。

技術でのつまずき

ツールの結果を確かめずに報告する

自動の診断ツールは、誤検知も見落としも出します。結果をそのまま報告書に載せると、開発者が直す必要のない項目に時間を使い、報告書全体の信頼も下がります。

対策：ツールが出した項目は、手で再現を取ってから報告します。逆に、ツールが拾えない権限の不備や業務の手順の飛ばし方は、仕様を読んで手で確かめる観点として別に持っておきます。

重大度の根拠が弱い

「危険度：高」とだけ書き、なぜ高いのかが説明されていない報告書は、開発者や発注元の判断に使いにくくなります。参画先の基準と自分の感覚がずれていると、報告書の中で判定がそろわないこともあります。

対策：参画先が使う評価の基準を最初に確かめ、それに沿って根拠を書きます。共通の評価の方法としては、FIRSTが公開しているCVSSがあり、2026年10月時点では v4.0 の仕様が公開されています。どの版と方法を使うかは参画先の決まりに合わせてください。

直し方の提案が実装と合わない

一般的な対策を書くだけでは、使っている言語やフレームワークの事情に合わず、開発者が動けないことがあります。

対策：対象の構成を事前に聞いておき、直し方は「どこで、何を確かめるか」が分かる粒度で書きます。分からない部分は、開発者に確かめたうえで書くほうが、報告書の質が上がります。求められる技術の中身は脆弱性診断エンジニアのスキルの記事にまとめています。

お金でのつまずき

夜間・休日の作業が精算されない

本番の診断で夜間や休日の作業が続いても、月額の契約に含まれる扱いになっていると、稼働が増えた分が報酬に反映されません。

対策：時間外の作業が月額に含まれるのか、別に精算するのか、精算幅を超えたときにどうなるのかを契約の前に確かめます。考え方は精算幅の記事をご覧ください。

繁忙期の後に空白ができる

診断の依頼はシステムの公開前などに集まりやすく、忙しい時期が終わると次の案件まで間が空くことがあります。

対策：契約終了の時期が見えたら、早めに次の案件の相談を始めます。生活費の数か月分を手元に置き、ツールのライセンスの更新時期も空白期間と重ならないように見込んでおきます。

支払期日があいまいなまま作業する

診断一式の請負では、報告書の検収が終わるまで支払いが確定しないことがあります。フリーランス法では、発注事業者は報酬の支払期日を、発注した物品等を受領した日から60日以内のできる限り短い期間内で定めることになっています（2026年10月時点、公正取引委員会の特設サイトによる）。

対策：報告書の提出日、検収の期日、支払期日が書面に書かれているかを確かめます。支払いが遅れたときの進め方は報酬の支払いが遅れたときで扱っています。

よくある質問

診断中に本番のシステムが止まってしまったら、どうすればよいですか？

まず作業を止め、決めておいた緊急時の連絡先にすぐ知らせます。そのうえで、いつ、どの対象に、どんな操作をしていたかを記録から整理して伝えます。自分の判断だけで復旧の操作をすると、状況を悪くすることがあるため、発注元の指示を待ってください。

許可の範囲外の対象に、偶然つながってしまいました。どうすればよいですか？

それ以上の操作をやめ、何が起きたかを記録して、発注元や間に入る会社に速やかに伝えます。隠したり、そのまま調べ続けたりすると、後で説明がつかなくなります。法律の当てはめは個別の事情で変わるため、判断に迷う場合は弁護士などの専門家にご相談ください。

報告書のレビューで大きく直されることが続きます。どうすればよいですか？

直された箇所を、判定の根拠、再現の手順、直し方の書き方に分けて振り返ると、自分の弱い部分が見えてきます。参画先の過去の報告書を読める場合は、書き方の型を先に合わせてください。書き方の伝え方は脆弱性診断エンジニアのスキルシートの記事も参考になります。