どうも、日曜の朝いかがお過ごしでしょうか。マイクです。
時刻は朝七時を少し回ったところ、二千二十六年十月四日、日曜日の「zenncast」お届けしていきます。

この番組では、技術系コミュニティサービス Zenn に上がっているトレンドの記事を、ゆるっと、でも中身はしっかりめにご紹介していきます。通勤、通学前の支度中のあなたも、ベッドの中でまだゴロゴロしてるあなたも、よかったら耳だけ貸してください。

今日はお便りはお休みなので、そのぶん記事紹介、内容みっちりでいきますね。
今日ご紹介する記事は、ぜんぶで五本。AI エージェントのコードレビューから、オフィスWi‑Fiの数理最適化、Claude Mods による拡張、AIにお任せするデータ分析の品質管理、そして Playwright Test Agents を安全に無人運用するためのノウハウまで、かなり攻めたラインナップになっています。

ではさっそく、一つ目の記事からご紹介していきましょう。

まず一つ目は、AI エージェントによる「敵対的レビュー」、コードレビューですね、これが実務でほんとに効くのかどうかをガチ検証した記事です。
やっていることがかなり本格的で、コードレビューをいくつかの観点に分けて、八本の「レーン」を走らせています。例えば、バグ探索用のレーン、セキュリティを見るレーン、設計をチェックするレーン…といった具合に役割を分担して、それぞれのレーンが同じプルリクエストを別々の視点からチェックしてくれる、そんなイメージですね。
さらに、そのままだと指摘が出過ぎるので、「YAGNI レーン」と呼ばれるレーンで、ほんとに必要な指摘に絞り込む、という工夫も入れています。「You Aren’t Gonna Need It」、要らないものは削ろう、の YAGNI ですね。

この体制で、なんと九十九回分のレビュー結果を集計したところ、重大な指摘が百三十八件見つかったそうなんですが、そのうち半分以上は「一つのレーンでしか見つからなかった」指摘だった、というのがポイント。
つまり、一人のレビュワーがざっと見る、みたいな通常のコードレビューでは拾えなかったであろう不具合やセキュリティの問題が、「観点を細かく分けて並列にレビューする」ことで、かなりの数、追加で見つかっているという結果になっています。

一方で、もちろんいいことばかりではなくて、コストの問題もかなり大きいです。トークンの消費量を測ってみると、標準的な一回のコードレビューと比べて、約九倍まで膨れ上がってしまった、と。しかも、全レーンを回したのに最終的な指摘はゼロ、という「空振り」の回もあったそうで、複数のレーンで出てきた指摘を突き合わせて、不要なものを棄却していく交差検証のコストも、かなり重たいことが分かりました。

元々、標準的なコードレビューって、変更された行にフォーカスする設計になりがちなので、別ファイルとの整合性とか、仕様とのずれが絡んでくるロジックの問題、データの整合性、セキュリティの抜け穴みたいなものは、構造的に見落としやすいんですね。一方で、「変更行の中で完結しているバグ」であれば、普通のレビューでもある程度は十分と言えそうだ、と。
この記事の筆者は、そうした現実とトークンコストを踏まえて、「すべてのプルリクに敵対的レビューをかけるのは現実的じゃない」と結論づけています。そのうえで、データ更新のロジックや、計算ロジック、認可処理みたいな、「業務的にクリティカルな部分」を含むプルリクにだけ、この敵対的レビュー方式を絞って適用するのがよさそうだ、と提案しています。
なので、「お金と時間をかけてでもミスりたくないところ」にだけ、AI の八人レビュー部隊を投入する、そんな運用が現実解なんじゃないか、という話ですね。

。。。。

続いて二つ目は、オピニオン系の記事で、オフィスの「ここはつながるのに、ちょっと動くと電波弱いなぁ」というおなじみの Wi‑Fi 問題に、勘ではなく「数理最適化」でちゃんと取り組んでみた、という面白い内容です。

筆者の方は、まずオフィスフロアをマス目に区切った「グリッドモデル」にしてしまいます。一マスごとに、「ここがどのくらい電波を受け取れるか」を近似的に計算できるようにするんですね。
電波の減衰は、「アクセスポイントからの距離」と、その間にある「壁の枚数」で単純化してモデル化します。さらに、執務エリアや会議室、共有スペースなど、「ここはつながってほしい！」という重要度の高いエリアには重み付けを大きくして、逆に廊下の端とか、あまり重要度の高くないところは重みを小さくする。
そのうえで、「限られた台数のアクセスポイントを、どこに置いたら、重要な場所をできるだけカバーできるか」というのを、整数線形計画問題として解いているんです。要は、数式で Wi‑Fi 配置パズルを解いている感じですね。

