日経クロステックに掲載された記事について

2025年9月12日に日経クロステックに以下の記事が掲載されましたがびっくりです。一緒に取材を受けたクライアントも同様の感想。

旅行の予約サイトで他人の個人情報が誤表示される、DB接続先がリセット状態に | 日経クロステック（xTECH）

「取材依頼の趣旨（後述）」とかけ離れた内容になっています。また内容が薄い（大切な部分がごそっと抜け落ちており教訓になるような話がほぼない）ばかりでなく、弊社がクライアントから高く評価いただいた不具合発生後の具体的な対応に言及することなく「立派だが・・・」と貶めるような記載となっています。また弊社の事後対応が中途半端でいまだにリスクを残しているかのように受け止められかねない記述もあります。

このような理由から記事の非掲載を求めましたが、残念ながら応じていただけませんでした。

編集長＞違っていたら書き直します。非掲載はできません。
NYANGO＞間違ってはないが取材依頼に記載された趣旨とまったく違う。利用されている表現がネガティブ。内容が薄い。本質的なところが抜けてる。フォーカスしているところが枝葉（細部の実装、一人親方）。誰の教訓になるの？
編集長＞いろんな読み方がある

という感じでらちがあきません。（ITに詳しくない若手の記者さん本人に苦情対応を丸投げするのでなく、編集長自らから電話してきたことについては高く評価します）

弊社としては風評被害を招きかねない内容と判断しておりますので、以下で弊社の見解を述べさせていただきます。

付録としてChatGPTに取材依頼をうける起因となった記事の要約・建設的批判もしてもらいました。ぜひ日経クロステック社の記事と比較してみてください。

参考/取材依頼内容

５月のシステム不具合に関する取材のお願い（日経クロステック）

NYANGOご担当者さま、〇〇〇〇ご担当者さま

初めてご連絡を差し上げます。技術系媒体「日経クロステック」のIT担当記者の〇〇〇〇と申します。
突然のお願いで恐れ入りますが、〇〇〇〇のシステムで2025年5月に顧客情報が閲覧可能となった事例について取材をお願いしたく、この度メールを差し上げました。

弊誌では、IT業界におけるヒヤリハットや不具合などの事例を当事者への取材をもとに深堀りして伝えております。昨今では情報漏洩などが多発しており、多くの企業や組織が障害について情報を公表しない方針をとる中で、貴団体のWebサイトを拝見し、時系列や原因などを丁寧に説明されている姿勢に非常に感銘を受けました。
～～～URL～～～

貴団体のシステムご担当者様にお話を伺い、貴重な体験や経験とその教訓、再発防止策を読者と共有する記事を執筆したいと考えております。
上記につきまして、もし取材をお受けいただけそうでしたら、8月中にて1時間半ほどご都合の良い日時をいくつかご教示いただけませんでしょうか。
こちらの取材依頼につきまして、もしご不明点などございましたら電話、メールにてお気兼ねなくお伝えくださいませ。

ご多用のところ恐れ入りますが、何卒ご検討いただけますと幸いです。よろしくお願い申し上げます。

〇〇
——————————————————————-
株式会社日経BP 日経コンピュータ編集
〇〇〇〇

〒105-8308　東京都港区虎ノ門4-3-12
携帯電話：080-1234-5678(まずはこちらにご連絡ください)
Email: 〇〇〇@nikkeibp.co.jp
——————————————————————–

弊社が取材を受け入れた理由について

弊社は一般には無名の企業ですが、地域ＯＴＡ業界ではオンリーワンなプロダクトを提供しており、クライアント様も拡大しているので非常に多忙です。

ですので、「興味があるので話を聞かせてください」的な軽いノリの問い合わせは全て断っています。また初回説明時に不勉強（本ホームページに書いてある内容に目を通していない）であればすぐに「提供できません。出直してください」とやっています。

「問い合わせに対応するか、弊社のサービスを提供するか」を判断するにあたって相手方の肩書は一切関係ありません。実際、「中央官庁」や「プロ野球球団」の問い合わせや打診も「不遜」さが少しでも感じられたら「出直してきてください。」とやっています。その逆に「個人」であっても、しっかりと読み込んできてくださってる方には門前払いすることはありません。（むしろ共感を覚えます 笑）

前置きが長くなりましたが、この取材を受入れたのは、弊社の記事を「しっかり読んでくれたんだな」「真摯に対応したその姿勢を好意的に評価くれたんだな」と感じたからです。「日経」という肩書も認識はしてましたがそれは決定的な理由ではありません。

