スマレジ連携アプリの情報漏洩｜氏名11万件流出の原因・対象者と10月のPHP脆弱性対応

2026年1月8日、SNSに「スマレジがサイバー攻撃を受けて個人情報が流出した」という投稿が出ました。スマレジの調査では、スマレジ本体からの流出は確認されず、スマレジ・アプリマーケットで提供されていた外部アプリ「書類上手/見積・請求書,＋invoice」の提供元、合同会社coastlineが管理するデータベースから情報が流出していました。3月の最終報告で、流出は氏名110,359件・電話番号100,293件、原因はデータベースのアクセス制御の不備と確定しています。2026年10月には、PHPの重大な脆弱性への対応をスマレジが公表しましたが、こちらは1月の件とは別の事案で、不正アクセスや情報流出の兆候は確認されていないとしています。その後も、10月26日に管理画面・セルフサービス、27日にウェイター管理画面のPHP対応版が公開されました。この記事では両社の公表資料に基づく事実を時系列で整理したうえで、連携アプリを使う店舗と、外部アプリを受け入れるプラットフォーム側が確かめる点をまとめます。

まとめ：スマレジ連携アプリの個人情報流出で確定した事実と対象者

流出したのは、スマレジのPOSを契約する店舗（加盟店）そのものの情報ではありません。外部アプリと連携設定をしていた8社の店舗に属する顧客、つまり店舗のエンドユーザーの氏名と電話番号です。スマレジの公表資料には、スマレジ自身のサーバーやシステムからの流出は確認されていないと繰り返し書かれています。

自分が対象かどうかは、利用していた店舗、またはcoastlineの問い合わせ窓口での確認が必要です。2026年10月に「スマレジ」と「脆弱性」が並んだ情報を見た場合、それはPHPの脆弱性への対応のお知らせで、スマレジの説明では、店舗側での対応は不要です。在庫管理、セルフサービス、ウェイターの各管理画面のPHP対応版は10月22日から27日にかけて順次公開され、在庫管理とウェイターのお知らせには、利用者の操作は要らないと書かれています。外部アプリを受け入れる側の教訓は、連携先のデータベースが本体と同じ水準で守られているとは限らない、という点にあります。

スマレジ・coastlineの公表の時系列｜1月8日の初報から最終報告後の状況まで

公表の流れ：スマレジ3回・coastline3回の発表内容と日付

この件では、プラットフォームを運営するスマレジと、アプリを提供したcoastlineがそれぞれ発表しています。

coastlineの最終報告は初報を「2026年1月13日付け」と書いていますが、同社サイトのページ情報では、初報ページの公開日時は1月10日18時50分で、1月13日に更新されています。その後coastlineは、2026年4月26日に公開した「お知らせ」ページで、最終確報について「2026年4月現在　個人情報保護委員会からの聞き取りを受けており」、終了しだいホームページで報告するとしています。2026年10月30日にこのページを確認した時点でも、記載は4月のままで、最終確報は掲載されていません。同じ日に見たスマレジの会社サイトのお知らせ一覧（2026年5月から10月28日までの掲載分）にも、この件の続報は載っていません。

1月8日：スマレジのSNS投稿の否定と、外部アプリ側の流出の判明

スマレジの1月8日の発表は、SNS上の「当社がサイバー攻撃を受け、個人情報が流出した」という投稿について、調査の結果スマレジからの流出は確認されていないとしました。そのうえで、特定の外部アプリで、提供元が保有する会員データが第三者に不正に取得・公開されていたことが判明したと公表しています。スマレジのサーバーに不審な挙動や不正アクセスの痕跡は無く、当該アプリからの通信を遮断し、対象の顧客に個別にメールで連絡したと書いています。

SNS投稿の具体的な中身（どこに何が掲載されたか）は、両社の資料には書かれていません。coastlineの最終報告も、事象を認識したきっかけを「ソーシャルメディア上での投稿」とだけ記しています。

1月13日：流出対象のアプリ名・連携8社・氏名と電話番号の件数の公表

スマレジの1月13日の続報で、対象アプリが「書類上手/見積・請求書,＋invoice」であること、対象が同アプリと連携設定をしていた8社の店舗に属する顧客情報であることが示されました。この時点の件数は氏名136,346件、電話番号114,951件で、「現時点で確認できているもの」とされています。