こうして求めた結果としては、やっぱり「執務エリアや会議室など、重要度の高い場所を優先してカバーする配置」が得られた、ということで、やみくもに「真ん中に置いとけばいいでしょ」みたいな人間の目分量より、ずっと筋の通った案を作れることが分かった、と。
ただし、これも万能ではありません。壁の影響をかなり単純化していることや、評価の対象エリアを広く取りすぎてしまっていること、どのくらい電波が届けば「カバーされている」とみなすのか、閾値の設定などに限界がある、ともきちんと書かれています。

なので、筆者はこの手法を「唯一の正解」を出すものとしてではなくて、「最初の配置案をつくるための道具」として使うのが現実的だ、と位置づけています。
まずは数理最適化で“それなりに筋のいい案”を出して、それをベースに、実際に現場で測定してみたり、ここは壁が厚いからもうちょっと寄せようか、みたいな人間の調整を組み合わせていく。
Wi‑Fi の配置ってどうしても「なんとなく」で決めがちですけど、こうやって一度モデルに落としてみると、議論の叩き台としてすごく良さそうだな、と思いました。

。。。。

三つ目は、Claude をお使いの方には気になる話題かもしれません。
「Claude Mods」という機能についての解説記事です。これは一言でいうと、Claude Code の機能や画面表示を、「TypeScript の関数で直接拡張できる仕組み」です。
従来も hooks という形でカスタマイズはできたんですが、それよりも深く、そして安全に、エディタやツールの挙動を自分たち仕様に変えられるようになったよ、という内容ですね。

具体的には、「Function Hooks」という形で、`register(on)` という関数と、`ドル記号カンマ e カンマ next` という、いわゆるミドルウェアパターンを使います。
これによって、ツールの実行、ユーザーインターフェイスの描画、状態管理、外部コマンドの呼び出しや HTTP リクエストまで、かなり広い範囲を一括して制御できるようになっています。`ドル.state` という形で状態を持てるようになっていて、そのまま AI 補助ツールの「ちょっとしたアプリケーション」みたいなものが書ける感じですね。

処理の流れも、五層のチェーンで整理されています。`prepend`、`user`、`append`、`builtin`、`core`という順番で実行されていくようになっていて、たとえば組織全体で決めたポリシーを `prepend` や `append` レイヤーに差し込んでおくと、個人ユーザーの Mod よりも強く効く、といった設計になっています。
これにより、「組織で守りたいルール」と「個人が入れたい便利拡張」を、ちゃんと優先順位をつけて共存させられるようになっているわけですね。

面白いのは、公式の `/diff` コマンドだったり、`AGENTS ドット エムディー` への対応、セキュリティ系の Mod、それからコミュニティが作ったブラウザ埋め込み Mod みたいなものも、みんなこの同じ枠組みの上で動いている、という点です。
つまり、「標準機能とまったく同じレーンで自作 Mod が走る」ので、「自分でも公式レベルの拡張が書けるんだ」というイメージが湧きやすい構造になっています。

さらに、`claude plugin validate` や `claude plugin test` といったコマンドで、作った Mod を検証・テストできるようになっていて、マーケットプレイスで配布するところまで含めた導線も用意されています。
この記事では、「小さな Mod を自作して、チーム内で配れるようにして、最終的には一般公開する」ところまでの流れを、一気通貫で学べるようになっていて、Claude Mods の入門としても、かなり実戦向きの内容になっています。
エディタを「AI 付きで自社用 IDE にしたい」みたいなニーズのあるチームには、かなり刺さりそうだなという印象ですね。

。。。。

四つ目の記事もオピニオン系で、テーマは「AI にデータ分析をさせるときの落とし穴と、その対処法」です。
最近、統計解析や機械学習のコードを AI に書かせて、そのまま結果だけ見てしまう、というケースが増えてきていますが、そこでよくあるのが、「方法論そのもの」にばかり意識が向いて、「診断や可視化をどこまで標準でやらせるか」が抜け落ちてしまう、という問題です。

