どうも、マイクです。おはようございます。
5月1日、金曜日の朝7時になりました。ここからの時間は「zenncast」、きょうはZennで話題になっているトレンド記事を、いっしょにチェックしていきたいと思います。
今日は全部で5本の記事をご紹介します。セキュリティからWeb開発、AIコーディングアシスタントとの付き合い方まで、かなり幅広いラインナップになってますので、通勤・通学のおともに、ゆるっと耳だけ貸してください。
まず1本目。
タイトルは「Linuxカーネルの脆弱性『CopyFail (CVE-2026-31431)』をEC2のUbuntu 22.04で実証してみた」。
名前からして物々しいんですが、中身もなかなかインパクトがあります。一般ユーザーが、たった1コマンドでrootを取れてしまう、というLinuxカーネルの脆弱性を、実際にAWSのEC2上のUbuntu 22.04で再現している記事です。
キモになっているのが `algif_aead` と `authencesn`、それから `splice()` の組み合わせ。これで、ディスク上のファイルじゃなくて、ページキャッシュ上に載っている `/usr/bin/su` を、任意のシェルコードに書き換えちゃうんですね。で、その書き換えた`su`がSetUID特権を持っているので、`setuid(0)`でrootになって、そのまま`/bin/sh`を起動してrootシェルをゲットできると。
怖いのは、ディスク上のバイナリは一切改ざんされていないところです。再起動したりキャッシュをクリアすると、何事もなかったかのように元に戻るので、侵害の痕跡が残りにくい。検知しようと思ったら、ページキャッシュ経由で読んだデータと、O_DIRECTでディスクから直接読んだデータのハッシュを突き合わせる、みたいなちょっとマニアックな方法が必要になってきます。
影響範囲も`su`だけじゃなくて、`newgrp`みたいな他のSetUIDバイナリでもroot化できることが確認されていて、「あ、うちも普通に入ってるやつだ…」と思った方、多いと思います。暫定対応として`algif_aead`を無効化する手もあるんですが、その副作用が読みにくいので、基本はディストリが出してくれるパッチを、できるだけ早く当てましょう、というメッセージです。インフラ担当の方、今日はぜひ自分のカーネルバージョンとアナウンス、チェックしてみてください。....
続いて2本目。
タイトルは「UIの面倒、実はDBの問題だった ― Local-First と Instant が示す Web 開発の未来」。
これは、Webアプリの「UI作るのダルい問題」に、かなり本質的に切り込んでる記事です。InstantDB v1.0というサービスを題材にしていて、「AIが書くアプリのための最適なバックエンド」という、なかなか攻めたキャッチコピーから始まります。
いまのWeb、SPAだ、SSRだ、RSCだ、Streamingだと、レンダリング戦略はどんどん進化してるんですけど、ユーザー体験を重くしてる本丸って、じつはUIじゃなくて「データまわり」じゃない？という指摘なんですね。具体的には、データ取得のレイテンシと、楽観的更新、リアルタイムなマルチプレイ、オフライン対応。このあたりをコンポーネントやフロントの状態管理だけで頑張ろうとするから、どんどんつらくなる。
InstantDBはそこをDB側で吸収しにいきます。Auth、リアルタイム同期、権限管理、楽観的更新、オフラインキャッシュをぜんぶデータベースの責務として統合して、フロント側は「結果を表示するだけ」に近づけよう、というアプローチ。裏側では、トリプルストア＋Pending Queue、書き込みログをもとにしたリアクティブ再計算、全部入りの巨大triplesテーブル、みたいなかなり攻めたアーキテクチャで、Local-Firstな動きを実現しています。
記事では付箋ボードをサンプルに、スキーマや権限をコードでサクッと宣言して、専用クエリ言語のInstaQLでグラフっぽいデータを扱いながら、ドラッグ＆ドロップの操作も`db.transact`一発でリアルタイム同期される、っていう体験が紹介されています。将来的には、多くのWebアプリがこういう「Local-FirstでReactiveなバックエンド」を前提に組まれていくんじゃないか、という未来予測で締めくくられていて、フロントエンド疲れのエンジニアには刺さる内容だと思います。....
3本目。
タイトルは「【Claude Code】CLAUDE.md・skills・agents を整備して開発体験が劇的に変わった話」。
AIコーディングアシスタント、なんとなく入れてるけど「思ったほど使いこなせてないなあ」という人に、ガツンと刺さるやつです。著者の方はGitHub CopilotからClaude Codeに乗り換えたんですが、VS Code拡張を入れただけだと、プロジェクトの文脈もドメイン知識もないから、的外れな提案が出てきたり、毎回ゼロから説明し直したりで、ちょっとストレスだったと。
そこでやったのが、Claude専用の「オンボーディング資料」をちゃんと作る、というアプローチです。まずはプロジェクトの概要や技術スタック、実行環境、ディレクトリ構成、よく使うコマンド、コーディング規約なんかをまとめた CLAUDE.md を用意して、「このプロジェクトで働く新入社員マニュアル」みたいな役割を持たせる。
さらに、RSpecの書き方とかRuboCopの使い方、ドキュメント更新手順といった「繰り返し発生する作業」のやり方を skills/ ディレクトリとして定義しておく。パフォーマンス分析専用のエージェント、みたいな特化型のサブエージェントを agents/ 以下に用意して、「この人はパフォーマンス担当」「この人はバグ調査担当」みたいに役割分担するイメージですね。
これを整えていくと、前提共有がぐっと進むので、短い指示でもチーム標準に沿ったコードを書いてくれたり、重い分析タスクを安心して丸投げできるようになった、と。あわせて .claude/settings.json で、叩いていいコマンドやアクセス権限を細かく制御して、本番環境を誤って触らないようにするといった安全面のTipsも紹介されています。「Claude入れたけど微妙だな」と感じている方は、このCLAUDE.md・skills・agentsの3点セットから始めると、一気に化けるかもしれません。....
4本目。
タイトルは「array[i++] = null; は本当に GC を促進するのか — Node.js で実測して確かめる」。
これはJavaScript書いてる人、特にパフォーマンスを気にし始めた中〜上級者には、めちゃくちゃ実用的な検証記事です。きっかけは、Reactの内部コードに出てくる `concurrentQueues[i++] = null` という一行。「これって本当にGC、つまりガーベジコレクションを助けてるの？」という素朴な疑問から、Node.jsでがっつり計測して確かめています。
ポイントは、モジュールスコープの配列ってGC Rootからたどれるので、インデックスを0に戻すだけだと、中身の参照は残ったままなんですよね。その状態だと、GCは「まだ使われてる」と判断しちゃうので、メモリは解放されない。実験でも、インデックスだけ戻すパターンは、だいたい100MB分が解放されずに、実質リークしていることが示されています。
一方で、`arr[i] = null` とか、`delete arr[i]`、あるいは `arr.length = 0` みたいに、スロットの参照をしっかり切ってあげると、ちゃんとGCが走ってメモリが空く。ただしそれぞれ副作用があって、`delete`は配列を「ホールだらけ」の特殊な形にしてしまって、以後ずっとパフォーマンスが落ちる。`length = 0` は配列バッファの再確保が増えるので、これもGC圧力が高まりがちです。
じゃあどうするのがいいのかというと、使い回し配列の場合は「インデックスをリセットしつつ、実際のスロットもnullで上書きしていく」というのが一番バランスが良い。Reactの実装も、まさにこの戦略を取っているよ、という話です。設計レベルの話としては、そもそも強参照でガッと持たないで、`WeakMap`で弱参照キャッシュにする、という選択肢にも触れられています。イベントキューやキャッシュ、デバウンス用バッファなんかで、じわじわリークしていないか、この記事を機に見直してみるといいかもしれません。....
そしてラスト、5本目。
タイトルは「Hono公式の Inertia アダプタが来た！Hono × Inertia × React によるSPA新体験」。
これは、Cloudflare WorkersとかでおなじみのHonoと、Inertia、そしてReactを組み合わせた、新しいSPAスタイルの開発体験レポートです。キーワードは「サーバ駆動の安心感」と「Reactの書き心地」、このいいとこ取りですね。
従来の「APIサーバ＋フロントSPA」構成だと、API専用エンドポイントを作って、React Routerでルーティングを組んで、`useEffect` と `fetch` と `useState` でデータを取ってきて…と、同じ情報をサーバとクライアントの両方に定義しがちです。このアダプタを使うと、画面遷移とデータ取得をかなりサーバ側に寄せられるので、クライアント側は「渡されたpropsをレンダリングするだけ」という薄い層になります。
新しい機能を足すときも、基本的にはHonoのルート定義と、対応するInertiaページの2か所だけ触ればOK。Viteのプラグインによって、サーバのルート文字列とフロントのページコンポーネントが型で結びつくので、「ルート名をtypoしててリンク切れてた」みたいな事故も防げます。
バリデーションまわりもよくできていて、zodのスキーマを1つ書けば、型定義と実行時バリデーション、エラーメッセージまで一元管理。フォーム送信でバリデーションに失敗した場合も、HTTP 422を返すんじゃなくて、同じフォームページを200 OKで返しつつ、入力値とエラー情報をpropsとして渡す、というスタイルを取っているので、エラー表示も「次に表示する画面のpropsをどう描くか」といういつものReactのノリで書けます。
結果として、RailsやLaravel的な「サーバが画面遷移を握っている」安心感を保ちつつ、フロントはReactで気持ちよく書ける、「the modern monolith」とも言いたくなる開発体験が得られた、というのがこの記事のまとめです。API設計とフロントの状態管理で疲弊している方には、かなり刺さりそうな内容ですね。
……というわけで、今日は5本の記事をご紹介しました。
おさらいすると、
・1本目は、Linuxカーネルの脆弱性「CopyFail」をAWSのUbuntuで実証した、かなり実務寄りのセキュリティ記事。
・2本目は、UIのつらさの正体はDB設計にあるんじゃないか、という視点から、Local-FirstなInstantDBを紹介した未来志向のWeb開発論。
・3本目は、Claude Codeを「新入社員」のように育てることで、開発体験を劇的に改善した、AIアシスタントとの付き合い方。
・4本目は、配列のクリア方法をNode.jsで実測して、GCとメモリリークのリアルな振る舞いを解説したパフォーマンス検証。
・5本目は、Hono × Inertia × Reactで、モダンなのにモノリシックな「新しいSPA体験」を得た、サーバ駆動フロントエンドの話。
どの記事も、詳しい内容や元のテキストへのリンクは、番組のショーノートにまとめてありますので、「気になる！」というものがあれば、ぜひそちらから飛んで読んでみてください。
この番組「zenncast」では、みなさんからの感想や、「このトピックを扱ってほしい」「この技術記事が面白かったよ」といったお便りも募集しています。普段どんなふうにZennの記事を活用しているのか、学び方の工夫なんかも教えてもらえるとうれしいです。
それでは、きょうも一日、良いコードと良いインシデントレスな運用に恵まれますように。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。