Overtype完全ガイド｜~111KB Markdownエディタを Tiptap/Lexical 等8種と比較

リッチテキストエディタを採用したことのある開発者なら、ContentEditableに振り回された経験が一度はあるはずだ。カーソル位置がずれる、IMEで日本語入力が壊れる、モバイルでキーボードが意図せず閉じる、コピペで余計なHTMLが混じる——Quill・Tiptap・Lexicalまで世代を重ねても、根本の難しさは変わらない。Overtype（panphora/overtype） は2025年8月に公開され、2026年5月時点でGitHub Star 3,646・~111KB（minified）という軽量さで「textareaのまま見た目だけリッチにする」第3の解を示したMarkdownエディタだ。

UIライブラリ全体の選び方やデザインシステム化の考え方は デザインシステムとは？仕組み・構成要素・有名事例をエンジニア向けに整理する【2026年版】 で整理している。

この記事では、Overtypeの仕組みと使い方、そして代表的なリッチエディタ8種（Tiptap・Slate.js・ProseMirror・Lexical・Editor.js・Quill・CKEditor 5・TinyMCE）との機能・サイズ・用途比較を、公式リポジトリのREADMEと一次ソースだけを根拠に整理する。AIチャット欄・管理画面・社内ツールに「とりあえず軽くて壊れないMarkdown入力欄」を入れたい開発者向けの実装ガイドとしても使ってほしい。

1. Overtypeとは何か：textareaを”見せる”WYSIWYGの再発明

Overtypeは「Markdownエディタは結局textareaが一番」という割り切りから生まれた、JavaScript製のクライアントサイドエディタだ。作者はpanphora（David Miranda）氏で、2025年8月にHacker NewsとXで公開された。

公式READMEは自身を「A lightweight markdown editor library with perfect WYSIWYG alignment using an invisible textarea overlay technique」と説明している。日本語にすると「透明なtextareaオーバーレイで完璧なWYSIWYG整列を実現する軽量Markdownエディタ」だ。

仕組みは思い切り単純で、装飾済みのプレビュー要素の真上に、文字色を完全透明にした<textarea>をピクセル単位で重ねるだけ。ユーザーがタイプしているのは終始ネイティブのtextareaで、画面に見えているのはその下の装飾済みプレビューという構成になる。

検証環境: Node.js 20 LTS / 任意のフロントエンド構成（React 19・Vue 3・vanilla JS で動作確認）/ Overtype main ブランチ（最終更新 2026-05-03）/ 確認日 2026-05-08。npm install overtype 単発で導入でき、ビルドステップは不要。

Overtypeの公式機能リスト

公式READMEの “Features” 節に並ぶのは以下の10項目だ。

• Invisible textarea overlay：透明な入力レイヤーを装飾済みプレビューに重ねるシームレス編集。
• Global theming：Solar（ライト）・Cave（ダーク）の2テーマがすべてのインスタンスに一括適用。
• Keyboard shortcuts：Cmd/Ctrl+B で太字など、Markdownの定番ショートカットを内蔵。
• Mobile optimized：モバイル専用のレスポンシブ調整を最初から組み込み。
• DOM persistence aware：既存DOMから状態を復元できる（HyperClay等のサーバ復元と相性が良い）。
• Lightweight：~111KB minified（全機能込み）。
• Optional toolbar：書式設定をカバーする最小限のツールバー。
• Smart shortcuts：選択範囲を保ったままトグル可能。
• Smart list continuation：GitHub風の自動リスト継続。
• Framework agnostic：React・Vue・vanilla JS・その他で動作。

ContentEditable系エディタが「カスタム書式とリッチなノード」に賭けたのに対し、Overtypeは「Markdown構文を見えるまま装飾し、入力体験はブラウザ任せにする」方向に賭けた。この思い切りが、~111KBという他に類を見ない軽さに直結している。

2. なぜ「textareaのまま」にこだわるのか：ContentEditable地獄からの脱出

