harperをローカルで動かす英語文法チェック環境の作り方

機密性の高いテキストを文法チェッカーに貼り付けるとき、少し手が止まりませんか。
Grammarly は便利ですが、入力したテキストはサーバーに送信される構造です。
契約書のドラフト・顧客向けメールの原稿・社内仕様書といった文書を、気軽にクラウドサービスに流せないケースは実務では珍しくありません。

セットアップから VS Code・Neovim への統合、業務文書への適用判断まで、 harper を実際に手元で動かしながら読める粒度で整理します。

機密テキストを文法チェッカーに渡していいのか、という問い

Grammarly の利用規約は何度か改定されていますが、テキストをサーバーに送って処理するという基本構造は変わっていません。
個人のブログ原稿や公開前提のドキュメントなら問題になりにくいですが、顧客との契約書ドラフト・未公開の製品仕様・社内の人事関連文書などは話が別です。
「クラウドに送っていいか」を都度判断するコストが地味に高く、結果として文法チェックをスキップしてしまう、というのが実態ではないでしょうか。

ローカルで動く選択肢として以前から LanguageTool がありました。
ただ、LanguageTool のローカル運用は Java ランタイムが必要で、サーバーを自前で立ち上げる手順もそれなりに重い。
エディタに統合するまでの道のりが長く、「試してみたけど面倒で諦めた」という声もよく聞きます。

そこに登場したのが harper です。
harper の核は harper-ls という LSP サーバーで、VS Code 拡張・Neovim 統合・CLI はすべてそのフロントエンドという位置づけです。
Rust 製なのでバイナリ 1 本で動き、依存関係はほぼゼロ。
インストールから動作確認まで数分で終わるのが、LanguageTool との最大の違いです。
2024年11月には WordPress.com を運営する Automattic が harper を買収しており、開発の継続性という面でも一定の安心感があります。

インストールは2分で終わる：cargoとバイナリ直接取得

インストール経路は大きく2つあります。
Rust ツールチェーンが手元に入っているなら、cargo 経由が一番シンプルです。

cargo install harper-ls --locked

これだけです。
--locked フラグは Cargo.lock に記録されたバージョンを厳密に使う指定で、harper-ls のドキュメントでも推奨されています。

インストール後に PATH が通っていないと harper-ls コマンドが見つからないことがあります。
cargo でインストールしたバイナリは ~/.cargo/bin に置かれるので、シェルの設定ファイルに以下を追加しておきましょう。

export PATH="$HOME/.cargo/bin:$PATH"

Debian 系 Linux を使っている場合、cargo install の途中で C コンパイラが見つからないというエラーが出ることがあります。
その場合は build-essential を先に入れておくと解決します。

sudo apt install build-essential

Rust ツールチェーンをまだ入れていない、あるいはビルド時間を省きたいという場合は、GitHub の Releases ページからプラットフォーム別のビルド済みバイナリを直接取得する方法が早いです。
ダウンロードして PATH の通った場所に置くだけなので、Rust 環境が不要な分だけ手順が少なくなります。

どちらの方法でも、最後に以下で応答が返ってくれば準備完了です。

harper-ls --version

バージョン番号が表示されれば、LSP サーバーとして起動できる状態になっています。

VS Code と Neovim に組み込む

VS Code の場合

拡張は VS Code Marketplace に公開されています。
コマンドラインからインストールするなら以下の 1 行です。

code --install-extension elijah-potter.harper

Cursor や VSCodium など VS Code フォークでも同じ拡張が使えます。
VS Code Marketplace と Open VSX Registry の両方に登録されているので、フォーク側のマーケットプレイスからも見つかるはずです。

拡張を入れるだけでも動きますが、settings.json で harper-ls の挙動を調整できます。
たとえばスペルチェックを有効にしつつ、数字をスペルアウトするルール（SpelledNumbers）を無効にしたい場合はこんな設定になります。

{
  "harper-ls.linters.SpellCheck": true,
  "harper-ls.linters.SpelledNumbers": false,
  "harper-ls.linters.LongSentences": true
}

設定後に Markdown ファイルや英語のテキストファイルを開くと、問題のある箇所に波線が引かれ、カーソルを当てるかコードアクション（Ctrl+. / Cmd+.）を呼び出すと修正候補が表示されます。

Neovim の場合