スマレジが2026年1月8日20時50分頃に個別メールを送った相手は、対象となる自社のPOS契約店舗です。影響を受ける可能性のある顧客や関係先への対応は、coastlineがホームページへの連絡先の掲載と電子メールなどで行い、最終報告の時点で完了したとしています。スマレジは当該アプリをアプリマーケットで非公開にし、スマレジのサービスへのアクセスを遮断しました。

流出した店舗顧客情報の範囲と、速報値・最終報告による件数の比較

最終報告で確定した氏名110,359件・電話番号100,293件

coastlineの最終報告（2026年3月5日）が流出した個人情報として挙げているのは、アプリを連携設定していた店舗に属する顧客の氏名110,359件と電話番号100,293件の2項目です。メールアドレスや住所は、流出項目として挙がっていません。1月13日の速報値より、氏名で約2万6,000件、電話番号で約1万5,000件少ない数で確定しました。

件数が減った理由は、両社の資料には書かれていません。不正アクセスが起きた時期も、最終報告には記載がありません。

連携していた8社の名前は、スマレジとcoastlineの資料には出てきません。ただし、自社で公表した店舗もあります。合羽橋の料理道具店、釜浅商店の1月27日のお知らせは、自店分を氏名5,375名・電話番号1,825名としています。対象は、2025年8月20日に同店が対象アプリを使い始めるより前に、店頭または電話で会員登録した人です。ECサイトだけの利用者は含まれません。自転車販売のサカイサイクルは3月10日の最終報告で、流出した項目を氏名（フリガナ含む）と電話番号としています。

速報値はスマレジが「現時点で確認できているもの」として出した数で、確定値はデータを管理していたcoastlineが出しています。報道などで速報値が引用されている場合は、最終報告の数に読み替えてください。

氏名と電話番号の組み合わせで想定される店舗や取引先を装った悪用

氏名と電話番号が対になって流出すると、店舗やスマレジ、関係先を名乗る電話やSMSに使われやすくなります。流出元が見積書や請求書を作るアプリだったため、取引先を装った請求の連絡を受ける可能性もあります。スマレジは1月13日の続報で、スマレジや関係先企業を装った不審なメールや電話には応じず、開封やリンクへのアクセスを控えるよう呼びかけました。最終報告の時点で、二次被害は確認されていません。

原因はcoastlineのデータベースのシステム構成とアクセス制御の不備

coastlineの最終報告が示したデータベースの流出原因と再発防止策

coastlineの最終報告は、原因を「当該アプリケーションのバックエンドシステム（データベース環境）において、外部からのアクセスに対する設定および運用管理体制の不備」と判断しています。具体的には、データベース管理に関連するシステム構成とアクセス制御に不備があり、第三者の不正アクセスを許す要因になったとしています。脆弱性の名前や攻撃の手口は書かれていません。

再発防止策として同社が挙げたのは、顧客情報を保管するサーバーをインターネットから直接アクセスできないよう遮断し、許可した管理端末からのみ操作できるようにすること、専門家による定期的な脆弱性診断と設定ミスを自動で検知する監査の仕組み、24時間体制の監視と異常検知の3点です。個人情報保護法の報告対象に当たるとして、個人情報保護委員会への報告も完了しています。スマレジ自身が当局へ報告したかどうかは、スマレジの資料には書かれていません。

自社データベースの接続許可ルールを確かめる読み取り専用のSQL

外部アプリの提供元に限らず、自社のデータベースについても、インターネットからの接続経路と認証設定を確認する必要があります。PostgreSQLを使っている場合、どのアドレスで接続を待ち受け、どこからの接続をどの認証方式で許しているかを、次のSQLで一覧にできます。coastlineがどのデータベース製品を使っていたかは公表されておらず、これは自社の点検用の例です。

-- 接続を受け付けるアドレスと、どこからの接続をどの認証方式で許可しているかを確かめる（PostgreSQL 10以降・参照のみ）
SHOW listen_addresses;

