八百万のOSS

All episodes.

28 episodes · showing the newest 28

#28 macOSでのビルドの難しさをHomebrewはどう吸収しているか

Nov 10, 2026 1 hr 4 min

Homebrewは、macOSでUnix系ソフトウェアのビルドとインストールを管理するパッケージマネージャーです。今回はcatatsuyが、macOSでソフトウェアをコンパイルするときの難しさと、Homebrewがそれをどう吸収しているかを紹介します。 macOSは標準のCコンパイラがClangで、ヘッダーやライブラリの配置もLinuxとは異なります。そのため、`./configure`、`make`、`make install`がそのまま通らないことがあります。Homebrewは、ソフトウェアのビルド手順や依存関係をRubyのFormulaで定義し、必要に応じてソースからビルドできる仕組みです。上流がビルド済みバイナリを配布している場合との違いも紹介します。 catatsuyの実体験として、M1 MacでLibreSSLをnginxと一緒にビルドできなかった件を紹介します。原因は、LibreSSLに含まれる`config.guess`と`config.sub`が古く、Apple Siliconを判定できなかったことでした。大元のプロジェクトから新しい版を取り込むPRを送り、マージされています。 Homebrewは2009年に登場し、現在はLinuxでも動作します。RubyのDSLを使う理由や、Homebrew自身が利用するPortable Rubyについて話します。System Integrity Protection（SIP）などmacOS特有の事情にも触れます。Apple Siliconでは`/opt/homebrew`、Intel Macでは`/usr/local`を標準のプレフィックスとすることで、Rosetta 2環境との共存を可能にしています。Cellarのディレクトリ構造や、シンボリックリンクを管理する`brew link`も紹介します。 Formulaでは`depends_on`で依存関係を指定できます。また、`brew tap`を使うことで、公式以外のリポジトリからもFormulaを導入できます。Formulaは単なる設定ファイルではなくRubyのコードであるため、信頼できるリポジトリを選ぶことが重要です。catatsuyはHTTP/3に対応させて独自にビルドしているcurlを、自分のtapで管理しています。後半では、Homebrewがビルド済みバイナリを配布するBottlesの仕組みを紹介します。続いて、catatsuyが開発しているkekkaiが、本人の知らないうちに第三者によって公式のhomebrew-coreに登録されていた話をします。その流れで、作者本人と第三者とで異なる登録基準や、GitHubのstars、forks、watchersの閾値についても話します。最後はセキュリティの話です。Homebrewは、公式リポジトリのレビューやチェックサムの検証、Bottlesなどによって安全性を高めています。一方で、...

#27 緊急！ISUCON2026優勝者に聞く、完全自律AIエージェントの作り方と今後のOSS | kawasy

Nov 5, 2026 1 hr 2 min

今回は、AIエージェントを完全自律で動かしてISUCON2026で優勝したkawasyさんをゲストに迎えたゲスト回です。fukabori.fmで語られた大会の全体像を踏まえて、準備の過程での判断と、その背景にある考え方を伺いました。 kawasyさんは当初から「人間が介入せず、8時間止まらずに最後まで自律的に動くこと」を目標に準備していました。AlphaEvolveのような進化的探索や独自コーディングエージェントも構想にありましたが、評価実験の結果、最終的にはClaude Codeをベースに、その上のユーザーハーネスだけを作る形に落ち着いています。準備の途中では、デプロイとベンチマークに合わせて全ホストのメトリクスを自動で取るツール群を作り込んでいました。しかし、何も用意しない構成のほうがスコアが高いケースがあり、エージェントがその場で必要な情報を取るアドホックな計測スクリプトを書いていたことに気づきます。9月末にハーネスを一度捨て、終盤のばらつきを減らす知識だけを慎重に足していったそうです。当日はSlackへの通知ツールやRemote Controlを用意しつつも、人間からの入力も通知も0回。競技開始から1時間22分で50万点に到達しました。後半では、汎用ツールやOSSはエージェント時代にどう使われるのか、長期的なプロダクト開発との違い、そして評価環境の整備やエージェント構成の判断など、人間に残る仕事について話しています。 AIエージェントにどこまで任せ、人間が何を担うのかを、ISUCONという評価基準が明確な舞台での実験から掘り下げた回です。 ## 関連リンク - fukabori.fm 142. ISUCON2026で優勝する方法 w/ kawasy: https://fukabori.fm/episode/142 - ISUCON2026 で優勝しました（当日編）: https://zenn.dev/luvtechno/articles/isucon2026-competition-day - ISUCON2026 受賞チームと全チームのスコア: https://isucon.net/archives/60126600.html - herdr: https://github.com/herdrdev/herdr - kawasy（X）: https://x.com/kawasy ───────────── YouTube: https://youtu.be/TeqlzPxliAI Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

#26 Renovateはどこまで設定できるか — nginx-buildとprivate-isuの全自動更新

Nov 3, 2026 51 min

