決済システム開発の外注方法とPCI DSS対応の判断基準｜発注前チェックリスト

決済機能の新設・刷新を任される担当者にとって、「決済システムを外注する」という選択は最初の一手として自然です。ただしいざ複数社から見積を取り始めると、方式ごとに提案内容も金額も大きくばらつくため、「どの方式が自社に合うのか」「見積の何を比べればよいのか」で立ち止まる方は少なくありません。

さらに、カード情報を扱う以上避けて通れないのが PCI DSS 対応です。「非保持化すればよい」という言葉は聞くものの、実際にどこまでが自社の責任範囲になり、外注先が何を担ってくれるのか、輪郭のはっきりした情報が意外なほど少ないのが実情です。ここが曖昧なまま発注してしまうと、リリース直前になって「実は自社側で SAQ-D 相当の対応が必要でした」と追加費用を積まれる、といった事態も起こりえます。

決済領域は、失敗すると情報漏えい・行政処分・信用毀損に直結する分野です。だからこそ、稟議書や RFP を書く前に「自社案件がどの外注方式に該当するのか」「PCI DSS のスコープが自社にどこまで及ぶのか」「発注先の実装力をどう見抜くのか」という 3 つの判断軸を、発注者の言葉で整理しておく必要があります。

本記事では、決済システム・決済代行連携の開発を外注する 3 方式の相場と特徴、PCI DSS 対応が自社に及ぶ範囲の判定基準、そして発注前に開発会社を見極めるためのチェックリストを、発注者視点で解説します。読み終わったときに、稟議書と見積依頼書に落とし込める粒度で「自社の決済案件」を言語化できる状態を目指してください。

決済システム開発の外注は「連携先」と「開発範囲」で3タイプに整理できる

決済システムを外注するとき、開発会社の提案は多種多様に見えますが、「どこと連携するか（連携先）」と「どこまで自社で作るか（開発範囲）」の 2 軸で整理すると、大きく 3 タイプに集約できます。この分類が、後述する PCI DSS 対応スコープや費用相場の土台になります。

SaaS 型決済サービス導入支援

Stripe や Square、Adyen などの SaaS 型決済プラットフォームを自社サービスに組み込むタイプです。決済画面や与信・売上処理はサービス提供元が用意しており、自社側はチェックアウト UI の埋め込みと、Webhook などのイベント受信を実装します。

このタイプの外注では、開発会社の主な役割はサービス選定支援、既存プロダクトへの組み込み、テスト・本番切り替えの支援です。決済手段のバリエーションを増やす、日本の商習慣に合わせた UX に調整する、といったカスタマイズ範囲が中心になります。

小〜中規模の EC、SaaS、D2C、サブスクなど「決済まわりを自前で持ちたくない」ケースに向いています。決済画面自体を SaaS 側にリダイレクトする、あるいは iframe で埋め込む構成を採ることが多く、後述する PCI DSS 対応スコープを最も軽く抑えやすい方式です。

決済代行 API 連携カスタマイズ開発

GMO ペイメントゲートウェイ、ROBOT PAYMENT、DGFT（DG フィナンシャルテクノロジー）、SB ペイメントサービスなどの決済代行会社が提供する API を、自社サービスに統合するタイプです。SaaS 型と異なり、決済フローやカード情報のトークン化のタイミング、エラー時の挙動などを自社側でコントロールする余地が大きくなります。

このタイプの外注では、決済代行 API と自社基幹システム（受注・会員・在庫・会計）のつなぎ込みが中心作業になります。都度課金と定期課金の両方を扱う、複数の決済代行を並行して使う、B2B のマルチテナントで加盟店ごとに決済経路を切り替える、といった複雑な要件が絡む場合はこの方式が選択されます。

中〜大規模の EC・BtoB SaaS・予約サービス・BNPL 事業者などに多いパターンです。カード番号を自社サーバーで一切扱わない「トークン型」「iframe 型」「リダイレクト型」といった非保持化アーキテクチャを、決済代行が提供するモジュールと組み合わせて設計するのが定石になります。

フルスクラッチ開発（自社で決済基盤を持つケース）

自社で決済基盤を持ち、カード会社との直接接続、あるいは複数の決済代行を束ねるハブとして機能させるタイプです。BtoB のマルチテナント SaaS でグループ内決済を集約する、金融・フィンテック系プロダクトで独自の与信ロジックを組む、といった特殊要件でのみ選ばれます。

