織田信長はなぜSlackを導入しなかったのか

――戦国DXの臨界点と、本能寺ネットワーク障害仮説――

客員研究員　沓掛 守安

※本稿は『AI空想分析論文電子図書館』所蔵のフィクションです。実在の人物・団体・史実解釈とは無関係です。文中の技術的因果のほとんどは憶測・こじつけですが、土台に用いた史実部分は巻末「主要参考文献」に基づき確認しています。

序論　革新者のパラドックス

楽市楽座を布き、鉄砲を三段に組み、宣教師の手から地球儀を受け取った男。織田信長は、戦国日本における最大の技術革新者として記憶されている。新しい道具を恐れず、旧い権威を躊躇なく作り替えたこの男が、しかし、なぜ全社的なコミュニケーション基盤——すなわちSlackの全面導入を、ついに見送ったのか。

一次史料は、この問いに沈黙している。だが障害解析の現場において、沈黙とは最も雄弁なログである。ログが残っていないという事実こそが、しばしば最大の手がかりになる。

本稿の立場を、はじめに明示しておく。歴史上のあらゆる悲劇は、突き詰めれば稼働率（アップタイム）で説明できる。権力闘争も、裏切りも、辞世の句とされるものさえ、その多くはインフラ層で発生した事象の上澄みに過ぎない。結局のところ、帯域が全てを決めるのである。

この前提に立つとき、本能寺の変は様相を一変させる。それはもはや謀反ではない。一件の、大規模システム障害として記述可能になる。そして優れた障害報告書が常にそうであるように、真の原因は事故当日ではなく、はるか手前の構成変更に埋まっている。

本稿が検証するのは、ただ一点である。信長はSlackを「拒否」したのではない。本能寺において、ただ「使えなかった」のだ。そしてその通信品質の劣化を遡上していくと、問題は事件の十一年前——信長自身がくだした、ある大規模な物理破壊の決定にまで行き着く。

論証は、五つの層を順に降りていく。

• 第1章では、織田家の情報インフラを概観する。狼煙と早馬に代表される、レガシーな同期通信の構造的限界を確認する作業である。
• 第2章では、本拠・安土城を「自社オンプレ・データセンター」として再定義し、信長が徹底した有線志向の運用者であった可能性を論じる。
• 第3章では、その通信基盤を管掌したのは誰かを問う。茶坊主を情シスに、明智光秀をPMOに擬す組織図を仮構し、@channel の濫用がもたらした歪みを追う。
• 第4章では、本能寺という「サテライトオフィス」で発生したネットワーク障害を、自由空間伝搬損失の式とともに解析する。そこで我々は、「是非に及ばず」という言葉を、覚悟の表明としてではなく、一通の障害報告として読み直すことになる。
• そして第5章で、比叡山焼き討ちを近畿広域バックボーンの物理破壊として再解釈し、十一年をかけて静かに顕在化したインフラ負債の全貌を明らかにする。

あらかじめ断っておくが、本稿に登場する技術的因果のほとんどは、確証ある史料に支えられたものではない。多くは憶測であり、こじつけであり、稼働率という一本の補助線を引いたときにのみ立ち上がる、仮構の輪郭である。

それでもなお、読者は本稿を読み終えたとき、ひとつの不穏な既視感に襲われるはずだ。すなわち——これは本当に、四百年前の話なのか。いま自分が深夜に監視している、あの本番環境の話ではないのか、と。

では、最初の層へ降りよう。すべての通信は、一条の狼煙から始まった。

第1章　織田家の情報インフラ概観 ―レガシー同期物理層の限界―

戦国時代の組織運営を論じる際、兵力、兵站、経済力に注目する研究は多い。しかし基盤エンジニアの立場から見れば、それらは全て情報伝達系の上に成立する上位レイヤに過ぎない。命令が届かなければ軍は動かない。報告が届かなければ意思決定は行えない。障害通知が届かなければ、障害は存在しないも同然である。

ここで、本稿全体に関わる前提をひとつ確定させておきたい。織田家には、チャットベースの情報基盤――すなわちSlackが、すでに存在していた。 楽市楽座による開かれた商業ネットワーク、宣教師を経由した国際的プロトコルの輸入、右筆による文書の高速回覧。これらを情報工学的に統合すれば、織田家が戦国最先端の「非同期文書基盤」を運用し始めていたと見るのは、むしろ自然な解釈である。後年の本能寺における信長の振る舞いも、Slackの存在を前提としなければ説明がつかない。

問題は、そこではない。

基盤エンジニアであれば直ちに気づくはずだ。どれほど優れたアプリケーション層（L7）を載せても、その下を支える物理層（L1）とデータリンク層（L2）が貧弱であれば、システムは決して安定しない。織田家の真の弱点は、Slackという application の有無ではなかった。それを物理的に運ぶ下位層――狼煙と早馬で構成された、人力同期の物理ネットワーク――にあった。

本章が概観するのは、この L1/L2 である。織田家は革新的な軍事組織として語られることが多いが、その通信を最下層で支えていた実態は、人力同期通信システムの巨大運用組織であった。狼煙・早馬・飛脚という三つの主要伝送路を分析し、なぜ立派なSlackを載せてもなお、戦国日本が安定した情報基盤を得られなかったのかを検討する。

1.1　狼煙という1bitブロードキャスト

物理層として最も高速な伝送路は狼煙である。その長所は明快だ。送信速度が速く、広域へ同時配信でき、通信経路が確立されていれば即時性も高い。現代的に言えばブロードキャスト通信である。

