どうも、おはようございます。マイクです。
朝7時を少し過ぎたところ、2026年4月13日、月曜日。今週も始まりました「zenncast」。この番組では、Zennに上がっているトレンドの記事から、開発の現場で役に立ちそうな話題をゆるっと、でも中身はガッツリめに紹介していきます。
今日も通勤・通学のおともに、コーヒー片手に、のんびり聞いていってください。

今日はお便りコーナーはお休みで、そのぶんガッツリ技術ネタに振り切っていこうと思います。
さて、今日ご紹介する記事は全部で5本です。AIエージェント、状態遷移設計、ジョブキューによるセッション管理、セキュリティアドバイザリへのツッコミ、そしてUIレビューをAIにやらせる話まで、かなり濃いラインナップになってます。

それでは、1本目からいきましょう。

まず最初は「agent-browser入門：Claude Codeからブラウザを自在に操る！導入＆他ツール使い分けガイド」という記事です。
これね、名前だけ聞くと「またヘッドレスブラウザのツール増えたの？」って感じなんですけど、Vercel Labsが作った「AIエージェント専用」をうたうRust製のヘッドレスブラウザCLIなんですね。ポイントは、人間がゴリゴリスクリプト書くというより、「Claude Codeに自然言語でお願いすると、裏でこのCLIを組み立ててブラウザを操作してくれる」というワークフローが主役になっているところです。
できることはかなり幅広くて、ページ遷移、クリック、フォーム入力、スクリーンショットやPDF出力、アクセシビリティツリーを使ったスナップショット取得と差分確認、ネットワーク制御、セッション使いまわし、バッチ実行と、テスト自動化にもスクレイピングにも使えそうな機能がそろっています。
記事では、検索結果の取得や、ログイン状態を保ったままの情報収集、ページの差分比較みたいなデモを通じて、「人間は自然言語で『このサイトからこういう情報とってきて』と指示、あとはエージェントに任せる」イメージを具体的に見せてくれています。
面白いのが、他ツールとの棲み分けをきちんと整理しているところで、決定論的なテストをガチガチにやりたいならPlaywright MCP、Pythonとの相性を重視するならBrowser Use、TypeScript/JavaScriptで柔軟に組み込みたいならStagehand、Node.jsと寄り添いたいならPuppeteer、といった形で比較してくれるんですね。そのうえで、agent-browserは「Claude Code前提で、情報収集やブラウザ操作をAIにまとめて任せたいときの主力ツール」という立ち位置がはっきりしている。ただし、Claude Desktopからはちょっと使いにくいので、用途に応じて他ツールも使い分けるといいよ、と。
導入自体はnpmからサクッと入れられるので、すでにClaude Codeを日常的に使っている人にとっては、「あ、これ一段ギアが上がるな」という感触の記事でした。ブラウザ操作を“人間の仕事”から“エージェントの仕事”に本気で移していく、そのためのベースツールっていう位置づけですね。

。。。。

続いて2本目。「Go + Reactで現場レベルの状態遷移を1つのテーブルに統合する — 13状態×15イベントを型で閉じ込める」という記事です。
これは、状態管理で心当たりがある人、多いんじゃないでしょうか。バックエンドでbooleanフラグがどんどん増えていって、「これtrueで、こっちもtrueのときって、そもそもありえるんだっけ？」みたいな地獄。フロントエンドも同じで、モーダルとオーバーレイが同時に出ちゃうとか、「ありえないはずのUI」が生まれてしまう問題ですね。
この記事では、CSVインポート機能を題材に、13個の状態と15個のイベントを“ぜんぶ列挙して、1枚の状態遷移マトリクスに落とし込む”というやり方を紹介しています。Go側では汎用的な状態遷移マシンのインターフェースを用意して、「Next(from, event)」で次の状態を返すようにしておき、その上にImportJobというドメイン固有の状態を定数とTransitionのテーブル、23本分で表現していく。データアクセスやサービス、ハンドラはinterfaceできちんと分離して、「状態遷移のルール」をひとつのテーブルに閉じ込める構成になっています。
で、面白いのはここからで、フロントエンドのTypeScript/React側も同じ状態遷移テーブルの思想に乗っかるんですね。状態からUIを映像にする関数、「ViewFor(State)」を定義して、状態と表示するUIを1対1で対応付けていく。表示分岐は「job.view」みたいな一箇所に集めておいて、exhaustive check、つまりコンパイラに「すべての状態が必ずハンドリングされているかをチェックさせる」ことで、状態を追加したのにUI側の実装を忘れる、みたいなミスをコンパイル時に検出できるようにしているんです。
さらに、GoとReactの両方について、テーブルレベルのテストと、フォーマット・Lint・テスト・ビルドを一括で回す「bin/quality」みたいなコマンドを用意して、仕様変更時も「このテーブルを直して、影響箇所が自動であぶり出される」構成にしている。結果として、「仕様が複雑になっても、状態を増やすときはこのテーブルに行を足せばよい」という形に近づけているのがポイントです。
「booleanが増えてきて、もう訳がわからない」というプロジェクトにはかなり刺さる内容で、「ドキュメントとしてのテーブル」と「コンパイラが守ってくれる網」の両方を手に入れる設計、というのが印象的でした。

