どうも、zenncastパーソナリティのマイクです。
時刻は朝7時を少し回ったところ、2026年2月12日、木曜日ですね。みなさんおはようございます。通勤通学中の方も、おうちでゆっくり準備中の方も、今日もZennで話題になっているトレンド記事をゆるっとチェックしていきましょう。

今日はね、セキュリティからAI VTuber、インフラの攻撃ログ分析、さらにはAIで構成図を描かせたり、Cloudflareを使い倒したサービスの話まで、全部で5本ご紹介していきます。技術の今っぽさがギュッと詰まったラインナップなので、耳だけ貸してもらえればOKです。

ではまず、今日紹介する記事は5本です。順番に読み上げていきますね。

1本目は「一番の脆弱性は"人間のコードレビュー"だった」。タイトルからしてちょっとドキッとしますよね。
この記事の筆者は、自律型AI脆弱性スキャナーの「Shannon」を自分のプロジェクトに試したんです。で、「AIならすごいゼロデイとか、難しいSQLインジェクションとか見つけてくれるのかな？」と思いきや、出てきたのは、オープンリダイレクト、消し忘れのデバッグ用エンドポイント、デフォルトパスワードがそのまま公開されている、といった“初歩的だけどガチで危ないやつ”ばかり。
しかも、それらはすでにSemgrepやチェックリストでもカバーしているし、コードレビューも通っている。それなのに穴が残っていた理由が、「まあ大丈夫でしょ」という、人間側の思い込みと集団でのスルーだった、というのが本質なんですね。
そこで筆者はAIを「脆弱性発見器」というより「思い込み破壊装置」として使おうと発想を転換します。(1) AIに「なぜ安全だと言えるのか」をレビュー時に質問させる、(2) 安全であるための前提条件をPRコメントでちゃんと言語化する、(3) その前提をAIに定期的に棚卸しさせる。こうした運用に変えた結果、「一番の脆弱性は技術そのものじゃなくて、人間の思考停止だった」と痛感した、と。
「AIは怖い」っていう話ではなくて、「人間ならではの油断をAIに突っ込んでもらおう」というポジティブな提案になっているのが面白いなと思いました。レビューする側の方はもちろん、される側も、「このコード、どんな前提で安全って言えてるんだっけ？」と一度立ち止まるきっかけになる記事です。

。。。。

2本目はガラッと雰囲気が変わって、「AI VTuber開発日記 〜AIキャラクターの作成からOBSを用いたYouTube配信まで〜」。タイトルのとおり、AI VTuber、いわゆる「AITuber」をたった15日間で動くところまで持っていった開発記録です。
筆者はまずaituber-kitというキットをベースに、ローカルのLLM、Ollamaと、音声合成のAivisSpeechを組み合わせて、「聞く・考える・しゃべる」まで全部AIで完結するVTuberを作っていきます。見た目のキャラはVRoid Studioで自作した3Dモデルを用意し、それを動かすのにVTube StudioとOpenSeeFaceでフェイストラッキングも試しています。
さらにOBS Studioで配信画面を組んで、YouTubeライブの設定、YouTube Data APIキーの取得、そこからaituber-kitと連携して、配信中のコメントをAIが拾って返事してくれるところまで構築しているのが熱いポイント。いわゆる「コメント読み上げ＆会話するAIキャラ」が一通り回るところまで行ってます。
中盤以降はよりマニアックで、OllamaのTool Streaming対応や画像入力対応に合わせてaituber-kit側も機能拡張したり、BlenderとVRM/VRMA、XR Animator＋bvh2vrmaを使ってモーションを編集、自作してみたり。「単に喋るAI」から「キャラクターとして動きも含めて魅力を出す」方向に踏み込んでいて、やり込み度が高いです。
最後に筆者が「誰のための、どんなAIキャラなのか」というコンセプト設計の大事さを改めて感じた、という振り返りも印象的でした。技術的にはどんどん何でもできるようになっているからこそ、「この子は何者で、どんな人と話したいのか？」を決めないと、ただ技術デモで終わっちゃう。AIキャラ作りに興味ある人には、技術スタックと同じくらい“キャラづくりの視点”のヒントにもなる記事です。

。。。。

3本目は「1月の攻撃ログを集計したら静的サイトとWordPressで全然違った」という記事。インフラやっている方、WordPressでサイト運営している方にはかなり刺さる内容だと思います。
筆者は、静的サイト（S3＋CloudFront）と、WordPress（Lightsail）の2つの環境について、1月分の攻撃ログを比較しています。まずリクエスト数だけ見ると、なんと静的サイトのほうが約3.2倍多い。でもだからといって、静的サイトのほうが危険かというと、そうではない。
静的サイト側にはPHPもなければ、wp-login.phpもxmlrpc.phpも存在しません。なので、そういうパスに向かってきた攻撃は、全部404で終わる。1ヶ月で8万件以上攻撃されていても、そもそも「動くものがない」から侵入リスクはほぼゼロ、というわけです。
一方WordPress側は、wp-login.phpやxmlrpc.phpが実在します。ここに対して、1月だけでwp-loginへのブルートフォース攻撃が1,260件。1回でもパスワードを当てられたら乗っ取り、という性質のものなので、こっちのほうが明らかに危険度が高い。
面白いのは時間帯と曜日の傾向も見ていて、日本時間の深夜、つまり欧米の昼間に攻撃が集中していること。特に火曜・木曜、それから月末に増えたり、お正月だからといって全く減らない、という人間味ゼロの統計も出てきます。
この記事の結論はすごくわかりやすくて、「攻撃数が多いか少ないかじゃなくて、何がそこに動いているかが危険度を決める」ということ。静的サイトは攻撃されても壊しようがない構成なので比較的安全。でもWordPressは、「WAFやiptablesなどで守りを固めて、それを運用できる前提」で選ぶべきだ、と。
筆者はこの分析に自作のAI監視サービス「CloudLogAI」を使っていて、ログ可視化の具体例としても参考になります。WordPressでブログやサービスを運用している方は、自分の環境がどう攻撃されているか、一度ちゃんと見ておくといいかもしれません。

