割賦販売法が改正され、クレジットカード情報を取り扱う事業者は「PCI DSS準拠」または、「クレジットカード情報の非保持化」が必要です。当記事では、守るべきクレジットカード情報とは何かから、キャッシュレス決済を取り巻く状況、ガイドラインの解釈、対応策、PCI DSS最新バージョン4.0など、すべてを徹底解説します。
PCI DSSとは(ペイメントカード業界データセキュリティ基準)
PCI DSS(Payment Card Industry Data Security Standard の略)とは、クレジットカード会員の情報を保護することを目的に定められた、クレジットカード業界の情報セキュリティ基準です。
PCI DSSは2004年に国際カードブランドのAmerican Express、Discover、JCB、MasterCard、VISAの5社によって策定されました。現在はその5社が共同設立した組織であるPCI SSC(PCI Security Standards Council)によって運営/管理されています。※Diners Club は Discover のグループであり、PCI DSS においては Discover の基準を適用している。
安全なネットワークの構築やカード会員データの保護など、12 の要件に基づいて約 400 の要求事項から構成されており、「準拠」とは、このうち該当する要求事項に全て対応できていることをいいます。PCI DSS 準拠の検証方法としては、①オンサイトレビュー(認定セキュリティ評価機関(QSA)による訪問審査)又は②自己問診(SAQ、自己評価によって PCI DSS 準拠の度合いを評価し、報告することができるツール)による方法があります。
PCI DSSが策定されるまでは、カードブランドなどが独自にセキュリティ基準を定めていたため、加盟店は各ブランドの求める要求に応える必要がありました。しかし、現在はひとつの加盟店で複数のカードが使える仕組みが一般的なため、各ブランドの要求に対応するのは、非常に大きな負荷となっていました。
一方で、サイバー攻撃は巧妙化かつ多様化し、その結果、カード会員データの流出事故は大規模になってきました。このような状況のため、American Express、Discover、JCB、MasterCard、VISAの5社は共同で、セキュリティリスクの低減と効率的な運用を目的として、クレジットカード情報保護のための統一的なセキュリティ基準を策定。それがPCI DSSです。
PCI DSS準拠が必要な企業とは
一般に「カード会社」と呼ばれる企業には、VisaやMastercardなどの国際ブランドと契約して加盟店との契約や決済と精算業務を行うカード会社(アクワイアラ)と同じく国際ブランドと契約してカード会員に対してクレジットカード発行業務を行うカード会社(イシュア)の2種類があります。カード会員がカードを加盟店に提示すると、その情報は決済ネットワークを通してアクワイアラに送られ、さらにイシュアへと連携されます。この過程でカード情報が通過・処理・保存される事業者は、外部の業務委託先も含め、全てPCI DSSに準拠しなくてはなりません。

日本政府は、2020年の東京オリンピック・パラリンピック開催を踏まえ、キャッシュレス決済普及と訪日外国人増加を踏まえたATMの海外発行カードの対応やカードを消費者が安心して利用できる環境整備に向けた対策の取りまとめを関係省庁に指示しました。これを受け、経済産業省をオブザーバーとしたクレジット取引セキュリティ対策協議会が、「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」(以下実行計画)を2016年から発行しており、2020年まで毎年アップデートが行われました。
実行計画内では、クレジットカード取引にかかわる事業者の種類別に、PCI DSS準拠の期限が決められています(加盟店についてはカード情報の非保持化も選択可能)。間に合わなかった場合、罰則規定はありませんが、決済代行事業者についてはアクワイアラは契約を見直すよう求められています。また2018年6月1日に施行される改正割賦販売法では、加盟店もカード情報保護について法律上の義務を負い、アクワイアラからの指導強化や、最悪の場合は加盟店契約が解除になるといった影響が考えられます。
PCI DSSにおけるカード情報の定義
PCI DSSでは、保護の対象となるカード情報を「アカウントデータ」と呼んでいる。アカウントデータに含まれる項目は「カード会員データ」と「機密(センシティブ)認証データ」の2種類に分けられます。

