Natively を業務で使えるか: Cluely 互換オーバーレイの実装とライセンスの境界

Natively が埋めようとしているのは文字起こしの穴ではない

会議の文字起こしツールはすでに飽和しています。Natively が狙うのはその先で、README は「Same UI as Cluely. More features.」と書き、Cluely のインターフェースをほぼそのまま再現したと説明しています。つまり乗り換えの学習コストをゼロに近づけ、そのうえで価格とデータの置き場所を差別化点に据える戦略です。README の比較文では競合が月 20 ドルから 149 ドルを請求し、データを自社サーバーに保存し、ある製品は 83,000 ユーザーの情報が漏えいしたと主張しています。この手の数字は出典が示されていないため、そのまま受け取るべきではありません。ただし製品の設計思想は読み取れます。対象読者は、面接や商談のように発話の直後に判断を求められる場面で、クラウドに録音を預けたくない個人です。会議の議事録をチームで共有する用途は想定の外側にあります。

音声取得からオーバーレイ表示までの流れ

README の説明で確認できる範囲では、処理はデスクトップ側で閉じる方向に寄せられています。ネイティブの音声キャプチャを行い、README は 500ms 未満のレイテンシをうたっています。これは著者側の主張であり、当サイトが計測した数値ではありません。文字起こしはローカルで処理され、生成したテキストを任意の LLM に渡して応答を作り、それを画面に重ねるオーバーレイとして表示する流れです。モデルは BYOK 方式で、利用者が自分の API キーを持ち込みます。この構成の帰結は明確で、推論の品質とコストは利用者が選んだモデルに依存し、Natively 側はモデルを提供しません。ローカル RAG も搭載すると記載されているため、過去のセッションや資料を検索対象として引き当てる経路が想定されています。ただし README の抜粋にはインデックス形式や保存先の記述がなく、検索精度を外から評価する材料はありません。

導入は Releases のバイナリから。ビルド前提ではない

README は macOS と Windows のダウンロードボタンを GitHub Releases の latest に貼っており、動作要件として macOS 12 以降（Apple Silicon と Intel の両方）または Windows 10/11 を挙げています。ソースからのビルド手順は抜粋に含まれていないため、TypeScript のリポジトリを clone して npm install する経路が公式に案内されているかは、この材料からは判断できません。リポジトリの言語が TypeScript である以上、Electron 系のデスクトップアプリだと推測はできますが、推測は推測として扱うべきです。設定面で材料から確実に言えるのは、LLM の接続に自前の API キーを使う BYOK 方式であること、そして stealth mode と呼ばれる表示モードが存在することの 2 点です。API キーをどのファイルに書くのか、環境変数なのか設定画面なのかは、抜粋からは分かりません。導入を検討するなら、まず Releases のバイナリを入れて設定画面でキーを登録し、そのうえでソースの構成を確認する順序が現実的です。

stealth mode は機能名であって、検出回避の保証ではない

README は stealth mode を主要機能として繰り返し挙げ、トピックにも undetectable interview AI といった語を並べています。ここは冷静に切り分ける必要があります。画面に重ねたウィンドウが特定の画面共有や録画でどう写るかは、OS のバージョン、共有の実装、キャプチャの方式に依存します。アプリ側が「検出されない」と保証できる性質のものではありません。README の抜粋には、どのプラットフォームの、どの共有方式で非表示になるかの検証結果が示されていません。したがって、この機能を前提にした運用判断はできません。加えて、面接や試験の場で補助ツールを使うこと自体が、多くの組織の規則で禁止されています。技術的に見えにくいことと、使ってよいことは別の話です。この点を曖昧にしたまま導入すると、ツールの問題ではなく利用者の問題として処理されます。

NOASSERTION という表示が意味するもの

GitHub 上のライセンス識別子は NOASSERTION です。これは「オープンソースライセンスとして判定できなかった」という意味で、パブリックドメインや MIT を意味しません。README とバッジは Personal Use Source という表現を使い、個人・教育・研究・非商用の利用は無償だと書いています。つまりソースは公開されているが、OSI 承認のオープンソースライセンスではない可能性が高い、という状態です。ここから実務的に言えることを整理します。商用利用の条件、再配布の可否、改変物の公開義務の有無は、LICENSE ファイルの実文を読まない限り判断できません。README の「free for personal, educational, research, and non-commercial use」という一文は、裏返せば商用には何らかの条件が付くという読み方になります。企業の端末に導入する場合、この一点が機能評価より先に来ます。法務判断は当サイトの領分ではないため、条文の確認は自組織で行ってください。

Otter や Granola とは何を最適化しているかが違う

比較対象として README 自身が挙げている Otter と Granola は、会議の記録を残して後から読む方向に最適化された製品です。会議後に要約が届き、検索でき、チームで共有できることが価値になります。Natively が最適化しているのは発話中の即時性で、500ms 未満という目標値も、オーバーレイという提示方法も、その一点に向いています。アーキテクチャ上の差はもっと単純です。Otter や Granola は録音と文字起こしをベンダーのサーバーで処理する前提で作られており、Natively は音声処理をローカルに置き、推論だけを利用者の選んだ API に投げます。この違いは、会議後の検索性ではクラウド型に分があり、機密性と費用の予測可能性ではローカル寄りに分がある、という形で現れます。どちらが優れているかではなく、記録を後から使うのか、その場の判断に使うのかで選ぶべきものです。

更新頻度と、それを支える前提

リリースは v2.6.0 が 2026 年 5 月、v2.7.0 が 6 月、v2.8.8 が 8 月と、おおむね 1 から 3 か月間隔で続いています。デスクトップアプリでこのペースを維持するには、OS 側の音声 API や画面キャプチャの変更に追随し続ける必要があります。macOS と Windows の両方を対象にしている以上、片方の破壊的変更がもう片方のリリースを遅らせる可能性は常にあります。利用者側のコストとして現実的なのは、自動更新の挙動と、更新後に API キーやローカルインデックスが保持されるかです。README の抜粋には更新方式の記述がないため、ここは導入後に自分で確認する項目になります。ソースが公開されていることは、ベンダーが開発を止めたときに自分でビルドを維持できる可能性を意味しますが、それは TypeScript のデスクトップアプリを保守できる人にとってのみ現実的な話です。

編集部の結論

個人が自分のマシンで、自分の API キーを使い、自分だけの会議や学習の記録を取る用途なら、Natively は試す価値のある構成です。macOS 12 以降か Windows 10/11 が必要で、配布物は Releases から取得します。逆に、チームの会議録をサーバー側で集約したい場合や、録音に対する同意取得を組織の統制下に置きたい場合には向きません。導入前に確認すべきは 3 点です。第一に LICENSE ファイルの実文と、個人・教育・研究・非商用という範囲が自組織の利用形態を含むか。第二に、stealth mode が対象プラットフォームの画面共有や録画でどう見えるか。第三に、文字起こしと LLM 呼び出しのうちどこまでがローカルで完結し、どこから外部 API に送られるかです。この 3 点が自組織の基準を満たさないなら、機能の比較に進む意味はありません。

公式情報源

1. Issues
2. Natively-AI-assistant/natively-cluely-ai-assistant on GitHub
3. Project website
4. README
5. Releases