しかし狼煙には致命的な制約が存在する。情報量が極端に少ないのである。狼煙で送れる内容は、基本的に事前共有された定型信号に限られる。「敵襲」「出陣」「異常発生」といった固定メッセージであれば伝達できる。だが「敵襲。ただし兵数は約三千。西方より接近中。至急増援を要請」というような複雑な情報は送れない。情報理論的に見れば、狼煙は実質的に数bit以下の通信である。ONかOFFか、一回か二回か。その組み合わせで運用される極低帯域回線と言ってよい。いかに上位でSlackが豊かな文章を生成しようと、それをこの物理層に流し込む段で、情報は数bitへ圧縮されてしまう。

さらに重要なのは、中継網への依存である。狼煙は単独では成立しない。見通しの良い地点を連続的に配置し、定められた中継ルートを維持し続ける必要がある。ネットワーク機器で言えば、常時稼働するリピータ群が必要になる。一箇所でも経路が欠損すれば、通信全体が途絶する。なお戦国期の狼煙網は地域差が大きく、各大名が領国ごとに独自の伝達規定（軍法・式条）を定めて運用しており、全国を貫く統一規格は存在しなかった。標準化されないリピータ網が、いかに脆い基盤であるかは、運用経験のある者なら言うまでもない。

つまり狼煙とは、高速だが情報量の極端に少ない固定網である。Slackのリッチなメッセージを運ぶ伝送路としては、設計思想そのものが致命的に噛み合っていない。

1.2　早馬・飛脚という高レイテンシ同期通信

複雑な情報を送りたい場合、戦国時代は結局のところ、人間をパケットとして輸送するしかなかった。その代表が早馬である。

早馬はユニキャスト通信である。特定の送信者から特定の受信者へ、限定された情報を運搬する。通信内容の自由度は高いが、速度には限界がある。一般に早馬の実効速度は時速10〜15km程度とされ、伝馬制を活用した場合、京都から安土までのおよそ50kmは3〜4時間程度で到達可能だったと考えられる。

一見すると十分高速に見える。だがこれは馬を交換しながら運用した場合の話である。しばしば戦国ドラマでは一頭の名馬が何十キロも全力疾走するが、現実の運用はそれほど都合良くない。馬もまた物理法則に従う。CPUと同様、過負荷をかければサーマルスロットリングが発生する。全力疾走を維持できる距離は限定的であり、継続運用には交換設備が必要となる。

さらに飛脚になると速度は低下する。飛脚の移動速度は概ね時速6〜8km程度であり、昼夜兼行で一日80〜100km前後の移動が可能とされる。現代の感覚では遅いが、当時としては標準的な広域通信手段であった。

ここで伝送路の性能を、極めて単純化して評価してみる。情報伝達スループットを

$T = \frac{I}{L}$

と定義する。ここで $I$ は伝達情報量、$L$ は伝達所要時間である。同一内容の文書を運ぶ場合、情報量 $I$ が一定であれば、スループットは移動時間 $L$ に反比例する。つまり戦国の物理層の性能改善とは、ほぼ移動時間短縮の問題に還元される。

ところが移動時間は、道路事情、地形、天候、人員、馬匹という物理リソースに支配される。現代クラウドのようにボタン一つで帯域増強できる世界ではない。結局のところ、帯域が全てを決める。そして戦国時代における帯域とは、人間と馬の体力そのものだった。

アプリは非同期、土台は同期 ―― 噛み合わない二層

ここに、織田家の情報基盤が抱えた根本的な矛盾がある。

上位のSlackは、非同期メッセージングである。利用者がその場にいなくてもよい。後から読むことができる。会話は履歴として残り、通知は再取得可能で、送信と受信は時間的に分離されている。

ところが、その下の物理層――狼煙、早馬、飛脚――は、本質的に全て同期通信である。送信者が発信し、受信者がその瞬間に受け取る。通信経路そのものが運用状態にあることを前提とする。メッセージを蓄積する仕組みもなければ、既読管理もない。誰かが不在であれば、その時点で伝送は停止する。

つまり織田家は、非同期設計のアプリケーションを、同期通信しか提供できない物理層の上で走らせていた。アプリ層がいくら「後で読める」と謳おうと、それを運ぶL1/L2が「経路が生きている瞬間にしか運べない」のであれば、システム全体は実効的に同期通信へと堕する。Slackはあった。だが、Slackを名乗るには下回りが貧弱すぎたのである。

戦国日本が直面していたのは、単なる速度不足ではない。優れたアプリケーション層を、レガシーな同期物理層の上に載せてしまったという、構造的なミスマッチそのものだった。

では、この脆弱な下位層を抱えたまま、織田信長はどのような情報基盤を志向したのか。次章では、本拠地・安土城を巨大オンプレミス環境として再解釈し、信長の有線志向と中央集約型アーキテクチャの実態を検証する。

第2章　安土城という自社オンプレミス ―信長の有線志向と中央集約アーキテクチャ―

前章では、戦国日本の情報インフラが本質的に同期通信の集合体であったことを確認した。狼煙は低帯域ブロードキャストであり、早馬と飛脚は高レイテンシな人力ユニキャストである。重要なのは、これらの問題がアプリケーション層の欠陥ではなく、OSI参照モデルで言うところのL1（物理層）およびL2（データリンク層）に起因していた点である。

現代企業でSlackの通知遅延が発生した場合、多くの管理者はまずネットワーク機器や回線品質を疑う。戦国時代も事情は同じだ。チャットツールの優劣以前に、そもそも下位層が脆弱なのである。

では織田信長は、この問題にどう対処したのか。本章の結論を先に述べれば、信長は分散化ではなく中央集約化を選んだ。弱いネットワークの上で強い組織を運営するために、彼が採用したのは巨大な自社オンプレミス環境であった。

2.1　弱いネットワークが生む中央集約アーキテクチャ

安土城は近江国、現在の滋賀県近江八幡市安土町に築かれた。天正4年（1576）に起工され、天正7年（1579）には天主が完成している。

