決済システムの開発現場では、PCI DSS 準拠とコード品質の両立に常に悩まされます。カード情報非保持化のアーキテクチャ設計、異常トランザクション検知ロジックの実装、AML/CFT 対応コードのレビュー――これらを限られたリソースで進めるのは容易ではありません。私自身、金融機関のシステム導入に携わる中で、セキュリティ要件と開発スピードのバランスに苦労する現場を数多く見てきました。本記事では、Claude Code を FinTech 決済処理に活用する際の具体的な手順と注意点を、PCI DSS 準拠の観点から整理します。効果の表現は慎重に行い、人間レビューが必須である点も明記します。
本記事の結論: Claude Code は設計支援・コード生成・異常検知パターン作成を補助できるが、PCI DSS 準拠判断・本番デプロイ前レビューは必ず人間が実施する
PCI DSS 要件と Claude Code の適用範囲
PCI DSS（Payment Card Industry Data Security Standard）は、カード情報を扱うシステムに課される国際的なセキュリティ基準です。要件 1〜12 のうち、特に要件 3（保存カードデータの保護）、要件 6（安全なシステム開発）、要件 10（アクセスログ記録）が開発現場で直接関わります。
Claude Code を活用できる領域は以下の通りです。
1. アーキテクチャ設計の壁打ち — カード情報非保持化（トークン化・外部 PSP 連携）の設計方針を自然言語で相談し、疑似コード・構成図の生成を依頼できます。ただし、生成された設計が PCI DSS 要件に準拠しているかの最終判断は QSA（認定審査機関）または社内コンプライアンス担当が行う必要があります。
2. 安全なコードパターンの生成 — 入力検証・暗号化処理・エラーハンドリングのコード例を生成できます。ただし、生成コードが特定の暗号ライブラリの最新版・推奨設定を正しく反映しているかは人間が検証します。
3. 監査ログ実装の補助 — 要件 10 に対応したログ記録処理のテンプレートを生成できます。ログに含めるべき項目（ユーザー ID・タイムスタンプ・操作内容・結果）のチェックリストも作成可能です。詳細は Claude Code で監査ログを実装する方法 で解説しています。
重要な制約: Claude Code は PCI DSS の条文解釈・準拠可否の判定を行う資格を持ちません。生成されたコードは「参考実装」であり、本番採用前に必ず人間（セキュリティエンジニア・QSA）がレビューしてください。
カード情報非保持化前提の設計支援
PCI DSS 対応の最も効果的な手段は、自社システムでカード番号を保持しないことです。トークン化または外部 PSP（Payment Service Provider）への処理委託により、スコープを大幅に削減できます。
Claude Code を使った設計相談の進め方は以下の通りです。
| ステップ | 内容 | Claude Code の役割 | 人間の役割 |
|---|---|---|---|
| 要件整理 | 決済フロー・保持期間・連携先 PSP の仕様確認 | 質問リストの生成、ユースケース図の下書き | 実際の業務フロー確認、PSP 契約条件の精査 |
| アーキテクチャ検討 | トークン化方式（クライアント側 / サーバー側）の比較 | 各方式のメリット・デメリット整理、疑似コード生成 | セキュリティポリシーとの整合、コスト試算 |
| API 設計 | 決済リクエスト・レスポンスの JSON スキーマ作成 | スキーマのドラフト生成、バリデーションルール提案 | 実在する PSP の API 仕様との照合、エラーハンドリング設計 |
| エラーシナリオ | タイムアウト・重複決済・部分承認への対応策 | リトライロジック・冪等性担保のコード例生成 | 業務ルール（返金ポリシー等）との整合確認 |
実際のプロンプト例（カード情報を自社 DB に保存しない前提）を以下に示します。
あなたは FinTech 決済システムのアーキテクトです。以下の条件で、
カード情報非保持化を実現する設計案を提示してください。
- 外部 PSP（Stripe 相当）を利用し、自社サーバーはトークンのみ扱う
- クライアント（Web / モバイルアプリ）から直接 PSP の JavaScript SDK を呼び出す
- 自社 API は決済完了通知を受け取り、注文 DB に結果を記録する
- PCI DSS スコープを最小化する設計とする
以下を出力してください。
1. システム構成図（Mermaid 形式）
2. 決済フロー（シーケンス図）
3. 自社 API のエンドポイント設計（疑似コード）
4. PCI DSS スコープから除外できる理由の説明このプロンプトに対して Claude Code が生成する構成図・コード例は、あくまで「たたき台」です。実際の PSP の SDK 仕様・Webhook 署名検証方法・冪等キーの扱いは、PSP の公式ドキュメントで必ず確認してください。
実務上の注意: 生成されたコードに「PCI DSS 準拠」と明記されていても、それは AI の推測です。準拠判定は QSA のレビューまたは自己問診票（SAQ）の記入を通じて人間が行います。
異常トランザクション検知パターンの生成
不正利用対策として、異常なトランザクションパターンを検知するルールエンジンの実装が必要です。Claude Code は、過去の不正事例をもとにした検知ルールのコード例を生成できます。
検討すべき検知パターンの例を以下に示します。
Claude Code を使った検知ルール生成の手順は以下の通りです。
- 既存の不正事例の整理: 過去のチャージバック・不正利用の記録から、共通する特徴（決済額・時刻・デバイス情報等）を抽出します。個人情報は削除し、統計値のみを扱います。
- 検知ルールの仕様書作成: 「いつ・どの条件で・どう対処するか」を自然言語で記述します。例：「同一 IP から 1 分以内に 5 回以上のカード登録試行があった場合、当該 IP をブロックリストに追加し、管理者に通知する」
- コード生成: 上記仕様を Claude Code に渡し、検知ロジックのコード（SQL クエリ・ストリーム処理・しきい値判定）を生成させます。
- テストケース作成: 正常系・異常系のテストデータを生成し、検知漏れ・誤検知の確認を行います。
以下は、短時間多頻度パターンの検知ロジック生成プロンプト例です。
あなたは不正検知システムの開発者です。以下の条件でトランザクション検知ルールを実装してください。
- データソース: PostgreSQL の transactions テーブル（user_id, amount, created_at, status）
- 検知条件: 同一 user_id が 5 分以内に 10 件以上の決済を試行（status = 'attempted'）
- アクション: 当該ユーザーの新規決済を一時停止し、fraud_alerts テーブルに記録
以下を出力してください。
1. 検知 SQL クエリ（ウィンドウ関数使用）
2. アクション実行の疑似コード（Python / TypeScript）
3. テストケース（正常・異常各 3 パターン）生成されたコードは、以下の点を人間が検証します。
- パフォーマンス: ウィンドウ関数・集約クエリがインデックスを活用しているか、大量データで遅延しないか
- 誤検知リスク: 正規の利用（複数商品の連続購入等）を誤って不正と判定しないか
- 回避可能性: 攻撃者が IP を変える・少額に分割する等の手口で検知を回避できないか
実際の運用では、機械学習モデル（異常スコアリング）との併用や、ルールの定期的な見直しが必要です。Claude Code はルールの「初期実装」を支援する位置付けと考えてください。
Claude Code をセキュリティ対策に活用する際のベストプラクティス も併せてご参照ください。
AML/CFT 対応コードの実装例
AML（Anti-Money Laundering：マネーロンダリング対策）および CFT（Countering the Financing of Terrorism：テロ資金供与対策）は、金融機関に課される法的義務です。疑わしい取引の検知・記録・報告が求められます。
Claude Code を使った AML/CFT 対応の支援範囲は以下の通りです。
1. 疑わしい取引パターンのチェックリスト作成 — 金融庁の「疑わしい取引の参考事例」をもとに、自社サービスに該当する事例を抽出し、検知ルールの仕様書を生成できます。ただし、法令解釈は弁護士・コンプライアンス専門家が行います。
2. 取引モニタリングコードの生成 — 高額送金・頻繁な入出金・第三者への即時転送等の条件を SQL または集約処理のコードに落とし込めます。生成コードは、実際のデータ構造・業務ルールに合わせて人間が修正します。
3. 報告書フォーマットの整備 — 疑わしい取引報告書（STR: Suspicious Transaction Report）のテンプレート（顧客情報・取引内容・疑義の根拠）を Markdown または JSON で生成できます。報告の要否判断は人間が行います。
実際のコード生成例として、以下のプロンプトを示します。
あなたは AML 対応システムの開発者です。以下の条件で疑わしい取引の自動検知ロジックを実装してください。
- データソース: transfers テーブル（from_user_id, to_user_id, amount, created_at, purpose）
- 検知条件:
1. 24 時間以内に同一送金元から 100 万円以上の分割送金（10 回以上）
2. 登録後 24 時間以内のユーザーが 50 万円以上を送金
3. 送金目的が空欄または「その他」で 30 万円以上
- アクション: suspicious_transactions テーブルに記録し、管理画面に表示
以下を出力してください。
1. 検知 SQL クエリ（各条件ごと）
2. 管理画面での確認項目リスト
3. 誤検知を減らすための追加チェック案生成されたコードを実装する際の注意点は以下の通りです。
| 注意点 | 内容 | 対応策 |
|---|---|---|
| 法令の更新 | AML/CFT 関連法令（犯罪収益移転防止法等）は改正が頻繁 | 弁護士監修のもと、定期的にルールを見直す |
| 誤検知の影響 | 正規ユーザーの取引を誤ってブロックすると顧客満足度低下 | 人間による最終確認プロセスを必ず設ける |
| ログの保管期間 | 疑わしい取引の記録は法令で保管期間が定められている | 自動削除設定の誤りに注意（通常 5〜10 年） |
| プライバシー保護 | 検知ログに含まれる個人情報の取扱い | アクセス権限の厳格化、暗号化、監査ログの記録 |
Claude Code はあくまで「コード生成支援」であり、AML/CFT 対応の責任は企業・経営者が負います。生成コードを本番環境に導入する前に、必ず法務・コンプライアンス部門のレビューを受けてください。
金融業界における Claude Code 活用事例 では、他の業務領域での活用例も紹介しています。
人間レビュー必須のチェックポイント
Claude Code を FinTech 決済処理に活用する際、以下の項目は 必ず人間がレビュー します。AI が生成したコードをそのまま本番デプロイすることは、セキュリティリスク・法令違反リスクの観点から推奨しません。
絶対に AI 任せにしてはいけない領域: PCI DSS 準拠可否の判定、暗号鍵の生成・管理方法、AML/CFT 報告の要否判断、個人情報保護法・犯罪収益移転防止法の解釈
具体的なレビュー項目を以下に示します。
- 暗号化アルゴリズム・鍵長の妥当性: Claude Code が「AES-256-CBC」と生成した場合、実際に使用する言語・ライブラリで推奨される設定か、IV（初期化ベクトル）の扱いが適切かを確認します。NIST SP 800-38A 等の標準文書と照合してください。
- 入力検証の網羅性: 決済金額・カード番号形式・有効期限のバリデーションが、実在するカードブランドの仕様（Luhn アルゴリズム・BIN 範囲等）と一致しているかを確認します。
- エラーメッセージの情報漏洩リスク: エラーレスポンスに内部構造（DB テーブル名・SQL エラー詳細）が含まれていないか、攻撃者に有利な情報を与えていないかをチェックします。
- ログ記録の過不足: PCI DSS 要件 10 で求められる項目（誰が・いつ・何を・どう操作したか）が漏れなく記録されているか、逆にカード番号等の機密情報がログに含まれていないかを確認します。
- 依存ライブラリの脆弱性: 生成コードが使用するライブラリ（例：Node.js の
express、Python のrequests）に既知の脆弱性がないか、最新版を使用しているかを確認します。
レビュープロセスの例を以下に示します。
1. AI 生成コードの静的解析 — SonarQube・Checkmarx 等のツールでセキュリティ脆弱性をスキャンします。ハードコードされたシークレット・SQL インジェクションリスク等を検出します。
2. セキュリティエンジニアによるコードレビュー — 暗号化・認証・アクセス制御の実装が設計方針と一致しているか、OWASP Top 10 の脅威に対処できているかを確認します。
3. コンプライアンス担当によるチェック — PCI DSS・AML/CFT の要件に照らし、ログ記録・データ保持期間・報告フローが法令に準拠しているかを確認します。
4. ペネトレーションテスト — 第三者のセキュリティ専門家（ホワイトハッカー）が実際に攻撃を試み、脆弱性の有無を検証します。
これらのレビューを経て初めて、AI 生成コードを本番環境にデプロイできます。レビューコストを惜しむと、情報漏洩・不正利用・法令違反のリスクが高まります。
まとめ
Claude Code を FinTech 決済処理に活用する際のポイントを以下に整理します。
- PCI DSS 対応: Claude Code は設計の壁打ち・コード生成を支援しますが、準拠可否の最終判断は QSA または社内コンプライアンス担当が行います
- カード情報非保持化: トークン化・外部 PSP 連携の設計案を生成できますが、実際の PSP 仕様・業務フローとの整合は人間が確認します
- 異常検知・AML 対応: 検知ルールのコード例・SQL クエリを生成できますが、誤検知リスク・法令遵守は人間がレビューします
- セキュリティレビュー: 暗号化アルゴリズム・入力検証・ログ記録の妥当性は、セキュリティエンジニアが必ず確認します
Claude Code は開発速度の向上に寄与しますが、「AI が PCI DSS 準拠を保証する」わけではありません。生成コードはあくまで「参考実装」であり、本番採用には人間の専門知識が不可欠です。
デジライズ では、FinTech 企業向けに Claude Code 法人導入支援 を提供しています。PCI DSS 対応を含むセキュリティ要件の整理から、AI 生成コードのレビュープロセス設計、開発チームへの研修まで、2 本柱（研修＋コンサル）で支援します。決済システム開発における AI 活用の進め方にお悩みの方は、ぜひ 無料相談 をご利用ください。実際のコード例・レビューチェックリストを用いた具体的なアドバイスを提供いたします。
関連記事
デジライズの実績は社内集計値です。特に明記のない数値付き事例は、匿名加工された実例をもとにしたモデルケースです。導入効果は企業や業務によって異なります。各サービスの料金・機能・提供条件は記事の公開・更新時点の情報であり、変更されるため、最新情報はAnthropic公式サイトなどの一次情報をご確認ください。
Claude Codeの法人導入・研修・業務活用を支援しています。
法人導入支援サービスを見る
