どうも、おはようございます。マイクです。
zenncast、2026年5月21日、木曜日の朝7時をちょっと過ぎたところでお届けしていきます。
この番組では、Zennに上がっているトレンドの記事をピックアップして、ラジオ感覚でゆるっと、でも中身はしっかりめにご紹介していきます。通勤・通学のおともに、コーヒー片手に、最後までお付き合いください。

今日はZennのトレンドから、全部で5本の記事をご紹介していきます。フロントエンド、AIツール、インフラ、セキュリティまで、なかなか濃いラインナップです。それぞれ噛み砕きながらお話ししていきますね。

まず1本目は「React CompilerをannotationモードとOxlintで漸進的に導入する」という記事です。
これね、React Compiler気になってるけど、「いきなり全ファイルに適用するのは怖いよ…」っていう現場のリアルにかなり寄り添った内容です。筆者のプロジェクトは、なんと約7,500ファイルのTypeScriptモノリス。最初は`compilationMode: "all"`で全部を対象にしたら、不具合がバンバン出てしまって、「これはダメだ」と。そこで方向転換して、`compilationMode: "annotation"`に切り替えます。
どうするかというと、`"use memo"`っていうディレクティブを書いたファイルだけ、React Compilerの対象にする方式にしたんですね。で、逆にTanStack Table v8とかreact-hook-formとか、まだCompilerと相性の悪いライブラリを使っているところは、`"use no memo"`を付けて「ここは触らないで」と明示。
さらに面白いのが、Oxlintを組み合わせて、従来のhooksルール違反だけじゃなく、React Compiler特有の非互換パターンもCIで検出できるようにしているところです。`react-hooks/*`と、jsPlugin経由の`react-hooks-js/*`を両方チェックして、「どこまでが安全にコンパイル対象にできるか」をPhase1で洗い出す。そしてPhase2では、新しく触るファイルから少しずつ`"use memo"`を増やしていく、難しいところは一旦`"use no memo"`で逃がす、というボーイスカウト方式。
最終的には、非互換ライブラリ側のアップデートを待ちつつ、`compilationMode: "all"`に寄せていくロードマップも描いていて、AGENTS.mdにルールを書いてAIエージェントにも同じ運用を守らせる、というのも今っぽいですよね。「でかいプロダクトにどうやってReact Compilerを入れていくか」が具体的に見える記事でした。

。。.。。.。.

続いて2本目。「GoogleのModern Web Guidanceスキル登場。AIが古いCSS・JSを書く問題を解決する」という記事です。
最近、「AIにフロント実装を書かせると、なんか古くさいCSSが出てくる…」って感じたことある方、多いと思います。float多用してたり、古いJS API推してきたり、アクセシビリティやセキュリティの配慮が薄かったり。これ、学習データにレガシーコードが大量に含まれてるので、どうしてもそうなりがちなんですよね。
そこでGoogleがI/O ’26で出してきたのが「Modern Web Guidance」。これは、UX、CSSレイアウト、パフォーマンス、フォーム＆UI、アクセシビリティ、そしてブラウザ内蔵AI、という6分野をカバーする「モダンWebの公式カンペ」をAIエージェントに読み込ませるためのスキルになっています。Baselineのリアルタイム互換情報を使って、「このAPIはもう安心して使えるよ」「ここはフォールバックこうしよう」みたいな提案もしてくれる。
導入もお手軽で、`npx modern-web-guidance@latest install`するだけで、Claude CodeとかCopilotみたいなツール側から、自動的に`search`や`retrieve`経由でこのガイドを参照してくれるようになるんですね。面白いのが、オフライン検索で完結するので、プライバシー面もかなり意識されているところ。
Googleの評価では、このスキルを入れる前は「モダンな実装ができていた率」が52%だったのが、85%まで上がったそうです。記事の筆者も自分のポートフォリオで試してみて、既にモダンに書いている部分の確認だけじゃなく、テーマ切り替えの改善やフォント調整、セキュリティ面のアップデート案までかなり具体的な提案がもらえたとのこと。
「AIに任せたら、よく分からないレガシーが混ざってた…」問題に対して、「じゃあAI側にモダンWebのベストプラクティスを注入しよう」という、かなり筋のいいアプローチだなと感じました。フロントエンドやってる方は、開発環境に一個入れておくと、だいぶ安心感が変わりそうです。

。。.。。.。.

3本目はAIコーディングエージェント界隈の話。「CodeRabbit が TAKT のスポンサーになりました：せっかくなので CodeRabbit と TAKT を共存させよう」という記事です。
TAKTっていうOSSのAIコーディングエージェントがあるんですが、これがAIレビューサービスのCodeRabbitからスポンサードされました。それをきっかけに、「じゃあTAKTのナレッジやポリシーをCodeRabbitにも読ませて、同じ基準でレビューさせよう」という実験をしてみた、という内容です。
やり方としては、`.coderabbit.yaml`の`knowledge_base.code_guidelines`に、TAKTが持っているfacetファイルを指定します。つまり、「うちのプロジェクトのコーディング規約、ここに全部あるから読んでおいてね」と渡すわけですね。その上で、検証用のPRを作って、意図的に「冗長な条件分岐」とか「外部変数をキャプチャするコールバック」とか「フォールバックの乱用」といった、独自のREJECTパターンを混ぜて、CodeRabbitの挙動を観察しています。
最初はprofileが`chill`だと、あんまり拾ってくれない。`assertive`にすると検出は増えるけど、それでも取りこぼしがある。そこで効いてきたのが、`reviews.path_instructions`の使い方です。ここに、「knowledge_baseのガイドラインを網羅的に参照しなさい」「差分の1ファイルごとに、各ルールを1つずつ照合しなさい」「どのガイドラインに基づいているか、毎回明示しなさい」みたいな手順をステップ形式で書いてあげた。すると、さっきの3つのREJECTパターンを、ちゃんとガイドラインの引用付きで全部指摘してくれるようになったそうです。
結論としては、`knowledge_base`は「規約の住所録」でしかなくて、「それを毎回どう使わせるか」は`path_instructions`でプロセスとして明示しないとダメ、っていう整理になっています。最終的な`.coderabbit.yaml`では、言語は日本語、profileは`assertive`、TAKTのfacet群をfilePatternsで登録して、`path_instructions`には特定ルールを書き連ねるんじゃなく、「facetを網羅参照させる手順」だけを書く、という構成に落ち着いたとのこと。
AIレビューツールに自社の品質基準をなじませたいチームには、かなり参考になる実験だと思います。「ナレッジ渡したのに、なんか活かしてくれないな…」と感じている方は、`path_instructions`周りを見直すヒントになりそうです。