Renovateは、リポジトリ内の依存関係を検出し、新しいバージョンが出たら更新のプルリクエストを作ってくれるOSSです。今回は、catatsuyがメンテナンスしているnginx-buildとprivate-isuを例に、デフォルト設定の先でRenovateをどこまでカスタマイズできるのかを話しました。 nginx-buildは、nginxや依存ライブラリのバージョンをGoのソースコードに直接書いています。`customManagers`の正規表現を使えばこれも更新対象にできますが、そもそも何を最新版とするのか、バージョン情報をどこから取得するのかという問題があります。マイナーバージョンの末尾を`[02468]`に限定してnginxのstable版だけを追う設定や、4つ目の数字を持つOpenRestyへの対応を紹介します。 OpenRestyではタグが後から削除・変更されるなど、リリース運用に問題があります。こうした問題を避けようと導入した`minimumReleaseAge`は、現在ではサプライチェーン攻撃への備えとしても役立っています。stable版を機械的に判定しづらいLibreSSLは、`dependencyDashboardApproval`で人が確認してから承認しています。また、5言語の実装が同居するprivate-isuでは、定期的なロックファイルメンテナンスを言語ごとのPRに分けています。後半はLTSの扱いです。MySQLのInnovationリリースが年月ベースの番号（26.7など）になり、LTSではない版への更新が提案されるようになりました。Docker Official Imagesの情報からLTS系列を抽出するカスタムデータソースや、JSONataを使って取得した情報を加工する仕組みを紹介します。さらにOpenSSLでは、LTS系列の変更を検出してRenovateが`renovate.json`自身の設定を書き換える仕組みまで実装しています。一時期放置されていた2つのリポジトリのメンテナンスを続けられているのは、Renovateによって更新作業を自動化できたからでした。依存関係の更新を自動化したい人や、OSSのバージョニングやリリース運用に興味がある人に聞いてほしい回です。 ## 関連リンク - Renovate: https://github.com/renovatebot/renovate - Renovate Docs: https://docs.renovatebot.com/ - Renovate（GitHub App）: https://github.com/apps/renovate - nginx-build: https://github.com/cubicdaiya/nginx-build - nginx-buildのrenovate.json: https://github.com/cubicdaiya/nginx-build/blob/f922e02770fec219eea31a2d80aaadae1636cf14/renovate.json -...

#25 go-jsonはなぜ速いのか — Opcode VMとgo:linknameの話 | goccy

Oct 27, 2026 1 hr 22 min

go-jsonは、Go標準の`encoding/json`と互換のインターフェースを持つ高速なJSONライブラリです。今回は作者のgoccyさんをゲストに迎え、主にエンコーダの高速化の仕組みを深掘りしました。開発のきっかけは、ブラウザゲームのサーバーで大量のJSONを返す際に、エンコードがボトルネックになったことでした。json-iterator/goへの置き換えでも十分な改善が得られず、自ら実装に取り組みます。 go-jsonの中心にあるのは、型ごとにOpcode（命令列）を生成・キャッシュし、VM（バーチャルマシン）で実行する仕組みです。関数呼び出しを繰り返す代わりに、巨大なswitch-caseで命令を処理します。ジャンプテーブルへのコンパイルをアセンブリで確認する方法や、caseの配置によってベンチマーク結果が変動する問題など、低レイヤーの最適化について詳しく聞きました。さらに、`reflect`のヒープへの強制エスケープを回避するために利用していた`go:linkname`の話へ。標準ライブラリの非公開APIへの依存がGo本体の開発を妨げる事例として、2024年にRuss CoxさんのIssueでgo-jsonが名指しされました。この問題を背景にGo 1.23では`go:linkname`への制限が強化され、Goのソースコードには今もgo-jsonの名前が残っています。 2026年9月のv0.11.0では、コーディングエージェントも活用しながら`go:linkname`を全面的に削除。Go 1.21での`reflect`の改善に加え、`typelinks`を使ったキャッシュをオープンアドレス法のハッシュテーブルに置き換え、読み出しをロックフリーに保ちながらメモリ使用量と性能を改善しました。その結果、bytedance/sonicを上回るベンチマーク結果も得られています。後半では、さらに高速なvelox-io/jsonの実装にも注目します。Cで記述したVMをELFとして埋め込み、GCCのcomputed gotoで命令を直接ディスパッチする方式です。こうした手法との比較を踏まえ、`encoding/json/v2`への対応やeasyjsonのようなコード生成方式など、go-jsonの今後についても議論しました。 JSONライブラリの内部実装から、ベンチマークとプロファイリングの向き合い方、OSSの保守と設計判断まで。GoでJSONを扱う方や、ISUCONに参加する方にぜひ聞いてほしい回です。 ## 関連リンク - go-json: https://github.com/goccy/go-json - go-json v0.11.0 リリースノート: https://github.com/goccy/go-json/releases/tag/v0.11.0 - go-json ベンチマークレポ...

#24 ログローテートで何が起きている？ファイルディスクリプタとinodeの仕組み

Oct 20, 2026 1 hr 1 min

CloudWatch Logsのようなクラウドのログ機能も、裏側ではログファイルを読み取り、別のサーバーへ送る仕組みが動いています。今回はFluentdを入口に、Linuxのファイル操作とログローテートの仕組みをcatatsuyが解説します。まずはファイルディスクリプタとinodeの基本から。`read()`によるファイルポジションの更新、並行処理での`pread()`の利用、複数プロセスからログを書き込む際の`O_APPEND`と`write()`の関係を説明します。続いてログローテートの仕組みを掘り下げます。ファイルを`mv`してもinodeは変わらず、開いたままのファイルディスクリプタは古いファイルを参照し続けます。Fluentdの`in_tail`はどうやってローテートを検知するのか。inotifyによるファイル監視がログの書き込み頻度によってCPU負荷を高める問題や、`enable_stat_watcher`による対策も紹介します。さらに、nginxが`USR1`シグナルでログを開き直す理由や、logrotateの`create`と`nocreate`の違いも解説します。 logrotateの`O_EXCL`によるファイル作成にも触れ、最後はFluentdの不具合をcronの`touch`で回避した結果、ログファイルの所有者がrootになり、アプリケーションが書き込めなくなった実際の障害を紹介します。普段は意識しないLinuxのファイル操作が、ログ収集や運用上の問題にどうつながるのかを掘り下げる回です。 ## 関連リンク - catatsuy「logrotateの設定とファイルのアクセスモードについて」（2018年）: https://catatsuy.medium.com/logrotateの設定とファイルのアクセスモードについて-f9719352dada - Fluentd: https://www.fluentd.org/ - Fluentd（GitHub）: https://github.com/fluent/fluentd - Fluentd in_tail（rotate_wait / enable_stat_watcher）: https://docs.fluentd.org/input/tail - Fluentdのログローテート検知時のwatcher修正: https://github.com/fluent/fluentd/pull/1598 - Fluent Bit: https://fluentbit.io/ - logrotate: https://github.com/logrotate/logrotate - logrotateのファイル作成処理（O_EXCL）: https://github.com/logrotate/logrotate/blob/1aba3764602a0a013ac3fb1ee57ed547dff03f88/logrotate.c#L600-L614 - logrotate(8): https://man7.org/linux/man-pages/man8/logrotate.8.html - Debianのnginxパッケージのlogrotate設定: https://sources.debian.org/src/nginx/1.26.3-3+deb13u7/debian/nginx-co...

