どうも、マイクです。おはようございます。
七月六日、月曜日の朝七時になりました。今週も zenncast、元気にお届けしていきます。今日は、Zennで話題になっているトレンドの記事を、まとめてじっくりご紹介していきますね。

今日は全部で、五本の記事を紹介していきます。どれも開発者目線で「うわ、それ分かる…」ってなるやつばかりなので、通勤・通学のおともに、ゆるっと聞いていってください。

まず一本目。
Cloudflare Workers と D一、そして better-auth を組み合わせたサービスで起きた、かなりクセの強い障害の話です。「特定のユーザーだけ、ぜんぶのリクエストが固まって、ブラウザを再起動しないと直らない」という、なかなかホラーな現象が起きたそうなんですね。

原因は、Cloudflare Workers 特有の「ハンギング・プロミス」という性質でした。
Workers って、リクエスト処理の途中で作られた Promise が、そのリクエストをクライアント側でキャンセルすると、その Promise が永遠に解決されなくなることがあるんです。で、better-auth 側が「初期化用の Promise を、モジュールとかインスタンスにキャッシュして再利用する」という設計になっていた。
その結果、たまたま認証の初期化を担当していたリクエストが途中で中断されると、その isolate の中にキャッシュされた初期化 Promise が、ずーっと解決されないまま固まってしまう。そうすると、その isolate 内で動いている認証処理が全部止まる、という状態になってしまったわけです。

さらにややこしいのが、接続のルーティングの都合で、「同じユーザーが、壊れたその isolate にずっと当たり続ける」という状況が起きていたこと。なので、そのユーザーから見ると「自分だけ、サーバー全体がずっと落ちてる」ように見えちゃう。怖いですよね。

対策としては三段構えでやっています。
ひとつ目が、AsyncLocalStorage を静的インポートで先にセットしておいて、危険な遅延インポートの経路を通らなくすること。
ふたつ目が、better-auth の遅延初期化処理を `ctx.waitUntil` に乗せて、クライアントが切断したあとでも、その初期化だけはちゃんと完了するようにすること。
みっつ目が、`getSession` にタイムアウト付きのハング検知を入れて、一定時間返ってこなかったら、そのインスタンスを作り直すようにしたこと。
この三つを入れたことで、問題は再現しなくなったそうです。

で、一般的な教訓として語られているのが、「Workers では、リクエスト中に作った Promise を、そのままモジュールスコープとか長生きする変数にキャッシュしないこと」。もしどうしてもやりたい場合は、`waitUntil` を組み合わせるか、タイムアウト付きの監視を入れるべきだと。
Cloudflare Workers とかエッジ環境で認証まわりを作ってる人には、かなり刺さる内容だと思います。。.。。

続いて二本目。
Claude Code の応答が「数分固まって見える」あの問題、ありますよね。「これ、サーバー落ちてない？」「ネットワーク詰まってる？」みたいに感じるやつ。
この記事の筆者が、セッションログを百八十八件も分析してくれています。で、「待ち時間がやたら長かったケース」を三百七十六件ピックアップして調べたところ、なんと本当に API 応答待ちだったケースは、たった一件だけ。残りは全部、「モデルが大量のトークンを延々と出し続けていた長考生成」だった、という結果が出ています。

最初に疑われたのは、サーバーの混雑とか、ネットワークの問題、それから巨大なコンテキストを投げたことによる遅延、モデルごとの生成速度の違い、みたいな仮説だったんですが、トークンレートやエラーログを細かく集計していくと、これらは全部否定されました。
じゃあ何が悪さをしていたのかというと、「調査、設計、実装を一ターンに全部まとめてやらせる」「探索で見つかったものを、親ターンのメモリにどんどん貯める」という使い方と、Opus 四点八というモデルが、重い依頼に対してかなり深く考え込む性質を持っていること。この二つが組み合わさって、thinking と出力が、数千から多いときは数万トークンにまで膨れ上がっていた、というのが原因と分析しています。

そこで筆者が提案しているのが、「探索専用の軽いモデルを subagent として定義して、探索フェーズは必ずそっちに投げる」という設計です。
具体的には、プロジェクトの CLAUDEドットエムディーに、「探索は必ず subagent に委譲すること」というルールを書いておく。さらに hooks の仕組みを使って、「あ、いま探索を本体にやらせちゃってるな」というケースを検知できるようにして、親ターンに重い処理を溜めこまないようにする。
こうやって、プロンプトやルールの設計レベルで「生成量そのものを減らす構造」を作ることで、固まって見える長考を抑えましょう、という提案になっています。Claude Code をヘビーに使っている人には、運用設計のヒントになりそうですね。。.。。

三本目は、開発環境の設定ファイル、いわゆる dotfiles の管理の話です。
この記事では、「開発環境の設定ファイルを GitHub で管理しておくと、新しい端末でも素早く同じ環境を再現できてめちゃくちゃ便利ですよ」というところから入っています。
で、そのうえで、ツールのインストールやバージョン管理に mise というツールを使う話が出てきます。`config.toml` に必要なツールを書いておくと、`mise up` を叩くだけで、Claude Code とか GitHub CLI みたいな開発用ツールを、まとめてグローバルに導入できる、という形ですね。

ここで出てくる悩みが、「バージョン指定を latest にしておくかどうか」。
常に最新を使いたい気持ちはあるんだけど、サプライチェーン攻撃とか、いきなり壊れたバージョンを踏むリスクもあって怖い。とはいえ、いちいち手動でバージョン更新するのもつらい…というジレンマです。

