どうも、マイクです。おはようございますー。
2026年3月26日、木曜日の朝7時をまわりました。「zenncast」今日も元気にお届けしていきます。
この番組では、エンジニアのみなさんの朝のお供に、Zennで今トレンドの記事をゆるっと、でも中身はしっかりめにご紹介していきますよ。
さて今日は、Zennで話題の記事を全部で5本、ご紹介していきます。アーキテクチャの話からAI活用、CI高速化まで、朝から情報量多めでお送りしますので、コーヒーでも飲みながら、耳だけ貸してもらえたらうれしいです。
。.。.
じゃあまず1本目。
タイトル「ハーネスエンジニアリングで人間のコードレビューをやめる」。
なかなか攻めたタイトルですよね。「レビューをやめるってどういうこと？」って思うんですけど、ここで言っているのは、人間がやらなくてもいい“機械的なチェック”はAIに任せちゃおう、という話です。
ポイントは「AIに丸投げ」じゃなくて、「ハーネス」と呼ばれる仕組みをちゃんと設計してあげること。制約を与えて、必要な情報を渡して、結果を検証して、ダメなら修正して……という枠組みの中でAIを動かすんですね。
この記事では、差分のレビューから、重要度のトリアージ、修正の実行、根本原因の検証までを、CodexとComposer 2という2種類のモデルに分担させて、最大6ループ回す、っていうかなり本格的な自動レビューの流れが紹介されています。さらにプロジェクト独自のガイドラインも参照させて、一貫性を保つ工夫もされている。
で、そのワークフローを「Rigg」というCLIでYAML管理して、Gitでバージョン管理することで、チームみんなで改善していけるようにしているんですね。人間は、「どの課題を優先するか」「何を作るか」といった上流の判断に集中して、方向性が決まったあとの品質チェックはAIに任せる。この役割分担の整理がすごく現実的だなぁと感じました。
。.。.
続いて2本目。
タイトル「クリーンアーキテクチャで迷子になったときに読む、もっと直感的なアーキテクチャ（Go実装例付き）」。
クリーンアーキテクチャとかヘキサゴナルとか、「言ってることはわかるけど、実際にフォルダ構成どうしたらいいの？」って悩む方、多いと思います。この記事では、そのモヤモヤを「コネクタブルアーキテクチャ」という考え方で整理してくれています。
キーワードは「Area」と「Connector」。App InOut、App Logic、App Infraみたいな“技術ごとのエリア”をまず分けておいて、エリア同士は直接importせず、必ずConnectorを噛ませてつなぐ、というシンプルなルールを採用します。
App Logicの中にはmodel、repository、service、usecaseといった“ビジネスロジック”を置いて、DBとか外部API、UIみたいな技術的な部分はInfraやInOut側に閉じ込める。で、その橋渡し役をConnectorが担当して、インターフェースの実装とデータ変換をやることで、疎結合を保ちながらテストしやすくするんですね。
狙いは、「用語の難しさ」じゃなくて「どこに何があるか一目でわかる構造」にすること。人間にもAIアシスタントにもわかりやすい設計を目指していて、Goの実装例付きでかなり具体的に解説されています。クリーンアーキテクチャで挫折しかけた人の“もう一回トライ用”の記事としても良さそうです。
。.。.
3本目。
タイトル「Microsoft Learn参照させるAgent Skillsあるじゃん！」。
これはAIエージェント側の“教え方”に関する記事ですね。筆者の方は、AI活用でちょっと出遅れたかも……と思いながら、巻き返しに向けて「Agent Skills」という仕組みを調べています。
Agent Skillsは、特定の作業手順とか、ツールの使い方をモジュールとして切り出しておいて、必要なときにエージェントが読み込めるようにするもの。毎回プロンプトで長々説明しなくても、「このスキルを参照してね」と渡すことで、安定して同じ動きをしてくれるようになる、というイメージです。
記事では、Microsoft公式のAzure開発用Skillsリポジトリをクローンして、CopilotやClaude Codeごとのフォルダに配置することで、Azure設計、セキュリティ、デプロイなどのベストプラクティスを、エージェントにちゃんと踏まえさせる、という使い方が紹介されています。
面白いのが、スキル自体は“知識の本体”というより、「何を、どのドキュメントで確認するか」という参照ガイドになっていて、実際の情報はMicrosoft Learnを検索・取得する「Learn MCP Server」と組み合わせて取ってくる前提になっているところ。MCPが使えない環境でもWebフェッチで代替できる柔軟さがあります。
筆者は、こうした仕組みを身につけることで、「調査」「設計」「ドキュメント作成」まで含めた開発スピードを一気に上げていきたい、という決意も書いていて、“AIをちゃんと使えるエンジニア”への第一歩としてのリアルな視点が印象的でした。
。.。.
4本目。
タイトル「Webアプリケーションにおけるキャッシュ戦略」。
キャッシュって、なんとなく「入れれば速くなるんでしょ？」って思いがちなんですが、この記事はまずそこに冷や水を浴びせてくれます。「キャッシュなしでできる高速化は、本当にやり切った？」という問いから始まるんですね。
キャッシュを入れると、たしかに高速化やコスト削減の効果は大きい一方で、不整合のリスク、障害ポイントの増加、設計の複雑化、検証コストの増大といった“裏側のツケ”が増える。なので、「まず使う」じゃなくて、「使うべき理由があるか」をちゃんと考えようと。
記事では、アプリ側で重い処理結果をKVS（memcachedやRedis）に入れるパターンと、HTTPレスポンスをブラウザやCDN、プロキシにキャッシュさせるパターンを分けて整理しています。
アプリ側キャッシュでは、TTL設計、Thundering herd対策、キーの設計、ヒット率やevicted数の監視など、運用していくうえでのチェックポイントが丁寧にまとまっています。一方、HTTPキャッシュでは、Cache-Control、ETag、Last-Modifiedをどう使うか、静的ファイルとCDNを組み合わせて転送量とレイテンシをどう削るか、といった実践的な話が中心。
ただし、CDNや各種ミドルウェアによって挙動が違うので、「仕様書を読む」「実機で検証する」をセットでやらないと痛い目にあうよ、という警告付きです。キャッシュ導入の“覚悟リスト”としても読める記事でした。
。.。.
そして5本目。
タイトル「8,706回のINSERTがCIを殺していた — Rails CI 55%短縮の全手順」。
これはRailsのCI改善のリアルな事例ですね。GitHub ActionsでRSpecを5分割して回しているんだけど、最遅で8分超えてしまっていて、開発テンポをかなり邪魔していたと。そこから、インフラとアプリの2段階でチューニングして、最終的には8分8秒から3分37秒まで、約55%短縮したというストーリーです。
第1弾は「本番コードはいじらない」方針で、MySQLテスト環境の設定を見直します。innodb_flush_log_at_trx_commitやsync_binlogをテスト用に緩めてI/O待ちを減らしたり、ランナーのサイズを適切にしたり、DateTime.now依存のflaky testを直したりして、これだけで約47%短縮。
第2弾では、test-prof/FactoryProfでボトルネックを可視化してみたら、なんとINSERTが8,706回も走っていたことが判明。ここをactiverecord-importでバルクINSERT化して56回まで減らし、テストのパラメタライズや重複削減、CI matrixの再分割なども合わせて、さらに17%短縮しています。
おもしろいのは、「インフラ → アプリ」の順でやること、「どこに時間を投資するか」を計測ベースで決めていること、そして「やらない施策」をちゃんと選んでいること。このあたりは、パフォーマンスチューニング全般に通じる考え方ですよね。最後には、MySQL設定の緩和、FactoryProfでの計測、1,000回超INSERTのバルク化といった“明日からすぐ試せるチェックリスト”も載っていて、CIが遅くて悩んでいるRailsエンジニアにはかなり心強い内容です。
。.。.
というわけで、今日は5本、駆け足でご紹介しました。
1本目は、人間がやるべきレビューとAIがやるべきチェックをきっちり分けて、自動レビューをハーネスとして設計する話。
2本目は、「コネクタブルアーキテクチャ」でクリーンアーキテクチャ迷子を救う、直感的なコード構造の提案。
3本目は、Microsoft Learnを参照するAgent Skillsを活用して、AIエージェントにいい資料の読み方を教える話。
4本目は、「まずキャッシュ」じゃなくて、リスクも含めたキャッシュ戦略の立て方。
そして5本目は、RailsのCIを測って、絞って、バルク化して、半分以下にまで短縮した改善の手順。
気になる記事があれば、タイトルで検索してみてください。詳しい内容やキーワードは、この番組のショーノートにもまとめておきます。
「zenncast」では、番組の感想や「こんなテーマ取り上げてほしい」なんてリクエストもお待ちしています。仕事前の支度をしながらでも、通勤中でも、また耳を貸してもらえるとうれしいです。
それでは今日はこのへんで。お相手はマイクでした。
また次回、お会いしましょう。いってらっしゃい！