blog.taaas.jp

この記事は何か？

Movable Typeの再構築（静的なファイルの生成）の高速化に関する個人的な実験の記録です。

筆者の天野はMovable Typeの開発にエンジニアとして参加しており、開発元のシックス・アパートにも所属していますが、この記事で触れられているコードや結果については全て個人として実験した記録になります。

比較対象

今回はざっくりとした比較なので、ウェブブラウザのインターフェイスから再構築操作をした結果の処理時間をベースとします。「処理時間: 33秒」となっているので、ここからざっくり10倍速くできるかどうかを試します。

対象のデータは以下のスクリプトで投入しています。

• 1500文字程度の内容で365記事
• 12カテゴリ

コンテンツタイプの方が最適化のしがいがありそうですが、手を広げると実装が大変なので最初のベンチマークとしてはこんなところかなと思います。

docker composeで起動した環境上での比較なので、DB（mysql）も全て同じ端末上で動作している状態です。

アプローチ

以下のアプローチで高速化を試みます。3点目についてはややチートっぽさがありますが、「互換性を切り捨てれば高速化できる」という面は往々にしてあるので、こういった試みの中では妥当な選択肢であると思います。

• Rustで実装する
• 複数スレッドで処理する
• コストのかかる互換性は維持しない

Rustで実装する

実行速度を優先すると2025年ではRustかGoあたりが有力な選択肢と思われますが、現状だと速度面やAIによる生成の効率など、公開されている調査結果を見るとRustが若干リードしているようなので、Rustを選びました。

またRustの方がWebAssemblyとの親和性が高く、ウェブブラウザ上やクラウドのエッジ上でも利用できる可能性があるというのも、特にMTとの関連では強みとなりそうです。

ウェブブラウザやエッジのランタイムだとTypeScriptという選択肢もあったりもします。MTのような使い方を踏まえるとTypeScriptの動的に拡張しやすいという点もとても魅力的なのですが、文字列操作が主な内容だと最速を目指すのは難しいと予想されるため、今回は選択肢に入れませんでした。

rust-mtml-parser

実は Rust にした理由はもう一つありまして、MTMLのパースは以前（今見たら3年前でした）書いた GitHub - usualoma/rust-mtml-parser というものを作っていて、これを使うと MTMLからASTを生成できるので、これを使いたいというのがありました。

上でも触れましたが、RustからはWebAssemblyを経由してnpmに変換する手段が用意されており、このパッケージもnpmのパッケージとして利用できるようにしています。以下は、npmパッケージを使ったパースと、パース結果のシリアライズ（整形）の実行例です。

rust-mtml-builder

今回実装したのは、そのパーサーを使ってパースした結果から、MTタグを評価して静的ファイルに書き出す部分です。以下がリポジトリです。（一部の実装しか含まれていませんが、理由は後ほど説明します）

GitHub - usualoma/rust-mtml-builder

実装のポイント

作業のほとんどはそれぞれのMTタグを実装していくだけなので、そこに関しては特にポイントはありません。実装が進んで細かいチューニングの段階に入れば、書き込み時の文字列処理で低レベルな最適化が入ってくると思いますが、今回はそこまではやっていません。

再構築の（もしくはSSGのような機能一般での）処理のボトルネックは多くの場合「SQLの問い合わせ回数」と「ファイルの読み書きのIO待ち」なので、それらの点の解消が性能を向上させるためのポイントになります。

結果

今回作成したのはコマンドラインのツールなので、ウェブブウラウザからの実行と比較するのはフェアではないのですが、まあざっくりなのでよしとして、以下のような結果になりました。

2秒以内で完了するようになりました。realと比べてuserやsysが大きいところから、マルチスレッドが使えていることが分かります。（この環境では10コアを利用しています）

なんちゃっての実装もあるので、作り込めば処理が複雑化して重くなる部分もあると思われるものの、一方で最適化も行っていないので、（多数のコアが使える環境であれば）10倍程度の高速化は十分に達成できそうだなという感触を得ることができました。