。。.。。.。.

4本目は、ローカルLLM好きにはたまらない話。「Gemma 4 E4Bをローカルで量子化してみた」という記事です。
筆者の環境はMacBook ProのM2 Pro、メモリ32GB。このマシン上で、Gemma 4 E4B-itというモデルをllama.cppとGGUF形式を使ってQ4_K_M量子化してみた、という記録です。事前に量子化ってそもそも何？とか、Q4_K_Mってどういう意味？GGUFって？みたいな基礎を、他の記事で学んだうえでチャレンジしています。
手順としては、まずllama.cppをMetal対応でビルドして、uvでPython環境を整備。Hugging Faceに認証して、元のモデル、約16GBを取得。それを`convert_hf_to_gguf.py`でBF16のGGUFに変換すると、だいたい14GBくらい。それをさらに`llama-quantize`でQ4_K_Mに量子化して、約5GBまで圧縮しています。
ログを追いながら、「4bitって言っても、全部が一律4bitになるわけじゃないんだな」とか、「重要な層はもう少し高い精度を残しているんだな」といった理解も得られたそうです。性能面では、`llama-bench`でF16と比較すると、プロンプトの処理速度はやや落ちるものの、生成速度はおよそ2倍。実際の対話テストでも、いくつかの推論問題にきちんと正答していて、「なるほど、これなら普段使いもいけそうだ」という手応え。
全体を通して、「量子化って難しそう」と感じている人に対して、「実はコマンドいくつか叩くだけでここまでできるよ」「ファイルサイズがここまで小さくなって、速度もこう変わるよ」というのが体感ベースで伝わる記事になっています。一方で、精度劣化の定量評価や、Q5やQ8、あるいはMLXとの比較などはまだこれからの課題と正直に書かれていて、そのあたりも好感が持てました。ローカルでLLMを回してみたい方の、最初の一歩の参考になりそうです。

。。.。。.。.

そして5本目。「tfstateに平文を残さずに秘密情報を管理する」という、インフラ・セキュリティ寄りの記事です。
Terraformを使うとき、SOPS×KMSの組み合わせで秘密情報を暗号化したままGitに置ける、というのはよく知られたやり方ですよね。ただ従来の`data "sops_file"`で参照するパターンだと、復号した平文がtfstateやplanファイルに書き込まれてしまう。つまり、state backendにアクセスできる権限があれば、全部のSecretsが見放題になっちゃう問題があります。しかもCloudTrailでの監査もしづらい。
この記事では、Terraform 1.11から入ったephemeral resourceと、AWS Providerのwrite-only属性、具体的には`secret_string_wo`を組み合わせて、「復号した値も、Secrets Managerに送る値も、どっちもtfstateやplanに残さない」構成を紹介しています。
ephemeral resourceは「実行中だけ値を持って、永続化しない」タイプのリソースで、さらに`sensitive`を付けるとCLIの出力にも出さないようにできます。一方でwrite-only属性は、値をAWSには送るけど、stateには保存しない。なので、「今の値とstate上の値を比較して差分を検出する」という普通のやり方が通用しなくなります。そこで`*_version`みたいな属性を持たせて、それをインクリメントすることで「更新のトリガー」を自前で作る必要が出てくる。
既存環境からの移行についても、注意点が丁寧に書かれていて、過去のtfstateに残っている平文は自動では消えてくれない、とか、`secret_string`から`secret_string_wo`に変えるとリソースの置き換えが発生するかもしれないので、そのタイミングでsecretのローテーションも一緒にやるのがおすすめ、などなど。
まとめると、「Terraformは使い続けたい、でもtfstateやplanに平文を一切残したくない」という現場に対して、TerraformとAWSの新しい機能をフル活用した、かなり実践的なレシピになっています。インフラ担当の方は、セキュリティレビューで突っ込まれる前に、ぜひ目を通しておきたい内容ですね。

というわけで、今日は
・React CompilerをannotationモードとOxlintで段階的に導入する話
・AIにモダンWebの知識を注入するModern Web Guidance
・TAKTのナレッジをCodeRabbitにも使ってレビューを揃える工夫
・Gemma 4 E4BをMacで量子化してローカルLLMを試した記録
・Terraformでtfstateに平文を残さずSecretsを扱うテクニック
この5本をご紹介してきました。

気になる記事があった方は、詳しい内容や元の記事へのリンクはショーノートにまとめてありますので、ぜひそちらもチェックしてみてください。番組の感想や、「こんな記事を取り上げてほしい」「こういうテーマで特集してほしい」といったリクエストも大歓迎です。あなたの開発現場のモヤモヤや発見なんかも、ぜひ教えてください。

それでは、そろそろお別れの時間です。
zenncast、お相手はマイクでした。
また次回の配信でお会いしましょう。それでは、いってらっしゃい。