「社内では脱PPAPを進めているのに、開発ベンダーから届く見積書は今もパスワード付きZIPのまま」──こうした違和感を抱えたまま、次のシステム開発発注に向けたRFPを書き始めていないでしょうか。
社内運用の切り替えは、ツールを導入して社員教育を回せば形になります。しかし外部ベンダーとのやりとりは相手側の慣習・ツール環境・契約条件が絡むため、発注者だけでは統制しきれません。要件書、設計書、DB dump、ソースコード、テストデータといった機微度の高い情報が、脱PPAP方針の外側で動いてしまうリスクがあります。
一方で、外部委託時の情報漏えいは発注者側の管理責任にもつながります。個人情報保護法は委託先の監督義務を定めており、IPAが公表する「情報セキュリティ10大脅威 2026」でも「サプライチェーンや委託先を狙った攻撃」が組織向け脅威の上位に位置づけられています。「社内は脱PPAPだが、委託先はPPAPのまま」という状態は、監査上もリスク管理上も放置できない論点です。
本記事では、脱PPAP（PPAP廃止）の概要をおさらいしたうえで、システム開発の発注実務でベンダーに何を確認し、RFP・契約書・キックオフ・運用ルールにどう落とし込めばよいのかを、そのまま自社テンプレートに転用できるチェックリスト形式で解説します。読み終えたときには、次のベンダー打ち合わせで「うちの脱PPAP方針に合わせて、どのツールでどう授受するか合意させてください」と、根拠を持って言えるようになっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
脱PPAP（PPAP廃止）とは？システム開発でも問われる理由
まずは脱PPAPの前提となる用語と、政府・大手企業の動向を短く整理し、そのうえで「なぜシステム開発の発注時にも脱PPAPが問われるのか」を確認します。
PPAPの仕組みと「なぜ広まったか」の背景
PPAPとは、メールでファイルを送る際に次の手順を踏むやり方の総称です。
- Password付きZIPファイルを送る
- Passwordを（同じメール経路で）送る
- Angoka（暗号化）
- Protocol（プロトコル）
この命名は、日本情報経済社会推進協会（JIPDEC）に在籍していた大泰司章氏が、2016年頃にピコ太郎の「PPAP（ペンパイナッポーアッポーペン）」の響きから着想して名付けたものとされています（週刊BCN+「『PPAP』は何の略語？ JIPDECの大泰司氏が命名」）。
日本でPPAPが広まった背景には、「暗号化してからパスワードを別送すれば安全」という認識と、上場企業が求められた情報セキュリティ内部統制の実務対応がありました。しかし後述するとおり、実際にはパスワードもZIPも同じ経路（メール）を通るため、盗聴時にセットで奪われるという構造的な弱点を抱えたまま、慣習として定着してしまいました。
政府・大手企業が進める脱PPAPの潮流
脱PPAPの流れは、2020年11月17日の平井卓也デジタル改革担当大臣（当時）の記者会見で加速しました。同大臣は同月24日の会見で、内閣府と内閣官房においてPPAPを11月26日に廃止すると発表しています（日経クロステック「平井大臣が宣言した『脱PPAP』がベンチャーで加速」）。
以降、金融業界でも動きが広がりました。2025年5月には、金融庁が金融機関に対しパスワード付きZIPファイルの電子メール送付慣行を改めるよう要請したことが報じられています（ニッキンONLINE「金融庁、PW付きメール送信 利用廃止呼びかけ」）。三菱UFJ銀行などの個別の金融機関もPPAP原則廃止を打ち出しており（ITmedia「三菱UFJ、PPAP廃止計画『以前からあった』 今になって実施の経緯は」）、金融業界を起点に取引先である一般企業への波及も進んでいます。
こうした潮流のなかで、大企業や金融機関は自社だけでなく取引先にも同水準のセキュリティを求めるようになっています。中堅・中小企業にとっても、他人事ではありません。
システム開発の発注時に脱PPAPが問われる3つの理由
社内の脱PPAPが進んでも、システム開発をベンダーに発注している間に扱う情報は、次の3つの観点で特別な意味を持ちます。
- 授受する情報の機密性が高い: 要件書に書かれた業務ロジック、設計書に含まれるDBスキーマ、開発中のソースコード、動作確認用に共有するテストデータ（本番相当を含む場合がある）は、いずれも漏えい時のインパクトが大きい情報です
- 委託先の管理責任が発注者に残る: 個人情報保護法第25条は、個人データの取扱いを委託する事業者に「委託先に対する必要かつ適切な監督」を義務付けています（個人情報保護委員会FAQ）。委託先で情報漏えいが起きた場合、報告義務や説明責任は発注者側にも及びます
- 監査・取引先審査の対象になる: セキュリティ監査や大手取引先からの委託先審査では「外部委託先とのファイル授受手段が定義され、運用されているか」が確認項目に含まれるケースが増えています。ここで「ベンダーからPPAPで受け取り続けている」と回答すると、監査指摘・取引先審査での減点につながります
つまり、社内脱PPAPだけでは不十分で、「発注時に何を確認し、契約でどう縛り、開発中どう運用するか」までを整えて初めて、脱PPAPは「意味のある取り組み」として完成します。
PPAPの何が問題か──システム開発現場で顕在化するリスク
一般論としてのPPAPの問題は多くの記事で解説されていますが、システム開発の発注実務では、そこにさらに固有のリスクが重なります。ここでは両方の視点で整理します。
PPAPそのものが持つセキュリティ上の欠陥
PPAPが「意味がない」と言われる主な理由は、次の4点です。
- パスワードもZIPも同じ経路（メール）を通る: 経路上で盗聴される場合、ZIPとパスワードは同じ経路にあるためセットで奪われます。「経路の暗号化」にはならず、単に手間だけが増えます
- ウイルス対策製品による検査を回避してしまう: ZIP暗号化された添付ファイルは、受信側のアンチウイルス・DLP（情報漏えい防止）製品で中身を検査できません。マルウェア混入ファイルの検知を「暗号化」が阻害する構図です（Emotetがこの構造を悪用したことで、PPAPの弱点が広く知られました）
- 誤送信時のリカバリが困難: 宛先を誤った場合、パスワードメールも同じ相手へ届くのが一般的です。「宛先を間違えたことに気付いてパスワードを送らなければ大丈夫」という運用は、多くの現場で徹底されていません
- 受信側の生産性を下げる: パスワード解凍・保管・共有の手間が受信側にも発生します。特に多数のベンダー・顧客を抱える発注担当者ほど、蓄積コストは無視できません
システム開発の受託・委託で流れる情報の機密性
システム開発の授受で扱う情報は、日常業務の書類とは性質が異なります。
情報種別 | 主な内容 | 漏えい時のインパクト例 |
|---|---|---|
要件書・業務フロー図 | 発注者側の業務ロジック、経営指標の定義 | 業務ノウハウ・競争優位が競合に流出 |
設計書・DB スキーマ | テーブル定義、認証設計、外部連携仕様 | 攻撃者に内部構造のヒントを与える |
ソースコード | アルゴリズム、認証・暗号キー、外部API 呼び出し | 直ちに攻撃コード化される可能性 |
認証情報・秘密鍵 | 開発用IDとパスワード、APIキー、証明書 | 即時の不正アクセス被害に直結 |
テストデータ | 本番相当の個人情報・取引データを含むことがある | 個人情報漏えい事故として報告義務が発生 |
議事録・打ち合わせ資料 | プロジェクトの意思決定過程、体制情報 | 交渉上の弱点が外部に流れる |
このように、システム開発で授受するファイルは「一度漏れると事後回復が困難」なものが多く、通常のオフィス文書と同じ感覚でPPAPに載せてしまうと、被害範囲を自ら広げてしまいかねません。
発注者が負う管理責任と法的リスク
外部委託しても、発注者側の責任がゼロになるわけではありません。押さえておきたいポイントは次のとおりです。
- 個人情報保護法上の委託先監督義務: 前述のとおり、個人データを扱う開発を委託する場合、発注者側に「適切な選定」と「必要かつ適切な監督」の義務があります。委託先でPPAP経由の漏えいが発生すれば、発注者側にも報告義務や説明責任が及びます。発注者側の情報セキュリティ管理体制の基礎は発注者のためのITガバナンスと情報セキュリティ基礎でも整理しています
- サプライチェーン攻撃のリスク: IPA「情報セキュリティ10大脅威 2026」では「サプライチェーンや委託先を狙った攻撃」が組織向け脅威の上位に位置づけられています（IPA「情報セキュリティ10大脅威 2026」）。攻撃者は本命の発注者を直接狙わず、セキュリティが手薄な委託先ベンダーを踏み台にする傾向が続いています
- 契約・下請管理上の観点: 業務委託契約・秘密保持契約（NDA）で情報の取り扱いを明確にしておかないと、事故発生時の責任分界が不明確になり、費用負担・法的対応で長期化しがちです
「委託したから責任はベンダー側」という整理は現実には成立しません。だからこそ、発注者側から能動的にファイル共有ルールを設計する必要があります。
脱PPAPの代替手段──システム開発の授受にはどれを使うか
脱PPAPの代替手段は、大きく5カテゴリに整理できます。ここではシステム開発の授受シーンに紐づけて「どれを何に使うか」まで踏み込んで解説します。
代替手段の主要カテゴリ（早見表）
カテゴリ | 代表例 | 主な用途 |
|---|---|---|
クラウドストレージ | Box、Microsoft OneDrive / SharePoint、Google Drive | 要件書・設計書・議事録などの文書共有 |
法人向けファイル転送サービス | GigaCC、DirectCloud、SmoothFile ほか | 大容量・単発の受け渡し、社外との一時共有 |
チャット／コラボレーションツール | Slack、Microsoft Teams | 打ち合わせ中の即時共有、雑談添付、通知連携 |
ソースコード共有プラットフォーム | GitHub、GitLab、Bitbucket | ソースコード、CI/CD 設定、Issue／PR 管理 |
セキュアメール／メール暗号化 | S/MIME、経路暗号化（TLS 強制） | 契約書などメール本文で完結させたいやり取り |
これらを「全部導入する」必要はありません。ポイントは、次項のように授受シーン別に第一選択を決めておくことです。
システム開発の授受シーン別の適材適所
システム開発では、開発フェーズごとに扱う情報の種類が変わります。授受シーンごとに「どのツールを使うか」を決めておくと、現場での判断コストが下がります。
授受シーン | 推奨ツール（第一選択） | 補足 |
|---|---|---|
要件書・提案書・見積書のやりとり | クラウドストレージ（共有リンク、閲覧権限つき） | メール本文にリンクを貼り、パスワード別送は不要 |
設計書・議事録・課題管理表 | クラウドストレージ、または PM／課題管理ツール | ベンダーと発注者のどちらが主管するか事前合意 |
ソースコード | GitHub / GitLab のプライベートリポジトリ | メール添付・ZIP 送付は原則禁止。IP 制限や SSO も検討 |
DB スキーマ・テストデータ | クラウドストレージ（強い権限管理）または専用ファイル転送サービス | 本番データを含む場合はマスキング要否をルール化 |
打ち合わせ中の一時共有・雑談添付 | チャットツール（Slack／Teams） | チャンネル権限・ゲストアカウントの整理が前提 |
契約書・NDA 等の締結書類 | 電子契約サービス（クラウドサイン、DocuSign 等） | 本人性・非改ざん性・保存性が担保できるため PPAP より安全 |
これらは「発注者が指定する」ケースと「ベンダーが用意する」ケースの両方があります。次項でその整理を行います。
発注者・ベンダーどちらのアカウントを主にするか
代替ツールを使うと決めた後に必ず論点になるのが、「発注者・ベンダーどちらのテナント／アカウントを主にするか」です。次の観点で決めるとスムーズです。
- アクセスログの管理主体: 監査対応で「誰がいつ何を見たか」を出す必要がある側が主テナントを持つのが原則。多くの場合は発注者側
- プロジェクト終了後の情報保管: 納品後にファイルを保持し続けるべき側が主テナントを持つ
- セキュリティポリシー適合: 発注者側で SSO・IP 制限・DLP を適用している場合、発注者テナントに集約する方が統制しやすい（SaaS ベンダー側のセキュリティ体制評価にはSOC2レポートとクラウドセキュリティが参考になります）
- 利用ライセンスの負担: 発注者テナントにゲスト招待する場合、ゲスト分のライセンス費や制限を事前に把握しておく
「うちがBoxを提供するので、御社担当者は招待メールでアクセスしてください」「ソースコードは弊社GitHub Organizationのプライベートリポジトリで管理させてください」など、発注者側が主導して合意しておくと、後の運用がぶれません。
システム開発発注時に脱PPAPを実現する確認チェックリスト
ここが本記事の核となる章です。発注者がベンダー選定〜契約〜キックオフまでに確認・要求すべき事項を、そのまま自社テンプレートに転用できる粒度でまとめます。
ベンダー選定時の確認チェックリスト（10項目）
RFI／RFP の質問票、あるいはベンダー面談時の確認シートに次の項目を組み込むことを推奨します。
# | 確認項目 | 期待する回答の例 |
|---|---|---|
1 | 貴社では PPAP を廃止（または方針決定）していますか | 廃止済み。◯年◯月以降、送信・受信ともに社内標準ツールに移行 |
2 | 顧客との標準ファイル授受手段は何ですか | クラウドストレージ（Box、OneDrive 等）／ソースは GitHub |
3 | 顧客指定ツールへの合わせ込みは可能ですか | 可能。当社アカウントを発行しゲストアクセス、または顧客テナントへ参加 |
4 | アクセス権限・共有リンクの発行ルールはありますか | 案件単位でフォルダを分離、期限付きリンク、ダウンロード可否管理 |
5 | 端末側のマルウェア対策・EDR は導入済みですか | 全社導入済み。定義更新・パッチ管理も一元化 |
6 | 監査ログの取得・提示は可能ですか | 主要ツールでアクセスログを取得。顧客要請時に開示可能 |
7 | 退職者・異動者のアカウント処理はどう運用していますか | 退職・異動当日に無効化、ID 棚卸しを◯ヶ月ごとに実施 |
8 | 再委託の予定はありますか。その場合の管理体制は | 再委託は事前承認制。再委託先にも同水準のセキュリティ要件を課す |
9 | フリーランス／個人事業主を活用する場合の統制は | 契約書で同水準の義務を課し、支給端末または管理された環境のみ利用 |
10 | セキュリティインシデント発生時の連絡体制・SLA は | ◯時間以内に一次報告、◯時間以内に影響範囲の報告、報告経路は◯◯ |
10項目すべてが揃わないベンダーを一律に落選させる必要はありませんが、「未整備」の回答が3項目以上ある場合、キックオフまでに合意する条件として明文化しておくと安全です。
RFP／提案依頼書に含めるべき記述例
RFP に書いておくと、提案書段階でベンダーが自社の運用を明示せざるを得なくなります。RFP に盛り込むセキュリティ要件全般の書き方はセキュリティ要件の書き方ガイドも参考にしてください。以下は、そのまま流用できる例文です。
- 授受手段の指定: 「本件に関する情報の授受は、原則としてパスワード付きZIPファイルのメール添付（いわゆるPPAP）を禁止し、当社が指定するクラウドストレージ、または当社と合意したファイル共有手段のみを使用すること」
- アカウント発行・権限管理: 「当社が指定する場合、貴社の担当者に対して当社テナント上のアカウントを発行する。貴社は担当者の入退場を速やかに当社に通知し、当社は当該アカウントの権限変更・無効化を行う」
- アクセスログ提示義務: 「本件で授受した情報について、当社の要請があった場合、直近◯ヶ月分のアクセスログを速やかに提示すること」
- 再委託の事前承認: 「本件業務の再委託は当社の事前書面承認を要する。再委託先にも本要件と同水準以上のセキュリティ運用を課すこと」
- インシデント時の報告: 「情報漏えい・その恐れがある事象を認識した場合、認識から◯時間以内に当社所定の窓口に第一報を行い、事実関係・影響範囲・是正措置を段階的に報告すること」
契約書（NDA／業務委託契約）に含めるべき条項例
RFP レベルの記述に加えて、契約書側にも明文化しておくと後日の紛争予防になります。システム開発の外部委託とセキュリティ契約全般の考え方はシステム開発の外部委託とセキュリティ契約で解説しています。実際の条項化は法務チェックを前提としつつ、盛り込みたい観点は以下のとおりです。
- 授受手段の限定: 情報の授受手段を発注者指定または双方合意のクラウドサービスに限定する条項
- アクセス権限管理義務: 案件担当者以外に不必要な閲覧権限を付与しない義務、退職・異動時のアクセス権限解除義務
- 監査ログ・監査受入れ: 発注者が求めた場合の監査ログ提示義務、書面またはリモートによる監査を受け入れる義務
- 再委託時の同等義務履行: 再委託先に本契約と同等以上の秘密保持・セキュリティ義務を課す義務、および再委託先の遵守について受託者が責任を負う旨
- 違反時の是正措置・損害賠償: 違反時の是正期限、契約解除条件、直接損害・逸失利益の扱いに関する条項
- 返却・削除義務: 契約終了時のデータ返却・削除およびその証跡提出義務
上記はセキュリティ観点に絞ったサンプルであり、実運用にあたっては自社の秘密保持契約雛形・業務委託契約雛形の該当条項の見直しと、法務部門・顧問弁護士による確認を推奨します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
発注後・開発期間中の脱PPAP運用ルール
契約締結だけでは脱PPAPは維持できません。実際に開発が動き始めた後、現場でどう回すかまで設計してこそ実効性が担保されます。
キックオフで合意しておく授受ルール
キックオフミーティングは、双方の運用ルールを揃える最良のタイミングです。次の項目を議事録に残しておきます。
- 標準ツール: どのクラウドストレージ・チャット・コード共有ツールを主に使うか
- 代替手段: 標準ツールが使えない場合の代替（例: 発注者側で外部SaaS利用に制限がある場合の対応）
- 命名規則とフォルダ構成: 案件名・年月・フェーズを含んだ命名ルール
- アクセス権限の付与単位: フォルダ単位か案件単位か、ゲストの追加・削除フロー
- 保管期間と削除タイミング: プロジェクト完了時、契約終了時のデータ返却・削除の期日
- PPAP メール受領時の対応方法: のちほど紹介する「切り替え提案」テンプレートを両社で共有
開発フェーズ別に扱うファイルとセキュリティレベル早見表
フェーズごとに扱うファイル種別と、推奨される授受方法・注意点を整理します。
フェーズ | 主な授受ファイル | 推奨授受方法 | 特に注意すべきポイント |
|---|---|---|---|
要件定義 | 業務要件書、機能一覧、ユースケース | クラウドストレージ | 業務ロジックの機密性が高い。閲覧者を最小限に |
基本設計 | 画面設計書、DB 設計書、外部連携仕様書 | クラウドストレージ | DB スキーマ・認証設計は攻撃者の関心対象 |
実装 | ソースコード、CI/CD 設定、シークレット | Git ホスティング + 秘密情報は別管理 | 認証情報は決してリポジトリに置かない |
テスト | テストデータ、テスト結果、バグ票 | クラウドストレージ、課題管理ツール | 本番相当データはマスキング／匿名化を検討 |
リリース | リリース手順書、切替設計、緊急連絡先 | クラウドストレージ + チャット通知 | 実行者・時間帯・影響範囲を明確に |
保守 | 障害報告書、ログ、追加開発の要件書 | 保守用チャネル + クラウドストレージ | 契約範囲外の情報流入を防ぐルールを持つ |
ベンダーから PPAP メールが届いたときの切り替え提案テンプレート
キックオフで合意しても、現場では慣習でパスワード付きZIPが送られてくることがあります。受け取り拒否だけでは関係が悪化するため、「切り替え提案」の返信テンプレートを用意しておくと、担当者間で気まずくならずに移行を進められます。
以下は返信文面のサンプルです。実際の宛先・案件名・ツール名は自社の運用に合わせて調整してください。
◯◯様
お世話になっております。◯◯（発注者名）の◯◯です。 ◯◯（ファイル種別）をお送りいただきありがとうございます。
弊社のセキュリティ方針により、パスワード付きZIPファイルの授受を廃止する運用に移行しております。恐れ入りますが、以下のいずれかの方法で再度お送りいただけますでしょうか。
- 弊社◯◯（クラウドストレージ名）フォルダへのアップロード（招待リンクは別途送付いたします）
- 貴社にて共有リンクを発行いただき、閲覧権限を◯◯@◯◯.co.jp 宛にご付与いただく方法
引き続きスムーズに進行できるよう連携させていただければ幸いです。ご不明点があればお気軽にお知らせください。
────────── 発注者名／担当者名／連絡先
このテンプレートを、社内 Wiki やベンダー窓口担当のマニュアルに載せておくと、担当者による対応のばらつきを防げます。
再委託・オフショア・フリーランス活用時の追加確認事項
近年は、ベンダー内での再委託や、オフショア開発拠点・国内フリーランスの活用が一般的です。それぞれで確認すべきポイントを追加で整理します。
- 再委託先の統制: 発注者側から見える窓口はベンダー1社でも、実作業を再委託先が担う場合があります。契約上の再委託承認プロセスに加え、実務では「再委託先の担当者は発注者テナントに直接ゲスト参加するのか、ベンダー側で情報を仲介するのか」を明確にしておきます
- オフショアの拠点別ルール: 拠点国のインターネット環境・ローカル法制によっては、日本側と同じツールが使えないケースがあります。標準ツールが利用可能か、代替として何を使うかを事前に確認します
- フリーランス／個人事業主: 個人 PC を使うケースが多いため、業務専用の作業環境（VDI、支給端末、専用アカウント）を要求するか、業務終了時のデータ削除フローを契約に含めるかを整理します
- 端末とアカウントの分離: 「誰の端末で」「どのアカウントで」作業するかを明確にすることで、退場時の権限剥奪と情報回収がスムーズになります
「発注しているのはベンダー1社」でも、実際に情報を触るのは複数の会社・複数の個人であるという前提で設計しておくと、後から「そこは想定していなかった」という穴を減らせます。
脱PPAP導入で起きやすい落とし穴と現実的な対処
ここまで理想的な運用像を描いてきましたが、現場で脱PPAPを進めると、必ずと言っていいほど「相手が対応できない」「代替手段側で新しい問題が起きる」といった壁に当たります。ここでは実務で頻出する4つの落とし穴と、それぞれの現実的な対処法を整理します。
開発ベンダー・取引先が脱PPAPに対応できない場合の暫定策
「うちはPPAPを廃止しました。今後はクラウドストレージでお願いします」と伝えても、相手側の情シスがそれを許可していない、あるいは客先ごとの個別対応にコストを割けない、というケースは珍しくありません。この場合に検討したい暫定策は次のとおりです。
- 発注者側テナントへのゲスト招待: ベンダー側で新規SaaSを契約する必要がなく、ブラウザで招待リンクを開くだけで参加できる形にする。導入摩擦がもっとも小さい選択肢です
- 暗号化ストレージリンク併用: 一時的にPPAP相当の運用が残る場合でも、パスワードは電話・SMS・別ドメインのチャットなど「メール以外の経路」で伝達するよう合意する。完全な脱PPAPには届きませんが、経路分離だけでも一定のリスク低減になります
- S/MIME やパスワードマネージャ連携: メール本文の暗号化を S/MIME で担保する、パスワード共有を専用サービス（1Password、Bitwardenなど）経由に置き換える、といった方法もあります。ただし双方の運用負荷が上がるため、短期の過渡措置と割り切ります
- 切り替え提案テンプレートの送付: 先ほど紹介した返信テンプレートを応用し、ベンダー側のIT部門にも回覧できる形で「発注者としての要望書面」を送る。担当者ベースの交渉から、組織対組織の合意形成に持ち上げる打ち手です
いずれも「暫定策」であることを明示し、いつまでに正規の代替手段へ移行するかの期日を合意しておくと、放置されるリスクを避けられます。
社内の心理的抵抗と一時的な二重運用の乗り切り方
脱PPAPは「今までのやり方を変える」プロジェクトなので、社内側にも心理的抵抗が生じます。特に発注担当者や営業担当が「取引先に手間をかけさせるのが申し訳ない」と感じ、こっそりPPAPに戻してしまうケースは少なくありません。
対処のポイントは次のとおりです。
- 経営メッセージとして明文化する: 「セキュリティポリシー上、PPAPは廃止方針である」旨を経営層や情シス責任者名で通達し、担当者個人の判断で運用を変えられない状態にします
- 二重運用期間を明示する: 「◯月◯日までは移行期間として、暫定策も許容する」といった期日を切り、それ以降は例外承認制にします。あいまいな移行期は長引きやすいので注意します
- 成功事例の社内共有: 「A案件のベンダーは切り替え提案で1週間以内に代替手段に対応してくれた」といった成功事例を社内で共有し、担当者の不安を軽減します
- PPAP受領時の窓口を情シスに集約する: 現場の営業や発注担当が個別に返信するのではなく、情シスの窓口が代表して切り替え提案を送る運用にすると、対応品質がそろい、担当者の心理的負担も減ります
代替手段側の権限管理不備・アクセスログ未整備のリスクと最低ラインの設定
「脱PPAPを進めた結果、クラウドストレージ側での権限設定が甘く、そこから漏えいした」というのは、現場で起きやすいパターンのひとつです。代替手段への切り替えは、単にツールを変えることではなく「情報漏えい防止の対策面を再設計する」ことでもあります。次の最低ラインは押さえたいところです。
- 共有リンクの発行ルール: 「誰でも閲覧可」のリンクを禁止し、招待制または期限付きリンクに限定します
- アクセス権限の見直しサイクル: 案件単位で権限を付与し、フェーズ移行時・退場時に必ず棚卸しをおこないます
- アクセスログの取得と保管: 主要ツールでログ取得を有効化し、契約に基づいて◯ヶ月〜◯年保管します
- DLP／情報漏えい防止機能の有効化: 大量ダウンロード検知、社外共有のアラート、機微データの自動分類など、契約プランに含まれる機能を必ず有効化します
- 端末側の対策との連動: EDRやMDMで管理された端末以外からのアクセスを制限する、ゼロトラスト的な設計を段階的に導入します
「PPAPよりは安全」で満足せず、代替手段側でどこまでのリスクを許容するかを、脱PPAP導入時にセットで整理してください。
移行後に定期的に見直すべきチェックポイント
脱PPAPは一度導入したら終わり、ではありません。時間経過とともに「例外運用が定常化する」「新規参加者が旧来の運用を持ち込む」などのゆるみが生じます。半期または年次で次のチェックポイントを回すことを推奨します。
- 半期棚卸し: 発注テナント上のゲストアカウント一覧、退場済み担当者の残存アカウント、共有リンクの棚卸し
- アクセスログレビュー: 通常業務時間外のアクセス、不審な大量ダウンロード、意図しない外部共有の兆候をチェック
- 例外運用の棚卸し: PPAPを暫定的に許容している取引先・案件のリストを更新し、正規化の期限を再確認
- 契約書・RFP テンプレートの見直し: 直近のセキュリティ動向・法改正を反映して、条項や記述例をアップデート
- 社内ルールの周知: 新規入社者・新規プロジェクト参画者向けに、脱PPAPの背景・運用ルールを説明する機会を設ける（中小企業ならではのセキュリティ対策の全体像は中小企業のセキュリティ対策も参考になります）
これらは「セキュリティ運用のPDCA」の一部として、情シスや情報セキュリティ委員会の定期業務に組み込むと定着しやすくなります。
まとめ──脱PPAPは「社内運用」と「発注実務」の両輪で完成する
本記事のポイントを3つに絞ります。
- PPAP はシステム開発現場でも大きなリスク源になる: 授受される情報の機密性が高く、発注者側にも委託先監督責任・サプライチェーンリスクが及ぶ
- 発注実務では「確認事項・契約条項・運用ルール」の3点セットで縛る: RFP・NDA・業務委託契約・キックオフ議事録に、授受手段・権限管理・監査・再委託・インシデント報告の観点を明文化する
- 社内脱PPAPと発注時の脱PPAP要求は両輪で回す: 社内だけ変えてもベンダー側が旧来のままでは、経路上のリスクは残り続ける
これから取り組む具体的な次アクションとしては、次の3つが有効です。
- RFP・提案依頼書テンプレートに「ファイル共有セキュリティ」セクションを追加する: 本記事の RFP 記述例をベースに、自社版として整備しておくと次案件からすぐ使えます
- 既存の主要ベンダーに再合意を打診する: 進行中プロジェクトのベンダーに対して、キックオフ済みであっても「今後の授受手段を再確認したい」と切り出し、標準ツールへの切り替えを進めます
- セキュリティポリシー・情報取扱規程を見直す: 社内文書に「外部委託先との授受手段」を明記し、監査時に説明しやすくします
脱PPAP は「メール添付をやめる」という表面的な話ではなく、外部委託を含めた情報の流れを整えるプロジェクトです。社内運用と発注実務のどちらも整えて初めて「意味のある脱PPAP」になります。次のベンダー打ち合わせから、本記事のチェックリストを1枚持ち込んでみてください。
関連情報
外部委託の情報セキュリティに関する実務資料や、システム開発のご相談窓口をご案内します。
外部委託・システム開発のセキュリティ設計を体系的に押さえたい方は、お役立ち資料一覧 から関連ガイドをダウンロードいただけます。RFP テンプレート・チェックリストなど、自社で活用しやすい資料をまとめています。
自社のセキュリティ方針に沿って外部開発ベンダーを選定・管理したい方や、RFP・契約書のセキュリティ条項を整えたい方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- ベンダーが脱PPAPに対応してくれない場合、発注自体を見送るべきですか？
一律に見送る必要はありません。発注者側テナントへのゲスト招待など相手側の導入負担が小さい暫定策を提示し、正規手段への移行期日を契約書や覚書で合意したうえで発注を進めるのが現実的な対応です。移行が進まない場合は再協議の期限も併せて決めておきましょう。
- 脱PPAPの取り決めは、どの書類に書けばよいですか？
RFPで授受手段の方針を明示したうえで、正式にはNDAや業務委託契約に「授受手段の限定」「アクセス権限管理」「監査ログ提示義務」などの条項として明文化するのが基本です。契約締結後はキックオフ議事録にも運用ルールとして残しておくと後々の齟齬を防げます。
- 中小企業がベンダー（特に大手）に脱PPAPを要求しても対応してもらえますか？
発注者として要求すること自体は問題ありません。発注者側テナントへのゲスト招待など相手側の導入負担が小さい方法を提示すれば、規模の大小に関わらず合意を得やすくなります。対応が難しい場合は移行期日を区切った暫定策も検討してください。
- 代替手段が複数あって迷います。まず何から導入すればよいですか？
まずは要件書・設計書などの文書共有をクラウドストレージに一本化するのが第一歩です。そのうえでソースコードはGit、契約書は電子契約サービスというように、授受シーンごとに使い分けを広げていくと現場の混乱を抑えられます。
- 委託先がPPAPのまま情報漏えいを起こした場合、発注者の責任はどこまで及びますか？
個人情報保護法上、委託先の監督義務は発注者側にあるため、報告義務や説明責任が発注者にも及ぶ可能性があります。契約書に監督・監査条項を定め、アクセスログの提示義務を課しておくことがリスク低減につながります。