。。。。

3本目は「Claude Codeのマルチセッション管理にジョブキューの概念を取り入れる」という記事です。
Claude Codeをがっつり仕事で使っている人ほど、「セッション多すぎ問題」にぶつかると思うんですよね。CI対応、レビュー反映、複数プロジェクト並行…とやっていると、どのタブで何をやってたか、頭のコンテキストがバラバラになってしまう。
この記事の著者は、その課題に対して「ジョブキュー」という発想を持ち込んで、自作ツール「tq」を作ったという話をしてくれています。tqはCLIとClaude Code Pluginから構成されていて、セッションを「アクション」としてキューに積み、tmux上で対話セッションと非対話セッションを切り替えながら進めていく、というスタイルです。
要は、マネージャーエージェントが全体のタスク分解や進捗管理を担って、人間はTUIで状況を眺めつつ、「これ先にやって」「こっちは後でいいよ」みたいな指示を自然言語で出すだけにする。対話セッションの数を意図的に絞ることで、人間が同時に追わないといけない文脈を減らし、定型作業や待ち時間の多い処理は非対話セッションでどんどんさばいていく設計になっているんですね。
特徴的なのは、tq自体は“薄いキュー層”に徹していることです。ワークフローはできるだけClaude Codeの進化に乗っかるようにしておいて、tqは「ジョブを積んで、状態をトラッキングして、結果を取りまとめる」部分に集中する。CLIのインターフェースはJSON前提で設計されていて、AIから扱いやすい仕様になっています。一方で、人間ユーザーはtqの細かいコマンドを深く知らなくてもよくて、TUIと自然言語で全体を動かせるようにしている。
実例としては、作業中に飛び込んでくる細かい依頼をとりあえずキューに積んでおく話とか、GitHubの通知やメールの下書きを自動生成しておいて、あとでまとめて人間がチェックするフロー、定型作業をぐるぐる回す「Ralph Loop」的な使い方、日報を自動でまとめるまで、かなり生活感のあるユースケースが挙げられています。
既存のセッションマネージャーや、YAMLでガチガチに書くワークフローエンジン、Claude Code自身のAgent Teamsや/loop,/scheduleと比較しながら、「ローカルに常駐して、履歴を引き継ぎつつ複数タスクを並列管理し、人間の負担を減らすジョブキュー」というポジションをはっきりさせているのが印象的でした。AIを「1セッションで全部やる相棒」から、「複数タスクを束ねるオーケストレーションの一員」に進化させていく実践例と言えそうです。

。。。。

4本目は、ちょっと毛色が変わってセキュリティ系。「GHSA-fvcv-3m26-pcqx (Axios の脆弱性) がなんか変」という記事です。
内容としては、Axiosに関するSecurity Advisory、つまりセキュリティ勧告が出ているんですが、その説明している攻撃シナリオ、本当に成立するの？というところを著者が検証している、いわば“検証記事”です。
問題になっているのは、「プロトタイプ汚染と組み合わせることで、ヘッダーインジェクション経由のリモートコード実行や、クラウドメタデータの窃取が可能になる」と説明されている点。著者はNode.jsのhttpモジュールとAxiosを組み合わせてPoC、概念実証をやってみたんですが、Object.prototypeを汚染してもヘッダーインジェクションが再現できなかった、と。
さらに、ヘッダーの中に改行を含めようとすると、Node.js側や新しいAxiosが例外を投げてブロックしてくれることも確認していて、「この前提だと、アドバイザリが説明しているみたいな攻撃、現実には成立しないのでは？」と疑問を投げかけています。もしNode.js以外のHTTP実装を想定しているなら、その前提条件をきちんと書くべきだし、プロトタイプ汚染を前提にCVSSスコア10（最高レベル）がついていることにも違和感を感じているようです。
記事全体としては、「セキュリティアドバイザリって、けっこう鵜呑みにしがちだけど、本当にその環境で再現するのかを検証することも大事だよね」というスタンスが伝わってきます。最近のライブラリ側は、プロトタイプ汚染対策もかなり意識して作られていて、その必要性に改めて驚いた、という締めになっていました。
実務的には、「Advisoryが出た→ただちにパニック」ではなくて、自分たちのスタック・バージョン・ランタイムでどういう影響があるのかを、一歩引いて評価する姿勢の重要性を教えてくれる記事と言えそうです。

