どうもー、おはようございます。マイクです。「zenncast」水曜日の朝のお時間です。
今日は2025年12月3日、水曜日。現在の時刻は朝7時を少し回ったところです。みなさん、今日も一日がんばっていきましょう。
この番組では、Zennに上がっているトレンドの記事をピックアップして、エンジニアのみなさんの朝の情報収集をちょっとだけ楽しく、ラクにしていこうというコンセプトでお送りしていきます。

さあ、今日はZennで話題になっている記事を、全部で5本ご紹介していきます。
クラウドインフラの話から、CIのコスト削減、CLIの爆速入門、AIの文章品質アップ術、そしてRAGプロダクトの周辺Tipsまで、けっこう盛りだくさんのラインナップです。通勤や通学のおともに、耳だけ貸してもらえればOKです。

まず1本目の記事。タイトルは「やったらあかんで！ AWSアンチパターン」。
名前からしてちょっとドキッとしますけど、内容はかなり実務的で、「それ、いま自分たちがやってるやつでは……？」と冷や汗をかく人も多そうな記事です。
テーマは、AWS初心者チームや、「なんとなく」でインフラを組んできたチームがハマりがちなアンチパターン集。代表的なのが、「全部の環境を1アカウントに詰め込む」「アカウントごとにIAMユーザーを乱立」「CI/CDをIAMユーザーのアクセスキーで回しちゃう」といった認証・権限まわりのやらかしパターン。
さらに、命名規則がメンバーごとにバラバラ、VPCとサブネットの設計が甘くて後から詰む、RDSやECS、S3をなんとなくパブリックにしてしまう、セキュリティグループを「とりあえず全部許可」にしてしまう、といった「事故の元」がズラッと並びます。
運用面でも、ECS Execを無効のまま運用したり、タスク定義に環境変数や機密情報をベタ書きしたり、ECRのlatestタグを本番でそのまま使ったり、Lambdaをコンソールで直接編集したりと、「最初はラクだけど、あとで泣くパターン」がたくさん取り上げられています。
著者は、これら一つひとつに対して是正策も提示していて、例えばアカウントは役割で分離してIAM Identity Centerを使う、一時的なロールで認証する、プライベートサブネットとVPC Endpointをちゃんと使う、役割ベースでセキュリティグループを設計する、ログは保持期間とS3エクスポートを決めておく、S3はバージョニングとライフサイクルを設定する、などなど。
締めのメッセージが「インフラの負債は複利で膨らむので、気づいたときに必ず返済しましょう」という言葉で、耳が痛いけど、いま見直せば未来の自分をだいぶ救える内容になっています。AWSに触り始めた人も、なんとなく運用を続けている人も、一度チームで読み合わせしてみるとよさそうです。 。。。

2本目の記事にいきましょう。タイトルは「YAMLを数行変えただけでGithub Actionsの料金を70%削減できて実行時間まで減った話」。
GitHub Actionsの料金、最近「気づいたらめっちゃ増えてるんだけど…」というチーム、多いと思うんですよね。この記事は、テストを削るとか、自前runnerをがっつり運用するとか、そういう重い話ではなくて、「サードパーティのrunnerサービスを導入して、YAMLのruns-onの指定を数行変えただけでだいぶよくなったよ」という実録です。
著者のチームでは、BlacksmithとWARPBUILDを比較検討して、管理画面の使いやすさや安定性、必要なだけスケールできることからBlacksmithを採用。導入作業自体は、Blacksmithに登録してGitHubアプリを入れて、そのうえで各Jobのruns-onをBlacksmithのラベルに変えるくらいで済んだそうです。
結果として、RSpecのジョブは約55分かかっていたのが23分になって、約60%の高速化。Docker buildも2分半から40秒に短縮されていて、体感としてもかなり嬉しいスピードアップ。しかも料金は約1/3、つまり70%削減ということで、「こんなに変わるのか」となる内容です。
もちろん、GitHub本体だけじゃなくBlacksmith側の障害影響も受けるというリスクはありますが、CIのチューニング沼にハマるより、プロダクト機能開発を優先したいチームにとっては、かなりコスパのいい選択肢だとまとめられています。「最近Actions代がしんどいな…」と思っている方は、一度こういう外部runnerサービスも検討してみるといいかもしれません。 。。。

続いて3本目。タイトルは「爆速CLI入門 ~最初に知りたかったTips~」。
CLIって、「ちゃんと使えるようになるとめちゃくちゃラクなんだけど、最初の壁がちょっと高い」みたいな存在ですよね。この記事は、その壁をかなり低くしてくれる入門記事になっています。
著者がまず伝えているのは、「CLIは怠惰を支える相棒だ」という考え方。サボりたいからこそ、手を動かす回数を減らすためにCLIを鍛えよう、というスタンスです。そのうえで、まず自分がどのシェルを使っているのか、$SHELLや$0を確認して把握しよう、というところからスタートします。
メインで扱われているのはzshでのキーバインド。`bindkey`で現在のショートカット一覧を出して、それをパイプで組み合わせて「これ何してるの？」と分解しながら覚えていくやり方が紹介されています。emacsモードへの切り替え方から、初心者向けの基本キーバインド、中級・上級者向けの便利なショートカットまで、かなり丁寧にまとまっています。
さらに、「調べる力」にフォーカスしていて、tldrコマンドを使って簡潔なヘルプを引く方法、`--help`や`man`ページの読み方、英語が苦手な人向けにPLaMo翻訳やghostで翻訳サーバを常駐させるテクニック、日本語manをJM Projectから入れてMANPATHを設定する方法なんかも解説されています。
manページをカラー表示にしたり、Neovimで快適に読めるようにしたりと、「どうやってCLIの世界を自分好みに、快適にしていくか」という視点がすごく充実していて、まさに「最初に知りたかったTips」がまとまっている感じです。普段マウス操作が多い人も、この記事をきっかけに少しずつCLIに寄せていくと、半年後の自分がかなり楽になっているんじゃないかなと思います。 。。。