ちなみに並列化しないと（1コアのみを利用）以下のような結果ですが、それでも5倍程度は達成できそうです。

なぜ一部の実装しか含まれていないか？

リポジトリにAGENT.mdが含まれていることが分かるように、例によって実装には生成AIを利用しています。

今回やってみて、（使ったのは GPT-5.2ですが、おそらくそれに限らず多くの）AIはMTタグの挙動をすでに良く知っているので互換性のある実装をさらっと進めることができ、特に面倒なMTタグの実装の部分では大きな力を発揮できることが分かりました。

しかしここで、MTの本体はかつてはGPL（MITやBSDではない）で公開されていた時代もあるものの、現在はソースは公開されているもののオープンソースのライセンスではないという状況があります。

AIによって生成されたコードが内容的に似ているかというと、似てはいないように見えました。MTタグの仕様は定義されているので、単純にそれを満たすように実装してもそのようなコードになると思われる内容ではあります。しかしそのようなものであったとしてもなお、「こんな内容がさっとできてこれを公開してもいいのか（あるいは、それがGPL時代のコードから学ばれたものだと仮定しても、それを翻案したものがMITなどで公開されてもいいのか）」という点から見て、公開して差し支えのないものという確信が持てなかったため、タグの実装の公開は控えることにしました。

自分が書ける以上の内容のコードが生成されること、内容を理解していないコードを公開すること、など、来年以降ますますそのような状況に直面することが多くなると思われますが、あらためて、なかなか考えさせらる機会となりました。

この記事について

この記事はMovable Type Advent Calendar 2025の25日目の記事です！

今年も11月にはMTDDC Meetup TOKYO 2025に参加ささせていただいて、直接いろいろな人と話ができて楽しかったです。（MT9のフィードバックをいただけるのはこれからだということが分かった）

そしてアドベントカレンダーでいつも通りの年末感で締めくくることができました。今年もお世話になりました。

それではみなさん良いお年をお迎えください！

（この記事はMT9を使って書かれています）

これは何か？

CMSの管理画面というのは基本的に無機質なものです。必須項目への入力を忘れれば「入力してください」と素っ気なく怒られ、頑張って記事を書いたとしても誰も褒めてくれません。SNSのメッセージ入力画面などはあれほど背中を押してくれるのに。

これはMovable Type 9に搭載された新しいリッチテキストエディタ（MTRichTextEditor）に、トフが編集を応援してくれる機能を追加して編集中の気持ちを少しでも上げようと試みるMovable Typeプラグインです。

GitHub - usualoma/mt-plugin-TophCheer

Contribute to usualoma/mt-plugin-TophCheer development by creating an account on GitHub.

github.com

追加される機能

• ステータスバーの領域でトフが跳ねて応援してくれます
• 行を追加するたびに文字数をカウントして応援してくれます
• 内容を踏まえてOpenAIのAPIを使ってメッセージを考えて応援してくれます

追加されない機能

• トフは応援するだけで、記事を書いてはくれません

設定

以下の項目を設定できます。

• Secret Key
• モデル
• システムプロンプト

実装の概要

MTRichTextEditor がインストールされている環境だと、ステータスバーに表示するアイテムのための MTRichTextEditor.Component.StatusbarItemElement をグローバルで参照できます。これは HTMLElementを継承しいているので、これをさらに継承したクラスを定義してカスタム要素として定義することで、ステータスバーに表示するアイテムを追加できます。

AIエージェントに任せたプラグインの作り方

MTRichTextEditor 開発者向けガイド と サンプルプラグイン があるので、それをエージェントに伝えてからコーディングを依頼すれば、それだけで割と動くものが出てきます。

この記事について

この記事はMovable Type Advent Calendar 2025の3日目の記事です！

トフについて

トフはシックス・アパートの公式キャラクターです。CC BY-NC-SA 4.0 の下でライセンスされており、オリジナルは シックス・アパートのウェブサイトで入手可能です。

これは何か？