このタイプの外注では、決済フローそのものだけでなく、カード情報を保持するための PCI DSS 準拠環境（ネットワーク分離、鍵管理、監査ログ、脆弱性診断、SOC 運用）まで含めて構築します。年次の PCI DSS 監査、SAQ-D または本審査対応、四半期ごとの脆弱性スキャンなど、リリース後も継続コストが発生する点が最大の特徴です。

このタイプを選ぶ企業は限定的で、多くの発注ケースは前述の 2 方式に収まります。「フルスクラッチが必要」と提案された場合は、なぜ SaaS 型や API 連携型では要件を満たせないのか、根拠を必ず確認することをおすすめします。

方式別の費用相場・工期・向いているケース早見表

3 方式の一般的な費用相場と工期の目安を整理します。金額は案件規模により大きく変動するため、稟議書の「オーダー感」把握用としてご参照ください。

上表は開発費のみの目安で、決済代行会社に支払う初期費用・月額固定費・トランザクション手数料は別途発生します。特にフルスクラッチではリリース後の PCI DSS 維持コスト（年次監査・脆弱性診断・鍵管理運用など）が年間 500〜数千万円規模で継続的にかかる点を、稟議上見落とさないようにしてください。

PCI DSS 対応が自社に及ぶ範囲は「カード情報の保持」で決まる

決済システムの外注検討で最も判断に迷うのが、「PCI DSS 対応が自社にどこまで及ぶか」です。ここは技術用語が多く登場するため難しく感じられがちですが、判定軸は「自社の環境でカード情報を保存・処理・伝送するかどうか」の一点に集約されます。

PCI DSS の位置付けと改正割賦販売法

PCI DSS は、Visa・Mastercard・JCB・American Express・Discover の国際 5 ブランドが策定したカード情報保護のグローバルセキュリティ基準です。2026 年時点で有効なのは v4.0.1 で、2024 年末に v4.0 は廃止されており、以降の審査はすべて v4.0.1 で実施されます（PCI SSC v4.0.1 SAQ 公開情報）。

日本国内では、改正割賦販売法が 2018 年 6 月に施行されて以降、クレジットカードを取り扱う加盟店に対して「カード情報の非保持化」または「PCI DSS 準拠」のいずれかを求めています（JCB による割賦販売法改正の案内、SB ペイメントサービスによる EC 事業者向け解説）。この「非保持化 or PCI DSS」の二択が、外注方式の選定に直接影響します。

「非保持化」とは、電磁的にカード情報を送受信・保存・処理しない、つまり自社の機器・ネットワークをカード情報が通過しない状態を指します。多くの EC 加盟店にとっては、決済代行会社の決済画面へリダイレクトする、または iframe で埋め込む、あるいはトークン化 API を経由してカード番号を自社に流さない、といったアーキテクチャで実現します。

「カード情報を保持するか / 非保持化するか」で決まる SAQ 区分

PCI DSS 準拠の負担は、自社が該当する SAQ（Self-Assessment Questionnaire、自己問診票）区分によって大きく異なります。EC 加盟店に関係する代表的な区分は次の 3 つです。

• SAQ-A: 決済ページ全体を決済代行会社にリダイレクト、または全画面を iframe で埋め込む方式。自社サーバーはカード情報に一切触れない構成。設問数は最も少なく、非保持化の代表パターンです
• SAQ A-EP: 決済ページの主要 UI は自社サイト上に置きつつ、カード情報入力欄のみを iframe やタグで決済代行会社側に飛ばすパートナーシップ型。自社サイトが「決済フローの一部」と見なされるため SAQ-A より厳しく、Web の脆弱性管理・タグ改ざん検知などが問われます
• SAQ-D: 自社の環境でカード情報を保存・処理・伝送するケース。フルスクラッチや、独自のトークン化基盤を自社で構築する場合が該当します。設問数は約 300 問前後と最も多く、リリース後の年次審査・脆弱性診断・監査ログ運用まで継続対応が必要です

2026 年時点では PCI DSS v4.0.1 に対応した SAQ が正式版として日本語でも公開されています（ICMS ソリューションズによる SAQ v4.0.1 日本語版公開のお知らせ）。特に SAQ A-EP は、v4.0.1 で改ざん検知やスクリプト管理の要件が強化されているため、SaaS 型・API 連携型のいずれで採用する場合も、以前より運用負荷が上がっている点に注意してください。

加盟店レベル別の対応負担

PCI DSS 対応の重さは、加盟店の年間取引件数によって「加盟店レベル」1〜4 に分類され、外部審査（QSA による訪問審査）が必要か、自己問診で足りるかが変わります。

