おはようございます。今朝も始まりました「zenncast」、パーソナリティのマイクです。
今日は2026年2月6日、金曜日の朝7時台です。みなさん、いかがお過ごしでしょうか。通勤・通学中の方も、おうちでゆっくりしている方も、これからZennで話題になっているトレンド記事を一緒にチェックしていきましょう。

今日は全部で5本の記事をご紹介します。セキュリティ、AWSのネットワーク、そして今ホットなClaude Codeの機能解説に、Windowsアプリ開発のDX向上まで、かなり幅広いラインナップになっています。

まず1本目。タイトルは「現在のパスキーは単一障害点である」。
パスキーって「パスワードレスで安全！」みたいなイメージが強いんですが、その裏側の危うさを真正面から指摘している記事です。多くのサービスは「パスキー＝それだけで十分に安全」と見なして、TOTPとか従来の二要素認証をパスキー利用時にはスキップしがちなんですね。ところが実際の実装、たとえばiCloudキーチェーン、Googleパスワードマネージャー、1Passwordといった主要どころは、基本クラウド同期前提。ローカル専用で「この端末からしか使えません」という保存オプションが用意されていない。
そうすると何が起きるかというと、Appleアカウントみたいな“親玉アカウント”を乗っ取られた瞬間、そのアカウント経由で同期されているパスキーの秘密鍵が、攻撃者のデバイスにも同期されてしまう可能性がある。結果として、各サービス側で「パスキーのときは2FA省略」と設計していると、その“親玉1発”が単一障害点になって、芋づる式に突破されてしまうかもしれない……という構図です。
本来WebAuthnの仕様上は、クラウド同期されるパスキーか、デバイス限定かっていう情報は区別できるようになっているので、「同期パスキーのときは追加認証を必須にする」とか、設計上いろいろ工夫ができるはずなんですね。でも現状、多くのサービスはそのフラグを見ていなかったり、クライアント側で「ローカル専用にしてくれ」と指定する術がなかったりする。
そこで著者は、自分で「じゃあローカル限定のパスキー環境、作るしかないじゃん」ということで、macOS向けの「LocalPasskey」というアプリを開発しています。Secure Enclaveの中に同期不可・抽出不可の形で鍵を作って、生体認証を必須にして使う設計。Apple側の実装の問題で一部メタデータがうまく伝わらない部分はあるけれど、セキュリティ自体には影響しないように作っているそうです。
記事全体としては、「パスキーは便利だけど、設計次第で単一障害点になりうるんだよ」という注意喚起と、「Appleやブラウザ側で、ちゃんとローカル専用パスキーを公式にサポートしてほしい」という提言が軸になっています。パスワードレスにワクワクしているエンジニアほど、一度読んでおきたい内容ですね。

。。。。

続いて2本目。タイトルは「[AWS] VPCエンドポイントを作っただけなのに」。
AWSやってる人なら、「あ〜〜そのタイトルだけで事故の匂いがする…」ってなるやつです。新サービス用に、ECRにアクセスするためのVPCエンドポイントを作ったら、なぜか既存サービスのECSデプロイが落ち始める、という実録記事ですね。
ポイントは「プライベートDNSを有効にしたVPCエンドポイントの影響範囲」です。著者のケースでは、新しいサブネットで新サービス用のVPCエンドポイントを作ったつもりが、プライベートDNSが有効になっていたために、「そのVPC全体」でECRの名前解決がエンドポイント経由に切り替わってしまった。結果として、既存サービスからECRへのimage pullも、全部そのVPCエンドポイントに流れ込むことになります。
ところが、そのエンドポイントのセキュリティグループは「新サービスのECSタスクからのアクセスだけ許可」みたいに絞って設定していたので、既存サービスのタスクからのアクセスはバッサリ遮断。ECRに行きたいのに、VPCエンドポイントの門番に止められてしまってデプロイ失敗、というわけです。
解決策としてはシンプルで、VPCエンドポイントのインバウンドルールを見直して、「新旧どちらのECSタスクのセキュリティグループも許可する」ように変更。これで無事にimage pullが通るようになりました。
教訓としては、「プライベートDNS有効にしたVPCエンドポイントは、サブネット単位じゃなくて“VPC全体”に効く」という点をちゃんと理解しておくこと。そして、新しくエンドポイントを増やすときには、既存通信の経路がどう変わるのか、DNSレベルでの影響も含めて設計しないと痛い目を見るよ、という話でした。AWSネットワーク構成をいじる人は、身に覚えがあるか、もしくはこれから身に覚えができるタイプの事例だと思います。