カスタムブロックは非常に拡張性が高いのですが、「入力フォーム兼テンプレートとなるHTMLはブロックエディタで用意する」「挿入するカスタムスクリプトはHTML形式で、style要素やscript要素を混ぜたものになる」というところで、ローカル環境で開発がやややりにくいところがあったので、その問題を解決するべく開発ツールを作ってみました。

以前のものとの違い

カスタムブロックの開発ツールの用意は以前も試みたことがあり、そのときにはVSCodeの拡張機能として「MT Custom Block Editor」というものを作っていました。（記事はここです）これはVSCodeとの連携の試みとしては面白かったのですが、VSCodeに強く結びついてしまうため他のcliツールとの連携が逆に難しくなる面がありました。

そのような折、去年から今年にかけていくつか出したnpmをベースにしたツールが意外と興味をもってもらえたのもあり、こちらのアプローチに変えてみようと思い、以前のVSCode版とは違うものとして作りました。

こんな感じで動きます。

npm create @usualoma/mt-custom-block

このコマンドで雛形を作成できて、動画のサンプルのカスタムブロックも最初から入っています。

.jsonのファイル自体は、ゼロからつくるよりも一回MTで簡単な設定をしてから書き出すほうが楽だと思います。そこをベースにして、このツールでは主に以下のデータを更新できます。

• アイコン
• JavaScript または TypeScript
  • .tsというファイル名で保存すると勝手にトランスパイルします
  • script[type=module]で挿入されるので、DOMContentLoadedを明示的に書く必要はありません
• 入力フォーム兼テンプレートとなるHTML

上の2つはエディタから、一番下はブラウザから更新します。（ブラウザの保存ボタンでちゃんとファイルも更新されます）

デモ動画をみてもらうとなんとなく分かりますが、エディタでTypeScriptを変更して保存するとブラウザの方も自動でリロードされ、TypeScript（カスタムスクリプト）の実行結果をすぐに確認できます。カスタムブロックの作成で一番手間がかかるのがここだと思うので、ここですぐに反映されるのは嬉しいのではないでしょうか。

データとしては本来、カスタムスクリプトにはlink要素やstyle要素を書くこともできるのですが、そのあたりはJavaScriptで動的に対応できるので、このツールでは割り切ってJavaScriptのみで動かすようにしています。

注意事項

ビルドのプロセスを経ることで、意図せずにJavaScriptを大きくなってしまいがちである点には注意が必要です。大きくなるとCMSのシステム側への負荷も大きくなるのでご注意ください。script[type=module]で読み込まれるので、ブラウザ上でのimportも普通に使えるのでnpmのモジュールの読み込みはcdnからの直接の読み込みなどを利用するのがおすすめです。

この記事について

この記事はMovable Type Advent Calendar 2024の25日目の記事です！

今年はMTDDC Meetup TOKYO 2024にも参加ささせていただいて直接いろいろな人と話ができ、そしてこのアドベントカレンダーでいつも通りの年末感も味わうことができました。どちらも主催者であった西山さんをはじめ、関係者のみなさん、ありがとうございました。おつかれさました。

それではみなさん良いお年を！

これは何か？

Movable Typeの管理画面のfaviconを自分の好きな画像に差し替えるプラグインです。画像はウェブブラウザに保存されます。

mt-plugin-ShortcutIcon

対応ウェブブラウザ

• Google Chrome : 任意の画像を設定できます
• Firefox : SVGやPNGは設定できますが、JPEGは設定できません
• Safari : 設定されません

開発の動機

@usualoma/mt-plugin-builderを使って何ができるかをもう少し考えたくて、「ウェブブラウザだけでできること」というテーマで作りました。

仕組み

ユーザーが指定した画像をIndexedDBに保存して、ページ表示の切り替わりごとに読み出してURL.createObjectURLを使ってURLを生成して、link[rel="shortcut icon"] を作成してheadに挿入するという動作をしています。

誰のためのものか？

faviconを設定するだけなら画像のリソースもプラグインに含んでしまえばよく、そうすればユーザー毎に設定せずともインストールしたMT全体で差し替えることができます。

