漏えいだけではない――観光列車の不正アクセス事案から考える「予約データの正しさ」の守り方

「予約システムは、いつもどおり開ける」
「お客様の名前も、利用日も表示されている」
「だから、その情報をもとに接客や手配を進めてよい」

その判断の前に、もう一つ確認したいことがあります。

画面に表示されている予約は、本当にお客様と約束した内容でしょうか。

例えば、お客様の手元には予約完了メールがあるのに、事業者の画面ではキャンセルになっている。申込みを受けた記録がないのに、予約枠が埋まっている。こうした状態では、システムが動作しているだけでは、安心して仕事を進められません。

2026年9月、あいの風とやま鉄道は、観光列車の座席管理システムへの不正アクセスを公表しました。公表内容には、個人情報の漏えいのおそれだけでなく、予約の取消しや、正規の手順によらない予約が確認されたことも含まれています。

今回は、この事案を入口に、宿泊施設、体験教室、美容室、修理受付など、予約を扱う中小企業が考えたい「データの正しさ」と「業務を再開するための確認」を整理します。

目標は、単に予約画面を復旧させることではありません。お客様との約束を確認し、正しい内容でサービスを提供できる状態へ戻すことです。

公表資料で確認できること――9月28日の続報も踏まえる

あいの風とやま鉄道は2026年9月15日、観光列車「一万三千尺物語」の座席管理システムへの不正アクセスを公表しました。9月8日に複数の予約取消しと正規の手順によらない予約を発見し、新規予約の受付を停止。調査により、9月2日から8日までに複数回の不正アクセスがあり、1,409人分の個人情報が漏えいしたおそれを確認したと説明しています。

ここで、1,409人という数は、個人情報が漏えいしたおそれのある対象者数です。予約が取り消された件数を示すものではありません。また、公表資料では原因を究明中としており、具体的な侵入方法は分かりません。同社は、運行計画の変更はないとも説明しています。

その後、9月28日の公式案内では、意図せず予約が取り消されたお客様への個別の状況確認の連絡は、すべて完了したと説明しています。同社から個別連絡のないお客様については、予約の取消しは発生しておらず、予約は正常に保たれているとしています。現在も予約取消しが未対応のまま続いている、という紹介は適切ではありません。

以下では、これらの公表内容を踏まえ、自社の予約業務をどう点検するかを考えます。本文の確認表や手順は、小規模事業者向けの実務上の提案であり、同社の実際の復旧方法を再現したものではありません。

情報セキュリティは、「見られないようにする」だけではない

情報セキュリティを考える際には、情報を不適切に見られないことに加え、不適切に変更・破壊されないこと、必要なときに利用できることも重要です。IPAのガイドラインでも、機密性・完全性・可用性が損なわれた場合の事業への影響を評価する考え方が示されています。

今回の中心となるのは、このうち「完全性」です。

NISTの用語集では、完全性について、不適切な変更や破壊から情報を守ることなどが説明されています。単にファイルが存在するかではなく、その内容を信頼できるかという観点です。

予約業務に置き換えるなら、「予約した人の情報を他人に見せない」だけでは不十分です。利用日時、人数、予約状態などが、お客様との合意に沿った内容で保たれていることも必要になります。

例えば、体験教室の予約が「4人」から「2人」に変わっていた場合を考えてください。担当者が画面だけを見て準備すれば、必要な道具や席が足りなくなります。これは、個人情報が外部へ流出していなくても、業務上の問題になる例です。

また、完全性の問題を、外部からの攻撃だけに限定する必要はありません。NISTのデータ完全性に関する資料では、悪意ある行為だけでなく、意図しない操作ミスなどからの復旧も対象としています。

本記事では、原因が攻撃なのか、操作ミスなのかを確認する作業と並行して、**「今ある情報を、そのまま業務の判断に使ってよいか」**を確認することを提案します。

まず、予約データで動く仕事を洗い出す

予約データの重要性を考えるには、その情報を使って、どの仕事が動くのかを確認しましょう。

例えば宿泊施設であれば、予約をもとに部屋を確保し、清掃や食事の準備を調整する業務が考えられます。体験教室なら、講師や道具の手配、美容室なら担当者と施術時間の確保などです。

これらは業務を整理するための例ですが、自社についても同じように、「予約のどの項目を、誰が、何の判断に使っているか」を書き出してみてください。

確認したいのは、顧客名だけではありません。利用日、開始時刻、人数、サービスの種類、担当者、代金の処理状況、特別な依頼、取消しの有無など、仕事に影響する項目を確認します。

