仕事で Mac と Windows PC を行き来したことがあるなら、非対称さに気づいたかもしれません。macOS は何年も前からシステム設定でシステム全体の文字置換と予測候補を提供してきたのに対し、Windows のデスクトップアプリでは、あったとしてもアプリごとの対応にとどまってきました。これはどちらのプラットフォームが「優れている」かという話ではなく、それぞれの OS が、動作するアプリに対してテキスト入力をどう見せることにしたのか、という違いです。

macOS が組み込んだもの

macOS には以前からシステムレベルの Text Replacements 機能(システム設定のキーボード内)があり、入力すると自動的に展開されるショートカットを自分で定義できます。加えて、トラックパッドやタッチ入力の場面ではキーボード上部に予測候補も表示されます。macOS は Cocoa アプリ全体で使われる統一されたテキスト入力の枠組みを握っているため、一度定義した置換や候補が、メール、メモ、Safari、そして標準のテキスト API 上に作られたあらゆるアプリで一貫して現れます。

この一貫性は、macOS のアプリケーションフレームワークから直接生まれています。ネイティブな Mac アプリの多くは同じ基盤コンポーネントを通してテキスト入力を処理するため、その層に組み込まれた機能は、ほぼ自動的にすべてのアプリへ行き渡ります。

Windows が別の道を選んだ理由

Windows のアプリケーションフレームワークの歴史は、より長く、より多彩です ―― Win32、WPF、UWP、WinUI に加えて、膨大な数の Electron / Chromium ベースのアプリ(Slack、Discord、VS Code)やブラウザーで描画されるアプリがあり、これらは単一のネイティブなテキスト入力基盤を共有していません。すべての Windows アプリが乗る唯一のフレームワークは存在せず、そのため「システム全体の予測入力」を中央で 1 つ定義し、ユーザーが打ちうるすべてのアプリで一貫して届けることは、はるかに難しくなります。

Windows にも予測入力がある場面はあります。たとえば画面上のタッチキーボードは単語候補を出します。しかしそれはタッチやタブレットのための入力面であり、Word や Outlook で物理キーボードを打っているときに現れるものではありません。デスクトップでのキーボード入力について、Windows は歴史的に、フレーズ単位の予測を OS の層ではなく個々のアプリ(一部のメールソフト、一部の IDE)に委ねてきました。

優劣の話ではありません: Windows のフレームワークの多様さは、そのまま柔軟さでもあります。同じ OS が、数十年前の Win32 ソフトから最新の Web ラップ型アプリまで動かしているのです。その柔軟さにはトレードオフがあり、システム全体の予測入力は、中央にまとめにくくなったものの 1 つでした。

実際にどうなっているか

Windows ユーザーにとっての帰結は、今日の予測入力の対応状況が、どのアプリを使っているかに完全に左右されるということです。

タッチキーボード:あり

Windows の画面キーボードは単語単位の候補を出しますが、その仮想キーボードを入力手段として使っているときに限られます。物理キーボードで打っているときには出ません。

一部のアプリ:独自機能あり

一部のアプリケーションは自前の入力補完や候補機能を備えていますが、そのアプリの中でしか働かず、ほかのどこにも引き継がれません。

デスクトップでの入力の大半:何もなし

チャットアプリ、ブラウザー、メモ帳、そしてほとんどの業務ソフトでは、打った文字がそのまま 1 文字ずつ入るだけで、フレーズ単位の候補はいっさいありません。

トレイ常駐ユーティリティですき間を埋める

Windows はこの機能を OS の層にまとめていないため、現実的な入手方法は、Windows アプリが一般にキーボード入力を受け取る仕組みに沿って働く常駐ユーティリティになります ―― どのフレームワークで作られたアプリであっても関係なく。 Typeahead for Windows はこの方式をとっています。システムトレイから動作し、ほぼすべてのデスクトップアプリでカーソルを追いかけます ―― WhatsApp、Telegram、Slack、Chrome、Edge、Firefox、Outlook、Thunderbird、Word、メモ帳、Notepad++、そして VS Code のチャット欄とテキスト欄。個々のアプリが自前の提案エンジンを作るのを待つ必要はありません。

これは実質的に、OS の層でまとめられなかったものをアプリケーションの層で解決するということです。ツール 1 つ、モデル 1 つで、目の前のアプリがどのフレームワークで作られていようと、一貫して働きます。

提案は実際どのように現れるか

Typeahead は入力に合わせて、いま書いている文の残りをカーソルの隣にゴーストテキストとして表示します。 Tab キー(既定値、変更可能)を押せば確定して先へ進め、そのまま打ち続ければ無視されます。確定キーを押さないかぎり、何かが勝手に挿入されることはありません。ローカルモデル(llama.cpp 上の Qwen 3)で完全にオフライン動作するため、特定のアプリのクラウド連携や特定の OS 機能の有無に依存しません。

観点 macOS 標準 Windows 標準 Typeahead for Windows
対象範囲 システム全体(Cocoa アプリ) アプリごと、またはタッチキーボードのみ 対応アプリ全体にわたってシステム全体
候補の種類 単語・フレーズの置換 単語単位(タッチキーボード) フレーズや文まるごとの続き
オフラインで動作 はい はい はい

よくある質問

Windows に標準の予測入力はありますか?
画面上のタッチキーボードは単語候補を出しますが、これはその仮想キーボードを入力手段として使っている場合に限られます。デスクトップアプリで物理キーボードを打っているときには当てはまりません。
macOS の Text Replacements のようなシステム全体の機能が Windows にないのはなぜですか?
Windows のアプリは、Win32、WPF、UWP、WinUI、Electron、ブラウザー描画型など、はるかに多様なフレームワークの上に作られており、ネイティブな Mac アプリの多くが Cocoa を共有しているようなテキスト入力の共通層がありません。この多様さゆえに、中央で 1 つの機能を定義し、すべてのアプリで一貫して実装することが難しくなっています。
これは Windows への批判ですか?
いいえ ―― 設計上のトレードオフを説明しているだけです。システム全体の予測をまとめにくくしているのと同じフレームワークの多様さが、旧来の Win32 アプリから最新の Web ラップ型ツールまで、膨大な種類のソフトを Windows で動かせる理由でもあります。
では Typeahead はどうやって、これほど多くのアプリで動いているのですか?
特定のアプリフレームワークに依存せず、OS の入力レベルでカーソルを見張るトレイ常駐ユーティリティとして動作します。だからこそメッセンジャー、ブラウザー、メールソフト、Word、テキストエディターにわたって一貫して提案できます。
どのアプリでも同じように動きますか?
提案の仕組みは共通です ―― カーソルの隣のゴーストテキストを Tab キーで確定します。ただし Typeahead はアプリごとに有効・無効を切り替えられ、VS Code ではチャット欄とテキスト欄に対応する一方、コードバッファーは既定でオフです。

Typeahead を入手

Windows 10/11 向けの、システム全体で使える文の予測。9.99 ドルの買い切り、7 日間の無料体験付き。

 Microsoft Store で入手