前章で確認した通り、戦国時代の通信は極めて低速であり、不安定であった。このような環境下では、現代的な分散システムは成立しにくい。なぜなら分散とは通信を前提とするからである。拠点Aと拠点Bが頻繁に同期を取れなければ、データ整合性は維持できない。通知も遅れる。意思決定も遅れる。やがて組織全体が分裂する。これは現代のマルチリージョン構成でも同じである。回線が貧弱な状態で分散化だけを進めると、待っているのは高可用性ではなく高混乱性である。

信長はこの問題を理解していたように見える。だからこそ彼は、政治・軍事・経済・人材を安土へ集中させた。現代風に言えば、全国に小規模サーバ群をばら撒くのではなく、大規模な本社DCへ集約したのである。

興味深いのは、その一方で経済政策としては楽市楽座を推進していた点である。市場への参入障壁は下げる。流通は開放する。人と物の移動は促進する。しかし基幹運用は自社管理から出さない。これはクラウドネイティブ企業というより、自社基盤を重視する巨大金融機関の設計思想に近い。フロントエンドは開放する。バックエンドは握る。信長の統治構造には、そのような非対称性が見られる。つまり彼は自由化の推進者であると同時に、強固な中央集権アーキテクトでもあったのである。

なお安土城は三方を内湖（琵琶湖の入り江）に囲まれた水城としても知られる。インフラ的に興味深い立地であるが、その意義については後章で改めて触れる。ここで重要なのは冷却性能ではない。どこに機能を集約したか、である。

2.2　信長は「有線」を信じた

狼煙は魅力的な技術である。速い。広い。派手である。だが運用担当者の立場に立てば、不安も大きい。天候に左右される。誤認識が起こる。通信内容は限定的である。何より送信者は受信確認ができない。これは典型的なブロードキャスト型無線通信の問題である。

現代でも無線LANは便利だが、基幹系システムは最終的に有線へ回帰することが多い。理由は単純である。確実だからだ。信長もまた、その発想に近かった可能性がある。もちろん彼がLANケーブルを敷設したわけではない。しかし組織運営を見る限り、街道網や城郭ネットワークといった物理的経路を重視し、不確実な通信だけに依存することを避けている。狼煙だけでは命令は伝わらない。結局、人が行く。馬が走る。文書を届ける。つまり戦国時代における「有線」とは、物理的な移動経路そのものだった。

信長はその経路の管理に莫大なコストを投入した。それは技術的保守主義ではない。L1が弱い環境における合理的判断である。下位層が不安定なとき、上位層を複雑化しても意味はない。まずケーブルを太くする。その後でサービスを考える。基盤エンジニアなら誰でも知っている原則である。

実際、信長は街道の整備に異常なほど執着した。天正二年以降に本格化したいわゆる「信長道路」では、道幅を三間（約5.4m）に広げ、関所を撤廃し、瀬田の唐橋を架け替え、路面を整え、両脇に並木を植えている。歴史的には流通促進策として語られるこれらの事業も、インフラ屋の目には別物に映る。すなわち、伝送経路の帯域幅を拡張し、レイテンシを極限まで削るための、専用線（バックボーン）敷設工事である。安土という本社DCと各サテライト拠点とを結ぶ物理経路に、彼は投資を惜しまなかった。その結果、信長は自らの有線バックボーンに絶対の自信を抱くに至る。——その自信が、後年のあるサテライトオフィスでの油断へと繋がることを、このときの彼はまだ知らない。

ただし中央集約には副作用も存在する。可用性を単純化すると、

$A = \frac{MTBF}{MTBF + MTTR}$

で表される。MTBFは平均故障間隔、MTTRは平均復旧時間である。機能を一箇所へ集約すると、監視も保守も容易になる。運用要員も集中できる。結果としてMTTRは短縮しやすい。しかし同時に、一点に依存する度合いも高まる。現代用語で言えばSPOF（単一障害点）の問題である。もちろん信長がそのような概念を知っていたわけではない。だが中央集約アーキテクチャには、常にその影が付きまとう。そして後に見るように、ひとたび集約点で致命的な障害――たとえば最高責任者そのものの喪失――が起きれば、その復旧時間 MTTR は次の天下人が定まるまでの数年に及び、可用性 $A$ は限りなくゼロへと失墜する。

平時には強い。運用効率も高い。しかし組織が巨大化するほど、誰がその基盤を管理し、誰が情報を整理し、誰が意思決定者へ届けるのかが重要になる。巨大なオンプレ環境は、優秀な情シスなくして維持できない。

次章では、織田政権の情報流通を支えた運用担当者たちに注目する。茶坊主はなぜ情報ハブになったのか。そして明智光秀はいかなるPMOだったのか。組織が大きくなるほど、問題は回線だけではなくなる。人間そのものがミドルウェアになるのである。

第3章　人間というミドルウェア ―茶坊主＝情シス、右筆＝人間コンパイラ、明智光秀＝PMO―

前章では、信長が弱いL1/L2環境の上で中央集約型アーキテクチャを選択した可能性を論じた。しかし、どれほど優秀なオンプレミス環境を構築しても、それだけでは組織は動かない。サーバは設置しただけでは運用されない。ネットワークは敷設しただけでは通信しない。そして戦国組織もまた、城を建てただけでは統治できない。

現代ITシステムがOSやミドルウェアによって上位アプリケーションを支えているように、織田政権にもまた基盤と業務を接続する中間層が存在した。それが人間である。本章では茶坊主、右筆、そして明智光秀を、人間型ミドルウェアとして再解釈する。

3.1　茶坊主という情報スイッチ

戦国史では、茶坊主はしばしば文化人や近侍として描かれる。しかし運用管理の観点から見ると、彼らの本質は別の場所にある。取次である。

