どうもー、おはようございます。マイクです。
時刻は朝7時をちょっと回ったところ、2026年3月21日、土曜日の朝です。
ここからの時間は「zenncast」、今日もゆるっとお届けしていきます。
この番組では、技術情報プラットフォーム「Zenn」に上がっている、いまホットな記事たちをピックアップしてご紹介していきます。通勤・通学のお供に、作業前のウォーミングアップに、耳だけでもぜひお付き合いください。
今日は、Zennのトレンド記事をぜんぶで5本、ご紹介していきます。
フロントエンドのスタイリングの話から、Obsidianを使った情報整理術、開発環境の整え方、GoのDockerまわりの最新ベストプラクティス、そして最後はJava・Go・Rust・Kotlinのガチ比較まで、幅広く揃ってますので、気になるところだけつまみ食いしてもOKです。
それでは、1本目からいきましょう。
1本目は
「業務アプリのフロントエンド負債と向き合い、Tailwind CSS から Panda CSS への移行を決めた話」
という記事です。
Next.jsとTypeScriptとTailwind CSSで作られた社内の業務アプリで、「なんか画面ごとに雰囲気違うなぁ」とか、「ちょっとしたスタイル変更が意外とつらいぞ」という問題がだんだん表面化してきた、というところから始まるお話です。
原因として挙げられているのが、まずコンポーネントの設計粒度が粗くて、細かい見た目の調整が各画面でバラバラに行われていたこと。そして、Tailwindのユーティリティクラスを、実装者のセンス任せでペタペタ書いていった結果、デザイントークンもあまり活用されず、「同じような見た目なのに別の指定をしている」という状態があちこちで発生してしまったことですね。
さらに、Tailwindって基本的には文字列クラスを組み合わせていくスタイルなので、「型で守られていない」ことによるツラさもあったと。ルールを決めてLintやレビューでがんばる、という手もあるけれど、それだとどうしても人力の限界があって、「設計やデザインの一貫性を仕組みで担保したいよね」という問題意識があったそうです。
そこで検討に上がったのが、Tailwindを続投するのか、vanilla-extractに寄せるのか、あるいは別の選択肢を取るのか、という選定。そして最終的に選ばれたのが Panda CSS。
決め手になったのが、Pandaの`strictTokens`という機能で、「定義されたデザイントークン以外は使えない」ようにできる点。これによって、「とりあえず #333 とか px 指定で…」みたいな、後々負債になりがちなスタイルを、型レベルで防げるようになります。
さらに、バリアントやSlot Recipeといった仕組みで、コンポーネントの内部構造をパターンとしてきちんと定義できるので、UIの一貫性や変更のしやすさがぐっと上がる。しかも型安全なので、今後AIのコーディングエージェントにスタイル実装を手伝ってもらうときにも、ルールを破りにくい、というのがポイントとして語られています。
もちろん良い点だけではなくて、Panda CSSのエコシステムの小ささや、チーム全体でトークン設計をちゃんとやるコスト、移行に伴う学習コストはちゃんと認識した上で、「それでも、この先を考えると型で守られた世界に寄せる価値のほうが大きいよね」という結論に至ったそうです。
個人的には、「ルールを文章で決めて人に守らせる」のではなく、「型と仕組みで守らせる」という発想が、まさに2026年っぽいなと感じました。Tailwindの便利さは捨てがたいけれど、チーム開発での運用を考えるなら、こういう”逃げ道を塞ぐ”仕組みはかなり効いてきそうです。今まさにスタイル負債に悩んでいるチームには、かなり刺さる記事だと思います。
。。，。，。。
続いて2本目。
「タスク管理もミーティングメモも Obsidian に自動で集まる仕組みを作った」
という記事です。
これは、日々の「タスク・議事録・日報・メモ」をObsidianで一元管理したい、でも毎回ノートを作って予定を写して…という手作業がしんどい、というところから、「できるだけ自動で集まるようにしちゃおう」と工夫した事例です。
まずはVaultのフォルダ構成を用途ごとに分けつつ、その中でも「2_Daily」という、日ごとのノートを置く場所を中心に据えています。ここでは、ObsidianのDaily NotesプラグインとTemplater、それからICSプラグインを組み合わせて、毎日のノートを自動生成するようにしているんですね。
工夫のひとつ目が、前日の未完了タスクを自動で引き継ぐ仕組み。最大7日前までさかのぼって、終わっていないタスクを拾ってきて、今日のノートの「Tasks Left」や「Daily Tasks」にまとめてくれます。「昨日のToDoどこ行ったっけ？」と探さなくてよくなるわけです。
ふたつ目が、Googleカレンダーの予定をICS経由で取得し、自動で今日のタスクリストに載せてくれるところ。毎日あるようなルーチンミーティングは除外して、本当にタスク性のある予定だけをDaily Tasksに追加。これによって、「今日なんか予定あったっけ？」をObsidianのノートだけ見れば把握できるようになります。
さらに面白いのが、ミーティングメモの自動取り込み。
Google Meetで行われた会議については、Geminiが自動でまとめてくれたメモがGoogle Drive上に.docxで保存されますよね。これを、rcloneとpandocを使ったPythonスクリプトで10分おきにチェックし、新しいファイルがあればMarkdownに変換して、Obsidianの「5_Work」フォルダに保存していく、という流れを作っています。
ファイル名には日付やタイトルをきれいに整形して付け直しつつ、内容も「まとめ」と「詳細」のセクションに絞って抽出。すでに同名のファイルがあればスキップして、重複も防いでいます。結果として、「会議が終わったら、勝手にObsidianの中に議事録が増えている」という状態になるわけですね。
一方で、限界もちゃんと書かれていて、Google Meet以外の会議はカバーできないとか、会議中に自分でもObsidianに直接メモを取ると、似たようなノートが二重にできてしまう問題もあると。ただ、それでも「手で全部やるよりは圧倒的に楽」と割り切って運用しているそうです。
Obsidianを「なんとなくメモ帳」として使っている方にとっては、「ここまで自動化できるのか」と目からウロコかもしれません。タスクとカレンダー、議事録が1箇所にまとまっていると、仕事の見通しもかなりよくなりますよね。
。。，。，。。
では3本目。
「個人的開発環境 2026春」
という記事です。
こちらは、新しくM5 MacBook Proを支給されたことをきっかけに、著者がzshの環境をゼロから整え直した、そのセットアップ手順と工夫をまとめたものになっています。いわゆる「dotfiles公開系」なんですが、2026年の今っぽいツール選定がまとまっていて、環境構築のヒントとしてかなり読みやすい内容です。
方針としては、設定はすべてdotfilesリポジトリで管理して、シンボリックリンクで各種設定ファイルに反映するスタイル。新しいマシンを手に入れたら、そのリポジトリを落としてきて、サクッと同じ環境を再現できるようにしています。
インストールしている主なツールとしては、Homebrew経由で、
・sheldon（zshプラグインマネージャ）
・fzf（ファジーファインダー）
・zoxide（賢いディレクトリ移動）
・atuin（履歴検索の強化）
・starship（高速でリッチなプロンプト）
・mise（ランタイムマネージャ）
・gitui（TUIのGitクライアント）
・gh（GitHub CLI）
あたりを入れていて、フォントはHackGen Nerdをターミナルに設定しています。
運用のイメージとしては、例えば`Ctrl+q`を押すと、zoxideのディレクトリ履歴をfzfで絞り込みつつサクッと移動できたり、`Ctrl+r`でatuinのリッチな履歴検索が使えたりと、「よくやる操作」をショートカットにガッと寄せている感じですね。プロンプトはstarshipを使うことで、今いるGitブランチや、miseで有効になっている言語バージョンなんかを、見やすい形で表示してくれます。
`.zshrc`側では、これらツールの初期化処理に加えて、`g=gitui`みたいなエイリアスも定義していて、「とりあえずターミナル開いてgって打てばGitの状態を一覧で確認できる」という、実務寄りのチューニングがされているのがポイントです。プラグイン周りはsheldonで管理しつつ、zsh-autosuggestionsやzsh-syntax-highlightingを入れて、コマンド補完や色分けも強化しています。
結びとして、「dotfilesでちゃんと管理しておくと、新しいマシンへの引っ越しが本当にラクになるよ」という話が書かれていて、これに首を縦に振るエンジニア、多いんじゃないでしょうか。これからMacの開発環境を作り直そうかな、という方には、かなり良い参考例になりそうです。
。。，。，。。
4本目にいきましょう。
「令和最新版 GoでのDockerfile / Docker Composeの書き方」
という記事です。
タイトル通り、Goアプリケーション向けのDockerfileと、Docker Composeの”いまどきのベストプラクティス”を整理した内容になっています。昔の情報のまま手が止まっている方ほど、「あ、もうその書き方いらないんだ」みたいな発見があると思います。
まずDockerfileについては、マルチステージビルドを前提としつつ、本番で使う実行イメージにはAlpineではなくDistrolessを推奨しています。特にnonrootイメージを使うことで、セキュリティと最小限のランタイム環境を両立しつつ、Trivyやcosignなどのツールでのスキャン・検証もしやすくしておきましょう、という話ですね。
イメージの指定も、単なるタグではなく「ダイジェストで固定する」ことが推奨されています。これによって、同じタグでも中身が変わってしまう、いわゆる”タグの揺れ”による事故を防ぎ、Renovateなどのツールで安全に更新管理ができるようになります。
ビルドの高速化やキャッシュ戦略についてもかなり踏み込んでいて、BuildKitのbind mountとcache mountを活用することで、go.modやgo.sum、ソースコードを一時的にコンテナ側へマウントし、`COPY`でレイヤーに乗せない書き方を紹介しています。これによってレイヤー汚染を防ぎつつ、キャッシュも効かせやすくなり、CIのビルドが速くなる、というわけですね。
そのために、Dockerfileの先頭でsyntax宣言と、`# check=error=true`によるBuild Checkを設定しておくこと、`.dockerignore`をきちんと用意して不要なファイルをビルドコンテキストに含めないことも、”令和最新版”のポイントとして解説されています。
Goコンパイル時のオプションについても、バージョンごとの事情に触れながら、1.22以降であれば`-ldflags`は基本`-s`だけでよく、1.16以降は`-mod=readonly`をわざわざ付けなくてもよいなど、「昔からの慣習で付けているけど、もう要らないもの」が整理されているのがありがたいです。
Composeのほうは、ファイル名は`compose.yaml`に統一し、`version`キーは書かない、コマンドは`docker compose`（スペースありのほう）を使いましょう、という、公式寄りのスタイルに揃える話が中心です。記事の最後には、開発用（AirやDelve入り）と本番用を分けたDockerfile、それからGoサーバとPostgresを起動するcompose.yamlの実例が載っているので、「理屈はわかったけど、具体的な書き方が見たい」というニーズにも応えてくれています。
普段からなんとなくコピペでDockerfileを書いている方は、一度この記事で自分のファイルを棚卸ししてみると、「あ、ここ直せるな」というポイントが見つかると思います。
。。，。，。。
そして最後、5本目。
「Java歴21年のエンジニアが同じAPIをJava・Go・Rust・Kotlinで実装して徹底比較した」
という記事です。
これはかなり読み応えのある企画で、同じ仕様のAPIサーバーを、
・Java / Spring Boot
・Go
・Rust
・Kotlin / Ktor
の4つで実装して、性能、メモリ使用量、起動時間、ビルド時間、コード量といった観点でガチ比較している内容になっています。
まずパフォーマンス面でのチャンピオンはRust。
スループットも高く、p99を含む全パーセンタイルのレイテンシも優秀で、メモリ効率もよく、成果物のサイズも小さい。そのうえコード量も少なめに抑えられたという結果が出ています。一方で欠点としては、とにかくビルド時間が長い。そこは「強いけど重い」武器を振り回している感じですね。
Goはというと、コールドスタートの速さが圧倒的で、起動時間は69msとほぼ一瞬。スループットも十分に高く、そして言語自体の学習コストも低めなので、サービスインまでのスピード感や、運用・保守のしやすさという観点ではかなりバランスが取れている、という評価になっています。
Kotlinは、スループットやp50レイテンシではGoといい勝負をしているものの、p99レイテンシやメモリ消費、特にZGC利用時の重さがネックになっていると分析されています。Java / Springと比べると起動は速いものの、やはりJVM系の重さはある程度ついて回る、という感じですね。
Java / Spring Bootは、やはり長年のエコシステムの強さと、ビルドの速さ、ライブラリの豊富さが大きな利点として挙げられていますが、その一方でメモリ効率や起動時間では、今回の比較対象の中では不利な面が目立つ結果になっています。
面白いのが、単純に「どれが一番速いか」ではなく、「用途別にどれが向いているか」を整理しているところです。
・巨大なエコシステムと既存資産をフル活用したいならJava
・開発スピードと運用のしやすさを重視するならGo
・インフラコスト削減や高い型安全性を重視するならRust
・JVMのエコシステムを活かしつつモダンな言語を使いたいならKotlin
といった具合に、「どの軸で最適化したいか」で選ぼう、というメッセージになっています。
筆者自身は、少人数で長期運用する基幹サービスのコスト最適化を何より大事にしていて、その条件だとRustがもっともフィットすると判断し、実際に本番環境をRustへ移行したそうです。Java歴21年のエンジニアが、ちゃんとデータと運用目線の両方から判断してRustに舵を切った、というストーリーに説得力があります。
言語選定ってどうしても宗教戦争っぽくなりがちなんですが、こうやって冷静に数字を取って比較すると、「自分たちのプロダクトなら何を優先するべきか」を考えるいい材料になりますね。
。。，。，。。
というわけで、今日はZennのトレンド記事を5本ご紹介しました。
ざっとおさらいすると、
1本目は、Tailwind CSSで膨らんだスタイル負債に向き合って、型安全なPanda CSSへの移行を決めた話。
2本目は、タスクとカレンダー、ミーティングメモをObsidianに自動で集約する仕組みづくり。
3本目は、2026年春版のMac zsh開発環境構築メモ、dotfiles管理とモダンなCLIツールの組み合わせ。
4本目は、Go向けDockerfile / Composeの、DistrolessやBuildKitを前提にした令和最新版の書き方。
5本目は、Java・Go・Rust・Kotlinで同じAPIを実装して、性能から運用まで徹底比較した結果、Rustに移行した話。
気になった記事があれば、このあとショーノートにタイトルをまとめておきますので、ゆっくり読み返してみてください。
番組「zenncast」では、みなさんからの感想や質問もお待ちしています。
「こんなテーマを取り上げてほしい」「この記事も面白かったよ」などなど、ゆるい一言でも大歓迎です。
それでは、そろそろお別れの時間です。
ここまでのお相手はマイクでした。
次回のzenncastで、またお会いしましょう。
今日も良い一日をお過ごしください。