「弊社はプライバシーマークを取得しています」。複数の開発会社から提案を受けたとき、こうしたアピールを目にすることは珍しくありません。個人情報を扱うシステムの発注では、上司や同僚から「プライバシーマーク取得企業にしたほうが安心」と助言されるケースも多いでしょう。
しかし、いざ選定基準として組み込もうとすると、いくつかの疑問が湧いてきます。プライバシーマークがあれば本当に情報漏えいのリスクは下がるのか。ISMS との違いは何か。マークを持っているだけで安心してよいのか、それとも他にも確認すべきことがあるのか。
実は、プライバシーマーク（Pマーク）に対する発注者側の理解は、過信と不安の両極端に振れがちです。「マークがあれば大丈夫」と思考停止すると見落としが生じますし、「マークでは不十分」と不安になりすぎれば判断軸を失います。重要なのは、認証が何を保証し、何を保証しないかを正確に把握することです。
本記事では、個人情報を扱うシステムを発注する立場の方に向けて、プライバシーマークの本来の意味と限界を整理し、認証情報を選定プロセスにどう組み込むべきかを実務的に解説します。認証だけに頼らない多層的な選定軸として、契約書条項とチェックリストもあわせて紹介します。読み終えるころには、「Pマーク取得企業＝安心」ではなく、「Pマークを入口に何を追加確認すべきか」という発想で発注先を見極められるようになるはずです。
失敗しないためのアプリ開発の考え方と開発パートナー選定チェックリスト
この資料でわかること
アプリ開発（スマートフォンアプリ・Web アプリ）の発注・開発を検討している企業の担当者が、開発パートナーを選ぶ際に「何を確認すべきか」「どのような観点で比較すべきか」を体系的に把握できる実践的なチェックリストを提供する。
こんな方におすすめです
- アプリ開発を検討しているが失敗したくない
- 開発パートナーの選び方が分からない
- アプリの形式選定やUI/UX設計の確認ポイントを知りたい
入力いただいたメールアドレスにPDFをお送りします。
プライバシーマーク（Pマーク）とは何か
プライバシーマークとは、一般財団法人日本情報経済社会推進協会（JIPDEC）が運営する、事業者の個人情報保護体制を評価する第三者認証制度です。事業者が個人情報を適切に管理する仕組みを構築・運用していることを審査し、基準を満たした事業者にマークの使用を認めます。発注者として最低限知っておきたい骨格を、以下で簡潔に整理します。
プライバシーマークの定義と目的
プライバシーマーク制度は、日本産業規格「JIS Q 15001（個人情報保護マネジメントシステム — 要求事項）」への適合性を、第三者である審査機関が評価する仕組みです（JIPDEC「プライバシーマーク制度の概要と目的」）。
つまり、プライバシーマークが評価しているのは「個人情報を扱うための社内マネジメントシステム（仕組み）」が JIS Q 15001 の基準を満たしているかどうかです。製品やサービスそのものの安全性、あるいはネットワークの技術的な堅牢性を直接審査しているわけではない、という点が大切なポイントです。
認定の仕組みと有効期間
プライバシーマークの審査は、JIPDEC から指定を受けた審査機関が実施します。事業者は、申請書類の提出と現地審査を経て、基準を満たすと判断された場合にマークの使用を許諾されます。
有効期間は2年間で、引き続きマークを使用するには2年ごとに更新審査を受ける必要があります。つまり、初回取得時にだけ基準を満たせばよいわけではなく、継続的に体制を維持していることが求められます。一方で、審査は2年に一度の頻度であるため、その間の日常運用がどのように行われているかは、審査時点では完全には把握しきれない構造になっています（この限界については後述の「プライバシーマークがあっても保証されないこと」で詳しく扱います）。
取得企業数と業界での位置づけ
JIPDEC の公開情報によれば、プライバシーマークの付与事業者数は2025年時点で17,000社を超える規模に達しています（JIPDEC「付与事業者数の詳細」）。日本国内において、個人情報保護の取り組みを対外的に示す代表的な認証として広く普及していると言えます。
業種別に見ると、情報サービス業（システム開発・SaaS事業者を含む）、人材サービス業、通信販売・EC、教育・学習支援などで取得割合が高く、特に「顧客の個人情報を業務として大量に取り扱う業界」での取得が中心です。発注者の立場で見ると、こうした業界の開発会社からプライバシーマーク所持を提案資料で示されるのは、業界水準として一般的な取得状況であることを理解しておくと、過大評価せずに判断できます。
プライバシーマークと他のセキュリティ認証（ISMS・SOC2）との違い
開発会社の提案資料には、プライバシーマーク以外にも「ISMS認証取得」「SOC2 Type II 対応」など、さまざまなセキュリティ認証のロゴが並ぶことがあります。これらをひとくくりに「セキュリティ認証」として扱ってしまうと、自社の発注内容に合わない判断基準で選定してしまう恐れがあります。ここでは、混同しやすい3つの認証の違いを整理します。
対象範囲の違い（個人情報・情報資産全般・クラウド統制）
3つの認証は、評価する対象範囲が異なります。
- プライバシーマーク: 個人情報を対象とする。氏名・住所・連絡先・購買履歴など、特定の個人を識別できる情報の取扱体制を評価する
- ISMS（ISO/IEC 27001）: 情報資産全般を対象とする。個人情報に限らず、技術情報・営業秘密・契約書類など、組織が保有するあらゆる情報資産の管理体制を評価する
- SOC2: 主にクラウドサービス事業者の内部統制を対象とする。セキュリティ・可用性・処理の完全性・機密性・プライバシーの5つの基準（Trust Services Criteria）に基づき、サービス運営の信頼性を評価する
簡単に言えば、「個人情報の扱い」を見たければプライバシーマーク、「情報資産全般の管理」を見たければ ISMS、「クラウドサービスの内部統制」を見たければ SOC2 が出発点になります。
国内認証 vs 国際認証
もうひとつ重要な違いは、認証の通用範囲です。
- プライバシーマーク: 日本独自の制度。海外の取引先や規制当局には認知されにくい
- ISMS（ISO/IEC 27001）: 国際規格。海外取引や海外子会社を含む情報管理体制の証明に活用しやすい
- SOC2: 米国公認会計士協会（AICPA）が策定した基準。北米のクラウド事業者を中心に普及している
国内向けサービスを発注するのであればプライバシーマークの認知度で十分ですが、海外データセンターを利用するサービスや、グローバル展開を視野に入れる案件では、ISMS や SOC2 の有無も視野に入れた評価が必要になります。
比較表（対象・規格・更新サイクル）
項目 | プライバシーマーク | ISMS（ISO/IEC 27001） | SOC2 |
|---|---|---|---|
対象 | 個人情報の取扱 | 情報資産全般 | クラウドサービスの内部統制 |
準拠規格 | JIS Q 15001 | ISO/IEC 27001 | AICPA Trust Services Criteria |
認定機関 | JIPDEC（日本） | 各国認定機関（ISMS-AC ほか） | 米国公認会計士（CPA）監査人 |
通用範囲 | 主に国内 | 国際的に通用 | 主に北米中心、世界的に普及 |
更新サイクル | 2年ごとに更新審査 | 1年ごとに維持審査、3年ごとに更新 | 通常6〜12ヶ月ごとに監査 |
発注内容に応じた認証の見方
発注する案件の性質によって、重視すべき認証は変わります。
- 会員情報・問い合わせ情報など個人情報が中核となるシステムを発注する場合 → プライバシーマークを重視し、ISMS があれば加点評価
- 自社の技術情報・営業秘密を共有する開発案件、または社内情報を広く扱う業務システムを発注する場合 → ISMS を重視
- 海外展開を視野に入れる、またはクラウドサービス事業者として相手を選定する場合 → SOC2 や ISMS を重視
ISMS について発注者の視点でさらに詳しく知りたい場合は、ISMS認証取得の開発会社に発注するメリットもあわせてご覧ください。また、認証ロゴ全般の見方・確認ポイントを発注者向けに整理したIT発注者のための情報セキュリティ基礎も参考になります。
プライバシーマーク取得企業に開発を発注するメリット
ここまで「過信は禁物」というトーンで述べてきましたが、プライバシーマークの価値を過小評価することも適切ではありません。発注者の立場から見て、Pマーク取得企業に依頼することには明確なメリットが3〜4点あります。順に整理します。
個人情報保護に関する社内体制・規程が一定水準で整備されている
プライバシーマークの審査では、個人情報保護方針の策定、社内規程の整備、教育・研修の実施、責任者の任命、リスクアセスメントの実施などが評価対象となります（JIPDEC「JIS Q 15001 適合性評価」）。
逆に言えば、Pマーク取得企業であれば、これらの要素が「ゼロから確認しなくても、最低限のレベルでは整っている」と推定できます。発注者にとっては、相手企業の体制をすべてゼロから審査する手間が省ける、というスクリーニング効果があります。
委託先選定の説明責任を果たしやすい
個人情報保護法第25条は、個人情報取扱事業者に対し、委託先に対する「必要かつ適切な監督」を義務づけています（個人情報保護委員会「個人情報の保護に関する法律」）。発注者側にも、委託先を選定する際に一定の責任が生じるということです。
社内稟議や取引先からの問い合わせがあった際、「委託先はプライバシーマーク取得企業を選定しました」という事実は、選定プロセスの妥当性を示す客観的な根拠として有用です。すべての安全を保証するものではないとしても、「合理的な選定努力を行った」という説明責任を果たしやすくなります。
漏えい時の対応体制が制度的に整備されている
プライバシーマークの審査基準では、個人情報の漏えい・滅失・毀損が発生した場合の対応手順（インシデント対応プロセス）の整備も求められています。具体的には、社内連絡体制、本人への通知、関係機関への報告、再発防止策の策定などが含まれます。
万が一インシデントが発生した場合、Pマーク取得企業であれば「最低限の対応手順は文書化されている」状態にあると期待できます。発注後にインシデントが起きたときの対応のしやすさは、契約期間中のリスク管理の観点で重要な要素です。
入札・取引条件としても通用する
官公庁の入札や大手企業との取引においては、プライバシーマークの取得が応札・参画の条件として求められるケースがあります。自社が今後より厳格なセキュリティ要件のある取引先と仕事をしていく可能性を考えると、Pマーク取得企業を委託先として選んでおくことは、サプライチェーン全体のセキュリティ要件適合性を担保する意味でも有効です。
プライバシーマークがあっても保証されないこと（過信は禁物）
ここからが本記事の核心です。プライバシーマークには明確な価値がある一方で、「マークがあるから絶対に安全」というのは事実と異なります。発注者として知っておくべき、認証の限界を正直に整理します。
マネジメントシステムの認証であり、技術的セキュリティの完全性は保証していない
JIS Q 15001 は「個人情報保護マネジメントシステム」の規格です。つまり、プライバシーマークが評価しているのは、個人情報を扱うための社内ルール・体制・運用の「仕組み」であって、ファイアウォール設定の堅牢性、暗号化の実装、Web アプリケーションの脆弱性対応といった技術的セキュリティ対策の完全性ではありません。
開発会社のサーバが堅牢かどうか、リリースするシステムにセキュリティ脆弱性がないかどうかは、Pマークだけでは判断できない領域です。
取得時点の体制を評価するもので、日常運用の完全性は別問題
プライバシーマークの審査は2年ごとに行われます。審査時点で体制が整っていることは確認されますが、その間の日常運用が常に基準を満たしているかどうかは別問題です。実際、プライバシーマーク取得企業による個人情報漏えい事例は毎年複数発生しています。
象徴的な事例として、プライバシーマーク制度の運営主体である JIPDEC 自身が、2023年に審査関連資料の漏えいを公表しています。プライバシーマーク審査員1名が、契約および規程に違反して個人所有のパソコンや外部記憶媒体に審査関連資料を保管しており、最大888社分の審査関連資料が外部から閲覧可能な状態となっていた、というものです（JIPDEC「プライバシーマーク審査関連資料の漏えいについて（第2報）」、日経クロステック「プライバシーマーク審査関連資料が漏洩、JIPDECが再発防止策を発表」）。
認証制度の運営者ですら漏えいを起こし得るという事実は、「Pマークを持っていれば絶対に漏えいしない」という考えが現実離れしていることを示しています。マークは「漏えいを起こさない保証」ではなく、「漏えいリスクを下げるための仕組みが整っている」ことを示すものに過ぎません。
委託先・再委託先までは認証範囲が及ばない場合がある
プライバシーマークの認証範囲は、原則として認証を取得した法人そのものです。その会社が業務を外部に委託する場合、再委託先や再々委託先まで Pマーク取得企業であるとは限りません。
開発の現場では、フリーランスへの再委託や、海外のオフショア開発拠点への一部委託が行われるケースが珍しくありません。委託先がPマーク取得企業であっても、再委託先がどう情報を扱っているかは、契約・運用レベルで別途確認する必要があります。
技術的脆弱性は審査対象外
繰り返しになりますが、プライバシーマークの審査は技術的脆弱性の検査ではありません。具体的には、以下の項目は基本的に Pマーク審査の対象外です。
- Webアプリケーションの脆弱性（SQLインジェクション、XSS など）
- インフラ・サーバの設定不備
- 通信経路の暗号化品質
- 認証・認可の実装品質
- ログ取得・監視の十分性
これらの技術的なセキュリティ品質を確認したい場合は、別途、脆弱性診断レポート、ペネトレーションテスト結果、セキュリティに関する開発標準の有無などを発注時に確認する必要があります。
認証は「最低限の体制」を示すものであり、業界水準を上回る安全性を意味しない
最後に、もうひとつ重要な観点として、プライバシーマークは「JIS Q 15001 の要求事項を満たす最低限の体制が整っている」ことを示します。業界水準を上回る卓越した安全性を保証するものではありません。
つまり、プライバシーマークの有無は「足切りライン」として機能しますが、「ここを超えていればどの会社も同等」というわけではありません。Pマーク取得企業のなかでも、運用品質や追加的なセキュリティ対策の充実度には大きな差があります。発注者の役割は、認証の有無を入口としつつ、その先で各社の運用品質を見極めることにあります。
個人情報を扱う開発委託時に発注者が確認すべきチェックリスト
ここまで読まれて、「では Pマークだけでは不十分とすれば、ほかに何を確認すればよいのか」という疑問を持たれたかもしれません。本セクションでは、認証情報に頼り切らず、発注者として確認すべき項目を「体制」「技術的対策」「運用」の3軸でチェックリストとして整理します。経済産業省・個人情報保護委員会のガイドラインを参考に、開発委託の文脈で実務的に必要な観点に絞っています。
委託先体制の確認項目
組織として個人情報保護に取り組む土台が整っているかを確認します。
- 個人情報保護方針が公表されているか（自社サイトに掲載されているか）
- 個人情報を取り扱う社内規程が整備されているか（プライバシーポリシーだけでなく、内部の取扱規程の存在）
- 個人情報保護責任者が任命されているか、責任分担が明確か
- 従業員に対する個人情報保護教育・研修が定期的に実施されているか
- プライバシーマーク・ISMS など第三者認証の取得状況（取得していなくても評価対象から外す必要はない。理由を確認する）
技術的対策の確認項目
実際にシステムを動かすうえでの技術的セキュリティ対策が整備されているかを確認します。
- アクセス制御の仕組み（最小権限の原則、特権アカウントの管理、ID/パスワード以外の認証の有無）
- 通信経路の暗号化（TLS の最新バージョンへの対応、内部通信の暗号化）
- データの暗号化（保管時の暗号化、バックアップデータの保護）
- ログ取得・監視の体制（アクセスログ・操作ログの保存期間、不正検知の仕組み）
- 脆弱性対応プロセス（OS・ミドルウェア・ライブラリの更新ルール、脆弱性診断の実施頻度）
- セキュア開発のガイドライン（コーディング規約、コードレビュー、SAST/DAST ツールの利用）
運用面の確認項目
契約後の日常運用において、リスクが管理されているかを確認します。
- 再委託の有無、再委託先の管理方法
- 委託先の従業員に対する誓約書・秘密保持義務の徹底
- インシデント発生時の連絡フロー、初動対応の手順書
- 開発・テスト環境での個人情報の取り扱い（本番データを使う場合のマスキング処理など）
- 契約終了時のデータ返還・削除のプロセス
認証 +α の評価方法
認証情報に加えて、発注者が独自に評価すべき要素もあります。
- 過去のインシデント実績: 過去に漏えい・障害事例がないか、公表事案を確認する
- 是正履歴: 過去に行政指導や認証取り消しを受けたことがないか
- 第三者監査・脆弱性診断の実施有無: 外部監査やペネトレーションテストの実施実績の有無
- 開発体制の透明性: 体制図・担当者・連絡経路を明確に開示できるか
これらは認証では直接見えない部分です。発注者として相手に問い合わせや RFP の項目に組み込むことで、認証の枠を超えた信頼性評価ができるようになります。なお、開発委託契約におけるセキュリティ条項の組み立て方はシステム開発委託のセキュリティ契約で詳しく解説しています。
発注契約書に入れるべき個人情報関連条項
認証情報とチェックリストで体制を確認したら、最後のピースは「契約書」です。万一インシデントが発生したときの責任関係や、想定外の利用を防ぐためのルールは、契約書面に明文化しておく必要があります。本セクションでは、業務委託契約書に最低限盛り込むべき個人情報関連条項を整理します。
目的外利用の禁止条項
委託の目的（システム開発・運用保守など）以外の用途で個人情報を利用しないことを明文化します。具体的には、社内マーケティング、別事業への流用、AI 学習データへの使用などを禁止する旨を盛り込みます。最近では、生成 AI のプロンプトに個人情報を入力する行為が現実的なリスクとなっており、この点を明示的に禁止する条項を追加するケースも増えています。
再委託の制限・事前承諾条項
委託先が業務の一部または全部を第三者に再委託する場合、発注者の事前の書面による承諾を必要とする条項を盛り込みます。承諾の対象（再委託先の名称・所在地・業務範囲）を明示させ、再委託先にも委託先と同等の義務を課す旨を明記します。フリーランスやオフショア事業者への再委託が発生する開発案件では、特に重要な条項です。
安全管理措置の具体的義務化条項
個人情報保護法第23条が定める「安全管理措置」を、契約上の義務として具体化します。たとえば、以下の要素を盛り込みます。
- アクセス制御・通信暗号化など技術的安全管理措置の実施
- 取扱者の限定・教育など人的安全管理措置の実施
- データ保管場所の物理的安全管理措置の実施
- 委託先内部での運用ルール（組織的安全管理措置）の整備
漏えい等発生時の通知・報告義務
万が一、個人情報の漏えい・滅失・毀損などのインシデントが発生した場合の通知義務を明文化します。具体的には、以下の項目を含めます。
- 発覚から発注者への通知までの時間（例: 発覚後24時間以内）
- 通知に含めるべき情報の範囲（発生日時、漏えい件数、原因、対応状況）
- 関係機関（個人情報保護委員会・本人）への報告・通知の主体と費用負担
- 損害賠償の範囲（直接損害・間接損害の取り扱い）
個人情報保護法では、一定規模以上の漏えい事案について、個人情報保護委員会への報告と本人への通知が義務化されています（個人情報保護委員会「漏えい等の報告等」）。契約段階で報告ルートを明確にしておくと、いざという時の対応がスムーズになります。
契約終了時のデータ返還・削除条項
契約終了時に、委託先が保有する個人情報の取り扱いを明確にします。具体的には、以下のいずれか、または両方を選択できるようにします。
- 発注者への返還
- 委託先での完全削除（バックアップを含む）
- 削除完了報告書の提出
特に、クラウドサービスを利用した開発の場合、バックアップデータが各種ストレージに残存しがちです。「すべての媒体からの削除」と「削除完了の証明」を契約上明確にしておきます。
監査権・立入検査権条項
発注者が必要に応じて、委託先に対する監査や立入検査を実施できる権利を明文化します。具体的には、以下の要素を盛り込みます。
- 監査の頻度（年1回など）と費用負担
- 監査の範囲（個人情報の取扱記録、安全管理措置の実施状況、再委託先への管理状況など）
- 突発的なインシデント発生時の臨時監査権
実際に毎年監査を実施するかどうかは別として、「権利として確保しておく」ことが、委託先の運用に対する牽制効果を持ちます。
なお、個人情報の取り扱いだけでなく、開発委託全体における秘密保持の枠組みを整える観点では、NDA（秘密保持契約）の実務知識もあわせて確認しておくと、契約全体の整合性が取りやすくなります。
まとめ — 認証は「入口」、安全な発注は「多層的確認」で実現する
プライバシーマークとは、JIPDEC が運営する第三者認証で、事業者の個人情報保護マネジメントシステムが JIS Q 15001 の基準を満たしていることを示すものです。発注者にとっては、相手企業の体制を一定水準でスクリーニングできる便利な指標であり、委託先監督義務を果たす上での説明材料にもなります。
一方で、プライバシーマークは「マネジメントシステムの認証」であって、技術的セキュリティの完全性、日常運用の完璧さ、再委託先までの安全性を保証するものではありません。認証制度の運営者である JIPDEC 自身が漏えいを公表した事実が示すように、「マークがあれば絶対に安全」という考えは現実離れしています。
個人情報を扱うシステムを発注する立場で重要なのは、認証を入口の足切りラインとして活用しつつ、その先で「体制・技術的対策・運用」を多角的に確認し、契約書で責任関係を明文化することです。
- 入口: プライバシーマーク・ISMS など第三者認証で最低限の体制を確認する
- 本選定: チェックリストで体制・技術的対策・運用の3軸を具体的に確認する
- 契約: 目的外利用禁止・再委託制限・安全管理措置・通知義務・データ返還・監査権を契約書に明文化する
この三層構造で発注先を見極めることが、個人情報を扱う開発委託のスタンダードです。プライバシーマークに対する過度な期待と漠然とした不安の両方から離れ、認証を冷静に「使いこなす」発注プロセスを設計していただければ幸いです。
失敗しないためのアプリ開発の考え方と開発パートナー選定チェックリスト
この資料でわかること
アプリ開発（スマートフォンアプリ・Web アプリ）の発注・開発を検討している企業の担当者が、開発パートナーを選ぶ際に「何を確認すべきか」「どのような観点で比較すべきか」を体系的に把握できる実践的なチェックリストを提供する。
こんな方におすすめです
- アプリ開発を検討しているが失敗したくない
- 開発パートナーの選び方が分からない
- アプリの形式選定やUI/UX設計の確認ポイントを知りたい
入力いただいたメールアドレスにPDFをお送りします。