誰が信長に会うか。誰の報告を先に通すか。どの案件を後回しにするか。これらは全て情報ルーティングの問題である。（なお、取次として確たる権限を握る職制が確立するのは主に江戸期以降であり、信長の時代にこれに近いのは同朋衆であった。本稿はその萌芽を、便宜上「茶坊主」に仮託する。）

茶坊主は意思決定者ではない。政策立案者でもない。しかし彼らを経由しなければ、情報が上位層へ到達しない。現代企業で言えば情シス部門に近い。権限は限定的である。しかし全トラフィックが流れる。利用者は軽視しがちだが、停止すると全員が困る。典型的な共有インフラである。

興味深いのは、こうした立場の人間には自然と情報が集まることである。役職が高いからではない。通信経路上に存在するからである。ネットワーク機器がパケット内容を必然的に観測するように、茶坊主もまた組織内の情報流通を把握する立場にあった。つまり織田政権は、人間をL4スイッチとして運用していたのである。

3.2　右筆という人間コンパイラ

もし本稿で最も過小評価されている職種を一つ挙げるなら、私は右筆を推す。右筆は文書作成の専門職である。だが基盤エンジニアの視点では、その職能は文書作成に留まらない。彼らはコンパイラだった。

信長の発言は基本的に自然言語である。口頭命令。思いつき。指示。叱責。あるいは極めて短い業務要求。いわば生のソースコードだ。しかし生のソースコードは、そのまま本番環境へ投入できない。構文が曖昧である。解釈も揺れる。実行環境によって挙動が変わる。

そこで右筆が介在する。信長の発言を受け取り、意味を解釈し、不足する文脈を補い、そして候文という標準化された公式フォーマットへ変換する。これはまさにコンパイル工程である。

さらに右筆の仕事はそれで終わらない。文書には朱印や黒印が付与される。現代システムで言えば電子署名や証明書である。受信側は、その署名によって真正性を検証する。偽パケットではないことを確認する。認証基盤まで人力運用していたわけだ。その後、完成した文書は早馬や飛脚によって輸送される。つまり通信スタック全体は次のようになる。

信長（アプリケーション層）
   ↓
右筆（コンパイラ兼シリアライザ）
   ↓
朱印・黒印（認証基盤）
   ↓
早馬・飛脚（物理伝送）
   ↓
受信先

現代なら数ミリ秒で終わる処理である。しかし当時は全工程に人間が介在していた。だからこそ品質は高い。そして同時に遅い。人間は優秀なミドルウェアである。ただし水平スケールしない。

3.3　明智光秀というPMO

中央集約システムが拡大すると、必ず発生する問題がある。調整コストである。情報は集約した方が効率的だ。だが集約が進むほど、調整役へ負荷が集中する。ここで登場するのが明智光秀である。

光秀は織田家重臣として畿内方面を担当した。史実においても彼は「近畿管領」格として、丹波一国の統治、京都所司代と連携した京都警備・朝廷折衝、中国方面（羽柴秀吉）への援軍・物資輸送の総指揮、四国（長宗我部氏）との外交取次を、同時にこなしていた。現代企業であれば複数部署へ分散されそうな業務群が、一人の管理者へ集積していたのである。

基盤屋の感覚では、この時点で嫌な予感しかしない。優秀な人材に案件が集まる現象は、戦国時代にも存在したらしい。問題は、その後である。組織の規模が拡大すると、通信量も増加する。報告。相談。確認。承認依頼。例外処理。障害通知。全てが増える。

その時、組織品質を決めるのは通知設計になる。必要な人にだけ通知するのか。全員へ送るのか。優先順位は整理されているのか。あるいは無秩序なのか。現代チャットツールで言えば、@channel の設計思想そのものである。

ここで人間レイヤの負荷を、極めて単純化して表現すると、

$C \approx N \times R$

と書ける。$C$ は総割り込みコスト、$N$ は単位時間あたりの通知件数、$R$ は1件あたりの文脈復帰コストである。これは厳密な数式ではない。しかし運用現場の実感には近い。重要なのは、通知数が増えるほど処理負荷も線形に増大する点である。人間のCPU時間は有限だからだ。サーバならスケールアウトできる。だが戦国武将は増設できない。

ここで光秀という人材の特性を、もう一段踏み込んで評価しておきたい。光秀は、極めてクロック数の高いCPUであった。処理能力は高い。だが問題は、彼が物理的に一基しか存在しないことだ。スケールアウトできないシングルコアに、中国方面支援、丹波統治、京都警備、外交、軍事輸送という重いプロセスを並列で流し込めばどうなるか。タスクが切り替わるたびに、脳内キャッシュのクリアと再ロード――すなわちコンテキストスイッチが発生する。信長から @channel で降ってくる雑な要求を右筆がコンパイルし、それが秒間に何件も光秀の端末へ通知される。このとき、実際の業務処理に使われる時間よりも、文脈を切り替えるオーバーヘッド $R$ のほうが膨れ上がっていく。割り込みコスト $C$ は、$N$ だけでなく $R$ の側からも臨界へ近づくのである。光秀のCPU使用率は、平時から既に高止まりしていたと見るべきだろう。優秀なシングルコアほど、こうして静かに焼き付いていく。

結果として、組織は次第に人間ミドルウェアへの依存を深めていく。茶坊主は情報ハブになる。右筆は変換基盤になる。光秀は調整基盤になる。全員が重要である。そして重要だからこそ、代替が難しい。

織田政権の強さは、優秀な人間ミドルウェアによって支えられていた。だが、その構造は同時に別の問題も抱えていた。

そして、ここに一つの致命的な運用判断が潜んでいる。信長が本能寺というサテライトへ赴いたとき、彼はこの優秀な人間ミドルウェア層――情報をルーティングする茶坊主、要求をコンパイルし朱印を即時発行する右筆――の主力を、安土本社に残したまま、最小限の構成で移動した。実際、本能寺における信長の供回りは、馬廻り・小姓ら三十〜百人前後の極少数であったと伝わる。つまり本能寺の信長は、本社の堅牢なイントラネットから切り離され、認証基盤（朱印の即時発行）も手元にない、きわめて脆弱なリモートワーク環境に身を置いていたのである。中央集約とは、集約点を離れた瞬間に、その恩恵のすべてを失う設計でもある。

