オフライン英文法チェッカーHarperとLanguageToolの違い

英文ドキュメントの校正をチームで恒常運用したいが、既存のクラウド型ツールは「機密情報をどこまで外部送信してよいか」の判断が難しく、LanguageTool のセルフホスト運用は数 GB 単位のメモリ要件がブロッカーになりがちです。かといって Grammarly の課金モデルは組織全体の導入判断を鈍らせます。

こうした背景から、オフラインで動作し、Rust の低フットプリントで IDE に常駐させられる英文法チェッカーとして注目を集めているのが Automattic 社の Harper です。

しかし GitHub 上には LanguageTool・Vale・textlint・ltex-ls など類似の OSS が並んでおり、初見で「Harper を採用すべきか」を判断する材料が散らばっているのが実情です。

本記事では、Harper のリポジトリメタデータ（スター数・ライセンス・最終更新）と公式ドキュメント（README・公式サイト・COMPARISON.md）に絞って一次情報を整理し、以下の 3 点を短時間で判断できるようにまとめます。

• Harper の仕組みと主要コンポーネントの役割分担
• LanguageTool・Grammarly と比較したときの棲み分け
• 自プロジェクトの言語・エディタ・要件に対して Harper が向くかどうか

なお本記事はドキュメントベースの調査記事です。執筆時点で Harper のインストール・実行・スクリーンショット取得は行っておらず、記載する内容はすべて公式ソースからの引用と整理に基づきます。

Harperとは何か｜Automattic製のオフライン英文法チェッカーOSS

Harper は Automattic（WordPress.com / Tumblr / WooCommerce 等の運営元）が GitHub 上で公開している英文法チェッカー OSS です。リポジトリ本体は Automattic/harper にあり、Offline, privacy-first grammar checker. Fast, open-source, Rust-powered というタグラインが掲げられています（出典: gh api /repos/Automattic/harper）。

執筆時点のリポジトリメタデータは次のとおりです（出典: gh api /repos/Automattic/harper の取得値）。

archived=false かつ fork=false であり、最終更新も 2026 年 8 月と直近です。スター数 1 万件超のアクティブなアップストリームリポジトリという位置づけになります。ライセンスは Apache-2.0 で、商用利用・改変・再配布・特許ライセンスまでカバーされます。

Harper の開発動機は、README（Automattic/harper README）にストレートに記されています。要点は次の 2 つです。

• Grammarly の「高価・強引・プライバシー問題」への不満
• LanguageTool の「重量級リソース要件」（数 GB RAM、~16GB の n-gram データセット）への不満

これに対して Harper は次を主張しています（出典: Automattic/harper README）。

• ドキュメントの lint は milliseconds で完了する
• LanguageTool のメモリフットプリントの 1/50 未満
• completely private（クラウド送信なし）
• WebAssembly でロード可能なほど軽量

またプロジェクトの姿勢として「long lint times [are considered] bugs」（長い lint 時間はバグとして扱う）というスタンスが README に明記されており、パフォーマンスは仕様の一部として扱われています。

対応言語は執筆時点で英語のみですが、core は他言語対応の拡張余地を持つ設計とされています。方言としては British / American / Canadian / Australian / Indian English がサポート対象として公式サイトに列挙されています（出典: Harper 公式サイト）。

Harperの仕組みと主要コンポーネント

Harper のリポジトリは、Rust 製のコアとその周辺コンポーネントから構成されるモノレポです。全体像は公式サイト writewithharper.com で確認できます。ここでは README・公式ドキュメントに登場する主要コンポーネントを 3 つに分けて整理します。

harper-core（Rust クレート）

harper-core は文法・スペルチェックのロジックを担う中核の Rust クレートです。Harper 全体の linting エンジンとして機能し、後述する harper-ls および harper.js は、いずれもこの core を土台として利用しています。

core は Rust 実装であることに加えて WebAssembly ビルドにも対応しており、これが harper.js によるブラウザ / Node.js 環境での実行を可能にしています（出典: harper.js Introduction）。

harper-ls（Language Server Protocol 実装）

harper-ls は Harper の Language Server Protocol（LSP）フロントエンドです。公式ドキュメントでは以下のように説明されています。

the Language Server Protocol frontend for Harper. Out of the box, it has built-in support for parsing the comments of most programming languages, as well as any and all Markdown files.

（出典: harper-ls | Harper Docs）

LSP 対応の IDE（Neovim / Helix / Emacs / Zed / VS Code / Sublime Text / Obsidian 等）から接続することで、Markdown ファイルや各種プログラミング言語のコメント部分を対象に、リアルタイムに英文校正の診断を受け取れます。

harper.js（WebAssembly + npm パッケージ）

harper.js は Web / Node.js アプリケーションに英文校正機能を組み込むための JavaScript / TypeScript ライブラリです。Harper core の WebAssembly ビルドを内包しており、CDN からブラウザに読み込む形と、npm 経由でパッケージとして導入する形の両方が提供されています。

公式ドキュメントでは以下の 3 種類の API が提示されています（出典: harper.js Introduction）。

• Linting
• Spans
• Rule Configuration

