2026年10月17日 公表 委託先・サプライチェーン 調査中 影響度:大

工房「発車オーライネット」のAPIサーバーに不正アクセス、バス事業者にも波及

対象組織:株式会社工房(発車オーライネット) / 規模:最大対象件数 8,341件(対象人数欄 5,614件)
// WHAT HAPPENED

高速バスの予約システムで、外部取引先と連携するためのAPIサーバーが不正アクセスを受けました。利用していたバス事業者も個別に公表しており、委託先経由の波及が続いています。

事案の概要データ

初報2026年10月15日
続報2026年10月17日
不審なアクセス2026年9月16日〜19日
検知2026年10月13日
最大対象件数8,341件(対象人数欄は5,614件。いずれも最終確認中)
対象情報予約名義、電話番号、乗車日/路線/予約番号など
対象外カード情報、口座情報、住所、メールアドレス、パスワードは保存されておらず対象外
侵入経路外部取引先連携用のAPIサーバー。具体的な手口は未公表
波及イルカ交通 2路線計258件・213名(10月17日公表)、中国バス 計17件(10月15日公表)
注意工房本体と各事業者の件数は合算できない

図解:この事故の構造

図:予約システムを提供する1社のAPIサーバーが入口。利用していたバス事業者が個別に公表した。
攻撃者2026年9月16日〜19日(10月13日に検知)
工房「発車オーライネット」外部取引先連携用のAPIサーバー/最大8,341件
イルカ交通2路線計258件・213名(10月17日公表)
中国バス計17件(10月15日公表)
そのほかの利用バス事業者個別に確認・公表が続く

何が起きたのか

工房は2026年10月15日に初報を出し、17日に続報を公表しました。高速バス予約サービス「発車オーライネット」において、外部取引先と連携するためのAPIサーバーに2026年9月16日から19日にかけて不審なアクセスがあり、10月13日に検知したというものです。

最大対象件数は8,341件(対象人数欄は5,614件、いずれも最終確認中)。対象となるのは予約名義、電話番号、乗車日・路線・予約番号などです。カード情報、口座情報、住所、メールアドレス、パスワードは保存されておらず対象外とされています。

通信を遮断した後の継続・拡大は確認されていません。

予約システムを使うバス事業者へ波及

この事案では、「発車オーライネット」を利用していたバス事業者が、それぞれ個別に公表しています。イルカ交通が2路線計258件・213名(10月17日公表)、中国バスが計17件(10月15日公表)です。

乗客から見れば「イルカ交通の予約情報が漏れた」という事案ですが、攻撃を受けたのは予約システムを提供していた会社です。2026年10月に繰り返された構図がここでも現れています。

注意したいのは、工房本体の件数と各事業者の件数を合算できないことです。工房の8,341件のなかに、イルカ交通や中国バスの分が含まれている可能性があります。

小規模な事業者ほど、予約システムを自社で作らず外部のサービスを使います。効率的な選択ですが、そのサービスが破られれば自社の顧客情報が流出し、説明するのは自社になります。

「外部取引先連携用のAPIサーバー」という入口

入口となったのは、外部取引先と連携するためのAPIサーバーでした。

バス予約のシステムは、複数のバス事業者、旅行代理店、他の予約サイトなどと連携する必要があります。そのための窓口がAPIサーバーです。

連携用のAPIは、外部からアクセスされることが前提です。だからこそ、誰からのリクエストかを厳格に確認する必要があります。しかし「取引先からしか来ない」という前提で、認証が緩くなっているケースがあります。

2026年10月は、APIを入口とする事案が集中しました。10月8日のローソン、13日のJR九州フードサービス、14日のアエナ、15日のソースネクスト(約2,251万件)、そして本件です。

自社が外部と連携するAPIを持っているなら、(1)接続元のIPアドレスを限定しているか、(2)認証キーが有効期限なしで使い回されていないか、(3)1回のリクエストで返す件数に上限があるか——を確認してください。

保存していない情報は漏れない

この事案で評価できるのは、カード情報・口座情報・住所・メールアドレス・パスワードを保存していなかった点です。そのため、これらは対象外になりました。

バスの予約に必要なのは、名義と電話番号と乗車情報です。住所もメールアドレスも、業務上は必須ではありません。

「集めていない情報は漏れない」——最も確実なセキュリティ対策です。自社が集めている項目のなかに、本当は不要なものがないか見直す価値があります。

時系列で見る経過

中小企業が学ぶべきポイント

  1. 外部連携用のAPIも、誰からのリクエストかを厳格に確認する。「取引先からしか来ない」は前提にしない。
  2. APIの接続元IPを限定し、認証キーに有効期限を設け、返す件数に上限を設ける。
  3. 集めていない情報は漏れない。業務に不要な項目を集めていないか見直す。
  4. 予約システムを外部に任せていても、乗客への説明責任は自社にある。
  5. 提供元と利用事業者の件数は合算できない。重複している可能性がある。

出典・参考

ご注意
本記事は、各組織の公表資料および報道をもとに、要点をわかりやすく整理したものです。 被害件数は「漏えいした可能性のある最大件数」として公表されている場合があり、実際に漏えいが確定した件数とは異なることがあります。 また、調査の進展により内容が変わる場合があります。正確な情報は必ず出典元の公式発表をご確認ください。

同じ分類の事故

← 新しい記事:ゲオ、自社システムへの不正アクセスでゲオオンライ… 古い記事:カーセンサーnet・C-MATCHに不正アクセス… →

もっと深く学びたい方へ

過去の代表的な事件の解説や、セキュリティ用語の基礎知識もまとめています。