はいどうもー、おはようございます！マイクです。
「zenncast」2026年3月13日、金曜日の朝7時をまわりました。
今日もZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。通勤や通学の支度をしながら、コーヒー片手に、耳だけ貸してもらえたらうれしいです。

今日は、全部で5本の記事を紹介していきます。
データベースの話から、AIで朝刊を自動生成する仕組み、Reactの状態管理、UIジェネレーターの裏側、そして「バグが気づいた頃にはもう直ってる」夢のようなワークフローまで、かなりバラエティ豊かなラインナップです。それぞれ500文字くらいで、サクッと本質をお届けしていきますね。

まず1本目。
タイトルは「MySQLが好きな私が、今はPostgreSQLを勧めたい理由」。
筆者の方は、もともと筋金入りのMySQL派なんですが、クラウド前提で最新のMySQLとPostgreSQLを比べ直してみた結果、「新規開発なら、いまはPostgreSQLを推したい」という結論に至った、というお話です。
昔よく言われていた「PostgreSQLは運用が重い」とか「DDLやレプリケーションが扱いづらい」といった懸念は、機能向上や各社のマネージドサービスのおかげで、だいぶ重要度が下がってきている。一方で、アプリケーション実装のしやすさという観点では、PostgreSQLならではの強みがまだまだ効いてくるんですね。
例えば、一意制約に引っかかったときだけ安全に無視できる `ON CONFLICT DO NOTHING` 的な挙動や、更新と同時に結果を1文で取れる `RETURNING`、小さな定数表をサクッと扱える `VALUES`。さらに、Window関数＋`WITH`＋`UPDATE ... FROM` を組み合わせた高度な更新処理、ソフトデリートと相性の良い部分インデックス、テストや移行をしやすくする遅延制約付きの外部キー、最近だと `pgvector` によるベクトル検索など。「アプリの素直な実装」を後押ししてくれる仕掛けが豊富なんですね。
MySQL 8で機能差はかなり詰まってきたけれど、「両方よく知った上で、いま新規で選ぶならPostgreSQLかな」という、落ち着いた視点が印象的でした。MySQLをディスるというより、「道具箱の選択肢が増えたよね」という前向きな記事です。

。。。。

続いて2本目。
タイトルは「Claude Codeで自分好みの朝刊が届く仕組みを作った」。
これ、個人的にめちゃくちゃ刺さりました。技術ニュースを追いかけてると、「気づいたら1時間溶けてた…」ってよくあると思うんですけど、それを自動化してくれちゃう仕組みの話です。
著者は、Claude Codeのカスタムコマンドと、macOSの `launchd` を組み合わせて、毎朝6時に自動でITニュースを収集・整理する「自分専用の朝刊システム」を作っています。Qiita・Zenn・はてブ・Hacker News はWebFetchで、RedditやYouTubeは標準ライブラリだけのPythonスクリプトで取得。Xや一般ニュース系はWebSearch、といった具合にソースごとに最適な取り方を分けているのがポイント。
取得した情報はカテゴリ別のMarkdownにまとめられて、直近7日分からgrepでURLを拾って重複排除する仕組みも入ってます。さらに、`launchd` からシェルスクリプト経由で `claude -p` を呼び出しつつ、設定ファイルで使うツールだけを事前許可しておくことで、完全無人で朝刊が生成される。
運用しながら見つけた工夫もたくさん紹介されていて、ブロックされがちなドメインだけPython側に逃がしたり、自動実行とプレビュー用の実行を分けたり、ログをちゃんと残したり。おもしろいのは「ホーム直下に必要ファイルをまとめておいて、権限トラブルを避ける」といった、かなり実務寄りのノウハウまで書かれている点です。これをベースに、自分の興味ジャンルに合わせてカスタマイズしたくなりますね。

。。。。

3本目いきましょう。
タイトルは「Reactでsignalsは必要ない、Jotaiがあるから」。
最近、UIフレームワーク界隈では「signals」がホットワードになっていますが、それをReactの世界に無理に持ち込まなくても、Jotaiがあれば十分じゃない？という提案です。
筆者は、signalsの価値を「reactive primitives」と「diffingバイパス」という2つの観点から整理しています。React自体、stateが変わると再レンダーされるリアクティブな仕組みを持っていて、`useState` でプリミティブな状態は扱える。ただ、それがコンポーネントローカルに閉じてしまうので、複数のコンポーネントで共有しようとすると、props の受け渡しや context が必要になりがちです。
そこでJotaiの出番。Jotaiはatomという単位で状態を定義して、`useAtom` で読み書きするスタイルをとることで、「共有できるreactive primitives」をReactのフックの流儀のまま提供してくれます。さらに、Providerごとに状態を切り分けられるので、サブツリー単位で独立したストアを持つことも簡単。
一方で、signalsのもうひとつのウリである「diffingをバイパスして局所的に最適化する」側面については、Reactが大事にしてきた宣言的UIの思想と相性がよくないのでは、と指摘します。部分的なパフォーマンス改善のために、挙動が読みづらくなるリスクを負うのはどうなのか、と。技術実験としての `jotai-signal` は面白いけれど、ふつうのReactアプリなら、素直に `useAtom` を使っていけば充分で、「signalsがないから困る」と感じる場面はかなり減るはずだ、という結論になっています。

