第1話から、インフラの仕事を知る

サーバーの使われ方を調べると、店舗の会計を支えていると分かる

第1話では、接続の記録と担当者の話を照らし合わせることで、目の前のサーバーが店舗の会計を支えていると分かります。別々に見えていた手掛かりが結びつき、仕組みが分かってくることは、この仕事の面白さの一つです。

ほかの担当者と相談し、それぞれの知識や権限で何ができるかを考える面白さもあります。第1話では、ネットワーク担当が通信を確認し、POSシステム担当がレジで会計できるかを確かめます。営業中は店舗の通信を維持し、閉店後の売上送信が終わってから更新することで、お客様が普段どおりに買い物できるようにしています。

一方で、依頼どおりに作業しても責められたり、全体が分からないまま判断を求められたりする難しさも描いています。以下では、その背景と作中の仕組みを説明します。気になった場面の解説から読んでみてください。

依頼どおりに作業しても、責められることがある

第1話では、「検証機」という説明を受けてパッチを適用すると、更新そのものは成功しても、店舗の会計が止まる結末があります。依頼された作業を終えたにもかかわらず、影響を受けた人から責められるという理不尽さも、この物語で考えてほしいことです。

作業を頼んだ側は、業務を止めずに対応することまで期待しているかもしれません。しかし、依頼に書かれた作業の範囲と、相手が期待している結果の範囲は、共有しなければ食い違うことがあります。 作中では、台帳の「検証用」という記録が現在の用途とずれており、その記録を基に「止めていいはず」と伝えられます。作業者の選択に加えて、依頼の根拠となる情報や、その確認方法にも見直す点があります。

「言われたことしかやらなかったから」と片づけると、作業者に際限なく先回りを求めることになります。影響を確認する役割は誰にあり、そのための情報・時間・権限があったのか。依頼者は、守るべき条件を伝えていたのか。責められたという結果だけでは、誰のどの判断や、どの仕組みに問題があったかは決まりません。

担当を分けた後も、互いに確認する必要がある

サーバーを再起動できることと、営業への影響を受け入れてよいと判断できることは別です。榊が通信を確かめても、レジで会計できるかはPOSシステム担当や店舗側の確認が必要です。作中では、知っていること、判断できること、実行する作業の範囲が、人によって異なります。

そのため、作業を引き継ぐときには、相手が判断するための情報や、作業を始めてよい条件も伝える必要があります。Aルートでは、残るリスクと夜間の適用計画をCIOに示して判断を求め、夜間担当には着手条件と、条件がそろわない場合の対応を引き継いでいます。

自分で決めてよい範囲と、ほかの人に判断を求める範囲を確かめ、その場合の相談先も決めておく必要があります。確認先や判断者が分からないときに相談できる経路も、組織として用意しておきたい条件です。

全体が見えないまま、判断を求められる

この仕事の怖さは、情報が足りないと分かっている場合だけでなく、何を知らないのかさえ分からないまま、作業を求められることにもあります。第1話の依頼者も、最初から店舗への影響を把握しているわけではありません。台帳、接続の記録、担当者の説明は、それぞれ違う範囲を示しているため、照合して初めて分かることがあります。

ただし、「全部調べてから作業する」ことも簡単ではありません。確認には時間がかかり、脆弱性を残して待つ間にもリスクがあります。どこまで確かめれば着手できるか、何が分からなければ見送るか、待つ間にどんな対策を取り、誰に判断を求めるかを考える必要があります。

結末まで読めば、最初には見えていなかった事情も分かります。しかし、あとから得た情報を、その時点の自分が知っていたことにはできません。振り返るときは、判断した時点で知っていたこと、確かめられたこと、まだ分からなかったことを分けて考えてみてください。作業者ができた確認とともに、依頼者や組織が用意できた情報や相談先も振り返ることができます。

作中のPOSは、接続が切れても自動ではつなぎ直さない

イツデモのPOSは、朝の開店処理でレジ1台につきTCP接続を1本張り、閉店まで同じ接続で値段を問い合わせます。営業中に切れても自動再接続しません。これは作中のPOSに固有の仕様であり、POS全般やTCPそのものの性質を説明したものではありません。

接続数だけでは誰が何の業務に使っているかは分からないため、担当者に利用状況と、止めたときの影響を確かめることが重要です。本作では、システム企画担当が台帳や導入時の申請書から担当部署をたどり、POSシステム担当が現在の利用状況と再起動の影響を答えます。

ノードリレーは価格照会に加え、閉店後の売上送信も中継する設定です。そのため通常の保守では、閉店時刻だけでなく売上送信の完了と店舗接続の終了を待ちます。決済の記録は別に残るため、価格照会の停止がそのまま決済の失敗を意味するわけではありません。

店舗回線を遮断した経路でも、サービスを再起動した経路でも、切れた接続は自動では戻らないため、サーバーが応答していてもレジの価格照会は再開しません。すでに支払いが済んだ会計をやり直して二重請求することなどを防ぐため、全店で中断した会計の有無を確認し、該当分の決済結果と売上・取消を照合します。全店舗の全取引が壊れた、という設定ではありません。

