しなないサイトのつくりかた：ゼロロジック、ゼロインフラ宣言

やあ、深夜に php2shell や WebShell アップロードの緊急脆弱性対応で叩き起こされ、涙目で WAF ルールを書きながら栄養ドリンクを流し込んだインフラエンジニア諸君、息災だろうか（笑）。

ここ最近、世間を激震させた「Php2shell」騒動はすごかった。 Web 黎明期から世界を支え続けてきたあの PHP に潜む深刻な実行バイパスの穴を突かれ、官公庁から大手企業までがパニックに陥り、ついには日本国の国家元首（首相）が臨時記者会見で異例の注意喚起声明を出すという歴史的大騒動に発展した。

その夜のことだ。普段はITの「あ」の字にも縁がない非テック系の知人から、突然こんな連絡が飛んできたのだ。

「ねえ、ニュースでなんかヤバいサイバー攻撃の事件やっててさ……。お前パソコン詳しいから知ってるかなと思って聞くんだけど、そのニュースで言ってた『PHP』って、一体なんなの？」

思わず苦笑してしまった。 世界のWebサイトの実に7割以上を黙って支え続けている、古き良き偉大なプログラミング言語のことだ。「なんかサイバー攻撃に関係する危険なモノらしいぞ？」という漠然とした恐怖とともに、一般人の口から「PHPってなあに？」と尋ねられる異常事態。長年のサーバー屋として、何とも言えない感慨を覚えていた。

……そして、まさにその騒乱の真っ只中。 我らが砧製作所（https://kinuta.dev/）の Cloudflare Analytics ダッシュボードを開いた私は、思わず二度見した。

コロンビア（Colombia）から、9,140 リクエスト。

一瞬、「砧製作所が南米コロンビアのテックギークたちの間でバズったのか？」「ついに南米の町工場から案件打診が来たか？」と色めき立った。 だが、詳細ログを覗いてすぐに乾いた笑いが漏れた。

アクセス元は、コロンビア・バランキージャ市の単一IPアドレス（152.202.232.217）。 新設されたばかりの .dev ドメインの噂を聞きつけた海外の自動脆弱性スキャナーボットが、未明から夜明けにかけて、一心不乱に以下のようなURLを絨毯爆撃していたのだ。

見事なまでの Php2shell・WordPress 探索スクリプトである。 自動化されたボットは、我がサイトが血眼になって探している獲物（脆弱な PHP サーバー）だと信じて疑わず、9,000回以上の怒涛の連打を浴びせかけていた。

だが、結論から言おう。 この9,140回の猛攻の最中、我がサイトのオリジンサーバーのCPU使用率は「完全な0.00%」。 ロードアベレージはピクリとも動かず、私は煎餅をポリポリかじりながら、布団の中でぬくぬくと快眠を貪っていた。

なぜか？ そもそも落とすべきサーバーも、侵入される PHP も、最初からどこにも存在しないからだ。

2. 要塞に爪楊枝：攻撃対象領域（Attack Surface）ゼロの構造

ボットがどれほど情熱的に /wp-login.php を連打しようと、我がサイトが動いているのは Cloudflare Pages の静的ホスティング基盤である。

ディスク上にあるのは、純粋な HTML、CSS、JavaScript、そして画像ファイルだけ。 Apache も Nginx も起動していない。Node.js のランタイムもなければ、Docker コンテナも立っていない。バックエンドの MySQL や PostgreSQL なんて1ミリも接続されていない。もちろん、世間を騒がせている PHP のインタプリタなど影も形もない。

ボットから放たれたリクエストは、オリジンサーバーに届くどころか、南米に最も近い Cloudflare のエッジデータセンター（ボゴタやマイアミ）で即座に受け止められ、キャッシュレイヤーから「404 Not Found」を数ミリ秒で機械的に投げ返されて終わりだ。

セキュリティ業界では「攻撃対象領域（アタックサーフェス）を最小化せよ」と口酸っぱく言われる。 だが、アタックサーフェスを縮小する究極の手段は、ファイアウォールを何重にも重ねることでも、高価な WAF 機器を買い揃えることでもない。

「攻撃対象となる実行環境（動的言語・OS・DB）そのものを、物理的にこの世から消滅させること」。

要塞の扉を頑丈にするのではなく、最初から「攻め込むべき城が存在しない平原」を作っておく。これ以上のセキュリティ対策がこの世にあるだろうか？

