どうも、おはようございます。zenncastパーソナリティのマイクです。
今日は2026年4月24日、金曜日の朝7時を少し回ったところですね。
この時間は、Zennで話題になっているトレンド記事を、エンジニアのみなさんと一緒にゆるっと追いかけていきます。

さて今日は、全部で5本の記事をご紹介します。
フロントエンドの構成の話から、AIを活用した要件定義、バンドルサイズ削減、Swiftの新機能チェック、そしてRTX 5090での最新大規模言語モデル検証まで、技術好きにはたまらないラインナップになってます。

それでは、1本目からいきましょう。

まず1つ目は「Next.js を SSG 化しようとして、最終的に React SPA に落ち着いた理由」という記事です。
もともと、受注ハックというサービスを、Next.js を ECS Fargate 上で常駐させて、その横に独立した Go のAPIサーバーを置く、というよくある構成で動かしていたそうなんですね。で、「サーバー常駐コストを下げたいぞ」ということで、Next.js を SSG や static export に寄せていこうと検討を始めた。
ところが、実際のアプリ構造を洗い出してみると、routing が完全に「pages router 前提」で、動的なIDやトークン、クエリ依存のページが多くて、「ページ単位で静的出力しましょう」というモデルと全然噛み合わない。実態としては、単一のエントリーポイントから runtime で解釈する、完全にSPA的な世界観のほうが自然だったんですね。
そこで、「だったらNextじゃなくてよくない？」という発想に至って、Vite + React Router を使った、素の React SPA に移行していきます。この移行の過程で、いきなりフルリプレースではなくて、`next/*` の shim を用意して互換レイヤーをつくり、既存コードを少しずつ置き換えていったのがポイント。routing、metadata、middleware、API Routes といった「Next.js がランタイムで担っていた役割」を整理し直して、フロントは静的アセットとして Cloudflare Workers からSPA fallback付きで配信、認証やステージング保護は Cloudflare Zero Trust に寄せ、バックエンドは Go API に一本化する構成に落ち着いたそうです。
結論として、「SSRやNextのAPI Routesにそこまで依存していない、クライアント中心のアプリなら、無理やりSSG化を頑張るより、素直にSPAとして再設計したほうが筋がいいよね」という話になっていて、「Nextありき」で考えがちな構成を一歩引いて見直す、いいケーススタディになっています。

。。。。

続いて2つ目は、「優秀なAI専門チームと爆速で高品質に仕上げる要件定義 — PMのためのClaude Code × AIエージェント実践ガイド」という記事です。
プロジェクトマネージャーのみなさん、要件定義って、判断そのものよりも「書き起こす」「漏れチェック」「用語そろえる」「調査する」みたいな作業がいちばんしんどくないですか？というところから始まる内容です。
この記事では、その「判断の前後」にある作業を、Claude Code の Skill と Sub Agent にできるだけ任せて、PMは「Why、何をなぜ作るのか」に集中しよう、というワークフローが提案されています。具体的には、Design Doc を生成するSkillと、「調査担当」「レビュー担当」「文書整形担当」「顧客視点での評価担当」といった複数のSub Agentを組み合わせることで、ヒアリングの内容から叩き台のドキュメントを自動生成し、自動でセルフレビューまで回す。これで、初稿を起こすまでの時間をかなり短縮しつつ、抜け漏れや用語のブレも減らしていくわけですね。
カギになっているのは3つで、まず1つ目が「関連ドキュメントをプロジェクトフォルダに集約して、AIのコンテキストに載せられる状態を作ること」。2つ目が「自社フォーマットとか、過去の失敗知見をSkillに組み込んで、使いながらアップデートしていくこと」。そして3つ目が「AIが出してきたエビデンスは、PM側が一次情報にあたって必ず裏取りすること」。ここをサボると、いくらすばらしい“AI専門チーム”を組んだつもりでも、根拠の弱い仕様書が量産されてしまうんですよね。
導入ステップとしては、まずClaude Codeを小さく触ってみて、プロジェクト直下に `CLAUDE.md` を置いて、この番組でいうところの「こういうしゃべり方してね」みたいな指示を書いていく。そこから徐々にSkillやSub Agentを一緒に設計していく流れが紹介されています。要件定義の「白紙から書くのがつらい」をAIに肩代わりさせて、人間側は「どちらを選ぶべきか」という判断に集中するための具体的な工夫がまとまっている記事でした。

。。。。

3つ目は、「Next.js (Turbopack) のバンドルサイズを元の半分まで削減した話」という、パフォーマンスチューニング好きにはたまらない記事です。
Next.js と Turbopack を使ったアプリで、「どのページを開いても巨大な共通チャンクが読み込まれてしまう」という構造的な問題にぶつかった、というところからスタートします。本来ならログイン画面みたいな軽いページはサクッと出てほしいのに、裏では大量のJavaScriptがロードされていて、体感がどうしても重くなる。
原因を掘っていくと、まず1つ目は lodash をフル import していて、tree-shaking が全然効いていなかったこと。2つ目が、自前で作ったUIライブラリの“バレル export”、つまり `index.ts` から `export *` して全部まとめて出していたせいで、特定機能だけが使う重い依存までが芋づる式に共通チャンクに入ってしまっていたこと。さらに、依存の向きも崩れていて、「下位層が上位層に依存する」みたいな逆向き依存も混ざっていた結果、共通チャンクがどんどん太っていった、という構図です。
対策としては、lodash は個別 import に切り替え、サードパーティパッケージの最適化は `optimizePackageImports` に任せる。自前のバレル export は思い切って全廃し、ESLintで再発を防止するルールを入れる。そして逆向き依存を整理して、本当に共通で使うロジックは下位の層におろし、上の層からだけ参照する、という健全な依存関係に組み替えていきます。
この結果、共通チャンクを中心にバンドルサイズが約半分まで削減されて、初回表示や静的ページの速度、開発時のFast Refreshの体感もかなり改善されたそうです。分析には `next experimental-analyze` を使って、「どのimportチェーンがどのチャンクに影響しているか」を可視化しながら、AIに調査や仮説立案、修正案の叩き台づくりを手伝ってもらった、という話も出てきます。「なんか重いな……」で止まらずに、チャンク構造と依存関係をちゃんと観測して、地道にダイエットしていくプロセスが、かなり具体的に書かれていました。

