ストーリー

規制制約

PCI DSS Level 1

NexPayはクレジットカード情報を処理するため、PCI DSS（Payment Card Industry Data Security Standard）Level 1への準拠が必須です。

// PCI DSS の12要件とアーキテクチャへの影響
interface PCIDSSRequirement {
  id: string;
  requirement: string;
  architectureImpact: string;
}

const pciDSSRequirements: PCIDSSRequirement[] = [
  {
    id: "Req-1",
    requirement: "ファイアウォールの設置と維持",
    architectureImpact: "CDE（カード会員データ環境）のネットワーク分離。VPC分割とセキュリティグループ設計",
  },
  {
    id: "Req-2",
    requirement: "ベンダー提供のデフォルト値を使用しない",
    architectureImpact: "IaCによる設定管理の徹底。デフォルトパスワード・設定の排除",
  },
  {
    id: "Req-3",
    requirement: "保存されたカード会員データの保護",
    architectureImpact: "トークン化サービスの導入。暗号化キーの管理（HSM/KMS）",
  },
  {
    id: "Req-4",
    requirement: "オープンネットワークでの暗号化",
    architectureImpact: "TLS 1.2以上の強制。内部通信もmTLSで暗号化",
  },
  {
    id: "Req-6",
    requirement: "安全なシステムとアプリの開発・維持",
    architectureImpact: "セキュアSDLC。コードレビュー必須。WAF導入",
  },
  {
    id: "Req-7",
    requirement: "カード会員データへのアクセスを業務上の必要性で制限",
    architectureImpact: "RBAC/ABAC。最小権限の原則。アクセスログの記録",
  },
  {
    id: "Req-8",
    requirement: "コンピュータアクセスの識別と認証",
    architectureImpact: "MFA必須。個人IDの管理。特権アクセス管理（PAM）",
  },
  {
    id: "Req-10",
    requirement: "ネットワークリソースとカード会員データへのすべてのアクセスを追跡・監視",
    architectureImpact: "集中ログ管理。監査ログの改ざん防止。1年間の保存",
  },
  {
    id: "Req-11",
    requirement: "セキュリティシステムとプロセスの定期的なテスト",
    architectureImpact: "脆弱性スキャン（四半期）、ペネトレーションテスト（年次）の自動化",
  },
  {
    id: "Req-12",
    requirement: "情報セキュリティポリシーの維持",
    architectureImpact: "ポリシーのコード化。コンプライアンスチェックのCI/CD統合",
  },
];

PCI DSSのネットワーク分離設計

graph TD
    subgraph Public["パブリックゾーン"]
        CDN["CDN"]
        WAF["WAF/LB"]
    end

    subgraph DMZ["DMZ（非CDE）"]
        GW["Web API Gateway"]
        ACC["Account Service"]
        TRF["Transfer Service"]
    end

    subgraph CDE["CDE（カード会員データ環境）<br/>※ すべての通信はmTLS<br/>※ 厳格なACLで制御"]
        PAY["Payment Service"]
        TOK["Tokenize Service"]
        CDB["Card DB<br/>(暗号化)"]
    end

    CDN --> GW
    WAF --> GW
    GW --> PAY

    classDef pub fill:#3498db,stroke:#2980b9,color:#fff
    classDef dmz fill:#f39c12,stroke:#e67e22,color:#fff
    classDef cde fill:#e74c3c,stroke:#c0392b,color:#fff
    class CDN,WAF pub
    class GW,ACC,TRF dmz
    class PAY,TOK,CDB cde

資金決済法

法規制: 資金決済法
適用範囲: 前払式支払手段（チャージ残高）、資金移動業（送金）
アーキテクチャへの影響:
  - 供託義務:
      内容: 未使用残高の50%以上を法務局に供託
      影響: 残高管理の正確性が法的義務。二重計上は許されない
  - 利用者資金の分別管理:
      内容: 自社資金と利用者資金を明確に分離
      影響: 勘定系の設計に分別管理の仕組みが必須
  - 犯収法対応:
      内容: 10万円超の送金にはKYC（本人確認）が必須
      影響: KYCサービスと送金サービスの連携設計
  - 報告義務:
      内容: 疑わしい取引の届出義務
      影響: AMLモニタリングシステムのリアルタイム化

金融商品取引法（投資機能）