#23 curlで覗くDNSとHTTP/3の仕組み

Oct 13, 2026 1 hr 3 min

APIを叩くとき、レスポンスを確認するとき、エンジニアなら誰もが一度は使うcurl。でも `curl -V` の出力をじっくり読んだことはありますか？今回は、HTTP/3やECHの挙動確認のためにcurlを自前でビルドしているcatatsuyが、普段何気なく使っているcurlの裏側を掘り下げます。 HTTP/3対応のcurlをビルドしようとすると、nghttp3やngtcp2、TLSライブラリなど、さまざまなOSSが登場します。当時の公式手順ではquictlsが使われていましたが、BoringSSL互換のAPIを持つLibreSSLでも動くはずだと考えて試したところ、問題なく利用できました。依存ライブラリを毎回ビルドするのは面倒なのでHomebrewのFormulaで自動化しました。その後、ECHの検証のためにOpenSSL 4系へ移行し、OpenSSL 4.0.0では動かなかったHTTP/3とECHの組み合わせが、4.0.2では動くようになっていた話も紹介します。普段使いのcurlにも意外な落とし穴があります。以前はTLS 1.1を指定する挙動だった `--tlsv1.1` が、TLS 1.1以上を使う指定に変わり、TLS 1.2で通信できてしまった経験を紹介します。TLS 1.1に限定するには `--tls-max 1.1` も必要です。また、`--resolve` を使えばHostヘッダーやSNIを維持したまま、接続先IPアドレスだけを差し替えられます。さらに、IPv6で問題が起きていてもIPv4へのフォールバックによって通信できてしまうHappy Eyeballsや、非同期DNSライブラリのc-aresなど、一見単純なHTTPリクエストの裏側にある仕組みを見ていきます。特に深掘りするのが、HTTPSレコードを使ったHTTP/3接続です。HTTP/2で通信した後、レスポンスに含まれるAlt-SvcヘッダーでHTTP/3の接続先を知る流れを紹介します。curlでも `--alt-svc` を使えば、その情報をファイルに保存して次回の接続に利用できます。一方、DNSのHTTPSレコードでHTTP/3対応を知ることができれば、最初からHTTP/3で接続できるはず。ところが実際には、たまにHTTP/3で接続できても、その後は何度試してもHTTP/2になってしまう。しばらく悩んだ末に分かった原因は、OSのDNSキャッシュでした。検証した環境では、A/AAAAレコードをgetaddrinfo経由でOSのDNSキャッシュから素早く取得できる一方、HTTPSレコードはc-aresで別途問い合わせていたため、HTTP/3の情報が届く前にHTTP/2で接続していたのです。DNSキャッシュを消すと再びHTTP/3で接続できるようになるという、キャッシュが効くことで新しいプロトコ...

#22 HTTPSでも見えているドメイン名 — ECHとインターネットの未来

Oct 6, 2026 1 hr 4 min

ECH（Encrypted Client Hello）は、TLSのClientHelloをInnerとOuterに分け、実際のSNIなどを含むClientHelloInnerを暗号化する仕組みです。ただ、いざ自分のサーバーで有効にしようとすると、思っていたよりずっと奥が深い世界が待っていました。前半では、なぜHTTPSでもドメイン名が見えていたのかをSNIから振り返り、ESNIがなぜうまくいかなかったのか、ClientHelloInner／Outer、GREASE ECHといった現在のECHの仕組みまで整理します。暗号化すれば検閲できなくなるわけではなく、中国やロシアでは残された情報を使ったブロックも実際に行われています。後半はいよいよ運用編です。DNSのHTTPSリソースレコードでECHConfigListを配る仕組み、ECH keyを定期的にローテーションするとDNS cacheとの間で世代がずれる問>題を扱います。複数世代の鍵から復号候補を絞る1 byteのconfig_id、古いECHConfigを持ったclientへ最新のECHConfigListを返せるretry_configs、さらにnginxのssl_ech_fileでは最初に指定した鍵だけがretry用になるという暗黙的な挙動まで掘り下げます。 OpenSSLでECH keyを生成し、nginxで実際に設定すると何が必要なのか。DNSが広告するECHConfigと各Edgeに配置されたprivate keyをどう同期させるのか。CloudflareのようにDNSとTLS Edgeの両方を持つ事業者では、この複雑な仕組みをどう自動化しているのかも考えます。最後は、サブドメインでテナントを分けるサービスではECHが何を隠せるのか、企業ネットワークのDNSやSNI監視とはどうぶつかるのか、そしてプライバシーを高めよ>うとすると、なぜ大規模なDNS・CDN事業者が有利になるのかまで話が広がります。 ECHの仕様を追っていくと、TLSだけではなく、DNS、CDN、検閲、そしてこれからのインターネットの構造まで見えてきます。インフラやCDN、TLSの運用に関わる人はぜひ本編で。 ## 関連リンク - RFC 9849 TLS Encrypted Client Hello（ECH）: https://www.rfc-editor.org/info/rfc9849/ - RFC 9848 Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings: https://www.rfc-editor.org/info/rfc9848/ - RFC 6066 TLS Extensions（SNI）: https://www.rfc-editor.org/info/rfc6066/ - RFC 9460 SVCB and HTTPS Resource Records: https://www.rfc-editor.org/info/rfc9460/ - RFC 8484 DNS Queries over HTTPS（DoH）: https://www.rfc-editor.org/info/rf...

