無料でTLS証明書を発行できるLet's Encrypt。でも本当に画期的だったのは「無料」ではなく、ACMEプロトコルによる自動更新だった——そんな話から始まる今回は、証明書運用の知られざる世界をcatatsuyがたっぷり語ります。

前半は、ドメインの所有をどう証明するかという「ACMEチャレンジ」の話。定番のHTTP-01、catatsuyが愛用するDNS-01、TLS終端リバースプロキシや大規模ホスティング事業者向けのTLS-ALPN-01という3方式の使い分けから、Certbot・dehydrated・legoといったクライアントの乗り換え遍歴、Route 53と組み合わせたDNS-01運用のノウハウまでを深掘りします。中盤では、Cloudflare DNSがダッシュボードに表示されないCAAレコードを自動追加していたという話と、そこから始めたCTログ監視の話も飛び出します。

後半は、証明書の有効期限が45日に短縮される規定路線を見据えた「プロファイル」の解説から、有効期限わずか6日のshortlived証明書を自宅サーバーで実運用してみた体験談へ。レートリミットとの戦い、ARIによる更新タイミングの調整とレート制限回避、常にクリティカルになってしま監視アラート、通知があふれて機能しなくなるCTログ監視……最先端を走ると何が起きるのか、実際に運用したからこそ見えた学びが満載です。証明書を「ポチポチ手作業」で更新している人、これから自動化を考えるインフラエンジニアにこそ聞いてほしい回です。

- Let's Encrypt: https://letsencrypt.org/

- ACMEプロトコル (RFC 8555): https://datatracker.ietf.org/doc/html/rfc8555

- Let's Encrypt 証明書プロファイル: https://letsencrypt.org/docs/profiles/

- ARI — ACME Renewal Information (RFC 9773): https://datatracker.ietf.org/doc/html/rfc9773

- CAAレコード (RFC 8659): https://datatracker.ietf.org/doc/html/rfc8659

- Certbot: https://certbot.eff.org/

- dehydrated: https://github.com/dehydrated-io/dehydrated

- lego: https://go-acme.github.io/lego/

- Certificate Transparency: https://certificate.transparency.dev/

- Amazon Route 53: https://aws.amazon.com/route53/

- Cloudflare: https://www.cloudflare.com/

- nginx: https://nginx.org/

- New Relic: https://newrelic.com/

─────────────

YouTube: https://youtu.be/7FQ_5ukYkqw

Web: https://yaoyorozu-oss.henteko07.com/

X: https://x.com/yaoyorozu_oss

Meetの録画じゃダメなの？——ダメなんです。音質の劣化、そして何より話者ごとにトラックを分離できないから。

今回はhentekoが「八百万のOSS」を支える自作ツール群を解説します。ブラウザだけで収録できる「Maycast Room」、非破壊編集にこだわったmacOSアプリ「Maycast Studio」、Apple公式SpeechAnalyzerとDeepgramの使い分け、50分の音源が10秒で文字起こしされる衝撃、Remotion製の予告編動画の作り方。失敗して捨てたハイライト抽出ツールが予告編のアイデアに繋がった話も必聴です。

自分でもポッドキャストをやってみたい人への実践的なヒントが詰まった回です。

- MayCast Studio (henteko): https://github.com/henteko/maycast-studio

- deepgram-cli (henteko): https://github.com/henteko/deepgram-cli

- Cloudflare: https://www.cloudflare.com/

- Cloudflare R2: https://developers.cloudflare.com/r2/

- Mediabunny: https://mediabunny.dev/

- Auphonic: https://auphonic.com/

- Deepgram: https://deepgram.com/

- Remotion: https://www.remotion.dev/

- FFmpeg: https://ffmpeg.org/

- Apple SpeechAnalyzer: https://developer.apple.com/documentation/speech/speechanalyzer

- Google Gemini API: https://ai.google.dev/

- Claude Code: https://claude.com/claude-code

- Logic Pro: https://www.apple.com/logic-pro/

- VLC media player: https://www.videolan.org/vlc/

- Pocket Casts: https://pocketcasts.com/

─────────────

YouTube: https://youtu.be/7WsDmAzB-r4

Web: https://yaoyorozu-oss.henteko07.com/

X: https://x.com/yaoyorozu_oss

HTTP/2とHTTP/3は、Webを速く、安定して使うために出てきたプロトコルです。ただし「HTTP/3はHTTP/2より常に速い」という単純な話ではありません。