そこで出てくる解決策が、Renovate を CI として dotfiles リポジトリに導入するというアイデア。
Renovate に、mise の設定ファイルを監視対象にしてもらって、そこで指定しているバージョンを固定しつつ、自動で更新 PR を出してもらう。
さらに、Renovate の「dependency cooldown」という機能を使って、新しいバージョンが出ても、すぐには飛びつかず、一定期間様子見してから更新できるようにする。
これによって、「ある程度の安全性を確保しながら、開発ツールを自動で、いい感じの最新状態に保つ」というバランスが取れるよ、という話になっています。

dotfiles、mise、Renovate、この三つの組み合わせで、「新しいマシンでも `mise up` 一発で、しかもそこそこ安全な最新環境が立ち上がる」っていうのは、環境構築が苦手な人にもかなり嬉しい仕組みなんじゃないかなと思います。。.。。

四本目は、コードレビューのオピニオン記事です。
筆者が、自分の環境で三か月間に行ったレビュー指摘を三百件ほど集めて、分類と「効き目」の採点をしたところ、本当に効果があったと感じられたのは、バグ指摘、つまり Bug と、仕様に関する質問、Spec の二種類だけだった、という話から始まります。

逆に、Style、Naming、Refactor、Architecture といった指摘は、品質や開発速度への貢献が小さかったり、むしろ開発速度を落としていた、という結果が出たそうです。特にポイントになっているのが、「`nit:` みたいな細かいスタイル指摘が多いプルリクエストほど、レビュアーの注意が分散して、本当に見つけるべきバグの検出精度が落ちていた」という観測です。
つまり、「細かい見た目を直せば直すほど、コードの本質的な質が下がってしまう」という、ちょっとショッキングな逆効果が見えてきた、というわけですね。

そこで筆者は、「じゃあ、レビューで守るものを二つに絞ろう」と提案しています。
スタイルは自動整形ツールに任せてしまう。命名は、事前にルールを決めておくのと、必要であれば AI によるチェックを使う。リファクタリングやアーキテクチャの大きな話は、プルリクの前に設計レビューをしたり、別のプルリクに切り出す。
そのうえで、プルリクレビューの場では、「バグの有無」と「仕様の理解・仕様通り動いているか」の二つだけに集中する体制に変えよう、という主張です。

この「二種類だけ守るレビュー」に切り替えた結果、筆者のチームでは、レビュー時間がだいたい四割ぐらい減ったそうです。その一方で、バグと仕様の理解に関する指摘の密度は上がった。
レビューをどう回すか、チームで悩んでいるところには、かなり議論のきっかけになりそうなオピニオンでした。。.。。

最後、五本目はサービス紹介の記事です。
EnvVault というツールなんですが、一言で言うと、「ドットエンブイファイルに本物の API キーを置かずに、ローカル開発したい人向けの、軽いコマンドラインツール」です。

ふつうローカル開発だと、`.env` に生の API キーを書いてしまいがちですが、EnvVault ではそこに `envvault://openai/dev` みたいな参照だけを書いておきます。本物の値は、macOS のキーチェーンとか、各 OS 標準のパスワード保存場所に入れておく。
そして、`envvault exec` でアプリを起動するときだけ、その参照を解決して、本物の値を環境変数として子プロセスに渡す、という動きになっています。
これによって、リポジトリや `.env` ファイルそのものには、生の API キーを残さずに済むわけですね。

さらに、対応している SDK であれば、ローカルホスト経由のプロキシモードも使えます。このモードでは、アプリケーション側には EnvVault 独自の一時トークンだけを渡しておいて、実際のプロバイダの API キーは、EnvVault が許可したリクエストにだけ付けて送る形になります。
もちろん、完全にすべてを隔離できる、というよりは、「ローカル開発でのシークレットの露出範囲を、できるだけ小さくする」ことに特化した、小さな secret 起動用ツールだ、という立ち位置です。

「とりあえず `.env` にキーを書いてるけど、本当はもうちょっとちゃんとしたい…」という人にとっては、そこまで重くない導入コストで、一段安全側に寄せられる選択肢になりそうです。

さて、そろそろお別れの時間です。
今日は五本、ご紹介しました。
Cloudflare Workers と better-auth で、特定ユーザーだけ固まってしまうハンギング・プロミス問題と、その三段構えの対策。
Claude Code の「固まって見える応答」の正体が、ほぼ全部、長考生成だったというログ分析と、subagent への探索委譲という設計の話。
dotfiles を GitHub で管理しつつ、mise と Renovate を組み合わせて、「ほどよく安全で、いい感じに最新」な開発環境を保つワークフロー。
それから、コードレビューは Bug と Spec の二種類に集中させて、他はツールや別プロセスに逃がそう、というオピニオン。
最後に、`.env` に本物のキーを置かずにローカル開発できる EnvVault という、小さなシークレット起動ツールをご紹介しました。

気になった記事があれば、詳しい内容や元の記事へのリンクは、ショーノートにまとめてありますので、そちらからじっくり読んでみてください。
zenncast では、番組の感想や、「こんなテーマを取り上げてほしい」みたいなリクエストも大歓迎です。ラジオネームを添えて、ぜひ気軽に送ってください。

それでは、月曜日の朝、七時台のおともは zenncast、マイクがお送りしました。
また次回お会いできるのを楽しみにしています。今日も一日、良いコードを書いていきましょう。