「プライマリアカウント番号(PAN)」とは、カード表面に印字された16桁(American Expressは15桁)のいわゆるカード番号である(将来的には19桁化が予定されている)。「CAV2/CVC2/CVV2/CID」とは、カード裏面に印字された3桁(American Expressはカード表面の4桁)の数字で、一般的には「セキュリティコード」と呼ばれている。「全トラックデータ」は、カードの磁気ストライプに含まれる72 バイト(69 桁)の文字列で、「全磁気ストライプ情報」ともいう。対面決済で利用されるが、非対面決済の与信照会(オーソリゼーション)に必要なPANと有効期限も含まれています。
(参考:
PCI DSSにおけるカード情報の定義)
コラム:時代遅れの「セキュリティコード」に頼る理由
クレジットカードを利用し、ECサイトなどで買い物をする際に、カード番号、氏名、有効期限とともに「セキュリティコード」の入力を求められることがあります。セキュリティコードとは、カードの裏面に印字されている3桁(American Expressのみ表面の4桁)の数字です。ECサイトを利用するときに、このセキュリティコードを要求しないカード加盟店もあります。例えばAmazonでは「1クリック」購入ボタンを押せば、登録してあるカード情報だけで決済が完了します。
セキュリティコードは、安全性を高める仕組みですが、ECサイトからすれば悩ましい存在だです。決済時にセキュリティコードの入力を求められると、利用者は正規のカードを準備してコードを確認しなければならない。これが面倒で、購入をやめてしまう人が少なからずいます。ECサイトでは、このような「カゴ落ち」と呼ばれる購入者の離脱率にきわめて敏感で、セキュリティコードの入力をあえて省略しているところも。つづきは
こちらから
クレジットカード漏洩時のビジネスインパクト
守るべきクレジットカード情報