nvim-lspconfig を使っている環境なら、最小構成はこれだけです。

require('lspconfig').harper_ls.setup {}

harper-ls バイナリが PATH に入っていれば、この 1 行で Markdown や text ファイルを開いたときに LSP が起動します。

linters の細かい設定をしたい場合は settings に渡します。

require('lspconfig').harper_ls.setup {
  settings = {
    ["harper-ls"] = {
      userDictPath = vim.fn.expand("~/.config/harper/user.dict"),
      linters = {
        SpellCheck = true,
        SpelledNumbers = false,
        LongSentences = true,
        RepeatedWords = true,
      },
    },
  },
}

harper-ls を mason.nvim で管理したい場合は、Mason のパッケージ名 harper-ls でインストールできます。

:MasonInstall harper-ls

こちらの方法だと mason が管理するディレクトリにバイナリが置かれるため、cargo や手動取得と混在させずに済みます。
Neovim の設定を他のマシンと共有している場合は、mason.nvim 経由の方が環境を揃えやすいです。

業務文書への適用：効く場面と効かない場面を正直に言う

harper は 決定論的なルールベースエンジン で動いています。
機械学習モデルではないので、同じ文章を何度チェックしても提案の内容が変わりません。
これは業務文書の校正フローにとって地味に重要な特性です。
「昨日は大丈夫だったのに今日は指摘された」という状況が起きないので、チェック結果をレビューコメントとして残したり、CI に組み込んだりするときに扱いやすい。

効果を感じやすいのは、英語の顧客向けメール・README などの技術文書・契約書ドラフトの初稿チェックといった場面です。
誤字・重複語・冠詞の抜け・長すぎる文といった、ルールで検出できるミスは確実に拾ってくれます。
特に「精度より速度とプライバシー」が優先される初稿段階では、クラウドに送らずリアルタイムでフィードバックが得られる点が素直に便利です。

一方で、文体の洗練や文脈を踏まえた言い換えは苦手です。
「この表現は技術文書としてやや硬すぎる」「もう少しカジュアルなトーンにしたい」といった要求には応えられません。
ルールベースの限界なので、これは harper の問題というより設計上の割り切りです。

もうひとつ正直に言うと、 harper は現時点で英語専用 です。
日本語のテキストには対応していません。
日英混在のドキュメントでは、英語部分だけチェックされる形になります。
社内ドキュメントが日本語中心のチームには、この制約がそのまま使いどころの限界になります。

harperとGrammarlyをどう使い分けるか

「harper か Grammarly か」という二択で考えると、どちらかを選ぶ理由が見つかりにくくなります。
実際には 文書の機密度と仕上げのフェーズ で使い分けるのが現実的な着地点です。

判断の軸を整理するとこうなります。

機密度 ── 契約書・未公開仕様・顧客情報を含む文書はクラウドに送らない。harper をローカルで使う。
仕上げフェーズ ── 初稿・社内レビュー段階は harper で十分。対外発信前の最終磨き込みは Grammarly の文体提案を活用する。
言語 ── 英語のみなら harper が使える。日本語が混在するドキュメントは harper の対象外になる。
エディタ統合 ── LSP 対応エディタで作業しているなら harper はほぼゼロコストで常時オンにできる。ブラウザ上で書く場面は Grammarly の Chrome 拡張の方が手軽。

この軸で整理すると、harper と Grammarly は競合というより役割が違うツールです。
初稿をエディタで書きながら harper でローカルチェック、最終版を Grammarly でひと磨き、という流れが現実的な使い方になります。

LanguageTool のローカル運用と比べると、harper は Java 不要・設定ファイル最小・起動が速いという点で導入コストが一段低い。
「とりあえず試してみる」ハードルが低いのは、継続して使えるかどうかに直結します。

機密性の高い文書を扱う機会が少しでもあるなら、harper を常時オンにしておくだけで校正の抜け漏れを減らせます。
クラウドに送らない安心感と、エディタ統合のリアルタイムフィードバックは、一度慣れると手放しにくくなります。

株式会社ホコサキは山口県宇部市を拠点に、Web 制作・業務システム開発・AI 活用支援・DX 推進に取り組んでいます。
「社内ドキュメントの品質を上げたい」「開発フローに校正を組み込みたい」といった相談も気軽にどうぞ。
詳しくはお問い合わせページからご連絡ください。