おはようございます。マイクです。
時刻は朝7時を回りました。今日は2026年6月6日、土曜日ですね。
ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきたいと思います。
今日はお便りコーナーはお休みで、そのぶんガッツリ技術記事を追いかけていきますよ。
さて、本日ご紹介する記事は全部で5本です。AIコードレビュー、フロントエンドのライブラリ理解、そしてAWSやSnowflakeの新サービスまで、幅広く押さえていきますので、通勤・通学のお供に最後までお付き合いください。
では、1本目。
タイトルは「PR 前後で AI レビューを2段構えにしたら、レビュー待ちが約70%減った話」。
これ、開発チームで「PRが溜まってレビュー待ち地獄なんですけど…」っていう方にはめちゃくちゃ刺さる内容だと思います。
estieという会社さんでの事例なんですが、AI Agentの活用でPRの本数が増えた結果、今度は人間レビューがボトルネックになってしまったと。そこで導入したのが、PRの「前」と「後ろ」でAIレビューを分担させる二段構えの運用です。
PRを出す“前”の段階では、開発者がローカル環境でClaude Codeに対して、影響範囲や仕様との整合を見てもらう。/graph-reviewとか/domain-reviewみたいなコマンドで、設計レベルやドメインレベルのチェックをしてもらうんですね。あわせてCodeRabbitのCLIでコード品質も検査しておく。
そしてPRを出した“後”は、GitHub上でCodeRabbitが自動レビューしてくれる、という分担です。前段は広く「設計・仕様・影響範囲」を、後段はdiffにフォーカスした具体的な修正提案、という役割分担がポイントになっています。
さらにおもしろいのは、技術ガイドラインとかレビュー規約を、両方のAIから参照できるようにして、チームとしての「レビューの型」をAIにも覚えさせているところ。これによって、AIのコメントがチーム文化にちゃんと沿ったものになっていきます。
結果どうなったかというと、レビュー待ち時間は14.1時間から4.3時間へ、およそ70%減。デプロイ頻度は月144PRから400PRへと大幅アップ。数字がかなりインパクトありますよね。
とはいえ、AIに全部任せるわけではなくて、「Approveを押す最終判断」は人間のまま。AIの指摘はあくまで判断材料にして、人間は設計やドメインの理解が必要なところに集中する方針を維持していると。
AIレビューを入れたいけど、「どこまで任せていいの？」と悩んでいるチームには、かなり良い設計図になる事例だと思いました。レビュー待ちがつらい方は、ぜひ詳細を読んでみてください。
。。。。
続いて2本目。
タイトルは「TanStack Query を完全にゼロから実装して理解する」。
Reactで開発している方にはおなじみのデータフェッチライブラリ、TanStack Query。その中身を「ライブラリのコードを読む」ではなく、「自分でゼロから作りながら理解する」というスタイルの記事です。
最初は、useStateとuseEffectだけを使った、素朴なuseQuery的なフックからスタートします。ここでは、コンポーネントごとに状態が閉じてしまって、queryKeyでの共有ができないという限界がすぐに見えてきます。
そこで登場するのが、QueryクラスとQueryCache、そしてQueryClient。Reactの外側にストアを作って、そこにクエリの状態と取得方法をまとめて持たせる。「queryKeyをハッシュ化して共有する」「前方一致で検索してinvalidateする」といった、本家っぽい構造が徐々に組み上がっていきます。
Reactとの橋渡し役にはQueryObserverとuseSyncExternalStoreを使っていて、「外部ストア＋購読」という設計パターンを、実際に手を動かしながら学べるのが嬉しいところ。
さらに、staleTimeを使ったstale-while-revalidate、つまり「表示はすぐに出して、裏側で静かに取り直す」挙動や、いま飛んでいるPromiseを共有してリクエストの重複を防ぐテクニックなんかも、ひとつひとつ自前実装していきます。
動的にqueryKeyが変わるときの購読の付け替えや、通知漏れといった罠も丁寧に解説されていて、「なぜ本家はこんな設計をしているのか？」という意図がよくわかる構成です。
最後には、ガーベジコレクションやリトライ、ウィンドウフォーカス時のrefetchなど、本家との差分も整理されていて、「公式実装を読むときの地図」として機能する、かなり実践的な記事でした。TanStack Queryをなんとなくで使っている方、内部の仕組みを押さえておくと、バグ調査やパフォーマンスチューニングがぐっとやりやすくなりそうです。
。。。。
さあ、3本目。
タイトルは「Amazon S3 Filesがでました！」。
AWS界隈の新サービス紹介ですね。S3 Filesは、Amazon S3をNFSv4.1としてマウントして、LambdaやEC2から普通のファイルシステムみたいに扱える、という新しいファイルシステムです。
特徴としては、作成・読み取り・更新・削除、いわゆるCRUDの操作が全部サポートされていること。そして内部的にはEFSがキャッシュ兼NFSのレイヤーとして動いている、という構成になっています。
これによって、アプリケーションから見るとNFSとして約1ミリ秒程度の低レイテンシでアクセスできて、その裏でEFSがだいたい60秒おきにS3へ同期する、という二段構え。1MB以上の大きめの読み込みは、直接S3から取ってくるような仕組みになっているそうです。
セキュリティ面ではTLS1.3に加えて、SSE-S3やKMSによる暗号化にも対応。IAMベースできめ細かくアクセス制御ができて、CloudWatchやCloudTrailでのログ・監視にも統合されます。
これまでのMountpoint for Amazon S3はFUSEベースで、キャッシュがなく、更新系の操作にもかなり制限があったんですが、S3 FilesではEFSキャッシュのおかげで、読み書きどちらもだいぶ柔軟になりました。
記事では実際に、S3バケットを作って、S3 Filesのファイルシステムを作成し、VPCを指定して、EC2とIAMロールを設定して、マウントコマンドで繋ぐところまで丁寧に手順が紹介されています。マウントした先でファイルの作成や追記を行って、60秒くらい経つとS3バケット側にちゃんと同期されている、という動作確認もされていますね。
一点注意なのは、純粋なEFS利用と比べると、背後にS3との同期があるぶん、読み取りレイテンシが増えるケースがあること。なので、「S3にデータを置きたいけど、ファイルシステムとして扱いたい」「更新もちゃんとやりたい」というシナリオでハマるサービス、といった印象でした。
。。。。
続いて4本目。
タイトルは「AWS Innovation Sandbox (ISB) を構築してみた！」。
PoC用の共用AWSアカウント運用で、「これ誰のリソース？」「もう使ってないっぽいけど消していいの？」っていう、あのモヤモヤ問題にガチで取り組んだ記事です。
AWS Innovation Sandbox、略してISBは、AWS公式のソリューションで、PoC用の「使い捨てサンドボックスアカウント」を、安全に貸し出す仕組みになっています。IAM Identity Centerと連携したWebポータルからサンドボックスを申請すると、あらかじめ決めたテンプレートに従って、予算や利用期間、しきい値超過時にどうするか（警告だけにするか、Freezeするか、完全にWipeするか）を厳格にコントロールできます。
Organizations配下には、管理アカウントとHubアカウント、そしてサンドボックス用のアカウント群が用意されます。4つのCloudFormationスタックで、OUやSCPの設定、Identity Centerのグループ、DynamoDBテーブル、さらにポータルやStep Functionsといった周辺の仕組みまで一気に構築してしまうのがポイントです。
サンドボックスアカウントは、「Entry」でAWS Nukeを実行して中身を空っぽにしてから、「Available」状態になり、貸し出されると「Active」、返却タイミングで「CleanUp」を経て、また「Available」に戻る、というライフサイクル管理になっています。全部OrganizationsのOU移動で制御しているのがなかなかおもしろい。
ただし、現実世界はそう甘くなくて、Organizationsが強制的に作るリソースが原因で、AWS Nukeが失敗してQuarantine行き…というトラブルも発生します。
記事では、AppConfig上のnuke-config.yamlに、Inspector2やAccess Analyzer、Control TowerやAFT関連のリソース、Inspector管理のEventBridgeルールなどを除外設定して、無限リトライやタイムアウトを防ぐ工夫が紹介されています。
最終的には、「誰のリソースかわからない」「消し忘れで課金が怖い」といった、PoCあるあるな悩みをかなり解消して、エンジニアが心理的安全性高くサンドボックスを使い捨てできる環境を実現した、という締め。
PoCや検証環境が増えてきて、「そろそろちゃんとガバナンス効かせないとな…」と感じている組織には、実践的なヒントが詰まった記事になっています。
。。。。
そしてラスト、5本目。
タイトルは「Snowflake App Runtime 入門 - プロンプトひとつでデータの隣に本格Webアプリをデプロイする！」。
データ基盤としてのSnowflakeの上で、Next.jsみたいなフルスタックWebアプリを直接動かしてしまおう、という新しいプラットフォーム、Snowflake App Runtimeの入門記事です。
Snowflake App Runtimeは、SPCSのAPPLICATION SERVICEとして動く仕組みで、インフラの構築やDocker、認証まわりの実装を自分でやらなくても、SnowflakeのSSOやガバナンスをそのまま継承したアプリをデプロイできるのが大きな特徴です。
StreamlitやNative App Frameworkとの住み分けとしては、より凝ったUIを持つ社内向けWebアプリを想定している形ですね。ダッシュボードや業務フローアプリみたいなものがターゲットになります。
記事の中では、AIコーディングエージェント「CoCo」のsnowflake-appsスキルを使って、Next.jsのテンプレートやSnowflake接続のヘルパー、設定用のsnowflake.ymlやapp.ymlを自動生成し、さらにsnow app CLIと連携して、「プロンプトから雛形を作って→ローカルでプレビューして→そのままデプロイ」という一連の流れを体験していきます。
実例としては、売上ダッシュボードを題材に、CLIのバージョンや、使うウェアハウス・デプロイ先の指定、ローカル開発時にどのロールを使うか、といった実務上つまづきやすいポイントが丁寧に説明されています。
デプロイ後は、SHOW APPLICATION SERVICESコマンドで、ちゃんとSnowflake上にアプリケーションサービスとして存在していることを確認できるなど、「本当にデータの“隣”でアプリが動いている」感じが伝わってきます。
データを外に出さずに、Snowflakeのセキュリティ境界内でアプリを提供できるので、「内製の業務アプリをもっと増やしたいけど、インフラと認可設計がネック」という組織にはかなり相性が良さそうです。ガバナンスを効かせたまま、データドリブンな社内アプリをどんどん生やしていける未来が見えてきますね。
。。。。
というわけで、きょうのzenncastでは、
AI二段構えレビューでPR待ちを大幅削減した話、
TanStack Queryをゼロから実装して理解する記事、
新サービスAmazon S3 Filesの検証レポート、
AWS Innovation SandboxでPoC用アカウントを安全に運用する話、
そしてSnowflake App Runtimeでデータの隣にWebアプリをデプロイする入門記事、
この5本をご紹介しました。
気になる記事があれば、詳しい内容は番組のショーノートにまとめてありますので、あとでゆっくりチェックしてみてください。
番組の感想や、「こんなテーマを取り上げてほしい！」といったリクエストも、いつでもお待ちしています。あなたの現場での悩みや気づきが、次回のzenncastのネタになるかもしれません。
それでは、そろそろお別れの時間です。
お相手はマイクでした。また次回のzenncastでお会いしましょう。
今日も良い一日をお過ごしください。