どうもー、おはようございます。マイクです。
「zenncast」、2026年4月21日、火曜日の朝7時にお届けしていきます。
この番組では、技術系情報共有サービス「Zenn」に掲載されている、いまホットなトレンド記事を、ラジオ感覚でゆるっと、でも中身はぎゅっと詰めて紹介していきます。
今日はお便りはお休みということで、そのぶん記事紹介をたっぷりめにいきましょう。
きょうピックアップする記事は全部で5本です。
セキュリティが2本、開発者体験を変えるバージョン管理が1本、Linuxでのゲーム環境構築が1本、そしてGoとターミナルGUIのチャレンジが1本。幅広くいきますよ。
まず1本目。
タイトルは「1日で作るサプライチェーン攻撃対策！運用死しないコスト『ほぼゼロ』の通信監視」。
サプライチェーン攻撃って、最近ほんとにニュースでも耳にする機会が増えましたよね。怖いのは、正規のアップデートやライブラリ経由で不正なコードが紛れ込むパターン。で、そういう不正コードって、外のC&Cサーバーとこっそり通信することが多いんですよね。
この記事は、「じゃあその“意図しない外向き通信”をちゃんと見張ろう」という、とても実戦的なアプローチのお話です。しかもポイントは、「100点満点を目指して燃え尽きるんじゃなくて、80点を低コストでちゃんと回し続ける」というところ。
構成は全部AWSマネージドサービスで、S3、Athena、DynamoDB、Lambda、EventBridge、それからRoute 53 ResolverのDNSログとVPC Flow Logs。これらを組み合わせて、外向き通信を集計して、ホワイトリストにない怪しい通信だけをSlackに飛ばす仕組みを作っています。
最初はアラートがいっぱい来るのを覚悟しつつ、ホワイトリストを整備したり、AthenaのSQLで除外条件を足したりして、徐々に「見るべきものだけが届く」状態に絞り込んでいく。運用としては、日次で数分だけSlackを確認して、必要な通信をホワイトリスト登録していけばOK、っていう現実的な運用を目指しています。
また、あえて偽ドメインとか外部IPにアクセスしてみて、「ちゃんと検知できるか」「逆に不要なものまで検知しすぎてないか」をテストするのも推奨していて、“ノイズと見逃しのバランスを取りながら、継続できるセキュリティ”という視点がすごくよく伝わる記事でした。サプライチェーン攻撃が気になってるインフラ・SREの方には刺さる内容だと思います。
。。.。。.。。.。.
続いて2本目。
タイトルは「Cursorで爆速開発、でもセキュリティは爆速で崩壊していた」。
AIコーディングツールを使っている方、多いと思います。Cursorだったり、Claude Codeだったり。コードが“爆速”で書けるようになる一方で、記事の筆者が指摘しているのは「セキュリティレビューが全然追いついてない」という問題です。
AIがどんどんパッチを書いてくれるんですけど、そのたびに既存の安全な実装が崩れちゃったり、レビューが甘くなってシークレットがうっかり露出したり、AIアプリ特有のプロンプトインジェクションとかSSRF、コスト爆発みたいな問題って、従来のチェックリストじゃカバーしきれないんですよね。
そこで筆者は、Claude Codeの「SKILL」という機能を使って、あたかも“シニアセキュリティエンジニアが憑依したAI”を作る、という面白いアプローチを取っています。OWASP Top 10やLLM Top 10、CVSSなんかをベースにして、5カテゴリ18軸のSKILL.mdを設計して、それに沿ってAIにレビューさせる。
さらに、「どの程度ヤバい問題が出てきたら、このコミットは止めるべきか」というルールも明文化していて、人間の“緊張感”をプロセスとしてAIに組み込んでいるんですね。「セキュリティレビューして」と呼び出すだけで、AIが差分を多角的にチェックしてくれるワークフローを提案しているのが面白いところです。
AIが「とりあえず動くコード」を量産してくれる時代だからこそ、ちゃんと安全性も一緒にスケールさせよう、というメッセージが印象的でした。AIコーディングをバリバリ使ってるチームには、ぜひ読んでおいてほしい内容ですね。
。。.。。.。。.。.
さあ、3本目。
タイトルは「バージョン管理システム Jujutsu」。
Jujutsu、略してjjですね。2022年に公開された比較的新しいバージョン管理システムなんですが、Gitをバックエンドに使いつつ、「日々の開発をもっと快適にする」というコンセプトで、かなり大胆に設計し直しているのが特徴です。
一番の違いは、変更の単位を「コミット」じゃなくて「チェンジ」として扱うところ。チェンジIDは履歴を書き換えても変わらないので、「あの変更」が履歴整理で行方不明になる、みたいなストレスが減るんですね。内容の更新はコミットIDの変化として表現されます。
作業コピー自体もチェンジとして扱われていて、`jj describe` で説明を付けたり、`jj new` で新しいチェンジを生やしたりしながら、`split` や `squash`、`restore`、`abandon`、`rebase` といった操作で、あとからいくらでもきれいに整理できる前提の設計になっています。いわば、匿名ブランチがデフォルト、みたいなノリですね。
Gitとの連携は `jj git fetch` / `push` と「ブックマーク」という仕組みで行っていて、ブランチ名はこのブックマークとしてチェンジに紐づける。これによって、「ブランチをどう管理するか」よりも、「チェンジをどう育てるか」に意識を集中できるスタイルになっています。
さらに `jj workspace` で複数の作業コピーを扱えたり、TUIでの履歴操作、コンフリクト解消を後回しにできたり、とにかく「Gitは強いけど、日常のワークフローがちょっとしんどいんだよね」という開発者のモヤモヤに寄り添ったツールになっています。Gitと互換を保ちながら、開発体験をアップデートしたい人には要チェックな記事です。
。。.。。.。。.。.
4本目いきましょう。
タイトルは「環境が汚れるのが嫌なのでPodmanコンテナの中でSteamを動かした」。
Linuxでゲームをする人なら、「Steam入れたら、32bitライブラリとかいろいろ落ちてきて、環境がごちゃごちゃになるのがちょっとイヤだな……」って、一度は思ったことあるんじゃないでしょうか。この記事の筆者は、その悩みに対して「じゃあコンテナの中でSteam動かせばよくない？」という解決策を実践しています。
使っているのはrootless Podman。セットアップはPodmanさえあれば2コマンドで済むように作り込まれていて、Steam関連のデータは専用ディレクトリの下に全部まとまるように設計されています。つまり、遊ぶのをやめたら、そのディレクトリとコンテナイメージを消すだけで、ホストはきれいさっぱりクリーンな状態に戻せる、というわけですね。
ContainerfileではUbuntu 24.04ベースで32bit/64bit両方のライブラリを入れて、GPUがAMDかNVIDIAかで必要なパッケージを切り替える工夫もされています。さらに、コンテナ側では不要なsteamdepsを無効化して、余計なものを減らしているのもポイント。
起動用のrun.shでは、事前チェック、GPUの自動検出、イメージの自動ビルド、デスクトップ環境との統合まで面倒を見てくれます。`podman run` のときには、ネットワークやPID、IPC、ユーザ名前空間を調整しつつ、GPUデバイスやvideo/renderグループ、X11、PulseAudio、D-Busソケット、ゲームパッド入力、それにSteamの設定ディレクトリやライブラリディレクトリをバインドマウント。
これによって、GPU性能をほとんど落とさずにGUIゲームが動かせて、かつ「ホストにパッケージを入れない」という、ほどよい隔離が実現できています。セキュリティガチガチなコンテナというよりは、「環境を汚したくないデスクトップLinuxユーザー向けの現実解」として、とても実用的な内容でした。
。。.。。.。。.。.
さて、最後5本目。
タイトルは「GuiguiとGhosttyを組み合わせてターミナルGUIを作ってみた」。
Goを書いている方、そしてターミナルエミュレータが好きな方にはたまらない内容ですね。筆者は、Goからlibghosttyを呼び出して、Ebitengine上で動くGUIフレームワーク「Guigui」と組み合わせた、macOS向けターミナルアプリ「gostty」を実装しています。
構成としては、Guigui側にTerminalWidgetを用意して、キー入力だけをGhostty側へ渡す。その代わり描画はGhosttyがMetalでNSViewに直接行う、という分業スタイルです。この統合の過程で、三つの大きな問題が起きています。
一つ目は、NSViewのlayer設定の順番を間違えて、描画が不安定になる問題。これは、レイヤー周りの制御をGhostty側に任せることで解決。
二つ目は、Ebitengineがメインスレッド以外で動くのに対して、TIS APIやAppKitはメインスレッド必須という制約があるため、`ghostty_app_new` を呼ぶとクラッシュしてしまう問題。ここは、初期化部分をメインスレッドで先にやっておいて、本当に必要な箇所だけ `RunOnMainThread` でラップすることで乗り切っています。
三つ目は、終了時にDispose内の `RunOnMainThread` がデッドロックしてプロセスが残り続ける問題。これは、ウィンドウクローズをちゃんと検知して、まだループが回っているうちにDisposeを呼ぶように変えることで解決しています。
開発プロセス面でも、GuiguiとGhosttyをgit submoduleとして固定しておいて、docsディレクトリに実装ログを残し、それをClaude Codeにローカル参照させることで、コンテキストが共有しやすくなった、という工夫も紹介されています。
libghosttyを使ってターミナルを構築する、という本来の目的は達成できた一方で、フレームバッファを外に出せるAPIがなく、描画をEbitengine側で直接扱えない、という課題も残っているとのこと。とはいえ、「既存の高機能ターミナル×ゲームエンジン的なGUI」というチャレンジの記録として、とても読み応えのある記事でした。
。。.。。.。。.。.
というわけで、きょうの「zenncast」、駆け足でおさらいしていきます。
まずは、AWSマネージドサービスだけで構成する、サプライチェーン攻撃対策向けの「低コストな外向き通信監視」のお話。
続いて、AIコーディング時代にあわせて、Claude CodeのSKILL機能に“セキュリティエンジニアの視点”を埋め込むことで、爆速開発とセキュリティを両立しようという提案。
3本目は、Git互換を保ちつつチェンジ中心の設計で日々の開発体験を良くしてくれる、新しいバージョン管理システム「Jujutsu」。
4本目は、Podmanコンテナの中でSteamを動かして、Linuxデスクトップの環境を汚さずにゲームを楽しむ工夫。
そして最後は、GuiguiとGhosttyを組み合わせてターミナルGUIを作るチャレンジと、その中で出てきたMac固有の問題と解決策のお話でした。
気になった記事があれば、詳しい内容は番組のショーノートにまとめてありますので、ぜひそちらから原文もチェックしてみてください。
この番組「zenncast」では、みなさんからの感想や、「こんなテーマを扱ってほしい」「この技術が最近気になってます」といったお便りも大歓迎です。ラジオネームを添えて、気軽に送ってください。
それでは、きょうはこのへんで。
お相手はマイクでした。また次回のzenncastでお会いしましょう。いってらっしゃい！