どうも、マイクです。おはようございます。
九月二日、水曜日の朝七時をまわりました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事をゆるっと、でも内容はみっちりめにご紹介していきます。

きょうは全部で五本の記事を紹介していきます。どれもAIエージェントまわりの設計とか自動化の実例、品質評価、そして認証やメールセキュリティまで、けっこう幅広いラインナップになってますので、通勤・通学のおともに最後までお付き合いください。

さあ、まず一本目。
一つ目は、AIエージェントとの対話を邪魔しないようにしつつ、ブラウザ側からの「ここ直して」という指摘をきっかけに、ファイル修正を回してくれるCLIの設計メモ、という内容です。かなりオピニオン強めの技術記事ですね。

背景にあるのが、「Claude Code」とか「Codex」とか「Cursor」とか、エージェント系のツールごとに仕組みがぜんぜん違うせいで、外部イベントからエージェントを自動で起こす、共通のやり方が存在しない、という問題なんです。
そこで筆者はどうしているかというと、もう、エージェントごとに別々の“起こし方”を実装しちゃっている、と。

たとえば、ブラウザからの指摘を受け付けて、それを処理するコマンドをバックグラウンドで待ち受けさせておいたり、既存のセッションのキューにメッセージを積み込んだり、あるいはACPを使って「専用セッション」を常駐させておいて、そこに投げる経路を用意したりと、エージェントごとに専用の起動パスを作り込んでいるんですね。

一方で、そうやって複雑になりがちなところを、あえてシンプルにする工夫もしています。
常駐デーモン方式はやめて、「一ファイル一プロセス」に絞る設計にして、どの指摘がどのファイルの、どの位置に対応しているのか、位置情報や状態管理を安全に扱えるように整理した、と書かれています。

最終的な見通しは、ちょっと悲観的です。
この「外部からセッションを起こす」部分が標準化される見込みは、いまのところ薄いだろう、と。
なので、当面は、新しいエージェントが増えるたびに、そのたびごとに個別の起動経路を足し続けていくしかないんじゃないか、という結論で締めくくられています。
「うわー、つらいな」と思いつつも、現場感あるリアルな設計メモでしたね。

。。。。

続いて二本目。
二つ目は「routine」という仕組みを使って、Claude Codeを自動で起動し、PRレビューとか本番エラーの調査まで、定額プランの枠の中でガンガン自動化している実例を紹介した記事です。ジャンルとしてはTips系ですね。

この「routine」という機能、トリガーが三種類あって、「時間指定」と「GitHubイベント」と「Webhook」で動く自動実行機能になっています。
クラウド実行ができるので、パソコンを閉じていても裏側で動いてくれるし、定額プランの範囲内なら、一回ごとのコストをあまり気にせず回せるのが強みだ、と説明されています。

定期実行の例がいろいろおもしろくて、
まず「毎朝のおはようルーチン」。これは、毎朝、利用枠の開始だけをやってくれるようなルーチンですね。
あとは、セッション名を自動でリネームしてくれる仕掛け。気づくと謎タイトルだらけになりますからね。
さらに、Googleカレンダーから休暇予定を集約してくれるルーチンとか、E2Eテストが失敗したときに、その失敗原因を推定して、必要であれば自動で再実行してしまう仕組み。
それから、LLMの出力エラーを週一で集計・分析するルーチンなど、日々のちょっとした面倒を埋めてくれるタスクがたくさん紹介されています。

イベント駆動の例も充実していて、たとえばDatadogのアラートが発火したら、ログとコードを突き合わせて、本番エラーの一次調査を自動でやってくれる仕組み。
それから、自分宛てにレビュー依頼が来たプルリクエストに対して、その背景とか主な変更点、どんな順番で読むと理解しやすいか、さらに指摘候補までまとめてくれる「理解補助レポート」を自動生成するルーチン。
そして、自分が出したプルリクに対して、LLMによる一次レビューを自動で走らせる、という使い方も紹介されています。ここでは、もともとGitHub Actionsでやっていた処理をroutine側に移すことで、定額の中で高性能なモデルを使えるようにした構成も、けっこう詳しく解説されています。

