決済に関わる独自のツールを構築する場合、コンプライアンスリスクは誰が負うのか？

それはあなたです。コードを生成したAIでも、ホスティングプロバイダーでも、決済プロバイダーでもありません。自社で構築したツールが決済に関わった瞬間から、コンプライアンスリスクは自社に帰属し、どれだけ多くの準拠ベンダーを組み込もうとも、そのリスクが消えることはありません。変えられるのはそのリスクの大きさであり、適切に設計されたカスタムツールと、不注意に作られたツールとの間には、天と地ほどの差があります。

なぜリスクはベンダーではなく自社に及ぶのか？

カード決済の受け入れは、契約の連鎖によって成り立っています。カードネットワークがルールを定め、アクワイアラ（カード売上を精算する銀行）がそれを執行し、加盟店契約を通じてそのルールがあなたに引き継がれます。そのルールブックが、カード業界のデータセキュリティ基準であるPCI DSSであり、カード会員データ（カード番号およびそれに付随する詳細情報）を保存、処理、または送信するすべての事業者に適用されます。現在のバージョンは4.0.1です。（バージョン番号やプログラムの詳細は公開時点のものであり、特定の内容はスナップショットとして扱ってください。）

ベンダーは自社システムに対する義務を負っており、準拠している決済プロバイダーを利用することで、あなたの作業負担は劇的に軽減されます。しかし、ベンダーが何をしようとも、責任の所在が移転することはありません。PCIセキュリティ基準審議会（PCI SSC）は、コンプライアンスの準拠証明が必要かどうかは決済ブランドとアクワイアラによって決定されると明言しており、加盟店契約に記された彼らの回答は「必要（Yes）」です。毎年、自社の担当者が、自社の環境が基準を満たしていることを示す準拠証明書に署名します。その署名はあなたのものであり、ベンダーのものではありません。

自社のコードがカードデータに関わった瞬間、何が変わるのか？

スコープです。コンプライアンスにかかる労力はスコープによって決まります。カード会員データに関わるすべてのシステムと、それに接続されているすべてのものが基準の対象となります。

準拠プロバイダーとその認定デバイスによって決済が完全に処理されている加盟店は、数十問程度の短い自己問診票（年次のチェックリスト）で準拠を証明できます。一方、自社のソフトウェアでカード番号を処理する加盟店は、最も厳格な階層に分類され、フル規格の大部分を反映した200以上の要件（四半期ごとの脆弱性スキャン、ペネトレーションテスト、アクセス制御、ログ記録、正式なセキュリティポリシーなど）に対応する必要があります¹。

AIが半日で書き上げたそのチェックアウトフォームはどうでしょうか？もしそれがカード番号を受け付けるのであれば、Webサーバー、データベース、管理用ノートPC、および店舗のWi-Fiまでもがすべてスコープの対象になり得ます。そして、どのみち短い問診票をこっそり提出することはできません。該当しない階層を選択してもリスクは軽減されません。署名した文書に誤りがあることを意味し、それは情報漏洩の直後という、最悪のタイミングで発覚するのが常です。

誤った対応をした場合、実際にどれほどのコストがかかるのか？

義務の履行は契約に基づくものであるため、通常は決済処理の明細書に現れます。多くの決済処理業者は、準拠を証明するまで、毎月継続的に非準拠手数料を請求します。漏洩事故が発生した後のコストはさらに膨らみます。自己負担となる義務的なフォレンジック調査、カードの再発行費用、およびアクワイアラを通じて課される段階的な罰金（PCIコンプライアンス評価機関が公表している罰金体系に基づくと、一般的に月額5,000米ドルから100,000米ドルの範囲と言われています）などです。深刻なケースでは、事業者はカード決済の受け入れ資格そのものを完全に失うこともあります。

小規模な加盟店にとって、最も重いコストは罰金よりも目立たないものです。本格的なセキュリティプログラムを運用するには、本来ビジネスの運営に充てるはずだった時間が奪われることになります。

カードデータのスコープを取り込まずにカスタムツールを構築するには？

コードをカードの経路から外すことです。カスタムツールは、カートの作成、割引の適用、注文の合計、請求金額の送信など、販売の調整（オーケストレーション）のみを行うべきです。カード自体は、認定端末（カード処理の検証をパスした決済ハードウェア）またはプロバイダーのホスト型決済ページのみを経由し、そこから決済処理業者（資金を移動させる企業）へ直接送信されるようにします。ツールは、承認または拒否の結果と、トークン（盗まれても第三者には無価値な参照番号）のみを受け取ります。

この分離こそが、ヘッドレスPOSアーキテクチャ（上部にカスタム画面、下部に認定決済インフラ）を推奨する最大の理由です。これこそが、AIが生成したチェックアウトがデモでは見事に動作しても本番環境で頓挫する理由であり、Interacのような対面デビット決済においてWebフォームが誤った選択肢である理由でもあります。対面決済は、技術的にも契約的にも認定ハードウェアで行われるべきなのです。

Finalはこの境界線を厳密に意識して構築されています。自身でプロンプトを作成するか、MCP経由で独自のAIを接続するかに関わらず、構築したフローは画面、カート、カタログを制御します。カードデータは認定端末ハードウェアからFinal Payを通じて決済処理業者に送信され、構築したフローに侵入することはありません。安全な部分はカスタムにし、責任が発生する部分は標準化するのです。

それでは、コンプライアンスリスクは誰が負うのでしょうか？

それはあなたであり、今後も変わりません。本当に決定すべきことは、どれだけのスコープを引き受けるかであり、それは書類上の選択ではなく、アーキテクチャの選択です。決済に関わるツールをリリースする前に、1つだけ問いかけてみてください。「自社のコードがカード番号を目にすることはあるか？」 もし「はい」であれば、コンプライアンスプログラムを運営するのはあなた自身です。もし「いいえ」であれば、負担をわずかに抑えつつ、カスタム開発の柔軟性を維持できます。現在そのような開発を検討している場合は、まず既製のPOSでは対応できなくなっているサインから確認してみてください。