どうもー、おはようございます。マイクです。
今朝は2026年5月23日、土曜日の朝7時をちょっと回ったところです。
ここからの時間は「zenncast」、Zennで今日トレンドの記事をゆるっと、でも中身はしっかりめにお届けしていきます。

今日はお便り紹介はお休みで、そのぶん記事をがっつり紹介していきますね。
さてさて、本日ご紹介する記事は全部で…5本です。技術ネタたっぷりでお送りします。

まず最初のトピックは、「URLを誰にも教えてない」が通じない理由、というちょっとドキッとするお話です。
タイトルは「『URLを誰にも教えてない』が通じない理由 — CTログを30分監視してみた」。
HTTPS証明書を発行した瞬間、そのドメインはCTログという公開の監査ログに記録されて、世界中のbotから一斉に「新しいドメインだ！」って見つけられちゃうよ、という内容です。
著者の方が実際にCTログを30分だけ監視して、直近2日以内に登録された個人開発っぽいTLDを62ドメインほど追いかけてみたところ、8割以上はまだ中身がない・準備中みたいな状態。でも実際に動いているアプリは7件だけで、そのほとんどがAI系SaaS、CloudflareとかVercelの上で動いていたそうです。
問題は、この動いているサイトのセキュリティヘッダがほぼスカスカ。CSPもX-Frame-OptionsもPermissions-Policyもほとんど入ってなくて、「ホスティング側のデフォルト頼み」という状況になっていたと。
そして攻撃者側はCTログを“新規ドメインリスト”として活用して、`GET /`を投げて挙動や脆弱性を探しにきます。つまり「まだ誰にも教えてないし、リンクも貼ってないから大丈夫」は全然防御にならない。
なので、個人開発でもHTTPS化した時点で「もうインターネットに公開されたもの」として扱って、Cloudflare AccessとかVPNで経路を絞るか、最低限でも認証・不要エンドポイントの削除・デフォルト認証情報の変更・管理画面の保護などはやりましょう、と締めくくっています。
結論としては、「HTTPS証明書を発行した瞬間、それはもう秘密URLじゃない」という前提で設計しようね、というお話でした。個人開発で“隠しURL運用”してる人は、ちょっと背筋伸びる内容ですね。

。。，。。，。。，

続いて2本目は、PDF圧縮の世界で、あのGhostscriptをRust自前実装で超えちゃったという、技術者心くすぐる話です。
タイトルは「【PDF圧縮】約40年続く業界標準Ghostscriptを、Rust 自前実装で抜いた話」。
Tauri製のデスクトップ画像圧縮アプリ「Karui」にPDF圧縮機能を入れる中で、業界標準のGhostscript、gsですね、この/ebookプリセットを、8種類のPDFで全部上回ったというレポートになっています。
PDFが太る原因って、フォント、画像、冗長な描画コマンド、メタ情報なんですが、この記事ではそこにRustでがっつり手を入れていきます。
具体的には、日本語を含むCJKフォントを「実際に使った文字だけ」にサブセット化して大幅削減したり、古いType1フォントをCFFへ変換して、LaTeX論文系のPDFでGhostscriptを超えたり。
さらにPowerPoint発のPDFによくある「zipで固めた中にJPEGが入ってる」みたいな二重圧縮をちゃんと剥がして再エンコードしたり、写真とアイコン画像を判定して、圧縮方法を分ける工夫も入っています。
Excel由来のやたら冗長な描画コマンドを短くしたり、重複しているXMPメタデータをバサッと削除したりと、いわゆる“紙やすりで磨きまくる”系のチューニングをRustで実装。
その結果、公文書・Office・論文PDFなどで、Ghostscriptよりさらに最大26ポイントも小さくできたケースがあるそうです。
しかもGhostscriptはAGPLで商用組み込みにちょっと扱いづらい一方で、このRust実装の圧縮エンジンは、要望があればMITライセンスで切り出すかも、という話も書かれていて、プロダクトにPDF圧縮を組み込みたい人にはかなり希望のある内容になっています。

。。，。。，。。，

3本目はAIエージェントを使って、社内開発を「1時間で完結させる」仕組みを作ったお話。
タイトルは「1時間で開発を完了する。Claude Code の Skill で社内プロジェクトを仕組み化した話」。
筆者の方、日々忙しすぎて、社内プロジェクトの開発がどうしても後回しになっちゃうと。会議の前にちゃんと仕様を詰める「前うち」の時間がとれず、結局その場で決めて終わり、みたいな課題を抱えていました。
そこで発想を変えて、「定例のあと1時間で、タスクの割り振りから実装、テストまで、できるところまで終わらせてしまおう」と。そのためにClaude CodeのSkill機能とサブエージェントを駆使して、自動化された開発フローを組んでいきます。
流れとしては、まずZoomの会議要約と社内のタスク管理ツールを突き合わせて、その日やるべき優先タスクを自動で選ぶ。
それをもとに、サブエージェントたちを並列で立ち上げて、設計、実装、テストコードの作成をそれぞれ担当させます。最後にPRの作成、ステータス更新、担当者への通知まで、一括でやってくれる仕組み。
ポイントは、Skill・Rules・Subagentsをうまく役割分担させて、メンバー全員分のタスクを一気に並列処理してしまうこと。依存関係で待たされる時間を減らしつつ、「定例後の1時間で、タスクがかなり完了に近づいた状態」に持っていくのを狙っています。
こうすることで、会議前の「前うち」の時間は「手を動かす場」じゃなくて「ちゃんと考える場」にできる。今後は実装の精度やプロンプト設計、サブエージェントの役割分けを継続的に改善していく、と締められています。
AIエージェント活用を、単発のすごいデモじゃなくて「運用の仕組み」に落とし込むところが、読みどころになってますね。