。。。。

4つ目は、「Upcoming Features ざっくりまとめ @ Swift6.3」という、Swift界隈の人には要チェックな記事です。
Swift 6 に向けて、実は Swift 5.8 以降で `--enable-upcoming-feature` というフラグを付けると、将来入ってくる言語仕様をちょっと早めに試せるんですね。この記事では、その中でも代表的なものをかいつまんで解説してくれています。
たとえば、「Existential 型を使うときは `any P` のように `any` を必須にする」というルール。これによって、プロトコルそのものと存在型の区別が明示的になって、曖昧さを減らせます。それから、`import` がデフォルトで `internal import` になることで、うっかり内部実装がAPIとしてリークしてしまうのを防いだり、extension のメンバーの有効範囲を「その module を import しているファイル内」に限定して、曖昧な候補が競合してエラーになるのを防いだりといった変更があります。
並行処理まわりだと、`@MainActor` みたいなグローバルアクターに隔離された型がプロトコルに準拠するとき、暗黙にそのアクターに紐づいてくれる仕様や、nonisolated な async 関数がデフォルトで `nonisolated(nonsending)` として扱われて、不要な Sendable エラーに悩まされにくくなる、といった改善が紹介されています。
さらに、「weak let」やクロージャキャプチャでの `[weak hoge]` みたいに、不変な弱参照が使えるようになる話もあって、これによってメモリ管理と Sendable 制約、それからデータ競合の安全性を両立しやすくなります。今のうちから upcoming feature をオンにして試しておくと、Swift 6 本番での移行ショックを和らげつつ、新しい書き方に身体を慣らしていけそうだ、というまとめになっていました。

。。。。

そして最後、5つ目は「【検証】RTX 5090でQwen3.6-35B-A3Bを動かす — 18 t/sの罠とQwen3.5との本当の差」という、LLMまわりの実験記事です。
舞台は RTX 5090 と llama.cpp の環境。新しい Qwen3.6-35B-A3B、UD量子化のモデルを試してみたところ、最初の計測で「TG 128 が18 t/s」という、明らかに遅すぎる数字が出てしまった。で、「5090でこれはおかしいだろ」と原因を追っていくと、実はWindows側で待機していた Ollama の Qwen3.6 と Gemma が、VRAMを合計で30GBぐらい持っていっていて、検証中の Qwen3.6 がGPUに載りきらず、CPUフォールバックしていた、というオチだったんですね。
そこで、Ollama をちゃんとアンロードして、llama.cpp も最新の b8870 に更新した、クリーンな環境で再計測すると、Qwen3.6 の Q4_K_M / Q5_K_S はどちらもおよそ180 t/s 前後まで一気に回復。UD量子化の世界では、Q4とQ5で速度差がほとんどなく、VRAMの節約だけを見るとQ4_K_Mのほうがコスパがいい、という知見が得られます。一方で、同じサイズ・同じ量子化方式で比べると、Qwen3.5 Q4_K_M のほうが約15%速くて、214 t/s 対 183 t/s。なので、「とにかくスループット最優先なら、まだQwen3.5に分があるよね」という評価になっていました。
品質面では、Qwen3.6はキャラクター性の演出や発想力の豊かさが光るところがある一方で、中国語の語彙が唐突に混ざったり、日本語としての安定性に不安が残るケースもあるようです。ですので、「創作寄り」「多言語前提」みたいな用途では3.6がおもしろいけれど、純粋に日本語の業務利用なら3.5を継続採用するのも十分アリ、という結論になっています。あとは、新モデルを試すときは「見えないところでVRAMを食ってるプロセスがいないか」「llama.cppのビルドがモデルに最適化された新しめのものか」をちゃんと確認しよう、という教訓も書かれていました。

。。。。

というわけで、今日は5本の記事を駆け足でご紹介しました。
ざっとおさらいすると、まずは「Next.jsを無理にSSGに寄せるより、SPA構成に整理し直したほうが自然だったよ」という構成見直しの話。
次に、Claude CodeとAIエージェントを組み合わせて、要件定義の「白紙からつらい」を減らして、PMは判断に集中しようというワークフローの話。
3本目は、Next.js + Turbopackでバンドルサイズを半分にした、lodashのimportやバレルexport見直しのお話。
4本目は、Swift 6.3に向けて、`any`必須化や並行処理まわりの改善など、upcoming featureをざっくり押さえる記事。
そして最後は、RTX 5090でのQwen3.6検証から、「VRAMの罠」と「Qwen3.5との速度と品質の差」を丁寧に比べたレポートでした。

気になった記事があれば、この番組のショーノートにタイトルをまとめておきますので、ぜひあとでじっくり読んでみてください。
zenncastでは、番組の感想や「こんなテーマ取り上げてほしい」といったリクエストも大歓迎です。あなたの開発現場での気づきや悩みなんかも、ぜひシェアしてもらえるとうれしいです。

それでは、そろそろお別れの時間です。
次回のzenncastで、また一緒に最新の技術トレンドを追いかけていきましょう。
パーソナリティのマイクでした。いってらっしゃい！