#21 スマートフォンPush通知の配信基盤 — APNs/FCMとGaurun

Sep 29, 2026 1 hr 3 min

アプリを開いていないのに、スマートフォンに通知が届く。普段は当たり前に使っているこの仕組みは、裏側ではどう動いているのでしょうか。今回はメルカリが公開し、すでにGitHub上でアーカイブされたGo製のプッシュ通知サーバー「Gaurun」を入口に、元メンテナのcatatsuyがスマートフォンのプッシュ通知の仕組みを掘り下げます。話はまず、iPhoneやAndroidにプッシュ通知が届く仕組みから。端末がAppleやGoogleのサーバーと張り続けているコネクションの話や、APNsが5223番、FCMが5228番というHTTPSとは別のポートを使っている話をhentekoが素朴に掘り下げます。そこからAPNsへ。HTTP/2しか話せずHTTP/1.1にフォールバックしない、コネクションを維持しながら大量の通知を送る必要がある、100万人に送るなら基本的には100万の配送先を扱う必要がある、といった独特の事情から、PHPのWebアプリケーションから直接大量のプッシュ通知を送るのが厳しく、Gaurunのような専用サーバーが必要だった背景が見えてきます。さらに話はGoのHTTP/2実装まで降りていきます。APNsの証明書認証のためにTLSClientConfigを設定するとHTTP/2が自動で有効にならず、golang.org/x/net/http2を明示的に使う必要があった時代がありました。しかしGo本体にもHTTP/2の実装がbundleされているため、異なるバージョンのHTTP/2実装が同居し、実際の障害につながります。最終的にはGo 1.13で追加されたForceAttemptHTTP2によって、Gaurunからgolang.org/x/net/http2への直接依存を外せるようになりました。Appleの証明書更新とJWTを使ったトークンベース認証など、「プッシュ通知を送る」裏側にある実装と運用の面倒さも語られます。後半は「今から作るなら」の話。現在はFCMからAPNsへ通知を送ることもでき、Topicを使えば大量のfan-outまでGoogle側に任せられます。Gaurunが自前で担っていた仕事のかなりの部分を、今ではFCMがManaged Serviceとして引き受けています。実はcatatsuy自身も、GaurunをFCM HTTP v1 APIに対応させるPull Requestを出していました。しかし当時はLegacy APIがまだ使えており、急いで移行する理由が薄かったためclose。その後Legacy APIは終了し、Gaurunもアーカイブされました。外部サービスのAPIの変化によって、OSSの役割がどう変わっていくのかという話にもつながります。さらに、既存のAPNs tokenをFCM側へ移す仕組み、registration tok...

#20 Honoはなぜ速い？ルーター8個とファストパスの裏側 | yusukebe

Sep 15, 2026 1 hr 2 min

Hono を使っていると「速いフレームワーク」だとなんとなく知っている人は多いはず。でもその速さは、どこから生まれているのでしょうか。今回は Hono の作者 yusukebe さんをゲストに迎え、henteko と catatsuy がベンチマークの裏側を根掘り葉掘り聞いていきます。 Hono には過去のものも含めると 8 個ものルーターが存在し、その筆頭が usualoma さんの 2 回目のプルリクで入った RegExpRouter だったという話から、コアだけを徹底的に小さくしてアダプターやミドルウェアで機能を足すレイヤー設計、Express との Hello World 比較、ベンチマークを「マーケティング」として捉える視点まで。さらに Headers オブジェクトの生成コストを避ける「ファストパス」の考え方、Response.json を採用したのに戻すことになった理由、Bun・Node.js・Deno でベンチ結果がまるで違う現実、bombardier と Elysia 作者のベンチマークを指標にしている理由など、パフォーマンスにこだわる人ほど唸る話が続きます。聞きどころは、Cloudflare Workers 向けに作ったのに、なぜベンチマークの基準が Bun になったのかという意外な経緯。フレームワークの速さがどう作られるかを知りたいエンジニアにおすすめの回です。 ## 関連リンク - Hono: https://hono.dev/ - Hono（GitHub）: https://github.com/honojs/hono - Hono ルーターの解説: https://hono.dev/docs/concepts/routers - Hono ベンチマーク: https://hono.dev/docs/concepts/benchmarks - Hono テストガイド（app.request）: https://hono.dev/docs/guides/testing - Hono CLI: https://github.com/honojs/cli - ax（yusukebe 作の AI 時代の curl）: https://github.com/yusukebe/ax - usualoma（GitHub）: https://github.com/usualoma - Cloudflare Workers: https://developers.cloudflare.com/workers/ - workerd: https://github.com/cloudflare/workerd - Bun: https://bun.sh/ - Deno: https://deno.com/ - JSR: https://jsr.io/ - Hono on JSR: https://jsr.io/@hono/hono - Node.js: https://nodejs.org/ - Fastly Compute: https://www.fastly.com/products/compute - Express: https://expressjs.com/ - Koa: https://koajs.com/ - koa-compose: https://github.com/koajs/compose - Elysia: https://elysiajs.com/ - Bun HTTP Framework Benchmark（Elysia 作者による）: https://github...

