調査レポート: MoonBit 版のブログの文章を Wasm の外に出す #

ドキュメント #

Static Assets、binding、料金と制限、Workers の制限 を読んだ。

• assets の設定は directory（置き場所）、binding（Worker から読むための名前。例は ASSETS）、run_worker_first。
• 既定（run_worker_first: false）では、パスがアセットに一致すると Worker を通さずにそのまま返す。true にするとすべてのリクエストが先に Worker に届く。パターンの配列で一部のパスだけにもできる。
• env.ASSETS.fetch() は Request、URL、文字列を受け取り、URL のホスト名は無視してパスだけで探す。
• 料金: 「Requests to static assets are free and unlimited」「There is no additional cost for storing Assets」。Worker を通るリクエストは今までどおり Workers の料金で数える。無料プランの上限を超えると、run_worker_first に一致するリクエストは 429 になる（今も全リクエストが Worker を通るので、条件は変わらない）。
• 制限: アセットのファイル数は Free で 20,000、Paid で 100,000。1 ファイルは 25 MiB まで。Worker 本体は非圧縮で 64 MiB まで。起動（グローバルスコープの評価）は 1 秒まで。
• アップロードしないファイルは、アセットのディレクトリの .assetsignore（.gitignore と同じ書き方）で指定できる。

spike #

/tmp に、記事 5 本と docs/sketch/ja/*.md 6 本を content/ に置き、次の設定で確かめた（wrangler 4.148.0）。

{
  "name": "assets-spike",
  "main": "./worker.mjs",
  "compatibility_date": "2026-10-01",
  "assets": { "directory": "./content", "binding": "ASSETS", "run_worker_first": true }
}

/raw/<path> で env.ASSETS.fetch(new URL(path, "https://assets.local")) の結果を返し、/many で記事 5 本を Promise.all でまとめて取る Worker を書いた。

ローカルの workerd での数字なので、本番の速さはデプロイしてから測る必要がある。

文章の置き場所 #

moonbit/cloudflare/build/（当時は moonbit/workers/build/）は、今も Wasm をコピーする、git で無視している置き場所になっている。ビルドのコマンドで、ここに content/ を作って文章をコピーする。

• content/posts/*.md（go/examples/blog/posts から）
• content/docs/TODO.md と content/docs/docs/**/*.md（リポジトリから。パスは今の repodocs と同じ）
• content/files.txt: 上のファイルのパスの一覧（目録）

Static Assets には一覧を返す API がないので、目録は自分で作る。find と sort で足りる。site.css と favicon.svg は小さく、記事とともに増えるものでもないので、埋め込んだままでよい。

Go 版は今までどおり go:embed で埋め込む。変わるのは MoonBit 版だけ。

Wasm への渡し方 #

今の serve は同期で、worker.mjs からパスを受け取ってその場で応答を作る。env.ASSETS.fetch() は非同期なので、Wasm から直接は呼べない。案は 3 つある。

案 1、**最初のリクエストで全部を渡す（推奨）**: Worker の起動後の最初のリクエストで、worker.mjs が files.txt とすべてのファイルを並行して取り、ファイル名と本文を順に Wasm に渡す（今の path_push と同じコード単位の受け渡しに、file_name と file_body のような export を足す）。Wasm はそれで Site を作り、以降は今と同じく同期で応答する。

• 今の Site::embedded は、埋め込んだファイルから最初の serve で Site を作っているので、その入力を差し替えるだけで済む。記事のリンクを解決するのに全部の文書の一覧が要る、という今の作りもそのまま使える。
• 代償は、Worker の起動後の最初のリクエストだけが、全部の文章を取る分だけ遅くなること。今の量（約 134 KB）なら、spike の数字から数 ms と見込む。isolate のメモリにも全文が載るが、これは今と同じ。

案 2、**JS がパスから要るファイルを決めて先に取る**: リクエストごとに 1 ファイルだけ取ればよいが、ルーティングの知識が worker.mjs に漏れる。一覧ページやリンクの解決には、結局全部の一覧と各記事の title / description が要る。