法規制: 金融商品取引法
適用範囲: 株式・投資信託の売買仲介
アーキテクチャへの影響:
  - 適合性原則:
      内容: 顧客の知識・経験・財産に適合した勧誘
      影響: ユーザープロファイルと投資商品のマッチングロジック
  - 最良執行義務:
      内容: 顧客にとって最も有利な条件で注文を執行
      影響: 複数取引所の価格比較と最適ルーティング
  - 分別管理:
      内容: 顧客資産と自社資産の分離
      影響: 投資口座の勘定設計
  - 取引記録の保存:
      内容: 注文・約定の全記録を10年間保存
      影響: イベントソーシングによる完全な監査証跡

「法規制はアーキテクチャの”外枠”を決める。その枠の中で最善の設計を考えるのがアーキテクトの仕事だ」 — 佐藤CTO

技術制約

既存システムからの移行

既存システム制約:
  現行アーキテクチャ:
    - モノリスアプリケーション（Java 11 / Spring Boot 2.x）
    - PostgreSQL 13（単一インスタンス）
    - AWS東京リージョン（単一AZ中心）
    - Jenkins CI/CD
    - 月次リリース

  移行制約:
    - ビッグバン移行は不可（300万ユーザーのサービス継続が必須）
    - 既存APIとの後方互換性を2年間維持
    - データ移行中のダウンタイムは最大4時間（深夜帯）
    - 既存加盟店の決済端末ソフトウェア更新は段階的

  共存期間:
    - 新旧システムの並行運用期間: 12-18ヶ月
    - ストラングラーフィグパターンで段階的に移行

チーム制約

// チーム構成と技術スキルマトリクス
interface TeamConstraints {
  totalHeadcount: number;
  teamStructure: TeamUnit[];
  skillMatrix: Record<string, SkillLevel>;
}

const teamConstraints: TeamConstraints = {
  totalHeadcount: 50,
  teamStructure: [
    { name: "決済チーム", size: 12, focus: "Payment/Settlement" },
    { name: "送金チーム", size: 8, focus: "Transfer/Remittance" },
    { name: "投資チーム", size: 8, focus: "Investment" },
    { name: "共通基盤チーム", size: 8, focus: "Platform/Auth/KYC" },
    { name: "SRE/インフラチーム", size: 6, focus: "Infrastructure/SRE" },
    { name: "セキュリティチーム", size: 4, focus: "Security/Compliance" },
    { name: "QAチーム", size: 4, focus: "Quality Assurance" },
  ],
  skillMatrix: {
    "Java/Kotlin": "STRONG",     // 全チーム
    "TypeScript": "MODERATE",    // フロントエンド中心
    "Go": "BEGINNER",           // SREの一部
    "Kubernetes": "MODERATE",   // SREチーム
    "AWS": "STRONG",            // 東京リージョン経験あり
    "PostgreSQL": "STRONG",     // 全チーム
    "Kafka": "BEGINNER",        // 一部メンバーのみ
    "マイクロサービス": "BEGINNER", // モノリス経験中心
  },
};

インフラ・予算制約

制約のアーキテクチャへの影響マッピング

制約→設計判断マトリクス

モノリスの場合:
  全システムがPCI DSSスコープに入る
  → 監査対象が膨大、コンプライアンスコスト大

マイクロサービスの場合:
  Payment Service + Tokenization ServiceのみがCDEスコープ
  → 監査対象を最小化、コンプライアンスコスト削減
  → 他のサービスはカード番号に触れない設計

Phase 1（0-6ヶ月）: SQS/SNS（チームの既存スキルで対応可能）
Phase 2（6-12ヶ月）: Amazon MSK（Managed Kafka）を一部導入
Phase 3（12-18ヶ月）: イベント駆動基盤をKafkaに統一

制約の受容と交渉

すべての制約が絶対不可変ではありません。制約を3つのレベルに分類して管理します。

「例えば、年間予算3億円はCFOとの交渉で4億円に増額できるかもしれない。でもPCI DSSは交渉の余地がない。この区別を明確にしておくことで、設計の自由度が見えてくる」 — 佐藤CTO

まとめ

チェックリスト

• PCI DSSの主要要件とアーキテクチャへの影響を理解した
• 資金決済法・犯収法の制約を把握した
• 既存システムからの移行制約を理解した
• チーム構成とスキルマトリクスの制約を認識した
• 制約のHard/Firm/Soft分類を理解した

次のステップへ

次はStep 1の演習です。ここまで学んだステークホルダー分析、品質属性シナリオ、制約分析を統合して、NexPayの要件分析ドキュメントを作成しましょう。

推定読了時間: 30分