Harper:ローカル完結のRust製英語文法チェッカー
オフラインのプライバシー最優先の文法チェッカー。高速、オープンソース、Rust ベース。
ひと目でわかる
- これは何?
- Automattic/harperはオフライン・プライバシー優先の英語文法チェッカーで、LanguageToolより小さなメモリとミリ秒級lintをREADMEが設計目標として掲げます。
- 誰に向いている?
- 英語原稿をネットワークへ送らずに校正したい執筆者・開発者に向きます。日本語校正やクラウド辞書共有が必須の編集フローには向きません。
- 商用利用できる?
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている?
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている?
- 主に Rust です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Grammarly/LanguageToolへの作者の不満
Harper READMEは、Grammarlyが高価で文脈不足の提案が多く、全文がサーバー送信されるプライバシー問題があると作者が述べます。LanguageToolは約16GB n-gramと巨大RAM、数秒lintをREADMEが比較対象として挙げます。
Harperはミリ秒lint、LanguageToolの1/50以下のメモリ、完全ローカル処理を設計目標とREADMEが説明します。Automattic/harper、Rust、Apache-2.0、star14768、v2.9.1(2026年8月29日)はメタデータです。
作者はGrammarlyのprivacy policyがデータをLLM学習等に使わないと主張するだけで売却しない、とREADMEが引用します。往復のネットワーク待ちが推敲を中断させる点も不満として挙げられます。Harperはその対極として端末内完結をREADME全体で繰り返します。
Harper is an English grammar checker designed to be just right.とREADME冒頭は述べ、過剰な自動修正ではなく執筆者の意図を尊重する方向性を示します。
EnglishのみとPerformance Issues方針
Language Support節は現時点Englishのみ、コアは他言語拡張可能で貢献歓迎とREADMEが述べます。Performance Issues節は長いlint時間をバグ扱いし、issue作成を促します。
日本語や中国語原稿の校正器として評価する材料はREADMEにありません。性能確認は同じ英語文書を複数回lintし、応答時間とCPU/RSSを記録するのがREADMEのPerformance Issues方針に沿います。
If you find a fix to any performance issue, we would appreciate the contribution. Just please make sure to read our contribution guidelines first.とPerformance Issues節はREADME原文です。長時間lintは再現手順付きissueとして報告する文化をREADMEが示します。
harper-lsとエディタ統合一覧
README Linksはharper-ls、VS Code、Neovim、Helix、Emacs、Zed、Obsidian統合文書(writewithharper.com/docs/integrations/*)とharper.js、FAQ、Discord(discord.gg/JBqcAaKrzQ)を列挙します。
crates.io/crates/harper-lsへのリンクもREADMEにあり、Language Serverとしてエディタへ接続する入口です。各エディタで同じ英文を開き、警告IDと修正提案が一致するかを比較すると統合品質を測れます。
GitHub Actionsのjust_checks.ymlはRust crateの静的チェックを示唆し、binaries.ymlは各OS向けバイナリー配布、build_web.ymlはWebAssemblyビルドをREADMEバッジから読み取れます。統合テストは利用者環境のharper-ls動作を代替しません。
WebAssemblyでブラウザから読み込む
READMEはHarper is even small enough to load via WebAssemblyと述べ、writewithharper.comへリンクします。ブラウザデモはネットワーク送信なしの訴求を補強しますが、本番執筆でWebAssembly版を使うかは利用者の環境次第です。
WebAssembly版とharper-ls版で同一英文をlintし、警告集合が一致するか、オフラインでも動作するかを確認してください。READMEはWebAssembly版のbundleサイズや対応ブラウザを数値化していません。
WebAssemblyデモ(writewithharper.com)をオフラインで開き、DevTools Networkが空であることを確認するのは、READMEのprivacy-first主張を手元で検証する単純な方法です。
CI workflowとv2.9.1リリース
READMEバッジはbinaries.yml、build_web.yml、just_checks.ymlのGitHub Actions workflowを示します。Releases v2.9.1(2026-08-29)が最新tagです。
導入確認では、対象OS向けReleaseバイナリーまたはcargo install harper-ls(README/crates.io参照)後、echo "This are bad." | harper-lsのような固定英文で警告が出るかを記録します。workflow greenは品質の参考であり、手元環境でのlint結果を代替しません。
openIssues 860(メタデータ)はバックログ規模の参考です。v2.8.0、v2.7.0もReleasesにあり、更新頻度はREADMEだけでは測れませんがtag日付は確認できます。
defaultBranch master、pushedAt 2026-08-29はGitHubメタデータで、バイナリー更新の鮮度参考になります。
Obsidianプラグインとharper.js
Obsidian Documentation(writewithharper.com/docs/integrations/obsidian)とharper.js Introduction(writewithharper.com/docs/harperjs/introduction)がREADME Linksにあります。ノート執筆とWeb組み込みの両経路をREADMEが示します。
Obsidian vault内の英語ノート1件でプラグインを有効化し、保存時lintと手動lintの差、オフライン時の挙動を記録してください。harper.jsを使うWebアプリでは、クライアント側のみで完結するかNetworkタブで外部送信がないかも確認対象です。
harper.jsはブラウザ組み込み向けAPIとしてREADME Linksが位置づけ、Obsidianは執筆ワークフロー向けです。同一英文でharper-ls CLIとObsidianプラグインの警告差分をdiffすると、統合ごとのルール差を把握できます。
Apache-2.0と貢献ガイド
Apache-2.0はREADME LICENSEリンクとメタデータが示します。著作権表示と変更通知の条件はLICENSE全文で確認が必要です。Contributors introduction(writewithharper.com/docs/contributors/introduction)がREADMEの貢献入口です。
性能修正のPRを送る場合、README Performance Issues節がcontributor guidelinesを先に読むよう求めています。社内でHarperを再配布する場合もApache-2.0のNOTICE要件を満たす必要があります。
Apache-2.0下でHarperを商用アプリに組み込む場合、NOTICEファイルと変更箇所の記載がLICENSE条件です。READMEはセキュリティ監査結果やSOC2等を提供していません。
README LinksはFrequently Asked Questions(writewithharper.com/#faqs)を含み、導入前の疑問をWebサイト側で整理していることを示します。FAQとREADME Performance Issues節を併読し、長文lintや統合不具合の既知回答がないか確認してからissueを起票するのが効率的です。
VS Code統合(writewithharper.com/docs/integrations/visual-studio-code)では拡張機能IDと設定キーを公式文書から控え、Neovim/Helix/Zed/Emacsも同様にintegrations配下のページ名を記録してください。Harper v2.9.1 tagとharper-ls crate版を対に保存すると、統合ごとの警告差分レビューが更新後も再現できます。
Discordとロゴ作者クレジット
Official Discord Server(discord.com/invite/JBqcAaKrzQ)がREADMEにあり、バグ報告や統合質問のコミュニティ窓口です。ロゴはLukas Werner(lukaswerner.com)デザインとREADME Huge Thanks節が明記します。
導入後の運用記録には、使用したharper-ls版、エディタ統合名、テスト英文、警告数、lint時間をセットで残し、v2.9.1から更新した際にPerformance Issues節の基準で再計測してください。
contributors graph(github.com/automattic/harper/graphs/contributors)へのリンクはコミュニティ規模の参考です。導入記録にはharper-ls --version、使用統合、テスト英文、lint ms、メモリ使用量をv2.9.1 tagとセットで残してください。
Helix、Emacs、Zedの統合ページもwritewithharper.com/docs/integrations配下にあり、harper-ls crate(crates.io/crates/harper-ls)の版とv2.9.1 tagを揃えてから、同一英文「This are bad.」で警告IDを比較します。Language Support節がEnglishのみと書く以上、日本語ノートをObsidianに入れても校正対象外になる点をvault側で確認してください。build_web.ymlが通っていても、writewithharper.comのWebAssemblyデモをオフラインキャッシュなしで開き直すと外部送信の有無が分かります。FAQ(writewithharper.com/#faqs)とPerformance Issues節を先に読み、長文lintをバグとしてissue化する前に再現手順と所要時間を添えてください。Apache-2.0のNOTICEとLICENSEはv2.9.1 tagのツリーから控え、harper-lsを社内バイナリーとして再配布する場合の著作権表示を同じフォルダに残します。
編集部の結論
英語原稿をネットワークへ送らずに校正したい執筆者・開発者に向きます。日本語校正やクラウド辞書共有が必須の編集フローには向きません。writewithharper.com/docs/integrations/visual-studio-codeを読み、短い英語Markdownでharper-ls警告と修正操作を確認してください。
コミュニティノート