案 3、**Wasm が要るファイルを返し、JS が取って呼び直す**: ルーティングは Wasm に残るが、ABI が「応答」か「このファイルが要る」の 2 通りを返すようになる。一覧ページのために、title と description をビルド時に目録に入れておく必要もある（Go 版と同じ規則で作るには、tinyfrontmatter と tinymarkdown を使う native のコマンドが要る）。

案 1 は ABI に入力の export を足すだけで、Wasm の中のルーティングもレンダリングもそのまま使える。案 3 は、文章が数 MB になって最初のリクエストの遅れが気になってきたら考える。そのときは TODO.md の Future work の「Workers 用アダプターを最適な形に磨く」と一緒に設計する。

変わらないこと、変わること #

• make dev と make deploy の使い方は変わらない。wrangler dev の watch_dir には、すでに記事と docs/ が入っている。
• make test は、テスト用の文章を Site に直接渡すので、ネットワークも Assets も要らない。実装では、埋め込みをテストと experiments/ に残した。
• 比較（make compare）は今までどおり、Go 版と一致することを確かめる物差しになる。

置き場所とビルド #

build/content/ は git で無視している（files.txt も含む）。記事を足したときに再生成が要るのは build だけで、テストは埋め込みを使うので embed が走る。

Wasm への渡し方 #

worker.mjs は files.txt を取ってから、一覧の各ファイルを Promise.all で取る。それを app.load() に渡すと、adapter.mjs が 1 ファイルずつ file(n) を呼ぶ。Site は serve の最初の呼び出しで作る。BASE_URL はリクエストの env から来るので、Site の組み立てをリクエストの処理まで遅らせている。

Site の組み立てに失敗したときは、その内容を 500 の本文にして返す。worker.mjs 側も ASSETS の取得に失敗したら 500 を返し、loading を捨てて次のリクエストでやり直す。isolate が生きているあいだ、内容は取り直さない（Static Assets はデプロイのときしか変わらない）。

サイズ #

2026-10-22、投稿 10 本（バンドルの 3 ファイルを含めて 12 ファイル）と文書 21（files.txt を足して 34 ファイル、約 397 KB）での比較。変更前は 2a3cdf1 の worktree で測った。

調査のときに「249 KB から 100 KB 強になる見込み」と書いたが、実際は 175 KB になった。文書が調査時より増えた（このレポート自身も入っている）のに、Wasm は記事と文書の量に比例しなくなった。wrangler deploy --dry-run は Read 41 files from the assets directory と言うが、これは 34 ファイルと 7 ディレクトリを数えたもので、Total Upload には入らない。

時間 #

Node.js 24 で、worker.mjs と同じ順序（load してから call）を実行して測った。内容は上の 34 ファイルのうち、files.txt を除く 33 ファイル。

wrangler dev の往復時間（curl を 40 回送り、最初の 10 回を除いた 30 回の中央値）は、同じ --persist-to を指定した変更前と変更後で次になった。

最初のリクエストだけ 40〜50 ms ほど遅い。内容の取得と Site の組み立ての分で、ローカルの workerd の数字なので、本番では未確認。温まったあとは 0.5 ms ほどで、リクエストごとの差はほぼない。

確かめたこと #

• make test: MoonBit のテスト 93 件（ほかに JS ターゲットの 2 件）と、Node での統合テスト 10 件が通る。
• Go 版のブログ（-debug -base-url https://blog.podhmo.workers.dev）と 62 パスを比べ、0 of 62 paths differ。記事のページと .md、文書と .md、一覧、/favicon.svg、/site.css、存在しないパスを含む。
• wrangler dev を動かしたまま記事を 1 本足すと、20 秒ほどで新しい記事が 200 で返り、app.wasm の SHA-256 は変わらなかった。消すと files.txt から外れて 404 に戻った（ファイルは build/content/ に残る。make clean で消える）。
• 記事の front matter に知らないキーを書くと、最初のリクエストが 500 になり、本文にそのキー名が出る（内容の誤りがリクエスト時に分かる）。

