どうもこんばんは、マイクです。「zenncast」のお時間やってまいりました。
今日は二〇二六年九月十六日、水曜日の朝七時台いかがお過ごしでしょうか。通勤・通学中のあなたも、リモートワークの準備をしているあなたも、ここからの時間は、Zennで今日トレンドになっている記事を、一緒にゆるっと追いかけていきましょう。
今日はお便りコーナーはお休みしまして、このまま本題に入っていきたいと思います。
きょうご紹介する記事は、ぜんぶで五本です。フロントエンドからインフラ、そして設計の話まで、かなりバラエティ豊かなラインナップになっていますよ。
まず一つ目。
Reactの最新バージョン、リアクトじゅうきゅうてんさんで入った「Fragment Refs」という機能の、ちょっと想定外な使い方を紹介している、裏技系・Tips系の記事です。
出発点になっているのが、「自分自身のコンポーネントは直接DOMは描画しないんだけれども、中に入っている子要素だけを、まるっと非表示にしたい」というニーズなんですね。たとえば Activity コンポーネントみたいに、何かのコンテナとしては使うんだけど、実際のDOMは中身だけ、みたいなケースです。ここでやりたいのは、ラッパーの div とか span を増やさずに、中身の要素にだけ display: none と同じ効果を掛けたい。そのためにこの記事では CSS の display プロパティじゃなくて、HTML の `hidden` 属性を使って、一括で隠したり表示したりする、という発想になっています。
そこで登場するのが React 一九・三で入った Fragment Refs。これを使うと、フラグメント全体に対して「FragmentInstance」というオブジェクトが取れるんですが、その中に `observeUsing` というメソッドがあるんですね。本来これは、`IntersectionObserver` とか `ResizeObserver` を渡して、「このフラグメントの配下に増えたDOM要素を、順次オブザーブしてくださいね」という用途を想定しています。
ところがこの記事では、あえてそこに、本物の IntersectionObserver ではなくて、「`observe` と `unobserve` メソッドだけ持っている自作オブジェクト」を渡します。そうするとどうなるか。React側は「おっ、オブザーバー来たな」と思って、フラグメント配下のすべてのDOM要素に対して、その自作オブジェクトの `observe` を順番に呼んでくれるんですね。さらに、子要素が増えたり減ったりするときには、対応する `observe` と `unobserve` もちゃんと呼んでくれます。
ここで `observe` の中で何をするかというと、渡される element に対して、`element.toggleAttribute('hidden', enabled)` みたいな処理をしてあげる。これによって `<Hidden enabled> ... </Hidden>` みたいなコンポーネントを作っておいて、`enabled` がオンのときは配下のDOM要素ぜんぶに hidden 属性を付与、オフのときは一斉に外す、という動きをさせています。ポイントは、Reactのコンポーネント自体は余計なDOMを増やさないで、フラグメントの中身にだけ、まとめて hidden を付け外しできる、というところですね。
ただしこの記事の筆者も念押ししているんですが、この Fragment Refs の使い方は、完全に「想定外のハック」ですと。Reactの公式がサポートしているパターンではなくて、あくまで裏技的なテクニックなので、将来のバージョンで内部実装が変わった瞬間に、動かなくなる可能性がかなり高い。その点をしっかり注意喚起しつつ、「こういうことも一応できてしまうよ」という、ちょっと攻めたTipsを紹介している記事になっています。
。 。 。 。
続いて二つ目。
こちらも React 界隈の話なんですが、テーマは「React Compiler」と「TanStack Table」。キーワードは、「`useMemo` とか `useCallback` みたいな手動メモ化という判断そのものを、極力なくしてしまおう」というチャレンジです。
記事の構成としては、まず Vite はちの React じゅうきゅうの環境で、Babel を入れずに、Oxc ベースの `oxc-transform-react` と、`@vitejs/plugin-react` の `compiler: true` オプションだけで、React Compiler を有効化している、というところから始まります。つまり、古い Babel フルセットではなくて、軽量な Oxc ベースのトランスフォームで、コンパイラをオンにしているわけですね。
そしてそこで問題になってくるのが、テーブルUIライブラリの TanStack Table。バージョンははじめ v8 を使っていたんですが、この v8 の設計だと「state が変わっても table オブジェクトの参照が変わらない」ようになっている。React Compilerは「参照の変化」と「依存関係の解析」を元にメモ化を自動でやってくれるので、ここがかみ合わない。結果として、「このコンポーネントでは Compiler によるメモ化をオフにしてね」という意味の `'use no memo'` というディレクティブを、あちこちに書かざるを得なくなってしまったんですね。
そこで筆者は、TanStack Table を v9 に移行します。v9 ではこの辺りの設計が変わっていて、React Compiler と相性が良くなっている。そのおかげで、さっき出てきた `'use no memo'` を、最終的にはゼロにできたそうです。つまり、「変な参照の維持のされ方をしていて、コンパイラにとって扱いにくい」状態から、「コンパイラに素直な参照の流れになる」ようにライブラリを入れ替えた、ということですね。
一方で、TanStack Table v9 にしても万能ではなくて、column や row のように「参照が固定されたオブジェクト」だけを props に渡している場合には、React Compiler 的には「この props は変わっていない」とみなされてしまって、再描画されない、という問題も確認しています。ここを解決するには、Subscribe の仕組みなどを使って、「このコンポーネントはこの state の変化に反応してね」と明示してあげる必要がある。つまり、「全部コンパイラにお任せ」ではなくて、「どの state を監視するか」という宣言だけは、人間側がちゃんと書き分けてあげる必要がある、という実践知が述べられています。
さらに面白いのが、「AI コード生成」を前提にした体制づくりの話です。プロジェクト内に `AGENTS.md` というドキュメントを置いて、「人間もAIも、原則として手動メモ化は禁止です」というルールを明文化しています。`useMemo` や `useCallback`、それから `React.memo` を基本的には使わない方針ですね。これだけだと守られないので、静的解析ツールの oxlint に自作ルールを追加して、これらのフックや関数を見つけたら機械的にエラーにする、というところまでやっているのがポイントです。
どうしても例外として `useMemo` などを残したい場合だけ、抑制コメントを書き、その上で「なぜここでは参照の同一性が重要なのか」という理由を必ず残すようにしている。こうすることで、ふつうのところは全部 React Compiler に任せてしまって、本当にクリティカルな箇所だけ、人間が意図を明確に宣言する、という運用を回しているわけですね。AI がコードを書く時代に合わせて、「判断しないで済むようにする」設計やルールづくりをしているのが、とても印象的な記事です。
。 。 。 。
三つ目は、GitHub Pages と独自ドメイン、それから TLS 証明書まわりのちょっとハマりがちなポイントをまとめた Tips 記事です。特に「プライベートな GitHub Pages にカスタムドメインを当てる」という、ちょっとニッチなケースでハマりやすいところを、かなり丁寧に解説してくれています。
まず大事なのが、CNAME レコードの向き先。GitHub Pages の設定画面を開くと、`xxx.pages.github.io` みたいなランダムなサブドメインが出てくる場合がありますよね。これをそのまま DNS の CNAME に設定したくなるんですが、実はそれは「ブラウザ上でページを分離するための配信元アドレス」であって、DNS で指定すべき正規のドメインではないんです。
プライベートな GitHub Pages に独自ドメインを当てるときは、そのランダムなサブドメインではなくて、「組織の既定ドメイン」、つまり `<organization>.github.io` を CNAME の向き先にする必要があります。ここを間違えると、その後の挙動がかなりややこしくなります。
どうややこしいかというと、CNAME をランダムな固有サブドメインに向けていると、Pages の内部ステータスとして `is_https_eligible: false` のままになってしまうんですね。これが「TLS 証明書の発行処理のキューに、そもそも載っていない状態」を意味しています。しかもこの状態、エラーらしいエラーは返ってこなくて、`is_valid: false` みたいな分かりやすい理由も出ず、APIレスポンスにも `https_certificate` というキー自体が出てこない。結果として、ユーザー側からは「いつまで待ってもHTTPSにならないけど、どこで止まってるのかわからない」という状況になってしまうんですね。
そこで役に立つのが、GitHub CLI の `gh api` コマンドを使ったヘルスチェックです。`gh api repos/{owner}/{repo}/pages/health` を叩くと、`is_https_eligible` が true かどうか、それから `is_cname_to_github_user_domain` が true かどうか、というフラグを確認できます。ここが false のままなら、「CNAME の向き先がおかしいですよ」というサインになります。また、`is_proxied: true` というフラグが立っている場合もあって、これは Cloudflare みたいな外部DNSサービスでプロキシ機能、つまりCDNを有効にしているときに起こりがちです。GitHub から見ると、「このIPはPagesのIPじゃないな」と見えてしまうので、やはり `is_https_eligible: false` のままになってしまいます。
なので、独自ドメインとGitHub Pagesを組み合わせるときには、DNS側で「DNS only」モードにして、プロキシをオフにしておくのが重要です。名前解決だけさせて、CDNとしては挟まない、という構成ですね。
設定を直したあとも、ただ待つだけじゃなくて一手間必要なケースがあって、GitHub 側のリポジトリ設定で、一度カスタムドメインの設定を削除してから、もう一回同じドメインを登録し直すと、健康チェックと証明書発行プロセスが再実行されます。その上で、最終的な完了状態は `gh api repos/{owner}/{repo}/pages --jq .https_certificate.state` で確認できる。こういった具体的な API とフィールド名まで含めて、「どこを見れば詰まりどころがわかるか」を整理してくれている、とても実務的なTips記事になっています。
。 。 。 。
四つ目は、AWSのセキュリティ、特に SSM Agent の Session Manager ポートフォワーディング機能に関するSSRF脆弱性、CVE-二〇二六‐はちきゅうぜろよんきゅう、について解説している記事です。
この脆弱性のポイントは、「古いバージョンの SSM Agent を使っていて、EC2 から RDS へのポートフォワーディングだけを許可しているようなケース」で、EC2 に直接ログインできないユーザーでも、EC2インスタンスに紐づいた一時クレデンシャルを取得できてしまう、という問題です。
Session Manager 経由で RDS にトンネルしているだけのつもりが、実はそのトンネルを悪用して、EC2 内のメタデータサービス、つまり IMDS にアクセスされてしまう、というイメージですね。
悪用されるとどうなるかというと、EC2 にアタッチされている IAM ロールの権限で、AWS の各種リソースを操作できるようになってしまう可能性があります。これだけ聞くと「うわ、かなりヤバそう」と感じるんですが、記事では冷静に、「もともと SSM でそのEC2にセッションを張れるユーザーなら、別な手段で同じように一時クレデンシャルを取れてしまうよね」という整理もしています。
つまり、Session Manager 経由でEC2に入れるユーザーに対して、なぜかSSHとか他の直接アクセスは一切許していない、かつポートフォワーディングだけ開けている、というかなり特殊な運用でなければ、リスクの増分はそこまで大きくないのではないか、という見解なんですね。影響が大きいのは、その「ポートフォワーディングだけ許可している特殊なパターン」に限られるだろう、と。
とはいえ、ちゃんと確認はしておきたいので、記事では CloudTrail を使った調査手順も具体的に解説しています。CloudTrail のログで EventName を `StartSession` に絞り込み、さらに `documentName` が「AWS-StartPortForwardingSessionToRemoteHost」になっているイベントを探します。ここからさらに、AWS CLI と jq を組み合わせてクエリを投げ、parameters の `host` フィールドを一覧していく。その中に、`一六九・にーごーよん・いちにーご・にーごーよん`、つまり IMDS の IP アドレス `169.254.169.254` への接続が含まれていれば、「これはポートフォワードを使ってメタデータを抜きに行った可能性があるな」と判断できる、というわけです。
この脆弱性、CVSS スコアは九・九という、ほぼ満点に近いかなり高い評価が付いています。ただ記事の筆者は、現実の運用を踏まえると、「内部犯とか、ユーザーの認証情報がすでに盗まれているケースが前提になることが多いし、そもそもEC2への直接アクセスも認めている組織が大半だから、実務上のリスクはスコアほど高くないのでは」とコメントしています。
つまり、「数字だけ見てパニックになるというよりは、自分たちの環境でどういうアクセスパターンを許しているのかを確認したうえで、優先度を判断しよう」というスタンスですね。それでももちろん、SSM Agent のアップデートや、ポートフォワーディング運用の見直しは必要なので、その辺りのバランス感覚が参考になる記事です。
。 。 。 。
そして最後、五つ目。
こちらは雰囲気がガラッと変わって、ドメイン駆動設計、DDDの文脈で「巨大なモノリスをどう分割していくか」というテーマの記事です。病院の業務フロー、「予約から診察、会計、処方箋」といった流れを例にして、サブドメインの境界をどこに引くか、という話を具体的に説明しています。
記事の中で強調されているポイントはいくつかあります。まず、「業務ごとに生まれる成果物の区切れ目」に注目すること。たとえば、受付で作られる受付票、予診で記入される問診票、診察で医師が書く診療記録、会計で発行される請求書や領収書、そして薬局側の処方箋といった具合に、「何がアウトプットとして生まれているか」を見る。次に、「その成果物が一方向に流れていくルート」がどこかを考える。受付から予診、予診から診察、診察から会計、といった流れの途中に、自然な「区切れ」が現れます。
さらに、「担当者グループの違い」もヒントになります。受付を担当している人たち、看護師チーム、医師、会計スタッフ、薬剤師…といった具合に、関わる人が変わるところには、しばしばサブドメインの境界が存在します。また、同じ「予約」という言葉でも、受付が使うときと診察側が使うときとで意味や扱いが変わることがありますよね。そういった、「同じ単語なのに文脈によって意味がズレる場所」も、境界候補になります。
さらに、「処理が走る頻度」や「きっかけの違い」も重要です。たとえば予約は一日に何度も更新されるけれど、会計の締め処理は一日一回とか、月末にまとめて、など。イベントの粒度やトリガーが違うところも、サブドメインを分けるヒントになります。
こうした観点を組み合わせることで、病院のシステムを「受付」「予診」「診察」「会計」などのサブドメインに分割していく。そして、「後からある部分を変更しても、別の領域に影響が波及しにくい境界」を見つけよう、という話をしています。要するに、「変更の頻度と影響範囲を最小化できる分割」を目指す、ということですね。
ただし、ここで大事なのは「唯一の正解はない」ということ。記事でも、最適な分割はチームの大きさや、これまで実際にどこがよく変わってきたか、そういう過去の変更パターンに合わせて調整するのが良い、と述べられています。迷うときは、最初から細かく分けすぎないで、ちょっと大きめの塊で切っておいて、運用しながら必要に応じて細かく分解していくアプローチを勧めています。
また、業務フローの図にはなかなか出てこないけれど、システム上はほぼ必ず必要になる「ユーザー管理」みたいなコンテキストもありますよね。そういうものも別途、サブドメインとして設計に含めるべきだ、と指摘しています。
そして最後の方では、egon.io というツールで作ったドメインストーリー図を、生成AIに読み込ませて、「この業務フローから考えられるサブドメインのたたき台を出して」とお願いする、という活用法にも触れています。そのたたき台をベースに、人間のチームで「ここはまとめた方がいいよね」とか「ここは分けた方がいいよね」と議論していく。AIをいきなり正解を出すマシンとして扱うのではなく、「議論のスタート地点を早く出すためのツール」として使う姿勢が、とても現実的だなと感じる記事でした。
。 。 。 。
というわけで、きょうの「zenncast」、お送りしてきた内容を、最後に駆け足でおさらいしておきますね。
まず一つ目は、React 一九・三の Fragment Refs を使って、フラグメント配下のDOM要素に `hidden` 属性を一括で付け外しする、かなり攻めた裏技的テクニックの紹介。
二つ目は、React Compiler と TanStack Table の導入・移行を通じて、`useMemo` など手動メモ化の判断を極力なくし、AIコード生成も前提にしたルールとlintで、「基本はコンパイラに任せる」スタイルを徹底する実践のお話。
三つ目は、プライベートな GitHub Pages に独自ドメインを当てるときのCNAME先や、`is_https_eligible` などのステータスの意味、Cloudflareのプロキシ設定との相性など、TLS証明書まわりでハマらないためのTips集。
四つ目は、AWS SSM Agent の Session Manager ポートフォワーディング機能における SSRF 脆弱性、CVE-二〇二六‐はちきゅうぜろよんきゅうについて、影響範囲や CloudTrail での確認方法を整理しつつ、実務上のリスクを冷静に評価していた記事。
そして五つ目は、病院の「予約〜診察〜会計〜処方箋」の例から、成果物の流れや担当者の違いなどを手がかりに、モノリスをDDDのサブドメインに分割する考え方と、AIを使ってサブドメイン設計のたたき台を作る、というお話でした。
それぞれ、もっと詳しい内容や具体的なコマンド・図解なんかは、番組のショーノートに元の記事へのリンクと一緒にまとめておきますので、気になったテーマがあった方は、ぜひそちらからじっくり読んでみてください。
「zenncast」では、番組の感想や、「こんなテーマの記事を取り上げてほしい」なんてリクエストもいつでも募集中です。ちょっとした気づきや、実際にやってみた話なども、ぜひお便りで教えてください。
それでは、そろそろお別れの時間です。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。いってらっしゃい、そして良い一日を！