Harperを解説:Rust製オフライン文法チェッカーが伸びる理由
Automattic/harperの用途、ローカル処理、Language Server連携、導入方法、制限、ライセンス、GrammarlyやLanguageToolとの差を整理します。
Harperは、文章をクラウドへ送らずローカルで動かせる英語向け文法チェッカーです。Rust製のコアをWebAssemblyやLanguage Serverとして利用でき、VS Code、Neovim、Helix、Emacs、Zed、Chromeなど複数の環境へ組み込めます。2026年7月25日の調査時点ではGitHub Trendingで約590 stars/dayの勢いが確認でき、直近にも開発コミットが続いています。
Harperの用途
Harperが狙うのは、スペルミス、文法、表現上の問題をエディタやブラウザ内で検出する用途です。特徴は、校正処理を外部サーバーへ送ることを前提にしない点にあります。
コードや社内文書、公開前の記事など、入力内容を外部サービスへ送信したくない環境では、ローカル処理の価値が分かりやすくなります。Language Serverとして動かせるため、専用エディタを新たに導入せず既存の開発環境へ組み込める点も実務向きです。
仕組み
HarperのコアはRustで実装され、WebAssemblyとLanguage Serverの両方から利用できます。Language Server版のharper-lsは、エディタ側がLSPに対応していれば校正エンジンを共通化できます。
この構成により、VS Code専用拡張だけに閉じず、NeovimやHelixなどでも同じ校正ロジックを利用できます。ブラウザ向けにはWebAssemblyを使った構成があり、Chrome拡張なども提供されています。
編集評価としては、文章校正機能そのものより「ローカルで動く共通コアを複数の編集環境から呼べる」設計がHarperの強みです。
導入方法
harper-lsは公式ドキュメントで複数の配布経路が案内されています。
- Homebrew
- Scoop
- Arch Linux系パッケージ
- Nix
- Cargo
- GitHub Releases
Cargoからビルドする場合は、プロジェクトがサポートするStable Rust環境が必要です。エディタごとにLanguage Serverの起動設定が必要になる場合もあります。
VS Codeなど既成の拡張がある環境では導入が容易ですが、LSPクライアントを手動設定するエディタでは実行ファイルのパスや起動引数を確認する必要があります。
GrammarlyやLanguageToolとの違い
Grammarlyはクラウドサービスとして広く使われ、文章の書き換え支援やアカウントをまたいだ体験が強みです。一方でHarperはローカル処理を中心に据えています。
LanguageToolも自己ホストを含む複数の運用方法がありますが、Harperは小さなローカルエンジンとエディタ統合を強く意識しています。
公式READMEには速度やメモリ使用量の比較も掲載されています。ただし、これらはプロジェクト側のベンチマーク値です。今回、独立した同条件ベンチマークは実施していないため、性能優位を断定する材料には使いません。
制限
最も大きい制限は、現時点で英語向けであることです。日本語文章の校正目的では主用途になりません。
また、校正ルールベースのツールなので、生成AI型の文章支援と同じ柔軟な書き換えを期待すると用途がずれます。文脈を広く読んだ構成変更や、目的に応じた文章全体の再生成まで任せたい場合は別のツールが必要です。
Chrome拡張はストア審査の都合で、他の統合より更新が数日遅れる場合があると公式が案内しています。環境ごとに最新バージョンが揃わない可能性もあります。
ライセンス
HarperはApache License 2.0で公開されています。企業利用や組み込みを検討しやすいライセンスですが、再配布や派生物を扱う場合はライセンス本文とNOTICE等の条件を確認する必要があります。
向いているケース
- 英語のREADME、Issue、ドキュメントを日常的に書く
- 原稿を外部校正サービスへ送信したくない
- VS Code以外のエディタでも同じ校正エンジンを使いたい
- Language Serverとして開発環境へ統合したい
- 軽量なローカル校正を常時動かしたい
逆に、日本語校正が中心、文章全体の生成・大幅な言い換えが主目的、クラウド側でチームの文章スタイルを一元管理したい、といったケースでは他の選択肢の方が自然です。
導入判断
Harperは、生成AIとは別方向から文章作業を改善する実用ツールです。ローカル処理、Rust製コア、LSP連携という設計は、コードと文章を同じエディタで扱う開発者に特に適しています。
GitHub上の注目度だけを理由に採用する必要はありませんが、英語文書を扱い、プライバシーとエディタ統合を優先する人には試す理由があります。性能比較は公式値を鵜呑みにせず、自分の文書と環境で確認するのが安全です。
参照情報
- GitHub: https://github.com/Automattic/harper
- 公式サイト: https://writewithharper.com/
- Language Server: https://writewithharper.com/docs/integrations/language-server
- Releases: https://github.com/Automattic/harper/releases