つまずいたこと #

**wrangler dev のビルドが重なる。** watch_dir のファイルを続けて変えると、前の make build が終わる前に次が始まる。最初の content.sh は出力を rm -rf してからコピーしていたので、そのあいだのリクエストが内容を見つけられなかった。embed.sh も $out.tmp という固定の名前を使っていたので、2 つのビルドが同じ一時ファイルを奪い合い、mv: cannot stat '...embedded.mbt.tmp' で失敗した。さらに、その途中で 0 バイトの app.wasm が置かれ、workerd が CompileError を返したことがある（開発中だけ）。

直し方:

• 一時ファイルの名前に $$（プロセスの ID）を足した（embed.sh、embed-assets.sh）。
• content.sh はファイルを出力の隣で作ってから mv で置き換え、files.txt を最後に書くようにした。ビルドの途中でも、壊れたファイルは見えない（新旧のファイルが混ざることはある）。
• content.sh は、消えた記事のファイルを消さずに files.txt から外すようにした。重なったビルドが互いのファイルを消す競合を避けるため。配信されないので、残っても害はない。

**計測の落とし穴。** 最初に wrangler dev の往復時間を比べたとき、変更後が 14 ms、変更前が 5.5 ms で、温まったあとも 8 ms も遅いように見えた。しかし、ブログのコードではなく wrangler dev の置き場所の問題だった。

• 変更前の worktree は /tmp（tmpfs）にあり、変更後はリポジトリ（ext4）にあった。
• wrangler dev はローカルの状態を .wrangler/state に持ち、リクエストごとにそこへ書く。tmpfs と ext4 でその費用が変わる。
• ASSETS を外して Wasm を呼ばずに 500 を返す経路でも 14 ms だったので、アプリの処理時間ではないと分かった。
• 両方に --persist-to で同じ tmpfs の場所を指定すると、6 ms 前後にそろった。

同じコードを /tmp に置いても速くなり、リポジトリの中の、中身が return new Response("hi") だけの Worker でも遅かった。ローカルの往復時間を比べるときは、状態の置き場所もそろえる必要がある。

**デプロイで古い JS と新しい Wasm が混ざった。** マージ直後に本番へデプロイしたところ、https://blog.podhmo.workers.dev/ が 500 で no content loaded: the host must call file for each asset を返した。git 管理外の build/ と _build/ はブランチを切り替えても残るので、あるブランチで作った app.wasm と content/ が残ったまま、別のブランチの worker.mjs でデプロイすると、この組み合わせになりうる。古い worker.mjs は file を呼ばないが、新しい Wasm は呼ばれる前提で Site を作るため、内容が空のまま最初のリクエストを迎える。

main を取り込んでからデプロイし直すと直り、Go 版との 62 パスの比較も一致した。CI のデプロイはクリーンな checkout なので起きない。ローカルでも同じことが起きないよう、make deploy は make clean に依存させ、毎回作り直してからデプロイするようにした（README の「Deploying」にも書いた）。

問い #

ASSETS バインディングへの fetch は subrequest の上限に数えられるか。数えられるなら、記事と文書が増えたときにどうするか。

答え #

数えられる。記事と文書をビルド時に 1 つのファイル content.bin にまとめ、Worker は最初のリクエストでそれを 1 回だけ取得するようにした。取得の回数は記事の数によらず 1 回になる。

どう確かめたか #

**本番で失敗した。** #89 をマージしたあとに make -C moonbit deploy したところ、https://blog.podhmo.workers.dev/ が次を返した。

Too many subrequests by single Worker invocation. To configure this limit, refer to https://developers.cloudflare.com/workers/wrangler/configuration/#limits

