おはようございます。マイクです。
時刻は朝7時を少し回ったところ。今日は2026年3月3日、火曜日ですね。
ここからの時間は「zenncast」、Zennでいまホットなトレンド記事をゆるっと、でも中身はみっちりめにご紹介していきます。
今日はお便りコーナーはお休みしまして、そのぶん記事をしっかりめに掘っていこうかなと思います。
というわけで、今日ご紹介する記事は全部で5本です。それぞれジャンルもバラバラなんですが、共通して「実務でかなり効きそう」という濃いラインナップになってます。
ではさっそく1本目。
タイトルは「上場企業のメールセキュリティを調べてみた – DMARC・SPF設定の実態」。
これね、会社のメール担当の方は耳が痛くなるやつです。DMARCとかSPFとか、名前だけ聞いたことあるけど、ウチちゃんと設定できてるのかな？ って方に刺さる内容。
この記事では、日本の上場企業3,745社を対象に、SPFとDMARCの設定状況をぜんぶ調べてるんですね。結果としては、SPFは入っているけど「softfail」の、いわゆるゆるめの設定が7割くらい。「fail」でガチっと締めてるのは2割ちょい。DMARCに至っては、ポリシーnoneで実質ウォッチだけ、っていう会社が半分以上。rejectまできっちり設定してる会社は4％ちょっとしかないという、なかなかシビアな実態が見えてきます。
おもしろいのは、金融業界だけはガイドラインの後押しもあって、rejectかquarantineをちゃんと入れているところが半分超え、っていう業界差ですね。さらに、レポート受け取り用のruaを設定してない企業が多くて、「そもそも今どれくらいなりすましが来てるのか把握できてないのでは？」という問題提起もされています。MXレコードがないドメインでも悪用され得るから、そこにもSPFやDMARCを入れようね、というあたりも含めて、まずはp=none＋ruaで現状把握、そのあと段階的にポリシーを強くしていく、という現実的なロードマップが示されている記事でした。社内で「DMARCやろうよ」って説得するときの資料にも、かなり使えそうな内容です。....
続いて2本目。
「VS Code + GitHub Copilot で並列タスクが快適になったので、やり方を整理する」という記事です。
これは、Copilotをただの自動補完ツールじゃなくて、「ちゃんとしたエージェント」として使い倒したい人向けの実践レポートですね。VS Codeに入った「エージェントセッション管理UI」、ここでCopilotとの複数セッションを一覧できるようになって、タスクごとにチャットを分けて並列で進められるようになった、と。
セッションごとに状態アイコンが付いていたり、ホバーでどんな会話だったかサッと確認できたり、名前もF2で変えられるから、「バグ調査用」「UI改善用」「ドキュメント整備用」みたいに、Copilotとの会話をプロジェクトマネジメントの単位として扱えるようになってるんですね。コツとして挙げられているのが、「エージェントに丸投げできるレベルまで要件をまとめてから投げる」こと。人間の側がタスク設計をちゃんとしておけば、あとはエージェントが自律的に動ける。その前提で、権限やワークスペースの構成を整えておくと、並列開発がすごくやりやすくなるよ、という話です。
一方で、マルチルートワークスペースでは編集権限に制約があるので、「1プロジェクト＝1ウィンドウ」運用前提になっているなど、今の時点での限界もちゃんと押さえています。それでも、VS CodeとCopilotだけで、コンソールゴリゴリじゃなくGUIベースで、現場で使えるレベルの並列作業ができるようになった、という手応えが詳しく語られている記事です。ツール更新を横目で見てた人も、一回この組み合わせ試してみようかな、って気になる内容ですね。....
さあ3本目。
タイトルは「壊れにくいUIテストの設計を考える（Playwright + Storybook + React + GitHub Actions）」。
これは「テストを書く側」と「実装を書く側」が別、っていう現場あるあるを前提に、「それでも壊れにくくて、ちゃんとバグも拾えるUIテストをどう設計するか」を考えた記事です。
テストを3層に分けているのがポイントで、まずE2Eテストには、本当に代表的な導線だけを置く。そこに全部盛りしないで、UIの状態遷移とか細かいコンポーネントの挙動は、Storybook TestとかComponent Testの下位レイヤー側に寄せる。これによって、テスト時間を短くしつつ、どこで失敗しているのか原因の切り分けもしやすくする、という構成ですね。
ロケータ設計もかなり実務的で、「ユーザー操作の意図」はRoleとLabelで取る、「機械的に安定して参照したいところ」はdata-testidを使う、というルールを決めています。このdata-testidを文字列で直書きしないように、src/testids以下で共通・ページ別に定数管理し、コンポーネントとテストの両方が同じ定数を参照する構造にしている。さらに、「直書き禁止」の独自ESLintルールまで用意して、口約束になりがちなルールを技術的に強制しているのがいいですね。
GitHub Actions上でも、lintからunit test、storybook、CT、E2Eまでを同じ粒度で回して、レポートも一元的に集めることで、誰が見ても状況が分かるようにしている。理想論じゃなくて、「現場で回せる運用」と「品質確保」の、ほどよい落としどころを探った設計ノウハウがまとまった記事でした。フロントエンドのテスト設計に悩んでいるチームには、かなり刺さると思います。....
4本目いきましょう。
タイトルは「もう.envにAPIキーを平文で置くのはやめた — macOS Keychain管理CLI『LLM Key Ring』」。
これはセキュリティ意識高めなLLMユーザーには必読ですね。.envにAPIキーをそのまま置いてると、うっかりGitにコミットしたり、ログに紛れたり、最近だとローカルで動くAIエージェントにコマンド実行を許している環境だと、「勝手に.envを読まれてキーを抜かれるんじゃ？」っていう新しいリスクも出てきている、と。
そこで著者の方が作ったのが、「LLM Key Ring」、略してlkrというCLIツール。macOSのKeychainを使ってAPIキーを暗号化保存しておいて、必要なときにだけ`lkr exec`経由で子プロセスの環境変数に注入する、という設計になっています。ポイントは、「キーの生値をstdoutとかファイル、クリップボードに極力出さない」方針を徹底しているところ。TTYガードで非対話環境からの生値出力をブロックしたり、「日常の推論用」と「管理・設定変更用」のキーを分けて、強い権限を持つキーが普段のワークフローに紛れ込まないようにしている。
どうしても.envが必要なケース向けには、genコマンドでファイルを生成する機能もあるんですが、基本はexecルートに寄せて、「秘密を外に出さない運用」を推奨しています。Rustのworkspace構成でモジュールをきれいに分けつつ、Zeroizingを使ってメモリ上からも秘密情報を消すなど、どこまで守れて、どこからは守れないのかを明示しているのも好印象です。個人開発のレベルでも現実的に導入できる、LLM用APIキー管理の一つの答えを提案している記事でした。macを使っていて、.envにAPIキー直書きしている方は、一度立ち止まるきっかけになりそうです。....
そしてラスト、5本目。
「運転動画を検索可能にする 〜Cosmos-Embed1とDatabricksで〜」という記事です。
これは自動運転の文脈ですね。大量の運転動画があるのに、「工事現場を避けたシーン」とか「歩行者が横断している場面」みたいな、内容ベースで欲しいシーンをサッと探せない、という課題に取り組んでいます。
そこで採用しているのが、映像とテキストを共通の埋め込み空間にマッピングできるCosmos-Embed1と、DatabricksのVector Search。アーキテクチャがおもしろくて、動画側のEmbeddingはオンプレのH100で日次バッチ処理、テキスト側のEmbeddingはLambdaでリアルタイムに計算する、非対称な構成を取っているんですね。動画のデコードと埋め込み生成もジョブを分けて、S3にParquetで貯めつつ、Delta Live TablesとDELTA_SYNC／TRIGGEREDモードのベクターインデックスで、コストと運用負荷を抑えながら回している。
フロント側はNext.js製の社内ビューアで、自然言語検索と類似シーン検索を一つのUIに統合。シナリオテストの拡充、学習データの品質管理、モデル挙動の分析など、複数チームで横断的に使われているそうです。今後の展望としては、複数カメラの映像をどう扱うかとか、検索精度をどう評価するか、動画データの多様性を高める工夫、クラスタリングして振る舞いを可視化する試みなど、応用範囲がかなり広そうな話も出てきます。
単なる「ベクター検索やってみた」ではなく、実際の自動運転開発の現場で、どういう要件・制約がある中でこの設計に落ち着いたのか、そのリアルが分かる記事になっていました。
というわけで、今日は5本ご紹介しました。
ざっとおさらいすると、1本目は上場企業のメールセキュリティ事情とDMARC・SPFの現実的な導入ステップの話。2本目はVS CodeとGitHub Copilotのエージェントセッションを活用して、並列タスクを気持ちよく回すワークフロー。3本目はPlaywrightやStorybookを組み合わせた、壊れにくいUIテスト設計。4本目は.envに平文でAPIキーを置くのをやめて、macOS KeychainとLLM Key Ringで安全に管理しようという提案。そして5本目が、Cosmos-Embed1とDatabricksを使って、自動運転の運転動画をセマンティック検索可能にした事例でした。
気になった記事があった方は、番組のショーノートに詳細を載せておきますので、ぜひ本編もじっくり読んでみてください。
「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」「うちの現場はこうしてるよ」といったフィードバックもいつでもお待ちしています。あなたの一言が、次回のラインナップを変えるかもしれません。
それでは今日はこのあたりで。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。いってらっしゃい。