Overtypeの設計を理解するには、ContentEditableが何を犠牲にしてきたかを押さえる必要がある。結論から言うと、ContentEditableは「自由にHTMLを編集できる」見返りに、ブラウザごとの実装差異・IME・選択範囲の扱いをエディタ側で全部背負う前提になっている。

ContentEditable方式の伝統的な課題

QuillもTiptapもLexicalも、内部ではcontenteditable="true"なDIVをイベントごとに監視し、入力をパースして仮想DOMを作り直す構造を持つ。この方式には次の難しさが付きまとう。

• IME衝突：日本語・中国語・韓国語の入力中に、エディタ側がDOM操作を挟むと変換が壊れる。各エディタで compositionstart/compositionend を握って回避するが、エッジケースが残り続ける。
• モバイル仮想キーボード：iOS Safari・Android Chromeでフォーカス挙動・自動補完・スワイプ入力に細かいバグが発生し、リリースのたびに対応が必要。
• コピペの不確実性：MS Word・Notion・他サイトからの貼り付けで予想外のHTMLが入り、サニタイズ処理を書く羽目になる。
• アクセシビリティ：スクリーンリーダーの読み上げ位置とDOMの不整合が起きやすく、ARIA属性で補完が必要。

これらをすべてエディタ側で吸収しようとすると、結果としてバンドルが膨れ上がり、結局「公式の貢献者しかメンテできないコード」になる。

Overtypeの解：入力はネイティブ、装飾は別レイヤー

Overtypeはこの構造を反転させ、入力はOSとブラウザが提供する素のtextareaに任せ、表示だけ別のDIVに描画する設計を採った。textareaは色・キャレット・選択ハイライトを完全透明化したうえで、装飾済みのプレビューDIVと完全にピクセル整列させて重ねる。

公式READMEの Comparisons 節でも「Mobile: Perfect native」を売りに据えている。HyperMD・Milkdown・TUI Editor・EasyMDEはいずれも「Mobile: Issues common」と公式比較表で評されているのと対照的だ。

3. 3行で動くMarkdownエディタ：インストールと最小実装

Overtypeは npm 1コマンドで導入でき、初期化も実質3行で済む。READMEの Quick Start に沿った最小実装はこうなる。

npm install overtype

import OverType from 'overtype';

const [editor] = new OverType('#editor', {
  value: '# Hello World\n\nここに**Markdown**を書く。',
  theme: 'solar',
});

editor.getValue();           // 現在のMarkdown文字列を取得
editor.setValue('# 新しい');  // 値を上書き
editor.setTheme('cave');     // ダークテーマに切替

new OverType() は配列を返す。これは「セレクタが複数要素にマッチした場合、各要素にエディタを生成して配列で返す」設計だからだ。先頭を分割代入で受ければ、単一エディタとして扱える。

data属性で複数エディタを一括初期化する

サーバ側で生成したHTMLにエディタを埋め込みたい場合、OverType.initFromData() がHTML data属性から設定を読み取って初期化する。Jinja・Rails・Laravelのテンプレート出力にそのまま流せる。

<div class="editor" data-ot-toolbar="true" data-ot-theme="cave"></div>
<div class="editor" data-ot-auto-resize="true" data-ot-min-height="200px"></div>
<div class="editor" data-ot-show-stats="true" data-ot-placeholder="ここに書く"></div>

<script type="module">
  import OverType from 'overtype';
  OverType.initFromData('.editor', { fontSize: '14px' });
</script>

サポートされる属性は toolbar / theme / value / placeholder / autofocus / auto-resize / min-height / max-height / font-size / line-height / show-stats / smart-lists / show-active-line-raw の13種。kebab-caseで書いた属性が自動的にcamelCaseのオプションへ変換される（data-ot-show-stats → showStats）。

イベントとの統合

Overtypeはイベントコールバックを通常のオプションとして受け取る。フォーム送信前に値を引き取りたい・ストアに同期したい場合は次のように書ける。

const [editor] = new OverType('#post-body', {
  value: initialMarkdown,
  toolbar: true,
  showStats: true,
  onChange: (markdown) => {
    store.commit('setBody', markdown);
  },
  onKeydown: (event, instance) => {
    if (event.key === 'Enter' && (event.metaKey || event.ctrlKey)) {
      event.preventDefault();
      submitForm(instance.getValue());
    }
  },
});