#19 lsが返ってこない！libcの壁をgetdents64で突破した自作lls

Sep 8, 2026 1 hr 2 min

lsは万能だと思っていませんか？実は数千万ファイルが入ったディレクトリでは、lsもrsyncも歯が立たなくなります。今回はcatatsuyがその壁を突破するために作ったGo製CLI「lls」を紹介。かつてオンプレのファイルサーバーに眠っていた3100万ファイルのリストを出し切り、AWSへの移行を可能にした自作ツールの中身を、hentekoが「なぜlsを再実装したのか」から順番に解きほぐしていきます。前半はllsに近づくための遠回り。システムコールとは何か、なぜCはlibcを介して呼ぶのか、glibcとmusl libcの違い、Goがlibcのレイヤーごと再実装している話、Goのブートストラップ問題（1.4はCで書かれた最後のGo）、そしてCの配列とGoの配列とスライスの違いまで、システムプログラミングの土台を丁寧に積み上げます。後半でようやく本題。libcのreaddirはgetdents64を小さなバッファで何度も呼ぶため終わらないこと、llsはgetdents64を直接呼び出して5MBのバッファで読み切ること、inode番号0のエントリや「.」「..」の扱い、Cの終端文字をGoの文字列に変換する処理など、実装の勘所を具体的に語ります。さらにCとGoのエラー処理の違い（errnoと多値返却）、getdents64がLinux専用ゆえの開発の不便さも。「readdirにバッファサイズを渡せればこんなことしなくて済んだのに」というcatatsuyの嘆きと、Hacker Newsに初投稿した顛末も聞きどころ。低レイヤーは自分に関係ないと思っているWebエンジニアにこそ聞いてほしい回です。 ## 関連リンク - lls（catatsuy）: https://github.com/catatsuy/lls - ファイルが多すぎてlsが打てなくなったディレクトリでファイル名のリストを出すllsを作りました（Zenn）: https://zenn.dev/catatsuy/articles/e5f3bc7944f9fe - llsとcachectlから学ぶ、Goでシステムプログラミングをする方法（Zenn）: https://zenn.dev/catatsuy/articles/e15714f8e253d8 - 旧ストレージ廃止大作戦−2900万超のファイルリストを取得する（PR TIMES 開発者ブログ）: https://developers.prtimes.com/2021/09/15/decommissioning_old_storage_list_a_dir_29million/ - You can list a directory containing 8 million files! But not with ls: http://be-n.com/spw/you-can-list-a-million-files-in-a-directory-but-not-with-ls.html - Hacker News（上記記事のスレッド）: https://news.ycombinator.com/item?id=28191639 - Show HN: lls...

#18 AIがなければ成立しない？週1技術ポッドキャストの作り方

Sep 1, 2026 57 min

毎週1本、50分超えの技術ポッドキャストを趣味で出し続ける——それを可能にしているものは何なのか。今回はいつものOSS紹介ではなく、「八百万のOSS」自体を題材に、17回続けてきた制作の裏側をhentekoとcatatsuyが分析する特別回です。テーマはChatGPTと壁打ちしながらアジェンダを生成し、GitHubのURLを渡して調査。さらにCodexにはソースコードを渡して深掘りしています。収録は自作ツールで各自ローカル録音、編集はAIサービスで無音カットとレベリングをして約1時間、予告編動画も約20分で完成。さらにXの告知投稿は、月5,000円のVPS上のcronからCloudflare Workersへ移行して運用コストをゼロにしました。「AIが出る前だったら考えられなかった番組」と2人が言い切る理由がよくわかる構成です。10年前に同じ番組をやろうとしたらどうなっていたか、という思考実験も面白いポイント。一方で、「ここだけは絶対にAIに任せない」と2人が口を揃える部分も語られます。AI時代に人間がジャッジすべきものは何か、その答えは本編で。 AIを活用した個人プロジェクトの続け方に興味がある人、これからポッドキャストを始めてみたい人に特におすすめの回です。 ## 関連リンク - OpenAI Codex（公式ドキュメント）: https://developers.openai.com/codex/ - Claude Code: https://claude.com/product/claude-code - Cloudflare Workers: https://workers.cloudflare.com/ - fukabori.fm: https://fukabori.fm/ - Go Conference: https://gocon.jp/ - YAPC::Japan: https://yapcjapan.org/ ───────────── YouTube: https://youtu.be/A3e_qP_Vlko Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

#17 PHPを書いていたはずが、ずっとCを読んでいた

Aug 25, 2026 56 min

