機能価格ドキュメントブログ
moteを入手
← ブログ
デザイン·2026年6月16日·読了まで6分

Markdownエディターをもう1つ作った理由

Markdownエディタはすでにたくさんあるのに、なぜもう一つ作るのでしょうか。機能が足りないからではなく、開いているときの軽さと、保存が残す痕跡と、指先の感触が、一つの製品の中で同時に噛み合ったことがなかったからです。

m
mote
ライブモードで開いたリリースノート。Markdown記号は隠れていて、キャレットが置かれた見出し行でだけ記号が薄く現れます。
ライブモードで開いたリリースノート。Markdown記号は隠れていて、キャレットが置かれた見出し行でだけ記号が薄く現れます。

Markdownエディタを選ぶたびに、一つずつ諦めなければなりませんでした。

インライン編集が快適なアプリは、保存するときにファイルを書き換えました。ファイルをそのまま保つアプリは、編集体験に物足りなさがありました。ノート機能が豊富なアプリは、文書を一つ開くだけでも重かったです。

結局、エディタを二つずつ開いていました。

そこでmoteを作り始めました。三つすべてを守るエディタです。

  • Markdown記号を隠して直接編集できること
  • 自分が書いたファイルをそのまま保存すること
  • Webエンジンなしで軽快に動作すること

それぞれを実現する製品はすでにたくさんあります。しかし、三つを同時に満たす製品は見つけられませんでした。

軽さは数字で語ります

インライン編集に対応するMarkdownエディタの多くは、WebKitGTKやChromiumのようなWebエンジンを使用しています。MarkdownをHTMLに変換してブラウザに描画する方式です。

実装は簡単になりますが、コストが生じます。文書の隣にブラウザが一つ一緒に立ち上がっているようなものだからです。プロセスとメモリが増え、キー入力も複数の段階を経ます。

ところが、このコストを公開している製品はほとんどありません。製品ページにはアイドル時のCPU使用率やキー入力の遅延ではなく、「軽い」という言葉だけが残っています。

moteは違います。

アイドル時のCPU使用率、メモリ、キー入力の遅延、起動時間を、同じコンピューターで同じ方法を使って測定します。測定用のスクリプトと生データもリポジトリにあります。定めたパフォーマンス予算を超えたビルドはリリースしません。

比較するときも、同じ時点で測定した値だけを使用します。測定できなかった値を0とはせず、測定できなかったと表示します。

軽さは感覚ではなく、測定値であるべきだからです。

保存するときにファイルを直しません

gitで文書を管理していると、妙なdiffに出会うことがあります。

表のセルを一つ直しただけなのに、次のコミットには変更していない行まで大量に入っています。エディタが保存時に、表の空白や配置を整え直したからです。自分が直した一行と、エディタが直した二十行が混ざるのです。

すべての内容が変わるわけではありません。改行や連続する空白をきちんと保持するエディタもあります。主に表と配置で違いが生じます。ファイルをそのまま保存する機能も、moteだけのものではありません。

それでも、必ず守るべき条件だと考えました。

moteではテキストが基準です。ファイルのバイトをそのままバッファに格納し、太字の文字や表、数式はその上に描画します。保存するときは、バッファをそのままディスクに書き込みます。

画面は見やすく変わっても、ファイルがひそかに変わることはありません。

表のセルを一つ「review」から「approval」に直して保存した後のgit diff — 変更された行はそのセルと最後の段落だけで、パイプの配置もアスタリスクの箇条書きもそのままです。ステータス行には+8 −6 Bと表示されています。
表のセルを一つ「review」から「approval」に直して保存した後のgit diff — 変更された行はそのセルと最後の段落だけで、パイプの配置もアスタリスクの箇条書きもそのままです。ステータス行には+8 −6 Bと表示されています。

韓国語入力からきちんと作ります

Webベースのエディタが持つ微妙な不便さは、指先で感じられます。スクロールやぼかし、動きが似ているように見えても、OSの標準アプリとは少しずつ違います。

韓国語を入力するときは、その違いがさらに大きくなります。

変換中の文字が分かれたり、カーソルが飛んだり、行末で入力が抜けたりすることがあります。Webエディタが韓国語の文字入力イベントを処理する過程で現れる問題です。

moteでは、文字とエフェクトをOSが直接描画するようにしました。韓国語の文字入力もプラットフォームの入力メソッドから直接受け取ります。その代わり、OSごとに入力方式を個別に実装し、実機で確認しなければなりません。現在はLinuxに対応しており、macOSとWindowsは開発中です。

より難しい道ですが、長い文章を書く人にとって、この違いは重要です。

韓国語の文書をライブモードで開いた画面 — キャレットが置かれた見出し行でだけ先頭の#が薄く現れ、上部の太字・斜体・インラインコードは記号なしで描画されています。
韓国語の文書をライブモードで開いた画面 — キャレットが置かれた見出し行でだけ先頭の#が薄く現れ、上部の太字・斜体・インラインコードは記号なしで描画されています。

moteを必要とする人は多くないかもしれません。

gitでREADMEや設計文書を管理する開発者。韓国語で長い文章を書く人。ノートパソコンで一日中エディタを起動している人。

しかし、彼らがエディタを離れる理由は明確です。

散らかったdiff。途切れる韓国語入力。回り続けるファン。

やらないことも決めました

moteには同期、プラグイン、バックリンク、AI、コラボレーション機能がありません。

独自の同期機能は作りません。アカウントもサーバーも設けません。文書フォルダには、別途設定ファイルさえ作りません。Markdownで表現できない状態を必要とする機能は入れませんでした。

そのため、フォルダには.mdファイルだけが残ります。iCloudやSyncthing、gitは、moteの存在を知らなくてもそのまま動作します。

プラグインAPIも公開しません。プラグインがタイマーを一つ実行するだけでも、パフォーマンスの約束が崩れる可能性があるからです。その代わり、テーマとスニペット、エクスポート用テンプレートは開放します。編集中のパフォーマンスに影響を与えることなく、成果物の見た目を変えられます。

バックリンクとグラフビューも作りません。ノートデータベースと競争するための製品ではないからです。フォルダツリーと標準的な相対リンクまでをサポートします。

AIも入れません。要約も続きを書くこともせず、文書フォルダを読み取って外部へ送ることもありません。エディタが自分の文書をどこにも送らないことも、重要な機能だと考えています。

リアルタイムコラボレーションにも対応しません。共同編集を実現するには、サーバー上の文書モデルを基準にしなければなりません。そうすると、ディスク上のファイルをそのまま守るという原則と衝突します。

二つのうち、moteはファイルを選びました。

Obsidianのエコシステムが必要なら、Obsidianのほうが適しています。Typoraの長年にわたる安定性が重要なら、Typoraが合っています。iA Writerのタイポグラフィも、まだ私たちが追いつくべき目標です。

moteは、すべてのMarkdownエディタに取って代わろうとしているわけではありません。

Markdownエディタがもう一つ必要だったわけでもありません。

ファイルとノートパソコンの両方を尊重するエディタが、一つ必要だったのです。

次の記事 →重さの原因はMarkdownではなくWebエンジンだった
RSSで更新を追えます。
書くことだけを残す
日本語
© 2026 mote