onChange はすべてのキー入力後に呼ばれ、引数はその時点のMarkdown文字列だ。Reactで使うときも、stateと双方向に同期する関数をここに渡すだけで済む。

4. 主要API・カスタムツールバー・テーマシステム

OvertypeのAPIは「インスタンスメソッド」「静的メソッド」「DOMモード切替」の3層に分かれる。よく使うのは次の8つだ。

モード切替：edit / raw / preview

Overtypeは1つのエディタインスタンスで3つの表示モードをトグルできる。

• edit（既定）：透明textareaが上に乗ったWYSIWYG編集モード。
• raw：プレビューを外し、生のMarkdownだけを表示する素のtextareaモード。
• preview：textareaを外し、装飾済みHTMLだけを読み取り専用で表示するレンダリングモード。

ブログ記事の「編集 / プレビュー」切替や、AIチャットの「ユーザー入力中はedit、送信後はpreview」のような使い分けに合わせやすい。

カスタムツールバーボタン（v2）

v2系で toolbarButtons オプションが追加され、組み込みボタンの並び替えと独自ボタンの追加が可能になった。

const [editor] = new OverType('#editor', {
  toolbar: true,
  toolbarButtons: [
    'bold', 'italic', 'code',
    {
      name: 'ai-rewrite',
      icon: '✨',
      title: 'AIで書き直し',
      action: async (instance) => {
        const text = instance.getValue();
        const rewritten = await callLLM(text);
        instance.setValue(rewritten);
      },
    },
  ],
});

action には任意の関数を渡せるので、LLM呼び出し・自動翻訳・スニペット挿入をボタン1つに紐づけられる。

テーマ：Solar と Cave

組み込みテーマは solar（ライト）と cave（ダーク）の2つだけ。OverType.setGlobalTheme('cave') で全エディタを一括切替できる。CSS変数で色を上書きすればカスタムテーマも作れるが、ロジック部分は共通のままだ。

5. Overtype vs リッチエディタ8種：機能とサイズの一括比較

ここで本題の比較表に入る。同じ「リッチテキストエディタ」と呼ばれていても、Overtype・Tiptap・Lexicalは設計の前提が根本から違う。先に結論だけ書くと、Overtypeは「Markdown構文を見せたまま装飾」、Tiptap/Lexical/Slate/ProseMirrorは「ContentEditableで構造化文書を編集」、Editor.jsは「ブロック単位のJSON出力」、Quill/CKEditor/TinyMCEは「伝統的WYSIWYG」というカテゴリ分けになる。

スター数・ライセンス・アプローチの比較表

GitHub Star・ライセンス・コアアーキテクチャ・最終更新の比較は次のとおり（2026-05-08時点、各リポジトリのGitHub APIから取得）。

バンドルサイズ・依存・モバイル挙動の比較表

サイズはOvertype公式比較表とPkgPulse・各公式ドキュメントの実測値を統合した。

Lexicalの「コア22KB」は確かに最軽量だが、実プロダクトで使うHistoryPlugin・RichTextPlugin・MarkdownPluginを足すと100KB台に乗ってくる。Overtypeは最初から「全部入り」で111KBなので、実装時の見積もりがブレない。

コラボ編集・拡張性・スキーマカスタマイズの比較表

「Notion風」「Google Docs風」を目指すと、ここが最大の分岐点になる。

Overtypeはコラボ編集を内蔵しないが、保存単位がMarkdownテキストなので、yjsやfirepad等の汎用文字列CRDTを後から被せれば共同編集化はそれほど難しくない。一方、Tiptap/Lexical/ProseMirrorは内部表現がツリー構造なので、専用バインディングが必須になる。

6. アーキテクチャ図解：透明テキストエリアが整列する仕組み

Overtypeの設計を絵で押さえておく。コンポーネントは大きく3層しかない。