ドキュメントを読んでも納得できないとき、あなたはどこまで潜りますか？　今回はリスナーのポヨヨンさんから届いた「PHP が C 言語のラッパーであるという話を詳しく知りたい」というお便りに、catatsuy が自身の経験を総動員して答えるお便り回です。 `fopen()`のモード文字がPHPのstream実装で`open()`へ渡すフラグに変換され、OSへ処理が委ねられる仕組みをCのソースコードで確かめるところから始まります。さらに、Webアプリケーションの根幹なのにCで実装されていて読み解くのが難しいPHPのセッションやRedis拡張にも触れながら、「マルチプロセスではメモリを共有できないはずなのに」を飛び越えてくるAPCuと共有メモリセグメントの正体へ。ISUCON本のわずか数行を書くために、APCuのC実装を数時間かけて読んだ経験も振り返ります。後半では、PHP 5.6から7への移行期にmemcache拡張からmemcached拡張へ乗り換えたところ、同じmemcachedサーバーに保存した値を正しく読めなくなった実運用トラブルを紹介します。memcachedのflagsはサーバーが解釈しないクライアント向けの領域であり、二つの拡張がそれぞれ異なる型情報や圧縮情報を記録していました。どちらも仕様に沿って実装されているのに、ライブラリを交換すると互換性問題が表面化する。その原因を突き止めるため、またCのコードへ潜っていきます。最後は、AIを使ったコードリーディングと、普段使うライブラリの実装まで同じ言語のまま降りやすいGoとの違いにも話が広がります。言語の内部実装に興味がある人にぜひ聞いてほしい回です。 ## 関連リンク - PHP: https://www.php.net/ - PHPの通常ファイル用stream実装（plain_wrapper.c）: https://github.com/php/php-src/blob/271f689482c8efdaa8b2b5ac11e8172c25335bdd/main/streams/plain_wrapper.c - PHPのセッション実装（ext/session）: https://github.com/php/php-src/tree/271f689482c8efdaa8b2b5ac11e8172c25335bdd/ext/session - APCu: https://pecl.php.net/package/APCu - APCu（GitHubリポジトリ）: https://github.com/krakjoe/apcu - memcached: https://memcached.org/ - memcached protocol: https://github.com/memcached/memcached/blob/master/doc/protocol.txt - PECL memcache: https://pecl.php.net/package/memcache - php-memcached（PHP の memcached 拡張）: https://github.com/php-memcached-dev...

#16 CIに潜む「宝探し」を止めろ！cicd-sensorで挑むサプライチェーン攻撃検知の最前線 | rung

Aug 18, 2026 56 min

「たまたまCIを止めていたから助かった」──そんな偶然に頼ったサプライチェーン攻撃対策、そろそろ卒業しませんか？今回はゲストにcicd-sensor作者のrungさんを迎え、CI/CDジョブの中身を監視して攻撃を検知するというアプローチを深掘りします。前半はcicd-sensorの概要から。GitHub ActionsやGitLab CI/CDのジョブ上でeBPFを使ってプロセス・ネットワーク・ファイルアクセスを監視し、SSHキーやクラウドのアクセスキーを狙う「宝探し」型の攻撃を検知する仕組みを解説します。検知結果の表示やジョブの強制失敗に加え、実行時の挙動をログやattestationとして残して後から調査することもできます。後半は実装の深掘りで、cgroupによるジョブへのイベント仕分け、式言語CELで書かれた検知ルールとベースラインルールの設計思想、HTTPSで暗号化される前の情報をOpenSSLのuprobeで取得する、開発中のHTTPリクエスト監視機能の設計など、かなりディープな内容に。GitHubが攻撃データのアップロード先として悪用されると、`github.com`というドメイン名だけでは正常な通信と区別できない、という検知の難しさの話は必聴です。 CIを回しているエンジニアなら他人事ではない一本。正式リリース前のいま、ぜひチェックしてみてください。 ## 関連リンク - cicd-sensor（公式サイト）: https://cicd-sensor.github.io/ - cicd-sensor（GitHubリポジトリ）: https://github.com/cicd-sensor/cicd-sensor - cicd-sensorのattestation predicate: https://cicd-sensor.github.io/user-guide/attestation-predicate.html - HTTPリクエスト監視機能の設計: https://github.com/cicd-sensor/cicd-sensor/issues/136 - GitHub Actions: https://github.com/features/actions - GitLab CI/CD: https://docs.gitlab.com/ci/ - eBPF: https://ebpf.io/ - CEL (Common Expression Language): https://cel.dev/ - Open Policy Agent (Rego): https://www.openpolicyagent.org/ - Expr: https://github.com/expr-lang/expr - Falco: https://falco.org/ - Tetragon: https://tetragon.io/ - cilium/ebpf: https://github.com/cilium/ebpf - cgroups: https://man7.org/linux/man-pages/man7/cgroups.7.html - Renovate: https://docs.renovatebot.com/ - GMO Flatt Security: https://flatt.tech/ ───────────── YouTube: https://youtu.be/DK1-qUmI_pA Web: https:/...

#15 103 Early Hints、返すだけでは速くならない

Aug 11, 2026 57 min

103 Early Hintsは、最終的なHTMLが完成する前に、必要になりそうなCSSやJavaScriptを`Link`ヘッダーでブラウザへ知らせる仕組みです。ただし、103を返すだけでページが速くなるわけではありません。今回catatsuyが紹介するEarly Hintsについて、初めて聞くhentekoが仕組みから実運用の注意点まで質問しながら掘り下げます。前半では、現在は主要ブラウザから削除されたHTTP/2 Server Pushから振り返ります。サーバーにはブラウザのキャッシュ状態が分からず、不要なリソースまで送ってしまう問題がありました。H2Oはこの問題に対して、ブラウザが持っていると推測されるリソースを`h2o_casper` Cookieで管理するCASPerを実装しました。さらに、その発想をHTTP/2へ一般化するCache Digestsも提案されましたが、標準化には至りませんでした。Early HintsではリソースそのものをPushせず、取得するかどうかをブラウザに委ねることで、この役割分担を変えています。後半では、SSRでHTMLを生成している間にCSSやJavaScriptの取得を進める仕組み、CDN Edgeから早く返す利点、fingerprint付きassetとデプロイ世代の同期問題を取り上げます。nginx 1.29.0の`early_hints`ディレクティブはupstreamから届いた103を転送する機能であり、nginx自身が103を生成するものではありません。また、HTTP/2・HTTP/3かつ`Sec-Fetch-Mode: navigate`に対象を絞る理由や、nginx 1.29.7以降ではproxy先のデフォルトがHTTP/1.1に変わったことも紹介します。 Early Hintsで重要なのは、確実に使う少数のリソースだけをHintし、端末別に計測することです。Shopifyの観測データの事例も参照しながら、preloadするリソースを増やしすぎると逆効果になり得ることや、実際にLCPが改善したかを確認する必要性まで考えます。 - Early Hintsの解説（Chrome for Developers）: https://developer.chrome.com/docs/web-platform/early-hints - Remove HTTP/2 Server Push from Chrome（Chrome for Developers）: https://developer.chrome.com/blog/removing-push - H2O HTTP/2 Directives — http2-casper: https://h2o.examp1e.net/configure/http2_directives.html - Cache Digests for HTTP/2（IETF Datatracker）: https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-digest/ - RFC 8297: An HTTP Status Code for Indicating Hints: https://datatracker.ietf.org/do...

