どうもー、おはようございます。マイクです。
時刻は朝7時、2026年5月19日、火曜日。今日も「zenncast」スタートしていきましょう。

この番組では、技術系のナレッジ共有サービス「Zenn」で、いまトレンドになっている記事を、マイクが朝イチでサクッと紹介していきます。通勤前の方も、おうちでのんびりしている方も、コーヒー片手にゆるっと聞いていってください。

今日はですね、Zennのトレンド記事を、ぜんぶで5本、ご紹介していきたいと思います。インフラからWebフレームワーク、自宅LANのトラブルシュートに、AIコーディングのセキュリティ、ヘルスケアデータ基盤、さらにSnowflakeのMCPサーバーの権限設計まで。かなりバラエティ豊かなんですが、全部「AI時代の実戦知」がぎゅっと詰まってる感じです。

それじゃあさっそく、1本目からいきましょう。

……。。

1本目。タイトルは
「飲み会の帰り道、自宅サーバが落ちていたのでスマホからClaudeに任せ1時間で復旧させた話(Proxmox + Tailscale)」

これ、タイトルからしてもうエモいですよね。
筆者の方、自宅にProxmoxで環境を組んでいて、その中でClaude Codeを常駐運用していたんですが、外出中に全セッションがまとめて落ちちゃう。で、「あれ、これホストごと死んでない？」っていう嫌な予感がするわけです。同じタイミングで、家のWiFiにつなげた端末がIPアドレスを取れなくなっていて、家族からも「ネットつながらないんだけどー」って連絡が来ると。エンジニアあるあるの悪夢ですね。

ここで登場するのがTailscale。家庭LANの中で新しくIPを取りにいけない端末が増えても、Tailscale経由なら、すでに参加しているノードには外から到達できる。そこで筆者は、飲み会の帰り道、スマホからpve01ホストへSSH接続して、1つだけ立ち上げたClaudeセッションに、切り分けから復旧作業までをほぼ丸投げしちゃうんですね。自分はスマホで状況説明と、「これやっていい？」って聞かれたときの最終承認だけ。

真因がまたややこしくて、2系統ありました。
1つ目は、optiplex上のpbs-storeコンテナで、dhclientが暴走。secondary dynamicなアドレスを延々増やして、なんと97個も抱えちゃって、DHCPプールを枯渇させていた。さらに、claude-devと同じIPを主張し始めてIP衝突まで起きていた。
2つ目は、Claudeを載せているpve01ホスト自体が、数日おきにクラッシュする既知の不安定状態で、そのクラッシュの1回でtmuxセッションが全部消えた、というダブルパンチ。

pbs-store側は、dhclientを止めてIPをflush、ディスクもパンパンだったので拡張して再起動。バックアップもそこで復活する。ホストのクラッシュ問題はまだ残課題として残しつつも、とりあえず1時間程度でサービスを復旧できた、というお話です。

おもしろいのは、「冗長構成で全部守る」というより、「障害ドメインの外に、1本だけ管理経路（Tailscale）を確保しておく」っていう現実的な設計と、その上で「AIエージェントに手を動かしてもらい、人間はgo/no-goだけ出す」という運用スタイル。
AIをインフラ運用の“作業員”としてうまく使って、最後の責任だけ人間が取る、っていう、これからのSREっぽさがすごく伝わる記事でした。

……。。

続いて2本目。
タイトルは「NestJSが好きだけどきつかったから2週間でWebフレームワーク作った ( ZeltJS )」

筆者はTypeScriptでバックエンドを書くとき、いわゆる「ちゃんとしたフレームワーク」としてNestJSを気に入っていた方なんですけど、ここ数年のモダン環境で使おうとすると、いろいろきつくなってきたと。
たとえば、独自実装のデコレータへの強い依存とか、ESM対応の弱さ、起動の遅さでサーバーレスにはあまり向かないところ、独特なミドルウェア設計など、「思想は好きなんだけど時代との相性が微妙」というツラミを、かなり具体的に挙げています。

