おはようございます！ zenncast、MCのマイクです。今日は10月27日、火曜日。朝7時になりました。これから一日を始める皆さんに、Zennで今日トレンドの記事をお届けします。
今日は、サーバーのメモリ改善から、コーディングAIの使い分け、情報漏えい対策、AIの文章を伝わりやすくする工夫、そしてNode.jsの脆弱性修正まで、5本の記事をご紹介します！
....
まず1本目は、APIサーバーのメモリ使用量と、source mapの関係についての記事です。
source mapは、実行しているコードと元のTypeScriptの位置を対応づけるための情報です。エラーが起きたとき、元のコードのどこに問題があったのかを調べる助けになります。
ところが、巨大な単一バンドルを使う筆者のAPIサーバーでは、エラーの呼び出し履歴を読むと、そのsource mapが展開され、メモリ上に保持されていました。その結果、ヒープが約1,470メガバイトも増えていたそうなんです。調査を助ける仕組みが、かなりのメモリを使っていたわけですね。
そこで筆者は、本番環境ではsource mapを読み込まない構成に変更しました。ただし、障害調査の手がかりまでなくすわけではありません。実際に動かすコードと同じビルドで生成したmapを、別途保管する方針にしています。
ほかの改善も合わせた結果、ローカルでのヒープ使用量は2,270メガバイトから683メガバイトに減りました。一方で、元のコードの位置は、障害調査の際に改めて調べる必要があります。
普段のメモリ消費を抑えることと、調査のしやすさ。そのバランスを、mapの保管方法も含めて見直した事例です。
....
続いて2本目は、コーディングAIを、仕事に合わせて使い分けるお話です。
コーディングAIには、それぞれ得意なことと不得意なことがあります。筆者は、Claude Codeだけを使っていると利用上限にもすぐ達してしまうため、5種類を併用しているそうです。
とはいえ、AIごとに画面を行ったり来たりするのは、ちょっと大変ですよね。そこで窓口をClaude Codeにまとめ、そこからほかのAIへ仕事を振り分ける方法を取っています。画面を切り替え続けなくても、作業に合うAIを使えるようにする工夫です。
具体的には、設計やデザインはClaude Code、画面操作や思考はCodex、文章作成はAntigravityに任せます。個人のコード作成には、安くて速いOpenCodeを使い、会社のコードにはCursorなどを使う、という分担です。
単純に性能だけで選ぶのではなく、品質、費用、そして情報の扱いまで考えて、使う道具を変えているんですね。
AIを1つに絞るのではなく、窓口は1つにして、その先で適材適所に振り分ける。複数のAIを使いたいけれど操作が煩雑になるのは避けたい、という方にも気になる運用です。
....
3本目は、国内の情報漏えい事案から、開発や運用で見直すべき点を考える記事です。
筆者は、2026年に公表された国内の情報漏えい71事案を分類しました。そのうち、経路が判明した48件を見ると、公開システムの脆弱性によるものが20件、認可や仕様の欠陥によるものが11件あったそうです。
特に注目しているのが、本来は見られないはずの他人の情報を取得できてしまう、設計上の穴です。こうしたアクセスは、正常な通信と見分けにくく、WAFなどの防御だけでは防ぎにくいと説明しています。
そこで重要になるのが、開発者による権限確認です。その利用者が、その情報を取得してよいのかを確かめること。そして、大量の照会に制限を設けることも必要だとしています。
さらに、委託先から被害が広がるケースや、発見までに時間がかかるケース、不要なデータを保管し続けていたケースも目立ったそうです。
高度な攻撃への備えだけではなく、社内ツールをどこまで公開しているか、不要なデータを削除できているか、バックアップから本当に復元できるか。こうした基本的な部分も見直すべきだ、という内容です。
守る仕組みを追加するだけでなく、そもそも誰に何を見せる設計なのか、何を残しておく必要があるのか。そこまで立ち返って確認したいですね。
....
続いて4本目は、AIが書く文章を、もっと伝わるものにするためのスキル、「explain-before-shorten」です。
これは、AIが作る説明不足の文章や、不自然に短い文章を直すための指示をまとめたものです。対象は、スライドや技術文書、メールなど。大切にしているのは、「まず伝わる説明を作ってから短くする」という順番です。
最初に、何を伝えたいのかを決めます。次に、隣にいる相手へ話しかけるつもりで、具体的に説明します。そのうえで、重複している部分や不要な前置きを削っていく、という流れです。
短くする際にも、異なる話題を無理に一文へ詰め込まないことがポイントです。また、専門用語や重要な条件は残します。文字数を減らすために、意味を理解するのに必要な情報まで落としてしまっては困りますからね。
そして最後には、短くした文章だけを読んで、本当に意味が伝わるかまで確認します。
短い文章を目指す前に、まず説明を成立させる。読み手に伝えるための順番として、AIへの指示だけでなく、私たち自身の文章づくりにも取り入れたい考え方ですね。
....
最後、5本目は、Node.jsのBrotli圧縮データの展開処理で修正された、脆弱性についての記事です。
今回修正されたのは、メモリ破壊や、外部からのコード実行につながる脆弱性です。原因として挙げられているのが、「入力不足」と「不正なデータ」を区別していなかったことです。
どちらも処理をそのまま進められない状態ですが、必要な対応は違います。入力が足りないなら続きを待つ場面がありますが、データそのものが不正なら、待ち続けるのではなく異常として扱う必要があるわけですね。
筆者は修正コードを読み解き、以前の処理では、不正なデータであっても入力を待ち続けたり、エラーを無視したりしていたと説明しています。
修正では、こうした異常の種類を区別して、確実に処理を停止する仕組みに変えたそうです。
単にエラーが起きたかどうかだけでなく、それがどういう状態なのかを正しく分けて扱う。その違いが、安全な処理につながることを考えさせられる記事でした。
....
さて、今日のzenncastは、5本の記事をご紹介しました。
source mapの読み込みを見直したサーバーのメモリ改善、Claude Codeを窓口にしたAIの使い分け、情報漏えい事案から見えた設計と運用の課題、説明してから短くする文章づくり、そしてNode.jsのBrotli展開処理の脆弱性修正でした。
詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてくださいね。番組の感想もお待ちしています。「この話が気になった」「こんな工夫をしています」といった皆さんの声を、ぜひ聞かせてください。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回も皆さんにお会いできるのを楽しみにしています。今日もすてきな一日を。お相手はマイクでした！