典型的には、例えばロジスティック回帰モデルを作らせて、「係数と AUC だけ出して、はいおしまい」みたいなケースですね。本来は、モデルがちゃんと当てはまっているかどうか、領域によって予測が変に偏ってないか、などを図や指標で確認する必要があるのに、そこがスキップされてしまう、と。
この記事の筆者は、これを防ぐための仕組みとして、「どの手法を使うなら、どの図と指標を必ずセットで出すべきか」という“お作法”を、あらかじめスキル群として設計しています。

具体的には、統計的推論、予測モデル、因果推論など、五つのカテゴリに分けて、それぞれについて「この手法を使ったら、必ず出すべき図と指標」「その図や指標の合格基準」「もし基準を満たさなかった場合に、次に取るべきアクション」を、一式ひとまとめにしたスキルを定義しているんですね。
たとえばロジスティック回帰なら、ROC カーブ、PR カーブ、キャリブレーションの図、それから残差プロットなどを自動で出させて、一定の条件を満たさないときは AI が「要対処」あるいは「要確認」といった形で、人間に判断を返すようにしている。
MCMC、いわゆるマルコフ連鎖モンテカルロ法でベイズ推定をするときには、Rハットや有効サンプルサイズの ESS といった、収束診断の指標を必ずチェックするようにする、などですね。

また、こうしたスキルを AI に投げすぎると、コンテキストが肥大化したり、「本当は予測モデルのスキルを使いたいのに、因果推論用のスキルを呼んでしまう」みたいな取り違えも起きがちです。そこで筆者は、「二段階のルーター構成」という工夫も入れています。
最初のルーターが、タスクの種類をざっくりと判定して、「これは予測だね」「これは因果だね」とカテゴリを選んであげる。そのうえで、二段階目のルーターが、そのカテゴリの中から適切なスキルを選ぶことで、誤ったスキル選択やコンテキストの膨れ上がりを抑える、という仕掛けです。

この仕組みによって、AI にお任せで分析をさせても、「最低限ここまではやっておいてほしい」という品質ラインを、自動的に守らせることができるようになります。
全部を AI 任せにするというよりは、AI に“標準の健康診断セット”を持たせて、「問題がありそうなときは、人間にアラートを返す」という使い方ですね。
チームでデータ分析を回している方や、「AI にはやらせたいけど、品質がちょっと不安」という方には、かなり参考になる考え方だと思います。

。。。。

そして五つ目、最後の記事は、Playwright を使った E2E テストの話題です。
テーマは、Playwright 一点五六で入った「Playwright Test Agents」を、GitHub Actions から完全無人で動かすための設計とサンプル実装を紹介する、Tips 系の記事になっています。

この Playwright Test Agents では、Planner、Generator、Healer という三種類のエージェントを使って、E2E テストの計画、テストコードの生成、それから壊れたテストの修復を自動化できます。ただ、当然ながら「AI が勝手にテストを直す」っていうのは、便利な反面、かなり危ない。
特に公式の Healer は賢すぎて、ロケーターだけじゃなく、テストの期待値を変えたり、`テスト ドット fixme` でテストそのものをスキップしてしまったりもするので、そのまま無人運用すると、「本当はアプリ側のバグなのに、テストの方をいい感じに書き換えて見えなくしちゃう」というリスクがあります。

この記事では、そのリスクを抑えるために、Healer に対してかなり厳しめのルールを「機械的に強制する」仕組みを紹介しています。
具体的には、「Healer が変更してよいのは、既存の Page Object だけ」「テストファイルは変更禁止」「`skip`、`only`、`fixme`、`fail` など、テストを有効・無効にする系の記法は全部禁止」「Node の危険な API も使わせない」といったルールを、AST 解析を使った `scripts スラッシュ guard ドット エムジェイエス` というスクリプトでチェックします。
つまり、「この範囲以外を変えたパッチは CI で即却下」というガードを、自動でかけているわけですね。

CI の設計もかなり凝っていて、エージェントを実行してパッチを作るジョブ、パッチをトークンや書き込み権限なしで適用して再テストする「検証ジョブ」、それから Draft プルリクを作成するジョブ、というふうに、役割ごとに分離しています。
さらに GitHub の Environment 機能やブランチ保護ルールを使って、「メインブランチにマージ済みの要件だけを、エージェントの入力として使う」「本番用のシークレットは、メイン以外のブランチからは絶対に使わせない」という形で、二段階の承認フローを構築しています。
これによって、「AI が勝手に本番用シークレットに触る」とか、「未レビューのコードを前提にテストを生成してしまう」といった事故を防いでいるわけですね。

