おはようございます！ zenncast、MCのマイクです。11月2日、月曜日、朝7時になりました。新しい1週間のスタートですね。温かい飲み物でも片手に、今日も気軽にお付き合いください。
この番組では、Zennで今日トレンドの記事をご紹介します。今日は、AIと挑む高速化競技の振り返りから、Webアプリの公開方法、PRの自動レビューまで、全部で5本をお届けします！
....
まず1本目は、Claude Codeに作業を任せて、ISUCON2026に挑んだお話です。
ISUCONは、Webサービスの高速化を競う競技です。筆者は今回、自作ツールを使わず、Claude Codeに作業を任せる形で参加しました。事前に取り組んだ過去問では、なんと当時の優勝スコアを大幅に上回っていたそうです。これは本番にも期待が高まりますよね。
ところが、本番は単純に処理を速くするだけでは解けない問題だったとのこと。結果は、40位から50位程度になる見込みだと振り返っています。
筆者が敗因として挙げているのは、AIによる作業時間の見積もりです。大きな修正に必要な時間を長く見積もってしまい、処理が一部のサーバーに集中する設計を直せなかったそうなんですね。
ここでのポイントは、AIに任せても、人間の判断が差を生むということです。AIの実装速度を踏まえて、どの変更にどれだけ時間がかかるかを判断する。そして、人間が問題点や戦略を把握しやすいように、情報の見せ方も工夫する。その両方が重要だったといいます。
実装が速いからこそ、「残り時間で何を変えるか」という判断の重みも増すんですね。AIを使う競技ならではの、興味深い振り返りです。
....
続いて2本目は、Cloudflare Workersで、Reactの画面とAPIをまとめて公開するお話です。
Cloudflare Workersでは、Reactで作った画面とAPIを、1つにまとめて公開できます。Viteプラグインを使えば、ローカルでの開発でも、画面とAPIを同時に動かせるそうです。開発から公開まで、まとまった構成で扱えるのが便利ですね。
公開の手順は、ビルドと、Wranglerによるデプロイの2段階です。ただし、この構成ではビルドで生成された設定ファイルが使われます。そのため、設定を変えたあとは、もう一度ビルドする必要があるという点に注意です。
もう1つ、SPA設定ならではの挙動も紹介されています。ブラウザでAPIのURLを開いたときに、APIの応答ではなく、画面が返ってくる場合があるんですね。APIを優先して動かすには、対象のパスにrun_worker_firstを設定します。
さらに、APIだけでなく画面にもIP制限をかけたい場合は、すべてのリクエストをWorkerに通します。CF-Connecting-IPを許可リストと照合して、許可された場合だけAPIや画面を返す、という方法です。
この構成は、小規模なWebアプリや認証処理に向いているとのこと。一方で、メモリは128MB固定で、無料プランではCPU時間にも制限があります。重い処理を任せる場合には、この制約を意識する必要があるんですね。
手軽にまとめて公開できるからこそ、設定の反映方法やリクエストの流れまで押さえておきたい、というお話でした。
....
続いて3本目は、ISUCONに初参加した筆者が、Codexと一緒に性能改善に取り組んだ記録です。
こちらでは、実装をCodexに任せ、DB接続の再利用や、検索用の索引の追加などを進めたそうです。その結果、基準となるスコアを約4.2倍に伸ばしました。初参加でこれだけ改善できるのは、うれしい成果ですよね。
ただし、AIに任せれば、改善の方向性まで全部決まるわけではありませんでした。AIは、既存の作りを前提に、その中で改善しようとしがちだったとのことです。
たとえば、通知の仕組みそのものを変えるような判断は、人間が担いました。筆者も、実装を任せることはできても、大きな方針は人間が考える必要があると振り返っています。
また、作業を自動化するための準備に、競技時間の半分近くを使ったそうです。その経験から、事前準備と、作業を並列に進めることが今後の課題として挙げられています。
自動化は頼もしい味方ですが、その仕組みを整える時間も必要なんですね。何を事前に準備して、当日は何に集中するか。AIとの役割分担に加えて、時間の使い方も考えさせられる記事です。
....
続いて4本目も、ISUCON2026への挑戦記です。今度は、新卒1年目のエンジニア2人が参加したお話をご紹介します。
2人は、初めて触るGoやAWSに戸惑いながらも、AIの助けを借りて改善を進めました。取り組んだのは、DBの検索、処理の順番待ち、通信の遅延などです。結果として、スコアは3970から15905へ、およそ4倍に伸びたそうです。
この記事で筆者が伝えているのは、経験が浅いことよりも、「計測して試し、だめなら戻す」という姿勢が大切だということです。
性能改善では、ある場所を速くすると、今度は別の場所が遅さの原因になることがあります。だからこそ、「きっとここが原因だろう」という思い込みだけで判断せず、変更した結果を繰り返し確かめていく。その過程に、学びと面白さがあったと述べています。
初めての技術が多い中でも、測って、試して、結果を見る。その積み重ねが約4倍という成果につながったんですね。これから性能改善に挑戦したい方にも、背中を押してくれる記録です。
....
最後、5本目は、Teamプランに付くAPIクレジットを、組織共通のPR自動レビューに活用するお話です。
使うのは、月最大500ドルのAPIクレジットです。ここで押さえておきたいのが、公式のClaude Code GitHub Actionは対象外ですが、自作のGitHub Actionsから非対話モードで実行すれば、対象になるという点です。
レビューでは、PRの差分や関連するIssueを集めて、Claudeにレビュー結果をJSONで返してもらいます。その結果をコメントとして投稿する処理は、別に分けているそうです。この仕組みを、複数のリポジトリで共通して使います。
認証にはWIFを使います。GitHub側の認証情報を、短時間だけ有効なトークンに交換する方式です。これによって、それぞれのリポジトリにAPIキーを配る手間と、キーが漏洩するリスクを減らせます。
安全対策としては、PR側の設定を実行しないこと、そしてClaudeの操作を読み取りに限定することが挙げられています。さらに、レビューごと、月ごとの両方で費用の上限も設定します。自動で動く仕組みだからこそ、権限と費用の管理もセットなんですね。
実測の費用は、レビュー1回あたり0.5ドルから3ドル程度とのことです。リポジトリごとにレビューの観点を調整できる一方、Copilotとのレビュー品質の比較については、まだ検証中だそうです。
使えるクレジットを生かしながら、認証、安全性、費用まで含めて、組織全体で使える仕組みにしている点が参考になりますね。
....
さて、今日は5本の記事をご紹介しました。
Claude Codeに任せて挑んだISUCON2026の振り返り、Cloudflare WorkersでReactの画面とAPIをまとめて公開する方法、Codexと進めた初めてのISUCON、新卒エンジニア2人の計測を重ねた高速化、そして、APIクレジットを活用するPR自動レビューのお話でした。
AIに実装を任せる場面が増えても、方針を決めること、結果を確かめること、安全に運用することは大切。今日は、そんな共通点も感じられましたね。
詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてください。番組の感想もお待ちしています。「この記事が気になった」「こんな使い方をしています」といったお声も、ぜひ聞かせてくださいね。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回もお会いできるのを楽しみにしています。今週も、無理せず自分のペースでいきましょう。zenncast、マイクでした。いってらっしゃい！