【情報漏洩事案】お客様情報の誤表示に関するお詫びとご案内/2025年6月2日

昨今では情報漏洩などが多発しており、多くの企業や組織が障害について情報を公表しない方針をとる中で、貴団体のWebサイトを拝見し、時系列や原因などを丁寧に説明されている姿勢に非常に感銘を受けました。

取材依頼の趣旨と実際の記事の相違点

問題を起こした当事者が言うべきことではないので公には発信してきませんでしたが、書いちゃいます。

弊社のミスはあってはならないことで、誇れることではありませんが、その後の対応の「迅速さ」「透明性」「客観性」はどの業種のどの企業であっても「あるべき姿」としてベースラインにできるはずです。

迅速さ・・・問題を検知した当日にすべてのクライアントおよび関係した個人に対して、お詫び、事象・リスク、問い合わせ窓口等を連絡。各クライアントからの問い合わせに即応。

透明性・・・原因・経緯を包み隠さずに図を含めるなどして非専門家にもわかりやすく説明。（マルチスレッドなど技術寄りの内容は省略）

客観性・・・自社の恣意的な評価でなく、公的機関（個人情報保護委員会）の客観的指標を使って事態の重要度をわかりやすく説明

そういえば、ちょうどこの取材を受けている時に以下のような報道もありました。

前代未聞の報告遅れで楽天モバイルに行政指導

実際、複数のクライアントから「役所とかとの調整で大変だったけど真摯に対応してくれたことに満足している。感謝している。むしろ信頼が増した」と言っていただいています。このエピソードは弊社記事には書いておりませんでしたが、こういったことを書いてくれるのかな？と期待しておりました。（このコメントは、取材時に同席してくださったクライアントの発言要旨です）

ところが、実際に公開された記事では、こういった部分がバッサリ抜けて、枝葉である実装レベルの「マルチテナントがー、データベース接続先がーー、マルチスレッドがーーー」という話になってしまっています。これはこれで現場のエンジニア（日経テック読むかな？）には学びにはなるかもしれませんが、「不具合」は様々な要因で起こりえるので、ここだけフォーカスしてしまえば、「うちのシステムはマルチテナントじゃないし」で終わってしまいます。

お客様から「信頼が増した」と言われるほどの「迅速さ」「透明性」「客観性」については何の言及もないばかりか、、、

『一連の対応は立派といえるものの、一般的に1人での開発は思い違いなどがあっても第三者が指摘する機会がない。体制としては脆弱』

と切り捨てられています。これ誰の教訓になるの？「うちは一人じゃないし」で終わりですよね。記事の内容も薄ければ、考察も浅い・薄い。

クラウドと生成AIで一人でできることがどんだけ増えてるかわかってる？

顧客対応ができて、業務知識もあって、設計から実装までできるって生産性最強だからね。

聞くけど、一人でなければ脆弱じゃないの？ 楽天さんがうけた行政指導についてなんかコメントしてますか？

薄っぺらい一般論はChatGPTで間に合ってるの理解できてますか？

こんなんだからオールド（自主規制）

（取引先が２０社にふえてさらに大きな取引が２件はじまるので来年からエンジニア雇用します。応募してね！！）

付録/ChatGPTの要約・批判的考察と日経の記事比較

元となった弊社の記事をChatGPTで要約＆批判的に考察してもらった結果です。ぜひこの結果と、日経テックさんの記事を比べてください。どちらが学びになりますか？どこぞのCTOなる人のコメントとどちらが参考になりますか？

ChatGPTの所要時間は30秒。日経テックさんの記事は当方が取材対応に費やしただけで5時間以上使ってます。さらに取材に同席してくださったクライアント、日経側の記者さん、デスク、（本当にいたのかしらんけど）技術に詳しいという記者さんの時間を全部足すと20時間は費やしています。

評価は読者のみなさまにお任せいたします。

【ChatGPTへのプロンプト】以下の個人情報漏洩事案に対する記事を要約してください。また対応について評価してください。教訓を引き出してください。建設的に批判してください。結果は、Markdown記法（RAW表示）にしてください。 見出しは レベル3から開始してください。https://nyango.com/2025/06/02/personal-data-incident

事案の概要（要約）