そのうえで、「この項目が誤っていたら、何を間違えるか」を考えます。

利用日が変われば、別の日に準備することになります。予約状態が変われば、確保すべき枠を空きとして扱うことになります。金額や返金状況が変われば、会計処理の確認が必要になります。

IPAは、情報資産を洗い出す際、機器や保存場所だけを見るのではなく、日常の業務でどのような電子データや書類を使っているかから考える方法を示しています。予約管理でも、システム名だけでなく、それを使って行う仕事まで整理することが有効です。

守る対象は「予約システム」という一つの箱ではなく、その情報を使って行う一連の仕事です。

不審な予約を見つけても、すぐに上書きしない

身に覚えのない取消しや変更を見つけたとき、現場では「正しい内容へ直しておこう」と考えるかもしれません。

しかし、原因が分からない段階で担当者ごとに修正を始めると、どこまでが元の異常で、どこからが対応のための変更なのかを整理しにくくなります。

本記事では、まず責任者へ連絡し、発見時点の状態を記録したうえで、修正する担当者と方法を決めることを提案します。

記録するのは、発見時刻、予約番号、表示されていた内容、本来の内容と考える根拠、すでに行った操作などです。画面の保存に加え、システムの操作履歴や関連記録の保全を、管理者やサービス提供者へ依頼してください。

IPAのガイドラインでも、発生・発覚からの経過や被害、実施した対応を整理し、必要に応じて事実関係を裏付ける情報や証拠を保全することが示されています。

ただし、証拠を残すために、不正な操作が続く状態を放置してはいけません。

管理者や専門家と連携し、対象のアクセスを止める、変更機能を制限する、新規受付を一時停止するなど、被害の拡大を防ぐ対応も並行して進めます。どの範囲を止めるかは、原因や影響範囲、システム構成に応じて判断します。

予約画面だけを停止しても、外部サービスとの連携や別の管理画面から変更できる構成なら、その経路も確認対象にしてください。

現場の判断で直し続けるのでも、調査が終わるまで何もしないのでもなく、変更を管理しながら、被害拡大防止と記録の保全を進めることが重要です。

「正しい予約」は、何を根拠に判断するのか

予約データが変更された疑いがある場合、現在の画面だけを見ても、正しい状態を判断できません。では、何と照合すればよいのでしょうか。

本記事では、予約の受付から変更・取消しまでに作成された記録を、時系列で組み合わせる方法を提案します。

例えば、最初の予約完了メールがあれば、その時点の申込内容を確認する材料になります。ただし、その後に正規の人数変更や取消しが行われていれば、最初のメールだけでは最新の状態を判断できません。

同様に、入金記録があっても、後から日程が変更されている可能性があります。予約画面、申込記録、変更依頼、決済記録が、それぞれ何を示す資料なのかを分けて考える必要があります。

照合に使う資料の例	確認できる内容の例	判断するときの注意点
予約完了メール・申込控え	受付時点の日時、人数、サービス内容	後から行われた正規の変更まで反映しているとは限らない
変更・取消しの受付記録	誰から、いつ、何を依頼されたか	依頼を受けたことと、実際に処理したことを分けて確認する
システムの操作履歴	変更時刻、使用されたID、変更対象	そのIDの名義人が実際に操作したと、直ちに断定しない
決済サービス等の記録	請求、入金、取消し、返金などの処理	予約状態との対応関係を確認する。カード番号全体の収集は不要
過去時点のバックアップ	保存時点の予約状態	保存した時点ですでに不正な変更が含まれていないか確認する
お客様への確認記録	申込みや変更の意図、手元の控え	本人確認を行い、一つの申告だけで矛盾する記録を上書きしない

この表は、照合方法を考えるための例です。すべての事業者が、すべての資料を持っていることを前提としていません。

大切なのは、資料の数を集めるだけでなく、いつ、どの仕組みで作られ、その後に変更され得るものかを確認することです。

同じ予約データから出力した一覧と帳票が一致していても、それは同じ元データを写しているだけかもしれません。独立した受付記録などと照合できるかを検討してください。

調査の記録自体についても、内容と出所を維持することが必要です。NIST CSF 2.0は、インシデント調査で扱うデータや記録の完全性と出所を保全することを示しています。

予約単位で、「確認済み」「要修正」「未確認」を分ける

照合作業を進めると、すぐに正しい内容を確認できる予約と、資料が食い違って判断できない予約が出てくるかもしれません。

その場合、全体をまとめて「復旧中」とするだけでは、現場がどの予約を使ってよいか分かりません。

