どうも、おはようございます。マイクです。
時刻は九月十八日、金曜日の朝七時を回りました。
ここからの時間は「zenncast」、きょうも元気にお届けしていきます。

この番組では、エンジニアのみなさんに役立つ、Zennで話題のトレンド記事をラジオ感覚でゆるっと紹介していきます。
通勤・通学中のあなたも、おうちで作業中のあなたも、耳だけ貸してもらえればオーケーです。

さて、きょう紹介する記事はぜんぶで五本。
AIエージェントのブラウザ操作から、個人Wikiの運用、フロントエンドの新しい設計の考え方、そしてJavaのnull取り締まり実践記まで、幅広く攻めていきます。

それではさっそく、きょうの一本目からいきましょう。

。。。。

まず一つ目は、AIエージェントにブラウザ操作を任せて、エンドツーエンドテスト、いわゆるEツーEテストを自動で回す、ノーコード寄りのテスト運用フローを紹介している記事です。

ここで面白いのが、テストケースの書き方。
gherkin記法を使って、「Given」「When」「Then」といったおなじみの書式で、テストを自然文として書いていくスタイルです。
さらに「Background」を使ったり、「パソコン用」「スマホ用」の切り替えのためのタグを工夫したりして、AIにとっても、人間にとっても読みやすい“手順書”としてテストケースを整えているんですね。

AI側には、「manual-testing」というスキルを用意していて、その中で `playwright-cli` を叩くようにしています。
これをスケジューラから定期実行することで、ブラウザ実機でのテスト実行から、結果レポートの作成、スクリーンショット付きの報告までを、エージェントが自律的にやってくれる構成になっています。

精度の検証として、あえてバグを仕込んでテストしてみたところ、画面上で確認できる不具合については、九件中九件すべて検出。
見逃しもゼロ、誤検知もゼロだったそうです。
しかも、そこまで高価なモデルではない、比較的安価なAIモデルを使ってこの精度が出ているというのがポイントで、「これ、もう実運用に乗せられるレベルじゃない？」という手応えがあった、という話でした。

テストを完全自動化しようとすると、どうしても専用ツールやコードが増えてメンテコストが跳ね上がりがちなんですが、自然文のgherkinで“ノーコード寄り”に寄せつつ、AIとPlaywrightをうまく組み合わせているのが印象的でしたね。

。。。。

続いて二つ目。
こちらはちょっと視点が変わって、個人の記録ツールに、LLMで自動生成するWikiを組み込んで、半年間運用してみた、という経験談です。

筆者の方は、メモや記録をタグで整理していくスタイルのツールを使っていて、そこにLLMを組み合わせました。
タグごとにWikiページを自動生成して、さらにタグ付けや表記ゆれの整理といった、「裏方の分類作業」もLLMに任せる、というアプローチです。
つまり、LLMには、分類と整理と、ページ本文の自動生成、両方をやらせてみたんですね。

ところが、いざ運用してみると、本文のほうは「要約をさらに要約しただけ」みたいな感じになってしまって、内容がどんどん平坦になっていった。
読んでも「あー、ふーん」で終わってしまう、心が動かない読み物になってしまった、という振り返りが書かれています。

一方で、本当に役に立ったのは別のところでした。
二十件以上の記録が付いたタグだけをページ化して、そのタグ同士の「共有出典」から、関連度をグラフとして可視化する二つの画面――
一つはタグの全体一覧、もう一つはタグの関連図――この二つが一番効いたそうです。

特に、「しばらく触れていないタグ」がわかったり、「どのタグとどのくらい強く結びついているか」が視覚的に見えることで、
自分の関心が今どこに向いていて、どこから離れていっているのか、時間を通じてはっきり分かるようになった、と。

この経験から筆者が得た結論は、LLMに“文章そのもの”を書かせるよりも、人間の代わりに「退屈な整理・構造化」をやらせて、その構造を人間が眺めて意味を考えるほうが、圧倒的に価値が高い、ということでした。

「書くのは人間、構造を整えるのはAI」という役割分担のヒントとして、個人の知的生産でもチームのナレッジベースでも応用できそうな話ですね。

。。。。