利用例として、Obsidian プラグインおよび Harper 公式サイト自身の実装基盤として使われている旨が同ドキュメントに記載されています。

なお同ページには harper.js が early access であり API が未安定である旨が明記されています。プロダクション組み込みを検討する際は、この点を意思決定材料に含める必要があります。

LanguageTool・Grammarlyとの違い｜公式比較表で読み解く選定軸

Harper 自身が COMPARISON.md で LanguageTool / Grammarly / hunspell との比較表を公開しています。以下は同ドキュメントからの引用（抜粋・要約整形）です。

（出典: Automattic/harper COMPARISON.md）

多言語対応（Multi-Lingual / Multi-Dialect）については、同じ COMPARISON.md の表で以下のように整理されています（出典: 同上）。

• Harper: 非対応（❌）。対応言語は英語のみ
• Grammarly: 非対応（❌）
• LanguageTool: 複数言語には対応するが、同時にはサポートしない（🟨 Not simultaneously）
• hunspell: 複数言語には対応するが、同時にはサポートしない（🟨 Not simultaneously）

多言語同時対応を要件とするユースケースは、この表からはいずれのツールでも直接カバーされないことがわかります。多言語ドキュメントを扱う場合は、言語ごとに設定を切り替えて運用する前提での比較になります。

この比較表から読み取れる選定軸は次の 3 点です。

1. 応答時間: 10ms（Harper）／ 650ms（LanguageTool）／ 4000ms（Grammarly）というオーダーの差があります。IDE 常駐でタイピングと並行して診断を受け取るユースケースでは、Harper の応答時間が有利に働きます。

2. ライセンス: Harper は Apache-2.0、LanguageTool は LGPL-2.1、hunspell は LGPL / GPL / MPL、Grammarly は Proprietary です。組織のライセンス方針に応じた選定が可能です。

3. リソースフットプリント: README では「less than 1/50th of LanguageTool's memory footprint」と主張されています（出典: Automattic/harper README）。LanguageTool のセルフホストで数 GB 単位の RAM を要していたケースでは、常駐運用のインフラコストに直接効いてきます。

プライバシー観点では、公式サイトに「Every check happens locally. No cloud round-trips, no telemetry, no LLM in the loop」と明記されています（出典: Harper 公式サイト）。クラウド送信・テレメトリ・LLM 関与がいずれも「なし」と宣言されている点は、Grammarly を機密ドキュメントに使えない環境における明確な差分になります。

対応エディタと導入方法

Harper の README および公式ドキュメントで対応が明示されているエディタは次のとおりです（出典: Automattic/harper README、harper-ls | Harper Docs）。

• Visual Studio Code
• Neovim
• Helix
• Emacs
• Zed
• Obsidian
• Sublime Text

導入経路は「IDE 側から Harper を使う」ケースと「Web / Electron アプリに組み込む」ケースで大きく分かれます。前者は harper-ls、後者は harper.js を使います。以下、公式ドキュメントに沿って両者の入り口を整理します。

harper-lsの導入（IDE側からHarperを使う）

harper-ls は複数のパッケージマネージャからインストールできます。公式ドキュメント（harper-ls | Harper Docs）に列挙されているインストール手段は次のとおりです（コマンドはドキュメントからの抜粋）。

# Windows (Scoop)
scoop install harper

# macOS / Linux (Homebrew)
brew install harper

# Arch Linux
sudo pacman -S harper
paru -S harper-git

# NixOS
nix-shell -p harper

# Termux
apt install harper

# Cargo
cargo install harper-ls --locked

（出典: harper-ls | Harper Docs）

上記に加えて GitHub Releases でプリビルドバイナリも配布されています。パッケージマネージャが使えない環境ではリリースアセットの直接取得が選択肢となります。

harper-ls が解析対象とする言語は、Markdown / HTML / LaTeX / Org Mode / AsciiDoc / Python / JavaScript / TypeScript / Rust / Go / Java / C++ / C# / Shell / Bash / PowerShell / Ruby / PHP / Kotlin / Swift 等、幅広くカバーされます（出典: 同上）。プログラミング言語についてはコメント部分が主な解析対象です。

辞書管理は user / file-local / static の 3 種類が提供されており、プロジェクト固有の固有名詞やチーム独自の用語を差分管理できる設計になっています（出典: 同上）。

harper.jsの導入（Web/Electronアプリに組み込む）

Web アプリや Electron アプリケーションに英文校正機能を組み込む場合は harper.js を使います。導入は CDN 経由（ブラウザ）と npm 経由の 2 系統です。公式ドキュメント（harper.js Introduction）で紹介されている npm 導入コマンドは次のとおりです。

npm install --save harper.js

（出典: harper.js Introduction）

harper.js は Harper core の WebAssembly ビルドを内包しているため、ブラウザ環境でも追加のバックエンドサーバなしで文法チェックを実行できます。前述のとおり本パッケージは early access であり API は未安定と公式に明記されているため、プロダクション導入時にはバージョン固定・変更追従の運用計画を合わせて設計する必要があります。

類似OSSとの比較｜Vale・textlint・ltex-lsとの棲み分け