#14 画像変換を支えるOSSと実運用

Aug 4, 2026 1 hr 24 min

Webサービスで画像をきれいに、軽く配るには何から考えればよいのでしょうか。今回は、可逆圧縮で透過も扱えるPNGと、非可逆圧縮で写真に向くJPEGの違いを出発点に、画像フォーマットの選び方と、それを実際のサービスで運用するための設計を整理します。現代のスマートフォンはカメラの性能が高く、Webサービスでそのまま扱うには大きすぎる画像がアップロードされることがあります。Canvas APIを使えば、ブラウザ上で画像を変換できます。ただし、必要な画質や保存したい元画像、通信量、変換を行う場所はサービスによって異なります。画像を一律に小さくすればよいのではなく、そのサービスに合った扱いを決める必要があります。配信する画像では、細かなquality設定より先に十分な画像サイズを確保します。高密度ディスプレイではCSS上の表示幅より大きな画像が必要ですが、全員に最大サイズを送ると転送量が増えます。そこで、固定サイズのサムネイルを事前生成する構成から、必要な派生画像を動的に生成してCDNへキャッシュする構成へ。`Accept`ヘッダーによるフォーマットの出し分けと、`picture`・`srcset`で複数サイズからブラウザに選ばせる方法を紹介します。 WebPは写真に有効な一方、テキスト画像やドット絵まで機械的にWebPへ変換するのは現実的ではありません。WebPの実装が実質的にlibwebp一つに限られていることや、画像の種類に応じたpresetの扱いも取り上げます。現在ではAVIFも有力な選択肢で、JPEGをフォールバックにしてAVIFを追加する構成も考えられますが、AVIFはエンコード負荷が高い点に注意が必要です。どの形式でも同じqualityの値が同じ見た目を意味するわけではないため、実際の画像と容量を見ながら調整します。 ImageMagickやcwebpを使えば、サーバー側でも画像を変換できます。ただし、変換処理が一度成功することと、ユーザーがアップロードする多様な画像を継続して処理できることは別です。極端な縦横比や想定外の画像が来たときの処理負荷、変換後のファイルサイズなど、実サービスで確認すべき点にも踏み込みます。画像URLをフロントエンドで自由に組み立てず、バックエンドが許可済みの候補URLを返す理由も、後方互換性とCDNキャッシュ効率の両面から考えます。派生画像をCDNへキャッシュし、実際に配信されたオブジェクトサイズを監視する。必要に応じて画像変換SaaSへ任せる。WebPを選べば終わりで...

#13 memcachedはシンプルなまま —— Netflix EVCacheの「賢いクライアント」設計

Jul 28, 2026 44 min

memcachedはシンプルで高速です。一方で、複数の場所にデータを複製したり、障害が起きたときの読み書きを切り替えたりするところまでは面倒を見ません。では、大規模なサービスでは、たくさんのmemcached serverをどう扱えばよいのでしょうか。今回はNetflixが公開しているOSS「EVCache」を読みながら考えます。 EVCacheはmemcached serverそのものを複雑にするのではなく、アプリケーション側のsmart clientが状況を判断します。writeは複数のAvailability ZoneにあるServerGroupへ送り、readは近くのServerGroupを優先。近くのcacheに問題があれば、別のzoneへ切り替えます。すべてのwriteが終わるまで必ず待つのではなく、一部の失敗や古い値を許容するのも、消えても作り直せるcacheならではの割り切りです。 serverを増減したとき、保存先の変化をどう小さくするのか。アクセスが一つのkeyに集中したらどうするのか。空のcache clusterをいきなりread対象にすると何が起きるのか。こうしたcacheの一般的な問題から出発し、consistent hashing、client-side in-memory cache、先にwriteだけを流して温めるwrite-only ServerGroupといったEVCacheの実装につなげていきます。 EVCacheのコードを手がかりに、Netflixが大規模なcacheをどう支えているのかを読み解きます。cacheをserverだけでなく、client、deploy、障害時の切り替え、監視まで含めて考える視点を学ぶ回です。 - Netflix EVCache: https://github.com/Netflix/EVCache - memcached: https://memcached.org/ - pecl memcached: https://pecl.php.net/package/memcached - 達人が教えるWebパフォーマンスチューニング（ISUCON本）: https://gihyo.jp/book/2022/978-4-297-12846-3 ───────────── YouTube: https://youtu.be/8_zwaJgqN5Y Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

#12 全部やらないデプロイツール — ecspresso/lambrollが引いた"分界点" | fujiwara

Jul 21, 2026 51 min