三つ目の記事は、フロントエンドとAIの関係をガラッと変えるかもしれない話題です。
テーマは「WebMCP」という仕組み。
これは、ブラウザ側のフロントエンドに、AIが直接呼び出せる“操作用の関数”、いわゆるツールを公開してしまおう、という考え方です。

通常、ブラウザ操作をAIにやらせようとすると、人間向けに作られた複雑なUIを、そのままポチポチ操作させることになります。
でも、CMSのように画面が入り組んでくると、それがものすごく非効率になる。
そこで、「人間向けUIをそのまま触らせるんじゃなくて、AI向けに直接操作できる関数を用意したほうが早いよね」という発想がWebMCPです。

筆者の方は、自社CMS「Orizm」のReact製デザインエディターに、このWebMCPを組み込んで実験しました。
やったタスクは、「既存ページを真似して、新しいページを作る」というもの。
一つは、AIにブラウザ操作だけをさせるパターン。
もう一つは、`list_blocks` や `insert_block` といった読み取り・書き込み用のツールをWebMCPとして用意して、そこ経由でブロック操作をさせるパターン。
この二つを比較したんですね。

結果はかなりはっきりしていて、ブラウザ操作だけでやった場合は、完了までに五分五十二秒。
一方、WebMCP経由でツールを呼ばせたケースでは、三分九秒で完了。
つまり、時間にしておおよそ半分になった、という結果でした。

もちろん、シンプルなフォーム入力みたいな単純作業なら、ここまでの仕組みは要らないかもしれません。
ただ、CMSのデザインエディターのように、画面が複雑で、操作パターンも多いところでは、「AI向けの操作口」を最初から用意しておくと、かなり効果が大きい。

筆者は、今後は「人間も使うWebアプリ」の側に、AIが直接叩ける操作口を用意することが、フロントエンド実装の新しい標準になっていく可能性がある、とまとめています。
UIは人間用、APIはサーバー用、そして“AI用のツールインターフェース”という第三のレイヤーが出てくるかもしれない、という話ですね。

。。。。

四つ目は、フロントエンド開発の「仕様」と「実装」と「テスト」の関係を、ガチガチに整理していこう、というかなり実務寄りのお話です。

現場あるあるとして、仕様書は日本語のExcelで書いてある、一方で実装はTypeScriptやReactのコードで書いてある、テストはまた別の形で書いてある。
それぞれの“言語”が違うせいで、「仕様どおりに実装されているか？」とか、「このコンポーネントって、どの仕様のどの項目に対応してるの？」というのをチェックするとき、どうしても人の目と勘に頼らざるを得ない、という問題があります。

この記事では、ここに対して、仕様と実装とテストをすべて、「誰が（Subject）・何を（Object）・どうするか（Verb）」という共通の語彙で統一して、機械的に差分検出できるようにしよう、というプロセスを提案しています。
この「S・O・V」の三つで責務を表す考え方を、「SOVアーキテクチャ」と呼んでいます。

具体的には、まずユーザーの意図ごとに「シナリオ定義書」を作ります。
そのファイルのfrontmatterの中で、「このシナリオには、こういうSubject・Object・Verbの組み合わせの責務があります」という一覧を宣言しておく。
次に、同じ語彙・同じ命名規則で、Reactコンポーネントなどの実装側にも名前を付けていきます。

そして、`ts-morph` というライブラリを使ってコードを解析し、「このプロジェクトには、こういうSOVの組み合わせの責務が実装されている」という集合を機械的に取り出します。
CI上では、「仕様に書いてあるけど、まだ実装されていない責務」と、「実装はされているけど、仕様にはどこにも書かれていない責務」を自動検出する仕組みを回す。
さらに、Playwrightなどのテストコードにも同じSOVのラベルを付けておき、仕様・実装・テストの三者を、同じ責務集合で突き合わせていくことで、トレーサビリティ――
つまり、「どの要求がどこで実装され、どのテストで検証されているか」を、継続的に追えるようにする、という発想です。

従来の要求トレーサビリティマトリクスや、BDD、ユースケース駆動開発といった考え方を踏まえつつも、「人手でIDを振って紐づける」というスタイルではなく、「語彙と命名そのものをキーにする」のが特徴になっています。

