投稿日：2026.10.07　最終更新日：2026.10.08

スマホアプリの脆弱性診断とは？頼む前に知っておきたい検査範囲と費用の決まり方

「自社アプリの診断って、何をどう頼めばいいんだろう」

取引先から、アプリのセキュリティ対策について聞かれた。上司からは「診断を受けたほうがいいのか、調べておいて」と言われた。

でも、「脆弱性診断」という言葉は知っていても、何をどこまで調べるものなのか、いくらかかるのかは、各社のサイトを見ても分かりにくいですよね。

実際にスマホアプリの診断を行っている私たちIFTが、頼む前に診断の範囲や段取りを考えておくと迷わないポイントを、順番にまとめました。

この記事でわかること

スマホアプリの脆弱性診断で確かめること、診断範囲の分かれ方、受けるタイミング
実際に検査される項目（共通・Android・iOS・API通信）
費用と期間の決まり方と、相談前に整理しておくこと
診断のあとに自社がやること
診断会社を選ぶときに確認することと、相見積もりの前に聞いておく6つの質問

この記事を書いた人

みらいと

セキュリティサービス事業部　コンサルタント／プログラマーからシステム運用を経て情報セキュリティ全般の業務に従事。現在は培った情報セキュリティの経験を活かしお客様の課題に向き合った企画やマーケティングを担当。

スマホアプリの脆弱性診断とはどんな検査？

スマートフォンのセキュリティ対策を示すイメージ

スマホアプリの脆弱性診断は、アプリの設計や実装に弱点がないか、端末に保存された情報が漏洩しないかを、アプリの解析と実機での検証で確かめる検査です。

Webサイトの診断とは何が違い、どこまでが対象になるのか。自社が受けるべきタイミングと合わせて、まずは全体像を整理しておきましょう。

アプリ本体だけでなく、端末からの情報漏洩まで確かめる

Webサイトの診断で見るのは画面とサーバーの動きですが、スマホアプリの場合はそこに「端末の中」が加わります。

アプリは利用者のスマホに直接インストールされるため、プログラムの弱点だけでなく、端末に残ったログ（動作の記録）や保存データから情報が漏洩しないかまで確認する必要があります。

診断で確認する主なリスクは、次の3つです。

アプリからの情報漏洩（パスワードや個人情報などが端末内に残っていないか）
アプリの改ざんや、意図しない動作をさせられるリスク
アプリとサーバー間の通信に関するリスク

たとえば、パスワードがアプリの動作記録（ログ）にそのまま残っていたら、その端末を手にした人に読まれてしまうかもしれません。こうした端末側のリスクに加えて、どこまでを診断の対象に含めるかも事前に確認しておきたいところです。

どこまで診てもらえるかの診断範囲は、会社によって違う

スマホアプリの診断範囲は、「サーバー側」と「アプリ（端末）側」の2つに分けるのが一般的です。

ただ、どこまでを診断の対象に含めるかは、会社によって一律ではありません。スマホアプリ診断を頼めばサーバー側まで見てもらえるとは限らないため、見積もりの段階で確かめておく必要があるのです。

IFTでは、「アプリ本体」と「サーバー側（アプリとサーバーの連携部分）」の2つに整理して対応しています。

アプリ本体：iOS／Androidアプリそのもの。端末に残る情報や、通信・権限まわりを調べます
サーバー側（連携部分）：アプリがデータをやり取りする通信先のサーバー（APIサーバー）。Webアプリケーションへの診断と同様の項目で確認します

特にログイン機能や会員情報を扱うアプリでは、このサーバー側を診断に含めるかどうかが、見積もりや安全性の大きな分かれ目です。

ログインや会員機能があるアプリは、Webアプリケーション診断も必要になる

ログインや会員情報の表示など、サーバーと通信する機能があるアプリでは、通信先のAPIサーバーも確かめる必要があります。

APIサーバーは、アプリからの求めに応じて会員情報などのデータをやり取りする裏側の仕組みで、Webアプリケーション診断で調べる範囲に入ります。「Webアプリケーション」は、ブラウザで動くWebサイトとその裏側のサーバーを指す言葉です。名前に「アプリ」と入っていますが、スマホアプリのことではありません。

私たちIFTの場合、このサーバー側（連携部分）は、Webアプリケーション診断で対応しています。

Webアプリケーション診断とは？その効果と必要・不要の見極め方を専門家が解説

