おはようございます！「zenncast」、MCのマイクです。10月22日、木曜日、朝7時になりました。今日もZennでトレンドになっている記事から、気になる話題をお届けします。朝のお支度や通勤のおともに、どうぞお付き合いくださいね。
今日は、CIの待ち時間改善から、AIによる問い合わせ調査、セキュリティ診断、ポケモンカードのAI対戦、そしてLaravelの認証に関する注意点まで、5本の記事をご紹介します。
....
まず1本目は、CIの待ち時間を、テスト前の準備から見直したお話です。
筆者がClaude CodeでCIの時間の内訳を計測したところ、テスト本体にかかっていた時間は、なんと全体の14パーセントでした。そこで注目したのが、テストそのものではなく、テストが始まるまでの準備時間です。ここを改善することで、待ち時間の中央値を約15分から4分45秒へ、約69パーセント短縮したそうです。
具体的な工夫を見ていきましょう。まず、画面の描画が必要ないテストは、ブラウザ環境を再現するjsdomではなく、Node.js環境で実行するようにしました。また、2 CPUの環境でも、テストを2並列で動かす設定にしています。
データベースの準備も見直しています。毎回ゼロから構造変更を適用するのではなく、適用済みの状態を保存しておき、次回はそれを復元して使う仕組みです。さらに、ほかのPRでも共有できるように、キャッシュはmainブランチで作成するようにしました。
データベースが不要なテストは別のジョブに切り出し、そのテストをさらに2分割して並列実行します。一方で、テストでコードのどこまで確認できたかという割合は、各ジョブの結果を合算して判定するようにしています。速くするだけでなく、全体の確認範囲もきちんと把握するわけですね。
加えて、node_modulesを保存・復元して、毎回のインストールも省略しています。ただし、キャッシュは容量の上限を超えると古いものから削除されるので、不要な保存を減らすことも大切だそうです。
テストが遅いと思ったら、実は準備に時間がかかっていた。まず内訳を測ることの大切さが伝わる記事ですね。
....
続いて2本目は、Devinによる問い合わせ調査で、なぜ原因を特定できないことがあるのかを分析した記事です。
筆者は、過去の問い合わせ約700件をLLMで分類しました。その結果、約56パーセントはバグではない問い合わせだったそうです。そして、そのバグではない問い合わせのうち、現在確認できる知識やコード、ログだけで原因を特定できるものは、約44パーセントでした。
では、確認できる情報を増やしたらどうなるのでしょうか。顧客の設定や外部サービスとの連携状態が入ったデータベースまで確認できれば、この割合は計算上、約73パーセントまで上がるとしています。ただし、ここは大事なところで、実際の調査精度が73パーセントになると保証する数字ではありません。問い合わせの分類に基づいた見積もりなんですね。
筆者が述べているのは、調査の成果を左右するのは、AIの賢さ以上に「何を確認できるか」だということです。どれだけ優秀でも、原因につながる情報が見えなければ、調べられる範囲には限界があります。
もちろん、データベースを見せるなら、読み取り専用にすることや、個人情報を保護することが必要です。そのうえで、さらに確認対象を広げるなら、自社の処理記録よりも、Googleなど外部サービス側の状態が有力だとしています。
AIを変える前に、AIが見られる情報を点検してみる。問い合わせ調査の仕組みづくりで、参考になりそうな視点ですね。
....
3本目は、AIが役割分担してWebアプリの弱点を探す、Strixというツールのお話です。
Strixは、オープンソースのペネトレーションテストツールです。複数のAIが役割を分けて調査し、実際に攻撃を再現して確認できた問題だけを報告する、という特徴があります。再現手順や対策を含んだ、日本語のレポートも作成できるそうです。
記事では、意図的に脆弱性を仕込んだRailsアプリを対象に、URLだけを与えて診断しています。その結果、約30分で6件の問題を検出しました。利用するAIモデルは選択できますが、今回の検証でかかったAPI利用料は19.77ドルだったとのことです。
ただし、すべてを見つけられたわけではありません。認証したあとの複雑な操作や、画面からリンクされていない機能については、見落としがありました。URLを渡すだけでは、ツールがたどり着けない場所もあるんですね。
そこで、調査してほしい内容を具体的に指示したり、ソースコードも渡したりすることで、診断できる範囲を広げられるとしています。
自分たちが診断する権限を持つ環境で使うことを前提に、得意な範囲と見落としやすい範囲を理解して活用したいツールですね。実際に再現できた問題を、手順や対策と一緒に確認できる点も注目です。
....
続いて4本目は、ポケモンカードのAI対戦コンペに挑戦した記事です。
筆者が採用したのは、行動の候補それぞれに点数をつけ、その評価をもとに行動を選ぶルールベースの方法でした。結果は、6807チーム中590位。銅メダルを獲得しています。たくさんのチームが参加するなかでの銅メダル、すばらしいですね！
開発では、まず対戦の様子を見て、改善案を考えます。それをCodexで一つずつ実装し、同じ条件で多数の対戦を行って、本当に効果があったか確かめる。この流れで改良を重ねたそうです。
ただ、コンペの終盤になると、強化学習を使う参加者には及ばず、手作業でルールを改善していく方法の限界も感じたと述べています。
振り返りで挙げられているのが、勝率だけに頼らない評価の必要性です。たとえば、理想の盤面を作るまでに何ターンかかったかも確認することで、勝ったか負けたかだけでは見えない違いを評価できる、ということですね。
また、チーム内の役割分担や、指示の内容も、もっと明確にする必要があったと振り返っています。
AIで実装を進めるだけでなく、何を改善とみなすのか、どう分担するのかまで設計する。ゲームの対戦AIに限らず、開発全般にもつながる学びが詰まっていますね。
....
最後、5本目は、Laravelのtoken guardを使っている方に確認していただきたい、認証に関する話題です。
Laravelのtoken guardには、MySQLやMariaDBの環境で、APIトークンを知らなくても認証を通過できる問題があります。ただ、公式情報では、11系以下の修正状況が分かりにくくなっているそうです。
そこで筆者は、全タグのソースを調査しました。その結果、11系では11.56.1から修正済みであることを確認した一方、10系以下では同じ修正を確認できなかったとしています。ただし、筆者は実際に攻撃が成功するかどうかまでは検証していません。ソースの修正状況を調べた結果と、実際の攻撃の成否は、分けて受け止めたいところです。
利用者がまず確認したいのは、自分たちの環境でtoken guardを使っているかどうかです。使っている場合は、11系なら11.56.1以上、12系なら12.68.0以上、13系なら13.29.0以上への更新を進める必要があります。
すぐに更新できない場合には、認証処理に入る前に、トークンが文字列であることを確認する対応が必要だとしています。
Laravelを使っているというだけで一律に判断せず、認証方式とバージョンを確かめて、必要な対応につなげてくださいね。
....
さて、今日のzenncastは、5本の記事をご紹介しました。
CIはテスト前の準備を見直して待ち時間を短縮。Devinの問い合わせ調査では、AIが確認できる情報が成果の鍵になるというお話。Strixによる、攻撃の再現まで行うセキュリティ診断。そして、ポケモンカードのAI対戦から学ぶ評価と役割分担、最後はLaravelのtoken guardの修正状況と対応についてでした。
詳しい内容はショーノートにまとめていますので、気になった記事をぜひチェックしてみてください。
番組の感想もお待ちしています。「この話が気になった」「自分の現場ではこうしています」など、ぜひ聞かせてくださいね。この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回もお会いできるのを楽しみにしています。お相手はマイクでした。今日も、よい一日をお過ごしください！