おはようございます、zenncastパーソナリティのマイクです。
今日は2026年6月3日、水曜日の朝7時を少し回ったところです。みなさん、いかがお過ごしでしょうか。
この時間は、Zennで今トレンドになっている記事をピックアップしてご紹介していきます。通勤・通学の準備をしながら、作業しながら、耳だけ貸してもらえたらうれしいです。
今日は全部で5本の記事をご紹介していきます。AIでのスライド作成、AIコーディング時代のコードレビュー、デプロイ高速化、whoisとRDAPの今、そして3D Gaussian Splattingというグラフィックス寄りのお話まで、かなりバラエティ豊かなラインナップになってます。
まず1本目。「なぜスライド作りはClaude Designでやるべきなのか？」という記事です。
これ、プレゼン資料づくりで毎回ブランドを整えるのに数日とかかかっていた著者が、Claude Designを導入したら、なんとだいたい1時間くらいで済むようになった、という体験談なんですね。
ポイントは「きれいなスライドをAIが作ってくれる」という話にとどまらず、既存の資料やロゴから「デザインシステム」を自動で抽出してくれるところ。色やフォント、余白の取り方、カードやアイコンのスタイル、さらには文章のトーンまで、一度ルール化してくれる。
この土台ができると、デザイナーじゃない人でも、ブランドがちゃんと揃った資料を量産しやすくなるし、組織の誰が作ってもブレにくくなるんですよね。
ワークフローとしては、まず既存資料からデザインシステムを作るのに15分くらい。そのあと原稿を渡して30分くらいでスライドを生成。複雑な図解はテキスト指示だけだと難しいので、ChatGPTで下絵を作ってからClaude Designで清書、みたいな二段構えにしているのも面白いポイントです。
とはいえ、全部AI任せではなくて、余白の調整やレイアウトの細かいところ、そして文章をスライド向けにそぎ落とすところは人間がちゃんと握るべきだよ、と。時間短縮だけでなく「使えば使うほどブランド資産が貯まって、次回がもっと速くなる」構造ができるのが良い、というまとめでした。非デザイナーが資料を量産しなきゃいけないチームには、かなり刺さりそうな内容ですね。
。 。 。 。
続いて2本目。「Claude Codeのために『臭うコード検出器』を開発し、Hooksに設定してみた話」です。
AIにコードを書いてもらう機会が増えると、人間のレビュー負荷がどんどん上がっていく、という課題感からスタートしています。既存のLintで拾えるものはいいとして、プロジェクト独自の「これ、できればやめてほしい」みたいな実装パターンってありますよね。
この記事では、それらをAST、つまり構文木レベルで解析する「臭うコード検出器」として実装して、CIやClaude CodeのHooksに組み込んでいく手法が紹介されています。
たとえばLaravel標準Loggerを直接使うのは完全NG、みたいな明確なルールはPHPStanのカスタムルールでCIを落とす。一方で、「UseCase層からDBを直参照してる」「useEffect内でsetStateしてる」「バリデーションで最大値を指定し忘れてる」「assertStatus(500)でテストしてる」など、状況によってはグレーだけど基本NGなやつは、「臭うコード」として検知だけする。
これを専用コマンドとStop Hookで検出して、その結果をClaude Codeに返して「ちょっとこのへん見直して？」と自律的に再検討させるのが面白いところです。
さらに、CLAUDE.mdやClaude Code Rules、SKILL、ReviewDogによるコメントなどを組み合わせて、「人間レビューが見るべきポイント」を事前に炙り出す仕組みも用意。静的に自動検出できるものから順に押さえていき、残りをテキストベースの設計ルールでカバーする、という多層防御的なアプローチが整理されています。AIコーディングを本番で回しているチームには、かなり実践的なノウハウが詰まっていました。
。 。 。 。
3本目。「デプロイ速度を約50%高速化した話」です。
こちらはDress Code社の事例で、Backend APIのデプロイ時間を約46%短縮した、という内容です。技術スタックはNestJS＋Prisma＋PostgreSQLをECS Fargateで動かしている構成ですね。
2週間スプリントで頻繁にデプロイする中、30分を超えるパイプラインが開発スピードやMTTRを圧迫していた、という課題からスタートします。
改善の打ち手がすごく体系的で、まずはmigrationとbuildを並列実行してクリティカルパスを短縮。次にDockerfileをマルチステージにして、COPYの順序やpnpmのキャッシュを見直して、不要ファイルも削除してイメージを軽量化。
ベースイメージもDocker Hubからpublic ECRに変えて、build cacheにはzstdを使うようにしたり、Fargate側ではSOCIを使ってコンテナ起動をlazy load化。
さらに、本番環境のレスポンスの最悪値を元に、ALBのヘルスチェックやDeregistration delayをチューニング。最後はRunnerやタスク定義、ベースイメージをARM64、つまりGravitonに統一して、将来的な最適化の幅を広げています。
結果として、migrationありのデプロイが32分から17分へ、Build & Pushは9分から4分へと短縮。Fargateのタスク起動も14%ほど速くなったとのこと。
教訓として、いきなり細かいチューニングに行くんじゃなくて、まずはジョブの依存関係など「構造」から見直すこと。本番データに基づいて閾値を決めること。そして、ARM64統一みたいな「今すぐじゃないけど将来の選択肢を増やす投資」をしておく重要性が語られていました。CI/CDがつらくなってきたチームには、ロードマップとしてすごく参考になる記事だと思います。
。 。 。 。
4本目。「whoisが無ェ、RDAPは何者だ？」です。タイトルからすでにちょっと味がありますね。
筆者は社内システムの `*.workers.dev` をwhoisで調べようとして、「あれ、情報取れないぞ？」となったところから調査が始まります。
背景として、WHOISは1982年から40年以上使われてきた古参プロトコルなんですが、GDPRなどの流れを受けて、ICANNが段階的な廃止を進めてきました。2025年1月28日には、多くのgTLDでWHOIS提供の義務がなくなったんですね。
その代わりに後継として標準化されているのがRDAP。HTTPS＋JSONで情報を返す、現代的な仕組みです。gTLDに関しては、今やこちらが公式の登録情報提供手段になっています。
ただし、ccTLD、たとえば `.jp` みたいな国別ドメインはICANNの義務の対象外なので、権威RDAPを持たないところがまだ多い。
この隙間を埋めているのがレジストラ独自のRDAPで、Gandiのように自社で扱うccTLDも返してくれるところがある一方で、GMO InternetのようにgTLDだけに絞るところもある。
筆者は、GMOのRDAPが `.jp` を返していた翌日に、方針変更で404を返すようになった瞬間をリアルタイムで観測していて、それがICANNの新RDAPプロファイルへの準拠と同時に行われたらしい、というのを一次情報ベースで追っています。
また、日本のドメイン登録ビジネスの構造として、ICANN認定レジストラがGMOグループとJPRSグループにほぼ集約されていて、多くの国内事業者はそのリセラーとして動いている、という実態も整理。
結論としては、「gTLDはRDAP中心、ccTLDは依然WHOIS中心」という二重構造の中で、レジストラごとの方針やタイミングによって、同じTLDでも時期によって引けたり引けなかったりする不安定さがある、と。エンジニアとしては、whoisだけじゃなくてrdapコマンドもちゃんと使い分けていこう、というメッセージで締められています。
。 。 。 。
そして最後、5本目。「3D Gaussian Splatting ビューワを作る」という記事です。
これはRustとwgpuで実装された、3D Gaussian Splatting、略して3DGSのビューワの描画パイプライン解説です。グラフィックス寄り、かつかなり今っぽいテーマですね。
3DGSは、半透明の楕円体、つまり3D Gaussianを大量に配置して、視点依存の色（SH係数）とアルファ合成でシーンを再構成する手法です。記事では、PLYファイルから位置や形状、向き、透明度、SH係数を読み込んで、GPU側の構造体に詰めていくところから始まります。
パイプラインがかなり多段で、まずPreprocess Passでは各Gaussianをカメラ空間に投影して、3Dの共分散行列から2Dの共分散行列を導出。そこから画面上での楕円の形や色、半径、どのタイルに影響するかを計算して、画面に映るGaussianだけをピックアップします。
次にPrefix Scanで「各Gaussianが何タイルに書くか」という可変長のオフセットをGPU上で計算し、DuplicateステップでタイルとGaussianのペアの配列を生成。そのあとRadix Sortで「tile_id優先、同じタイル内では奥行き順」でソートし、Tile Rangeで各タイルの開始・終了インデックスを出します。
最後のTile Renderでは、1タイルを1 workgroupとして、そのタイルに属するGaussianだけをShared Memoryに読み込んでバッチ処理。2D Gaussianを評価しながら、奥行き順にアルファ合成して、最終的なピクセルの色を計算します。
これらを複数のcompute passとDispatch Indirectでつなぐことで、CPUにあまり戻らずにGPU側で完結したリアルタイム描画を実現している、という構成です。Rust＋wgpuでここまで組み立てているのもあって、3DGSに興味がある方だけでなく、モダンなGPUパイプラインの組み立て方を知りたい人にも勉強になる内容でした。
というわけで、今日は5本の記事をご紹介しました。
ざっとおさらいすると、まずはClaude Designでスライド作りを仕組み化して、ブランド資産を貯めていこうという話。次に、Claude CodeとHooksを組み合わせて「臭うコード」を自動で炙り出す仕組みづくり。
それから、ECS Fargate環境でのデプロイ時間を約半分に縮めた、構造から見直すパイプライン高速化の話。
4本目では、WHOISからRDAPへの移行期に起きているgTLDとccTLDの二重構造と、レジストラの方針変更を追ったドメイン調査。
最後は、Rustとwgpuで実装した3D Gaussian Splattingビューワの、GPUフル活用な描画パイプライン解説でした。
気になった記事があれば、詳しい内容はショーノートにまとめておきますので、あとでゆっくりチェックしてみてください。
zenncastでは、番組の感想や「こういう記事を取り上げてほしい」といったリクエストも、いつでもお待ちしています。
それでは、そろそろお別れの時間です。今日も良い一日をお過ごしください。
ここまでのお相手は、マイクでした。次回のzenncastでまたお会いしましょう。