自社のWebサイトやサービスのセキュリティ、「本当に大丈夫？」と不安を感じていませんか？「『Webアプリケーション診断』を耳にするけれど、具体的に何をするの？」「費用はどれくらい？」「そもそも、うちの会社にも必要なの？」このような疑問や不安、もしかしたらあなたも感じていませんか？

診断を検討するタイミングは「未受診・機能追加・第三者評価」の3つ

次のどれかに当てはまるなら、診断を考えてよいタイミングです。

一度も診断を受けていない：これまで問題が起きていなくても弱点がないとは限らない。まずは現状のリスクを把握しておく必要がある
機能の追加や改修を行った：プログラムを変更した部分に、新たな脆弱性が入り込んでいるリスクがある
取引先などから第三者評価を求められた：自社の説明だけでなく、客観的な診断結果が必要になる

これらに当てはまるなら、診断を具体的に検討する段階に入っています。実際にどんな項目を調べるのか、検査の中身を見ていきましょう。

スマホアプリの脆弱性診断では実際に何を調べる？

「ストアの審査を通っているんだから、大丈夫では？」

たしかに、ストアに公開できていれば、ひと安心したくなりますよね。ただ、ストアの審査と、セキュリティ上の安全を確かめる脆弱性診断は別物です。

では、脆弱性診断では実際に何を調べるのでしょうか。

検査項目の分類や呼び方は診断会社によって違いますが、私たちIFTでは、「共通8項目」「Android特有」「iOS特有」「API通信」の4つに整理して検査を行っています。

共通8項目：通信・権限・端末に残る情報を確認する

OSを問わず、どのアプリでも共通して確認しておきたい基本項目があります。個人情報や決済情報を扱うかどうかにかかわらず、通信や権限の設定、端末へのデータ保存は、どのアプリでもセキュリティ上の抜け穴になりやすいためです。

難しく感じるかもしれませんが、防ごうとしているのは身近なトラブルです。たとえば、「端末の時計を変更するだけで期限切れのクーポンが再利用できてしまう」「アプリの中からサーバーにつなぐための鍵が抜き出されてしまう」といった、スマホアプリならではの弱点を探します。

私たちIFTでは、具体的に次の8項目を検査しています。

SSL証明書検証の不備：通信相手を検証せず、偽のサーバーと通信してしまわないか
不適切なパーミッションの使用：必要以上の権限を持っていないか
カスタムスキームの不適切な使用：外から呼び出されたとき、想定外の動きをしないか
デバッグ機能の使用：開発用の機能が、本番のアプリでも使えてしまわないか
端末の時間変更による制限の迂回：時計をずらすだけで、利用制限を外せてしまわないか
アプリへの重要情報の埋め込み：アプリの中に、鍵やパスワードが入っていないか
ストレージへの重要情報の出力：個人情報などが、読める形で保存されていないか
ログへの重要情報の出力：ログに、パスワードなどが残っていないか

ここまでは、すべてのアプリに共通して調べる基本項目です。これらに加えて、AndroidやiOSといったOSそれぞれの仕組みに応じた検査項目も確認していきます。

Android特有：逆コンパイルで中身まで解析する

Androidアプリの診断では、アプリケーションパッケージ（配布用のアプリのファイル）を逆コンパイル解析（プログラムを読める形に戻す解析）し、ソースコードのレベルまで踏み込んで脆弱性を探す手法があります。

そのうえで、Android特有の仕組みについて検査します。たとえば、ほかのアプリから呼び出されたときに、ログインしないと見られないはずの画面がそのまま開いてしまわないか、といった点です。

フルバックアップ機能の使用：アプリのデータを丸ごと取り出せる設定になっていないか
Activityの不適切な使用：外から呼び出された画面（Activity）が、想定外の動きをしないか
Service／Content Provider／Broadcast Receiverの不適切な使用：裏で動く処理やデータの受け渡しが、外からの要求で想定外の動きをしないか
重要情報のBroadcast：一斉通知（ブロードキャスト）で、重要な情報を他のアプリに渡していないか

自社のアプリがAndroid版かiOS版か、あるいは両方かによって、検査される項目は変わります。

iOS特有：通信の安全設定（ATS）を確認する

iOSアプリでは、安全な通信方式を使わせるiOSの仕組み「ATS（App Transport Security）」が正しく働いているかを、個別の項目として確認します。

OSの仕組みなので自動的に守られているように思えますが、アプリ側の設定によってはATSが無効化され、暗号化されていない通信が許されていることがあるためです。

API通信：サーバー側はWebアプリケーション診断と同じ項目で検査する

