アプリ開発者のためのPCIコンプライアンス：簡潔で痛切な現実

PCIコンプライアンス（カードデータを取り扱うすべての人に適用されるクレジットカード業界のセキュリティルール）は、「クレジットカード決済対応」を掲げる代償です。簡潔に言えば、カードデータが自分が書いたコードや管理するサーバーに一度でも触れた場合、数百もの管理要件、年次の自己問診・準拠証明書（基準を満たしていることを署名して証明する正式な文書）、そして決済サービスプロバイダー経由で科される罰則などを伴うセキュリティ基準を全面的に負うことになります。アプリ開発者にとって痛切な事実は、チェックアウト画面を構築し終えた後に初めてこの現実に気づくケースが多いということです。

具体的な説明に入る前に1点注意です。以下に記載されているバージョン番号、日付、問診票のルールは本記事公開時点のものです。基準は更新されるため、これらの詳細はあくまで時点情報として捉えてください。

そもそもPCIコンプライアンスとは？

PCI DSS（Payment Card Industry Data Security Standard）は、法律ではなく契約上の義務です。カードブランドが提携銀行や決済事業者に義務付け、さらに事業者が加盟店や加盟店が利用するソフトウェアに対して義務付けています。現在のバージョンは4.0.1であり、新しい要件の最終波は2025年3月31日に必須化されました¹。この基準は、ネットワークセキュリティや暗号化からアクセス制御、ログ管理に至る12の要件ファミリーで構成され、数百もの個別管理要件に細分化されています²。

規制当局が突然家にやってくるわけではありません。代わりに商業的なペナルティが課されます。アクワイアラー（加盟店契約会社）経由で転嫁される違約金、決済手数料の引き上げ、最悪の場合はカード決済機能の全面停止などです。データ漏洩事故が発生した場合、フォレンジック調査費用やカード再発行費用も同様のルートで請求されます。

なぜ「決済機能を追加するだけ」でアプリ全体が対象（スコープ内）になるのか？

対象範囲（スコープ）こそがすべての鍵です。PCI DSSは、カード保持者データを保存、処理、または送信するすべてのシステム、ならびにそれらのシステムに接続されているすべての要素に適用されます。準拠の評価基準は階段のようになっており、段が上がるごとに負担が劇的に重くなります²:

• SAQ A（自己問診票A）：決済処理が準拠プロバイダーに完全外部委託されており、カードデータが自社システムに一切触れない場合。問診項目が最も少ないタイプです。

• SAQ A-EP：サイト自体はカードデータに触れないものの、顧客が決済フォームにアクセスするプロセスを制御している場合。フル基準のかなりの部分がWebサーバーに適用されます。

• SAQ D：自作したシステム（保存の有無や時間の長短を問わず）をカードデータが通過する場合。実質的に規格全体の適用を受け、毎年文書化と証明書の提出が必要になります。

一番下の段階（SAQ A）だからといって負担がゼロというわけではありません。2025年1月、PCI Security Standards CouncilはSAQ Aから決済ページのスクリプト要件を削除しましたが、新たな適用要件を追加しました。自社サイトがECシステムに影響を及ぼすようなスクリプト攻撃に対して脆弱でないことを確認しなければなりません¹。決済処理を完全に外部委託している場合でも、他社の決済フォームを掲載するページ自体の防衛が求められます。

年間600万件を超えるカード取引が発生すると自己問診は終了し、QSA（認定審査員）による現地監査が義務付けられます²。

コーディングによって対面決済の要件を回避できるか？

不可能です。対面決済（カードプレゼンツ）において、この課題は階段から高い壁へと変わります。対面決済には認定ハードウェアが不可欠です。すなわち、PCI協議会のPTSラボプログラムに合格し、承認されたファームウェアを実行し、決済プロセッサー経由でプロビジョニングされた物理リーダーが必要となります。ソフトウェアのみでスマートフォンを決済端末化する手法は、別の規格であるMobile Payments on COTS (MPoC)の対象であり、これはソリューションプロバイダーを認定するものであって開発されたアプリを認定するものではありません。

これはAIによるコード生成が越えられない一線です。AIモデルは一晩で精巧なチェックアウト画面を作成できますが、LovableやReplitでPOSを構築できるか？やバイブコーディングによるPOS開発で述べているように、開発は必ずある段階で頓挫します。どんなにモデルがどれほど長く監視なしでコードを書き続けても、生成されたコードが認定リーダー、加盟店契約、または準拠証明書を生み出すことはありません。コンプライアンス違反は、バイブコードされた決済アプリがApp Storeで拒否される理由における典型的な原因でもあります。

開発者がPCIスコープ（対象範囲）を実際に縮小する方法

コンプライアンス対応を力任せに行うのではなく、準拠すべき対象を減らすアーキテクチャを設計します：

• PAN（主要口座番号、つまりカード番号自体）をコードに一切触れさせないこと。決済事業者のホステッド決済フィールドを使用し、カードデータが顧客のブラウザから直接プロセッサーに送信されるようにします。

• カード情報ではなくトークンを保存すること。トークナイゼーション（カード番号を盗まれても無価値な参照用文字列に置き換える技術）を利用することで、登録済みカードや返金処理によって自社のデータベースがスコープに含まれるのを防ぎます。

• 対面販売ではプロセッサーの認定カードリーダーを使用し、カードデータがアプリを経由せず端末からプロセッサーへ直接流れるようにします。

• 決済ページは極力シンプルに保つこと。サードパーティ製スクリプトを追加するたびに、監査報告の対象が増えることになります。

正しく構築すれば、アプリはカードデータを保持することなく決済処理を統制でき、自己問診票も短い項目で済みます。間違った構築をすると、「利便性のためにリクエストボディ全体をログ出力する」といった1つの機能のせいで、知らぬ間にSAQ Dの対象に格上げされてしまいます。

結論：アプリ開発者にとってPCIコンプライアンスはどれほど困難か？

その困難さは、コードが触れるカードデータの量に比例します。だからこそ、「一切触れない」設計こそが最も賢明なアプローチとなります。開発チームが手書きで組んだアプリであろうと、AIが一瞬で生成したアプリであろうと、セキュリティ基準には関係ありません。スコープはスコープです。カード決済機能をリリースする前に、次の問いを自問してください。「自分が書いたコードをカード番号が通過する可能性が一度でもあるか？」もし答えがYESなら、監査費用を予算に組み込んでください。NOなら、その状態を徹底して維持してください。

このアーキテクチャこそが、Finalが採用しているアプローチです。Buildで指示を出して作成したチェックアウトフローでも、MCP経由で自前のAIを使って構築したフローでも、Final上で構築された決済はFinal Payを通じて実行されます。決済プロセッサーと認定端末ハードウェアがカードデータを処理するため、フロー自体がカード番号を保持・所有することはありません。Final Payの利用可能地域では運用面での詳細を解説しており、Tap to PayをAI POSフローに接続するでは、コンプライアンス層があらかじめ組み込まれた状態でのカード決済受け入れの仕組みを紹介しています。