多くの EC・SaaS 事業者はレベル3 または 4 に該当するため、「SAQ に回答すれば準拠状態を維持できる」構成に設計することが、開発・運用コスト最小化の鍵になります。逆に言えば、フルスクラッチや SAQ-D 相当の構成を提案された場合は、レベル 1〜2 の外部審査が視野に入るため、稟議段階で運用コストを明確化しておく必要があります。

外注方式別に見た PCI DSS 対応スコープ

前章で整理した 3 つの外注方式ごとに、典型的な PCI DSS 対応スコープを対応させると次のようになります。

見積比較の段階で「うちは非保持化で対応できます」と提案された場合、SAQ-A に該当するのか SAQ A-EP に該当するのかを、必ず確認してください。両者は自社の運用負担が段違いに変わるため、稟議に書く費用感・工数感の前提が変わります。

発注先の開発会社を見極めるチェックリスト

外注方式と PCI DSS スコープの見立てが定まったら、次は開発会社そのものを評価するフェーズです。ここでは、見積を比較する段階で確認すべき項目を、発注者が RFP／見積依頼書に差し込める形で整理します。

決済代行 API との連携実績

まず確認したいのは、その開発会社がどの決済代行会社の API を、どの規模で、どの業種向けに何本実装してきたかです。「決済連携できます」という抽象的な回答ではなく、実案件レベルで具体化してもらうことがポイントになります。

• 直近 3 年で連携した決済代行会社の名称と、それぞれの案件数
• 自社が想定している決済代行会社と同じプロバイダの連携実績
• 業種・取引規模の近い案件（EC / BtoB SaaS / サブスク / 予約サービス など）
• 都度課金だけでなく、定期課金・分割払い・返金フローまで実装したか

同じ「決済代行 API 連携」でも、都度課金だけの実装と、定期課金・オーソリ・キャプチャの分離・部分返金まで扱うのとでは、要求される設計力が大きく違います。自社の要件に近い実装経験があるか、複数社を横並びで比較してください。

非保持化アーキテクチャの設計・実装経験

SAQ-A / SAQ A-EP のどちらで対応するかを、開発会社側がどう提案するかは重要な評価ポイントです。提案アーキテクチャの選択肢と、それぞれのメリット・デメリットを説明できるかを確認してください。

• リダイレクト型・iframe 型・トークン型のいずれを推奨するか、その根拠
• 自社の UX 要件と、非保持化との両立をどう設計するか
• SAQ-A で収めるための構成上の制約と、SAQ A-EP になった場合の追加運用負担
• 決済代行会社の JavaScript タグを埋め込む場合の、改ざん検知・スクリプト管理の方針

「非保持化できます」だけで済ませる提案は要注意です。SAQ-A と SAQ A-EP のどちらに該当する構成なのか、明確な根拠とセットで説明できる開発会社を選んでください。

PCI DSS / SAQ 準拠の支援範囲

PCI DSS 対応のうち、どこまでを開発会社が支援し、どこからが発注元の自社責任になるのかは、契約書に落とし込むべき論点です。曖昧なままだと、リリース直前・リリース後に「その対応は範囲外です」と切り離されるリスクがあります。

• SAQ 回答作成の支援範囲（テンプレート提供のみか、回答レビュー・監査対応の伴走まで含むか）
• QSA（審査員）や AISS（内部監査支援）と連携した経験の有無
• 開発会社自身が PCI DSS 準拠の環境で開発しているか（QA・ステージング環境の切り分け）
• 脆弱性診断（ASV スキャン）の実施・結果対応の役割分担

決済領域特有の運用・保守体制

決済システムは、リリースがゴールではなく、リリース後の運用が本番です。決済代行 API の仕様変更、カード会社のセキュリティ要件変更、障害時の対応など、継続的にコミットしてもらう必要があります。

• 決済代行 API のバージョンアップ通知にどう追随するか（自動監視 / 定期チェック）
• 障害時の一次対応 SLA（決済失敗の検知・通知・切り戻し）
• 決済代行会社側の障害時の切替方針（マルチプロバイダ運用の場合）
• カード会社主導のセキュリティ要件変更（3-D セキュア 2.0、EMV 3DS 等）への追随実績

契約時に切り分けるべきスコープ項目

見積比較の段階で、以下の 5 つの工程を「どこまで含むか / どこから追加費用か」を明示させてください。ここが曖昧な見積は、後から必ず揉めます。

