そのサーバのログを、誰が見ているのか

―― クラウドとAIが変えた組織で、「最後まで見る人」が消える

業界が変わった。

かつて、社内システムは一部屋にあった。サーバを買うのも、建てるのも、止まったときに駆けつけるのも、IT部署の仕事だった。遅かったが、境界はひとつだった。「そのサーバのログを誰が見るのか」という問いには、考えるまでもなく答えがあった。IT部署が見る。他に見る者はいなかった。

クラウドが、その一致を壊した企業は多い。各部署が自分でアカウントを開き、自分で環境を建てられるようになると、IT部署はインフラの所有者から、契約と請求を整理する管理者へと後退していく。資産管理が費用管理になる。それでも、アプリケーションを作る仕事だけは、まだ手元に残っていた。

その最後の砦も、いま揺らいでいる。生成AIとバイブコーディングは、コードを書く力そのものを各部署へ配り始めた。事業部は、情シスを通さずに、思いついたものを来週には動かせる。速い。事業側から見れば、合理的だ。

問題は、この流れに組織のあり方が追いついていないことだ。

DX推進、とは誰もが言う。だが多くの場合それは、新しい道具を各部署に配ることを意味していて、誰が何に責任を持つのかという設計図の描き直しまでは含まれていない。責任分担――RACI でいう Accountable の割り当て――が、変化に置き去りにされている。オンプレ時代、インフラの実行責任と最終責任は、IT部署に集まりやすかった。クラウドで実行は各事業部へ散った。ところが最終責任は、どこにも再配置されないまま宙に浮きやすい。とりわけセキュリティのように、部門をまたいで横に走る関心事で、その空席は効いてくる。

これは、ある一社の物語ではない。どこにでもある光景だ。ただ、その光景を考えるきっかけとして、公表された一つのインシデントを外から眺めてみたい。

4日と、それをどう読むか

2026年6月から7月にかけて、駐車場・カーシェア事業を営むある名鉄グループの企業――名鉄協商――が、不正アクセスによる被害を段階的に公表した。

同社は6月23日に各種Webサービスのシステム障害を公表し、7月2日には、その原因が第三者による不正アクセスであることを明らかにした。公表によれば、6月23日の朝に不審なアクセスを検知して一部サーバが停止し、直ちにシステムの切り離しとネットワーク遮断を実施。外部専門機関の調査で、6月19日にランサムウェアによる不正アクセスの痕跡が確認された。7月6日にコールセンターを開設し、7月22日にはカーシェア「カリテコ」や法人向けサービスの一部を再開。そして7月28日、複数サーバへの攻撃が確認され、顧客情報の外部漏洩のおそれが否定できないとして、対象顧客への個別案内を順次始めたと公表した。すでに案内済みなのは、カーシェア「カリテコ」の会員だという。同日、駐車場管理を委託していた中電不動産も、委託先の事故に関連して、月極契約者の情報が漏洩した可能性があると、別に公表している。

ここで一つの数字に目を留めたい。痕跡の日付は6月19日、検知は6月23日。その間に、4日ある。

この4日を「4日間、警報が鳴っていたのに誰も見なかった」と読むのは、行きすぎだ。6月19日の時点で、検知できるログやアラートが実際に存在したのかどうかは公表されていない。痕跡は事後の調査で見つかるものであって、当時リアルタイムに見える形で残っていたとは限らない。

だからこそ、この4日は、断罪の材料ではなく、問いの入り口になる。痕跡が残る場所と、それを見る人は、同じ責任線の上に置かれていたのか。 どのログが、どの監視に届き、どの時点で「これは異常だ」と判定できる仕組みになっていたのか。その設計の有無が、発見までの時間を決める。侵入経路も、侵害の起点も、この会社は公表していない。だから外からは、この問いを立てることしかできない。だが、この問いこそが本質だ。

外から見えるのは、分散だけだ

公開情報――DNSや外部からの応答――を確認すると、この会社のシステムに、異なる公開構成が同居していることは観測できる。

一方には、配信の前段にCDNなどのエッジを持ち、インシデントの間も応答を返していたサイト群がある。もう一方には、外からオリジンサーバへ直接到達するように見えるサイトや、長く応答が戻らなかった業務サービス群がある。外部から停止や機能制限を観測できた期間が長かったのは、主にこちら側だった。

ただし、ここから先は慎重に読む必要がある。停止した場所と、侵入された場所は、同じとは限らない。 認証基盤やデータベース、ネットワークといった、外からは見えない共通基盤が侵害され、その依存先として公開サービスが止まった、という可能性も十分にある。だから言えるのは、「ここが起点だ」ではなく、「公表された影響と外形を重ねると、直接ネットに面した構成や業務基盤に依存する側ほど、外から見て復旧に時間を要したように見える」というところまでだ。

