スマホアプリのセキュリティで最も高くつく失敗は、脆弱性を作り込むことではありません。「誰がいつセキュリティを担保するのか」を決めないまま発注してしまうことです。 決めていなければ、見積もりにその費用は載りません。載っていない作業は行われません。そして問題が表面化するのは、たいていリリース後、つまり最も直しにくいタイミングです。
本記事は、自社サービスや業務用のスマホアプリを開発会社に発注しようとしている経営者・事業責任者・情シス担当の方に向けて、契約前に決めておくべきセキュリティ要件を12項目に整理します。技術者になる必要はありません。何を要求すべきかを知り、開発会社に確認できるようになることがゴールです。費用の全体像はスマホアプリ開発費用の完全ガイド、Web側の脆弱性についてはWebアプリケーションセキュリティ OWASP Top10ガイドで扱っています。
目次
- 結論：アプリの安全性は「置き場所」と「持ち主」で決まる
- なぜスマホアプリは特に危ないのか
- 要件12項目（発注前に決める）
- ストア審査は「セキュリティの最低ライン」ではない
- 見積もりのどこを見るか
- 開発会社への質問文（そのまま使える）
- 契約に書くべき責任分界
- よくある失敗
- 発注前チェックリスト
- よくある質問（FAQ）
- 発注前に整理したいとき
<a id="conclusion"></a>
結論：アプリの安全性は「置き場所」と「持ち主」で決まる
スマホアプリのセキュリティを難しく考える必要はありません。発注者として押さえる論点は、突き詰めると次の3つです。
- どのデータを、端末の中に置くのか（置かない設計にできないか）
- 鍵と権限を、誰が持つのか（開発会社か、自社か、クラウド事業者か）
- リリースした後、脆弱性が出たとき誰が直すのか（その費用は誰が持つのか）
この3つに答えが出せていれば、細かい実装は開発会社に任せてよい領域です。逆に、この3つが空白のまま「セキュリティもよろしく」と発注すると、担当者の裁量と善意に依存した作りになります。善意は退職とともに消えます。
とくに3番目は見落とされがちです。アプリは公開した瞬間から、OSのバージョンアップ、ライブラリの脆弱性公表、ストア規約の変更にさらされ続けます。開発費は一度きりでも、安全性の維持は続くという構造を、契約の形にしておかなければなりません。
<a id="why"></a>
RESTAURANT DX
店長の経験と勘を、仕組みで再現できる店舗にしませんか？
発注／シフト／予約／FLコストを標準化する多店舗飲食特化のDX。食材ロス削減・インバウンド対応まで概算費用をその場で示します。
なぜスマホアプリは特に危ないのか
Webサイトとスマホアプリでは、守り方の前提が違います。Webは基本的にサーバー側で処理が完結し、利用者の手元にはブラウザ画面しか渡りません。一方スマホアプリは、プログラムそのものが利用者の端末にインストールされます。
これが何を意味するかというと、攻撃者はアプリを自分の端末に入れて、中身をじっくり調べられるということです。アプリの中に書き込まれたAPIキーやパスワード、サーバーのURL、暗号化のロジックは、時間をかければ取り出されうる前提で設計する必要があります。「アプリの中に隠してあるから大丈夫」は成り立ちません。
もう一つの違いは、利用者の端末環境を選べないことです。会社支給のPCなら管理者が設定を統制できますが、従業員や顧客の私物スマホには、古いOS、改造された端末、素性の分からないアプリが同居している可能性があります。自社アプリが健全でも、隣にいるアプリが悪意を持っているかもしれない。この前提での設計が求められます。
この領域の要件を体系的に整理した国際的な標準として、OWASPが公開しているMASVS（Mobile Application Security Verification Standard）があります。検証手順をまとめたMASTGとあわせて公開されており、無料で参照できます。発注者がすべてを読む必要はありませんが、開発会社に「MASVSのどのレベルを満たす想定か」と聞けることには意味があります。答えられない相手は、この領域を体系的に扱っていない可能性が高いからです。
<a id="requirements"></a>
要件12項目（発注前に決める）
以下は、見積もり依頼の前に自社として方針を決めておくべき項目です。すべてを最高水準にする必要はありません。扱うデータの重さに応じて、どこを厚くするかを決めるのが発注者の仕事です。
領域1：端末に置くデータ
横にスクロールして確認できます
| # | 決めること | 判断のヒント |
|---|---|---|
| 1 | 端末内に保存するデータの範囲 | 個人情報・決済情報・業務データを端末に残さない設計にできないか。残すなら何のためか |
| 2 | 保存する場合の保護方式 | OSが提供する安全な保管領域を使うのか、独自実装か。独自実装なら理由を確認する |
| 3 | ログアウト・アンインストール時の消去 | 退職者の端末、譲渡された端末に業務データが残らないか |
最も効果が大きいのは1番です。「そもそも端末に置かない」という判断ができれば、2と3の難易度は一気に下がります。オフラインでの利用が本当に必要か、キャッシュはどこまで必要かを、業務側の要件として先に詰めてください。技術で守るより、持たないほうが安全で安く済みます。
領域2：通信と認証
横にスクロールして確認できます
| # | 決めること | 判断のヒント |
|---|---|---|
| 4 | 通信の暗号化と証明書の扱い | 全通信を暗号化するのは前提。加えて偽サーバー対策をどこまでやるか |
| 5 | 認証方式 | ID・パスワードのみか、多要素か、生体認証を使うか。業務アプリなら会社アカウント連携が使えるか |
| 6 | セッションの有効期限とログアウト条件 | 一度ログインしたら永久に使える設計になっていないか |
認証は利便性とのトレードオフが最も大きい領域です。「毎回ログインは面倒」という現場の声と、「端末を落としたら誰でも入れる」というリスクのどちらを取るかは、技術判断ではなく経営判断です。開発会社に丸投げすると、たいてい利便性側に倒れます。
領域3：ログと監視
横にスクロールして確認できます
| # | 決めること | 判断のヒント |
|---|---|---|
| 7 | 何を記録するか | 誰が・いつ・何をしたかを後から追えるか。事故が起きたとき調査できるか |
| 8 | ログに個人情報を書かないルール | デバッグ用のログに個人情報が残ったまま公開される事故は珍しくない |
ログは平時には価値が見えず、削られやすい項目です。しかし情報漏えいが疑われたとき、ログがなければ「漏れていない」ことすら証明できません。取引先や顧客への説明責任を果たせるかどうかは、ここで決まります。
領域4：第三者ライブラリと外部サービス
横にスクロールして確認できます
| # | 決めること | 判断のヒント |
|---|---|---|
| 9 | 使用する外部ライブラリの一覧を納品物に含めるか | 何が使われているか分からなければ、脆弱性公表時に影響を判断できない |
| 10 | 外部SDK（分析・広告・地図等）が送るデータの範囲 | 自社の意図しないデータが第三者に渡っていないか |
現代のアプリは、大部分が外部の部品の組み合わせでできています。だからこそ、使っている部品の一覧（いわゆるSBOM的な情報）を納品物として要求することが有効です。一覧がなければ、ある部品に重大な脆弱性が公表されたときに「うちのアプリは影響を受けるのか」を判断できず、開発会社に問い合わせて回答を待つしかなくなります。
領域5：リリース後
横にスクロールして確認できます
| # | 決めること | 判断のヒント |
|---|---|---|
| 11 | 脆弱性が公表されたときの対応期限と費用負担 | 保守契約に含むのか、都度見積もりか。何日以内に対応するか |
| 12 | OSメジャーアップデートへの追随 | 年1回のOS更新で動かなくなったとき、誰が費用を持つか |
11と12は、開発費の見積もりには現れないのに、後から必ず発生する費用です。ここを契約前に決めていないと、リリース1年後に「対応しますが別途お見積もりです」という会話が始まります。金額そのものより、対応の義務があるかどうかを先に固めてください。
<a id="store"></a>
ストア審査は「セキュリティの最低ライン」ではない
「App StoreとGoogle Playの審査を通ったのだから、セキュリティは大丈夫」という理解は危険です。
両ストアの審査は、Appleの App Review Guidelines や Google Play の Developer Policy に基づいて行われますが、その主眼はプライバシー開示の適切さ、禁止コンテンツの排除、決済ルールの遵守、機能の実在性などにあります。発注者が期待するような「このアプリに脆弱性がないことの保証」ではありません。
一方で、審査要件は無視できません。とくに近年は、収集するデータの種類と用途の申告、第三者への提供の有無、トラッキングの許諾取得といったプライバシー関連の要求が厳格化しています。ここでの申告内容と実装が食い違えば、審査でリジェクトされるか、公開後に指摘を受けます。
発注者として押さえるべきは次の2点です。第一に、プライバシー関連の申告内容は、開発会社ではなく自社が決めるべき事項であること。どのデータを何のために集めるかは事業判断であり、開発会社が推測で埋めるものではありません。第二に、審査要件は変わり続けるため、リリース後の更新時に再びリジェクトされる可能性があること。これも領域5の「リリース後」に含めて考える必要があります。
なお、個人データの取扱いについては、ストアのルールとは別に日本の個人情報保護法が適用されます。個人情報保護委員会が法令・ガイドライン等を公開しているので、利用目的の特定・通知や第三者提供の考え方は、アプリの仕様を決める前に自社側で整理しておいてください。
<a id="estimate"></a>
見積もりのどこを見るか
セキュリティ費用は、見積もりの中で最も「消えやすい」項目です。理由は単純で、機能一覧には現れないからです。ログイン画面やカート機能は誰でも指差せますが、「ログに個人情報を書かない」は指差せません。
見積もりを受け取ったら、次の観点で読んでください。
- セキュリティに関する行が独立して存在するか。 「一式」の中に溶けていないか
- テスト工程の内訳に、セキュリティ観点の確認が入っているか。 機能テストだけになっていないか
- リリース後の保守の範囲に、脆弱性対応が明記されているか。 「不具合対応」と「脆弱性対応」は別物として書かれているか
- 外部診断（脆弱性診断）を入れるかどうかが判断できる形で書かれているか。 入れないなら、入れない前提であることが明示されているか
複数社から見積もりを取る場合、この観点が揃っていないと金額を比べる意味がありません。セキュリティ要件を書いていない見積もりが最も安く見えるのは当然で、それを理由に選ぶと、差額は後から利息付きで返ってきます。見積もりの前提を揃える考え方はシステム開発の費用・見積もりガイドでも整理しています。
<a id="questions"></a>
開発会社への質問文（そのまま使える）
商談や見積もり説明の場で、次の質問をそのまま使ってください。専門用語を使わずに、答えの質で相手の実力が測れる形にしています。
- 「このアプリは、利用者の端末の中にどんなデータを保存しますか。保存しない設計は可能ですか」
- 「アプリの中に、サーバーに接続するための鍵やパスワードに相当するものは入りますか。入る場合、どう守りますか」
- 「利用者がログアウトした場合、端末に残るデータは何ですか」
- 「使用する外部ライブラリの一覧は、納品物に含まれますか」
- 「そのライブラリに脆弱性が公表された場合、どのくらいの期間で対応いただけますか。費用はどうなりますか」
- 「OSのメジャーアップデートで動作しなくなった場合の対応は、保守に含まれますか」
- 「ログには何を記録しますか。個人情報が含まれない確認は誰が行いますか」
- 「OWASP MASVSなど、参照している基準はありますか。どのレベルを想定していますか」
- 「ストア審査でプライバシー関連の申告が必要ですが、内容は誰が決める前提ですか」
- 「リリース前に外部の脆弱性診断を入れる想定はありますか。ない場合、その理由を教えてください」
答えの内容そのものより、即答できるか、持ち帰るか、質問の意図を理解しているかを見てください。質問8で「特に決めていません」と返ってくる場合、その会社にとってセキュリティは案件ごとの個人技である可能性が高い。それが悪いとは限りませんが、担当者が替わったときの再現性は期待できません。
<a id="contract"></a>
契約に書くべき責任分界
要件を決めても、契約に落ちていなければ実行されません。最低限、次の4点は文書化してください。
第一に、納品物の定義。 ソースコード、設計書、使用ライブラリ一覧、ビルド手順、そしてストアアカウントの権限。とくにストアアカウントを開発会社名義で作らせないことは重要です。名義が相手にあると、取引を終えるときにアプリごと人質になります。納品物の考え方はシステム開発の納品物とはも参考になります。
第二に、脆弱性対応の義務と期限。 「重大な脆弱性が公表された場合、◯営業日以内に影響有無を回答する」という形で、調査の義務と回答期限を書きます。修正まで無償で義務づけるのは現実的でない場合が多いので、まず「調べて教えてもらえる」状態を作るのが実務的です。
第三に、鍵と権限の管理主体。 署名用の鍵、クラウドの管理者権限、APIキーを誰が保管し、誰が渡すか。ここが曖昧だと、開発会社を変える段階で作り直しに近い工数が発生します。
第四に、契約終了時の引き渡し。 どの状態で何を渡すか。この一文があるかどうかで、乗り換えの自由度がまったく変わります。契約形態そのものの整理は受託開発とは何か（請負・準委任の違い）を参照してください。
<a id="failure"></a>
よくある失敗
- セキュリティを「テスト工程の一部」だと思っている。 実際には設計段階で決まる部分が大半で、後工程の点検では作り直しになる。
- 端末に置く必要のないデータを置いている。 「オフラインでも見たい」という要望を精査せず受け入れた結果、守るべき対象が増える。
- 外部ライブラリの一覧を持っていない。 脆弱性が公表されても自社が影響を受けるか判断できず、初動が数日遅れる。
- ストアアカウントが開発会社名義。 契約終了時にアプリの更新権限を失い、実質的に乗り換えられない。
- リリース後の脆弱性対応が契約にない。 1年後に「別途お見積もり」となり、予算がないので放置される。
- プライバシー申告を開発会社任せにしている。 事業側が把握していない申告内容が公開され、実態と食い違う。
<a id="checklist"></a>
発注前チェックリスト
- 端末内に保存するデータの範囲を自社として決めた
- 「端末に置かない設計」の可否を開発会社に確認した
- 認証の強度（多要素の要否・セッション期限）を経営判断として決めた
- ログに何を記録し、何を記録しないかを決めた
- 外部ライブラリ一覧を納品物に含めることを見積もり条件に入れた
- 脆弱性公表時の調査義務と回答期限を契約条件に入れた
- OSメジャーアップデート対応の費用負担を決めた
- ストアアカウントの名義を自社にすることを確認した
- プライバシー申告の内容を決めるのは自社だと社内で合意した
- 見積もりにセキュリティの行が独立して存在することを確認した
- 外部の脆弱性診断を入れるか入れないかを明示的に決めた
- 契約終了時の引き渡し条件を文書化した
<a id="faq"></a>
よくある質問（FAQ）
Q. セキュリティ要件を厚くすると、費用はどれくらい上がりますか。 A. 要件の内容と対象データの重さで大きく変わるため、一律の割合は示せません。ただし費用構造として言えるのは、設計段階で決めた要件は相対的に安く、リリース後に足す要件は高いということです。同じ「端末にデータを残さない」でも、設計前なら方針の選択で済み、リリース後なら作り直しになります。
Q. 社内で使う業務アプリでも、ここまで必要ですか。 A. 判断軸は「社内向けかどうか」ではなく「何を扱うか」です。社内アプリでも顧客の個人情報や取引データを表示するなら、端末紛失時の影響は外部向けアプリと変わりません。逆に、公開情報しか扱わないアプリなら要件は軽くできます。
Q. 開発会社が「セキュリティは万全です」と言っています。信じてよいですか。 A. 「万全」という言葉には検証可能な中身がありません。本記事の質問文で、保存データの範囲、ライブラリ一覧の提供可否、脆弱性公表時の対応期限といった具体で確認してください。具体に落ちない回答は、実務が伴っていない可能性があります。
Q. 脆弱性診断は必ず入れるべきですか。 A. 扱うデータの重さで決めます。決済情報や個人情報を扱うなら入れる価値が高く、社内の閲覧専用アプリなら費用対効果が合わないこともあります。重要なのは、入れる／入れないを意識的に決めて記録することです。検討した形跡がないまま「なかった」のが最も弱い状態です。
Q. すでに公開しているアプリがあります。今からできることは何ですか。 A. 順序としては、(1) 使用ライブラリの一覧を開発会社から入手する、(2) 端末に保存しているデータの範囲を確認する、(3) 脆弱性公表時の対応が保守契約に入っているか確認する、の3つです。この3つが分かるだけで、次に何を直すべきかの優先順位がつきます。
Q. 開発会社を変えたいのですが、何から確認すべきですか。 A. ストアアカウントの名義、署名鍵の保管者、ソースコードと設計書の所在、外部サービスの管理者権限です。この4つが自社側にないと、乗り換えの見積もりが跳ね上がります。
Q. MASVSは自社で読むべきですか。 A. 発注者が通読する必要はありません。開発会社との会話で「参照している基準はあるか」を聞くための背景知識として知っておけば十分です。詳細な検証は開発側と、必要なら第三者の役割です。
<a id="cta"></a>
発注前に整理したいとき
スマホアプリのセキュリティは、リリース後の点検で取り返すには高くつきます。端末に何を置くか、鍵を誰が持つか、後から誰が直すか——この3つを発注前に決めておくだけで、避けられる事故と余計な出費の大半は防げます。
そして、この3つはいずれも技術の問題ではなく、事業側が決めるべき事項です。開発会社に決めさせると、決めやすい方（利便性が高く、責任が軽い方）に倒れます。倒れた結果を引き受けるのは発注した側です。
GXOは特定の開発手法や製品の販売元ではないため、「この見積もりにセキュリティの費用が入っているか」「この要件で足りるか」を発注側の立場で点検できます。
- 受け取った見積もりにセキュリティ要件が入っているか見てほしい → 見積もりセカンドオピニオン
- 発注前に要件そのものを整理したい → 要件定義・業務フロー整理の相談
- 自社のセキュリティ体制から相談したい → セキュリティ事業
- 公開後の運用・脆弱性対応を任せたい → セキュリティ運用伴走
- アプリ開発の費用感を先に知りたい → スマホアプリ開発費用の完全ガイド
「作った後に点検する」から「作る前に決める」へ。その順序の入れ替えを、発注の前にご一緒します。
参考（一次ソース）
- OWASP MASVS（Mobile Application Security Verification Standard）（一次・国際標準）
- OWASP MASTG（Mobile Application Security Testing Guide）（一次・国際標準）
- IPA「安全なウェブサイトの作り方」（一次・公的機関）
- 個人情報保護委員会「法令・ガイドライン等」（一次・公的機関）
- 個人情報の保護に関する法律（e-Gov法令検索）（一次・法令）
- Apple「App Review Guidelines」（一次・プラットフォーム公式）
- Google Play「Developer Policy Center」（一次・プラットフォーム公式）
※MASVSの版数、ストアの審査要件、個人データ保護の運用は、いずれも更新され続けます。本記事に挙げた要件は「発注前に決めておく論点」の整理であり、個別の実装可否や法令適合の判断を代替するものではありません。実際の設計・申請にあたっては、上記の公式ページで最新版を確認し、必要に応じて法務・専門家の助言を得てください。
