この記事はギガワタス（giga-watasu.jp）の運営ブログです。ファイル転送サービス運営者として、法人ユーザーから実際に寄せられる規程相談の傾向を踏まえて書いています。記事末尾にそのまま社内回覧できるルールひな型を公開しています。最終確認日: 2026年5月16日。
「PPAPを廃止したけど、社内のファイル送付ルールはどう書けばいい？」「中小企業でもISO/IEC 27001並みの規程が必要なのか？」——ファイル転送の社内ルール作りは、情シス・総務・経営者の悩みどころです。
結論を3行で。①PPAP廃止後の規程テンプレは中小企業ほど不足しており、現場の判断任せで漏洩リスクが残ります。②必須7要素（利用サービス指定／機密度区分／パスワード強度／保存期間／PPAP禁止／送信前確認／事故報告フロー）を網羅すれば「ファイル送受信」に絞った最低ラインの規程が成立します。③本記事末尾に、コピペで使える「ファイル転送取扱規程」のひな型を中小企業向け（5項目）とフル版（7要素＋細則）の2バリエーション公開します。なお、ISO/IEC 27001:2022認証取得を目指す場合は本記事の範囲を超える管理策対応（責任者権限・記録保存・例外承認・委託先管理・アクセス権限レビュー等）が必要なので、本記事はその前段の運用基盤づくり用としてお使いください。
なぜファイル転送の社内ルールが必要か｜3つの理由
「うちは小さい会社だから不要」と思われがちですが、社内ルールがないと次の3つのリスクが残ります。
理由1：個人情報保護法の漏洩報告義務
2022年4月施行の改正個人情報保護法により、個人データの漏洩等が発生した場合、個人情報保護委員会への報告と本人通知が義務化されました。具体的には、個人情報保護法ガイドライン（通則編）に基づき、速報は事案を知った後速やかに（おおむね3〜5日以内）、確報は30日以内（不正アクセス等の場合は60日以内）に報告するとされています（詳細はPPC公式の漏えい等の対応ページを参照）。ガイドラインは「組織的安全管理措置」として取扱規程の策定・責任者の設置・報告連絡体制の整備まで求めており、ルールの不在は法的にも不利になります。
理由2：PPAP廃止潮流と取引先からの要請
2020年11月24日の内閣府発表（中央省庁のPPAP運用停止）を契機にPPAP（パスワード付きZIPメール添付）の廃止が加速し、大手企業から「PPAPは受け取れない」と要請されるケースが増えています。代替手段としてファイル転送サービスを使う場合、どのサービスをどう使うかを社内で統一しないと、現場ごとに異なる運用が並走してしまいます。詳細は脱PPAPの進め方もあわせて。
理由3：内部不正・誤送信の抑止
情報漏洩の原因で多いのは外部攻撃よりも内部からの誤送信・持ち出しです。IPAの情報セキュリティ10大脅威2025でも「内部不正による情報漏えい等の被害」は組織編4位に挙がっています。社内ルールは抑止力として機能し、違反時の懲戒根拠にもなります。情報漏洩が起きる5つの原因もあわせてご覧ください。
本記事の評価基準｜ルールに含めるべき7要素
規程に何を入れるかは、運用者の経験と既存ガイドラインの両方を踏まえて決まります。本記事では個人情報保護委員会の「組織的安全管理措置」とISO/IEC 27001:2022（Annex Aの93管理策）の運用要件を出発点に、ファイル送受信に絞って中小企業でも運用できる粒度に落とし込んだ7要素を採用します。
| 要素 | 目的 | 必須扱いの根拠 |
|---|---|---|
| ①利用可能サービスの指定 | シャドーIT防止 | PPCガイドラインの「組織的安全管理措置」が前提 |
| ②機密度区分 | 機密度ごとの取扱差を作る | 「個人データの取扱区分」を明確化する個情法の要請 |
| ③パスワード保護のルール | URL流出時の被害最小化 | 「アクセス制御」の運用統制 |
| ④保存期間の上限 | 長期放置による漏洩防止 | 「保有データの最小化」原則 |
| ⑤PPAP禁止の明文化 | 取引先からの要請対応 | 内閣府2020/11/24発表の流れ |
| ⑥送信前確認の手順 | 誤送信の抑止 | 「ヒューマンエラー対策」の運用 |
| ⑦事故・誤送信時の報告フロー | 個情法の漏洩報告義務に対応 | 速報3〜5日・確報30日（不正アクセス60日） |
この7要素は「ファイル送受信」というスコープに絞った最小限です。ISO/IEC 27001:2022認証取得を目指す場合は、本7要素に加えて責任者権限の規定・記録保存・例外承認手続き・委託先管理・アクセス権限レビュー・定期的な内部監査などが必要になります。本記事はその手前の「現場運用を回す規程」として位置づけてください。
必須7要素の中身｜現場運用まで踏み込んで解説
要素1：利用可能サービスの指定（シャドーIT防止）
ルールがないと、社員が「速かったから」「無料だったから」という理由で個人アカウントのギガファイル便やWeTransferを使い始めます。これがシャドーITです。情シスが把握できないサービスで業務データが流れると、漏洩時の追跡が困難になります。
規程では「会社が認めたサービスのみ利用可能」と明示し、利用サービスを2〜3個に絞ります。選定基準としては暗号化・パスワード保護・送信履歴・国内データセンター・プライバシーマーク等の認証を満たすかどうかが、PPCガイドラインの「物理的・技術的安全管理措置」と整合します。詳細はセキュアファイル転送サービス5選を参照してください。
要素2：機密度区分（4段階）
すべてのファイルを最高セキュリティで送るのは現場負荷が大きすぎます。機密度に応じて取扱を変えるのが規程設計の核心です。
| 区分 | 例 | 送信時の必須条件 |
|---|---|---|
| 公開 | カタログ・公開資料 | サービス指定のみ（パスワード任意） |
| 社内 | 議事録・社内向け資料 | パスワード保護必須 |
| 秘 | 契約書・取引先資料 | パスワード＋DL回数制限＋保存14日以内 |
| 極秘 | 個人情報・人事評価・財務情報 | パスワード＋ワンタイムDL＋（原則）IPアドレス制限＋保存7日以内 |
「極秘」のIPアドレス制限は原則です。テレワーク時など固定IPが取れない場合は、VPN経由・端末認証・DLPツールなど代替統制を適用する形にします（詳細はテレワークのファイル共有を参照）。
要素3：パスワード保護のルール
パスワードを「設定するだけ」では意味がありません。次の3点を規程に明記します。
- 強度: 半角英数記号8文字以上。4桁数字は不可
- 伝達経路: メール本文への記載は禁止。SMS・電話・チャットなど別経路で伝える
- 有効期限: 同一パスワードの使い回しは禁止。送信ごとに新規発行
詳細はファイル転送のパスワード保護とはも参考になります。
要素4：保存期間の上限
サーバー上にファイルが残り続けると、URL流出時の被害が長期化します。機密度ごとに保存期間の上限を定めます。
- 公開資料：30日以内
- 社内・秘：14日以内
- 極秘：7日以内＋ワンタイムDL設定
「相手のDLが完了したら手動削除」を併用すると、より安全です。
要素5：PPAP禁止の明文化
「暗号化ZIPをメール添付し、別メールでパスワードを送る運用は原則禁止」と明記します。例外を認める場合は、上長の事前承認＋送信記録の保存を条件にします。取引先がPPAPで送ってきた場合の受信対応（自社では使わないが受信は許容するなど）も明記しておくと現場が迷いません。
要素6：送信前確認の手順
誤送信は技術的対策だけでは防げません。送信ボタンを押す前のチェックリストを規程に組み込みます。
- 宛先のメールアドレス・名前を声に出して読み上げる
- 添付ファイルの中身を最終確認（特に同名ファイルの取り違え）
- 機密度が「秘」「極秘」のときは別の社員にダブルチェック依頼
- パスワード強度を画面で確認
要素7：事故・誤送信時の報告フロー
誤送信や情報漏洩が発生したら、1時間以内に情シス／個人情報保護管理者へ連絡することを義務化します。報告フローには次を含めます。
- 連絡先（情シス・管理者の電話番号／メール）
- 第一報の項目（発生日時・対象データ・送信先・概算件数）
- 初動封じ込め：該当URLの削除・送信停止・受信者への連絡
- 証跡保全：送信履歴・ログのスクリーンショット保存
- 個情法に基づく外部報告（個人情報保護委員会・本人通知）の判断主体
- 事後検証会の開催ルール
ログ管理の体制づくりはファイル転送のログ管理もあわせて参考にしてください。
主要6社の「規程7要素への適合度」比較
規程を作っても、利用サービスが要素を満たしていなければ意味がありません。規程の7要素に各サービスがどの程度対応しているかを、出典付きで整理しました。判定は「○：標準で実装」「△：条件付き／一部のみ」「×：非対応」の3段階です。
| サービス | ①利用指定 | ②機密度別組合 | ③パスワード | ④保存期間 | ⑤PPAP代替 | ⑥送信前UI | ⑦事故対応 |
|---|---|---|---|---|---|---|---|
| ギガワタス |
○ | ○ DL回数制限・ワンタイムDL・IP制限を無料併用可 | ○ 桁数自由 | ○ 3〜111日 | ○ PPAP移行ガイド掲載 | ○ アップロード設定画面 | ○ 会員マイページで送信履歴／日本語サポート |
| ギガファイル便 |
○ | △ DL回数制限なし | △ 半角英数4桁固定 | ○ 3〜100日 | ○ URL発行＋別経路PWで対応可 | ○ アップロード画面で設定可（広告表示あり） | ○ 無料会員でDL履歴閲覧可 |
| firestorage |
○ | △ ワンタイムパスコード等は機能限定 | ○ 桁数自由 | ○ 3時間〜14日 | ○ URL発行＋別経路PWで対応可 | ○ 送信画面で設定可 | ○ プライバシーマーク取得・会員マイページ履歴 |
| データ便 |
○ | ○ ビジネスでDL回数制限・セキュリティ便 | ○ 自動生成3パターン | ○ 1時間〜30日 | ○ URL発行＋別経路PWで対応可 | ○ 送信画面で設定可 | ○ プライバシーマーク取得・送受信履歴 |
| WeTransfer |
○ | △ DL回数制限あり（プラン依存） | ○ 無料アカウントで設定可 | △ 無料は最大3日 | ○ URL発行＋PWで対応可 | ○ 無料アカウント＋送信画面で設定 | △ サポートは英語中心 |
| おくりん坊 |
○ | △ BIZのみ | × 無料版非対応 | △ ゲスト7日 | ○ URL発行＋別経路PWで対応可（PWはBIZのみ） | △ ゲスト機能は限定 | △ 法人BIZのみ |
規程7要素を無料プランで広くカバーできるのは、本表ではギガワタス・firestorage・データ便の3社です（各リンク先の機能ページ・プランページで仕様を確認できます）。WeTransferも無料パスワードは可ですが、無料は最大3日保存・要アカウント作成、サポートが英語中心の点が日本企業には制約となります。10〜30名規模の中小企業は、この3社のいずれかをメインに据えて、用途に応じて使い分けるのが現実的です。法人プランの管理画面・監査ログまで踏み込みたい場合は、データ便のビジネスプランやギガワタスのプレミアムが選択肢に入ります。
用途別おすすめ｜こんな人にはこのサービス
| こんな組織 | おすすめ | 理由 |
|---|---|---|
| 無料で7要素を満たし多層防御したい中小企業 | ギガワタス | パスワード＋AES-256＋ワンタイムDL＋IP制限を無料で組み合わせ可 |
| プライバシーマーク取得済みサービスを規程に明記したい | データ便 | Pマーク取得・送受信履歴・パスワード自動生成。法人安心感が高い |
| 取引先の認知度を優先したい | ギガファイル便 | 受信者が迷わない知名度。ただしパスワード4桁制約あり |
| 海外取引先とのファイル送受信が多い | WeTransfer | 海外でブランド認知度が高い・UI洗練 |
| 老舗で実績重視・Pマークを優先 | firestorage | ロジックファクトリー株式会社運営。Pマーク取得済み |
正直に伝えるギガワタスの3つの弱み
比較記事の信頼性は「自社の弱みも開示できるか」で決まります。運営者として、規程運用の文脈でのギガワタスの弱みを3つ正直に挙げます。
- 知名度ではギガファイル便に劣る：受信者から「初めて見るサービスでファイルを受け取るのは不安」と言われる可能性があります。社内規程に複数サービスを併記する場合は、ギガファイル便（受信側のみ受信受付）とギガワタス（送信時の機密案件用）を併用する形が現実的です。
- ウイルススキャンに対象制限がある：公式機能ページに「500MB以下のファイルが対象」と明記されており、動画ファイルは運用上の注意事項として対象外の扱いになります（2026年5月時点）。大容量動画ファイルでは送信前に自前のセキュリティソフトでスキャンする運用補助が必要です。
- パスワード強度は運用ルールに依存：桁数自由のため、ユーザーが「1234」のような弱いパスを設定できてしまいます。データ便のように自動生成機能で強度を底上げする仕組みは現状ないため、規程の運用ルール（要素3）でカバーする必要があります。
そのまま使える「ファイル転送取扱規程」ひな型（コピペ可）
規程の文面はゼロから書く必要はありません。下記の2バリエーションから、自社規模に合うものをコピーして社名・サービス名を埋めてください。本ひな型は商用・社内利用ともに自由に改変いただけます（ご利用報告は不要）。
バリエーションA：中小企業向け最小版（5項目・10〜30名規模）
ファイル送受信ガイドライン（最小版）
第1条（目的） 本ガイドラインは、〇〇株式会社（以下「当社」）の業務における社外向けファイル送受信の運用基準を定め、情報漏洩リスクを低減することを目的とする。
第2条（利用サービス） 社外へのファイル送付は、当社が指定するファイル転送サービス（〇〇、〇〇）のみを利用するものとし、個人アカウントの利用は禁ずる。
第3条（パスワード） 社内向け以上（公開以外）のファイル送付にはパスワード保護を設定し、パスワードは半角英数記号8文字以上とする。パスワードはメール本文に記載せず、SMS・電話・チャット等の別経路で伝達する。
第4条（保存期間） 保存期間は最大14日以内とし、相手のダウンロード完了後は速やかに削除する。
第5条（事故対応） 誤送信・漏洩等が発見された場合、発見者は1時間以内に情報管理担当者（連絡先：〇〇）に第一報を入れる。担当者は速やかに該当URLの削除・送信記録の保全・受信者への連絡を行い、事案の重大性に応じて、個人情報保護法に基づく個人情報保護委員会への報告および本人通知の要否を判断する。
制定日: 〇〇年〇〇月〇〇日／施行日: 〇〇年〇〇月〇〇日
バリエーションB：フル版（7要素＋細則・100名以上）
ファイル転送取扱規程（フル版）
第1条（目的） 本規程は、〇〇株式会社（以下「当社」）における社外向けファイル送受信に関し、必要な事項を定めるものとする。
第2条（適用範囲） 本規程は、当社の役員・正社員・契約社員・派遣社員・業務委託先（以下「使用者」）に適用する。
第3条（責任者） 本規程の主管は情報セキュリティ管理者とし、運用状況の確認および規程改定を行う。
第4条（利用可能サービス） 使用者は、別途定める「ファイル転送サービス利用基準」に基づき、情報セキュリティ管理者が承認したサービスのみを利用するものとする。個人アカウントの利用および無承認サービスの利用を禁ずる。
第5条（機密度区分） ファイルは以下の4区分に分類し、区分ごとに送信時の必須条件を遵守する。
- 公開：サービス指定のみ（パスワード任意）
- 社内：パスワード保護必須
- 秘：パスワード保護＋ダウンロード回数制限＋保存14日以内
- 極秘：パスワード保護＋ワンタイムダウンロード＋（原則）IPアドレス制限＋保存7日以内。テレワーク時等で固定IP取得が困難な場合は、VPN経由・端末認証等の代替統制を適用する
第6条（パスワード） パスワードは半角英数記号8文字以上とし、メール本文には記載しない。SMS・電話・チャット等の別経路で伝達するものとする。同一パスワードの使い回しを禁ずる。
第7条（保存期間） 機密度区分に応じて、第5条に定める上限内で設定する。受信者のダウンロード完了後は速やかに削除する。
第8条（PPAP禁止） 暗号化ZIPファイルのメール添付による送付（PPAP）は原則禁止する。やむを得ず利用する場合は、所属長の事前承認および送信記録の保存を要する。
第9条（送信前確認） 使用者は送信前に、宛先・添付内容・パスワード強度を確認する。機密度「秘」以上は別の使用者によるダブルチェックを行う。
第10条（事故報告） 誤送信・漏洩・URL流出等が発生した場合、発見者は1時間以内に情報セキュリティ管理者へ報告する。管理者は速やかに次の対応を実施する。
- 初動封じ込め（該当URLの削除・送信停止・受信者への連絡）
- 証跡保全（送信履歴・ログのスクリーンショット保存）
- 事案評価および個人情報保護法に基づく外部報告（個人情報保護委員会への速報および本人通知）の要否判断
- 事後検証会の開催
第11条（記録保存） 送信履歴・事故報告書は最低3年間保存する。
第12条（委託先取扱い） 業務委託先がファイル転送を行う場合、本規程に準拠した取扱を契約書に明記する。
第13条（教育・見直し） 情報セキュリティ管理者は、本規程の周知のため年1回以上の研修を実施し、規程内容を見直す。
第14条（違反時の措置） 本規程に違反した場合、就業規則に基づき懲戒の対象となることがある。
制定日: 〇〇年〇〇月〇〇日／施行日: 〇〇年〇〇月〇〇日／改定日: ―
このまま使うのが最低ライン。社内事情に応じて条文を追加してください。ISO/IEC 27001:2022認証取得を目指す企業は、本規程に加えてアクセス権限レビュー・内部監査・経営層レビュー等の管理策対応が必要になります。詳細はJIPDECのプライバシーマーク制度や日本品質保証機構のISMS認証のガイドを参照してください。
運用でよくある失敗3つ｜「作って終わり」を防ぐ
規程を作っても、運用しなければ意味がありません。運営者として法人のお客様から相談を受ける中で見えてきた失敗パターンを3つ共有します。
失敗1：「制定して回覧して終わり」で更新がない
制定から3年経って、利用サービスが廃止されていたり、機密度区分の現実が変わっていたりするケース。年1回の見直しを規程に組み込むのが原則です。フル版第13条「教育・見直し」に「年1回以上の見直しと研修」を入れておくと、形骸化を防げます。
失敗2：抜き打ちチェックがない
ルールがあっても、実態が違うケース。情シスが定期的に「直近30日の送信履歴をサンプリングして規程適合を確認」する運用を組み込みます。マイページの送信履歴が見られるサービス（ギガワタス無料会員・firestorage・データ便）なら、無料で実施可能です。
失敗3：違反時の手続きが曖昧
「違反したら厳重注意」だけでは、現場が動きません。第14条（違反時の措置）で就業規則との連動を明文化し、軽微・重大の区分と懲戒の範囲を具体化します。これにより抑止力が働きます。
よくある質問
Q. ISO/IEC 27001やプライバシーマークを取得していなくても、この規程は使える？
はい。本記事のひな型は「認証取得を目指していない中小企業でも今日から運用できる粒度」で設計しています。個情法の組織的安全管理措置の最低ラインを意識した内容で、認証取得を考えている企業はこれをベースに、ISO/IEC 27001:2022 Annex Aの93管理策やプライバシーマーク基準への対応を追加していく形になります。
Q. 10名規模の会社でも規程は必要？
必要です。社員数に関わらず、個人情報を扱う事業者は個情法上の「個人情報取扱事業者」に該当し、組織的安全管理措置が求められます。10名規模なら本記事のバリエーションA（最小版）から始めるのが現実的です。
Q. クラウドストレージ（Google Drive・Dropbox等）にも同じルールを適用すべき？
クラウドストレージは「保存」と「共有」の2機能があるため、ファイル転送とは別のルールが必要です。ただし機密度区分・パスワード・事故報告フローは共通化できます。詳細はクラウドストレージとファイル転送の違いを参考にしてください。
Q. PPAP禁止を明記すると、取引先からのPPAPメールは受信できなくなる？
本記事のひな型は「自社からの送信」の禁止のみを定めており、受信側の対応は組織判断に委ねています。受信もブロックしたい場合は、第8条に「PPAPメールの受信時はメールサーバーで隔離し、送信元へ代替手段を依頼する」と追記してください。
Q. テレワーク環境でも同じルールで運用できる？
運用可能ですが、テレワーク環境ではIPアドレス制限の取扱が課題になります。社員の自宅IPは固定でないことが多いため、極秘ファイルのIP制限は原則扱いとし、テレワーク時はVPN経由・端末認証・MDM等の代替統制を適用する形にします。詳細はテレワークのファイル共有もあわせてご覧ください。
Q. 規程を作成するとき、人事部・情シス・法務のどこが主管すべき？
情シスが主管、法務がレビュー、人事が研修運用の役割分担が標準的です。経営判断（規程改定や外部委託先への通達）は経営者が最終決裁します。30名規模以下なら、総務が主管して情シス的役割を兼ねるケースも多いです。
Q. 既存の情報セキュリティポリシーがある場合、別規程として作るべき？
独立した規程として作るのを推奨します。情報セキュリティポリシーは抽象度が高い基本方針が中心になることが多いため、「ファイル送受信」という具体行動の規程は別に切り分けたほうが現場で参照しやすくなります。上位ポリシーから本規程を参照する形にすれば階層構造として整合します。
Q. 業務委託先にもこの規程を適用すべき？
適用すべきです。個情法では委託先の監督義務が定められているため、フル版第12条のように業務委託契約書に本規程準拠を明記するのが原則です。フリーランス・外注先にもメールで規程の要点を共有しておくと、事故時の責任分界が明確になります。
Q. 送信履歴やログは何年保存すればいい？
業界・法令によりますが、情報セキュリティ関連の社内記録は最低3年（フル版第11条）、できれば5年を目安にすると安全です。個情法上の漏洩対応記録は事案クローズ後の参照を踏まえると長めの保存が望ましく、税務関連と一緒に整合させると管理しやすくなります。
まとめ｜今日から始める3ステップ
ファイル転送の社内ルール作りは、「完璧」より「動かす」が優先です。本記事の内容を踏まえて、今日から始める3ステップを提案します。
- 本記事の「バリエーションA（最小版）」をコピーして、社名と連絡先を埋める
- 利用可能サービスを2〜3個に絞る（ギガワタス・firestorage・データ便から自社用途に合うもの）
- 1ヶ月運用してフィードバックを集め、フル版へ拡張
「無料でセキュリティ機能を全部試したい」「規程の7要素を実装した動作を確認したい」場合は、ギガワタスを試してみてください。まずは登録不要のゲスト送信でパスワード保護＋AES-256暗号化を体験できます。継続して使う場合は無料会員登録（メールアドレスのみ）でワンタイムDL・IPアドレス制限・送信履歴管理まで開放されます。333GBまで送信可能で、規程運用の検証用としても活用できます。
記事作成: ギガワタス編集部（株式会社グッドヒルシステムズ）。本記事のひな型は商用・社内利用ともに自由に改変いただけます（利用報告は不要）。各社サービスの料金・仕様は変更される場合があるため、最新情報は各社公式サイトおよび個人情報保護委員会でご確認ください。最終確認日: 2026年5月16日。