しかしここで、「制作会社のユーザー」と「クライアントのユーザー」で考えると、クライアントのユーザーは複数のサイトのMTを使うわけではないのでMTのデフォルトでよく（むしろそれが自然）、制作会社のユーザーは複数のサイトのMTを使うのでfaviconで「どのサイトのMTか？」を区別できるとよかったりすると思います。そのようなわけで意外と「ユーザーが自分の好きなfaviconを設定できる」という機能にも需要があるのではないかと思っています。

この記事について

この記事はMovable Type Advent Calendar 2024の12日目の記事です！

こんにちは。OSS珍百景として紹介されたPRの作者の天野です。

OSS観光名所 - honojs/hono 2022/2/20 #109@usualoma さんのIntroduce RegExpRouter

Honoの特徴である「速さ」を象徴するRegExpRouter(ルーティングをひとつの正規表現にして一発でマッチさせる)が導入された記念すべきもの。https://t.co/MLxqHB3MOg

— Yusuke Wada (@yusukebe) November 29, 2024

今年は以下のあたりを中心にHonoにコミットしました

• v3.12.0
• CSRF Protection Middleware
• css Helper
• v4.0.0
  • Client Components
• v4.5.0
  • Combine Middleware
  • React 19 Compatibility

この記事ではこれらの機能の実現に使った内部の機能に触れつつ、PolyglotなSVGを使ってHonoのJSXの表現力を試してみたいと思います。

できたもの

hono-polyglot-svgができました。以下のSVG画像ファイルはそのまま出力するとオリジナルのHonoのアイコン画像が表示されますが、HonoのJSXを経由すると、色を変えつつ自分自身を出力するQuineなSVG画像として出力されます。

• http://localhost:3000/static/hono.svg : そのまま出力
• http://localhost:3000/static/hono.svg?eval=1 : JSXで処理して出力

です。以下のような結果になります。

解説

コールバックから書き換える

HonoのJSXの文字列化では、要素の属性値や内容としてPromise<string | String>を返すことができ、useを使うことなしにasyncな関数コンポーネントから簡単に文字列の結果を出力することができます。さらにここでStringに対してisEscapedやcallbacksを指定することで、出力される際の挙動をコントロールすることができます。

この特殊なStringを作成するためには、通常は"hono/utils/html"からエクスポートされているraw()を使いますが、使わずに作成することもできます（内部の構造は今後変更される可能性もあるので、推奨はされませんが）。

callbacksに指定した関数が呼び出されるタイミングは、単純な文字列化以外にもrenderToReadableStream()を使ってレスポンスを返す前後のタイミングなど、いくつかあるのですが、ここでは深入りせず単純な文字列化を前提とします。以下のようにしてcallbacksに指定した関数で渡されたbufferの値を変更すると、出力結果を書き換えることができます。

これが今回の、処理するたびにSVG画像の色が変わる挙動の仕組みです。Honoに実装された機能の中では「css Helper」でのstyle要素の埋め込みや、「React 19 Compatibility」でのtitle要素のhoistingで使われています。

（無駄に）Combine Middlewareを使う

「同じパスのURL」でありながら「処理方法（クエリストリングで指定）によって結果が変わる」ということを表現したかったので、Combine Middlewareのsome()を無駄に使って宣言的に書いてみました。以下のように書くと「evalが指定されたときにのみevalSvgMiddlewareを適用する」という挙動になります。

今回の例だと無理矢理感がありますが、hono.devのドキュメントでは認証と組み合わせた実用的な例も紹介されています。

解説は以上になります。

今年の振り返り

さて今年といえばHonoにとってはHono Conference 2024 - Our first stepの開催が一番のイベントだったと思います。（参加レポート書いてなかったですが。）コミッターの方やコメントをしてくれる方の顔を見られて、どんな話し方をするのかを知ることができたのは嬉しかったです。議論が円滑に進むかどうかはまた別の話だとしても、「GitHubのコメントが当人の声で再生できるようになる」というのは、やはりよいものだと思いました。

この記事について

これは Hono Advent Calendar 2024 のシリーズ 1の6日目の記事です。シリーズ 2もあるようなので、引き続きよろしくお願いします！