クレジットカード情報はどのように盗まれるのか
まず、最も典型的な手法としてあげられるのが、「SQLインジェクション」によるカード情報の抜き取りです。SQLインジェクションとは、ECサイトなどのWebサーバに対して、不正なデータベースコマンドを入力して、データベースサーバに保存されている情報を抜き取るという方法です。
また、バックドアによるカード情報の詐取の手口が有名です。バックドアをECサイトなどの決済を行うWebサイトのカード決済画面やアプリケーションサーバに潜ませることにより、カード情報を悪意のある第三者のサーバにも送信することができます。特徴的なのは、カードの決済情報は通常通りPSP(決済代行事業者)にも送られているため、決済は正規に完了します。そのためカード情報の流出に気付かず、長い期間に渡ってカード情報が流出し続けるということが多いです。
最後に、現在米国で急増中のPOSマルウェアによるカード情報盗難の事例を紹介します。POSマルウェアは、加盟店の店舗内のPOSマシンで使用しているネットワークと接続しているネットワーク(Wi-Fiなど)を利用しているPCなどから感染し、POSマシンやストアサーバからカード情報を検索し、外部に不正に送信を行います。(参考:
PCI DSSとは? カード情報漏えいとセキュリティ対策)
盗まれたカード情報はどう換金されるのか
抜き取ったカード情報は、本人確認の比較的甘いプリペイドカードへの残高チャージや、モバイルペイメントアプリに登録して使用されるケース、他人のクレジットカードをiPhoneに支払カードとして登録して、不正利用されるなどが考えられます。
また、入手したカード情報を自分で使用せず、偽造や不正利用に使えるカード情報リストとして販売するブラックマーケットも存在しています。カード番号・有効期限がセットになったデータが販売されています。こうして不正に得たお金が組織犯罪やテロの資金源となっているとも言われています。
カード情報が情報漏えいした加盟店の支出(例)
万一、加盟店がカードデータを流出してしまった時、ビジネスに対してどのようなインパクトがあるか。直接的な金銭支出について考えてみます。
[1]調査のコスト:500万円~1,000万円
[2]お客様へのお詫びのコスト:1人あたり500円程度
[3]他の加盟店でカード情報が不正に使用された場合:損失負担は流出させた加盟店
[4]二次被害を防ぐためにカード会社や国際ブランドによるモニタリング:加盟店負担
[5]カード会社の再発行手数料:1枚あたり2,000〜3,000円を加盟店が負担
[6]カード会社が対応するためのコールセンター運営:加盟店負担
原因を明らかにしてセキュリティ対策が完了するまではカード情報の流出が続いている疑いがあります。そのため、原則としてクレジットカード決済は一時停止措置が取られます。その間当該加盟店は顧客にクレジットカードによる支払手段を提供出来ません。(参考:
PCI DSS準拠の必要性 クレジットカード漏洩時のビジネスインパクト)
コラム:狙われる「ブランドプリペイドカード」
ブランドプリペイドはカード、発展途上国で銀行口座を持っていない人でもVisaやMasterCardを利用することを可能にするために作られたものです。アフリカなどの国では、治安の悪さ、マネーロンダリングや脱税防止の観点からも、振込んだ年金をそのままカードで使用してもらう方が国民にとっても為政者のとっても好ましいため、推進を進めている国もあります。またプリペイドカードは、国際ブランドにとっても先進国で飽和したクレジットカード市場を拡大していくために重要な戦略でです。若い世代を取りこむ戦略であることは理解できます。しかし、本人確認をほとんどせずにクレジットカードやデビットカードとほぼ同じ機能を持つカードを配布することにより、新たなカード犯罪の温床になる可能性があります。つづきは
こちらから
クレジットカード取り扱い事業者が実施すべきセキュリティ対策
クレジットカード取り扱い事業者が実施するべきセキュリティ対策として、クレジット取引セキュリティ対策協議会が取りまとめた、「
クレジットカード・セキュリティガイドライン」に基づいた対策が必要です。このガイドラインは、セキュリティ対策置の実務上の指針と位置づけられていた「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」(実施期限は2020年3月末)の後継文書となります。
クレジットカード・セキュリティガイドラインは、「割賦販売法(後払分野)に基づく監督の基本方針」において割賦販売法で義務付けられているカード番号等の適切管理及び不正利用防止措置の実務上の指針として位置付けられるものです。本ガイドラインに掲げる措置又はそれと同等以上の措置を講じている場合には、セキュリティ対策に係る法令上の基準となる「必要かつ適切な措置」を満たしていると認められます。
クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画
日本政府は、2020年の東京オリンピック・パラリンピック開催を踏まえ、キャッシュレス決済普及と訪日外国人増加を踏まえたATMの海外発行カードの対応やカードを消費者が安心して利用できる環境整備に向けた対策の取りまとめを関係省庁に指示しました。これを受け、経済産業省をオブザーバーとしたクレジット取引セキュリティ対策協議会が、「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」を2016年から発行しており、2020年まで毎年アップデートが行われました。
実行計画内では、クレジットカード取引にかかわる事業者の種類別に、PCI DSS準拠の期限が決められています(加盟店についてはカード情報の非保持化も選択可能)。間に合わなかった場合、罰則規定はありませんが、決済代行事業者についてはアクワイアラは契約を見直すよう求められています。また2018年6月1日に施行される改正割賦販売法では、加盟店もカード情報保護について法律上の義務を負うこととなっています。
必要なセキュリテュ対策内容とは
[1]クレジットカード情報保護対策として「
カード情報の非保持化」をおこなうこと。カード番号等を保持するのであればカード情報セキュリティの国際基準であるPCI DSSに準拠すること。
[2]クレジット偽造防止による不正利用対策としてICカードによる決済ができる端末を設置すること。非対面取引におけるクレジットカードの不正利用対策として、なりすましによる不正利用を防止するための対策をとること。
改正割賦販売法(抜粋)
ポイント |
内容 |
(第35条の1)
クレジットカード番号等取扱業者
|
・1号事業者 イシュア
・2号事業者 アクワイアラ
・3号事業者 加盟店
|
(第35条の16)
クレジットカード情報の適切な管理等
|
・カード情報の非保持化あるいはPCI DSS準拠
・委託先の情報管理に係る指導等の義務
|
(第35条17の15)
クレジットカードの不正使用対策の義務 |
・クレジット決済端末のIC化
・ネット上のなりすまし対策
|
コラム:個人情報保護法が求めるカード番号漏えい時の対応
個人情報保護法において、ある情報が個人情報に当たるかどうかを判断する際の根拠となるのが「容易照合性」。ほかの情報と容易に照合することができ、それにより特定の個人を識別できるかどうかということです。
カード発行会社では、カード番号から会員の氏名、住所などの個人情報を照合することは容易です。このため、カード発行会社にとってカード番号は個人情報となります。しかし、カード発行会社以外では、カード番号だけでは個人を識別できません。したがって、カード発行会社以外の事業体にとっては、カード番号のみの場合は個人情報とは見なされません。ただし、カード情報が外部に流出する際に、カード番号だけが漏えいすることはほとんどありません。つづきは
こちらから
クレジットカード情報の非保持とは
クレジットカード情報の非保持化とは、カード情報を保存する場合、それらの情報は紙のレポートやクレジット取引にかかる紙伝票、紙媒体をスキャンした画像データ等のネットワークにおいて「カード情報」を『保存』、『処理』、『通過』しないこと」をいいます。
クレジットカード情報保護において、非保持化がPCI DSS準拠と同等であると見なされるのは、クレジットカード加盟店だけであることに留意する必要がある。実行計画では、カード発行会社(イシュアー)、加盟店契約会社(アクワイアラー)、サービスプロバイダー(PSP、プロセシング事業者=決済データの処理などを受託する会社など)といった加盟店以外でカード情報を取り扱う事業者に対しては、カード情報の保持を前提とした適切な対策の構築を求めています。そのため、それらの事業者には非保持化という選択肢はなく、PCI DSSへの準拠が求められます。
(参考:
「カード情報非保持」の定義とは)
PCI SSCが提供するドキュメント・ライブラリー
PCI Security Standards Council は、PCI セキュリティ基準の開発、管理、教育、 および認知を担当する、オープンなグローバルフォーラムです。下記サイトでは、PCI DSS準拠を実現するのに役立つさまざまなツール、問診、ガイダンス、FAQ、トレーニングリソースなどの資料や情報が提供されます。是非参考にしてください。
▼参考:PCI Data Security Standard Self-Assessment Questionnaireはこちらから
https://www.pcisecuritystandards.org/document_library
認定審査機関一覧(QSA=Qualified Security Assessor)
日本国内においてPCI DSSの審査が可能なQSA(認定審査機関)は、下記のPCI SSCのサイトで、実施場所や言語で絞り込むことで、認定審査機関(QSA)の一覧が確認できます。クレジットカード情報を保存、処理、通貨する企業で、例えば、カード加盟店やカード会社、銀行、決済代行、BPO事業者などのサービス・プロバイダーが対象です。
https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors
また、QSA企業一覧は
日本カード情報セキュリティ協議会(JCDSC)のQSA/ASV企業一覧のページにも掲載されています。
PCI DSSで求められる要件
具体的にどのような基準が定められているのか、PCI DSSでは6つの目標とそれに対応する12の要件が定められています。また、カード会員データを扱う範囲と保護が必要な箇所が特定することで、効率的な準拠が実現できます。具体的にPCI DSSで定められている6つの目標とそれに対応する12の要件は以下となります。(参考:
PCI DSS 6つの目標と12の要件 PCI DSS準拠が必要な企業とは)
6つの目標 |
12の要件 |
安全なネットワークとシステムの構築と維持 |
要件1 カード会員データを保護するために、ファイアウォールをインストールして構成を維持する
要件2 システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
|
カード会員データの保護 |
要件3 保存されるカード会員データを保護する
要件4 オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
|
脆弱性管理プログラムの維持 |
要件5 すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアまたはプログラムを定期的に更新する
要件6 安全性の高いシステムとアプリケーションを開発し、保守する
|
強力なアクセス制御方法の導入 |
要件7 カード会員データへのアクセスを、業務上必要な範囲内に制限する
要件8 システムコンポーネントへのアクセスを識別・認証する
要件9 カード会員データへの物理アクセスを制限する
|
ネットワークの定期的な監視およびテスト |
要件10 ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
要件11 セキュリティシステムおよびプロセスを定期的にテストする
|
情報セキュリティポリシーの整備 |
要件12 すべての担当者の情報セキュリティに対応するポリシーを維持する
|
コラム:DUKPTによる暗号化の仕組み
DUKPT(Delivered Unique Key Per Transaction)は、米国国家規格協会の「ANSI X9.24 Part1」として規定されている、暗号化のためのプロトコルです。トランザクションごとに異なる暗号鍵による暗号化処理を行うことが大きな特徴。
サーバー側で保持しているシステム鍵(Base Derivation Key:BDK)を用いて決済トランザクションごとに異なる暗号鍵を生成、決済端末の初期設定時に、端末ベンダーが端末固有ID情報をサーバーに渡し、サーバー側はそれを基に端末用の初回鍵を作成します。つづきは
こちらから
PCI DSS準拠への対応プロセス
PCI DSS対象範囲策定
クレジットカード会員情報の取り扱い範囲特定し、PCI DSS準拠対応が必要な範囲を確定します。PCI DSS準拠対応においては、この最初の対象範囲を確定する作業がとても重要な作業となります。
FIT&GAP分析、対応方法の検討(ツール/サービス選定)
現在のセキュリティ対策状況を洗い出し、PCI DSSの要求事項とギャップ分析を行います。分析結果に基づいて、対応策の検討を行います。
システムへの実装と文書作成
システム仕様の策定をおこない、実装および運用手順/帳票などのポリシー文書作成を行います。また、執務エリアや店舗など環境整備も必要です。
運用と審査
内部スキャンや外部スキャン、ペネトレーションテストをを行います。検出事項への対応から、審査機関(QSA)へ提出する各種ドキュメント準備をおこないます。
PCI DSSの準拠対応後
PCI DSS 準拠は、お客様ビジネスの保護に不可欠な一手ですが、それだけでは十分ではありません。日々の運用改善、継続的な努力が必要です。企業が成長するにつれ、また時代とともにリスクも大きく変化しますので、各事業者は、最新の情報に基づいて、多面的・重層的な対策をする必要があります。
PCI DSS v4.0 今後のスケジュールと最新情報
PCI DSS v4.0 公開予定が延期(2021年2月26日更新)
2021年第2四半期とされていたPCI DSS v4.0の公開予定が延期された。PCI Security Standards Council(以下PCI SSC)公式ブログに掲載された新しいスケジュールでは、PCI DSS v4.0の完成は2021年第4四半期を目標としている。(参考:
https://blog.pcisecuritystandards.org/pci-dss-v4.0-timeline-updated-to-support-an-additional-rfc)
したがって、以下のスケジュールについては、アップデートがあり次第共有致します。
(参考:
PCI DSS v4.0 公開予定延期と追加RFCの実施)
改訂の目的と移行スケジュール
PCI DSS v4.0へのバージョンアップの目的は大きく2つだと考えています。1つは、ペイメントデータの安全を維持するための土台として、必要なセキュリティの強化を図ること。もう1つはステークホルダーに柔軟性を追加することです。
2021年第2四半期にPCI DSS v4.0が公開される予定です。2021年後半にかけてSAQやROCなどのサポート文書が整備され、その18ヶ月後(2023年第2四半期)に、PCI DSS v3.2.1からv4.0への移行期限が設定される予定です。
ドラフト版は最終版とは異なる可能性があるということです。RFCの結果、内容が変更される場合もありますので、2021年半ばに予定されている正式版の公開をお待ち下さい。(参考:
PCI SSC インタビュー記事)

PCI DSS v4.0移行までのスケジュール
PCI DSS v4.0で顕在化するクラウドサービスの課題
現行のv3.2.1からの改訂ポイントは、主に4つありますが、その中でも課題となるのが、「④クラウドサービスの要件への取り込み」です。PCI DSS準拠企業は、さまざまな外部委託先を活用しています。近年では、PCI DSS準拠対象となるシステムにSaaS、PaaSなどのクラウドサービスやセキュリティサービスを活用されることが増えています。ところが、日本で展開されるそれらのサービスの多くにPCI DSS準拠に活用できることをうたっているにも関わらず、自身はPCI DSS準拠をしていないという現状があります。
仮に、この問題を放置してPCI DSSに準拠していないサービスプロバイダーのサービスを使い続けた場合、認定審査機関(QSA)の審査からの指摘事項となりPCI DSS完全準拠とは言えないと判断されるケースが想定されます。
もう一点、「外部委託先との間の責任区分の明確化」についても注意が必要です。
PCI DSS準拠企業に対し、PCI DSS要件ごとの責任区分の明確化を求めています。しかし、サービスプロバイダーから情報開示が無いと、準拠側の責任範囲が分からないので、この要件を満たすことができず、PCI DSSに準拠できないことになってしまいます。言い換えると、責任区分を明示した文書を提供していないクラウドサービスを利用してPCI DSSに準拠することはできない可能性があるため注意が必要です。(参考:
PCI DSS準拠のために導入したクラウドサービスがPCI DSS準拠してない矛盾)
PCI DSS準拠のためのコンサルティング/クラウドサービス
PCI DSS Cloud プライベートクラウドモデル
プライベートクラウド環境を利用したい決済代行事業者、サービスプロバイダー、BPO事業者等向けにPCI DSS Ready CloudはPCI DSSの全要件の準拠を支援します。クレジットカードを取り扱う事業者向けのマルチテナント型プロバイダー、クラウドサービスを展開する事業者に利用されており、フルカスタマイズ、スケールアップが可能なサービスです。
PCI DSS Cloud AWSモデル
決済ソフトウェア会社、カード会社、スタートアップ事業者、Fintec事業者向けにAWSに最適化されたPCI DSS Ready CloudでPCI DSSの全要件の準拠を支援します。現在最も多くのお客さまに利用されており、AWSのPCI DSS準拠済コンポーネントと組み合わせることで最も短期で、リーズナブルに構築、運用が可能です。
PCI DSS準拠支援コンサルティング
PCI DSS準拠またはクレジットカード情報非保持化に伴う、PCI DSS対象範囲の策定、ギャップ分析、最適なツールやサービス選定支援、ドキュメント作成支援、審査支援まで幅広くサービスを提供します。本コンサルティングは国内トップクラスの実績と、可能な限り、運用コストを下げる構築支援が特長です。
BIZTELコールセンター PCI DSS
コールセンターで保存、処理、通過されるクレジットカード情報を、セキュリティを確保しながら取り扱うことができる PCI DSS要件に準拠済みのクラウド PBX サービスを、低コストで提供しています。国内導入実績トップのBIZTELにPCI DSS準拠したことで、アウトソーサーは電話によるクレジットカード決済処理など、新たな事業展開での利用が広がっています。
PCI DSS 事例
クレジットカード情報非保持化 事例
“Pay TGは非対面加盟店の現場に寄り添い、一から設計されたサービス。オペレーターの負担を最小限に、スムーズにカード情報非保持化を実現できるサービスです”

オルビス株式会社 CRM・顧客満足推進部 部長 橋本 祥永 氏
改正割賦販売法の技術的指針である実行計画に基づいた高いセキュリティレベルを担保したうえで、現場のオペレーターが使いやすい仕組みであることが大切です。その点で、Pay TGは、非対面加盟店の現場に寄り添い、一から開発していることに強みがあると感じます。
一つ例を挙げると、テンキーでカード番号を入力した際の表示があります。他社サービスの場合「*****」といったように、入力したカード番号が見えないようマスクされるケースがありますが、Pay TGは、確定されるまではカード番号がそのまま画面に表示される仕様となっています。(参考:
オルビス株式会社 様 導入事例)
PCI DSS準拠 事例
“ 新サービスの宿泊予約エンジン「メトロブッキング」に必須となる、PCI DSS 準拠のシステムを1ヵ月で構築。
低コストで、スピード感あるローンチに成功しました ”

株式会社メトロエンジン 取締役 和田拓馬 氏
PCI DSS Ready Cloud AWSモデルを採用した最も大きな理由は、システムを自社で構築する方法、他社のサービスを利用する方法と比較して低コストで準拠環境を実現できることです。
コスト以外の理由が、短納期での対応ですね。当社はスピード感のある経営を心がけており、サービスのアイデアが生まれ、プロジェクトが始まってから、だいたい1、2ヵ月で、MVP※を完成し、市場でテストマーケティングさせることを目指しています。メトロブッキングも、4月末にプロジェクトが始まり、6月中にリリースするというタイトなスケジュールを組みました。リンクにそのような短期の構築が可能であるか否か確認したところ、自信をもって「できる」との回答をいただき、本当に心強く感じましたね。(参考:
株式会社メトロエンジン 様 導入事例)