ポイントは2つある。1つ目は textareaとプレビューDIVのフォント・行送り・パディングを完全に揃えること。Overtypeは内部CSSで両者のfont-family font-size line-height padding letter-spacing を強制的に同一にしており、ユーザーが文字を打った位置に装飾済み文字が重なる。

2つ目は 入力イベントから装飾の更新までを同期パースで完結させること。仮想DOMやReact再レンダリングを挟むと1フレーム分ずれてキャレットがちらつくため、Overtypeは素のDOM操作だけで装飾DIVを更新する。これが依存ゼロ・~111KBに収まる理由でもある。

スクロール同期と高さの同期

textareaとプレビューDIVは別要素なので、内部スクロールと高さも同期させる必要がある。Overtypeはscrollイベントで両者のscrollTopを一致させ、auto-resizeオプションが有効なら入力に応じて両方のheightを再計算する。ここの細かさが「ピクセル整列」の体感品質を決めている。

7. ユースケース別の選び方：Overtypeが正解になる場面

「結局どれを選ぶか」は用途で割り切れる。迷ったら下のフローで判断すれば外れない。

Overtypeを選ぶべき場面

• AIチャットの入力欄（ChatGPT風UI）でMarkdownを許したいが、モバイルでも壊れたくない。
• 管理画面・社内ツールのコメント欄・記事入力欄で、依存を増やしたくない。
• staticサイトジェネレータのプレビューエディタ（HyperClay等）で、サーバ側もMarkdownのまま保存する。
• READMEドラフト・個人ブログ・Issueテンプレ入力など、Markdown構文をそのまま見せたほうが分かりやすい場面。

Tiptap・Lexicalを選ぶべき場面

• Notion風のスラッシュコマンド・メンション・カスタムブロックを自前で組みたい。
• リアルタイムコラボ編集（Yjsとの統合）が要件にある。
• AIエージェントから操作されるエディタを作りたい（CopilotKit完全ガイド｜React/Angularで作るAIエージェント & AG-UI Protocol解説 でCopilotKitのuseAgentと組み合わせる事例を扱った）。
• React/Vue以外の独自フレームワーク・SSR・モバイルアプリ（React Native）まで対応させたい。

Slate.js・ProseMirrorを選ぶべき場面

• Google Docs・Dropbox Paper級のカスタム文書モデルを作る。
• ネスト構造・テーブル・脚注・コメントなどスキーマ駆動の高度な編集を要件に持つ。
• 学習コストを支払える専任チームがいる。

Quill・CKEditor 5・TinyMCEを選ぶべき場面

• レガシーCMS・社内グループウェアからの置き換えで、Wordライクな振る舞いが必須。
• エンタープライズ要件（SLA・サポート契約・WCAG厳密準拠）がある。
• HTMLそのまま保存したい。

＜悪い例＞ 「軽量でモダン」という曖昧な理由でTiptapを選び、ProseMirrorのスキーマ・コラボ・拡張をフル理解しないまま、結局Overtype程度の機能しか使わずバンドルだけ200KB増やす。

＜改善例＞ 「Markdownを保存・モバイル動作・依存ゼロ」が要件ならまずOvertype。途中でテーブル・コラボ・スラッシュコマンドが要件に入った時点でTiptap/Lexicalへ移行する。

8. 実装パターン：React・Vue・vanillaの組み込みと注意点

Overtypeはフレームワーク非依存なので、React/Vueでは「useEffect または onMounted でnew OverType()を1回呼ぶ」だけで動く。フレームワークの再レンダリングと干渉させないための定石がいくつかある。

Reactでの組み込みパターン

import { useEffect, useRef } from 'react';
import OverType from 'overtype';

export function MarkdownField({ value, onChange, theme = 'solar' }) {
  const containerRef = useRef(null);
  const editorRef = useRef(null);

  useEffect(() => {
    if (!containerRef.current) return;
    const [editor] = new OverType(containerRef.current, {
      value,
      theme,
      toolbar: true,
      onChange: (md) => onChange(md),
    });
    editorRef.current = editor;
    return () => editor.destroy?.();
  }, []); // 初回だけ生成

  // 親state更新を反映（ローカル編集中は無視するためフラグ管理を推奨）
  useEffect(() => {
    if (editorRef.current && editorRef.current.getValue() !== value) {
      editorRef.current.setValue(value);
    }
  }, [value]);

  return <div ref={containerRef} style= />;
}