今回は、HTTP/1.1で同じホストに複数TCP接続を張っていた時代から、SPDYを経てHTTP/2が生まれ、HTTP/3では何が変わったのかまでを整理します。

HTTP/2は、1本のTCP接続で複数のリクエスト・レスポンスをストリームとして多重化し、HTTP/1.1にあったHTTPレイヤーのHead-of-Line Blockingを改善しました。HPACKによるヘッダー圧縮、ALPNによる`h2`と`http/1.1`の切り替え、仕様上は平文の`h2c`もあるがブラウザ向けWebでは実質HTTPS前提になっていること、nginxでは現在`http2 on;`で有効化することも扱います。

一方でHTTP/2はTCPの上で動くため、TCP由来のHead-of-Line Blockingは残ります。パケットロスが起きると、1本のTCP接続に多重化された複数ストリームがまとめて影響を受けることがあります。HTTP/3はUDPを使うことで、このTCP由来の問題を避けやすくしようとしたプロトコルです。

ただしHTTP/3は完全上位互換ではありません。安定した低遅延・低ロス環境ではHTTP/2と大差ないこともあり、データセンター間通信のような安定したネットワークでは通常HTTP/3は使いません。効きやすいのは、モバイル回線、海外通信、高RTT、パケットロスのあるような不安定なエンドユーザー回線です。

導入面では、HTTP/3はHTTP/2のように同じTCP接続上で自然に切り替わるわけではなく、`Alt-Svc: h3=":443"`やHTTPS RRで「このオリジンはHTTP/3も使える」と知らせます。失敗すればHTTP/2やHTTP/1.1にフォールバックするため、実運用では共存が前提です。

nginxでのHTTP/2はかなり実用上枯れてきており、ブラウザ向けHTTPSでは有効化しやすい選択肢です。一方でHTTP/3はアプリケーション側で実装・制御する範囲が大きく、自前で扱うのは大変です。現実的にはCDN側でHTTP/3を有効化し、CDN-Origin間やデータセンター間通信はHTTP/1.1やHTTP/2のままにする構成が普通です。

OSS、ブラウザ、サーバー、CDN、標準化が絡み合ってHTTPが進化してきた話として、HTTP/2とHTTP/3の違いを見ていきます。

- HTTP/2 (RFC 9113): https://www.rfc-editor.org/rfc/rfc9113

- HTTP/3 (RFC 9114): https://www.rfc-editor.org/rfc/rfc9114

- HPACK / HTTP/2ヘッダー圧縮 (RFC 7541): https://www.rfc-editor.org/rfc/rfc7541

- TLS 1.3 (RFC 8446): https://www.rfc-editor.org/rfc/rfc8446

- ALPN (RFC 7301): https://www.rfc-editor.org/rfc/rfc7301

- Alt-Svc ヘッダー (RFC 7838): https://www.rfc-editor.org/rfc/rfc7838

- SVCB / HTTPSリソースレコード (RFC 9460): https://www.rfc-editor.org/rfc/rfc9460

- SPDY (Chromium): https://www.chromium.org/spdy/

- nginx: https://nginx.org/

- nginx HTTP/2 module: https://nginx.org/en/docs/http/ngx_http_v2_module.html

- curl: https://curl.se/

- nghttp2: https://nghttp2.org/

- OpenSSL: https://www.openssl.org/

- Next.js: https://nextjs.org/

- webpack: https://webpack.js.org/

- jQuery: https://jquery.com/

- Cloudflare: https://www.cloudflare.com/

- さくらのVPS: https://vps.sakura.ad.jp/

- AWS: https://aws.amazon.com/

─────────────

YouTube: https://youtu.be/pOth4rhg3M8

Web: https://yaoyorozu-oss.henteko07.com/

X: https://x.com/yaoyorozu_oss

キャッシュサーバmemcachedをGoで再実装したcatatsuy。

「マップに入れて返すだけでしょ」と思いきや、メモリを使い切る前にデータを捨てるeviction、最近使われていないデータを管理するLRU、そして素直なLRU実装では「GETがhitしてもリスト更新が走る」という落とし穴がありました。

read-heavyなキャッシュなのに、GETが書き込みに近い処理になる。この自作版ではLRUがボトルネックになり、コード上は1コアしか使わない実装になっていました。自作してみると、mapで返すだけでは終わらない、LRUとロックの難しさが見えてきます。

