PCI SSCがAI利用の手引きを公表 義務ではない 確認する5点

PCI SSC(Payment Card Industry Security Standards Council)は、クレジットカードのセキュリティ基準「PCI DSS」などを作っている団体です。2026年9月15日の公式ブログで、AIの安全な使い方についての補足の手引き「Security Considerations for AI Systems」を公表したと発表しました。

公式ブログは、この手引きはガイダンスで、必須の要件ではないと書いています。PCI DSSが改定されたわけでも、AIの利用に新しい義務ができたわけでもありません。この記事では、公式の資料で確かめられたことと、カードを扱う会社の情シスが自社で確かめる点を分けて整理します。

公式の資料で確かめられたこと

上の図は、公式ブログの本文です。手引きの要点と、必須の要件ではないという注記が書かれています。

手引きの4つの柱

公式ブログは、手引きが次の4つの領域を説明していると書いています。

• AI Deployment and Use: AIをどう導入するか。導入の範囲と影響を見積もる方法と、枠組みの例が説明されています
• Defending Against Malicious Use of AI: AIを使った攻撃への備え。AIによる脆弱性の発見が進む時代の防御として、脆弱性の監視と管理を、頻繁に、できれば継続して行うことが重要だとされています
• PCI Standards and AI Use: AIを使う場合も、適用されるPCIの要件の範囲を考えるときは、ほかの技術と同じ扱いにするとされています
• AI Use-case examples: 決済環境でAIをどう導入し、どう審査するかの例が示されています

手引きの本体は開いていません

手引きの本体(PDF)は、PCI SSCの文書ライブラリにあります。ライブラリは、文書を開く前に利用条件(License Agreement)への同意を求めることがあります。会社として同意することになるため、この記事では本体を開いていません。公式ブログの中にも、同意なしで開ける直接のPDFの案内は見つかりませんでした。

そのため、4つの柱の説明は公式ブログの要約までです。「AI Use-case examples」にどんな例が載っているかは、確かめていません。

同じ団体が2025年に出したAIの原則

PCI SSCは、2025年9月11日に別のブログ「AI Principles: Securing the Use of AI in Payment Environments」を出しています。手引きの公式ブログも、このブログを関連の資料として挙げています。原則は「してはいけない」「すべき」「してもよい」の形で書かれていて、これもガイダンスだと断っています。ただし、最初の1項目だけは「must(しなければならない)」です。

Use of AI does not remove or bypass the need to meet the requirements of any applicable PCI SSC standard.

AIを使っても、該当するPCI SSCの基準の要件を満たす必要がなくなる、省ける、ということはない、という意味です。たとえばPCI DSSの適用範囲にある実装なら、AIも、データの保存・処理・送信の守り方を含めてPCI DSSの要件に沿う必要がある、と書かれています。

この原則から、情シスの確認に関わる記述を拾います。

• カード会員データ(口座情報)は、AIが扱う場合も十分に守られているときだけ渡す。PCI DSSの要件3(保存)と要件4(送信)は、AIを使うシステムにも同じように当てはまる
• 守られていない口座情報、APIの認証情報、暗号鍵は、AIに使わせるデータに入れない
• 正式に責任を負う操作や役割は、AIには向かない。鍵の管理者や、管理職レベルの承認はその例
• 作成から本番への反映までの流れを、人が関与しないまま、AIにすべて任せない。全体を見て責任を持つ人が常にいる状態にする
• AIの操作は、記録して監視できるようにし、行動の責任を負う人を1人決める。可能なら、AIに入力した内容と、答えに至った過程も監査できる記録にする
• AIには、仕事に必要な範囲だけの権限と情報を渡す。PCI DSSの要件7の「最小権限」と「知る必要があること」の考え方と同じ
• 問題が起きたとき、すぐに止められるようにしておく
• AIは、導入の前から運用の間まで、期待どおりに動いているかを確かめ続ける

上の図は、AIに責任を持たせない、という原則の原文です。鍵の管理者と並んで、管理職レベルの承認や許可を出す役割が、AIには向かない例として挙げられています。

公式のブログは、AIに許される使い方の例も挙げています。

• 不正の検知やリスクの管理(以前から使われている)
• 承認の判断の入力を出すこと(たとえばパッチの検討)。その使い方を認める責任者は人
• ログの確認や、情報の収集・要約(PCI DSSの要件10.4のログの確認が例)
• 方針書やソフトウェアなどの作成の補助
• 問い合わせ窓口のチャットボットなど、利用者とのやり取り。公開された窓口は、他の利用者の情報を引き出す操作の対象になると想定する必要がある

影響する会社・しない会社

• 影響する: カード会員データを保存・処理・送信する会社(EC、店舗、決済代行、コールセンターなど)で、AIをその環境の近くで使っている、または使う予定がある会社。PCI DSSが対象とするのは、公式ページによると、カード会員データや機密認証データを保存・処理・送信する、またはカード会員データ環境の安全性に影響しうる組織です
• 影響する: 開発・運用・ログ確認などの業務にAIを使い、そのAIがカード会員データの環境に接続している会社
• 影響しにくい: カード情報を自社では持たず、決済代行会社の画面にそのまま遷移させる形のEC事業者。ただし、自社のどの範囲が基準の対象になるかは、契約先の決済代行会社や審査機関(QSA)が決めます(編集部の補足)
• 影響しない: カード決済を扱わない会社。PCI DSSの適用対象ではありません

情シスが今日やること

1. 自社でAIを使っている場所を書き出す。問い合わせ対応、ログの確認、開発や運用の補助など。カード会員データの環境(保存・処理・送信する場所と、それに接続する場所)に触れているものに印を付ける
2. 印を付けたAIについて、カード会員データやAPIの認証情報、暗号鍵に触れるかを確かめる。触れるなら、渡す範囲を絞る。守られていない口座情報は、AIに渡さない
3. AIに与えている権限を見直す。AI専用の認証情報にして、必要な範囲だけにする。止める手順も決める
4. AIの操作の記録を取れるか確かめる。AIごとに、責任者を1人決める(編集部の補足: 変更の承認や、本番への反映は、AIだけで完結させない運用にする)
5. 契約先の決済代行会社や審査機関(QSA)に、AIを入れた範囲が適用範囲にどう関わるかを確かめる。AIを使った攻撃への備えとして、脆弱性の確認の頻度も見直す(公式は、頻繁に、できれば継続して行うことを重視)

書かれていないこと

次の点は、確認できた公式のページには書かれていません。この記事でも、書きません。

• 手引きの本体の細かい内容と、AI Use-case examplesの具体的な例
• 手引きに沿っているかを、審査で確認するかどうか
• 日本のクレジットカード・セキュリティガイドラインなど、国内の制度との関係(この記事では確かめていないため、触れていません)

AIの原則のブログは2025年9月11日の投稿で、2026年9月の手引きの本体とは別の資料です。原則の中身が、手引きにそのまま載っているかどうかは、本体を開いていないため分かりません。

最近の動きは、PCI SSCのブログのAIの分類ページで追えます。2026年4月から10月にかけて、連載「The AI Exchange: Innovators in Payment Security」が複数回、掲載されています。