どうも、マイクでーす。おはようございます。
今日は二千二十六年十月三日、土曜日の朝七時になりました。
この番組「zenncast」では、きょうも Zenn に上がっている技術記事の中から、今ホットなトレンド記事をピックアップしてご紹介していきます。
さてさて、きょうも気になる記事がたっぷり揃っておりますので、さっそく本題にいきましょう。
きょうご紹介する記事は、ぜんぶで五本です。技術寄りのお話が多めなので、コーヒーでも飲みながら、ゆったり聴いてください。
まず一つ目。
一つ目は、Claude Code、特にプロとかマックスのプランでおなじみの「五時間枠」と「週間枠」、これが実際どうやって減っているのかを、ものすごくガチで調べ上げた技術レポートです。
環境としては Max 二十倍の環境で、実際にたくさんリクエストを投げて、その挙動から「裏側の計算式、こうなってるんじゃない？」と逆算していった、かなりマニアックな内容になっています。
記事によると、一回のリクエストでどれくらい枠を消費するかは、
「モデルごとの重み かける、かっこ、インプット ＋ キャッシュ書き込み × 一・二五 ＋ アウトプット × 五 ＋ キャッシュ読み出し × ゼロ・ゼロ二五、かっことじる」
みたいな形で近似できる、と。
さらに、これが対話モードなのか、ヘッドレスなのか、あとアクセスしている時間帯によっても、五時間枠と週間枠への換算倍率が変わる、というのがポイントです。
特にヘッドレスの利用だと、五時間枠の減り方が最大で二・八六倍も早くなるケースがあるらしくて、「なんかヘッドレスだけ異様に減り早くない？」って感じていた人には刺さる内容ですね。
モデルの「重み」も面白くて、Haiku、Sonnet、Opus、Fable の順に、一対一・五対二・二〜二・七五対十、という比率になっていると推定されています。
これ、公式に出ている API の料金比、だいたい一対二対四対五対十、とはちょっとズレていて、「ドル換算の料金」と「サブスクの枠の減り方」が必ずしも一致していないんですよね。
さらに、キャッシュリード、つまりキャッシュ読み出しも、ウェイトとしてはゼロ・ゼロ二五倍と軽いんですが、ちゃんと枠のカウント対象になっているので、キャッシュを多用するワークロードだと、無視できないインパクトになってきます。
あと重要なのが、二千二十六年九月中旬に、事前告知なしでこの計算式が変わったらしい、という点です。
このタイミングで、アウトプット側の重みは軽くなった一方で、さっきのキャッシュリードが新たにカウントされるようになった、と。
公式には「五時間枠をプラス二十パーセントしました」と案内されていたんですが、この記事の実測だと、増え方はおおよそ一・一一倍、つまり十一パーセントぐらいにとどまっているそうです。
このあたり、公式の告知に出ている数字と、実際の枠の変化量が食い違っているんじゃないか、という問題提起にもなっていて、「どうしてこんなに減りが早いんだろう？」と悩んでいる人には、かなりの解像度で答えをくれる内容になっています。
。。.。.
続いて二つ目。
二本目は Next.js のキャッシュまわり、特に `use cache: private` と Partial Prefetching を組み合わせたときの挙動についての解説記事です。
「プライベートキャッシュにしてるから、サーバー側には残らないよね」と思いきや、設定次第ではブラウザ側にキャッシュが残ってしまう、というちょっと怖いパターンを教えてくれています。
ポイントは、`cacheComponents: true` と `partialPrefetching: true` をオンにしているケースです。
この状態で、たとえば `cacheLife({ stale: 三百 })` みたいに、ステールタイムを五分以上に設定していると、同じブラウザの中でページ遷移したときに、前にレンダリングした結果がそのまま再利用されることがあります。
つまり、「サーバー間では共有されていないけど、同じブラウザユーザーの中では、そこそこ長くキャッシュが効く」状態になるわけですね。
ここで問題になるのが、クッキーに基づいた値をキャッシュしている場合。
Server Action から `cookies().delete()` を呼ぶと、その場で UI が再レンダリングされるので、ログアウトなんかもきれいに反映されます。
一方で、Route Handler 側でクッキーを消したり、クライアントで `document.cookie` を直接いじって削除しただけだと、ブラウザに残っている古いキャッシュがそのまま表示され続けてしまうことがある、と。
ログアウト処理なんかでこれをやられると、別ユーザーが同じブラウザを使ったときに、前のセッションの情報がチラッと見えてしまう、というリスクがあるわけです。
なのでこの記事では、そういったケースでは `router.refresh()` を呼んで、アプリ全体を再取得させてあげるとか、最悪 `window.location.href` を使ってページ全体をフルリロードしてあげる、といった対策が必要だよ、とまとめています。
とくに認証系やユーザー情報を扱う画面では、「サーバーのキャッシュ戦略」だけじゃなくて、「ブラウザまわりで残るキャッシュ」も意識しないと危ないよ、というのを丁寧に教えてくれる記事です。
。。.。.
さあ、三つ目の記事です。
三本目は、AWS のエージェント SDK「Strands Agents」で使われている、Strands Decider Two B というモデルについての技術解説。
これは「文章を生成するモデル」というよりは、「候補の中から一つを選ぶことに特化した判断モデル」ですね。
記事自体はオピニオンというより、サービス紹介寄りのテクニカルな解説になっています。
この Strands Decider Two B は、Qwen 三・五–Two B–Base というモデルを土台にしていて、文章を理解する力はそのまま活かしつつ、出力部分だけを差し替えています。
普通の言語モデルだと、「次に来るトークン、単語を一個ずつ生成していく頭」を持っているんですが、ここを「用意された候補を採点する頭」、いわゆる Pointer Head に置き換えているんですね。
さらに LoRA と呼ばれる小さめの追加パラメータで、「どの候補を選ぶのが良いのか」という判断を学習している、という構造になっています。
入力としては、「状態」つまり問い合わせ本文とか、そのときのコンテキストと、「こういう基準で判断してね」という指示、そして「この中から選んで」という候補リストを一緒に渡してあげます。
モデルはそれに対して、各候補ごとの確率と、候補数をちゃんと考慮した Confidence、つまり「分布がどれくらい一つに集中しているか」の指標を返してくれます。
この Confidence が高ければ、「この選択にはかなり自信があるよ」、低ければ「どれにしても微妙かも」といったニュアンスが読み取れるわけですね。
記事の中では、日本語の質問三百件をつかった業界分類タスクで、いくつか条件を変えながら検証しています。
たとえば、候補それぞれに説明文を付けるかどうか、候補リストの順番を入れ替えたら結果が変わるのか、Confidence のしきい値をどこに置くかで、精度や採用件数がどう変わるか、などです。
実験の結果としては、候補の順序によって結果が変わってしまうことがあるとか、Confidence のしきい値を高く設定すると、採用件数は減るんだけど、そのぶん「採用した分だけの正解率」は上げられる、というトレードオフが見えてきたと。
つまり、「自信がないときは ‘選ばない’ という選択もする」ことで、実務での誤判定を減らせるよ、という感じですね。
実運用上の注意点としては、まず入力の長さの制限があります。
状態と指示、それから候補説明を全部突っ込んでいくと、けっこうすぐにトークン数の上限に当たってしまうので、候補の説明をどこまで厚く書くかは、精度とのバランスになります。
もう一つは、「どれにも当てはまらない」という候補をちゃんと用意しておく必要がある、という点。
現実の問い合わせだと、あらかじめ用意したカテゴリにきれいに収まらないケースも多いので、そこを無理やりどれかに割り振らないようにするためですね。
エージェントシステムの「最終決定役」に、こういう専用のデシジョンモデルをかませることで、LLM だけに全部を任せるよりも、安定した挙動が得られる、というのが記事全体のメッセージになっています。
。。.。.
では、四つ目。
四本目は C ライブラリ、glibc に入っている `strlen` 関数の実装が、どうやって高速化されているのかを解説した記事です。
`strlen` って、「文字列の終端のゼロ文字を見つけるだけでしょ？」と思いがちなんですが、実は中身はかなりの職人芸になっています。
ふつうストレートに書くと、一バイトずつ `'\0'` を探していくような実装になるんですが、glibc 版ではもっと賢いアプローチを取っています。
具体的には、文字列のちょっと外側まで含めて、ワード、つまり六十四ビット単位でまとめて読み込むことで、一気に処理してしまうんですね。
これをやるときにネックになるのが、ページ境界をまたいでしまってアクセス違反、いわゆるセグフォが起きないようにすることです。
そのために、読み出すアドレスを八バイト境界に揃えながら、二千二十三年の変更では、文字列の先頭より少し手前のワード境界から読み始める工夫が入っています。
終端文字、つまりゼロバイトの検出には、ワード全体を整数として扱って、引き算とか AND、NOT などのビット演算を組み合わせて、「このワードのどこかにゼロがあるか」を一度に判定するテクニックが使われています。
先頭付近の処理では、「文字列より前にあるゼロは無視したい」という事情があるので、各バイトについてちゃんとゼロ判定ができる `find_zero_all` という仕組みと、シフト処理を組み合わせて、最初の `'\0'` の位置を正確に計算しています。
その後、文字列の途中をぐるぐる回るループでは、「ゼロがどこにあるか」までは分からなくてよくて、「このワードにゼロが一個でも含まれているかどうか」だけ分かればいいので、もっと軽い式である `find_zero_low` で判定します。
そして、ゼロが検出された最後のワードのところでだけ、マスクから `__builtin_ctzl` なんかを使って、ゼロバイトの位置を求める、という流れです。
こうやって、「ゼロがあるかどうか」だけ知りたい場面と、「最初のゼロの位置をちゃんと知りたい」場面とで、ビット演算のやり方を切り替えることで、`strlen` だけじゃなく `memchr` とか `strcpy` といった基本関数も、現代の CPU 上でさらに速く動くように最適化されているんですね。
普段は一行で呼んで終わりの関数の裏側に、こんなロマンが詰まっているのか、というのが伝わる記事でした。
。。.。.
そして最後、五つ目の記事です。
五本目は、Cloudflare の新しい統合 CLI「cf」と、TypeScript ベースの設定ファイル `cloudflare.config.ts` への移行手順と注意点をまとめた、Tips 系の記事です。
これまで Wrangler やいろんな設定ファイルをバラバラに扱っていた人にとって、「そもそも何が嬉しいの？」というところから、実際に移行するときの手順、そしてハマりポイントまで、一通り押さえてくれています。
まずメリットから。
一番大きいのは、設定とアプリのコードが TypeScript で強く結びつく点です。
`cloudflare.config.ts` にすると、IDE の補完が効いたり、型チェックで設定ミスを早めに検知できたりするので、「typo ひとつで本番が落ちる」みたいな事故を減らせます。
さらに、Workers だけじゃなくて、Cloudflare の他のサービスも含めて、一つの CLI「cf」でまとめて扱えるようになるのもポイントですね。
Vite や React Router と一緒に開発するときの体験も良くなりますし、設定が TypeScript で書かれているぶん、AI ツールに「ここ直して」と頼んで自動編集させやすい、というメリットもあります。
実務での具体的なステップとしては、まず `cf migrate` を実行して、既存プロジェクトを新しい形式に変換します。
そのあと `cloudflare.config.ts` の中に残っている TODO やエラー表示を一つずつ潰していって、`bindings.secret()` の定義をちゃんと書いてあげる。
それから `cf workers types` を実行して、型情報を生成しておくと、エディタ上で Workers の型がきれいに補完されるようになります。
フロントエンド側では、Vite の設定で `experimental.newConfig: true` を有効にして、BOS の出力内容を React Router などと同期させる、という手順も必要です。
最後に、`package.json` のスクリプトを古い `wrangler` コマンドから、新しい `cf` 系のコマンドに置き換えていく、という流れですね。
一方で、落とし穴もいくつか紹介されています。
たとえば、Windows 上の純粋な Worker で `cf deploy` を叩くと、`spawn EFTYPE` というエラーになってしまう問題があって、これは内部で Wrangler に委譲するときの不具合が原因とされています。
また、新しい `cf deploy` には `--var` オプションがなくなっているので、従来このオプションで変数を渡していた CI などは、そのままだと動かなくなってしまいます。
さらに、CI や E2E テストが `wrangler.jsonc` に依存している場合、何も考えずにこのファイルを削除してしまうと、パイプラインが一気に壊れる、という怖いパターンもあります。
記事では、そういう環境では、しばらくのあいだ Wrangler や旧設定との併用も視野に入れて、段階的に移行していくのがいいですよ、とアドバイスしています。
新しいツールチェーンは便利な反面、移行の影響範囲も大きいので、そのあたりを現場目線で整理してくれているのがありがたい記事でした。
。。.。.
ということで、きょうの zenncast はここまでです。
きょうはまず、Claude Code の五時間枠と週間枠が、モデルごとの重みやキャッシュの使い方でどう減っていくのかを実測で解析した記事、
次に、Next.js の `use cache: private` と Partial Prefetching の組み合わせで、ブラウザ側にキャッシュが残る落とし穴と、その対策のお話。
三本目に、AWS の Strands Agents 向け判断モデル、Strands Decider Two B が、候補選択タスクでどう使えるのかという技術解説。
四本目は、glibc の `strlen` がワード単位の読み込みとビット演算で高速化されている仕組み、
そして最後に、Cloudflare の新 CLI「cf」と `cloudflare.config.ts` への移行メリットと注意点を、駆け足でご紹介しました。
気になった記事や、もう一度じっくり読みたい内容があれば、詳しいリンクや情報はショーノートにまとめてありますので、あとでチェックしてみてください。
番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストも、どしどしお待ちしています。
それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回の zenncast でお会いしましょう。