本家memcachedはHOT / WARM / COLD / TEMPのような世代分けを持ち、GETのたびに毎回LRU順位を真面目に更新するのではなく、active bit、async bump、LRU maintainerなどでリスト更新を分散・近似しています。LRUを真面目にやりすぎるとロックが増えるから、あえて真面目にやらない。その工夫があるからこそ、本家memcachedは複数CPUのある環境でもスケールしやすい。

hentekoと一緒に、プロトコルの単純さと内部実装の難しさのギャップを覗いていきます。

- utsuro: https://github.com/catatsuy/utsuro

- memcached: https://github.com/memcached/memcached

- memcached - a distributed memory object caching system https://memcached.org/blog/modern-lru/

- Redis: https://redis.io/

- OpenAI Codex: https://github.com/openai/codex

- Go: https://go.dev/

─────────────

YouTube: https://youtu.be/KzZSzbZF5ik

Web: https://yaoyorozu-oss.henteko07.com/

X: https://x.com/yaoyorozu_oss

nginxは「速いWebサーバー」というより、Webアプリケーションの前段でクライアントとの通信を受け持つ定番OSSです。

遅いクライアント、大量接続、静的ファイル配信、gzip圧縮、バッファリング、キャッシュをnginxに任せることで、アプリケーションサーバーは本来の処理に集中できます。

今回は、C10K問題、イベント駆動、ノンブロッキングI/Oといったnginxの基本的な考え方から、静的ファイル配信、gzip、upstream keepalive、古いコピペ設定が変わりつつある話までを取り上げました。

「とりあえずnginxを置く」と言われがちな理由を、設定例の暗記ではなく、Webアプリケーションを楽にするための役割分担として整理していきます。

EnvoyやPingoraとの違い、Cloudflareで使われてきた実績、そして「全部入り」はUnix哲学に反するのか、という話も取り上げています。

nginxをなんとなく使っている人にも、設定の意味を改めて整理したい人にも楽しめる回です。

- nginx: https://nginx.org/

- freenginx: https://freenginx.org/

- NGINX Plus（エンタープライズ版）: https://www.f5.com/products/nginx/nginx-plus

- Envoy: https://www.envoyproxy.io/

- Pingora（Cloudflareのプロキシ実装）: https://github.com/cloudflare/pingora

- H2O（Fastlyで使われるHTTPサーバー）: https://github.com/h2o/h2o

- PHP: https://www.php.net/

- Node.js: https://nodejs.org/

- AWS ALB（Application Load Balancer）: https://aws.amazon.com/elasticloadbalancing/application-load-balancer/

- Cloudflare: https://www.cloudflare.com/

- Fastly: https://www.fastly.com/

- Mercurial: https://www.mercurial-scm.org/

- OpenSSL: https://www.openssl.org/

- Redis: https://redis.io/

- Go: https://go.dev/

- epoll（Linux man page）: https://man7.org/linux/man-pages/man7/epoll.7.html

─────────────

YouTube: https://youtu.be/e8lkL79n9KU

Web: https://yaoyorozu-oss.henteko07.com/

X: https://x.com/yaoyorozu_oss

毎日使っているのに、ブラウザが中で何をしているか実はよく知らない——そんな話から始まる今回。

catatsuyが取り上げるのは、ChromiumやFirefoxが裏側で扱っている「巨大なデータ」です。

ブラウザはHTMLを描画するだけでなく、HTTPSへ強制するドメイン一覧、危険URLのリスト、証明書の失効情報、よく使われるリソースURLパターンなど、さまざまな補助データを持っています。しかし、それらを単純な巨大リストとしてそのまま持つのは難しく、毎回サーバーへ問い合わせるのもレイテンシやプライバシーの問題があります。

今回はHSTS Preload、Google Safe Browsing、CRLite、Pervasive resource URL patternsなどを題材に、巨大なデータをブラウザがどう持ち、どう配り、どう高速に判定しているのかを話しました。

HSTS Preloadのドメイン一覧とsuffix判定、Safe Browsingのhash prefix、CRLiteのBloom Filter cascade、そしてURL patternによるリソースURLの扱いなど、暗号やTLSだけではない、ブラウザを支えるデータ構造と配布設計を覗いていきます。

trie treeやBloom Filterといったデータ構造の話も出てきますが、完全な仕様解説ではなく、ブラウザの裏側にある設計の面白さを見ていく回です。

