2022年ごろから「生成AI」を中心に巻き起こった第3次AIブームは、舞台をクラウドからオンデバイスに移し、そしてOSなどの基礎プラットフォーム自体に組み込まれるようになり、一部では「第4次AIブーム」と呼ばれるフェーズへと移行しました。

この流れに随分敏感に乗っているのがMicrosoftです。Microsoftは、昨年の年初早々に2024年以降に発売されるPCへの「Copilot」キーの搭載を発表したのです。OS分野でのプラットフォーマーである同社が発したこの方針に各社従わざるを得ず、結果として現在流通する多くの新製品のPCにはCopilotキーが標準で搭載されていますね。

今回はそのCopilotキーの話。

Copilotキー

Copilotキーは、その名の通りAIアシスタントであるCopilotを起動するためのキーです。これまでは、タスクバーのCopilotボタンを押すことで起動できましたが、これが物理キーとしてキーボードに組み込まれた形です。

数十年ぶりの新しいキーの追加にしてはかなりあっさりと追加されたような気がします。

Copilotキーの位置については各社の判断に委ねられていますが、ほとんどの場合において「アプリケーション」（コンテクストを開く）キーまたは右Windowsキーを置き換えることが多いです。

このキーの機能的な不満。

まず、機能的な不満を述べていきます。CopilotキーでCopilotが起動した場合、そのCopilotはウィンドウとして起動します。その上、スタートメニューほど敏感に立ち上がってくれません。レスポンスが悪い。

その上、開いたウィンドウはCopilotキーで閉じることができますが、ESCキーで閉じることができません。これが厄介（もしかしたらどうにかできるのかもしれないけど）。

あと、Copilotはスタートメニューと違ってアプリケーションとして起動するため、しっかりと「閉じる」をクリックしないとタスクバーに居座ります。

Copilotキーの仕様

では、Copilotキーの仕様について見ていきます。

CopilotキーはCopilotキー単体で3つのキーのショートカットとして動作します。

通常、Windowsは、キーボードとマウスのすべてのキー・ボタンの入力に対して、特定の「Virtual-Key」（VK）コードを割り当て、そのVKコードを基に入力を判定しています。例えば、普通の英語キーであれば、AやBというVKコードが割り当てられていますし、スペースキーならVK_SPACEというVKコードが割り当てられています。

Windowsキーやアプリケーションキーもそれぞれ例外ではなく、それぞれVK_LWIN（左のWinキー）、VK_APPS（アプリケーションキー）が割り当てられています。

では、Copilotキーはどうでしょうか。実は、CopilotキーにはこのVKコードが単独で割り振られていません。実は、Copilotキーは「Windowsキー」「Shiftキー」「F23キー」のショートカットとして割り当てられています。つまり、Copilotキーを押すことで、実質的に前述の3つのキーが同時に押されたという判定になるのです。

本当は、Copilotキー搭載PCを用意してその挙動を確認したのですが、残念ながら今手元にありません。なのでその逆、前述のショートカットを使用して、Copilotが立ち上がるのかどうかを調べてみます。

実験

私のキーボード、WinキーとShiftキーはありますが、流石にF23キーはないので、PowerToysを使ってF23キーを擬似的に作り上げます。

そして、Windows + Shift + 右Alt（F23）を同時に入力すると・・・

Copilotが起動しました。つまり、Copilotキーは、WindowsキーとShiftキーとF23キーの同時押しで起動するということがわかりました。

問題点

では、このCopilotキーの挙動について、問題点を指摘していきましょう。

未定義スキャンコードの問題

Copilotキーを搭載するPC・ハードウェアにおいて、Copilotキーを押すと、Win+Shift+F23のショートカットが入力され、信号として送信されると組み込まれています。つまり、1キーに対して3キーの信号が割り当てられる事になりました。

ハードウェアはシステムに対して、キーボードが入力された際に「スキャンコード」という符号で信号を送っています。そのスキャンコードを基に、OS側でVKに変換して解釈しています。例えば、Windowsの場合、左Winキーを押すと、0x5Bというスキャンコードがキーボードからシステムに送信され、WindowsがこのスキャンコードをVK_LWINと解釈してスタートメニューが開かれます。

通常、このスキャンコードは一部のキーボードの機能的なものを除いて、1キーあたり1つのスキャンコードが割り当てられています。しかし、Copilotキーは前述の通り、Win+Shift+F23のショートカットであるため、Winキーのスキャンコード0x5B、Shiftキーのスキャンコード0x2A（または0x36）、F23のスキャンコード0x6Eが同時に送信されます。

Windowsでは、この3つのキーの組み合わせがCopilotキーのショートカットであると解釈されますが、Copilotキーの定義がなされていないシステムでは、Copilotキーを単なる3つのキーの組み合わせとして認識します。これらのキーはそれぞれ独立した機能を持つため、Copilotキーとしての動作は期待できません。

LinuxでスキャンコードとLinuxのキーコードの対応を担っているatkbdは、Linux 6.14に至るまでF23用のキーコード（WinでのVKのようなもの）を用意していなかったのでこのキーは実質的にWin（Metaキー）+Shiftという組み合わせとして認識されていました。

カーネルとして対応していなかったため、ユーザー空間でCopilotキーの挙動を定義していたとしても利用することができませんでした。

Linuxでは、この問題がv6.14でスキャンコード0x6eに対して、新しいキーコード193（KEY_F23）を割り当てることで解消していますが、LTSバージョンなどではまだこれに対応していません。

3キーの組み合わせ

加えて、3キーの組み合わせが送信されることによって、安価なシステムなどではCopilotキーと組み合わせたキーが利用できないという問題もあります。

現代のハードウェアにおいて、ショートカットキーなどが発展した関係で、代替のシステムが5キー程度のキーボード同時押しに対応しています。ただ、安価なシステムでは3キーロールオーバー（同時押しが3キーまで）にサポートがとどまっている場合があり、この場合、Copilotキーだけでその3キー分を使い果たしてしまいます。

このため、Copilot + 別のキーのような使い方ができません。CopilotをWinキー（あるいはMetaキー）として利用したい場合には割と問題があるような気がしますね。

まとめ

ということで、今回はCopilotキーの不満点に重きをおいて記事を書いてみました。

MicrosoftがCopilotキーを追加したときに、特定のスキャンコードとVKを用意しなかったのは、もはやコンピュータが成熟したこの現代において、新しくそれらをCopilot用に確保してしまうと、一部のベンダーのキーマッピングと競合するなど、何等かの不具合が生じる懸念があったからだと推測されます。

ただ、ちょっとお粗末な対応ではなかったかなとは思います。あまりにも劇的な追加だったので、Windows以外の対応が遅れ、Linuxの対応も1年も後の話になりました。今後、Copilotキー搭載のキーボードが登場するかは不明ですが、この変更はMacにも影響を与える可能性が高いです。

かと言って、追加してしまった今の状況から仕様を変更するのも、反感を買いそう。個人的にScroll LockキーあたりにCopilotの機能統合すればよかったのではないか・・・なんて思ったりしています。ほなまた。