1. 要件定義（自社要件のヒアリング、非機能要件、監査要件）
2. 設計（アーキテクチャ設計、SAQ 区分の選定、シーケンス設計）
3. 実装・テスト（結合テスト、決済代行のテストトランザクション、負荷試験）
4. 監査・PCI DSS 対応支援（SAQ 回答支援、脆弱性診断対応）
5. 保守（決済代行 API 仕様変更対応、障害時 SLA、リグレッションテスト）

発注前に整理すべき要件チェックリスト

開発会社に見積を依頼する前に、発注元が自社で決めておくべき要件があります。ここが曖昧なまま複数社に見積依頼を出しても、返ってくる金額と工期はバラバラで、比較になりません。稟議書と RFP の粒度を一気に引き上げるために、次の 4 カテゴリで要件を整理してください。

対応決済手段

日本の EC・SaaS では、クレジットカード以外の決済手段の重要度が上がっており、「どこまで初期リリースに含めるか」の判断が費用に直結します。

• クレジットカード（Visa / Mastercard / JCB / Amex / Diners）
• QR コード決済（PayPay / 楽天ペイ / d 払い / au PAY / メルペイ など）
• 銀行振込・コンビニ払い・キャリア決済
• 電子マネー（交通系、iD、QUICPay など）
• BNPL（後払い、Paidy、NP 後払い、B2B 掛け払いなど）

「初期リリースはクレジットカードのみ、6 ヶ月後に QR 決済を追加」といった段階リリースの方針も、この段階で決めておくと開発会社側の設計がぶれません。

取引特性

決済フローそのもののパターンを整理します。ここが曖昧だと、追加要件が後出しになり、追加費用の温床になります。

• 都度課金のみか、定期課金（サブスク）を含むか
• 予約課金（オーソリ→キャプチャ）を扱うか、扱うなら承認保持期間の要件
• 分割払い・リボ払い・ボーナス払いを扱うか
• 返金・部分返金・キャンセルのフローと、業務側の権限設定
• 3-D セキュア 2.0 の適用範囲（全取引か、リスクベースか）

UI・UX

決済画面の UX が売上に直結する事業（EC・D2C・サブスクなど）では、決済 UI の要件が SAQ 区分の選択に直接影響します。

• 決済画面の遷移方式（自社サイト内 iframe / 外部リダイレクト / モーダル埋め込み）
• モバイル・PC 別の UX 要件（1 画面完結、ワンクリック決済、カード情報の保存）
• 多言語・多通貨対応の有無
• ゲスト決済の可否、会員登録との統合方針

会計・運用

決済システムは基幹の会計・受注・在庫システムと必ず連動します。ここを開発着手前に決めておかないと、リリース直前に会計要件で手戻りが発生します。

• 売上計上のサイクル（都度、日次、月次締め）と会計システム連携方式
• 消込・返金・チャージバックの業務フロー
• 月次締めのタイミングと、決済代行の締めサイクルとの整合
• 監査ログの保持期間・エクスポート要件

外注方式ごとに起きやすい失敗と、契約段階で防ぐ方法

最後に、発注後に実際に起きやすいトラブルを、外注方式ごとに整理しておきます。稟議・契約の段階でこれらを条項として盛り込むかどうかで、リリース後の追加費用・追加期間の発生確率が大きく変わります。

SaaS 導入型の落とし穴

Stripe や Square のような SaaS 型は「速く安く」が売りですが、カスタマイズ限界にぶつかると一気に破綻します。多い失敗パターンは次の 3 つです。

• 日本独自の商習慣（月末締め翌月払い、掛け払い、BtoB の複雑な請求書決済）を後から差し込めない
• 基幹システム（受注・会員・在庫）との連携で、SaaS の Webhook 仕様が追いつかない
• SaaS 提供元の料率改定や API バージョンアップに追従する運用体制が確保できていない

契約段階では、「初期リリース時点で対応する SaaS の機能範囲」「Webhook 連携で自社側が担う処理範囲」「SaaS 側の API 更新に追随する保守条項」を明文化しておくことをおすすめします。

API 連携カスタマイズの技術負債

決済代行 API 連携は、リリース後に「動いているけれど手を入れられない」状態に陥りがちです。原因の多くは次の 3 つです。

• 決済代行 API のバージョンアップに追随せず、旧バージョンに固定化されている
• 決済代行のテスト環境を模した「テストダブル」が整備されておらず、リグレッションテストができない
• 決済ロジックがアプリケーション層にべた書きされ、決済代行を切り替えられない

「バージョンアップ追随の SLA」「テストダブルまたはサンドボックス連携の整備」「マルチプロバイダを想定した抽象化レイヤーの有無」を、見積比較と契約の両方でチェックしてください。