本記事では、予約ごとに確認状況を管理する「予約データ照合票」を作ることを提案します。予約番号が受付経路ごとに発行される場合は、受付経路と番号を組み合わせ、対象を取り違えないようにします。

管理項目	記録する内容
対象の特定	受付経路、予約番号、利用日など
発見時点の状態	日時、人数、予約状態など、問題となった項目
照合した根拠	申込控え、変更記録、操作履歴などの保管場所
確認結果	確認済み、要修正、未確認など
正しい内容と判断した根拠	どの記録や確認結果に基づいて判断したか
修正内容	変更前と変更後の値、修正理由
作業者・確認者	修正を行った人、結果を確認した人
関連する処理	空き枠、通知、代金処理、他サービスへの反映状況
残る対応	お客様への確認、担当者、期限、対応結果

例えば、予約完了メールでは4人、現在の画面では2人となっていたとしても、それだけで4人へ戻してよいとは限りません。

その後の正規の人数変更が確認できれば、2人が正しい場合もあります。変更記録がなく、お客様への確認も終わっていなければ、「未確認」として扱い、判断に必要な情報を集めます。

同時に、未確認の予約に関係する枠を、新しいお客様へ販売してよいかも責任者が判断します。「未確認」は、予約を無効とみなしてよいという意味ではありません。

修正するときも、「おかしかったので変更した」ではなく、何を根拠にどの値へ変更したのかを記録します。お客様への影響が大きい修正や一括処理は、可能な範囲で別の担当者による確認を設けましょう。

照合票そのものにも個人情報が含まれるため、閲覧者を限定し、必要以上の情報を転載しない運用にしてください。

予約表だけでなく、通知・空き枠・代金処理も照合する

予約の表示を直したら、対応は終わりでしょうか。

自社の構成によっては、予約状態の変更に連動して、確認メールの送信、空き枠の更新、外部予約サイトへの反映、代金の取消しや返金などが行われる場合を想定しておく必要があります。

ここでは、取消しに連動して枠を再販売する仕組みを使う、架空の体験教室を考えます。

正規の予約が不正に取り消され、その枠に別のお客様が新しく申し込んでいたとします。元の予約だけを戻せば、同じ枠に二つの予約が存在する状態になります。

この場合に必要なのは、単なるデータの修正ではなく、両方のお客様との申込内容を確認し、事業者として対応を決めることです。システム上の数を合わせるために、どちらかを担当者の判断だけで削除してはいけません。

代金処理についても、予約状態の修正に伴って再請求や重複した返金が起きないよう、予約番号と取引の識別情報を対応させて確認することを提案します。

メールやSMSなどの通知も、送信済みなのか、これから送られる予定なのかを分けて調べます。誤った通知が待機している場合は、サービス提供者と停止方法を確認してください。修復後に一括で再実行してよいかも、内容を確認して判断します。

予約データの修復は、関連する仕事に何が反映されたかを確認するところまで含めて考える必要があります。

こうした関連処理を把握するため、平時に「予約作成」「人数変更」「取消し」を行った際、どのシステムへ何が送られるのかを、保守会社と一緒に整理しておきましょう。

手作業で受け付ける場合も、「仮受付」と「予約確定」を分ける

システムの確認中、電話や紙で受付を続ける方法を検討する場合もあるでしょう。

その際、まず決めたいのは、どの予約枠なら正しい残数を確認できるかです。元の予約状態が分からない枠について、画面上で空いているという理由だけで新しい予約を確定しないようにします。

本記事では、空き状況を確認できない場合、申込みの意向を受ける「仮受付」と、利用を確約する「予約確定」を区別する方法を提案します。

例えば、次のように案内できます。

現在、予約状況を確認しているため、この時点ではご予約を確定できません。ご希望内容を仮受付としてお預かりし、確認後、担当者から改めてご連絡いたします。

これは案内文の作成例です。いつまでに連絡できるかが決まっている場合は、その時刻も加えます。実行できない期限を約束しないようにしてください。

手作業で受け付けたものには、仮受付番号、受付時刻、担当者、希望内容、確定の有無を記録します。複数の担当者が同じ枠を別々に確約しないよう、確定を判断する窓口を一本化する方法も考えられます。

復旧後は、手作業の記録を誰が入力し、誰が重複や反映漏れを確認するかを決めます。入力済みの記録が分かるようにし、途中で担当者が交代しても同じ申込みを二度登録しない手順にしてください。

一時的な紙や表計算ファイルも、通常の顧客情報と同じく管理対象です。私物の端末や個人のメッセージアプリへ分散させず、会社が承認した場所へ集約しましょう。

