ECサイトの外注は何から決めればいいですか
最初に決めるのは「カード情報を自社のサーバに持たない構成にするか」の1点です。ここが決まると、後続の要件はほぼ自動的に絞られます。
逆の順番で進めると行き詰まります。デザインやカート機能の希望から話を始めると、見積もりは出るものの、セキュリティと個人情報の責任範囲が宙に浮いたままになります。
カード情報を持つか持たないかで変わること
カード情報を自社で保持しない構成とは、カード番号の入力と保存を決済代行事業者の側で完結させる構成です。利用者から見ると自社サイトで買っているように見えますが、番号そのものは自社のサーバを通りません。
どちらを選ぶかで、御社が負う作業は次のように変わります。
| 決める項目 | 自社で保持しない構成 | 自社で保持する構成 |
|---|---|---|
| カード番号の保存先 | 決済代行事業者 | 自社のサーバ |
| 求められる安全管理の範囲 | 決済代行事業者との連携部分 | カード情報を扱う全体 |
| 発注時に決める主な要件 | 決済代行の選定と連携の分担 | 保存、暗号化、アクセス管理の全項目 |
| 公開後の運用の重さ | 比較的軽い | 継続的な点検と記録が必要 |
中小企業の新規のECサイトでは、保持しない構成が出発点になります。保持する構成を選ぶ理由が社内にあるかを先に確認してください。
発注前に自社で決める項目と、制作会社に任せる項目の境目
境目は「業務の決め事か、技術の実現方法か」で分かれます。業務の決め事は御社しか決められません。
発注前に御社で決める項目は次の4つです。
- カード情報を自社で保持するかしないか
- 注文時に利用者から受け取る項目 (氏名、住所、電話番号、生年月日など)
- 受け取った情報を保存する期間
- 情報が漏れた疑いが出たときに、誰が誰へ連絡するか
制作会社に任せるのは、これらを満たす実装方法の選定です。暗号化の方式や管理画面の権限の作り方は、技術の実現方法にあたります。
実装の現場で多いつまずきは、2番目の項目が決まらないまま設計が進むことです。入力欄を1つ増やすだけの変更に見えても、保存先の設計、退会時の削除処理、管理画面の表示まで影響します。公開直前の追加は費用も日数もかさみますので、注文画面の入力欄は発注前に紙の上で確定させておくことをおすすめします。
決済と顧客情報それぞれの要件の書き方は、このあとのセクションで順に説明します。
決済の要件はどこまで書けばいいですか
決済代行の選定と、EMV 3-Dセキュアをどちらがどこまで実装するかの分担を要件に書きます。決済方式の名称だけでは要件になりません。
「クレジットカード決済に対応」とだけ書いた要件書では、見積もりの金額も作業範囲も会社ごとにばらつきます。比較ができる要件にするには、認証の仕組みと分担まで踏み込む必要があります。
EMV 3-Dセキュアがどう位置づけられているか
EMV 3-Dセキュアとは、カード決済のときに利用者本人かどうかを追加で確認する仕組みです。一度だけ使えるパスワードの入力などを求めます。
クレジットカード・セキュリティガイドラインの改訂により、2025年3月末までに原則としてすべてのEC加盟店でEMV 3-Dセキュアを導入することが求められました。これは法律の条文で直接義務づけられたものではなく、割賦販売法にもとづくカード会社の加盟店管理義務を通じて実効性が担保される構図だと説明されています。
出典: クレジットカード・セキュリティガイドラインの改訂内容に関する公表報道 (2025年3月末の期限、基準日2026年10月)
御社の側で判断が要るのは、導入するかどうかではなく、どの画面でどう見せるかという利用者の体験の部分です。認証の画面が挟まることで購入を途中でやめる利用者が出ますので、カート画面の設計と併せて決めてください。
決済代行と制作会社の作業分担の線引き
分担は3者の間で切れます。要件書には次の形で書くと、見積もりの比較ができるようになります。
| 作業 | 担う側 | 要件書への書き方 |
|---|---|---|
| 決済代行事業者の契約と審査の申込 | 御社 | 契約主体を明記する |
| 決済代行の管理画面の初期設定 | 御社または制作会社 | どちらが行うかを指定する |
| サイトから決済代行への連携の実装 | 制作会社 | 対象の決済手段を列挙する |
| EMV 3-Dセキュアの組み込みと動作確認 | 制作会社 | 確認の方法と合格の基準を書く |
| 本番環境での少額のテスト決済 | 御社と制作会社 | 実施の回数と立会いの有無を書く |
実装の現場で抜けやすいのは最後の行です。テスト環境で動いていても、本番の契約で決済手段ごとに設定が分かれていることがあります。公開日の前に本番で少額のテスト決済を行う枠を、日程と費用の両方に入れておいてください。
参照する版を発注時点で確認する理由
ガイドラインは更新が続いているためです。版が変わると求められる対策の範囲も変わります。
クレジット取引セキュリティ対策協議会は2025年3月4日の第12回本会議で6.0版を取りまとめ、EC加盟店におけるカード情報保護対策の指針を追加するとともに、脆弱性対策と不正ログイン対策の実施を取り上げています。2026年3月11日の第13回本会議では6.1版を取りまとめたと報じられています。
要件書には版の番号を書かず、「着手時点の最新版に準拠する」と書く方法が安全です。版数と期限は情報源によって記述が分かれる場合がありますので、実際の対応では協議会と日本クレジット協会の公式資料で最新版をご確認ください。
顧客情報の取り扱いで決めることは何ですか
保存する項目、保存期間、保存先、そして漏えいが分かったときの連絡体制の4つを要件に書きます。収集する項目を減らすこと自体が要件になります。
この4つは技術の話ではなく業務の決め事です。制作会社に尋ねても答えは出ませんので、発注前に御社で決めてください。
収集する項目を先に削る考え方
持っていない情報は漏れません。注文の処理と問い合わせの対応に使わない項目は、入力欄から外すのが出発点です。
判断は項目ごとに次の順で行います。
- その項目を、誰のどの業務で使うかを言えるか
- 言えない場合は入力欄から外す
- 言える場合は、いつまで必要かを月または年の単位で書く
- 必要な期間を過ぎたデータをどうするかを決める (削除するか、氏名などを外して集計用に残すか)
生年月日や性別は、販促の分析のために何となく集めてしまいがちな項目です。分析の担当者が社内にいない段階では外しておき、必要になった時点で追加する判断で問題ありません。
漏えい等の報告が必要になる類型と期限
ECサイトは、漏えいが起きたときに報告の対象になりやすい情報を扱っています。期限が決まっているため、体制を先に用意しておく必要があります。
個人情報保護委員会は、報告が必要になる漏えい等の事態として次の類型を挙げています。
- 要配慮個人情報が含まれる場合
- 不正に利用されると財産的被害が生じるおそれがある場合
- 不正の目的をもって行われたおそれがある行為による場合
- 本人の数が1,000人を超える場合
報告の期限は次のとおりです。
| 区分 | 期限 |
|---|---|
| 速報 | 発覚日から3日から5日以内 |
| 確報 | 発覚日から30日以内 |
| 確報 (不正の目的で行われたおそれがある場合) | 発覚日から60日以内 |
出典: 個人情報保護委員会「漏えい等が発生したら」 (基準日2026年10月)
ECサイトはクレジットカード番号を扱うため、財産的被害が生じるおそれがある個人データの類型に当たりうる点が実務上の要点です。人数が少なければ報告が要らないとは限りません。報告義務そのものは個人情報保護法第26条第1項にもとづくもので、2022年4月の改正で努力義務から法的義務に変わったと解説されています。
誰が何時間以内に誰へ連絡するかの決め方
速報の期限から逆算して決めます。発覚日から3日という前提で考えると、社内で1日、調査で1日が現実的な配分です。
要件書と運用の手順書に書く項目は次の4つです。
- 異常に気づく経路 (管理画面の監視、決済代行からの連絡、利用者からの申告)
- 最初の連絡を受ける社内の担当者と、その代理の担当者
- 制作会社または保守の担当者へ連絡する手段と、応答までの目安時間
- 事実関係を誰が取りまとめ、誰が報告の判断をするか
抜けやすいのは2番目の代理の担当者です。担当者1人の携帯電話だけが連絡先になっている体制は、その人が不在の日に止まります。保守契約の中で、夜間や休日の連絡をどこまで受けるかも併せて確認しておいてください。
公的な基準の引き方は次のセクションで説明します。
セキュリティ要件はどの公的基準を引けばいいですか
IPAのモデル取引・契約書と「安全なウェブサイトの作り方」を引くと、発注側が自分で文章を考えずに要件を書けます。基準の名前を指定するだけで要件になります。
ECサイトは、脆弱性の届出が多い領域です。IPAの届出状況では、2004年7月8日の受付開始から2026年6月末までの累計届出件数20,315件のうち、ウェブサイトに関する届出が13,599件で、全体の約7割を占めています。
出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況[2026年第2四半期]」 (基準日2026年6月末)
見積書と仕様のどこに書くか
仕様の「セキュリティ要件」の項に、基準の名称と確認方法を書きます。見積書の様式を定めた公的な基準は確認できていませんので、費用の欄の書き方は制作会社の様式に合わせて構いません。
引ける公的資料は次の3種類です。
| 目的 | 参照する資料 | 要件書への書き方の例 |
|---|---|---|
| 要件を一緒に決める過程を示す | IPA「情報システム・モデル取引・契約書」第二版と「セキュリティ仕様策定プロセス」 | セキュリティ仕様の策定は同プロセスに沿って協議する |
| 要件の中身を示す | IPA「安全なウェブサイトの作り方」改訂第7版と別冊「ウェブ健康診断仕様」 | 同書の第1章の脆弱性対策を実装し、ウェブ健康診断仕様の検査パターンで確認する |
| 公開後の運用の範囲を示す | IPA「安全なウェブサイトの運用管理に向けての20ヶ条」 | 保守の範囲を同20ヶ条の各項目に対応づけて明記する |
出典: IPA「情報システム・モデル取引・契約書（第二版）」、IPA「安全なウェブサイトの作り方」、IPA「安全なウェブサイトの運用管理に向けての20ヶ条」
「情報システム・モデル取引・契約書」第二版は2020年12月22日に公開され、付属資料として「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」が用意されています。御社に専門の担当者がいない場合でも、何を制作会社と決めるべきかの枠組みとして使えます。
自社側の体制については、IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版に付録が用意されています。付録3「5分でできる！情報セキュリティ自社診断」と付録7「中小企業のためのクラウドサービス安全利用の手引き」は、発注の前に自社の現状を確認する用途に向いています。
制作会社の回答で確認する点
確認するのは「実施します」という返答ではなく、何をもって実施したと判断するかの基準です。次の3点を聞いてください。
- ウェブ健康診断仕様の検査パターンのうち、どこまでを納品前に確認するか (つまずきやすい点: 検査の範囲を決めずに進めると、公開後の指摘が追加費用の扱いになります)
- 確認の結果をどの形で渡すか (報告書か、画面の記録か)
- 公開後に新たな脆弱性が公表されたとき、調査と連絡をどちらが行うか
実装者として申し添えると、クロスサイトスクリプティングのように件数の多い脆弱性は、個別の対策の積み上げよりも、出力の処理を1か所に寄せる設計で防ぐほうが確実です。IPAの資料でも、届出受付開始から2014年第4四半期までにウェブサイトの届出件数の約5割に相当する届出があったとされています。設計の方針として確認しておくと、後からの手直しが減ります。
公開後に脆弱性が見つかったときの責任の範囲は、次のセクションで扱います。