フルスクラッチの維持コスト

フルスクラッチで決済基盤を持つ場合、開発費よりも運用費が事業判断を左右します。想定外に膨らみやすいコストは次の通りです。

• 年次 PCI DSS 監査（QSA による訪問審査）の費用と工数
• 四半期ごとの ASV スキャン、年次の内部・外部ペネトレーションテスト
• 鍵管理（HSM 運用、鍵ローテーション、監査ログ）
• SOC（24 時間監視）の構築または外部委託費用

これらは「開発費見積」には含まれないケースが多いため、稟議書と中長期予算計画に別枠で計上する必要があります。

契約段階で防ぐための条項リスト

外注方式によらず、契約書または RFP に次の項目を盛り込むことで、想定外のコスト・責任範囲拡大を大きく減らせます。

• 変更管理: 決済代行 API 仕様変更、PCI DSS バージョンアップ時の対応範囲と費用負担
• 監査対応: SAQ 回答支援、脆弱性診断結果への対応、外部監査時の資料提供
• 障害時 SLA: 決済失敗の検知・通知、一次対応時間、切り戻し手順
• 情報漏えい時の責任分界: 開発会社起因・自社起因・決済代行起因の切り分けと、賠償上限
• 知財・秘密保持: 決済ロジックのソースコード帰属、テストデータ・本番データの取扱い

発注判断のまとめ｜自社ケースを整理する 3 ステップ

ここまでの内容を、稟議書と RFP に落とし込むための 3 ステップとして整理します。この順番で自社案件を当てはめれば、複数の開発会社から比較可能な見積を集められる状態になります。

Step1｜案件を 3 方式のどれに当てはめる

まず、自社の決済案件が「SaaS 型導入支援 / 決済代行 API 連携カスタマイズ / フルスクラッチ」のどれに該当しそうかを、ラフに決めます。判断基準は次の通りです。

• 決済まわりを自前で持たなくてよく、対応決済手段も限定的 → SaaS 型
• 基幹システム連携、定期課金、複数決済経路、業種特有の商習慣がある → 決済代行 API 連携
• 独自の与信・マルチテナント決済・グループ内決済を扱う特殊要件 → フルスクラッチ

この段階では確定である必要はなく、後述の PCI DSS スコープ判定と往復させながら精度を上げていく前提で構いません。

Step2｜PCI DSS の対応スコープを非保持化か保持化かで確定する

Step1 の候補方式に対して、「自社の環境でカード情報を保存・処理・伝送するか」を判定します。

• カード情報を一切自社サーバーに通さない → SAQ-A（最軽量、リダイレクトまたは全面 iframe）
• 決済ページの UI は自社側だが、カード情報入力欄のみ決済代行に飛ばす → SAQ A-EP（中程度、Web の脆弱性管理が必要）
• 自社サーバーでカード情報を扱う → SAQ-D（重い、年次審査・脆弱性診断・監査ログ運用が継続発生）

多くの発注ケースでは SAQ-A または SAQ A-EP に収める設計が現実解になります。稟議書には「対応スコープは SAQ-〇 を想定」「継続コストは年間〇〇万円規模」まで書けるようにしておくと、経営層・法務・情シスとの合意形成が一気に進みます。

Step3｜発注先候補に投げる質問リストを RFP／見積依頼書に落とし込む

Step1・Step2 の見立てが固まったら、開発会社への質問リストを RFP／見積依頼書に差し込みます。本記事で挙げたチェックリストから、自社の状況に合わせて次の順番でピックアップすると効率的です。

1. 決済代行 API との連携実績（想定プロバイダ・業種・規模の近い案件数）
2. 非保持化アーキテクチャの提案パターン（SAQ-A / SAQ A-EP の選定根拠）
3. PCI DSS / SAQ 準拠の支援範囲（どこまで開発会社が支援するか）
4. 運用・保守体制（API バージョンアップ追随、障害時 SLA）
5. 契約時に切り分けるべきスコープ項目（要件定義・実装・テスト・監査対応・保守の内訳）

同じ質問リストを複数の開発会社に投げることで、初めて「同じ土俵での見積比較」が可能になります。決済領域は失敗の代償が大きい分野ですが、逆に言えば、判断軸を先に発注者側で言語化しておけば、発注後の追加費用・トラブルの多くは事前に防げるものです。まずは自社案件を 3 方式のどれに当てはめるか、そして PCI DSS のスコープをどこに置くかから、稟議書に書き起こしてみることをおすすめします。