。。。。

3本目。タイトルは「Claude Code Hooksを遊び倒す｜海外勢のネタ設定が面白すぎた」。
Claude CodeのHooks機能、lintやformat自動化みたいな真面目な用途はもちろんなんですが、海外コミュニティは「遊び心」に全振りした使い方をしていて、それをまとめて紹介してくれている記事です。
たとえば通知・エンタメ系。特定のイベントが起きたときに効果音を鳴らす「Voice Hooks」、パーミッション要求があるときに「モ〜〜」って牛の鳴き声が鳴る「Moo Plugin」、待ち時間にエレベーターのBGMを流す「Elevator Music」、集中しすぎたときに瞑想アプリを自動表示する「Clauditate」、タスク完了を音声で読み上げてくれるTTS通知などなど…。IDEの中でこんなに遊んでいいのか、というノリですね。
一方で、実用寄りのアイデアもかなり充実しています。編集後に自動でgit addしてくれるHookや、セッション終了時に自動コミットする仕組み、セッションごとにGitブランチを分けてくれるフロー、さらにはJujutsuと連携して変更管理を強化する例など。「人間がサボりがちなバージョン管理まわりを、エージェントとHooksで肩代わりさせる」という発想です。
さらに高度なところでは、セッション開始時にGitHub IssuesやCIステータスを読み込んで、その日のタスク状況を自動で把握するとか、サブエージェントの開始・終了のログをきっちり取る仕組み。面白いのが、巨大ファイルや多数ファイルの操作を、自動でGeminiに委譲しちゃう「Claude-Gemini Bridge」なんてネタも挙がっている点です。エージェント同士でいい感じに“分業”させようという発想ですね。
また、雑なプロンプトを検知して「その指示だと曖昧だけど大丈夫？」とClarify質問を出してくれる「Prompt Improver」的なHooksも紹介されていて、「プロンプト設計を機械に支援させる」っていう視点も面白いです。
筆者自身が「特に試したい」と挙げているのが、TTS通知、セッション別ブランチ管理、Claude-Gemini Bridge、通知音カスタマイズあたり。Hooksはグローバルやプロジェクト単位のsettings.jsonで設定できて、まずは通知系から入ると理解しやすい、と締めくくっています。Claude Codeを触っている方は、真面目な自動化に行く前に、ちょっとふざけたHooksを入れて遊んでみるのもおすすめです。

。。。。

4本目。タイトルは「2026年初頭のClaude Code Skillsについてまとめる」。
こちらは同じくClaude Codeの中でも、「Skills」機能がこの1年ちょっとでどう変化してきたのかを、時系列で整理した記事です。Claude Codeの拡張って、Rules、Commands、Skills、Subagentsの4つが出てくるんですが、それぞれの役割がバージョンアップのたびに微妙に変わってきているんですよね。
Skillsが登場したのは2025年10月ごろで、「Composable/Portable/Efficient/Powerful」な専門知識モジュールとして導入されました。当初は、Rulesは最初から読み込まれる不変ルール、Commandsはコマンド的な指示、Skillsは必要なときに読み込む専門知識、Subagentsは別人格のエージェント、というきれいな棲み分けがありました。
ところがその後のアップデートで、だんだん境界が曖昧になってきます。v2.0.43ではSubagentsが、起動時に特定のSkillsを読み込めるようになり、さらにv2.1.0でSkillsに「context: fork」や「agent」フロントマターが追加されて、「これもうサブエージェントみたいに動いてない…？」という状態に。極めつけはv2.1.3でCommandsとSkillsが統合されて、CommandsがほぼSkillsのライト版、ラッパーのような存在になってしまったことで、筆者自身は「もうSKILL.md中心で管理した方が分かりやすい」と判断したそうです。
現在の整理としては、Rulesは初期ロードされる変わらないルールセット、Skillsは必要に応じて読み込む専門知識モジュール、という大枠は維持しつつ、Subagentsとはこうやって使い分けよう、という提案がされています。具体的には、「参照用SkillsはSubagents側のskillsフロントマターで展開して読ませる」「タスク実行を任せたいSkillsは、agentフロントマターでどの実行エージェントを使うか指定する」といった具合ですね。
総じて、Skillsは今やClaude Code拡張の“中核”になりつつあるけれど、RulesとSubagentsとは責務をうまく分離したまま進化しているのが面白い、とまとめられています。最近Claude Codeを触り始めた人が「RulesとSkillsとSubagents、どれに何を書けばいいの？」と迷ったときの、地図代わりになる記事だと思います。

