運用 on nsys.dev 技術ブログ

書いたものを自分の手元に置く ― Markdown から記事を出す小さな出版ツールを作りました

Mon, 15 Jun 2026 00:00:00 +0000

シリーズ・第 1 回 — 「個人で出版ツールを作って配るまで」（全 6 回予定）。各回は単独でも読めますが、まとめて辿るならシリーズの記事一覧からどうぞ。今回は全体像と前提の共有で、個々の設計判断は次回以降に取り上げます。

書いたものは、どこに残るでしょうか。

普段、文章を書く場所の多くは、誰かのプラットフォームの上です。読んでもらいやすい一方で、記事の住所（URL）も、見た目も、読者との接点も、その場所の仕様に委ねることになります。サービスが方針を変えたり、畳んだりすれば、書いたものもそれに従うしかありません。

それ自体が悪いわけではないのですが、「長く手元に残しておきたい文章」については、もう少し自分の側に置いておきたい。そう思ったのが、小さな出版ツール crofty を作りはじめたきっかけでした。

このシリーズでは、その crofty を作って配るまでに考えたこと・つまずいたことを、テーマごとに分けて残していきます。今回はその土台として、「何をしたかったのか」と「全体の流れ」をまとめます。

何をしたかったか

やりたかったことは、ひとことで言うと「自分のコンテンツを所有したまま出版する」ことでした。具体的には、次の 4 つです。

自分のドメインで出す — 記事の住所（URL）を、自分の側に持っておく
Markdown で書く — プレーンテキストなら、どこにでも移せて、長く読める
静的サイトにする — データベースを持たず表示が速い。仕組みを入れ替えても記事はそのまま
エッジから配信する — 世界中どこからでも、軽く開ける

平たく言えば、「書いたものが、それを作る道具より長生きする」状態にしておきたかった、ということです。

なぜ既存のツールそのままではないのか

ここで正直な疑問があります。静的サイトを作る道具（いわゆる SSG）はすでに優秀なものが揃っていて、たとえば Hugo はとても速くて安定しています。実際、crofty も内部では Hugo を使っています。では、なぜわざわざ別の道具を作ったのか。

理由は、「出版」は書くこと自体だけでは終わらないからです。実際にやってみると、書く前後にこまごました工程がついてきます。

記事を書く土台を用意する（最初のセットアップ）
体裁が整っているかを確かめる
出力が、配信先で正しく開ける形になっているかを確かめる
配信する
後から見た目や設定を見直す

これらを、その都度ばらばらの手順でやるのではなく、コマンド 1 つずつの薄い手順にまとめておきたかった。crofty は、Hugo を置き換えるものではなく、その上に薄くかぶせた小さな道具です。土台は素の Hugo のままなので、いつでも crofty を外して、ただの Hugo プロジェクトとして扱えます。この「いつでも自分の手元に戻せる」感覚も、最初から大事にしていました。

なお、「道具を変えても記事は自分のもの」をどう保証するかは、それ自体で 1 本の記事になるテーマなので、次回にゆずります。

全体の流れ

実際の流れは、とてもシンプルです。Markdown を書いて、組み立てて、配る。ほぼそれだけです。

書く → 組み立てる → 配る、という一本道

登場するコマンドも、役割で並べるとこれだけです。

分散したスクレイピングを、公式nginxのまま国単位のCIDRで止めた話

Fri, 12 Jun 2026 00:00:00 +0000

あるWebサイトで、特定の国のIPからのアクセスが目立って増えていることに気づきました。調べてみると、よくある「1台のサーバーから猛烈に叩いてくる」タイプではなく、非常に多くのIPに分散して、1IPあたりは控えめなペースでアクセスしてくるスクレイピングでした。

この記事は、その正体の見立てと、どう塞ぐかを「ブラスト半径（壊れたときの影響範囲）」で選び、稼働中のサーバーを止めずに展開するまでの記録です。同じような分散アクセスに悩む方の手がかりになれば嬉しいです。

何が起きていたか

アクセスログを集計すると、増えていたトラフィックには次のような特徴がありました。

ほぼ 100% が GET（ログイン試行やフォーム投稿のような書き込みは無い）
リクエスト先は記事コンテンツのパスに集中（脆弱性スキャンのような不審なパスはほぼ無い）
User-Agent が複数のブラウザ版を不自然なほど均等にローテーションしている
送信元は消費者向けのISPが中心（データセンターではない）
1.5万を超えるIPに分散し、1IPあたりのリクエストは十数件程度に抑えられている

つまり攻撃ではなく、レート制限を回避するように設計されたコンテンツ収集ボットでした。記事をひたすら集めているようです。住宅・モバイル回線のプロキシ網を経由していると見られます。