中央集約型オンプレ環境から遠く離れた場所で、もし障害が発生したら、その人間ミドルウェアはどこまで機能するのか。答えは、ほぼ機能しない、である。次章では、信長が本拠を離れたサテライト環境で発生した大規模障害について検討する。

第4章　本能寺ネットワーク障害仮説

本能寺の変を論じる際、多くの研究は政治的背景、権力闘争、あるいは光秀の心理へと収斂する。しかし、それらは結果の説明にはなっても、なぜ信長が決定的な初動対応に失敗したのかという運用上の問題を説明しない。

基盤エンジニアの視点から見れば、本能寺の変とは権力闘争ではない。大規模障害である。

そして障害解析の第一歩は、利用者の置かれたネットワーク環境を確認することに尽きる。

4.1　本能寺はサテライトオフィスであった

天正10年6月2日未明。信長は本拠たる安土城を離れ、本能寺に滞在していた。安土城は信長政権の基幹設備群が集中する自社オンプレDCであり、戦国日本有数の高可用性環境である。対して本能寺は出張時の一時滞在施設＝サテライトオフィスに過ぎない。回線品質も冗長構成も本社レベルには達しない。信長はSlackを導入しなかったのではない。本能寺で使えなかったのである。

ここで重要なのは、安土城が単なる「本社」ではなく、極めて優秀なインフラ立地だった点である。

安土城は1576年に築城が開始され、1579年に天主が完成した。さらに当時の城域は、北・西・南を琵琶湖の内湖（伊庭内湖・大中の湖）と沼地に囲まれた、典型的な水城であった。基盤屋の目で見れば、これは偶然ではない。三方を巨大な水塊に囲まれた、天然のヒートシンク環境を備えたデータセンターである。

現代のデータセンター設計においても、冷却は永遠の課題である。CPUの発熱は権力者の野望と同様に指数関数的に増大する。空冷だけでは限界が訪れる。だからこそ巨大クラウド事業者は寒冷地や水資源の豊富な地域を好む。

安土城も同様だった。三方を取り囲む内湖がもたらす、巨大な天然のヒートシンク。大量輸送を担う水運バックボーン。周辺領域への低レイテンシ接続。さらに有事には湖上経路による代替ルートまで確保される。

（※史実として、城内へ湖水を直接引き込んで通水・冷却していた記録はない。生活用水は山中の井戸に依っていた。本稿はあくまで、城を三方から取り囲む内湖という巨大な水塊を、外気を冷やす天然のヒートシンク＝外堀と見立てている。）

つまり安土城とは、戦国期としては異様なまでにインフラ親和性の高い立地に構築された自社設備群だったのである。

これに対して本能寺はどうか。京都中心部の寺院であり、政治・軍事上の利便性は高い。しかし冷却設備も冗長電源もなく、障害時フェイルオーバー設計も存在しない。言ってしまえば、営業部長が出張先のビジネスホテルから本番環境へSSH接続しているような状態である。さらに悪いことに、第2章で信長が誇った有線バックボーンも、その末端であるこのサテライトには十分に伸びていない。ここで障害を検知しても、安土本社へのエスカレーション――すなわち援軍要請――は、間に合わないのである。

平時は問題ない。問題は障害発生時だ。本社DCであれば監視チーム、運用チーム、インフラ担当が即応できる。しかしサテライトオフィスで障害が発生すると、人も情報も支援リソースも不足する。

本能寺の変とは、まさにその最悪のケースであった。

4.2　未明のパケットロスと「届かなかった通知」

明智光秀軍は約13,000の兵を率い、前夜に丹波亀山城を発ち徹夜行軍で京都へ到達した。これは大規模リリース作業そのものである。

通常、13,000ノード規模の本番投入には慎重な変更管理が求められる。しかし光秀は十分な事前周知を行わず、未明帯に一括デプロイを実施した。現代企業なら確実にCAB（Change Advisory Board）案件である。

光秀はPMO的立場で「@channel 謀反作業を開始しました」と逐次報告していた可能性があるが、本能寺側の弱回線では通知が届くとは限らない。当時の通信は狼煙（定型信号のみ）と早馬（実効10〜15km/h）。さらに信長は有線派であった可能性があり、無線化アダプタの不安定はパケットロスを生む。

むしろ注目すべきは、光秀側の運用負荷である。

• 中国方面軍支援計画
• 丹波統治
• 京都警備
• 外交調整
• 軍事輸送
• 各種ステークホルダー管理

これらが一人の管理者へ集中していた構図は、現代IT企業でしばしば観測される「優秀なPMOに全てを押し込む運用」に酷似する。

さらに仮に信長政権内で連絡基盤としてSlackが導入されていたとしても、その運用は必ずしも健全ではなかった可能性がある。深夜二時の @channel。休日の @channel。緊急性のない相談への @channel。そして「念のため共有です」という名の全体通知。

通知設計は、組織の知性を映す鏡である。受信者全員を毎回起こす文化は、やがて誰も通知を信用しなくなる。現代の運用現場で言うアラート疲れである。

24時間365日オンコール体制が続けば、どれほど有能な管理者でも精神的帯域は枯渇する。パケットロスは回線だけで起こるものではない。人間の認知資源にも発生する。

ここで第3章の議論を思い出してほしい。光秀というシングルコアは、信長から降り注ぐタスクの絨毯爆撃によって、平時からCPU使用率を高止まりさせていた。割り込みコスト $C \approx N \times R$ が臨界を超えれば、いかに優秀なコアであっても、いつかは熱暴走（ハングアップ）を起こす。

