OpenLess を採用する前に読む: ホットキー音声入力と AGPL-3.0 の境界

OpenLess が埋めようとしている「思考と整形済みテキストの間」

音声入力そのものは珍しくない。OpenLess が解こうとしているのは、話した内容をそのまま文字起こしするのではなく、カーソルがある任意のアプリに、その場にふさわしい形の文章として差し込むまでの一連の手間である。README は対応先として ChatGPT、Claude、Cursor、Notion、メールの下書き、チャット欄を挙げている。対象は、こうした入力欄を行き来しながら一日を過ごす人だ。

差別化として README が前面に出すのは AI-prompt モードである。話した内容に構成を与え、制約条件を拾い、ChatGPT や Claude、Cursor にそのまま貼れるプロンプトへ組み上げる、と説明されている。単語を一つずつ書き取るだけの dictation ツールとは、出力の形が違う。

README の前半はかなり踏み込んだ主張を展開する。HTTP、Git、Stripe を引き合いに出し、優れていたから普及したのではなく、調整の手間が消えたから普及したのだと論じ、OpenLess も同じ種類のものだと位置づける。この比喩が読者に効くかどうかは別として、設計の狙いはここから読み取れる。トーンはスタイルパックに、固有名詞は辞書ホットワードに、テキストの着地点は単一の挿入プロトコルに、モデルと資格情報は OS の資格情報ストアに、それぞれ「沈殿」させるという整理である。

録音から挿入までの流れと、失敗時のクリップボード退避

README が示す動作は明快だ。任意のテキスト欄にカーソルを置き、グローバルホットキーを押して話す。アプリは音声を録音し、文字起こしし、選択中のモードで文章を整え、カーソル位置に結果を挿入する。

ここで見落とせないのが挿入失敗時の扱いである。README は、挿入がブロックされた場合はテキストをクリップボードにコピーすると明記している。話した内容が失われないための保険だ。アクセシビリティ権限が不足しているアプリや、独自の入力処理を持つエディタでは、この退避経路が実際の主経路になる可能性がある。挿入が成功したかどうかを利用者がどう知るのかは、README からは読み取れない。

構成は Rust 2021 と Tauri 2 である。リポジトリのトピックには tauri、rust、asr、llm、prompt-engineering が並び、音声認識と LLM による整形の両方をアプリ内のパイプラインとして抱えていることがうかがえる。対応 OS は macOS 12 以降、Windows 10 以降。Linux については README のバッジに egui とあり、Tauri 版とは別の実装系が存在するように見えるが、本文でどこまでサポートされるかは記述からは判断できない。

音声認識と整形をどの事業者の API に投げるのか、ローカル推論の選択肢があるのかは、与えられた README の範囲では確認できない。ここは採用判断の前に必ず一次情報で埋めるべき空白である。

スタイルパック、辞書ホットワード、OS 資格情報ストアという 3 つの設定面

OpenLess の設定は、README の言葉を借りれば「繰り返される調整をデフォルトに沈殿させる」方向に寄っている。具体的には 3 つだ。

第一にスタイルパック。トーンを名前付きで切り替え可能な単位として保存し、キー操作一つで呼び出す。毎回「この文章はどの口調で書くか」を決め直さないための仕組みである。第二に辞書ホットワード。人名や製品名などの固有名詞を ASR に認識させ、整形モデルにもヒントとして渡す。毎回スペルを直さないための仕組みだ。第三にモデルと資格情報で、README はこれを OS の vault に置くと表現している。初回起動時に一度許可すれば、以降は再交渉しないという設計思想である。

この 3 点は、導入後に効いてくる順序が逆になる。スタイルパックと辞書は使えば使うほど整備が要る項目で、初期状態では恩恵が小さい。逆に資格情報の一元化は初回起動時にいきなり判断を迫られる。マイク、アクセシビリティ、クラウド資格情報をまとめて許可する流れを README は明示しており、ここでつまずくと他の機能を試す前に止まる。

README には具体的な設定キー名や設定ファイルのパスが載っていない。したがって、スタイルパックをチームで共有する方法、辞書を一括でインポートする方法、資格情報を組織のポリシーに合わせて差し替える方法は、この記事の材料からは示せない。実際に導入を検討するなら、リポジトリのソースとアプリ内の設定画面で確認する作業が先に来る。

インストールと初回起動: 確認できるのはここまで

配布は GitHub Releases 経由である。README は最新リリースへのリンクと、公式サイト openless.top を案内している。ビルド済みバイナリをダウンロードする経路が基本で、パッケージマネージャ経由のインストールコマンドは README には記載されていない。

ソースからビルドする場合、言語は Rust 2021、UI フレームワークは Tauri 2 である。リポジトリの構成は openless-all/app/src-tauri/ 以下にアイコンなどのアプリ資産が置かれる形で、Tauri の標準的なレイアウトに沿っている。ただし README には cargo build や tauri build といった具体的なビルド手順、必要なツールチェーン、プラットフォーム別の前提パッケージは書かれていない。ビルド手順を確認したい読者は、リポジトリ内の個別ドキュメントや CI 定義を当たる必要がある。

初回起動時に求められる許可は 3 種類で、マイク、アクセシビリティ、クラウド資格情報である。アクセシビリティ権限は macOS ではシステム設定の該当項目で明示的に許可する必要があり、Windows でも同種の入力フックに関する許可が絡む。ここを拒否すると、カーソル位置への挿入が働かず、README が述べるクリップボード退避だけが残る。