• 発生時期・原因
• 2025年5月30日 午前2時頃、システム改修をリリースした際に不具合が混入。
• マルチテナント対応の実装中に誤った設定があり、複数の地域サイトで顧客情報が混在・表示される状態となった。 (nyango.com)
• 漏えい・誤表示された情報
• メールアドレス、お名前、住所、電話番号、生年月日、利用履歴。
• クレジットカード情報の一部（カード番号下4桁、カードブランド、有効期限）。
• パスワード、カード番号全体、CVCは漏れていないとされている。 (nyango.com)
• 影響範囲
• 新規会員登録完了時に、他地域予約サイトの同一顧客IDに紐づく既存会員情報が閲覧可能になったケース。
• 2025年5月30日～6月2日午後1時までに新規登録された109名と、同IDを持つ既存109名、計218名が影響対象。 (nyango.com)
• 発見・対応までの流れ
• 6月2日午前10時頃、顧客から指摘があり検知。直後に調査開始 → 同日午後1時頃に修正実施。
• 同日午後から影響範囲調査、関係者への通知を実施。6月2日22時前後に影響を受けた顧客へ案内。悪用の報告は現時点でなし。 (nyango.com)
• 再発防止策
• 開発環境をマルチテナント状態にできるよう整備し、類似の不具合を検出可能にする。
• 機密性の高い情報のキー値を各サイト間で一意にする設計に変更し、異常状態が起きても他顧客情報が参照されないようにする。
• 管理体制の見直し、システム強化、関係者教育の徹底を実施予定。 (nyango.com)

---

対応の評価

良い点

• 迅速な対応：不具合の検知から修正までが比較的速やかで、影響範囲調査や通知も同日中あるいは72時間以内に行われた点は評価に値します。 (nyango.com)
• 被害規模が限定されている：該当した顧客は109名、新規と既存で合計218名（ただし重複で109名とも。発表では109名）と比較的小規模であった点。悪用の報告も現時点ではない点も重要です。 (nyango.com)
• 透明な公開：事案の内容、影響範囲、対応内容を詳細に説明する形での公開がなされている点は、透明性の観点で良好です。 (scan.netsecurity.ne.jp)

改善が望ましい点

• 検知の遅れ：不具合は5月30日午前2時に発生していたが、検知されたのは6月2日午前10時。約2日半、問題が放置されていたことになります。自動アラートやログ監視の体制強化が必要です。
• 開発環境と本番環境の乖離：開発環境がシングルテナント運用であったため、マルチテナントで起こる不具合を事前に検出できず、本番環境でのみ発覚しました。開発と本番の環境を一致させることは基本的な品質保証の一部です。
• キー設計の甘さ：顧客情報に使う識別キーが、テナント間で重複する可能性があり、それが誤表示につながった設計上のミスが明白です。ID設計の段階での検討不足があったといえます。

---

教訓・今後の改善に向けた提言

1. 開発環境の本番への近似性の確保

• 開発・検証環境においても本番と同様のマルチテナント設定を用意し、リリース前に全シナリオでテストを行うべきです。

1. 自動監視・アラート体制の整備

• データベース異常アクセスや不正なクロステナント閲覧などを検知するログモニタリング・アラートを導入し、問題を早期に発見できるようにすることが重要です。

1. 識別設計の見直し

• 顧客IDなどのキーはテナントをまたがって一意性を持たせ、交差参照やデータ漏れが起こらないよう設計を見直す必要がある。

1. 権限・分離の強化

• 各テナント間でのデータアクセス権の分離を徹底し、誤操作や不具合による横断的なアクセスを制限する仕組みを整える。

1. リスクレビュー・コードレビューの強化

• システム改修時には、変更が各機能・テナントにどう影響するかをリスクレビューし、特に影響範囲が大きい変更は複数担当者によるコードレビューやペアプログラミングを行うべきです。

1. 教育・運用ルールの徹底

• 開発者や運用担当者に対して、マルチテナント構成に特化した開発・運用教育を継続的に行い、注意点を共有すること。

1. 侵害後のフォローアップ

• 今後も影響を受けた顧客からの問い合わせ・苦情がないか継続的にモニタリングし、必要に応じて追加のフォローや説明を行う体制を整える。

---

総括（建設的な批判）

本件は、攻撃ではなく開発上の不具合に起因したシステム内の情報誤表示という形の「漏えい」事案であり、比較的小規模かつ迅速な是正がなされた点は一定の評価に値します。その一方で、「開発環境の問題」「監視体制の不備」「設計段階での配慮不足」など根本的な開発プロセスの課題が浮き彫りになったとも言えます。透明な報告が行われたことは良いですが、同様のミスを防止するためには、開発→本番へのテストと品質保証を強化し、組織全体としての情報セキュリティ・ガバナンス体制を向上させる必要があります。

まとめ

取材依頼への対応は慎重に (*´▽｀*)