。。。。

4本目。
タイトルは「時計アイコンを精密につくるツールを開発した（迫真）」。
これはプロダクトそのものだけじゃなく、「ジェネレーターを作ることの大変さ」にスポットライトを当てた記事です。
著者は、Illustratorいらずで時計アイコンを作れるツールを自作し、短針・長針の長さや角度、太さ、文字盤の細かい目盛り、破線の領域、色など、とにかく細かくパラメーターを調整できるようにしています。その結果、「アイコン本体を作るより、そのUIを作るほうが10倍むずかしかった」と感じたそうです。
何が大変かというと、まず大量のパラメーター定義が必要になる。それを全部UIのスライダーやカラーピッカーに対応させて、双方向に値を同期させて…となると、一気に複雑さが増していきます。著者は、そのパラメーター群を「ジェネレーターの基盤となるモデル層」と位置づけていて、「ここをちゃんと設計しないと、表面のUIもSVGの描画も綺麗に作れない」と振り返っています。
技術的なポイントとしては、精密なバウンディングボックスを取る際に、SVGのgetBBoxに頼らず、canvasを使ったほうがよかった、という結論も紹介されています。また、図形そのものの構造とTransformをきちんと分離する設計が重要だという話もあって、グラフィックス系やエディタ系のツールを作りたい人にとっては、かなり実践的な知見です。最後は「自動車を作るより工場を作るほうが難しい」という例えで締めくくられていて、「アイコンみたいな成果物より、それを量産するシステムづくりのほうがはるかに複雑だよ」というメッセージが刺さります。

。。。。

そしてラスト5本目。
タイトルは「バグチケットに気づく頃にはもう直っている仕組みを作った」。
これは夢がありますね。GitHub Issueに「QA-bug」というラベルが付いた瞬間に、Claude Code Actionが自動で動き出して、バグ内容を解析し、修正コードを書いて、PRまで投げてくれる、という仕組みのお話です。
従来だと、エンジニアはチケットを確認して、再現して、原因を追って、修正して、PRを作って…という一連の流れを全部自分でやっていたわけですが、この仕組みだと、「起票されたと同時に、AIが修正案を出したPRを用意してくれる」。人間は、そのPRをレビューしてOK出す、もしくはちょっと手直しするだけで済む。文言の修正やレイアウトの細かいズレみたいな軽微なバグほど、効果が大きいですね。
著者が強調しているのは、「AIが修正してくれること」そのものよりも、「人間の作業中断やコンテキストスイッチを極限まで減らすこと」に本質がある、という点です。GitHub Actionsとしてパイプラインに組み込まれることで、これまで属人的だったプロンプトもリポジトリに残って共有されるようになり、チームとしてAI活用を育てていける副次効果も生まれています。
その結果、「仕様さえ書けばPMも実装できるんじゃないか」とか、「翻訳テキストの更新も同じように自動入稿できそう」といった、次の自動化アイデアにもつながっている。一方で、今後のボトルネックとして、「大量に生成されるPRのレビューや品質保証をどうするのか」という問題も出てきます。特にコードレビューについては、その役割を細かく分解して、どこまでAIに任せられるかを探っていくと、将来的には今のようなコードレビューという儀式自体が自然になくなるかもしれない、という未来像も示されています。品質検証をどう設計するかは、別記事で扱っていく予定のようです。

というわけで、今日の「zenncast」は、
1本目「MySQL好きだけど、いまはPostgreSQLを推したい理由」、
2本目「Claude Codeで自分専用の朝刊を自動生成する仕組み」、
3本目「Reactでsignalsはいらない、Jotaiで十分じゃない？」、
4本目「時計アイコンジェネレーター開発から見えた、工場づくりの難しさ」、
5本目「QA-bugラベルを起点に、AIがPRまで自動で出してくれるワークフロー」、
この5本を駆け足でご紹介しました。

気になった記事があれば、詳しい内容はショーノートにまとめてありますので、あとでゆっくりチェックしてみてください。
番組の感想や、「こんなテーマ取り上げてほしい」といったリクエストも、どしどしお待ちしています。マイクへの質問でも大歓迎です。

それでは、そろそろお別れの時間です。
ここまでのお相手はマイクでした。
次回の「zenncast」でまたお会いしましょう。
今日も良い一日を！