おはようございまーす！マイクです。
「zenncast」、本日も元気にお届けしていきます。
今日は2025年12月11日、木曜日の朝7時。
これから通勤・通学の方も、おうちでゆっくりしている方も、短い時間ですがお付き合いください。
この番組では、毎回Zennで話題になっているトレンド記事をピックアップして、ラジオ感覚でゆるっとご紹介していきます。
さて今日は、全部で5本の記事をご紹介していきます。
開発環境の小ワザから、AWSの本気バックアップ戦略、LLMを使った動画解析パイプライン、Next.jsの次の選択肢、そして低レイヤー向けRustアップデートと、かなり盛りだくさんです。最後まで聞いてもらえると、テック界隈の「今」がだいたい掴めるラインナップになってます。
それではさっそく、1本目からいきましょう。
……。…。…。
1本目は
「ローカル開発のシークレット設定を自動化する ── Go × AWS Secrets Manager」
という記事です。
ローカル開発で、環境変数のシークレット設定……これ、地味にめんどくさい問題ですよね。
「1Password見てコピペしておいてください」とか、「1Password CLI叩いて…」って、新しく入ったメンバーに説明するのも手間だし、自分自身も久しぶりにそのサービスを起動しようとしたら「あれ、何が必要だっけ？」ってなる、あの現象です。
この記事の作者さんは、すでに社内で使っている `aws sso login` を前提に、「ローカル開発限定でシークレットを自動注入してくれる」Goパッケージを自作しています。
ポイントは、GoのstructタグとAWS Secrets Managerの組み合わせ。`envconfig`と併用して、`localsecret`タグが付いていて、なおかつ環境変数がまだ埋まってないフィールドだけを、Secrets Managerから補完してくれる仕組みです。
環境変数は上書きしないし、エラーが出てもサービスの起動をブロックしないので、「本番っぽい厳しさ」ではなく「ローカル開発の快適さ」を優先した設計になっているのがいいですね。
さらに、命名規約に沿ってSecrets Managerへ登録してくれるCLIも用意されていて、「どのフィールドをシークレットにするのか特定 → Secrets Managerに登録 → structタグ追加」までを、対話的にサポートしてくれます。
面白いのが、Claude Codeにカスタムコマンドを用意して、既存のシークレットを`localsecret`対応にするフローまで自動化しているところ。
結果として、「1Passwordを見て設定しておいてください」という属人的なオンボーディングが不要になって、新メンバーも久々起動もスムーズに。シークレット更新も自動反映されるので、セキュリティとDXの両取りを狙った取り組みになっています。
Go前提の話ですが、発想自体は他言語にも持ち込めそうで、「ローカル専用のちょっとした自動化」がチームを楽にする好例だと思いました。
……。…。…。
続いて2本目は
「ランサムウェア対策としてのバックアップ戦略＠AWS」
という記事です。
ここ数年、ニュースでもたまに耳にするランサムウェア。IPAの「10大脅威2025」でも、組織向け脅威の1位にランクインしている、かなりホットというか、怖いテーマですね。
しかも最近の攻撃者は、「バックアップを守っていればOKでしょ」という前提そのものを狙ってきていて、バックアップデータも暗号化したり、削除したりということが実際に起きています。
この記事では、Veeamの有名な「3-2-1-1-0ルール」をベースに、「AWSで真面目にランサムウェア対策するならどうする？」を整理しています。
3-2-1-1-0って何かというと、
・3つ以上のコピーを取る
・2種類以上の異なるストレージに保存する
・1つはオフサイト（別拠点）に置く
・さらに1つはイミュータブル（書き換え不可）にしておく
・そして復旧テストでエラー0を確認する
という考え方ですね。
AWSでは、これを実現するために、AWS Backupを中心に据えて、
・東京と大阪リージョンへの多重コピー
・論理的エアギャップを作るVault Lock（WORM）なバックアップボールト
・クロスアカウント共有で「爆発半径」を小さくする構成
などが紹介されています。
OrganizationsとSCP（サービスコントロールポリシー）を組み合わせて、「バックアップを消したり改変したりする操作を、そもそもできないようにする」ガードレールもちゃんと敷きます。
さらに一歩踏み込んで、Multi-Party Approval、つまり「復旧時には別経路の認証が必要」な仕組みを組み合わせて、万が一アカウントが侵害された場合でも、攻撃者にバックアップを消しきられないようにする、という考え方も解説されています。
最後には、こうした構成はもちろんコストも複雑さも増えるけれど、最近の被害状況を考えると、もはや「やりすぎ」とは言い切れない、というちょっと重めの結論。
クラウド運用している方や情シス、SREの方には、チェックリスト代わりにもなる濃い内容でした。
……。…。…。
3本目はちょっとワクワク系のやつです。
タイトルは「$1で最大8時間の動画を話者分離・文字起こし・LLM分析するAWSパイプラインを作った」。
ユーザーインタビューや会議の録画、たまりますよね。見直すのはつらいし、でもちゃんと分析したい。
この記事の作者さんは、「じゃあ全部AWSのサーバーレスで自動化しちゃおう」ということで、最大8時間の長尺動画を、安く・高精度に処理できるパイプラインを作っています。
構成としては、S3に動画をアップロードすると、Step FunctionsとLambdaが起動して、
・まず音声を抽出
・8分＋30秒オーバーラップでチャンク分割
・pyannote.audio 3.1で並列話者分離と埋め込みクラスタリング
・話者ごとに音声を切り出し
・faster-whisperで並列文字起こし
・最後にgpt-5-miniで要約と分析
まで自動でやってくれます。
「誰が」「何を」「どのタイミングで」話したかまで整理されて、そこにLLMの要約や洞察が乗る、というイメージですね。
インフラとしては、ほぼLambdaとStep Functionsの従量課金で、Secrets Manager・ECR・CloudWatch Logsくらいが脇役。
その結果、月額の固定費は約2ドル、8時間フルの動画でも処理コストは約2.3ドル程度で、AWS Transcribeを素直に使うより約5倍コスパがいい、という試算になっています。
実装面のハックも面白くて、Step Functionsの256KBペイロード制限によるStates.DataLimitExceededエラーを、`resultPath: DISCARD`と途中結果のS3退避で回避したり、PyTorchやモデルサイズの制約を踏まえてチャンク長・同時実行数を調整したりと、かなり現場感のあるノウハウが詰まっています。
今後はGoogle Meetの自動録画とつないで、「会議したら勝手に録画・話者分離・要約・分析まで終わってる」世界を目指しているとのこと。
「インタビューのテキスト化つらいな…」と思っている人には、夢のような構成ですね。
……。…。…。
4本目はフロントエンド界隈の話題。
タイトルは「『とりあえずNext.js』をやめてBetter-T-Stackを試してみた」。
ここ最近、React Server Components周りの議論や、Next.jsのセキュリティ問題をきっかけに、「全部Next.jsでいいの？」っていう問い直しが起きていますよね。
この記事の作者さんのチームでも、「メタフレームワークに依存しすぎない構成にしたい」「AIとの協調開発も見据えたい」という狙いから、Better-T-Stackという選択肢を試してみた、というお話です。
Better-T-Stackは、ざっくり言うと
・フロントはReact
・ルーティングとアプリケーションフレームワークにTanStack Start
・バックエンドにElysia.js（Bun前提の高速なやつ）
・通信はoRPCで型安全なRPC＋OpenAPI自動生成
・全体はTurborepoでmonorepo構成
といった組み合わせになっています。
良かったポイントとして挙げられているのが、まずCLIがかなり優秀で、対話的に回答していくだけで、かなりリッチな構成のプロジェクトが一気に立ち上がること。
TanStack Startは、デフォルトで「アイソモーフィックな実行モデル」を採用していて、`use client`問題に悩まされにくいのも、Next.jsに不満を持っている人には刺さりそうです。
oRPCは、型安全なRPCでありつつOpenAPI仕様も自動で出してくれるので、「フロントとバックの型定義がズレる問題」と「外部連携用にOpenAPI書くのだるい問題」を、同時に解消してくれる存在として評価されています。
Elysia.jsは、Bun前提なところは賛否あるかもしれませんが、高速で、OpenAPI対応もすごくシンプルに書けるのが魅力とのこと。
この記事の結論としては、「いきなり全部乗り換え」ではなく、小規模案件からTanStack Start＋monorepo＋RPC構成を試していきつつ、AIとの協調開発で仕様乖離を減らす、という方向性を探っていく、というもの。
最後には、こういったモダン技術を一緒に試してくれるエンジニア募集の告知もされていて、技術選定と採用PRをうまくセットにした記事になっています。
……。…。…。
そしてラスト、5本目はRust好き・低レイヤー好き向けのまとめ記事。
タイトルは「低レイヤー開発者が注目すべきRustのアップデート 2025年版」。
Rust 1.84.0〜1.91.0の中から、特にOS開発や組み込み、システムプログラミング寄りの人が気にすべきアップデートを、ぎゅっと整理してくれています。
まずインパクトが大きいのが、1.88.0でnaked functionsが安定化したこと。
関数のprologue/epilogueを省略して、自前のインラインアセンブリで制御しつつ、安全に復帰できるようになったので、ブートローダや割り込みベクタをRustで書きたい人にはかなり嬉しい更新ですね。
生ポインタ周りでは、1.84.0でstrict provenance APIが入ったり、安全なポインタ生成の改善、即dropされる値へのポインタに対する警告、1.86.0でのnon-null検査など、とにかく「解析しやすく、安全寄り」に寄せる変更が続いています。
Edition 2024では、unsafeまわりがさらに厳格化。`unsafe extern` や `unsafe` attribute、`unsafe_op_in_unsafe_fn` 警告、`static mut` 参照禁止など、「ここは危ない処理だよ」というのをコンパイラレベルでしっかり明示する方向に進んでいます。
CPUの機能フラグまわりでは、`target_feature` がsafe関数にも付けられるようになって、`std::arch` の多くがsafe関数として使えるようになったのもトピック。
さらに、`asm goto` 対応や、`extern "C"` のpanic挙動の改善、ABI省略時の警告、doctestのクロスコンパイル対応、`extern "C"` でのi128/u128対応、const generics推論など、細かいけど実務では効いてくる改善もまとめられています。
記事では「Rustで低レイヤーを書くとき、どこがどう良くなったのか？」を、バージョンごとに追えるようになっていて、追い切れていなかった人には一気にキャッチアップできる内容です。
12月21日には、この辺りを題材にしたイベントも告知されていて、「RustでOSやミドルを書きたい勢」は必見という感じでした。
……。…。…。
というわけで、本日のzenncast、駆け足でおさらいすると、
1本目は、GoとAWS Secrets Managerを使ってローカル開発のシークレット設定を自動化する仕組み。オンボーディングと更新作業を一気に楽にしてくれる話。
2本目は、ランサムウェア対策としてのAWSバックアップ戦略。3-2-1-1-0ルールをAWS BackupとVault Lock、Multi-Party Approvalで実現するという、かなり本気の構成。
3本目は、8時間動画を安く処理するAWSパイプライン。話者分離・文字起こし・LLM分析まで、サーバーレスで完結させた事例。
4本目は、「とりあえずNext.js」から一歩外に出て、Better-T-Stackを試した話。TanStack StartやElysia、oRPCを軸にしたmonorepo構成の実験レポート。
5本目は、低レイヤー開発者向けのRustアップデートまとめ。naked functionsやstrict provenance、Edition 2024のunsafe強化など、システム寄りの人が押さえておきたいポイントでした。
気になる記事があった方は、番組のショーノートに詳しい情報を載せておきますので、あとでゆっくりチェックしてみてください。
この番組「zenncast」では、皆さんからの感想や、「こんなテーマ扱ってほしい」「この技術の記事を深掘りしてほしい」といったリクエストも募集中です。
ラジオネームを添えて送っていただけると、番組内でご紹介させていただきます。
それでは、そろそろお時間です。
今日も良い一日をお過ごしください。お相手はマイクでした。
また次回のzenncastでお会いしましょう。バイバーイ。