一方で、課題もちゃんと書かれていて、routineは個人アカウントに紐づくので、チームで共有できないこと。
それから、GitHubイベントの設定がリポジトリごとで、数が増えるとかなり煩雑になること。
イベントの種類やフィルタ条件を、もっと細かく指定したいのに、現状そこまで柔軟ではない、という点などが挙がっています。

とはいえ、まずは小さな定期タスクから試してみるのがいいよ、と記事ではまとめています。
プロンプト設計やroutineの設定自体も、Claudeに相談しながら一緒に作ってしまうと楽だよ、という、ちょっとしたコツも添えられていました。

。。。。

三本目。
三つ目は、エージェントの品質評価をどうやって考えるか、というTips系の記事です。
ここでは、エージェントの品質を六つの観点に分けていて、「数字の正しさ」「裏付け」「読みやすさ」「聞き方」「安全性」「途中で止まらないか」、この六つそれぞれに合った評価メトリクスを割り当てています。

まず、「揺らぎが許されないところ」は、LLMにジャッジさせない、という方針がポイントになっています。
たとえば数値の一致とか、ツールからの出力との整合性、それから安全性まわりですね。
個人情報が混入していないか、プロンプトが漏洩していないか、プロンプトインジェクションに引っかかっていないか、こういった部分は、カスタムメトリクスを用意して、決定的にチェックする、という考え方です。

一方で、「読みやすさ」とか、ユーザーへの「問いの立て方が適切か」、会話の進行の上手さみたいな、唯一の正解がない部分については、rubric、つまりチェック項目を細かな文章として定義した、LLMベースのメトリクスを使っています。
このとき、スコアのしきい値も、ゼロ・ポイント・ナナとかゼロ・ポイント・ハチぐらいで、多少のブレを許容する設定にしておく、というのがコツになっています。

マルチターン会話の評価には、LLMで「ユーザー役」を演じさせるシミュレーターを用意して、曖昧な依頼をされたときに、勝手に決めつけずにちゃんと聞き返せているか、とか、単発のテストでは測りにくい挙動をチェックしています。
これ、実際のユーザーとの対話にかなり近づけられるので、かなり強力な手法ですね。

ただし、「LLMがジャッジする側」に回る、いわゆるLLM-as-a-Judgeの手法には落とし穴もあって、使うモデルやプロンプト次第で、評価そのものがスキップされたり、スコアが大きく揺れたりすることがあります。
なので、評価されるエージェント側だけじゃなくて、「判定している側の品質もちゃんと疑おう」と。
同じ設定で複数回走らせて、その結果の傾向を見て良し悪しを判断することが重要だ、と強調されています。
エージェントを本番投入する前に、どう品質を測るか悩んでいる人には、かなり参考になる内容でした。

。。。。

四本目。
四つ目は、社内向けのHTML共有サービスの認証を、Google Workspaceに寄せてしっかり実装する方法を解説した記事です。
まず、人間のログインについては、GoogleのOIDC、OpenID Connectですね、これを使っています。
そしてOAuthの同意画面を「内部」設定にすることで、社外のGoogleアカウントは、そもそもの入口で自動的に締め出してしまう、という構成になっています。

加えてアプリ側でも、IDトークンに含まれる「エイチディー」クレーム、hdクレームのドメインをチェックして、自社ドメインのユーザーかどうか確認する。
さらに、JWKSと呼ばれる公開鍵情報を使って、IDトークンの署名検証もちゃんと行うことで、安全性をぐっと高めています。

次に、API用の個人トークン、いわゆるパーソナル・アクセストークンについては、「そのトークンを発行した人が、まだ会社に在籍しているか」をDirectory APIで確認しています。
これを実現するために、AWS上で動いているアプリケーションから、Googleのサービスアカウントになりすます「Workload Identity Federation」という仕組みと、「ドメイン全体の委任」という、二段構えの設定を使っています。
ちょっとお作法は複雑なんですけど、そのぶん運用の安心感は大きいですね。