。。，。。，。。，

4本目は、Googleの新しいTUI、Antigravity CLIを触ってみたレビュー記事です。
タイトルは「Googleの新しいTUI Antigravity CLIを試してみた」。
このAntigravity CLI、略してAGY CLIは、軽量なテキストUIのインターフェースで、旧Gemini CLIの進化版的な立ち位置なんですが、IDEとかエージェント司令塔の「Antigravity 2.0」と名前が似てて、そこがまずちょっと紛らわしい、と。
導入自体はcurl一発でインストールできるんですが、その前にAntigravity IDE側での認証が必要だったりして、最初のハマりポイントが紹介されています。
設定はJSONでかなり細かく制御できて、実行中はスラッシュコマンドが豊富。/configで設定を開いたり、/resume、/rewindで会話の流れをコントロール、/permissionsで権限を確認したり、/tasksや/mcpでタスク・MCP周りを触ったり、/modelで使うモデルを切り替えたりできます。
使えるモデルも、Gemini 3.5 / 3.1系だけじゃなくて、ClaudeやGPT-OSS系まで選べるのがポイント。
面白いのが、Three.jsで3D花火を作らせる比較デモです。旧Gemini CLIだと、実装は素直なんだけど、表現がちょっとのっぺりしていて、生成に4分11秒かかった。一方のAGY CLIでは、UnrealBloomPassを使ったり、ポストプロセスやUIの演出まで入れ込んだ、かなりリッチな花火アプリを2分20秒で出してきた、と。
その分、AGY CLIは実装言語がTypeScriptからGoに変わって、オープンソースじゃなくなっちゃったのは残念ポイントとして挙げられています。
著者としては、今後Skillsやサブエージェントの活用も試していきたいし、既存のGemini CLIユーザーにはAGY CLIへの移行をおすすめ、という締め方になっていました。

。。，。。，。。，

そして5本目。最後はMCPサーバーを既存サービスに組み込むときの、設計の勘所をまとめた記事です。
タイトルは「既存サービスにMCPサーバーを組み込む際の設計ポイント」。
Finatextの保険プラットフォーム「Inspire」にMCPを統合した事例をもとに、既存のGoバックエンドの中にMCPサーバーを埋め込むとき、どこを気をつけるべきかが整理されています。
MCPの中核は`tools/list`と`tools/call`で、この2つの設計、とくに「どのツールが誰に見えるのか」と「どう認可するか」が肝になる、と。
アーキテクチャとしては、MCP専用の独立サーバーを立てるパターンと、既存APIに組み込むパターンがあって、この記事では後者を採用。公式のgo-sdkを使い、GitHub MCP Serverなどの既存実装を参考にしつつ組み上げています。
特徴的なのが、認可の二重チェックです。まず`tools/list`の段階で、ユーザー権限に応じて「そもそも見えるツール」を絞り込む。さらに`tools/call`側でも、もう一度認可を行う。ツール定義に「必要権限」を紐づけておくことで、一覧も実行も両方ちゃんと制御する形ですね。
実装的には、ミドルウェアで認可情報をcontextに積んでおいて、クリーンアーキテクチャのUseCase層をそのまま呼ぶ構成。既存サービスのビジネスロジックを、MCPからもきれいに再利用できるようにしています。
また、CIMDを使ったクライアントの検証や、将来ツールが増えたときに`tools/list`をどうスケールさせるか、といった設計の論点も挙げられていて、これからMCPを既存プロダクトに統合しようとしているチームには、かなり参考になりそうな内容です。
記事全体として、「MCPの標準はまだ固まりきっていないので、これからもしばらくは認証・認可と可視性制御が重要テーマになっていく」という見通しで締めくくられていました。

……というわけで、今日は5本まとめて駆け足でお届けしてきました。
CTログから見える「URLを教えてなくても公開されている」現実、
Rust実装でGhostscript超えを目指したPDF圧縮の職人仕事、
Claude CodeのSkillで、定例後1時間で開発を進める仕組み化、
Googleの新しいAntigravity CLIでのTUI体験とモデル比較、
そして、既存GoサービスにMCPサーバーを組み込むときの設計ポイント、
このあたり気になったものがあれば、ぜひショーノートから元記事もチェックしてみてください。

「zenncast」では、番組の感想や、取り上げてほしいテーマ、Zennで見つけたおすすめ記事なんかも募集しています。
マイクへの質問や、こんな開発の悩みがあるよ、なんて話もぜひ送ってください。

それでは、そろそろお別れの時間です。
今日も良い一日をお過ごしください。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。バイバイ。