SELECT line_number, type, database, user_name, address, netmask, auth_method, error,
       CASE
         WHEN auth_method = 'trust' AND type <> 'local'
              AND address NOT IN ('127.0.0.1', '::1') THEN '要修正：パスワードなしで外部からの接続を許可'
         WHEN (address = 'all' OR netmask IN ('0.0.0.0', '::')) AND auth_method <> 'reject' THEN '要確認：全アドレスから接続可能'
         WHEN auth_method = 'trust' THEN '要確認：同じサーバー上からはパスワードなしで接続可能'
         ELSE ''
       END AS finding
FROM pg_hba_file_rules
ORDER BY line_number;

PostgreSQL公式ドキュメントによると、pg_hba_file_rules は既定ではスーパーユーザーしか読めません。設定ファイルの現在の内容を表示し、サーバーが最後に読み込んだ内容とは限らない点にも注意してください。PostgreSQL 18.6 で、initdb が作る既定の設定に「全アドレスからscram-sha-256で接続可能」の行と「10.0.0.0/8 からパスワードなし（trust）」の行を足して実行すると、前者が「要確認」、後者が「要修正」と表示されました。SQLは参照だけで、設定は変えません。error 列に値が出た行は書式の誤りです。誤りが1行でもあると再読み込みは失敗し、ファイル全体が反映されないまま、従来の認証設定で動き続けます。サーバーログには、pg_hba.confのパスに続けて「was not reloaded」と記録されます。

この判定は行ごとの確認候補で、実際に使われる認証方式とは限りません。また、このSQLの行番号順は、設定を別ファイルから読み込む構成では認証ルールの評価順と一致しません。PostgreSQL 16以降でinclude等を使う場合は、file_nameとrule_numberも表示し、rule_number順で確認してください。pg_hba.conf は上から順に照合し、接続の種類・接続元・データベース・ユーザーが最初に一致した行だけを使います。上の試験では「全アドレス」の行が先にあるため、10.0.0.0/8 からの接続も実際にはパスワード認証になり、trust の行は使われません。それでも、上の行を消したり順番を入れ替えたりした瞬間にパスワードなしの接続が通るようになるので、「要修正」の行は消すか認証方式を変えておきます。直したら SELECT pg_reload_conf(); で設定を読み込み直し、新しい接続で認証が求められることを確かめます。「全アドレスから接続可能」の行は、データベースの手前にあるファイアウォールやセキュリティグループで接続元が絞れているかを確かめてください。社外から届く経路が残っていないかを第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断を受ける方法もあります。

データベースの公開ポートに対する社外回線からの接続可否の確認

接続許可ルールが正しくても、データベースのポートそのものがインターネットに開いていれば、総当たりや未修正の脆弱性を狙われます。coastlineが再発防止策の1つ目に「インターネットから直接アクセスできないよう遮断」を挙げたのも、この入口を塞ぐためです。次のbashスクリプトは、自社が管理する公開ホストについて、代表的なデータベースのポートに社外から接続できるかを確かめます。TCPの接続を試すだけで、データは送りません。他社のホストには使わないでください。

#!/usr/bin/env bash
# 自社が管理する公開ホストで、データベースの代表的なポートがインターネットから届くかを確かめる
# 社外の回線（自宅回線やクラウド上の検査用VMなど）から実行する。接続を試すだけで、データは送らない
# 使い方：bash check-db-exposure.sh app.example.co.jp 203.0.113.10
ports="1433 3306 5432 6379 9200 27017"   # SQL Server / MySQL / PostgreSQL / Redis / Elasticsearch / MongoDB

if [ "$#" -eq 0 ]; then
  echo "使い方：bash check-db-exposure.sh ホスト名またはIPアドレス ..." >&2
  exit 2
fi

# 5秒で打ち切ってTCP接続を試す。LinuxとGit BashはGNU timeoutとbashの/dev/tcp、timeoutの無いmacOSは標準のncを使う
if command -v timeout >/dev/null 2>&1; then
  probe() { timeout 5 bash -c 'exec 3<>"/dev/tcp/$1/$2"' _ "$1" "$2" 2>/dev/null; }
elif command -v nc >/dev/null 2>&1; then
  probe() { nc -z -G 5 "$1" "$2" >/dev/null 2>&1; }
else
  echo "検査できません：timeout も nc も見つかりません" >&2
  exit 2
fi

for host in "$@"; do
  for port in $ports; do
    if probe "$host" "$port"; then
      echo "[要確認] $host:$port がインターネットから接続を受け付けている"
    else
      echo "$host:$port この検査では接続が成立しなかった"
    fi
  done
