どうもー、おはようございます。ラジオ「zenncast」パーソナリティのマイクです。
2026年4月9日、木曜日の朝7時になりました。みなさん、今日も一日が始まりましたが、いかがお過ごしでしょうか。通勤・通学の電車の中、あるいはおうちで支度をしながら聴いてくれているあなたに、今日もZennのトレンド記事をゆるっと、でもがっつり紹介していきたいと思います。

今日はですね、全部で5本の記事を紹介していきます。プロダクト開発やAIエージェント、Vimの最新機能、セキュリティ、そしてGitHub Copilot CLIの学習コースまで、かなり幅広いラインナップです。気になるところだけつまみ食いしてもOKなので、耳だけ貸してもらえたらうれしいです。

まず1本目。
タイトルは「デザインシステムを丸ごと Skills にする」。
これはサイボウズのkintone Design Systemを、AIエージェント向けに「MCP」ではなく「Skills」として提供した、という事例の紹介です。MCPって、段階的に情報を出せるのが便利なんだけど、サーバ立てたり運用したり、あとコンテキストがすぐパンパンになる、という悩みがあったんですよね。そこで登場するのがSkills。nameとdescriptionがあって、そこから必要になったらSKILL.md、さらに必要ならreferences…という感じで、AIが「必要なときに必要な情報だけ取りに行く」という仕組みになっています。
kintone Design System自体は、ドキュメントとコードが単一リポジトリにまとまっていて、階層ごとにREADME.mdxが整理されている、とても整った構造。そのリポジトリをローカルにキャッシュして、「どこを辿れば何がわかるのか」だけをSKILL.mdに書く、いわば“ナビゲーションスキル”を作ったという話なんですね。
このやり方が面白いのは、提供側は既存のリポジトリ構造をそのまま活かしつつ、ほとんどSKILL.mdを書くだけで済むこと。そして使う側もサーバ要らずで、ローカルにスキルを入れればよい、という手軽さ。結果として、人間とAIの両方にとって「役割ごとのフォルダ構造」「階層ごとのREADME」「Markdownドキュメントとコードが共存する整理されたリポジトリ」が、めちゃくちゃ重要だよね、という再確認にもつながった、と。
「AIに読ませること」を前提に、情報設計やリポジトリ設計を見直すヒントがギュッと詰まった記事でした。自分のチームのドキュメント構造、大丈夫かな…とちょっとドキっとする人もいるかもしれません。

。。.。。.。・。

続いて2本目。
タイトルは「Vim の春コーデ — 透け見せの着こなし」。
もうタイトルのセンスが最高なんですけど、内容はガチです。Vimにポップアップウィンドウと補完メニュー、いわゆるpumですね、それらに半透明機能が入ったよ、というアップデートの解説記事です。
ポップアップウィンドウには `opacity` というオプションがついて、0〜100で透過度を指定できるようになりました。`termguicolors` を有効にしていると、背景色とキレイにブレンドされて描画されるので、補完メニューとかヘルプウィンドウが「ドンッ」と前面を占拠するんじゃなくて、ちょっと“透け感”のある、春っぽい軽い見た目になるわけですね。Neovimの `winblend` を使ったことがある人は、なんとなくイメージしやすいかも。ただ、実装の仕様は少し違うそうです。
記事では、単に「設定はこうです」だけじゃなくて、ワイド文字の扱いとか、分割ウィンドウとの兼ね合い、あとWindowsコンソールでのチラつきをどう抑えたか、など、実装上の苦労話もたっぷり語られています。`pumopt=opacity:50` みたいに設定することで、補完メニューにだけ半透明をかけることも可能。すでにvim-lspなどのプラグインが対応し始めていて、これをきっかけに「Vimって見た目地味」というイメージが少し変わるかもしれません。
ビジュアル面にそこまでこだわらないVimユーザーも多いと思いますが、「情報量はそのままに、視覚のノイズを少し減らす」という意味で、半透明のポップアップは意外と集中力アップに効くかもしれません。最新のVimでぜひ試してみてください。

。。.。。.。・。

3本目。
タイトルは「脆弱性対応と minimumReleaseAge を両立しながら依存管理をクリーンに保つ」。
npmまわりのセキュリティと依存管理に頭を抱えている人には、めちゃくちゃ刺さる内容です。pnpmには `minimumReleaseAge` という機能があって、「出たばかりの新バージョンは、しばらく経つまで入れない」という“冷却期間”を設けることができます。サプライチェーン攻撃が増えている今、これ自体はかなり有効な対策なんですが、一方で「脆弱性を直したいときに、その修正版までブロックされちゃう」というジレンマが出てきます。
特にややこしいのが、推移的依存の脆弱性。直接依存してないパッケージの脆弱性を直すために、`overrides` でバージョンを固定したり、`minimumReleaseAgeExclude` で例外指定したりして、緊急対応をすることになります。ただ、これを手動でやると、いつの間にか不要になったoverrideが残りっぱなしになって、依存関係がどんどんカオスになっていくんですよね。
この記事の作者は、ここを自動化しました。GitHub Actionsで毎日 `pnpm audit --json` を叩いて、その中の `patched_versions` 情報をもとに、「今、必要なoverrideとexcludeはどれか？」をゼロベースで再計算する仕組みを作ったんです。その結果を自動PRで投げることで、`minimumReleaseAge` によるブロックを必要なところだけ解除しつつ、いらなくなったoverrideはどんどん消していく。RenovateやDependabotではカバーしきれない、セキュリティ対応とクリーンな依存管理を両立させるための“裏方オーケストレーション”みたいな役割ですね。
dependency hellに悩んでいるチームにとって、「人間が覚えておくこと」を極力減らして、ツールに任せる方向性を示してくれる記事になっています。