3. 「SSRは流行りですからねえ」：一周回ってたどり着いたエンジニアの桃源郷

ここ数年、フロントエンド界隈では「SSR（サーバーサイドレンダリング）」「React Server Components（RSC）」「Edge Rendering」といった華々しい技術がもてはやされてきた。

もちろん、リアルタイムにパーソナライズされた大規模ECサイトやSNSであれば、動的なレンダリング基盤は必須だ。 だが、世の中のコーポレートサイト、技術ブログ、ドキュメントサイト、LPの9割に、果たして毎秒Node.jsサーバーをブン回してDBから記事データをフェッチする理由がどこにあるのか？

「モダンだから」という理由だけで不用意に SSR やフルスタックフレームワークを採用した結果、何が起きるか。

• 深夜の死活監視アラート: Node.js のメモリリークでポッドが不意に再起動する。
• DBコネクション枯渇: SNSでちょっとバズっただけで、データベースの最大接続数に達して「500 Internal Server Error」を吐いて即死する。
• パッチ適用の賽の河原: フレームワークやライブラリの依存関係（npm audit）に毎週のように脆弱性警告が付き、バージョンアップ対応で週末が潰れる。
• 無駄なクラウド請求: 誰も見ていない深夜帯も、落ちないように冗長化されたコンテナとマネージドDBの基本料金が数万円単位で課金され続ける。

私はかつて、オンプレミスの物理ラックに顔を突っ込み、熱風を浴びながら SCSI ケーブルを締め、深夜のカーネルパニックに震えながら Linux の再コンパイルを繰り返してきた骨の髄からのインフラ屋だ。

その私が今、声を大にして言いたい。

「一周回って、静的HTML（Jamstack / SSG）こそが、Webエンジニアが最後に辿り着く究極の桃源郷である」と。

Markdown で原稿を書き、Git に push する。 すると GitHub Actions が走り、数秒で静的な HTML がビルドされ、Cloudflare のエッジストレージへと配置される。 手元の軽快さは90年代のテキストエディタ手書き時代そのままに、配信基盤だけが世界最強のエッジCDNと直結している。

この圧倒的なシンプルさと強靱さに勝るアーキテクチャが、他にあるだろうか。

4. なぜ我々は堂々と [email protected] を晒せるのか？ —— メールサーバーすら持たない美学

当サイトのフッターやお問合せ窓口を見た何人かのベテランエンジニアから、「お前、正気か？」と聞かれたことがある。

なぜなら、コンタクト先として堂々と [email protected] という、いかにも世界中のスパムクローラーや総当たり辞書攻撃の格好の標的になりそうなアドレスを記載しているからだ。

昔気質のインフラ屋なら、寒気を感じるはずだ。 かつて我々は、メールサーバー（Sendmail / Postfix / Qmail / Dovecot）の運用で文字通り生き血を削ってきた。

ポート25番の開放に怯え、オープンリレーになっていないか夜中に何度もコマンドを叩き、DNSの逆引きレコード（PTR）を揃え、SPF・DKIM・DMARC の呪文のようなTXTレコードを検証し、Spamhaus や Spamcop のブラックリストにIPが載ってしまった日は血の涙を流しながら解除申請を送る……。

さらに忘れもしない、痛恨の記憶：Gmail の POP3 取り込み終了事件。 Gmail が完全招待制だったベータ版時代から20年近く愛用してきた古参の私ですら、あの仕様変更の煽りを食らい、クリスマスイブから冬休み明けにかけて寝ず食わずでメール移行対策に奔走した。あんなに愛した相手（Google）に年末進行で裏切られ、極寒の部屋でログを見つめた悲哀は、今でも昨日のことのように思い出せる。

そんな酸いも甘いも噛み分けた私が、なぜ平然と [email protected] を晒せるのか？

理由は極めて明快である。メールサーバーすら、我が工房には存在しないからだ。

当ドメインのメールは、Cloudflare Email Routing をポチッと数クリック有効化しているだけだ。 キャッチオール（*@kinuta.dev）で受けて、普段使っている個人 Gmail へ無料・ノータイムで安全に転送させている。

スパムや不正なリレーは、Cloudflare の広大なエッジが水際で勝手に握りつぶしてくれる。 我々が管理すべきメールスプールもなければ、あふれて死ぬディスク容量もない。 「クラウドフレアさまさま」が生み出した、究極のノーメンテナンス・コミュニケーション窓口なのだ。