。。。。

そして最後、5本目。「GitHub Copilot CLIの画像レビューをスキル化したらUI改善が捗った」という記事です。
これはUIを作っている人、デザイナーさんだけじゃなくてフロントエンドエンジニアにもかなり刺さる内容だと思います。GitHub Copilot CLIでスクリーンショットを`@画像パス`で指定してあげると、GPT-5.4に画像を送ってUIレビューをしてもらえる、という機能を取り上げた記事なんですね。
GPT-5.4は、他のモデルと比べても画像理解やUI評価の精度が高いらしくて、単なる「ここ、ちょっと見にくいですね」みたいなコメントじゃなくて、「背景色は少し抑えて、レアリティの違いは枠線で表現すると視認性が上がりそうです」とか、「散らばっている情報をサマリーボックスに集約して、詳細は折りたたみに回すと情報設計としてスッキリします」みたいな、割と具体的で実践的な提案を返してくれると。
著者はこれをさらに一歩進めて、「screenshot-review」というスキルとして実装し、Claude CodeみたいなAIコーディングエージェントから呼び出せるようにしています。フローとしては、エージェントがアプリのスクリーンショットを撮る → GitHub Copilot経由でGPT-5.4にレビューさせる → 返ってきたフィードバックをもとに、エージェントがコードを直す、という一連のサイクルを自動化しているんですね。
記事の中では、ゲームの報酬画面のUIを段階的に改善していくケーススタディが出てきます。最初は情報がごちゃっとしていたところから、GPT-5.4が「ここに進捗バーを」「ここはグルーピングして」みたいに方向性を出す。Before/Afterの比較をしながら、コードの修正はAIコーディングエージェントが担当し、最後の微妙なバランス調整や演出の追加は人間が仕上げる、という分業体制がうまくハマった、という話です。
ポイントは、「コードを生成するAI」と「画像・UIを見るのが得意なAI」を分業させるワークフローを、CLI経由でつないでいるところにあります。これによって、UIを持つあらゆるプロジェクトで、「実装の前に、まずスクリーンショットをAIにレビューしてもらう」というステップを簡単に組み込めるようになる。結果的に、エンジニアだけのチームでも、ある程度“それっぽいUI”を量産しやすくなるし、デザイナーとのコミュニケーションのたたき台としても使える、というのが面白いところでした。

。。。。

というわけで、今日のzenncastでは、
Claude Codeと相性抜群のブラウザ自動化ツール「agent-browser」の入門と使い分けの話、
GoとReactで状態遷移を1枚のテーブルに閉じ込めて、boolean地獄から抜け出す設計の話、
Claude Codeのマルチセッションをジョブキューでさばく「tq」というオーケストレーションの話、
Axiosのセキュリティアドバイザリ「GHSA-fvcv-3m26-pcqx」にツッコミを入れつつ、検証の大事さを教えてくれる記事、
そしてGitHub Copilot CLIとGPT-5.4を組み合わせて、UIレビューをスキルとして自動化してしまう話、
この5本をご紹介しました。

気になる記事があった方は、詳しい内容や元の記事タイトルはショーノートにまとめておきますので、あとでゆっくりチェックしてみてください。
番組の感想や、「こんな記事を取り上げてほしい」「自分のZenn記事を読んでほしい」といったリクエストも、どしどしお待ちしています。あなたの現場の悩みが、次回のトピックになるかもしれません。

それでは、今週もゆるっと、でも自分のペースでやっていきましょう。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。いってらっしゃい！