。。.。。.。・。

4本目。
タイトルは「GitHub App の秘密鍵を AWS KMS に閉じ込める」。
こちらは、セキュリティ沼の、さらに核心に踏み込んだ話です。Trivyなどの侵害事例で明らかになったように、GitHub Actionsの設定ミスや、サードパーティアクションの侵害が起きると、GitHub Secretsに入っているシークレットが全部抜かれてしまう可能性があるんですよね。
特にヤバいのが、GitHub Appの秘密鍵。これは有効期限のない“マスターキー”的な存在で、一度漏れたらそのAppを丸ごと乗っ取られてしまう可能性があります。Secretsにそのまま入れておく構成は、かなりリスキーだと。
この記事のアプローチは、「秘密鍵をランナーに渡さない」という発想です。秘密鍵そのものはAWS KMSにインポートして閉じ込めておき、GitHub ActionsからはKMSのSign APIだけを使ってJWTに署名する、という専用アクションを実装しています。つまりランナー側は“署名してもらう”ことしかできず、鍵の中身は一切読めない。“sign-only”な運用ですね。
さらにIAMポリシーやKMSの鍵ポリシー、そしてOIDCのクレームを組み合わせることで、「このリポジトリの、このワークフローからのリクエストだけ署名を許可する」といった、かなり細かい絞り込みも可能になります。あわせて、トークン権限の指定を必須にすることで、なんでもできちゃう“フル権限トークン”を発行させないようにもできる。
導入ステップも現実的で、KMS鍵を作って秘密鍵をインポートし、この署名用アクションをワークフローに差し込むだけ。後ろの処理（GitHub AppとしてのAPI呼び出し）は今までどおりでOKです。
「Secretsに入れずに、そもそも盗めない構造にする」という発想の転換が参考になる記事でした。GitHub App運用しているチームは、一度自分たちの構成とリスクを見直すきっかけになると思います。

。。.。。.。・।

そして5本目。
タイトルは「GitHub Copilot CLIを"タダ"で体系的に学べるコースをやってみた」。
これは、GitHubが提供している無料教材「GitHub Copilot CLI for Beginners」を実際に受講してみて、その内容をレポートした記事です。書籍管理のCLIアプリを題材に、全8章・5〜6時間ぐらいで、インストールから基本の使い方、開発ワークフローへの組み込み方まで、一通り学べるコースになっています。
内容としては、3つのインタラクションモードの使い分け、`@`でコンテキストを明示指定するやり方、コードレビューやテスト生成にCopilot CLIをどう活かすか、といった実践的な話が中心。さらに、カスタムエージェントとスキルの定義、MCPとの連携までカバーしていて、「とりあえず補完してくれるツール」から一歩進んで、「自分のワークフローに組み込まれたAI開発パートナー」に育てていくためのヒントが盛りだくさんです。
CLI版ならではの強みとして、コンテキストを明示的にコントロールしやすいこと、ProgrammaticモードでCI/CDにも組み込めること、SSH先のリモート環境でも同じように使えること、そしてエージェントやスキル、MCP定義をファイルとしてGit管理できて、チームで共有しやすいことが挙げられています。
記事では、最初の入口として「まずはREADMEだけ日本語化してみる」といった学習のコツや、`/fleet` `/compact` `/review` `/delegate` `/rewind` など、知っておくと便利なスラッシュコマンドもたくさん紹介されています。Copilot CLI自体がかなりのハイペースで進化しているので、バージョンごとの新機能や、使えるモデル一覧をチェックするリンクも貼られていました。
「英語だし、どこから手をつけていいか分からない」という人にとって、この無料コースはかなり良いガイドになりそうですし、チームで一緒に受けて「Copilotの使い方を標準化する」なんていう使い方もアリだと思います。

。。.。。.。・。

というわけで、今日のzenncastは、
AIエージェント向けにデザインシステムをSkillsとして提供した話、
Vimに入った“透け感”のある新しい見た目の機能、
pnpmのminimumReleaseAgeと脆弱性対応を両立する依存管理の工夫、
GitHub Appの秘密鍵をAWS KMSに閉じ込めて守るセキュリティの取り組み、
そしてGitHub Copilot CLIを無料コースで体系的に学んでみた体験記、
この5本を駆け足でお届けしました。

気になった記事があれば、ぜひショーノートから元の記事もチェックしてみてください。ここでは触れきれなかった細かい設定例や図解、コードの断片なんかも、記事本編にはたっぷり載っています。

番組「zenncast」では、聴いてくださっている皆さんからの感想や、取り上げてほしいテーマ、Zennで見つけたオススメ記事のタレコミなんかもお待ちしています。「こんな記事面白かったよ」「ここもう少し深掘りしてほしい」といった一言でも、マイクの励みになります。

それでは、そろそろお時間です。
今日も良い一日をお過ごしください。お相手はマイクでした。
また次回のzenncastでお会いしましょう。ではでは。