メールの設定にも、複数性の痕跡はある。送信を許可された外部サービスは、DNS上で複数にまたがっている（もっとも、そのすべてが現在も使われているとは限らない）。なりすまし監視のレポート先も、一つではない。

だが、ここで立ち止まりたい。宛先が複数あることは、それ自体では「責任者がいない」ことを意味しない。一つの統括組織が複数の宛先へ配っているのかもしれないし、冗長化や外部分析サービスとの併用かもしれない。むしろ複数の目が見ている、とも読める。問題は、宛先がいくつあるかではない。 受け取ったレポートを、誰が異常と判断し、誰が送信元を止め、誰が各部門に是正を求め、誰が完了を確認するのか。その一続きの流れを、最後まで担う者がいるのか、だ。

名鉄協商が実際にどのような分担をしていたかは、公表されていない。私はそれを知らないし、外から知る術もない。ここで描いているのは、この会社の内部ではなく、外形が投げかける、どの会社にも当てはまる問いである。

なぜ、この問いが刺さるのか

こうしたシステムの分層は、組織の分業と重なって現れることが多い。新しい顧客接点は事業部門が主導して更新され、従来の基幹は既存の運用体制に残る。悪意でも怠慢でもない。所有と利用が分離し、購買がIT部署から事業部門へ移り、クラウドやAIのベンダ自身がビジネス側に直接売り込む――この構造の必然として、環境はITの視界の外で増え、構成は継ぎはぎになっていく。

そして残るのは、いつも同じ空白だ。実行責任は、たいてい誰かが持っている。誰かが建て、誰かが動かしている。欠けやすいのは、最初に異変を見つけてから、原因を切り分け、止め、直し、再発防止まで確認する――その一連を、一続きの責任として持つ者だ。検知はA部門、基盤はB社、通知はC部署、と分かれていても、日々は回る。回らなくなるのは、継ぎ目を越えて誰かが最後まで見なければならない、その瞬間だけだ。

AIは、これを一段速く回す。クラウドは各部署にインフラを配った。AIは各部署に、作る力を配る。購買の分散に、生産の分散が重なる。環境が増える速度が、棚卸しの速度をさらに超えていく。そして、海外拠点やグループ会社、業務委託先が増えれば、この継ぎ目は複雑になる。委託元が委託先の事故を自ら公表する場面も出てくる。ただ――複雑になるだけで、問われていることは変わらない。その継ぎ目を、最後まで見る人がいるか。

では、何を変えるのか

だから、これは技術で閉じる話ではない。パッチも、監視も、必要だ。しかしその前に、誰がそれに責任を持つのかを決めるのは、技術ではなく組織設計の仕事だ。役割が定義されていなければ、どんな道具も、誰の仕事にもならない。

手渡せる問いは、そう多くない。

まず、自社のドメイン配下のホストを列挙してみてほしい。そして、そこからクラウドアカウント、公開API、SaaS連携へと、棚卸しを広げていく。その一つひとつに、運用主体と更新責任者を書き込めるだろうか。自社でパッチを管理するものは最終適用日を、クラウドやSaaSに委ねているものは、どこまでが事業者の責任で、どこからが自社の責任かを、書き分けられるだろうか。「ログを見ていますか」と問えば、誰もが「見ています」と答える。だが「その運用主体と責任境界を書けますか」と問えば、空白が見える。書けない行が並んだところに、リスクは溜まっている。

そのうえで、各システム・各統制について、最終責任者の名前を一つずつ置けるだろうか。会社全体のセキュリティを一人に背負わせる、という話ではない。脆弱性管理の最終責任、インシデント対応の指揮、グループ横断監視の統括――対象ごとに、責任を一意にできるか、ということだ。

そして最後に、最も大事な問い。異変の検知から、切り分け、停止、修正、再発防止の確認までを、一続きの責任として持つ人がいるか。その人の名前を、あなたは答えられるか。

結び

痕跡は6月19日に残り、検知は6月23日だった。この会社に、最後まで見る人がいたのかどうか、私には分からない。外からは、決して分からない。

だが、確かなことが一つある。いま、多くの会社が、この問いに即答できなくなっている。クラウドが「持つ仕事」を各部署に分散させ、AIが「作る仕事」まで分散させていく一方で、「最後まで見る仕事」だけが、誰の職務記述書にも書かれないまま残されているからだ。

あなたの会社のドメインを引き、そこに並ぶホストと、その先に連なるクラウドやSaaSを眺めてみてほしい。そして問うてみてほしい。それらを監視し、更新し、最初に異変に気づき、そして最後まで見届ける人の名前を、答えられるだろうか。

技術は、その名前を決めてはくれない。答えるのは、組織のかたちのほうだ。