スマホアプリ脆弱性診断の見積条件｜費用を比べる前に確認すること

スマホアプリ脆弱性診断の見積書を比べるとき、アプリ数や画面数だけでは前提をそろえられません。OS、配布形態、認証後の機能、API、外部連携、実施環境が異なれば、依頼先に伝える条件も変わります。

結論から言うと、スマホアプリ診断の見積は、OS・画面・認証・API・実施制約が同じときにだけ比較します。各見積書の費目を同じ条件表へ写し、対象外や未確認の条件を質問として残すことが、比較の出発点です。

この記事では、モバイル固有の対象条件、実施条件、比較表への写し方を整理します。見積書の合計ではなく、何を確認する依頼なのかを揃えてから社内で判断しましょう。

本記事で分かること

• OS・配布形態・認証・APIをそろえる方法
• テスト用情報と実施制約の整理
• 見積書を同じ条件表へ写す順番
• 条件差を社内で説明する方法

結論：モバイルの見積条件をそろえる（早見表）

スマホアプリ診断の見積は、OS・画面・認証・API・実施制約が同じときにだけ比較します。対象表と条件表を先に作り、各見積書に書かれた内容を同じ欄へ記載します。

対象の条件をそろえる

画面数だけでなく、OSと連携条件を確認します。各見積書に渡す対象表には、アプリ本体、認証後の画面、API、外部連携、対象外にする範囲を分けて記載します。

OSと配布形態

対象表には、iOSとAndroidのどちらを対象にするか、確認するアプリの版、配布形態を記載します。両方のOSを提供していても、利用者が使う機能や連携先が同じとは限りません。共通部分と異なる部分を分け、依頼先に確認してほしい範囲を伝えます。

配布形態も、実施条件に関係する情報です。公開中の版か、検証用に用意した版か、配布先を限定している版かを整理します。変更予定がある場合は、確認する版と変更の連絡先を記録し、見積書の前提と対象表を照合します。

認証後の画面

認証後の画面は、画面名だけでなく、利用者区分と主な機能を対応付けます。一般利用者、管理を担う利用者、社内確認用の利用者など、権限が異なる場合は別の行にします。どの権限でどの範囲を確認するかを、テスト用アカウントの条件と合わせて整理します。

Webアプリ診断の費用構造を参照し、画面・機能・認証後の範囲を同じ仕様表にそろえます。対象外にする権限や機能がある場合は、理由と見直す条件を記載します。画面数だけを比較軸にせず、利用条件まで確認します。

APIと外部連携

APIと外部連携は、アプリ本体と分けて対象表に記載します。連携先の管理者、利用目的、自社が承諾を得られる範囲を確認し、対象に含めるかを決めます。外部サービスを利用しているだけの場合は、自社だけの判断で対象に含めません。

見積書では、連携先が対象に含まれるか、アプリ側のどの機能を確認するか、対象外の理由は何かを確認します。連携の条件が異なるものを同じ前提で比べないことが重要です。対象表に管理者と確認先を残すと、質問を整理しやすくなります。

実施条件をそろえる

実施環境とテスト用情報の違いを比較に混ぜません。テスト用アカウント、実施時間帯、変更凍結と連絡体制を、すべての依頼先に同じ条件で伝えます。

テスト用アカウント

テスト用アカウントは、利用者区分ごとに必要な権限と利用できる範囲を整理して準備します。実在の利用者情報をそのまま扱う前提にせず、社内の取扱いルールに沿って提供できる情報と、確認が必要な情報を分けます。提供方法、利用期限、通常の質問窓口を条件表に記載します。

アカウントを用意できない機能がある場合は、対象外にするのか、別の環境で確認するのかを関係者で決めます。情報を渡すことだけで完了にせず、どの画面・権限・APIの確認に使うかを対象表に対応付けます。依頼先ごとに異なる前提を渡さないようにします。

実施時間帯

実施時間帯は、通常の利用状況、連携先の都合、保守やリリースの予定を踏まえて整理します。いつでも実施できると仮定せず、避ける時間帯、確認可能な環境、予定外の状況で相談する窓口を依頼条件に記載します。

本番に近い環境を使う場合は、利用できる操作と運用上の制約を確認します。別の環境を使う場合も、対象となる版と本番との差を記録します。時間帯と環境の条件を同じ欄でそろえると、実施準備の違いを説明しやすくなります。

変更凍結と連絡

対象となる版や連携先に変更予定がある場合は、変更を避ける期間と、変更が必要になった場合の連絡方法を決めます。変更を完全に止められない場合も、どの変更を共有するか、誰が対象への影響を判断するかを整理します。

脆弱性診断の費用構造を参照し、対象、実施条件、成果物、再確認を同じ比較表で確認します。変更・連絡の条件を先にそろえることで、見積書の差分を対象や実施制約と結び付けて説明できます。

見積書を同じ条件に直して比べる

見積書に書かれた対象と条件を、社内の対象表・実施条件表・報告条件表の同じ欄へ写します。各社の記載順が違っていても、比較表の順番を変えずに前提差を質問します。

対象を同じ表へ写す

最初に、各見積書に書かれたOS、画面、認証後の範囲、API、外部連携、対象外を対象表へ写します。一行に複数の条件が書かれている場合も、対象の軸ごとに分けます。対象に含まれるか分からない項目は、仮に同じ条件として扱わず質問事項にします。

対象表の行ごとに、管理者、承諾範囲、確認する版を対応付けます。これにより、見積書の表現が異なっていても、同じ対象を扱っているかを確認できます。変更予定がある場合は、対象表と見積書の前提を更新します。

条件差を質問する

実施環境、テスト用アカウント、時間帯、連絡体制、報告・再確認の条件に差がある場合は、差分を質問します。質問は、何を含めるかを増やすためではなく、どの前提で回答されているかを確認するために行います。回答を受けたら、比較表の該当欄を更新します。

条件をそろえるために追加情報を渡す場合は、すべての依頼先に同じ情報を共有します。片方だけに詳細な対象表を渡すと、比較表の前提が変わります。質問と回答の履歴を残すことで、社内説明で条件差を追いやすくなります。

社内説明に残す

社内説明には、対象、実施条件、報告、再確認、未確認事項、判断した担当を記載します。見積書の合計を中心にせず、どの依頼がどの条件を含むかを対象表から説明します。決裁前に、対象外と未確認の範囲も共有します。

セキュリティ診断の発注ガイドを参考に、目的、対象、期限、社内の担当をそろえます。判断後に条件が変わった場合は、何が変わり、誰が影響を確認したかを記録します。比較表を更新すれば、次の見積依頼にも同じ条件を使えます。

まとめ

スマホアプリ脆弱性診断の見積は、OS、画面、認証、API、実施制約を同じ対象表・条件表でそろえて比べます。見積書の費目を同じ欄へ写し、対象・実施・報告・再確認の差分を質問として残すことで、社内の判断を共有しやすくなります。

モバイルの見積条件は、Webアプリ診断の費用構造と、費用の記事一覧から確認できます。