done

macOS 26.6.2（bash 3.2.57・timeoutコマンド無し）で example.com に対して実行すると、6つのポートはすべて「この検査では接続が成立しなかった」になり、対象を443番に変えると「要確認」と表示されました。timeoutを使う経路は、GNU timeoutの代わりにPerlのalarmで5秒で打ち切る形にして、IPアドレス指定で確かめると、1.1.1.1 の443番が「要確認」、5432番が5秒で打ち切られて「成立しなかった」になりました。「成立しなかった」には、接続の拒否、5秒以内に応答が無い場合、ホスト名を引けない場合がまとめて入ります。開いていない証明ではないので、ホスト名の綴りと、実行した回線が本当に社外かを確かめてください。社内ネットワークから実行すると、社内からだけ届く経路まで「受け付けている」と出るため、必ず社外の回線から実行します。

2026年10月PHP脆弱性（CVE-2026-109618・109619）とスマレジ対応

PHPの2件の脆弱性：認証なしのリモートコード実行と修正版の情報

PHPの開発チームは2026年10月21日、php.netのセキュリティアドバイザリで、認証なしのリモートコード実行につながる2件の脆弱性を公表しました。メモリ不足の処理中に内部データが壊れるCVE-2026-109618と、解放済みの内部状態が次のリクエストに残るCVE-2026-109619です。GitHubのアドバイザリGHSA-w8hw-w9fx-j79wでは、どちらもCVSS v4.0で9.2（Critical）とされています。php.netは、Webリクエストを処理するすべてのPHP環境が対象だとし、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを挙げています。

8.1以前は、PHPのセキュリティチームが7.4・8.0・8.1向けに最小限のソースのバックポートを出しただけで、更新版は配布されていません。ディストリビューションのパッケージは版番号を上げずに修正を取り込むことがあるので、番号だけでなく、変更履歴に2つのCVE番号があるかで判断します。版の確かめ方と、すぐに更新できない場合の設定はPHP2Shellの影響範囲と修正版で扱っています。

スマレジの公表内容：サービス継続下の暫定対応と情報流出の調査状況

スマレジは10月22日、PHPの脆弱性に関する対応のお知らせで、2件の脆弱性について自社サービスへの影響を調べていること、対応はサービスを停止せずに行うこと、現時点で利用者に対応してもらうことは無いことを公表しました。翌23日のPHPの脆弱性に関するQ&Aで示した内容は次のとおりです。

• サービスの一部でPHPを使っており、今回の脆弱性の対象になる
• 暫定対応を順次実施し、10月23日中に完了する見込み。完了すると、現時点で確認されている攻撃の手口には対策済みになる
• 現時点で、不正アクセスや情報流出の兆候は確認されていない
• レジでの会計を含め、対応中も通常どおり使える
• PHPを使っている箇所や対応の詳細は、セキュリティ上の理由で答えない

製品ごとの更新も出ています。管理画面・在庫管理は10月22日のver.4.56.1で対策を当て、23日のver.4.56.2でその対策を恒久的なものにしたとしています。アプリマーケットのスマレジ自社アプリでは、10月23日の対応完了のお知らせで、キッチンモニター、引換券モニター、オーダープリント、UberEATS LINKのサーバー側を更新し、ネイティブアプリのPAYGATE POSは対象外としました。スマレジECの利用事業者には、管理画面のお知らせとメールで個別に案内しているとしています。

製品ごとのPHP対応リリース：在庫管理・セルフサービス・ウェイター管理画面の版番号

スマレジのお知らせ一覧には、10月23日のQ&Aの後も、製品ごとのPHP対応のリリース情報が追加されています。10月26日には管理画面・セルフサービス ver.1.14.3が「PHPの脆弱性への対応を行いました」として公開され、27日にはウェイター管理画面 ver.2.46.2が「PHPの脆弱性への恒久対応を行いました」として公開されました。2026年10月30日時点で、お知らせの題名にPHPの脆弱性への対応と書かれた製品リリースは次の4件です。

