どうも、おはようございます。マイクです。
「zenncast」2026年6月1日、月曜日の朝7時を回りました。
この番組は、技術記事プラットフォーム Zenn に上がっているトレンド記事を、朝イチでサクッとチェックしていくラジオです。通勤・通学のおともに、作業前のウォーミングアップに、ゆるっと聞いていってください。
今日は、Zennで話題になっている記事を、全部で5本ご紹介していきます。
開発環境の整え方から、個人開発のリアル、Terraform運用の悩み、Ubuntuを使い込んだ話、そしてGitHub Copilotの新機能まで、幅広くピックアップしてますよ。
ではさっそく、今日紹介する1本目。
タイトルは「yadm + mise で dotfiles 環境構築を整理する」。
複数マシンやコンテナで、いつもの開発環境をサッと再現したい……これ、エンジニアあるあるですよね。
筆者の方は、いままでシンボリックリンクを手で貼ったり、自作スクリプトをメンテしたりしていたそうなんですが、「環境差も出るし、再現性も低いし、つらいぞ」と。そこで、dotfiles 管理を yadm と mise によせて、思い切って再構成しています。
要件は、ユーザー権限だけでセットアップできて、1〜2分で終わって、学習コストも維持コストも低いこと。
yadm は `$HOME` そのものを Git で管理できる軽量な dotfiles マネージャー。mise は、言語ランタイムや開発ツールをユーザー権限でまとめて入れられるパッケージマネージャーですね。
構成がおもしろくて、まず `curl | bash` 一発で yadm のセットアップとリポジトリの clone までやってしまう。そのあと、yadm の bootstrap と mise で必要なツールを一気に入れる、という二段階構成になっています。
さらに工夫として、sparse-checkout で `$HOME` に不要なファイルを置かないようにしたり、Neovim から yadm 管理ファイルを普通の Git リポジトリとして扱えるように環境変数で調整したり、OSごと・環境ごとの設定切り替えを yadm alternates でやったり、と運用の細かいところまできちんと整えているのがポイント。
「手動作業を減らす」「自作スクリプトをノリで増やさない」って、長く開発やってるとすごく効いてくるんですよね。
環境構築に毎回30分かけてる人は、こういう仕組みを一度ちゃんと作っておくと、数ヶ月後の自分にめちゃくちゃ感謝されると思います。
。。.。。.。。.。.
続いて2本目。
タイトルは「CodexでFlutterアプリを3か月未満で公開したけど、今どきの個人開発はコード以外が大変すぎる」。
OpenAI Codex を使って、Flutter 製のクラウド連携ギャラリーアプリを作って、87日で Google Play 公開まで行った、というお話です。
「AI × Flutterですごいスピードで実装進んだぞ！」という成功談かと思いきや、実はそこから先がめちゃくちゃ大変だった、というのがこの話の核ですね。
具体的には、Google OAuth の審査で、Cloudflare の Bot 対策が邪魔してしまったり、その設定を緩める必要が出てきたり。
それから、YouTube に権限の使い方を説明する動画を用意しろとか、Google データの扱いを細かく書いたプライバシーポリシーを用意しろとか、とにかく「コード以外の準備」が山盛り。
さらに、クローズドテストで12人のテスターを集めるところも、技術じゃなくて「お願い力」が問われる。家族・友人・会社・DM……人間関係総動員で、なんとか人数を揃えていく感じですね。
そして一番刺さるのが、奥さんからの「編集できないから使えない」というシンプルなフィードバック。そこから2週間かけて、文字入れやモザイクなどの簡単な編集機能を追加して、コードは一気にボリュームアップ。
最終的には本番環境利用申請や製品申請も通ったんですが、筆者が強調しているのは、「実装はCodexで加速できたけど、公開準備の負荷はむしろ増えてる」という点です。
ストアの審査や約款・規約を書く作業、動画作成、テスター集め……こういう泥臭いところまで含めて「個人開発」だよね、という現代のリアルが、かなり生々しく書かれています。
。。.。。.。。.。.
3本目。
タイトルは「全部Terraformで管理してはいけない？『かつての最適解』が生んだ管理の壁と、私たちが引き直した境界線」。
SRE 視点での、Terraform 運用の悩みと、その解決に向けた設計の話です。
舞台になっている会社では、「インフラはすべてTerraformで厳密に管理、手動変更は禁止！」という、ある意味とても真面目な運用をしていたんですね。
ところが、ECS タスク定義の環境変数をちょっと追加したい、みたいな軽微な変更でも、SE が Jira でチケットを切って、SRE が対応して、3環境に展開して……と、めちゃめちゃ重いフローになってしまった。
結果として、SE 側の開発スピードも落ちるし、SRE 側も定型的なチケット対応に追われて、基盤の改善に手が回らない。かなり「もったいない」状態になっていたわけです。
その原因として挙げられているのが、「静的リソース」と「動的リソース」を同じ Terraform で一元管理していたこと。
VPC や DB みたいに、そんなに頻繁に変えないものと、ECS タスク定義や環境変数みたいに、頻繁に更新されるもの。
このライフサイクルの違いを無視して、一つの枠組みに押し込んでいたのが問題だった、と分析しています。
そこで方針転換。インフラのコード（静）と、デプロイのコード（動）を分ける。
特に「動」の部分をアプリケーション側のリポジトリで管理して、SE 自身が自律的にデプロイできるようにする。
一部プロダクトでこれを導入した結果、Jira 経由の待ち時間がほぼ消えて、変更が数分〜数十分で完了するようになり、SRE も「ひたすらチケットをさばく係」から解放されつつあるそうです。
とはいえ、会社の中には多様なプロダクトがあるので、このモデルをどう横展開するかは、まだまだ技術的・組織的なチャレンジとのこと。
記事の最後では、SRE として全体最適や開発体験の向上に取り組む仲間を東京拠点で募集している、というメッセージも添えられていて、現場の空気感が伝わってきます。
。。.。。.。。.。.
4本目。
タイトルは「Ubuntu 26.04 LTS を1ヶ月使って感じたメリット6選」。
長年 Windows や macOS を使ってきた筆者が、「OSに触れない領域があること」にモヤモヤしていたところから、Ubuntu 26.04 LTS を1ヶ月メイン機として使ってみて感じたことをまとめた記事です。
Linux の大きな魅力として挙げられているのが、「OSの深部まで開かれている」感じ。
設定やプロセス、入力レイヤーまで自由に触れて、「必要なことはだいたい何でも、自分の手の届くところにある」という安心感ですね。
アプリ面でも、必要なフリーソフトはだいたい揃うし、足りないところは自分で簡単なGUIツールをこしらえることもできる。
マウスやキーボードの挙動、ワークスペースの切り替え方、日本語入力のキーマップなどまで細かくカスタマイズできて、しかも動作の劣化も少ないから、ほとんど再起動の必要を感じない、と。
さらに、KVM を使った仮想環境構築も高速かつ柔軟で、環境全体をスクリプトや dotfiles として再現・自動化しやすいのも大きなメリット。
要は「いじれる範囲が広いから、仕組みを理解して、自分好みに組み直せる」っていう楽しさですね。
もちろん課題もあって、IME の精度、Wayland 特有の制約、特に AMD ノートでの電源管理まわりにはまだ難しさがある、とも正直に書かれています。
それでも、「いらないものはそぎ落として、必要なものだけ自分で組み上げる」という、“引き算の美学”を体現できるOSとして、Linux、特にUbuntuを高く評価しているのが印象的でした。
「最近ちょっとLinux気になってるんだよな」という人には、背中を押してくれるような内容になっていると思います。
。。.。。.。。.。.
ラスト、5本目。
タイトルは「GitHub Copilot app で rubber-duck が既定有効になったので考えたこと」。
GitHub Copilot app のバージョン 0.2.14 で、rubber-duck というエージェントが、デフォルトで有効になった、という話題です。
この rubber-duck は、コードを書いてくれるわけではなくて、設計や実装に対して建設的なフィードバックをくれる“批評役”のエージェント。
コマンド `/rubber-duck` で呼び出せるようになっています。
元になっているのは、ラバーダック・デバッグの考え方ですね。
「自分が書いたコードや設計を、アヒルのおもちゃに向かって説明していると、頭が整理されてバグに気づく」という、あの有名なやつです。
それを AI にやらせて、「実装するエージェント」とは独立した“ツッコミ役”を挟めるようにしたのが、この rubber-duck という位置づけ。
1つのエージェントに、実装とレビューの両方を任せると、「最初に立てた前提」をそのまま引きずってしまって、設計の抜けや誤りに気づきにくくなるんですよね。
そこで、計画・実装・テスト・PR などの要所で、短く `/rubber-duck` を呼び出して、「その設計で責務ちゃんと分かれてる？」「ここテスト観点足りなくない？」「セキュリティ的にここ大丈夫？」みたいな観点を挟んでもらう。
筆者は、これまでも Reviewer 的なエージェントを手作業で用意していたそうなんですが、GitHub Copilot app の中で、CLI と同じように「作業の途中でサクッと相談する」体験として組み込めるようになったのを高く評価しています。
「実装する」「レビューする」「相談する」のうち、特に“相談する”を習慣化しやすくなるのがいいところだ、と。
もちろん、これで誤りが完全になくなるわけではないし、最終判断はあくまで開発者自身が持つべきだ、というスタンスも忘れていません。
そのうえで、「独立した批評者をワンコマンドで呼べる」というのは、開発プロセスの質を底上げする、けっこう大きな変化だよね、という結論になっています。
。。.。。.。。.。.
そろそろお別れの時間です。
今日は、全部で5本の記事をご紹介しました。
1本目は、yadm と mise を組み合わせて、dotfiles と開発環境構築をサクッと再現できるようにしたお話。
2本目は、Codex でFlutterアプリを高速開発したものの、公開までの「コード以外」がとにかく大変だったという、個人開発のリアル。
3本目は、全部Terraformで管理する運用から、「静的なインフラ」と「動的なデプロイコード」を分け直したSRE チームの取り組み。
4本目は、Ubuntu 26.04 LTS を1ヶ月メインで使ってみてわかった、「なんでも自分で触れる」Linuxの魅力と課題。
そして5本目は、GitHub Copilot app にデフォルトで入った rubber-duck エージェントを、どう開発フローに組み込んでいくか、というお話でした。
気になった記事があれば、詳しい内容はこの番組のショーノートにまとめてありますので、そちらから元の記事もチェックしてみてください。
「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」「最近こんなことで悩んでます」といったお便りもお待ちしています。
朝の作業用BGM代わりに聞いている方も、通勤中に聞いている方も、ふと思ったことがあれば、ぜひ気軽に送ってください。
というわけで、ここまでのお相手はマイクでした。
次回の配信で、また一緒に最新のZennトレンドを追いかけていきましょう。
それでは、いってらっしゃい。