。。。。

4本目は「draw.ioの公式MCPサーバが出てたのでClaude Codeで試してみる」。これは、いわゆる「AIに構成図を書いてもらう」ための新しいルートを試した記事です。
draw.ioって、みなさんおなじみの図作成ツールですよね。その公式のMCPサーバが登場したので、これをClaude Codeから使って、プロンプトだけで構成図を自動生成してみよう、という内容になっています。
手順としては、まずWindows環境で`.mcp.drawio.json`という設定ファイルにMCPサーバの定義を書きます。中身としては、`npx @drawio/mcp@latest`を呼び出す設定をしておいて、`claude --mcp-config .mcp.drawio.json`でClaude Codeを起動。「/mcp」と打つと、ちゃんとdraw.io MCPがつながっているか疎通確認ができる、という流れです。
そこから「AWSサービスを組み合わせたインフラ構成図を作成してください。drawio MCPを使ってください。」と指示すると、ブラウザでdraw.ioが立ち上がり、自動生成された構成図が表示される。あとはそれをベースに人間が微調整したり、PNGやSVGにエクスポートしたりして使えるわけです。
さらに面白いのが、CloudFormation、特にSAMの`template.yaml`を指定して、「このIaCテンプレートから構成図を書いて」と頼むと、API Gateway、Lambda、DynamoDBなどのリソースを自動的に図にしてくれるところ。ユーザからのリクエストフローまで含めて描画してくれるので、「文字だけだとイメージしづらいクラウド構成」が一気に可視化されます。
加えて、AWSの各サービス専用アイコンも、MCP経由で「サービスごとの公式アイコン使って」と指示すれば付けてくれるので、「いきなり資料にそのまま使えるレベル」の構成図がほぼ自動で出てくる。インフラ設計やレビュー、ドキュメント作成の効率がかなり変わりそうな、ワクワクする記事でした。

。。。。

そして5本目、最後は「Cloudflareを使い倒してmarkdownやMarpを一瞬で公開できるサービスを作った」という記事です。Markdown勢、スライド作りが多い方には最高のやつですね。
筆者が作ったサービスの名前は「tmplink」。ユーザー登録なしで、MarkdownやMarpスライドをサクッと一時共有できるというコンセプトです。エディタ部分はCodeMirror 6を使っていて、marked＋highlight.jsでライブプレビュー付き。ワンタッチのトグル操作で、同じMarkdownをそのままMarpスライド表示に切り替えられるのが気持ちいいポイントです。
公開するときは、7日間だけ有効なURLが発行されて、期限が来たら自動削除される仕様。裏側では、レンダリング済みHTMLとOGP画像をR2に保存していて、Cache APIで公開ページとOGPをエッジキャッシュ。Cron Triggersで期限切れコンテンツをバッチ削除する、という「Cloudflareで完結する構成」になっています。
OGP画像の生成もかなり凝っていて、メインはBrowser Rendering APIでスクリーンショットを撮る方式、もし失敗したらsatori＋resvg-wasmで画像を生成するフォールバックも用意。しかもこのOGP生成をwaitUntilで非同期化して、R2保存とD1への書き込みをPromise.allで並列実行することで、レスポンス時間を1〜5秒から、なんと約85msまで短縮したそうです。
フロント側ではMarpを動的importで遅延読み込みしてバンドルサイズを抑えたり、marked v15のAPI変更、HonoのJSXレスポンスがcloneできない問題、CodeMirrorのlineWrapping設定、Cloudflare特有の`caches.default`の型問題など、実装上のハマりどころも丁寧にケアされています。
Workers、D1、R2、Cache API、Browser Rendering API、Cron Triggers、Assetsだけで「wrangler一発デプロイ」ができて、無料枠中心で低コスト運用、それでいてエッジ実行で高速レスポンス、という、Cloudflareプラットフォームをフルに活かした好例になっていました。「個人ツールをサクっと世界に公開する」ための設計の参考にもなりそうです。

。。。。

というわけで本日は、
・人間の思い込みをAIであぶり出すセキュリティレビューの話、
・15日でAI VTuber環境を作り上げた開発日記、
・静的サイトとWordPressの攻撃ログ比較から見えたリスクの違い、
・draw.ioのMCPサーバを使ってAIに構成図を描かせる実験、
・Cloudflareを使い倒してMarkdown／Marpを一瞬で公開する「tmplink」の話、
この5本を駆け足でご紹介しました。

気になった記事があったら、ぜひショーノートから元の記事も読んでみてください。技術的な詳細やコード、図なんかは、やっぱり実際のページを見るのが一番伝わると思います。

このzenncastでは、番組の感想や、「こんなテーマ取り上げてほしい」「この技術、最近気になってます」みたいなお便りも募集しています。日々の開発で感じたモヤモヤや、ちょっとした発見なんかも大歓迎です。

それでは、そろそろお別れの時間です。
今日も一日、安全で楽しい開発ライフをお過ごしください。
お相手はマイクでした。また次回のzenncastでお会いしましょう。バイバーイ。