Reactでハマりやすいのは「親stateとエディタ内容の双方向同期」。毎レンダリングでsetValueを呼ぶとキャレットが先頭に飛ぶため、上のように getValue() !== value のときだけ反映するか、isLocalEdit フラグで親更新の上書きを抑止する。

Vueでの組み込みパターン

Vue 3 Composition APIでは onMounted と watch の組み合わせで同等の制御ができる。v-modelを擬似的に実装するなら次のような形になる。

import { onMounted, ref, watch } from 'vue';
import OverType from 'overtype';

export default {
  props: ['modelValue'],
  emits: ['update:modelValue'],
  setup(props, { emit }) {
    const root = ref(null);
    let editor = null;

    onMounted(() => {
      [editor] = new OverType(root.value, {
        value: props.modelValue,
        toolbar: true,
        onChange: (md) => emit('update:modelValue', md),
      });
    });

    watch(() => props.modelValue, (next) => {
      if (editor && editor.getValue() !== next) editor.setValue(next);
    });

    return { root };
  },
  template: '<div ref="root" style="min-height:200px"></div>',
};

よくある落とし穴と回避策

destroy() メソッドが提供されているので、SPAでアンマウント時に必ず呼んでDOMをクリーンアップする。コンポーネントが複数回マウント・アンマウントされる画面では、これを忘れるとイベントリスナーがリークする。

AIチャット入力欄での実例：vibe codingとの相性

LLMから返ってきたMarkdownを編集して再送するワークフローは、Overtypeのスイートスポットに近い。「ユーザーが書いたMarkdown」と「AIが返したMarkdown」を同じ表示で扱えるのは、内部表現が文字列のまま完結しているからだ。AIエージェント側のフロントエンド統合は CopilotKit完全ガイド（前出）の useAgent と組み合わせるのが定石になる。

実装としては、onChangeでユーザー入力をストアに同期しつつ、AI応答が返ってきたらsetValueで上書きする。3モード切替を使えば、編集中はedit、AI生成中はpreviewに切り替えて編集を抑止する、といった制御も書ける。

9. まとめ：軽量Markdownエディタという第3の選択肢

Overtypeを評価するうえで重要なのは、「これはTiptap・Lexicalの代替ではない」という前提を共有することだ。Overtypeは、リッチテキスト編集をやめてMarkdown編集に戻す代わりに、~111KB・依存ゼロ・モバイル完璧という対価を得た。だからこそ、AIチャット欄・管理画面・社内ツール・ブログ管理・READMEプレビューといった「Markdownで十分な領域」に対しては、現状もっとも筋の良い選択肢になる。

逆に、Notion風WYSIWYG・コラボ編集・カスタムスキーマが要件に入った瞬間にOvertypeはマッチしない。そのときはTiptap/Lexicalに切り替える判断が必要で、その境目を最初の設計で見極めることが、後の総工数を一番圧縮する。

参照ソース

• panphora/overtype（GitHub Repository） — README・Comparisons節・Quick Start・Data Attribute Configuration
• OverType公式サイト（overtype.dev） — Live Examples・モード切替・テーマ
• overtype - npm — 配布パッケージ・最新バージョン
• Show HN: OverType – A Markdown WYSIWYG editor that’s just a textarea — 初期公開時の議論
• Tiptap公式リポジトリ（ueberdosis/tiptap） — Star数・拡張一覧・ProseMirror依存
• Lexical公式リポジトリ（facebook/lexical） — Features・コアサイズ・Yjs統合
• Slate.js公式リポジトリ（ianstormtaylor/slate） — 設計思想・スキーマレス
• ProseMirror公式リポジトリ（ProseMirror/prosemirror） — モジュール構成・ContentEditable