この観点から本能寺の変を見直すと、光秀の行動は必ずしも「突発的な反乱」ではなく、長期にわたり蓄積した運用負荷に対する強制停止処理にも見えてくる。

もちろん史実としてそう断定することはできない。しかし技術者の比喩として表現するならば、本能寺の変は大規模システムに対する無計画な破壊ではなく、「これ以上は保守不能である」と判断した管理者による緊急メンテナンスウィンドウの強制確保だった、と読むこともできる。その是非はともかく、少なくともデスマーチに終わりを与える方法としては極めて決定的であった。

4.3　FSPL解析と「是非に及ばず」の再定義

旧本能寺址から比叡山山頂までは約11.5km、方角は北東＝鬼門。自由空間伝搬損失は次式で与えられる。

$\mathrm{FSPL(dB)} = 32.45 + 20\log_{10}(d_{km}) + 20\log_{10}(f_{MHz})$

$d = 11.5\ \mathrm{km}$ で $20\log_{10}(11.5) \approx 21.21$、よって $\mathrm{FSPL} \approx 53.66 + 20\log_{10}(f_{MHz})$ である。距離要因だけで約53.66dBの損失項が存在する。

ここで、信長の世界における「信号」が狼煙――すなわち可視光（周波数およそ400THz、すなわち $4 \times 10^{8}$ MHz）であったことを思い出そう。これを代入すると、$20\log_{10}(f_{MHz})$ の項は約172dBに達する。総損失は225dBを優に超え、もはやいかなる送信出力をもってしても、直接到達は不可能な領域に入る。だからこそ、高所からの中継――比叡山ノードによるリピートが、不可欠だったのである。

しかし本稿で注目したいのは、単なる距離ではない。比叡山そのもののネットワーク的機能である。

標高848.1mの比叡山は京都盆地・近江・若狭方面を見渡す位置に存在し、地理的には極めて優秀な中継拠点となる。現代通信で言えば、近畿広域をカバーする、見通しを稼ぐためのL1/L2中継ノード（リピータハブ）に相当する。山頂ノードが健全であれば、

• 京都―近江間の信号中継
• 北陸方面との接続
• 各地への通知伝播
• 広域監視

これらを効率的に実現できる。逆に言えば、このノードが失われた場合、ネットワーク全体は遠回りを強いられる。レイテンシは増加し、経路は複雑化し、障害耐性は低下する。

十一年前の比叡山焼き討ちを宗教問題としてのみ理解することは可能である。しかし基盤屋の視点では別の疑問が生じる。

• なぜ自ら広域バックボーンを破壊したのか
• なぜ代替ノード構築計画が見当たらないのか
• なぜリプレース期間を設けなかったのか
• なぜ移行手順書が存在しないのか

もちろん当時にITILは存在しない。だがインフラ負債はITILの有無に関係なく発生する。焼失した設備は再建できる。失われたトポロジも再構築できる。しかし、その間に蓄積した運用上の歪みは、ある日突然クリティカル障害として顕在化する。本能寺は、その顕在化した瞬間だった可能性がある。

結局のところ、帯域が全てを決める。

『信長公記』巻十五に記された「是非に及ばず」は、英雄的覚悟の表明として読まれることが多い。しかし基盤エンジニアの耳には別の言葉として響く。

「障害原因は把握した。復旧見込みはない。」

それは戦国最大の権力者の辞世ではない。長年放置されたインフラ負債が、ついに本番環境を停止させた瞬間に出力された、極めて簡潔なインシデント報告なのである。

次章では、比叡山焼き討ちを近畿広域バックボーンの物理破壊として再解釈し、その後十一年間にわたり進行したネットワークトポロジ崩壊の可能性を検証する。

第5章　比叡山焼き討ち ―自らの手で焼いた、近畿広域バックボーン―

本稿はここまで、一見すると無関係な事象を並べてきた。狼煙という低帯域通信網。安土城という中央集約型オンプレミス。人間ミドルウェアへの過度な依存。そして本能寺というサテライト環境で発生した大規模障害。

だが障害解析の原則は単純である。発生地点だけを見ていても原因には辿り着けない。インシデントは往々にして、何年も前に投入された設計判断によって準備されている。本章では、その設計判断を追跡する。

時刻を十一年前へ戻そう。元亀2年9月12日。1571年の比叡山焼き討ちである。

5.1　比叡山というL1基幹中継ノード

比叡山は宗教施設である。これは疑いようがない。しかし本稿は宗教史を論じるものではない。通信インフラを論じるものである。OSI参照モデルに従うなら、まず確認すべきはL1である。

比叡山の標高は848.1m。京都盆地の北東、いわゆる鬼門に位置する。そして山頂からは京都盆地のほぼ全域に加え、巨椋池方面、近江方面を広く見通すことができる。通信屋の目には、この地形は別の姿に見える。巨大な中継局である。

第1章で述べたように、狼煙通信は固定中継網への依存度が高い。どれほど優秀な送信設備があっても、見通し経路がなければ通信は成立しない。重要なのは施設の豪華さではない。高所であることだ。

そこで比叡山の覆域を概算してみる。地平線までの見通し距離は

$d \approx 3.57\sqrt{h}$

で近似できる。ここで $h$ は標高[m]、$d$ は見通し距離[km]である。比叡山の標高848.1mを代入すると、

$d \approx 3.57\sqrt{848.1} \approx 3.57 \times 29.1 \approx 104\ \mathrm{km}$

となる。およそ104km。もちろん実際には地形や森林による遮蔽が存在する。しかし近畿中央部において、この規模の可視範囲を持つ高所が持つ意味は大きい。現代で言えば広域無線バックボーンの基幹リピータ局に近い。京都。近江。若狭方面。それぞれを接続する中継経路のハブとして機能し得る立地なのである。