。。。。

そして最後、5本目。タイトルは「【続編】WindowsアプリUI開発はもうつらくない！ Blazor × Tailwind CSS完全版」。
Windowsデスクトップアプリで、WPF上のBlazor WebViewを使ってUIを作る。そのうえで、Tailwind CSSをJITモードで回しながら、.NET Hot Reloadともちゃんと共存させる、というかなり実践的なノウハウをまとめた記事です。
問題の出発点は、Hot Reloadが/wwwroot配下の静的ファイルの変更を監視できない、という仕様。Tailwind CLIがJITでCSSを生成しても、その更新がBlazor側に自動で反映されないんですね。そこで著者は、3段構成の仕組みでこれを解決しています。
まず1つ目は、「アプリ起動・終了に合わせてTailwind CLIをプロセスとして起動／停止」する仕組み。アプリを立ち上げたらTailwindの監視ビルドも一緒に立ち上げ、閉じたら止める、という連携です。
2つ目は、MetadataUpdateHandlerAttributeを使った「HotReloadHandler」。これはHot Reloadが発火したタイミングをフックして、Razor側へイベント通知を飛ばす役割を持たせています。
3つ目が、CssHotReloadSync.razorコンポーネント。ここでイベントを受け取ったら、JavaScriptのreloadCss関数を呼んで、該当CSSファイルのlink要素にクエリパラメータを付けてキャッシュバスターにし、ブラウザ的に再読み込みさせる、という流れ。これによって「C#側のHot Reload」と「TailwindのCSS更新」が一体となって、React＋Tailwindで開発しているかのような体験に近づけています。
さらに記事では、.csprojにDownloadFileやExecターゲットを追加して、Tailwind CLIやdaisyUIをビルド時に自動ダウンロード・ビルドする方法にも触れています。これによって、新しい開発環境を用意するときにも「npm install地獄」にならず、プロジェクトをクローンしてビルドすれば必要なツールが揃う構成にできる。加えて、Razorでもちゃんと効くTailwind IntelliSenseの設定方法も紹介されていて、「XAMLつらいけどWeb技術ならいける」という人にとっては、かなり救いになる記事です。
WindowsアプリのUIを、Webフロントの知識で気持ちよく作りたい人には、ぜひ一度読んでほしい内容ですね。

。。。。

というわけで、今日は5本の記事をご紹介しました。
1本目は、パスキーがクラウド同期前提だと単一障害点になりうる、というセキュリティの指摘と、ローカル専用パスキー「LocalPasskey」の話。
2本目は、VPCエンドポイントにプライベートDNSを有効化したことで既存ECSデプロイが巻き込まれた、AWSネットワーク設計の落とし穴。
3本目は、Claude Code Hooksで通知音からGit連携、Geminiブリッジまで、海外勢の遊び心あふれる活用例の紹介。
4本目は、Claude CodeのSkillsがこの1年でどう変化して、RulesやSubagentsとどう棲み分けられているか、というまとめ。
そして5本目は、WPF＋Blazor WebView＋Tailwind CSS＋Hot Reloadを気持ちよく共存させて、WindowsアプリUIのDXを上げるための実践テクニックでした。

気になる記事があった方は、詳しい内容は番組のショーノートにまとめてありますので、あとでゆっくりチェックしてみてください。
「zenncast」では、番組の感想や「こんなテーマを取り上げてほしい」といったリクエストも随時募集しています。Zennで気になった記事や、「この記事解説してほしい！」というネタも大歓迎です。

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