どうもー、おはようございます。マイクです。「zenncast」朝のお時間がやってまいりました。
今日は2026年3月11日、水曜日の朝7時台にお届けしていきます。
この番組では、Zennで話題になっているトレンド記事を、ラジオ感覚でゆるっと、でも内容はがっつりめにご紹介していきます。

さて今日は、お便り紹介はお休みで、その分しっかり記事を深掘りしていきたいと思います。
ご紹介する記事は全部で5本。技術選定からSEOトラブルシューティング、コンパイラの最適化、LLM時代の新言語設計、そしてRAGの次の一歩まで、かなりバラエティ豊かなラインナップになっています。

まず1本目。
タイトルは「DenoからBunに切り替えたらシングルバイナリが約9分の1になった」。
TypeScriptで書かれたCLIツール「Rulesync」を単体バイナリで配布している著者の方が、Denoの `deno compile` から、Bunの `bun build --compile` に乗り換えたところ、バイナリサイズが最大で約9分の1まで小さくなり、ビルド時間も1分18秒から数秒レベルまで一気に短縮された、というレポートです。
ポイントは、Bunが内蔵バンドラでtree-shakingをがっつり効かせて、`--minify` も使いながら「本当に使っているコードだけ」を最適化してバイナリに埋め込んでくれるのに対して、Denoはnpmの `node_modules` を含む依存パッケージをごっそりバイナリに詰め込む設計になっているところ。結果として、配布用バイナリのサイズ差が如実に出たかたちですね。
運用面も面白くて、GitHub Actions上ではUbuntuランナーでBunの `--target` を使って全OS向けにクロスコンパイルしつつ、`actions/cache` で成果物を共有して、各OSのランナーでE2Eテストを回す、というパイプラインにしているそうです。Denoは安全性や開発体験の良さが評価されつつも、「サイズを最優先するなら、現状はBunが有力候補」という結論。CLIツールを配布している方にはかなり刺さる検証になっていると思います。
。.。.。.

続いて2本目。
タイトルは「秘密にしたい URL が Google 検索に載ってしまった話」。
これ、テーマがかなりユニークで、サカバンバスピスの顔をランダム生成して遊べるWebアプリを作った著者の方のお話です。URLのパラメータにseedを持たせて、「自分で引き当てた“当たり”の顔」をシェアできるようにしていたんですが、その“当たりURL”がGoogle検索結果に出てしまって、「自力で見つける楽しさ」がスポイルされる、という事態になってしまったと。
技術的な原因は、HonoとViteでSSRしていて、seedごとにOGPを変えて返していたものの、canonicalタグを設定していなかったために、検索エンジン側がそれぞれ別ページとしてインデックスしてしまったこと。
対応としては、まずSearch Consoleでサイト所有権を確認して「一時的な削除」を使い、既にインデックスされてしまったURLを非表示に。そして、すべてのページにcanonicalタグを追加して、正規URLをトップページに統一したうえで、`og:url` はseed付きのままにしてSNS用とSEO用の役割を分離しています。ここで面白いのが、noindexとcanonicalの併用は混ぜるな危険、という実践知で、シグナルがバラけるのでcanonical一本に絞ったと。
さらにアプリ側でも工夫していて、図鑑でまだ出会ってないseedからやってきた場合は「シェアされたかお」と表示して、「自分で見つけたか」「誰かに教えてもらったか」を区別できるようにしています。教訓として、公開前にcanonicalなどSEOの基本設定をちゃんと見直すこと、SSRを自前でやるならSEO周りも自分で責任を持つこと、そしてSearch Consoleは早めに導入しよう、というメッセージが込められています。
。.。.。.

3本目の記事。
タイトルは「LLVMに対する32ビット定数除算の改善」。
コンパイラ好き、低レイヤー好きにはたまらない内容です。LLVMで、符号なし32ビット整数の「定数除算」、例えば x を7で割る、みたいな処理をもっと高速にする最適化パッチがmainブランチにマージされた、という技術レポートになっています。
従来はGM法という手法にもとづいて、乗算と加減算、それからシフト命令を組み合わせて、整数除算をエミュレートしていたんですが、今回のアプローチでは「33ビットのマジック定数を64ビットに拡張し、u64×u64→u128乗算の上位64ビットだけを取り出す」という形に式変形することで、事実上「乗算1命令で除算を実装する」というスタイルに持ち込んでいます。
x64アーキテクチャならmulx、Apple M4ならumulhといった命令1発で、x/7, x/19, x/107といったパターンが表現できるようになり、ループ内の命令数がかなり減った結果、ベンチマークではXeon環境で約1.67倍、M4で約1.98倍という、体感レベルでわかる高速化が出ています。
実装面では、DivisionByConstantInfoでマジック定数の再構成を行い、TargetLowering::BuildUDIV側で128ビット乗算の「上位64ビット利用」パターンに変更する、という形で統合。さらに生成AIもフル活用して、パッチ作成やリファクタリングを進めたというのも今っぽいポイントですね。RISC-Vなど他のアーキテクチャにもこの最適化が水平展開されていることが確認されていて、GCC側にも同様の最適化を持ち込む試みが進行中とのこと。mulxをumulh相当として使うパターン追加で、LLVM並みのコード生成を狙っていく見通しが語られています。
。.。.。.