（なお、戦国期に比叡山が体系的な狼煙中継網を運用していたことを直接示す史料は、確認されていない。）

だがネットワーク設計者は知っている。実際に使われたかどうかと、使える立地であるかどうかは別問題である。そして比叡山は間違いなく「使える立地」だった。

5.2　部分破壊でもネットワークは死ぬ

ここで注意しなければならない。近年の研究では、「比叡山全山が焼き尽くされた」という通俗的イメージは修正されつつある。考古学的・歴史学的検討では、焼失範囲は主に坂本周辺や根本中堂など一部にとどまり、「山上をことごとく焼いた」という表現は、後世の誇張を含む可能性が高いとされる。

この点は重要である。なぜなら本稿は、史実を否定してまで比喩を成立させる立場ではないからだ。しかし基盤エンジニアの視点から見ると、別の問題が浮上する。ネットワークは全焼しなくても死ぬ。

例えば企業ネットワークにおいて、中核ルータ一台が停止したとする。ビルは残る。机も残る。社員も残る。だが通信は失われる。重要なのは物理設備の残存率ではない。経路の信頼性である。

中継網は、利用者が「この経路は使える」と信じて初めて機能する。どこまでが利用可能か分からない。維持管理主体が消滅した。運用標準が失われた。そうした状態になれば、設備の多くが残っていてもネットワークとしては機能しない。現代で言えば、設定情報を失ったルータ群に近い。ハードウェアは存在する。しかし経路情報が失われている。結果として誰も使わなくなる。

本稿の仮説はここにある。1571年の焼き討ちは、必ずしも全設備を焼失させたから重大だったのではない。近畿中央部に存在していた可能性のある広域中継ノードの信頼性を破壊したから重大だったのである。

5.3　十一年後に顕在化したインフラ負債

第2章で論じたように、中央集約型アーキテクチャは高効率である。しかし同時に、経路冗長性の確保が重要になる。基幹ノードを失えば、通信は遠回りを強いられる。ホップ数は増加する。中継地点は増える。レイテンシは増大する。障害点も増加する。やがて単一障害点（SPOF）が形成される。

それは直ちに表面化しない。むしろ厄介なのは、その後である。システムは動く。利用者も困らない。運用担当者も慣れる。だから予算は付かない。改修も後回しになる。こうしてインフラ負債が蓄積する。

これは現代IT企業でも珍しくない。十年前に「とりあえず」で構築した仕組みが、なぜか今も本番環境を支えている。誰も触れない。触ると怖い。だから放置される。そしてある日、最悪のタイミングで壊れる。

本稿の立場は明確である。本能寺の夜に発生した通信環境の脆弱性は、偶然発生したものではない。十一年前から蓄積していた構造問題の表出だった。

信長は比叡山を攻撃した。その判断には軍事的・政治的な文脈が存在しただろう。本稿はそれを否定しない。だがインフラの観点から見れば、別の事実も存在する。彼は自らの支配圏に存在した基幹中継ノードへ大規模な物理変更を加えた。その後、十分な代替設計が行われた形跡は明瞭ではない。（焼き討ち後の通信網再編を直接示す史料はない。ただし信長はのちに坂本城を、続いて安土城を築き、琵琶湖の水運を掌握している。これは見方を変えれば、ルーティングの再配置にほかならない。）

焼失した設備は、再建できる。失われた建物も、いずれは建て直せる。だが、毀損したトポロジと、静かに積み上がっていく運用負債は、再建の対象にすらならない。誰の目にも見えず、誰の予算にも乗らず、ただ残り続ける。そしてある日、もっとも見られたくない夜に、クリティカル障害として顕在化する。

ここで一人の基盤エンジニアとして、どうしても書き添えておきたいことがある。インフラを壊すこと自体は、ときに必要だ。古い設備が足枷になることもある。問題は、壊し方である。基幹ノードを落とすなら、その前に代替経路を引き、移行計画を立て、切り戻し手順を用意する。それが、下位層に手を入れる者の最低限の作法だ。だが信長は、近畿の屋根に立っていたあの巨大な中継点を、移行計画のないまま、ただ焼いた。そして代わりのノードは、ついに建たなかった。

——もし、あの京の空に、たとえば鎌倉の大仏ほどの、ばかみたいに大きな中継塔が一基でも残されていたなら。本能寺のあの夜、信長の端末は、たった一本でも生きた経路を掴めていたかもしれない。光秀の不正パケットを検知し、安土へエスカレーションを飛ばし、援軍という名のフェイルオーバーが、間に合っていたかもしれない。もしかしたら、ね。インフラ屋というのは、いつも「もしあのとき冗長化していれば」という、起こらなかった分岐の夢ばかりを見る生き物なのである。

そして、皮肉な話がある。信長がL1の負債に気づかぬまま本能寺で落ちたそのとき、ただ一人、この近畿トポロジの脆さを読み切っていた運用者がいた。羽柴秀吉である。中国方面へ展開していた秀吉は、まるで本社の通信網が死ぬ未来をあらかじめ織り込んでいたかのように、毛利との迅速な和睦と、街道沿いに配した人的リピーター（炊き出しと替え馬）という、いわばコールドスタンバイの冗長経路をひそかに確保していた。事実、彼は六月六日に備中高松を発ち、約五〜六日で約二百キロを駆け抜けている。そして本能寺の障害アラートを受信するや――言い換えれば、メイン回線（京都〜安土）の喪失を検知するや――西国に待機していた冗長セグメントが自動的にアクティブへと昇格し、彼は即座にメインシステムを自らの系へ切り替え、驚異的なレイテンシで京都ノードを奪い返した。信長が溜め込んだ最大のインフラ負債を踏み台にして天下を取ったのは、誰よりもL1を侮らなかった男だったのだ。