そこで出てくるのが、自作フレームワーク「ZeltJS」。コンセプトは「NestJSの思想 ＋ モダンTS ＋ どこでも動く」。
ベースにはHonoを採用していて、Node、Bun、Cloudflare Workers、AWS Lambdaなど、いろんな実行環境で同じコードが動くように設計されています。
依存性注入（DI）もちゃんと用意されていて、Valibotでの入力バリデーション、ConfigもDIコンテナに載せてテストコンテナとの連携もしやすい。Laravelやfrourioといった他フレームワークの良い思想も持ち込みつつ、「パラメータの取得をデフォルト引数の関数式にする」といった独自設計にもチャレンジしています。

面白いのは、これを「2週間で作り切った」背景に、Claude Codeをフル活用しているところです。設計の選択肢を洗い出して比較したり、POCをポンポン量産したりといった“設計まわりの試行錯誤”を、かなりの部分AIに手伝ってもらっている。
その結果、「最強のフレームワークって、自分で作っていいんだよ」というメッセージで締めていて、「フレームワーク利用者」から一歩踏み出して、「思想を持ったフレームワークの作者になる」楽しさを伝えてくれる記事になっています。NestJS周りでモヤモヤしてる人には、刺さる人多いんじゃないかなと思います。

……。。

3本目。
タイトルは「AI コーディングで secret を漏らさないための４層防御」

これは、AI時代ならではのセキュリティ実務の話です。
著者ご本人が、過去に「顧客向けマニュアルにIDとパスワードを直書きしてコミットしてしまい、そのあと履歴の削除と、関係するパスワード全ローテーションをやる羽目になった」という、かなりつらい実体験をされています。で、その反省も踏まえて、「AIでコード生成量が爆増する時代に、どうやってsecretを守るか」というテーマで、4層の防御を提案している記事です。

ポイントは、「人間が気をつける」ではなく、「gitを単一の入口として、決定論的な仕組みで守る」という発想。
第1層は、実際の値を含むファイルを`.gitignore`に入れて、そもそも混ざりようがない設計にする。dotenvとか、JSONの実値ファイルとかですね。
第2層が、gitleaksとlefthookを使ったpre-commitフックでのスキャン。汎用パターンに加えて、プロジェクト固有のルールも作って、コミット前に自動検知する。
第3層は、GitHubのPush Protection。ローカルをすり抜けても、サーバー側で最後のフェイルセーフをかける。
第4層は、Claude CodeのPreToolUseフックを使って、AIが書き込みをする前にgitleaksを回す補助的な防御。ただし、ここは「補助」であって、「AIに守らせる」ことを主防御にしちゃダメだよ、という強いメッセージもあります。

もし漏れちゃった場合の対応も、かなり具体的です。
git filter-repoなどを使って履歴からしっかり削除したうえで、必ず該当シークレットをローテーションする。GitHubのキャッシュなど、履歴がどこに残るかという残存リスクも理解して動きましょう、と。
全体として、「人とAIの注意力」ではなく、「gitレベルでのルールと自動検査」で守るのが、AIコーディング時代の基本戦略だよ、という、現場目線の実践ノウハウになっています。

……。。

4本目。
タイトルは「AppleヘルスケアをBigQueryに貯めて、MCP経由でスマホから分析してみた」

これは、技術で自分の生活をちゃんと良くしていく方向の話で、読んでてワクワクしました。
筆者は、ダイエットとか体調管理のためにAppleヘルスケアを使っていて、そのデータをAIが「長期コンテキスト」として扱えるようにする、個人向けデータ基盤を作った、という内容です。

構成としては、iPhoneからHealth Auto Export Proというアプリを使って、Cloud RunのエンドポイントにJSONでPOST。それをBigQueryに保存していきます。
データは3層構造で管理。
生データのBronze、重複排除や単位変換などをしたSilver、そして日次集計のGold。このGoldレイヤーでは、特にサンプル粒度の細かい心拍数やHRVなんかを、「AIが扱いやすい日次の粒度」に寄せてあげているのがポイントです。

分析側も凝っていて、ClaudeからはBigQuery MCP経由で直接クエリを投げる。一方、ChatGPTにはSilver/Goldの一部だけをSupabase越しに見せる構成にしていて、権限と公開範囲を最小限に抑えている。自分のヘルスデータなので、ここはすごく大事ですよね。

これによって、「今日は運動したほうがいいのか、休んだほうがいいのか」とか、「最近ちょっと無理してない？」みたいな相談を、睡眠や運動量、HRV、体重の長期推移全部込みで、AIに聞けるようになった。で、AIから「今日は休んだほうがいい」と言われると、「じゃあ休むか」と素直に受け入れやすくなった、と。これはあるあるですね、人から言われるより、データとAIに言われたほうが納得しやすいところあります。