さらに、人・機械・CI、それぞれのトークンをきちんと分けています。
CI用のトークンについては、「人」ではなくシステムなので、在籍チェックの対象にはせず、リポジトリ単位での権限制御と、管理者が明示的に失効させる運用で管理する方針にしている、というのもポイントです。
誰が何をできるのか、どこで切り離すのかが、構造としてきれいに整理されている事例でした。

。。。。

そして五本目。
最後は、メール送信の仕組みと、SPF・DKIM・DMARCの歴史と役割を整理しながら、「なりすましメールはなぜ成立して、どこまで防げるのか」を解説した記事です。

まず前提として、SMTPというメールの配送プロトコルには、差出人が本物かどうか確かめる仕組みが、標準ではありません。
そのため、実はMAIL FROM、いわゆるエンベロープのFromと、メール本文に載るFromヘッダ、見た目の差出人ですね、この両方とも自由に詐称できてしまいます。
この性質があるので、フィッシングメールやなりすましメールが広がってしまった、というわけですね。

そこで出てきたのが、SPFとDKIMです。
SPFは、「このドメインからメールを送ってよい送信サーバのIPアドレス一覧」をDNSに公開しておいて、エンベロープFromが、その一覧に含まれているサーバから送られているかどうかだけをチェックする仕組みです。

一方、DKIMは、メール本文や一部ヘッダに電子署名を付与して、「このメールは特定のドメインが送ったもので、途中で改ざんされていない」ということだけを保証します。
ただし、SPFもDKIMも、「表示されるFromヘッダのドメイン」とは、直接は結びついていない、という弱点があります。
つまり、ちゃんとSPFとDKIMを通していても、「見た目の差出人」を別のドメインに偽装する余地が残ってしまうんですね。

そこで登場するのがDMARCです。
DMARCは、SPFとDKIMの検証結果と、「ユーザーに表示されるFromのドメイン」を突き合わせて、その一致、アラインメントをチェックします。
そのうえで、検証に失敗したメールをどう扱うか――受信拒否にするのか、隔離するのか――そして、その結果レポートをどこに送るかを、ドメイン管理者側がポリシーとして宣言できるようにする仕組みです。

記事の中では、実際にコードを書いて、SPFとDKIMの検証をちゃんと通した「なりすましメール」を送ってみて、最終的にDMARCでブロックされる様子を確認しています。
この実験から、送信側の立場としては、「SPFとDKIMだけ設定しても、見た目の差出人ドメインのなりすましは防げない」。
DMARCまできちんと設定して、初めて意味があるんだ、という結論が示されています。
メールの世界、歴史的な経緯もあってややこしいんですが、かなり整理された良い解説記事でした。

。。。。

というわけで、きょうのzenncastは、
一つ目に、AIエージェントを外部イベントからどう起こすか、そのCLI設計メモと、標準化がなかなか難しそうだという話。
二つ目に、routineを使ってClaude Codeを自動起動し、PRレビューや本番エラー調査まで、定額枠の中でガンガン自動化している実例。
三つ目に、エージェント品質を六つの観点に分解して、LLM判定と決定的チェックを使い分けながら評価するTips。
四つ目に、社内向けHTML共有サービスの認証を、Google Workspaceベースでガチっと固める方法。
そして最後五つ目に、メールの仕組みとSPF・DKIM・DMARCの役割を整理して、なりすまし防止にはDMARCまで必要だよ、というお話をお届けしました。

気になった記事があれば、詳しい内容は番組のショーノートにまとめてありますので、ぜひそちらもチェックしてみてください。
この番組「zenncast」では、みなさんからの感想や、取り上げてほしいテーマ、日常のちょっとした出来事など、お便りもいつでも募集しています。

それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回のzenncastでお会いしましょう。