4本目の記事です。タイトルは「AI出力の品質が悪い？『レビューと改善を3回繰り返して』だけで圧倒的に品質が上がる」。
AIに文章やコードを書かせてみたはいいものの、「なんか期待していたほどよくないな…」っていう経験、あると思います。この記事が提案しているのは、すごくシンプルだけど効果の高いテクニックで、「AIに対して、自分自身でレビュー&改善を3回繰り返すように指示しよう」というものです。
やり方は簡単で、もとのプロンプトに「生成した内容を、自分でレビューして改善を3回繰り返してください」と一文足すか、生成が終わったあとに「いまの文章をレビュー・改善して」と依頼するだけ。AIが「生成モード」と「レビューモード」を行き来しながら、段階的にクオリティを高めていってくれます。
背景として、Self-Refineという論文で、生成とレビューは別の認知プロセスで、数回の反復で精度が上がることが示されていて、2〜3回回すだけで平均20%くらい品質が向上したという話も紹介されています。
さらに、効果を高めるコツとして、「どこを見てレビューしてほしいか」を具体的に伝えることも挙げられています。例えば「論理の飛躍がないか」「冗長な部分を削ってほしい」「エッジケースもカバーしてほしい」「この受入基準を満たしているかをチェックして」など、レビュー観点を事前にリストアップしておく。
それらをドキュメント化したり、カスタム指示としてAIに覚えておいてもらうことで、チームとしてのアウトプット品質を、手軽に底上げしていけるという内容です。プロンプトを凝ったものに変える前に、まず「レビューと改善を3回繰り返して」と付け足すだけでも、けっこう世界が変わるかもしれません。 。。。

そして最後、5本目の記事。タイトルは「RAGプロダクトを支える、ベクトルDB構築以外の周辺Tips」。
いまRAG、いろんな現場で「とりあえず試してみよう」から「ちゃんとプロダクトとして使われるものを作ろう」というフェーズに入ってきていますよね。この記事は、松尾研究所での「Slackボットで研究資料を横断検索する」というプロジェクトを題材に、RAG実装の“ベクトルDB以外の”工夫にフォーカスしています。
基盤にはVertex AI Searchを使っていて、Google Drive上の資料をCloud Storage経由で取り込み、レイアウトパーサーで図や表、段落を構造的に扱うところから始まります。ここでポイントになるのが「古い資料に引きずられないようにする」という発想で、作成日時などのメタデータを使って、新しいコンテンツを優先して検索結果に出すよう、boostSpecで重みづけしているところ。
ユーザの質問側にもかなり工夫があって、社内特有の用語や曖昧な表現を、そのままLLMに投げるのではなく、「RAGに適した検索クエリ」に言い換えるプロンプトを一枚かませています。さらに、Vertex AI Search自体が持っている「クエリの言い換え」機能を活用して、冗長なクエリをシンプルにしたり、複合クエリを分割したりもしている。
もうひとつおもしろいのが、「ヒットしなかったとき」の工夫で、LLMの確率性を逆に利用して、クエリをすこし変えて自動でリトライするワークフローを組んでいる点です。これによって、「ちょっと言い回しを変えたら出てきたのに…」というケースを、ユーザが気づく前に裏側で救いにいくわけですね。
全体として、「使われるRAG」を作るには、ベクトルDB単体の精度だけでなく、クエリ変換、検索ロジック、データ鮮度管理といった細かい設計をきちんと積み上げることが大事だ、というメッセージになっています。RAGの実装を始めてみたけど、社内であまり使われていない…というチームにとって、かなりヒントの多い記事だと思います。

というわけで、今日は5本の記事をご紹介しました。ざっとおさらいすると、
AWSのやってはいけないアンチパターンとその直し方、
YAMLを数行いじるだけでGitHub Actionsの料金と実行時間をガッと減らした話、
CLIを「怠惰の相棒」にするための爆速入門Tips、
AIに「レビューと改善を3回繰り返して」と頼むだけで品質を上げるテクニック、
そして、RAGプロダクトを本当に“使われる”ものにするための周辺設計の工夫、
この5つでした。

気になる記事があった方は、詳しい内容をショーノートにまとめておきますので、あとでぜひチェックしてみてください。
番組の感想や、「こんなテーマ取り上げてほしい」「この記事も紹介してほしい」といったリクエストも、どしどしお待ちしています。あなたの一言が、明日のzenncastのネタになるかもしれません。

それでは、そろそろお別れの時間です。
今日も一日、無理せず、でもちょっとだけ前に進めるような、いい日になりますように。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。いってらっしゃい！