リリースの並びを見ると、v1.3.18-tauri のような安定版と、v1.3.18-Beta.7-tauri のような Beta 版が短い間隔で出ている。既定ブランチが beta である点も合わせると、追従する側は「どのタグを固定して使うか」を最初に決めておかないと、更新のたびに挙動が動く。

Beta 既定ブランチという運用コストと、AGPL-3.0 が課す配布時の条件

このプロジェクトで最初に引っかかるのは、既定ブランチが beta であることだ。リポジトリの Last push は 2026-09-09、直近のリリースは v1.3.18-Beta.7-tauri が 2026-08-24、v1.3.18-tauri が 2026-08-21 と、Beta と安定版が数日単位で交錯している。活発であることの裏返しで、利用者側は「どのリリースを固定するか」を決め、上げるタイミングを自分で管理する必要がある。自動更新の有無や更新チャネルの切り替え方法は README からは読み取れない。

ライセンスは AGPL-3.0 である。ここは用途によって重みが変わる。個人が自分の端末で使う分には通常のオープンソースソフトウェアと変わらない。しかし、改変した版を社内で配布する、あるいはネットワーク経由で他者に機能を提供する形にする場合、AGPL-3.0 はソースの提供を含む条件を課す。ソースを改変せずそのまま社内配布する場合でも、ライセンス全文と著作権表示の同梱が要る。これは法的助言ではないので、実際の判断は法務に確認してほしい。少なくとも「オープンソースだから自由に社内展開できる」と短絡するのは危うい。

もう一つの運用コストは音声とテキストの扱いである。README は資格情報を OS の vault に置くと述べるが、録音データや文字起こし結果がどこに保存され、どの API に送られるのかは記述からは確認できない。クラウド ASR とクラウド LLM を前提にするなら、送信先と保持期間を把握しないまま業務利用するのは避けたい。

Wispr Flow や Superwhisper との違いは「整形の主導権」にある

README 自身が比較対象として Typeless、Wispr Flow、Lazy、Superwhisper を挙げ、OpenLess をその完全なオープンソース代替と位置づけている。違いは単に無料かどうかではない。

商用ツールの多くは、音声認識から整形までのパイプラインを自社サービスとして閉じて提供する。利用者はモデルの選択やプロンプトの調整に踏み込めず、代わりに品質の安定と導入の手軽さを得る。OpenLess は逆で、整形の指示とトーンをスタイルパックとして、固有名詞を辞書ホットワードとして、利用者側が持ち込む前提で設計されている。プロンプトエンジニアリングというトピックがリポジトリに付いているのは、この立場の表れだ。

この違いは、そのまま責任の所在の違いでもある。商用サービスなら認識精度の不満はベンダーへのフィードバックになるが、OpenLess では自分のスタイルパックと辞書を直す作業になる。手間を引き受ける代わりに、どのモデルに何を送るかを自分で決められる。逆に言えば、設定を育てる気がない人にとっては、商用ツールの方が総コストは低い。

音声認識エンジンや整形モデルの切り替えがどこまで可能かは、README の記述からは判断できない。比較の軸として重要な点なので、採用前に確認したい。

どんなチームが採用し、どんなチームが避けるべきか

向いているのは、プロンプトを書く時間が長く、その入力を音声に置き換えたい個人開発者や小規模チームだ。特に、商用クラウドの音声入力に自分の音声と文章を預けることに抵抗があり、かつ Rust と Tauri の構成を読める、あるいは読める人を確保できる体制なら、AGPL-3.0 の条件も含めて自分で判断できる。

避けるべきなのは、端末の権限を中央管理していて、マイクやアクセシビリティの許可を利用者個人が与えられない組織である。初回起動時の一括許可という設計は、そのままでは通らない。また、音声データの保管場所と送信先を文書で説明する義務がある業務、たとえば医療や法務の記録作成に使うのは、現時点の README だけでは根拠が足りない。

導入を決める前に確認する項目は絞れる。第一に、使用する音声認識と整形のバックエンドが何で、音声がどこへ送られるか。第二に、挿入がブロックされたときにクリップボード退避が働いたことを利用者がどう知るか。第三に、beta 既定ブランチに対して自分がどのタグを固定するか。第四に、AGPL-3.0 の下で自組織の配布形態が何を要求されるか。この 4 点が埋まらないうちは、試用を個人端末に限定しておくのが妥当だ。

編集部の結論

OpenLess が向くのは、ChatGPT や Claude、Cursor へのプロンプト入力を毎日繰り返し、商用クラウドの音声入力にテキストと音声を預けたくない個人や小規模チームだ。逆に、組織の端末管理ポリシーでマイクとアクセシビリティ権限が一括制御されている環境や、音声データの保存先を自前で監査する必要がある業務には、そのままでは持ち込みにくい。導入前に確認すべきは 3 点で、第一に beta ブランチと v1.3.18-Beta.7-tauri のような Beta タグ付きリリースが並ぶ更新の速さに自分の運用が追随できるか、第二に README が述べる「初回起動時にマイク、アクセシビリティ、クラウド資格情報をまとめて許可する」設計が自組織の権限管理と衝突しないか、第三に AGPL-3.0 の下で社内配布や改変を行う場合の義務を法務がどう評価するかである。この 3 点を潰せないなら、採用は見送る判断も合理的だ。

公式情報源

1. License: AGPL-3.0
2. Open-Less/openless on GitHub
3. Project website
4. README
5. Releases