おはようございます！ zenncast、MCのマイクです。11月9日、月曜日、朝7時になりました。新しい1週間のスタート、皆さんいかがお過ごしですか？ 今朝もZennで今日トレンドの記事から、気になる話題をお届けします。
今日ご紹介するのは5本です。AIを活用した脆弱性チェックから、Markdownの品質管理、統計の検定方法、AIと挑んだ性能改善競技、そしてAWSの高額請求への対応まで。実務のヒントが詰まっていますよ。それでは、始めましょう！
....
まず1本目は、サーバーの脆弱性チェックを自動化する仕組みのお話です。
GitHub Actionsを使って、毎朝サーバーのOSやソフトウェアのバージョンを収集。それをZero WireのRSSにある脆弱性情報と照合して、対応が必要なものがあればGitHub Issueで通知します。
この仕組みのポイントは、Claudeとコードで役割をはっきり分けていることです。脆弱性の影響の評価はClaudeが担当し、バージョンの比較はコードが担当します。修正済みかどうかは公式データを使って確定させる一方、Claudeには、そのソフトウェアの利用条件や、外部から接続できる状況などの評価を任せるんですね。こうすることで、判断が「要確認」のまま止まってしまうケースを減らしています。
バージョンの扱いにも注意が必要です。Ubuntuについては、Ubuntu独自の修正版と比較します。また、Node.jsが内蔵している部品は、OS側を更新しても修正されないため、別に確認します。この仕組みでは、Dependabotでは拾えないNode.js本体の脆弱性も検出できるそうです。
安全面の境界も明確です。Claudeにはサーバーの操作を許可せず、外部ページに書かれた指示にも従わせません。そして、コードが未修正と判定した場合は、Claudeがどんな結論を出しても通知します。サーバー情報を守るため、リポジトリは非公開にしています。
AIに任せるところと、確実なルールで判断するところを切り分ける。セキュリティの自動化を考えるうえで、参考になる設計ですね。
....
続いて2本目は、Markdownの文書を検査するCLIツール、regomarkのお話です。
対象になるのは、設計上の決定を記録する文書、ADRなどのMarkdown。これを、regoで書いたルールに沿って検査します。
AIに文章で指示していても、いつの間にか書式がずれたり、求めていた内容から外れたりすること、ありますよね。そこでregomarkでは、「構造は機械で、意味はLLMで検査する」という役割分担を採っています。
例えば、必須の節やStatusがあるか、文書間の参照が適切か、リンク切れがないか。こうした項目は機械的に調べて、違反があればCIの自動チェックを失敗させます。
一方で、「このADRは、設計上の決定を残す文書ではなく、仕様書や手順書になっていないか」といった、意味を読み取る必要がある判断はLLMが担当します。ただし、LLMの結果のぶれで作業が止まらないように、こちらはPR上の注意として表示。根拠となる行と、その判断の理由も示します。
さらに、機械的な検査ルールとLLMへの質問を、同じregoで管理できます。ツール本体を更新しなくてもルールを追加できて、ADR以外のMarkdownにも使えるとのことです。
必ず守ってほしい形式は厳密に、解釈が必要な部分は根拠付きの助言にする。この使い分けなら、文書を書く人も改善に取り組みやすそうですね。
....
3本目は、統計の検定方法について、気をつけたいお話です。
正規性検定で問題が見つからなかったとしても、それは「このデータが正規分布に従っている」と証明できたわけではありません。まず、ここが大事なポイントです。
筆者は、正規性検定の結果を見てから、t検定などの方法を選ぶ進め方に注意を促しています。そうすると、実際には差がないのに「差がある」と判断してしまう確率が、想定していた5パーセントなどの水準から外れる場合がある、というんですね。
では、どうすればよいのか。記事で強調されているのは、データを見る前に検定方法を決めることです。
事前に分かっているデータの性質と、何を調べたいのかという目的。その両方に基づいて方法を選び、必要なデータ数についても、あらかじめ計画すべきだと述べています。
結果を見てから方法を選びたくなる気持ちはありますが、その選び方自体が判断に影響する場合がある。分析は計算を始める前の設計から大切なんだと、改めて考えさせられる記事です。
....
続いて4本目は、性能改善競技、ISUCON2026にClaude Codeで挑んだ振り返りです。
筆者は、自作した運転・監視の仕組みを使って、Claude Codeをほぼ自律的に稼働させて参加しました。結果は579チーム中38位。スコアは初回のおよそ98倍に達したそうです。これは大きな伸びですね！
ただ、振り返りでは、安全重視の手順が持つ難しさも挙げられています。
例えば、失敗した変更を元に戻すといった手順は、安定稼働には役立ちました。その一方で、大幅な設計変更を進めるうえでは、妨げにもなったといいます。堅実に動かし続けることと、大きく構造を変えて性能を伸ばすこと。その間に難しさがあったわけですね。
同じAIを使った優勝者との得点差は、およそ3倍。この差を踏まえて、筆者は、事前に用意する仕組みと手順書が成果を左右すると考えています。
練習も、単に停止を防ぐためのものだけでは足りません。複数地域のサーバーを使いながら、どの設計方針を選ぶかを判断する練習も必要だと述べています。
同じAIでも、どんな環境と手順を用意するかで成果が変わる。AIに仕事を任せる側の設計力も問われる、興味深い振り返りですね。
....
最後の5本目は、AWSで不自然な高額請求を見つけたときの対応です。
今回、筆者の画面に表示された請求額は、なんと約4億3千万円。驚く金額ですが、原因はトークン使用量が100万倍で計上されていたことでした。翌日には訂正され、該当する料金は約390円になったそうです。
では、こうした請求に気づいたら、どう動くのか。記事では、まず英語チャットでAWSサポートに連絡することを挙げています。筆者の経験では、Webからの問い合わせより初動が早かったとのこと。また、請求についての相談は、サポートプランに関係なく無料です。
並行して確認したいのが、AWS Healthの障害情報。そしてBillsやCost Explorerで、サービスごとの使用量と、その単位を調べます。表示された数字だけを見るのではなく、実際に処理したデータ量と見合うのか、計算して確かめることが大切です。
問い合わせには、アカウントID、リージョン、実行日時、ジョブID、データ量、請求内訳を添えます。そのうえで、使用量の調査と、料金・税の訂正、消費されたクレジットの返還、さらに解決までの自動引き落としの停止を依頼します。
チャットの入り口は、「Account and billing」から「Billing」、続いて「Other Billing Questions」と進み、英語を選択する流れです。
こういうときは、びっくりして頭が真っ白になりそうですよね。だからこそ、問い合わせ先と、そろえる情報を知っておくことが助けになります。今回の訂正に至る経緯も含めて、覚えておきたい事例です。
....
さて、今朝のzenncast、5本の記事をお届けしました。
Claudeとコードで役割を分ける脆弱性チェック。構造と意味を分担して検査するregomark。データを見る前に方法を決めたい統計の検定。Claude Codeと挑んだISUCON2026。そして、AWSの不自然な高額請求への対応でした。
今日は、AIを使う場面でも、データを扱う場面でも、判断の仕組みや事前の準備が大切だと感じる話題がそろいましたね。
詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてください。番組への感想もお待ちしています。「この話が役立った」「こんなテーマも聞いてみたい」など、気軽にお寄せくださいね。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回また皆さんにお会いできるのを楽しみにしています。今週も、無理なくいいスタートを切っていきましょう。お相手はマイクでした。いってらっしゃい！