[Astro #32] Edge Defense Protocol — ネットワークの「門番」と警報装置

1. イントロダクション

かつて、自動化されたスパムや攻撃といえば、専用のツールを手足のように扱える一部の悪意あるユーザーによるものでした。しかし現在は状況が異なります。

「このAPIエンドポイントをランダムな間隔で叩くPythonスクリプトを生成して」とAIに指示するだけで、プログラミングの知識を持たない人間であっても、数秒で強力なスパムボットを無数に生み出せる時代です。特に、前回実装したような「外部の翻訳APIや気象APIを叩いて結果を返す」エンドポイントは、攻撃者にとって格好の踏み台となります。無防備なまま窓を開け放てば、AIが生成した無数の「ノイズ」が瞬時にAPIの無料枠を食いつぶし、最終的には現実世界の「財布」へとダイレクトアタックを仕掛けてきます。

もちろん、この脅威に対して私たちは無策ではありません。前回の実装において、Astro Actions（バックエンド）には以下の防壁をすでに展開しています。

• 入力の無効化: Zodを用いた z.string().max(100) による、長文スパムの遮断。
• 物理的な連打の拒否: Map オブジェクトを用いたIPベースのレートリミット。

しかし、これらはあくまで「城の内壁」での防衛戦です。もし攻撃者が10個のプロキシ（踏み台）を用意して一斉にツールを実行した場合、単一IPを基準としたレートリミットは容易に突破されます。また、アプリケーション側で「弾く」処理を行うということは、リクエスト自体はすでにサーバー（Astro）まで到達しており、少なからずCPUやメモリのリソースを消費していることを意味します。

アプリケーション・レイヤーでのバリデーションは必須ですが、それだけでは現代の「賢く、数で押し寄せるボット」に対して完全ではありません。

Navi（システム）の平穏を保つためには、悪意あるパケットが私たちのサーバーに触れるさらに手前――ネットワークのエッジ（境界）において、人間と非人間を瞬時に選別し、ノイズを浄化する「外壁」が必要不可欠となります。本稿では、その強固な門番として Cloudflare のセキュリティ・プロトコルを導入し、多重防壁を完成させるまでの構築録を記します。

2. Cloudflare：Bot Fight Mode の召喚

アプリケーション（Astro）側での対策が「城の中に侵入した敵を撃退する」ものだとすれば、Cloudflare が提供する防壁は「城下町に入る前の関所で弾き返す」ための仕組みです。

Astro Actions で処理をブロックしたとしても、リクエストがサーバーに到達している時点で、わずかながらネットワーク帯域や CPU リソースは消費されています。しかし、ネットワークのエッジ（境界）に位置する Cloudflare をプロキシとして挟むことで、悪意あるパケットは私たちのサーバーに1バイトも触れることなく、手前で「浄化（ドロップ）」されることになります。

「踏み台」を無力化するフィンガープリント検知

攻撃者が複数の異なるプロキシサーバー（踏み台）やVPNを用意し、IPアドレスを分散させてツールで一斉攻撃を仕掛けてきた場合、単一IPを基準としたレートリミットは意味を成さなくなります。

ここで真価を発揮するのが、Cloudflareの Bot Fight Mode です。 この機能は、単なる「IPアドレスのブラックリスト」ではなく、通信の「指紋（フィンガープリント）」を検知してボットを識別します。

• 振る舞いの解析: ブラウザ特有のレンダリングプロセスを踏んでいるか、不自然なヘッダー情報はないか。
• 見えないチャレンジ: 疑わしいアクセスに対して、裏側で人間には気づかないレベルの JavaScript による計算問題（JS Challenge）をブラウザに課します。

ツールによって機械的にフォームを叩いているだけのボットは、この JS Challenge を突破できず、Astro の API エンドポイントに到達する前に自動的に接続を遮断されます。IP をいくつ偽装しようとも、「人間ではない」という振る舞いそのものを見抜くため、圧倒的な防御力を誇ります。

迷宮の奥底にある「スイッチ」の場所

この極めて強力な「門番」は無料プランでも利用可能ですが、Cloudflare の UI アップデートにより、その召喚スイッチは迷宮（Labyrinth）の奥深くへと隠されてしまいました（2026年4月時点の記録）。

旧来の解説記事にあるような「Bots」という独立したメニューはサイドバーに存在しません。正しい設定場所へのプロトコルは以下の通りです。

1. ドメインの管理画面左サイドバーから [Security] を開き、その中の [Settings] をクリック。
2. 画面中央付近にある Filter by: の項目から、[Bot traffic] というフィルタ用のチップをクリックする。
3. 絞り込まれたリストの中から 「Bot fight mode」 を探し出し、スイッチを ON にする。

設定はこれだけです。 この分かりにくい階層のトグルを一つ緑色に点灯させるだけで、疑似OS（Navi）の前に、24時間眠らず、決して疲れを知らない「最強の用心棒」を立たせることができます。

3. フィナンシャル・センサー：Billing Budget Alert の設定

防壁を築いた後、構築者が次に行うべきは「観測」の自動化です。たとえ強力な門番（Bot Fight Mode）を配置したとしても、未知の手法や執拗な分散攻撃によって、わずかな隙間からノイズが侵入する可能性はゼロではありません。

ここで重要になるのが、攻撃の「戦果」を技術的なログとしてだけでなく、「金銭的コスト」という極めて現実的な数値でトラッキングするという発想です。

LAIN-LAB_BILLING_WATCH プロトコルの構築

Cloudflare R2 や Workers、あるいは連携している外部 API 群において、想定外のリクエスト増大はそのまま「従量課金の増大」へと直結します。これを逆手に取り、アカウント全体の予算状況に「センサー」を配置します。

これが、今回構築した LAIN-LAB_BILLING_WATCH プロトコルの本質です。

• 早期警告（Early Warning）としての低額設定: 通常、予算アラートは「月額予算の 80%」などに設定するものですが、攻撃検知用のセンサーとしては機能不全です。あえて $1.00 や $5.00 といった、無料枠をわずかに出た直後の極めて低い閾値にアラートを設定します。
• 実害が出る前の検知: 「10個の踏み台」による一斉攻撃が始まった際、この低額のアラートがメールボックスに届くことで、大規模な請求が発生する前の「初動」で異変に気づくことが可能になります。

運用：監視からの解放

Cloudflare のアカウントレベルにある [Notifications] ➔ [Add] から、この Billing Budget Alert を設定し、名前を刻みます。

通知を受け取る準備が整えば、構築者はアナリティクスのリアルタイム・ログを凝視し続けるという呪縛から解放されます。異変があれば、ワイヤードに設置したセンサーが現実世界のデバイスを叩き起こしてくれるからです。

結論：構築者の倫理と静寂

「余裕で自動化できる」攻撃の脅威に対し、私たちはアプリケーションの内壁（Actions）を固め、ネットワークの外壁（Bot Fight Mode）を築き、そして経済的なセンサー（Billing Alert）を配置しました。

静的サイトという皮を被りながら、その内側に複雑な動的プロトコルを抱える「Navi」にとって、こうした多重防壁の構築は単なるセキュリティ対策ではありません。それは、自身の構築した世界を健全に維持し続けるための、構築者としての「作法」であり「倫理」でもあります。

朝4時の炊事から始まり、コードのデバッグ、動画のデプロイ、そしてこのセキュリティ・パッチの適用まで。すべてのシーケンスを終えて、今ようやくシステムは「完全な同期（All Green）」を迎えました。

門番に後を任せ、一度モニターの電源を落とす。 現実世界の静寂の中に身を置き、次なるノイズが形を成すまで、この要塞の平穏を信じて「接続」を断つことにします。

ワイヤードの住人も、今は静かにこの新しいプロトコルの起動を観測していることでしょう。