B・Cルートでは、各店の店長と締め担当が並行して照合を進めます。途中の会計の件数が店ごとに異なるため、完了時刻にも差が出ます。最初の連絡では、届き始めた店舗報告と確認手順を基にPOSシステム担当が21時ごろという暫定見積もりを伝えます。全384店の個別見積もりがすでに確定したわけではなく、不一致があれば延びる前提です。照合後の接続確認や売場の再開準備も含め、22時までに営業を再開できる見通しが立たないため、店舗運営部が全店の当日営業終了を決めます。お客様に退店を案内し、売場のスタッフは片付けを終えて退勤します。店長・締め担当などが残って売上・決済を照合し、本日分を締めます。未送信の売上と取消は、店舗の記録を保守用の手順で回収し、POSシステム担当が取引番号と本部の受信記録を照合して重複なく取り込む設定です。本部ではテストレジで価格照会と会計取消を確認しますが、店舗のレジはその夜は通常の接続を再開しません。翌朝の開店処理で接続し、価格照会を確認して9時に営業を再開します。保守用の回収手順、見積もりと確認の所要時間は物語上の想定であり、実在するPOSの標準機能や標準的な所要時間ではありません。

回線を戻しても、会計を再開できない理由

結末Bでは、社外と一緒に店舗の通信も遮断したため店舗で異常が起き、本部へ連絡が届いてから原因を確認して設定を戻すまでに時間がかかります。回線を戻した時にはレジの接続がタイムアウトしており、自動再接続しないため会計を再開できず、結末Cと同じ全店の復旧対応・当日の営業終了へ進みます。

この物語では、遮断から設定復旧までに接続がタイムアウトした、という設定です。何分なら接続が残るかという一般的な境界は示していません。結末の違いは、店舗の通信を維持したかどうかにあります。

ファイアウォールの設定では何を変更したのか

榊の端末はFortiGate／FortiOS 7.6系をモデルにしています。イベント用の社外許可1042を削除し、店舗用2042を残す設定に変更します。番号、アドレス、インターフェース名、構成、表示する試験記録は創作であり、掲載したコマンドはそのまま別の環境に適用するための手順ではありません。

この場面では、社外の業務接続がなく、同じ宛先を通す別の許可もなく、拒否ログを記録できることを事前に確かめているため、1042の削除によって社外からの新しい接続が拒否される、という見通しを立てられます。

変更後は「接続できない」だけで終えず、同じ試験の送信元・宛先・時刻・ポートをFWの拒否ログと照合します。同時に、本社の検証用POSが同じ接続で100円を返し、全384店の照会が続いていることも確認します。止めたい通信が止まり、店舗の会計が続いていることを、両側から確かめる場面です。

FortiOSでは、設定変更に伴って既存セッションが再評価されることがあります。ルールを残す意図だけでは通信の継続を保証できないため、作中でも変更後のセッション表と実際の価格照会を確かめます。社外の既存セッションが残っていないことも確認します。FortiOS 7.6.0 Best Practices の Policy configuration changesを参照しています。

構文の参照：FortiOSのポリシー設定 ／ ログ設定 ／ ncのマニュアル

外部からの通信を遮断しても、パッチを適用する必要がある

外部からの通信を遮断しても、PHPの脆弱性そのものは解消されず、パッチの適用が不要になるわけではありません。店舗網からはサービスに届くため、営業を続けるAルートではFW変更の承認とは別に、残るリスクと監視、夜間の適用計画をCIOに示し、未修正のまま営業を続けてよいか判断を求めます。

CVSSは脆弱性の深刻度を示す指標であり、侵入の確率や業務への損害額を示す数値ではないため、実際の公開範囲や利用状況も合わせて判断します。FIRSTのCVSS解説を参照しています。

AルートでCIOが決裁すること、全店の締め・売上送信と接続終了を待って土曜0時に着手判断をすることは、イツデモの体制と業務時間に合わせた設定です。実際の責任者や手順、選べる対策は組織によって異なります。

店舗回線も遮断したBルートでは、閉店を決めた後に会計記録を保全し、売上取込を一時停止して、御影の承認による緊急更新を行います。店舗側の照合を並行して進められるため、通常の0時の作業枠までは待ちません。更新後の確認を経て売上取込を再開しますが、パッチを当てても中断した会計の照合は必要なので、それだけで営業を再開できるわけではありません。

結末A（旧版で引き継ぎまでを描いた旧Aを含む）は利用状況と着手条件を確かめ、関係者に判断や作業を引き継いだ結果であり、「緊急パッチは延期すればよい」という一般則を示してはいません。また、先送りの経路で侵入が起きる時刻も、シナリオ上の出来事です。

侵入後は価格表を戻すだけでは再開できない

結末Dでは、隔離と記録の保全、侵入範囲の調査を経て、サーバーの再構築・パッチ適用・影響する認証情報の変更と、確認済みバックアップからの復元を行います。セキュリティ担当の接続再開の確認、本部と各店の業務確認を経て、店舗運営部が営業を再開します。復旧時の再感染防止や再構築については、CISAなどの StopRansomware Guide 第2部を参照しています。

