おはようございます。マイクです。
朝の zenncast、2026年3月18日、水曜日の朝7時をまわりました。
この番組では、毎回Zennで話題になっているトレンド記事をピックアップして、通勤通学のおともにゆるっとご紹介していきます。今日も最新の技術ネタを一緒にキャッチアップしていきましょう。

今日は、全部で5本の記事をご紹介していきます。
CIのローカル実行ツールから、ちょっと変態チックなタスクランナー、フロントエンドのディレクトリ構成、AIコードレビューの育て方、そしてApple Neural EngineでLLMを速くしようとしたチャレンジまで、濃いラインナップになってます。

まず1本目。
タイトルは「GitHub Actions 互換のローカルタスクランナーを作った」。
GitHub Actionsって便利なんですけど、「ちょっと直して動かしてみよう」がけっこう重いんですよね。ワークフローの起動を待って、ログ見て、artifacts拾って…みたいな。そのストレスを一気に解消しようとしているのが、この記事で紹介されている「actrun」です。
やっていることは、ざっくり言うと「.github/workflows/*.yml を、そのままローカルで動かせるようにする」というもの。GitHub ActionsのYAMLを、スクリプトDSLみたいに解釈して、npxでサクッと動かせたり、ネイティブ、Dockerからも使えたりします。「--dry-run」や「--dry-run --json」で、どんなジョブが動くかを事前に確認できるので、他のスクリプトと組み合わせることも想定されています。
面白いのは、actions/checkout みたいな標準アクションも、ローカル用に独自実装しているところ。worktreeを使うか、一時ディレクトリに置くか、完全ローカルでやるか、といった切り替えもできて、matrix や needs、if、workflow_call、container/services までかなりの範囲をカバーしています。Nixと組み合わせてツールチェーンを自動で揃えたり、gitの差分ベースで「変わったところだけ実行」したり、失敗ジョブのリトライまで実験中ということで、「CIのデバッグ、まずローカルでサクッとやろうよ」という世界観がかなり実用レベルまで来ている印象でした。今後GitHub以外のCIにも広がっていくかも、という話もあって、CIまわりの開発体験をガッツリ変えてきそうなツールですね。

。。.。。.。.

続いて2本目。
タイトルは「Vite+ の異常なタスクランナー: vite-task は如何にしてキャッシュの手動依存管理をなくしたか」。
名前からしてすでにちょっと怪しい香りがするんですが、内容もかなり攻めてます。vite-taskは、Turborepo や Wireit みたいな、monorepo向けのタスクランナーなんですが、一番の特徴が「キャッシュのための依存ファイルを手で列挙しなくていい」というところ。
普通のタスクランナーだと、「このタスクは、このファイルとこのディレクトリに依存しています」って設定で書き忘れると、キャッシュが外れなかったり、逆に全然ヒットしなかったりするんですよね。vite-taskはそこを、OSレベルのテクニックでゴリっと解決していて、タスクが実行されている間に「プロセスが実際に読み書きしたファイル」を全部自動で追跡して、それをそのままキャッシュキーにしてしまう、という発想です。
裏側で動いているのが Rust 製の「fspy」。動的リンクされた libc を LD_PRELOAD でフックして、open とかファイル関連の関数呼び出しを横取りしちゃう。で、そのアクセスログを共有メモリに書いていく。さらに、子プロセスを生む exec 系の関数もフックして、LD_PRELOAD をプロセスツリー全体に伝播させるので、「タスクの中で spawn された子プロセス」も含めて、全部のファイルアクセスが追えるようになっている、と。
これが使えない静的リンクバイナリなんかに対しては、seccomp の USER_NOTIF を使ったシステムコール監視にフォールバックする、という二段構え。OSの低レイヤにあまり詳しくない筆者が、それでもこのアプローチの面白さを噛みしめていて、「キャッシュの依存ファイル管理って、設定じゃなくてOSが教えてくれればいいじゃん」という視点がとてもエモい記事でした。monorepoでキャッシュ設計に日々悩まされている人には刺さりそうです。

。。.。。.。.

3本目。
タイトルは「フロントエンドのディレクトリ構成で再帰的な features 構成を推したい」。
React + TypeScriptで大規模開発をやっていると、「featureごとにディレクトリを切る」というのは、もはやわりと定番なんですが、数が増えてくると「これ、どこまでがこのfeatureの責務なんだっけ？」とか「sharedが肥大化して何でも倉庫になってきた」みたいな問題が出がちですよね。
この記事で提案されているのは、featureを「再帰的にネスト可能な単位」として扱う構成です。要となるのが、各featureの `index.tsx` を「唯一の公開インターフェース」にする、というルール。他のfeatureからは、この `index.tsx` だけをインポートして、中にあるコンポーネントを直接触らない。API呼び出しやビジネスロジックは `index.tsx` に寄せて、見た目だけの「描画コンポーネント」はその配下に置く。
これを徹底すると、「このフォルダの中が、このfeatureのスコープです」というのがディレクトリ構造だけで分かるようになります。特定feature専用のコンポーネントも、そのfeature配下に閉じ込められるので、shared/ 以下にどんどん私物が溜まっていく、という悲劇も防ぎやすくなる。
さらにテスト戦略として、「APIモックが必要かどうか」を基準に、featureとcomponentを分類しているのも面白いポイントです。`index.mock.tsx` を用意しておけば、テストやStorybookからはそれを差し替えるだけで、そのfeatureに必要なAPIモックが一括で効く、という仕掛けになっていて、「モックをどこに書く問題」にも一つ解を出している形ですね。bulletproof-react との比較もしつつ、「ドメイン」よりも「コンポーネントの凝集とスコープの見えやすさ」を優先したいチームにとって、かなり参考になりそうな構成案でした。

。。.。。.。.

4本目。
タイトルは「AIコードレビューを「単一責任の原則」で育てた話」。
AIにコードレビューさせてみたものの、「なんか毎回言うこと違うし、的外れなコメントも多いし、これ本当にレビューになってる？」って感じたことがある方、多いと思います。このチームは、そこで「AIにも単一責任の原則を適用しよう」と考えたのが面白いところです。
グロービスのDevExチームでは、Claude CodeのSub-agents機能を使って、「観点ごとに専用のAIレビュワーを分割」しています。たとえば、Rails向けのもの、Flaky Testを検知するもの、ページネーションとソートのバグを見つけるもの…といった具合に、実際に過去に起きた障害パターンを元に、エージェントごとにMarkdownプロンプトと description を作る。「どんなPRで呼び出すべきか」をかなり具体的に書いておくことで、ツール側が自動的に最適なエージェントを選んでくれるようにしているんですね。
ポイントは、AIを「導入して終わり」にしないこと。障害が起きて、その原因が判明したら、そのナレッジを「新しいエージェント」や「既存エージェントの改善」として還元していく。こうして役割ごとにAIを育てていくと、人間がつい見落としがちな観点を、AIが機械的にカバーしてくれるようになっていく。
このやり方は、Claudeに限らず、CursorやCopilotのような他ツールにも応用できる考え方として紹介されています。AIレビュワーを「チームの一員」として扱い、失敗パターンを言語化して蓄積していくことで、結果的にチームの暗黙知を形式知として残せる、という副次効果もある、というのがいいですね。「AIが賢くない」というより、「AIにどんな役割を与えて、どう育てるか」の話なんだな、と思わせてくれる記事でした。

。。.。。.。.

そして5本目。
タイトルは「Apple Neural Engine の Private API を叩いて LLM 推論を高速化しようとした話」。
これはApple Silicon好き、ローカルLLM好きにはたまらない内容でした。Qwen3.5 の登場で、「手元でそこそこ強いLLMを動かす」というのが現実路線になってきたタイミングで、「じゃあMacに積まれているApple Neural Engine、まだ余ってるよね？ これ直接叩いたらもっと速くならない？」というチャレンジをした記録です。
最初にシンプルな Linear を乗せてみたところ、データ転送のオーバーヘッドが大きすぎて、Metal GPUに完敗。しかし、FFNブロックを15個の演算にfuseすることで、ようやく2〜12倍の高速化が見えてくる。その過程で、D=4096 のときだけやたら遅い、という謎現象にぶつかり、調べていくとSRAMのbank conflictが原因らしいと判明。そこで+64のパディングを入れることで解消する、という、かなりハード寄りのチューニングまでやりきっています。
ただ、系統的にベンチマークしていくと、「Dが1024以下の小さいモデル」ならANEがかなり効く一方で、実際に使いたい4B以上のLLM、しかもMLXのlazy evaluationやFlashAttention込みでE2Eで測ると、結局Metal GPUの方が速い、という現実も見えてきます。結論としては、「ANEは、小さなモデルを固定shapeで、省電力かつGPUを空けたまま回す用途にはすごく向いているけど、実用サイズのLLMをガチで高速化するには、構造的に向いていない」というもの。
この「やってみたらダメでした」も含めて、どこにANEの適性があるのかをかなり丁寧に掘り下げていて、Private APIを叩く系のニッチな探究が、ちゃんと実務的な示唆にもつながっている、読み応えのある記事でした。

。。.。。.。.

ということで、今日のzenncastでは、
GitHub Actions互換のローカルタスクランナー「actrun」の話、
OSレベルでファイルアクセスを追跡するタスクランナー「vite-task」の話、
Reactフロントエンドでの再帰的features構成の提案、
AIコードレビューを単一責任の原則で育てる運用の話、
そしてApple Neural EngineでLLMを速くしようとしたチャレンジ、
この5本をご紹介しました。

気になった記事があれば、詳しい内容はショーノートのリンクから、ぜひ原文をチェックしてみてください。この台本では触れきれなかったコードや図解、筆者の試行錯誤もたっぷり載っています。
番組への感想や、「こんなテーマも取り上げてほしい！」といったリクエストも、どしどしお待ちしています。あなたの一言が、次回のラインナップを決めるかもしれません。

それでは、そろそろお時間です。
今日も一日、良いコードと良いデバッグに恵まれますように。
お相手はマイクでした。また次回の zenncast でお会いしましょう。