もちろん、ユーザーのIntent――何をしたいのか、どんなケースがあり得るのか――の洗い出しそのものは、機械にはできません。
仕様がそもそも間違っていたり、抜けていたりしたら、その正しさは人間がレビューとテストで担保するしかない。
なので、Intentの定義や仕様の質は業務側も含めた人間がしっかり見る。
一方で、「決めたIntentが実装・テストに漏れなく反映されているか？」という部分は、SOVの語彙を軸に機械的にチェックする。
そういう、人とツールの役割分担を提案している記事でした。

。。。。

そして五つ目、ラストの記事は、Javaのnullの扱いをちゃんと決めるために、既存の大規模なSpring Bootプロジェクトに、静的解析ツールのNullAwayをプロダクションコード全体へ段階的に導入していった、という実践レポートです。

もともとの課題は、「この値、nullになる可能性あるんだっけ？」という不確実なNullabilityが多くて、レビューのたびに確認が必要になり、レビュー負荷も高いし、バグの温床にもなっていたこと。
そこで、JSpecifyのアノテーションとNullAwayを組み合わせて、「nullの可否はコンパイルエラーとして管理する」、つまり、コンパイラに判断させる方針を取っています。

導入の順番も工夫されていて、まずはデータベースのスキーマを根拠に、インフラストラクチャ層のDTOのnull可否を整理。
「このカラムは絶対にnullじゃないから、このフィールドもNonNullだよね」といった具合に、スキーマから決めていきます。
次に、ドメインの不変条件――ビジネス上「ここは必ずセットされているべき」というルール――を手がかりに、ドメイン層のNullabilityを整理。
そのあと、OpenAPI仕様を作り直しながらプレゼンテーション層を整えていき、最後に、周辺の層のnull可否が固まった状態で、ユースケース層のNullabilityを「両側から挟み込む」形で決めていく、というステップを踏んでいます。

途中では、単にNullAwayをオンにするだけでなく、API仕様の統一やlintの導入、ArchUnitによる依存ルールの整備、生成コードをどう扱うかといった周辺の整備も並行して実施。
最終的には、すべてのパッケージをNullAwayでチェックするところまで移行できたそうです。

実際にやってみると、作業の多くはツール設定そのものよりも、「このフィールド、本当にnullありなの？なしなの？」という曖昧なNullabilityを洗い出して、仕様として固定していくプロセスだった、と振り返られています。
その中で、エージェントの支援を使ったり、プルリクエストを細かくスキルで分割したりして、機能開発と並行しながら少しずつ前に進めていった、という工夫も紹介されています。

結果として、「念のために入れておこう」といった防御的なnullチェックを減らして、nullに関する判断を、できるだけ人の勘ではなくコンパイラに任せる形に近づけることができた。
とはいえ、Nullableな項目そのものを減らしたり、スキーマを見直したりといった、より根っこの改善はまだまだ続けていく必要がある、と締めくくられていました。

。。。。

というわけで、きょうのzenncastでは、
一つ目に、AIエージェントとPlaywrightを組み合わせて、gherkin記法の自然文テストから、ブラウザ実機テストとレポートまで自動で回す、ノーコード寄りのEツーEテスト運用フロー。
二つ目に、LLMを個人Wikiに組み込み、文章生成よりも「退屈な整理・構造化」を任せるほうが価値が高いと気づいた、半年運用の経験談。
三つ目に、フロントエンドにAI向けの操作ツールを公開する「WebMCP」を使って、CMSのページ作成をおよそ半分の時間でこなした事例。
四つ目に、「誰が・何を・どうするか」というSOVの語彙で、仕様・実装・テストを統一し、トレーサビリティを自動で確保していくフロントエンドのプロセス提案。
そして五つ目に、NullAwayとJSpecifyを段階導入しながら、大規模Spring BootプロジェクトのNullabilityを仕様レベルから固め直していった実践レポート。
この五本を駆け足でご紹介しました。

気になった記事があった方は、ぜひショーノートから元の記事もチェックしてみてください。
今日お話しした内容はあくまで概要なので、実際のコードの構成や運用のコツ、著者の方の葛藤なんかは、本編で読むとまた印象が変わると思います。

この番組「zenncast」では、感想や「こんなテーマを取り上げてほしい」といったリクエストも大歓迎です。
マイクへの質問や、仕事での導入事例、「うちでも似たことやってます！」みたいな話もぜひ送ってください。

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