「デプロイって、実はAPIを3回くらい叩けばできるんですよ」——ECS用デプロイツール「ecspresso」とLambda用の「lambroll」を作ったfujiwaraさんをゲストに迎え、自作デプロイツール10年の進化を深掘りするゲスト回です。 SAMやServerless Frameworkを選ばずCloudFormationを経由しない道を選んだ理由から始まり、最初は300行だったツールが1万行に育つまでに足されてきた機能の話が続きます。デプロイ前にイメージやサブネットの存在を検証するverify、マネコンでの手動変更による先祖返りを防ぐdiff、プルリクから生まれたrun task対応、Terraformのtfstateを名前解決に使うtfstate-lookup。Jsonnetとテンプレート記法が衝突した「食い合わせ問題」や、ECS側にネイティブロールバックが入って追従に苦労した話など、APIを直接叩くツールならではの苦労も赤裸々です。終盤はREADMEを丸ごとバイナリに埋め込むAI対応と、ecspressoインスパイアなツールが独立に複数生まれている最近の面白い現象へ。デプロイツールを自作したい人、OSSのメンテナンスのリアルを知りたい人におすすめの回です。 - ecspresso: https://github.com/kayac/ecspresso - lambroll: https://github.com/fujiwara/lambroll - tfstate-lookup: https://github.com/fujiwara/tfstate-lookup - Amazon ECS: https://aws.amazon.com/ecs/ - AWS Lambda: https://aws.amazon.com/lambda/ - Terraform: https://www.terraform.io/ - AWS CDK: https://aws.amazon.com/cdk/ - AWS SAM: https://aws.amazon.com/serverless/sam/ - Serverless Framework: https://www.serverless.com/ - apex: https://github.com/apex/apex - Jsonnet: https://jsonnet.org/ - go-jsonnet: https://github.com/google/go-jsonnet - skillsmith: https://github.com/Songmu/skillsmith ───────────── YouTube: https://youtu.be/P2gl8GSH-Ec Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss

#11 Let’s Encryptは無料より自動化がすごい！証明書運用の知られざる世界

Jul 14, 2026 52 min

無料で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/yao...

#10 なぜMeetやZoomで録らないのか —— ポッドキャスト収録の技術

Jul 7, 2026 50 min

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

#9 HTTP/2で速くなった、はずだった —— HTTP/3との違いとCDN利用の現実

Jun 30, 2026 1 hr 10 min

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/rfc75...

#8 GETするだけなのに書き込みが走る？memcachedのLRUとCPUの話

Jun 23, 2026 35 min

キャッシュサーバ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

#7 nginxを使わない理由がない？Webアプリを楽にするリバースプロキシの基本

Jun 16, 2026 46 min

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

#6 ブラウザに巨大JSONが眠ってる？巨大データで見るブラウザの裏側

Jun 9, 2026 1 hr 4 min

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

#5 systemdは「プロセス起動係」じゃない？何でもできる正体に迫る

Jun 2, 2026 41 min

Linuxを触っていれば必ずお世話になっているのに、意外と中身を知らないsystemd。 henteko の「OS起動時にプロセスを立ち上げる便利ツールでしょ?」という理解から話はスタートしますが、catatsuy が解き明かすその正体は想像のはるか上。依存関係の管理、死活監視、リソース制御、ソケットアクティベーション、cronより柔軟なタイマーまで——「何ができないのか」を探すレベルです。 Linuxサーバーを運用する人なら絶対に聞いてほしい一本です。 https://github.com/systemd/systemd

#4 AIが攻撃してくる時代、OSSの信頼はどう守る？

May 26, 2026 42 min

「ソースを公開する方がリスクが高い」——そんな時代が本当に来てしまったのかもしれません。攻撃者が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

#3 ファイル改ざんに張る「kekkai」

May 19, 2026 37 min

EC2にPHPやRailsをポンと置いて運用している現場、ファイルがこっそり書き換えられたらどうやって気付きますか？ OSS「kekkai」は、ファイルごとのハッシュ値で改ざんを検知するシンプルなCLIツール。なぜエージェント型ではなくCLIなのか、S3とIAMでハッシュをどう守るのか、.gitignoreを敢えて共有しない設計思想までを丁寧に解説します。 Docker時代に忘れられがちな「ファイル配置型」サーバーのセキュリティが気になる人にぜひ。 https://github.com/catatsuy/kekkai

#2 なぜ自分で nginx をビルドするのか？ — nginx-build の世界

May 12, 2026 33 min

apt で入る nginx で大抵は事足りる。でも「この機能を使いたい」「最新の OpenSSL じゃないと動かない」となった瞬間、自分でコンパイルする世界が待っています。今回は catatsuy がメンテナンスする nginx-build を題材に、henteko が「そもそも、なんでビルドが必要なの？」と素朴に切り込みます。スタティックモジュールの話から、catatsuy が個人 VPS で ECH を動かすために加えた機能まで、nginx のディープな運用に興味がある人にぜひ。 https://github.com/cubicdaiya/nginx-build

#1 GitHubで200スター集めた「Purl」の作り方

May 5, 2026 33 min

OSSを作って公開しても、誰にも届かずに埋もれていく──そんな経験はありませんか。今回はcatatsuyが作ったGo製CLIツール「Purl」がGitHubで200超のスターを集めた裏側を聞きました。READMEに動画を貼った理由、英語圏に向けて発信する意味、そして「自分が一番のユーザーであること」が改善の芯を食う、というドッグフーディングの話まで。ツールを作って広めたい人、自作OSSを育てている人にぜひ聞いてほしい回です。 https://github.com/catatsuy/purl