Writing Tools を採用する前に確認したいこと: ホットキー1つで動く LLM 校正ツールの実像
The world's smartest system-wide grammar assistant; a better version of the Apple Intelligence Writing Tools. Works on Windows, Linux, & macOS, with the free Gemini API, local LLMs, & more.
ひと目でわかる
- これは何?
- Windows、Linux、macOS でシステム全体のテキストを LLM に投げる校正ツール。GPL-3.0、Swift 製の macOS 移植版と Windows/Linux 版で構成が分かれており、その分割こそが導入判断の分かれ目になる。
- 誰に向いている?
- システム全体で使える校正ツールを無料で試したい Windows ユーザー、とくに Gemini API の無料枠か Ollama をすでに持っている人には向いている。逆に、社内の文章を外部 API に送れない環境や、Program Files 以下のような保護されたフォルダに置きたい人、macOS で Intel 機を使っているために移植版の対象外になる人は、先に別の手段を検討したほうがよい。
- 商用利用できる?
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている?
- されています。最後のコミットは 28 日前です。
- 何の言語で書かれている?
- 主に Swift です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Writing Tools が埋めようとしている穴は、アプリごとの校正機能の分断である
多くのエディタやブラウザには校正機能が付いているが、それぞれ別物で、設定も語彙も共有されない。メールクライアント、チャット、IDE、PDF ビューアを行き来するたびに、同じ文章を別のツールに見せることになる。Writing Tools はこの分断を、OS 全体で動く単一のホットキーで埋めようとする。README によれば、任意のテキストを選択して `ctrl+space` を押すと Proofread、Rewrite、Friendly、Professional、Concise といったプリセット、または `Describe your change...` に書いた自由指示でテキストが置き換わる。置き換え後に `ctrl+z` で戻せる点も README に明記されている。クリップボードを経由しない設計を掲げており、これはコピー履歴を汚したくない人にとって実務上の差になる。想定読者は、複数のアプリで文章を書くが、それぞれに拡張機能を入れて回る気はない人である。
処理の流れは「選択テキストを LLM に渡して置換する」であり、要約とチャットは同じ入口の別モードである
README から読み取れるデータフローは単純である。選択中のテキストをホットキーで取り込み、選んだプリセットか自由指示をプロンプトとして LLM に送り、返ってきた文字列で元のテキストを置き換える。テキストを選択せずに `ctrl+space` を押すと、LLM との会話モードに入る。README はこのときのチャット履歴がウィンドウを閉じると削除されると書いている。要約は別の入口ではなく、同じ操作の後に Summary、Key Points、Table を選ぶ形になっている。Web ページやドキュメントなら `ctrl+a` で全選択、YouTube 動画なら概要欄のトランスクリプトを選択してから呼び出す。出力は Markdown をレンダリングしたポップアップで表示され、その要約に対して追加質問ができる。つまりアプリの実体は、テキスト取得、プロンプト組み立て、LLM 呼び出し、書き戻しという4段のパイプラインであり、プリセットと要約とチャットはその入口の違いにすぎない。
導入は zip を展開して exe を起動するだけだが、書き込み権限の制約が先に来る
Windows の場合、手順は Releases ページから最新の `Writing.Tools.zip` を取得し、任意の場所に展開して `Writing Tools.exe` を実行するだけである。インストーラは存在しない。ここで見落とされやすいのが、README が明記しているポータブルアプリとしての性質だ。設定ファイルは exe と同じフォルダに作られるため、Program Files のような保護されたフォルダに展開した場合は、初回起動時に管理者として実行しないと設定ファイルを作成できない。常時管理者で動かすのは避けたいので、`Documents` か `App Data/Local` に置くのが現実的である。起動時に自動実行させたい場合は、タスクトレイのアイコンから設定を開いて有効にする。LLM 側の選択肢は広く、README は無料の Gemini API と Gemini 2.0、Ollama などのローカル LLM、OpenAI API 互換のクラウドサービスを挙げている。Ollama の手順は README 内に v7 以降向けとして用意されている。
Windows/Linux 版と macOS 版は別実装であり、同じ体験を前提にできない
このプロジェクトで最も誤解を招きやすいのが構成である。リポジトリの主要言語は Swift とされているが、README は macOS 向けを「Native Swift Port」として別セクションに切り出し、Windows/Linux 版とは別の開発者(Arya Mirsepasi)が移植版全体を作ったと書いている。リリース名も `Win_v9+mac_OS_v6.1` のように両者が並記され、バージョン番号が一致していない。つまり利用者は単一のアプリを入れるのではなく、プラットフォームごとに別の成果物を選ぶことになる。README の機能説明やトラブルシューティングは Windows/Linux 版を前提に書かれた部分が多く、macOS で同じ挙動を期待できるかは移植版のドキュメントを別途読む必要がある。Linux 版は README の時点で work-in-progress と明示されており、完成度を前提にした導入は勧められない。
GPL-3.0 とポータブル配布の組み合わせが、社内展開の可否を決める
ライセンスは GPL-3.0 である。個人が自分のマシンで使う分には、この選択が日常の操作に影響することはほとんどない。問題は配布側に回ったときだ。GPL-3.0 は、ソフトウェアを配布する場合にソースコードの提供と同一ライセンスでの公開を求める。社内で Writing Tools を改変して全社員に配る、あるいは顧客向けの製品に組み込むといった使い方を考えるなら、この条件が設計に効いてくる。ここで注意したいのは、Writing Tools がポータブルアプリであり、設定ファイルが exe と同じフォルダに置かれるという事実である。配布物に設定を同梱する運用は、ライセンスの話とは別に、API キーの扱いという実務上の問題を生む。README は API キーと設定ファイルが手元のデバイスに留まり、ログや診断情報の収集、トラッキング、広告がないと書いているが、これはあくまでアプリの挙動についての説明であり、配布方法の安全性を保証するものではない。具体的な法的判断はここでは扱わない。
Ollama や llama.cpp を自分で組む場合との違いは、テキスト取得と書き戻しを誰が担うかにある
比較対象として素直なのは、Ollama や llama.cpp を自分で立てて、ホットキーから呼び出す小さなスクリプトを書く方法である。この場合、モデルの選択もプロンプトも完全に自分で決められる。代わりに自分で作る必要があるのが、前面アプリから選択テキストを取り出す処理と、結果を元の位置に書き戻す処理だ。Writing Tools が提供している価値の中心はここにあり、LLM 呼び出しそのものではない。OpenAI API 互換のエンドポイントを設定できると README が書いている点を踏まえると、バックエンドを自前のサーバーに向けることはできる。つまり Writing Tools は「LLM を選ぶ層」と「OS に統合する層」を分けており、前者は差し替え可能、後者はこのアプリ固有の実装である。自前スクリプトとの比較で言えば、置き換えられるのは前者だけであり、後者を作る手間を省くためにこのアプリを入れるかどうかが判断の軸になる。
向かないケースと、導入前に自分で確かめるべき3点
向かないケースははっきりしている。第一に、扱う文章を外部 API に送れない環境である。ローカル LLM を使えばデータは端末内に留まると README は説明しているが、その場合はモデルの品質とマシン性能がそのまま体験になる。無料の Gemini API を使う構成と、Ollama で手元のモデルを回す構成では、書き換えの質が別物になり得る。第二に、Linux を本番環境として使いたい場合。README 自身が work-in-progress と書いている段階では、業務の前提に置けない。第三に、macOS で Intel 機を使っている場合や EU 域内での利用を想定している場合で、README はこれらをこのツールの存在意義として挙げているが、移植版が自分の環境を対象にしているかは別途確認が要る。導入前に試すべきは、`ctrl+space` を押して `Describe your change...` に自分の言語で指示を書き、期待どおりの出力が返るかどうかである。プリセットの Proofread や Concise が自分の文章ジャンルに合うとは限らない。設定は exe と同じフォルダに作られるので、まず書き込み可能な場所に展開し、トレイの設定から起動時の自動実行を必要に応じて切り替える。ここまで試して初めて、このツールが自分の作業面に合うかが判断できる。
編集部の結論
システム全体で使える校正ツールを無料で試したい Windows ユーザー、とくに Gemini API の無料枠か Ollama をすでに持っている人には向いている。逆に、社内の文章を外部 API に送れない環境や、Program Files 以下のような保護されたフォルダに置きたい人、macOS で Intel 機を使っているために移植版の対象外になる人は、先に別の手段を検討したほうがよい。導入前に確認すべきは3点ある。第一に、配布されている `Writing.Tools.zip` の展開先を自分で書き込める場所にできるか。第二に、`Describe your change...` に何を書けば求める出力になるかを自分の言語と用途で試せるか。第三に、macOS 版を使うなら、自分のマシンが移植版の対象に入っているか。この3つが満たせないなら、このツールの利点である「どこでも ctrl+space」は体験できない。
コミュニティノート