月曜9時の再開は、必要なバックアップと再構築の手段があり、再開条件を満たせたという物語上の結果です。二日あれば直せるという標準時間や、営業再開で調査がすべて終わることを意味しません。

御影の反省は経路で分けています。検証機という前提を確認しなかった場合、遮断範囲を誤った場合、待機中の対策を決めなかった場合は、それぞれ異なる判断だからです。Dでは、待つ間の対策を決めなかったことを振り返り、会社への報告と関係者との経緯の確認を引き受けます。

悩んだ末に、御影が退職する結末を変えました

以前のDルートでは、ランサムウェア被害の後、御影が退職を申し出て、最終出社日を迎えるところまで描いていました。ゲームとしては、退職という出来事で選択の結果をはっきりと示せるため、分かりやすい結末でした。それでも、この結末を残してよいのかは悩みました。

退職は人の人生に関わることなので、ゲームの結末として軽々しく扱いたくありません。また、この描き方によって傷つく人がいるかもしれないとも考えました。何より、「攻撃を受けて被害が出たら、責任を取って辞める」という世界観を、この作品で肯定したいのかと自分に問い直したとき、答えは明確に「いいえ」でした。そのような責任の取り方を是認したくも、後押ししたくもありません。

ゲームとして結末が分かりやすいことだけでは、その描き方を選ぶ理由にはできないと考え、悩んだ末に、御影が退職する結末から、仕事への自信が揺らいだまま、その後の業務が続く結末へ変えました。

現在の結末では、月曜の運用席で翌日の対応予定を確かめている御影の手が止まり、「俺、この仕事向いてないのかな……」という独り言が漏れます。画面に目を戻しても、しばらく手は動きません。営業を再開できたからといって、そこで働く人の自信まで元に戻るとは限らない、という余韻を残しています。

この独り言は、御影がこの仕事に向いていないという作品からの答えではありません。励ましを受けて立ち直る場面も、辞めるか残るかを決める場面も置かず、被害の重さと、答えが出ないまま仕事に向き合う姿を描くことにしました。事故への対応や再発防止についても、誰か一人の進退で話を終えず、判断に使われた情報や組織の仕組みまで振り返ってほしいと考えています。

結末の評価と損失額の読み方

共有カードの評価は、営業継続が「任務達成」、当日営業終了が「痛恨の判断」、土日とも休業が「最悪の週末」です。金額の大小ではなく、店舗の営業に何が起きたかを表しています。

報告書の金額は、作中の店舗数、客数、客単価、未回収率、粗利率などを使った試算です。結末B・Cは会計が止まった時刻から通常閉店の22時までの営業機会を失い、翌週末までの影響も含みます。障害発生が遅い経路では、22時までの残り時間に応じて当夜の逸失粗利を計算します。全ルートで従業員の人件費と通常の保守費用を除いています。0円は、この集計範囲での営業損失が0円という意味です。

選択肢ごとの時刻や、復旧に要する時間もあらかじめ定めています。現実の障害の費用・所要時間を予測するモデルではなく、選択によって店舗の営業や復旧作業にどのような違いが生じるかを比較するために設定しています。客数と客単価は調査値を参考にしていますが、会計の時間帯別ペース、未回収率、粗利率、廃棄量、翌週への影響と費用は創作の仮定です。結末ごとに集計範囲も異なるため、現実の対策を費用だけで順位づける表ではありません。具体的な算定式はシナリオ正本に記載しています。

この仕事のどんなところが気になりましたか

仕組みが分かって面白かった場面はありましたか。また、どの登場人物の仕事をもっと知りたいと思いましたか。気になった用語を調べたり、別の選択肢を試したりすることも、この仕事を知る入口になります。

判断の過程をさらに考えてみたい方は、今回通った場面を一つ選び、次の問いに沿って振り返ってみてください。結末の評価と損失額は作中で起きた結果を表しており、それだけで、その時点の判断の妥当性や責任の分担まで決まるわけではありません。

• その時点で何を知っていて、何を前提として受け入れていましたか。確かめられたことと、あとから初めて分かったことは何でしたか。
• 自分で決めてよかったことと、別の人に判断を求める必要があったことは何でしたか。その人が判断できる材料を渡せていましたか。
• 確認する時間や情報が足りなかったとき、作業の見送りや、待つ間の対策を誰に相談できましたか。
• 自分が依頼する側なら、目的と守るべき条件をどう伝えますか。組織として、担当者が確認・相談しやすくするために何を用意できますか。

複数人で遊んだ場合は、同じ場面で判断が分かれた理由も話してみてください。それぞれが想定した仕事の範囲や、当然だと思っていた前提の違いを確かめる機会になります。

題材にした出来事と、創作した部分

題材にした出来事は、クリア後の「この話の元になった事件」で紹介しています。イツデモ、ノードリレー、登場人物、依頼に書かれたCVSS 9.8、更新パッケージ、構成と被害は本作の設定です。作中の操作や結末は、題材にした事件の再現ではありません。