ブラウザの中身に興味が湧いてくる、盛りだくさんなお話です。

* Chromium: https://www.chromium.org/

* Firefox: https://www.mozilla.org/firefox/

* HSTS Preload: https://hstspreload.org/

* Google Safe Browsing: https://safebrowsing.google.com/

* CRLite（Firefox）: https://github.com/mozilla/crlite

* Certificate Transparency: https://certificate.transparency.dev/

* Trie: https://en.wikipedia.org/wiki/Trie

* Bloom Filter: https://en.wikipedia.org/wiki/Bloom_filter

* Pervasive resource URL patterns: https://chromium.googlesource.com/chromium/src/+/HEAD/services/network/pervasive_resources

* Brotli: https://github.com/google/brotli

* Zstandard (zstd): https://github.com/facebook/zstd

* Hono: https://hono.dev/

* jQuery: https://jquery.com/

* Rust: https://www.rust-lang.org/

─────────────

YouTube: https://youtu.be/NH1yseBycOw

Web: https://yaoyorozu-oss.henteko07.com/

X: https://x.com/yaoyorozu_oss

Linuxを触っていれば必ずお世話になっているのに、意外と中身を知らないsystemd。

henteko の「OS起動時にプロセスを立ち上げる便利ツールでしょ?」という理解から話はスタートしますが、catatsuy が解き明かすその正体は想像のはるか上。依存関係の管理、死活監視、リソース制御、ソケットアクティベーション、cronより柔軟なタイマーまで——「何ができないのか」を探すレベルです。

Linuxサーバーを運用する人なら絶対に聞いてほしい一本です。

https://github.com/systemd/systemd

「ソースを公開する方がリスクが高い」——そんな時代が本当に来てしまったのかもしれません。

攻撃者がAIでOSSをスキャンして自動で弱点を突いてくる今、守る我々もAIで立ち向かうしかない。xz事件からHonoのAI Slop問題、TanStackのサプライチェーン攻撃、Takumi Guardのような新しい防御サービスまで、catatsuy が実体験を交えて語ります。

なぜ今、狙われているのが「開発者本人」なのか。OSSに関わるすべてのエンジニアに聞いてほしい一本です。

## xz

* Everything I Know About the XZ Backdoor - https://boehs.org/node/everything-i-know-about-the-xz-backdoor

* CVE-2024-3094 / Ubuntu security page - https://ubuntu.com/security/CVE-2024-3094

## Hono - OSSにおけるAI Slop問題の何が問題なのか？

* https://zenn.dev/yusukebe/articles/3fd5bc6ea341c9

## TanStackのnpmサプライチェーン攻撃とGitHub Actionsの危険な権限設計

* TanStack npm supply-chain compromise - https://tanstack.com/blog/npm-supply-chain-compromise-postmortem

* npm staged publishing - https://docs.npmjs.com/staged-publishing/

* pull_request_target の背景・リスクに関するGitHub Community discussion - https://github.com/orgs/community/discussions/179107

## axios ソフトウェアサプライチェーン攻撃の概要と対応指針

* https://blog.flatt.tech/entry/axios_compromise

## tj-actions/changed-files CVE-2025-30066

* https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-tj-actionschanged-files-cve-2025-30066-and-reviewdogaction

## Takumi Guard

* https://flatt.tech/takumi/features/guard

EC2にPHPやRailsをポンと置いて運用している現場、ファイルがこっそり書き換えられたらどうやって気付きますか？

OSS「kekkai」は、ファイルごとのハッシュ値で改ざんを検知するシンプルなCLIツール。なぜエージェント型ではなくCLIなのか、S3とIAMでハッシュをどう守るのか、.gitignoreを敢えて共有しない設計思想までを丁寧に解説します。

Docker時代に忘れられがちな「ファイル配置型」サーバーのセキュリティが気になる人にぜひ。

https://github.com/catatsuy/kekkai

apt で入る nginx で大抵は事足りる。でも「この機能を使いたい」「最新の OpenSSL じゃないと動かない」となった瞬間、自分でコンパイルする世界が待っています。

今回は catatsuy がメンテナンスする nginx-build を題材に、henteko が「そもそも、なんでビルドが必要なの？」と素朴に切り込みます。スタティックモジュールの話から、catatsuy が個人 VPS で ECH を動かすために加えた機能まで、nginx のディープな運用に興味がある人にぜひ。

https://github.com/cubicdaiya/nginx-build