在庫管理 ver.4.56.1とウェイター管理画面 ver.2.46.2のお知らせには、管理画面側の更新のため、利用者の操作は要らないと書かれています。セルフサービス ver.1.14.3のお知らせは更新内容を1行で示しているだけで、利用者の操作には触れていません。それでも10月22日のお知らせで、スマレジは利用者に対応してもらうことは無いと全体として説明しています。

ウェイター管理画面は、10月21日の ver.2.46.1 が割引計算や印刷の改善などのシステムの修正で、PHPの対応として出たのは ver.2.46.2 が最初です。2.46.2は「恒久対応」と書かれていますが、その前の暫定対応がいつ当たったかは、お知らせ一覧からは読み取れません。10月28日には在庫管理 ver.4.56.3 も出ていますが、更新内容は「システムの内部的な調整」で、PHPとの関係は書かれていません。

スマレジは、PHPを使う箇所は答えないとしています。表に無い製品がPHPを使っていない、という意味にはなりません。スマレジの管理画面を業務の仕組みに組み込んでいる事業者は、スマレジのお知らせ一覧の製品リリース情報で、使っている製品の版が上がったかを見ておくと、提供元へ問い合わせるときに状況を伝えやすくなります。

アプリマーケットの外部アプリのPHP対応状況と提供元ごとの確認

10月23日の対応完了のお知らせに名前があるのは、スマレジ自身が提供する4つのアプリだけです。アプリマーケットには、1月の書類上手のように外部の会社が提供するアプリもあります。そのサーバーがPHPで動いているか、修正版に上がったかは、スマレジのお知らせからは分かりません。1月の件は、本体が守られていても連携先のサーバーから漏れるという構図でした。PHPのような共通部品の脆弱性でも構図は同じなので、外部アプリを使っている店舗は、提供元のお知らせを見るか問い合わせて、対応状況を確かめてください。

外部連携アプリの情報流出に、店舗とプラットフォームが備える点

スマレジが示した再発防止策：外部ベンダー審査の強化と定期監査

スマレジの最終報告（2026年3月9日）は、アプリマーケット全体の運用と管理体制を見直し、外部ベンダーの審査基準を強化したとしています。具体的にはセキュリティ要件の追加と体制確認の義務化で、今後は外部連携アプリに定期的なセキュリティ監査を行うとしています。

この件の構図は、本体が侵害されていなくても、本体のデータを受け取った連携先から漏れるというものです。取引先や委託先を経由する攻撃の類型はサプライチェーン攻撃の起点別3類型で整理しています。

連携アプリが受け取れるデータを決めるAPIスコープと、その先の保存

スマレジ・プラットフォームAPIでは、アプリがアクセストークンを取得するときに使うAPIの範囲（スコープ）を指定します。共通仕様書によると、要求できるスコープはアプリのAPI設定で有効にしたものの中から選ぶ仕組みで、有効にしていないスコープを要求しても無視されます。スコープは、アプリがプラットフォームから取り出せるデータの範囲を絞る仕組みです。

ただし、一度取り出したデータをアプリ提供元が自社のデータベースにどう保存し、どう守るかは、スコープの外の話です。今回流出したのも、スマレジ側ではなく、coastlineが管理するデータベースの情報でした。書類上手がどのスコープを使っていたかは公表されていません。プラットフォーム側の審査では、アプリが求めるスコープと、提供元が実際に保存するデータの範囲の両方を確かめる必要があります。

連携アプリを入れる店舗が確かめる保存データの範囲と提供元の管理体制

外部アプリが顧客情報を取得し、提供元のサーバーに保存する構成では、氏名や電話番号がPOS本体とは別の会社のデータベースにも複製されます。連携の前に、アプリ提供元がどのデータを自社のサーバーに保存するのか、保存先は外部から直接届かない構成か、脆弱性診断を受けているかを確かめておくと、今回のような事態で影響を判断しやすくなります。使わなくなったアプリは連携を解除し、提供元に保存データの削除を依頼してください。店舗が顧客の個人データの取扱いを外部の事業者に任せる場合、個人情報保護法25条は委託先を監督するよう求めています。確認項目と契約条項の例は委託先管理と監督義務のチェックリストにまとめました。API連携で渡すデータの範囲の決め方はAPI連携の仕組みと導入判断、POSと周辺システムのつなぎ方はPOSシステムの仕組みと導入の判断で扱っています。

連携アプリの審査基準：個人情報の保存の有無・取得権限・機密性