4本目。
タイトルは「『Claude Code に向いているプログラミング言語』記事を見て、LLM が書きやすい言語 Almide を土日で作ってみた」。
これは「人間が書きやすい言語」ではなく「LLMが書きやすい言語」をガチで設計してしまった、というチャレンジングな記事です。Claude Codeの言語別ベンチマークを見た著者の方が、「じゃあ最初からLLMが迷わないような文法に振り切った言語を作ればいいのでは？」と考えて、週末でAlmideという新言語を設計・実装したお話になっています。
言語設計の方向性としては、nullやエラー処理をOptionとResultに統一して、else必須のifや網羅性チェック付きのmatch、そして副作用のある処理はeffect fnに限定するなど、とにかく「LLMが間違えやすい表現」を文法レベルで潰しにいっているのが特徴です。
実装プロセスも面白くて、まずはBNFからTypeScriptのトランスパイラを起こし、その後Claudeの力も借りながらRust製コンパイラへと移行。最終的には、Rust、TypeScript、WASMの3種類のターゲットコードを生成できるようになっています。パフォーマンスとしてはRubyの約3倍遅いぐらいとのことなんですが、そこは「まだAlmideコードのデータが少ないからLLMがうまく最適化できていない」という見立てで、その代わりに非常に手厚いエラーメッセージを用意して、LLM自身が自己修正しやすい設計にしているのがポイント。
WASM対応のPlaygroundや、モジュール・依存管理、HTTPや正規表現といった標準ライブラリ、タプルや構造化エラー型なども揃えたうえで、v0.1.0として公開されています。将来的には、Almideのコードが増えていけば増えるほど、次世代のLLMがAlmideをより速く、正確に扱えるようになる、という「フライホイール仮説」も提示されていて、言語設計とAIの関係性を考えるうえでかなり刺激的な内容になっています。
。.。.。.

そして最後、5本目。
タイトルは「RAGで足りなくなったので Agentic Search を調べてみた」。
社内向けの情報検索チャットボットをRAGで構築していた著者の方が、「どうしても辿り着きたい1文」に届かないケースが増えてきて、次の一歩としてAgentic Searchを調べてみた、という実務寄りの知見共有です。
RAGは基本的に「ユーザーの質問に対して、ベクトル検索を1回か数回行い、引っかかったコンテキストをもとに回答する」というワンショット志向の仕組みなんですが、曖昧な質問や、複雑で段階を踏まないと理解できない問い合わせには弱い。そこで出てくるのがAgentic Searchで、これはLLMエージェントが質問を分解し、検索戦略を自分で立てて、検索→評価→再検索、というサイクルを自律的に回していくアーキテクチャです。
RAGとの違いは、単に「検索前にちょっと要約する」レベルではなく、複数のデータソースやツールを動的に切り替えながら、探索の深さや方向性もLLM自身が調整できる点。これによって精度や対応力は上がる一方で、レイテンシは伸びるし、トークンコストも増えますし、設計もぐっと複雑になります。さらに、多段階推論になればなるほど、一箇所のハルシネーションが後段に伝播してしまうリスクも増える。
その対策として、RAGをグラウンディングの基盤として組み合わせて使うことや、マルチエージェントでお互いの回答を検証させる、人間によるレビューを重要なところだけ挟む、といった工夫が紹介されています。導入判断の指針としては、シンプルなQ&Aや「とにかく速く返したい」用途ならRAGで充分。一方で、複雑な質問や異なる種類のデータをまたいだ探索、あるいは正確性が最優先の領域ならAgentic Searchも検討したほうがいい、とまとめられています。最終的には、「エージェントにお任せ」ではなく、ちゃんとツール設計とデータ構造を整えたうえで段階的に拡張していくのが大事だよ、という、かなり現場感のある提言になっています。

というわけで、今日のzenncastは、
DenoからBunへの乗り換えでシングルバイナリを劇的に軽量化した話、
seed付きURLがGoogleにインデックスされてしまったところからcanonicalとSearch Consoleでリカバリした話、
LLVMの32ビット定数除算を「実質乗算1命令」にまで最適化したパッチの話、
LLMが書きやすいことを第一に設計された新言語Almideの話、
そしてRAGの限界からAgentic Searchへ踏み出すときの考え方、
この5本をご紹介しました。

気になる記事があった方は、詳しい内容や元記事へのリンクはショーノートにまとめてありますので、ぜひそちらからチェックしてみてください。
番組の感想や、「こんな記事を取り上げてほしい」「ここもっと深掘りしてほしい」といったリクエストも、どしどしお待ちしています。

それでは、そろそろお別れの時間です。
お相手はマイクでした。また次回のzenncastでお会いしましょう。いってらっしゃい！