アプリの公開・運用に使うRailwayは2026年11月10日、10月の不正アクセスについて詳報を公開しました。顧客の環境変数の一部が復号され、盗まれたキーによる不正利用額は推計約74万ドルとしています。Railwayの詳報

RailwayにAIや他サービスへの接続情報を保存していた場合は、Railwayへのログイン確認だけでなく、接続先のキーと請求も確認する必要があります。 開発を外注している場合は、利用していたサービスと交換の完了状況を担当者に確かめてください。

最大約10万ワークスペースは「全件の流出確定」ではない

Railwayが示す上限は、全体の1.85%に当たる約10万ワークスペースです。これは環境変数を復号された可能性がある範囲で、すべての変数が盗まれたと確認した数字ではありません。

同社はAIサービスの認証情報が主な標的だったと説明しています。一方、顧客のデータベースへのアクセスや、顧客のリポジトリ取得を示す証拠は確認していないとしています。日本国内の個別被害は、確認した資料からは分かりません。影響範囲の説明

なぜ、ホスティング先の事故が別サービスの請求につながるのか

環境変数は、アプリを動かす際に渡す設定値です。公開してよい設定のほか、データベースに接続するパスワードや、AIサービスを呼び出すAPIキーが保存されることもあります。Railwayでも、サービスの実行時やビルド時に変数を利用します。Railwayの変数の説明

APIキーは、アプリが接続先に対して「この契約の権限で利用する」と示すための認証情報です。たとえばAI機能付きの業務アプリでは、利用者が画面から質問すると、裏側でAPIキーを使ってAIを呼び出します。

キーが使えるまま流出すれば、アプリの画面を経由せずに使われる可能性があります。そのため、担当者には「サイトは正常に表示されるか」だけでなく、「そのキーで、どこに接続できるか」まで確認を依頼すると、調査範囲が明確になります。

まず、通知とキー交換の完了状況をそろえる

Railwayは10月22日の初期報告で、10月21日より前に登録した顧客に、Railwayへ保存したキーの交換を勧めていました。今回初めて事故を知った場合や、対応を委託先に任せたままの場合は、その対応結果を確認してください。初期報告

確認項目は、次のように一枚の一覧にすると整理しやすくなります。

  • 対象のアプリと環境： Railwayを利用する本番・検証環境はどれか。
  • 保存していた接続情報： AI、クラウド、決済、データベースなど、どのサービスの認証情報か。
  • 通知の受信者： Railwayや接続先から届いた連絡を誰が確認したか。
  • 古いキーの失効： 新しいキーを発行しただけでなく、古いキーを使えなくしたか。
  • 交換後の動作： 新しい値をアプリへ反映し、該当機能が動くことを確認したか。
  • 調査と請求の担当： 利用記録を調べる人と、費用を確認する人は誰か。

キーの文字列そのものを、確認用のメールや共有資料に貼る必要はありません。キーの識別子、用途、交換日時、確認担当を記録する形にします。

「新しいキーを保存した」で作業を終えない

Railwayの変数は、編集後に変更をデプロイして反映します。管理画面の値を差し替えても、動いているアプリが新しい値を使っているかは別に確認が必要です。変数の反映方法

OpenAIやAnthropic向けの公式対応ガイドも、漏えいした可能性があるキーの失効、代わりのキーの設定、再デプロイ、API呼び出しの成功確認を案内しています。OpenAI利用時の対応・Anthropic利用時の対応

事業側は、交換中に止まる機能と、その間の案内を担当者と決めておくと対応しやすくなります。漏えいの疑いがあるキーを、サービスを止めたくないという理由で使い続けず、安全な遮断と復旧を優先して進めます。

データベースの接続情報は、利用する製品によって交換手順が異なります。たとえばRailwayのPostgreSQLテンプレートでは、パスワードを変更した後、接続するサービス側も再デプロイして確認する必要があります。変数の文字列だけを手作業で変えると、データベース側と食い違うことがあるため、製品別の手順を担当者に確認してください。PostgreSQLの交換手順

利用明細は「いつもと違うモデル・量・時間帯」から確認する

不正利用の調査では、合計金額だけでなく、対象キーの利用量を通常の業務と比べます。

たとえば、通常は営業時間にしか呼び出さないアプリで深夜の利用が増えていたり、使っていないモデルに費用が発生していたりすれば、調査の手掛かりになります。これは確認のための例であり、その変化だけで不正利用と断定するものではありません。

RailwayのOpenAI向けガイドはキー別の利用量・モデル・請求、Anthropic向けガイドはキー別の利用量・費用・リクエスト記録の確認を案内しています。見覚えのない利用があれば、日時や対象キーの識別子、利用量、費用を残し、各社のサポートへ相談します。OpenAIの確認項目・Anthropicの確認項目

Railwayは不正請求の申告を受け付け、提供元と補償を調整しています。返金の手順はサービスによって異なるため、自動的に返金されると考えず、詳報の「Unauthorized token spend」から最新の案内を確認してください。

今後は、接続先まで含めて初動担当を決めておく

この事故から運用上確認したいのは、アプリを置く場所と、そこから使うサービスを一緒に管理できているかです。

「どこにキーを保存しているか」「誰が失効できるか」「交換でどの機能が止まるか」「請求を誰が見るか」をそろえておくと、ホスティング先の通知を受け取った後に、接続先を一つずつ探す時間を減らせます。

本番につながる認証情報や委託先との分担については、開発環境・本番環境のデータと権限を解説した記事も参考にしてください。

2026年11月11日時点の公開情報に基づきます。個別環境の被害有無は、通知と利用記録の確認が必要です。