通信先のAPIサーバーに対しては、不正な命令を送り込んでデータベースを操作するSQLインジェクションなど、Webアプリケーションへの診断と同様の項目で検査します。

このように、サーバーと通信するスマホアプリでは、「端末側のアプリ」と「通信先のサーバー」の双方を確認して、はじめて全体の安全性を確かめられます。

スマホアプリ診断の費用と期間はどう決まる？

診断費用を計算するイメージ

費用はいくらかかり、期間は何日見ておけばよいのか。それぞれの決まり方を整理しておきましょう。

費用：診断する範囲・手法と、アプリの構成で変わる

費用を左右するのは、主に次の3点です。

診断する範囲：アプリ本体だけか、サーバー側も含めるか
診断の手法：ツールだけか、手動の診断も入るか
アプリの構成：対象のOS、機能の数や種類

このように、診断する範囲やアプリの構成によって料金が変わるため、各社のサイトを見ても一律の金額では比較しにくいのが実情です。

IFTの場合は手動診断も組み合わせるため、スマホアプリの構成を聞いたうえでの個別見積もりにしています。

期間：アプリの預け方とサーバーへの接続確認で前後する

Webサイトの診断と違って、スマホアプリの診断では、アプリそのものを診断会社に預ける準備が必要です。アプリのファイルをどう渡すか、アプリからサーバーへの接続をどう確かめるかといった段取りで、診断を始めるまでの日数が前後します。

IFTの場合、こうした準備を含めて、申し込みから診断開始までは10営業日前後が目安です。

報告書は、診断が終わってから通常5営業日以内に届きます。

リリースの日程を考えるときは、検査期間だけでなく、診断開始前の準備期間も予定に組み込んでおく必要があります。

費用と日程を相談する前に、整理しておきたい主な項目

診断会社に見積もりを依頼する際、費用や日程を算出するために確認される主なポイントがあります。

会社によって多少の差はありますが、たとえば私たちIFTのヒアリングでは、事前に次の4点を確認しています。

対象のプラットフォーム（iOS／Android）
アプリの種類や操作内容
アプリケーションファイルの提供可否
診断の希望期間

開発を外部の制作会社に任せている場合は、アプリのファイルや接続先の情報を用意してもらうことになるので、先に声をかけておくと進めやすくなります。

相談の前に4点をまとめておけば話が早く進みますし、複数社に見積もりを頼むときも、同じ条件で並べて比べられます。

スマートフォンアプリケーション診断

診断のあとに、依頼した側がやる2つのこと

報告書をもとに修正内容を確認するイメージ

診断は、検査をして終わりではありません。見つかった脆弱性を直し、直ったことを確かめるところまでを、依頼した側で進めていくことになります。

なかには、最終的な報告書を待たずに、診断の途中から動ける対応もあります。

危険度の高いものから先に直す

見つかった脆弱性はすべてを一度に直そうとするのではなく、悪用されたときの影響が大きい「危険度の高いもの」から優先して修正を進めます。

診断会社によっては、重大な問題が見つかった時点で早めに知らせてくれる場合もあります。たとえば私たちIFTでは、早急な改修が必要だと判断した脆弱性を、診断期間中に速報で知らせています。

こうした速報を活用して報告書の到着を待たずに初動を起こせれば、危険度の高いものからすぐに対策へ入れますし、全体の修正スケジュールにも余裕が生まれます。

報告書をもとに脆弱性を修正する

診断が完了して正式な報告書が届いたら、自社の開発チームや委託先の制作会社と共有し、具体的な改修作業に入ります。

この修正作業をスムーズに進めるカギになるのが、報告書に「再現手順」と「対策方法」が具体的に書かれているかどうかです。単に「脆弱性がある」とだけ書かれていても、社内にセキュリティの専門家がいない場合、どう直せばよいか迷って手が止まってしまいます。

たとえば私たちIFTの報告書では、脆弱性1件ごとに次の4点を整理して記載しています。

危険度レベル（緊急・高・中・低の4段階）
脆弱性の内容
再現手順
対策方法

自社の環境で問題が起きることを再現手順で確かめ、具体的な対策方法に沿って直せるため、開発現場でもスムーズに改修を進めやすくなります。また、危険度別に並んでいるので、社内の意思決定者へ報告する際も状況を説明しやすくなります。

スマホアプリ診断会社を選ぶ3つの判断基準

診断会社を判断基準で比べるイメージ

「何社か問い合わせてみたけれど、何が違うのかよく分からない」

