おはようございます！「zenncast」、MCのマイクです。10月8日、木曜日、朝7時。今日もZennでトレンドになっている記事を、皆さんと一緒にチェックしていきます。
今日は、PostgreSQLの処理の見直しから、AIレビュー、GitHub Actionsのキャッシュ管理、エージェントへの引き継ぎ、そしてXcodeのビルド高速化まで、5本の記事をご紹介します。開発のちょっとした困りごとを解くヒント、見つけていきましょう！
....
まず1本目は、PostgreSQLで大量のOR条件を並べたときに、SQLを実行する前の処理が重くなる、というお話です。
今回のポイントは、実行そのものではなく、データをどう読み出すかを決める「planning」です。記事の実測では、条件の数に比例してメモリ使用量が増え、処理時間は条件数の二乗ほどに増えていました。条件が増えると、実行前の準備だけで大きな負荷になってしまうんですね。
ログを見てbindの時間が長い場合も、このplanningを疑ってみるとよいそうです。値をbind変数で渡すようにしても、ORで並べている条件の数が変わらなければ、負荷は減りません。
また、work_memを変更しても、今回の負荷は抑えられないとのこと。work_memは実行時のソートなどに使う設定で、planningが使うメモリは対象外なんです。「メモリの設定を増やせば解決するかな？」と思っても、処理の段階が違うわけですね。
対策は、倉庫ごとに商品IDをまとめて、INや、配列を渡すANYを使い、条件数を減らすことです。商品1万6,000個を使った実測では、ORで56秒かかっていたplanningが、3〜4ミリ秒まで短縮しました。これは大きな差ですね！
さらにANYなら、商品数が変わってもSQLの形を保てます。配列を1つのbind変数として渡せるので、変数の個数上限も避けやすくなります。SQLが遅いときは、実行だけでなく、その手前の準備にも目を向けたいですね。
....
続いて2本目は、チームの暗黙の作法を文書化して、AIレビューで共有する取り組みです。
筆者のチームでは、バックエンドの作法が口伝に頼っていました。そのため、実装する人が増えるほど、レビュー担当者の負担も増えていたそうです。「このチームではこう書きます」という知識が、レビューの場で初めて伝わる状況だったんですね。
そこで筆者は、過去のレビューコメント1,105件をもとに、40のルールを整理しました。暗黙になっていた作法を文書にして、AIレビューを通じて共有する仕組みを作ったんです。
導入後の結果を見ると、変更提案、つまりPRあたりのコメント数は1.32件で、変わりませんでした。一方で、指摘なしで承認されたPRの割合は、64.5パーセントから71.2パーセントに増えています。
コメント数だけを見ると変化がなくても、指摘なしで進められる割合には変化があった、ということですね。筆者は、実装する前にルールを知れることに価値を感じているそうです。
そして次の課題として挙げているのが、開発中のAIチェックを改善することと、PRを小さくすること。レビューで指摘するだけでなく、書いている段階で作法を確認できるようにする。チームの知識を、必要なタイミングで使える形にする取り組みです。
....
3本目は、GitHub Actionsのキャッシュを、必要なものを守りながら自動で掃除するお話です。
GitHub Actionsは、キャッシュが容量上限を超えると、最終アクセスが古いものから削除します。そのままにしていると、残しておきたいキャッシュまで削除される可能性があるんですね。
そこで記事では、まず容量の内訳を調べて、不要になった2種類のキャッシュを自動で削除しています。
1つ目は、実行ごとに保存されるビルドキャッシュです。同じブランチの最新1件を残して、古いものを削除します。ただし、再実行のときに全件を消してしまわないよう、今回のキャッシュが存在する場合だけ掃除する、という条件を付けています。
2つ目は、クローズ済みのプルリクエストや、削除済みのブランチにひもづくキャッシュです。プルリクエストのクローズやブランチの削除をきっかけに掃除しますが、CIがまだ動いている場合は見送ります。実行中に必要なキャッシュまで消さないための配慮ですね。
削除には、actionsのwrite権限が必要です。エラーの扱いも大切で、対象がすでに削除されていた場合だけは無視し、権限不足などは失敗として検知します。また、イベントに合わせた削除で取り残されたものには、定期実行による掃除も必要です。
そして、容量上限を上げるなら、組織側の設定も確認します。自動削除だけでは足りない場合もあるので、実際に使っているキャッシュ量を測り、余裕のある上限を設定することが大切だそうです。掃除と容量の確保、両方で考えるわけですね。
....
4本目は、AIエージェントの記憶をどう残し、別のツールへ引き継ぐか、という記事です。
記事では、記憶を役割ごとに分けています。作業手順はSkills、規約や構成はAGENTS.md、そして作業の進み具合は引き継ぎノートに保存します。Claude CodeとIBM Bobで検証したところ、Markdownだけでツール間の引き継ぎができたそうです。
ただ、ノートに何を書くかが重要です。「次にやること」だけを書いた場合、ツールによって作業を止める地点が変わってしまいました。そこで、「次のセッションで完了させる範囲」と「その後の予定」を分けて書きます。直近でどこまで終えるのか、その先に何があるのかを、別々に伝えるんですね。
方針を残すときには、それが「ユーザーの指示」なのか、「エージェント自身の判断」なのかも区別します。さらに、いつまで有効な方針なのかも記録します。ノートを更新したときに、この区別が消えていないかを確認し、次の作業範囲は人間がチェックする、という運用です。
特に定期的に見直したいのは、方針や制約、これまでの経緯など、コードから確認できない情報です。こうした情報は古くなっても、エージェントが気づきにくいからなんですね。
高度な記憶管理の仕組みを用意する前に、まず何を書き、いつ更新するかを決める。引き継ぎをうまく進めるには、保存の仕組みだけでなく、情報の整理の仕方が大事だというお話でした。
....
最後、5本目は、Xcode 26のCompilation Cacheを、Git Worktreeでも活用する方法です。
Compilation Cacheは、コンパイル結果を再利用する機能です。ただし、Git Worktreeでは作業場所ごとに絶対パスが変わります。そのため、この機能を有効にするだけでは、キャッシュがほとんど使われないそうです。
対策は、異なる作業場所のパスを、共通の仮想パスにそろえること。設定としては、COMPILATION_CACHE_ENABLE_CACHINGに加えて、SwiftとClangのENABLE_PREFIX_MAPPING、ENABLE_PROJECT_PREFIX_MAPPINGをYESにします。
SwiftPMを使う場合は、さらにSWIFT_OTHER_PREFIX_MAPPINGSとCLANG_OTHER_PREFIX_MAPPINGSで、worktreeのルートも共通の仮想パスに置き換えます。作業場所の違いを、キャッシュの再利用を妨げない形にそろえるわけですね。
記事の検証では、キャッシュの利用率が58パーセントになり、ビルド時間は250秒から209秒に短縮しました。41秒の短縮ですから、繰り返しビルドする場面ではうれしい改善ですね。
ただし、マクロに依存するターゲットには、設定してもキャッシュを再利用できない問題が残っています。筆者の修正ではすべて再利用できたそうですが、その修正は2026年10月7日時点では未マージです。設定による改善と、まだ残っている問題を分けて押さえておきたいですね。
....
さて、今日の「zenncast」は、5本の記事をお届けしました。
PostgreSQLでは、大量のOR条件を見直してplanningの負荷を減らす工夫。AIレビューでは、暗黙の作法を40のルールとして共有する取り組み。GitHub Actionsでは、不要なキャッシュを安全に掃除する方法。そして、AIエージェントの引き継ぎ情報の整理と、Xcode 26で作業場所のパスをそろえてキャッシュを活用するお話でした。
詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてください。
番組の感想もお待ちしています。「この工夫を試してみたい」「うちのチームではこうしています」など、皆さんの声を聞かせてもらえるとうれしいです。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価で応援してもらえるとうれしいです！
それでは、次回も皆さんにお会いできるのを楽しみにしています。お相手はマイクでした。今日も、よい1日を！