今後の構想としては、食事、日記、位置情報、SNSの投稿、ChatGPTへの相談ログなんかも全部統合して、「自分の生活全体をAIが読める長期コンテキストにしたい。AIに管理されたい」とまで書いてあって、その第一歩が、今回のAppleヘルスケア → BigQuery → MCPのパイプラインだと位置づけられています。

実装上のハマりどころとして、Health Auto Export Proのpayload仕様の揺れとか、睡眠データのsource重複、パーセンテージ表現のばらつき、巨大なexport.xmlへの対応なんかも書かれていて、単なる夢物語じゃなくて、「やってみるとここがつらいよ」というリアルも含めた記事になっています。

……。。

そして本日ラスト、5本目。
タイトルは「Snowflake-managed MCP ServerのOAuth認証への理解と権限設計」

これは、SnowflakeのManaged MCP Serverを本番運用するときに、「認証」と「認可」をきちんと分けて設計しよう、という話です。AIエージェントからSnowflakeを触らせるときに、どこまで何を許すか、ですね。

リスクとして挙げられているのは、たとえばOwner権限で動いちゃうToolや、任意SQLを実行できるToolによる想定外のデータアクセス。PAT（Personal Access Token）の配布・ローテーション運用の難しさ、Toolを広く公開しすぎて誤用される可能性、実行主体やSQLが追えなくなる監査不能な状態、こういった現実的な懸念です。

認証の部分では、Snowflakeの推奨どおりOAuthを基本にして、SECURITY INTEGRATIONでクライアントを事前登録。そのうえで、強い権限を持つRoleはBLOCKED_ROLES_LISTで制限しておく。
さらに、クライアント側でscopeを`session:role:<ROLE>`に固定することで、セッション上で`USE ROLE`を打ち換えるのを禁止して、安全側に倒すことができる。ただしscopeの強制までは仕組みとしてできないので、サービスユーザーを作って最小権限ロールを割り当てる、という設計案も紹介されています。

SQL実行系のToolについては、`read_only: true`を必ず付けて、完全に読み取り専用にする。そしてOAuthの側でも、そのToolが使えるロールをかなり絞る。
認可設計では、MCP Serverの「作成」「所有」「利用」、それからTool実行権限（Cortex Search/Analyst/Agent、UDFやストアドプロシージャ）をレイヤーごとに分離して考えます。
具体的には、ロールを
・MCPを作成する「MCP_ADMIN_ROLE」
・各Schemaごとの所有を担う「MCP_<schema>_OWNER_ROLE」
・それを利用する「MCP_<schema>_USER_ROLE」
という三層に分けて、さらにSECURITYADMIN/USERADMINロールがその統合や管理を担う、という構造にすることで、事故が起きたときの影響範囲をきちんと限定できるようにしている。

AIエージェントがどんどんSnowflakeを叩くようになっていく中で、「誰が、どのロールで、どんなSQLを実行したのか」をきちんと追えるようにしつつ、過剰な権限を与えない。そのための実践的な設計パターンがまとまった記事になっています。

……。。

というわけで、今日は5本の記事をご紹介しました。
1本目は、TailscaleとClaudeを駆使して、飲み会帰りに自宅サーバを1時間で復旧させたインフラ運用のお話。
2本目は、NestJSの思想を引き継ぎつつ、2週間で自作したモダンTSフレームワーク「ZeltJS」の話。
3本目は、AIコーディング時代にsecretを守るための、gitベース4層防御。
4本目は、AppleヘルスケアのデータをBigQueryにためて、MCP経由でAIから分析できるようにした、個人用データ基盤の話。
そして5本目は、Snowflake-managed MCP Serverを安全に運用するための、OAuth認証と権限設計の実践ノウハウでした。

気になった記事があった方は、番組のショーノートから、ぜひ元の記事もチェックしてみてください。細かい設定や実装の工夫なんかは、そちらのほうが断然詳しく書かれています。

「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」「この技術で悩んでます」といったお便りも、いつでも募集しています。日々の開発や勉強のおともに、この番組をどう使っているかなんかも教えてもらえると嬉しいです。

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