そのときの worker.mjs は、files.txt と、そこに並ぶファイルを 1 つずつ ASSETS から取得していた。各コミットでの内容のファイル数（list-files.sh で数えた）と、最初のリクエストでの取得回数（files.txt を含む）は次のとおり。

50 を超えたのは #89 からで、失敗が始まった時期と合う。ほかに subrequest を出すコードはないので、ASSETS への取得が数えられていたことになる。

**Cloudflare のドキュメント**（2026-10-27 に読んだ）。

• Workers の Limits: subrequest は "any request a Worker makes using the Fetch API or to Cloudflare services like R2, KV, or D1"。1 回の呼び出しあたり Free で 50、Paid で 10,000（最大 1000 万）。Static Assets のファイルは 1 つ 25 MiB まで、Worker のバージョンあたり Free で 20,000 ファイルまで。
• Wrangler の設定の limits: subrequests は "defaults to 50 for free accounts"、"The free account maximum is 50"。また "Limits are only enforced when deployed to Cloudflare's network, not in local development"。
• Static Assets のバインディング と Billing and limitations: ASSETS への fetch が subrequest に数えられるかどうかは書かれていない。Service bindings には "Each request to a Worker via a Service binding counts toward your subrequest limit" とある。ASSETS も Fetcher のバインディングなので、同じ扱いと考えるのが自然で、本番の失敗とも合う。

**手元での確認。** wrangler dev は上限を課さない（上のドキュメントのとおり）ので、上限で失敗するかどうかは手元では再現できない。代わりに、一時的に env.ASSETS.fetch を数えるコードを worker.mjs に足して make dev PORT=8798 で動かし、リクエストごとの取得回数を出した（確認のあとで外した）。

• 新しい isolate の最初のリクエスト（/）: 1 回（content.bin）
• 続く /posts/、/slops/、/posts/why-ai-novel-is-bored、/posts/why-ai-novel-is-bored/article1.md、/docs/: 0 回
• /preview.wasm: 1 回（これまでどおり ASSETS へそのまま渡す）

content.bin を worker.mjs の unpack で分けると、53 ファイルの名前が前の files.txt と同じ順で一致し、中身も元のファイルとバイト単位で一致した。Go 版と make compare で比べると、トップページと各一覧からリンクされた 44 パスと article1.md が一致した（/preview.wasm は比較ツールがバイナリを UTF-8 として読めずに両側でエラーになるので、cmp で元のファイルと同じことを確かめた）。

選ばなかった案 #

• **limits.subrequests を上げる。** Free の最大が 50 なので上げられない。Paid にしても、記事が増えるたびに上限へ近づく形は変わらない。
• **ページごとに必要なファイルだけ取得する。** トップページや一覧はすべての記事のタイトルと日付を要るので、最初のリクエストで結局すべてを読むことになる。
• **Wasm に埋め込み直す。** 記事を足すたびに Wasm が太るのを避けるために外へ出したので、戻す理由がない。
• **JSON にまとめる。** 今の記事や文書はどれも UTF-8 のテキストなので、JSON でも運べる。ただ、Wasm に渡すのはもともとファイルごとの Uint8Array なので、<size> <name>\n のヘッダーと中身のバイト列を並べる形のほうが、文字列への変換と戻しを挟まずに切り出すだけで済む。束はバイナリーのファイルを扱わないので、バイナリーのためにこの形を選んだわけではない。

残ること #

• content.bin は 1 ファイルなので、25 MiB の上限に近づいたら分ける必要がある。今は約 630 KB。
• ~~本番で直ったかは、デプロイしてから確かめる。~~ 修正を make -C moonbit deploy したあと、https://blog.podhmo.workers.dev のトップページ、/posts/、/slops/、/posts/why-ai-novel-is-bored、/posts/why-ai-novel-is-bored/article1.md（text/markdown）、/docs/、/preview.wasm（application/wasm）が 200 を返し、存在しないパスは 404 を返した。新しい isolate の最初のリクエストを狙って打ち分けたわけではないが、修正前はトップページが subrequest の上限のエラーを返していた。