各社の解説を読み比べると、診断の種類や検査範囲が会社ごとにばらばらなことが分かります。技術の要素で分ける会社もあれば、守備範囲や公開基準で分ける会社もあり、同じ「スマホアプリ診断」という名称でも中身の定義は一律ではありません。

見比べる際は、「診断範囲」「診断のやり方」「診断後のサポート」という3つの視点を持つと整理しやすくなります。

①診断範囲：API連携部分まで含まれるか

アプリとサーバーの連携部分（API）まで「スマホアプリ診断」に含まれているかは、会社によって違います。

診断範囲の前提が違うまま見積もりを並べても、金額の比較にはなりません。

提示された見積もりにAPI連携部分まで含まれているのか、それとも別料金（オプション）なのかを確認し、診断範囲の条件を揃えてから金額を見比べてみてください。

②診断のやり方：手動診断があるか、アプリの中身まで見るか

「診断」と一口に言っても、ツールによる自動診断だけなのか、診断員による手動診断も入るのかで内容や費用が大きく変わります。

ツールは決まったパターンを素早く調べられますが、業務の文脈や仕様の抜け穴までは判断できません。見積もりに大きな開きがある場合は、手動診断が含まれているかを確認してみてください。

もう一つ確認したいのが、Androidアプリを逆コンパイル（プログラムを読める形に戻す解析）し、ソースコードのレベルまで踏み込んで調べてくれるかという深さです。

検査の基準は、OWASPなどがまとめた国際的な基準を用いる会社もあれば、独自の基準を持つ会社もあります。

たとえばIFTでは、ツールと手動診断を組み合わせ、Androidアプリは逆コンパイル解析まで実施しています。独自の「スマートフォンセキュリティガイドライン」に基づいて検査し、単に弱点を見つけるだけでなく、現場の開発者が改修しやすいアドバイスまで行っています。

診断の手法や深さを確認できたら、最後に「診断が終わったあとのサポート体制」がどうなっているかも見比べておきましょう。

③診断後のサポート：報告書に再現手順があるか、再診断は料金に含まれるか

診断後のサポートで、会社によって差が出やすいのは次の3つです。

報告書に、開発者が再現できる手順と対策方法が書かれているか
修正後の再診断が料金に含まれるか
診断結果を、取引先への第三者評価として提出できるか

見つかった弱点を正しく改修し、修正漏れを防ぐには、報告書の中身と再診断の条件が重要になります。

参考までに、IFTの場合は危険度・内容・再現手順・対策方法の4点で整理した報告書を作成しています。また、取引先への提出が必要な場合は、診断結果を添えたアプリの納入にも対応しています。

相見積もりの前に聞いておく6つの質問

API連携部分は、診断の範囲に含まれますか
手動の診断はありますか
アプリの中身（逆コンパイル）まで見ますか
報告書に再現手順と対策方法は書かれますか
診断結果を、取引先への第三者評価として提出できますか

すべてに「はい」と答える会社がよい、というわけではありません。

たとえば、ログインも会員情報もなく、サーバーとやり取りしないアプリなら、1つ目の質問は気にしなくて大丈夫です。取引先から第三者評価を求められていないなら、6つ目も後回しで構いません。

まとめ：「どこまでを誰に頼むか」を決めて、まずは個別見積もりで確かめよう

この記事のポイント

診断範囲は「アプリ本体」と「サーバー側」の2つに分かれる
検査項目は、OS共通・Android特有・iOS特有・API通信の4つ
費用は範囲・手法・構成で決まり、期間はアプリを預ける段取りで前後する
報告書で直したら、再診断で「本当に直ったか」まで確かめる
会社選びは「範囲・やり方・診断後のサポート」の3点で比べる

スマホアプリの診断で一番迷うのは、実は「何をどこまで頼むか」のところです。

事前に決めておきたいのは、診断をアプリ本体だけにするか、サーバー側（連携部分）まで含めるかです。ここが明確になれば、見積もりも会社選びも進めやすくなります。

あとは対象のOS、アプリの種類と操作内容、アプリファイルを渡せるか、希望の時期の4点をメモしておけば、相談の準備は十分です。

私たちIFTでは、「診断して終わりじゃない、”改善”まで見届ける手厚いサポート」を大切にしています。

報告書を渡したところで終わってしまえば、脆弱性が本当に直ったのかを確かめられないからです。

自社アプリのどこまでを診断すればいいか迷っている方は、アプリの構成をお聞かせいただくところから、お気軽にご相談ください。