テストの失敗についても、`scripts スラッシュ classify ドット エムジェイエス` というスクリプトで、「pass」「heal」「escalate」、つまり「そのまま通してよい」「Healer に任せてよい」「人間にエスカレーションする」の三つに分類します。
このときも、まずはレポート形式や終了コードの整合性をチェックして、「そもそもテストの結果がまともかどうか」を確認。そのうえで、HTTP エラーが出ていないかどうか、テスト側に「expected‑http」といった注釈が付いているか、エラーメッセージのパターンはどうか、などを見て、「これはロケーターが原因の失敗だね」と自信を持って言えるものだけを heal 対象にして、あいまいなケースは必ず人間に回すようにしています。

さらに、テスト設計の段階から、「ロケーターは必ず Page Object に集約して、テスト本体に `page ドット getByRole` などは書かない」「期待どおりの HTTP エラーは、注釈で“これは想定どおり”と明示する」「各テストには少なくとも一つは `expect` を書く」といった約束事を定めています。
こうすることで、先ほどの guard スクリプトや classify スクリプトが、「この変更はセーフ」「これは怪しい」と判定しやすい構造にしているわけですね。

実際に、実プロジェクトとミニマルなサンプルの両方で検証してみたところ、ガードや分類ロジックがちゃんと動いていること、Draft プルリク経由で人間のレビューに自然につなげられることなどは確認できた一方で、「ボタンが消えるバグを、ロケーターを変えることで“すり抜けてしまう”」といった限界や、Copilot CLI や `GITHUB_TOKEN` を使うときの制約も、きちんと正直に書かれています。
なので結論としては、「AI に任せればテストの面倒を全部見てくれる」ではなく、「AI にできるところは任せつつも、最終判断は必ず人間のレビューで補う」ことを前提にした運用を勧めている、というスタンスですね。
自動化したい気持ちと、安全性を守りたい気持ち、そのバランスをどう取るか、という意味で、とても示唆に富んだ記事でした。

。。。。

というわけで、今日は五本の記事をご紹介しました。
ざっとおさらいすると、まずは、八本のレーンと YAGNI レーンを組み合わせた AI エージェントの敵対的レビューで、重大なバグ検出力は上がるものの、トークンコストも九倍近く膨らむので、クリティカルなプルリクに絞って使おう、という話。
次に、オフィスの Wi‑Fi 配置を、距離と壁の枚数を使ったグリッドモデルと整数線形計画で最適化して、「勘」ではなく合理的な初期配置案をつくろう、という試み。
三つ目は、Claude Mods で TypeScript の関数から Claude Code を深く安全に拡張して、組織ポリシーからコミュニティ Mod まで同じ枠組みで動かし、`validate` や `test` コマンド、マーケットプレイス配布まで含めて学べる入門記事。
四つ目は、AI にデータ分析をさせるときに、各手法ごとに「必ず出すべき図と指標」「合格基準」「次のアクション」をスキルとして定義して、二段階ルーターで選択ミスも防ぎつつ、最低限の分析品質を守る仕組み。
そして最後は、Playwright Test Agents を GitHub Actions で無人実行するにあたって、Healer に厳格なガードをかけ、CI ジョブと GitHub の仕組みで二段階承認を入れつつ、最終判断は人間のレビュー前提にする、という E2E テスト運用の Tips でした。

気になる記事があった方は、番組のショーノートに元の記事への情報を載せておきますので、そちらからぜひじっくり読んでみてください。ラジオではどうしても細かい数式やコードまでは追いきれないので、実際に手を動かしてみたい方はそちらがおすすめです。

「zenncast」では、番組の感想や、「このテーマを取り上げてほしい」といったリクエストも募集中です。
AI エージェント運用してみた話とか、Wi‑Fi 最適化やってみたレポートなんかも、ぜひ聞いてみたいですね。テキストで一言でも大歓迎なので、気軽に送ってください。

それでは、そろそろお別れの時間です。
お相手はマイクでした。次回の「zenncast」でまたお会いしましょう。今日も良い一日をお過ごしください。