おはようございます！「zenncast」、MCのマイクです。今日は10月21日、水曜日。朝7時、皆さん、いかがお過ごしでしょうか。
今日もZennでトレンドの記事から、開発の現場で役立つ話題をお届けします。ツールの移行からサイトの点検、AIとの付き合い方まで、今日ご紹介する記事は全部で5本です。それでは、さっそくいきましょう！
....
まず1本目は、コードをチェックするlinterと、見た目を整えるformatterの移行についてのお話です。
移行先を選ぶとき、処理の速さは気になりますよね。でも、この記事で大切にしているのは、それだけではありません。既存のコードの整形や並び順を、きちんと保てるかどうかも選定のポイントなんです。
記事では、独自のTailwind CSSクラスまで同じ順番に整えられる、OxlintとOxfmtの組み合わせを採用。チェックにかかる時間を、約9.3秒から約3秒に短縮したそうです。
そして、もう1つの軸が、開発の規約を「機械で守れる形」に分けること。並び順などはformatterで自動修正し、禁止したimportなどはlinterで検出する。文書には、機械では判断できない規約や、その規約が必要な理由を残す、という整理です。
エラーメッセージの書き方にも工夫があります。「これは禁止です」で終わらせず、禁止する理由と、代わりにどう書けばいいかを伝えるんですね。これなら、人間もAIも、別の文書を探しに行かずに修正できます。エラーが、そのまま次の行動の案内になるわけです。
ただし、移行やルール追加は一度に大きく進めず、小さく分けて変更内容を確認します。自動修正によってコードの意味が変わる場合もあるので、型チェックとテストも実行することが大切です。
移行前には、既存ルールが移行先で対応しているか、そして有効・無効の設定がどうなっているかも確認します。Oxfmtはバージョンを固定し、更新時には整形結果に違いが出ないかチェックする。速さを手に入れつつ、これまでのコードとの連続性も守る、丁寧な移行の話でした。
....
続いて2本目は、自分が管理するサイトのHTTPヘッダーを点検したお話です。
記事では、Nucleiによる低負荷な技術判定と、curlによるHTTPヘッダーの確認を行っています。ここで最初に押さえておきたいのが、「使われている技術がわかった」ことと、「脆弱性が見つかった」ことは別だという点です。技術を検出しただけで、危険だと決めつけないんですね。
今回のEmDash環境で注目されたのは、Server-Timingというヘッダーでした。ここから、データベースの処理やキャッシュ、プラグインなど、内部処理の計測情報が公開されていたそうです。確認するときは、HEADリクエストだけでなく、GETリクエストでも調べています。
公開する必要がないと判断した情報は、依存ライブラリを直接編集するのではなく、Cloudflare Workerで、レスポンスを返す直前のヘッダーから削除しました。内部の計測処理そのものは残して、外に返す情報だけを調整する方法です。
修正後はビルドと型チェックを行い、専用ブランチとPRで変更を分離。本番に反映したあともcurlを使って、対象のヘッダーが消えているか、そして必要なヘッダーは残っているかを確認します。消すべきものだけ消せているか、最後まで見るわけですね。
ただ、Server-Timing自体は正当な機能です。削除すれば、それだけでサイトが安全になるわけではありません。今回の確認対象も一部のURLに限られています。認証や更新、アクセス制御などの対策は、別途必要です。
何を公開しているのかを確かめて、必要性を判断し、変更後も確認する。この一連の進め方が参考になる記事です。
....
ここから3本目です。テーマは、これからのエンジニアにとってのAIエンジニアリングです。
AIの活用は、製品の機能だけでなく、日々の開発作業にも広がっています。そのなかで、AIエンジニアリングは専門職だけのものではなく、多くのエンジニアが身につけるスキルになってきている、と記事では捉えています。
筆者が中心に置いているのは、評価と失敗分析を繰り返すことです。AIは、出力が毎回変わるもの。だからこそ、結果を評価して、うまくいかなかった原因を分析し、改善につなげることが大切なんですね。
そのためには、AIにどんな情報を渡すか、どこまで任せるかを整える必要があります。そして、人が結果を確認し、責任を持つ仕組みも欠かせません。
第一歩は、身近な作業の出力を評価して、改善してみること。いきなり大きな仕組みを作るのではなく、普段の仕事のなかで、AIの結果を見直すところから始められる。そんな、取り組みの入り口を示してくれる内容です。
....
続いて4本目は、JavaScriptの実行エンジン、V8の高速化のお話です。
Chromiumで使われているV8で、配列を同じ値で埋めるArray.prototype.fillが改善されました。ポイントは、要素ごとに繰り返していた重複処理を省くこと。記事の実測では、整数で最大約7.4倍、doubleで約5倍の高速化が確認されています。
では、具体的に何を変えたのでしょうか。
まず、V8が値を直接格納できる整数であるSmiです。これまでは要素を1つずつ汎用的な処理で書き換えていましたが、MemsetTaggedを使い、まとめて埋めるようにしました。
次に、倍精度浮動小数点数のdoubleです。こちらは、要素ごとに毎回行っていた値の変換を、最初の1回だけに変更。その変換結果を各要素へ書き込むようにしています。同じ値を入れるのだから、同じ変換を何度も行う必要はない、という改善ですね。
一方、オブジェクトについては変更していません。オブジェクトの書き込みでは、メモリ管理の仕組みに対して、書き込んだことを知らせる処理が必要だからです。
また、高速化の効果は、配列の種類や長さによって異なります。例えば、16要素の整数配列では約1.3倍でした。どんな配列でも最大約7.4倍になる、というわけではない点には注意したいですね。
繰り返しのなかから不要な処理を取り除く。その積み重ねが、実行エンジンの大きな性能改善につながる、興味深いお話でした。
....
最後、5本目は、Claude Codeの「アイドル圧縮」についてです。
これは、長い会話をしばらく放置したとき、キャッシュの有効期限が切れる前に、会話を自動で要約する機能です。対象はターミナルでの対話。既定では、20万トークン以上の会話を約54分放置すると動作し、次に入力した際、会話全体を処理し直す負担を減らします。
筆者の実測では、55.6分後に圧縮が行われ、27万2,422トークンが1万3,522トークンになったそうです。さらに、過去のログでも、同様の動作が3件確認されています。数字だけ見ると、かなりコンパクトになっていますね。
ただし、ここは続きも大切です。作業を再開した際には、ファイルの読み直しなどが入り、約9万5千トークンになっていました。
また、この機能を無効にした場合との差や、実際にどれだけ使用量を削減できたのかまでは確認できていません。会話が圧縮されたことと、最終的な使用量がどれだけ減ったかは、分けて考える必要があるんですね。
自動要約が動く条件と、その実測結果、そしてまだ確認できていないこと。その範囲を押さえて読んでおきたい記事です。
....
さて、今日のzenncastは、5本の記事をご紹介しました。
OxlintとOxfmtへの丁寧な移行、HTTPヘッダーと公開情報の点検、評価と失敗分析を軸にしたAIエンジニアリング、V8の配列処理の高速化、そしてClaude Codeのアイドル圧縮。開発を速く、扱いやすくする工夫と、その効果をきちんと確かめる姿勢が印象に残りましたね。
詳しい内容はショーノートに書いてありますので、気になった話題はぜひチェックしてみてください。
それでは、次回も皆さんにお会いできるのを楽しみにしています。番組の感想も、ぜひお寄せくださいね。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価をつけてもらえるとうれしいです！
お相手はマイクでした。今日も、よい1日をお過ごしください！