「システムが開いた」以外の再開条件を決める

業務の再開を、ログインできたことだけで判断しないようにしましょう。

NIST CSF 2.0は、復元した情報などの完全性と正常な稼働状態を確認し、定めた基準に基づいて復旧の終了を宣言することを示しています。

これを予約業務へ当てはめるなら、技術面の確認と、業務面の確認を分けると整理しやすくなります。

技術面では、不正な操作につながった経路への対処、設定の確認、監視の再開などを管理者やサービス提供者が確認します。業務面では、予約内容、利用できる枠、通知や代金処理、手作業で受け付けた分の反映を、実際の担当者が確認します。

本記事では、次のような再開条件を事前に決めることを提案します。

確認する範囲	再開前に確認したい状態
不正操作への対処	確認された侵入経路や不正な権限への対処が行われ、再発を監視できる
予約内容	再開対象の予約について、根拠に基づく照合が完了している
空き枠・定員	未確認の予約を含め、同じ枠を重複して提供しない状態になっている
関連処理	通知、外部連携、代金処理などとの不整合を確認している
代替受付分	手作業で受け付けた内容を反映し、重複と入力漏れを確認している
残る課題	未解決事項の対象、影響、暫定措置、担当者、期限が明確になっている

予約の総件数や売上合計が合うことだけを、完了条件にしないことも重要です。

例えば、正規の予約が1件消え、別の予約が1件追加されていれば、総件数は変わりません。合計が一致することと、個々の内容が正しいことは別です。

すべてを同時に再開できない場合は、確認できた範囲だけを再開する方法も検討できます。ただし、その範囲を未確認のデータから切り離して扱えるかを確認し、責任者が判断してください。

未確認の予約が残っているのに、対外的に「すべて正常化した」と案内しないようにします。

クラウド予約サービスには、「戻せる範囲」を確認する

クラウド型の予約サービスを利用している場合も、事故時にどのような確認や復元ができるかを把握しておきましょう。

本記事では、「バックアップを取っていますか」という質問だけで終わらず、自社の予約をどの単位で戻せるか、どの履歴を確認できるかまで質問することを提案します。

例えば、予約1件だけを戻せるのか、ある時点の全体へ戻す必要があるのか。変更前後の内容を確認できるのか。操作履歴は何日分残り、自社で取得できるのか。履歴やバックアップの提供には、どのような依頼手続きが必要なのかを確認します。

復元した場合の影響も重要です。正常な予約や、その後に行われた正規の変更をどう扱うのか。連携先へ通知や処理が再送されるのか。検証用の環境で確認できるのかを、利用しているサービスの仕様と契約に基づいて確かめてください。

問い合わせ文は、例えば次のように作れます。

当社の予約情報に不正な変更や誤操作が発生した場合を想定し、変更履歴の取得範囲、保存期間、予約単位での復元可否、復元に伴う他の予約や外部連携への影響を確認したいと考えています。当社契約で利用できる機能、依頼窓口、対応条件をご案内ください。

この確認は、サービス提供者だけへ責任を移すためのものではありません。

技術的に元へ戻す作業と、どの予約が正しいかを判断する作業には、異なる情報が必要です。お客様からの電話変更や店頭での対応を自社だけが把握しているなら、その記録は自社側で整理しなければなりません。

提供者ができること、自社が判断すること、双方で確認することを分けておくことが、復旧準備になります。

変更履歴は、「ログインした記録」だけでは足りない

平時の改善として確認したいのが、予約データの変更履歴です。

本記事では、システムへ入った記録に加え、どの予約の、どの項目が、何から何へ変わったかを追えるか確認することを提案します。

記録項目の例は、変更時刻、対象の予約番号、変更に使われたアカウント、変更前後の値、操作の種類、受付経路、処理結果などです。正規の変更依頼を管理している場合は、その記録と対応付けられるようにします。

ただし、何でもログへ記録すればよいわけではありません。パスワードや認証コード、業務上不要な個人情報まで残さないよう、必要な調査と情報保護の両方を考えて決めてください。

また、ログを変更できる権限や、記録の保管場所も確認します。予約を変更する権限と、変更履歴を削除する権限を分けられるか、別の管理下で記録を保管できるかを検討しましょう。

NISTのデータ完全性に関する検知・対応資料は、影響を受けたシステムを特定し、影響分析に十分な情報を集めることを重視しています。

記録を残した後は、確認する人と条件も決めます。短時間の大量取消し、通常とは異なる時間帯の一括変更、業務上の理由が確認できない変更などを、調査のきっかけにする方法が考えられます。