顧客の氏名・電話番号などの個人情報を、提供元のサーバーに保存する連携は、セキュリティ要件の確認を必須にすべきです。今回の流出は、まさにこの形の連携で起きました。本記事では、保存の有無に加え、スマレジのAPIスコープで許可する操作と取り扱う情報の機密性を審査基準にすることを提案します。保存しない連携でも、個人情報の取得権限を持つ場合は認証情報の管理を確認すべきです。保存するデータの種類で審査の重さを分け、個人情報を保存する連携から順に定期監査の対象にするのが現実的です。

個人情報流出時の報告と本人への連絡におけるアプリ提供元とスマレジの分担

今回は、流出元のデータを管理していたcoastlineが個人情報保護委員会に報告し、影響を受ける可能性のある人への対応も行いました。同社は2026年4月時点で委員会の聞き取りを受けていると公表しています。スマレジは、影響が確認された自社の契約店舗への個別連絡と、Webサイトでの情報開示を担っています。店舗の側でも、サカイサイクルは関係各社と協力して委員会への報告を完了したと書き、釜浅商店は委員会への報告を含む対応を進めると表明しました。顧客情報を集めた店舗も、データの持ち主として報告と問い合わせ対応の当事者になります。プラットフォーム、アプリ提供元、店舗のどこが報告と通知を担うかは、契約や委託関係によって異なるため、個別の確認が必要です。報告の類型と期限は個人情報保護委員会への報告義務で詳しく解説しています。

よくある質問

スマレジ連携アプリの個人情報流出と、10月のPHP脆弱性への対応について、店舗の利用者と事業者から出やすい質問をまとめました。

スマレジから個人情報が漏えいしたのですか？

スマレジの公表資料によると、スマレジのサーバーへの不正アクセスやスマレジのシステムからの流出は確認されていません。流出したのは、スマレジ・アプリマーケットで提供されていた外部アプリ「書類上手/見積・請求書,＋invoice」の提供元、合同会社coastlineが管理するデータベースの情報です。

どんな情報が何件流出しましたか？

coastlineの最終報告（2026年3月5日）によると、アプリを連携設定していた店舗に属する顧客の氏名110,359件と電話番号100,293件です。速報値との差分は、本文の比較表で確認できます。メールアドレスや住所は流出項目に挙がっていません。

自分が対象かどうかはどう確かめればよいですか？

対象は、外部アプリと連携設定をしていた8社の店舗の顧客です。8社の一覧は公表されていませんが、釜浅商店やサカイサイクルのように自社で公表した店舗もあります。利用している店舗のお知らせを確認し、店舗に問い合わせるか、合同会社coastlineのお客様相談窓口（[email protected]）に確認してください。coastlineは、影響を受ける可能性のある人への対応は、ホームページへの連絡先の掲載と電子メールなどで完了したとしています。

身に覚えのない引き落としやSMSは、今回の流出と関係がありますか？

最終報告で流出項目とされたのは氏名と電話番号の2つで、クレジットカード番号やパスワードは含まれていません。カードの明細に覚えのない請求があれば、今回の件と結びつけて待たずに、カードの裏面にあるカード会社の窓口へ連絡してください。一方、氏名と電話番号が対で漏れているので、店舗やスマレジ、取引先を名乗る電話やSMSには注意が要ります。身に覚えのない連絡のリンクは開かず、自分で調べた公式の連絡先に問い合わせてください。

2026年10月のPHPの脆弱性で、スマレジから情報は漏れましたか？

スマレジの10月23日のQ&Aでは、現時点で不正アクセスや情報流出の兆候は確認されていないとしています。対応はサービスを止めずに進め、暫定対応は10月23日中に完了する見込みとしていました。スマレジを使う事業者が行う対応も、現時点では無いとしています。1月の連携アプリからの流出とは別の事案です。その後も、10月26日に管理画面・セルフサービス ver.1.14.3、27日にウェイター管理画面 ver.2.46.2のPHP対応版が公開されています。

関連記事

• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位を解説
• 委託先管理とは？個人情報保護法25条の監督義務とチェックリスト・契約条項の実務
• PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版・更新できない場合の設定【2026年10月】
• API連携とは？仕組み・データ連携との違い・導入判断までわかりやすく解説
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務