宿泊施設向けサイトコントローラー「TEMAIRAZU」を提供する手間いらず株式会社は2026年9月28日、同社システムへの不正アクセスを確認し、宿泊者情報の一部が第三者に閲覧または取得された可能性を否定できないと公表しました。発端は9月21日深夜から、利用施設の予約者にWhatsAppやSMSで不審なメッセージが届いたことです。10月7日の第二報では、閲覧・取得の可能性がある情報が氏名・電話番号・メールアドレスなど7項目と示されました。本記事は公式発表を時系列で整理し、サイトコントローラーが侵害されると被害が広がる理由を説明したうえで、予約者・宿泊施設・OTAや接続先の各社が今やる点検を、通知対象の抽出や監査ログの確認に使えるコードとあわせて示します。
まとめ：手間いらずの不正アクセスで公表された事実と施設・予約者がまず行う対応
公式発表で確定しているのは、9月21日深夜ごろから予約者への不審なメッセージが報告され、その調査の過程で同社システムへの不正アクセスが見つかったこと、原因を特定して対策を完了し、TEMAIRAZUは通常どおり稼働していることです。手間いらずはクレジットカード情報と宿泊予約サイトのログイン情報を保持していません。一方で、影響を受けた件数、不正アクセスの具体的な手法、脆弱性の種類は公表されていません。
不審なメッセージは、名前や宿泊日、料金といった本物の予約情報を添えて届くため、従来の詐欺メールより見破りにくいのが特徴です。予約者は「予約内容が合っている」ことを本物の根拠にせず、施設か予約サイトの公式窓口で確かめます。宿泊施設はTEMAIRAZUのパスワード変更と管理画面の確認、対象予約への注意喚起を先に済ませてください。OTAや接続先は、送金先口座と権限設定の変更履歴を確かめる段階です。
| 項目 | 公表されている内容 |
|---|---|
| 不正アクセスの発生 | 2026年9月21日（施設告知による） |
| 原因箇所の特定・対策完了 | 9月26日（施設告知による） |
| 手間いらずの公表 | 9月28日（第一報）、10月7日（第二報） |
| 閲覧・取得の可能性 | 氏名・電話番号・メールアドレスなど7項目 |
| カード情報・予約サイトのログイン情報 | 保持していない |
| 影響件数・手法 | 非公表 |
公式発表を時系列で確認する｜9月21日の不審メッセージから10月7日の第二報まで
9月21日深夜の不審メッセージ連絡から9月28日の公表までの一週間
手間いらずの第一報（2026年9月28日）によると、9月21日（月）深夜ごろから、複数の宿泊施設より「予約者にWhatsApp等のメッセージアプリ、電子メール、SMSで不審なメッセージが届いている」との連絡が入りました。メッセージには宿泊予約の情報を把握しているとみられる内容が含まれ、予約の確認・確定、クレジットカード情報の再入力、緊急の支払いを求めて不審なウェブサイトへ誘導するものでした。
同社はこの調査の過程でシステムへの不正アクセスを確認し、アクセスの遮断を含む被害拡大防止措置を講じています。一時停止していた機能は対策後に再開済みです。個人情報保護委員会への報告と警察への通報・相談を進め、外部の専門機関にも調査を依頼しました。9月29日には英語版の告知も出ています。
9月28日の公表日には、利用施設の側でも自社サイトに告知を出すところが相次ぎました。予約者にとっては、手間いらずの名前を知らないまま、泊まる予定の施設からの告知で初めて事態を知る順番になります。
第二報で示された閲覧・取得の可能性がある7項目とカード情報の扱い
10月7日の第二報で、第三者に閲覧・取得された可能性のある情報が次の7項目と示されました。第一報の時点では「宿泊者情報の一部」とだけ書かれていたため、範囲が初めて具体化したことになります。
- 宿泊者の氏名、電話番号、メールアドレス
- 宿泊施設名、チェックイン日、チェックアウト日
- 宿泊料金
同社はクレジットカード情報と宿泊予約サイトのログイン情報を保持していないと明記しています。カード番号そのものは漏れていない一方、メッセージで「カード情報の再入力」を求めて偽サイトに入力させる手口が使われています。第二報は不審なメッセージを、宿泊施設や予約サイトを装ってカード情報を取得し金銭をだまし取る目的のフィッシング詐欺とみられると位置付けました。
旧インストール型サービスの機能が原因とされた点と公表されていない事項
手間いらず自身は、セキュリティ上の理由から不正アクセスの具体的な手法と対策の詳細を公表していません。原因の輪郭が分かるのは、利用施設側の告知です。あなぶきホテルズを運営する穴吹エンタープライズの告知（2026年9月28日）は、手間いらずからの報告として、過去に提供されていたインストール型サービスを構成する機能の一部にセキュリティ上の問題があったと伝えています。
同じ告知には、確認された不正アクセスは9月21日に発生したものに限られること、9月26日に原因箇所を特定して対策を完了したことも記されています。実施した対策は、管理ツールのパスワード変更、サーバーへの接続制限と認証方法の強化、検知・防御・監視体制の強化、類似箇所の点検です。影響件数、脆弱性の種類、取得された記録の範囲はまだ出ていないため、本記事ではそれらを推測で補いません。
サイトコントローラーが侵害されると被害が広がる構造｜複数の予約サイトの予約が一か所に集まる
複数の予約サイトの在庫と予約を一元管理する仕組みと情報の集約点
サイトコントローラーは、楽天トラベルやじゃらん、海外OTAなど複数の宿泊予約サイトに出している在庫・料金・予約を一つの管理画面で扱うシステムです。TEMAIRAZUの製品ページは、国内外の宿泊予約サイトに加えて自社HP予約システム、ホールセラー、メタサーチと連携し、客室在庫・予約情報・料金設定をTEMAIRAZUひとつで設定できると説明しています。仕組みの全体像はサイトコントローラーとはで整理しています。
便利さの裏返しとして、どのサイト経由の予約もここに集まります。予約サイトごとに分かれていれば一社の事故で済む情報が、サイトコントローラーでは一度の侵入で複数の販路の予約者に届きます。今回、施設ごとに予約経路を問わず注意喚起が出たのはこの構造のためです。
本物の予約情報を添えたフィッシングが通常の詐欺より見破りにくい理由
一般的なフィッシングは、宛先の名前すら入っていない文面で数を打ちます。今回のメッセージは、氏名・宿泊施設名・チェックイン日・料金が合っています。受け取った側は「予約した本人しか知らないはずの情報」を見て、施設からの正規の連絡だと判断しがちです。
第二報によると、誘い文句は事前チェックインや予約の維持を理由にした外部サイトへの誘導です。宿泊直前の予約者は手続きの連絡を待っている時期でもあり、心理的に断りにくくなります。送信側の認証や誘導先の検知といった技術的な見分けの仕組みはフィッシング詐欺の実装者向け解説にまとめています。
予約者が今やること｜WhatsAppやSMSの事前チェックイン依頼を公式窓口で確かめる
予約名と宿泊日が正しくても本物と判断しないための見分けの基準
判断の基準は一つです。予約内容が正しいかどうかではなく、どの経路で届いたかを見ます。手間いらずは第一報で、メッセージのURLやリンクを開かない、カード情報や個人情報を入力しない、返信しない、指示に従って支払わない、予約内容は施設か予約サイトの公式窓口で確かめる、の5点を案内しています。
特に、予約時に使っていないWhatsAppやWeChatに突然連絡が来た場合は、それだけで疑う理由になります。あなぶきホテルズの告知でも、不審なメッセージが確認されたのはWhatsAppを利用している予約者の予約でした。期限を切って「今すぐ」と急がせる文面は、第二報が名指しで注意を促している型です。
偽サイトにカード情報を入力してしまった場合の連絡先と報告窓口の順番
入力してしまった場合の最優先は、カード会社への連絡です。カードの利用停止と再発行を依頼し、直近の利用明細に心当たりのない請求がないかを確認します。手間いらずも、不審なサイトにカード情報を入力した場合は速やかにカード会社へ相談するよう案内しています。
次に、受け取ったメッセージをフィッシング対策協議会の報告ページから報告してください。SMSは転送できないため、スクリーンショットをメールに添付する方法が案内されています。金銭の被害が出た場合は、警察庁のフィッシング対策ページにある相談窓口から最寄りの警察へつなぎます。予約そのものは、施設に直接電話して有効かどうかを確かめておけば安心です。
宿泊施設が回す点検と予約者への通知｜対象予約の抽出から管理画面の確認まで
9月21日までに成立し以降に宿泊する予約を抽出するPythonの例
あなぶきホテルズの告知は、不審なメッセージが確認された予約の条件を「9月21日までに成立した予約」「9月21日以降の宿泊日の予約」「予約者がWhatsAppを利用している予約」のすべてに当たるものと示しています。WhatsAppの利用有無は施設側では分からないため、通知の範囲は前の二つの条件で切るのが現実的です。予約一覧をCSVで書き出せれば、通知の宛先は次のスクリプトで抜き出せます。CSVの読み書きは標準ライブラリのcsvモジュールだけを使います。
import csv
from datetime import date
CUTOFF = date(2026, 9, 21) # 不正アクセスが確認された日
FIELDS = ["予約番号", "氏名", "メールアドレス", "電話番号", "チェックイン日"]
def to_date(value):
return date.fromisoformat(value.strip()[:10])
with open("reservations.csv", encoding="utf-8-sig", newline="") as src, \
open("notify_targets.csv", "w", encoding="utf-8-sig", newline="") as dst:
writer = csv.DictWriter(dst, fieldnames=FIELDS)
writer.writeheader()
count = 0
for row in csv.DictReader(src):
if row["キャンセル"] == "1":
continue
if to_date(row["予約日"]) <= CUTOFF and to_date(row["チェックイン日"]) >= CUTOFF:
writer.writerow({k: row[k] for k in FIELDS})
count += 1
print(f"通知対象: {count}件")Python 3.14.6で、条件に当たる予約2件と、成立日が9月22日以降・宿泊済み・キャンセル済みの予約を混ぜたテストCSVを入力すると、対象の2件だけがnotify_targets.csvに出力されます。列名は施設が書き出したCSVの見出しに合わせて書き換えてください。予約日が「2026-09-21 23:10」のように時刻付きでも、先頭10文字で日付として比較します。これから泊まる予約だけに絞るなら、チェックイン日の条件をdate.today()以降に変えます。
TEMAIRAZUのパスワード変更と管理画面の操作履歴で確かめる項目
手間いらずは利用施設に、念のためTEMAIRAZUのログインパスワードを変更するよう依頼しています。共有アカウントを複数の担当者で使っている施設は、変更と同時に誰が使っているかを棚卸しし、退職者や外部委託先が知っているパスワードを残さないようにします。
あわせて管理画面で、身に覚えのないログインと、意図しない登録内容の変更がないかを確かめます。見るのは9月21日前後のログイン記録、プランや料金の設定変更、予約者への連絡文面の変更です。見つかった場合は手間いらずへ連絡してください。自社でWebサーバーや予約エンジンを持つ施設は、同じ期間のアクセスログも確認しておくと判断材料が増えます。見るべきログの種類は不正アクセスのログ確認・解析方法が参考になります。
宿泊施設が予約者への案内文に入れておく約束と避けるべき書き方
案内文に必ず入れたいのは、「当館からWhatsAppやSMSでカード情報の入力や支払いをお願いすることはありません」という約束です。施設がしないことを明言しておけば、予約者は次に届いた不審な連絡を自分で切り分けられます。問い合わせ先は、施設の代表電話や公式サイトの窓口だけを書きます。
避けたいのは、案内文の中にリンクを並べることです。施設からの正規の案内にもリンクがあると、偽物との区別が付かなくなります。詳細の掲載先は「公式サイトのお知らせ欄」と場所で示すほうが安全です。個人情報保護委員会への報告が施設側に及ぶかどうかの読み方は、同じ時期に起きたファインズの予約システム不正アクセスで、委託元への通知による例外を含めて整理しています。
OTA・接続先のパートナーが確かめる設定｜送金先口座と権限の意図しない変更
第一報が関係各社へ確認を求めた四つの事項と送金先口座を優先する判断
第一報は、OTA各社とシステム接続先のパートナーにも、自社の管理画面について次の確認を求めています。身に覚えのないログインの有無、アカウントまたは権限設定の意図しない変更、送金先口座その他の登録情報の意図しない変更、不審なメッセージまたは操作履歴の有無です。
優先すべきは送金先口座です。ログインや権限の変更は後から気づいても取り消せますが、口座が書き換えられた状態で精算が走ると、お金が実際に動きます。次の精算日より前に、口座情報の変更履歴を確認してください。
送金先口座や権限の変更履歴を監査ログから期間を絞って洗い出すSQLの例
管理画面の操作を監査ログとしてテーブルに残している場合は、期間と操作種別で絞れば確認は数分で終わります。次は、操作日時・操作者・接続元IP・操作種別・変更前後の値を持つ監査ログのテーブルを想定した例です。操作種別の値は自社の実装に合わせて置き換えます。
SELECT occurred_at, actor_id, source_ip, action, target, old_value, new_value
FROM audit_log
WHERE occurred_at >= '2026-09-20T00:00:00+09:00'
AND action IN ('payout_account.update', 'role.grant', 'user.create', 'api_key.create')
ORDER BY occurred_at;
SELECT l.account_id, l.source_ip, MIN(l.occurred_at) AS first_seen
FROM login_log AS l
WHERE l.occurred_at >= '2026-09-20T00:00:00+09:00'
AND NOT EXISTS (
SELECT 1 FROM login_log AS p
WHERE p.account_id = l.account_id
AND p.source_ip = l.source_ip
AND p.occurred_at < '2026-09-20T00:00:00+09:00'
)
GROUP BY l.account_id, l.source_ip
ORDER BY first_seen;1本目は9月20日以降の口座変更・権限付与・ユーザー追加・APIキー発行を時系列に並べます。2本目は、それ以前に一度も使われていない接続元IPからの初回ログインをアカウントごとに抜き出します。SQLite 3.53.1でテストデータに対して実行し、期間内の口座変更と権限付与、新しい接続元からのログインだけが返ることを確かめました。日時は文字列で比較しているため、ログの時刻表記が同じ形式でそろっている前提です。
監査ログが無い管理画面で口座と権限の確認を済ませるときの代わりの手順
監査ログを持たない管理画面では、現在の設定値を正本と突き合わせるしかありません。送金先口座は契約時の書面や前回の精算明細と1件ずつ照合し、管理者権限を持つアカウントの一覧を出して、全員が現役の担当者かを確かめます。照合した日付と担当者を記録しておけば、後から問い合わせが来たときの説明に使えます。
この作業に半日以上かかるなら、監査ログを持たないこと自体が課題です。口座情報と権限の変更だけでも記録を残す改修は、管理画面の改修の中では工数が小さい部類に入ります。
提供を終えた機能が入口になった教訓｜旧版の経路を塞ぐ設定と棚卸しの順番
過去に提供されていたインストール型サービスの部品が攻撃の入口になった構図
原因として伝えられたのは、現行のクラウド型の機能ではなく、過去に提供されていたインストール型サービスを構成する機能の一部でした。具体的な部品名や脆弱性は公表されていませんが、構図は受託開発の現場でもよく見ます。新しい版へ移行した後も、旧版の利用者向けに残した連携用の受け口やファイル受け渡しの経路が、同じサーバー群につながったまま動き続ける形です。
提供を終えた機能は、誰も改修しないため更新も止まりがちです。一方で本番のデータベースへ届く権限は持ったまま残ります。新機能の脆弱性診断では対象外にされやすく、存在自体が台帳から抜けていることもあります。
使わなくなったパスをnginxで塞ぎ管理ツールを接続元で絞る設定例
旧版の受け口を残す必要がないなら、アプリケーションに届く前にWebサーバーで閉じます。次は、旧版のパスには410を返し、管理ツールは運用拠点の接続元だけに絞る例です。allowとdenyの指令は上から順に評価され、最初に一致した規則が適用されます。return指令は指定したステータスで処理を打ち切ります。
# 提供を終えた旧版の受け口は、アプリケーションに渡さず410で閉じる
location ^~ /legacy/ {
return 410;
}
# 管理ツールは運用拠点の接続元だけに絞る
location ^~ /admin/ {
allow 203.0.113.10;
allow 198.51.100.0/24;
deny all;
proxy_pass http://127.0.0.1:8080;
}/legacy/と/admin/のパス、IPアドレスは例示用です。自社の旧版の受け口と運用拠点の接続元に置き換えてください。410は「恒久的に無くなった」を意味するため、旧版をまだ使っている連携先がいれば、そのエラーで気づけます。塞いだ後もアクセスログに旧パスへの要求が残り続ける場合は、送り主を特定して止めてもらいます。
自社で予約連携を持つ事業者が点検する順番と外部診断に出す判断
点検は、提供中・提供終了を問わず外部から到達できる受け口の一覧作り、各受け口から本番データベースへ届く権限の確認、提供終了した受け口の停止、の順に進めます。一覧作りを最初に置くのは、台帳に無い受け口は診断の対象にも入らないからです。
外部診断に出すかどうかの判断基準は明確です。旧版から現行版へ移行した経緯があり、旧版の受け口の一覧を社内で作れないなら、外部の診断に出す価値がある状況です。現行版しか持たず、受け口が管理画面と予約APIの数本に限られるなら、まずは上の設定と監査ログの整備で足ります。外部から到達できる入口の洗い出しと種類の選び方は脆弱性診断とはに、受け口からデータベースまでの経路を含めた確認を依頼する場合は脆弱性診断・セキュリティ診断にまとめています。
よくある質問
手間いらずの不正アクセスについて、予約者と宿泊施設から出やすい質問をまとめました。
手間いらずの不正アクセスでクレジットカード情報は漏れましたか？
手間いらずはクレジットカード情報を保持していないと公表しています。第二報で閲覧・取得の可能性があると示されたのは、氏名、電話番号、メールアドレス、宿泊施設名、チェックイン日、チェックアウト日、宿泊料金の7項目です。ただし、届いたメッセージから偽サイトに入力した場合はカード情報が詐欺グループに渡るため、その場合はすぐにカード会社へ連絡してください。
自分の予約が対象かどうかはどうすれば分かりますか？
手間いらずは影響範囲を確認中としており、件数は公表されていません。あなぶきホテルズの告知では、不審なメッセージが確認されたのは「9月21日までに成立し、9月21日以降に宿泊する予約」でWhatsAppを利用している予約者でした。泊まる予定の施設がTEMAIRAZUを使っているかは利用者からは見えないため、施設の公式サイトのお知らせを確認するか、代表電話で問い合わせるのが確実です。
TEMAIRAZUは今も使い続けて問題ありませんか？
手間いらずは原因を特定して対策を完了し、TEMAIRAZUは正常に稼働していると公表しています。施設には念のためログインパスワードの変更を依頼しています。調査は外部の専門機関と継続中で、新たな事実が判明すれば公表するとしているため、続報を確認しながら、パスワード変更と管理画面の確認を済ませたうえで使うのが現実的です。
予約サイト経由で予約したのに施設名でメッセージが来るのはなぜですか？
サイトコントローラーには、複数の予約サイト経由の予約が施設ごとに集まります。そのため、予約サイトで予約した人の情報も施設の予約として管理されており、施設名と宿泊日を添えたメッセージが作れてしまいます。予約サイトの公式アプリや、施設の代表電話など自分で調べた連絡先から予約内容を確かめてください。
宿泊施設は個人情報保護委員会へ報告する必要がありますか？
手間いらずは委員会への報告を含む対応を進めています。施設側の報告要否は、委託の関係や取扱いの実態によって変わるため、一律には言えません。報告の対象となる四つの類型と速報・確報の期限は個人情報保護委員会の案内に、実務の流れは個人情報保護委員会への報告義務の解説にまとめています。
関連記事
- ファインズの不正アクセスと153万件の予約者情報｜予約システムを使う店舗の報告と通知の手順：予約SaaSの侵害で利用店舗が回す報告と通知の比較に
- サイトコントローラー比較の判断軸｜料金体系・接続チャネル・PMS連携で絞る選び方：接続先の数と連携方式から製品を見直すときに
- Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し：受け口のサーバーからデータベースへ届いた同系統の事例
- タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計：会員情報の保管設計を見直す材料に
- フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説：予約情報を添えたフィッシングを技術面で防ぐ前提