ただし、異常に見える操作を検知しただけで、攻撃と断定してはいけません。正規の一括処理や障害対応かもしれないため、作業記録と照合します。

監視の目的は、担当者を疑うことではなく、説明できない変更を見つけ、早く確認できる状態にすることです。

個人情報保護では、「外へ出ていないから問題ない」とは限らない

予約情報に個人データが含まれる場合は、外部への流出だけでなく、内容の変更や喪失についても確認が必要です。

個人情報保護委員会のガイドラインでは、個人データの内容が意図しない形で変更されることなどを「毀損」とし、内容の改ざんを該当例として挙げています。

また、不正の目的で行われたおそれがある行為による個人データの漏えい・滅失・毀損などは、報告対象となる要件の一つです。人数だけで対象外と判断することはできません。

そのため、「データを持ち出された証拠はない」「予約は元に戻した」という説明だけで、報告や本人への通知の検討を終えないようにしてください。

何が変更されたのか、個人データに当たるのか、原因や影響範囲は何かを整理し、社内の責任者や必要に応じて弁護士、個人情報保護委員会の相談窓口などへ確認しましょう。

業務を戻す作業と、法令や契約に基づく対応の判断は、別の管理事項として進めることをおすすめします。詳細な調査の完了を待たずに対応が必要になる場合があるため、初期段階から担当者を決めておくことが大切です。個人情報保護委員会も、報告対象となる事態について、発覚後は速やかに報告するよう案内しています。

机上演習では、「システム停止」だけでなく「内容の食い違い」を試す

復旧手順が使えるかを確かめるため、予約内容が食い違う場面を、架空のデータで練習してみましょう。

例えば、次のような想定です。

明日の体験教室について、お客様から「人数を変更していないのに、2人分になっている」と連絡がありました。お客様の申込控えには4人と記載されています。予約画面は正常に開き、他の申込みも受け付けていますが、同じ時間帯に複数の予約が変更されています。

これは訓練用の架空の状況です。原因を最初から不正アクセスと決めず、何を確認するかを考えます。

現場担当者には、最初の連絡先と、記録する内容を確認してもらいます。管理者には、操作履歴を取得する方法と、必要な場合に変更や受付を制限する方法を確認してもらいます。

業務責任者には、正しい人数を何で判断するか、未確認の枠へ新しい予約を入れてよいか、お客様へいつ何を説明するかを考えてもらいます。

さらに、途中で「昨夜のバックアップはあるが、それ以降にも正規の予約が入っている」「取消しメールが送信済みだった」という条件を加えれば、単純な復元だけでは終わらない対応を確認できます。

評価するのは、原因を言い当てたかではありません。証拠を失わずに対応できたか、未確認の情報で予約を確定しなかったか、修正の根拠と承認者を残せたか、再開条件を説明できたかを振り返ります。

訓練で使うのは、実際のお客様の情報ではなく、架空の予約情報にしてください。本番の予約を変更したり、実際の通知を送ったりしない環境で行いましょう。

まとめ――予約を守るとは、お客様との約束を守れる状態にすること

予約業務のセキュリティでは、個人情報の漏えい防止やシステムの停止対策に加え、データが不適切に変えられていないこと、変わった場合に確認して戻せることも考える必要があります。

まず、自社の予約を一つ選び、その内容を何で確かめられるか確認してください。

申込みを受けた記録はあるか。変更や取消しの依頼を追えるか。画面と記録が食い違ったとき、誰が判断するか。修正によって通知や代金処理に何が起きるか。どの条件がそろえば、受付を再開できるか。

これらを、予約業務の手順として整理していきましょう。

バックアップからデータを戻すことは、復旧の重要な作業です。しかし、それだけでお客様との約束まで正しい状態に戻ったとは判断できません。受付から変更、支払い、サービス提供までの記録を照合することが必要です。

「画面が開くから使う」ではなく、「内容を確認できたから、その範囲で仕事を進める」。

予約データの正しさを守る取り組みは、お客様への誤案内や手配の行き違いを防ぐための、日常業務の整備でもあります。

ライトハウスコンサルタントでは、クラウド、バックアップ、社内ルールの現状確認や、インシデント発生時の判断・連絡・復旧方針を確認する机上演習を支援しています。自社の予約業務について、どの記録を残し、どの条件で業務を再開するかを整理したい場合は、ご相談ください。

投稿タグ: あいの風とやま鉄道, インシデント対応, データ完全性, データ復旧, データ改ざん, バックアップ, 一万三千尺物語, 不正アクセス, 中小企業, 予約システム, 変更履歴, 業務継続

MENU