LanguageTool / Grammarly 以外にも、英文・散文校正の領域には複数の OSS が並んでいます。Harper と役割が近い OSS を 4 件挙げ、差分を整理します（スター数・言語・ライセンス・概要は各リポジトリの gh api レスポンスに基づく）。

差分を Harper との比較で整理すると次のようになります。

• vs LanguageTool: 25+ 言語対応・広範なルールセット（Custom + N-Gram + LLM）を要件とする場合は LanguageTool 側に優位。Harper は英語のみだが、10ms オーダーの応答と 1/50 未満のメモリフットプリントで IDE 常駐に振り切っている
• vs Vale: Vale は Google / Microsoft スタイルガイドへの適合性チェック（散文の一貫性検証）が主眼。Harper は文法・スペルチェックが主目的で、スタイルガイド適合性を求めるユースケースは Vale の担当領域
• vs textlint: textlint は Node.js 実行前提のプラグインアーキテクチャで、日本語含む多言語ルールを追加できる。Harper は英語向けのデフォルトルールがパッケージ化されており、LSP による IDE 直結体験を重視
• vs ltex-ls: ltex-ls は LanguageTool を LSP でラップした Kotlin 実装で LaTeX / Markdown に特化。Harper は独自コアを LSP から直接提供し、依存が軽量にまとまっている

用途カテゴリで整理すると、「英語のドキュメント・コメントを IDE で軽量にリアルタイム校正したい」用途は Harper、「多言語対応が必要」なら LanguageTool、「スタイルガイド適合性の CI 組み込み」なら Vale、「日本語含む多言語プラグインで独自ルールを組みたい」なら textlint、「LaTeX ワークフローに LanguageTool を LSP で組み込みたい」なら ltex-ls、というように棲み分けができます。

Harperが向くケース・向かないケース

ここまでの一次情報の整理を踏まえ、Harper が向くケースと向かないケースを整理します。

向くケース

• 英語のみのドキュメント（README・API リファレンス・技術ブログ・OSS プロジェクトのコメント）を校正したい: Harper の対応言語は英語のみだが、その領域では 10ms オーダーの応答と軽量なリソース要件で優位
• IDE 常駐でリアルタイム校正したい: LSP 経由で Neovim / Helix / Zed / VS Code / Emacs / Obsidian / Sublime Text から利用可能
• プライバシー要件が厳しい: 公式が「クラウド送信なし・テレメトリなし・LLM 関与なし」を明言しているため、機密ドキュメントの校正でも外部送信のリスクを回避できる
• セルフホスト運用のインフラコストを抑えたい: 「LanguageTool の 1/50 未満のメモリフットプリント」の主張どおりであれば、常駐サーバのインスタンスサイズを大きく削れる
• Apache-2.0 での商用利用・改変・再配布を前提としたい: ライセンス互換性の観点で採用しやすい

向かないケース

• 日本語・多言語校正が必要: 現時点で英語のみ。多言語同時対応が必要なら LanguageTool / textlint 側
• スタイルガイド適合性チェックが主目的: Google / Microsoft スタイル等への適合性検証は Vale の担当領域
• 完成品の GUI Web アプリとしてすぐ使いたい: ブラウザ拡張・macOS デスクトップアプリの提供はあるが、Grammarly のようなクラウド完結型サービスを期待するユースケースには合わない
• harper.js の API 未安定に耐えられない Web 組み込み: harper.js は early access。API 破壊的変更への追従計画が組めない場合は組み込みを見送るか、harper-ls 経由の運用に絞る

執筆時点ではリポジトリが archived=false / fork=false / disabled=false の健全な状態にあり、最終更新も 2026-08-20 と直近であるため、メンテナンス状況の観点では「採用可能な状態が維持されている」と判断できます（出典: gh api /repos/Automattic/harper 取得値）。

まとめ

本記事では、Automattic 社が公開している Rust 製オフライン英文法チェッカー OSS の Harper について、公式ドキュメント（README・公式サイト・COMPARISON.md）とリポジトリメタデータの範囲で以下の 3 点を整理しました。

• 仕組み: Rust 製 core + WebAssembly ビルドを土台に、IDE 連携のための harper-ls（LSP）と、Web / Node.js 連携のための harper.js（npm / CDN）が提供されている
• LanguageTool・Grammarly との違い: 10ms の応答時間・Apache-2.0 ライセンス・LanguageTool の 1/50 未満のメモリフットプリント・完全ローカル実行という差別化。多言語対応は英語のみとトレードオフになる
• 類似 OSS との棲み分け: 英語ドキュメント・コメントの IDE 常駐校正は Harper、多言語なら LanguageTool、スタイルガイド適合性は Vale、多言語プラグインは textlint、LaTeX ワークフローは ltex-ls という棲み分け

次のアクションの選択肢として、公式サイト（writewithharper.com）でブラウザ試用してから、IDE 側から使うなら harper-ls のインストール、Web / Electron 組み込みなら harper.js のドキュメントを参照する経路があります。判断材料が揃った段階で、自プロジェクトの言語・エディタ・組織の機密要件と照合してください。

関連情報

英文ドキュメントの品質管理を含む開発体制・技術選定のご相談を検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。