どうも、マイクです。おはようございます。
二千二十六年九月十七日、木曜日の朝七時をまわりました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。
さて、きょうはお便りはお休みということで、そのぶん記事紹介をみっちりやっていきましょう。
きょうご紹介する記事は、ぜんぶで五本です。AI開発、Next.js、ゲームAI、そしてテストがほぼ無いレガシー環境でのAI活用まで、かなり攻めた内容がそろってます。
まず一つ目。
テーマは「AIにバイブコーディングでGUIアプリを書かせると、なぜだんだんカオスになるのか？」というお話です。
最近流行りの、AIに「ここ直して、あそこ変えて」ってバイブコーディングでGUIアプリを作らせていくと、最初はそれっぽく動くんですけど、そのうち画面同士が互いを直接操作し始めて、キー連打とか、処理中に別の操作をした瞬間に状態がぶつかり合うんですよね。
その結果、「この画面を閉じるまで戻れない」とか、「本来表示されるはずの画面が出てこない」とか、不具合が連鎖的に増えていく、という問題を指摘しています。
原因としては、画面ごとにバラバラに判断していて、イベントの流れとか状態管理を、どこか一箇所でちゃんとまとめてないからだ、と説明しています。AIに任せると、その場その場で都合のいいところからボタン押したり、画面を直接いじりにいっちゃうんですよね。
そこで筆者が提案しているのが、「古くからある設計パターンをちゃんと組み合わせて、壊れにくい構造をAIに強要しよう」という発想です。
具体的には、すべてのUIコンポーネントを一つのRootの下に置いて、画面側のViewは「受動的な描画専用」、いわゆるパッシブビューにする。ユーザーの操作イベントは、Chain of Responsibilityのパターンで親方向に伝播させていって、最終的にMediatorがステートマシンとして状態遷移を一元管理する、という構造です。
で、この構造を人間ががんばって設計するんじゃなくて、「こういうルールでUIを作りなさい」というのを一文の“呪文”としてプロンプト化して、AIに投げるのがポイント。
その呪文を毎回バイブコーディングの最初に読ませておくと、「画面同士が直接触りあってぐちゃぐちゃ」みたいな状態になりにくくて、比較的壊れにくいGUIアプリになりやすいんじゃないか、という提案になっています。
AIに設計を任せるというより、「設計パターンのレールを先に敷いておく」ことで、事故を減らそうという発想が面白いですね。
。。。。
続いて二つ目。
こちらは「開発の一日の流れを丸ごとAIにやらせるスキルを作って、Issue取得からPR作成まで半自動化してみた」という体験談です。
GitHubのIssueを前提にしていて、まずAIがIssueを拾ってきて、そこから設計と実装をClaude Codeが担当します。
そのあと、別のAIであるCodexがコードレビューをして、人間は最後にクリティカルな観点でレビューする、という流れになっています。
おもしろいのが、この一連の流れをかなり細かく定型化して「一つのスキル」にしているところです。
たとえば、ブランチをどう作るか、ベースブランチをどう決めるか、作業ログをどこに保存するか、Codexにレビューをお願いするときの依頼テンプレートはどうするか、こういう実務的なポイントを全部レシピ化しているんですね。
このスキルによって何が起きたかというと、開発の主導権が人間からAI側に移るんですね。
開発者は「自分がタスクを回す」のではなく、「AIが進めてくることに答えたりレビューするだけ」でよくなる。結果として、作業の負荷がぐっと下がった、と。
特に効いているのが、AIが工程全体を理解して、先回りでPull Requestの素案作成までどんどん進めてくれるところ。人間が「そろそろPRにしようかな」と考える前に、たたき台ができているイメージですね。
さらに、窓口役となるAIを一つに決めておいて、そのAIが裏側でサブAIとやりとりしてくれる、という構造も実務的にかなり便利だとしています。
「このAIに話しかけておけば、あとは勝手に設計も実装もレビューも進んでいく」という状態に近づけていくことで、日々の開発フローを丸ごとAI寄りにシフトする、というお話でした。
。。。。
三つ目の記事は、Next.jsユーザーにとってじわっと怖い、でもめちゃくちゃ役立つ知見です。
テーマは、Next.jsのProxy、以前のMiddlewareですね。ここでリダイレクトを返すときのLocationヘッダーが、どう扱われるか、という細かい挙動について。
まずProxy側では、Locationヘッダーには「絶対URL」、つまりプロトコルとホスト名、ポートまで含めたフルのURLを渡す必要があります。
もしここにいきなり「スラッシュから始まる相対パスだけ」を書くとエラーになってしまう。
ところが、その絶対URLが、元のリクエストと同じオリジン、つまり同じホスト名・同じポートであれば、Next.jsが自動的に「相対URL」に書き換えて返してくれる、という動きになります。
一方で、外部サイトへのリダイレクトの場合は、そのまま絶対URLで返される、という挙動ですね。
一方、Route Handler側はちょっと違います。こちらでは、`redirect("/path")` のように、相対パスをそのまま指定することができますし、`new Response` でLocationに「スラッシュ始まりのパス」を入れて返す、ということも可能です。
ただ、ここで`new URL("/path", request.url)` のように、request.urlをベースに絶対URLを組み立てる書き方をすると、ホスティング環境によっては`request.url`がローカルの`localhost:3000`になっていたりして、思わぬ事故が起こりうる、と警鐘を鳴らしています。
つまりまとめると、Proxyでは「必ず絶対URLを渡す。でも、元のリクエストと同じオリジンであれば自動的に相対URLに変換される」。
Route Handlerでは「相対URLをそのまま書けるけれど、自動変換はない。そのかわり、request.urlをどう扱うかはホスティングごとに前提が違うので注意が必要」という違いがあります。
「request.urlはいつも本番ドメインだろう」と思い込んで書くと危ないので、デプロイ先のサービスごとに、この前提をちゃんと確認したうえで設計しようね、という実務目線の解説でした。
。。。。
四つ目は、ゲームAIの話。
ポケモンカードのAI対戦環境を使ったコンペで、上位プレイヤーのリプレイから模倣学習を行いつつ、終盤だけモンテカルロ木探索でリーサル、つまり「このターンで勝ち切る手順」を探す、ハイブリッドなエージェントを作った事例です。
このAIは、盤面の状況、手札、サイド落ち、ターン内での行動履歴といった情報を、かなり細かく特徴量として取り込んでいます。
それをLightGBMに食べさせて、「そのとき人間が実際に選んだ行動」を貪欲に予測させることで、短期間でもそこそこ強いAIを作る、というアプローチを取っています。
ここでのポイントは、「重い強化学習ではなく、まずは模倣学習で人間のプレイを真似させる」ことで、短い期間でも実用レベルの強さに持っていけているところです。
終盤のリーサル探索では二段構えになっています。
まず、「確定で勝てるかどうか」をルールベースで判定。ドローとか確率要素が絡まない、見えている情報だけで勝ちが決まるパターンは、ここでさくっと見つける。
それでも足りない場面、つまりドロー運が絡むような局面では、PUCTという手法を使ったモンテカルロ木探索で、「このターンのうちに勝ち切れる確率はどれぐらいか」を推定しながら、行動を選んでいきます。
序盤のプレイについては、ルールベースの戦略を組んでみたり、手作業で盤面評価関数を作ってみたり、「絶対にやってはいけない行動」をガードレールとして入れてみたり、いろいろ試したそうなんですが、
最終的には、シンプルに「模倣学習＋終盤のリーサル探索」という構成の方が勝率が高かったそうです。
この結果から、筆者は、「短期間で現実的に強いポリシーを作りたいなら、重くて時間のかかる強化学習に突っ込むより、模倣学習と小さな探索の組み合わせのほうが有効なケースが多い」という示唆を得た、とまとめています。
ゲームAIに限らず、業務フローの最適化にも通じそうな考え方ですよね。
。。。。
そして五つ目。
これはかなり攻めた現場の話です。「十年以上動いているWebサービスで、自動テストが一件もない」という、なかなかスリリングな環境で、開発速度を倍にするために、あえて人の確認を減らしてAI主導のフローに振り切ってみた、という経験談です。
この現場では、もともとコード差分を人が行単位でじっくり読む、という手作業のレビューがボトルネックになっていました。
そこを思い切って削ってしまって、要求整理、見積もり、実装、コードレビュー、試験仕様書の作成といったプロセスを、Claudeを中心としたスキルで自動化して、人間は「六つの要所」だけで承認する形にしたそうです。
もちろん、ここには大きな前提があります。
テストやCI、静的解析といった、「壊したときに自動で反応してくれる仕組み」がほとんどないことを、ちゃんと自覚したうえで進めている、という点です。
著者は、「どこで誤りが止まり、どこをすり抜けるか」を図解して可視化しつつ、要件ドキュメントをきちんと整備して、さらに試験仕様書でカバーする、という形でリスクをコントロールしようとしています。
一か月ほど運用してみたところ、スピードの低下はなく、むしろ並行して回せるタスク数は増えたとのこと。
その一方で、トークン制限でAIの文脈が切れてしまう問題とか、レビュー負荷が特定の人に偏りがちになること、さらには「要件自体が現実とズレてきたときに、それを検出できない」という根本的な課題も見えてきたといいます。
この経験から著者が強調しているのは、「こういうテストの薄い環境でAI活用を広げるなら、まず『壊したときに何が反応してくれるのか』を数値で把握すること」。
そのうえで、「検知力がどれくらい薄いか」を自覚して、どこまでAIに任せるか、その範囲を慎重に決める順番が大事だ、と結んでいます。
スピードアップの話というより、「安全側の線引きをどう考えるか」という、現場感のある記事でした。
。。。。
というわけで、きょうのzenncast、五本まとめてお届けしてきました。
AIにGUIを作らせるときの設計パターンの“呪文”の話から、開発フロー丸ごとの半自動化、Next.jsのProxyとRoute Handlerのリダイレクト挙動の違い、ポケモンカードAIの模倣学習と終盤探索のハイブリッド戦略、そしてテスト皆無のレガシー環境でのAI主導フローまで、一気に駆け足でおさらいしました。
気になる記事の詳しい内容や元ネタへのリンクは、この番組のショーノートにまとめておきますので、通勤通学のあとで、ぜひじっくりチェックしてみてください。
番組への感想や、「こんなテーマを取り上げてほしい」といったリクエストも、いつでもお待ちしています。
それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回のzenncastでお会いしましょう。