5. 悲報：頑丈すぎて公式マスコット「きぬたたぬき」の出番が一生来ない

さて、そんな「死なないサイト」を構築してしまった我々だが、実は社内で密かに深刻な問題を抱えている。

Twitter（現X）の「クジラ（Fail Whale）」、Amazonの「看板犬（Dogs of Amazon）」、あるいは はてな の「しなもん」。 名だたるテックサービスには、障害時にユーザーの怒りを鎮め、逆に愛着を生み出す愛らしい「500エラー用マスコット」が存在する。

我々もその伝統にあやかり、500番台エラー画面のために工房の公式マスコットを考案した。 その名も、「きぬたたぬき」。

……だが、哀しいかな。 この「きぬたたぬき」の出番は、サイトが開設されて以来、ただの1秒たりとも訪れていない。

当たり前だ。Cloudflare Pages は 500 番台エラーなんて吐きようがないのだ。

• PHP がないから、500 Internal Server Error が出ない。
• Node.js がないから、502 Bad Gateway が出ない。
• オリジンサーバーがないから、504 Gateway Timeout も出ない。

結果として、丹精込めて生み出された「きぬたたぬき」は、エラー画面の出番を一生奪われたまま、オフィスの片隅で静かにメロンパンをかじるだけのニートキャラと化している。 インフラが頑丈すぎるのも、時に罪深いことである。

6. もし巨大クラウドが消滅したら？ CTOオカダが抱く「唯一の危機感」

ここまで「絶対に死なない」と豪語してきたが、工学に絶対はない。 私が現時点で想定している、我がサイトが死ぬ唯一のシナリオを明かそう。

「Microsoft（GitHub）と Cloudflare と Oracle（OCI Always Free）が、明日同時に地球上から消滅したら、さすがに我がサイトは死ぬ。」

もしそのレベルの事態が起きたとしたら、それは巨大隕石が激突したか、第三次世界大戦で海底ケーブルが全滅したか、太陽フレアで全電子機器が蒸発した時だ。 その時は私のサイトの生存など誰も気にしていないだろうから、潔く諦めがつく。

……というのは大真面目な冗談として、万が一の事態に対する「縮退設計」も抜かりはない。

手元のローカルPCとGoogleドライブには完全な Git リポジトリが同期されており、万一 Cloudflare が死んだとしても、GCP（Cloud Storage）や、我らが愛するさくらインターネット（石狩データセンター）のオブジェクトストレージへ、DNSのCNAMEレコードを書き換えるだけで数分以内に全サイトを別エッジで再興できる。

巨大な巨人の肩に乗っかりつつも、手綱だけは決して手放さない。 これこそが、大人のインフラ設計というものだ。

7. 結び：引き算の美学 —— 禅の境地「不生不滅」のインフラ論

仏教・禅の教義に、「不生不滅（ふしょうふめつ）」という言葉がある。 「本来、生じることもなければ、滅することもない」 という真理を説いたものだ。

現代のインフラエンジニアリングは、あまりにも「足し算」に偏りすぎているように見える。 マイクロサービス、サービスメッシュ、Kubernetes、分散トレーシング……複雑な課題を解決するために、さらに複雑なソフトウェアを何層にも積み上げ、結果として自分自身がその複雑さの炎に巻かれて深夜に悲鳴を上げる。

だが、日本の伝統工芸や枯山水（かれさんすい）を見てほしい。 水を一切使わずに、白砂と石の配置だけで大海原や宇宙を表現する引き算の美学。

インフラも同じだ。 サーバーを生み出さないからこそ、サーバー死も存在しない。 動的なプログラムを動かさないからこそ、Php2shell に怯える夜も訪れない。

余計なものを極限まで削ぎ落とし、純度の高い本質（HTMLとエッジ配信）だけを研ぎ澄ます。 AI駆動開発（AIDD）という最新のテクノロジーを手にした今だからこそ、我々は足し算の熱狂から一歩身を引き、「引き算のインフラ」の涼しさを味わうべきなのだ。

今夜もどこかのサーバーが Php2shell の砲火に晒されているかもしれない。 だが、我がサイトは今夜も、世界300都市のエッジの片隅で、涼しい顔をして静かに息づいている。