DEV Community: upa_rupa

How to Match Only `/` in CloudFront Using `/?*`

upa_rupa — Tue, 21 Apr 2026 10:30:52 +0000

How to Match Only `/` in CloudFront Using `/?*`

Introduction

When building a site on AWS CloudFront, a common requirement arises: "I want to route only the root (/) to a specific origin, or apply unique logic strictly to that path."

The challenge is that CloudFront’s path patterns lack a way to match exactly /. Typically, you end up relying on the Default Behavior (*), which captures everything from scripts to styles. This makes it difficult to separate caching strategies or route requests to different origins cleanly.

This article explores a clean way to solve this by taking advantage of the specific behavior of the ? wildcard: using the /?* pattern to isolate the root path.

The Constraint: CloudFront Path Patterns

CloudFront’s routing relies on path patterns with specific limitations:

No regular expressions
Two available wildcards:
- *: Matches any string of 0 or more characters.
- ?: Matches exactly one character.
Priority-based evaluation: The first pattern to match a request wins.

Within these constraints, the goal is to find a way to express “everything except the root” so the root itself can be handled independently.

How the Pattern Works

The key lies in the strict "exactly one character" rule of the ? wildcard.

Breaking Down the Pattern

The /?* pattern works as follows:

/ — A literal slash.
? — Exactly one character (required).
* — Any string of 0 or more characters.

This means that /?* matches any path that has at least one character following the initial slash.

💡 The Mechanism

By assigning /?* a higher priority, you ensure that only the root request (/)—which has zero characters after the slash—does not match and falls through to the Default Behavior (*).

Matching Results

Path	Matches `/?*`?	Reason
`/index.html`	✅ Yes	Matches `/` + `i` + `ndex.html`
`/main.js`	✅ Yes	Matches `/` + `m` + `ain.js`
`/assets/style.css`	✅ Yes	At least one character follows the slash
`/`	❌ No	Zero characters follow the slash

Fine-Grained Routing: SSR vs. Static Assets

The most practical application is a hybrid setup (e.g., Astro, Next.js), where you need to separate dynamic rendering from static delivery.