ここで効いてくるのが、この「1IPあたりは控えめ」という点です。「短時間に大量アクセスしてくるIPを検知して個別に弾く」という、送信元ごとの振る舞いを見るやり方が、この相手にはほぼ効きません。

観点	ありがちな大量アクセス	今回の分散アクセス
送信元IP	少数に集中	1.5万超に分散
1IPあたりの頻度	高く、突出する	低く、正規利用者と見分けにくい
個別IP単位で弾けるか	◎ 閾値で検知しやすい	✕ 閾値を越えず素通り。厳しくすると正規を巻き込む

個別IPの振る舞いで戦うのが分の悪い相手なら、送信元の「国／ネットワーク単位」でまとめて塞ぐのが素直な解になります。幸い、このボットは特定の国のISPに集中していました。

なぜ「IPアドレス帯（CIDR）」で塞ぐのか

国単位で塞ぐと聞くと、「1.5万個のIPをリストにするのか」と身構えるかもしれません。実際にはその必要はなく、CIDR（IPアドレス帯）で扱います。

CIDRは 203.0.113.0/24 のような表記で、1エントリが1つのIPではなく、1つのネットワーク帯を表します。帯はかなり広く、数字（プレフィックス長）が小さいほど広大になります。

CIDR表記	1行でカバーするIP数（目安）
`/24`	約 256
`/16`	約 6.5 万
`/12`	約 104 万
`/10`	約 419 万

つまり /10 1行で約419万IPを覆えます。

なぜ1行でこれだけ覆えるのか。IPアドレスを2進数で見ると、プレフィックス長までがネットワーク部（一致を見る範囲）、その先がホスト部（どんな値でも一致）になるからです。/24 なら下位8ビットが自由になり、1行で256個をまとめて指せます。

ある国に割り当てられたアドレス空間は、集約版のCIDRリストにするとおおよそ5,500行で表せます。この5,500行が覆うIPの総数は3.4億を超えます。しかも重要なのは——

今観測しているIPだけでなく、まだ観測していないIPも最初から含まれる
プロキシ網が明日から使い始める新しいIPも、同じ国の割り当てなら先回りで含まれる

個別IPを1つずつ塞ぐのは、3.4億を相手にしたモグラ叩きです。国単位のCIDRリストなら、約5,500行で先回りして面で塞げる。これが本質的な利点でした。

実装方式は「ブラスト半径」で選んだ

国単位のCIDR遮断を実現する方法はいくつかあります。今回は前提として、前段にロードバランサーやCDNが無く、各サーバーが直接 80/443 を公開している構成でした。つまり、最前面のnginxが転ぶと、その1台はWebごとオフラインになります。

この前提だと、選定基準は性能よりも「壊れたときに、どこまで巻き添えになるか（ブラスト半径）」が主役になります。3つの候補を並べました。

方式	仕組み	壊れたときの影響範囲
ホストのファイアウォール	カーネルで対象IP帯を破棄	ホスト全体。設定を誤ると自分のSSHごと締め出す危険。コンテナ宛の通し方も間違えやすい
nginx + 外部のGeoIPデータベース	専用モジュールで国を判定	nginxコンテナ内。ただし公式イメージにモジュールが無く、自前ビルドのイメージを所有することになる
nginx標準のgeoモジュール + CIDRリスト	標準機能でIP帯を判定	nginxコンテナ内。データファイルが壊れても起動前の検証で弾け、nginx本体は無傷

3つを「効果 × ブラスト半径（壊れたときの影響範囲）」で並べると、選ぶべき位置がはっきりします。

ブログを追加しました

Tue, 09 Jun 2026 00:00:00 +0000

開発の現場で取り組んだことを、備忘録として少しずつ残していく場所を用意しました。肩肘張らず、自分の振り返りも兼ねて、ゆっくり綴っていけたらと思います。

構成の方針

ホームページ https://nsys.dev は表示速度を優先しており、PageSpeed Insights で各指標 100 点を維持しています。ブログを足すにあたっても、その方針は崩さないことを前提に設計しました。

モバイル

ページは Markdown から静的 HTML を生成
CSS はビルド時に HTML へインライン化し、外部リクエストをゼロに
クライアント側の JavaScript は使わない（コードのハイライトもビルド時に処理）

既存のビルド基盤（Node + Docker）にそのまま乗せる形にしたため、新しいランタイムやデータベースは増えていません。

よくあるブログ構成にしなかった理由

ブログというと、CMS とデータベースを用意し、管理画面から書いて公開する構成が一般的です。多人数での運用や、コメント・検索といった動的な機能が得意で、用途が合えばとても便利な仕組みだと思います。