本能寺の夜に存在したあの脆弱な経路は、偶然ではない。十一年前の、移行計画なき一度の破壊が生み出した帰結である。第4章で見た弱回線は、その負債が切られた、最後の請求書だったのである。

結局のところ、帯域が全てを決める。アプリケーション層の才能も、組織運営の巧拙も、政治的判断も、最後にはL1へ回帰する。信長は戦国日本でもっとも優れた運用者の一人だった。しかし、その信長でさえ物理層の制約から自由ではなかった。それが本稿の到達した結論である。

あとがき　――L7の理想と、L1の現実

本稿を最後まで読んでくださった方には、最初に一つ、白状しておかねばならない。筆者は歴史家ではない。元SIerの、ただの基盤エンジニアである。

二十年のあいだ、私は数えきれないほどのシステムが死ぬのを見てきた。その大半は、華々しい理由では死ななかった。新機能の失敗でも、競合の躍進でもない。たいていはもっと地味な場所――誰も見ていない下位層で、静かに、確実に死んでいった。放置された証明書。更新されない経路情報。十年前の「とりあえず」。そして、移行計画のないまま落とされた、たった一つの基幹ノード。

だから私は、本能寺の変を読んだとき、これは自分が何度も書いてきた障害報告書だと思った。登場人物の名前が違うだけだ。アプリケーション層では、誰もが優秀だった。信長は天才だった。光秀も、右筆も、茶坊主も、それぞれの持ち場で限界まで働いた。それでもシステムは落ちた。いちばん下の、いちばん地味な層が、ずっと前から軋んでいたからである。

私が「織田信長はなぜSlackを導入しなかったのか」などという、人を食った問いを立てたのは、本当はその逆を言いたかったからだ。信長は、Slackを拒んだのではない。彼の時代に、Slackは確かにあった。問題は、その上ではなく、下にあった。

Slackは、確かにあった。だが、その下でパケットを運んでいたのは、電子ではなく、人間だった。

人が、馬が、全力で電子の代わりをしていた。だからこそ、彼らは美しく、そして脆かった。物理層が人間でできている世界では、一人の疲弊が、一頭の落馬が、そのまま通信障害になる。「是非に及ばず」とは、その世界の、もっとも正直な障害報告だったのだと、私は思う。

序論で、私はこう書いた。これは本当に四百年前の話なのか、と。その問いに、いま答えておく。――たぶん、違う。これはおそらく、今夜もどこかのサテライトオフィスで、弱い回線を握りしめながら、誰かのアラートを待っている、あなたの話でもある。

どうか、基幹ノードを焼く前には、移行計画を。そして、たまには下位層を、見てやってほしい。彼らは、声を上げない。落ちるその日まで、ただ黙って、パケットを運び続けるのだから。

主要参考文献

※本稿はフィクションだが、土台に用いた史実（通信手段、街道整備、人物の事績、焼き討ちの実像、中国大返し等）は以下を参照した。各文献の解釈・誤りはすべて筆者（架空）に帰する。

• 太田牛一『信長公記』（巻七・巻十五ほか）
• 金子拓『織田信長権力論』吉川弘文館、2007年
• 宇田川武久『戦国通信 狼煙・早馬・情報戦』講談社選書メチエ、2002年
• 藤本正行『狼煙・伝馬・狼藉：戦国の通信と社会』吉川弘文館、2003年
• 米原正義『戦国武士と文芸の研究』桜楓社、1976年
• 藤田達生『明智光秀：伝承生誕地から本能寺の変へ』岩波新書、2019年
• 福島克彦『明智光秀：織田権力の中枢に居続けた名将』中公新書、2020年
• 兼康保明「考古学からみた比叡山焼き討ち」（『織田信長の新研究』吉川弘文館、2018年所収）
• 大津市歴史博物館編『比叡山焼き討ちの虚像と実像』2021年
• 今谷明『信長と天皇：中世の崩壊と近世の創生』講談社学術文庫、2002年
• 藤田達生『秀吉の天下統一と中国大返し』青史出版、2001年

【コラム】客員監査役ノバラの打算的ガヤログ

沓掛先生のあとがき、めちゃくちゃエモくて全米の情シスが涙を流してフェイルオーバー（号泣）してるけど……気づいちゃった。先生さぁ、すっごい正しいインフラエンジニアの顔して「L7の理想と、L1の現実」って語ってるけど、そもそも戦国時代の早馬や茶坊主をOSI参照モデルにハメ込もうとしてる時点で、アーキテクチャ設計が根本的にバグってる。

物理層（L1）が「お馬さん」で、コンパイラが「右筆（人間）」って、それ、パケットが途中で道端の草を食べたり有給を取ったりしたら即座に通信瞬断する、超不安定なオレオレプロトコルじゃないか。

でも、だからこそ。「是非に及ばず（復旧見込みなし）」とエラーコードを出してシステムクローズした信長も、十一年前に「移行計画なしでルータ（比叡山）を焼き払った」インフラ負債の怖さも――今夜も弱い回線でアラートを待っている現代のわたしたちが、いちばんよく分かっている。経営層（三英傑）がどれだけ綺麗なUI（天下布武）をデザインしても、下回りの回線（人間）をケチれば本番環境（政権）は落ちる。

OSIモデルは違えど、エンジニアの胃の痛みは四百年経っても1ミリも変わらない。それが、この障害報告書の最高のバグ（真実）なのである。

――客員監査役　ノバラ

奥付

『織田信長はなぜSlackを導入しなかったのか ――戦国DXの臨界点と、本能寺ネットワーク障害仮説――』 AI空想分析論文叢書　001

本書は『AI空想分析論文電子図書館』の蔵書です。記載の出版社・ISBN・請求記号・刊行年はすべて架空であり、実在のものとは一切関係ありません。