/ (Root): Route to a dynamic origin (Lambda, App Runner, etc.) to serve dynamic content and generate SEO metadata.
Everything else (/assets/*, /favicon.ico, etc.): Serve directly from S3 for maximum performance and lower costs.

Without this pattern, you’d need to manually enumerate every file extension. With /?*, you get a robust, catch-all solution for assets.

CDK Implementation Example

This approach keeps your infrastructure-as-code clean and easy to reason about:

import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';

const distribution = new cloudfront.Distribution(this, 'MyHybridDist', {
  // 1. Default (*) Behavior — Lowest Priority
  // Only the root (/) falls through to here.
  defaultBehavior: {
    origin: new origins.HttpOrigin('ssr-api.example.com'), 
    cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED, // SSR requires fresh data
    viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
  },
  additionalBehaviors: {
    // 2. Everything except root (/?*) — Higher Priority
    // Serve and cache all static assets from S3.
    '/?*': {
      origin: origins.S3BucketOrigin.withOriginAccessIdentity(assetBucket),
      cachePolicy: cloudfront.CachePolicy.CACHING_OPTIMIZED,
      viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
    },
  },
});

Strategic Advantages

Zero-Maintenance Asset Routing: No need to update your config when adding new file types (.webp, .avif, etc.).
Architectural Clarity: The logic for your "Entry Point" and your "Assets" is split cleanly at the edge.
Optimized Caching: Apply a no-cache policy to your dynamic root while keeping aggressive, long-term caching for everything else.

⚠️ A Subtle but Crucial Limitation

When combining this with CloudFront Functions, keep in mind:

Rewriting request.uri within a Function does not trigger a re-evaluation of cache behaviors.

If a request hits the Default Behavior (*) and your Function rewrites the URI to /index.html, CloudFront will not move that request over to the /?* behavior. Execution stays within the behavior that matched the original request.

Summary

The ? wildcard in CloudFront is often overlooked, but it can be surprisingly powerful. Its strictness allows for an elegant implementation of path-based negation.

Whether you are managing SSR setups, multilingual redirects, or maintenance pages, /?* is a reliable tool for handling the root path as a first-class citizen in your routing logic.

This article was originally published in Japanese on archelon-inc.jp.

The "Reply to Author" Pitfall in Google Groups — Why Your Messages Seem to Disappear

upa_rupa — Tue, 21 Apr 2026 10:01:18 +0000

The "Reply to Author" Pitfall in Google Groups — Why Your Messages Seem to Disappear

Introduction

In the Google Groups web interface, you’ll see three main reply options:

"Reply to all," "Reply to author," and "Forward."

Have you ever used "Reply to author"?

There’s one important thing to keep in mind: the messages you send aren’t automatically saved for you to access later.

What Actually Happens

When you click "Reply to author" in Google Groups, it opens a window to send a direct email to the original poster. You write your message, hit send—and then:

It won’t appear in the group archive — because it’s treated as a private email.
It won’t appear in your Gmail Sent folder — because the message is sent through Google Groups rather than your own Gmail account.

In short, you won’t have any way to review that message afterward.

Since there’s no record in your "Sent" folder or the group history, you can’t double-check what you wrote or confirm it was successfully delivered. You’re left waiting for a response without a paper trail.

Why Does This Happen?

Google Groups was originally designed as a bulletin board system, but many people use it like a mailing list. Because the interface feels like email, it’s natural to expect sent messages to be saved—this is where the confusion starts.

Action	How it's handled	History
Reply to all	Posted to the entire group	Saved in the group archive
Reply to author	Sent as a private message	Not saved in the group or Gmail

"Reply to author" sends a direct email through the Google Groups platform. Since your own email client isn't the one sending it, no copy is kept in your Sent folder.

Watch Out for Delivery Settings

Your email delivery settings can make this even easier to run into.

If your subscription is set to "Digest," multiple posts are bundled into a single email. To reply to a specific post, you often have to open the Google Groups web interface—which makes it much more likely you’ll click "Reply to author" by mistake.

A Known Issue for Users Worldwide

This is a well-documented issue. The Google Help Community contains many threads from users reporting this exact confusion.

For example, a thread titled "How can I see replies to author (a la Sent Messages)" has over 130 "I have the same question" votes. A Gold Product Expert confirmed that Google Groups does not provide a Sent folder or a built-in way to review these messages.

Even the official help page, "Compose or reply to a message," explains how to use the feature but doesn't explicitly mention that your messages won't be saved.

How to Avoid This

The Reliable Fix: Reply via Gmail

Avoid using "Reply to author" on the web interface. Instead, open the notification email in your Gmail inbox and reply directly from there.

When you send from Gmail, the message is saved in your Sent folder just like any other email.

Other Workarounds

BCC yourself (if the option is available)
Copy and save your message before hitting send
Manually add your own email address as a recipient

Summary

The "Reply to author" button might look convenient, but it lacks the basic record-keeping we expect from modern email. To ensure you always have a copy of your correspondence, get into the habit of replying directly from your email client. Don't let your important messages become "sent and forgotten" without a trace!

Getting 404 Errors After Building a Teams Tab App? HTML Caching Might Be the Cause

upa_rupa — Tue, 31 Mar 2026 10:47:14 +0000

Getting 404 Errors After Building a Teams Tab App? HTML Caching Might Be the Cause

Introduction

When developing Microsoft Teams tab apps, there's a frustrating issue you may run into during local development.

After modifying frontend code and rebuilding, Vite/Rollup adds a content hash to filenames (e.g., TeamsInitializer.bBRVpIft.js). However, if the browser (Teams WebView) has cached the HTML, the old HTML continues to reference the old hashed filenames, which results in 404 errors.

In this article, we'll share a solution we discovered by digging into the internal structure of the Teams SDK v2 local server.

Common Solutions and Their Drawbacks

Approach 1: Remove Hashes from Filenames

// astro.config.mjs or vite.config.js
export default {
  vite: {
    build: {
      rollupOptions: {
        output: {
          entryFileNames: 'assets/[name].js',
          chunkFileNames: 'assets/[name].js',
          assetFileNames: 'assets/[name].[ext]',
        },
      },
    },
  },
};

Drawback: Removing hashes means the browser may cache files indefinitely, preventing code updates from being reflected. You lose the benefits of cache busting.

Approach 2: Use the Dev Server (HMR)

Using Vite or Astro's dev server with HMR (Hot Module Replacement) avoids caching issues altogether.

Drawback: Teams apps are typically configured so that the Teams client (WebView) accesses a specific port, making it difficult to use the dev server's separate port directly.

Investigating the Teams SDK v2 Internals

When looking into the @microsoft/teams.apps package in Teams SDK v2, we discovered that HttpPlugin uses Express internally.

// Excerpt from node_modules/@microsoft/teams.apps/dist/plugins/http/plugin.js
const express_1 = __importDefault(require("express"));

let HttpPlugin = class HttpPlugin {
    constructor(server, options) {
        this.express = (0, express_1.default)();
        // ...
        this.use = this.express.use.bind(this.express);  // ← use() is exposed!
    }

    static(path, dist) {
        this.express.use(path, express_1.default.static(dist));
        return this;
    }
}

Key findings:

HttpPlugin holds an internal Express instance
The use() method is exposed and bound to Express's app.use()
This means we can add arbitrary Express middleware

Solution: Set Cache-Control Headers via Middleware

Leveraging this discovery, we add middleware to disable HTML caching only during local development.

// src/index.ts
import fs from "fs";
import https from "https";
import path from "path";

import { App, HttpPlugin, IPlugin } from "@microsoft/teams.apps";
import { ConsoleLogger } from "@microsoft/teams.common/logging";

const sslOptions = {
  key: process.env.SSL_KEY_FILE ? fs.readFileSync(process.env.SSL_KEY_FILE) : undefined,
  cert: process.env.SSL_CRT_FILE ? fs.readFileSync(process.env.SSL_CRT_FILE) : undefined,
};

const httpPlugin = new HttpPlugin(
  sslOptions.cert && sslOptions.key ? https.createServer(sslOptions) : undefined
);

// Disable HTML caching for local development only
if (!process.env.RUNNING_ON_AZURE) {
  httpPlugin.use("/tabs", (req, res, next) => {
    // Disable caching for HTML files and index.html requests
    if (req.path.endsWith(".html") || req.path === "/" || !req.path.includes(".")) {
      res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate");
      res.setHeader("Pragma", "no-cache");
      res.setHeader("Expires", "0");
    }
    next();
  });
}

const plugins: IPlugin[] = [httpPlugin];
const app = new App({
  logger: new ConsoleLogger("tab", { level: "debug" }),
  plugins: plugins,
});

app.tab("home", path.join(__dirname, "./client"));

(async () => {
  await app.start(+(process.env.PORT || 3978));
})();

Key Points

Environment-based control: The middleware is only added when the RUNNING_ON_AZURE environment variable is not set (i.e., during local development)
Path matching: Paths ending in .html, the root path, and paths without extensions (SPA routing) are treated as HTML requests
Cache-busting headers: Three headers — Cache-Control, Pragma, and Expires — are set to ensure caching is fully disabled

Benefits of This Approach

Hashed filenames are preserved: JS/CSS files keep their hashes, so production environments' caching efficiency is unaffected
No impact on production environments: Since it's controlled by an environment variable, the middleware is not added during Azure deployments
Extensible: The same technique can be used to add logging, authentication, custom headers, and more

Use Case: Adding Other Middleware

Using this technique, you can add various middleware to the Teams SDK.

// Add request logging
httpPlugin.use((req, res, next) => {
  console.log(`${req.method} ${req.path}`);
  next();
});

// Add custom headers
httpPlugin.use((req, res, next) => {
  res.setHeader("X-Custom-Header", "my-value");
  next();
});

// Add authentication for specific paths
httpPlugin.use("/api/private", (req, res, next) => {
  if (!req.headers.authorization) {
    res.status(401).send("Unauthorized");
    return;
  }
  next();
});

Caveats

This approach relies on the internal implementation details of Teams SDK v2 (@microsoft/teams.apps v2.x)
The API may change in future versions
This usage is not documented in the official documentation

Conclusion

We discovered that Teams SDK v2's HttpPlugin uses Express internally and exposes the use() method. By taking advantage of this:

HTML caching issues during local development are resolved
Cache-busting via hashed filenames is preserved
Development experience is improved without affecting production environments

We hope this helps anyone working with Teams SDK v2 who runs into the same issue.

This article was originally published in Japanese at archelon-inc.jp.

How to Change the Emoji Font to Noto Color Emoji in VS Code on macOS

upa_rupa — Tue, 31 Mar 2026 10:26:33 +0000

How to Change the Emoji Font to Noto Color Emoji in VS Code on macOS

Introduction

Have you ever wanted to change the look of emojis displayed in VS Code?

On macOS, Apple Color Emoji is used by default for emoji rendering. While Apple's emoji designs are polished, some people prefer Google's Noto Color Emoji.

However, many online sources claim that "Noto Color Emoji doesn't work in VS Code on macOS."

In this article, we'll show you how to use Noto Color Emoji in VS Code on macOS, based on steps we tested and verified on macOS (Apple Silicon).

TL;DR

It's surprisingly simple — just two steps:

Install the Noto Color Emoji font
Update the font settings in VS Code's settings.json

No Custom CSS extensions or system-level font configuration changes are needed.

Steps

1. Install Noto Color Emoji

Install it using Homebrew:

brew install font-noto-color-emoji

2. Update VS Code Font Settings

Open settings.json and configure as follows:

Editor:

"editor.fontFamily": "Your Font Name, monospace, Noto Color Emoji"

Terminal:

"terminal.integrated.fontFamily": "Your Font Name, monospace, Noto Color Emoji"

Restart VS Code after making these changes.

Key Point: Don't Use Single Quotes

Normally, font names containing spaces are often wrapped in single quotes (e.g., 'Noto Color Emoji'). However, in our testing, it worked correctly without single quotes.

When quotes are added, macOS's system font fallback may prioritize Apple Color Emoji. Omitting the quotes allows VS Code (which is Chromium-based) to correctly resolve and use Noto Color Emoji.

Approaches That Didn't Work

During testing, we also tried the following approaches, but they were ultimately unnecessary:

Overriding with Custom CSS Extension

You might consider using vscode_custom_css.imports to replace Apple Color Emoji with Noto Color Emoji via @font-face:

@font-face {
  font-family: 'Apple Color Emoji';
  src: local('Noto Color Emoji');
}

While this worked for the editor area, it doesn't affect the terminal because the terminal renders via Canvas/WebGL, which means CSS overrides are not applied. In the end, the editor.fontFamily setting alone was sufficient.

System-Level Font Changes on macOS

Modifying CoreText's fallback settings is another option, but it risks breaking with macOS updates and affects all applications, so we don't recommend it.

Why This Method Isn't Well Known

VS Code is an Electron (Chromium)-based application. Chromium's font fallback handling can behave differently from macOS native applications.

Many articles explain that "Apple Color Emoji is prioritized at the system level on macOS, so it can't be changed." This is generally true for native macOS applications. However, in Chromium-based apps like VS Code, font-family specifications are more directly reflected in font selection, which is why this method works.

Test Environment

macOS: Darwin arm64 25.1.0 (Apple Silicon)
VS Code: 1.109.4 (Universal)
Electron: 39.3.0
Chromium: 142.0.7444.265
Noto Color Emoji: Installed via Homebrew
Also verified working over Remote SSH connections

Conclusion

Changing the emoji font in VS Code on macOS turned out to be much easier than expected. Simply add Noto Color Emoji (without quotes) to editor.fontFamily and terminal.integrated.fontFamily.

Despite widespread claims online that "it's not possible on macOS," by taking advantage of the fact that VS Code is Chromium-based makes it achievable with a simple settings change.

If you'd like to change the look of your emojis, give it a try!

This article was originally published in Japanese at archelon-inc.jp.

References:

CloudFront パスパターンで「ルートだけ」を特定するテクニック

upa_rupa — Tue, 31 Mar 2026 00:46:29 +0000

CloudFront パスパターンで「ルートだけ」を特定するテクニック

はじめに

AWS CloudFrontでWebサイトを構築する際、「ルート（/）だけを特別なオリジンに向けたい、あるいは特別な処理をさせたい」という要件に直面することがあります。

しかし、CloudFrontのパスパターン設定には「/ のみ」をピンポイントで指定する記法がなく、通常は Default Behavior (*) を使うしかありません。これではルート以外のアセット（JS/CSS/画像）まで同じ設定に巻き込まれてしまい、キャッシュ戦略やオリジンの分離が難しくなります。

本記事では、CloudFrontのワイルドカード仕様を逆手に取った、/?* パターンを使ってルートを浮かび上がらせるテクニックをご紹介します。

背景：CloudFront パスパターンの制約

CloudFrontのキャッシュビヘイビアでは、パスパターンを使ってルーティングを制御しますが、以下の制約があります。

正規表現は使えない
使用可能なワイルドカード:
- *: 0文字以上の任意の文字列にマッチ
- ?: 正確に1文字にマッチ
パターンの評価: 設定の上（優先度が高い順）から評価され、最初にマッチしたものが適用される

この「正規表現が使えない」という制約の中で、「ルート以外すべて」を表現する方法が鍵となります。

解決策：`/?*` パターンの正体

ここで活用するのが、? ワイルドカードの「正確に1文字」という仕様です。

パターンの意味

/?* というパターンは、以下のように解釈されます。

/ : スラッシュ（固定）
? : 正確に1文字（必須）
* : 0文字以上の任意の文字列

つまり、/?* は 「スラッシュの後に少なくとも1文字以上あるパス」 にマッチします。

💡 ここがポイント

このパターンを優先度「高」で設定することで、Default Behavior (*) にはルートリクエスト（/）だけを落とし込むことが可能になります。

マッチングの結果

パス	マッチ判定	理由
`/index.html`	✅ マッチ	`/` + `i` + `ndex.html`（1文字以上の継続あり）
`/main.js`	✅ マッチ	`/` + `m` + `ain.js`（1文字以上の継続あり）
`/assets/style.css`	✅ マッチ	スラッシュの後に「1文字以上」が存在する
`/`	❌ 不適合	スラッシュの後に文字がゼロ個のため

実用的なユースケース：SSR + 静的アセットの分離

最も汎用的な活用例は、Astro や Next.js などを用いた「SSR（動的生成）と静的配信のハイブリッド構成」です。

/ (ルート): 最新記事のリストやSEO用のメタタグを動的に生成したい（Lambda / App Runner 等の SSR）
それ以外の全パス (/assets/*, /favicon.ico 等): S3から直接、高速かつ安価に配信したい

通常なら拡張子ごとにビヘイビアを定義する必要がありますが、/?* なら一撃で分離できます。

CDKでの実装例

このテクニックを用いると、インフラ構成コード（CDK）も非常にシンプルになります。

import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';

const distribution = new cloudfront.Distribution(this, 'MyHybridDist', {
  // 1. Default (*) ビヘイビア：優先度が最も低い
  // ここには / だけが落ちてくるため、SSRサーバー（動的オリジン）へ向ける
  defaultBehavior: {
    origin: new origins.HttpOrigin('ssr-api.example.com'), 
    cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED, // SSRは基本キャッシュなし
    viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
  },
  additionalBehaviors: {
    // 2. ルート以外のすべて (/?*)：優先度を高く設定
    // アセット類をすべて S3 から配信する
    '/?*': {
      origin: origins.S3BucketOrigin.withOriginAccessIdentity(assetBucket),
      cachePolicy: cloudfront.CachePolicy.CACHING_OPTIMIZED, // 静的ファイルは強力にキャッシュ
      viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
    },
  },
});

この手法のメリット

拡張子の列挙が不要: *.js, *.css, *.webp ...と延々と設定を増やす必要がありません。
責務の分離 (Separation of Concerns): 「動的なトップページ」と「不変の静的アセット」という、性質の異なるリソースをパスのレベルで完全に分離できます。
キャッシュ戦略の最適化: ルートHTMLには no-cache を、アセット類には長期間のキャッシュを、といった切り分けが一行のパターン定義で完結します。
メンテナンス性: 新しいファイル形式を追加しても、CloudFrontの設定変更は不要です。

⚠️ 注意点：CloudFront Functions との組み合わせ

このテクニックを使用する際、CloudFront Functions でパスの書き換え（Rewriting）を行う場合は注意が必要です。

CloudFrontの仕様上、Function内で request.uri を書き換えても、キャッシュビヘイビアの再評価（再マッチング）は行われません。

例えば、Default Behavior (*) に落ちてきたリクエストを Function で /index.html に書き換えたとしても、そのリクエストが /?* ビヘイビアに移動することはありません。あくまで「最初にマッチしたビヘイビアの設定」で処理が継続されます。

まとめ

CloudFrontの ? ワイルドカードは地味な存在ですが、「正確に1文字」という厳密さを利用することで、標準機能だけでは難しい「パスの否定論理」を組み立てることができます。

「ルートだけを特別扱いしたい」という要件は、SSR構成、多言語リダイレクト、あるいはメンテナンス表示など、実務で頻繁に発生します。この /?* テクニックを、シンプルかつ堅牢なインフラ設計の引き出しとして持っておくと非常に便利です。

参考資料:

Google グループ「投稿者に返信」の落とし穴 ― 送ったメッセージが消える？

upa_rupa — Tue, 31 Mar 2026 00:43:59 +0000

Google グループ「投稿者に返信」の落とし穴 ― 送ったメッセージが消える？

はじめに

Google グループのウェブ画面には、返信ボタンが3つ並んでいます。

「全員に返信」「投稿者に返信」「転送」。

このうち 「投稿者に返信」 を使ったことはありますか？

実はこのボタン、送信した内容が どこにも保存されない という、非常に気づきにくい落とし穴があります。

何が起きるのか

Google グループのウェブ画面で「投稿者に返信」をクリックすると、投稿者個人宛のメール作成画面が開きます。ここでメッセージを書いて送信すると……

グループのアーカイブには残らない — 個人宛の私信として扱われるため
Gmail の送信済みフォルダにも残らない — Gmail ではなく Google グループのシステムが代行送信しているため

つまり、送信した瞬間に、送信者本人ですら二度と内容を読み返せなくなります。

それだけではありません。送信済みフォルダにも履歴にも何も残らないということは、そもそも自分のメッセージが正しく送れたのかどうかすら確認できないのです。「相手に届いているだろうか」「内容に間違いはなかっただろうか」――そんな不安を抱えたまま、相手からの反応を待つしかありません。

なぜこうなるのか

Google グループは「掲示板（アーカイブ）」として設計されています。しかし実際には、多くの組織がメーリングリストとして利用しています。メールソフトのような感覚で使っているからこそ、「送信済み」に残るはずだという思い込みが生まれ、この落とし穴にハマりやすくなるのです。

操作	処理のされ方	履歴
全員に返信	掲示板への書き込み	グループのアーカイブに残る
投稿者に返信	掲示板の外での私信	どこにも残らない

「投稿者に返信」は、掲示板を通さずにシステムが直接メールを飛ばします。Gmail を介していないため、Gmail 側の「送信済み」フォルダにコピーを保存する処理が走らないのです。

メール配信設定にも注意

Google グループのメール配信設定も関連する話題です。

配信設定を「ダイジェスト」にしていると、グループへの投稿がまとめて届くため、個別のメッセージへの返信操作を Google グループのウェブ画面から行いがちです。結果として「投稿者に返信」の罠にハマりやすくなります。

世界中のユーザーが困っている

この問題は世界中で知られており、Google の公式ヘルプコミュニティには同様の質問が多数寄せられています。

英語版のヘルプコミュニティでは、「How can I see replies to author (a la Sent Messages)」というスレッドに 130人以上のユーザーが「同じ質問がある」と回答しています。Gold Product Expert の回答は 「Google グループには送信済みフォルダが存在せず、投稿者への返信を確認する方法はない」 というもので、現時点で仕様改善には至っていません。

なお、Google の公式ヘルプ「メッセージを作成する、メッセージに返信する」では「投稿者に返信」の操作方法は説明されていますが、送信内容が保存されないことについては一切触れられていません。

対策

鉄則：Gmail から返信する

Google グループのウェブ画面にある「投稿者に返信」ボタンは使わない。 必ず、自分の Gmail に届いた通知メールに対して、Gmail アプリ・画面から返信してください。

Gmail から送信すれば、「送信済み」フォルダにしっかり残ります。

その他の自衛策

返信画面で 自分を BCC に含める（チェックボックスがある場合）
送信前に内容をコピーしておく
宛先に自分のアドレスを追加する

まとめ

Google グループの「投稿者に返信」は、一見便利に見えて実は大きな落とし穴が潜んでいます。

送信内容はグループにも Gmail にも残らない
これは Google の仕様であり、現時点で改善の見通しはない
Gmail から返信するのが唯一確実な回避策

仕事のやり取りで「送った内容が確認できない」のは致命的です。ぜひこの仕様を知っておいて、大切なメッセージが消えてしまう前に対策してください。

Teams タブアプリでビルド後に404が出る？HTMLキャッシュが原因かも

upa_rupa — Mon, 30 Mar 2026 12:15:44 +0000

Teams タブアプリでビルド後に404が出る？HTMLキャッシュが原因かも

はじめに

Microsoft Teams タブアプリを開発していると、ローカル開発時に困る問題があります。

フロントエンドのコードを変更してビルドすると、Vite/Rollup がファイル名にハッシュを付けます（例: TeamsInitializer.bBRVpIft.js）。しかし、ブラウザ（Teams の WebView）が HTML をキャッシュしていると、古い HTML が古いハッシュ付きファイル名を参照し続けて 404 エラー が発生します。

この記事では、Teams SDK v2 のローカルサーバーの内部構造を調査して見つけた解決方法を紹介します。

一般的な解決策とその問題点

方法1: ファイル名からハッシュを除去する

// astro.config.mjs または vite.config.js
export default {
  vite: {
    build: {
      rollupOptions: {
        output: {
          entryFileNames: 'assets/[name].js',
          chunkFileNames: 'assets/[name].js',
          assetFileNames: 'assets/[name].[ext]',
        },
      },
    },
  },
};

問題点: ハッシュを外すと、ブラウザがファイルをキャッシュしてしまい、コード更新が反映されないことがあります。キャッシュバスティングの仕組みを失うことになります。

方法2: 開発サーバー（HMR）を使う

Vite や Astro の開発サーバーを使えば HMR（Hot Module Replacement）でキャッシュ問題は起きません。

問題点: Teams アプリは Teams クライアント（WebView）から特定のポートにアクセスする構成のため、開発サーバーの別ポートを直接使うのは難しい場合があります。

Teams SDK v2 の内部構造を調査する

Teams SDK v2 の @microsoft/teams.apps パッケージを調べてみると、HttpPlugin が内部で Express を使っていることがわかりました。

// node_modules/@microsoft/teams.apps/dist/plugins/http/plugin.js より抜粋
const express_1 = __importDefault(require("express"));

let HttpPlugin = class HttpPlugin {
    constructor(server, options) {
        this.express = (0, express_1.default)();
        // ...
        this.use = this.express.use.bind(this.express);  // ← use が公開されている！
    }

    static(path, dist) {
        this.express.use(path, express_1.default.static(dist));
        return this;
    }
}

重要な発見：

HttpPlugin は内部で Express インスタンスを持っている
use() メソッドが公開されており、Express の app.use() にバインドされている
つまり、任意の Express ミドルウェアを追加できる

解決策: ミドルウェアでキャッシュ制御ヘッダーを設定

この発見を活かして、ローカル開発時のみ HTML ファイルのキャッシュを無効化するミドルウェアを追加します。

// src/index.ts
import fs from "fs";
import https from "https";
import path from "path";

import { App, HttpPlugin, IPlugin } from "@microsoft/teams.apps";
import { ConsoleLogger } from "@microsoft/teams.common/logging";

const sslOptions = {
  key: process.env.SSL_KEY_FILE ? fs.readFileSync(process.env.SSL_KEY_FILE) : undefined,
  cert: process.env.SSL_CRT_FILE ? fs.readFileSync(process.env.SSL_CRT_FILE) : undefined,
};

const httpPlugin = new HttpPlugin(
  sslOptions.cert && sslOptions.key ? https.createServer(sslOptions) : undefined
);

// ローカル開発時のみ、HTMLファイルのキャッシュを無効化
if (!process.env.RUNNING_ON_AZURE) {
  httpPlugin.use("/tabs", (req, res, next) => {
    // HTMLファイルとindex.htmlへのリクエストはキャッシュを無効化
    if (req.path.endsWith(".html") || req.path === "/" || !req.path.includes(".")) {
      res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate");
      res.setHeader("Pragma", "no-cache");
      res.setHeader("Expires", "0");
    }
    next();
  });
}

const plugins: IPlugin[] = [httpPlugin];
const app = new App({
  logger: new ConsoleLogger("tab", { level: "debug" }),
  plugins: plugins,
});

app.tab("home", path.join(__dirname, "./client"));

(async () => {
  await app.start(+(process.env.PORT || 3978));
})();

ポイント解説

環境変数で制御: RUNNING_ON_AZURE 環境変数がない場合（ローカル開発時）のみミドルウェアを追加
パス判定: .html で終わるパス、ルートパス、拡張子がないパス（SPA のルーティング）をHTML リクエストとみなす
キャッシュ無効化ヘッダー: Cache-Control, Pragma, Expires の3つを設定して確実にキャッシュを無効化

この方法のメリット

ハッシュ付きファイル名を維持: JS/CSS ファイルはハッシュ付きのままなので、本番環境でのキャッシュ効率は変わらない
本番環境に影響なし: 環境変数で制御するため、Azure デプロイ時にはミドルウェアが追加されない
他のミドルウェアも追加可能: 同じ手法でロギング、認証、カスタムヘッダーなども追加できる

応用: 他のミドルウェアを追加する

この手法を使えば、様々なミドルウェアを Teams SDK に追加できます。

// リクエストログを追加
httpPlugin.use((req, res, next) => {
  console.log(`${req.method} ${req.path}`);
  next();
});

// カスタムヘッダーを追加
httpPlugin.use((req, res, next) => {
  res.setHeader("X-Custom-Header", "my-value");
  next();
});

// 特定パスに認証を追加
httpPlugin.use("/api/private", (req, res, next) => {
  if (!req.headers.authorization) {
    res.status(401).send("Unauthorized");
    return;
  }
  next();
});

注意点

この方法は Teams SDK v2 (@microsoft/teams.apps v2.x) の内部実装に依存しています
将来のバージョンで API が変わる可能性があります
公式ドキュメントには記載されていない使い方です

まとめ

Teams SDK v2 の HttpPlugin が内部で Express を使っており、use() メソッドが公開されていることを発見しました。これを活用することで：

ローカル開発時の HTML キャッシュ問題を解決
ハッシュ付きファイル名によるキャッシュ無効化の仕組みを維持
本番環境に影響を与えずに開発体験を改善

Teams SDK v2 を使っている方で同じ問題に悩んでいる方の参考になれば幸いです。

macOSのVSCodeで絵文字フォントをNoto Color Emojiに変更する方法

upa_rupa — Mon, 30 Mar 2026 11:04:54 +0000

macOSのVSCodeで絵文字フォントをNoto Color Emojiに変更する方法

はじめに

VSCodeで表示される絵文字の見た目を変えたいと思ったことはありませんか？

macOSでは、絵文字はデフォルトで Apple Color Emoji が使用されます。Appleの絵文字デザインも素敵ですが、Googleの Noto Color Emoji のほうが好みという方もいるでしょう。

しかし、ネット上の情報では「macOSではNoto Color EmojiはVSCodeで使えない」という記述が多く見られます。

本記事では、macOSのVSCodeでNoto Color Emojiを使う方法を、実際に動作確認した手順でご紹介します。

結論

意外にもシンプルで、以下の2ステップだけです：

Noto Color Emoji フォントをmacOSにインストール
VSCodeの settings.json でフォント設定を変更

Custom CSSの拡張機能やシステムレベルのフォント設定変更は不要です。

手順

1. Noto Color Emoji のインストール

Homebrewを使ってインストールします：

brew install font-noto-color-emoji

2. VSCodeのフォント設定を変更

settings.json を開き、以下のように設定します：

エディタ部分：

"editor.fontFamily": "お好みのフォント, monospace, Noto Color Emoji"

ターミナル部分：

"terminal.integrated.fontFamily": "お好みのフォント, monospace, Noto Color Emoji"

設定後、VSCodeを再起動すれば完了です。

ポイント：シングルクォートを付けない

通常、スペースを含むフォント名はシングルクォートで囲みます（例：'Noto Color Emoji'）。しかし、今回の検証では シングルクォートを外した状態 で正しく動作しました。

クォートを付けた場合、macOSのシステムフォールバックにより Apple Color Emoji が優先されてしまう場合があります。クォートなしで指定することで、VSCode（Chromiumベース）のフォント解決が Noto Color Emoji を正しく認識するようです。

うまくいかないアプローチ

検証の過程で、以下のアプローチも試しましたが、こちらは不要でした：

Custom CSS拡張機能による上書き

vscode_custom_css.imports を使って @font-face で Apple Color Emoji を Noto Color Emoji に差し替えるアプローチも考えられます：

@font-face {
  font-family: 'Apple Color Emoji';
  src: local('Noto Color Emoji');
}

エディタ部分ではこの方法も機能しましたが、ターミナル部分は Canvas/WebGL で描画されるため CSS が効きません。結局、editor.fontFamily の設定だけで十分でした。

macOSのシステムレベルでのフォント変更

CoreTextのフォールバック設定を変更する方法もありますが、macOSアップデートで壊れるリスクがあり、他のアプリにも影響するためおすすめしません。

なぜこの方法がネット上で知られていないのか

VSCodeはElectron（Chromium）ベースのアプリケーションです。Chromiumのフォントフォールバック処理は、macOSのネイティブアプリとは異なる挙動をする場合があります。

多くの記事では「macOSではApple Color Emojiがシステムレベルで優先されるため変更できない」と説明されていますが、これはネイティブアプリでの話です。VSCodeのようなChromiumベースのアプリでは、font-family の指定がより直接的にフォント選択に反映されるため、この方法が機能すると考えられます。

動作確認環境

macOS: Darwin arm64 25.1.0（Apple Silicon）
VSCode: 1.109.4 (Universal)
Electron: 39.3.0
Chromium: 142.0.7444.265
Noto Color Emoji: Homebrew経由でインストール
リモートSSH接続環境でも動作確認済み

まとめ

macOSのVSCodeで絵文字フォントを変更するのは、思った以上に簡単でした。editor.fontFamily と terminal.integrated.fontFamily に Noto Color Emoji（クォートなし）を追加するだけです。

ネット上では「macOSでは不可能」という情報が多いですが、VSCodeがChromiumベースであることを活かせば、シンプルな設定変更で実現できます。

絵文字の雰囲気を変えたい方は、ぜひ試してみてください。

参考資料:

DEV Community: upa_rupa

How to Match Only `/` in CloudFront Using `/?*`

How to Match Only / in CloudFront Using /?*

Introduction

The Constraint: CloudFront Path Patterns

How the Pattern Works

Breaking Down the Pattern

💡 The Mechanism

Matching Results

Fine-Grained Routing: SSR vs. Static Assets

CDK Implementation Example

Strategic Advantages

⚠️ A Subtle but Crucial Limitation

Summary

The "Reply to Author" Pitfall in Google Groups — Why Your Messages Seem to Disappear

The "Reply to Author" Pitfall in Google Groups — Why Your Messages Seem to Disappear

Introduction

What Actually Happens

Why Does This Happen?

Watch Out for Delivery Settings

A Known Issue for Users Worldwide

How to Avoid This

The Reliable Fix: Reply via Gmail

Other Workarounds

Summary

Getting 404 Errors After Building a Teams Tab App? HTML Caching Might Be the Cause

Getting 404 Errors After Building a Teams Tab App? HTML Caching Might Be the Cause

Introduction

Common Solutions and Their Drawbacks

Approach 1: Remove Hashes from Filenames

Approach 2: Use the Dev Server (HMR)

Investigating the Teams SDK v2 Internals

Solution: Set Cache-Control Headers via Middleware

Key Points

Benefits of This Approach

Use Case: Adding Other Middleware

Caveats

Conclusion

How to Change the Emoji Font to Noto Color Emoji in VS Code on macOS

How to Change the Emoji Font to Noto Color Emoji in VS Code on macOS

Introduction

TL;DR

Steps

1. Install Noto Color Emoji

2. Update VS Code Font Settings

Key Point: Don't Use Single Quotes

Approaches That Didn't Work

Overriding with Custom CSS Extension

System-Level Font Changes on macOS

Why This Method Isn't Well Known

Test Environment

Conclusion

CloudFront パスパターンで「ルートだけ」を特定するテクニック

CloudFront パスパターンで「ルートだけ」を特定するテクニック

はじめに

背景：CloudFront パスパターンの制約

解決策：/?* パターンの正体

パターンの意味

💡 ここがポイント

マッチングの結果

実用的なユースケース：SSR + 静的アセットの分離

CDKでの実装例

この手法のメリット

⚠️ 注意点：CloudFront Functions との組み合わせ

まとめ

Google グループ「投稿者に返信」の落とし穴 ― 送ったメッセージが消える？

Google グループ「投稿者に返信」の落とし穴 ― 送ったメッセージが消える？

はじめに

何が起きるのか

なぜこうなるのか

メール配信設定にも注意

世界中のユーザーが困っている

対策

鉄則：Gmail から返信する

その他の自衛策

まとめ

Teams タブアプリでビルド後に404が出る？HTMLキャッシュが原因かも

Teams タブアプリでビルド後に404が出る？HTMLキャッシュが原因かも

はじめに

一般的な解決策とその問題点

How to Match Only `/` in CloudFront Using `/?*`

解決策：`/?*` パターンの正体